Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-19.txt - 5.1 Primary Requirements, Forwarding - Departure rate

[[e-mail]]

Greg,

the proposal is

CURRENT TEXT: "Operators of nodes that support the NQB PHB could choose to aggregate other service classes into the NQB queue. This is particularly useful in cases where specialized PHBs for these other service classes are not provided."
RG PLEASE ADD: "An operator only deploying an NQB and a Default Queue may obtain an NQB performance similar to that of EF, as described by [RFC2598], Appendix A.3.1."

To me, this statement is required as it simply acknowledges the fact NQB equals EF resulting from the NQB configuration and operation *in that case*. I recognize and accept, that doesn't expand to all NQB deployment scenarios, but it certainly is true with the above preconditions defined by  draft NQB. I prefer the draft to be explicit to this point, as I don't expect casual readers to be DiffServ experts and I think it's fair practice to reference them to available IETF standards (and their references) helping them to understand operation of the DiffServ mechanism they may want to configure and operate. 

The above statements likely benefit from one more sentence, as EF recommends rather to drop than to remark and forward excess traffic. NQB recommends the latter, if the traffic protection mechanism is implemented. Please line out further caveats, which add to this, to enable technical discussion. 

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: Greg White <[e-mail]> 
Gesendet: Donnerstag, 31. August 2023 01:44
An: Geib, Rüdiger <[e-mail]>
Cc: [e-mail]
Betreff: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-19.txt - 5.1 Primary Requirements, Forwarding - Departure rate

Hi Ruediger,

See below [GW].

-Greg


On 8/3/23, 1:39 AM, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>> wrote:

Hi Greg,

Draft NQB section
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#name-aggregation-of-other-dscps- <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#name-aggregation-of-other-dscps->
contains:

"Operators of nodes that support the NQB PHB could choose to aggregate other service classes into the NQB queue. This is particularly useful in cases where specialized PHBs for these other service classes are not provided."

Let's assume an operator only deploys NQB and a Default Queue. Please point out the difference in operation between NQB queue and the EF PHB by referring to the experimental WRR EF implementation which is part of RFC2597, EF, by suitable text in draft NQB:
https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1 <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1>

If there is no difference, please add text stating that "An operator only deploying an NQB and a Default Queue may obtain an NQB performance similar to that of EF, as described by [RFC2598], Appendix A.3.1., presenting results of a WRR EF simulation as a worst case EF implementation."
https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1 <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1>


[GW] Both EF and NQB can be implemented via WRR.  In RFC2598, for EF the WRR weight is configured via a "proper choice of the EF queue’s WRR share of the output link with respect to its subscribed rate" and ends up being a "worst case" implementation of the PHB.  Whereas in NQB the WRR weight would be set to 50% of the link capacity, and it would be recommended to additionally implement a traffic protection mechanism.  In the very specific simulation conditions in RFC2598 Appendix A.3.1 (where EF traffic is limited to an average of 30% of the bottleneck rate and the WRR weight is 31%) the NQB configuration would be expected to provide better latency and jitter performance than the EF WRR configuration for marked traffic, but I think it would be misleading to make the statement you suggested without adding further caveats.   Moreover, I don't quite see the point of it.  Could you explain why you think such a statement is useful?





[GW] for a response to the points below, please see the other thread https://mailarchive.ietf.org/arch/msg/tsvwg/mCETQtmpiZtcLP6rLHvWpgbqFM0/

I'm not aware of any reference native NQB/Default configuration provided by draft NQB or by you in any separate mail. This may prove to be useful to understand configuration of an NQB Queue with the same forwarding preference (and hence the same likelihood of being deferred if other traffic is being served) as" the Default queue. I regard myself as pretty experienced in configuring QoS. I'm sure, less experienced readers appreciate information how to configure only a Default queue in addition with the NQB queue, respecting that "the NQB PHB cannot be configured with a rate R" (or anything similar to that).


I'm as of yet only aware of two suggestions for an NQB implementations.


