[ih] Better-than-Best Effort

[Toerless Eckert]

On Fri, Aug 27, 2021 at 03:49:04PM -0700, touch--- via Internet-history wrote:
> 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.

Very much agree with the concept of relative bandwidth allocation.
RSVP is a bit of a red herring here because not only does it not have
the concept of relative, it also does not have the concept of variable
(we did once start multi-TSPEC in TSVWG but never finished it). And
ultimately contention based relative weight are a matter of AQM and CC.

RFC8698 has the concept of weighted CC, allowing flows to get
differentiated bandwidth. DPS has weighting in AQM (that could
be integrated with RSVP). I am sur there are many other example
not well explored because its such a big gap between great idea
and actual adoption, especially when its not only affecting hosts.

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

The main issue is inelastic traffic, such as classical VoIP with video
(not very common anymore), when it tries to get more of a links
equal share - and that link is loaed with many more TCP flows. How
common or uncommon that situation is so highly deployment dependent,
so many folks may never get into it and think QoS is never required...

Cheers
    Toerless

> 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
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history

-- 
---
tte at cs.fau.de