Re: Fwd: New Version Notification for draft-liu-multipath-quic-01.txt
Christian Huitema <huitema@huitema.net> Mon, 14 December 2020 19:34 UTC
Return-Path: <huitema@huitema.net>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE7523A183F for <quic@ietfa.amsl.com>; Mon, 14 Dec 2020 11:34:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.011
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpCUjn1CLXxB for <quic@ietfa.amsl.com>; Mon, 14 Dec 2020 11:34:37 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 748CB3A183E for <quic@ietf.org>; Mon, 14 Dec 2020 11:34:37 -0800 (PST)
Received: from xse245.mail2web.com ([66.113.196.245] helo=xse.mail2web.com) by mx136.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1kotc9-001Amp-Ql for quic@ietf.org; Mon, 14 Dec 2020 20:34:34 +0100
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4Cvs5y19x9z3HXJ for <quic@ietf.org>; Mon, 14 Dec 2020 11:34:30 -0800 (PST)
Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1kotc6-0008P7-1G for quic@ietf.org; 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 [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.58.43.253]) (envelope-sender <huitema@huitema.net>) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for <yunfei.ma@alibaba-inc.com>; 14 Dec 2020 19:34:29 -0000
Subject: Re: Fwd: New Version Notification for draft-liu-multipath-quic-01.txt
To: Yanmei Liu <miaoji.lym@alibaba-inc.com>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, AN Qing <anqing.aq@alibaba-inc.com>, 李振宇 <zyli@ict.ac.cn>, quic <quic@ietf.org>, Yunfei <yunfei.ma@alibaba-inc.com>
References: <1baa86a9-455d-4256-85f2-9aee159afed9.miaoji.lym@alibaba-inc.com> <CAN1APdc_1+VwOoGaX16iaQPUXfySoD-bmjuSVBJ_gLF4HUBO1Q@mail.gmail.com> <CAN1APddoML7akHEE7EiR8qbfjf=D+0n+gNP=FccvL3JSt19a0w@mail.gmail.com> <bdc7a13a-0c69-4db7-b13c-28107f8d6898.miaoji.lym@alibaba-inc.com>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <321f7b37-afb0-1cd7-06f2-7eed237d522c@huitema.net>
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: <bdc7a13a-0c69-4db7-b13c-28107f8d6898.miaoji.lym@alibaba-inc.com>
Content-Type: multipart/alternative; boundary="------------2EDB9750C9A162023A0D6C6D"
Content-Language: en-US
X-Originating-IP: 66.113.196.245
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.245/32
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.245/32@xsmtpout.mail2web.com
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
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/CK2XUgROGwZoiJzYqzKgrHY-3z0>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=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 ACK_MP. 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
- Fwd: New Version Notification for draft-liu-multi… Yanmei Liu
- Re: Fwd: New Version Notification for draft-liu-m… Mikkel Fahnøe Jørgensen
- Re: Fwd: New Version Notification for draft-liu-m… Mikkel Fahnøe Jørgensen
- Re: Fwd: New Version Notification for draft-liu-m… Mikkel Fahnøe Jørgensen
- Re: Fwd: New Version Notification for draft-liu-m… Christian Huitema
- Re: Fwd: New Version Notification for draft-liu-m… Yanmei Liu
- Re: Fwd: New Version Notification for draft-liu-m… Mikkel Fahnøe Jørgensen
- Re: Fwd: New Version Notification for draft-liu-m… Christian Huitema
- Re: Fwd: New Version Notification for draft-liu-m… Mikkel Fahnøe Jørgensen
- Re: Fwd: New Version Notification for draft-liu-m… Christian Huitema
- Re: Fwd: New Version Notification for draft-liu-m… Mikkel Fahnøe Jørgensen
- Re: Fwd: New Version Notification for draft-liu-m… Christian Huitema
- Re: Fwd: New Version Notification for draft-liu-m… Christian Huitema
- Re: Fwd: New Version Notification for draft-liu-m… Mikkel Fahnøe Jørgensen
- Re: Fwd: New Version Notification for draft-liu-m… Christian Huitema
- Re: Fwd: New Version Notification for draft-liu-m… Yunfei Ma
- Re: Fwd: New Version Notification for draft-liu-m… Mikkel Fahnøe Jørgensen
- Re: Fwd: New Version Notification for draft-liu-m… Mikkel Fahnøe Jørgensen
- Re: Fwd: New Version Notification for draft-liu-m… Mikkel Fahnøe Jørgensen
- Re: Fwd: New Version Notification for draft-liu-m… Quentin De Coninck
- Re: Fwd: New Version Notification for draft-liu-m… Yunfei Ma
- Re: Fwd: New Version Notification for draft-liu-m… Mikkel Fahnøe Jørgensen
- Re: Fwd: New Version Notification for draft-liu-m… Quentin De Coninck
- Re: Fwd: New Version Notification for draft-liu-m… Mikkel Fahnøe Jørgensen
- Re: Fwd: New Version Notification for draft-liu-m… Quentin De Coninck
- Re: Fwd: New Version Notification for draft-liu-m… Christian Huitema