Hi Mikael,
> On Nov 29, 2018, at 08:46, Mikael Abrahamsson <swm...@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: swm...@swm.pp.se
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
