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

Mikkel Fahnøe Jørgensen <> Mon, 14 December 2020 10:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C5423A0F0B for <>; Mon, 14 Dec 2020 02:33:50 -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 sutHdNV4gRNA for <>; Mon, 14 Dec 2020 02:33:48 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::b2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CCC0A3A0EFB for <>; Mon, 14 Dec 2020 02:33:47 -0800 (PST)
Received: by with SMTP id u203so15087540ybb.2 for <>; Mon, 14 Dec 2020 02:33:47 -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=mlw0l40HCo8LZTApqiaxVFyEysR/18pQjC3VvnujZ6M=; b=oUTKuRwA6OU4/C2W/txSH2kpfoChXa4X0cJxeTqwLwGxdf41M4zqwKqYjx/ZeQQ6qK WTkJyRbltWD6zwvbKHBfjKhis5IFVQrzlSoShQpqmy0mdraDEdNTp4pn2qkDuhvP2gjY 2ssotoGL7CAiy6GREpvq7UhRZjbtkIwwdAdvX1qqMgutbH7nlmhmR8eybBtJ2HR0VpWc 4LOukYb9wgitLu5K0wRGuSBXZxQe7jZF6wjQ4HnWJRf00OGsc7oEW8rAXUQSh/yWd/ml oI+Y+T1U9DjG3pOLPp0qwv2OvrrQcNG3p3wib8siYTFsReihHiu1rRafIfZwrs8kMAjl oUbA==
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=mlw0l40HCo8LZTApqiaxVFyEysR/18pQjC3VvnujZ6M=; b=K2xXec0Gx6EKJV2VtQXFgJvUzljg9noGaZzvVra3SIBCQXM7hIrhxN6d2bkhXeLl+F DwL+zbEBukBdBJQ9xTJ9DXBAb76VbkHGyQ3vo6i60zSq4oGB5vW5TxA4exIJKv/6E7AI IsKuCcorWi+oELU1Wfu6e9suEugIC0itqT6zu0/zXS3Y7RKELKpm6rAJb/PTDsVK64t9 BNcdUpuE0ptnzwb52/DUKaPRGdH0J9P8nWyXhRwS5ZR6LozkvL7xWM89MhU0V52VqKZz jB2jErO36wKvvkIvt9JTZVmf35IyzTz8Laz1fc7deIgvP45eIf3FpSuNJAVtxRNB4ndk QSwA==
X-Gm-Message-State: AOAM532Pj66YUbVTT32WWFHPInJ0K/iQb1pfnpHsRsZuKENEBWQqyqtB zIF40vlnO/R2Gz+ay+bQViUAVjK0Ca5deErTZyY=
X-Google-Smtp-Source: ABdhPJxQ+D6rPvZlVcbGfJgClRRWUzDp4k/6eKPuXYnYywfQlQ/JutzOrVbTgNeBHDIN04a+FtJcf5x5EiMlqxQyigc=
X-Received: by 2002:a25:4409:: with SMTP id r9mr36137007yba.113.1607942026866; Mon, 14 Dec 2020 02:33:46 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Mon, 14 Dec 2020 02:33:46 -0800
From: Mikkel Fahnøe Jørgensen <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Date: Mon, 14 Dec 2020 02:33:46 -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="00000000000054b62805b66a2d74"
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 10:33:50 -0000

Some more comments on the proposed MP design

On protocol violations:


"If an endpoint receives MP frames from packets of other encryption
levels, it MAY return MP_PROTOCOL_VIOLATION as a connection error and
close the connection."

I think it is important to use strict MUST on easily detectable protocol
violations to ensure interop and security.

Also, to my previous point on path sequence numbers as IV source:

What is the motivation for using the same key on all paths? Is it
considered a resource constraint to have more keys? Considering a server
might have 10K+ connections, and perhaps 1.3 paths per connections (wild
guess), it doesn’t seem to much of an overhead.

In addition, having separate keys avoids the sync issues mentioned in the
document. As it stands, failure on one active path can block key update.
This sounds like an accidental or intentional attack vector, although I’m
not sure that it is.

On the document format:

I think the discussion on application influence is good, but maybe isolate
that discussion a bit. It seems that stream priorities are part of the MP
design, which isn’t really the case, even if it is relevant to MP

On QoE:
Maybe it is good to leave the interpretation open to applications, but it
makes it more difficult to design a protocol layer on top. Is it the
intention that, for example, a QUIC-MP video protocol is designed which
then documents how to interpret QoE? If so, does this need to be in the MP
protocol, or could it be in a control stream created by the app level
protocol? In other words, I’m not sure wha the value is at the transport
level if it doesn’t affect the transport layer directly (unless of course I
am missing something).

ACK_MP frame:
If this is an extension to QUIC-v1 it makes sense (and this seems to be the
case). If it is intended as a new protocol version, maybe replace the
regular ACK frame to avoid protocol bloat? I can see the counter argument
that a new frame ID makes it easier to reuse v1 implementations, but
protocol bloat is a concern as well.

The scheduling section has an example mentioning one of the two paths. I’m
sure this a left-over since there could be more than two active paths as I

Path state:
I do not understand this well enough, but I’m a bit concerned about one
endpoint dictating the behaviour of the other regarding priorities etc. It
seems like this could easily be abused, and perhaps this is also better
done in an application level protocol?

The text is not very clear about the client and the servers role in path
negotiation. It seems that that it follows he QUIC-v1 async design due to
relying on the v1 PATH packets. So presumably this also places constraints
on who can send path state updates.

If MP was to become more symmetric, I wonder if there is a natural
evolution from here, or the proposed design is just digging the async
design hole deeper, so to speak. Note that async MP is useful in its own


On 14 December 2020 at 10.38.58, Mikkel Fahnøe Jørgensen (

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