Diffserv8 vs Diffserv4/3 inconsistencies

[RubenKelevra]

I'm currently doing some work on the man page and noticed that diffserv8 is implemented differently than diffserv3/4 in terms of bandwidth and quantum settings. I'm not sure if that is really intentionally. While the two background classes in Diffserv8 get's a very low bandwidth share set in Diffserv3/4 and a low quantum, the opposite is the case in Diffserv8.

Bandwidth

Traffic-Class	Diffserv3-Prio	Diffserv3	Diffserv4-Prio	Diffserv4	Diffserv8
Network Control	High	25%	Very High	25%	39.26%
Minimum Latency	High	25%	Very High	25%	44.87%
Interactive Shell	High	25%	High	50%	51.28%
Low Latency Transactions	High	25%	High	50%	58.61%
Video Streaming	Mid	100%	High	50%	66.99%
Bog Standard	Mid	100%	Mid	100%	76.56%
High Throughput	Low	6.25%	Low	6.25%	87.50%
Background Traffic	Low	6.25%	Low	6.25%	100%

Quantum (set in the cakeconfig* functions)

Traffic-Class	Diffserv3-Prio	Diffserv3	Diffserv4-Prio	Diffserv4	Diffserv8
Network Control	High	256	Very High	256	98
Minimum Latency	High	256	Very High	256	113
Interactive Shell	High	256	High	512	130
Low Latency Transactions	High	256	High	512	149
Video Streaming	Mid	1024	High	512	171
Bog Standard	Mid	1024	Mid	1024	196
High Throughput	Low	64	Low	64	224
Background Traffic	Low	64	Low	64	256

[RubenKelevra]

Btw as it's not explained in the man page: How does the “bandwidth” per tin work?

The source code documents:

The priority queue operates according to a weighted DRR scheme, combined with
a bandwidth tracker which reuses the shaper logic to detect which side of the
bandwidth sharing threshold the tin is operating.  This determines whether a
priority-based weight (high) or a bandwidth-based weight (low) is used for
that tin in the current pass.

But sorry, I just can't understand it without further explanations. How will the bandwidth setting per tin affect the traffic?

• Is this an upper limit and traffic in this tin can't use more bandwidth.
• Is this kind of the “minimum” bandwidth and traffic in this tier get this bandwidth guaranteed if lower tins send also a lot of data.

[dtaht]

I'm sorry, could you add the actual codepoint to your above table?

It's been a really long time since I thought seriously about the design choices we made. One thing I felt strongly about was the need to fix the priority inversion that CS1 represents in a strict precedence setup common in 2003, (and still today), when it had been redefined to mean "background" around then. Later on I kind of gave up on making CS1 behave (it's prioritized on switches over CS0, and deprioritized on wifi), and embraced the LE codepoint.

I don't know what you mean by diffserv?-prio in this table.

What you are describing could be a mistake, or intentional, i mostly advocated for adoption of the diffserv3 layout of these priorities as they most closely matched wondershaper (2002), and more recently diffserv4 (more bandwidth for videoconferencing). I asked the list to look at it.... in cake, all forms of traffic can borrow, so even background traffic can use 100% of the bandwidth if no other traffic is present.

[chromi]

On 22 Dec, 2022, at 10:13 pm, @RubenKelevra @.***> wrote:

How does the “bandwidth” per tin work? Is this a hard limit and traffic in this tin can't use more bandwidth? Or is this kind of the “minimum” bandwidth and traffic in this tier get this bandwidth guaranteed if lower tins send also a lot of data?

It's basically the latter "guarantee" model, but not purely so. More precisely, a tin has one priority (in the form of a round-robin weighting) to deliver traffic at rates up to and including its own bandwidth threshold, and a different priority (weighting), usually much lower, above that threshold.

In Diffserv3 and Diffserv4, the "background" tin is implemented using a high below-threshold priority relative to the "best effort" tin, but a low bandwidth threshold. In Diffserv8, both priorities are low and (IIRC) equal, while the bandwidth threshold is high since it no longer plays a role. Both approaches ensure that background traffic is not starved, but doesn't interfere much with more important traffic. Using the bandwidth threshold mechanism theoretically has a latency benefit over using only the weighting, but it might be difficult to measure in practice.

I'll say that Diffserv3 and Diffserv4 got significantly more attention and testing in the later stages of CAKE's development. Practical use of Diffserv in a home-networking context is just not fine-grained enough to justify 8 tins; it's much better suited to 3, one each for low-latency, high-throughput, and altruistic traffic types.

• Jonathan Morton