Re: LLQ- help

Didn't you see his previous message, when he tested non-FR interface?
Go back and check it out...

--
Marko Milivojevic - CCIE #18427 (SP R&S)
Senior CCIE Instructor - IPexpert
On Tue, Dec 18, 2012 at 12:05 PM, Paul Negron <negron.paul_at_gmail.com> wrote:
> Actually, I'm not aware that he disproved it. In fact, He proved it with
> Frame Relay by showing you that he was NOT congested and still experienced
> drops. How did that support my wrong case?
>
> For nowb&lets agree to disagree.
>
> When I show you that the burst rate WILL INDEED affect the traffic even when
> the link is NOT congested, You may change your mind or I will if it is
> proven otherwise.
>
> Agreed?
>
> Paul
>
> Paul Negron
> CCIE# 14856
> negron.paul_at_gmail.com
>
>
>
> On Dec 18, 2012, at 2:53 PM, Marko Milivojevic <markom_at_ipexpert.com> wrote:
>
> You are aware that Carlos disproved what you were saying all along,
> except for Frame Relay? Given how Frame Relay has its own QoS
> mechanisms (granted, probably not at play here), I don't see how this
> is supporting your (wrong) case :-)
>
> Anyway... Feel free to misunderstand how LLQ works. I'll keep
> understanding it well and we're all happy...
>
> --
> Marko Milivojevic - CCIE #18427 (SP R&S)
> Senior CCIE Instructor - IPexpert
>
> On Tue, Dec 18, 2012 at 11:40 AM, Paul Negron <negron.paul_at_gmail.com> wrote:
>
> Very well done Carlos!!!
>
> That burst is pesky and a pain !!!!! This is similar to what I saw in my
> "INVALID TEST"
>
> This is the reason why they removed it in IOS-XR as a default.
>
> Now, I would think that this output should help others in putting this to
> bed. Any complaints against it would be pure pride and speculation.
>
>
> Paul Negron
> CCIE# 14856
> negron.paul_at_gmail.com
>
>
>
> On Dec 18, 2012, at 11:44 AM, Carlos G Mendioroz <tron_at_huapi.ba.ar> wrote:
>
> Yes, there are policy drops:
>
> HQ-1#sh policy-map interface
> Serial0/1/0
>
> Service-policy output: prioUDP
>
>   queue stats for all priority classes:
>
>     queue limit 64 packets
>     (queue depth/total drops/no-buffer drops) 0/0/0
>     (pkts output/bytes output) 297/292842
>
>   Class-map: udp (match-all)
>     460 packets, 453560 bytes
>     5 minute offered rate 10000 bps, drop rate 6000 bps
>     Match: access-group name udp
>     Priority: 100 kbps, burst bytes 2500, b/w exceed drops: 163
>
> Without the service policy, all traffic flies...
>
> -Carlos
>
> Marko Milivojevic @ 18/12/2012 13:33 -0300 dixit:
>
> Can you post the output of "show frame pvc" when you tested the FR? I
> would be very careful jumping to any conclusions (which you did not),
> as something other than the policer could be dropping those packets.
> Did you see the hit counter increase on the drops in the class?
>
> --
> Marko Milivojevic - CCIE #18427 (SP R&S)
> Senior CCIE Instructor - IPexpert
>
> On Tue, Dec 18, 2012 at 7:26 AM, Carlos G Mendioroz <tron_at_huapi.ba.ar>
> wrote:
>
> Just tested this under 15.1.1T @ 2811.
>
> Incoming interface fastEthernet, outgoing serial.
> Monitoring TX on serial via snmp, generating with a script udp traffic
> at a constant rate.
>
> Baseline: 100K and 200K both are seen at TX on serial.
> Check1:
>  class-map match-all udp
>   match access-group name udp
>  policy-map prioUDP
>   class udp
>     priority 100
>  interface Serial0/1/1
>   service-policy output prioUDP
>  ip access-list extended udp
>   permit udp any any
>
> Both 100K and 200K seen on TX on serial.
>
> That was my understanding. (no congestion, no policing).
>
> But... same code, same config on an interface that has frame relay, does
> drop packets even when not congested.
>
>
> To play with this, all you need is one router (real one, no dynamips to test
> QoS please :), and some time.
> I can provide a perl script that generates udp traffic. Also copy of a small
> SNMP interface traffic graphing tool which is handy.
> (Interface Traffic Indicator, InfTraf.exe
> Version 1.1.0; April 2004
> Software by Carsten Schmidt)
>
>
> -Carlos
>
>
>
>
> Carlos G Mendioroz @ 18/12/2012 06:56 -0300 dixit:
>
> May I ? :)
>
> It might be that the whole issue is that:
> -the behaviour changed in some point in time
> -the behaviour is different in some architecture
> -some test was done with some issue that drove a false idea on someone
>
> I have not tested this latelly, but it used to be the case that the
> policer would not be there when not congested. Fact, tested by many.
>
> I will retest this ASAP to (again ?) be ascertive about it. I respect
> Paul and it may be that with some code (an some arch) this has changed.
> After all, it would make sense for cisco to impose a policer on a
> priority queue always, because that's how most people believe it would
> behave.
>
> The burst size may just be a measurement parameter. After all, instant
> rate is always input interface speed, right ? You for any throughput
> metering, you need some time slots, which might not be aligned, and some
> bursting slack.
>
> As to whether there is or not a queue, it would be very hard to be
> conclusive, because the TX ring will always behave as one. But what
> difference would it make, or if it would be needed at all given that
> it is priority and should be below the output if rate, I don't know nor
> care :)
>
> I would like this NOT to be taken offline. We all can learn. I would
> also like to everyone to agree to a self imposed rate limit, may be
> exponential, to filter any impulse driven answer. It's an important
> subject, IMHO.
>
> -Carlos
>
>
>
> Marko Milivojevic @ 18/12/2012 02:14 -0300 dixit:
>
>
> 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
>
>
>
>
>
> --
> Carlos G Mendioroz  <tron_at_huapi.ba.ar>  LW7 EQI  Argentina
>
>
> --
> Carlos G Mendioroz  <tron_at_huapi.ba.ar>  LW7 EQI  Argentina
Blogs and organic groups at http://www.ccie.net