Subject: Fw: New Version Notification for draft-liu-multipath-quic-02.txt (was Re: PSA: Choosing codepoints)

From: "Yanmei Liu" <[email-masked]>
Date: Wed, 16 Dec 2020 15:55:00 +0800

Hi all,

We have published a new version and modified the codepoints used in multipath extension, including transport parameter and frame types, to avoid collisions with others.
Please check this: https://tools.ietf.org/html/draft-liu-multipath-quic-02
(The draft defines provisional values for experiments, but we expect IANA to allocate short values if the draft is approved.)

Thanks Martin and Lucas for pointing out the problem.

Thanks,
Yanmei

------------------------------------------------------------------
From:internet-drafts <[email-masked]>
Sent At:2020 Dec. 16 (Wed.) 15:14
To:Christian Huitema <[email-masked]>; AN Qing <[email-masked]>; Yunfei <[email-masked]>; LIU Yanmei <[email-masked]>; 李振宇 <[email-masked]>
Subject:New Version Notification for draft-liu-multipath-quic-02.txt

A new version of I-D, draft-liu-multipath-quic-02.txt
has been successfully submitted by Yanmei Liu and posted to the
IETF repository.

Name:  draft-liu-multipath-quic
Revision: 02
Title:  Multipath Extension for QUIC
Document date: 2020-12-16
Group:  Individual Submission
Pages:  18
URL:            https://www.ietf.org/archive/id/draft-liu-multipath-quic-02.txt
Status:         https://datatracker.ietf.org/doc/draft-liu-multipath-quic/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-liu-multipath-quic
Htmlized:       https://tools.ietf.org/html/draft-liu-multipath-quic-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-liu-multipath-quic-02

Abstract:
   This document specifies multipath extension for the QUIC protocol to
   enable the simultaneous usage of multiple paths for a single
   connection.  The extension is compliant with the single-path QUIC
   design.  The design principle is to support multipath by adding
   limited extension to [QUIC-TRANSPORT].

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 Thomson" <[email-masked]>
Date: Wed, 16 Dec 2020 20:09:15 +1100

Thanks for being so responsive on this. It is a small thing we requested that you could have deferred until a larger update, but I appreciate the update.

I am curious now to see how this design works out.

On Wed, Dec 16, 2020, at 18:55, Yanmei Liu wrote:
> Hi all,
> 
> We have published a new version and modified the codepoints used in 
> multipath extension, including transport parameter and frame types, to 
> avoid collisions with others.
> Please check this: 
> https://tools.ietf.org/html/draft-liu-multipath-quic-02 
> (The draft defines provisional values for experiments, but we expect 
> IANA to allocate short values if the draft is approved.)
>

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 16 Dec 2020 16:29:23 +0000

On Wed, 16 Dec 2020, 09:10 Martin Thomson, <[email-masked]> wrote:

> Thanks for being so responsive on this. It is a small thing we requested
> that you could have deferred until a larger update, but I appreciate the
> update.
>

+1, thanks

---

From: Martin Duke <[email-masked]>
Date: Wed, 16 Dec 2020 13:39:40 -0800

Thanks for this draft! I like the way it's going.

I'm not sure I like the repurposing of RETIRE_CONNECTION_ID to close a
path. There are other valid reasons to retire a path -- for instance, the
sequence number is low relative to the other active ones, and the
intermediate numbers are requiring extra state. RETIRE_CONNECTION_ID is
useful to force the peer to use a new CID for the path.

---

From: Christian Huitema <[email-masked]>
Date: Wed, 16 Dec 2020 14:14:58 -0800

On 12/16/2020 1:39 PM, Martin Duke wrote:
> path. There are other valid reasons to retire a path -- for instance, 
> the sequence number is low relative to the other active ones, and the 
> intermediate numbers are requiring extra state. RETIRE_CONNECTION_ID 
> is useful to force the peer to use a new CID for the path.

We had a bit of discussion about that. The RETIRE_CONNECTION_ID is not 
meant to trigger a peer's action, except for freeing the resource 
associated with the connection ID that is being retired. The PATH_STATUS 
frame may be used to request a peer to abandon a path.

-- Christian Huitema

---

From: Martin Duke <[email-masked]>
Date: Wed, 16 Dec 2020 14:44:42 -0800

This is not how I read the draft at all. There are two separate paths, no?
client->server and server->client?

4.5.2:

This has no direct effect on reverse paths from this endpoint to the
   peer.  If the peer wants to direct the endpoint to abandon such
   paths, it should send PATH_STATUS(abandon) frames for the relevant
   paths.

So IIUC PATH_STATUS refers to the peer's CID/identifier, and
RETIRE_CONNECTION_ID refers to the sender's CID/identifier, so both are
necessary to tear down both ends?

---

From: Christian Huitema <[email-masked]>
Date: Wed, 16 Dec 2020 15:06:30 -0800

On 12/16/2020 2:44 PM, Martin Duke wrote:
> This is not how I read the draft at all. There are two separate paths, 
> no? client->server and server->client?
>
> 4.5.2:
> RETIRE_CONNECTION_ID refers to the sender's CID/identifier, so both 
> are necessary to tear down both ends?

Let's get some experience of what works or not. If we believe that the 
client is ultimately in charge of resource management, then a logical 
sequence would be:

1) Client asks server to abandon path x.

2) Server does that and sends RETIRE_CONNECTION_ID(x)

3) Client sends RETIRE_CONNECTION(y) -- the value that was used for 
"return path".

-- Christian Huitema

---

From: Martin Duke <[email-masked]>
Date: Tue, 22 Dec 2020 08:10:38 -0800

I'm fine to do some experiments, but I'm quite unclear as to what the draft
is specifying right now.