Re: LLQ- help

Paul, can you provide the configuration you used for your testing to include the IOS version and device used.

Regards,
 Joe Sanchez

( please excuse the brevity of this email as it was sent via a mobile device. Please excuse misspelled words or sentence structure.)

On Dec 18, 2012, at 3:16 AM, Marko Milivojevic <markom_at_ipexpert.com> wrote:

> 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
>
> _______________________________________________________________________
> 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 - 06:54:58 ART