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 ; 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