Re: Fwd: New Version Notification for draft-liu-multipath-quic-01.txt

[Mikkel Fahnøe Jørgensen <[e-mail]>]

Would it be practical to lift the 32-bit constraint on the CID sequence
number?

Even if it probably is enough for most use cases I find it unfortunate to
introduce a new constraint here because if affects design decisions
elsewhere in stack.

For example, it could be required that a key is updated at least once in
every 2^31 sequence numbers, or the IV could be hashed and use a
sufficiently frequent key update.


On 14 December 2020 at 07.14.07, Yanmei Liu ([e-mail])
wrote:

Hi all,

Here is an updated version of the draft which was posted in the mailing
list last Friday. Please check this link:
https://tools.ietf.org/html/draft-liu-multipath-quic-01
Regarding the questions in the mailing list for the previous version:
1. We have fixed the IANA registry problem in the new version. Thanks Lucas
for pointing out this problem.
2. We currently use Github for editing, and we prefer discussions on the
mailing list, so we removed the Github link in this draft.

This version merges our draft and Christian’s draft, and here are some of
the key features:

* Re-use as much as possible mechanisms of QUIC-v1, which has
supported connection migration and path validation.

* To avoid the risk of packets being dropped by middleboxes (which
may only support QUIC-v1), use the same packet header formats as
QUIC V1.

* Endpoints need a Path Identifier for each different path which is
used to track states of packets. As we want to keep the packet
header formats unchanged [QUIC-TRANSPORT], Connection IDs (and the
sequence number of Connection IDs) would be a good choice of Path
Identifier.

* For the convenience of packet loss detection and recovery,
endpoints use a different packet number space for each Path
Identifier.

* Congestion Control, RTT measurements and PMTU discovery should be
per-path (following [QUIC-TRANSPORT])

Thanks Jana and Kazuho for reviewing the proposal.

We would like to know how people think about the draft, and all feedbacks
and suggestions are welcome!


Thanks,
Yanmei



------------------------------------------------------------------
From: internet-drafts <[e-mail]>
Date: 2020年12月14日(星期一) 12:36

To：安勍(莳逸) <[e-mail]>; "Ma, Yunfei"
<[e-mail]>; 刘彦梅(喵吉) <[e-mail]>;
Christian Huitema <[e-mail]>; 李振宇 <[e-mail]>

Subject: New Version Notification for draft-liu-multipath-quic-01.txt


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

Name:  draft-liu-multipath-quic
Revision: 01
Title:  Multipath Extension for QUIC
Document date: 2020-12-14
Group:  Individual Submission
Pages:  18
URL:
https://www.ietf.org/archive/id/draft-liu-multipath-quic-01.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-01
Diff:
https://www.ietf.org/rfcdiff?url2=draft-liu-multipath-quic-01

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