. On Sun, Mar 29, 2015 at 10:04 PM, sahil grover 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 > 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 >> >> >