LLQ ans packet discarding

Unanswered Question
Jun 18th, 2007

I would like to use drop precedence of the EF classe in order to prioritize some phone call in case of congestion.

So, voip flux with higher drop precedence would be discarded before voip flux with lower drop precedence.

I wanted to use LLQ algorithm to give maximum priority to EF class and use RED algorithm to delete packet according to their drop precedence value. But according to what I could read on cisco documentation, RED can't be use with LLQ algorithm (logic as voip don't use TCP windows).

Which technik of packet discarding could I use with LLQ algorithm to be able to discard packet in accordance with their drop precedence?

Thanks for your help.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
mohammedmahmoud Mon, 06/18/2007 - 02:20

Hi,

LLQ can't use RED at all (due to the nature of the UDP packets that are going to be LLQed), and unfortunately the only drop mechanism that LLQ can utilize is tail drop.

HTH,

Mohammed Mahmoud.

Paolo Bevilacqua Mon, 06/18/2007 - 02:24

Short answer - none.

The theory is that ALL the packets marked EF should have same priority and the link should have enough bandwidth to transmit them as FIFO without further discrimination.

Now, if your link doesn't have enough bandwidth to transmit them all, what do you want is CAC, that is the voip calls that cannot get enough bandwidth will fail at setup time with a diagnostic of "network congestion". This requires additional configuration on the router.

Is that Ok with you? Or what is that you are trying to do ?

Djule2804 Mon, 06/18/2007 - 02:38

Ok, I see what you mean!

But the system you explain me don't allow to prioritize some phone call. What I'm tring to do is to ensure that packet flux from very important call phone won't be discarded whereas another voip flux would be police.

I just read this document

http://www.cisco.com/en/US/products/sw/iosswrel/ps1830/products_feature_guide09186a0080087b13.html

and i saw it could be possible : Here is this example

"In this example, voice1 and voice2 classes of traffic go into the high priority queue and get strict

priority queueing over data traffic. However, voice1 traffic will be rate-limited to 24 kbps and

voice2 traffic will be rate-limited to 48 kbps. The classes will be individually rate-limited"

PS: Mohammed, I also read that tail drop couldn't be use with LLQ

Paolo Bevilacqua Mon, 06/18/2007 - 02:44

Well it seems to me this in a confusing example.

You will have two priority queues, one limited to 24, one to 48. What will be total? 48, or 24+48 ? The document fails to say that. And, I'm not 100% sure now, but more recent IOS could allow to configure only 1 priority queue.

Anyway, if you want to try that, all what you have to do is make the classification based on IP addresses so that the calls fail in different classes.

Djule2804 Mon, 06/18/2007 - 02:48

Thanks for your help, I gonna try to test this configuration.

griffinmark Wed, 06/20/2007 - 03:34

I think you need to do hierarchal queuing/embedded policy maps.

Here is an example I just tried out.

First setup your class maps to whatever method you are using to match.

Then create a policy map for your normal calls like the one I created below named default-call.

policy-map default-call

class default-call

priority 128

Next create a new policy as the parent policy and configure the class for critical calls like normal. Then embedded your default-call policy like I did under the "class crit-call". example below.

policy-map crit-call

class crit-call

priority 256

service-policy default-call

class class-default

fair-queue

From there you can create whatever other classes you need like it was any other policy.

The only draw back is I believe that the embedded policy has to draw upon the bandwidth reserved in the parent. In this case I configured the parent with 256k and then configure the default for 128k. If my reasoning is right then if the parent doesn't use up all 256k then the default would be allowed up to 128. This should get your critical calls scheduled before your normal calls

I'm use to doing hierarchal queuing in other vendor routers but if the logic is the same it should work.

You would have to do this in every router along the traffic path - at least the bottle necks.

While this could be a way to do it with policy maps I think I'm with PB in saying that using call admission control to prioritize who gets to establish a call first would be the best way.

Djule2804 Wed, 06/20/2007 - 03:47

Excellent solution! I gonna try to put in pratice what you advise me.

Thank you very much!!!

Actions

This Discussion