[Bloat] Requirements for bufferbloat to occur

David Lang david at lang.hm
Sun Mar 29 14:02:44 EDT 2015

On Sun, 29 Mar 2015, sahil grover wrote:

> 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).

These are several different concepts, all related to network perfromance, but 
most unrelated to buffer sizing.

Any network connection is either 100% used, or idle if you look at a small 
enough timeframe. When the network connection finishes sending one packet, it is 
idle until the next packet is available to send. If there is no buffer, the 
connection is idle until the software generates new data to send. since this 
takes time, the connection will be idle. As a result, you want to have some 
buffer so that the software can generate the traffic a little earlier than it's 
needed so that as soon as the network finishes sending one packet, it has the 
next packet available to send.

when you have a router that is receving packets from multiple computers and 
sending it out one link, buffers become even more important, if you have two 
computers send you a packet at the same time, without a buffer youc an only send 
one and the other will have to be dropped. so you need to have a buffer to hold 
the second packet so you can send it out as soon as you have time.

bufferbloat is when the buffers are "too large" for the output connection and 
you end up with "too much" data sitting in the buffers waiting to be sent. The 
problem with trying to size buffers is that how long it takes to transmit the 
data in the buffer depends on how large the packets in teh buffer are and how 
fast the connection is. Traditionally, buffers were sized in terms of X packets. 
If you have a buffer that can hold 10ms worth of 75 byte packets at 1Gb/sec, 
but you are connected to a DSL line with an upload spped of 1Mb/sec and are 
sending 1500 byte packets, then your buffer now holds 200,000ms worth of 

TCP ramps up it's sending speed until it looses packets (or gets an ECN signal), 
no packets will be dropped until the buffer fills up (in addition to the traffic 
that gets sent), so the buffer will fill up and everything that you try to do, 
including DNS lookups, gaming, VoIP, etc is going to be delayed by how long it 
takes to get through the buffer.

window size, delay-bandwidth product, etc are a different aspect of the network 
stack. they limit a little bit how much traffic a single TCP connection will try 
to send without receiving any ack packets for the data. The idea is that if you 
have a 1Gb/s connection, and a 1sping time, to keep the connection full you 
should have 1Gb of taffic "in flight" (i.e. that you have sent and not yet 
received acks for). If your window of allowd unacked data is less than this, 
then you send your limit, then the connection goes idle until the receiving side 
sends the asks

Since the system doesn't actually know how long the path is, or the available 
bandwidth, it again is guessing this and ramping it up until it runs into 
trouble and then slows down

so back to your questions, the delay of the link times the bandwidth of the link 
(delay-banseidth produt) determins the ideal window size for a given TCP 
connection. This determins the minimum size of a buffer of unacknowleged packets 
that a system has transmitted. This has _nothing_ to do with the buffer size for 
packets that a system or rotuer is waiting to transmit. Bufferbloat happens on 
the buffer for packets that are waiting to be transmitted.  a few ms worth of 
buffering for packets waiting to be transmitted is necessary to keep the 
connection busy, bufferbloat happens when these queues get much larger than this 
minimum value. There isn't a hard limit that separates bloat from non-bloat, but 
if your queues are over a second, you are very clearly way beyond a reasonable 
size buffer. 10s of ms is probably reasonable, 100s of ms is probably not.

Does this help?

David Lang
-------------- next part --------------
Bloat mailing list
Bloat at lists.bufferbloat.net

More information about the Bloat mailing list