Date: Sun, 22 Jan 1995 06:21:25 -0500 From: "Charles M. Hannum" <mycroft@ai.mit.edu> To: davidg@Root.COM Cc: olah@cs.utwente.nl, hackers@FreeBSD.org Subject: Re: Netinet internals (Was: Patching a running kernel) Message-ID: <199501221121.GAA28543@duality.gnu.ai.mit.edu> In-Reply-To: <199501221012.CAA00270@corbin.Root.COM> (message from David Greenman on Sun, 22 Jan 1995 02:12:05 -0800)
next in thread | previous in thread | raw e-mail | index | archive | help
Choppiness aside, this also fixes another problem where some 4.3BSD based hosts would often send less than the expected mss during a normal bulk transfer on an idle network. This can happen if you fill up the socket buffer before outputting a full window, since the receiver will wait until either a delayed ack timeout or a full window is received before acking. This usually happens with Berkeley TCP because for `performance reasons' the socket buffer is not aggressively compressed; nonetheless it is a more generic problem, and caused a factor of nearly 100 slowdown in one particular application I was looking at that opens a TCP connection to the local machine. I solved this (in NetBSD) by having the receiver always ack immediately if the incoming packet has the PUSH bit set. In the worst cases, there is either no change (if the PUSH bit is never set), or delayed ack is effectively disabled (if the PUSH bit is always set). In a slightly better implementation of TCP, the application would be able to request a push. In Berkeley TCP, the PUSH bit is set by the TCP stack automatically for the last piece of data in the buffer. Most implementations I've seen use the bit in this latter fashion. For compatibility reasons, all senders must set the PUSH bit about as often as Berkeley TCP (whether automatic or by request of the user), so the `worst case' of `no change' never happens. For the case of an honestly requested push, acking immediately is clearly the correct thing to do, since the sender would like to know as soon as possible that the data has actually been received. For the Berkeley TCP case, it turns out to solve the previous problem, and cause no additional network usage for bulk data transfers. I'm not aware of any problems created by this solution. (BTW, I also posted about this to comp.protocols.tcp-ip, though I only received one reply, on a somewhat different subject.)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199501221121.GAA28543>