[c-nsp] LLQ not utilizing reserved bandwidth & packet drops in Nested policy-map (2 level hierarchial policymap)

Mon Feb 24 04:42:33 EST 2014

Hello Arun,

What kind of traffic are you flowing through the priority class ?

I can see that there are b/w exceed drops.

You should consider the following things:

1) priority class is using police action on the packets that exceed the configured bandwidth

2) priority class will drop packets reaching over the configured bandwidth no matter what, even if you don't have any traffic in the other classes at a given time.

Maybe you are wondering why it is like that. 

The point is that actually the priority traffic should NOT try to overcome the reserved bandwidth for it. 

So when you configure priority class, you should pick such value that would be enough for the priority traffic in any occasions.

Priority class is intended to be used for benign traffic such as voice.

So the question is what happens when you try to push TCP traffic in a priority class. 

Well actually I didn't run tests to see what actually happens, but here is what I think.

As you know, TCP is trying to get as much throughput as possible. So in fact when your burst is smaller, interval of 200ms, packets are getting dropped way too often, which is degrading the TCP session performance a lot. As far as I know, each time packet is dropped, the window size is halved.

When you increase the burst respectively the time interval to 2s, the packet drops are less and you are able to extract more out of a single tcp session.

Priority class is used to guarantee latency of benign traffic with a well known capacity.

If you want to guarantee bandwidth for a TCP traffic, then you should NOT use priority class, but a regular bandwidth guarantee class, which is using shaping action on the packets, which in fact is far more well-intentioned to the TCP sessions.

Hope you find that information helpful.

Best regards.

Monday, February 24, 2014, 9:37:07 AM, you wrote:

Hi Velimir - Please find the full configuration of ACL, Class map and policy map

C2800-R6-CPE1#sh class-map
 Class Map match-all EF (id 1)
   Match access-group name EF

 Class Map match-all DATA1 (id 2)
   Match access-group name DATA1

 Class Map match-all DATA2 (id 3)
   Match access-group name DATA2

 Class Map match-all DATA3 (id 4)
   Match access-group name DATA3

 Class Map match-all DATA4 (id 5)
   Match access-group name DATA4

 Class Map match-any class-default (id 0)
   Match any

C2800-R6-CPE1#sh ip acce
C2800-R6-CPE1#sh ip access-lists
Extended IP access list DATA1
    10 permit ip any host 172.9.0.10 (56100 matches)
Extended IP access list DATA2
    10 permit ip any host 10.20.0.10 (18579 matches)
Extended IP access list DATA3
    10 permit ip any host 124.7.227.17
Extended IP access list DATA4
    10 permit ip any host 124.7.227.19
Extended IP access list EF
    10 permit ip host 10.10.1.2 host 119.227.3.159 (125370 matches)
C2800-R6-CPE1#

C2800-R6-CPE1#sh policy-map child-out1
  Policy Map child-out1
    Class EF
      priority 50 (%) 16000
    Class DATA1
      bandwidth 20 (%)
    Class DATA2
      bandwidth 10 (%)
    Class DATA3
      bandwidth 10 (%)
C2800-R6-CPE1#

C2800-R6-CPE1#sh policy-map parent-out
  Policy Map parent-out
    Class class-default
      Average Rate Traffic Shaping
      cir 128000 (bps)
      service-policy child-out1

Service-policy output: parent-out

    Class-map: class-default (match-any)
      199999 packets, 45317308 bytes
      30 second offered rate 0 bps, drop rate 0 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/2631/0
      (pkts output/bytes output) 197368/47497736
      shape (average) cir 128000, bc 512, be 512
      target shape rate 128000

      Service-policy : child-out1

        queue stats for all priority classes:
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/2631/0
          (pkts output/bytes output) 122667/19466406

        Class-map: EF (match-all)
          125298 packets, 18630200 bytes
          30 second offered rate 0 bps, drop rate 0 bps
          Match: access-group name EF
          Priority: 50% (64 kbps), burst bytes 19200, b/w exceed drops: 2631

The router uses the "shape average CIR" value used in parent policy map when percentage is used in child policy map. Please see the above output where in class-map EF has 64kbps when 50% of parent CIR 128Kbps is configured. Tried changing the bandwidth command under the interface to 128K but still the issue persists.

Hi Jeya - The issue is LLQ should be able to burst till 64kbps during no congestion which is not happening with default burst size of 1600 bytes (200ms). Only when the burst size is changed to 16000bytes (2s), i am able to burst till 64Kbps.

On Fri, Feb 21, 2014 at 2:44 PM, Jeyamurali Sivapathasundaram <sjeyamurali at gmail.com> wrote:
Hi Arun 

When no congestion, you can use more than 16K for LLQ  or any of the other classes. This is default behaviour. 

Jey

On Thu, Feb 20, 2014 at 2:27 PM, Arun Kumar <narain.arun at gmail.com> wrote:
Hi,

I think this issue is quite old but I could not get any conclusive
explanation.

Below is the configuration:

C2800-R6-CPE1#sh policy-map parent-out

  Policy Map parent-out

    Class class-default

      Average Rate Traffic Shaping

      cir 128000 (bps)

      service-policy child-out1

C2800-R6-CPE1#sh policy-map child-out1

  Policy Map child-out1

    Class EF

      priority 50 (%) 16000

    Class DATA1

      bandwidth 20 (%)

    Class DATA2

      bandwidth 10 (%)

    Class DATA3

      bandwidth 10 (%)

C2800-R6-CPE1#

In the above configuration, parent policy has 128Kbps and Child has 4
Classes with Class EF is LLQ with priority of 50% bandwidth (burst size is
default 1600bytes), class DATA1 with 20%, class DATA2 with 10% and class
DATA3 with 10%.

With the above configuration, I could not able to push beyond 16Kbps of
traffic on class EF (LLQ). When the burst size is increased to 16000 bytes,
I am able to push around 60Kbps.

Wanted to understand this is the expected behavior of LLQ in Nested policy
map or I am missing something.

thanks in advance
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net

https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

-- 
Best Regards, 

Jey S.
Network Engineer 
London 