Re: LLQ- help

Priority Queue implies use of PQ framework = 4 queues, older and
deprecated queueing method Cisco abandoned for a more modern custom
queueing. Rings a bell? :-)

That's semantics and since both PQ and other queues are (officially)
on the CCIE lab blueprint and this being a CCIE lab study list, I like
to be very precise about the terminology, since LLQ is not quite the
same as PQ :-). Hopefully that clears that.

Now...

The "priority" keyword adds a "strict priority" queue (should really
be strict schedule), which is conditionally policed, i.e. when there's
no congestion, there's no queue and the traffic that would be mapped
to this queue is allowed to exceed conditionally policed rate.
However, when there is a congestion, hence the queue is engaged, this
traffic is not allowed to exceed the rate, except for a very short
period of time, as defined by the "burst" keyword after the "priority"
rate configuration. Implying that because voice traffic is not bursty
this is somehow not true is ridiculous at best, as the traffic mapped
to this queue does not have to be voice *at all*. This queue is very
similar in nature to what is in IOS called PQ, except for the
conditional policer, which prevents the queue starvation caused by the
other queues.

Hopefully that clears what I'm talking about...

P.S. Hobbit is pretty interesting in 48 fps frame rate...

On Mon, Dec 17, 2012 at 10:07 PM, John Neiberger <jneiberger_at_gmail.com> wrote:
> Marko,
>
> I'm a little confused by your statement that the priority keyword does not
> create a priority queue. It's my understand that that's exactly what it
> does. It adds a priority queue to CBWFQ, right? Are you saying that even
> though we're adding the priority keyword, the queue that it creates isn't a
> real priority queue?
>
> I haven't configured it in a while, but in your latter example, as I recall
> it would police the priority queue to 2 Mb/s.
>
> From Cisco's documentation:
>
> "When you specify the priority command for a class, it takes a bandwidth
> argument that gives maximum bandwidth in kilobits per second (kbps). You use
> this parameter to specify the maximum amount of bandwidth allocated for
> packets belonging to the class configured with the priority command. The
> bandwidth parameter both guarantees bandwidth to the priority class and
> restrains the flow of packets from the priority class.
>
> In the event of congestion, when the bandwidth is exceeded policing is used
> to drop packets. Voice traffic enqueued to the priority queue is UDP-based
> and therefore not adaptive to the early packet drop characteristic of
> Weighted Random Early Detection (WRED). Because WRED is ineffective, you
> cannot use the WRED random-detectcommand with the priority command. In
> addition, because policing is used to drop packets and queue limit is not
> imposed, the queue-limit command cannot be used with the priority command.
>
> When congestion occurs, traffic destined for the priority queue is metered
> to ensure that the bandwidth allocation configured for the class to which
> the traffic belongs is not exceeded."
>
>
> So, in the presence of 10 Mb/s of traffic, 8 Mbps would get dropped, at
> least according to the documentation. The documentation also specifically
> states that the priority keyword creates a priority queue, which is what
> I've always understood LLQ to be: CBWQF + a priority queue.
>
>
> Did I misunderstand what you were getting at?
>
>
> Thanks!
>
> John
>
>
>
>
> On Mon, Dec 17, 2012 at 10:14 PM, Marko Milivojevic <markom_at_ipexpert.com>
> wrote:
>>
>> Oh, I understand it very well... This has *nothing* to do with burst,
>> as I said hours ago... :-) It has something to do when a strict
>> scheduler is in effect. It's in effect when software queueing is in
>> effect and is in effect when lower layer (for the lack of better term
>> - TX, parent shaper) signal they are congested (TX) or they exist
>> (shaper).
>>
>> Now, your message I'm responding to clearly shows you really
>> misunderstand how CBWFQ works. There is no policer there. Conditional
>> policer exists only in the LLQ. Unfortunately, I'm off to watch The
>> Hobbit now, so I'll have to explain better in couple of hours.
>>
>> PRIORITY keyword does not create a "PRIORITY QUEUE". It creates LLQ,
>> which I downright * refuse* call by the term used in IOS for something
>> else.
>>
>> If you're curious. Create LLQ with 2 Mb/s priority. Send 10 Mb/s of
>> the traffic that matches, but *no* other traffic. Ensure that you're
>> not oversubscribing the outgoing interface. What will happen?
>>
>> --
>> Marko Milivojevic - CCIE #18427 (SP R&S)
>> Senior CCIE Instructor - IPexpert
>>
>>
>> On Mon, Dec 17, 2012 at 9:03 PM, Paul Negron <negron.paul_at_gmail.com>
>> wrote:
>> > 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
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Tue Dec 18 2012 - 01:16:15 ART