Re: OT: Shaping and extended burst

Ah, this makes sense on policing, we were talking about shaping before.
Basically, dropping packets "shapes" your tx speed on TCP. So he wants
to avoid the possibility of the policy dropping of packets forcing a
below CIR tcp flow rate. As TCP mandates a rate halving, doind that
at (perceived) twice the CIR would be ok.

Relax now, good luck on the test.
-Carlos

Chris Proctor @ 05/03/2011 19:05 -0300 dixit:
> One reference to it is here:
> http://slaptijack.com/networking/inbound-rate-limiting-on-cisco-catalyst-switches/
>
>
> "Because TCP window scaling
> <http://slaptijack.com/system-administration/what-is-tcp-window-scaling/> halves
> the window size for each dropped packet, its important to set the burst
> size at a level that doesnt impact performance. The rule of thumb is
> that the burst size should be double the amount of traffic sent at the
> maximum rate at a given round-trip time. In this example, I assumed a
> round-trip time of 50 ms which results in a burst size of 100 KB."
>
> I have also seen this in NetApp documentation for Snap Mirror
> implementation. There seems to be a relationship between the burst
> size. the round trip delay and the TCP windowing function. I have not
> seen a detailed explanation of the interaction though.
>
> For lab purposes, I'm not sure what implied delay would be. I suppose
> in a vaccum, I'd just go with the default burst size. Does anyone else
> have a different/better way to approach this issue?
>
> Chris
>
>
> On 3/5/2011 11:14 AM, Carlos G Mendioroz wrote:
>> I was referring to the Be = Bc or such simple lab rules.
>>
>> If you have the source of the one you are mentioning, it would be nice
>> to know the basis of such rule. I can not figure out why the round trip
>> time would have any relation to this, but may be in a good design
>> the numbers happen to match ?
>>
>> I would expect it to be more sensible to the ratio between AR and CIR.
>> As I said, this is in the end compensating jitter. Comonsense applies,
>> so to say. Also, may be the app is bursty to begin with! Too many ifs.
>>
>> -Carlos
> -- This message has been checked by ESVA and is believed to be clean.

-- 
Carlos G Mendioroz  <tron_at_huapi.ba.ar>  LW7 EQI  Argentina
Blogs and organic groups at http://www.ccie.net