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

Christian Huitema <> Mon, 14 December 2020 20:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2F5623A1A04 for <>; Mon, 14 Dec 2020 12:02:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.011
X-Spam-Status: No, score=0.011 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fxWITZnDfPHr for <>; Mon, 14 Dec 2020 12:02:12 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 269173A1A00 for <>; Mon, 14 Dec 2020 12:01:27 -0800 (PST)
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1kou25-0005V6-Lt for; Mon, 14 Dec 2020 21:01:25 +0100
Received: from (unknown []) by (Postfix) with ESMTPS id 4Cvshs5x4qz1Nsg for <>; Mon, 14 Dec 2020 12:01:17 -0800 (PST)
Received: from [] ( by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <>) id 1kou21-0001AQ-Nc for; Mon, 14 Dec 2020 12:01:17 -0800
Received: (qmail 20909 invoked from network); 14 Dec 2020 20:01:17 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 14 Dec 2020 20:01:17 -0000
Subject: Re: Fwd: New Version Notification for draft-liu-multipath-quic-01.txt
To: Mikkel Fahnøe Jørgensen <>, "安勍(莳逸)" <>, quic <>, 李振宇 <>, Yanmei Liu <>, "Ma, Yunfei" <>
References: <> <> <> <>
From: Christian Huitema <>
Message-ID: <>
Date: Mon, 14 Dec 2020 12:01:17 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------F0D1DAD9F5091AACB8DEDB9D"
Content-Language: en-US
Authentication-Results:; auth=pass smtp.auth=
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5x6h2yQpzTslcOqazQkKtAFKj/EwzSHE5FGYwwjsNRPCCHj zZz/53s3KMxCLX3sq97mD6wdmZPcItWbGe10hXJtXL4FsauCVkDjmcYJdU3yWp7KuHNaaKdg7iBE ZefdsNUFWKwa/wzJUjmazeC7ImcaSiHjxvv4gKLTeB2fpVmS6BQ6V51u76v35b1wNe/MvdIN+Yj9 JT+HIE3AciYbXmyy2+J9PgaoF8SQHto3le4zsHTaeQtlKubP6iUTjj6yPARK6buALVaA782LKxg6 vRmng8N1aLhXqdc+jC1RcnVud53D5caUhbVtvqItBqoizkEt9O20UjkwI0v+LOlw05G4BS+iyyNq bT8dUMXMJ4tUCMj6G37ZfAMLceP5aNHPt26RBupu5v1nytoNnc138GfEJRQ2qC7jjynPIHPNqSn4 QTXUjLjYWQt1/5xnQymMoPsgr/U0flMcy2Vi/IcBgY4arPaiJ1W6hAyiRC61jekdwIcXNugoOEbH RyFULpSjm7jZ1h/HfDRQ5Ig8VhPsPE8NDxdyIeJZUl7T+dBx2dACjzAOtHDt7qlwjJCg4/tkU2kx wK7gQmw3hNY4UG+EFno1DRojSVizNl0ce/s7u0P9b7Oijoc3SCZfWp1RjkjWCw/vIUzTXkDAiiJi mGhLUFuS2lhaIetXfCg1JdAVrOwKfFg0VJMcSNMYGGKFqQbtFbpUoFIvD3sIcP1fhJPM6B/8n/pG JMW4R7UkxGxxOK12mgec17hSgrK8VNMBO2dsi6yJ+dym1L8cD17Js0v4cp1M6McEBQdkr0f3V/cw BGAWMzcKVNeVJ9BXyu9+ceCqThTYg2px1fSoqxQCCHnLMo/m9VKh99btUAanjnMCAH2co+fBoeG+ Hs0afhsY/5zhNYWRVYKU9W9tbmVXJBqdHHDmZEKhyNAv1N35kYWaEdgLurFV5oTvAcwA4rM3FkfW 8/1kE/e7sUnsVpINvARNxpFO
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 20:02:14 -0000

On 12/14/2020 2:38 AM, Mikkel Fahnøe Jørgensen wrote:

> Sorry, “async design “ should read asymmetric design, in that only one 
> endpoint can create multiple paths, as opposed to a symmetric design 
> where both can.
> On 14 December 2020 at 11.33.46, Mikkel Fahnøe Jørgensen 
> ( <>) wrote:
>> async design

The proposal indeed keeps the asymmetric design of QUIC v1. That design 
is grounded in practical realities, such as the prevalence of NAT and 
stateful firewalls that would drop "unexpected" packets sent to a 
client. Also, the client typically knows about the cost of paths better 
than the server, for example whether sending more data on a given path 
will generate larger invoices from the provider. The design goal is to 
let the client express these preference to the server using a simple 
priority scheme.

Anything more complex probably requires application level decisions. 
That why the design provides the QOE frame. That frame let applications 
exchange information about paths in an application specific way. The 
expectation is that the application posts them as it sees fit, and the 
transport delivers them as they are received. The application then uses 
locally provided API to affect the way data is sent over multiple paths.

We could debate whether the QOE frame is needed at all. Applications 
could also exchange the data as part of application protocol itself. I 
think that having a separate frame reduce the overall complexity, by 
separating application specific path control from the application 
protocol itself.

We could also debate whether the QOE frame should be specified in 
greater details. The current design simply passes a byte string. The DNS 
SVCB RR type addresses a related problem by an SvcParams field that 
contains a list of key-value pairs. It is possible that having a similar 
list of key-value pairs would be useful there. On the other hand, we do 
not yet have a lot of experience. And open design with a byte string is 
probably good enough for now.

-- Christian Huitema