[Cake] diffserv3 vs diffserv4

[David P. Reed]

+1000%
 
I believe the problem with diffserv arose at conception, because it violated the core idea of IETF's operation:
 
"rough consensus and working code"
 
It was clear very, very early( to everyone but those working on it!) that no working approximate implementation ever existed, nor could it!
 
Had someone proposed a single better-efforts category, whose implementation would be Autonomous System by Autonomous System defined by a scheme roughly equivalent to "Paris Metro Pricing", it would have afforded experience at scale. (In Paris Metro Pricing, there are two knds of cars on each train, First Class and Second Class. If you pay for first class, you get to go into the first class cars. Cars change from second to first class iff the seats in first class are tending to be full. Trains run more often when there are lines waiting for second class cars. The analogy with router decisions is should be clear, except since trains can't run more often, congestion is signaled by drop or marking, which means that second class packets would be dropped or marked unless there were no first class packets.)
 
But instead the designers ignored implementation entirely, and invented "wish-based" classes.
 
This also violated an end-to-end argument - you should only put "in the network" functions that can be completely *implemented* "within the network".
And the TOS/QOS idea isn't meaningful to routers.
 
On Friday, July 24, 2020 11:13pm, "Jonathan Morton" <chromatix99 at gmail.com> said:



> > On 24 Jul, 2020, at 6:56 pm, Justin Kilpatrick <justin at 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
> 
> _______________________________________________
> Cake mailing list
> Cake at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20200725/3d5654cf/attachment.html>