arXiv subjects

Olivier Bonaventure

Publications and source records attributed to Olivier Bonaventure.

16 recordsLinked to original sources

arXiv2024

Adaptive Address Family Selection for Latency-Sensitive Applications on Dual-stack Hosts

Latency is becoming a key factor of performance for Internet applications and has triggered a number of changes in its protocols. Our work revisits the impact on latency of address family selection in dual-stack hosts. Through RIPE Atlas measurements, we analyse the address families latency difference and establish two requirements based on our findings for a latency-focused selection mechanism. First, the address family should be chosen per destination. Second, the choice should be able to evolve over time dynamically. We propose and implement a solution formulated as an online learning problem balancing exploration and exploitation. We validate our solution in simulations based on RIPE Atlas measurements, implement and evaluate our prototype in four access networks using Chrome and popular web services. We demonstrate the ability of our solution to converge towards the lowest-latency address family and improve the latency of transport connections used by applications.

cs.NI↗

arXiv2023

Towards SSH3: how HTTP/3 improves secure shells

The SSH protocol was designed in the late nineties to cope with the security problems of the telnetf family of protocols. It brought authentication and confidentiality to remote access protocols and is now widely used. Almost 30 years after the initial design, we revisit SSH in the light of recent protocols including QUIC, TLS 1.3 and HTTP/3. We propose, implement and evaluate SSH3, a protocol that provides an enhanced feature set without compromise compared to SSHv2. SSH3 leverages HTTP-based authorization mechanisms to enable new authentication methods in addition to the classical password-based and private/public key pair authentications. SSH3 users can now configure their remote server to be accessed through the identity provider of their organization or using their Google or Github account. Relying on HTTP/3 and the QUIC protocol, SSH3 offers UDP port forwarding in addition to regular TCP forwarding as well as a faster and secure session establishment. We implement SSH3 over quic-go and evaluate its performance.

cs.NI↗

arXiv2023

MCQUIC: Multicast and unicast in a single transport protocol

Multicast enables efficient one-to-many communications. Several applications benefit from its scalability properties, e.g., live-streaming and large-scale software updates. Historically, multicast applications have used specialized transport protocols. The flexibility of the recently standardized QUIC protocol opens the possibility of providing both unicast and multicast services to applications with a single transport protocol. We present MCQUIC, an extended version of the QUIC protocol that supports multicast communications. We show how QUIC features and built-in security can be leveraged for multicast transport. We present the design of MCQUIC and implement it in Cloudflare quiche. We assess its performance through benchmarks and in emulated networks under realistic scenarios. We also demonstrate MCQUIC in a campus network. By coupling QUIC with our multicast extension, applications can rely on multicast for efficiency with the possibility to fall back on unicast in case of incompatible network conditions.

cs.NI↗

arXiv2023

Routing over QUIC: Bringing transport innovations to routing protocols

By combining the security features of TLS with the reliability of TCP, QUIC opens new possibilities for many applications. We demonstrate the benefits that QUIC brings for routing protocols. Current Internet routing protocols use insecure transport protocols. BGP uses TCP possibly with authentication. OSPF uses its own transport protocol above plain IP. We design and implement a library that allows to replace the transport protocols used by BGP and OSPF with QUIC. We apply this library to the BIRD routing daemon and report preliminary results.

cs.NI↗

arXiv2022

FlEC: Enhancing QUIC with application-tailored reliability mechanisms

Packet losses are common events in today's networks. They usually result in longer delivery times for application data since retransmissions are the de facto technique to recover from such losses. Retransmissions is a good strategy for many applications but it may lead to poor performance with latency-sensitive applications compared to network coding. Although different types of network coding techniques have been proposed to reduce the impact of losses by transmitting redundant information, they are not widely used. Some niche applications include their own variant of Forward Erasure Correction (FEC) techniques, but there is no generic protocol that enables many applications to easily use them. We close this gap by designing, implementing and evaluating a new Flexible Erasure Correction (FlEC) framework inside the newly standardized QUIC protocol. With FlEC, an application can easily select the reliability mechanism that meets its requirements, from pure retransmissions to various forms of FEC. We consider three different use cases: $(i)$ bulk data transfer, $(ii)$ file transfers with restricted buffers and $(iii)$ delay-constrained messages. We demonstrate that modern transport protocols such as QUIC may benefit from application knowledge by leveraging this knowledge in FlEC to provide better loss recovery and stream scheduling. Our evaluation over a wide range of scenarios shows that the FlEC framework outperforms the standard QUIC reliability mechanisms from a latency viewpoint.

cs.IT↗

arXiv2019

