911������

Transcript

What makes the Internet work? Most people have a vague sense, if that, of what goes on behind the curtain—bits and bytes whooshing around, somewhere, like in an IBM commercial, or TRON. The reality isn’t all that complicated, an example of elegant simplicity and minimalism, crafted and honed by pioneering and forward thinking technical experts.

Like a lot of infrastructure, its workings are largely hidden beneath the surface and thus easily taken for granted. The plumbing works, the lights go on, and I can download a cat video, so I’m good.

The foundation for all that, what makes it possible, has its roots in a 30-year-old document that specifies a lightweight but powerful regime that laid the seeds for a radical transformation of many aspects of contemporary life.

Many news stories got written about the 40th anniversary of the Internet and the 20th anniversary of the World Wide Web, but somehow the 30th anniversary of this got missed. I can tell you why—it’s very technical and makes pretty turgid reading. Much of its 45 pages is the equivalent of typewriter art diagrams specifying how the guts of the Internet work. True, in October of 1969 the first message of sorts went from one computer to another via a network, and yes, there are other milestones and standards you could point to as important, but TCP/IP gives it structure and makes it work, and it started here.

TCP/IP stands for the Transfer Control Protocol/Internet Protocol, and its roots go back to those early days and the search for a way to link computers to share data. Initially that was intended for things like moving files around and logging in to computers remotely to make using them more efficient, back when computing power and time were precious commodities.

Under these protocols, the “Internet” is a network, connecting networks, and it does very little, except pass stuff around, unchanged and unexamined. That’s the genius of this, that the

Internet does about as little as possible, and there’s no specific hardware or software required to be a part of it. This simplicity makes it easy to implement, subscribe to and maintain, which is part of its incredible success.

What is does is called packet switching. When any file or message is sent across the Internet, it’s divided up into lots of smaller chunks or packets, each of which can take separate paths to the destination, where they’re reassembled. Each of those chunks takes the most efficient path at that instant, which means it could go anywhere in the network. That improves performance and speed. It doesn’t matter what the sender or receiver are, where they are, or who they are. So long as they both subscribe to the TCP/IP protocols, the message will go through and everybody’s happy.

Once you have this base layer of networking where stuff moves around, lots of much more interesting things can use it, taking that all for granted. Things like email, for example, or timekeeping, or the maintenance of the domain name service that lets everything be found. Oh yeah, and the Web; it’s one of a bunch of applications that ride on top of TCP/IP like a Honda on an interstate without the faintest notion what goes into keeping the road working. That’s why a full Web address includes that “http://” business; there are over a dozen more of those that work atop TCP/IP.

The document itself is one of a long series of several thousand RFCs, requests for comment, which tells us something about the people involved: collaborative, open, often operating by consensus, coming to a shared understanding and agreement. There is a formal approval process, described in something called the Tao of IETF, which also helpfully lays out the preferred meeting dress code of t shirts and sandals. It’s both charming and a little icky that Jon Postel, the long time editor, had his obituary sent out as RFC 2468.

A great deal of networking effort in those days was government/Defense Department stuff; the Defense Advanced Research Projects Agency approved this as the military network standard in 1982 which really gets things rolling. However, the migration to this standard wasn’t seamless or easy; in fact, a couple of tart emails from Jon Postel point to this; to nudge network administrators along, the powers that be the turned off previous protocol for a few days, and even then it took 3 months for everybody to get on board when the switchover finally happened (Sound familiar? Y2K, DTV?)

This Internet thing seems likely to be around for a while, and has affected most parts of daily life, as I said, so let me focus on one you might not have thought about: disintermediation. Remember Napster? Copyright infringement notwithstanding, it’s a great example of a peer to peer system; anybody could download music files from anybody on the network. Handy, and you don’t need a recording company or record store to make that work. Which is great, unless you’re a recording company or record store. Substitute “movie” or “book” or any other format in there and you see what happens. In a peer to peer world, like the Internet, what’s the middle for? For that matter, what’s the middle?

And yet. The world is tough for booksellers and record stores but Amazon and iTunes are thriving. So are the App Store, Google Play, Netflix, Kayak, Angie’s List, and a range of other intermediaries and advice-givers ready and willing to help out in the networked age, so it seems that even if you cut out the middleman, that middle keeps re-emerging. One more curiosity about the RFC document itself; it betrays the technology of its time in its formatting. They’re laid out in pages, trying to replicate the look and feel of the typed pages of the early days, spaced out with blank lines between page numbers. It seems strange, even retrograde, to 21st century eyes, used to PDF documents or Web pages that don’t rely on, well, pages. Meanwhile, the technology it laid out has liberated information of all types from its containers, potentially forever.

References:

IETF Trust. (n.d.). The Tao of IETF: A Novice’s Guide to the Internet Engineering Task Force. Retrieved August 7, 2012, from http://www.ietf.org/tao.html#anchor36

Internet protocol suite - Wikipedia, the free encyclopedia. (n.d.). Retrieved August 7, 2012, from http://en.wikipedia.org/wiki/Internet_protocol_suite

Jon Postel. (1981). RFC 791. Retrieved August 7, 2012, from http://datatracker.ietf.org/doc/rfc791/

Mike Oliver. (n.d.). ITPRC - TCP/IP FAQ. Retrieved August 7, 2012, from http://www.itprc.com/tcpipfaq/

TCP/IP Internet Protocol. (n.d.).Living Internet. Retrieved August 7, 2012, from http://www.livinginternet.com/i/ii_tcpip.htm