[Ecn-sane] draft-white-tsvwg-nqb-02 comments

[Sebastian Moeller]

Dear tsvwg,

	[SM] I had a look at draft-white-tsvwg-nqb-02 and amongst other things I tripped over the following section


"8.3. WiFi Networks

WiFi networking equipment compliant with 802.11e generally supports either four or eight transmit queues and four sets of associated CSMA parameters that are used to enable differentiated media access characteristics. Implementations typically utilize the IP DSCP field to select a transmit queue.

As discussed in [RFC8325], most implementations use a default DSCP to User Priority mapping that utilizes the most significant three bits of the DiffServ Field to select User Priority. In the case of the 0x2A codepoint, this would map to UP_5 which is in the "Video" Access Category (one level above "Best Effort").

Systems that utilize [RFC8325], SHOULD map the 0x2A codepoint to UP_6 in the "Voice" Access Category."


	[SM] This is highly debatable! See RFC8325 for a description of the consequences of selecting AC_VO, in short AC_VO entails a considerable advantage of acquiring airtime (over all other ACs) that will immediately affect ALL users of the same channel (and nearby channels); that is all networks using that channel in the RF-neighbourhood, in addition AC-VO also seems to grant longer TXOP (airtime slots) than both AC_BK and AC_BE.
	Using AC_VO for any data flow that is not both reasonably low bandwidth and latency sensitive is rather rude and should not be enshrined in an IETF draft. As NBQ seems specifically designed to also allow for high bandwidth flows, AC_VO should be off-limits, as the consequences will not be restricted to the wifi network carrying the NQB flows. If a big data flow is abusing AC_VO it will effectively slow all other AC's traffic to a trickle and since wifi (currently) is mostly half-duplex it will also affect traffic in both directions.
	Let me try to phrase my objection in IETF conforming terms, this recommendation needs to be reconciled with the mapping recommendations in https://tools.ietf.org/html/rfc8325 for different types of traffic. I realize that this draft references RFC8325, but it clearly fails to understand the rationale for dividing different traffic types into different access classes due to the side-effects these classes have.

Best Regards
	Sebastian