[ih] Better-than-Best Effort

[Brian E Carpenter]

On 28-Aug-21 08:24, Scott O. Bradner via Internet-history 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” 
> 
> 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”

And so it's been since the beginning of time. One of my favourite memories is a meeting in Brussels around 1995 (effectively pre-web) when we, the 
science community, met with several PTTs to discuss our need for international 34 Mb/s links. I remember one of them saying "You can't possibly need that much bandwidth for a private network [i.e. the Internet], there are no applications that could ever need that." I think it was someone from Telecom Italia but they all agreed with him. Of course these were people who made a lot of their money via settlements and had no real concept of a connectionless network. I'm a bit shocked that BT still had people thinking that way as recently as the NGN hypefest.

As long as queuing theory holds and glass fibres are cheap, I am not sure 
much is going to change. 

   Brian

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