Re: [Bloat] incremental deployment, transport and L4S (Re: when does the CoDel part of fq_codel help in the real world?)

[Mikael Abrahamsson <swmike@swm.pp.se>]

On Thu, 29 Nov 2018, Jonathan Morton wrote:

> You are essentially proposing using ECT(1) to take over an intended function of Diffserv.

Well, I am not proposing anything. I am giving people a heads-up that the 
L4S authors are proposing this.

But yes, you're right. Diffserv has shown itself to be really hard to 
incrementally deploy across the Internet, so it's generally bleached 
mid-path.

> In my view, that is the wrong approach.  Better to improve Diffserv to 
> the point where it becomes useful in practice.

I agree, but unfortunately nobody has made me king of the Internet yet so 
I can't just decree it into existance.

>  Cake has taken steps in that direction, by implementing some reasonable 
> interpretation of some Diffserv codepoints.

Great. I don't know if I've asked this but is CAKE easily implementable in 
hardware? From what I can tell it's still only Marvell that is trying to 
put high performance enough CPUs into HGWs to do forwarding in CPU (which 
can do CAKE), all others still rely on packet accelerators to achieve the 
desired speeds.

> My alternative use of ECT(1) is more in keeping with the other 
> codepoints represented by those two bits, to allow ECN to provide more 
> fine-grained information about congestion than it presently does.  The 
> main challenge is communicating the relevant information back to the 
> sender upon receipt, ideally without increasing overhead in the TCP/IP 
> headers.

You need to go into the IETF process and voice this opinion then, because 
if nobody opposes in the near time then ECT(1) might go to L4S 
interpretation of what is going on. They do have ECN feedback mechanisms 
in their proposal, have you read it? It's a whole suite of documents, 
architecture, AQM proposal, transport proposal, the entire thing.

On the other hand, what you want to do and what L4S tries to do might be 
closely related. It doesn't sound too far off.

Also, Bob Briscoe works for Cable Labs now, so he will now have silicon 
behind him. This silicon might go into other things, not just DOCSIS 
equipment, so if you have use-cases that L4S doesn't do but might do with 
minor modification, it might be better to join him than to fight him.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se