Since everybody seems intent on discussing Multipath, I just wrote this short draft that presents a minimalist design for adding Multipath support to QUIC. Basically, it puts the onus entirely on the sender. The receiver side would just require support for a couple of management frames to explicitly abandon or promote a path. The sender will have to track the relation between packet number and path, possibly manage ranges of packet numbers, manage the per-path congestion control, update the packet loss detection to take path delays into account, and of course chose an algorithm for scheduling packets to paths.
-- Christian Huitema -------- Forwarded Message -------- Subject: New Version Notification for draft-huitema-quic-mpath-option-00.txt Date: Tue, 20 Oct 2020 23:42:14 -0700 From: [email protected] To: Christian Huitema <[email protected]> A new version of I-D, draft-huitema-quic-mpath-option-00.txt has been successfully submitted by Christian Huitema and posted to the IETF repository. Name: draft-huitema-quic-mpath-option Revision: 00 Title: QUIC Multipath Negotiation Option Document date: 2020-10-20 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/archive/id/draft-huitema-quic-mpath-option-00.txt Status: https://datatracker.ietf.org/doc/draft-huitema-quic-mpath-option/ Htmlized: https://datatracker.ietf.org/doc/html/draft-huitema-quic-mpath-option Htmlized: https://tools.ietf.org/html/draft-huitema-quic-mpath-option-00 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. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat
