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

[Christian Huitema <[e-mail]>]

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




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