Re: LLQ- help (with elephants)

Hmm, I still don't get it quite clear.

Part of your presentation on what the BURST parameter is relies on the
messages that debug shows, and you analyze:

now 8928004 tokens 6000 pak_size 8032 max_token_limit 6000
WFQ: dropping a packet from the priority queue 0

and deduce that you are dropping all packets because the packet size
exceeds the burst.

But I have been playing with sending packets of half the burst size
(375) at slighty more of the allowed bandwidth (40k) and this is what
happens: (LLQ engaged all the time thanks to extra traffic)
(timestamps removed for clarity)

now 13945052 tokens 5088 pak_size 2944 max_token_limit 6000
now 13945128 tokens 4424 pak_size 2944 max_token_limit 6000
now 13945204 tokens 3760 pak_size 2944 max_token_limit 6000
now 13945280 tokens 3096 pak_size 2944 max_token_limit 6000
now 13945356 tokens 2432 pak_size 2944 max_token_limit 6000
WFQ: dropping a packet from the priority queue 0
now 13945432 tokens 4712 pak_size 2944 max_token_limit 6000
now 13945508 tokens 4048 pak_size 2944 max_token_limit 6000
now 13945584 tokens 3384 pak_size 2944 max_token_limit 6000
now 13945660 tokens 2720 pak_size 2944 max_token_limit 6000
WFQ: dropping a packet from the priority queue 0
now 13945740 tokens 5120 pak_size 2944 max_token_limit 6000
now 13945812 tokens 4336 pak_size 2944 max_token_limit 6000
now 13945892 tokens 3792 pak_size 2944 max_token_limit 6000
now 13945968 tokens 3128 pak_size 2944 max_token_limit 6000
now 13946044 tokens 2464 pak_size 2944 max_token_limit 6000
WFQ: dropping a packet from the priority queue 0
now 13946120 tokens 4744 pak_size 2944 max_token_limit 600
...

See the pattern ? I would say that 750 (6000) is really Bc + Be,
(i.e. the token capacity and not the token replenishment).
It is not having a fixed Tc, because the math is being done at
packet arrival time (now value reflects this in ms)

But I agree, this is a two color one rate policer.
(This test done with pre HQF image).

-Carlos

Narbik Kocharians @ 20/12/2012 13:26 -0300 dixit:
> But Carlos you can maually set it at 750, it could be that the new
> 12.4(15)T code calculates the default using a different formula, I have not
> tried it on 15 code. But the fact is that burst works they way the lab
> proves it. Just like a single rate two color marker.
>
> On Thu, Dec 20, 2012 at 7:25 AM, Carlos G Mendioroz <tron_at_huapi.ba.ar>wrote:
>
>> Well, I tried a 12.4(15)T and I get your output:
>>
>> RouterA#sh policy-map int
>> Serial0/0/0
>>
>>
>> Service-policy output: tst
>>
>> Class-map: ef (match-all)
>> 0 packets, 0 bytes
>> 5 minute offered rate 0 bps, drop rate 0 bps
>> Match: precedence 5
>> Queueing
>> Strict Priority
>> Output Queue: Conversation 40
>> Bandwidth 30 (%)
>> Bandwidth 30 (kbps) Burst 750 (Bytes)
>> (pkts matched/bytes matched) 0/0
>> (total drops/bytes drops) 0/0
>>
>> which leds me to believe that this is pre HQF ( 12.4(20)T ) behaviour.
>> -Carlos
>>
>> Carlos G Mendioroz @ 20/12/2012 09:14 -0300 dixit:
>>
>> Narbik,
>>> Would you mind sharing which IOS version those tests were made on ?
>>> Trying to reproduce it and I get burst at 1500 instead of your 750 value
>>> on the serial interface with the tst policy.
>>> Also, I'm curious about your show policy map showing "conversations"
>>> wich is a gadget from CBWFQ which is not present on HQF.
>>> On 15.1(1)T :
>>>
>>> HQ-1#sh run int s 0/1/1
>>> Building configuration...
>>>
>>> Current configuration : 204 bytes
>>> !
>>> interface Serial0/1/1
>>> bandwidth 100
>>> ip address 10.1.7.101 255.255.255.0
>>> ip access-group drop in
>>> loopback
>>> no keepalive
>>> clock rate 2000000
>>> max-reserved-bandwidth 80
>>> service-policy output tst
>>> end
>>> HQ-1#sh policy-map int
>>> Serial0/1/1
>>>
>>> Service-policy output: tst
>>>
>>> queue stats for all priority classes:
>>>
>>> queue limit 64 packets
>>> (queue depth/total drops/no-buffer drops) 0/0/0
>>> (pkts output/bytes output) 0/0
>>>
>>> Class-map: ef (match-all)
>>> 0 packets, 0 bytes
>>> 5 minute offered rate 0 bps, drop rate 0 bps
>>> Match: precedence 5
>>> Priority: 30% (30 kbps), burst bytes 1500, b/w exceed drops: 0
>>>
>>>
>>> ...
>>>
>>> For sake of comparizon, your R1 output:
>>> R1#Show policy-map interface
>>> Serial0/1
>>> Service-policy output: tst
>>> Class-map: ef (match-all)
>>> 0 packets, 0 bytes
>>> 5 minute offered rate 0 bps, drop rate 0 bps
>>> Match: precedence 5
>>> Queueing
>>> Strict Priority
>>> Output Queue: Conversation 40
>>> Bandwidth 30 (%)
>>> Bandwidth 30 (kbps) Burst 750 (Bytes)
>>> (pkts matched/bytes matched) 0/0
>>> (total drops/bytes drops) 0/0
>>>
>>> Tks,
>>> -Carlos
>>>
>>> P.S.
>>> Why on earth trying to understand this stuff is childish ?
>>>
>>> Narbik Kocharians @ 19/12/2012 21:18 -0300 dixit:
>>>
>>>> To all,
>>>>
>>>>
>>>> Please go to micronics.nl and download the LLQ-LAB and I think I have
>>>> done
>>>> my best to show how the "burst" in LLQ works just like the Bc in single
>>>> rate two color marker, by the way there are no Be in two color marker
>>>> with
>>>> single rate. BUT I do not have time to go over that and prove it, even
>>>> though I can.
>>>>
>>>>
>>>> BTW, this is my last post, i am conducting a class and have no time for
>>>> this kind of childish stuff , It is embarrassing (Double
>>>> dare??)sharing which
>>>> wow.........
>>>>
>>>> Have fun.
>>>>
>>>>
>>>> On Wed, Dec 19, 2012 at 4: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)
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>> --
>> 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