Skip to main content

QUIC Multipath Negotiation Option

Document Type Replaced Internet-Draft (individual)
Expired & archived
Author Christian Huitema
Last updated 2021-09-12
Replaced by draft-lmbdhk-quic-multipath
RFC stream (None)
Intended RFC status (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Replaced by draft-lmbdhk-quic-multipath
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. We propose a simple mechanism to support not just migration, but also simultaneous usage of multiple paths. In its simplest form, this mechanisms simply requires that multipath senders keep track of which packet is sent on what path, and use that information to manage congestion control and loss recovery. With that, clients can send data on any validated path, and server on any validated path on which the client recently sent non-probing packets. A more sophisticated mechanism can be negotiated to explicitly manage paths and packet scheduling.


Christian Huitema

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