Re: [Bloat] [Rpm] receive window bug fix

[rjmcmahon <rjmcmahon@rjmcmahon.com>]

> these folk do good work, and I loved the graphs
> 
> https://blog.cloudflare.com/unbounded-memory-usage-by-tcp-for-receive-buffers-and-how-we-fixed-it/

Very cool. Thanks for sharing.

I've been considering adding stress tests to iperf 2. Looks like 
Cloudfare has at least two

Small reads & writes with short delay to stress receive window 
processing per

   At the sending host, run a TCP program with an infinite loop, sending 
1500B packets, with a 1 ms delay between each send.
   At the receiving host, run a TCP program with an infinite loop, 
reading 1B at a time, with a 1 ms delay between each read.

And then, rx buffer limit tests, from 
https://blog.cloudflare.com/optimizing-tcp-for-high-throughput-and-low-latency/

   reads as fast as it can, for five seconds this is called fast mode, 
opens up the window
   calculates 5% of the high watermark of the bytes reader during any 
previous one second
   for each second of the next 15 seconds: this is called slow mode
   reads that 5% number of bytes, then stops reading
   sleeps for the remainder of that particular second
   most of the second consists of no reading at all
   steps 1-3 are repeated in a loop three times, so the entire run is 60 
seconds

   This has the effect of highlighting any issues in the handling of 
packets when the buffers repeatedly hit the limit.

Curious about any other traffic scenarios driven by socket read/write 
behaviors that could be useful. Or any others that might apply to WiFi 
aggregation.

Then, if there is a way to generalize these types of send/read/delay 
graphs with a parametric command line?

Bob