From nowicki@Sun.COM  Tue May 16 15:48:38 1989
Posted-Date: Tue, 16 May 89 15:49:22 PDT
Received-Date: Tue, 16 May 89 15:48:38 -0700
Received: from Sun.COM by venera.isi.edu (5.61/5.51)
	id <AA27514>; Tue, 16 May 89 15:48:38 -0700
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)
	id AA01786; Tue, 16 May 89 15:49:31 PDT
Received: from sparky.sun.com by snail.Sun.COM (4.1/SMI-4.1)
	id AB13243; Tue, 16 May 89 15:48:14 PDT
Received: from rose.sun.com by sparky.sun.com (4.1/SMI-4.1)
	id AA08739; Tue, 16 May 89 15:49:22 PDT
Date: Tue, 16 May 89 15:49:22 PDT
From: nowicki@Sun.COM (Bill Nowicki)
Message-Id: <8905162249.AA08739@sparky.sun.com>
To: van@helios.ee.lbl.gov
Subject: Obscure TCP implementation question
Cc: end2end@venera.isi.edu
Status: R

We recently ran into another obscure problem with TCP performance, at
least in the BSD implementation of Van's congestion control.  The
problem happens if the MTU of the network allows an MSS greater than
the default send size, and the user buffer size is also larger than the
default send size.  For example, on FDDI, MSS can be 4388 (once the
other bugs are fixed in raw 4.3).  The problem is that the "congestion
window" field (tp->snd_cwnd in BSD) is initialized to be the send space
(sbspace(&so->so_snd), 4K default) when the socket is created.  After
the creation, but before the connect, the send space is increased to
24K.  When I send my first data, using a buffer of 8K, it sends the
first 4096 bytes and then goes into persist mode, since it thinks the
congestion window is still 4096.  After one persist timeout, the window
gets opened back up to 24K and everything goes at full speed, but that
initial persist timeout really kills performance.

I fixed this by adding an update to tp->snd_cwnd in the connect code,
in tcp_usrreq, just after setting the initital sequence number
tp->iss.  However, this still seems wrong to me.  Why does the send
congestion window have anything to do with the socket SEND space? How
about using the initial window of the other side on the received SYN?
(That is, it should be the other side's receive space, like snd_wnd.)

	-- WIN