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 <[email protected]> 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 > [email protected] > https://lists.bufferbloat.net/listinfo/make-wifi-fast _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
