QoS Scavenger - drop behavior

norbert.zehetner · ‎01-13-2014

Hi there,

i have a question regarding the drop behavior in my QoS setup, especially because i want to implement a Scavenger queue for some big file transfers to protect some other critical applications.

Here is the configuration for the outgoing direction (incoming marking is done correctly and the right pakets/applications are in the right queue and are not part of this question):

----------------------------------

class-map match-any voice_rw

match dscp ef

class-map match-any gold_rw

match dscp af42

class-map match-any silber_rw

match dscp af32

class-map match-any scavenger_rw

match dscp af13

policy-map egress_queue_rw

class voice_rw

priority percent 25

class gold_rw

bandwidth percent 15

class silber_rw

bandwidth percent 30

class scavenger_rw

bandwidth percent 1

class class-default

bandwidth percent 29

interface Serial0/0/1

bandwidth 1024

service-policy output egress_queue_rw

----------------------------------

Traffic in the queue "silber_rw" (30%) should be protected from traffic in the queue "scavenger_rw" (1%).

As you can see in the following output of the outgoing policy there is congestion on the serial interface and traffic in both queues is more than the configured guaranteed minimum bandwidth.

Why are there drops in the queue "silber_rw" and NO drops in the queue "scavenger_rw"?

sh policy-map inter s0/0/1

Serial0/0/1

Service-policy output: egress_queue_rw

queue stats for all priority classes:

queue limit 64 packets

(queue depth/total drops/no-buffer drops) 0/0/0

(pkts output/bytes output) 0/0

Class-map: voice_rw (match-any)

0 packets, 0 bytes

30 second offered rate 0 bps, drop rate 0 bps

Match: dscp ef (46)

0 packets, 0 bytes

30 second rate 0 bps

Priority: 25% (256 kbps), burst bytes 6400, b/w exceed drops: 0

Class-map: gold_rw (match-any)

0 packets, 0 bytes

30 second offered rate 0 bps, drop rate 0 bps

Match: dscp af42 (36)

0 packets, 0 bytes

30 second rate 0 bps

Queueing

queue limit 64 packets

(queue depth/total drops/no-buffer drops) 0/0/0

(pkts output/bytes output) 0/0

bandwidth 15% (153 kbps)

Class-map: silber_rw (match-any)

44974 packets, 47207246 bytes

30 second offered rate 599000 bps, drop rate 5000 bps

Match: dscp af32 (28)

44974 packets, 47207246 bytes

30 second rate 599000 bps

Queueing

queue limit 64 packets

(queue depth/total drops/no-buffer drops) 39/841/0

(pkts output/bytes output) 44133/46028582

bandwidth 30% (307 kbps)

Class-map: scavenger_rw (match-any)

8968 packets, 8906597 bytes

30 second offered rate 362000 bps, drop rate 0 bps

Match: dscp af13 (14)

8968 packets, 8906597 bytes

30 second rate 362000 bps

Queueing

queue limit 64 packets

(queue depth/total drops/no-buffer drops) 53/0/0

(pkts output/bytes output) 8968/8906597

bandwidth 1% (10 kbps)

Class-map: class-default (match-any)

33442 packets, 8655798 bytes

30 second offered rate 55000 bps, drop rate 0 bps

Match: any

Queueing

queue limit 64 packets

(queue depth/total drops/no-buffer drops) 0/0/0

(pkts output/bytes output) 33555/8657634

bandwidth 29% (296 kbps)

Many thx for your answers.

Norbert

Joseph W. Doherty · ‎01-13-2014

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

It could be the behavior of the silber_rw traffic. I.e. more "bursty".

Silber_rw also has about the same bandwidth allocation as class-default. Although the latter isn't using much bandwidth, they would compete equally for bandwidth. So, again, if silber_rw is more bursty, and queued class-default traffic would delay how fast silber_rw dequeues a burst.

You might try increasing silber_rw's queue allocation.

norbert.zehetner · ‎01-15-2014

The bursty traffic was also my first thoughts, but why is it over a "longer" period of time (up to 20 seconds i think).

I will try to reproduce the problem in a lab scenario.

Maybe i should implement WRED to worse the scavenger queue...

Joseph W. Doherty · ‎01-15-2014

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Well realize what might be happening. For example, silber_wr bursts so quickly, the bandwidth, with or without scavenger traffic, is insufficient to handle the burst before there are tail drops. If the silber_wr traffic is rate adaptive, if will then slow its transmission rate. The former would then account for the drops and the later the lower average transmission rate. The way to test this, would be to not have any scavenger traffic.

The scavenger traffic's bandwidth demand is such that its transmission rate and queues are such it doesn't overflow. Also, depending on the client's TCP stack, it might be adjusting its transmission rate based on RTT.

If you look carefully at your OP stats, you'll see both silber_wr and scavenger have queued packets, 39 and 53 respectively. With such queue depths, especially for scavenger, it's actually more surpising the latter hasn't recorded any drops.