Re: [tsvwg] draft-ietf-tsvwg-nqb-15.txt - 5.1 Primary Requirements, Forwarding

[Greg White <[e-mail]>]

Hi Ruediger,

FYI I've added an issue in the GitHub tracker to ensure this gets resolved.
https://github.com/gwhiteCL/NQBdraft/issues/32


I'll try to answer your question.

[RFC2598]: The EF PHB is defined as a forwarding treatment for a particular
   diffserv aggregate where the departure rate of the aggregate's
   packets from any diffserv node must equal or exceed a configurable
   rate. The EF traffic SHOULD receive this rate independent of the
   intensity of any other traffic attempting to transit the node.  It
   SHOULD average at least the configured rate when measured over any
   time interval equal to or longer than the time it takes to send an
   output link MTU sized packet at the configured rate.  (Behavior at
   time scales shorter than a packet time at the configured rate is
   deliberately not specified.) The configured minimum rate MUST be
   settable by a network administrator (using whatever mechanism the
   node supports for non-volatile configuration).

[NQB]: ... the NQB PHB provides a shallow-buffered, best-effort service as a complement to a Default deep-buffered best-effort service. ... A node supporting the NQB PHB makes no guarantees on latency or data rate for NQB-marked flows, but instead aims to provide an upper-bound to queuing delay for as many such marked flows as it can and shed load when needed.

So, NQB PHB does not have a configurable departure rate, nor does it guarantee that NQB traffic will receive any particular departure rate, regardless of the presence of other traffic of any intensity.


[RFC2598]: If the EF PHB is implemented by a mechanism that allows unlimited
   preemption of other traffic (e.g., a priority queue), the
   implementation MUST include some means to limit the damage EF traffic
   could inflict on other traffic (e.g., a token bucket rate limiter).
   Traffic that exceeds this limit MUST be discarded. This maximum EF
   rate, and burst size if appropriate, MUST be settable by a network
   administrator (using whatever mechanism the node supports for non-
   volatile configuration). The minimum and maximum rates may be the
   same and configured by a single parameter.

[NQB]: A node supporting the NQB PHB SHOULD NOT rate limit or rate police the aggregate of NQB traffic separately from Default traffic. The NQB queue SHOULD be given equivalent forwarding preference compared to Default. The node SHOULD provide a scheduler that allows NQB and Default traffic to share the link in a fair manner, e.g., a deficit round-robin scheduler with equal weights. .... network elements that support the NQB PHB SHOULD support a "traffic protection" function that can identify flows that are inconsistent with the sender requirements in Section 4.1, and either re-mark those flows/packets as Default and reclassify them to the QB queue or discard the offending traffic. ... it is RECOMMENDED that traffic protection algorithms base their decisions on the detection of actual queuing, as opposed to simply packet arrival rate or data rate.

So, EF is (in effect) given high priority as long as the arrival rate remains below the configured "minimum rate", and in most cases traffic arriving above the configured rate (or possibly a second "maximum EF rate") is discarded.  Whereas NQB is given equivalent priority to Default, regardless of its arrival rate. If a queue begins to form because the arrival rate exceeds the actual departure rate, the PHB is recommended to selectively discard (or reclassify) packets from the flows most responsible for the queue build up.  (there is a separate thread and GitHub issue https://github.com/gwhiteCL/NQBdraft/issues/28 on clarifying the traffic protection requirements)

-Greg




On 3/17/23, 5:32 AM, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>> wrote:


I have no recollection of having asked you to redefine NQB to just be another EF. I'd appreciate if you were answering a technical question by technical arguments.


I've mentioned that both, NQB and EF PHB are specified to offer low delay, low jitter and low loss to either kind of traffic (and I note that NQB contains text that EF traffic may be scheduled by NQB).


You state: " The EF definition is one way to achieve that, the NQB definition is another." Then I expect it to be absolutely simple for you to offer technical text, why the following EF requirements in no way apply for NQB. Please.


The EF PHB is defined as a forwarding treatment for a particular diffserv aggregate where the departure rate of the aggregate's packets from any diffserv node must equal or exceed a configurable rate. The EF traffic SHOULD receive this rate independent of the intensity of any other traffic attempting to transit the node. It SHOULD average at least the configured rate when measured over any time interval equal to or longer than the time it takes to send an output link MTU sized packet at the configured rate. (Behavior at time scales shorter than a packet time at the configured rate is deliberately not specified.) The configured minimum rate MUST be settable by a network administrator (using whatever mechanism the node supports for non-volatile configuration).


Regards,


Ruediger


-----Ursprüngliche Nachricht-----
Von: Greg White <[e-mail] <mailto:[e-mail]>> 
Gesendet: Sonntag, 12. März 2023 21:24
An: Geib, Rüdiger <[e-mail] <mailto:[e-mail]>>
Cc: [e-mail] <mailto:[e-mail]>
Betreff: Re: [tsvwg] draft-ietf-tsvwg-nqb-15.txt - 5.1 Primary Requirements, Forwarding


In order to provide low loss, low latency and low jitter, it is necessary that the queue remain small. The EF definition is one way to achieve that, the NQB definition is another. I am not interested in redefining NQB PHB to just be another EF. So, I don't agree that adding the EF requirements language to the NQB PHB is needed (or desired).


-Greg






On 2/3/23, 1:00 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,




the goal of draft-ietf-tsvwg-nqb is a PHB providing statistically better loss, latency (very low queueing delay, respectively), and jitter performance as compared to the default PHB. 




https://www.rfc-editor.org/rfc/rfc2598.html <https://www.rfc-editor.org/rfc/rfc2598.html> <https://www.rfc-editor.org/rfc/rfc2598.html> <https://www.rfc-editor.org/rfc/rfc2598.html&gt;> (which has been obsoleted) specifies a PHB which can be used to build a low loss, low latency, low jitter ...end-to-end service through DS domains.




Apart from offering similar goals (and recommending similar DSCPs), both share a set of common features, in particular the treatment of aggregates, at least at the bottleneck. RFC2598 determines these common basic requirements as follows:




The EF PHB is defined as a forwarding treatment for a particular diffserv aggregate where the departure rate of the aggregate's packets from any diffserv node must equal or exceed a configurable rate. The EF traffic SHOULD receive this rate independent of the intensity of any other traffic attempting to transit the node. It SHOULD average at least the configured rate when measured over any time interval equal to or longer than the time it takes to send an output link MTU sized packet at the configured rate. (Behavior at time scales shorter than a packet time at the configured rate is deliberately not specified.) The configured minimum rate MUST be settable by a network administrator (using whatever mechanism the node supports for non-volatile configuration).




Low loss, low latency and low jitter REQUIRE the above to hold. Please add that text in section 5.1. "Primary Requirements" of draft NQB and a please add a reference to RFC2598.








Regards,




Ruediger




















-----Ursprüngliche Nachricht-----
Von: tsvwg <[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]>>
Gesendet: Donnerstag, 12. Januar 2023 01:34
An: [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
Cc: [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
Betreff: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-15.txt








A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group 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-15.txt Pages : 25 Date : 2023-01-11




Abstract:
This document specifies properties and characteristics of a Non- Queue-Building Per-Hop Behavior (NQB PHB). The purpose of this NQB PHB is to provide a separate queue that enables smooth, low-data- rate, application-limited traffic flows, 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 flows.








The IETF datatracker status page for this 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;>




There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-15.html <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-15.html> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-15.html> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-15.html&gt;>




A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-15 <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-15> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-15> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-15&gt;>








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