From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 19:23:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2C701065676 for ; Thu, 18 Feb 2010 19:23:22 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail3.es.net [IPv6:2001:400:4c01::2]) by mx1.freebsd.org (Postfix) with ESMTP id C39B18FC18 for ; Thu, 18 Feb 2010 19:23:22 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o1IJNKo6031149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Feb 2010 11:23:21 -0800 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id B34251CC09; Thu, 18 Feb 2010 11:23:20 -0800 (PST) To: Harald Schmalzbauer In-reply-to: Your message of "Thu, 18 Feb 2010 17:24:05 +0100." <4B7D69A5.4010506@omnilan.de> Date: Thu, 18 Feb 2010 11:23:20 -0800 From: "Kevin Oberman" Message-Id: <20100218192320.B34251CC09@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-02-18_14:2010-02-06, 2010-02-18, 2010-02-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1002180148 Cc: Patrick Mahan , freebsd-stable@freebsd.org, Stephen Hurd Subject: Re: 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]] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 19:23:23 -0000 > Date: Thu, 18 Feb 2010 17:24:05 +0100 > From: Harald Schmalzbauer > Sender: owner-freebsd-stable@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@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751