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

["Black, David" <[e-mail]>]

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]<mailto:[e-mail]>
----------------------------------------------------------------