Re: [tsvwg] draft-ietf-tsvwg-nqb, more questions

[Greg White <[e-mail]>]

Hi Sebastian,

Interoperability with existing WiFi equipment is an important aspect, since WiFi latency can be considerable. By default, many existing APs only support 4 priority queues, and thus it is not possible to meet all of the requirements of the NQB PHB (at least in this default configuration).  Nonetheless, it is possible to utilize two of the four queues in order to meet some of the requirements, and thus provide some of the benefits of the NQB PHB.  With proper configuration and/or policies, this can be done safely.  The final SHOULD is intended to address your concern about prioritization (since it results in segregation without prioritization). Absent this requirement (or the ability to comply with it operationally), the operator would need to consider (and perhaps limit) which applications are allowed to be marked as NQB.  This aspect isn't discussed in the draft, but I will add it based on your input.

Network operators understand the value of segregating NQB traffic on WiFi links, and will almost certainly select a DSCP in practice that achieves that goal.  Assigning a different DSCP in this draft would do nothing to prevent them from doing so.  Instead, what we need to do is clearly articulate how to make best use of the existing WiFi tools, and how to avoid conflicts. 

In existing RFCs, the IETF already recommends that video conferencing applications mark their traffic as either AF4x or CS4, all of which get mapped to AC_VI.  The remaining language in the NQB draft describes sparser flows than these.

Based on your comments, I attempted to remove all text that could be interpreted as recommending that high-data-rate traffic be marked NQB.  It appears that I missed one instance (in the Introduction it gives "interactive voice and video" as an example). Aside from this (which I can correct), I think the draft currently recommends that NQB only be used for sparse traffic.  That said, the section where this guidance is intended to be given is still lacking in specificity, and poses some open questions that may need to be addressed in a subsequent revision.

Best Regards,
Greg


On 11/4/19, 3:25 PM, "tsvwg on behalf of Sebastian Moeller" <[e-mail] on behalf of [e-mail]> wrote:

    Regarding https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/?include_text=1
    
    7.3.  WiFi Networks
    
       WiFi networking equipment compliant with 802.11e generally supports
       either four or eight transmit queues and four sets of associated EDCA
       parameters (corresponding to the four WiFi Multimedia Access
       Categories) that are used to enable differentiated media access
       characteristics.  Implementations typically utilize the IP DSCP field
       to select a transmit queue, but should be considered as Non-
       Differentiated Services-Compliant Nodes as described in Section 4 of
       [RFC2475].  As a result this document discusses interoperability with
       WiFi networks, as opposed to PHB compliance.
    
       As discussed in [RFC8325], most existing implementations use a
       default DSCP to User Priority mapping that utilizes the most
       significant three bits of the DiffServ Field to select "User
       Priority" which is then mapped to the four WMM Access Categories.  In
       order to increase the likelihood that NQB traffic is provided a
       separate queue from QB traffic in existing WiFi equipment, the 0x2A
       codepoint is preferred for NQB.  This would map NQB to UP_5 which is
       in the "Video" Access Category.
    
       Systems that utilize [RFC8325], SHOULD map the NQB codepoint to UP_5
       in the "Video" Access Category.
    
       In order to preserve the incentives principle, WiFi systems SHOULD
       configure the EDCA parameters for the Video Access Category to match
       those of the Best Effort Access Category.
    
    
    [SM] This last section is puzzling: if the wifi system configures AC_VI with EDCA parameters that match the AC_BE parameters, AC_VI ceases to be different from AC_BE, in that case picking a codepoint that automatically maps to CS0 and hence to AC_BE  seems much safer, simpler and straight forward to me. 
    Especially since essentially none of the millions deployed WiFi APs out there will a) have this configured like proposed already and b) none of the consumer APs I know actually allow to easily adjust EDCA parameters at all. I guess I must be missing something and would be delighted to be shown why the proposed text is the right thing.
    My take on this still is, if NQB traffic is sufficiently sparse using AC_VI can be justified, but without any rate limits this has the potential of being quite unfair to concurrent APs on the same channel (as well as the neighboring channels that overlap with the selected). 
    I do not want to sound alarmist, but given the number of cable-ISP WiFi-APs (as indicated by a SSID containing the ISPs name) in my city, I believe making sure that those APs will not basically start hogging most airtime seems the prudent thing to do. If there are sufficient backstops in place (like rate limiting or automatic down-marking if the traffic is not sparse enough) to avoid the described situation, I am all for it.
    
    The text probably should also openly discuss that in WiFi/WMM the four available queues by design have different priorities, and by moving NQB out of the default AC_BE while leaving QB flows in there, this effectively runs against  the following text in the draft: "The NQB queue SHOULD be given equal priority compared to queue-building traffic of equivalent importance." (leaving alone the question how an AP or a station is supposed to measure importance)
    
    
    Sebastian