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