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

From: Christian Huitema <[email-masked]>
Date: Tue, 20 Oct 2020 23:47:18 -0700

Since everybody seems intent on discussing Multipath, I just wrote this
short draft that presents a minimalist design for adding Multipath
support to QUIC. Basically, it puts the onus entirely on the sender. The
receiver side would just require support for a couple of management
frames to explicitly abandon or promote a path. The sender will have to
track the relation between packet number and path, possibly manage
ranges of packet numbers, manage the per-path congestion control, update
the packet loss detection to take path delays into account, and of
course chose an algorithm for scheduling packets to paths.

-- Christian Huitema

-------- Forwarded Message --------
Subject: 	New Version Notification for
draft-huitema-quic-mpath-option-00.txt
Date: 	Tue, 20 Oct 2020 23:42:14 -0700
From: 	[email-masked]
To: 	Christian Huitema <[email-masked]>

A new version of I-D, draft-huitema-quic-mpath-option-00.txt
has been successfully submitted by Christian Huitema and posted to the
IETF repository.

Name: draft-huitema-quic-mpath-option
Revision: 00
Title: QUIC Multipath Negotiation Option
Document date: 2020-10-20
Group: Individual Submission
Pages: 8
URL: https://www.ietf.org/archive/id/draft-huitema-quic-mpath-option-00.txt
Status: https://datatracker.ietf.org/doc/draft-huitema-quic-mpath-option/
Htmlized:
https://datatracker.ietf.org/doc/html/draft-huitema-quic-mpath-option
Htmlized: https://tools.ietf.org/html/draft-huitema-quic-mpath-option-00

Abstract:
The initial version of QUIC provides support for path migration. In
this draft, we argue that there is a very small distance between
supporting path migration and supporting simulatneous traffic on
multipath. Instead of using an implicit algorithm to discard unused
paths, we propose a simple option to allow explicit management of
active and inactive paths. Once paths are explicitly managed, pretty
much all other requirements for multipath support can be met by
appropriate algorithms for scheduling transmissions on specific
paths. These algorithms can be implemented on the sender side, and
do not require specific extensions, except maybe a measurement of one
way delays.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Martin Duke <[email-masked]>
Date: Wed, 21 Oct 2020 09:10:42 -0700

Thanks, Christian, I am happy to see what a minimalist design would look
like.

Some comments:
At the end Section 2 you discuss paths that have been validated, but not
received an ack-eliciting frame. But as PATH_CHALLENGE/RESPONSE are
ack-eliciting, what's the true distinction here?

3.1 The TP section should probably specify if it can/must be kept for 0RTT,
though as the frames are 1RTT specific the answer is obvious.

3.3 "Endpoints MUST NOT send PATH_STATUS frames for a Path Identifier until
the peer has acknowledged a PATH_IDENTIFICATION frame containing that
identifier, unless the frames are sent in the same QUIC packet." Otherwise,
we have messy states where PATH_STATUS arrives before PATH_IDENTIFICATION
and the receiver discards it, but the packet is acked and the sender has no
idea it's discarded. Alternatively, we could change the language about
discarding PATH_STATUS.

4.1 Senders that want to control this issue may do so

   by dedicating sub-ranges of packet numbers to different paths.

There be many dragons here! This would seem to violate the requirement
that packet numbers be sent in increasing order, which is a mechanism
that underlies several designs (e.g. key update).

Thanks again!

Martin

On Tue, Oct 20, 2020 at 11:47 PM Christian Huitema <[email-masked]>
wrote:

> short draft that presents a minimalist design for adding Multipath support
> to QUIC. Basically, it puts the onus entirely on the sender. The receiver
> side would just require support for a couple of management frames to
> explicitly abandon or promote a path. The sender will have to track the
> relation between packet number and path, possibly manage ranges of packet
> numbers, manage the per-path congestion control, update the packet loss
> detection to take path delays into account, and of course chose an
> algorithm for scheduling packets to paths.
>
> -- Christian Huitema
>
>
> To: Christian Huitema <[email-masked]> <[email-masked]>
>
>
> URL:
> https://www.ietf.org/archive/id/draft-huitema-quic-mpath-option-00.txt