Challenge: CB-WFQ Bandwidth+Police behavior
I have to admit I was somewhat surprised by the lab test results I’ve published in my previous CB-WFQ post. It looks like we’ve been fed misleading information about (classic) CB-WFQ behavior for years.
Don’t tell me that things are completely different with HQF implemented in IOS releases 12.4(late)T and 15.0. I know that … but 95+% of the installed base do not use those releases.
Let’s see whether you can figure out what my next lab test results showed. I’ve been running three parallel TTCP sessions on ports 5001, 5002 and 5003 across a 256 kbit point-to-point link. Here’s the relevant part of my router configuration:
policy-map WAN
class P5001
bandwidth percent 50
class P5002
police rate percent 50
violate-action drop
!
interface Serial0/1/0
bandwidth 256
clock rate 256000
ip address 10.0.6.1 255.255.255.252
encapsulation ppp
ip ospf 1 area 0
load-interval 30
service-policy output WAN
TTCP is a program that sends meaningless data across a TCP session. It’s a nice load to use in a QoS test, as it uses TCP stack (ensuring it behaves like a real application) but still sends the data as fast as possible (as it spends no time generating it).
What would be your answers to these questions?
- A single TTCP session is running on port 5001. How much bandwidth does it get?
- A single TTCP session is running on port 5002. How much bandwidth does it get?
- Three parallel TTCP sessions are running on ports 5001, 5002 and 5003. How much bandwidth does each session get?
Try to find the answer before reading the solution.
* A single TTCP session is running on port 5002. How much bandwidth does it get? 50%
* Three parallel TTCP sessions are running on ports 5001, 5002 and 5003. How much bandwidth does each session get?
5001 - 4x%
5002 - 4x%
5003 - ~5%
100% from availabe bw.
* A single TTCP session is running on port 5002. How much bandwidth does it get?
50% from 256 kbps
* Three parallel TTCP sessions are running on ports 5001, 5002 and 5003.
5001 ~ 50% to 100% from available bw.
5002 ~ no more then 128kbps. most probably near by 0%
5003 ~ most probably near by 0%
I think the biggest problem is the misconception of what each of these lines do. To be clear:
class P5001
bandwidth percent 50
Guarantees 50 percent of the band width but does not restrict it to only 50 percent.
class P5002
police rate percent 50
violate-action drop
Restricts to no more than 50 percent of the bandwidth but does not guarantee any.
So, basically, CB-WFQ does exactly what it is supposed to do with the configurations you've posted.
1) Gauranteed 50% during congestion, can use up to 100%.
2) Limited to 50% period.
3) 5003 AND 5002 split the available remaining bandwidth after 5001 has been provided it's gauranteed 50%.
That's what I would expect anyways.
2) 50%
3) 5001 - 75% (50% + 50% of remaining unallocated)
5002 - 12.5%
5003 - 12.5%
The link i provided in my previous post demostrates how that stuff works in pre-HQF implementations.
Petr
2) ~20%. The drops will cause the TCP session to under utilize it's offered bw.
3) The port 5001 session gets 50% and then the 5001 and 5002 share the remaning. So, 5001 gets ~75%, 5002 ges ~25% but 5003 won't get any bw since it has lower priority than any configured class.
A single TTCP session is running on port 5002, this will get up to 50% of 256kps bw standard.
One thing I think is missing from the previous comments is that there is no command regarding maximum BW available.. And by default 25% will be left available for the default class!!
Three parallel TTCP sessions are running on ports 5001, 5002 and 5003.
5001 ~ guaranteed 50% of 75% of 256kps
5002 ~ no more than 50% of 256kbps.
5003 ~ guaranteed 25%