In 1990, while working under the tutelage of the legendary Arlington Hewes at The Phone Company (tpc.int),[2] we posited the need for Yet Another Protocol (YAP). At the time, a variety of application protocols were under active development, the web had not yet been fully born, and the TCP protocol had not yet been revised to make the port number a constant.

      We immediately began work on the protocol, naming it Blocks. We then deferred any future specification of the details for 10 years in order to properly ponder the problem.

      The guiding metaphor of the Blocks protocol was the map. The pain that produced the metaphor was network topology.

      In those days, the Cisco router was not the marvel of plug-and-play interoperability that we know today. There were times when, through inattentive reading of the step-by-step documentation, we screwed up the routes and rendered our networks inoperable.

      An old network management trick, when you screw up your network cloud, is to telnet into the closest router using the IP address (the DNS name being somewhat useless if you can't see your DNS server). Once on that first router, you telnet to the next one until, after crawling over a series of data links, you reach the offending misconfigured router, chant a few incantations, and repair the net.

      A map of the network topology seemed an obvious tool in assisting such misguided operations (we leave aside the obvious issue of the server that has your map being in the unreachable part of your network). Indeed, maps of other people's networks might even be a useful tool for identifying services available to the outside world, say an ftp, whois, or finger server. Thus was born the idea of a protocol that would assist in mapping the Internet, sharing those maps, and giving people the ability to step above the net and look around.

      Many people regarded the SNMP protocol suite[3] as the mechanism that would allow these maps to be built by network management software. In retrospect, SNMP had a much more precise function. Rather than being the magic bullet that reached the holy grail of visualizing network topology on the fly, SNMP ended up being a means of instrumenting network devices, allowing data such as the number of packets dropped on a router or the average power consumption of a UPS to be made available to a network management agent.

      The extensible nature of SNMP, through the use of MIBs, made it a valuable model for protocol development. The core protocol was fixed and simple, yet the MIB effort allowed anyone and everyone to draft a method of instrumenting devices from toasters to satellites. If a monkey wanted to draft a banana tree MIB, the SNMP protocol mechanism allowed the monkey to do so, and it was up to the user base and the market to decide if that MIB came into broad use. However, the requirements of the banana MIB did not impact the core protocol or even the development of other MIBs.

      Unfortunately, SNMP did not solve the problem of divining network topology. It was obviously a valuable source of data, but any information gleaned from skulking SNMP-accessible devices would have to be combined with data from a wide variety of other resources such as the routing tables. We thus moved from the issue of visualizing the network to that of a flexible mechanism for resource discovery.

      The rich visual map of a network built from a large number of resource discovery mechanisms was certainly a tool for the professional network manager, but we actually envisioned that this mechanism would prove useful to end users who would want to see network topology as a means towards better navigation.

      We had a scenario why end users would care about network topology, a notion that was considered somewhat heretical by the "Internet hides all topology and transparently connects end nodes" oral tradition that serves as the Internet architecture. This school of thought felt that networks should always be transparent and that even things like domain names would be hidden from the user.

      Our scenario on why the end user should care ran something like this. Let's say you engaged in an MBONE video session with a user named Deering at Xerox Parc. In 1990 and 1991, multicast was just beginning the hypergrowth that has led to our modern MBONE, and session directory protocols like SDP[4] did not exist. If the face at the other end of the video screen says something interesting in a video conference, your first inclination would be to look around the subnetwork that is the source of the video. Is there perhaps an FTP, mail, or finger server on that subnet? Is there a little FTP server on the same machine as the video? Most likely a personal archive of documents. Perhaps a "big" server on the same subnet (as evidenced by the number of documents, size of machine, or kind of link)? Perhaps the departmental server!

      We thus saw maps of networks as a service location and navigation tool. And, if the resource discovery and map construction could be based on a well-defined protocol, perhaps the effort of mapping the entire Internet could be accomplished as a highly-distributed enterprise. Indeed, such a protocol would allow one group to map a network and then share that map with other people. The key to these maps was the distributed collection of data, the ability to add to and personalize the data collected, and the ability to construct and share different views or interpretations of the underlying topology.

      Maps are a metaphor, and one can argue that maps of network topologies are the wrong metaphor to be pursuing. After all, on the Internet, one can build virtual worlds. Maps of topology had no interest to many people, but building virtual worlds attracted a huge following to efforts such as VRML.

      Our feeling was that if you were going to build virtual worlds, you shouldn't start from scratch. You should start with the real world (and to us the mass of data and servers that is the Internet is the real world) and use that as a bootstrap mechanism, the raw materials that people would use to build virtual worlds.

      Network topology as a useful tool to the end user and as the raw material of an effort to construct virtual worlds became the elevator pitch. Map became the metaphor.

Next » Space as Better Metaphor