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

[Sebastian Moeller <[e-mail]>]

Hi All,


> On Nov 23, 2022, at 11:30, <[e-mail]> <[e-mail]> wrote:
> 
> 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).

	[SM] Since end-points in WiFi networks are also encouraged to mark packets NQB by application policy alone, it seems to follow that the queue protection mechanism would need to be located in the WiFi AP, if the goals is to minimize abuse of airtime. In that case, to repeat my earlier proposal, it seems to make considerably more sense to default NQB to a DSCP that maps into AC_BE (or AC_BK which would also meet the stated requirement of "enable[ing] separate queuing from default traffic" in a way that has little side effects on legacy networks) AND use WiFi's standard qos_mapping feature on NQB-aware APs to map that NQB DSCP into the desired AC (which could even be AC_NQB with the desired properties of being a peer to AC_BE). It seems rather achievable to design this in a way where side-effects can only happen for nodes actively opting-in, and nodes opting in can be expected to meet the NQB requirements including queue-protection/policing. IMHO that would actually be a selling point for NQB, it does no harm, and promises to improve ow latency performance on NQB-compliant network elements.

Regards
	Sebastian


>  
> Regards,
>  
> Ruediger
>  
>  
> Von: Greg White <[e-mail]> 
> Gesendet: Dienstag, 22. November 2022 22:33
> An: Bless, Roland (TM) <[e-mail]>; Geib, Rüdiger <[e-mail]>; [e-mail]
> Cc: [e-mail]; 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]> on behalf of "Bless, Roland (TM)" <[e-mail]>
> Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT)
> Date: Monday, November 21, 2022 at 11:57 AM
> To: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, "David.Black=[e-mail]" <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] 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:
> 
> 	• The WiFi gear SHOULD carry NQB traffic in a separate queue in AC_BE
> 	• 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.
> 	• If the above aren’t possible or the conditions are unknown, then:
> 		• ISP SHOULD take precautions to prevent issues caused by prioritization of excessive and/or mismarked NQB traffic
> 		• ISP equipment SHOULD bleach NQB by default (so that any pass through of NQB is intentional)
> 		• 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) 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]> Im Auftrag von Black, David
> Gesendet: Mittwoch, 2. November 2022 04:47
> An: tsvwg IETF list <[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] list, although purely
> editorial comments may be sent directly to the authors. Please cc: the
> WG chairs at [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)