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