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

[[e-mail]]

Hi Greg,

you suggest to change the following:

Greg EXISTING
As a result there is no rate R that can be configured for the NQB PHB, and moreover the NQB PHB does not guarantee any serving rate for NQB-marked traffic,

Greg NEW
As a result there is no rate R that can be configured for the NQB PHB that would serve the purpose described in the EF definition, and moreover 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 (which includes Default traffic).

RG: I'd appreciate standards text which specifies what is configured, rather than text stating what is not configured.

RG: as an orientation some excerpts from other RFCs, referring to the Default PHB. Both recommend to reserve some minimum resources for the default PHB, e.g, buffer, bandwidth (RFC4594 calls that "bandwidth guarantee" - I absolutely agree with this text and I have no recollection that this was questioned while that document progressed through the WG). My assumption would be, that a standard NQB contains text stating that the same minimum of amount bandwidth or rate is configured for NQB, as for the Default PHB (less buffer, obviously as a short Queue is an NQB design aim). Referencing to the RFCs below may be useful, but I leave that to you.
Otherwise, if "no rate R can be configured for the NQB PHB", my take is, no rate R can be configured for Default PHB, as both configs are supposed to be identical. My expectation is, that the draft written in way not allowing for diverging interpretations or interpretations which contradict existing standards, unless that's what the document is scoped for. Updating RFC2474 or 4594 isn't intended, is it? 

Configuration of Default PHB see
https://datatracker.ietf.org/doc/html/rfc2474#section-4.1
   A reasonable
   policy for constructing services would ensure that the aggregate was
   not "starved".  This could be enforced by a mechanism in each node
   that reserves some minimal resources (e.g, buffers, bandwidth) for
   Default behavior aggregates.

https://datatracker.ietf.org/doc/html/rfc4594#section-1.5.1
   The basic forwarding behaviors applied to any class of traffic are
   those described in [RFC2474] and [RFC2309].  Best-effort service may
   be summarized as "I will accept your packets" and is typically
   configured with some bandwidth guarantee.


Hope that helps,

Ruediger


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

Hi Ruediger,


Thanks for your responses. I hope you don't mind, but I've included all four of them in this single post, since they are all related. If you'd rather respond to this via separate posts, please do so.


See below, with my responses as [GW].


-Greg




-------- https://mailarchive.ietf.org/arch/msg/tsvwg/jSHOYp_MA3JuuUXpym-Tg9lHgFU/  ----------- 


as far as I can tell, IETF standards should be technology neutral, i.e. not assume any particular technology to be deployed to support a standard.


As an example, the EF-PHB was standardized to allow operation without requiring Priority Queuing (PQ) scheduling. AFAIK, some vendors don't support PQ, while their equipment supports EF and saw and continues to see commercial deployment.


Greg, you "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." I'd prefer Internet standards to be written in a way to allow for deployment in the general Internet to the extent possible, rather than reflecting an implementation for limited equipment. To me, assuming a particular scheduler to be present should be avoided, if a PHB is standardized. In my recollection, that has been consensus within IETF, but I may be wrong (and chairs can easily correct my perception).


[GW] I don't understand the connection between your response and the text of mine that you quoted. I agree with the words in your response, but I think you've missed my point. In general, standards cannot be constrained by existing implementations, otherwise we'd never get anywhere. If (for example) the Wi-Fi 7 standards (IEEE 802.11be) were only allowed to contain requirements that could be met by user configuration of all (or even most) existing Wi-Fi 6 devices, that would be ridiculous. The same is true in the IETF. If the IETF were to be forbidden from producing standards that go beyond the capabilities of existing gear, what would be the point of it? If there *are* standards that happen to be implementable with user configuration on gear that was deployed before the standard was drafted, that's great, but it can't be a requirement. Do you disagree with this? 


Thanks for trying to suggest a configuration for an existing example vendor, but your response argues past may point. I've asked you to suggest a configuration without a "rate R that can be configured for the NQB PHB". Your suggested configuration assigns a rate r for NQB and fails to address my request.


