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

Christian Huitema <> Mon, 14 December 2020 19:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DE7523A183F for <>; Mon, 14 Dec 2020 11:34:38 -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 KpCUjn1CLXxB for <>; Mon, 14 Dec 2020 11:34:37 -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 748CB3A183E for <>; Mon, 14 Dec 2020 11:34:37 -0800 (PST)
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1kotc9-001Amp-Ql for; Mon, 14 Dec 2020 20:34:34 +0100
Received: from (unknown []) by (Postfix) with ESMTPS id 4Cvs5y19x9z3HXJ for <>; Mon, 14 Dec 2020 11:34:30 -0800 (PST)
Received: from [] ( by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <>) id 1kotc6-0008P7-1G for; Mon, 14 Dec 2020 11:34:30 -0800
Received: (qmail 20899 invoked from network); 14 Dec 2020 19:34:29 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 14 Dec 2020 19:34:29 -0000
Subject: Re: Fwd: New Version Notification for draft-liu-multipath-quic-01.txt
To: Yanmei Liu <>, Mikkel Fahnøe Jørgensen <>, AN Qing <>, 李振宇 <>, quic <>, Yunfei <>
References: <> <> <> <>
From: Christian Huitema <>
Message-ID: <>
Date: Mon, 14 Dec 2020 11:34:29 -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="------------2EDB9750C9A162023A0D6C6D"
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: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT+albhx2Ff5GpfXeOkgYObbPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5x6h2yQpzTslcOqazQkKtAFKj/EwzSHE5FGYwwjsNRPCLtM UAG6wMJcaIvCl6ZXZmnmD6wdmZPcItWbGe10hXJtyz/MWLF6jnm7fdxjsJMmvxOMEZrAzcbOYTBU Hb9yjjUYFoLz2NZcguRHblw+ZN9KE5LN1n8YXzQY0mQUNzTGAwCyMkrqOaHyAipaXQfAHlJH3v3Q 7PQeNoNQjwiv3IhNPpDsdaHHqGG7YXgprtn5XLToE7g5LY8o1a6sSJrLl3xdARnv/HGR54G9CHRY hyVqYO/Ae1h1hLGGi4ebv387hThA9A+LrmkGouiRB8qN/5RbHDa6yUUKFnWNneAcuva3BS+iyyNq bT8dUMXMJ4tUCMj6G37ZfAMLceP5aNHPt26RBupu5v1nytoNnc138GfEJRQ2qC7jjynPIHPNqSn4 QTXUjLjYWQt1/5xnQymMoPsgr/U0flMcy2Vi/IcBgY4arPaiJ1W6hAyiRC61jekdwIcXNugoOEbH RyFULpSjm7jZ1h/HfDRQ5Ig8VhPsPE8NQ/T3Op6Um662jkOH4BxhazAOtHDt7qlwjJCg4/tkU2ld qDluHt1kvmB2nukdwv8M2JUne37EdXOqrRyXv4wzniPbQ8sJuEui1t94t+0mATw11lqdy1V/0aEk MCdb3YpWUo4/+EUytKrR9Md9I2Rs12wCRGGpj80tIn+o5B1NEw5PCC/cRgvQKtcrMMueERx3f3Hd c+Ezl1PZXtD++tJuWCAv50rGgAxxi38eBu1rr1GIaIzNoZzswxuMaWjBAlpwfUTRGK6djIyKiPJc QxWeYvUf9oDBqtClgM5jH/om1Q5UomG0v+rwIiID/kwKc8V5Tj9+FRkaOS/DNjANmb8tO61SbYdY AwdpaVzHW7wHO7YhEWyJzIkwSFAW0Pw8uiKeubcolFl/rX+2ReQklqJDASQX2Id+W5hjJNcdGs0+ iHjXODmj5PX/tZQU3bYnWKpb
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:34:39 -0000

On 12/14/2020 10:44 AM, Yanmei Liu wrote:

> > ACK_MP frame:
> > If this is an extension to QUICv1 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 im> 
> plementations, but protocol bloat is a concern as well.
> I think that it’s important to keep compatible with QUIC-v1. If implementations send ACK frame in multiple paths, it still need to be processed without errors.

Some more explanations of this ACK frames issue. Sending packets and 
receiving acknowledgements forms a control loop, triggering actions like 
loss correction or changes in congestion control parameters. When 
implementing control loops, it is generally better to keep delays short. 
This has a clear effect in management of multiple paths. The shortest 
loops are obtained when the acknowledgements are sent on the shortest 
available path, which may not always be the same path over which data 
was sent. Since we use a separate number space for each path, supporting 
shortest-path-acknowledgements requires adding a path identifier in the 

Part of the problem there is that we end up with four frame type 
identifiers for acknowledgements, depending on whether the path 
identifier is present or not and whether the ECN counters are present or 
not. If I had to change something, I would put the ECN counters in a 
separate frame that could be composed with the ACK frame, just like time 
stamps can be carried in a separate time stamp frame. That way, we would 
end up with just three frame types for ACK, ACK_MP and ECN counters, 
instead of four. But the ECN counter decision was done a couple years 
ago, and it is too late to change it now.

-- Christian Huitema