[ih] Better-than-Best Effort

[Brian E Carpenter]

On 28-Aug-21 11:24, Jack Haverty via Internet-history wrote:
> Well, some of us actually foresaw the eventual need for management 
> mechanisms like a "Settlement Protocol".   For example, somewhere in the 
> late 80s I asked Cyndi Mills to drive an IETF activity on "Usage 
> Accounting", or something like that, so it would be possible as a first 

> step to actually gather data on usage of the net.   That led to things 
> like RFC 1272 (see https://sandbox.ietf.org/doc/rfc1272/ )
> 
> But "rough consensus" was the hurdle to jump, and anything that had the 

> taint of possible money issues involved was soundly suppressed by the 
> research community.   So as the Internet became a commercial 
> infrastructure, things like a "Settlement Protocol" were missing.
> 
> That's another piece of the Internet History of What Didn't Happen.

Interesting. I'd say that effort fell like a small rock into deep water
and was never seen again. Of course, there's been a lot of work on
measurement of all kinds since then, but mainly for operational purposes
and traffic engineering in particular. Usage-based charging, or at least
data caps, have crept in at the subscriber edge, but otherwise the
industry has gone in for capacity-based charging.

Settlements has always been a dirty word. After I posted
https://datatracker.ietf.org/doc/html/draft-carpenter-metrics-00
in 1996, I was taken off for a quiet lunch which turned into a
good roasting by a couple of *very* senior ISP folk. Why? They 
hated any talk of this topic because they were very concerned about
the Sherman Act.

   Brian

> 
> /Jack
> 
> 
> On 8/27/21 1:24 PM, 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”
>>
>> 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
> 
>