Re: LLQ- help

This is some juicy stuff! For those of us not-yet-experts on the
sidelines - this is a gold mine of information. Thanks to the
experts! Keep it up, learning is happening. ;-)

-Tim

On Tue, Dec 18, 2012 at 7:54 AM, Joe Sanchez <marco207p_at_gmail.com> wrote:
> 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
>
> _______________________________________________________________________
> 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 - 09:57:15 ART