Quality of the internet

Thu Jun 18 12:46:19 UTC 2020

On 18/Jun/20 14:28, Saku Ytti wrote:

> ACK. Good Internet is almost an emergent feature, not something we
> really designed for. The main remaining problems are congested
> peerings, which is a silly political problem which ends up hurting
> customers and not helping anyone.

It's easier to keep selling bandwidth to people than to find another
model from which to make money. That, as network operators, is our fate :-).

> No one needs strict priority queues anymore, which was absolutely
> needed at one point in time.
>
> We are not in a market which cares about QoS,...

I was just thinking about this 2 years ago, when we sold more and more
IP services than anything else, despite a market with aggressive price
points, e.t.c., to the extent that while we still build all our nodes
with PHB-DSCP/EXP, with all the usual EF, AF, BE queues and 33% policing
on EF queues and LLQ forwarding on EF queues, and all the rest, in
practice, we don't really need them anymore.

We either over-provision capacity to the point where those QoS policies
never kick in, or (and more likely), all traffic is public Internet,
which lives in BE.

Basic policing/shaping/queueing of customer traffic at the edge is
pretty stable; we haven't needed a new QoS feature in that space for
over 8 years. So when vendors are trying to sell new line cards with
enhanced QoS scale, it makes me wonder. Unless it's for BNG deployments
where millions of customers need to be dumped in specific queues, which
isn't for us, and which I doubt many of the up-and-coming mom & pop FTTH
service providers can afford anyway.

>  yet our BE is globally
> <200us max jitter on a typical day and AF is <50us. Average jitter
> being under 10us. So if I'd have HW timestamping NTP server and
> client, I could synchronise clocks over IP transit cross continents to
> ten microsecond accuracy. I think this is pretty crazy. And I'm sure
> anyone who measures, measures similar numbers, this would have sounded
> scifi 20 years ago.
> As a context, Zoom recommends a jitter of 40ms or better, or 40000us.

Which is a good point.

Sitting at my house in Jo'burg, my Zoom calls are typically served out
of some data centre in Paris (161ms from my house) or Amsterdam (176ms
from my house). I've tracked this for months now, my jitter on Zoom
calls is 1ms - 2ms, steady.

The case for EF queues to deliver VoIP calls between a customer and PABX
sitting 1ms apart simply doesn't track anymore. Either the network
already does it due to all the over-engineering, or the traffic goes
over the Public Internet anyway as folk migrate for cost, convenience
and value reasons.

Mark.