Subject: Re: [tsvwg] Some comments on NQB (part 2)

From: Greg White <[email-masked]>
Date: Mon, 4 Apr 2022 21:03:06 +0000

I’d like to come back to this topic to see if we can find a resolution to it.  After the meeting, I received an off-list comment from an engineer representing a large AS / ISP, with the comment that it would be better (in his opinion) if the draft didn’t actively discourage end-to-end usage of the value 45.  I wonder if there is a wording that would make everyone happy here (he says, hopefully).

Regarding the paragraph that discusses re-marking 45 to 5 prior to interconnection, how about something along the lines of:

To support NQB, networks MUST preserve a DSCP marking distinction between NQB traffic and Default traffic when forwarding via an interconnect from or to another network. Networks that support NQB SHOULD support the ability to re-mark NQB traffic prior to such an interconnection.  It is RECOMMENDED that interconnecting networks negotiate the use of the DSCP value 45 to indicate NQB traffic across their interconnections (thus avoiding the need to re-mark traffic), however, local DSCP usage by either network could require the use of a different value.  To be clear, interconnecting networks are not precluded from negotiating (via an SLA, TCA, or some other agreement) a different DSCP than 45 to use to mark NQB traffic across an interconnect. In situations where negotiation of a DSCP between interconnection partners is infeasible, networks that support NQB SHOULD NOT use the value 45 for NQB at network interconnects, but rather SHOULD remap NQB traffic to DSCP 5 prior to interconnection.  This is intended to facilitate the default treatment of NQB traffic in backbones and core networks discussed in the previous section (where it is possible that IP Precedence may still be deployed).  Additionally, the fact that this PHB is intended for end-to-end usage does not preclude networks from mapping the NQB DSCP to a value other than 45 or 5 for internal usage, as long as the appropriate NQB DSCP is restored when forwarding to another network.

The above would be a replacement for this paragraph:
https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-10.html#section-4.3-2

-Greg

From: tsvwg <[email-masked]> on behalf of Gorry Fairhurst <[email-masked]>
Date: Friday, March 18, 2022 at 1:23 PM
To: "[email-masked]" <[email-masked]>
Subject: [tsvwg] Some comments on NQB (part 2)

2) I have been reflecting on the text in 4.3, largely because I have prodded to think what DSCPs can still be assigned for useful work.

There are some aspects of this text that still concern me, and I think this revolves around the use of which key words are used with which actions around the DSCPs. I don't think this is hard, but

2a)  advocates remarking 45 to 5 at the edge
 "To facilitate the default treatment of NQB traffic in backbones and core networks discussed in the previous section (where IP Precedence may be deployed), networks that support NQB SHOULD NOT use the value 45 for NQB at network interconnects unless that usage is explicitly documented in the TCA (Traffic Conditioning Agreement, see [RFC2475<about:blank?compose#RFC2475>]) for that interconnection."

- I want to know if the SHOULD is considered important? The impact is that this draft recommends remarking to deploy NQB. I now that some paths/policies might have this result anyway and aggregate all traffic with the same high-orde 3-bit values.

2b) The section has text that goes on to talk about  ToS-based precedence:

