Quentin De Coninck

dblp:167/5916 · DBLP profile ↗
← Back
12ranked-venue papers
4as first author
4since 2021 · last 2026
0000-0001-6483-3157ORCID · verified

Domains — the database's venue-derived domains; a paper can count in several

Computer networks · 11 · 3 first-author · 4 since 2021Security and privacy · 1 · 1 first-author
YearPublicationVenuePosition
2026 LAMP5G: A Link-Aware Multipath QUIC Scheduler for Heterogeneous and Disruption-Prone 5G Cellular Networks
abstract
peer reviewed
Hongmiao Yu, Yuanhao Chang, Jorge Perez Ortiz, Quentin De Coninck, K. K. Ramakrishnan
IWQoS4
2023 xBGP: Faster Innovation in Routing Protocols
Thomas Wirtgen, Tom Rousseaux, Quentin De Coninck, Nicolas Rybowski, Randy Bush, Laurent Vanbever, Axel Legay, Olivier Bonaventure
NSDI3
2023 FlEC: Enhancing QUIC With Application-Tailored Reliability Mechanisms
abstract
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.
François Michel, Alejandro Cohen, Derya Malak, Quentin De Coninck, Muriel Médard, Olivier Bonaventure
IEEE/ACM Trans. Netw.4
2022 Leveraging eBPF to Make TCP Path-Aware
abstract
The Transmission Control Protocol (TCP) is one of the key Internet protocols. It is used by a broad range of applications. TCP was designed when there was typically a single path between a client and a server. Today’s networks provide higher path diversity, yet TCP still only uses the single path selected by the network layer. This limits the ability of TCP to react to events such as interdomain failures or highly congested peering links. We propose the TCP Path Changer (TPC), a set of eBPF programs that are incorporated into the Linux TCP/IP stack to make it more agile. To illustrate the benefits of our approach, we first demonstrate that TPC can quickly reroute an ongoing TCP connection around a failure. We then show that TPC can also monitor the round-trip-time of active TCP connections and automatically reroute them if it becomes too high. Our evaluation of TPC in emulated networks evidences the significant performance benefits of a path-aware transport protocol.
Mathieu Jadin, Quentin De Coninck, Louis Navarre, Michael Schapira, Olivier Bonaventure
IEEE Trans. Netw. Serv. Manag.2
2020 xBGP: When You Can't Wait for the IETF and Vendors
abstract
Thanks to the standardization of routing protocols such as BGP, OSPF or IS-IS, Internet Service Providers (ISP) and enterprise networks can deploy routers from various vendors. This prevents them from vendor-lockin problems. Unfortunately, this also slows innovation since any new feature must be standardized and implemented by all vendors before being deployed.
Thomas Wirtgen, Quentin De Coninck, Randy Bush, Laurent Vanbever, Olivier Bonaventure
HotNets2
2019 The Case for Pluginized Routing Protocols
abstract
Routing protocols such as BGP and OSPF are key components of Internet Service Provider (ISP) networks. These protocols and the operator's requirements evolve over time, but it often takes many years for network operators to convince their different router vendors and the IETF to extend routing protocols. Some network operators, notably in enterprise and datacenters have adopted Software Defined Networking (SDN) with its centralised control to be more agile. We propose a new approach to implement routing protocols that enables network operators to innovate while still using distributed routing protocols and thus keeping all their benefits compared to centralised routing approaches. We extend a routing protocol with a virtual machine that is capable of executing plugins. These plugins extend the protocol or modify its underlying algorithms through a simple API to meet the specific requirements of operators. We modify the OSPF and BGP implementations provided by FRRouting and demonstrate the applicability of our approach with several use cases.
Thomas Wirtgen, Cyril Dénos, Quentin De Coninck, Mathieu Jadin, Olivier Bonaventure
ICNP3
2019 QUIC-FEC: Bringing the benefits of Forward Erasure Correction to QUIC
abstract
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.
François Michel, Quentin De Coninck, Olivier Bonaventure
Networking2
2019 Pluginizing QUIC
abstract
Application requirements evolve over time and the underlying protocols need to adapt. Most transport protocols evolve by negotiating protocol extensions during the handshake. Experience with TCP shows that this leads to delays of several years or more to widely deploy standardized extensions. In this paper, we revisit the extensibility paradigm of transport protocols.
Quentin De Coninck, François Michel, Maxime Piraux, Florentin Rochet, Thomas Given-Wilson, Axel Legay, Olivier Pereira, Olivier Bonaventure
SIGCOMM1
2017 Multipath QUIC: Design and Evaluation
abstract
Quick UDP Internet Connection (QUIC) is a recent protocol initiated by Google that combines the functions of HTTP/2, TLS, and TCP directly over UDP, with the goal to reduce the latency of client-server communication. It can replace the traditional HTTP/TLS/TCP stack and the IETF has chartered a working group to standardize it. QUIC encrypts all data and most protocol headers to prevent interferences from middleboxes.
Quentin De Coninck, Olivier Bonaventure
CoNEXT1
2016 A First Analysis of Multipath TCP on Smartphones
Quentin De Coninck, Matthieu Baerts, Benjamin Hesmans, Olivier Bonaventure
PAM1
2016 Observing real Multipath TCP traffic
Hoang Tran-Viet, Quentin De Coninck, Benjamin Hesmans, Ramin Sadre, Olivier Bonaventure
Comput. Commun.2
2015 Poster: Evaluating Android Applications with Multipath TCP
abstract
Smartphones are the most popular mobile multihomed devices. End-user expects that thanks to their WiFi and cellular interfaces, they are able to seamlessly use all available networks. Unfortunately, reality tells us that seamless coexistence between cellular and WiFi is not as simple as what the user expect. Several cellular/WiFi coexistence technologies have been proposed during the last years. Some of them have been deployed. Recently, Multipath TCP received a lot of attention when it was selected by Apple to support its voice recognition (Siri) application. As of this writing, Siri is the only deployed smartphone application that uses Multipath TCP. and there is no public information about the benefits of using Multipath TCP with it. Multipath TCP is a TCP extension that allows to send data from one end-to-end connection over different paths. On a smartphone, Multipath TCP allows the applications to simultaneously send and receive data over both WiFi and cellular interfaces. It achieves this objective by establishing one TCP connection, called subflow, over each interface. Once the subflows have been established, data can be sent over any of the subflows. Researchers have analyzed the performance of Multipath TCP in such hybrid networks. However, these analyses have been performed with bulk transfers between laptops and servers. As of this writing, no detailed analysis of the performance of real smartphone applications with Multipath TCP has been published. We fill this gap in this paper by proposing a framework that automates user actions on Android smartphone applications to perform network measurements. We use it to analyze how eight popular smartphone applications interact with Multipath TCP.
Quentin De Coninck, Matthieu Baerts, Benjamin Hesmans, Olivier Bonaventure
MobiCom1