[ih] Better-than-Best Effort

[Toerless Eckert]

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