Furthermore, in other network environments where IP Precedence ([RFC0791<about:blank?compose#RFC0791>]) is deployed, it is RECOMMENDED that the network operator re-mark NQB traffic to DSCP 5 in order to ensure that it is aggregated with Default traffic.

- is that remarking necessary to achieve the goal of being aggregated with Default traffic? or could it be optional when it leaves the edge?

- to me this practice is deprecated, so why would the IETF perpetuate that? - would the WG consider to just call these networks out as taking a non-standards approach.

2c) And in balance, advocates remarking 5 to 45 at the edge:

In order to enable interoperability with WiFi equipment as described in Section 8.3.1<about:blank?compose#wifi_interop>, networks SHOULD re-mark NQB traffic (e.g. DSCP 5) to DSCP 45 prior to a customer access link, subject to the safeguards described below and in that section.

- This is also in-network re-marking, which we should consider carefully, (e.g. when the edge is not clearly formed).

Perhaps we could try and make sure we are on the same same page this meeting?

Best wishes,

Gorry

---

From: Sebastian Moeller <[email-masked]>
Date: Tue, 5 Apr 2022 00:26:02 +0200

So here is a question:

is it really justified to request both DSCPs 45 and 5 if both are intended for pretty much exactly the same use-cases? IMHO that sounds like a somewhat wasteful use of relative sparse resources... As I have argued in the past the tools and methods* are already available to make DSCP5 work for both network traversal as well as SAFE roll-out of NQB in WiFi networks (by defaulting to side-effect free use of the default AC_BE unless the WiFi gear has already been updated for NGB to treat DSCP 5 differentially according to the NQB recommendations).

I do not accept  the "ease of deployment argument" for DSCP 45 as valid. NQB will have different properties from EF as used currently and so it is far from clear whether the few common users of AC_VO/VI mapping DSCPs will actually switch to NQB, UNLESS NQB actually offers something over EF and in that case NQB simply needs to be compelling enough to make them switch... 

Regards
	Sebastian

*) as part of IEEE standards no less, see e.g. in 9.4.2.95 QoS Map element in e.g. IEEE Std 802.11-2016, this seems to be designed for the use-case at hand: to configure APs and connected stations to use a non-standard DSCP to AC mapping, which effortlessly will allow to treat DSCP5 with the desired NQB properties over WiFi, be that map DSCP5 to AC_VI or optionally to any other AC with modified EDCA parameters (which according to "10.2.4.2 HCF contention based channel access (EDCA)" might also be "programmed" for the Stations from the AP if the Hybrid coordination function (HCF) is used, not sure how realistic this capability is for deployed stations, new NQB-enabled APs sure could require and use such capabilities).

@Jerome, could I respectfully ask for your expert opinion on whether my reading of the IEEE standard here is correct or not, please?

> On Apr 4, 2022, at 23:03, Greg White <[email-masked]> wrote:
> 
>  "To facilitate the default treatment of NQB traffic in backbones and core networks discussed in the previous section (where IP Precedence may be deployed), networks that support NQB SHOULD NOT use the value 45 for NQB at network interconnects unless that usage is explicitly documented in the TCA (Traffic Conditioning Agreement, see [RFC2475]) for that interconnection."
> 
> Furthermore, in other network environments where IP Precedence ([RFC0791]) is deployed, it is RECOMMENDED that the network operator re-mark NQB traffic to DSCP 5 in order to ensure that it is aggregated with Default traffic.
> 
> In order to enable interoperability with WiFi equipment as described in Section 8.3.1, networks SHOULD re-mark NQB traffic (e.g. DSCP 5) to DSCP 45 prior to a customer access link, subject to the safeguards described below and in that section.
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 6 Apr 2022 08:32:13 +0100

On 05/04/2022 00:26, Sebastian Moeller wrote:
> So here is a question:
>
> is it really justified to request both DSCPs 45 and 5 if both are intended for pretty much exactly the same use-cases?
> IMHO that sounds like a somewhat wasteful use of relative sparse resources... As I have argued in the past the tools and methods* are already available to make DSCP5 work for both network traversal as well as SAFE roll-out of NQB in WiFi networks (by defaulting to side-effect free use of the default AC_BE unless the WiFi gear has already been updated for NGB to treat DSCP 5 differentially according to the NQB recommendations).
>

I agree that the DSCP assignemnets is something that might be 
considered, registering DSCP 5 is a decision that needs to be weighed 
carefully, other DSCPs could potentially be aggregated to this be a 
remarking that bleaches the top 3 bits of the DSCP.

DSCP 45 appears easier to register, in that it would have less 
implications on later DSCP registrations.

If we register two DSCPs we should think carefully about how to describe 
and work with DSCP 5 - so that it is also clear what the difference is 
between 5 and 45.

Gorry

---

From: "Jerome Henry (jerhenry)" <[email-masked]>
Date: Wed, 6 Apr 2022 16:36:15 +0000

Hi Sebastian,

You are 100% correct on the interpretation of 802.11. Clause 9.4.2.95. It is widely used (for example in Wi-Fi Alliance Passpoint/Hotspot, or Optimized Connectivity Experience), and it allows the AP to be configured with, and send to all associated stations, a map of DSCP values and their associated UP value. The map does not dictate which type of traffic should use DSCP value  (however, there is a Wi-Fi Alliance program, OCE QoS Management R2, that allows an AP to program a STA to do just that, apply specific DSCP values to specific flows), but it does tell the STA which UP should be used for a given DSCP value.

Take care

Jerome

