10 Mar
2023
10 Mar
'23
11:14 a.m.
From reading a lot of papers on the origins of TCP I can confirm that people appear to
have been thinking in terms of a dozen connections per machine, maybe half that on 16-bit
hardware, around 1980. Maybe their expectations for PDP-10’s were higher, I have not
looked into that much.
From: Tom Lyon <pugs78(a)gmail.com>
Sun chose UDP for NFS at a point when few if any
people believed TCP could
go fast.
I remember (early 80s) being told that one couldn't use TCP/IP in LANs
because they were WAN protocols. In the late 80s, WAN people were saying
you couldn't use TCP/IP because they were LAN protocols.
I’m not disputing the above, but there was a lot of focus on making TCP go fast enough for
LAN usage in 1981-1984. For example see this 1981 post by Fabry/Joy in the TCP-IP mailing
list: https://www.rfc-editor.org/in-notes/museum/tcp-ip-digest/tcp-ip-digest.v1n6…
There are a few other similar messages to the list from around that time.
An early issue was check-summing, with that initially taking 25% of CPU on a VAX750 when
TCP was heavily used. Also ideas like having "trailing headers" (so that the
data was block aligned) were driven by a search for LAN performance. Timeouts were reduced
from 5s and 2s to 0.5s and 0.2s. Using a software interrupt instead of a kernel thread was
another thing that made the stack more performant. It always seemed to me that the
BBN-CSRG controversy over TCP code spurred both teams ahead with BBN more focussed on WAN
use cases and CSRG more on LAN use cases. I would argue that no other contemporary network
stack had this dual optimisation, with the possible exception of Datakit.