Re: [tsvwg] draft-ietf-tsvwg-nqb-15.txt - 4.2. Aggregation of the NQB DSCP with other Diffserv PHBs

[Greg White <[e-mail]>]

Hi Ruediger, 

Sorry if my response wasn't clear. 

If you read section 5 in that referenced draft-livingood (and in particular 5.1 & 5.2), you'll find that it recommends that network operators DO NOT classify individual applications to the NQB PHB.  Instead, it recommends that operators ONLY use the DSCP 45 marking to identify NQB packets (and that the operator not re-mark traffic to/from 45), thus allowing the application to make the decision as to whether it prefers the shallow-buffered queue or the deep-buffered queue. 

As I implied below, section 4.3 in NQB draft-16 describes options that differ from the specific guidance in draft-livingood, but I was arguing that it perhaps doesn't deviate from the spirit of what is recommended there. In other words, aggregating other selected DSCPs into the NQB PHB still is relying on application marks, and presuming the operator knows something about what those marks mean in the context of their network (e.g. if non-SLA voice traffic is marked EF) they could reasonably safely classify EF into the NQB PHB.  But, I recognize that this is a bit of a gray area, and that others might not think this is safe or advisable.  For those who would object to this aggregation, are the existing caveats in section 4.3 sufficient?

I was further trying to point out that introducing the idea of multifield classification in the NQB draft would (in my opinion) completely diverge from the guidance in draft-livingood.  

Now, the NQB draft is not required to align with draft-livingood, but as a WG I think we would need to weigh the arguments in that draft and if we decide to diverge from those recommendations, discuss what the ramifications are and what additional caveats we'd want to include in NQB.

Does that help explain my previous response?

-Greg


On 3/14/23, 6:38 AM, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>> wrote:

Hi Greg,

please clarify your response:

[RG]: You seem to say, classification of traffic from NQB marked traffic and other DSCPs SHOULD be based on DSCP values only by your following statement below:
"I tried to recognize in the draft that in many networks there may exist traffic that is carried as Best Effort today (i.e. no SLA), but that is largely compliant with the NQB sender requirements, though it is not marked with the recommended DSCP. In that case, aggregation of such traffic into the NQB PHB might be a good option (for a network operator that wishes to provide good Best Effort performance) rather than aggregating it into the Default queue."

[RG]: But in the next sentence, you refer to applications which are classified by operators for NQB PHB:
"I think the recommendations in section 5 of https://www.ietf.org/archive/id/draft-livingood-low-latency-deployment-01.html <https://www.ietf.org/archive/id/draft-livingood-low-latency-deployment-01.html> provide good rationales as to why we should be careful encouraging operators to pick and choose which applications get access to the NQB PHB and which ones don't."

[RG]: To me, the most reliable way to classify an "application" for a PHB is by MF evaluation. DiffServ supports a concept of assigning "behaviour aggregates" to PHBs and marks these by DSCPs. There's no relation to a single application. Applications sharing similar performance requirements may be forwarded by the behaviour aggregate and PHB. Please be so kind to explain, how an operator identifies applications to be classified for NQB, if this isn't done by MF classification. 

Per-hop Behavior (PHB): a description of the externally observable
forwarding treatment applied at a differentiated services-compliant
node to a behavior aggregate.

Behavior Aggregate: a collection of packets with the same codepoint
crossing a link in a particular direction. The terms "aggregate" and
"behavior aggregate" are used interchangeably in this document.

Regards,
Ruediger


-----Ursprüngliche Nachricht-----
Von: Greg White <[e-mail] <mailto:[e-mail]>> 
Gesendet: Samstag, 11. März 2023 21:42
An: Geib, Rüdiger <[e-mail] <mailto:[e-mail]>>
Cc: [e-mail] <mailto:[e-mail]>
Betreff: Re: [tsvwg] draft-ietf-tsvwg-nqb-15.txt - 4.2. Aggregation of the NQB DSCP with other Diffserv PHBs

Hi Ruediger,

Sorry for the delay in getting back to this. I'm not sure that the scenario you describe aligns with the philosophy of the NQB PHB. What you are describing sounds to me like the EF PHB. With EF, the goal is a guarantee (or very high probability) of low/bounded latency for a groomed subset of traffic in a controlled environment. NQB on the other hand is intended to provide "statistically better loss, latency and jitter" (as compared to the Default queue) for Best Effort Internet traffic on Access Network segments. With Internet traffic, there is no option to implement admission control, there are no trusted senders, and there are very few known properties. So, we are relying on creating appropriate incentives such that mis-use is minimized, and we are recommending mechanisms to shed load and minimize degradations when overload conditions inevitably occur. The Queue Protection mechanism implemented in the NQB PHB in DOCSIS equipment, in simple terms, aims to maintain a low queuing delay by selectively redirecting traffic from the flows that are causing a queue to form (only when they are causing it) and not redirecting traffic from the flows that aren't causing the queue. To restate my point, this is different from EF, where (in my understanding) there is an expectation of trust and control over DSCP markings at the sender, and overload is either prevented via admission control protocols (either you get service or you get a "busy signal") or traffic conditioning introduces delay and loss to all flows equally. 

I tried to recognize in the draft that in many networks there may exist traffic that is carried as Best Effort today (i.e. no SLA), but that is largely compliant with the NQB sender requirements, though it is not marked with the recommended DSCP. In that case, aggregation of such traffic into the NQB PHB might be a good option (for a network operator that wishes to provide good Best Effort performance) rather than aggregating it into the Default queue. It certainly wasn't my intent to describe how an operator can build something like an SLA service using the NQB PHB (which sounds like what you are asking for). But even setting that aside, this is a controversial topic, and one which network operators need to carefully consider before implementing. I think the recommendations in section 5 of https://www.ietf.org/archive/id/draft-livingood-low-latency-deployment-01.html <https://www.ietf.org/archive/id/draft-livingood-low-latency-deployment-01.html> provide good rationales as to why we should be careful encouraging operators to pick and choose which applications get access to the NQB PHB and which ones don't. Introducing multi-field classification seems to me like it crosses that line, whereas aggregating additional DSCPs seems (to me) safer, since the application has presumably chosen to mark its traffic with a non-default DSCP under an expectation that the network would treat it differently. But, I recognize that others could have different views. 

-Greg

On 2/14/23, 1:37 AM, "[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>" <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:

Hi Greg,

I'm ok with emphasizing operator responsibility rather than, let's say, node responsibility. Without going to details by this mail, it might make sense to add text related to multifield classification, rather than DSCP based classification only (if it is about forwarding other classes by NQB PHB and the traffic offered by these classes isn't reliably NQB). Low loss and low jitter result from keeping the actual load rate below scheduler bandwidth. If just the DSCP is used for classification and all trust is based on the NQB DSCP only, traffic conditioning may have different requirements as compared to multifield classification, where the operator tries to ensure that a trusted sender creates traffic with known properties for access configurations of known properties, and then forward it by the NQB queue. Example: the NQB scheduler has a transmit rate of 25 Mbit/s (or more) and a broadcast stream of known and controlled origin offers 6-8 Mbit/s, then that may work (for a limited number of broadcast flows). To add, the same operator may offer accesses with an NQB scheduler of 5 Mbit/s under some circumstances. The operator wouldn't classify any broadcast traffic for NQB for the latter.

If the above scenario is something you'd like to address by "classifying other classes for the NQB PHB" (or whatever headline you prefer), then I'd appreciate text explaining that. What worries me is, the text as is seems to propose classification based on DSCP only. 

Regards,
Ruediger