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

[Sebastian Moeller <[e-mail]>]

Hi Greg,


> On Sep 6, 2019, at 19:18, Greg White <[e-mail]> wrote:
> 
> Hi Ruediger,
>  
> Many networks can (and do) configure the DSCP to PHB mappings and policies in accordance with their own intended usage.  In particular, DOCSIS links and LTE links (likely others as well) can be configured in a manner that complies with the PHB definition.  In other cases, it may be either necessary or sufficient (or both) to support NQB traffic without fully complying with the PHB (of course this isn’t new with NQB).
>  
> One of the high level goals is to ensure that the benefits of differentiating NQB traffic are not lost when that traffic traverses a WiFi link (since in many of the target use cases it does).  WiFi gear will likely not support all of the aspects of the PHB definition (at least current equipment will not).  We are essentially limited to 4 queues (BK, BE, VI, VO) and their associated CSMA parameters.  An additional constraint that we’re faced with is that in many cases the mapping from DSCP to AC is essentially fixed – it is either operationally hard or impossible to change.
>  
> Of the WiFi APs that we’ve tested (a sample of current generation .11ac devices, covering several chipsets) 100% of them use the “default mapping” of DSCP to AC as follows.
>  
> DSCP
> WMM Access Category
> 001xxx, 010xxx
> Background (AC_BK)
> 000xxx, 011xxx
> Best Effort (AC_BE)
> 10xxxx
> Video (AC_VI)
> 11xxxx
> Voice (AC_VO)
>  
> Living within this constraint, and trying to make the best of it, we’ve selected as a default DSCP the 0b101010 value, which would get mapped into the Video Access Category (along with CS4, AF41, AF42, AF43, CS5, VA, EF).  This would ensure that, in large part, NQB traffic is handled in a separate queue from the queue-building bulk data traffic (the vast majority of which uses AC_BE or AC_BK).


	[SM] To summarize, if we can be sure that NQB traffic does NOT contain any of the following traffic types

 |    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      |      |          |             |                    |
  +--------------------------------------------------------------------+

then AC_VI can be considered in agreement with https://www.rfc-editor.org/rfc/rfc8325.txt, otherwise your only option is AC_BE. 
Really, if you decide to label a set of diverse flows with one identifier, then for wifi scheduling purposes you must restrict yourself to the lowest priority access class of any of the possible members of your set. If you dislike this, define and enforce your set, such that all members fulfill the rfc8325 requirements.
Just to be clear, e.g. DNS traffic which you seem to give as a candidate for NQB "(examples: online games, voice chat, DNS lookups)" falls explicitly into the OAM category in rfc8325 and hence does not justify AC_VI or AC_VO, so either exclude DNS from NQB or restrict yourself to AC_BE.

In the light of the default dscp to AC mapping this directly implies that the selected codepoint 0x2A is NOT SUITABLE as dscp for NQB, you need to restrict yourself to a dscp out of the AC_BE set (000xxx, 011xxx)

Sidenote, since rfc8325 are the normative IETF recommendations for dscp to ieee 802.11 ACs recommending both AC_VI amd AC_VO in section 8.3 of the draft makes little to no sense.


@chairs, do you agree with my interpretation of the rfc8325 requirements?

Best Regards
	Sebastian




>  
> I would not expect that it would be important for NQB marked traffic to be differentiated in core network switches or routers, which in many cases do not provide deep (10’s to 100’s of ms) buffers.  So, in these switches NQB would likely be treated the same as Default (or whichever local use codepoint is used for best effort).
>  
> A characteristic of the NQB PHB as implemented in DOCSIS is that it provides low latency, low latency variation, and low loss for an NQB marked flow as long as the flow is “well behaved”.  If an NQB-marked flow is not well behaved then it experiences greater latency variation, greater loss, and potential re-ordering.   A well behaved flow is one that does not materially cause queue build-up in the network, i.e. its instantaneous rate does not materially exceed the instantaneous available bandwidth of the path.
>  
> In managed networks, or in cases where SLAs are provided, it seems to me that an operator should determine whether traffic that is already in a defined service class would benefit from being further differentiated based on QB vs NQB behavior (like, as you suggested using various AF marks), or whether certain existing service classes can be grouped into QB vs NQB meta-classes, depending on the technology limitations at each hop (MPLS, Ethernet, WiFi, LTE, DOCSIS, etc).  The result of this determination could require the use of non-default (i.e. non-standard) marking of NQB traffic in some cases.
>  
> -Greg
>  
>  
> From: "[e-mail]" <[e-mail]>
> Date: Thursday, September 5, 2019 at 2:03 AM
> To: Greg White <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>
> Subject: AW: [tsvwg] TSVWG: WG adoption of draft-white-tsvwg-nqb!
>  
> Hi Greg,
>  
> the policy of the company I work for is: EF marked traffic received on a peering interface is remarked. DiffServ traffic destined to a retail access is subject to admission control, if that traffic is not expected to experience congestion. 
>  
> The latter might change with high-speed access links. If the users and the above traffic have a hard time congesting these access links, the admission control requirement may not be strictly required.
>  
> If NQB traffic is supposed to be sent to third parties without an SLA at peering links being in place, proper selection of the DSCP matters. Without a deeper thought, a DSCP 000xx1 may be a proper choice in that case. Without an SLA being in place, the forwarding to be expected is default forwarding. If NQB is supposed to define a default-like behavior for a serious traffic share, it should be marked by a DSCP in the range 000 xxx at interconnection.
>  
> If an SLA is expected to be in place at peerings, any traffic without admission control should face a higher packet drop probability if destined to a retail access, than admission controlled traffic. If I assume the admission controlled traffic to be marked AFx1, NQB traffic in the same queue should be marked AFx2 (or AFx3). I’m open to discuss queue depths and expected traffic properties for a suitable AF class. RFC 8100 proposes to specify DSCPs only at interconnection. That may be a starting point, should SLAs on NQB at peerings be within commercial scope (that’s a non-technical issue, of course).
>  
> The choice of a DSCP for traffic which is created and terminated within a single domain doesn’t need to specified – here the PHB specification is important and the behavior of that traffic in the presence of traffic from other PHBs. I’d again opt for AFx2 or AFx3 (hoping that the NQB PHB specification allows for a useful implementation suiting AFx1 and NQB traffic in the same queue, expecting both to expect no congestion, AFx1 traffic to be admission controlled if present and NQB having features to reduce bandwidth if congestion is imminent). 
>  
> I’m not sure what is expected from a backbone network supporting NQB (and other DiffServ PHBs). MPLS supports 8 traffic classes or codepoints, respectively. This coding space includes the codepoints required for ECN (codepoints, not bits).
>  
> I appreciate more standard DSCPs based on a clear and consented definition of the corresponding PHBs. Default marking, LE, EF and Network Management are good examples.
>  
> My take – sorry if I misunderstood some of your design aims, should that be the case.
>  
> Regards,
>  
> Ruediger
>  
> Von: tsvwg <[e-mail]> Im Auftrag von Greg White
> Gesendet: Donnerstag, 5. September 2019 01:02
> An: Black, David <[e-mail]>; [e-mail]
> Betreff: Re: [tsvwg] TSVWG: WG adoption of draft-white-tsvwg-nqb!
>  
> 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.
>  
> -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]
> ----------------------------------------------------------------