[ih] Fwd: Fw: Quantifying OSI

[Craig Partridge]

On Mon, May 11, 2026 at 10:09 AM Bob Purvy via Internet-history <
internet-history at elists.isoc.org> wrote:

> "Quantifying" : this is a good way to approach this. Everyone focuses on
> the money, especially from the USG, but there's also "implementation
> hours":
>
> How many hours did OSI proponents spend actually writing code and getting
> networks running? Writing papers and going to meetings doesn't count.
>
>
I'd suggest focusing on the hours spent running the network -- think of it
as post-initial implementation experience running and maintaining the code.

I say that because, especially after 4.2BSD was released*, implementing a
new protocol such as TP4 or CLNP became a straightforward semester project
for a graduate student (two semesters if you measured the performance of
your implementation).  I did it twice between 1984 and 1987 (HMP [RFC 869]
and RDP [RFCs 908 and 1151] - and RDP's state diagram was more complex than
TCP's).  My recollection is that Mitch Tasman found TP4 similarly easy (I
think he was the guy who did the Wisconsin TP4).  The one nit here is that
ES-IS turned out to conflict with the BSD routing model, causing Keith
Sklower (who did the BSD OSI implementation) some pain.

By 1989, what differentiated the protocol suites was the sheer number of
operational hours the implementations had accumulated and the protocol
implementation (and specification) improvements those operational hours
drove.   It takes a long time to winkle out some issues.  Two examples.
First, only in 1988, after SMTP had been used for 5 years and delivered
probably well over a billion messages, did I track down that SMTP had a
race condition (RFC 1047).  Second, as Van Jacobson improved the TCP
round-trip time estimator, he captured hundreds (thousands?) of traces over
challenging network links.  If you sat down with him during that time, he'd
likely start flipping through a stack of several dozen slides illustrating
how different RTT estimators would have performed over specific demanding
links.  Creating those challenging data sets could only happen in a network
under intense operational use (or really great network simulators, which we
did not have at the time).

Craig

*PS: Why did 4.2BSD matter?  It had a nice dispatch table mechanism in the
networking code which made it easy to drop in a new protocol and the socket
API would recognize the new protocol.  The device driver to layer 3
interface was a bit more crude (if I remember aright), but still
manageable.  And many vendors knew how to take BSD-compatible code and fit
it into their OS.


-- 
*****
Craig Partridge's email account for professional society activities and
mailing lists.