[ih] Quantifying OSI

[John Day]

Much of what is wrong, the mistakes that need to be rectified are any where from 55 to 35 years ago. Sounds like history to me.

We have found that resolving the mistakes makes things incredibly simpler and better than burying your head in the sand that has been recommended more than once here.

Some of the mistakes were subtle, therefore worth understanding, some just short-sighted design that could be fixed, some appear to oversight but I am not entirely sure, and some forgot they were designing for an internet, not a network.

So it is very much worth understanding. If it isn’t done, they are condemn to repeat the mistakes. (And have been working on it.)

> On May 11, 2026, at 16:52, Bob Purvy <bpurvy at gmail.com> wrote:
> 
> > You seem to be more interested in kicking a dead horse than facing the real problems.
> 
> I thought we were discussing what happened with OSI. What, now you don't want to talk about that?
> 
> There's plenty to discuss about what's wrong today. However, this group has "history" in its name. Maybe it isn't the right forum for your issues.
> 
> On Mon, May 11, 2026 at 1:41 PM John Day <jeanjour at comcast.net <mailto:jeanjour at comcast.net>> wrote:
>> You know that is really where the disconnect occurred.
>> At the time, (the 80s) there was no market for something like the Internet. US corporations were focused on where the market was, which was corporate networks. 
>> 
>> A market for something like the Internet was definitely coming as we all knew. It was probably accelerated by at least a decade if not more by the advent of the Web.
>> 
>> You want to play raise one games?  How about how much has the Internet caused its users by never being productized in terms of ransomware, phishing, web scams, cyberattacks, etc.
>> 
>> You seem to be more interested in kicking a dead horse than facing the real problems.
>> 
>> Take care,
>> John
>> 
>> > On May 11, 2026, at 16:23, Bob Purvy via Internet-history <internet-history at elists.isoc.org <mailto:internet-history at elists.isoc.org>> wrote:
>> > 
>> >> 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 <craig at tereschau.net <mailto:craig at tereschau.net>>
>> > wrote:
>> > 
>> >> 
>> >> 
>> >> On Mon, May 11, 2026 at 10:09 AM Bob Purvy via Internet-history <
>> >> internet-history at elists.isoc.org <mailto: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.
>> >> 
>> > -- 
>> > Internet-history mailing list
>> > Internet-history at elists.isoc.org <mailto:Internet-history at elists.isoc.org>
>> > https://elists.isoc.org/mailman/listinfo/internet-history
>> > -
>> > Unsubscribe: https://app.smartsheet.com/b/form/9b6ef0621638436ab0a9b23cb0668b0b?The%20list%20to%20be%20unsubscribed%20from=Internet-history
>>