Watching the IPv6 Takeoff from an IXP's Viewpoint

The different level of interest in deploying the new Internet address space across network operators has kept IPv6 tardy in its deployment. However, since the last block of IPv4 addresses has been assigned, Internet communities took the concern of the address space scarcity seriously and started to move forward actively. After the successful IPv6 test on 8 June, 2011 (World IPv6 Day [1]), network operators and service/content providers were brought together for preparing the next step of the IPv6 global deployment (World IPv6 Launch on 6 June, 2012 [2]). The main purpose of the event was to permanently enable their IPv6 connectivity. In this paper, based on the Internet traffic collected from a large European Internet Exchange Point (IXP), we present the status of IPv6 traffic mainly focusing on the periods of the two global IPv6 events. Our results show that IPv6 traffic is responsible for a small fraction such as 0.5% of the total traffic in the peak period. Nevertheless, we are positively impressed by the facts that the increase of IPv6 traffic/prefixes shows a steep increase and that the application mix of IPv6 traffic starts to imitate the one of IPv4-dominated Internet

How happy are your flows: an empirical study of packet losses in router buffers

Studies of Internet traffic have revealed that traffic is consistent with self-similar scaling, shows long-range dependence, and that flow sizes are consistent with heavytailed distributions. However, how such characteristics affect fundamental network properties such as buffer overflows and therefore the loss process and link utilization has not been explored in detail. Relying on advanced instrumentation via NetFPGA cards, we perform a sensitivity study of the packet loss process within routers for different network load levels, flow size distributions, and buffer sizes. We find that packet losses do not affect all flows similarly. Depending on the network load and the buffer sizes, some flows either suffer from significantly more drops or significantly less drops than the average loss rate. Very few flows actually observe a loss rate similar to the average loss rate. Therefore, any single flow is very unlikely to observe the global packet loss process. Furthermore, the loss process can exhibit scaling properties

Exploiting Locality of Churn for FIB Aggregation

Snapshots of the Forwarding Information Base (FIB) in Internet routers can be compressed (or aggregated) to at least half of their original size, as shown by previous studies. In practice however, the permanent stream of updates to the FIB due to routing updates complicates FIB aggregation: keeping an optimally aggregated FIB in face of these routing updates is algorithmically challenging. A sensible trade-off has to be found between the aggregation gain and the number of changes to the aggregated FIB. This paper is the first to investigate whether the spatial and temporal locality properties of updates to the tree-like FIB data structure can be leveraged by online FIB aggregation. Our contributions include (a) an empirical study of the locality of updates in public Internet routing data, (b) the specification and simulations of our Locality-aware FIB Aggregation algorithm (LFA), and (c) a competitive analysis that sheds light on the performance of online algorithms under worst-case update streams. Our results show that even a simple algorithm like LFA can effectively exploit the locality of FIB churn to keep low the number of updates to the aggregated FIB, as most FIB updates affect only a small number of regions in the FIB

Understanding Flow Performance in the Wild

Abstract-Recent Internet studies have reported on continued traffic growth and popularity of web-based applications. Any adverse impact that these observed trends may have on Internet traffic flows can result in sub par performance, which in turn results in unsatisfactory user experience. Leveraging data collected at a major content distribution network (CDN), we investigate flow-level performance in the wild. We observe that packet losses differ widely across flows of different sizes, and even for flows of similar size. To shed light on these observations, we rely on a controlled testbed setup with advanced instrumentation via NetFPGA cards. We highlight the key factors which can degrade flow-performance across different network loads and flow-size distributions. We find that packet losses do not affect all flows similarly. Depending on the network load, some flows either suffer from significantly more drops (unhappy flows) or significantly less drops than the average loss rate (happy flows). Very few flows actually observe a loss rate similar to the average loss rate. Therefore, any single flow is very unlikely to observe the global packet loss process. Furthermore, we find that some flows are burstier than others as indicated by their average congestion window

OFLOPS: An Open Framework for Openflow Switch Evaluation,” in PAM,

Abstract. Recent efforts in software-defined networks, such as OpenFlow, give unprecedented access into the forwarding plane of networking equipment. When building a network based on OpenFlow however, one must take into account the performance characteristics of particular OpenFlow switch implementations. In this paper, we present OFLOPS, an open and generic software framework that permits the development of tests for OpenFlow-enabled switches, that measure the capabilities and bottlenecks between the forwarding engine of the switch and the remote control application. OFLOPS combines hardware instrumentation with an extensible software framework. We use OFLOPS to evaluate current OpenFlow switch implementations and make the following observations: (i) The switching performance of flows depends on applied actions and firmware. (ii) Current OpenFlow implementations differ substantially in flow updating rates as well as traffic monitoring capabilities. (iii) Accurate OpenFlow command completion can be observed only through the data plane. These observations are crucial for understanding the applicability of OpenFlow in the context of specific use-cases, which have requirements in terms of forwarding table consistency, flow setup latency, flow space granularity, packet modification types, and/or traffic monitoring abilities

OFLOPS: An Open Framework for Openflow Switch Evaluation,” in PAM,

Abstract. Recent efforts in software-defined networks, such as OpenFlow, give unprecedented access into the forwarding plane of networking equipment. When building a network based on OpenFlow however, one must take into account the performance characteristics of particular OpenFlow switch implementations. In this paper, we present OFLOPS, an open and generic software framework that permits the development of tests for OpenFlow-enabled switches, that measure the capabilities and bottlenecks between the forwarding engine of the switch and the remote control application. OFLOPS combines hardware instrumentation with an extensible software framework. We use OFLOPS to evaluate current OpenFlow switch implementations and make the following observations: (i) The switching performance of flows depends on applied actions and firmware. (ii) Current OpenFlow implementations differ substantially in flow updating rates as well as traffic monitoring capabilities. (iii) Accurate OpenFlow command completion can be observed only through the data plane. These observations are crucial for understanding the applicability of OpenFlow in the context of specific use-cases, which have requirements in terms of forwarding table consistency, flow setup latency, flow space granularity, packet modification types, and/or traffic monitoring abilities

OFLOPS: An Open Framework for OpenFlow Switch Evaluation

Abstract. Recent efforts in software-defined networks, such as OpenFlow, give unprecedented access into the forwarding plane of networking equipment. When building a network based on OpenFlow however, one must take into account the performance characteristics of particular OpenFlow switch implementations. In this paper, we present OFLOPS, an open and generic software framework that permits the development of tests for OpenFlow-enabled switches, that measure the capabilities and bottlenecks between the forwarding engine of the switch and the remote control application. OFLOPS combines hardware instrumentation with an extensible software framework. We use OFLOPS to evaluate current OpenFlow switch implementations and make the following observations: (i) The switching performance of flows depends on applied actions and firmware. (ii) Current OpenFlow implementations differ substantially in flow updating rates as well as traffic monitoring capabilities. (iii) Accurate OpenFlow command completion can be observed only through the data plane. These observations are crucial for understanding the applicability of Open-Flow in the context of specific use-cases, which have requirements in terms of forwarding table consistency, flow setup latency, flow space granularity, packet modification types, and/or traffic monitoring abilities.