Rob <nom...@example.com> writes: > Dave Täht <d...@taht.net> wrote: >> Bufferbloat is different that the TCP receive or transmit window >> size. Bufferbloat is unmanaged buffers in the software TXQUEUE, the >> hardware TX ring, and the device itself. >> >> The TCP layer of buffering is not what we are talking about with >> bufferbloat. TCP's window and amount of buffering is highly tunable, and >> controllable. > > When the users would set their TCP window to a reasonable value, the > bufferbloat problem would not exist! > When the TCP window is correct for the delay*bandwidth product of a > TCP session, there are no packets piling up in buffers halfway, as > there is a continous stream of just enough data.
Without TCP supplying timely - unbuffered - feedback via ACK and ECN - data will pile up in the unmanaged buffers, period. Unmanaged buffers have the tendency to fool TCP into thinking that your actual distance from site A to site B is several lunar distances. > When everyone sets multi-meg windows and does not properly slowstart > the connection, the bufferbloat problem kicks in. There are many other potential causes, but yes, that's one. This thread has gotten way off topic, if you'd like to discuss this sort of stuff in more detail, join lists.bufferbloat.net -- Dave Taht http://nex-6.taht.net _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
