Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-id-13.txt

Bob Briscoe <> Fri, 05 March 2021 10:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AC5213A2346 for <>; Fri, 5 Mar 2021 02:42:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.433
X-Spam-Status: No, score=-1.433 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ORi1OckcM9zC for <>; Fri, 5 Mar 2021 02:42:39 -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 6FE743A2345 for <>; Fri, 5 Mar 2021 02:42:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=d3OnRf1ZEsIISPa1kZulIqp7UPHrO7PcopuY2RRgQAs=; b=yYz3xeq7GV4b08Dz5CzcofFBxP MaYgqqTKJ2PEqd39Zsw9KqYls4ll7AOWMPuUxPyw81Khfz3Dl1Zo4tUbf637V5kFJZPxq0RYReu16 py122IndqvRrmMgC7msIKAYOk3vr5ERC9IwHMOxDZ1RzxSov8kteBD7S9YALA0bokEmJnAfxr186e LlbuKAt7GUMOrV/C2qy/eIaHY5W4Wg9zmdixcMlFN7N70ipWsOzHi18MdpyE+Vz+p9BYWWYO35cvl o1ijWmBUkLKeQm8TvON6s+cgg6FeI2ZcVWAH0a1dlXtpLSPdQk8A872NNm0WyiY5b0oMxYfoqqMOX fWDEiLPw==;
Received: from ([]:54830 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <>) id 1lI7uo-0002vj-4Z; Fri, 05 Mar 2021 10:42:38 +0000
To: Asad Sajjad Ahmed <>
Cc: Ingemar Johansson S <>, "" <>
References: <> <20210225200602.lix6lyq2w6c6bclz@debian.debian> <> <> <> <20210304233941.2ucge2vfgu7iaqrk@debian.debian>
From: Bob Briscoe <>
Message-ID: <>
Date: Fri, 5 Mar 2021 10:42:37 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <20210304233941.2ucge2vfgu7iaqrk@debian.debian>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
Archived-At: <>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-id-13.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 05 Mar 2021 10:42:42 -0000

Asad, see [BB] inline