NQB implementation status, text links to:
https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresco/download?id=79935977-877b-4027-8f6f-7d739945e1d1 <https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresco/download?id=79935977-877b-4027-8f6f-7d739945e1d1>


I found, which specifies that "conditional priority is given to the Low Latency Service Flow" - that is the NQB traffic. This is astonishing as a reference implementation, taking into account that you so far claimed that NQB is definitely not about priority. I also note, that implementation is suggested by a WRR scheduler:


CM-SP-MULPIv3.1-I25-230419.pdf
Page 289 ff


Which contains:
Inter-SF Scheduler: CMTS mechanism to identify the amount of resources that will be allocated between the Low Latency and Classic Service Flows that belong to the same ASF.


From there I take:
7.7.3.2 Inter-SF Scheduler
As the Dual Queue Coupled AQM architecture provides only one-way coupling from the Classic Service Flow to the Low Latency Service Flow, it relies on the Inter-SF Scheduler to balance this by ensuring that conditional priority is given to the Low Latency Service Flow within the ASF. “Conditional priority” means that traffic of the Low Latency Service Flow will be serviced with a priority, yet without the Classic Service Flow being starved. Weighted Round Robin (WRR) is a simple scheduler that achieves the desired results, and is recommended in [draft-ietf-tsvwg-aqm-dualq-coupled].


For Downstream ASFs, the CMTS SHOULD implement a WRR scheduler between the Low Latency Service Flow and the Classic Service Flow within the Aggregate Service Flow.


##########


Apart from that, I have suggested a pseudo native NQB/Default scheduler which can be configured by routers of one commercial vendor, see


https://mailarchive.ietf.org/arch/msg/tsvwg/08BwyTAe0glWvIApQB-eaPuA_V0/ <https://mailarchive.ietf.org/arch/msg/tsvwg/08BwyTAe0glWvIApQB-eaPuA_V0/>


Feel free to suggest corrections for the latter to clarify NQB deployment for equipment of this vendor.


Regards,


Ruediger




-----Ursprüngliche Nachricht-----
Von: tsvwg <[e-mail] <mailto:[e-mail]>> Im Auftrag von [e-mail] <mailto:[e-mail]>
Gesendet: Mittwoch, 26. Juli 2023 19:08
An: [e-mail] <mailto:[e-mail]>
Cc: [e-mail] <mailto:[e-mail]>
Betreff: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-19.txt




A New Internet-Draft is available from the on-line Internet-Drafts directories. This Internet-Draft is a work item of the Transport Area Working Group (TSVWG) WG of the IETF.


Title : A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services Authors : Greg White Thomas Fossati Filename : draft-ietf-tsvwg-nqb-19.txt Pages : 29 Date : 2023-07-26


Abstract:
This document specifies properties and characteristics of a Non- Queue-Building Per-Hop Behavior (NQB PHB). The NQB PHB provides a shallow-buffered, best-effort service as a complement to a Default deep-buffered best-effort service for Internet services. The purpose of this NQB PHB is to provide a separate queue that enables smooth (i.e. non-bursty), low-data-rate, application-limited traffic microflows, which would ordinarily share a queue with bursty and capacity-seeking traffic, to avoid the latency, latency variation and loss caused by such traffic. This PHB is implemented without prioritization and can be implemented without rate policing, making it suitable for environments where the use of these features is restricted. The NQB PHB has been developed primarily for use by access network segments, where queuing delays and queuing loss caused by Queue-Building protocols are manifested, but its use is not limited to such segments. In particular, applications to cable broadband links, Wi-Fi links, and mobile network radio and core segments are discussed. This document recommends a specific Differentiated Services Code Point (DSCP) to identify Non-Queue- Building microflows.


[NOTE (to be removed by RFC-Editor): This document references an ISE submission draft (I-D.briscoe-docsis-q-protection) that is approved for publication as an RFC. This draft should be held for publication until the queue protection RFC can be referenced.]


The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/ <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/>


There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html>


A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19 <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19>


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts