Re: [tsvwg] WGLC: draft-ietf-tsvwg-nqb-14, closes 21 November 2022

[[e-mail]]

Hi Greg,

the NQB draft does not clearly specify what is to be done. If the draft needs to be crisp and clear, under which conditions a packet may be forwarded by DSCP 101101 to a home network. It doesn’t help, if there’s a DOCSIS implementation doing a rewrite. Rewriting the DSCP of offending traffic (packets or flows) to DSCP default by requirement language must be part of draft NQB (and reading the whole spec, a discard option should be offered too by this text). This is a general internet standard track document. Pointing to some DOCSIS standard or implementation is inappropriate, draft NQB must specify safe implemention and operation of NQB as a stand alone doc on these important aspects.

Regards,

Ruediger

Von: Greg White <[e-mail]>
Gesendet: Donnerstag, 24. November 2022 00:09
An: Geib, Rüdiger <[e-mail]>; [e-mail]; [e-mail]
Cc: [e-mail]; David.Black=[e-mail]
Betreff: Re: [tsvwg] WGLC: draft-ietf-tsvwg-nqb-14, closes 21 November 2022

Ruediger,

Specifically for DOCSIS equipment, a per “Service Flow” DSCP overwrite function exists (and has existed for 20+ years). Since the Queue Protection function in LLD redirects packets from the Low Latency Service Flow to the Classic Service Flow, it wasn’t deemed necessary to introduce another feature to perform the same function.  Instead, CableLabs maintains a Technical Report providing guidance for cable network operators on the configuration of the LLD feature.  In that TR, it is recommended that the Classic SF in upstream and downstream overwrite the DSCP with the value 0 (which is actually nothing new, since operators very commonly use that feature to bleach the DSCP on the single SF that exists today).  So, the result of this is that (in both directions) packets that exceed the QP thresholds are reclassified to the Classic SF and the DSCP is bleached to 0.

In my suggested text below for the legacy WiFi (unmanaged networks) case, I had explicitly listed re-marking excess traffic to Default as an outcome of a traffic policer/shaper.  I am not opposed to making the same recommendation for a traffic protection mechanism in that scenario.  Would that address your concern?

More broadly, the NQB draft already does list that “some networks may prefer to police the application of the NQB DSCP at the ingress edge, so that in-network traffic protection is not needed”.  It sounds like you would like to see more discussion of this option in the draft.  Am I reading you correctly on that?

But, as the queue protection draft indicates, congestion is (typically) a localized matter, and for purposes of reclassifying traffic in an NQB node, congestion is usually more accurately detected where it happens. So, my preference is to keep this (i.e. local traffic protection) as the main recommendation, and offer other forms of policing as secondary options.

-Greg



From: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, November 23, 2022 at 3:31 AM
To: Greg White <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "David.Black=[e-mail]<mailto:David.Black=[e-mail]>" <David.Black=[e-mail]<mailto:David.Black=[e-mail]>>
Subject: AW: [tsvwg] WGLC: draft-ietf-tsvwg-nqb-14, closes 21 November 2022

Dear colleagues,

I just read into https://datatracker.ietf.org/doc/html/draft-briscoe-docsis-q-protection-06#section-5.5 of the “queue protection” ID, end of that section:

In these 'persistent offender' cases, QProt might
also overwrite each redirected packet's DSCP or clear its ECN field
to Not-ECT, in order to protect other potential L4S queues
downstream.

I read that as to say the queue protection forwarding by default PHB is a local decision and the DSCP of a flow offending the NQB queue protection remains as is, while locally being forwarded by default PHB. That means, offending NQB traffic is forwarded marked by DSCP 101101 to WiFi, to be scheduled AC_VI there.
I do not look at the NQB draft as belonging onto standards track. I do not look at the draft as being ready for WGLC.

My take for a standard is, IF and only IF a non-L4S NQB flow passes a required queue-protection and is classified as not causing congestion by that queue protection, THEN it should be marked DSCP 101101. This just requires adding a remarking capability to the existing specification (which is a basic DiffServ functionality).

Regards,

Ruediger


Von: Greg White <[e-mail]<mailto:[e-mail]>>
Gesendet: Dienstag, 22. November 2022 22:33
An: Bless, Roland (TM) <[e-mail]<mailto:[e-mail]>>; Geib, Rüdiger <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; David.Black=[e-mail]<mailto:David.Black=[e-mail]>
Betreff: Re: [tsvwg] WGLC: draft-ietf-tsvwg-nqb-14, closes 21 November 2022

