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

[Sebastian Moeller <moeller0@gmx.de>]

Hi Mikael,


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

	With your kind of clue, I would happily vote you as (temporary) king of the internet. ;)

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

	As far as I can tell intel is pushing atom/x86 cores into its docsis SoCs (puma5/6/7) as well as into the high-end dsl SoCs (formerly lantiq, https://www.intel.com/content/www/us/en/smart-home/anywan-grx750-home-gateway-brief.html?wapkw=grx750), I am quite confident that those also pack enough punch for CPU based routing at Gbps-rates. In docsis modems these are already rolled-out, I do not know of any DSL modem/router that uses the GRX750


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

Call me naive, but the solution to the impasse at getting a common definition of diffserv agreed upon is replacing all TCP CC algorithms? This is replacing changing all endpoints (and network nodes) to honor diffserve with changing all endpoints to use a different TCP CC. At least I would call that ambitious.... (unless L4S offers noticeable advantages for all participating without being terribly unfair to the non-participating legacy TCP users*).

Best Regards
	Sebastian


*) Well, being unfair ad out-competing the legacy users would be the best way to incentivize everybody to upgrade, but that would also be true for a better diffserve scheme...

> 
> -- 
> Mikael Abrahamsson    email: swmike@swm.pp.se
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat