Re: [tsvwg] TSVWG: WG adoption of draft-white-tsvwg-nqb!

[Sebastian Moeller <[e-mail]>]

Hi Greg,

let me chime in...

> On Sep 5, 2019, at 01:01, Greg White <[e-mail]> wrote:
> 
> Thanks David.
>  
> On your item 3, could you clarify what you mean?   RFC 8325 does not discuss a “non queue building” service class, and so I don’t see a technical inconsistency between the NQB draft and RFC8325.  There has been some discussion on the list as to whether IETF should recommend that NQB be mapped to UP_6/AC_VO or UP_5/AC_VI, but in at least one of those cases where it was suggested to change the draft, the rationale for doing so was based on an incorrect assumption that NQB-marked traffic would by definition include capacity-seeking flows (e.g. L4S).  As I stated on list, I don’t have a problem with changing it to UP_5/AC_VI if that is the consensus.  But, the reason for mapping NQB to UP_6/AC_VO is so that both RFC8325 and “default mapping” 802.11 devices map EF, VA and NQB together to the same UP/AC, and so that both types of devices map these traffic types one AC level “higher” than elastic traffic sources (e.g. AF3x).  I’d like to see a more reasoned argument as to why NQB should be grouped with AF3x traffic as opposed to EF & VA before making a change.


Have a look at figure 1 on page 19-20 RFC 8325 (https://tools.ietf.org/html/rfc8325#page-19):

+-------------------------------------------------------------------+
  | IETF Diffserv | PHB  |Reference |         IEEE 802.11              |
  | Service Class |      |   RFC    |User Priority|  Access Category   |
  |===============+======+==========+=============+====================|
  |               |      |          |     7       |    AC_VO (Voice)   |
  |Network Control| CS7  | 
RFC 2474
 |            OR                    |
  |(reserved for  |      |          |     0       | AC_BE (Best Effort)|
  | future use)   |      |          |See Security Considerations-Sec.8 |
  +---------------+------+----------+-------------+--------------------+
  |               |      |          |     7       |    AC_VO (Voice)   |
  |Network Control| CS6  | 
RFC 2474
 |            OR                    |
  |               |      |          |     0       | AC_BE (Best Effort)|
  |               |      |          |    See Security Considerations   |
  +---------------+------+----------+-------------+--------------------+
  |   Telephony   |  EF  | 
RFC 3246
 |     6       |    AC_VO (Voice)   |
  +---------------+------+----------+-------------+--------------------+
  |  VOICE-ADMIT  |  VA  | 
RFC 5865
 |     6       |    AC_VO (Voice)   |
  |               |      |          |             |                    |
  +---------------+------+----------+-------------+--------------------+
  |   Signaling   | CS5  | 
RFC 2474
 |     5       |    AC_VI (Video)   |
  +---------------+------+----------+-------------+--------------------+
  |   Multimedia  | AF41 |          |             |                    |
  | Conferencing  | AF42 | 
RFC 2597
 |     4       |    AC_VI (Video)   |
  |               | AF43 |          |             |                    |
  +---------------+------+----------+-------------+--------------------+
  |   Real-Time   | CS4  | 
RFC 2474
 |     4       |    AC_VI (Video)   |
  |  Interactive  |      |          |             |                    |
  +---------------+------+----------+-------------+--------------------+
  |  Multimedia   | AF31 |          |             |                    |
  |  Streaming    | AF32 | 
RFC 2597
 |     4       |    AC_VI (Video)   |
  |               | AF33 |          |             |                    |
  +---------------+------+----------+-------------+--------------------+
  |Broadcast Video| CS3  | 
RFC 2474
 |     4       |    AC_VI (Video)   |
  +---------------+------+----------+-------------+--------------------+
  |    Low-       | AF21 |          |             |                    |
  |    Latency    | AF22 | 
RFC 2597
 |     3       | AC_BE (Best Effort)|
  |    Data       | AF23 |          |             |                    |
  +---------------+------+----------+-------------+--------------------+
  |     OAM       | CS2  | 
RFC 2474
 |     0       | AC_BE (Best Effort)|
  +---------------+------+----------+-------------+--------------------+
  |    High-      | AF11 |          |             |                    |
  |  Throughput   | AF12 | 
RFC 2597
 |     0       | AC_BE (Best Effort)|
  |    Data       | AF13 |          |             |                    |
  +---------------+------+----------+-------------+--------------------+
  |   Standard    | DF   | 
RFC 2474
 |     0       | AC_BE (Best Effort)|
  +---------------+------+----------+-------------+--------------------+
  | Low-Priority  | CS1  | 
RFC 3662
 |     1       | AC_BK (Background) |
  |     Data      |      |          |             |                    |
  +--------------------------------------------------------------------+

  Note: All unused codepoints are RECOMMENDED to be mapped to UP 0
  (See Security Considerations below)

       Figure 1: Summary of Mapping Recommendations from Downstream
                       DSCP to IEEE 802.11 UP and AC


draft-white-tsvwg-nqb defines the following characteristics for flows to qualify for NQB:

"There are many applications that send traffic at relatively low data rates and/or in a fairly smooth and consistent manner such that they are highly unlikely to exceed the available capacity of the network path between source and sink."
[...]
"These Non-queue-building (NQB) flows are typically UDP flows that send traffic at a lower data rate and don't seek the capacity of the link (examples: online games, voice chat, DNS lookups)"

To me this does not rule out relatively high bandwidth applications like (paced) video delivery over UDP.

Anyway the issue I see is that NQB lumps quite a few different traffic types into one category, and when mapping to AC's it seems prudent to not only look at the best case, but also at the average and worst cases as well.

So with video streams as valid NQB flows (@Greg if you believe streaming video not to qualify for NQB then the draft should mention that explicitly) the highest AC defensible according to figure 1 above is AC_VI. So can we please reduce the discussion to the only open question, does NQB qualify for AC_VI or AC_BE?

I argue that NQB will be used for "low latency data" flows, whether the current draft acknowledges that or not (in the end NQB has all the right trimmings for being the "L4S" dscp and I consider it highly unlikely that it will not be used as a cheap entry into the fast lane). And in that case, I believe the aggregate that is marked by NQB should only be marked AC_BE. 
Especially considering that in the egress direction stations will send NQB-marked packets and hence potentially hog air-time slots if using AC_VI/VO, before the queue protection of the router has any possibility to keep things in check.


	Sebastian

>  
> -Greg
>  
>  
>  
> From: tsvwg <[e-mail]> on behalf of David Black <[e-mail]>
> Date: Friday, August 30, 2019 at 9:41 AM
> To: "[e-mail]" <[e-mail]>
> Subject: [tsvwg] TSVWG: WG adoption of draft-white-tsvwg-nqb!
>  
> In the Montreal TSVWG meeting, there was a strong sense of the room that the TSVWG WG should adopt draft-white-tsvwg-nqb as a starting point for work on an NQB PHB.   The WG call for adoption on this list has been open for over a week, since August 21, and having seen only one objection on the list to adoption of the draft (from Dave Taht), the WG chairs (Gorry, Wes and David) have concluded that the WG rough consensus is to adopt this draft.  It’s important to emphasize that the draft is adopted as a *starting point* for TSVWG work, i.e., the current draft content does not represent the rough consensus of the WG.  Significant work will be required to produce an actual PHB spec that is suitable for implementation – see the recent RFC 8622 on the LE PHB (https://datatracker.ietf.org/doc/rfc8622/) for an example of what a PHB spec looks like.
>  
> There are a few items that will need attention before the initial -00 WG version of the NQB draft is submitted – these are to avoid confusion about what the WG intends to do:
> 1)      The draft needs to be clear that the use of the 0x2A DSCP value as the default for this PHB is a *suggestion by the authors that is subject to change*.  Whether to use that DSCP or a different one is a WG decision; the plan is to discuss and select the default DSCP value starting (and hopefully concluding) in September.
> 2)      The criticisms on this list of the “queue protection” requirement in the draft are largely accurate.   The draft needs at least an Editor’s Note that this material will be revised, as while the DOCSIS mechanism is an example of how to do queue protection, it is not appropriate to require implementation of that mechanism.   A plausible plan that I have discussed with the authors is to write a set of functional/behavioral requirements for NQB “traffic protection” that can be satisfied by a “queue protection” mechanism such as the DOCSIS mechanism, or by a suitably configured FQ AQM implementation.
> 3)      RFC 8325 reflects the IETF consensus on how to map between Diffserv and WiFi QoS, hence the 8.3 section of the NQB draft needs to be modified to be consistent with RFC 8325.
> 4)      Similarly, the 8.2 section of the NQB draft needs to be modified to reflect the conclusion of discussion on this topic in Montreal.
> Those 4 changes are necessary in the -00 WG version of the NQB draft.
>  
> In addition, related to item 2), my expectation (which is open to further discussion) that “traffic protection” will be a “MUST” requirement, perhaps with some well-specified exceptions (including explanations of why the exceptions are ok).   This is because “traffic protection” (e.g., “queue protection” or a suitably configured FQ AQM) appears to be necessary in general to keep queue-building traffic out of the NQB traffic aggregate, as allowing such traffic degrades the properties of the NQB PHB.
>  
> Thanks, --David (TSVWG co-chair, will be shepherd for NQB draft).
> ----------------------------------------------------------------
> David L. Black, Senior Distinguished Engineer
> Dell EMC, 176 South St., Hopkinton, MA  01748
> [phone] New    Mobile: [phone]
> [e-mail]
> ----------------------------------------------------------------
>