Re: [tsvwg] NQB: Use of DSCP 45

[[e-mail]]

Hi Sebastian,

I don't favour new standards making design choices _mainly_ to deal with out-of-date gear. Out-of-gate to me is something, which no longer dominates by the time of standardisation and is definitely slowly diminishing, but may be present with ever shrinking numbers for years to come. I don't say, ignore such gear, but I also don't want to make such gear main focus for design choices of a new standard.

Regards,

Ruediger

 

-----Ursprüngliche Nachricht-----
Von: Sebastian Moeller <[e-mail]> 
Gesendet: Mittwoch, 5. Januar 2022 09:39
An: Geib, Rüdiger <[e-mail]>
Cc: Black, David <[e-mail]>; [e-mail]
Betreff: Re: [tsvwg] NQB: Use of DSCP 45

Hi Ruediger, list


> On Jan 5, 2022, at 08:29, <[e-mail]> <[e-mail]> wrote:
> 
> Hi David,
>  
> I agree to your proposal related to point [1].
>  
> Points [2] and [3]: I think to recall that there has been a discussion whether upcoming IETF transport standards should be built around out-of-date and never-to-be-updated WiFi HW related to some other issue in the past. I fail to recollect, whether and what consensus was reached.

	[SM] Just to understand your point, do you consider the selection of DSCP decimal 45 (selected to exploit the default WMM DSCP to AC mapping) as building NQB around "out-of-date and never-to-be-updated WiFi HW" or as a clean way forward that would be selected in a non-legacy world as well?


Side-note: I believe that the WiFI fq_codel/airtime fairness patches in OpenWrt's Ath9K, Ath10k, ans mt76 drivers actually demonstrate how to properly implement something like the desired NQB behavior on existing devices. Equitable scheduling (ES) seems to fulfill NQB's desired network treatment much better than any flavor of prioritization, and in a way that is based on observed behavior instead of arbitrary classifiers that can and will be gamed.

Regards
	Sebastian



>  
> Regards,
>  
> Ruediger
>  
> Von: tsvwg <[e-mail]> Im Auftrag von Black, David
> Gesendet: Dienstag, 4. Januar 2022 17:15
> An: [e-mail]
> Betreff: [tsvwg] NQB: Use of DSCP 45
>  
> In catching up on emails, I've reviewed the discussion of NQB usage of DSCP 45 (0x2D), mostly between Greg and Sebastian.  Writing as draft shepherd, I think that there are several issues in that discussion that deserve broader WG attention, one of which I think I understand and two that I definitely do not fully understand.
>  
> [1] Use of DSCP 45 (0x2D) for NQB at network interconnections (the one that I understand).
>  
> There are a number of things that could go wrong if DSCP 45 is used for NQB traffic at network interconnections because DSCP 45 results in better forwarding treatment than DSCP 0 for Default (best effort) traffic in many networks.
>  
> The draft currently says that DSCP 45 SHOULD NOT be used at network interconnects via SHOULD requirements to remap it to DSCP 5.  I don't think that's sufficient, and hence suggest strengthening that text based on the Diffserv Architecture (RFC 2475):
> 	• Define DSCP 45 for NQB as a "local use" codepoint, based on the definition of "local use" in RFC 2474 and RFC 2475.
> 	• Explicitly prohibit use of DSCP 45 at network interconnects unless that usage is explicitly documented in the TCA (Traffic Conditioning Agreement, see RFC 2475) for that interconnection.
> 		• The change here would be from the current "SHOULD remap for interconnection" to "MUST NOT use for interconnection unless explicitly allowed by the TCA for that interconnection."
> This would also help clarify the IANA considerations for NQB DSCPs– DSCP 5 would be the single default DSCP for NQB, with a note added to the IANA registry that DSCP 45 is available for local use under the conditions specified in the NQB PHB RFC.
>  
> Overall, I don't think this proposed approach departs significantly from the intended usage (mostly non-usage) of DSCP 45 for network interconnection, and I think it results in significantly clearer text in both the draft and the IANA registry.
>  
> [2] Interaction of DSCP 45 with standards-compliant vs. legacy WiFi equipment.
>  
> The crucial rationale for use of DSCP 45 for NQB is this sentence in Section 8.3.1 of the NQB draft:
>  
>    In order to increase the likelihood that NQB traffic is provided a
>    separate queue from QB traffic in existing WiFi equipment that uses
>    the default mapping, the 45 code point is recommended for NQB. 
>  
> I don't understand the long-term intent here.  Is it that DSCP 45 will be used for WiFi for the foreseeable future or that DSCP 45 will be supplanted by DSCP 5 as WiFi gear gets upgraded?  If the latter, there are a plethora of problems in figuring out whether or not the WiFi gear is upgraded or not.  What's the intent here?
>  
> On a related note, I agree with Sebastian that this paragraph in Section 8.3.1 is unrealistic:
>  
>    Furthermore, in their default configuration, existing WiFi devices
>    utilize EDCA parameters that result in statistical prioritization of
>    the "Video" Access Category above the "Best Effort" Access Category.
>    If left unchanged, this would violate the NQB PHB requirement for
>    equal prioritization, and could erode the principle of alignment of
>    incentives.  In order to preserve the incentives principle for NQB,
>    WiFi systems SHOULD configure the EDCA parameters for the Video
>    Access Category to match those of the Best Effort Access Category.
>  
> I'm not even sure that IETF ought to be standardizing requirements on WiFi EDCA parameters, as those would seem to be for IEEE 802 to prescribe, not IETF.
>  
> FWIW, I have a worked example of that paragraph being unrealistic, as I recently bought a couple of basic WiFi APs off of eBay to solve some local problems (e.g., wife's tablet was not reliably connecting to WiFi from the other end of the house), and those APs don't have a consumer-accessible interface for configuring EDCA parameters.
>  
> I suspect that the above 8.3.1 paragraph needs to be bit-bucketed, but I don't understand what to do about WiFi and DSCP 45 in general.
>  
> [3] End-system use of DSCP 45
>  
> Section 4.1 of the draft says:
>  
>    Applications that align with the description of NQB behavior in the
>    preceding paragraphs SHOULD identify themselves to the network using
>    a Diffserv Code Point (DSCP) of 45 (decimal) so that their packets
>    can be queued separately from QB flows.
>  
> That strikes me as just plain wrong, as it inflicts DSCP 45 on non-WiFi gear.
>  
> OTOH, I don't know what to do here, as this sort of simple guidance (always do <X>) is crucial to get application developers to use this sort of new functionality.
>  
> Thanks, --David
>  
> David L. Black, Sr. Distinguished Engineer, Technology & Standards 
> Infrastructure Solutions Group, Dell Technologies mobile +1 
> 978-394-7754 [e-mail]