On 04/03/2021 23:39, Asad Sajjad Ahmed wrote:
> Bob,
> (see [ASA] inline for comments, your original reply got lost for me (not
> in the spam folder, so I had to reconstruct the thread from a later reply.)
>>>> -----Original Message-----
>>>> From: Bob Briscoe <>
>>>> Sent: den 2 mars 2021 14:54
>>>> To: Asad Sajjad Ahmed <>no>;; Ingemar
>>>> Johansson S <>
>>>> Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-id-13.txt
>>>> Asad and Ingemar,
>>>> @Asad. Thank you v much for reminding me of that section in RFC3168. The
>>>> text in ecn-l4s-id wasn't trying to allow a higher min window than existing
>>>> RFCs. Indeed, it was trying to encourage implementers the other way -
>>>> lower. But without forcing anyone, because implementing a lower minimum
>>>> than 1  requires a step-change in complexity (as your thesis on this subject
>>>> taught me).
> [ASA] Sorry, that was what I meant. There is no need, I hope, to reinforce the
> same requirement in the L4S experiment, as long as RFC3168
> requirement about being responsive to congestion at low cwnd stands.
> It's also good that the problem and the requirement of RFC3168 is mentioned
> here as with very low queuing delay there is significantly higher likelihood
> for the problem to occur.
>>>> I don't think the first sentence with the SHOULD contradicts RFC3168, but it
>>>> seems the second sentence makes it look that way to some people's eyes.
>>>> So let's reword it. Also, I notice that it was only applicable to TCP, not all
>>>> transports. How about...
>>>>          A scalable congestion control SHOULD remain responsive to
>>>>          congestion when typical RTTs over the public Internet are
>>>>          significantly smaller because they are no longer inflated by
>>>>          queuing delay.  It would be preferable for the minimum window of a
>>>>          scalable congestion control to be lower than the 1 segment minimum
>>>>          for TCP mentioned in S.6.1.2 of [RFC3168] (or an equivalent for other
>>>>          transports). However, a lower minimum is not set as a formal
>>>> requirement
>>>>          for L4S experiments (see Appendix A.1.6 for rationale)."
> [ASA] Thanks, this new text is good. But, Appendix A.1.6 needs to reflect the
> same view (TCP as is does NOT allow a minimum other the maximum RTO you
> are allowed to set [RFC6298], i.e., 60 seconds). For Appendix A.1.6, I would
> also rephrase the paragraph I quoted to be more explicit about, when competing
> with unresponsive flow it's a trade off between being fully responsive and
> going back to behaving same as one Not-ECT flow.
> This got me thinking, should an unresponsive ECN flow be allowed to keep using
> the ECT(1) code-point? I would say no because when you decide to go
> unresponsive, you made the decision to harm other traffic (!), you are not
> interested in keeping the queue low (!!), you are gambling that the AQM /drops/
> your packets with the same probability as for Not-ECT flows (and not mark
> them) (!!!). This means that you are, essentially, aiming for no benefits
> from L4S so why bother signaling to the network that you are responsive.
> This would give a more appropriate trade-off, on one side you keep the
> benefits of L4S by being responsive while on the other side you withdraw
> your benefits, but at the same time be more "protected from starvation". In
> quotes, because you are now as much protected as the Not-ECT flows you once
> tried to starve.


> Asad
>>>> @Ingemar, you said your min in SCReAM is 3 datagrams, but you could
>>>> configure it lower. Are SCReAM's datagrams smaller than the MTU? Is the
>>>> text above clear enough for a non-TCP transport? Whatever, would you set a
>>>> different limit?
>>>> Bob
>>>> On 25/02/2021 20:06, Asad Sajjad Ahmed wrote:
>>>>> Bob,
>>>>> Thanks for updating and for have put in a lot of effort into this draft.
>>>>> I have a minor comment regarding the cwnd reduction over ECN when
>>>> cwnd
>>>>> is already very low:
>>>>> Current draft gives a formal requirement:
>>>>> §4.3:
>>>>>         "A scalable congestion control SHOULD remain responsive to
>>>>>          congestion when typical RTTs over the public Internet are
>>>>>          significantly smaller because they are no longer inflated by
>>>>>          queuing delay.  It would be preferable for the minimum window of a
>>>>>          scalable congestion control to be lower than the 2 segment minimum
>>>>>          of TCP Reno [RFC5681] but this is not set as a formal requirement
>>>>>          for L4S experiments (see Appendix A.1.6 for rationale)."
>>>>> §A.1.6:
>>>>>        "However, the requirement in Section 4.3 is worded as a "SHOULD"
>>>>>         because the existence of a minimum window is not all bad.  When
>>>>>         competing with an unresponsive flow, a minimum window naturally
>>>>>         protects the flow from starvation by at least keeping some data
>>>>>         flowing."
>>>>> But, this contradict with RFC3168 (PS):
>>>>> §6.1.2:
>>>>>        "[...] Therefore, the sending TCP MUST reset the
>>>>>         retransmit timer on receiving the ECN-Echo packet when the congestion
>>>>>         window is one.  The sending TCP will then be able to send a new
>>>>>         packet only when the retransmit timer expires."
>>>>> The contradiction here is "SHOULD" vs. "MUST". Also TCP CC, as given
>>>>> out by RFC5681, does NOT mandate a minimum transmission rate. TCP's
>>>>> loss recovery at low cwnd relies on RTO to recover lost segments and
>>>>> TCP using ECN is supposed to mimic this behavior [floyd98]. Otherwise,
>>>>> you risk starving the Not-ECT set of flow, driving up the queue and
>>>>> increasing the marking probability by going unresponsive at cwnd of
>>>>> two segments. This is about harm toward other traffic so it make no
>>>>> sense to relax a formal "MUST". Of couse, it is desireable that the
>>>>> AQM take action and evict packets from non-responsive flows, but this is
>>>> not true for all AQM, one example being CoDel.
>>>>> But, the minimum cwnd of 2 does not originate from L4S, but has been
>>>>> the current practice for a very long time at least under the Linux TCP stack.
>>>>> This, obviously, also needs to be addressed.
>>>>> Asad
>>>>> [floyd98]
>>>> 861fc
>>>>> b972bfc-e0a4204086eb23c8&q=1&e=417868d5-deeb-4c4f-9d1e-
>>>> debe95d3e33c&u=
>>>>> (§8)
>>>>> On 21/02/22 14:01:03, wrote:
>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>> directories.
>>>>>> This draft is a work item of the Transport Area Working Group WG of the
>>>> IETF.
>>>>>>            Title           : Identifying Modified Explicit Congestion Notification (ECN)
>>>> Semantics for Ultra-Low Queuing Delay (L4S)
>>>>>>            Authors         : Koen De Schepper
>>>>>>                              Bob Briscoe
>>>>>> 	Filename        : draft-ietf-tsvwg-ecn-l4s-id-13.txt
>>>>>> 	Pages           : 58
>>>>>> 	Date            : 2021-02-22
>>>>>> Abstract:
>>>>>>       This specification defines the identifier to be used on IP packets
>>>>>>       for a new network service called low latency, low loss and scalable
>>>>>>       throughput (L4S).  L4S uses an Explicit Congestion Notification (ECN)
>>>>>>       scheme that is similar to the original (or 'Classic') ECN approach.
>>>>>>       'Classic' ECN marking was required to be equivalent to a drop, both
>>>>>>       when applied in the network and when responded to by a transport.
>>>>>>       Unlike 'Classic' ECN marking, for packets carrying the L4S
>>>>>>       identifier, the network applies marking more immediately and more
>>>>>>       aggressively than drop, and the transport response to each mark is
>>>>>>       reduced and smoothed relative to that for drop.  The two changes
>>>>>>       counterbalance each other so that the throughput of an L4S flow will
>>>>>>       be roughly the same as a non-L4S flow under the same conditions.
>>>>>>       Nonetheless, the much more frequent control signals and the finer
>>>>>>       responses to them result in much more fine-grained adjustments, so
>>>>>>       that ultra-low and consistently low queuing delay (typically sub-
>>>>>>       millisecond on average) becomes possible for L4S traffic without
>>>>>>       compromising link utilization.  Thus even capacity-seeking (TCP-like)
>>>>>>       traffic can have high bandwidth and very low delay at the same time,
>>>>>>       even during periods of high traffic load.
>>>>>>       The L4S identifier defined in this document distinguishes L4S from
>>>>>>       'Classic' (e.g. TCP-Reno-friendly) traffic.  It gives an incremental
>>>>>>       migration path so that suitably modified network bottlenecks can
>>>>>>       distinguish and isolate existing traffic that still follows the
>>>>>>       Classic behaviour, to prevent it degrading the low queuing delay and
>>>>>>       low loss of L4S traffic.  This specification defines the rules that
>>>>>>       L4S transports and network elements need to follow to ensure they
>>>>>>       neither harm each other's performance nor that of Classic traffic.
>>>>>>       Examples of new active queue management (AQM) marking algorithms
>>>> and
>>>>>>       examples of new transports (whether TCP-like or real-time) are
>>>>>>       specified separately.
>>>>>> The IETF datatracker status page for this draft is:
>>>>>> There are also htmlized versions available at:
>>>>>> A diff from the previous version is available at:
>>>>>> Please note that it may take a couple of minutes from the time of
>>>>>> submission until the htmlized version and diff are available at
>>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> --
>>>> __________________________________________________________
>>>> ______
>>>> Bob Briscoe                     
>>>> 75f4171a-2a6f6ec2-861fcb972bfc-e28ad1342845f12e&q=1&e=417868d5-
>>>> deeb-4c4f-9d1e-debe95d3e33c&
>> -- 
>> ________________________________________________________________
>> Bob Briscoe                     

Bob Briscoe