Re: LLQ- help

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