[ih] Quantifying OSI

[Bob Purvy]

> 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> 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> 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>
> > wrote:
> >
> >>
> >>
> >> 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.
> >>
> > --
> > Internet-history mailing list
> > 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
>
>