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 94C503A083E for <tsvwg@ietfa.amsl.com>; Sat, 6 Mar 2021 07:21:49 -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 VaPD9VnfcOGx for <tsvwg@ietfa.amsl.com>; Sat, 6 Mar 2021 07:21:46 -0800 (PST)
Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 4781A3A083B for <tsvwg@ietf.org>; Sat, 6 Mar 2021 07:21:43 -0800 (PST)
Received: from mail-mx11.uio.no ([129.240.10.83]) by mail-out01.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 1lIYjf-0002KE-KS; Sat, 06 Mar 2021 16:20:55 +0100
Received: from ti0187q162-5631.bb.online.no ([31.45.119.66] helo=localhost) by mail-mx11.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 1lIYjd-00048n-Vk; Sat, 06 Mar 2021 16:20:55 +0100
Date: Sat, 6 Mar 2021 16:16:20 +0100
From: Asad Sajjad Ahmed <asadsa@ifi.uio.no>
To: "Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net>
Cc: Bob Briscoe <ietf@bobbriscoe.net>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Message-ID: <20210306151620.b3b67x5d2jhzsz53@debian.debian>
References: <c6f792b9-7523-987e-edbe-4c9f019daf28@bobbriscoe.net> <202103051212.125CCi6H059878@gndrsh.dnsmgr.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <202103051212.125CCi6H059878@gndrsh.dnsmgr.net>
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx11.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=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5)
X-UiO-Scanned: E924972922F3DF991B0BDB247A1587301098BEE3
X-UiOonly: 41FEE7FB7295EFE0488988459664CDBC9F27DF90
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/XAomea7t4oFFTb7SXjtDqiSytAs>
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:50 -0000

Hi Rod, see [ASA2] inline

On 21/03/05 04:12:44, Rodney W. Grimes wrote:
> Bob, see [RWG] inline
> 
> > 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>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.
> 
> I would think it does not matter what causes the decrease.  Simplify
> by ending at "smaller"?  Or better yet, can that just be expressed
> as "SHOULD remain responsive to congestion independent of RTT"?
> 
> 
> >                        It would be preferable for the minimum window of a
> >        scalable congestion control to be lower than 1 segment rather than
> 
> lower than 1?  That is 0, and that is window colapse which in most
> stacks would be a deadlock, that is why the minimum window is 1.
> 
> Also what is "segment" in this context?    Or is what your saying
> is that the minimum window can be lower than a TCP segment in the
> sense of MSS?
> 

[ASA2] Less than 1 segment per RTT means that you send out your segment with a
local computed delay (possible with pacing), so if you want to keep a cwnd of 
0.5 segment per RTT you would need to send out one segment every other RTT. 
Of course, you could send out smaller segments, in this case half a segment per 
RTT, but you would then have more overhead per packet which would make the
network useless as less data is transferred.

The idea is that if every sender can defer their segment with a small delay 
then the AQM can continue to keep a shallow queue. This would benefit 
everyone at the bottleneck as they would only traverse the shallow
queue. If the sender instead keep at a minimum 1 or 2 segments in flight
per RTT, then the AQM have no way to slow down the sender and as a result the 
queue would get out of control. This is current practice under Linux at
least, where a ECN mark is merely ignored when cwnd is as low as 2.

Asad

> >        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).
> > 
> > 
> > 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/
> > 
> 
> -- 
> Rod Grimes                                                 rgrimes@freebsd.org

-- 
Asad