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

[Ian Swett <[e-mail]>]

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
>
>
>