[ih] Better-than-Best Effort

[Toerless Eckert]

On Fri, Aug 27, 2021 at 04:24:05PM -0400, Scott O. Bradner wrote:
> when the ITU-T was starting work on NGN, which assumed QoS that users would select & pay for, I said
> in a panel at the ITU “the Internet is not reliably crappy enough to drive that business plan” 

That IMHO very much depends on the actual application requirements

> specifically, the Internet works for VoIP (for example) too much of the time
> for anyone to be willing to pay extra for QoS that would only apply a small part of the time and would not deal. with many problems (like a tree falling & taking out your local access)

Counterpoints:

>From my experience, SPs that in the past decade migrated their own analog/digital
infrastructure to VoIP do use DiffServ to protect it and to be able to provide the
same flawless quality as they had in before. And of course, those SPs will never
offer such a DiffServ network option to any OTT voip provideer because QoS is one of
the few distinguishing aspects that an OTT can not easily clone. So with this data
point i would re-emphasize that i think business models and regulations for equal
access to nework services are a key challenge to enable use of better network services.

Besides: 90% of all TCP/IP use is not the Internet, but in limited domain networks, and
you will find a lot of QoS there, especially also when its being sold as managed services.
Its the fine-grained business model of Internet subscribers where so far no business
model evolved that would not compete with biger gains through siloed platforms such as
SP owned VoIP service (see above).

> the response from the BT person was “we are missing a TCP settlement protocol”

I thought we had that. In 2020, we had national politicans asking CEOs of content
streamers like Netflix to reduce streaming rates during Corona to allow more WFH productivity,
and i think tha was actually done for a few months by several countries in Network if i
remember correctly.

Does that count ?

Ok. Fun aside.

How do you call it when SPs need to do per-flow and per-subscriber policing of traffic 
to re-balance the unfairness introduced by a variability of aggressivness of deployed CCs, especially
those like torrents that easily eat bandwidth persistently like an ideal gas ? This type of overcoming
basic limitations of the end-to-end CC architecture of the Internet has been deployed by SPs
for a long time and is of course becoming ever more difficult to recreate the desired fairness
the more end-to-end encryption is used by application.

Why do we have BOFs for something like MADINAS ?

Cheers
    Toerless

> Scott
> 
> > On Aug 27, 2021, at 2:33 PM, Toerless Eckert via Internet-history <internet-history at elists.isoc.org> wrote:
> > 
> > Louis,
> > 
> > In that FGNET2030 document where i wrote a section of, one of the core
> > goals was to explicitly eliminate transit as an initial targe for QoS - because
> > we have to much experience (yours included) how difficult it is to figure
> > out not only what it could be, but then more importantly, how to finance it.
> > 
> > To answer the question what it could be: If i was an access provider, i would
> > like transit that can support to provide different relative bandwidths to different
> > subscriber flows within my aggregate that i am providing to you. For example
> > ensuring no-loss for < 10% of my aggregate, so it could carry low-loss traffic,
> > such as traditional voice. and the rest just for example that my gold-class
> > customers get 4 times as much bandwidth when there is contention than my lead-class
> > customers. So i can sell more differentiated service to my customers and have this
> > work across transit.
> > 
> > And we always failed in the way too complicated thought process in SPs about
> > the technologies required to monetize this. I saw this through when
> > inter-provider Inter-AS VPN was considered by SPs. Way too convoluted.
> > 
> > Cheers
> >    Toerless
> > 
> > On Fri, Aug 27, 2021 at 02:02:17PM -0400, Louis Mamakos wrote:
> >> On 26 Aug 2021, at 19:27, Toerless Eckert via Internet-history wrote:
> >>> 
> >>> Pessimistic as i am,
> >>> I think those business models will again, like we saw 20 years ago with
> >>> MPLS/VPN
> >>> evolve in isolated VPN/slices across the same infrastructure. And
> >>> because they
> >>> are driven by a small number of customers such as mobile operators,
> >>> industrial or public
> >>> services/traffic-control/power-distribution/... etc, we will just see a
> >>> proliferation of hacked-together
> >>> qos for one-off solutions. Like i have seen it in QoS in MPLS/VPN.
> >>> Managemenet
> >>> of Queue weights by FAX messages between customer and subscriber is my
> >>> favourite common hack.
> >>> 
> >>> As an ex-colleague-liked to say: www.showmethemoneyforqos.com
> >> 
> >> Around 1999-2000 while I was at UUNET, I recall having conversations with
> >> some
> >> of the marketing people about building some sort of QoS product or feature
> >> into the
> >> Internet transit service that we sold.  I asked them what their expectations
> >> (or
> >> really, what the customer's expectations) would be of such a product?  Would
> >> it:
> >> 
> >> - produce an obvious, demonstrable, differentiated level of performance on
> >> an
> >>  on-going basis?
> >> - or, was it an insurance policy?
> >> 
> >> If you're selling IP transit, the best-effort service can't suck too much
> >> because
> >> competition in the marketplace.  You probably can't get by with even a 1% or
> >> 2%
> >> packet loss rate for best-effort delivery vs. a premium offering.  So what
> >> would
> >> the differentiated QoS offering bring?  We already sold different size
> >> bandwidth
> >> pipes..  A few percent packet loss across your backbone wasn't acceptable;
> >> it was
> >> a capacity problem to be solved.
> >> 
> >> What about as an insurance policy?  We already offered a 100% availability
> >> SLA to
> >> customers.  Not because they wanted to collect a refund; they just wanted it
> >> to work.
> >> It was to demonstrate the confidence in the reliability of our platform.  So
> >> the
> >> "insurance policy" against the thing we said wasn't going to happen?
> >> 
> >> And then of course, as much as you'd like to believe you had all the
> >> important
> >> customers on your network, how was some sort of QoS performance commitment
> >> supposed
> >> to work over peering interconnects?  We had all sort of backed into
> >> settlement-free
> >> peering interconnects and it wasn't at all clear how multiple classes of
> >> traffic
> >> was going obviously fit into that model.
> >> 
> >> I'm a customer of Internet transit these days, and I have no idea how I'd
> >> buy a
> >> QoS product if the problem I'm trying to solve is reaching a segment of
> >> customers
> >> defined by "everywhere on the Internet."
> >> 
> >> Louis Mamakos
> > 
> > -- 
> > ---
> > tte at cs.fau.de
> > -- 
> > Internet-history mailing list
> > Internet-history at elists.isoc.org
> > https://elists.isoc.org/mailman/listinfo/internet-history

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