[ih] Better-than-Best Effort

Louis Mamakos louie at transsys.com
Fri Aug 27 11:02:17 PDT 2021


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



More information about the Internet-history mailing list