[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