Re: Quantifying OSI

The bell rang, John. You can't un-ring it.

I'm not going to answer you anymore.

On Mon, May 11, 2026 at 5:32 PM John Day <[email protected]> wrote:

> 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 <[email protected]> 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 <[email protected]> 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 <
>> [email protected]> 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 <[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
>>
>>
>
-- 
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