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.

11 comments:

  1. * A single TTCP session is running on port 5001. How much bandwidth does it get? ~100%
    * 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%

    ReplyDelete
  2. * A single TTCP session is running on port 5001.
    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%

    ReplyDelete
  3. I aggree with the posters above.
    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.

    ReplyDelete
  4. Rephrasing what had already been stated:

    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.

    ReplyDelete
  5. 1) 100%
    2) 50%
    3) 5001 - 75% (50% + 50% of remaining unallocated)
    5002 - 12.5%
    5003 - 12.5%

    ReplyDelete
  6. Hehe i remember i've been running the same tests and got pretty much surprised by case (3) :) That result of classic WFQ scheduling is not something one would expect. What I learned from that day is that you should always assign some bandwidth value in case if you want any guarantees - fair queue command in class-default makes sense only when used standalone.

    The link i provided in my previous post demostrates how that stuff works in pre-HQF implementations.

    Petr

    ReplyDelete
  7. 1) ~100%. The router reserves some bw for routing, etc.
    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.

    ReplyDelete
  8. Is it possible to run multiple parallel TTCP sessions from one cisco router to another cisco router? :'(

    ReplyDelete
  9. Sure. You can run one TTCP session on each line (console/VTY) and you can create as many VTY lines as needed on a router.

    ReplyDelete
  10. A single TTCP session is running on port 5001 will be allowed upto 100% from 256kbps bw as there is no congestion.

    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%

    ReplyDelete
  11. Masood Ahmad Shah11 November, 2009 10:11

    FYI :) ttcp is also available on Cisco IOS routers as a hidden command and can be setup as either the sender or receiver.

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.