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