Re: [Cake] testing cake at 55mbit down/5mbit up

[Jonathan Morton <chromatix99@gmail.com>]

> On 5 May, 2015, at 22:43, Dave Taht <dave.taht@gmail.com> wrote:
> 
> the diffserv4 thing did not line
> up with the markings netperf-wrapper is using for the rrul test.

True, but neither does Wi-Fi QoS, which ignores the low-order DSCP bits and uses only the Precedence ones, with some re-ordering:

Precedence 0 & 3 go into BE,
           1 & 2 into BK,
           4 & 5 into VI,
           6 & 7 into VO.

Both CS5 and EF therefore fall into the VI (video) queue on Wi-Fi; only CS6 and above get the VO (voice) queue.  This doesn’t make much sense, which is probably one reason why I ignored that practice when setting up cake.

With cake, CS5 and EF both fall into the "voice" class; CS5 supposedly corresponds to “voice signalling”, which is why I put it there.  Cake’s “video” class is meant for applications which need reliable access to bandwidth (eg. streaming video) rather than especially low latency.

Here’s a summary of where all the well-known DSCPs end up on Wi-Fi and cake:

DSCP WiFi Cake
==== ==== ====
CS0   BE   BE  <- default
TOS1  BE   VI  <- max reliability (legacy)
TOS2  BE   BE  <- max throughput (legacy)
TOS4  BE   VI  <- min delay (legacy)
CS1   BK   BK  <- low priority
AF1x  BK   BE  <- high throughput
CS2   BK   VI  <- admin & management
AF2x  BK   VI  <- low latency data, ie. database
CS3   BE   VI  <- broadcast video
AF3x  BE   VI  <- multimedia streaming, ie. YouTube
CS4   VI   VO  <- realtime interactive, ie. games
AF4x  VI   VI  <- multimedia conferencing
CS5   VI   VO  <- signalling
VA    VI   VO  <- telephony with capacity reservation
EF    VI   VO  <- VoIP and games
CS6   VO   VO  <- network control, ie. NTP
CS7   VO   VO  <- network control, ie. routing

 - Jonathan Morton