RE: QOS Question, Why inflate burst and max burst values?

From: Michael Snyder (msnyder@xxxxxxx)
Date: Sun Aug 11 2002 - 15:23:48 GMT-3


   
Part of the thread I started was if could you use GTS "Traffic-shape
group" vs. "rate-limit output access-group" to police these
requirements? Which I believe we answered as we could do so.

If you substitute the traffic-shape group where you have rate-limit
output access-group, keeping the same access lists and bit values, I
believe it will also work.

In other words, going by it's parameters, the GTS command, seems to be
the grandfather of the rate-limit command.

I have a question about your bit values.

You have:

Bit Rate = x

Burst Size = 3x/16 ; 1.5/8=3/16=.1875

Maximum Burst Size = 3x/8 ; 2(1.5/8)=3/8=.375

Where Burst size is 1.5 times bit rate over 8 and Maximum Burst Size is
twice that value. I understand that 8 comes from the timer interval.

Here's my question. Why (3/16)x for the burst and (3/8)x for the max
burst?

Doesn't that undermine the limiting you are trying to do?

Is it the convention to use 3/16's and 3/8's? If so I'll start using
3/16's and 3/8's, they are easily to remember.

Personally, if I was trying to limit a bit rate, I would use:

Bit rate = x

Burst Size= x/8 (time interval)

Max Burst = 0 (no extra bits on my watch)

Could someone enlighten me, if we are trying to limit something, why
would we inflate the burst and max burst sizes?

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Glenn Johnson
Sent: Sunday, August 11, 2002 11:44 AM
To: ccielab@groupstudy.com
Subject: RE: QOS Question from Routopia LAB 3

Quoting original problem --

; Configure the serial interface on R6 so that Ping
; traffic can only
; utilize 10% of available bandwidth. Allow BGP to
; utilize no more
; than 20% of available bandwidth. Allow all other
; traffic to utilize up
; to 70% of available link capacity.

I'm _far_ from a QoS expert, but wouldn't three separate rate-limit
statements work? (you could add three more if 'input' control was an
issue as well -- something you can't do with CBWFQ, which seems limited
to output control [at least on my equip])

Assuming a 256k link for purposes of calc.

10% is 25600
20% is 51200
70% is 179200

The burst values below were calculated using the target limit/8 and then
multiplying by 1.5, and finally multiplying that number by 2.

Originally entered as:
(Conf-if)
  101 25600 4800 9600 conform-action
transmit exceed-action drop
rate-limit output access-group 102 51200 9600 19200 conform-action
transmit exceed-action drop
rate-limit output access-group 103 179200 33600 67200 conform-action
transmit exceed-action drop

Then from sh run int fa0/0 (things get rounded)

Interface FastEthernet0/0
ip address 10.1.1.1 255.255.255.0
rate-limit output access-group 101 24000 4800 9600 conform-action
transmit exceed-action drop
rate-limit output access-group 102 48000 9600 19200 conform-action
transmit exceed-action drop
rate-limit output access-group 103 176000 33600 67200 conform-action
transmit exceed-action drop

access-list 101 permit icmp any any
access-list 102 permit tcp any any eq bgp
Access-list 103 permit ip any any

(following some intense icmp traffic)

Router#sh int fa0/0 rate-limit
FastEthernet0/0
  Output
    matches: access-group 101
      params: 24000 bps, 4800 limit, 9600 extended limit
      conformed 31 packets, 27334 bytes; action: transmit
      exceeded 3 packets, 4542 bytes; action: drop
      last packet: 14692ms ago, current burst: 6068 bytes
      last cleared 00:01:10 ago, conformed 3000 bps, exceeded 0 bps
    matches: access-group 102
      params: 48000 bps, 9600 limit, 19200 extended limit
      conformed 0 packets, 0 bytes; action: transmit
      exceeded 0 packets, 0 bytes; action: drop
      last packet: 3233872ms ago, current burst: 0 bytes
      last cleared 00:01:10 ago, conformed 0 bps, exceeded 0 bps
    matches: access-group 103
      params: 176000 bps, 33600 limit, 67200 extended limit
      conformed 0 packets, 0 bytes; action: transmit
      exceeded 0 packets, 0 bytes; action: drop
      last packet: 3233876ms ago, current burst: 0 bytes
      last cleared 00:01:10 ago, conformed 0 bps, exceeded 0 bps

This seems to work. My question is should we go back and adjust the
burst values based on the IOS rounding of our initial numbers?

Thanks



This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:48:23 GMT-3