Cake - diffserv3 - DSCP - How badly are liars/outliers punished

[Wistuplu]

Dear Forum members,

Cake relies among others on DSCP to assign packets to priority tins (Cake uses the "tin" word. I see those as priority queues.) To discourage DSCP "liars", some sort of trade-off is built-in to ensure that priority tins get some disadvantages together with the benefits.

For the general idea of a trade-off, see "Enforcing that trade-off in this manner should encourage applications to choose an appropriate DSCP for their traffic, rather than lazily applying the highest available priority for “maximum” performance." , at https://www.bufferbloat.net/projects/codel/wiki/CakeTechnical/. For some details, see Cake man page, among others:

To avoid perverse Diffserv marking incentives, tin weights have a "priority sharing" value when bandwidth used by that tin is below a threshold, and a lower "bandwidth sharing" value when above. Bandwidth is compared against the threshold using the same algorithm as the deficit-mode shaper.

Merlin 386.2 has diffserv3 as default. It allows giving priority to Audio calls (if your VoiceOverIP equipment properly tags packets, e.g. with DSCP EF, as mine does). By the way, Audio calls don't use much bandwidth.

If e.g. traffic from Microsoft Teams or Zoom, including potentially video, is also "manually" tagged as EF, one risks exceeding the threshold for the priority tin of diffserv3, which is defined as 1/4 of the bandwidth. It might be a non-issue on symmetrical links with high speeds. I am on DOCSIS with highly asymmetrical link, currently 6.5 Mbps up; and sometimes 2 concurrent Teams video sessions, so 1/4 is approx. 1.6Mbps and might be exceeded by 2 Teams sessions in real life, which might make that traffic of mine appear as "liar/outlier".

I'd like to discuss the potential drawback of tagging Teams as EF in diffserv3. And an alternate approach.

First, I am aware that the threshold in Cake is not "hard". So, e.g. "Audio" traffic will still be sent anyway, however, it will be somehow "demoted in priority" (https://www.bufferbloat.net/projects/codel/wiki/CakeTechnical/). I don't know/understand exactly how/how much, but it is probably in a way that "liars/outliers" are slightly penalized.

Alternatively, I am considering using diffserv4, which uses 50% as the threshold for the Video tin (the second best priority), and 25% for the Audio tin (the highest priority). I would then tag Teams as CS3, which will bring the packets to the Video tin. (Truth be told, because I am possibly lazy (and maybe pragmatic), in practice, I would probably start by tagging ALL outgoing upstream UDP as CS3.)

I'm pretty sure the impact would be subtle anyway, so, I'm happy to discuss the "theory" of the incentive/punishment for respecting the cake threshold of each tin; and simple ideas related to tagging.

By the way, besteffort probably works just fine, but that leaves the fun of discussing/experimenting/understanding out ;-)

Best regards
W.

FYI, extract from tc -s qdisc with my current settings (diffserv4 and 6.5Mbps up):

                Bulk          Best Effort  Video        Voice
  thresh        416Kbit     6656Kbit     3328Kbit     1664Kbit
  target         43.7ms          5ms       5.46ms       10.9ms
  interval        139ms        100ms        100ms        106ms

EDIT:
PS: diffserv3 is actually the default of cake itself, not an "exotic" choice of Merlin:
https://www.man7.org/linux/man-pages/man8/CAKE.8.html
https://elixir.bootlin.com/linux/latest/source/net/sched/sch_cake.c#L2702

 

[Morris]

Each tin will act as it's won besteffort. If not oversubscribed all but file transfers will work just fine. File transfers with the wrong DSCP tag may go a little faster yet all other traffic will still get through. If oversubscribed life is never good yet this will just mess it up differently.