Re: [Make-wifi-fast] [Cerowrt-devel] [tsvwg] Comments on draft-szigeti-tsvwg-ieee-802-11e

[Jonathan Morton <chromatix99@gmail.com>]

> https://datatracker.ietf.org/doc/draft-szigeti-tsvwg-ieee-802-11e/

> On the topic of the actual mappings....

Here’s a handy comparison table to show how the draft, CJ’s suggestions, and cake’s current implementation map DSCPs to traffic classes:

DSCP | SZ | CJ | Cake
---------------------
CS7  | XX | VO | VO
CS6  | ?? | VO | VO
EF   | VO | VO | VO
VA   | VO | VO | VO
CS5  | VI | VO | VO
AF4x | VI | VI | VI
CS4  | VI | VI | VO
AF3x | VI | BE | VI
CS3  | VI | BE | VI
AF2x | BE | BE | VI
CS2  | BE | BE | VI
AF1x | BK | BE | BE
DF   | BE | BE | BE
CS1  | BK | BK | BK
TOS4 | BE | BE | VI
TOS2 | BE | BE | BE
TOS1 | BE | BE | VI

Interesting to note that cake puts a lot more traffic in “high” classes than either of these suggestions.  I also note that cake does invert CS4 vs AF4x in a way that CJ doesn’t like - but perhaps this is mitigated by the fact that cake thresholds VI at three times the bandwidth as VO, which I think is appropriate since video consumes more bandwidth than voice (or games) traffic.

None of these suggestions make any practical distinction between the “drop probability” divisions within the AFxx classes - even though in some cases they are mapped to distinct UP values, these always fall into the same major class.  I suppose that distinction would be better left to an AQM algorithm that was aware of them, which cake is not since I can’t immediately see a way to make Codel respond reasonably to it.

The draft doesn’t address the “legacy” codepoints associated with the old TOS bits, but cake does, so I extended the table accordingly.

I couldn’t quite decipher Sebastian’s suggestions into table form, so I omitted those.

The major “dangerous” feature I see in the draft is the treatment of CS6 and CS7 traffic - long on “drop or remark” and short on “if you must, just stick it in VO".  CS6 in particular is used by common NTP implementations, and for good reason.  As far as I’m concerned, equipment should *not* remark or drop traffic by default based solely on its DSCP.  Indeed, equipment should probably assume they are not acting as the edge of a network domain unless specifically configured otherwise.

 - Jonathan Morton