On Thu, 29 Nov 2018, Sebastian Moeller wrote:
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
"10 Gbit/s packet processor". Game over, again.
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*).
L4S proposes a separate queue for the L4S compatible traffic, and some kind of fair split between L4S and non-L4S traffic. I guess it's kind of along the lines of my earlier proposals about having some kind of fair split with 3 queues for PHB LE, BE and the rest. It makes it deployable in current HW without the worst kind of DDoS downsides imaginable.
The Internet is all about making things incrementally deployable. It's very frustrating, but that's the way it is. Whatever we want to propose needs to work so-so with what's already out there and it's ok if it takes a while before it makes everything better.
I'd like diffserv to work better, but it would take a lot of work in the operator community to bring it out to where it needs to be. It's not hopeless though, and I think https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-06 is one step in the right direction. Just the fact that we might have two queues instead of one in the simplest implementations might help. The first step is to get ISPs to not bleach diffserv but at least allow 000xxx.
-- Mikael Abrahamsson email: swm...@swm.pp.se _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
