QoS on ASR1002

Unanswered Question
Mar 5th, 2014
User Badges:

Hi experts,


Please see below for the config. The problem right now is that I see saw-tooth shape of traffic usage. I want to make it more smooth.


!

policy-map pmap_ParentEgressInside

class class-default

  shape average percent 95

  service-policy pmap_EgressInside2

!

policy-map pmap_EgressInside2

...

class cmap_WWW-UserInbound

  shape average 115000000

  queue-limit 2000 packets

...

!

interface GigabitEthernet0/0/1


service-policy output pmap_ParentEgressInside

!


We have multiple classes but the biggest class is this WWW class shown above. My first question is that, will increase the queue-limit help?


The second question is how

#sh policy-map int g0/0/1

...

        Class-map: cmap_WWW-UserInbound (match-any)

      ...

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


With above config, what dropping mechnism is being used for this class? Is it tail-drop? If I configure "random-detect", will it help? If I apply "random-detect" without any option like "dscp" or "precedence", does it care of different TCP flows or does it drop completely randomly for all the traffic in the class?


Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Vasilii Mikhail... Wed, 03/05/2014 - 10:58
User Badges:
  • Gold, 750 points or more

Hello, Difan.


Besides random-detect you need to adjust min and max threshold for respective precedence values.

If you have 2000 packets queue, then I would suggest to use min = 500 and max = 1200.

Difan Zhao Wed, 03/05/2014 - 11:52
User Badges:

Thanks Mikhail. What is the dropping mechnism it is using right now? And how does it work?

Vasilii Mikhail... Wed, 03/05/2014 - 20:30
User Badges:
  • Gold, 750 points or more

Hello, Difan.


"Random-detect" will make class using WRED (

http://www.cisco.com/en/US/docs/ios-xml/ios/qos_conavd/configuration/15-2mt/qos-conavd-cfg-wred.html)

WRED could help to avoid TCP synchronization issue.

But sometimes the drops could be a result of queue size oversubscription on physical interface (interface has less queue size, than a sum of all queues under classes) and, in such cases, WRED won't help you.


To see what is current mechanism, you need to run command "show policy-map int G0/0/1 out" (please share the output).

Joseph W. Doherty Thu, 03/06/2014 - 07:04
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


"Saw tooth" is quite common for TCP traffic.  However, if your seeing aggregate (concurrent multi-flow) "saw tooth", you might be bumping into global synchronized tail drop.  If you have multiple flows, you can break up the aggregate/concurrent tail drops using RED or per-flow queuing.


Why are you shaping the parent's policy at 95%?


What's the physical/logical bandwidth of the link?  (I see its a gig interface, but is it running at gig?  You have full gig bandwidth?)


What's the typical end-to-end latency from interface g0/0/1?


PS:

BTW, too large a queue-limit can actually be counter productive.  I normally recommend it shouldn't exceed half the BDP.

Difan Zhao Thu, 03/06/2014 - 08:44
User Badges:

Thanks Joseph for your response!


This is mostly for Internet traffic so latency varies.


g0/0/1 is the inside interface. policy-map is applied on the output direction to limit download from Internet. ISP is giving 250mbps. See here is the thing that I don't understand. ISP should rate-limit to 250mbps. So technically we should not see any drops since we have a full Giga outbound interface, right? So traffic should be queued or dropped, or at least shouldn't be too many, assuming that the ASR is able to handle that much of traffic volume. Correct?


I can check top talker to find most common destination IPs so I can get RTR. Is BDP calculated as RTR * 250mbps in my case?


Thanks!

Joseph W. Doherty Thu, 03/06/2014 - 09:34
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


You're trying to control ingress bandwidth by shaping egress bandwidth?  It can be done, if you shape egress TCP ACKs, but it's inexact and you have to shape ACKs very much in comparison to inbound bandwidth.  Probably easier to police ingress.


So ISP is providing 250 Mbps, in both directions?


Yes, you can still see drops on a gig interface with a downstream 250 Mbps cap.  In your case, you're shaping WWW at 115 Mbps, so you're drops might be more there than the interface itself.


Yes, BDP is bandwidth * RTT (the bandidth delay product).  Ya don't need top talker, what you need to know is "typical" end-to-end bandwidth and RTT (from router).  For example, can a single flow do 250 Mbps coast-to-coast (US)?

Difan Zhao Thu, 03/06/2014 - 10:13
User Badges:

Our setup is that, g0/0/0 is connected to the ISP. g0/0/1 is connected to inside. Policy-map is applied on g0/0/1 to shape incoming traffic from Internet. Sorry this is probably what you mean but I just don't understand ingress and egress very well.


Shaping ACKs is interesting idea. If I am shaping ACKs sending out of g0/0/0, it could theoratically shape traffic coming from Internet. Is it what you mean? How much ACK should I shape however assuming that 115mbps is what I want for return...?


Yes 250 is for both directions but we never have that much of uploading volume. It is problem with downloading that it is saw-tooth shape of traffic


For that class, I am not doing shaping. It is just a bandwidth statement to gurantee some bandwidth. I am doing shaping in the parent policy. However assuming that the ISP is already rate-limit to 250mbps, then my shaper probably don't do much becuase I should never get more than 250mbps, right? Well there could be peek which exceeds 250mbps sometimes...

Joseph W. Doherty Thu, 03/06/2014 - 17:34
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


Ah, ok, understand.  G0/0/1 is you internal interface and you shaping on it hoping to control ingress bandwidth from the Internet on g0/0/0.  That would normally be even less effective than policing ingress on g0/0/0.  Internet traffic will burst down your Internet link and just queue up on the shaper.


As to how much to shape ACKs for a certain rate, hard to say.  Depends on the bandwidth ratios between the ACK packets and the data packets.  You might start at about 30:1 (this assuming data packets are 1500 bytes and ACKs are one per two data packets, minimum size).

Difan Zhao Fri, 03/07/2014 - 10:19
User Badges:

Thank you very much for your interesting idea. I will try it and tune it and see it effect!

Difan Zhao Thu, 03/06/2014 - 09:10
User Badges:

Another question is that, if I also apply fair-queue to a class, what does it do generally? Does it tend to give equal bandwidth to all flows in the class? How does it achieve it? Does it tend to queue more packets for the small flows? How does it work together with WRED? Apparently both commands can be applied to the same class-map..


Thanks!

Joseph W. Doherty Thu, 03/06/2014 - 10:00
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


Ideally each flow gets its own queue, or, more likely, multiple flows are hashed into a flow queue.


If it's FQ, each flow queue is allow equal share of bandwidth.  If WFQ, different flows are permitted unequal shares of bandwidth.  NB: even with FQ, normally different flows will be using different amounts of bandwidth, but they are guaranteed access to equal bandwidth.


What FQ does, if there's congestion, each flow queue will fill with packets.  How fast depends on flow's attempted bandwidth usage, flow's share of egress bandwidth, and size of packets.  In practice, everything else being equal, flows with high attempted bandwidth usage, will fill their queue earlier and drop sooner.  I.e. FQ tends to drop packets from the heavy bandwidth flows first.


Yes, you can use RED too, but usually RED is global to the whole class (unless you're using a device that supports FRED).  Since FQ "target" heavy bandwidth usage flows before light bandwidth usage flows, if FQ is available, I consider it much better than RED.  (In theory, RED is great, in practice, it's difficult to accomplish its intended goals.)

Difan Zhao Thu, 03/06/2014 - 10:34
User Badges:

Please allow me to have a quick example to help me understand..


For the class I created, let's say that I have three streams falling in the class, traffic to Youtube, google and yahoo. They are coming in as 7mbps, 2mbps and 1mbps. The class is only configured with "bandwidth 3000". There is no shaping or policing for the class.


With "fair-queue" command, does it do FQ or WFQ? If it is WFQ, is the weight solely based on DSCP value? Well let's assume that they all have dscp of 0.


So let's say they are hashed into three different flows. BTW how many flows can one class have?


Will all three streams essentially throttled to 1mbps each or will they reach original throughput assuming that there is no congestion?


For the flow queue, do they each have the equal amount of queue size = "queue size configured for the class" / # of flows?


Thank you very much!

Difan Zhao Fri, 03/07/2014 - 10:20
User Badges:

Could you also take a look at my above question? Thanks!

Actions

This Discussion