See below, marked [GW].


From: tsvwg <[e-mail]<mailto:[e-mail]>> on behalf of "Bless, Roland (TM)" <[e-mail]<mailto:[e-mail]>>
Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT)
Date: Monday, November 21, 2022 at 11:57 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "David.Black=[e-mail]<mailto:David.Black=[e-mail]>" <David.Black=[e-mail]<mailto:David.Black=[e-mail]>>
Subject: Re: [tsvwg] WGLC: draft-ietf-tsvwg-nqb-14, closes 21 November 2022

Hi Rüdiger,

sorry for the delayed reply, I'm currently on a business trip. Please see inline.

On 17.11.22 at 12:48 [e-mail]<mailto:[e-mail]> wrote:

you aren’t editor or author of the NQB draft. I still like to address you, as you are working or at least have been working with WiFi scheduling.
Actually, I haven't been working with WiFi scheduling, so I'm not the desired expert here.

To me, the idea of NQB reads similar to the EF PHB.  As NQB as of yet picks it’s DSCP to deliberately enable prioritized forwarding by WiFi, I think, traffic management as specified by EF applies. I’m referring to the deprecated text of EF here, which doesn’t carry quantitative requirements, but nevertheless seems helpful.

[GW] To be clear, the NQB DSCP was deliberately chosen to enable separate queuing from default traffic in legacy WiFi networks.  As the draft indicates (and as has been discussed extensively on this mailing list), the fact that (by default) that also gives priority in those networks is an unfortunate side effect which results in some challenges.

https://datatracker.ietf.org/doc/html/rfc2598#section-2

The following are my thoughts ( I don’t specify NQB or L4S, I hope not be wrong on L4S ):


1.       What I think applies to NQB too: the NQB scheduler departure rate MUST at all time intervals be above NQB arrival rate – and to me, a policer MUST ensure that.

So, in general you are right that for the NQB queue to be empty in average and provide low loss,
low delay, low jitter service for the flows, the departure rate must be strictly larger than the aggregate's
arrival rate. I'm actually missing a hint in the draft stating what happens if too many NQB flows enter
the queue causing overload. So this can only be prevented or enforced by policing (and admission
control). However, the way I read the draft, it is probably assumed that the traffic load and traffic usage pattern
is probably known by the provider at this part of the access network, so that there is the assumption that
this will not happen.

[GW] NQB is not a guaranteed low latency service, so I don’t think that the MUST statements above are appropriate. The draft currently recommends implementing a “traffic protection” method rather than a traditional rate policer, and the section where it is discussed (5.2) only talks about issues caused by individual flows.  I agree that we can (and probably should) say more around aggregate traffic management in certain cases.


2.       As long as NQB isn’t clearly delineated from L4S, to me it shouldn’t cause L4S ECT 11 marks – i.e., NQB MUST ensure random collisions only with L4S by appropriate sending behaviour and policing too.

3.       Then my take is, that the NQB rate-limit should be between 30% and 50% of the L4S scheduler bandwidth, if I apply EF dimension suggestions for NQB and look at the L4S queue as what’s termed “line rate” by the EF draft.

4.       Traffic above that rate to me should be marked for default forwarding (and I suggest to set ECT 11 in addition, without prior investigation of the ECT value – to deal with the yet unspecified co-scheduling of NQB with L4S).

[GW] IIRC it would not be compliant with RFC3168, RFC8311 or ECN-L4S-ID to CE mark Not-ECT packets.


Assuming L4S to receive 50% of the bandwidth available for all default traffic, then NQB would be policed to  [0,3 … 0,5] * 0,5 = 15% to 25% of the overall default traffic.

My questions to you:

5.       would a traffic share of 15% (to 25%) of AC_VI downlink traffic as compared to traffic scheduled for default enable somewhat fair and useful WiFi operation at least under many or most operational conditions? Meaning single up to half a dozen terminals on a single WLAN which operates with almost full spectrum.

6.       Looking at https://datatracker.ietf.org/doc/html/rfc8325#section-6.2.3 , AC_BE seems to have around 10% chance of getting access to WiFi scheduling as compared to AC_VI, that’s why I’d prefer 15% as an NQB/Default traffic share guidance. Is that making sense?

