Re: Fwd: Fw: Quantifying OSI

> hours spent running the network

OK, I'll see that, and raise you one:

"hours spent running the network and feeding that experience back into the
code."

that's what OSI was lacking. It wasn't "elegant design."


On Mon, May 11, 2026 at 11:33 AM Craig Partridge <[email protected]>
wrote:

>
>
> On Mon, May 11, 2026 at 10:09 AM Bob Purvy via Internet-history <
> [email protected]> 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.
>
-- 
Internet-history mailing list
[email protected]
https://elists.isoc.org/mailman/listinfo/internet-history
-
Unsubscribe: https://app.smartsheet.com/b/form/9b6ef0621638436ab0a9b23cb0668b0b?The%20list%20to%20be%20unsubscribed%20from=Internet-history