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

[[e-mail]]

Greg,

~~~~~~~~ New proposed Appendix B. Comparison to Expedited Forwarding ~~~~~~~~~ The Expedited Forwarding definition [RFC3246] provides the following text to describe the EF PHB: "This specification defines a PHB in which EF packets are guaranteed to receive service at or above a configured rate" and "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." Notably, this description is true of any class of traffic that is configured with a guaranteed minimum rate, including the Default PHB if configured per the guidelines in Section 1.5.1 of [RFC4594]. [RFC3246] goes on to formalize the definition of EF by requiring that an EF node be characterizable in terms of the fidelity with which it is able to provide a guaranteed rate.

[RG] This is true, but I fail to understand why that is relevant for NQB.

[RG]: Please extend: 
The NQB PHB is not required to be configured with a guaranteed minimum rate. Based on common operational practice, RFC 2474 and RFC 4594 recommend assigning some minimum resources for the Default PHB however, in particular some dedicated bandwidth. If a guaranteed minimum rate is configured for Default PHB, it is recommended (Section 5) to configure an identical minimum rate for NQB. In such cases, the NQB PHB receives a rate guarantee of 50% of the rate guaranteed to the combined NQB/Default PHBs. 

Given that the EF PHB cannot, at least in some cases, be distinguished from the NQB PHB simply by virtue of its forwarding behavior, the distinction becomes one of intended usage as described in [RFC4594] and actual usage in practice in the Internet. In Section 1.5.3 of [RFC4594], EF is described as generally being used to carry voice or data that requires "wire like" behavior through the network, and it is recommended that EF traffic be policed at various points in the network to ensure that configured EF forwarding rates aren't overrun. 

RG please change the next sentence:
The NQB PHB, in contrast, is described here as being useful for any traffic that is sent at a low and/or consistent rate and for which the application would be negatively affected by excessive packet delay and delay variation, and there is no recommendation for policing of NQB traffic to a certain rate in general (Section 4.4.1 notwithstanding).

NEW: The NQB PHB is useful to carry application traffic requiring wire-line like performance, characterized by low packet delay and delay variation. To limit access of traffic to the NQB PHB in the case of congestion, draft NQB recommends deployment of a traffic protection (see Section 5.2).

RG I'm having trouble with the following statement. Unless some providers speak up who configure their network to allow for unconditional preemption of other PHBs by EF, please delete: In actual practice, EF traffic is oftentimes prioritized over Default traffic,
RG: If a PHB has a guaranteed departure rate, it has a guaranteed departure rate. If PQ or a PQ-like configuration is configured to schedule EF, than a rate limitation is recommended by standards bodies as well as by vendors. If you provide evidence, that many providers don't limit the amount of traffic forwarded by EF, I'm ready to discuss maintaining your statement. 

RG: Please delete commercial statements in technical documents: and sometimes EF is treated as a specialized traffic class that is subject to additional carriage agreements, tariffs, etc. 

RG: the following has been stated already and I understood draft NQB to standardize that: This contrasts with NQB traffic which is to be treated with the same forwarding priority as Default (and sometimes aggregated with Default), and is intended to be a Best Effort service.

In addition, the lack of a requirement of a guaranteed minimum rate, 

RG: as long as there's NQB text recommending a traffic protection, statements like the following are misleading and should be deleted:  and the lack of a recommendation to police incoming traffic to such a rate, 
RG the NQB traffic protection limits the NQB traffic to the NQB scheduler departure rate, be the latter guaranteed or not.

