RELENG_8 ignoring TCP window size? [Was: Re: Help for TCP understanding wanted, ACK-MSS-Window [Was: Re: best practice to watch TCP parms of established sockets]]

[Kevin Oberman]

> Date: Thu, 18 Feb 2010 17:24:05 +0100
> From: Harald Schmalzbauer <h.schmalzbauer at omnilan.de>
> Sender: owner-freebsd-stable at freebsd.org
> 
> Stephen Hurd schrieb am 18.02.2010 17:09 (localtime):
> ...
> > A TCP SHOULD implement a delayed ACK, but an ACK should not be 
> > excessively delayed; in particular, the delay MUST be less than 0.5 
> > seconds, and in a stream of full-sized segments there SHOULD be an ACK 
> > for at least every second segment.
> 
> That's why I asked for help understandig TCP. I'm surely wrong then. I 
> thought the ACK segment gets sent after the transfer of n segments 
> equals windows-size. I don't undesrtand that window size yet... I'm back 
> into my books

I recommend "TCP/IP Illustrated, Volume 1: The Protocols" by the late
Rich Stevens. ISBN-13: 978-0201633467. It is easily the best book on how
TCP/IP should actually work, though it is 16 years old and a few bits
are obsolete. It is still my standard reference, though, and the basics
are very well presented and those have not changed much since window
scaling and the book covers that.

Use wireshark to look at the PCAP file. It can spot a variety of
"interesting" issues. For far more detail, tcptrace in conjunction with
xplot can really show what is happening, but it requires pretty good
understanding of how TCP works to make any sense of the output.

The window is used to allow for long RTT links and processing delays. A
path from the west coast of the US to Amsterdam is about 160 ms. The
window allows for many packets to be in flight and with a 3 Gbps flow,
that is a LOT of data. While an ACK is sent every two packets of
received data, the transmitting side does not wait for the ACKs. It
reduces the transmit window by the amount of data sent, but keeps
sending until the window is too for the next packet. It also keeps track
of received ACKs and, if one odes not come back, will retransmit. If
SACK is used, only the missing data is retransmitted. If SACK is not
enabled, all of the data from the missing packet on is retransmitted.

That is a VERY simple and incomplete explanation of what is happening
with the window, but most of that is irrelevant in local transfers with
reasonable window sizes. Since large windows can adversely impact local
transfers, most modern TCP stacks auto-tune window size. As a result,
local transfers should use a smaller window than long distance
transfers.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751