QUIC Multipath Negotiation Option
draft-huitema-quic-mpath-option-01
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) | ||
Formats | |||
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:
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
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)