EMAIL SUPPORT

dclessons@dclessons.com

LOCATION

NZ

QOS Policing & Shaping

QOS Policing & Shaping

Posted on Jan 24, 2020 (0)

QOS Policing & Shaping

Traffic Shaping When and Where:

There are two main reasons for which traffic shaping is used.

  • To shape the traffic at same rate as policing
  • To avoid the effect of egress blocking

Let’s discuss the both scenario one by one.

Shaping at same rate as Policing:

Let’s suppose you have branch site from branch 1 to branch 24 and there is one head quarter. Branch 1 does not shapes the traffic and whereas branch 24 shapes the traffic to 96kbps. In both cases WAN Switch is configured to police the traffic at 96kbps and CIR of each case is 64kbps.

Let’s suppose branch 1 let’s say send the traffic more than 96kbps, now WAN Switch will police the traffic and will cause the traffic drop. Branch 24 will delay the packet due to shaping and WAN switch will not discard the packet but some packet will experience more delay and jitter.

So to avoid the situation each Branch should shape the traffic with same rate as policing.

Avoid Egress Blocking:

Egress Blocking occurs when packets try to exit from Multi-Access WAN but cannot exit due to network congestion. Let’s take the previous example and suppose that shaping and policing is configure at 96kbps. Now If all branch from Branch 1 to branch send the traffic, about 2.25 Mbps of traffic needs to be exit to reach to headquarter but the Access rate of main router is 1.5 Mbps causes the egress blocking.

To avoid this situation, ALL Virtual Circuits at branches should shape the traffic to CIR of 64kbps due to which the cumulative offered load will not exceed the access Rate at Main site.

How Shaping works

Shaping only occurs when the physical clock rate of media exceeds a traffic contract. Any router can only send the traffic in and out at its physical clock rate To get the average bit rate over time lower than clock rate , router needs to send packets for some specified period to time and then not to send any packet for another time period.

Let’s understand this by this example, R1 has 128 kbps access rate and CIR of 64 kbps and a network admin wants to shape the traffic to match the 64kbps.Now in this case R1 has to send the traffic on link half of the time and if R1 does this and send the traffic half of the time at 128kbps it can get the average rate 64kbps over time.

So R1 will shapes the traffic at 64kbps with access rate 128kbps. 

Now Tc defaults to 125 ms for many tools and application now R1 at the end of 125 ms would send the traffic to 62.5 ms and for next 62.5ms will be ideal and this will be done for next 8 interval to meet 1 sec thus R1 will send the 64kbps traffic with Access rate 128kbps.

But in IOS or NXOS, shaping does not actually starts a timer for 62.5ms and then stops for next 62.5. SO IOS actually calculate this bit rate based on configuration to determine how many bits should router send for each interval so that its shaping rate can be met and this value is called committed burst (Bc) for each interval and it is considered as burst because bits actually flows at physical line rate.

Bc = Tc*CIR

     = .125(S) * 64000bps = 8000 bits.

So while configuring shaping, we only configure shaping rate and if we configure Bc also then IOS changes the Tc by formula. 

With traffic with no excess burst, token buckets are used to determine how shaping is implemented. Let’s suppose a bucket is filed with tokens and each token lets you to buy the right to send 1 bits and the size of bucket is of Bc.

Now shaper will put Bc worth of tokens in to bucket at beginning of each interval and if all tokens are not used in particular time interval and shaper puts Bc worth of tokens then some tokens will split out.


[pms-restrict subscription_plans="1315, 1316, 1317, 1735"]
Every time packet is sent shaping will spend the token from bucket to forward the traffic. If packet size is 1000 bits long then 1000 tokens are removed from bucket. Now when traffic shaping tries to send the packet, and bucket does not have that much of token then shaping must wait until next time interval to refill the token bucket.

To configure Shaping following formula is used on IOS:

Shape [avg | Peak] means rate [burst size Bc] [excess-burst-size Be]

Let’s say we provide command

Shape avg 64000

Here CIR is 64000bps and as per default tc .125 sec it will calculates the Bc by following formula:

Bc = Tc*CIR

Bc = .125s*64000bps = 8000bits then Be will also be 8000bits. Now token bucket size will be Bc+Be = 16000bits and after a period of inactivity 16000bits can be sent whereas under high load 8000bits can be sent each Tc because token will be filled at Bc 8000 bits per interval.

But if we put command for peak:  

Shape peak 64000

In this case token size will be 16000bits (Bc+Be) and shaper has right to send the committed Burst and Excess Burst at each Tc.

With this rate if you want to calculate to see that it can achieves the Actual Access Rate, can also be calculated.

Shaping rate = config_rate (1+Be/Bc)

                       = 64(1+8000/8000) = 128kbps = target rate.

Policing When and Where:

Whenever physical clock rate exceeds the traffic contracts policing needed and instead of discarding the packet Policers mark the packet with different IP Precedence or DSCP value and based on marking network traffic flows based on policy configured or if network is congested packet is much more likely to be discarded.

