Re: [Bloat] Requirements for bufferbloat to occur

[sahil grover <sahilgrover013@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3089 bytes --]

.

On Sun, Mar 29, 2015 at 10:04 PM, sahil grover <sahilgrover013@gmail.com>
wrote:

> Thanks a lot for replying.
>
> can you please explain me  the concept of  delay-bandwidth product,window
> size and buffer size(or something related with pipe size and packets in
> flight).
>
>  because i am unable to understand it from papers/articles etc.
>
> And the way you explained to me everytime, was very effective.
>
> So please help in making me understand this(BDP,window size) concept too .
>
>
>
>
>
> On Sun, Mar 29, 2015 at 2:09 AM, Jonathan Morton <chromatix99@gmail.com>
> wrote:
>
>>
>> > On 29 Mar, 2015, at 11:04, sahil grover <sahilgrover013@gmail.com>
>> wrote:
>> >
>> > (1) All say bufferSize should be set very large for bufferbloat to
>> occur.
>> >
>> > But how much large?? is there any condition?
>>
>> There’s a clue in the name: if the buffer is significantly larger than it
>> needs to be (and is unmanaged), we call that bufferbloat.
>>
>> If the buffer is too small to absorb a typical burst of packets, the
>> resulting increase in packet loss will cause a reduction in throughput.
>> The correct size for an unmanaged buffer is typically the delay-bandwidth
>> product, which enables it to absorb a transitory burst from a single TCP
>> flow.
>>
>> However, determining the delay is difficult a priori, and frequently
>> differs substantially between different flows on the same connection.  So
>> we usually make some reasonable assumption about the delay component of
>> that formula: 100ms is typical for a broadband connection to the public
>> Internet, and VoIP can just-about cope with that in practice.
>>
>> Or, to put it another way - if the buffer *induces* significantly more
>> than 100ms delay under load, that is bufferbloat.
>>
>> > (2) even after setting buffersize very  very large,  if packets get
>> dropped due to buffer
>> > overflow  when heavy traffic is there.
>> >
>> > is it bufferbloat?
>>
>> Yes.  Packet loss has nothing to do with it - it’s the induced delay that
>> matters.
>>
>> > sholud we take care that maximum limit of buffersize is never reached
>> and no
>> > packet  drop is there due to queue overlow for bufferbloat condition?
>>
>> Extremely large buffers are usually the result of hardware engineers
>> naively attempting to achieve zero packet loss, by providing buffers larger
>> than the TCP receive window size.  (That is a futile goal - rwnd is
>> unlimited in modern operating systems which support window scaling.)
>> However, zero packet loss is not a necessary condition.
>>
>> AQMs often deliberately drop packets in order to signal congestion to the
>> endpoints.  Under some circumstances, this can actually result in less
>> overall packet loss than on an unmanaged buffer.  Even without ECN, the AQM
>> rarely causes burst losses, whereas overflowing an unmanaged queue often
>> does.  With ECN, an AQM can often signal congestion sufficiently well
>> without dropping any packets at all.
>>
>>  - Jonathan Morton
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 4523 bytes --]