Thanks for writing this Christian, I have a new use case for which I think this simpler single-PN space version of multipath would be perfect. The marginal implementation complexity on top of our existing connection migration implementation seems like it will be relatively small.
Is there a github repo to create issues or editorial PRs, or should I leave any comments via email on the list? Thanks, Ian On Sun, Sep 12, 2021 at 7:20 PM Christian Huitema <[email protected]> wrote: > Following prompting by Michael Eriksson, I updated and resubmitted the > QUIC Multipath Negotiation Option draft, describing the "simple multipath > option". I cleaned up the draft in the following way: > > 1) Make it strictly about negotiating transmission on multiple paths > without otherwise changing the QUIC transport protocol. The new draft just > defines a transport parameter for negotiating the option, and does not > define any new frame type. > > 2) Allow the negotiation to optionally negotiate the path management and > scheduling extensions defined in draft-liu-multipath-quic, i.e., the > PATH_STATUS and QOE_CONTROL_SIGNALS. When that is negotiated, we obtain > pretty much the same behavior as draft-liu-multipath-quic, but using a > single number space instead of multiple number spaces. > > 3) Add a section with Implementation Considerations, based on the > experience in early tests (and the implementation in picoquic). > > -- Christian Huitema > > > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-huitema-quic-mpath-option-01.txt > Date: Sun, 12 Sep 2021 16:09:32 -0700 > From: [email protected] > To: Christian Huitema <[email protected]> <[email protected]> > > > A new version of I-D, draft-huitema-quic-mpath-option-01.txt > has been successfully submitted by Christian Huitema and posted to the > IETF repository. > > Name: draft-huitema-quic-mpath-option > Revision: 01 > Title: QUIC Multipath Negotiation Option > Document date: 2021-09-12 > Group: Individual Submission > Pages: 12 > URL: > https://www.ietf.org/archive/id/draft-huitema-quic-mpath-option-01.txt > Status: https://datatracker.ietf.org/doc/draft-huitema-quic-mpath-option/ > Htmlized: > https://datatracker.ietf.org/doc/html/draft-huitema-quic-mpath-option > Diff: https://www.ietf.org/rfcdiff?url2=draft-huitema-quic-mpath-option-01 > > 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. > > > > The IETF Secretariat > > >
