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

[Simon Barber <simon@superduper.net>]

On 7/30/2015 1:29 PM, Jonathan Morton wrote:
>> 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
CS4 is for videoconferencing and gaming - this involves bursts of data 
much larger than pure voice traffic. Putting this in VO will prevent 
real pure voice traffic being able to achieve truly low latencies. I 
would also suggest lowering the priority of CS5.
> AF3x | VI | BE | VI
AF3 is for elastic flows - like TCP, so will use all available 
bandwidth. VI has significantly higher priority over the air than BE, so 
will starve other BE flows. This should be BE at most.
> CS3  | VI | BE | VI
> AF2x | BE | BE | VI
> CS2  | BE | BE | VI

> AF1x | BK | BE | BE
AF1 is described as bulk traffic, and not latency sensitive - in an 
attempt to achieve some prioritization I believe it should be put in a 
lower AC than BE, so that BE has some meaningful priority above bulk 
transfers. I think the draft has it right here.
> 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.
Problem is - cake is not operating on other WiFi flows on overlapping 
WiFi networks - only EDCA is giving priority there.
>
> 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
>
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast