Re: [Bloat] Tackling bufferbloat in 3G/4G networks: A receiver-based TCP solution.

[Jonathan Morton <chromatix99@gmail.com>]

On 4 Jun, 2012, at 4:32 am, Haiqing Jiang wrote:

> It's really excited to find the new direction to tackle bufferbloat, on TCP layer instead of routers (like AQM). The bufferbloat problem actually seems to be the most prominent, comparing with other networks. 
> Therefore, we suggest the more efforts to tackling bufferbloat problem in cellular networks and seeking a good solution in TCP layer space.

I read the paper quickly, and this seems to be a good use of TCP timestamps.  It thus represents an additional way to solve (or at least mitigate) the problem in cases where the managers of bottleneck links are unwilling or unable to implement AQM.

If you look far enough back in the list archives - search for "Blackpool", for example - you'll see that I implemented a somewhat cruder solution using the same basic mechanism - limiting the receive window to prevent a single TCP stream from attempting to occupy the entire buffer.  It was cruder because it simply chose a window size based on the bandwidth of the flow and an empirical relationship between bandwidth and last-mile-hop latency, and didn't attempt to use timestamps.  It made a big difference for traffic from my local cell tower to a desktop Linux machine.

May I ask what happens if TCP timestamps are not available for a particular flow, particularly one that competes with a timestamped flow?  Such crude stacks are probably getting less common now, but they undoubtedly still exist.

It would also be interesting to investigate what happens when your scheme competes with a number of LEDBAT based flows (eg. uTP), both with and without AQM in place.

 - Jonathan Morton