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

Christian Huitema <> Mon, 14 December 2020 22:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 75E0A3A1220 for <>; Mon, 14 Dec 2020 14:49:47 -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 mLxWfOhhUvlL for <>; Mon, 14 Dec 2020 14:49:46 -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 EB9B43A121F for <>; Mon, 14 Dec 2020 14:49:45 -0800 (PST)
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1kowew-0004f1-8n for; Mon, 14 Dec 2020 23:49:40 +0100
Received: from (unknown []) by (Postfix) with ESMTPS id 4CvxR16Kglz12XH for <>; Mon, 14 Dec 2020 14:49:33 -0800 (PST)
Received: from [] ( by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <>) id 1kower-0006NX-Ok for; Mon, 14 Dec 2020 14:49:33 -0800
Received: (qmail 27438 invoked from network); 14 Dec 2020 22:49:33 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 14 Dec 2020 22:49:33 -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 14:49:32 -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="------------E82A3A849E5259307AFFB48D"
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/EwzSHE5FGYwwjsNRPCFH1 VhqTceiVDgKDVYnm21nmD6wdmZPcItWbGe10hXJtXL4FsauCVkDjmcYJdU3yWp7KuHNaaKdg7iBE ZefdsNUFWKwa/wzJUjmazeC7ImcaSiHjxvv4gKLTeB2fpVmS6BQ6V51u76v35b1wNe/MvdL/hXir I7jpLA3NtNK1rbkD2+J9PgaoF8SQHto3le4zsHTaeQtlKubP6iUTjj6yPARK6buALVaA782LKxg6 vRmng8N1aLhXqdc+jC1RcnVud53D5caUhbVtvqItBqoizkEt9O20UjkwI0v+LOlw05G4BS+iyyNq bT8dUMXMJ4tUCMj6G37ZfAMLceP5aNHPt26RBupu5v1nytoNnc138GfEJRQ2qC7jjynPIHPNqSn4 QTXUjLjYWQt1/5xnQymMoPsgr/U0flMcy2Vi/IcBgY4arPaiJ1W6hAyiRC61jekdwIcXNugoOEbH RyFULpSjm7jZ1h/HfDRQ5Ig8VhPsPE8NlkBmbR1LS6Kx8w5MHqDEEzAOtHDt7qlwjJCg4/tkU2mQ tp+n2LwGM4LacqDmlvEYDRojSVizNl0ce/s7u0P9b7Oijoc3SCZfWp1RjkjWCw/vIUzTXkDAiiJi mGhLUFuS2lhaIetXfCg1JdAVrOwKfOYtNQ5f9KF8tkKZqCafMxFUoFIvD3sIcP1fhJPM6B/8I74Z hs6dcU3l+4gUuK5uD+JsbQ06fI17C+NYYI73oYOJ+dym1L8cD17Js0v4cp1MJ+8EdaJOS3cmW0I5 fxQkSzcKVNeVJ9BXyu9+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 22:49:47 -0000

On 12/14/2020 12:30 PM, Mikkel Fahnøe Jørgensen wrote:
> OK, thanks for explaining.
> I wonder if the current asymmetric approach could be enhanced 
> relatively easily by allowing a server to announce a list of 
> address/port/QoE tuples that it can recommend the client to use as 
> virtual endpoints, without initiating anything. The client would then 
> issue path challenges as usual, but can do so to any one of the 
> proposed endpoints. The server could periodically propose new such 
> tuples or update QoE on existing. If a server wants to retire an 
> endpoint, it could send that information too, but a draining period 
> would be needed.
> This could also piggy back on the existing CID update system where a 
> server CID is associated with a virtual endpoint.

Yes, it is tempting to add a way for a server "to announce a list of 
address/port/QoE tuples that it can recommend the client to us" as part 
of the multipath design. I think that we should resist that temptation, 
and treat "annoucing addresses" as a separate problem. After all, even 
if the endpoint do not use the multipath extension, they might still use 
these server addresses as targets of V1-supported address migration.

Nick Banks was discussing this server address migration issue in the 
Slack chat room a couple of weeks ago. His use case was a server joined 
through a bandwidth limited VPN; there would be benefits in moving the 
connection to a direct path outside the VPN. It turns out that this 
migration requires more than merely communicating alternate server 
addresses to the peer: server and clients also need to cooperate to open 
a hole in the firewall that protects the server. This gets very close to 
problems encountered in peer to peer scenarios.

These are good problems to address, but I would rather address them in a 
targeted effort than as part of the multipath design.

-- Christian Huitema