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

Bob Briscoe <ietf@bobbriscoe.net> Fri, 05 March 2021 10:42 UTC

Return-Path: <ietf@bobbriscoe.net>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5213A2346 for <tsvwg@ietfa.amsl.com>; Fri, 5 Mar 2021 02:42:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.433
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
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 ORi1OckcM9zC for <tsvwg@ietfa.amsl.com>; Fri, 5 Mar 2021 02:42:39 -0800 (PST)
Received: from mail-ssdrsserver2.hosting.co.uk (mail-ssdrsserver2.hosting.co.uk [185.185.84.51]) (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 6FE743A2345 for <tsvwg@ietf.org>; Fri, 5 Mar 2021 02:42:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; 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 67.153.238.178.in-addr.arpa ([178.238.153.67]:54830 helo=[192.168.1.11]) by ssdrsserver2.hosting.co.uk with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <ietf@bobbriscoe.net>) id 1lI7uo-0002vj-4Z; Fri, 05 Mar 2021 10:42:38 +0000
To: Asad Sajjad Ahmed <asadsa@ifi.uio.no>
Cc: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
References: <161403126355.2878.575062349927307577@ietfa.amsl.com> <20210225200602.lix6lyq2w6c6bclz@debian.debian> <bb46880a-0e4a-b5a3-24a8-95123a3d6a48@bobbriscoe.net> <HE1PR0701MB22993AB48783A4E011335A36C2989@HE1PR0701MB2299.eurprd07.prod.outlook.com> <f618a4b0-eed3-f369-8646-bd6a6c99a2a7@bobbriscoe.net> <20210304233941.2ucge2vfgu7iaqrk@debian.debian>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <b24557e2-e82c-8798-74cd-b0e638e01072@bobbriscoe.net>
Date: Fri, 05 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 - ssdrsserver2.hosting.co.uk
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: ssdrsserver2.hosting.co.uk: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: ssdrsserver2.hosting.co.uk: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/YJ_D6VB5kGOgDsaLZM9xgbagw_w>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-id-13.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=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 <ietf@bobbriscoe.net>
>>>> Sent: den 2 mars 2021 14:54
>>>> To: Asad Sajjad Ahmed <asadsa@ifi.uio.no>; tsvwg@ietf.org; Ingemar
>>>> Johansson S <ingemar.s.johansson@ericsson.com>
>>>> 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.

[BB]



>
> 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]
>>>>> https://protect2.fireeye.com/v1/url?k=b9da725e-e6414b1d-b9da32c5-
>>>> 861fc
>>>>> b972bfc-e0a4204086eb23c8&q=1&e=417868d5-deeb-4c4f-9d1e-
>>>> debe95d3e33c&u=
>>>>> http%3A%2F%2Fwww.icir.org%2Ffloyd%2Fpapers%2Fecnsims.pdf (§8)
>>>>>
>>>>> On 21/02/22 14:01:03, internet-drafts@ietf.org 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:
>>>>>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-l4s-id/
>>>>>>
>>>>>> There are also htmlized versions available at:
>>>>>> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-13
>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-13
>>>>>>
>>>>>> A diff from the previous version is available at:
>>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-ecn-l4s-id-13
>>>>>>
>>>>>>
>>>>>> Please note that it may take a couple of minutes from the time of
>>>>>> submission until the htmlized version and diff are available at
>>>> tools.ietf.org.
>>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>>
>>>>>>
>>>> --
>>>> __________________________________________________________
>>>> ______
>>>> Bob Briscoe                               https://protect2.fireeye.com/v1/url?k=2a6f2e59-
>>>> 75f4171a-2a6f6ec2-861fcb972bfc-e28ad1342845f12e&q=1&e=417868d5-
>>>> deeb-4c4f-9d1e-debe95d3e33c&u=http%3A%2F%2Fbobbriscoe.net%2F
>> -- 
>> ________________________________________________________________
>> Bob Briscoe                               http://bobbriscoe.net/
>>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/