Re: LLQ- help

Marko,

There are 2 distinct things in play for LLQ.

1) CBWFQ scheduler- This operates exactly the way you have been stating the entire time. Congestion must be in effect for this scheduler to be operating effectively.

2) The priority Class- I think you are very mistaken about this part of LLQ. The fact that you did not understand the "Burst" proves this. Not that this is a bad thing. SO what if you did not know. Does not mean I think less of you.;-)

You keep speaking about LLQ from only one of the above perspectives.

I understand the multiple input interfaces deal. I was not testing the Queuing, that is very straight forward.

I was testing the Policer in the Priority Class. Ya know the part that makes LLQ different from CBWFQ. You are speaking as if they behave the same when they don't.

I think I see where we MAY be speaking past each other but let me clarify. I was making a point so EVERYONE would understand how the Priority Q works which is very different then what MOST people think. The statement from the point I was referencing was about the "PRIORITY" keyword, which means it is participating as a Priority Queue.

Paul

Paul Negron
CCIE# 14856
negron.paul_at_gmail.com
303-725-8162

On Dec 17, 2012, at 11:33 PM, Marko Milivojevic <markom_at_ipexpert.com> wrote:

> And mind you :-). I was not the one who talked about flows. I talked
> about different interfaces or classes in the same policies. Two flows
> in the same queue coming from the same input interface be it 1 or 19
> phones is still 1 input 1 output. To see the queueing, you need
> multiple input interfaces. Think of a Y.
>
> --
> Marko Milivojevic - CCIE #18427 (SP R&S)
> Senior CCIE Instructor - IPexpert
>
> On Mon, Dec 17, 2012 at 8:31 PM, Marko Milivojevic <markom_at_ipexpert.com> wrote:
>> Paul,
>>
>> If there was no congestion on the TX ring, there was no LLQ. TX ring
>> congestion is what signals to IOS that software queueing needs to be
>> engaged. Your test was flawed, sorry to say.
>>
>> --
>> Marko Milivojevic - CCIE #18427 (SP R&S)
>> Senior CCIE Instructor - IPexpert
>>
>> On Mon, Dec 17, 2012 at 8:25 PM, Paul Negron <negron.paul_at_gmail.com> wrote:
>>> I have tested it precisely!
>>>
>>> I put Voice traffic into the Priority Class and left the burst to default.
>>>
>>> I placed enough voice calls to equal the amount of traffic I used with the
>>> "priority" command (4 calls at 32K each/NO VAD enabled). ALL traffic passed
>>> and was not rejected. I placed a 5th call and it also went through with no
>>> problem because it did not exceed the burst rate parameter (Voice is not
>>> bursty). The second I placed another call, ALL of the Voice flows were
>>> negatively impacted. The priority class began dropping traffic! It reacted
>>> as if it was receiving burst traffic that exceeded what it would allow.
>>>
>>> When I extended the Burst parameter, ALL of the Voice call issues cleared
>>> up.
>>>
>>> There was NO congestion on the transmit ring at ANY time during this test.
>>>
>>>
>>> I also performed the same test with Live Video but the results were
>>> devastating due to the extreme Bursty nature of the traffic I was using. I
>>> needed to extend the "BURST" parameter extensively due to it's extreme
>>> restrictive default.
>>>
>>> This is why some people misspeak and say that the Priority class is a
>>> maximum value. It's true in that it binds the high end bandwidth but it does
>>> ALLOW you to burst and squeeze a little bit more by default. It's just
>>> REALLY restrictive. It does not enforce the 1 to 2 second recommendation.
>>>
>>> I still disagree with your example of where you " MAY SEE" queueing of
>>> packets since I have NOT been able to prove it to this point. I did not ask
>>> you to show me the packets to be confrontational or argumentative. I
>>> actually thought I was going to learn something in this conversation about
>>> how the Priority Queue actually buffers packets. I don't know what command
>>> you used to verify this.
>>>
>>> This is why I am NOT confused about how LLQ works. I understood what the
>>> BURST parameter actually does. I am NOT guessing.
>>>
>>> Policing will impose its constraint weather you are congested on the TX ring
>>> or NOT. Same goes for Shaping!
>>>
>>> Paul
>>>
>>> Paul Negron
>>> CCIE# 14856
>>> negron.paul_at_gmail.com
>>>
>>>
>>>
>>> On Dec 17, 2012, at 10:19 PM, Marko Milivojevic <markom_at_ipexpert.com> wrote:
>>>
>>> On Mon, Dec 17, 2012 at 7:11 PM, Marko Milivojevic <markom_at_ipexpert.com>
>>> wrote:
>>>
>>>
>>> Yeah, I've seen that in the command reference as well. It's not
>>> exactly well documented what it does.
>>>
>>>
>>> What I suspect though (and this is purely speculation) is that it
>>> allows the traffic to burst for the specified time when the LLQ is
>>> engaged, which means when TX ring (or other choke point, i.e. shaper
>>> in the parent class) trigger a congestion. Since there's no LLQ when
>>> there's no congestion, I don't see how this parameter is at all
>>> relevant when LLQ is not active. That's the thing with your statement
>>> about 30 seconds that I mostly disagree with.
>>>
>>> --
>>> Marko Milivojevic - CCIE #18427 (SP R&S)
>>> Senior CCIE Instructor - IPexpert

Blogs and organic groups at http://www.ccie.net
Received on Tue Dec 18 2012 - 00:03:39 ART