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

[Sebastian Moeller]

Hi Jonathan,

nice information about the competing schemes (and I do not consider my rant a proposed scheme ;) )

But looking at https://en.wikipedia.org/wiki/IEEE_802.11e-2005 I learn that AC_VO gets 1.5ms guaranteed TXOP (roughly air-time), AC_VI gets 3ms and BE and BK only get  a single MSDU. Even assuming this means an A-MSDU which as far as I can tell reaches up to 8K (in 802.11n, no idea about ac). If I do the math I see that from roughly 42 Mbps on AC_VO actually gets more airtime than BE and BK, AC_VI by the same logic reaches parity with BK and BE from 21 Mbps on. So for a well set up wifi net both VI and VO will get preferred media access and a larger bandwidth share, I hope I misunderstood something, but basically this means that the incentives to choose the correct AC shift with available bandwidth. So from speeds > 21 Mbp any client or AP should use AC_VI exclusively and above 42 AC_VO, or do I miss something here (can clients/STAs actually enforce their marking or does the AP call the shots)? Anyway, for me it seems that the whole IEEE 802.11e thing might contain dragons… (but most likely I simple do not grasp the beauty of 802.11e, for all I know it might actually be well-designed)


Best Regards
	Sebastian

On Jul 30, 2015, at 22:29 , Jonathan Morton <chromatix99 at gmail.com> 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
> 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
> 
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast