[ih] Better-than-Best Effort

[touch at strayalpha.com]

Hi, Dave,

> On Aug 26, 2021, at 3:39 PM, Dave Crocker via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> Having not followed actual QOS work over the year, my naive brain wandered oddly, today with a thought about a semi-QOS approach.
> 
> The usual view is that it requires complete, end-to-end support. Massive barriers to adoption, at the least.

Absolute QoS does (ensuring 300 Mbps capacity), but relative QoS can be deployed as a layer on top of nearly anything — i.e., run RSVP in an overlay and you don’t get 300 Mbps per se, but that reservation would get twice the capacity of one reserving 150 Mbps on paths they share.

> I'm thinking that the long-haul infrastructure tends to have enough capacity that it usually isn't the source of latency.  It's the beginning and ending legs that do.

We do have some cases where that happens in the customer upload direction (bufferbloat), but I wonder if it’s more often in the aggregation network between the edge networks and the core. That’s the typical case I’ve seen for cable Internet, where the aggregation tree was designed assuming ratios that don’t match current transport protocol use. I have 200 Mbps cable over a WiFi LAN that can support 2.2Gbps, but I almost never see those capacities.

At the other side, I wonder too if there are overloads on the end systems more than the edge net.

> So what about a scheme that defines and provides QOS in those segments but not the long middle?  Cheaper, more implementable, and might give usefully-better performance.

Interesting question; FWIW, I don’t know if the edge is more agile than the core; AFAICT, they’re both susceptible to the same inertia and lack of consolidated oversight...

> Assuming that this idea is new only to me, I'm curious about reactions/history/etc.
> 
> d/
> -- 
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net

—
Joe Touch, temporal epistemologist
www.strayalpha.com