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

Mikkel Fahnøe Jørgensen <> Mon, 14 December 2020 19:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 782023A172E for <>; Mon, 14 Dec 2020 11:18:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Status: No, score=-0.197 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] 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 K-D1KddrNDNf for <>; Mon, 14 Dec 2020 11:17:59 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::b35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D1BCA3A1735 for <>; Mon, 14 Dec 2020 11:17:56 -0800 (PST)
Received: by with SMTP id w135so16513434ybg.13 for <>; Mon, 14 Dec 2020 11:17:56 -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=hO0LiVa8AkCYDHXU/JF9NichpvC5+213nCMBijfNp70=; b=Wzpy4N5pzBqGMfouen8wCslU2n+irz5jir1ZWFyAou3p2zAnF4kepjfUVj48DwUDko yezdxgHRtrn+gbxNkDQ7vS95K0s1nVlurkJ/A2FiGRZanjkn5mO7qLibYb+7msn0T4l7 zD3ixK6gUAg+Z9LvyAbmhOVxtIkz8iiKr37D1snVlpXWle1PFgztkNIQUQ4pzdVx0PCr 07j2CdbOjRcnt0GfrnOKMvA++0gcHMExHOOdsbFRpIyTaf/DrM3YnMH2YYaotZpj//T2 GdYvJlEnwDLI1tyr8U/XBqeJVBL+7sQ2lebX6FCgqn9HuMEv4nFKtOtUoGBaJM4QMOQF v4RA==
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=hO0LiVa8AkCYDHXU/JF9NichpvC5+213nCMBijfNp70=; b=X8IhtwqPRyEp3WE6UPJVr4Nj88CvXMxyVj71XBDYHP56cxYcEZckNec3oD3bq5B/Ia vlo6WEQnHbdcG3NGYWZ+LSC2PVHVaYUbkoFmXnv2PRmumqbtpYlJeDbLKPz2miFFWiMo gD7R39FBW4JgnaFFdZrf62cfLN6iDMwVDBMd0+up8FGibXmZy1P7MavZKvRv7kyp+ScL 00py8A7rCSLIK0PI5xbo8l72Yyh4QwUx5jxmDpMZDRygrO7nYF3R+/+5nWiM2UGxfi3G cShjk4I5jdzO6/qbaI7NGXnLom8hLrnZUeBi2KoZLzDEO0Rtjl1f/RD0czT06X3n+7tX HNDw==
X-Gm-Message-State: AOAM532YjHsb6/+MqHzYE19D69LMHjojvwopndQWQqshTYm2HKYJVlR6 /apz1q5InVZRYWZgI9F3Nm/jjXOpF/0aqWmuQqY=
X-Google-Smtp-Source: ABdhPJy8mDQo9aZLMgHU9iE4otPXhc107jIpy2vW8JTCFli0TN2KwT85+zNIBAFTSl9JZQHAQRZz6iulW0SUqE8Biww=
X-Received: by 2002:a25:348a:: with SMTP id b132mr31050299yba.378.1607973475967; Mon, 14 Dec 2020 11:17:55 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Mon, 14 Dec 2020 11:17:55 -0800
From: Mikkel Fahnøe Jørgensen <>
In-Reply-To: <>
References: <> <> <> <>
MIME-Version: 1.0
Date: Mon, 14 Dec 2020 11:17:55 -0800
Message-ID: <>
Subject: Re: Fwd: New Version Notification for draft-liu-multipath-quic-01.txt
To: AN Qing <>, 李振宇 <>, quic <>, Yanmei Liu <>, huitema <>, Yunfei <>
Content-Type: multipart/alternative; boundary="000000000000d7e8f505b6717fb8"
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 19:18:01 -0000

Hi Yanmei, thanks for explaining.

Comments inline:

We have discussed about using different keys in different paths. This
requires adding a key derivation procedure for each path, and
also adding ways to identify the relevant key in the incoming packets,
and we will have to modify the QUIC-v1 packet headers to support the

Why can’t you use the connection ID to find this information? It is needed
to find the connection anyway, and you need it in the IV, so it should be
trivial to store a local key ID along with CID lookup pointing to the
connection, or am I missing something?

It is true that you need a key derivation, but that machinery is already in
place in QUIC-TLS, altough some details need to be added.

As we have explained in the basic design principles of the proposal,
we don’t want to modify the packet header format of QUIC-v1, to avoid
the risk of packets being dropped by middleboxes (which may only
support QUIC-v1).

No, that would not be good. It also wouldn’t really be a QUIC-v1 extension.

I’d like to express a little more, we have discussed a lot about this problem:
As the management of paths is largely specific to application, Why we
will need a frame that one endpoint use it to dictate the behaviour of
the peer?
1. In uploading scenarios, as the sender side, client can decide the
scheduler strategy itself, by providing APIs to let applications
specify their path management preferences etc.
2. In downloading scenarios, as the receiver side, client need to
express its preference of these paths. For example, client may need to
tell server which path is preferred to use (maybe Wi-Fi path when
there are both cellular and Wi-Fi environment). In the case client
sends a management frame says "send on path #1 (the Wi-Fi path)", if
server sends on path #2 (the cellular path), it will make users spend
more traffic costs, and users will not be happy with that.

Yes, that all makes sense.

Without the management frame in the transport, we will not be able to
explain that preference of paths. Servers will never know which path
client is prefer to use.

This is what I do not understand. Why do you need it in transport instead
of the app level. Well, yes, as a general preference maybe it does make
sense. But sense transport cannot distinguish between different kinds of
payloads: different streams, different datagrams etc., all it can do is to
apply this to all content.

Furthermore, what if it is not upload or download, but something far more
complex, like a game server that sends realtime location data on game
objects and the game client sending player actions the other way, both at
low latency. At the same time the game server sends new scene data in high
bandwidth, high latency, in the background, and the client and server
uploads voice chat with different priorities.

Even if we forget about that complexity, what if both endpoints want to
change priorities of the path because of different content. Who gets to

So I agree about the need to manage paths, but I think it needs to be at
the application protocol level, just likely the now abandoned HTTP/3
prioritised streams were decided in the app protocol, not in the transport.

So we start from simple and clear design of path states
(0- Abandon 1- Standby 2- Available), and we added priority for
scenarios like endpoints want to send 20% packets on one path / 80%
packets on the other.
Both client and server can send the PATH_STATUS frame.

Yes, but I think this will lead to problems, even though I fully agree that
paths needs to be managed somehow.

If you compare to QUIC-v1, the transport spec does not say anything about
how to schedule and prioritize streams even though it does suggest using
pacing and does provide some guidance. This is not because scheduling is
not important, because it is, but transport is not the right place to do
it. Also here, you can imagine that it is the receiver, and not the sender,
that should decide. Yet there is no priority frame in the transport spec.

Thanks again for all the feedback!

And thanks for the great work.

I think it is important work.