Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-19.txt

[Greg White <[e-mail]>]

How about:

A node supporting the NQB PHB that provides rate limits or rate guarantees for Default traffic SHOULD ensure that such limits and/or guarantees are shared with NQB traffic in a fair manner. This could be supported using a hierarchical scheduler where the rate limits and guarantees are configured on a parent class, and the two queues (Default and NQB) are arranged as the children of the parent class and given equal access to the capacity configured for the parent class (e.g. with equal DRR scheduling).

-Greg





On 10/9/23, 12:57 AM, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>> wrote:


Hi Greg,


thanks. You write:


"The NQB PHB describes a hierarchical structure that associates the two queues, provides rate shaping/guarantees to the aggregate, and provides DRR scheduling between them."


Please change or add text in the draft clarifying that. I've yet missed text or at least a hint, that the design is preferably by a hierarchical scheduler. If other options are valid but not recommended, please be sufficiently clear in the text. An example:


Hierarchical
Parent Default: 10% of linerate
NQB: 50% of parent rate
Default: 50% of parent rate


Assuming the aim is to operate Default traffic in sum by 10% of the linerate, an alternative (largely identical by scheduling) to me is 
NQB: 5% of linerate
Default: 5% of linerate


If this draft is to technology agnostic, the functionality should be described, text example (:
The parent Default scheduler capacity is shared equally by Default and NQB traffic (e.g., by configuring equal DRR scheduling between them). 
Pick a different term, if "parent Default scheduler capacity" isn't your preferred one - it just should be clear, what it is called.


If you prefer NQB not to be technology agnostic, the text should state that explicitely. Example: NQB is preferably implemented by weight based scheduling mechanisms, like DRR.


Regards,


Ruediger




-----Ursprüngliche Nachricht-----
Von: Greg White <[e-mail] <mailto:[e-mail]>> 
Gesendet: Freitag, 6. Oktober 2023 02:54
An: Geib, Rüdiger <[e-mail] <mailto:[e-mail]>>
Cc: [e-mail] <mailto:[e-mail]>
Betreff: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-19.txt


Hi Ruediger,


Please see below. 
BTW I'm trimming some of the earlier messages from this post.


-Greg




On 10/5/23, 1:47 AM, "[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>" <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:


Hi Greg,


thanks, the proposed text is better.


Proposed GW:
As a result any rate R that is configured for the NQB PHB is shared equally with Default traffic.


Alternative proposed RG:
As a result any rate or weight R that is configured for the NQB PHB is identically configured equally for the Default PHB. Also the access to spare excess capacity is configured identical for both PHBs, if explicit configuration is supported.


RG: Sharing: I agree, that by identical configuration and picking a suitable queuing mechanism (e.g., D/WRR, WFQ), two identically configured queues share resources. But I think the point is "identical" configuration. I further extended that to access to excess capacity (unused by another queue, if present). Some vendors offer explicit commands, like access-to-spare-capacity-priority "low/high" for a particular queue. 


[GW] I don't believe that is true in general (or in the case of the equipment that you are concerned with). For example, two queues that are each identically given a guaranteed 10% of the egress link rate don't (in general) share that guarantee. When they are both saturated and the link is saturated, the aggregate of the two will be guaranteed 20% of the egress link rate, not 10%. Similarly, two queues that are each configured identically with a rate limit of 30% of the link rate will not generally share that limit. When they are both saturated and the link is not saturated, they will in aggregate consume 60% of the link rate, not 30%. The NQB PHB describes a hierarchical structure that associates the two queues, provides rate shaping/guarantees to the aggregate, and provides DRR scheduling between them. Linux htb and DOCSIS ASFs and many network devices implement this hierarchical mechanism explicitly (some call it 'hierarchical class of service' or 'hierarchical quality of service'). In some cases, the same end result can be achieved in equipment that does not support hierarchical structures - but it is not possible in all situations, and it requires more than simply setting the parameters to be the same between the queues. I am comfortable with defining the NQB PHB under the assumption that a hierarchical mechanism exists in the node, and not spending a lot of time on the details of configuration (and limitations) in the case that it doesn't.


[GW] To that end, would you agree with a statement in 5.1 such as:
Support for the NQB PHB can be achieved in a hierarchical scheduling system by configuring two queues (one for NQB, the other for Default) that equally share the rate (limit and/or guarantee) of a parent class, and don't themselves have a rate (limit or guarantee) configured. In certain situations, it may also be possible to support the NQB PHB in equipment that does not support hierarchical scheduling. 








RG: I'm having trouble with the following sentence and prefer it to be deleted:
Thus, the NQB PHB does not guarantee any serving rate for NQB-marked traffic that is independent of the offered load of Default traffic.




RG: If there's a minimum bandwidth guarantee for Default PHB, there's a minimum bandwidth guarantee for NQB PHB too. A configuration where this doesn't hold would consist of an NQB/Default PHB based on access permission to excess bandwidth only AND the consumption of all spare resources up to full line capacity by suitable configuration other PHBs. No doubt, such a configuration is feasible. But assuming it to be present and a pre-condition before NQB is deployed requires an explicit statement by the draft, I think. I'd like to point to the RFCs I've referenced to again, stating that Default PHB config should avoid starvation or have a small guaranteed bandwidth, respectively. In that case, the same would obviously hold for NQB (which then receives a *limited but existing* bandwidth served independent of the load of the Default PHB).




If you partially agree, on the upper part hopefully, let's separate issues and discuss the latter issue (independence of NQB bandwidth from Default load) in a separate thread.




Regards,




Ruediger