Thanks, Christian, I am happy to see what a minimalist design would look like.
Some comments: At the end Section 2 you discuss paths that have been validated, but not received an ack-eliciting frame. But as PATH_CHALLENGE/RESPONSE are ack-eliciting, what's the true distinction here? 3.1 The TP section should probably specify if it can/must be kept for 0RTT, though as the frames are 1RTT specific the answer is obvious. 3.3 "Endpoints MUST NOT send PATH_STATUS frames for a Path Identifier until the peer has acknowledged a PATH_IDENTIFICATION frame containing that identifier, unless the frames are sent in the same QUIC packet." Otherwise, we have messy states where PATH_STATUS arrives before PATH_IDENTIFICATION and the receiver discards it, but the packet is acked and the sender has no idea it's discarded. Alternatively, we could change the language about discarding PATH_STATUS. 4.1 Senders that want to control this issue may do so by dedicating sub-ranges of packet numbers to different paths. There be many dragons here! This would seem to violate the requirement that packet numbers be sent in increasing order, which is a mechanism that underlies several designs (e.g. key update). Thanks again! Martin On Tue, Oct 20, 2020 at 11:47 PM Christian Huitema <[email protected]> wrote: > 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]> <[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 > > >
