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

[Sebastian Moeller <[e-mail]>]

Hi Greg,


> On Mar 12, 2023, at 21:23, Greg White <[e-mail]> wrote:
> 
> 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.

But NQB claims to work without prioritization (in the abstract: "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.") while at the same time seems to encompass building two separate queues and delivering preferentially from one, which is pretty close to the dictionary definition of prioritization e.g. here https://dictionary.cambridge.org/dictionary/english/prioritize?q=prioritization
"to decide which of a group of things are the most important so that you can deal with them first"

I would really like to hear what the NQB definition actually is that promises to achieve the effects of prioritization without doing prioritization. I claim that this is simply impossible unless you define as "prioritization" one specific technique of giving preferential delivery to NQB packets that you avoid, while not encompassing those prioritization methods that your proposed NQB scheduler actually relies on. My gut feeling is that you consider only unconditional strict prioritization (aka precedence) as "prioritization", but that is not clear from the draft.

To repeat my self, if I build a scheduler that does round robin packet-by-packet or quantum-by-quantum sharing between to queues with traffic of two different classes, the class with less packets/quanta will effectively be prioritized over the class with more packets/quanta (each packet will see on average a shorter sojourn time). And that seems to be pretty much what the NQB system boils down to. I can understand not calling this unlimited prioritization, but claiming that works "without prioritization" requires IMHO proof how you achieve the impossible. Same for the lack of rate limiting, unless NQB traffic is limited to a "smallish" fraction of the bottleneck capacity you can not really guarantee expedited forwarding at all. If all traffic is NQB you are back to a simple FIFO with a dual queue design... . How do you assert that not all traffic is NQB without some direct or indirect method of limiting the fraction of NQB traffic of the essentially unknown (to the endpoint) bottleneck capacity?

My take is that either NQB fails to deliver on its promise of what it delivers to the application or on the "promise" bout what its implementation does not.

I consider it important that RFCs actually are as truthful as reasonable possible and stick to existing definitions, and if they do not offer their own clear definitions of terms that are used with non-standard meaning.

I bring this up here, as just as EF can only deliver its promises under certain conditions, aka by the EF capacity being over-provisioned so it never self-congests, so can NQB only deliver lower-latency and low-jitter delivery if given priority over the competing traffic.


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

	I accept that desire, but how does NQB deliver on its promises that are pretty close to what EF promises, while at the same time rejecting the methods that EF requires to assert its guarantees?

Sebastian

P.S.: This is orthogonal to the fact that over WiFi both proposed methods, configuring NGWB to use AC_VI or re-configuring the EDCA parameters of AC_VI as effectively a secondary AC_BE class to be round-robin scheduled with the existing AC_BE. See above how this still is a form of prioritization, namely of the AC with less traffic. And this prioritization is absolutely required as the goal of lower- than-QB latency and jitter can NOT be delivered with out differential treatment of NQB over QB, and that process is (a form of) prioritization.


> 
> -Greg
> 
> 
> 
> On 2/3/23, 1:00 AM, "[e-mail] <mailto:[e-mail]>" <[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> (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]>> Im Auftrag von [e-mail] <mailto:[e-mail]>
> Gesendet: Donnerstag, 12. Januar 2023 01:34
> An: [e-mail] <mailto:[e-mail]>
> Cc: [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/>
> 
> 
> 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>
> 
> 
> 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>
> 
> 
> 
> 
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
> 
> 
> 
> 
> 
> 
>