Skip to main content

QUIC Multipath Negotiation Option

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Expired & archived
Author Christian Huitema
Last updated 2021-04-23 (Latest revision 2020-10-20)
Replaced by draft-lmbdhk-quic-multipath
RFC stream (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:


The initial version of QUIC provides support for path migration. In this draft, we argue that there is a very small distance between supporting path migration and supporting simulatneous traffic on multipath. Instead of using an implicit algorithm to discard unused paths, we propose a simple option to allow explicit management of active and inactive paths. Once paths are explicitly managed, pretty much all other requirements for multipath support can be met by appropriate algorithms for scheduling transmissions on specific paths. These algorithms can be implemented on the sender side, and do not require specific extensions, except maybe a measurement of one way delays.


Christian Huitema

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)