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

[Sebastian Moeller <[e-mail]>]

Hi Greg,


> On Mar 14, 2023, at 23:09, Greg White <[e-mail]> wrote:
> 
> Sebastian,
> 
> You are redefining words now to suit your arguments.

	[SM] Which words? Specifics please. I am pretty clear about what I consider to be prioritization and I backed this up with a definition from a dictionary, So this is not something I made up but something where I asked myself, "is my intuition what prioritization means, actually correct?" and looking into dictionaries convinced me that I am pretty much right in its meaning.

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

	[SM] I disagree. I asked this before on the list and literally NOBODY jumped on this and told me that only strict precedence is considered priority, which would be expected if network expert natuarlly would equate prioritization with strict precedence. But even if there is a consensus, you are fighting very hard instead of simply chanhing the abstract to read "without strict prioritization" which would be one way to solve the issue in a way that works with but the implicit meaning for network engineers and readers from other fields. In a "dialog" this is how such issues can often resolved, by some sort of synthesis/compromise... 
	Eventually Gorry replied with the reference to the term "priority queueing", which is as you might note not a definition of "prioritization" in general. If you mean priority queueing in the abstract, then please use the exact term (as you are now on note that what you wrote is not universally understood as you seem to intend it). Or give a definition in the draft for what you mean exactly by the term prioritization. It is IMHO not unreasonable having to define one's nomenclature, especially if this nomenclature re-uses existing words.
	I note you also called what WiFI does with its ACs as "stochastic prioritization" even though this, as you remarked there is not strict precedence either, yet you termed it a form of "prioritization".
	In all honesty, I think I would not object to call what you are attempting to do here as "redefining words to suit [your] argument". 


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

	[SM] Yes, I would have no issue with calling this a conditional priority scheduler, albeit with a pretty sophisticated dynamic re-prioritization scheme. Your point being? The goal for fq schedulers generally is to allow each "flow" to get up to the equitable share of available capacity. Packets in a flow still below its equitable share* and increasing its send rate needs to be conditionally prioritized over packets of flows that are already at their capacity (I gloss over some dynamics here). Once flows reach their capacity share they are equally prioritized with other flows in that state. However a flow will only be able to gain its equitable share of capacity.
	In your 2 class design a flow in the shallow queue will be able to get 50% of capacity (under some conditions) and if there are more than 1 flows in the deep queue this will result in noticeable inequality in throughput, but that only as an aside why class based scheduling is inherently at odds with the general treat flow equally goal for the internet...

*) equitable share is slightly more intricate than capacity/number of flows and depends on whether flows actually use their allotted share, but in your example that does not matter much...


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

	[SM] Yes I agree that for an FQ scheduler that perspective is not terribly helpful albeit not wrong either**. But you are not proposing an FQ scheduler at all, but a simple 2 class scheduler and there these complications do not exist, so this looks like a distraction to me.
	And to add to my observations before, if the NQB queue is shallow the QB queue is deep and NQB than under most conditions it is almost guaranteed that the NQB queue is going to be smaller than the QB queue, resulting in pretty reliable conditional priority of NQB packets over QB packets... And that is actually required and unavoidable as the goal is lower latency service for NQB... so there really is no alternative to conditional prioritization if NQB is to reach its goals. 
	Really, I consider this resistance to either drop or refine the "without prioritozation" claim absurd***, the reason for the 2 class scheduler is to give NQB packets better service, and this only works by doing what the dictionary calls prioritization, so not calling it prioritization obfuscates matter. Let me ask you directly, why do you seem to be hell bent of not calling this spade a spade. I have two explanations for this, none of them all that flattering to you, but I want to give you a chance to explain your rationale.


**) It is however not the simplest or most intuitive way to describe how an fq scheduler achieves its goals.

***) Also a sign that you, qquite disrespectful actually, stopped discussing with me and switched to debating me...

Regards
	Sebastian



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