Increasing broadband reach withHybrid Access Networks

End-users and governments force network operators to deploy faster Internet access services everywhere. Access technologies such as FTTx, VDSL2, DOCSIS3.0 can provide such services in cities. However, it is not cost-effective for network operators to deploy them in less densely populated regions. The recently proposed Hybrid Access Networks allow to boost xDSL networks by using the available capacity in existing LTE networks. We first present the three architectures defined by the Broadband Forum for such Hybrid Access Networks. Then we describe our experience with the implementation and the deployment of Multipath TCP-based Hybrid Access Networks.

cs.NI↗

arXiv2019

Flexible Anonymous Network

Internet technologies have been designed from guidelines like the robustness principle also known as Postel's law. Jon Postel's law is described as: "Be conservative in what you do, be liberal in what you accept from others." Fundamentally, it advises protocol designs to be tolerant with what they accept from the other peers. We propose to take a step back and wonder how the robustness principle could be revisited to support security requirements as well as unifying flexibility from specifications, protocol design and software implementations. Our goal would be to define a software architecture that offers the benefits of the robustness principle (i.e., efficient network services despite the presence of various software versions), while also guaranteeing that this robustness cannot be exploited by making sure that it is only used to support authentic evolution of the protocol specification.

cs.CR↗

arXiv2019

Beyond socket options: making the Linux TCP stack truly extensible

The Transmission Control Protocol (TCP) is one of the most important protocols in today's Internet. Its specification and implementations have been refined for almost forty years. The Linux TCP stack is one of the most widely used TCP stacks given its utilisation on servers and Android smartphones and tablets. However, TCP and its implementations evolve very slowly. In this paper, we demonstrate how to leverage the eBPF virtual machine that is part of the recent versions of the Linux kernel to make the TCP stack easier to extend. We demonstrate a variety of use cases where the eBPF code is injected inside a running kernel to update or tune the TCP implementation. We first implement the TCP User Timeout Option. Then we propose a new option that enables a client to request a server to use a specific congestion control scheme. Our third extension is a TCP option that sets the initial congestion window. We then demonstrate how eBPF code can be used to tune the acknowledgment strategy.

cs.NI↗

arXiv2019

QUIC-FEC: Bringing the benefits of Forward Erasure Correction to QUIC

Originally implemented by Google, QUIC gathers a growing interest by providing, on top of UDP, the same service as the classical TCP/TLS/HTTP/2 stack. The IETF will finalise the QUIC specification in 2019. A key feature of QUIC is that almost all its packets, including most of its headers, are fully encrypted. This prevents eavesdropping and interferences caused by middleboxes. Thanks to this feature and its clean design, QUIC is easier to extend than TCP. In this paper, we revisit the reliable transmission mechanisms that are included in QUIC. More specifically, we design, implement and evaluate Forward Erasure Correction (FEC) extensions to QUIC. These extensions are mainly intended for high-delays and lossy communications such as In-Flight Communications. Our design includes a generic FEC frame and our implementation supports the XOR, Reed-Solomon and Convolutional RLC error-correcting codes. We also conservatively avoid hindering the loss-based congestion signal by distinguishing the packets that have been received from the packets that have been recovered by the FEC. We evaluate its performance by applying an experimental design covering a wide range of delay and packet loss conditions with reproducible experiments. These confirm that our modular design allows the protocol to adapt to the network conditions. For long data transfers or when the loss rate and delay are small, the FEC overhead negatively impacts the download completion time. However, with high packet loss rates and long delays or smaller files, FEC allows drastically reducing the download completion time by avoiding costly retransmission timeouts. These results show that there is a need to use FEC adaptively to the network conditions.

cs.NI↗

arXiv2019

Scaling Networking Education with Open Educational Resources

To reflect the key role played in our society by the network technologies, the networking courses have moved to Bachelor degrees where they are taught to large classes. We report our experience in developing an open-source ebook that targets those introductory networking courses and a series of open educational resources that complement the ebook.

cs.CY↗

arXiv2019

COP2: Continuously Observing Protocol Performance

As enterprises move to a cloud-first approach, their network becomes crucial to their daily operations and has to be continuously monitored. Although passive monitoring can be convenient from a deployment viewpoint, inferring the state of each connection can cause them to miss important information (e.g., starvation). Furthermore, the increasing usage of fully encrypted protocols (e.g., QUIC encrypts headers), possibly over multiple paths (e.g., MPTCP), keeps diminishing the applicability of such techniques to future networks. We propose a new monitoring framework, Flowcorder, which leverages information already maintained by the end-hosts and records Key Performance Indicators (KPIs) from their transport protocols. More specifically, we present a generic approach which inserts lightweight eBPF probes at runtime in the protocol implementations. These probes extract KPIs from the per-connection states, and eventually export them over IPFIX for analysis. We present an application of this technique to the Linux kernel TCP stack and demonstrate its generality by extending it to support MPTCP. Our performance evaluation confirms that its overhead is negligible. Finally, we present live measurements collected with Flowcorder in a campus network, highlighting some insights provided by our framework.

