Re: How to use TCP window autosizing?

[Dave Huang <khym%azeotrope.org@localhost>]

On Mon, Aug 03, 2015 at 08:26:31AM -0400, Greg Troxel wrote:
> I have not actually read the code, but I am 99% sure that the window is
> only increased if there are signs that it isn't big enough.  That's
> complicated but the key point is that the connection has to be up
> against the window, rather than congestion.

The code in question seems to be in sys/netinet/tcp_input.c, around
line 2072. The comment says:

       * The criteria to step up the receive buffer one notch are:
       *  1. the number of bytes received during the time it takes
       *     one timestamp to be reflected back to us (the RTT);
       *  2. received bytes per RTT is within seven eighth of the
       *     current socket buffer size;
       *  3. receive buffer size has not hit maximal automatic size;

It seems like those criteria should be met... I haven't tried adding
printfs or something in the series of "if"s to see whether it's making
it all the way to the block that increases the size, and if not, which
check is failing.

> That's big, and perhaps you will fill that pipe, but I would be very
> surprised if you got 100 Mbps with no loss between you and the other
> end.

Perhaps there'd be an occasional lost packet, but it looks like there
are enough contiguous streams of packets with no loss that the
autosizing code should've kicked in.

> Hmm.  I was expecting to get to this point and suspect packet loss and
> tell you to run "xplot" (in pkgsrc) which lets you visualize the
> ack/etc. behavior.

I used xplot a long time ago, but can't get it working now...
tcpdump2xplot complains about "Malformed entry in dump file". I found
http://mail-index.netbsd.org/current-users/2004/11/30/0010.html which
suggests removing the string " IP" from the tcpdump output, but that
didn't help:

tcpdump2xplot: Malformed entry in dump file :1 "1438577662.919916 52.74.238.147.36628 > 10.1.1.73.22: Flags [S], seq 3042363803, win 26883, options [mss 8961,sackOK,TS val 17717649 ecr 0,nop,wscale 7], length 0"

Actually, I think I used tcptrace last time instead of
tcpdump2xplot... I'm not very proficient at interpreting these graphs,
but I think I know the basics, and I think it confirms that the window
size is too small and that the autosizing should increase the size.
You can take a look at http://www.azeotrope.org/~khym/pics/tsg1.png
and http://www.azeotrope.org/~khym/pics/tsg1_zoomed.png

> > If I increase net.inet.tcp.recvspace to 4194304, the scp connects and
> > does the ssh protocol handshake (according to "scp -v"), but the data
> > transfer never actually starts... no idea what that means. If I set
> 
> I wonder if there is a 32-bit bug someplace.  I would try a number that
> fits in 31 bits.

I set it to 4MB, not 4GB... 

> Here, you should use xplot, which will plot tranmsitted packets, the ack
> line, the window, and sacks.  Read the README, and use tcpdump2xplot.
> It will take you an hour the first time, but then you'll wonder how
> anybody can pore over numbers in tcpdump output to understand TCP
> ack/window/congestion behavior.

http://www.azeotrope.org/~khym/pics/tsg2.png and
http://www.azeotrope.org/~khym/pics/tsg2_zoomed.png

I don't really know how to interpret this one, but it doesn't seem
like there's was any packet loss/retransmission.
-- 
Name: Dave Huang         |  Mammal, mammal / their names are called /
INet: khym%azeotrope.org@localhost |  they raise a paw / the bat, the cat /
FurryMUCK: Dahan         |  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 39 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++