Re: OT: Shaping and extended burst

The best I have been able to find is be = 2(traffic per round trip time)

So, if we expect a maximum round trip time of 100ms and 100kb to be sent
during that 100ms... the be would be 200kb. Is that more or less your
understanding?

On 3/5/2011 10:31 AM, Carlos G Mendioroz wrote:
> Well, if Be is too small the app will suffer.
> If it is too large, in the extreme, you don't shape at all.
> But the "right" one is dependent on so many things that we have
> some rules to do something that is not too bad.
>
> -Carlos
>
> Chris Proctor @ 05/03/2011 12:06 -0300 dixit:
>> Nod. This is on topic for me.
>>
>> I believe Aaron's interpretation is correct. I can understand why
>> the burst is needed, but I have never been able to figure out
>> "correct" burst size and what really happens when the burst size is
>> too large or small.
>>
>> Chris
>>
>> On 3/5/2011 8:29 AM, Aaron Riemer wrote:
>>> Thanks Carlos,
>>>
>>> I just wanted to know if my understanding was correct more than
>>> anything.
>>> When things don't add up I like to question rather than just accept an
>>> answer without knowing why. This I think helps to solidify my
>>> understanding.
>>>
>>> Thanks for your help again mate.
>>>
>>> Cheers,
>>>
>>> -Aaron
>>>
>>> -----Original Message-----
>>> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
>>> Carlos G Mendioroz
>>> Sent: Saturday, 5 March 2011 7:57 PM
>>> To: Aaron Riemer
>>> Cc: ccielab_at_groupstudy.com
>>> Subject: Re: OT: Shaping and extended burst
>>>
>>> Aaron,
>>> > What I am confused about is the fact that more than the CIR rate can
>>> > actually be sent over the initial lets say 1 second ...
>>>
>>> Now think about it, it's only the *first* second. When did it happen in
>>> an actual implementation ? :)
>>>
>>> It's called *burst* for a reason. And doing the analysis from the math
>>> is not going to help you understand it, IMHO.
>>>
>>> It's there to compensate the jitter in the packets, because your
>>> line rate is/may be way faster than your CIR, and your "small window
>>> perception" (aka Tc) of the rate may not be accurate.
>>>
>>> As far as I see it, this is not OT at all.
>>>
>>> -Carlos
>>>
>>> Aaron Riemer @ 05/03/2011 04:34 -0300 dixit:
>>>> Hi Guys,
>>>>
>>>>
>>>>
>>>> I am just reading up on the token bucket principles with shaping in
>>>> particular with the use of Bc and Be (extended burst capability).
>>>>
>>>>
>>>>
>>>> I have read that when Be is configured the token bucket maximum
>>>> size will
>>>> equal Bc + Be. Therefore initially (Let's say the first Time Period
>>>> Tc) Bc
>>> +
>>>> Be packets will be taken from the bucket.
>>>>
>>>>
>>>>
>>>> Does this mean that when Be is configured you can initially send
>>>> more than
>>>> the actual shaped rate?
>>>>
>>>>
>>>>
>>>> Take this example:
>>>>
>>>>
>>>>
>>>> I enable traffic shaping and set the shaped rate to 64kbps over a
>>>> 128kbps
>>>> serial link. I stick with the default Tc and therefore calculate Bc
>>>> to be
>>>> 8000bits (64000 * .125). I enable Be to be 8000bits as well.
>>>>
>>>>
>>>>
>>>> Going by the token bucket logic the shaper will take (Bc+Be) from the
>>> bucket
>>>> (the bucket is full to start with). This means 16000 bits are taken
>>>> effectively allowing the burst to 128kbps for the first Tc of .125ms.
>>>>
>>>>
>>>>
>>>> What I am confused about is the fact that more than the CIR rate can
>>>> actually be sent over the initial lets say 1 second of transfer (8
>>>> * Tc).
>>> I
>>>> calculate this to be 72k bits for the first second of transfer and
>>>> then
>>> 64k
>>>> bits for every subsequent second assuming full load over one second.
>>>>
>>>>
>>>>
>>>> Is this correct? I am just trying to get my head around it and
>>>> understand
>>>> this completely.
>>>>
>>>>
>>>>
>>>> Any comments welcome as always.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Thanks guys,
>>>>
>>>>
>>>>
>>>> -Aaron
>>>>
>>>>
>>>> Blogs and organic groups at http://www.ccie.net
>>>>
>>>> _______________________________________________________________________
>>>>
>>>> Subscription information may be found at:
>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>

-- 
Chris Proctor
--
This message was scanned by ESVA and is believed to be clean.
Blogs and organic groups at http://www.ccie.net