Re: [tsvwg] tsw/ospa: Internet phone-in-QoS ?

[Jonathan Morton <[e-mail]>]

> On 15 Apr, 2020, at 12:44 pm, Sebastian Moeller <[e-mail]> wrote:
> 
> 	Wasn't the issue with RED, that it requires some tuning and nobody knows how to automate the tuning, and that it increases the RTT-dependent throughput inequality if flows of different RTTs share a congested hop?

That's why I specified WRED, which includes some automation of that tuning.  It's not great, but it's something.  Better algorithms exist, and should be used where available.

It's important to keep the scale of the problem in perspective.  Internet paths have a median of about 80ms RTT, baseline.  Adding a few milliseconds to that is no big deal, and a good AQM can keep the queue down to 5ms already.  An old AQM might only control the queue to a few tens of milliseconds, which is still basically acceptable.  But an uncontrolled FIFO is in the hundreds to even tens of thousands of milliseconds, depending on how cheap memory is for the vendor - and above about 2000ms, DNS just stops working.

> Well, currently ISPs have mostly zero control over bandwidth sharing at congested hops, so even equal fair sharing will be an improvement…

Correct for wireline, at least.  I've noticed my local 4G tower has low latency even when heavily congested, though, provided I keep my traffic shaped to below the share of airtime available to me.  So some ISPs manage to share bandwidth at bottlenecks, even if they don't implement AQM.

> Well, the challenge for anything "better" than N-tupel-fairness (with different N) requires to propagate per-packet-information to the potentially congested hops. I believe this is done with-in reason using diffserv markings and PHBs, but that does not scale to differentiating "entertainment or [...] critical functions" in a generic fashion.

I think the important point here is that reliably defining whose traffic is "more equal" than the rest - in the Animal Farm sense - is a Hard Problem, one that has been tackled many times over the years without any significant success.  It's also one that we don't even *need* to solve, as long as the "fair share" is sufficient to let the critical applications work.  In the example I gave, that is probably true.

It also has the benefit of keeping the masses entertained indoors, which in the current crisis is the critical factor for solving the wider problem sooner and with fewer casualties.

Diffserv and its ilk may then be useful for improving the utility of a *single* subscriber's service, working within that fair-share.  The important distinction is, that subscriber has the right to decide which of his own traffic is more important to himself.  He does not have the right to decide that his traffic is more important than his neighbour's.

 - Jonathan Morton