Re: [Ecn-sane] IETF 110 quick summary

[Pete Heist <pete@heistp.net>]

On Tue, 2021-03-09 at 12:50 -0500, Steven Blake wrote:
> On Tue, 2021-03-09 at 12:31 -0500, Steven Blake wrote:
> 
> > Their whole safety plan depends on the claim that Classic RFC 3168
> > ECN 
> > is not deployed (except in fq_codel on the edge; who cares? they can
> > patch their code). If that were the case, it would make more sense
> > for
> > them to try to move classic ECN to historic and redefine ECT(0) to
> > signal L4S traffic (ala DCTCP). 
> 
> Actually, that is the ideal outcome. ECT(0) signals ECT-Capable, ECT(1)
> and CE signal two levels of congestion. In other words, SCE everywhere.
> 
> Maybe that is an argument that you can throw at them: if it is safe to
> ignore classic ECN, might as well move straight to SCE with non-ECT
> traffic shunted off to a separate queue(s).

You've hit on what IMO is a serious inconsistency in section B.5 of the
L4S-ID draft, which at one point explored that option:

-----
B.5.  ECN capability alone

   This approach uses ECN capability alone as the L4S identifier.  It
   would only have been feasible if RFC 3168 ECN had not been widely
   deployed.  This was the case when the choice of L4S identifier was
   being made and this appendix was first written.  Since then, RFC
3168
   ECN has been widely deployed and L4S did not take this approach
   anyway.  So this approach is not discussed further, because it is no
   longer a feasible option.
----

On the one hand, the argument is that 3168 is *not* widely deployed
when it comes to safety with existing AQMs, and on the other hand, it
*is* widely deployed when it comes to selection of the identifier. I
think this finally needs bringing up, maybe tomorrow.

We had a conversation late last year around instead making a
discontinuous upgrade to ECN/SCE by redefining ECT(0) to be the
identifier, and I spent some time thinking about it. It's not without
issues, but I wouldn't mind hearing other's thoughts on it before I
pollute it with mine.

Pete

> Regards,
> 
> // Steve
> 
> 
> 
> 
> _______________________________________________
> Ecn-sane mailing list
> Ecn-sane@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/ecn-sane