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

[Michael Welzl]

> On 29 Nov 2018, at 08:46, Mikael Abrahamsson <swmike at swm.pp.se> wrote:
> 
> 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.

Rumours, rumours. Just like "SCTP can never work", all the Internet must run over HTTP, etc etc.

For the "DiffServ is generally bleached" stuff, there is pretty clear counter evidence.
One: https://itc-conference.org/_Resources/Persistent/780df4482d0fe80f6180f523ebb9482c6869e98b/Barik18ITC30.pdf
And another:  http://tma.ifip.org/wp-content/uploads/sites/7/2017/06/mnm2017_paper13.pdf


>> 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.

Well, for what you want (re-ordering tolerance), I would think that the LE codepoint is suitable. From:
https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-06
"there ought to be an expectation that packets of the LE PHB could be excessively delayed or dropped when any other traffic is present"

... I think it would be strange for an application to expect this, yet not expect it to happen for only a few individual packets from a stream.


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

+1


> 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.

Indeed I think that the proposal of finer-grain feedback using 2 bits instead of one is not adding anything to, but in fact strictly weaker than L4S, where the granularity is in the order of the number of packets that you sent per RTT, i.e. much higher.


> 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.

Yes...

Cheers,
Michael