From: Sebastian Moeller <[email-masked]>
Date: Monday, April 4, 2022 at 6:26 PM
To: Greg White <[email-masked]>
Cc: Gorry Fairhurst <[email-masked]>, [email-masked] <[email-masked]>, Jerome Henry (jerhenry) <[email-masked]>
Subject: Re: [tsvwg] Some comments on NQB (part 2)
So here is a question:

Regards
        Sebastian

---

From: Greg White <[email-masked]>
Date: Wed, 6 Apr 2022 23:04:42 +0000

Sebastian,

For the reasons discussed in the draft, as well as the reasons I explained in my earlier response to you on this topic (https://mailarchive.ietf.org/arch/msg/tsvwg/fBcm6eUfv9egmlo-TX8N3OAFM_A/), and additionally for the reasons that Gorry mentions below, the value 45 is advantageous for use by applications to mark NQB traffic.  Please go back and re-read my earlier response, since I think it explains that part of the rationale well.  

The question we've been discussing is how strongly to recommend re-marking to another IANA assigned value 5 at interconnections.  For that, I think it would help to have input from ASes and maybe IXPs.  What I offered for consideration below was that the value 45 be recommended across interconnections in cases where the two interconnecting partners are NQB-aware and they negotiate DSCP markings.    In other cases (maybe the other network is NQB-unaware, or the other network is unknown(?)) an NQB-aware network should re-mark NQB traffic to 5 in order to increase the likelihood that it a) passes through the other network with a differentiating DSCP intact, and b) that it receives default treatment in any NQB-unaware network that it traverses.  But, this is different from what we'd discussed previously, which was that 45 was recommended for use at the edge, and 5 was recommended for use across all interconnects, and all NQB-aware networks would be recommended to re-mark between those two values. 

I'm interested in hearing feedback from the WG on whether or not this new language results in a better outcome overall.  

While the DSCP space is certainly limited (there are only 64 values, 16 of which are reserved for local use, 23 of which are already assigned in the IANA registry, leaving 25 currently unassigned), we're not in real danger of running out of them any time soon.

The data from Ana Custura and Gorry indicates that, unless something changes in regards to bleaching of the upper 3 bits by some networks, any future assignments of the values 13, 21, 29, 37, 53, 61 would do well to keep in mind that any traffic so marked could end up being aggregated with NQB traffic.  That said, this sort of bleaching is non-compliant with the definition of the DSCP field, and is already problematic for EF, VA, and all of the CS codepoints (which aggregate in incompatible ways), so (as was commented in the last meeting) we may want to consider identifying the routers that continue to do this, and try to work with the associated network operators to change the behavior. 

-Greg

On 4/6/22, 1:32 AM, "Gorry Fairhurst" <[email-masked]> wrote:

    Gorry

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 7 Apr 2022 14:27:10 +0000

On 4/6/22, 19:05, "tsvwg on behalf of Greg White" <[email-masked] on behalf of [email-masked]> wrote:

> The question we've been discussing is how strongly to recommend re-marking to another IANA assigned value 5 at interconnections.  For that, I think it would help to have input from ASes and maybe IXPs.  What I offered for consideration below was that the value 45 be recommended across interconnections in cases where the two interconnecting partners are NQB-aware and they negotiate DSCP markings.

[JL] I took a look at marking across our interconnects again this morning. I see essentially zero packets marked DSCP 45. So it seems like if an access network was marking from the user edge as DSCP 45 then it'd be easier & simpler to carry DSCP 45 end-to-end, without the need to remark to DSCP 5. Not remarking at domain borders to me will mean less complexity, which means less chance of technical error, faster time to diagnose & repair, better resiliency, etc.

[JL] I then looked at DSCP 5 usage and see some usage - *but* on a Mbps basis it is essentially zero traffic relative to overall volume. In addition, the large majority originates from a single AS (easily fixed it would appear).

> The data from Ana Custura and Gorry indicates that, unless something changes in regards to bleaching of the upper 3 bits by some networks, any future assignments of the values 13, 21, 29, 37, 53, 6…

[JL] +1 on working with any such networks to correct this. I'm sure it dates to some long ago network decision - maybe related to router processing constraints that no longer exist or some other long-forgotten requirement/assumption/constraint - and so perhaps there may now be an opportunity to modernize things.

[JL] Regarding the suggested language, simpler is better IMO (I'm writing a network integration guide for L4S experiments so been giving thought to how to provide simple instructions). Perhaps something like:

When using NQB:
- Networks MUST preserve a DSCP marking distinction between NQB traffic and Default traffic across interconnections.
- Networks SHOULD mark NQB traffic with the DSCP value 45 (at the edge).
- Networks MAY instead use another DSCP value other than 45 internally, as needed.
- Networks SHOULD use the DSCP value 45 for NQB traffic across interconnections (which should avoid the need to re-mark).
- Optionally, two interconnected networks MAY instead agree to use DSCP value 5, such as in cases when one of those two networks is using the DSCP value 45 for another purpose within their network domain and is originating traffic with DSCP value 5.

Said another way:
1 - DSCP value 45 is recommended both within and between networks.
2 - Networks can also use a different DSCP value within their networks. If they use a different DSCP value, they should remark to DSCP value 45 at interconnections.
3 - While networks should use DSCP value 45 across interconnections as the default, on a limited as needed basis due to existing usage of DSCP value 45 within a network, then the networks may use DSCP value 5.

Jason

---

From: <[email-masked]>
Date: Mon, 11 Apr 2022 15:21:30 +0000

Jason,

I'm responsible for the QoS configuration of one of the backbones looking at any traffic received with a DSCP starting with 101 xxx at interconnections without an SLA in place as undesired. 
-   I don't know what a sender intends to signal to me by a DSCP  in range 101 xxx and 
    unless there's an SLA, I will protect my backbone from traffic which can potentially 
    be misclassified (please read https://datatracker.ietf.org/doc/rfc8100/ for a deeper 
    discussion). That means: rewrite it to 000 xxx.
-   If you look for a PHB offering some advanced form of default transport, my 
    preference (and recommendation) is to use a DSCP 000 xxx. I'd appreciate a standard 
    determining any picked DSCP (and reserve a small range of DSCP for advanced PHBs 
    requiring no more than default PHB in the backbone and at interconnection).
     If the desired PHB is desired for one of our access products, it'll take little time to make 
     that operational. As our access node is a QoS policy point anyway, changing a DSCP is 
     commodity there.
-   To the extent I recall it, DSCP 45 has been suggested to deal with old WiFi gear which 
    will never support L4S in its lifetime. I'm not happy with a design basing advanced 
     standards on limitations of old, outdated technology.
-   And I also think that this isn't a good justification for a first standard end to end DSCP too.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: tsvwg <[email-masked]> Im Auftrag von Livingood, Jason
Gesendet: Donnerstag, 7. April 2022 16:27
An: Greg White <[email-masked]>; [email-masked]
Betreff: Re: [tsvwg] Some comments on NQB (part 2)

When using NQB:

Said another way:

Jason

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 11 Apr 2022 09:40:29 -0700

On Mon, Apr 11, 2022 at 8:23 AM <[email-masked]> wrote:
>     be misclassified (please read
https://datatracker.ietf.org/doc/rfc8100/ for a deeper
>     discussion). That means: rewrite it to 000 xxx.

Please forgive an ignorant question from a lurker in the audience.

Is there a reason why these are not bleached to 000 000? Isn't that what
RFC 2475 and RFC 8100 recommend, if such remarking is done?

Mike Heard

---

From: <[email-masked]>
Date: Wed, 13 Apr 2022 08:27:34 +0000

Mike,

The original intent is to allow for a limited QoS transparency – with the least significant bits.

My personal judgement as of today:

  *   That doesn’t make too much sense, if the result is 000 xxx, as it interferes with using 000 xxx for useful (standard) extensions of backbone default transport & differentiated access/home network service.
  *   That is useful, if there’s an SLA in place and aaa xxx is remarked to bbb xxx (an example is with an AF PHB – that’s where RFC 8100 is providing a fair benefit)
  *   If TSV WG opts to revise DiffServ RFCs, I’d appreciate some text on re-marking practice and some guidance, and that may include a recommendation to rewrite (NOT 000 xxx) to 000 000.

I’m ready to discuss that also internally, if DiffServ standardization heads a (from my point of view) useful way regarding assignment of DSCPs in range 000 xxx. Without that, it’s not my number one priority – TSV WG consent for a useful way to assign standard DSCPs in range 000 xxx for PHBs which can cope well with default transport at interconnection and in backbone-networks, I’ll make that a priority.

Regards,

Ruediger

Von: C. M. Heard <[email-masked]>
Gesendet: Montag, 11. April 2022 18:40
An: Geib, Rüdiger <[email-masked]>
Cc: Jason_Livingood=[email-masked]; [email-masked]
Betreff: Re: [tsvwg] Some comments on NQB (part 2)

Mike Heard