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

[Sebastian Moeller <[e-mail]>]

Hi Gorry

> On Feb 22, 2023, at 12:19, Gorry Fairhurst <[e-mail]> wrote:
> 
> On 22/02/2023 11:13, Sebastian Moeller wrote:
>> 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?
>> 
> Of course - a DSCP identified traffic to be treated differentially from other traffic,.
>>> 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
>>> 
> This seems like it be a discussion on what you think prioritisation means within diffserv.

	[SM4] I am not sure I share your assessment, IMHO this is a discussion about what "without prioritization" means in the abstract and whether that is a veridical claim. Here is the text:
"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"

If we agree that differential treatment of DSCP identified traffic is equivalent with some sort of prioritization (and when we are talking about low-delay I argue we deal with prioritization), then the last sentence above seems incorrect/unachievable. A second queue alone is not enough to "avoid the latency, latency variation and loss caused by such traffic [QB]", you need selective scheduling between these queues to reach that goal. E.g. If I would dequeue proportional to the size of the respective queue, both queues would see similar delay variations; if I dequeue round-robin between the queues the queue with less traffic/flows would get priority over the other and see on average lower delays. Is any of this contentious?

So this seems not described as an "aspirational goal", but as a fact ("is implemented"). I personally would like to see substantiating evidence for that sentence or have that sentence changed to fit with how the actual implementation works. Or a definition what the drat considers to be "priro

Regards
	Sebastian

P.S.: I am still open for explanations how one can give one class reliable lower-latency access to a medium (which is the corollary of "avoid the latency, latency variation and loss caused by such" other classes, in effect the NQB class is supposed to get lower-latency service) without giving other class(es) higher-latency and how this "better" medium-access is not a form of prioritization. 

P.P.S.: If an IETF draft states "without prioritization" I want be able to rely on that and not having to scrutinize which limited definition of prioritization was used and how/if the draft actually manages to achieve that.


> 
> Gorry
> 
>