I can’t hang the idea as stuff getting realy messed up and oppose each other.
From my understanding, the LLQ should be served immidiaetly when traffic queue in it while congestion occurs.
If the queues work by percentage, then the PQ might have 100Mbps capacity (10%) , and 2nd queue has 500Mbps capacity (50%), and the 3rd queue will have 400Mbps (40%) capacity.
Lets assume that there’s been a congestion and now traffic will start to buffer up , the interface is capable to transmit 1Gbps and there is extra 50Mbps in the queues, and just before about dropping packets from the buffers being full , the interface can start to transmit the queued data - so what will / can happen?
one option would be that the first 20Mb will refer to the PQ and will be transmitted, after that, another 30Mbps in the 2nd queue should be served but as soon as 20Mbps of traffic has been served, the PQ gets another 100Mbps in it to be served , so the router should stop forwarding the data in the 2nd queue and immidiaetly start to serve again the PQ for 100Mbps.
In this scenario the PQ will serve a total of 120Mbps instead of the 100Mbps limit that configured as the Implicit policer’s bucket should have replenished its tokens while the 2nd queue was active for serving those pitifull 20Mbps.
Those, I can’t understand the statement you said about that each queue can be taking the exact % of Bandwidth which it configured for , as in actual practice the PQ was configured for 10% but served 12% total and the 2nd queue’s serving had to be stopped in the middle of the operation in my theory which reflect my understanding about the LLQ operation and how policers and shapers should be working like.
Another thing that doesn’t sound quite right is that the queues will use TDM mechanism to utilize the BW - this way the entire link won’t be used at all for 80Mbps of traffic as it was scheduled to serve only the PQ for 10% of the time since the congestion occured ,and the PQ had only 20Mb in it.