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

[Fred Baker <fred@cisco.com>]

On Apr 7, 2012, at 4:54 AM, Neil Davies wrote:

> The answer was rather simple - calculate the amount of buffering needed to achieve
> say 99% of the "theoretical" throughput (this took some measurement as to exactly what 
> that was) and limit the sender to that.

So what I think I hear you saying is that we need some form of ioctl interface in the sockets library that will allow the sender to state the rate it associates with the data (eg, the video codec rate), and let TCP calculate

                           f(rate in bits per second, pmtu)
     cwnd_limit = ceiling (--------------------------------)  + C
                                g(rtt in microseconds)

Where C is a fudge factor, probably a single digit number, and f and g are appropriate conversion functions.

I suspect there may also be value in considering Jain's "Packet Trains" paper. Something you can observe in a simple trace is that the doubling behavior in slow start has the effect of bunching a TCP session's data together. If I have two 5 MBPS data exchanges sharing a 10 MBPS pipe, it's not unusual to observe one of the sessions dominating the pipe for a while and then the other one, for a long time. One of the benefits of per-flow WFQ in the network is that it consciously breaks that up - it forces the TCPs to interleave packets instead of bursts, which means that a downstream device on a more limited bandwidth sees packets arrive at what it considers a more rational rate. It might be nice if In its initial burst, TCP consciously broke the initial window into 2, or 3, or 4, or ten, individual packet trains - spaced those packets some number of milliseconds apart, so that their acknowledgements were similarly spaced, and the resulting packet trains in subsequent RTTs were relatively small.