Re: LLQ- help (with elephants)

> #1 You are aware that 5th call may have gone through because the
> timing on it was such that packets were arriving in such a way to
> never trigger a congestion, even though you exceeded the bandwidth by
> calculation, but not in reality? See example from Carlos about
> elephants (brilliant!)
>
I said it DID NOT congest the link. the total bandwidth was under 128 K at
that point. Voice is very SOLID. Not bursty at all.

> #6 6th call of course overwhelmed the link, as the statistical timing
> offset was astronomical at that point for different flows to
> interleave without triggering the congestion. When this happens, *of
> course* policer kicks in and all traffic, regardless of the flow gets
> policed at the specified rate.

The burst can be configured to help drop more aggressively dude!!! Or extend
to not drop packets if need be.
>
> #3 "Kicked out of VOICE CLASS" - how *on Earth* does traffic gets
> kicked out of the class once it's classified there?

WHY do we configure Q limit then? So the drop happens somewhere else?

>
> #4 Higher burst parameter causes more draps? What's this about? If
> anything, higher burst means longer measurement interval (in what you
> claim it does), or higher calculated rate that can exceed without
> causing drops. Are you now claiming that BURST parameter in the
> priority command does something entirely different? If yes, pray
> explain, as I have lost you completely at this point.

You are taking me out of context here. I said the burst was high for the rate
being sent through the class but the burst parameter was not set to sustain
it. That is what I inferred.
>
Last but not the least...Paul Negron

Look at the sarcasm ! and I am supposed be professional!!

CCIE# 14856
negron.paul_at_gmail.com
303-725-8162

On Dec 19, 2012, at 7:01 PM, Marko Milivojevic <markom_at_ipexpert.com> wrote:

> On Wed, Dec 19, 2012 at 3:43 PM, Paul Negron <negron.paul_at_gmail.com> wrote:
>> Therefore, when I placed 4 calls that tootled approx 112K of the Pipe. All
>> worked well. The 5th call went through fine cause it was not enough to
>> congest the link. The 6th call had to have had congested the link which
>> kicked in the BURST parameter set in the Priority Queue and traffic
dropped
>> traffic out of the VOICE CLASS.
>>
> [...]
>> I also have in my notes that the POLICE action worked very similar to a
Single Rate 2 Color Policer. '
>>
>> The conclusion was that the Priority Class Burst Parameter will drop
traffic only when the link is congested, even if it's by a little depending on
the traffic.
>
> Dear Lord, I don't even know where to begin with this...
>
> #1 You are aware that 5th call may have gone through because the
> timing on it was such that packets were arriving in such a way to
> never trigger a congestion, even though you exceeded the bandwidth by
> calculation, but not in reality? See example from Carlos about
> elephants (brilliant!)
>
> #6 6th call of course overwhelmed the link, as the statistical timing
> offset was astronomical at that point for different flows to
> interleave without triggering the congestion. When this happens, *of
> course* policer kicks in and all traffic, regardless of the flow gets
> policed at the specified rate.
>
> #3 "Kicked out of VOICE CLASS" - how *on Earth* does traffic gets
> kicked out of the class once it's classified there?
>
> #4 Higher burst parameter causes more draps? What's this about? If
> anything, higher burst means longer measurement interval (in what you
> claim it does), or higher calculated rate that can exceed without
> causing drops. Are you now claiming that BURST parameter in the
> priority command does something entirely different? If yes, pray
> explain, as I have lost you completely at this point.
>
> Last but not the least...
>
>>
>> This is how the BURST parameter works.
>
> HOW? I never saw an explanation, just a mass confusion as some
> authority-referencing (Wendell), which is not a valid argument.
>
> --
> Marko Milivojevic - CCIE #18427 (SP R&S)

Blogs and organic groups at http://www.ccie.net
Received on Wed Dec 19 2012 - 19:28:38 ART