Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-id-13.txt
Asad Sajjad Ahmed <asadsa@ifi.uio.no> Sat, 06 March 2021 15:21 UTC
Return-Path: <asadsa@ifi.uio.no>
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 B21C03A083E for <tsvwg@ietfa.amsl.com>; Sat, 6 Mar 2021 07:21:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 pmIr4x1D-gfb for <tsvwg@ietfa.amsl.com>; Sat, 6 Mar 2021 07:21:17 -0800 (PST)
Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 A4F753A083B for <tsvwg@ietf.org>; Sat, 6 Mar 2021 07:21:16 -0800 (PST)
Received: from mail-mx12.uio.no ([129.240.10.84]) by mail-out02.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4) (envelope-from <asadsa@ifi.uio.no>) id 1lIYjr-0000xK-UL; Sat, 06 Mar 2021 16:21:07 +0100
Received: from ti0187q162-5631.bb.online.no ([31.45.119.66] helo=localhost) by mail-mx12.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user asadsa@ifi.uio.no (Exim 4.93.0.4) (envelope-from <asadsa@ifi.uio.no>) id 1lIYjq-000Ar8-E4; Sat, 06 Mar 2021 16:21:07 +0100
Date: Sat, 06 Mar 2021 16:19:37 +0100
From: Asad Sajjad Ahmed <asadsa@ifi.uio.no>
To: Bob Briscoe <ietf@bobbriscoe.net>
Cc: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Message-ID: <20210306151937.t2nr3qi62it6ehtc@debian.debian>
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> <c6f792b9-7523-987e-edbe-4c9f019daf28@bobbriscoe.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <c6f792b9-7523-987e-edbe-4c9f019daf28@bobbriscoe.net>
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 31.45.119.66 is neither permitted nor denied by domain of ifi.uio.no) client-ip=31.45.119.66; envelope-from=asadsa@ifi.uio.no; helo=localhost;
X-UiO-Spam-info: not spam, SpamAssassin (score=-2.9, required=5.0, autolearn=disabled, AWL=2.125, UIO_MAIL_IS_INTERNAL=-5)
X-UiO-Scanned: 508D757432BCDD4EB1A2E791415EC399C6DB244C
X-UiOonly: 0D62A6F270C6227F6D15DFEB8136998D550180A6
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/pYpW6o176hGobhkzbqtoWfpN0yk>
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: Sat, 06 Mar 2021 15:21:21 -0000
Bob, see [ASA2] inline, On 21/03/05 11:42:58, Bob Briscoe wrote: > 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] I would rather encourage L4S flows to do what the SHOULD says, than > "give up". They can do this either by implementing a min window <1 or by > doing what RFC3168 requires. So I've changed the wording again to make it > clearer that the RFC3168 requirement is still relevant to L4S as a (rather > drastic) alternative to window < 1. > > o 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 1 segment rather than > use the timeout approach described for TCP 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). [ASA2] Thanks, this new text works for me. Asad > > > Also thx for pointing out the Appendix is now inconsistent. I've also > updated that. Rather than try to explain the diffs here, I'll shall be > posting the new rev when the IETF servers open on Monday. Then everyone can > use the usual diff tools. > > Cheers > > > Bob > > > > > > 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/ > -- Asad
- [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