Re: [tsvwg] Consensus call on ECT(1)

[Steven Blake <[e-mail]>]

On Tue, 2020-05-19 at 09:46 +0200, Roland Bless wrote:
> Hi Dan,
> 
> On 18.05.20 at 18:46 Dan Siemon wrote:
> > My vote is #3 (more testing) because I don't have a complete enough
> > understanding of L4S to be firmly against it and I don't fully
> > understand the tunnel marking implications. Second choice is ECT as
> > output.
> > 
> > My interest and concern in this comes from the point of view of a
> > vendor [1] that offers traffic management solutions for the fixed
> > wireless market [2]. We use FQ-CoDel but at this point have not
> > widely
> > enabled ECN (the little experimentation we've done looks
> > promising).
> > 
> > My rational is as follows:
> > * One of the reasons that DSCP hasn't taken off, in addition to the
> > coordination problem, is that without per-subscriber isolation, it
> > will
> > be gamed. I do not understand why a new classification scheme would
> > not
> > suffer the same fate.
> 
> +1
> 
> > * The improvement with a modern AQM is already dramatic.
> > * It's "weird" that in the "ECT(1) as input" option, of the four
> > ECN
> > combinations, three are related to congestion control and one is a
> > special, 'DSCP doesn't work so we stole it for classification'
> > value.
> > Explaining that outside of this forum may not be fun.
> 
> Yep, that's also one of the points I find quite odd. It would be
> better
> to make DSCPs "work" (at least not bleaching them) instead of
> creating
> more and more work arounds.
> 
> > * SCE (ECT(1) as output) is more intuitive to me.
> 
> The nice thing about this is that the output is at least unambiguous:
> ECT(1) means some/light congestion level (scalable congestion control
> reaction), CE means traditional indication of congestion (stronger
> congestion control reaction). Whereas in L4S it is not clear whether
> CE actually means "classic CE" or "L4S CE".
> 
> > * Most fixed wireless networks are flat IP with little tunnelling
> > and
> > use simple equipment that I'm skeptical will adopt L4S. These
> > networks
> > host millions of subscribers in the U.S. alone.
> > 
> > [1] - https://www.preseem.com
> > [2] - https://www.wispa.org/what_is_a_wisp.php
> > 
> 
> Regards
>  Roland

The sad/hilarious side of this is that we once had a bit in IP to
indicate a preference for low-delay: the D bit in the TOS field.

https://tools.ietf.org/html/rfc791#page-12

Unfortunately, in addition to (correctly IMHO) advising vendors to make
the mapping between these bits and HW mechanisms configurable, the
geniuses who came up with Diffserv also changed the (default) semantic
interpretation of this bits in ways that, with 20 years of hindsight,
haven't resulted in a raging operational success.

SMDH.


// Steve