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

From: Christian Huitema <[email-masked]>
Date: Sun, 12 Sep 2021 16:19:56 -0700

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-masked]
To: 	Christian Huitema <[email-masked]>

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

---

From: Ian Swett <[email-masked]>
Date: Wed, 15 Sep 2021 09:19:01 -0400

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-masked]>
wrote:

> QUIC Multipath Negotiation Option draft, describing the "simple multipath
> option". I cleaned up the draft in the following way:
>
> 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.
>
> To: Christian Huitema <[email-masked]> <[email-masked]>
>
>
> URL:
> https://www.ietf.org/archive/id/draft-huitema-quic-mpath-option-01.txt

---

From: Christian Huitema <[email-masked]>
Date: Wed, 15 Sep 2021 11:37:26 -0700

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