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

[[e-mail]]

Greg,

while many of your statements are correct, they do not reflect the full picture. The text comparing EF and NQB needs to be clear and complete regarding technical properties:

RG
An operator only deploying an NQB and a Default Queue may obtain an NQB performance similar to that of EF, as described by [RFC2598]. Both, EF and NQB require mechanisms ensuring that the departure rate of the PHB's scheduler never exceeds the forwarding rate available to the PHB. The following caveats and differences apply: EF is typically expected to be a managed service, whereas NQB is not expected to be a managed service. The mechanism ensuring that the departure rate of the PHB's scheduler never exceeds the forwarding rate  process differs between both PHBs. While EF relies on rate policing and dropping of excess traffic, this is one option for NQB only. NQB alternatively allows to re-mark and forward excess traffic by the Default PHB, rather than dropping it. Further, NQB recommends a flow based mechanism to limit the performance impact of excess traffic to those flows causing potential congestion of the NQB queue, whereas EF ignores flow properties. 

This statement is based on draft NQB and on EF. I accept diverging text, if any of my statements are wrong, misleading and cannot be backed by text of the two documents. 

I'll respond to other messages, once we settled this.

Regards,

Ruediger


-----Ursprüngliche Nachricht-----
Von: Greg White <[e-mail]> 
Gesendet: Mittwoch, 11. Oktober 2023 19:14
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

The other difference in NQB traffic protection is that it is recommended to be microflow-aware.  I think the expectation with EF is that it is microflow-blind.

What I have currently is no change to the first paragraph in 4.3, but adding a new second paragraph in 4.3 which reads:

An operator only deploying an NQB and a Default Queue may obtain an NQB performance similar to that of EF, as described by [RFC2598] with the following caveats. EF is typically expected to be a managed service where the arriving rate of traffic into the EF PHB doesn't exceed the forwarding rate configured for the PHB, whereas NQB is not a managed service, and hence the aggregate of traffic arriving to the NQB PHB queue could exceed the forwarding rate available to the PHB. Additionally, Section 5.2 discusses the recommended handling of excess traffic in the NQB PHB, which differs from the handling expected in the EF PHB.

I can add a more explicit statement in the last sentence, something like:

Additionally, Section 5.2 discusses the recommended handling of excess traffic in the NQB PHB (microflow-aware re-marking/re-scheduling or microflow-aware drop), which differs from the handling expected in the EF PHB (drop without microflow awareness).

-Greg





On 10/11/23, 6:04 AM, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>> wrote:
Greg,

Please clarify, is the statement will be included:

"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. An operator only deploying an NQB and a Default Queue may obtain an NQB performance similar to that of EF, as described by [RFC2598]."

Regarding similarities and differences with EF, RFC 2598 says:

1) Configuring nodes so that the aggregate has a well-defined minimum departure rate. ("Well-defined" means independent of the dynamic state of the node. In particular, independent of the intensity of other traffic at the node.)

RG: that has been settled, I think

2) Conditioning the aggregate (via policing and shaping) so that its arrival rate at any node is always less than that node's configured minimum departure rate.

RG: draft NQB recommends a "traffic protection" ensure 2). NQB traffic protection works like a highly sophisticated shaper or a policer, but it serves the purpose of ensuring that the NQB schedulers arrival rate is always less than its departure rate.

Text NQB as is:
However, a QB microflow that is mismarked as NQB would cause queuing delays and/or loss for all the other microflows that are sharing the NQB queue.
To prevent this situation from harming the performance of the microflows that are in compliance with the requirements in Section 4.1, network elements that support the NQB PHB SHOULD support a "traffic protection" function that can identify microflows that are inconsistent with the sender requirements in Section 4.1, and either re-mark those microflows/packets as Default and reclassify them to the QB queue or discard the offending traffic.

RG: The difference here with EF is that excess EF traffic MUST be dropped, whereas that is an "or" to re-marking/re-scheduling for NQB. That latter fact is worth a statement "compared with EF, NQB...".

Regards,
Ruediger



-----Ursprüngliche Nachricht-----
Von: Greg White <[e-mail] <mailto:[e-mail]>>
Gesendet: Dienstag, 10. Oktober 2023 22:51
An: Geib, Rüdiger <[e-mail] <mailto:[e-mail]>>
Cc: [e-mail] <mailto:[e-mail]>
Betreff: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-19.txt - 5.1 Primary Requirements, Forwarding - Departure rate


See below [GW].


On 10/9/23, 3:18 AM, "[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>" <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:


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."


[GW] Ok. I agree in principle. I don't think we should reference Appendix A.3.1 though. That appendix has very specific performance numbers for jitter variation resulting from a simulation of priority queuing and WRR in one specific set of scenarios. I'm not sure that we would even expect an EF implementation today to provide similar result to that in general. 




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. 


[GW] Ok. I think the other distinction is that EF traffic is expected to be managed such that the arriving rate doesn't exceed the forwarding rate, whereas NQB is an unmanaged service. If EF is aggregated into the NQB PHB along with unmanaged traffic, the result could be different from a pure EF deployment. 




Regards,




Ruediger




-----Ursprüngliche Nachricht-----
Von: Greg White <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> 
Gesendet: Donnerstag, 31. August 2023 01:44
An: Geib, Rüdiger <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
Cc: [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[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]> <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>" <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[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-> <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-&gt;> <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-&gt;> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#name-aggregation-of-other-dscps-&gt;> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#name-aggregation-of-other-dscps-&amp;gt;&gt;>
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> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1&gt;> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1&gt;> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1&gt;> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1&amp;gt;&gt;>




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> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1&gt;> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1&gt;> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1&gt;> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1&amp;gt;&gt;>








[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/ <https://mailarchive.ietf.org/arch/msg/tsvwg/mCETQtmpiZtcLP6rLHvWpgbqFM0/> <https://mailarchive.ietf.org/arch/msg/tsvwg/mCETQtmpiZtcLP6rLHvWpgbqFM0/> <https://mailarchive.ietf.org/arch/msg/tsvwg/mCETQtmpiZtcLP6rLHvWpgbqFM0/&gt;>




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> <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&gt;> <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&gt;> <https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresco/download?id=79935977-877b-4027-8f6f-7d739945e1d1&gt;> <https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresco/download?id=79935977-877b-4027-8f6f-7d739945e1d1&amp;gt;&gt;>








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/> <https://mailarchive.ietf.org/arch/msg/tsvwg/08BwyTAe0glWvIApQB-eaPuA_V0/> <https://mailarchive.ietf.org/arch/msg/tsvwg/08BwyTAe0glWvIApQB-eaPuA_V0/&gt;> <https://mailarchive.ietf.org/arch/msg/tsvwg/08BwyTAe0glWvIApQB-eaPuA_V0/> <https://mailarchive.ietf.org/arch/msg/tsvwg/08BwyTAe0glWvIApQB-eaPuA_V0/&gt;> <https://mailarchive.ietf.org/arch/msg/tsvwg/08BwyTAe0glWvIApQB-eaPuA_V0/&gt;> <https://mailarchive.ietf.org/arch/msg/tsvwg/08BwyTAe0glWvIApQB-eaPuA_V0/&amp;gt;&gt;>








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]> <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>> Im Auftrag von [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
Gesendet: Mittwoch, 26. Juli 2023 19:08
An: [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
Cc: [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[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/> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&gt;> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&gt;> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&gt;> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&amp;gt;&gt;>








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> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html&gt;> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html&gt;> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html&gt;> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html&amp;gt;&gt;>








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> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19&gt;> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19&gt;> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19&gt;> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19&amp;gt;&gt;>








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