[TUHS] Re: scaling on TCP socket connections

[Paul Ruizendaal via TUHS <tuhs@tuhs.org>]

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@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.1
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.