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 wrote: > > > On 29 Mar, 2015, at 11:04, sahil grover > 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 > >