Interesting People mailing list archives

IP: 10 choices that were critical to the Net's success


From: Dave Farber <dave () farber net>
Date: Fri, 13 Sep 2002 05:02:35 -0400



 


------------------------------------------------------------------------Post
ed on Sun, Sep. 08, 2002

10 choices that were critical to the Net's success
By Dan Gillmor
Mercury News Technology Columnist

In our modern, corporate culture, the rise of the Internet is a happy
accident. In its roots and growth, says Scott Bradner, the Net never had a
business model.

How did technologists, government officials and a host of other early
players turn something with no obvious business model into a system that has
become so intrinsic to the new century? A series of decisions proved
critical -- choices that helped turn data transport into a commodity
business and put the power in users' hands, not in the centralized
telecommunications companies' controlling grasp.

At a telecom conference in Massachusetts last week, Bradner, senior
technical consultant at Harvard University and a longtime leader in the
formation of Internet standards, listed 10 crucial decisions along the way.
(You may have other candidates; send them to me and I'll list them on my Web
page). Here are Bradner's picks:

1) Make it all work on top of existing networks. Designers deliberately
didn't try to build a single, new über-data network -- it was about
``networks, not a network,'' Bradner observes. This meant supporting
multiple network types by putting a simple set of rules, now called the
Internet protocols, on top. This added layer was wide open for innovation,
not controlled by a few players.

2) Use packets, not circuits. Telephone networks open a circuit from one
phone to another, keeping the connection open until the call is ended. The
Internet splits messages into little packages called packets, which are sent
to their destination by various routes and at various times. This was a
radical idea at the time, but it has been one of the qualities that makes
the Internet so basically reliable and resilient under stress.

3) Create a ``routing'' function. Stand-alone boxes along the way from point
to point make instant decisions on what route to send each packet by,
reacting to failures in the networks. Again, this was a decentralizing
function that enhanced reliability.

4) Split the Transmission Control Protocol (TCP) and Internet Protocol (IP),
which are generally used together in much of what we do on the Net and are
called TCP/IP. Originally they were meant to be tied together in a single
service designed to guarantee that the stream of data would get to its
destination complete and in perfect order. To do this, however, would have
given network services far less flexibility. IP by itself offers an
unreliable but still enormously valuable service, simply sending the packets
through the network without checking to see if they all get there.

TCP makes sure, among other things, that they actually do get there. So an
application can use TCP if it cares most about reliability, while another
application can use IP (and other protocols) if it's more concerned with
timeliness -- such as an Internet phone call -- where losing a few packets
matters much less than getting most of the data there on time.

5) The National Science Foundation (NSF) funds the University of
California-Berkeley, to put TCP/IP into the Unix operating system originally
developed by AT&T. Berkeley thereby created a full but low-cost network
operating system, along with a full suite of network applications, that
computer start-up companies flocked to use in their boxes. It was, says
Bradner, ``a way to get into the networking game without spending a lot of
money.'' So it spread fast.

6) CSNET, an early network used by universities, connects with the ARPANET,
the Internet precursor network operated by the Pentagon's Advanced Research
Projects Agency. ARPA funded much of the early technical work on what later
became the Net. ARPANET use had been restricted solely to government-funded
individuals. The connection was for e-mail only, but it led to much more
university research on networks and a more general understanding among
students, faculty and staff of the value of internetworking. When students
graduated, they sought employers that had the technology.

7) The NSF requires users of the NSFNET to use TCP/IP, not competing
protocols. This decision about the NSFNET, which was originally created to
connect supercomputer centers, forced wider availability of the TCP/IP
protocol, and helped prevent a wasteful ``proliferation of miscellaneous
transport protocols for the Internet,'' Bradner says.

8) International telecommunications standards bodies reject TCP/IP, then
create a separate standard called OSI. TCP/IP, remember, was designed as a
low layer on top of which other applications, such as e-mail, would be
created. OSI was carrier-centric, a suite of protocols that included things
like e-mail. Had TCP/IP been accepted and then co-opted by the international
groups and telecom companies, things we now take for granted might not have
appeared, or might have been under central control. One the fundamentals of
the Net is we can create new protocols on top of IP, as Tim Berners-Lee did
to create the World Wide Web, says Bradner -- ``and we don't have to have
permission of the carriers to do that.

9) The NSF creates an ``Acceptable Use Policy'' restricting NSFNET use to
noncommercial activities. Although this rule grew blurry, it was largely
heeded despite fierce criticism. The result was an incentive to create
commercial network providers. The commercial providers created a huge
business of long-haul ``backbone'' and local carriers upon which the
Internet relies today.

10) Once things start to build, government stays mostly out of the way. If
the Internet suffered from a lack of regulation, Bradner says, it was ``a
good suffering'' for all of us.
------------------------------------------------------------------------
Next week: New decisions, new threats to communications. Dan Gillmor's
column appears each Sunday, Wednesday and Saturday. Visit Dan's online
column, eJournal (www.dangillmor.com). E-mail dgillmor () sjmercury com; phone
(408) 920-5016; fax (408) 920-5917.

For archives see:
http://www.interesting-people.org/archives/interesting-people/


Current thread: