Nowadays, due to excessive queuing, delays on the Internet can grow longer than the round trip time between the Moon and the Earth – for which the “bufferbloat” term was recently coined. Some point to active queue management (AQM) as the solution. Others propose end-to-end low-priority congestion control techniques (LPCC). Under both approaches, promising advances have been made in recent times: notable examples are CoDel for AQM, and LEDBAT for LPCC. In this paper, we warn of a potentially fateful interaction when AQM and LPCC techniques are combined: namely, AQM resets the relative level of priority between best-effort and low-priority congestion control protocols. We validate the generality of our findings by an extended set of experiments with packet-level ns2 simulation, considering 5 AQM techniques and 3 LPCC protocols, and carry on a thorough sensitivity analysis varying several parameters of the networking scenario. We complete the simulation via an experimental campaign conducted on both controlled testbeds and on the Internet, confirming the reprioritization issue to hold in the real world at least under all combination of AQM policies and LPCC protocols available in the Linux kernel. To promote cross-comparison, we make our scripts and dataset available to the research community.

Nowadays, due to excessive queuing, delays on the Internet can grow longer than several round trips between the Moon and the Earth - for which the “bufferbloat” term was recently coined. Some point to active queue management (AQM) as the solution. Others propose end-to-end low-priority congestion control techniques (LPCC). Under both approaches, promising advances have been made in recent times: notable examples are CoDel for AQM, and LEDBAT for LPCC. In this paper, we warn of a potentially fateful interaction when AQM and LPCC techniques are combined: namely (i) AQM resets the relative level of priority between best effort and low-priority congestion control protocols; (ii) while reprioritization generally equalizes the priority of LPCC and TCP, we also find that some AQM settings may actually lead best effort TCP to starvation. By an extended set of experiments conducted on both controlled testbeds and on the Internet, we show the problem to hold in the real world for all tested combination of AQM policies and LPCC protocols. To further validate the generality of our findings, we complement our experiments with packet-level simulation, to cover cases of other popular AQM and LPCC that are not available in the Linux kernel. To promote cross-comparison, we make our scripts and dataset available to the research community.

Many researchers have recently dealt with P2P traffic classification, mainly because P2P applications are continuously growing in number as well as in traffic volume. Additionally, in response to the shift of the operational community from packet-level to flow-level monitoring, witnessed by the widespread use of NetFlow, a number of behavioral classifiers have been proposed. These techniques, usually having P2P applications as their main target, base the classification on the analysis of the pattern of traffic generated by a host and proved accurate even when using only flow-level data. Yet, all these approaches are very specific and the community lacks a broader view of the actual amount of information of behavioral features derived by flow-level data. The preliminary results presented in this paper try to fill this gap. First of all we define a comprehensive framework by means of which we systematically explore the space of behavioral properties and build a large set of potentially expressive features. Thanks to our general approach, most features already used by existing classifiers fall into this set. Then, by employing tools from information theory and data from packet-level traces captured on real networks, we evaluate the amount of information conveyed by each feature, ranking them according to their usefulness for application identification. Finally we show the classification performance of these set of features, using a supervised machine learning algorithm.

This work studies the impact of flow sampling on the accuracy of behavioral traffic classification. More precisely, we consider the case where the traffic classification engine is located at different vantage points of the network. Usually, behavioral classification is performed close to the user access network - where all the traffic exchanged by an endpoint can be observed. In this work instead we take into account the case of a classifier placed deeper in the aggregation network - where, due to load balancing or routing issues, only part of the traffic is generally observed. We use the Abacus behavioral classification engine as our case study, as it has been shown to provide accurate classification of P2P applications, by relying only on the count of packets and bytes peers exchange during fixed-length time-windows. We further consider multiple policies of flow sampling, that either reflect real router forwarding table, or allow to assess parameter impact under controlled settings. An accurate measurement campaign shows that, provided that the signature definition does not rely on absolute counters of the traffic volume (e.g., which can be achieved by means of normalization), even when signatures are computed over a minority of the traffic (e.g., about 10%) the classification is still reliable (e.g, accuracy exceeds 75%).

BitTorrent developers have recently introduced a new application layer congestion control algorithm based on UDP framing at transport layer and currently under definition at the IETF ledbat Working Group. Ledbat is a delay-based protocol which aims at offering a ``lower than Best Effort'''' data transfer service, with a lower priority with respect to elastic TCP and interactive traffic (e.g., VoIP, game). However, in its current specification, ledbat is affected by a late-comer advantage: indeed the last flow arriving at the bottleneck is more aggressive due to a wrong estimation of the base delay and finally takes over all resources. In this work, we study several solutions to the late-comer problem by means of packet level simulations and simple analysis: in the investigation process, we individuate the root cause for LEDBAT unfairness and propose effective countermeasures.

A few months ago, BitTorrent developers announced that the transfer of torrent data in the official client was about to switch to a new application-layer congestion-control protocol using UDP at the transport-layer. This announcement immediately raised an unmotivated buzz about a new, imminent congestion collapse of the whole Internet. As the new congestion control aims at offering a lower than best effort transport service, this reaction was not built on solid technical foundation. Nevertheless, a legitimate question remains: whether this new protocol is a necessary building block for future Internet applications, or whether it may result in an umpteenth addition to the already well populated world of Internet congestion control algorithms. To tackle this issue, we implement the novel congestion control algorithm and investigate its performance by means of packet-level simulations. Considering a simple bottleneck scenario, where the new BitTorrent competes against either TCP or other BitTorrent flows, we evaluate the fairness of resource share as well as the protocol efficiency. Our results show that the new protocol successfully meets some of its design goals, as for instance the efficiency one. At the same time, we also identify some potential fairness issues, that need to be dealt with. Finally, we point out that end-users will be the final judges of the new protocol: therefore, further research should evaluate the effects of its adoption on the performance of the applications ultimately relying on it.

Nowadays Cisco Netflow is the de facto standard tool used by network operators and administrators for monitoring large edge and core networks. Implemented by all major vendors and recently a IETF standard, Netflow reports aggregated information about traffic traversing the routers in the form of flow-records. While this kind of data is already effectively used for accounting, monitoring and anomaly detection, the limited amount of information it conveys has until now hindered its employment for traffic classification purposes. In this paper, we present a behavioral algorithm which successfully exploits Netflow records for traffic classification. Since our classifier identifies an application by means of the simple counts of received packets and bytes, Netflow records contain all information required. We test our classification engine, based on a machine learning algorithm, over an extended set of traces containing a heterogeneous mix of applications ranging from P2P file-sharing and P2P live-streaming to traditional client-server services. Results show that our methodology correctly identifies the byte-wise traffic volume with an accuracy of 90% in the worst case, thus representing a first step towards the use of Netflow data for fine-grained classification of network traffic.

It is a common belief that using a virtual machine for portable executions of data-plane packet-processing applications would introduce too many penalties in terms of performance, because of the assumed overhead caused by the presence of a hardware abstraction layer. Even if common sense proves true in the case of general purpose virtual machines, such as the JVM and the CLR, it may be wrong in case of a special-purpose network-oriented virtual machine. This paper describes the architecture of a run-time environment and a compiler infrastructure for the Network Virtual Machine (NetVM), showing that the portability of packet-processing programs can be achieved without additional penalties even over heterogeneous platforms. Our implementation supports three different target architectures: one with a general purpose processor (Intel x86), one with a multi-core network processor (Cavium Octeon) and one with a systolic-array network processor (Xelerated X11), and shows that the NetVM model (i) is able to abstract such heterogeneous platforms and (ii) enables the exploitation of hardware functionalities provided by the specific architecture; finally, it demonstrates that the performances of NetVM programs compiled into native code are comparable to those obtained using commercial general purpose compilers.