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/
- [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-id-1… internet-drafts
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Asad Sajjad Ahmed
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Bob Briscoe
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Ingemar Johansson S
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Bob Briscoe
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Ingemar Johansson S
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Bob Briscoe
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Bob Briscoe
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Asad Sajjad Ahmed
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Ingemar Johansson S
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Bob Briscoe
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Bob Briscoe
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Bob Briscoe
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Rodney W. Grimes
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Ingemar Johansson S
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Asad Sajjad Ahmed
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Asad Sajjad Ahmed
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Tom Henderson
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Bob Briscoe
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Tom Henderson
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Rodney W. Grimes
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Bob Briscoe