cs.NI↗

arXiv2018

Flexible failure detection and fast reroute using eBPF and SRv6

Segment Routing is a modern variant of source routing that is being gradually deployed by network operators. Large ISPs use it for traffic engineering and fast reroute purposes. Its IPv6 dataplane, named SRv6, goes beyond the initial MPLS dataplane, notably by enabling network programmability. With SRv6, it becomes possible to define transparent network functions on routers and endhosts. These functions are mapped to IPv6 addresses and their execution is scheduled by segments placed in the forwarded packets. We have recently extended the Linux SRv6 implementation to enable the execution of specific eBPF code upon reception of an SRv6 packet containing local segments. eBPF is a virtual machine that is included in the Linux kernel. We leverage this new feature of Linux 4.18 to propose and implement flexible eBPF-based fast-reroute and failure detection schemes. Our lab measurements confirm that they provide good performance and enable faster failure detections than existing BFD implementations on Linux routers and servers.

cs.NI↗

arXiv2018

Leveraging eBPF for programmable network functions with IPv6 Segment Routing

With the advent of Software Defined Networks (SDN), Network Function Virtualisation (NFV) or Service Function Chaining (SFC), operators expect networks to support flexible services beyond the mere forwarding of packets. The network programmability framework which is being developed within the IETF by leveraging IPv6 Segment Routing enables the realisation of in-network functions. In this paper, we demonstrate that this vision of in-network programmability can be realised. By leveraging the eBPF support in the Linux kernel, we implement a flexible framework that allows network operators to encode their own network functions as eBPF code that is automatically executed while processing specific packets. Our lab measurements indicate that the overhead of calling such eBPF functions remains acceptable. Thanks to eBPF, operators can implement a variety of network functions. We describe the architecture of our implementation in the Linux kernel. This extension has been released with Linux 4.18. We illustrate the flexibility of our approach with three different use cases: delay measurements, hybrid networks and network discovery. Our lab measurements also indicate that the performance penalty of running eBPF network functions on Linux routers does not incur a significant overhead.

cs.NI↗

arXiv2018

Observing the Evolution of QUIC Implementations

The QUIC protocol combines features that were initially found inside the TCP, TLS and HTTP/2 protocols. The IETF is currently finalising a complete specification of this protocol. More than a dozen of independent implementations have been developed in parallel with these standardisation activities. We propose and implement a QUIC test suite that interacts with public QUIC servers to verify their conformance with key features of the IETF specification. Our measurements, gathered over a semester, provide a unique viewpoint on the evolution of a protocol and of its implementations. They highlight the arrival of new features and some regressions among the different implementations.

cs.NI↗

arXiv2018

Adding Forward Erasure Correction to QUIC

Initially implemented by Google in the Chrome browser, QUIC gathers a growing interest. The first stable specification for QUIC v1 is expected by the end of 2018. It will deliver the same features as TCP+TLS+HTTP/2. The flexible design adopted by the IETF for QUIC enables this new protocol to support a variety of different use cases. In this paper, we revisit the reliable transmission mechanisms that are included in QUIC. More specifically, we design, implement and evaluate Forward Erasure Correction extensions to QUIC. Our design supports a generic FEC frame and our implementation includes the XOR, Reed-Solomon and Convolutional RLC schemes. We evaluate its performance by applying an experimental design with a wide range of packet loss conditions. In single-path scenarios, RLC delivers more data than the two other schemes with short loss bursts. Reed-Solomon outperforms RLC when the bursts are longer. We also apply FEC to Multipath QUIC with a new packet scheduler that helps to recover more lost packets.

cs.NI↗

arXiv2017

TCPSnitch: Dissecting the Usage of the Socket API

Networked applications interact with the TCP/IP stack through the socket API. Over the years, various extensions have been added to this popular API. In this paper, we propose and implement the TCPSnitch software that tracks the interactions between Linux and Android applications and the TCP/IP stack. We collect a dataset containing the interactions produced by more than 120 different applications. Our analysis reveals that applications use a variety of API calls. On Android, many applications use various socket options even if the Java API does not expose them directly. TCPSnitch and the associated dataset are publicly available.

cs.NI↗