Re: New Version Notification for draft-huitema-quic-mpath-option-01.txt

[Christian Huitema <[e-mail]>]

I am maintaining the draft using GitHub, 
https://github.com/huitema/quicmpath. You can certainly enter editorial 
issues there. You could start other discussions too, but it is probably 
preferable to have discussions of substance on the mailing list, because 
the draft has not been adopted by the WG yet, and the repo is not 
managed by the WG.

-- Christian Huitema

On 9/15/2021 6:19 AM, Ian Swett wrote:
> 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 <[e-mail]>
> 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: [e-mail]
>> To: Christian Huitema <[e-mail]> <[e-mail]>
>>
>>
>> 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
>>
>>
>>