There are three options while doing policing:

  • Don’t Police: All Customers sends and receives data at the clock rate of access-link.
  • Police at contracted rate: To support traffic levels, Network only needs to support contracted rates and also core must be over build to supports new customer and its BW requirements.
  • Police somewhere in between Contracted rate and Access-link clock rate.

There are three general levels of traffic policing packet rate.

  • Conforming Traffic: This type of traffic is transmitted without any another intervention.
  • Exceeding Traffic: This traffic is above normal defined traffic profile but under top allowed packet rate. Generally this type of traffic is remarked with lower priority and then processed as per policy configured.
  • Violating Traffic: This type of traffic is always above top allowed traffic rate and is generally dropped by policy

Both Policing and shaping ensure that traffic does not exceed a bandwidth limit in following ways:

  • Policing drops the packet more often causing more retransmission of TCP connections.
  • Shaping causes delay, jitter and latency to traffic.

Different Policing methods:

Single Token Bucket:

In Single token bucket model , if there are enough tokens in bucket the traffic will be conforming and allowed from network utilizing the tokens and if there are not enough tokens in the bucket the traffic will be considered as exceeding limit and is generally dropped.

Let’s understand this by example that a bucket has 500 tokens and any data comes with 300 bytes and each token grants to permit 1 bytes. Now as the data is 300 bytes and bucket has 500 tokens than the traffic will be conformed and after using 300 tokens from bucket 300 bytes of packets is allowed from network, leaving 200 tokens in bucket. Now soon next 300 bytes of packets arrived and no new tokens have been added to bucket then 300>200(tokens) which exceed the rate limit and now exceed action is performed either to drop packet or remark the packet.

Single Rate – Single Token Bucket Class-based Policing

We will use below diagram to learn this method:

With Traffic policing new token are added I to token bucket based on interpacket arrival rate and CIR. Every time a packet is policed, new token are added to bucket.

The number of token that will be added to token bucket can be calculated by following formula:

(Current Packet arrival time – Previous packet arrival time) * CIR

Whereas CIR can be calculated as follows:

CIR = Bc (bits)/Tc(second)

If CIR of any link is 16 Mbps then taking default Tc .125 seconds we can calculate the Bc

Bc = 16000000bps*.125 = 2000000bits

Now without excess bursting capability, of Bc tokens have been filled to capacity the token bucket will overflow and newly arriving tokens will be discarded. And if 2000000bits every .125 sec will be allowed the maximum traffic rate will never be exceeded with CIR of 16Mbps.

Single Rate – Dual Token Bucket class based Policing

This methods is used when we have to implement the excess bursting capability. In this when the first token is filled with Bc of tokens than extra tokens can be accumulated to second token bucket. Be is the maximum amount of excess traffic over and above Bc that can be transmitted during time interval after a period of inactivity. In single rate the maximum size of Be fills with same CIR rate as first token bucket.

If second token bucket fills up to capacity no more tokens can be filled and excess tokens can be discarded.

When using dual token bucket model traffic can be rated as follows:

  • Conforming Traffic: This type of traffic is transmitted without any another intervention.
  • Exceeding Traffic: This traffic is above normal defined traffic profile but under top allowed packet rate. Generally this type of traffic is remarked with lower priority and then processed as per policy configured. In this there are not enough token present in first bucket but are enough tokens on second bucket with maximum size of Be.
  • Violating Traffic: This type of traffic is always above top allowed traffic rate and is generally dropped by policy and there are no enough tokens on first and second token bucket.

When traffic is conformed, all traffic is allowed and if traffic is exceeded it may be remarked to lower priority and drops for all violating traffic. This method enables a different policy to be applied to packet in the Be category.

Dual Rate Class Based Policing:

With dual-rate metering, traffic rate can be enforced according to two separate rates: CIR and
peak information rate (PIR). Before this feature was available, you could meter traffic using a
single rate that is based on the CIR with single or dual buckets. Dual-rate metering supports a
higher level of bandwidth management and supports a sustained excess rate that is based on the
PIR.

With dual-rate metering, the PIR token bucket fills at a rate that is based on the packet arrival rate, and the configured PIR and the CIR token bucket fills at a rate that is based on the packet arrival rate and the configured CIR.

When a packet arrives, the PIR token bucket is first checked lo sec if there are enough tokens in the PIR token bucket to send the packet. The violating condition occurs if there are not enough tokens in the PIR token bucket to transmit the packet. If there are enough tokens in the PIR token bucket to send the packet, then the CIR token bucket is checked. The exceeding condition occurs if there are enough tokens in the PIR token bucket to transmit the packet but not enough tokens in the CIR token bucket to transmit the packet. The conforming condition occurs if there are enough tokens in the CIR bucket to transmit the packet.

Dual-rate metering is often configured on interfaces at the edge of a network to police the rate of traffic that is entering or leaving the network. In the most common configurations, traffic that conforms is sent and traffic that exceeds is sent with a decreased priority, and traffic that violates is dropped. Users should change these configuration options related to QOS to suit their network needs.
[/pms-restrict]


Comment

    You are will be the first.

LEAVE A COMMENT

Please login here to comment.