[GW] FYI, all else being equal, the AC_VI:AC_BE scheduling ratio is more like 4.5:1. That said, I would think the concern is mainly around the case where the ISP could police NQB traffic somewhere in their network (e.g. a CMTS or BRAS) and doesn’t have visibility into the WiFi network bandwidth. So, we’d be mainly worried about situations where the WiFi bandwidth is significantly less than the access network rate.   As a result, 15% seems sort of high to me. Maybe 5% would be better?



7.       Are there operational conditions of WiFi, when NQB deployment isn’t recommended (as a non expert, I thought about multi-terminal WiFi, like a hot-spot, or locations, where the spectrum of many unmanaged WLANs overlap).

8.       As I’m not an expert on WiFi, please add important aspects that I’m not aware of.

I’m asking you these questions since this is a standards track RFC and I feel uncomfortable with the level of guidance offered by it so far for secure and reliable operation. I don’t expect things to be watertight, I’m interested in an operation which wouldn’t cause the network provider hotlines to experience a massive increase in calls, once NQB is enabled.

I agree that the draft could give more operational guidance in this respect.

[GW] For the case that you are concerned about here (downlink traffic from an ISP entering a network containing WiFi gear) I am open to providing more guidance than we currently have.  The current guidance is the following:
1)      The WiFi gear SHOULD carry NQB traffic in a separate queue in AC_BE
2)      If the above isn’t possible in certain equipment, then the WiFi network SHOULD be configured such that AC_VI is equal in priority to AC_BE.
3)      If the above aren’t possible or the conditions are unknown, then:
a.       ISP SHOULD take precautions to prevent issues caused by prioritization of excessive and/or mismarked NQB traffic
b.       ISP equipment SHOULD bleach NQB by default (so that any pass through of NQB is intentional)
c.       As an alternative to bleaching, ISP could deploy traffic protection or policing, for example policing NQB traffic to a set fraction of the interconnection data rate, with excess traffic either being dropped or sent as default.

This part 3c it seems is where more specific guidance is wanted.

Here is a proposal for consideration:
As an alternative to re-marking, the operator could deploy a traffic protection (see Section 5.2<https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-14.html#traffic_protection>) or a shaping/policing function on NQB-marked traffic that minimizes the potential for negative impacts on Default traffic.  In the case that a traffic policing function or a rate shaping function is applied to the aggregate of NQB traffic destined to such a downstream domain, the policer/shaper rate SHOULD be set to either 5% of the interconnection data rate, or 5% of the typical rate for such interconnections, whichever is greater, with excess traffic being either dropped or re-marked and classified for Default forwarding.  A traffic policing function SHOULD allow approximately 100 ms of burst tolerance (e.g. a token bucket depth equal to 100 ms multiplied by the policer rate). A traffic shaping function SHOULD allow approximately 10 ms of burst tolerance, and approximately 50 ms of buffering.

In addition to this text, I think that the text around appropriate sender behavior should indicate that the 1 Mbps limit is given in the context of today’s networks “where access network data rates are typically on the order of 100 Mbps” i.e. the upper limit is approximately 1% of “typical” access network speeds.  Thus, the shaper/policer rates above work out to ~5 simultaneous maximum-rate NQB streams on access network segments that are less than the “typical” rate, and more such streams on higher rate access network segments.

Thoughts?

Greg





Regards,

 Roland





Von: tsvwg <[e-mail]><mailto:[e-mail]> Im Auftrag von Black, David
Gesendet: Mittwoch, 2. November 2022 04:47
An: tsvwg IETF list <[e-mail]><mailto:[e-mail]>
Betreff: [tsvwg] WGLC: draft-ietf-tsvwg-nqb-14, closes 21 November 2022


This email announces a TSVWG Working Group Last Call (WGLC) on:



A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services

draft-ietf-tsvwg-nqb-14

https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/



This draft is intended to become a Proposed Standard RFC.



This WGLC will run through the end of the day on Monday, November 21.

The WG will meet in London on Monday, November 7, while this WGLC

is in progress.



Comments should be sent to the [e-mail]<mailto:[e-mail]> list, although purely

editorial comments may be sent directly to the authors. Please cc: the

WG chairs at [e-mail]<mailto:[e-mail]> if you would like the chairs to

track such editorial comments as part of the WGLC process.



No IPR disclosures have been submitted directly on this draft.



Thanks,

David, Gorry and Marten

(TSVWG Co-Chairs)