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

[Sebastian Moeller <[e-mail]>]

Dear list,


"Finally, some jurisdictions impose regulations that limit the ability of networks to provide differentiation of services, in large part based on the belief that doing so necessarily involves prioritization or privileged access to bandwidth, and thus a benefit to one class of traffic always comes at the expense of another.

In contrast, the NQB PHB has been designed with the goal that it avoids many of these issues, and thus could conceivably be deployed end-to-end across the Internet."

I have two issues with adding this paragraph:

A) NQB very much prioritizes NQB traffic over QB traffic, see my ample posts about how this is, and why this is the ONLY way to deliver lower delay and jitter.


And indeed if we read:
"Also, the NQB traffic is to be given a separate queue with priority equal to default traffic and given no reserved bandwidth other than the bandwidth that it shares with default traffic."

It becomes clear that NQB will actually be given increased priority on a per-packet basis as long as the NQB traffic share is below 50% of capacity ("equal" priority) if there are fewer NQB using flows than QB using flows, the NQB flow is essentially prioritized against QB flows. With NQB implementing a shallow queue and QB a deep queue it is hard to imagine scenarios where NQB sees sustained higher traffic volumes than QB under saturating loads.


B) I do not think that a RFC is the appropriate place to give essentially legal advise that has not been tested by any coutrt in any jurisdiction. Especially given the claim is "avoids many of these issues" which seems problematic for deploying NQB in some jurisdictions.

Regards
	Sebastian

P.S.: The claim "a benefit to one class of traffic always comes at the expense of another" seems pretty much apply 1:1 to NQB, under load for every NQB packet getting shorter sojourn time other QB packet(s) will by necessity experience longer sojourn times, as this is essentially a zero-sum game.

QUESTION: Anybody disagreeing that scheduling under load is a zero-sum game please point me to references showing that this is wrong.



> On Jan 12, 2023, at 01:46, Greg White <[e-mail]> wrote:
> 
> All,
> 
> I've posted an updated NQB draft that I believe addresses all of the comments that had been submitted during WGLC. I'll write up a summary of the changes shortly, but in the interim I wanted to provide a better diff link than the one auto-generated by the draft submission tool (which currently seems to have some problems).
> https://author-tools.ietf.org/diff?doc_1=draft-ietf-tsvwg-nqb-15&rfcdiff=1
> 
> Best Regards,
> Greg
> 
> 
> 
> 
> On 1/11/23, 5:34 PM, "tsvwg on behalf of [e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]> on behalf of [e-mail] <mailto:[e-mail]>> wrote:
> 
> 
> 
> 
> 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