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