Re: [tsvwg] path forward on L4S issue #16

[Ingemar Johansson S <[e-mail]>]

Hi

I believe that it is fair to assume that it will be a difficult task to come
up with a RFC3168 bottleneck detection algorithm in Prague that will hold
water in all different kinds of scenarios. 
It reminds me of the competing TCP flows detection algorithms in the RMCAT
standards work, SCReAM has one such algo, that sometimes works, sometimes
not. It is disabled by default in the running code.

So, given that there is likely to be cases where the RFC3168 bottleneck
detection work as intended, how bad is it?, will the internet melt down ? 
I think some clues lie in the answer to the questions. 
1) How widely are  RFC3168 ECN capable AQMs deployed _and_ enabled ?
2) If they are deployed _and_ enabled, can/will they be updated ?

Looking at all this from a 3GPP view the answers to #1 and #2 above is very
simple, there is AFAIK no deployment of RFC3168 ECN capable AQMs in 4G and
5G, meaning that this is no issue as possible implementations from now on
can address the coexistence of L4S and RFC3168 style ECN.

Now this will to some people sound like I want to dismiss the whole issue an
irrelevant, please don't interpret it like that right away, find relevant
answers to #1 and #2 instead. 
Given the answers, this can then be put in relation to the cases where the
RFC3168 ECN bottleneck detection, the current or an improved version of it
can fail. 

/Ingemar  

> 
> > I think fixing this is part of making the
> > classic queue detection and end-host performance robust in as many cases
> as
> > possible when trying to take advantage of L4S in the network, but
doesn't
> lead to a
> > safety issue.
> >
> > Are there any plans or thoughts on how to proceed on issue #16 that
> people can share?
> 
> [Writing as an individual, not WG chair]
> I have an alternate perspective on this issue, and suggest an alternate
> approach to addressing it.
> 
> Under the heading of TCP Prague, an enormous amount of work has gone
> into endpoint detection of RFC 3168 ECN bottlenecks and endpoint-based
> problem avoidance.   Of the test results that have been posted, Pete
Heist's
> scenario 8 results (https://mailarchive.ietf.org/arch/msg/tsvwg/-
> gx8R1jcwiCsX1_5cdnvl3kKlOs/) ought to give everyone pause, as they show
> TCP Prague flows getting into trouble competing among themselves.
> 
> This TCP Prague work on bottleneck detection and problem avoidance has
> been going on for a year, and while it's produced some very interesting
> results and I'm sure that more progress will be made, I'm skeptical that
> relying on it to close issue #16 will yield much more than rounds of
finding
> new problems in the next five versions of TCP Prague.   Beyond that, I'd
> expect to see quite a bit of L4S low latency traffic from protocols whose
> endpoint implementations have not been scrutinized to anything
> approaching the degree of attention that has been recently devoted to TCP
> Prague, and hence are at more risk of getting into trouble.
> 
> As an alternative, I suggest starting from Neil Cardwell's network and
> operator perspective (from
> https://mailarchive.ietf.org/arch/msg/tsvwg/kyDZ7vYLeOk1V15nZfNXGmaU
> Nxk/):
> 
> 	- L4S flows potentially causing unfairness in RFC3168 ECN
bottlenecks
> has
> 	been mentioned as a potential concern. However, a robust RFC3168
> ECN
> 	bottleneck should already have a mechanism to avoid unfairness
> caused by
> 	flows that are marked as ECT(0|1) and yet not performing RFC3168
> responses.
> 	In particular, many of the large sources of known deployments of
> RFC3168
> 	--  Linux fq_codel and cake -- are already deployed with fair
> queueing. In
> 	such bottlenecks L4S traffic should not cause harm to other non-L4S
> flows.
> 	Furthermore, if there really are ISPs with deployments of RFC3168
> 	bottlenecks that have neither FQ nor any other protection from
> 	non-RFC3168-ECT(1) flows, then they can bleach incoming ECT(1)
> code points
> 	to Not-ECT and treat L4S as Not-ECT (ISPs typically already
transform
> the
> 	DSCP byte at their ingress anyway). So I do not see harm to RFC3168
> ECN
> 	bottlenecks as a prohibitive concern.
> 
> 	- More generally, if there is any problem discovered with the L4S
> 	experiment, either the algorithm or particular implementations,
> bottlenecks
> 	can easily identify L4S traffic and bleach it into Not-ECT, and
treat it
> 	like Reno/CUBIC traffic.
> 
> TCP Prague is not only not mentioned in the text quoted above, it appears
> nowhere in the entire email from which that was extracted.  Nonetheless,
> the email lays out an approach to L4S safety, although as initially
proposed, it
> invites operator bleaching of ECT(1), which would be unfortunate, as
ECT(1)
> not being subject to bleaching is among the key reasons for using it.
Refining
> that approach might produce something more robust that doesn't invite
> ECT(1) bleaching, and that recognizes that FQ is not a 100% solution to
flow
> interference (e.g., courtesy of the birthday paradox for the number of
hash
> buckets in an FQ implementation).  As noted before, please don't cast
> aspersions in Neal's direction for introducing the notion of operator
bleaching
> of ECT(1).
> 
> So, I would suggest focusing attention on networks and operators as an
> alternative approach to focusing on endpoints.
> 
> Thanks, --David
> 
> > -----Original Message-----
> > From: tsvwg <[e-mail]> On Behalf Of Wesley Eddy
> > Sent: Thursday, June 4, 2020 4:54 PM
> > To: [e-mail]
> > Subject: [tsvwg] path forward on L4S issue #16
> >
> >
> > [EXTERNAL EMAIL]
> >
> > I think we should discuss the path forward on L4S issue #16 and what
> people are
> > working on, planning to do, or expecting to see in this regard.
> >
> > This is the issue on interaction with RFC 3168 ECN AQMs in the network.
> >
> > I think this is one of the more important ones in many recent
discussions,
> so would
> > like to make sure we're agreeing on what it will take to complete or
what
> success
> > will look like.
> >
> > The classic bottleneck detection work is a key part of this.? In that
vein, I'd
> like to
> > subsume issue #29 (that it looks like Pete Heist
> > opened) under this one and close #29.? Issue #29 shows some cases where
> an L4S
> > queue is misidentified as a classic one.? I think fixing this is part of
making
> the
> > classic queue detection and end-host performance robust in as many cases
> as
> > possible when trying to take advantage of L4S in the network, but
doesn't
> lead to a
> > safety issue.
> >
> > Are there any plans or thoughts on how to proceed on issue #16 that
> people can
> > share?
>