Enterasys Networks X-PeditionTM manual Differences Between Traffic Policing and Traffic Shaping

Mechanisms Providing QoS

XSR(config-pmap-c<d32>)#exit

XSR(config-pmap<cbts>)#class foo

XSR(config-pmap-c<foo>)#shape 38400 15440

XSR(config-pmap-c<foo>)#bandwidth per 30

XSR(config-pmap-c<foo>)#exit

XSR(config-pmap<cbts>)#class class-default

XSR(config-pmap-c<class-default>)#set ip dscp 33

Differences Between Traffic Policing and Traffic Shaping

Traffic shaping and traffic policing may appear identical at first glance, but are marked by the following differences:

•Traffic policing marks or drops packets, it does not buffer them and has no associated queue management algorithm.

•The police command configures independent input and output rate-limit rules on the same interface while traffic shaping applies to output only.

•Traffic policing can be used to implement CAR (Committed Access Rate). You can specify both conform-actionand exceed-action. If the exceed-action is drop, then the rate limit is essentially a CAR rate. Traffic-shaping has no such parameters as all in-profiletraffic will be forwarded or queued and out-of-profiletraffic queued and shaped.

•Traffic shaping and policing differ in how they refill the token bucket. Shaping add tokens in the bucket at regular intervals of 10 milliseconds and calculates token added using this formula: tokens equal 10 millisecond rate.

The Policer adds tokens to the bucket on every packet, calculating the interval between the current and previous packet to determine the number of tokens it must add using this formula: tokens equal (interval between packets) multiplied by rate divided by 8bits

Traffic Shaping and Queue Limit

Traffic shaping delays packets in the queue if there are too few tokens in the bucket. How many packets are delayed (queued) depends on the shaper values, refill interval of the token bucket (10 milliseconds) and incoming traffic. If too many packets are delayed, the queue may overflow and incoming packets get dropped, so the queue size must be correct to avoid unwanted dropped packets.

The queue may also overflow because incoming traffic is significantly beyond expected parameters. The XSR has no control over incoming traffic and if it misbehaves, no shaping configuration will prevent packet drops.

Another cause for the queue overflowing is its size may not be big enough to sustain the configured average rate. Since every 10 milliseconds QoS fills the bucket, the queue should be configured with enough capacity to hold a 10msec burst. This is the minimum queue size required to sustain the average rate. Use the following formula to calculate the queue size:

Shape burst equals (rate multiplied by (10msec/1000) divided by (minimum packet size multiplied 8 bits)

If incoming traffic is expected to be bursty and the expected burst is bigger than the queue size, packets will be dropped. You can hike the queue size to accommodate incoming bursts as follows:

Expected burst equals burst (in bytes) divided by (minimum packet size)

The XSR automatically calculates shaper burst and you configure expected burst using the queue- limit command. When both queue-limit and shaper are configured on a queue, QoS uses the

XSR User’s Guide 12-9