[TUHS] Craig Partridge on BBN vs BSD TCP/IP

[Paul Ruizendaal via TUHS]

> Craig wrote this to the IETF list, when people started talking some TCP/IP
> history. Since it's about the DARPA funded work at Berkeley, and the prior
> BBN implementation and how people (Craig certainly!) felt about it, I
> thought it might be interesting for folk here.
> 
> It's opinionated, but there's nothing wrong with opine IMO
> 
> https://mailarchive.ietf.org/arch/msg/ietf/rbWOYPjlCs2HwT4x66Hsuu7bCpI
> 
> -G

About 7 years ago I dived deep into the history of this and Craig was very helpful to locate and retrieve BBN document for that effort. At the time I did start on writing some pages for the TUHS FAQ section, but never quite finished the effort. The draft text is staged here:
https://chiselapp.com/user/pnr/repository/TUHS_wiki/wiki?name=early_networking
There are also many posts to this list between, say, 2016 and 2020.

The competition between the BBN stack and the CSRG stack was emotional and political at the time and this makes it tough to get a clear view on the technical history. Below some of my own conclusions and they are necessarily just that, my own conclusions.

- The BBN (and earlier NCP) stack designed to have minimal code interaction with the rest of the kernel. In the late seventies both the network stacks and the unix kernel were developing fast and minimal code interaction made sense. The BBN work continued in this line, also because it was supposed to be reference code for integration in multiple operating systems. CSRG on the other hand was (amongst other things) tasked to develop an API to support (distributed) message passing architectures and to integrate this with the Unix kernel.

- The BBN team was targeting Arpanet which used 50kb modems and satellite links. The CSRG team was targeting local area networks, notably early ethernet. Hence, the BBN code focused on reliability over poor connections, the CSRG code focused on speed over more reliable connections.

The different contexts lead to different design choices being made.

As to the specific topics that Craig mentions:

- CSRG was not tasked by DARPA "to put a VM into Unix”. Having done that with BSD3 and 4.0 made them credible as a contract partner for DARPA. It is correct though that the CSRG contract did *not* include the development of a TCP/IP stack.

- I am uncertain on the importance of “mbufs”. Craig sees this as a major innovation (and Clem seems to be of this opinion as well). Personally, I don’t see it. The 1975 NCP Unix already uses a scheme to create 64-byte buffers out of 512 byte disk buffers and the 1979 V7 Unix packet driver does something similar. Changing that to take space from the page manager instead does not seem like a big conceptual leap to me. The other innovation is the use of a “start” pointer with each buffer next to the “len” parameter. This allows to chop off protocol headers without copying. Slightly similar earlier work exists.

- "Rob also redid the code to work with software interrupts”. This is true, but misleading. The original BBN code used a separate kernel process to run the network code, not software interrupts. That I have first seen in the CSRG code. Later on, the BBN code was reworked to use software interrupts as well. Doing it this way is necessary on fast networks, as integrating the quick service of the network kernel process with regular process scheduling is too hard / slow.

- Bill Joy did rewrite the BBN TCP/IP stack. A few surviving SCCS snippets show that he started with (parts of) the BBN code and rapidly modified that code. Very quickly the result was a new code base, with just a few echoes of the starting point remaining. The original BBN code was neatly layered with an input state machine and many small action routines. This fits with the "portable reference code” purpose. CSRG was writing fast code for fast networks and the early VAX C compiler used a rather slow call sequence. My guess is that this was the main driver for preferring a single, big routine.

- The bug compatibility referred to appears to be an “off by one” error in the implementation of out-of-sequence (“urgent”) segments in the TCP stream. Here the BBN code and the CSRG code are off by one versus the spec. This is mentioned in the Comer networking books. Urgent segments in TCP are rarely used (it is easier to just open a second channel) and I don’t think many people encountered this protocol compliance bug in practice. Maybe only in the BBN-CSRG controversy it was important.

- It is true that the spec was still maturing at the time. TCP v4 was more or less done in 1979, but the full protocol did not come together until 1982. During that period IP was separated from TCP, UDP and ICMP were introduced, etc. and that this lead to two stacks having to be maintained in parallel.