[tsvwg] Comments draft-ietf-tsvwg-nqb-15

[Gorry Fairhurst <[e-mail]>]

On 22/02/2023 08:43, Sebastian Moeller wrote:
> Hi Gorry,
>
> to clarify:
>
>> On Feb 22, 2023, at 09:06, Gorry Fairhurst <[e-mail]> wrote:
>>
>> On 22/02/2023 07:51, Sebastian Moeller wrote:
>>> Hi Gory,
>>>
>>> see [SM] below one important comment on your point 2) and a few drive by comments on other points as well.
>>>
>> Thanks Sebastian,
>>
>> I see you disagree on the intended goal of the work, in (2), and I note the comment in your previous emails sent to this list. I'll leave it to the document editors to refelect and decide how to revise based on the comments received at this particular stage.
> The abstact says:
> "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"
>
> That does not appear to be a description of a mere goal, but a claim of what the draft delivers, no? And I would very much expect an explanation how this is supposed to work.
> To state how I understand the principle involved here:
> 1) NQB promises reliable lower-latency, by isolating NQB traffic from QB traffic. This means, lower (than average) queueing delay for NQB packets and that in turn means some other traffic will be delayed longer (than e.g. expected for a hard round-robin per flow scheduler let alone a simple FIFO). That in essence is what prioritization is all about, treating things consistently differently. So to pose this as a simple question:
>
> QUESTION: How to you give some packets higher priority without some sort of differential treatment, aka prioritization?
>
> To elaborate, if such a prioritization system is somehow bound (e.g. by queue protection) at its heart in its normal regime it still will prioritoze NQB traffic over QB traffic and hence will still work via prioritization.
>
> Now, it is well possible that I am just showing my incompetence and lack og knowledge here, but if so, please enlighten me how to square that apparent circle?
>
>
>
>
> Regards
> 	Sebastian

Differentiated services is all about flow differentiation, so I'd expect 
the ability to offer different treatement for each traffic class. 
Clearly if this proposed a treatment that placed the packets ahead of AF 
or some other recognised PHB  (other than LE), then this would I think 
of this as a priority access to capacity. I think in this case, the 
packets are schduled as a part of Default treatment. I think we need to 
let the editors propose text.

Gorry