[GW] Ok, is your issue just one of terminology? The relevant NQB PHB requirement in https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html#section-5.1 is "A node supporting the NQB PHB SHOULD NOT rate limit or rate police the aggregate of NQB traffic separately from Default traffic.", which means that NQB traffic *shares* whatever rate is configured for Default. This does not mean that NQB cannot be rate limited or rate policed, or that the configuration of NQB cannot include a rate element. It just means that the NQB traffic needs to be rate limited/policed *jointly* with Default traffic. The text you seem to be objecting to is in Appendix B (https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html#appendix-B) which reads: 


The Expedited Forwarding definition [RFC3246] provides the following intuitive description of the EF PHB: "the rate at which EF traffic is served at a given output interface should be at least the configured rate R, over a suitably defined interval, independent of the offered load of non-EF traffic to that interface." This differs from the definition of the NQB PHB, in which NQB traffic is treated as being the same forwarding preference (and hence the same likelihood of being deferred if other traffic is being served) as Default traffic.
As a result there is no rate R that can be configured for the NQB PHB, and moreover 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. This difference additionally makes the NQB PHB suitable for implementation in networks where link capacity is not guaranteed.


[GW] I think this can be improved by changing the offending sentence to read: 


As a result there is no rate R that can be configured for the NQB PHB that would serve the purpose described in the EF definition, and moreover 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 (which includes Default traffic).


[GW] Does this wording work for you?






------------ https://mailarchive.ietf.org/arch/msg/tsvwg/QFhiliqsR5XyZ_-VaSNxIRgUWs4/  -----------------


a second response within this thread. The vendor from whom I copied a default config 
"has a long history of working together to develop and deploy innovative telecom networking solutions at the core, edge, data center, and telco cloud. Tune into this interview with <name omitted>, Head of Voice & Messaging at Deutsche Telecom to hear how the partnership has evolved over the years." 


[GW] I don't understand how DT's business partnerships (or their evolution) are relevant to the discussion. Please explain.


The configuration suggested by me is the default offered for their equipment, also for edge and access routers. Please stop alleging, my example to be "for a core network router". A standard NQB PHB should be configurable on equipment of this and other commercial access network vendors, not just on DOCSIS routers.


[GW] I did provide a suggested configuration for your routers, but still I stand by my statement that future IETF standards cannot be constrained by existing implementations. 




--------- https://mailarchive.ietf.org/arch/msg/tsvwg/subd7tnVmeRJamzjDImBiFpqdTM/ ---------


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.


[GW] By my understanding of the configuration options, the two suggested configurations are not identical. Yours would not be compliant with the NQB PHB definition, while mine would.


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? 


[GW] Without seeing the rest of the configuration, it is impossible to say whether this is a valid configuration of the NQB PHB. Please instead refer to the configuration that I provided.


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


[GW] I think my suggested wording above is better, but if you find it objectionable, I can use your wording instead.


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. 

[GW] I fail to see how that would help.


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.

[GW] So, based on that, the NQB PHB should match your expectation. The NQB PHB *is* technology and platform agnostic, it is *not* suited only for specific networks, and it *does not* require particular technologies for configuration.




--------- https://mailarchive.ietf.org/arch/msg/tsvwg/KaZUenSlywnZvvc2goWIZoovc3c/  ------------

I don’t think that actual configuration-examples or pseudo code solve the issue. 

[GW] Ok, good. 

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. 

[GW] Addressed above. 


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. 

[GW] I don't disagree.




Regards,


Ruediger












-----Ursprüngliche Nachricht-----
Von: Greg White <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> 
Gesendet: Mittwoch, 30. August 2023 23:34
An: Geib, Rüdiger <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>; [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




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








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> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#EF> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#EF&gt;> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#EF> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#EF&gt;> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#EF&gt;> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#EF&amp;gt;&gt;>








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