Re: [Bloat] Best practices for paced TCP on Linux?

[Jonathan Morton <chromatix99@gmail.com>]

On 7 Apr, 2012, at 10:01 pm, Steinar H. Gunderson wrote:

> I got reports from people in Norway that this instantly stopped the problems
> on the HD stream, so incredibly enough, it may have worked.
> 
> I don't understand these mechanisms. Why would a smaller send window help?
> Less burstiness?

That's the short answer, yes.  It limits the amount of data that can be "in the network" at any one time, which is where it needs to find buffers whenever the link speed narrows.  If it needs to find buffers but they aren't big enough to hold all the data, packets are lost.

Another side effect is that it increases the "resonant frequency" of the connection, so the receiver can communicate about lost packets and actually receive the retransmissions before it's own buffer runs out.

Note also that once the client buffer is satisfied, it only needs to get data smoothly, almost one frame at a time, whereas if it has just had to deal with a major loss event, the buffer will be empty and needs a lot of data to fill it.  This latter effect is why, once the problem has occurred, it keeps on occurring.  The periodicity probably is synchronised - to the video keyframes!

 - Jonathan