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

Christian Huitema <> Wed, 16 December 2020 16:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1E4E23A10DB for <>; Wed, 16 Dec 2020 08:36:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 rmB47S3Kw3wt for <>; Wed, 16 Dec 2020 08:36:18 -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 3676F3A10D7 for <>; Wed, 16 Dec 2020 08:36:18 -0800 (PST)
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1kpZmg-000DLH-Ny for; Wed, 16 Dec 2020 17:36:16 +0100
Received: from (unknown []) by (Postfix) with ESMTPS id 4Cx13K3lY3z1ywQ for <>; Wed, 16 Dec 2020 08:36:13 -0800 (PST)
Received: from [] ( by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <>) id 1kpZmf-00033M-DV for; Wed, 16 Dec 2020 08:36:13 -0800
Received: (qmail 17852 invoked from network); 16 Dec 2020 16:36:12 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 16 Dec 2020 16:36:12 -0000
Subject: Re: Fwd: New Version Notification for draft-liu-multipath-quic-01.txt
To: Quentin De Coninck <>, Mikkel Fahnøe Jørgensen <>, Yunfei Ma <>
Cc: "安勍(莳逸)" <>, quic <>, 李振宇 <>, Yanmei Liu <>, "Ma, Yunfei" <>
References: <> <> <> <> <> <> <>
From: Christian Huitema <>
Message-ID: <>
Date: Wed, 16 Dec 2020 08:36:12 -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="------------6B98FB0C42F3109F75E57CF2"
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/EwzSHE5FGYwwjsNRPCFZ7 ArRKJ0qGeNoTrlh3/nDmD6wdmZPcItWbGe10hXJtyz/MWLF6jnm7fdxjsJMmvxOMEZrAzcbOYTBU Hb9yjjUYFoLz2NZcguRHblw+ZN9KE5LN1n8YXzQY0mQUNzTGA6mwRNpj5snmK3jmyZjmm2JH3v3Q 7PQeNoNQjwiv3IhNPpDsdaHHqGG7YXgprtn5XLToE7g5LY8o1a6sSJrLl3xdARnv/HGR54G9CHRY hyVqYO/Ae1h1hLGGi4ebv387hThA9A+LrmkGouiRB8qN/5RbHDa6yUUKFnWNneAcuva3BS+iyyNq bT8dUMXMJ4tUCMj6G37ZfAMLceP5aNHPt26RBupu5v1nytoNnc138GfEJRQ2qC7jjynPIHPNqSn4 QTXUjLjYWQt1/5xnQymMoPsgr/U0flMcy2Vi/IcBgY4arPaiJ1W6hAyiRC61jekdwIcXNugoOEbH RyFULpSjm7jZ1h/HfDRQ5Ig8VhPsPE8NaP2gA77cO7WeI9Ftai6futPVglyn2M1Ne3VuFRksqHwL YKt0fOdx3JQ0e1s7sWXhDRojSVizNl0ce/s7u0P9bwss+Xo8EUrTp45MZfYRbgAI3NNm+Y5BUKGz 7XyDEWSpOTgtjQWHblEKb/bSn512w9qoLbHrX5KHDBoYpFP6SoHZcpPgEJKLbDyaC/LdLvvYwJNk 2Sa0M8tH9NLuWATf6/pVB9v9zY0h8asEYmbGGsJkWjQ4xyeNtxxq2TXT/AfNgWH7GTOjKdjx/QnC QSBbKRX0XF3qP/dj48psOHFCwviQxKSBCGH0S84CnKX/NUAV3jR5NeVaJQBh0uawl0Cg8nrgSS6D 7FozWS6JHKREtqdEPzY64lXv2dr2sny4a4Sj0cqzvWDlDrFILmNCVZ/264kd2x35zAiBFPp64JaI ysAWfpirH8g1GOR1IFGt5BWm
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: Wed, 16 Dec 2020 16:36:21 -0000

On 12/16/2020 5:08 AM, Quentin De Coninck wrote:
>>> In my opinion, I don't think the "path" should be the element we 
>>> should identify. Rather, I think we should identify "forward flows" 
>>> and "backward flows" (what we call uniflows in our deconinck draft) 
>>> and see paths as a combination of a forward flow and a backward one.
>> Maybe - it sounds appealing. But if the client is always responsible 
>> for probing paths also for different server announced endpoints, then 
>> both endpoints are naturally coupled. The alternative would be for 
>> the server to also probe paths, and that can be difficult with NATs 
>> without STUN. There are many things to consider ...
> Sure. Most of the time it is the client that will open the way and the 
> server waits for the client's packets exposing reachable IP/port 
> tuple. But I would find unfortunate to have a core design preventing 
> such flow creation initiative by the server. And while the client can 
> use, e.g., two flows to reach the server, the server may only want to 
> keep one flow towards the client to limit its state and we have two 
> possible circuits: 1) flow 1 client to server/flow server to client 
> and 2) flow 2 client to server/flow server to client.

The "symmetry of paths" is exactly the kind of issue for which we need 
experimentation with multiple implementations. We will know much more 
about that in a couple weeks.

The "symmetry of roles" is another matter. It is tied to discovery of 
addresses and traversal of NAT and firewalls. The address discovery 
issues are not specific to multipath -- they are prominent for example 
in P2P scenarios using QUIC V1. I think we should address them 
separately, as part maybe of an address discovery extension to QUIC V1. 
If that discovery extension was available, it could be composed nicely 
with multipath extensions.

I don't think there is anything in the current draft that would prevent 
that "composition with address discovery", but people are fallible. If 
there is, it will be fixed.

-- Christian Huitema