Reading âCCIE Practical Studies Vol IIâ by Karl Solie and Leah Lynch, I come across something that seems to be not as I understood it. On page 425, it says:
Each queue is emptied, to its byte or packet limit, and then the next queue is serviced. [...] After a queue's packet or byte size limitation is met, any new packets destined for that queue are dropped.
Again, on page 426 it says:
With CQ, when a queue is full, the last packet in the queue is transmitted before the next queue is serviced. If a queue fills up while waiting for service, and new packets for the queue are dropped.
This is not how I had understood it. The book seems to imply that the byte count and the packet limit are both tail-drop limits, beyond which packets are discarded. Instead, I had always understood that the queue limit (in packets) was a tail-drop limit, whereas the byte-count determined the number of bytes that would be serviced before going on to the next queue in the round-robin, even if the queue was not yet empty.
Consider the command queue-list 1 queue 2 byte-count 3000 limit 20. I thought that this means that each time the queue is serviced, up to 3000 bytes would be taken off the front of the queue and transmitted, and then the scheduler would move on to queue 3, even if queue 2 was not empty yet. If the queue ever gets full at 20 packets, then the next packet would be tail-dropped.
Suppose we are sending packets of exactly 1500 bytes. By my understanding, the scheduler would transmit two packets each round-robin. The queue could hold up to 20 packets, i.e. 30000 bytes. If there are 10 packets in the queue, the scheduler would transmit 2, leaving 8 in the queue until the round-robin comes round again.
- The book says that the byte-count and packet-limit are both about tail drop, and the scheduler empties the whole queue
- I think that the byte-count is about the scheduling from the head of the queue, while the packet-limit is about tail-drop from the back of the queue.
I did my first QoS tests on Custom Queueing in 1999 using a lab setup including a 2 Mbps serial link between two routers and a Smartbits 2000 IP traffic generator to send and receive traffic on two instrument ethernet ports.
I haven't found the test results file but I remember there hadn't been any surprises: the byte counts and the average packet size for each queue defines the bandwidth allocation.
I don't think Cisco changed CQ implementation later.
In the same book later the examples are developed using the usual calculations with byte count and average packet size. (the 9 steps on pages 435 - 439)
Using higher byte-count values lead to a better, more precise, bandwidth allocation
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...