[ih] Better-than-Best Effort

[Scott O. Bradner]

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” 

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)

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

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