You are heartily welcome.
Regarding the show policy-map interface command output you have highlighted, that is logical and correct. The CBWFQ is actually built upon WFQ. However, whereas WFQ classifies flows automatically and on its own, in CBWFQ, the classification is done by you (or more precisely, by class-maps) and each non-default queue is given its own single conversation queue. In essence, each class in a policy-map is given its own queue. Thus, a policy-map is a system of queues. The weight of each queue is calculated as interface bandwidth divided by the class bandwidth. Now, you have all you need for running WFQ on these queues - they have their weights and there is a mechanism for classifying packets into these queues. The WFQ does not run inside these queues, rather it runs using these queues as the only queues it works with.
The only exception here is the default class, as within this class, the WFQ makes also its subsequent classification and uses its own conversation queues to schedule packets.
Therefore, the CBWFQ can be seen as a WFQ in which the automatic classification has been replaced by user-created classes and in which the weights are assigned to classes, not to individual packets. After this, the principle of scheduling packets is the same as with plain WFQ - the packets with the lowest sequence numbers will be served first.
You may be interested in reading this article, it does contain a rough info about the CBWFQ:
In this case, if i have different traffic flows, then ultimately all will be in class-default only.Thus, that much flows may be created inside class-default. Here what is the tool used to drop the excess flows as CDT does in typical WFQ??
There are several mechanisms here:
- You can use the command queue-limit to define the maximum size of the entire default queue (encompassing all conversation queues if the WFQ is activated in the default queue)
- You can use the WRED on the entire default queue to provision for proactive random-based drops before the queue is full
Note that if you know there are some flows that may behave badly, or which require a special treatment you should not put them into the default class but rather make a special class for them and set the QoS provisions separately. The default queue should be considered as best effort queue. The router will try to give all flows a fair treatment but with no special guarantees. If you want such guarantees then the flow is not supposed to be in the default queue.
Also note that even if there was no CDT, the WFQ mechanism itself would be working fair enough because its principle is always to service the queue that has been the most neglected (the so-called max-min fairness). What CDT does is an additional improvement - if a packet arrives that is over limit but that can be managed to be sent in time then fine - let it go, at the expense of some other packet that would be so or so sent later. The WFQ in Cisco implementation, as activated directly on an interface, is basically a closed and untweakable solution - you cannot modify its basic behavior - so it tries to be as smart as possible. The CDT in plain WFQ helps to ensure that a higher priority packet arriving later can still be queued at the expense of other packets in different queues. You can do this in CBWFQ by having a separate class for such packets, whereas in WFQ, it had to somehow deal with it alone. The CDT is a fine concept in plain WFQ with many implications. However, with the advent of CBWFQ, it is in a sense superfluous.
NOTE: Initial topic (CDT > HQ) is still not clarified. please help, however efforts has been taken from my side to get the answer
Well, sometimes, the most simple answer is the closest to the truth - perhaps we are trying to find a sophisticated answer to a plain fact - the sanity check on the relation between the CDT and HQ simply isn't implemented in IOS. Perhaps the implementors forgot to do it, perhaps they didn't want to do it as you can use it to effectively deactivate the CDT... There are several places in the IOS CLI where it is up to you to enter sane values and the IOS will not try to outsmart you and tell you that your are wrong. This might be just one of those.