Kristjon Ciko, Peyman Teymoori, Michael Welzl
Abstract
We present LGC-ShQ, a new ECN-based congestion control mechanism for datacenters. LGC-ShQ relies on ECN feedback from a Shadow Queue, and it uses ECN not only to decrease the rate, but it also increases the rate in relation to this signal. Real-life tests in a Linux testbed show that LGC-ShQ keeps the real queue at low levels while achieving good link utilization and fairness.
Wang Chao, Alessandro Finamore, Lixuan Yang, Kevin Fauvel, Dario Rossi
Abstract
The recent success of Artificial Intelligence (AI) is rooted into several concomitant factors, namely theoretical progress coupled to practical availability of data and computing power. Therefore, it is not surprising that the lack of high quality data is often recognized as one of the major factors limiting AI research in several domains, and the networking domain is not excluded. Large companies have access to large data assets, that would constitute interesting benchmarks for algorithmic research in the broader scientific community. However, such datasets are private assets that are generally very difficult to share due to privacy or business sensitivity concerns.
Following numerous requests we received from the scientific community, we release AppClassNet, a commercial-grade dataset for benchmarking traffic classification and management methodologies. AppClassNet is significantly larger than the datasets generally available to the academic community in terms of both the number of samples and classes, and reaches scales similar to the popular ImageNet dataset commonly used in computer vision literature.
To avoid leak of user- and business-sensitive information, we opportunely anonymized the dataset, while empirically showing that it still represents a relevant benchmark for algorithmic research. In this paper, we describe the public dataset as well as the steps we took to avoid leakage of sensitive information while retaining relevance as a benchmark. We hope that AppClassNet can be instrumental for other researchers to address more complex commercial-grade problems in the broad field of traffic classification and management.
Maxime Piraux, Tom Barbette, Nicolas Rybowski, Louis Navarre, Thomas Alfroy, Cristel Pelsser, François Michel, Olivier Bonaventure
Abstract
The Internet use IP addresses to identify and locate network interfaces of connected devices. IPv4 was introduced more than 40 years ago and specifies 32-bit addresses. As the Internet grew, available IPv4 addresses eventually became exhausted more than ten years ago. The IETF designed IPv6 with a much larger addressing space consisting of 128-bit addresses, pushing back the exhaustion problem much further in the future.
In this paper, we argue that this large addressing space allows reconsidering how IP addresses are used and enables improving, simplifying and scaling the Internet. By revisiting the IPv6 addressing paradigm, we demonstrate that it opens up several research opportunities that can be investigated today. Hosts can benefit from several IPv6 addresses to improve their privacy, defeat network scanning, improve the use of several mobile access networks and their mobility as well as to increase the performance of multicore servers. Network operators can solve the multihoming problem more efficiently and without putting a burden on the BGP RIB, implement Function Chaining with Segment Routing, differentiate routing inside and outside a domain given particular network metrics and offer more fine-grained multicast services.
This July 2022 issue contains one technical paper and two editorial notes.
The technical paper, The Packet Number Space Debate in Multipath QUIC, by Quentin De Coninck, deals with how QUIC packets should be numbered over multiple paths. This work provides a comparison between the usage of a single (shared) or multiple packet space numbers for QUIC multipath. The main outcome of the evaluation is that using multiple packet number spaces has the advantage that packet losses can be detected while maintaining a significantly lower state at the receiver. Also, it allows using fewer signalling frames at the cost of a more profound modification of the QUIC protocol.
We have two editorial notes. The first one, The multiple roles that IPv6 addresses can play in today’s Internet, by Maxime Piraux and his colleagues, argues that the large IPv6 addressing space allows reconsidering how IP addresses are used and enables improving, simplifying and scaling the Internet. The second, AppClassNet: A commercial-grade dataset for application identification research by Wang Chao and his colleagues, releases a commercial-grade dataset for benchmarking traffic classification and management methodologies. AppClassNet is significantly larger than the datasets generally available to the academic community.
I hope that you will enjoy reading this new issue and welcome comments and suggestions on CCR Online (https://ccronline.sigcomm.org) or by email at ccr-editor at sigcomm.org.
Quentin De Coninck
Abstract
With a standardization process that attracted much interest, QUIC can be seen as the next general-purpose transport protocol. Still, it does not provide true multipath support yet, missing some use cases that Multipath TCP addresses. To fill that gap, the IETF recently adopted a Multipath proposal merging several proposed designs. While it focuses on its core components, there still remains one major design issue: the amount of packet number spaces that should be used. This paper provides experimental results with two different Multipath QUIC implementations based on NS3 simulations to understand the impact of using one packet number space per path or a single packet number space for the whole connection. Our results show that using one packet number space per path makes Multipath QUIC more resilient to the receiver’s heuristics to acknowledge packets and detect duplicates.
Vaibhav Bajpai, Oliver Hohlfeld, Jon Crowcroft, Srinivasan Keshav, Henning Schulzrine, Jorg Ott, Simone Ferlin-Reiter, Georg Carle, Andrew Hines, Alexander Raake
Abstract
During the Covid-19 pandemic, many smaller conferences have moved entirely online and larger ones are being held as hybrid events. This reduces the carbon footprint of conference travel and
makes events more accessible to parts of the research community that have difficulty traveling long distances. Hybrid events will become an attractive alternative in the future since they make meetings broadly available without the need for travels, while preserving all elements of in-person gatherings. While we have developed a solid understanding of how to design virtual events, we do not yet know how to properly run hybrid events. We present guidelines and considerations–spanning technology, organization and social factors–for organizing successful hybrid conferences. This is the output of a Dagstuhl seminar on “Climate Friendly Internet Research” held in July 2021.
Dean H. Lorenz, David Breitgand, Kathy Barabash, Etai Lev-Ran, Danny Raz
Abstract
Cloud computing is transforming networking landscape over the last few years. The first order of business for major cloud providers today is to attract as many organizations as possible to their own clouds. To that end cloud providers offer a new generation of managed network solutions to connect the premises of the enterprises to their clouds. To serve their customers better and to innovate fast, major cloud providers are currently on the route to building their own “private Internets”, which are idiosyncratic. On the other hand, customers that do not want to stay locked by vendors and who want flexibility in using best-for-the-task services spanning multiple clouds and, possibly, their own premises, seek for solutions that will provide smart overlay connectivity across clouds.
The result of these developments is a multiplication of closed idiosyncratic solutions rather than an open standardized ecosystem. In this editorial note we argue for desirability of such an ecosystem, outline the main requirements and sketch possible solutions. We focus on enterprise as our primary use case and illustrate the main ideas through it, but the same principles apply to various different use cases.
Mike Kosek, Trinh Viet Doan, Simon Huber, Vaibhav Bajpai
Abstract
The Domain Name System (DNS) is one of the most crucial parts of the Internet. Although the original standard defined the usage of DNS over UDP (DoUDP) as well as DNS over TCP (DoTCP), UDP has become the predominant protocol used in the DNS. With the introduction of new Resource Records (RRs), the sizes of DNS responses have increased considerably. Since this can lead to truncation or IP fragmentation, the fallback to DoTCP as required by the standard ensures successful DNS responses by overcoming the size limitations of DoUDP. However, the effects of the usage of DoTCP by stub resolvers are not extensively studied to this date. We close this gap by presenting a view at DoTCP from the Edge, issuing 12.1M DNS requests from 2,500 probes toward Public as well as Probe DNS recursive resolvers. In our measurement study, we observe that DoTCP is generally slower than DoUDP, where the relative increase in Response Time is less than 37% for most resolvers. While optimizations to DoTCP can be leveraged to further reduce the response times, we show that support on Public resolvers is still missing, hence leaving room for optimizations in the future. Moreover, we also find that Public resolvers generally have comparable reliability for DoTCP and DoUDP. However, Probe resolvers show a significantly different behavior: DoTCP queries targeting Probe resolvers fail in 3 out of 4 cases, and, therefore, do not comply with the standard. This problem will only aggravate in the future: As DNS response sizes will continue to grow, the need for DoTCP will solidify.
Nicola Bonelli, Fabio Del Vigna, Alessandra Fais, Giuseppe Lettieri, Gregorio Procissi
Abstract
Software data planes running on commodity servers are very popular in real deployments. However, to attain top class performance, the software approach requires the adoption of accelerated network I/O frameworks, each of them characterized by its own programming model and API. As a result, network applications are often closely tied to the underlying technology, with obvious issues of portability over different systems. This is especially true in cloud scenarios where different I/O frameworks could be installed depending on the configuration of the physical servers in the infrastructure. The nethuns library proposes a unified programming abstraction to access and manage network operations over different I/O frameworks. The library is freely available to the community under the BSD license and currently supports AF_XDP and netmap for fast packet handling along with the classic AF_PACKET and the pcap library. Network applications based on nethuns need only to be re-compiled to run over a different network API. The experiments prove that the overhead introduced by nethuns is negligible, hence making it a convenient programming platform that eases the coding process while guaranteeing high performance and portability. As proofs of concept, a handy traffic generator as well as the popular Open vSwitch application have been successfully ported and tested over nethuns.
Khwaja Zubair Sediqi, Lars Prehn, Oliver Gasser
Abstract
Autonomous Systems (ASes) exchange reachability information between each other using BGP—the de-facto standard inter-AS routing protocol. While IPv4 (IPv6) routes more specific than /24 (/48) are commonly filtered (and hence not propagated), route collectors still observe many of them. In this work, we take a closer look at those hyper-specific prefixes (HSPs). In particular, we analyze their prevalence, use cases, and whether operators use them intentionally or accidentally. While their total number increases over time, most HSPs can only be seen by route collector peers. Nonetheless, some HSPs can be seen constantly throughout an entire year and propagate widely. We find that most HSPs represent (internal) routes to peering infrastructure or are related to address block relocations or blackholing. While hundreds of operators intentionally add HSPs to well-known routing databases, we observe that many HSPs are possibly accidentally leaked routes.