Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-19.txt

[[e-mail]]

Hi Greg,

to the extent I understand the configuration options of the example, both of our suggested configurations (yours and mine) operate equal, regarding default and NQB scheduling.

Assuming the interface to offer 100 xbps, the following purely rate based config is equivalent:
schedulers {
...
best-effort { ****transmit-rate  47x; ....
NQB { ****transmit-rate 47x; ..... 

x could be "m" for Mbit/s, or "k" for kbit/s.

If that is a valid configuration of the NQB PHB by *a* rate R that *is* configured for the NQB PHB - could the text of the draft kindly reflect that? I suggest to remove this statement: As a result there is no rate R that can be configured for the NQB PHB. Please change to "The NQB PHB does not guarantee any serving rate for NQB-marked traffic, let alone one that is independent of the offered load of non-NQB-marked traffic."

If it helps discussion, I can provide another example of a configuration based on a rate configured for default and NQB. Referring to equipment of a different commercial vendor. 

I repeat my expectation that standard PHBs should be technology and platform agnostic. From my point of view, DiffServ related standards reflecting solutions suiting specific networks or requiring particular technologies or methods to configure them should be Info or Experimental.

Regards,

Ruediger


-----Ursprüngliche Nachricht-----
Von: Greg White <[e-mail]> 
Gesendet: Mittwoch, 30. August 2023 23:34
An: Geib, Rüdiger <[e-mail]>; [e-mail]
Cc: [e-mail]
Betreff: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-19.txt

Hi Ruediger,

I'm not opposed to providing some additional guidance in an Annex in the draft, if we can agree upon it (though I don't think it is appropriate to recommend vendor-specific configurations).  Also, I don't think there is (or should be) a requirement that a standards-track draft needs to be immediately implementable via existing user configuration commands on all existing equipment with current software.  If that was the requirement, the IETF wouldn't make much progress would it?  NQB is already configurable in DOCSIS equipment via a standardized configuration mechanism.  Since NQB is described as being developed primarily for access network segments, I'd argue that an example DOCSIS configuration would be more appropriate than one for a core network router. Would you be ok if I used DOCSIS instead?  If not, then I don't understand how you have a valid objection to it being standards track or starting last call.



In regards to the specific vendor implementation you mentioned, I found the documentation you are referring to, but it leaves some gaps in the description.  It would seem to me that an NQB compliant configuration might be:

schedulers {
network-control {
****transmit-rate percent 5; ****
buffer-size percent 5;
****priority medium-low; ****
drop-profile-map loss-priority any protocol any drop-profile terminal; } best-effort { ****transmit-rate percent 95; **** buffer-size percent 95; priority low; drop-profile-map loss-priority any protocol any drop-profile terminal; } NQB { ****transmit-rate percent 95;**** buffer-size percent 5; priority low; drop-profile-map loss-priority any protocol any drop-profile terminal; } }

Based on my read of this vendor's documentation, this would allow network-control traffic to have up to 5% of the link capacity without being preempted (and access to any leftover bandwidth unused by best-effort and NQB). Best-effort and NQB would compete with equal priority for up to 95% of the link capacity without being preempted by network-control (and would have equal access to any leftover bandwidth unused by network-control).

 
But, I'll restate my point from above.  If you happen to have a piece of core network gear that doesn't support the NQB PHB requirements with its current software, that is NOT grounds for blocking the progression of the draft.

-Greg





On 8/2/23, 6:50 AM, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>> wrote:


Hi Greg,


please reword the NQB Annex linked below. I'm copying in an excerpt of the public config-manual of a router vendor. Draft NQB should reflect commonly deployed commercial network solutions without making assumptions which are not proven and can't be proven. Note that I marked one command-line and a text-statement ****.


Please suggest how this vendor should configure "The NQB PHB [, ] a shallow-buffered, best-effort service as a complement to a Default deep-buffered best-effort service for Internet services."
- without a "rate R that can be configured for the NQB PHB"
- while having "the same forwarding preference (and hence the same likelihood of being deferred if other traffic is being served) as Default traffic."
To help you, you'll find my take below. Again some relevant commands highlighted ****.


Dear chairs,


I'm sorry, but as long as draft NQB contains statements as those in the Annex linked below
- I don't think it is ready for last call
- I don't think it should be standards track I will stop commenting if draft NQB is put on experimental or on info track, or progressed as an ID.


Greg, chairmen:
NQB Annex https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#EF <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#EF>


Regards,


Ruediger




############# Copy from public vendor documentation ################### The following ****default scheduler**** is provided when you install the ... OS. These settings are not visible in the output of the show class-of-service command; rather, they are implicit.
[edit class-of-service]
schedulers {
network-control {
transmit-rate percent 5;
buffer-size percent 5;
priority low;
drop-profile-map loss-priority any protocol any drop-profile terminal; } best-effort { ****transmit-rate percent 95;**** buffer-size percent 95; priority low; drop-profile-map loss-priority any protocol any drop-profile terminal; } }


##### RG pseudo default config consisting of NQB and Default PHB, same forwarding preference... as Default traffic #############


schedulers {
network-control {
transmit-rate percent 6;
buffer-size percent 5;
priority low;
drop-profile-map loss-priority any protocol any drop-profile terminal; } best-effort { ****transmit-rate percent 47; **** buffer-size percent 95; priority low; drop-profile-map loss-priority any protocol any drop-profile terminal; } NQB { ****transmit-rate percent 47;**** buffer-size percent 5; priority low; drop-profile-map loss-priority any protocol any drop-profile terminal; } }




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