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

[Sebastian Moeller <[e-mail]>]

Hi Gorry,

> On Feb 22, 2023, at 11:15, Gorry Fairhurst <[e-mail]> wrote:
> 
> 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.

	[SM3] Good so we agree on differential treatment being part of the NQB PHB then?

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

	[SM3] But we are essentially dealing with a proposal the prioritizes NQB over BE (assuming that most QB traffic will end up in BE, if that is not intended the draft seems to miss a discussion about how to deal with different PHBs for QB, and what to do under saturating loads, should NQB be granted low latency independent of QB's priority or just over QB packets in the same priority tier).

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

	[SM3] How can this be? How can you ensure lower-delay service (which I read to be the NQB promise), without giving some sort of priority access? The way I see it on can not give any low latency guarantees for NQB over QB unless you at some level prioritize NQB packets over QB packets.(As Ruediger mentioned this is "possible" if there is no queueing at all due to capacity not being exceeded, but that is not the scenario the NQB PHB seems to be designed for). So I would expect that the NQB draft does not claim to deliver NQB packets at lower delay than QB packets without prioritization at least not without a formal proof how this apparently impossible feat is to be performed. 

Sure we can play semantic games here: e.g. asking is giving the QB and NQB classes nominally equal priority to access a medium a form of prioritization? To which I would say, as long as the class priorities do not match the traffic volumes (either in bytes or packet rate depending on what is the limiting factor) the class with volume-share below scheduler-share is essentially given priority over the other, as any packet of that class has a higher probability of being forwarded faster than any packet of the other class.
This is BTW how I assume the "non-priority" way of re-configuring AC_VI into effectively a second AC_BE proposed in the draft works, both "AC_BEs" will have equal medium access probability but NQB traffic is supposed to be only a low single digit percentage of capacity...

Mind you the fix as I see it for this issue is simply to drop the claims NQB would achieve its smooth low-latency for NQB traffic "without prioritization". I am open to to a rationale as well, why this is not prioritization, but I am rather skeptical that will work for the saturated link case.

Regards
	Sebastian


> 
> Gorry
>