John Romkey, as told to Bernard Aboba
Dave Clark had gone to England for sabbatical and while he was there, had implemented TCP/IP in BCPL for the TRIPOS operating system, a predecessor of the Commodore AMIGA operating system. He brought the TCP/IP code back with him, and the Lab for Computer Science had a bunch of Xerox Alto workstations, and someone at LCS ported Dave's TCP/IP to the Alto.
Then someone ported it to Version 6 UNIX and rewrote it in C. And that was what we took, and ported to PC DOS. At that point there were no C compilers that ran on the PC, and we were using a compiler that ran on a PDP 11/45 on Version 6 UNIX, and then on a VAX 750 running BSD v4.1. That was the AT&T portable C compiler, and a group of people on the fourth floor of the LCS had written an 8088 code generator for it. This was before Microsoft C, and before 4.2 BSD.
Our first tasks were to bring up TFTP, TCP, and a telnet client under DOS. Several people were involved. Lou Konopelski did the initial TCP and telnet work, and Dave Brigham did similar work to what I did. This was my first C programming experience!
The port was very difficult. We didn't have a debugging environment, so we had to rely on printf debugging. Fortunately a lot of the code we started out with was good code, but there were problems because C was not as standardized then as it is today. For example the behavior of a shift operator would vary depending on the processor it was running on and the C compiler. Sometimes it would carry the sign bit, and sometimes it would not, and that caused a lot of wierd problems, which have largely been cleaned up by the ANSI C specification.
That was the very first TCP/IP for IBM PCs, called PC-IP, and it was pretty successful. We brought up a bunch of small programs under DOS, such as finger, whois and time client. I also wrote an application called NetWatch, which was inspired by an application that ran on the Altos called EtherWatch, that gave you a dump in octal of every packet. It had no filtering capabilities, just lots of octal numbers.
We had one of the very first 3COM Ethernet boards, which could be put into promiscuous mode. For a debugging tool, I built netwatch, which I believe was the first monitor for PCs. That would print out a dump in Hexadecimal of all the the packets as they went by. Then I realized that this was a computer, and so I added table-driven lookups and it printed out TCP/IP headers in a form that was much easier to understand.
After we finished the project, the source code for PC-IP was given away, and a lot of people got it. In fact, some people ask for it now, but it's way out of date. Jerry Saltzer had arranged the copyright, which said you could do anything with it, including sell it, as long as you credited MIT with having written it. This was before the Free Software Foundation, and I hope that Richard Stallman would have been proud of the copyright that Jerry Saltzer came up with.
After we released PC-IP, people asked for more things, and in my spare time I continued to maintain it. But since we had accomplished the goal of the research project in proving that it could be done, it wasn't part of my official job anymore. After I graduated, I became a staff member working with Dave Clark and didn't have much time to work on TCP/IP. A fellow at Carnegie Mellon University named Drew Perkins picked it up, and brought it from the cross compilation environment we had on the Vax to Microsoft C. CMU gave that port away again on the same terms as MIT did.
The most likely thing to do was to take TCP/IP, add the things people were asking for, and try to sell it. I wasn't really convinced that I could make a living off it, that people would pay money for it when they could get it for free. Then I heard from a friend that a company was selling PC-IP for $800, and I said "Boy, we can sell something much better for half the price!" and that convinced me to go ahead with it. So after that, five people, including myself and Dave Brigham, founded FTP Software, in 1986. A number of people that had been selling MIT's code became our distributors.
We started with CMU's port of PC-IP to Microsoft C, and although the code was basically good, we had a lot of work to do. We had taken a lot of shortcuts with PC-IP. PC-IP did not support fragmentation and it didn't support IP options, so we had to add fragmentation code to PC/TCP. A lot of other vendors ended up doing that as well in response to host requirements, since a lot of vendors were selling code that didn't support domain name system, or didn't support RFC 822 correctly in the mailers, or didn't support fragmentation.
It was pretty hard work for a while. I was it for development at FTP when we started, but we built the product, which included the first implementations of rlogin, lpr, and FTP.
Around that time a lot of other free TCP/IPs for PCs started showing up. There was KA9Q and NCSA Telnet. NCSA Telnet was totally independent of PC-IP. I think it may have been a port of BSD v4.2. KA9Q is an original implementation by Phil Karn, also by Phil Karn. Still later, Dan Lanciani at Harvard picked it up and rewrote it, and integrated in a number of things that people on the net had done, and produced the last release that bore the name PC-IP, in 1989.
In response I created the packet driver specification in 1988.It predated NDIS from Microsoft and ODI from Novell, but doesn't have any place outside out of the DOS/Windows environment. A packet driver under Windows NT or OS/2 is pretty much meaningless.
We're on the tenth revision of the specification now. I am not actively involved in updating the specification at this point, but the question is how the specification will evolve. It has an indefinite lifetime; as long as DOS is around, packet drivers will be useful, but it's not clear what the next step in their evolution is, or who should be shaping it, since companies other than FTP Software now have a stake in it. For example, there is a company called Crynwr, run by Russ Nelson, which does packet driver support, who did a large number of packet drivers under the GNU copyleft, who is making a living out of writing packet drivers.
Another issue was separating the TCP/IP stack from the applications. Prior to release v2.0 of PC/TCP, TCP/IP was integrated into each of the applications. In 1988, FTP was working with a distributor called Gold Hill, whose product was a LISP implementation that ran in protected mode on a 286. They were trying to provide a product that was similar in functionality to a Symbolics LISP machine, but on a PC, so they needed network support. They had a lot of code already, that wouldn't allow them to link in FTP software's TCP/IP.
FTP at the time was also investigating how to do an NFS client and a NetBIOS client, and there was no way to do that if TCP/IP was linked in with every application. So we had to separate the TCP/IP stack from the applications. Working with Gold Hill and Gaylord Miyata, he and I hashed out a specification for a programming interface, that ended up similar to Berkeley sockets, but that didn't try to provide the protocol independence that sockets has. The interface was really tailored to TCP/IP, and provided more asynchronous notification than sockets did.
For example, the application would get notification when data was received or when it was possible to do another write of data without blocking, or when a connection opened or closed. In sockets you do that using select, and we had a similar function, but you could also be notified. That was FTP Software's 2.0 release. At that point we were using Microsoft C.
FTP software also eventually followed up on NetWatch with a product called LANwatch, but at the time they didn't have the resources or vision to compete with Network General's Sniffer, which is the preeminent product. They are working on that now.
I worked for FTP Software for two years. It was doing pretty well when I left; it had always been profitable. It helped a lot to have a pretty good piece of code to start with; starting from scratch would have changed the picture. When we started out it was five technical people, and when I left we had a financial person and a marketing person. Now it has close to 300 employees.
We never really got to do those things; we got very caught up in the day to day chores of doing contract programming, and lost sight of our goals. Karl left Epilogue in 1990 and is now starting a new company called Empirical Tools and Technology (ETT), trying to follow up on those ideas by building intelligent active network debugging tools. He has a nice product called Dr. Watson, and is integrating a lot of strategies for debugging. A lot of people say "I have SNMP, and that's all I need to manage my network," but that's wrong. Network management tools like LanWATCH or Sniffer are a whole different class of tools, and that is what Karl is working on.
While at Epilogue, Karl wrote one of the very first SNMP implementations, a client and manager, which was designed to be portable and small. That was Epilogue's first product, and we licensed it. As a result, we found that clients would say to us "we want to hire you to create a UDP for us, for this to run over." So in order to avoid writing the same code over and over, I wrote a UDP that was designed to be as portable as possible, and we transitioned to doing product sales and licensing from contract programming.
We also added a TCP module, and I wrote a MIB compiler for SNMP. The MIB compiler would take in an SNMP MIB description and would generate C code that would do a variety of things with those variables for you. Over time, I guess I've developed a model of how I think applications should be written, which is that you should express components of an application in whatever way it is natural for that component to be expressed. For SNMP MIBS, the natural way to express it is in ASN.1, and the concise MIB format, and likewise, if you're expressing algorithms, it's natural to do the work in C or C++. I do most of my work in C++ nowadays.
And if you're doing a graphical user interface, it's logical to use tools. And then you have a view of an application as being a number of cooperating components, expressed in ways that are appropriate for the component's function. The MIB compiler for me was a tool for expressing MIBs.
So we had an SNMP controlled toaster. If you put bread in the toaster, and set a variable in SNMP, the toaster would start toasting. There was a whole MIB written up for it, including how done you wanted the toast, and whether it was a bagel or Wonderbread. In order to figure out a matrix of how long to toast a bagel or Wonderbread to get it done to a specific doneness, I ended up with lots and lots of bread in my garage.
The other exhibit we had that year was a weatherstation. I created a MIB that modelled Weather information, so that you could gather information from weather stations around the net, and query the weather state. But we never got that deployed.
The Internet Toaster got a lot of attention because of the novelty of it, but I don't think that managing your kitchen through SNMP is very practical today. I would never say that anyone should connect their appliances and try to manage it using today's protocols. However, to have a Toaster connected to an Ethernet shows a lot about the state of the technology and where it can go. So you should think in terms of using a network technology two or three generations beyond Ethernet to link appliances two or three generations from now.
This is the vision of ubiquitous computing, which could add pressure on the IP address space. However, regardless of whether this comes to pass, we will need to improve the way in which the IP address space is managed. Although I think the IETF working groups on the next IP are very important, I have been trying to stay far away from them, since they are also huge time sinks.
John initiated the conversation, and the three of us got together at a Chinese Restaurant called The Little Garden. We worked out the details of how to make it work between us, using very low end routers, PCs running KA9Q. We then made a deal with Rick Adams at Alternet, that would allow us to split the cost. We set it up and it worked, and I continued using it until I moved back to Boston.
My main interest now is usability. I'm concerned that a lot of the technology on the Internet is pretty bad, and that while the applications appeal to gadget freaks, there are a lot of people intimidated by VCRs, and they should be able to use the Internet as well.
The problem is that the applications are oriented to providing an interface to protocols, not doing a job. You use FTP to get files, but most FTP interfaces are just designed to interact with the FTP protocol, not to help you get files. I'm working with a small company now called ELF communications, and my partners and I each have projects to enhance the usability of the Internet. We are looking to improve people's ability to communicate and deal with the information glut.
