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

[[e-mail]]

Hi Greg,

I don’t think that actual configuration-examples or pseudo code solve the issue. Draft as is contains a statement that “As a result there is no rate R that can be configured for the NQB PHB...”

The text of the draft should be technology- and vendor agnostic, that’s all I’m asking for. My config example indicated, that an NQB can be configured standards compliant by configuring a rate R for this PHB. If you agree, please change the text, as I suggested.

There are different scheduling-methods and -architectures by which a the PHBs standardized up to now are configurable. That’s good tradition, and I think, we should keep it.

Regards,

Ruediger

Von: Greg White <[e-mail]>
Gesendet: Donnerstag, 31. August 2023 00:00
An: Geib, Rüdiger <[e-mail]>; [e-mail]
Cc: [e-mail]
Betreff: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-19.txt


And, for reference here is an example configuration of a 100 Mbps DOCSIS service offering that would comply with the NQB PHB requirements:



25 Downstream Service Flow = {

1 Service Flow Reference = 5

6 QoS Param Set Type = 7

36 Aggregate Service Flow Reference = 7

}

25 Downstream Service Flow = {

1 Service Flow Reference = 6

6 QoS Param Set Type = 7

36 Aggregate Service Flow Reference = 7

}

71 Downstream Aggregate Service Flow = {

1 Service Flow Reference = 7

8 Maximum Sustained Traffic Rate = 100000000

42 Low Latency Aggregate Service Flow Encodings = {

  1 Low Latency SF Reference = 6

  6 Scheduling Weight = 128

}

}

23 Downstream Classifier = {

1 Classifier Reference = 11

3 Service Flow Reference = 6

9 IPv4 Classifier = {

  1 Tos Range And Mask = 0xB4 0xB4 0xFC

}

}

23 Downstream Classifier = {

1 Classifier Reference = 13

3 Service Flow Reference = 6

12 IPv6 Classifier = {

  1 Traffic Class = 0xB4 0xB4 0xFC

}

}



This is a standardized configuration syntax that all current DOCSIS 3.1 and DOCSIS 4.0 equipment would support.




If I add this to an Annex of the draft, would this close your issue?

-Greg




From: tsvwg <[e-mail]<mailto:[e-mail]>> on behalf of Greg White <g.white=[e-mail]<mailto:g.white=[e-mail]>>
Date: Wednesday, August 30, 2023 at 3:34 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: 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]%20> " > 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





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





There is also an HTML version available at:

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





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