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

[Greg White <[e-mail]>]

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]>" <[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