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

Mikkel Fahnøe Jørgensen <> Mon, 14 December 2020 09:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 75F393A0EA5 for <>; Mon, 14 Dec 2020 01:39:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.196
X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id np81kKeC_Yzx for <>; Mon, 14 Dec 2020 01:39:12 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::b2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 67E013A0E95 for <>; Mon, 14 Dec 2020 01:39:00 -0800 (PST)
Received: by with SMTP id 82so8022107yby.6 for <>; Mon, 14 Dec 2020 01:39:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=rZ6+9x6m0GEUkv6hxGAxwk2xLNLTBASHlwcMo3ZWuqM=; b=chqUOmugE+bNlQeoJdrxfUrpkWSKpkwyMdTrzCG9tovufS1CSHf7JGsHVX6RKzftPP Ubdq2vMNeIhnY7PvsWsG+gqNS17Dwv2ZJIscVTRXQ/Ft9JNbUG6IccaTjsnuvYXYxrF3 dxwv77TrPuBrwiErFoKpBBKkIhC3EQRRLUY8cjazkMUdq4wKd1f0iZ0cb+dI/BMbMVOR UrTF7mcmApdKvAUNe3OxkiXrepqinn0n2wE4qijEqxZGh5s0rHdm7loHKNXWxh6jGyuB RX5fPcJr1cV2QLbfVpUrvGvbWOA1abdomcjnMK4silwFzlYxWFfNCFnqXQhKngCtJHRm ZF7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=rZ6+9x6m0GEUkv6hxGAxwk2xLNLTBASHlwcMo3ZWuqM=; b=S+8+0R8WHeiPzyEanQVxZFkyqqBDBaYNDfmE9n8UYv0/qGMTtuf8aT2zXgWbFhGSPP vPPgg4wtksH6/NAqEKxVMtLwhA893il4u6BOvY10gIb2xtOb/aaP8rRaf93LFzd0PUG6 PEK9SIrrDxKYlLh1YhP1KWGY7s586CUCvZpK7zlVqvneMn4S+XWN2bItrAQEC84qWENG ZVNvUE+CA8h3J+SkhKLtGny3oJ1EDSGoNhi3OQSVVyjeVvu+ju46ffI9nM+QVsoBpq6p cLqBMPKAy+b7MP6kduHDpcjC4n8P02u2KXzleECf6LfvN2f5pw42n+ZS6188syXTSlBo tYbA==
X-Gm-Message-State: AOAM531wpbDRksVr8lALXNVJvwNHviwR8HWxEr6hs8tpk89jCLC1MDx1 lC0z3p7DJqWO5dSPkTGIdNcHB3b9bnd4XuM6yuM=
X-Google-Smtp-Source: ABdhPJwqW70bGplmmwERQ0X4Kd/DOuqZErdsdfCp0Q3SR+y83k6wxvXstYvuy4RSBdNTYyYF122Q9Qb/k6yUHaLZx9w=
X-Received: by 2002:a25:23d7:: with SMTP id j206mr35928003ybj.243.1607938739507; Mon, 14 Dec 2020 01:38:59 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Mon, 14 Dec 2020 01:38:58 -0800
From: Mikkel Fahnøe Jørgensen <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Date: Mon, 14 Dec 2020 01:38:58 -0800
Message-ID: <>
Subject: Re: Fwd: New Version Notification for draft-liu-multipath-quic-01.txt
To: "安勍(莳逸)" <>, quic <>, 李振宇 <>, Yanmei Liu <>, huitema <>, "Ma, Yunfei" <>
Content-Type: multipart/alternative; boundary="00000000000063936905b6696904"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 14 Dec 2020 09:39:16 -0000

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

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 (

Hi all,

Here is an updated version of the draft which was posted in the mailing
list last Friday. Please check this link:
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

* 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

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

* 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!


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

To:安勍(莳逸) <>; "Ma, Yunfei"
<>; 刘彦梅(喵吉) <>;
Christian Huitema <>; 李振宇 <>

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

   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

The IETF Secretariat