On Fri, Oct 17, 2014 at 7:31 AM, Yann Ylavic <[email protected]> wrote:
> The pcap does not show the window scaling factor (SYN SYN/ACK not > captured). > Without this factor, the client's receive window is of 65, which would > need a scaling factor of at least 9 (which is not the default AFAICT > in linux) to fit the 29216 bytes (ie. 53359 - 24143) in flight at the > time of the frame 20. > > Can't this be a *current* window issue (as opposed to the *max* > window), can you still reproduce with, eg : > sysctl -w > > net.ipv4.tcp_rmem="49152 49152 4194304" > on the client side (or anything that makes the client announce a > window > 30K from the very beginning)? > Thanks for having a look -- of course the one capture I actually posted was not running when the connection was established. I have overlayed with a complete one on people.a.o The advertised scaling factor / effective window size are extremely large by the end of these runs, 1MB. The client has: net.ipv4.tcp_rmem = 2129920 2129920 882129920 One interesting part that might not have came through -- my file was originally 130k, then 120k, and now only about 30k. It's always only the one last"partial" frame that is delayed by 1 RTT. -- Eric Covener [email protected]
