Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Changed to Normative Classic ECN detection Text

Christian Huitema <huitema@huitema.net> Sun, 01 November 2020 19:48 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: tcpprague@ietfa.amsl.com
Delivered-To: tcpprague@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 182FA3A0E1E for <tcpprague@ietfa.amsl.com>; Sun, 1 Nov 2020 11:48:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.134
X-Spam-Level:
X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 FG34qVCw6Gdk for <tcpprague@ietfa.amsl.com>; Sun, 1 Nov 2020 11:48:19 -0800 (PST)
Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 38CDE3A0E17 for <tcpPrague@ietf.org>; Sun, 1 Nov 2020 11:48:19 -0800 (PST)
Received: from xse235.mail2web.com ([66.113.196.235] helo=xse.mail2web.com) by mx169.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1kZJKn-000rc5-KP for tcpPrague@ietf.org; Sun, 01 Nov 2020 20:48:16 +0100
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4CPRRc2NDHzqpp for <tcpPrague@ietf.org>; Sun, 1 Nov 2020 11:48:12 -0800 (PST)
Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1kZJKm-0000R3-7a for tcpPrague@ietf.org; Sun, 01 Nov 2020 11:48:12 -0800
Received: (qmail 7772 invoked from network); 1 Nov 2020 19:48:10 -0000
Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.139]) (envelope-sender <huitema@huitema.net>) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for <tcpPrague@ietf.org>; 1 Nov 2020 19:48:10 -0000
To: Jonathan Morton <chromatix99@gmail.com>
Cc: iccrg IRTF list <iccrg@irtf.org>, Bob Briscoe <ietf@bobbriscoe.net>, tsvwg IETF list <tsvwg@ietf.org>, "De Schepper, Koen (Koen)" <koen.de_schepper@nokia.com>, TCP Prague List <tcpPrague@ietf.org>
References: <1b71a610-75ea-e1d4-e3ce-f0ae6a4c12f7@bobbriscoe.net> <28247e5f-5df3-1f75-50e6-b4a7e80d5ab0@huitema.net> <61B6E9DC-8786-4CC0-9AC0-7F74E3529A73@gmail.com>
From: Christian Huitema <huitema@huitema.net>
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH
Message-ID: <40751956-daa0-5693-d880-c45e8ca262cc@huitema.net>
Date: Sun, 1 Nov 2020 11:48:09 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <61B6E9DC-8786-4CC0-9AC0-7F74E3529A73@gmail.com>
Content-Type: multipart/alternative; boundary="------------27D8CA2479553515CD6429CB"
Content-Language: en-US
X-Originating-IP: 66.113.196.235
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.235/32
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.235/32@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0XvADx2zSFwG+3csxFBPBHmpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGD42+pgDSJdnVPeXOEK1m6uDbl kDZNUkuHiojIVh7uAUvAB1OJHBkjcz9byGlmlUIRUZq99/v+OWrp+SY7iSuea8EuNfnjQsRqWXYP fdewBkdPR9o014ICOs9pIWX8OtLJkJMlHRIWtRpp4V4PED3qDNbNhTNyx2YOvjKTJ3Ps/x2i3GSv wir0OshyEkOwfCYvxs5/T0oXYyKdvWabEYxQFC5Ano+acIK7aoZBBKN3kq8lTiPCf+PwTb/RKAdw /TswIg1fYmNb1kgzViAoNrSrXN1jhnM/Mbva2XLV/LIEzaJm4kYWBU//ZZ8pZ1xZfmaG1NRsUdzW awx6dX0NJ8Bzt99fxN2oReTDHAyOynaY0ClENaQq/2aUAxcG3yLqjApZmdySlZou9qHIGOZDEEo7 O58ZQzrOqjAERHu4pt/Ia6wELzcGxDgkPe7eR6qspNNQGjLhGMBSrFdf8dBbPvtqJwEiRQv+PVjj wa+Z5RFCOMTQVmTYR5SAzTRFbXVNTDv1gM5nBN3RJV9d5r5Q9lo7jszxgxhYBzM2+4BnTFvsXJXQ H50sZPeDQaETTMuyQC0ZCkbu0MIf5gIxteqwqB3UtXuXCC1A5Cukky0WFo38JXT3Y80OmAux3oN1 3+ztUznewCRQPWF2E4IsCIsjaWgrKL83o7TP54FLJfg9sR3SxHLLGnbyn7Qsr0CcmcAsjT/95XkJ osV7x+qD/ILIgQTnY4W+axx2DzNv8BNlsyaVn+WJZaCGVcqE0K0GEdVNC7oG3UVkhX78ZcdZtWJt ri4lXS4599fEDT1GENo62d+DqD+gavEa4Cf1ILpAKBLSDHQENgjpXL2y/ONOC04/YEfTu1ss+n2f fnQxt6aJ7klZab8CvOT2YjlrAxveXsTwUzCTkiX4qyX2d5a1xbDejUjyqRVeiJQ5XjnH4gzAuCMQ 8aUxL7hrJSk60SF3F6RYOYr2
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpprague/f76ETQoSfiOwOrdFBwMesPMmvnI>
Subject: Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Changed to Normative Classic ECN detection Text
X-BeenThere: tcpprague@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." <tcpprague.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpprague/>
List-Post: <mailto:tcpprague@ietf.org>
List-Help: <mailto:tcpprague-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Nov 2020 19:48:23 -0000

