×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

QoS Scavenger - drop behavior

Unanswered Question
Jan 13th, 2014
User Badges:

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Joseph W. Doherty Mon, 01/13/2014 - 16:58
User Badges:
  • Super Bronze, 10000 points or more

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 Wed, 01/15/2014 - 01:42
User Badges:

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 Wed, 01/15/2014 - 03:20
User Badges:
  • Super Bronze, 10000 points or more

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.

Actions

This Discussion

Related Content