QUIC Multipath Negotiation Option
draft-huitema-quic-mpath-option-01

Document Type Replaced Internet-Draft (individual)
Author Christian Huitema 
Last updated 2021-09-12
Replaced by draft-lmbdhk-quic-multipath
Stream (None)
Intended RFC status (None)
Formats
Expired & archived
plain text html xml pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Replaced by draft-lmbdhk-quic-multipath
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-huitema-quic-mpath-option-01.txt

Abstract

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.

Authors

Christian Huitema (huitema@huitema.net)

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