On 11/1/2020 9:00 AM, Jonathan Morton wrote:
>> On 1 Nov, 2020, at 3:07 am, Christian Huitema <huitema@huitema.net> wrote:
>>
>> I am reading the L4S ECN-AQM proposal with an eye on responding to it in an implementation of QUIC, and I have a couple of questions regarding use of ECN marking with QUIC. 
>>
>> The document does not mention QUIC, yet QUIC is already used in a large fraction of Internet traffic. QUIC does specify support for ECN, and QUIC acknowledgements may carry counts of each category of ECN marks received from the peer -- three counters for ECT(0), ECT(1) and CE. In theory, QUIC implementations could take advantage of L4S -- in fact, at least one implementation supports DC-TCP like CC already. Is there interest in specifying L4S for QUIC?
>>
>> My next question regards the interaction of the proposed L4S ECN-AQM with CC algorithms like BBR that attempt to discover the bottleneck packet rate for the connection, and use pacing to send packets at that rate. I observed that BBR is never mentioned in the draft, yet BBR is used in a sizeable part of Internet traffic. Do we have data on how a non-L4S aware implementation of BBR interacts with the proposed L4S AQM?
>>
>> My last question regards potential use of ECT(1) marking. Most current implementations set ECT(0), but setting ECT(1) instead is trivial. This should elicit an L4S compatible response in L4S-AQM, and the BBR implementation might be modified to use the signals as part of the bottleneck bandwidth tracking. But there is a small issue there. With BBR, QUIC packets are supposedly paced at just under the bottleneck rate, except during "probe" periods in which they probe for 1 RTT at a slightly higher rate. The L4S AGM might degenerate in a form of ON-OFF control -- no feedback at all most of the time, then a bunch of CE marks if the probe rate exceeds the bottleneck bandwidth. As anyone experimented with that?
> In my view, the biggest question you should be asking is how QUIC will distinguish between CE marks applied by an L4S AQM on the path, and those applied by an RFC-3168 AQM on the path.  The latter will treat ECT(1) marked packets the same as ECT(0), and expects the same multiplicative-decrease congestion response, but L4S expects a qualitatively different linear response.

Yes, that's a significant issue. As it is, nodes can only work with L4S
on specific paths that are somehow guaranteed to not mix the "classic"
and "L4S" behavior. For now, the only way I would implement it is by
adding an "l4s" option, that would only be turned on by default when
experimenting with L4S behavior. If we want any large scale deployment,
we have to get an IETF consensus on the evolution of ECN -- something
prescriptive, not just the "may experiment" of RFC 8311. Currently,
implementations can only treat CE marks as an indication that they are
probably sending faster than the network allows.

> You should probably not do any substantial work on integrating L4S into QUIC until you have a good answer to that question.  Alternative approaches to high-fidelity congestion control exist which resolve that particular conundrum easily.  In particular, the ECN field feedback mechanism in QUIC can also support SCE.

Yes, QUIC implementations could indeed support SCE. But they could not
support both SCE and L4S, and that's a big bummer.

I wonder whether there is a way to unify the L4S and SCE behaviors.
Transport protocol developers are unlikely to widely develop either
option unless the IETF comes to a consensus. This is a shame, because
ECN based congestion control does not have the ambiguity of loss-based
CC: ECN marks are not ambiguous, they are clearly signals from the
network, the application does not need to build logic to differentiate
between congestion induced losses and random losses due to, for example,
radio event. Failing that ECN unification CC algorithms end up relying a
lot on bandwidth and delay measurements, but that is sub-optimal because
some radio links do have variable bandwidth and variable delays.

By the way, I do think that L4S makes too many hypotheses about the CC.
I wish the AQM was based on intrinsic properties, such as "this flow is
using more than its fair share of bandwidth" or "this link is congested
and the transport should back off" rather than reasoning as if
implementations were still using TCP-RENO, which neither Linux or
Windows or Chrome does.

-- Christian Huitema