> Date: Thu, 18 Feb 2010 17:24:05 +0100 > From: Harald Schmalzbauer <h.schmalzba...@omnilan.de> > Sender: owner-freebsd-sta...@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: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
