Re: [tsvwg] Response to Sebastian Moeller - on "without prioritization"

[Greg White <[e-mail]>]

Sebastian,

You are redefining words now to suit your arguments.

Dialog only works if the participants agree on the meaning of words. In the parlance of network engineers (and the IETF Transport working group) your definition of priority/prioritize is not correct and not useful.

As a thought experiment, consider an fq scheduler.  For purposes of this thought experiment, I'd like you to imagine one that does not implement the "new flows" mechanism in fq_codel. So, this fq scheduler cycles through the set of queues using DRR with an equal quantum per active queue (let's say 100 B).  Imagine now that only two of the queues are active, and each of them happens to have 100 packets, each of 100 bytes.  The DRR scheduler will alternate between the two queues, forwarding one packet from each queue on each cycle, A,B,A,B,A,B,... correct?  Based on your definition, we'd need to say that this scheduler is a conditional priority scheduler, because it is sending the packets out in a different order than they arrived (unless they just happen to always arrive in that exact order). In fact, we'd need to say that it is deciding to prioritize one queue or the other on a per-packet basis, via some complex function of the individual arrival times of the packets. Or, maybe that it alternates priority between queue A & B on a per-packet basis. Next, extend this thought experiment to an arbitrary number of active queues and arbitrary packet arrivals. 

Now, we *could* define the word priority to mean this. But we don't.  That's not useful.

-Greg




On 3/14/23, 5:03 AM, "Sebastian Moeller" <[e-mail] <mailto:[e-mail]>> wrote:


Hi Gorry,




> On Mar 14, 2023, at 11:29, Gorry Fairhurst <[e-mail] <mailto:[e-mail]>> wrote:
> 
> On 14/03/2023 09:41, Sebastian Moeller wrote:
>> [SM] Disagree, the dual queue method is effectively a conditional prioritization scheme as I have explained before, you fudge with temporal dequeue order of packets based on some class identifier* that is close to the dictionary definition of prioritization. To be explicit that claim NQB as described in the draft would operate "without prioritization"is actively misleading and counter-factual.
>> If you disagree please present the definition of "prioritization" you work against and proof how the proposed scheme does not fall under that definition. Words have common meanings, if you use them counter to that meaning the onus should be on you to explain your terms.
> 
> In terms of DiffServ Service Classes, the proposal is that NQB traffic is treated as a part of the Default treatment.


[SM] I disagree, NQB is conditionally prioritized over all other QB traffic (not sure how this is supposed to work if addition DSCP PHBs are implemented on a node). If I send Qb and QB packets in the same flow I need to expect to observe re-ordering, so these are not treated equally. If NQB would be treated as part of the default they could simply share a single queue. But they can not because NQB packets need to be (conditionally) prioritized over QB packets to deliver on the "isolation"/lower-delay/lower-jitter promise.


That you seem to ignore that part of how NQB actually works concerns/puzzles me considerably.




> Capacity assigned to this class is not prioritised with respect to other classes, AFxx, EF, etc.


[SM] That is absurd, prioritization is about temporal order primarily not capacity. EF for example is not intended to get absolute precedence over other diffserv classes, but to be admission controlled such that the EF traffic never exceeds the assigned EF capacity along a path.
NQB is designed to give lower latency delivery compared to QB traffic, which is the very definition of what prioritization is.




> 
> Of course, Default traffic (i.e. part of the the Best Effort Access Category) marked as NQB could be prioritised with respect to LE. (i.e. the NQB "queue" would be emptied in a priority sequence before the LE "queue").


[SM] The draft might claim that NQB is part of BE, but if NQB packets experience reliably (absolute perfection not required) lower delay an earlier dequeueing than they are not part of the Best Effort Access category. They are marked with a specific non BE DSPC and have a different PHB degined than best effort. If it walks like a duck and quacks like a duck...


> 
> The use of a scheduler within a class would result in some packets that are assigned to the specific class, such as Default traffic, being reordered - i.e., sent before other packets within the same class.


If it would be the same class we would not have:
a) a unique DSCP for NQB (it could just use CS) and be done with)
b) a draft document to describe its specific PHB (as that would not be required for Default, that agin is literally what default means no need to specify anything special)
c) a scheduler that conditionally prioritizes NQB over non-NQB packets.


This set of facts seems to imply that the claim "NQB traffic is treated as a part of the Default treatment" seems problematic.


You are making these arguments up to shut me up mainly, not to improve the NQB draft? 




> Scheduling within a class is always permitted,


[SM] However diffserv uses DSCPs and PHBs to define different classes, and since NQG does not use the Default DSCP or PHB it is effectively not in the same class as Default. And that is based on the described behaviour...


> and routers have many ways to design that besides prioritisation (e.g., flow queues, rate queuing).


[SM] But the draft at hand describes a dual queue design with a conditionally prioritizing dequeue mechanism which treats the NQB class different on average better than the non NQB class. Let's focus in the draft and not the infinite possibility of unexplored alternatives please.




> If you are searching for how the IETF has used these terms, see RFC4594 (e.g., Section 1.4).


[SM] So RFC4594 describes a strict priority scheduler (aka precedence) under the section priority queueing but that is not what people (like me) have in mind when we talk about prioritization*. But if I accept your argument in good faith, then section 1.4.1.2. Rate Queuing becomes relevant, as it describes exactly what NQB proposes to use. In that case that we language lawyer our way to relaying on RFC4594's definition of the term priority queueing (which is not the term used in the abstract, mind you) I ask for haveing it made explicit in the abstract like:


"This PHB is implemented using rate queuing and without priority queuing (see RFC4594) and can be implemented without rate policing, making it suitable for environments where the use of these features is restricted."


Honestly, this looks/feels a bit like a post-hoc constructed justification for the claim in the abstract. 


Sebastian




*) Just look at the dictionary and see that the strict part in the RFC4594 definition for "priority queueing" is not part of the definition of prioritization


> 
> Gorry Fairhurst
> 
> tsvwg Co-Chair
> 
>