Re: [Cake] diffserv3 vs diffserv4

[Jonathan Morton <chromatix99@gmail.com>]

> On 24 Jul, 2020, at 6:56 pm, Justin Kilpatrick <justin@althea.net> wrote:
> 
> "sqm-scripts used 3 tiers of priority pretty successfully as does free.fr. - de-prioritization seems a good idea, prioritization not so much."
> 
> This is the best comment on why diffserv3 is the default that I could find on bufferbloat.net. I'm interested in hearing about what data (anecdotes welcome) lead to this conclusion.

In Cake, Diffserv4 maps conceptually (but not in detail) to the four priority buckets in Wifi - BK, BE, VI, VO.  In Diffserv3 the VI bucket is dropped, because Cake's flow isolation within BE is already good enough to give decent video streaming performance.  The BK and VO buckets are still useful to deal with certain specific problems; BK is the place to put "swarm" protocols which intend to be scavengers but which flow-isolation tends to prioritise, and VO is for latency-sensitive protocols which the user wants to specifically protect from random traffic fluctuations.

Thinking more broadly, I believe Diffserv would have been far more successful if it had replaced Precedence/TOS with a simple two-bit, four-way set of PHBs:

00: High Throughput - equivalent to traditional Best Effort service.

01: High Reliability - "Every Packet's Sacred".

10: Low Cost - a scavenging service for altruistic applications.

11: Low Latency - for the many protocols that are sensitive to delays more than throughput.

It may also have been reasonable to include a couple of extra bits for uses internal to an AS, on the understanding that the basic two bits would be preserved end-to-end as an indication of application intent.

Of the above four classes, Diffserv3 provides three - omitting only the High Reliability class.  But that is a class most useful within a datacentre, where it is actually practical to implement a lossless backplane with backpressure signals instead of loss.

What we *actually* have is a six-bit field with ill-defined semantics, that is neither preserved nor respected end-to-end, is consequently ignored by most applications, and consumes all the space in the former TOS byte that is not specifically set aside for ECN (a field which could profitably have been larger).  It is a serious problem.

Implementations of PHBs still tend to think in terms of bandwidth reservation (a Bell-head paradigm) and/or strict priority (like the Precedence system which was lifted directly from telegraphy practice).  Both approaches are inefficient, and go along with the misconception that if we can merely categorise traffic on the fly into a large enough number of pigeonholes, some magical method of dealing with the pigeonholes will make itself obvious.  However, both the easy, universal method of categorisation and the magical delivery strategy have failed to materialise.  It rather suggests that they're doing it wrong.

So that is why Diffserv3 is the default in Cake.  It offers explicit "low cost" and "low latency" service for suitably marked traffic, and for everything else the Best Effort service uses flow and host isolation strategies to maintain good behaviour.  It usually works well.

 - Jonathan Morton