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

Christian Huitema <> Sun, 01 November 2020 01:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F2F3C3A0B5D for <>; Sat, 31 Oct 2020 18:08:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.134
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=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QOvEXb4rd8Yn for <>; Sat, 31 Oct 2020 18:08:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A21EA3A0B60 for <>; Sat, 31 Oct 2020 18:08:08 -0700 (PDT)
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1kZ1qk-0018FC-DO for; Sun, 01 Nov 2020 02:08:06 +0100
Received: from (unknown []) by (Postfix) with ESMTPS id 4CNyb54KV4z1pwN for <>; Sat, 31 Oct 2020 18:08:01 -0700 (PDT)
Received: from [] ( by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <>) id 1kZ1qj-0006Fz-Fr for; Sat, 31 Oct 2020 18:08:01 -0700
Received: (qmail 2708 invoked from network); 1 Nov 2020 01:07:59 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 1 Nov 2020 01:07:59 -0000
To: Bob Briscoe <>, tsvwg IETF list <>
Cc: iccrg IRTF list <>, TCP Prague List <>, "De Schepper, Koen (Koen)" <>
References: <>
From: Christian Huitema <>
Autocrypt:; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH
Message-ID: <>
Date: Sat, 31 Oct 2020 18:07:58 -0700
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: <>
Content-Type: multipart/alternative; boundary="------------D11F9CC1B9AE72132C2FC657"
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: Mvzo4OR0dZXEDF/gcnlw0QBfAh7lyK8tB8mq1asnDr6pSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGD42+pgDSJdnVPeXOEK1m6uDbl kDZNUkuHiojIVh7uAUtF3PTDZxxNKLySeFujEVZ/UZq99/v+OWrp+SY7iSuea8EuNfnjQsRqWXYP fdewBkdPR9o014ICOs9pIWX8OtLJ7vsLUQAHXiJg5GjKIcUuXtbNhTNyx2YOvjKTJ3Ps/x2i3GSv wir0OshyEkOwfCYvxs5/T0oXYyKdvWabEYxQFC5Ano+acIK7aoZBBKN3kq8lTiPCf+PwTb/RKAdw /TswIg1fYmNb1kgzViAoNrSrXN1jhnM/Mbva2XLV/LIEzaJm4kYWBU//ZZ8pZ1xZfmaG1NRsUdzW awx6dX0NJ8Bzt99fxN2oReTDHAyOynaY0ClENaQq/2aUAxcG3yLqjApZmdySlZou9qHIGOZDEEo7 O58ZQzrOqjAERHu4pt/Ia6wELzcGxDgkPe7eR6qspNNQGjLhGMBSrFdf8dBbPvtqJwEiRQv+PVjj wa+Z5RFCOMTQVmTYR5SAzTRFbXVNTDv11iiswIL19UozX430T5i48IJ+zcGg8YNIjYugiI+1n+ST LzguUFz1tkGsPM0m2aI9QtcrfYIhqFYqsLGImKB3kkqTD2ipD9y2znxCv9uYkc8RFZ4oobg8BBg3 Jq+ntzj0/wgM0viE1oGu2MObkZJnlk7JPy9twDyaj6un7qWOkNfLRNT5LX79iO7L7vrPIp05Ubhy dJ4+ReHyZKkqNXeUBXi0EW+/nh8HB0VCDAq8bK3CN/QrniP/YVGLg6hpF+Hh647lNwN4qOsSZg+f YhVZG3Fpf9P2WwOdPRT3EWlMd754CMBw7+ErSKQN7lw8ITGaNmGHCZF9ZXtfSxIkZLsbHZnckpWa LvahyBjmQxBKOzsmHW0N+NPiHPgn+dyxhvT1Z5EPOIlpyGKEA1x50oTQDUtseoetsROuM82YMzIj 8EU=
Archived-At: <>
Subject: Re: [tcpPrague] ecn-l4s-id: Proposed Changed to Normative Classic ECN detection Text
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 01 Nov 2020 01:08:11 -0000

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?

-- Christian Huitema

On 10/31/2020 2:54 AM, Bob Briscoe wrote:
> Folks,
> The co-authors of ECN L4S ID have been reviewing the correctness of
> the normative 'Prague' requirements.
>     See
> This is the second of 2 emails, about 2 of the requirements that we
> think ought to be reworded a little.
> If you agree with the rationale, but think the new wording still
> doesn't fully capture the requirement, pls suggest sthg better.
> If you disagree with the rationale, pls discuss.
> 4.3.  Prerequisite Congestion Response
> ...
>    o  A scalable congestion control MUST react to ECN marking from a
>       non-L4S but ECN-capable bottleneck in a way that will coexist with
>       a TCP Reno congestion control [RFC5681 <>] (see Appendix A.1.4 <> for
>       rationale).
>       Note that a scalable congestion control is not expected to change
>       to setting ECT(0) while it falls back to coexist with Reno.
>    o  A scalable congestion control MUST implement monitoring in order
>       to detect a likely non-L4S but ECN-capable AQM at the bottleneck.
>       On detection of a likely ECN-capable bottleneck it SHOULD be
>       capable (dependent on configuration) of automatically adapting its
>       congestion response to coexist with TCP Reno congestion controls
>       [RFC5681] (see Appendix A.1.4 for rationale and a referenced
>       algorithm).
>       Note that a scalable congestion control is not expected to change
>       to setting ECT(0) while it falls back to coexist with Reno.
> 1/ The requirement as currently written says what an omniscient sender
> MUST do. So there's an implied requirement that a sender MUST be
> omniscient, which is of course impossible.
> 2/ The requirement needs to be recast to require a sender to aim to be
> as knowledgeable as possible. Then, what it does as a result needs to
> take into account the a priori likelihood of there being a non-L4S
> bottleneck present.
> 3/ This includes the possibility that the operator of the host knows
> that the network it serves has not deployed any single queue classic
> ECN AQM (e.g. in a CDN case they're doing out of band testing, or
> they've asked the ISP). So we've included the possibility of fall-back
> being disabled by configuration.
> 4/ Nonetheless, as has been pointed out on the list, there is still a
> possibility that there is a Classic ECN AQM somewhere else on the path
> (to continue the CDN example, perhaps beyond the ISP in a home
> network). The 'MUST monitor' requirement still stands to ensure the
> operator doesn't miss these cases.
> 5/ Then, if the server operators have disabled fall-back for their
> deployment, they can reconsider their policy or at least do more
> focused testing if they are frequently detecting a single-queue
> Classic ECN AQM.
> Items 3-5 are the "react via management" model that I've talked about
> on the list, given the unfairness doesn't amount to starvation, and it
> is possible that the prevalence of the problem is very low.
> Finally, after the bullet list of requirements in section 4.3, (which
> are prerequisites for setting the ECT1 codepoint), we propose to add
> the following requirement, as suggested on the tsvwg list:
>       To participate in the L4S experiment, a scalable congestion
> control MUST
>       be capable of being replaced by a Classic congestion control (by
>       application and by administrative control). A Classic congestion
> control
>       will not tag its packets with the ECT(1) codepoint.
> Cheers
> Bob
> -- 
> ________________________________________________________________
> Bob Briscoe                     
> _______________________________________________
> tcpPrague mailing list