Traffic Policing versus Shaping-Part1

Traffic Policing versus Shaping

There are two methods to limit the amount of traffic originating from an interface: policing and shaping. When an interface is policed outbound, traffic exceeding the configured threshold is dropped (or remarked to a lower class of service). Shaping, on the other hand, buffers excess (burst) traffic to transmit during non-burst periods. Shaping has the potential to make more efficient use of bandwidth at the cost of additional overhead on the router.

All this is just dandy, but doesn't mean much until you see its effects on real traffic. Consider the following lab topology:

We'll be using Iperf on the client (192.168.10.2) to generate TCP traffic to the server (192.168.20.2). In the middle is R1, a Cisco 3725. Its F0/1 interface will be configured for policing or shaping outbound to the server.

Iperf

Iperf is able to test the bandwidth available across a link by generating TCP or UDP streams and benchmarking the throughput of each. To illustrate the effects of policing and shaping, we'll configure Iperf to generate four TCP streams, which we can monitor individually. To get a feel for how Iperf works, let's do a dry run before applying any QoS policies. Below is the output from Iperf on the client end after running unrestricted across a 100 Mbit link:

Client$ iperf -c 192.168.20.2 -t 30 -P 4
------------------------------------------------------------
Client connecting to 192.168.20.2, TCP port 5001
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[1916] local 192.168.10.2 port 1908 connected with 192.168.20.2 port 5001
[1900] local 192.168.10.2 port 1909 connected with 192.168.20.2 port 5001
[1884] local 192.168.10.2 port 1910 connected with 192.168.20.2 port 5001
[1868] local 192.168.10.2 port 1911 connected with 192.168.20.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[1900]  0.0-30.0 sec  84.6 MBytes  23.6 Mbits/sec
[1884]  0.0-30.0 sec  84.6 MBytes  23.6 Mbits/sec
[1868]  0.0-30.0 sec  84.6 MBytes  23.6 Mbits/sec
[1916]  0.0-30.0 sec  84.6 MBytes  23.6 Mbits/sec
[SUM]  0.0-30.0 sec   338 MBytes  94.5 Mbits/sec

Iperf is run with several options:

• -c - Toggles client mode, with the IP address of the server to contact
• -t - The time to run, in seconds
• -P - The number of parallel connections to establish

We can see that Iperf is able to effectively saturate the link at around 95 Mbps, with each stream consuming a roughly equal share of the available bandwidth.

Policing

Our first test will measure the throughput from the client to the server when R1 has been configured to police traffic to 1 Mbit. To do this we'll need to create the appropriate QoS policy and apply it outbound to F0/1:

policy-map Police
 class class-default
  police cir 1000000
!
interface FastEthernet0/1
 service-policy output Police

We can then inspect our applied policy with show policy-map interface. F0/1 is being policed to 1 Mbit with a 31250 bytes burst:

R1# show policy-map interface
 FastEthernet0/1

Service-policy output: Police

Class-map: class-default (match-any)
  2070 packets, 2998927 bytes
  5 minute offered rate 83000 bps, drop rate 0 bps
  Match: any
  police:
      cir 1000000 bps, bc 31250 bytes
    conformed 1394 packets, 1992832 bytes; actions:
      transmit
    exceeded 673 packets, 1005594 bytes; actions:
      drop
    conformed 57000 bps, exceed 30000 bps

Repeating the same Iperf test now yields very different results:

Client$ iperf -c 192.168.20.2 -t 30 -P 4
------------------------------------------------------------
Client connecting to 192.168.20.2, TCP port 5001
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[1916] local 192.168.10.2 port 1922 connected with 192.168.20.2 port 5001
[1900] local 192.168.10.2 port 1923 connected with 192.168.20.2 port 5001
[1884] local 192.168.10.2 port 1924 connected with 192.168.20.2 port 5001
[1868] local 192.168.10.2 port 1925 connected with 192.168.20.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[1884]  0.0-30.2 sec   520 KBytes   141 Kbits/sec
[1916]  0.0-30.6 sec  1.13 MBytes   311 Kbits/sec
[1900]  0.0-30.5 sec   536 KBytes   144 Kbits/sec
[1868]  0.0-30.5 sec   920 KBytes   247 Kbits/sec
[SUM]  0.0-30.6 sec  3.06 MBytes   841 Kbits/sec

Notice that although we've allowed for up to 1 Mbps of traffic, Iperf has only achieved 841 Kbps. Also notice that, unlike our prior test, each flow does not receive an equal proportion of the available bandwidth. This is because policing (as configured) does not recognize individual flows; it merely drops packets whenever they threaten to exceed the configured threshold.

Using Wireshark's IO graphing feature on a capture obtained at the server, we can observe the apparently random nature of the flows. The black line measures the aggregate throughput, and the colored lines each represent an individual TCP flow.

Shaping

In contrast to policing, we'll see that shaping handles traffic in a very organized, predictable manner. First we'll need to configure a QoS policy on R1 to shape traffic to 1 Mbit. When applying the Shape policy outbound on F0/1, be sure to remove the Police policy first with no service-policy output Police.

policy-map Shape
 class class-default
  shape average 1000000
!
interface FastEthernet0/1
 service-policy output Shape

Immediately after starting our Iperf test a third time we can see that shaping is taking place:

R1# show policy-map interface
 FastEthernet0/1

Service-policy output: Shape

Class-map: class-default (match-any)
  783 packets, 1050468 bytes
  5 minute offered rate 0 bps, drop rate 0 bps
  Match: any
  Traffic Shaping
       Target/Average   Byte   Sustain   Excess    Interval  Increment
         Rate           Limit  bits/int  bits/int  (ms)      (bytes)
      1000000/1000000   6250   25000     25000     25        3125

Adapt  Queue     Packets   Bytes     Packets   Bytes     Shaping
    Active Depth                         Delayed   Delayed   Active
    -      69        554       715690    491       708722    yes

This last test concludes with very consistent results:

Client$ iperf -c 192.168.20.2 -t 30 -P 4
------------------------------------------------------------
Client connecting to 192.168.20.2, TCP port 5001
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[1916] local 192.168.10.2 port 1931 connected with 192.168.20.2 port 5001
[1900] local 192.168.10.2 port 1932 connected with 192.168.20.2 port 5001
[1884] local 192.168.10.2 port 1933 connected with 192.168.20.2 port 5001
[1868] local 192.168.10.2 port 1934 connected with 192.168.20.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[1916]  0.0-30.4 sec   896 KBytes   242 Kbits/sec
[1868]  0.0-30.5 sec   896 KBytes   241 Kbits/sec
[1884]  0.0-30.5 sec   896 KBytes   241 Kbits/sec
[1900]  0.0-30.5 sec   896 KBytes   241 Kbits/sec
[SUM]  0.0-30.5 sec  3.50 MBytes   962 Kbits/sec

With shaping applied, Iperf is able to squeeze 962 Kbps out of the 1 Mbps link, a 14% gain over policing. However, keep in mind that the gain measured here is incidental and very subject to change under more real-world conditions. Also notice that each stream receives a fair share of bandwidth. This even distribution is best illustrated graphically through an IO graph of a second capture: