HN Books @HNBooksMonth

Inventing the Internet (https://mitpress.mit.edu/books/inventing-internet) is a fantastic place to start

Innovations in Internetworking (https://www.amazon.com/Innovations-Internetworking-Artech-Te...) is a great collection of papers that help you understand the original thinking behind each protocol

The Elements of Networking Style (https://www.amazon.com/Elements-Networking-Style-Animadversi...) explains why you see only 4 layers in the real Internet while ISO slices it into 7 and all the fun parts os standard bodies while retaining a unique sense of satire

This account is also good, it's fairly technical and very funny: http://www.amazon.com/Elements-Networking-Style-Animadversio...

Eh. The fact that you had to spend around $1,000 to buy the set of manuals required, back when that was perhaps $2,000 in today's dollars, was probably a bigger factor than the article makes it out to be. Standards organizations like ISO and ANSI, at least back then, made their money selling manuals, which just doesn't work for something so ubiquitous in the number of people who have to know details.

Another problem that I read about at the time is that some of the ISO protocols didn't work. The "ISORMites" (http://www.amazon.com/Elements-Networking-Style-Animadversio...) were reported to be contemptuous of the Internet protocols, their origin from the "US Department of Death", etc. ... and didn't have a policy like the IETF's "running code wins" approach.

More generally, per http://www.ietf.org/tao.html "One of the 'founding beliefs' is embodied in an early quote about the IETF from David Clark: 'We reject kings, presidents and voting. We believe in rough consensus and running code'"

Not too impressed with this account, which I will admit starting to skim around halfway. E.g.:

I'm not sure the author realizes TCP is a virtual circuit protocol (then again I'm sure OSI had one or more much heavier weight ones).

The real fatal flaw of OSI, before even getting to the point of finding out if their protocols worked---many of them did get far enough in standardization process---was their going to ISO in the first place. If you just needed to get things done, the difference between spending around $2,000 ($1,000 in 1988 dollars) to buy a shelf of the standards documents, or $0 or thereabouts to get all the RFCs (chicken and egg, you might need to buy a CD or a tape to get them to your systems), made a very big difference.

If you're really interested in all this, I highly recommend Padlipsky's very opinionated "The Elements of Networking Style: And Other Essays & Animadversions on the Art of Intercomputer Networking" (http://www.amazon.com/Elements-Networking-Style-Animadversio...), a very colorful work with rhetorical gems like "gilding the ragweed".

⬐ shenberg

TCP really isn't a virtual circuit protocol in the same sense that X.25 PLP is a virtual circuit protocol: In VC protocols you say something like "network, I want to talk to address X," establish a channel (getting a channel ID allocated) and from then on send packets to the channel (not mentioning the remote address again), knowing that they'll arrive there. This means the routers on the way are stateful. TCP theoretically doesn't care about routing, and IP is stateless.

⬐ mturmon

"not sure the author realizes TCP is a virtual circuit protocol"

That struck me too -- kind of undermining the simple narrative of "connection-full telecom biggies vs. connection-less insurgents". It would have been worth a note in the article, because it's in IEEE Spectrum after all.

Not a networking pro, but I believe the converse is also true, that OSI has specifically connection-less protocol elements (e.g., CLNS) that are at a lower level in its own hierarchy, and more equivalent to IP in TCP/IP.

I just saw part of an interview with Cerf (http://www.internet-history.info/media-library/mediaitem/100...), in which he said that part of the motivation for packet switching is to maintain command and control in the chaos of a post-nuclear-strike world. That explains why the person connected with packet switching (Paul Baran) was at RAND, which was not a networking place, but very much a "let's plan for the apocalypse" place.

⬐ derleth

Actually, it seems ARPANET was not designed to survive nuclear war:

http://www.internetsociety.org/internet/what-internet/histor...

> It was from the RAND study that the false rumor started claiming that the ARPANET was somehow related to building a network resistant to nuclear war. This was never true of the ARPANET, only the unrelated RAND study on secure voice considered nuclear war. However, the later work on Internetting did emphasize robustness and survivability, including the capability to withstand losses of large portions of the underlying networks.

Charles Herzfeld, ARPA Director (1965–1967), said:

http://inventors.about.com/library/inventors/bl_Charles_Herz...

> The ARPANET was not started to create a Command and Control System that would survive a nuclear attack, as many now claim. To build such a system was, clearly, a major military need, but it was not ARPA's mission to do this; in fact, we would have been severely criticized had we tried. Rather, the ARPANET came out of our frustration that there were only a limited number of large, powerful research computers in the country, and that many research investigators, who should have access to them, were geographically separated from them.

Paul Baran:

http://www.wired.com/wired/archive/9.03/baran.html

> Wired: The myth of the Arpanet - which still persists - is that it was developed to withstand nuclear strikes. That's wrong, isn't it?

> Paul Baran: Yes. Bob Taylor had a couple of computer terminals speaking to different machines, and his idea was to have some way of having a terminal speak to any of them and have a network. That's really the origin of the ARPANET. The method used to connect things together was an open issue for a time.

⬐ mturmon

Cerf does say that part of the reasoning behind packet switching was robust command and control in the event of nuclear war. Cerf doesn't say that ARPANET, in itself, was designed for that (and neither did I).

This is also consistent with the following quote in the Baran interview you cite:

  Baran: But the origin of packet switching itself is very much Cold War.
  The argument was: To have a credible defense, you had to be able to 
  withstand an attack and at least be able to show you had the capability 
  to return the favor in kind.

So there is no disagreement on that point, and your corrective "Actually, ..." is misplaced.

⬐ hga

Well, there was a big controversy over basing your protocols on datagrams with stateless nodes in the middle. The CCITT's X.25 didn't.

When I was working for Lisp Machines Inc. (LMI) in 1982-3, when TCP/IP was being mandated for the Arpanet (and therefore Lisp Machines, sometime I worked on at LMI), I can remember the father of the Lisp Machine, Richard Greenblatt, arguing that it wouldn't work because too many packets would get lost in the middle. With stateless nodes---a necessary virtue for the small memory minicomputers the Arpanet was built on---re-transmission has to come from the endpoints, and if the error rate was too high it would have failed to be practical. Look at TCP over ATM for a modern example of this sort of lossage.

I assume Vint Cerf et. al. did the math based on observed error rates, then tested it to make sure (TCP/IP and NCP ran side by side for some time on the Arpanet) and Greenblatt, who was rather distracted designing his 3rd generation Lisp Machine, was going by general principles.

⬐ alan

> I'm not sure the author realizes TCP is a virtual circuit protocol (then again I'm sure OSI had one or more much heavier weight ones).

You've missed that they're referring to level 2 and 3 virtual circuits, IE "data is always delivered along the same network path, i.e. through the same nodes" ( https://en.wikipedia.org/wiki/Virtual_circuits#Layer_2.2F3_v... )

⬐ mcguire

I was hoping someone (else) would mention Padlipsky.

In my dissertation, Elements of Networking Style is the reference for the OSI section (which was needed because everybody is still using the damn terminology).

⬐ mjn

> spending around $2,000 ($1,000 in 1988 dollars) to buy a shelf of the standards documents

The ISLISP standardization group did an interesting workaround for this: http://www.islisp.info/history.html

An ISO committee to standardize the language was constituted but stalled on doing any real work drafting a standard. While they waited around, the community drew up a draft standard, which was published as a public recommendation to the ISO committee, with the draft put into the public domain. The committee then voted to adopt the community's draft as the standard unchanged. So now an official ISO document is available for the usual fee, but you can get a predecessor document that looks surprisingly similar, for free as a PDF.

Of course, this requires everyone on the committee agreeing to not really take the ISO process seriously. You might wonder why one would bother with it at all then, and in this case it seems to have been to reassure clients that ISLISP is stable by getting it an ISO standard.

⬐ aidenn0

Common Lisp also has an interesting history with regard to copyright, which resulted in the HyperSpec. I can't find the history here, but someone (KMP maybe?) wrote about the discussion when it came time to transfer the copyright to ISO.

⬐ hga

Reminds me of how I always used drafts of the ANSI SCSI standard, or vendor documents.

"in this case it seems to have been to reassure clients that ISLISP is stable by getting it an ISO standard"

Which is a nice hat trick if nobody uses the actual standards document ... although I suppose Franz and perhaps a few others did buy a copy....