makes the NQB PHB suitable for implementation in networks where link capacity is not or cannot be guaranteed.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~` 

Regards,

Ruediger

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

Coming back to this point now...

On 10/5/23, 1:47 AM, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>> wrote:

[snip]

RG: I'm having trouble with the following sentence and prefer it to be deleted:
Thus, the NQB PHB does not guarantee any serving rate for NQB-marked traffic that is independent of the offered load of Default traffic.


RG: If there's a minimum bandwidth guarantee for Default PHB, there's a minimum bandwidth guarantee for NQB PHB too. A configuration where this doesn't hold would consist of an NQB/Default PHB based on access permission to excess bandwidth only AND the consumption of all spare resources up to full line capacity by suitable configuration other PHBs. No doubt, such a configuration is feasible. But assuming it to be present and a pre-condition before NQB is deployed requires an explicit statement by the draft, I think. I'd like to point to the RFCs I've referenced to again, stating that Default PHB config should avoid starvation or have a small guaranteed bandwidth, respectively. In that case, the same would obviously hold for NQB (which then receives a *limited but existing* bandwidth served independent of the load of the Default PHB).

[GW] With the addition of the text on hierarchical scheduling, and the text I've added describing the similar performance between EF and NQB in the situation that you mentioned, perhaps the Appendix B Comparison to Expedited Forwarding is less needed.  But in any case, I've re-drafted it based on the discussion in this thread. Please have a look and let me know if you have concerns with it. 

~~~~~~~~ New proposed Appendix B. Comparison to Expedited Forwarding ~~~~~~~~~ The Expedited Forwarding definition [RFC3246] provides the following text to describe the EF PHB: "This specification defines a PHB in which EF packets are guaranteed to receive service at or above a configured rate" and "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." Notably, this description is true of any class of traffic that is configured with a guaranteed minimum rate, including the Default PHB if configured per the guidelines in Section 1.5.1 of [RFC4594]. [RFC3246] goes on to formalize the definition of EF by requiring that an EF node be characterizable in terms of the fidelity with which it is able to provide a guaranteed rate.

The NQB PHB is not required to be configured with a guaranteed minimum rate. Though, if Default traffic is provided a guaranteed minimum rate, it is recommended (Section 5) that NQB traffic share and be given equal access to that rate. In such cases, the NQB PHB could be described as having a rate guarantee that is 50% of the rate guaranteed to the combined NQB/Default class.

Given that the EF PHB cannot, at least in some cases, be distinguished from the NQB PHB (or from the Default PHB) simply by virtue of its forwarding behavior, the distinction becomes one of intended usage as described in [RFC4594] and actual usage in practice in the Internet. In Section 1.5.3 of [RFC4594], EF is described as generally being used to carry voice or data that requires "wire like" behavior through the network, and it is recommended that EF traffic be policed at various points in the network to ensure that configured EF forwarding rates aren't overrun. The NQB PHB, in contrast, is described here as being useful for any traffic that is sent at a low and/or consistent rate and for which the application would be negatively affected by excessive packet delay and delay variation, and there is no recommendation for policing of NQB traffic to a certain rate in general (Section 4.4.1 notwithstanding). In actual practice, EF traffic is oftentimes prioritized over Default traffic, and sometimes EF is treated as a specialized traffic class that is subject to additional carriage agreements, tariffs, etc. This contrasts with NQB traffic which is to be treated with the same forwarding priority as Default (and sometimes aggregated with Default), and is intended to be a Best Effort service.

In addition, the lack of a requirement of a guaranteed minimum rate, and the lack of a recommendation to police incoming traffic to such a rate, makes the NQB PHB suitable for implementation in networks where link capacity is not or cannot be guaranteed.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~`










If you partially agree, on the upper part hopefully, let's separate issues and discuss the latter issue (independence of NQB bandwidth from Default load) in a separate thread.


Regards,


Ruediger


-----Ursprüngliche Nachricht-----
Von: Greg White <[e-mail] <mailto:[e-mail]>>
Gesendet: Donnerstag, 5. Oktober 2023 00: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


Ok, perhaps this text would work better...


Draft-19 Existing (Appendix B):
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.


Proposed:
As a result any rate R that is configured for the NQB PHB is shared equally with Default traffic. Thus, the NQB PHB does not guarantee any serving rate for NQB-marked traffic that is independent of the offered load of Default traffic.




Also...


Draft-19 Existing (section 5.1):
A node supporting the NQB PHB SHOULD NOT rate limit or rate police the aggregate of NQB traffic separately from Default traffic.


Proposed:
A node supporting the NQB PHB SHOULD NOT rate limit or rate police the aggregate of NQB traffic separately from Default traffic. A node supporting the NQB PHB SHOULD NOT provide a bandwidth guarantee or reservation for the aggregate of NQB traffic that is separate from that which is provided for Default traffic. Any rate limit or reserved rate that is configured for Default traffic SHOULD be shared with NQB-marked traffic.




Do you think that covers it?


-Greg








