[ih] Another TCP Reference Implementation

[Bob Braden]

In a recent message to this list (Vol 73 Issue 15), Jack Haverty 
described his experience with implementing TCP/IP for a PDP-11/40 at 
BBN, one of the six "reference" implementations commissioned by Vint at 
ARPA . Jack suggested that we geezers who were responsible for the 
reference implementations should do memory dumps while we still can ;-( 
Herewith is my contribution.

My TCP/IP implementation was for an IBM 360 Model 91 in the UCLA 
computer center, communicating with the UCLA IMP as host 1/1. It ran 
under OS/MVT and later OS/MVS with virtual memory. The 360/91 might be 
called a maxi-computer, the top of IBM's 360 line. Furthermore, UCLA had 
stretched to buy 4 MB of main memory, the only other machine of that 
power having disappeared into some bunker in the Washington DC area. I 
believe that Vint chose the UCLA IBM system for a reference 
implementation because he wanted a real-world implementation ("real 
world" meant IBM 360 and OS/MVT in 1978) to convince skeptics in the DoD 
that TCP/IP was real.

Our TCP/IP implementation had several attributes that distinguished it 
from the other five reference implementations. First, it was written in 
IBM assembly language, not in C.At every TCP bakeoff, I had to put up 
with kidding from the other participants over the size of my program 
listing. I would come with a stack of IBM printer paper maybe 2" thick, 
while their C code fitted on 10 pages. (Which was not actually fair; my 
protocol implementations of TCP and IP took only 100 pages of heavily 
commented assembly language. The rest was a real time OS environment and 
interfaces to IBM software components.)Another difference was that the 
TCP/IP code replaced NCP on a production facility serving serious 
computational customers, especially the climate dynamics group at Rand. 
It had to work; the US government (under Nixon, if I recall) had slashed 
the government subsidy of university computing centers, and the 
ARPA-funded climate group supplied the dollars to keep the UCLA 
computing center alive.

When I launched into implementing TCP/IP, the UCLA 360/91 had been an 
ARPAnet host since 1971. We had an IMP interface (IBM *hated* having a 
3^rd part device on their channel!), a driver, and an implementation of 
the host-host protocol NCP. It supported User and Server Telnet, User 
and Server FTP, and a remote batch job entry program called NETRJS 
(RFC88, RFC740). Our FTP Server was undoubtedly the most complete 
implementation of the RFC 959 protocol ever, as we tried to support many 
of the features of IBM's very baroque file system. Initially, our Telnet 
server did not do anything very interesting because IBM's OS/MVT did not 
support time sharing. When IBM released OS/MVS with virtual memory and a 
primitive but useful time sharing system called TSO, we upgraded the 
ARPAnet code to run on the new hardware and OS and to couple the Server 
Telnet to TSO.

The package of code to support the ARPAnet with NCP, and later TCP/IP, 
wascalled theACP (ARPAnet Control Program. The ACP ran as a privileged 
job in an 80 KB memory partition.We began development of the ACP by 
constructing a general IPC mechanism that we called the Exchange, in the 
OS/MVT kernel. We were pretty naïve then, so we designed the IPC 
facility by analogy to a telephone crossbar switch. This is illustrated 
in the paper "A Server Host System on the ARPANET" , Fifth Data Comm 
Symp, 1977. Then we built a real time OS that ran as a system-level 
process ("task" in IBMese) within the ACP. This real time OS created 
pseudo tasks with non-preemptive scheduling (co-routines to Knuthians) 
and had all the usual OS primitives. Context switching among pseudo 
tasks was relatively light weight, so we used separate pseudo tasks for 
the IMP driver, the NCP, and the applications mentioned above. With this 
general environment, it was straightforward to insert TCP and IP modules 
in place of the NCP module. For several years, in fact, the 360/91 
supported both NCP in production and my experimental TCP/IP. So Jan 1, 
1983 was a non-event on the UCLA 360.

The NCP and applications were written by members of the very talented 
system programming staff * in the UCLA computer center (ah, the good old 
mainframe days!). I was wise enough to keep my fingers out of the 
code.But implementing the TCP/IP protocols looked like a really fun 
task, so I took it on myself.

Like the others, I began with version 2.5 of the TCP spec, the last 
version before the famous split. I recall taking a programming scalpel 
to the version 2.5 code to create distinct IP and TCP layers; thanks to 
a lucky modularity, it was quite straightforward. I note with some 
chagrin that, according to RFC 1025, my code had the lowest score in the 
bakeoffs.I don't recall why we lost points. I believe that the UCLA 
TCP/IP code was written with care for efficiency, although we did not 
think of VJ's header prediction idea. It implemented the Push bit and 
the Urgent pointer correctly according to the intent of the TCP spec. 
The Push bit was important for record-oriented systems like IBM's. Come 
to think of it, it might be easier to implement the record-oriented SCTP 
than TCP on an IBM mainframe.

Someone mentioned the early problems with getting the check sums right. 
Another issue that took some time to resolve was sequence number 
comparisons. It turned out to be surprisingly subtle. Strangely, the 
simplest most obvious algorithm turned out to be the right one.

Why did I use assembly language? Because there was no reasonable 
alternative. IBM refused to release their PL/C system programming 
language, and PL/I was hopelessly heavy weight and baroque.

In 1983, I found an open-source C compiler for a 360 from AT&T, and I 
adapted it to compile code to run in the ACP envornment. Using the AT&T 
C compiler, I implemented SMTP User and Server code as well as RFC 822 
in C. Had I stayed at UCLA I would probably converted other parts of the 
ACP into C, but in 1986 I moved from UCLA to ISI.

Those were truly fun times. Jack and Vint, is there an authoritative 
list of the six reference implementations?

Bob Braden

*Especially Steve Wolfe, Stu Feigin, Lou Rivas, Neil Ludlam, and Denis 
DeLaRoca for the ARPAnet/Internet code.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20130422/737e28b6/attachment.htm>