On 10/4/23, 2:51 AM, "[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>" <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:




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 <https://datatracker.ietf.org/doc/html/rfc2474#section-4.1> <https://datatracker.ietf.org/doc/html/rfc2474#section-4.1> <https://datatracker.ietf.org/doc/html/rfc2474#section-4.1&gt;>
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 <https://datatracker.ietf.org/doc/html/rfc4594#section-1.5.1> <https://datatracker.ietf.org/doc/html/rfc4594#section-1.5.1> <https://datatracker.ietf.org/doc/html/rfc4594#section-1.5.1&gt;>
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] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
Gesendet: Samstag, 30. September 2023 01:18
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]>>; [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,








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/ <https://mailarchive.ietf.org/arch/msg/tsvwg/jSHOYp_MA3JuuUXpym-Tg9lHgFU/> ----------- <https://mailarchive.ietf.org/arch/msg/tsvwg/jSHOYp_MA3JuuUXpym-Tg9lHgFU/&nbsp;&nbsp;-----------> <https://mailarchive.ietf.org/arch/msg/tsvwg/jSHOYp_MA3JuuUXpym-Tg9lHgFU/&amp;nbsp;&amp;nbsp;-----------&gt;> 








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 <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html#section-5.1> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html#section-5.1> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html#section-5.1&gt;> 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 <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html#appendix-B> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html#appendix-B> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html#appendix-B&gt;>) 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/ <https://mailarchive.ietf.org/arch/msg/tsvwg/QFhiliqsR5XyZ_-VaSNxIRgUWs4/> ----------------- <https://mailarchive.ietf.org/arch/msg/tsvwg/QFhiliqsR5XyZ_-VaSNxIRgUWs4/&nbsp;&nbsp;-----------------> <https://mailarchive.ietf.org/arch/msg/tsvwg/QFhiliqsR5XyZ_-VaSNxIRgUWs4/&amp;nbsp;&amp;nbsp;-----------------&gt;>








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








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




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]>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> <mailto:[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, 30. August 2023 23:34
An: Geib, Rüdiger <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> <mailto:[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]>>> <mailto:[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]>>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[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]>>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> <mailto:[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]>>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> <mailto:[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;> <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;> <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;> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#EF&amp;gt;&gt;> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#EF&amp;amp;gt;&amp;gt;&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;> <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;> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#EF&amp;gt;&gt;> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#EF&amp;amp;gt;&amp;gt;&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;> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#EF&amp;gt;&gt;> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#EF&amp;amp;gt;&amp;gt;&gt;> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#EF&amp;gt;&gt;> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#EF&amp;amp;gt;&amp;gt;&gt;> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#EF&amp;amp;gt;&amp;gt;&gt;> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#EF&amp;amp;amp;gt;&amp;amp;gt;&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]>>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> <mailto:[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]>>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> <mailto:[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]>>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> <mailto:[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]>>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> <mailto:[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;> <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;> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&gt;> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&amp;gt;&gt;> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&amp;gt;&gt;> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&amp;amp;gt;&amp;gt;&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;> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&gt;> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&amp;gt;&gt;> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&amp;gt;&gt;> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&amp;amp;gt;&amp;gt;&gt;> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&gt;> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&amp;gt;&gt;> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&amp;gt;&gt;> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&amp;amp;gt;&amp;gt;&gt;> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&amp;gt;&gt;> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&amp;amp;gt;&amp;gt;&gt;> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&amp;amp;gt;&amp;gt;&gt;> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&amp;amp;amp;gt;&amp;amp;gt;&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;> <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;> <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;> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html&amp;gt;&gt;> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html&amp;amp;gt;&amp;gt;&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;> <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;> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html&amp;gt;&gt;> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html&amp;amp;gt;&amp;gt;&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;> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html&amp;gt;&gt;> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html&amp;amp;gt;&amp;gt;&gt;> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html&amp;gt;&gt;> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html&amp;amp;gt;&amp;gt;&gt;> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html&amp;amp;gt;&amp;gt;&gt;> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html&amp;amp;amp;gt;&amp;amp;gt;&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;> <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;> <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;> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19&amp;gt;&gt;> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19&amp;amp;gt;&amp;gt;&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;> <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;> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19&amp;gt;&gt;> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19&amp;amp;gt;&amp;gt;&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;> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19&amp;gt;&gt;> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19&amp;amp;gt;&amp;gt;&gt;> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19&amp;gt;&gt;> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19&amp;amp;gt;&amp;gt;&gt;> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19&amp;amp;gt;&amp;gt;&gt;> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19&amp;amp;amp;gt;&amp;amp;gt;&amp;gt;&gt;>
































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