As stated in "Interdomain Internet Routing" [1], wide-area routing today occurs between "...autonomous systems (ASes) that exchange reachability information." Using Border Gateway Protocol (BGP), they send this information through two prevalent AS-AS relationships--"transit" and "peering." Transit involves a "provider" that provides access to most, if not all, of the destinations in its routing tables to its "customers." Peering, on the other hand, involves ASes that provide access only to a subset of these destinations.
These two relationships suggest roles that ASes play--that of a provider and of a customer, as already described in the case of transit, and that of a peer in peering. A provider has to allow its customers access to whatever it needs access to, because, as also stated in the paper, they pay for this access. Peers, meanwhile, limit the access they provide as they do not want other peers to use their resources for free. BGP is able to handle these roles with eBGP for routers in different ASes and iBGP for routers in the same AS.
This author wonders whether this routing architecture counteracts the Internet design's goal of survivability.
If one considers it closely, the relationships mentioned above imply a somewhat hierarchical structure, with peering disrupting what might otherwise be a perfect star topology of ASes. Removing one "provider" AS from the star removes its "customers" as well, since customers are--and this is an assumption by this author--generally connected to only one provider at a time. An answer might be to connect a customer to multiple providers--but this means that the customer now has to pay two providers to ensure constant connectivity.
It is very interesting to see how strongly routing on the Internet today is influenced by commercial considerations.
Reference:
[1] Hari Balakrishnan and Nick Feamster, "Interdomain Internet Routing."
Thursday, July 2, 2009
Thursday, June 25, 2009
On Network Design and Town Planning
Reading "End-to-end Arguments in System Design" [1] and "The Design Philosophy of the DARPA Internet Protocols" [2] was quite an enlightening experience for this author.
"End-to-end..." argued that "...functions placed at low levels of a system may be redundant or of little value when compared with the cost of providing them at that low level." After reading the several examples cited, one tends to agree with the paper, especially when it goes on at length about "careful file transfer." Implementing important network functions at low levels add overhead that is easily avoided because of the availability of these functions at higher levels.
"The Design..." "...attempts to capture some of the early reasoning which shaped the Internet protocols," as it states early on, and capture this reasoning it does. One feels as though he is part of history as the paper explains how the Internet came to be designed the way it is; why the datagram, for reasons of survivability and "fate sharing," became a core feature of its architecture; and why TCP and IP, originally one protocol, were split and respectively assigned to handle reliable end-to-end transfer and routing.
These papers remind the author of the days when he used to draw city layouts using Paintbrush in Windows 3.1 (don't laugh; he was young and had a lot of free time). Imagining himself to be the town planner of some distant place devoid of civilization, he would place roads with the line tool, color city blocks with the bucket tool, and occasionally indicate places of interest with the rectangle tool, eventually ending up with his ideal city (at least for that day) from scratch.
Network protocol designers, this author thinks, may feel something similar to his experience with town planning. Given computer systems completely devoid of networking, protocol designers set out to identify the layers needed by the system, design the packets that will bring data to and from these layers, and eventually come up with their ideal design--or at least, ideal in how closely it achieves its goals.
However, just like how this author sometimes wishes to rebuild his cities because of flaws in his design, network protocols may need revising because of flaws in their design. As stated in "End-to-end...," reinforcing the lower layers of a system to attempt to achieve the design's goals may actually counteract it, with the overhead of low-level robustness getting in the way of high-level efficiency. He is a lucky man who gets to design an entire network from the lowest layers up to the end applications; most designers have to build their designs around existing protocols--and their existing flaws.
The designers of the Internet were very lucky men indeed.
During their time, the large networks that already existed were not interconnected with each other, which meant that they got to design their protocols from scratch. Their goals allowed them to design protocols that provided just enough robustness for applications to function well and not get bogged down by irrelevant network traffic. This "good enough" architecture is indeed good enough that it persists today, more than twenty years later.
Sometimes, this author wonders what these initial designers felt as they laid out the foundations of the Internet. Though his forays into town planning are over, work continues on the Internet today, as designers continue to create new protocols for new applications and revise old ones to support this new work. Designing "good enough" protocols does not take more than a few years, but once implemented, they last--forever.
Reference:
[1] J.H. Saltzer et al., "End-to-End Arguments in System Design," ACM Transactions in Computer Systems, vol. 2, no. 4, pp. 277-288, November 1984.
[2] David D. Clark, "The Design Philosophy of the DARPA Internet Protocols," ACM SIGCOMM Computer Communication Review, vol. 18, issue 4, August 1988.
"End-to-end..." argued that "...functions placed at low levels of a system may be redundant or of little value when compared with the cost of providing them at that low level." After reading the several examples cited, one tends to agree with the paper, especially when it goes on at length about "careful file transfer." Implementing important network functions at low levels add overhead that is easily avoided because of the availability of these functions at higher levels.
"The Design..." "...attempts to capture some of the early reasoning which shaped the Internet protocols," as it states early on, and capture this reasoning it does. One feels as though he is part of history as the paper explains how the Internet came to be designed the way it is; why the datagram, for reasons of survivability and "fate sharing," became a core feature of its architecture; and why TCP and IP, originally one protocol, were split and respectively assigned to handle reliable end-to-end transfer and routing.
These papers remind the author of the days when he used to draw city layouts using Paintbrush in Windows 3.1 (don't laugh; he was young and had a lot of free time). Imagining himself to be the town planner of some distant place devoid of civilization, he would place roads with the line tool, color city blocks with the bucket tool, and occasionally indicate places of interest with the rectangle tool, eventually ending up with his ideal city (at least for that day) from scratch.
Network protocol designers, this author thinks, may feel something similar to his experience with town planning. Given computer systems completely devoid of networking, protocol designers set out to identify the layers needed by the system, design the packets that will bring data to and from these layers, and eventually come up with their ideal design--or at least, ideal in how closely it achieves its goals.
However, just like how this author sometimes wishes to rebuild his cities because of flaws in his design, network protocols may need revising because of flaws in their design. As stated in "End-to-end...," reinforcing the lower layers of a system to attempt to achieve the design's goals may actually counteract it, with the overhead of low-level robustness getting in the way of high-level efficiency. He is a lucky man who gets to design an entire network from the lowest layers up to the end applications; most designers have to build their designs around existing protocols--and their existing flaws.
The designers of the Internet were very lucky men indeed.
During their time, the large networks that already existed were not interconnected with each other, which meant that they got to design their protocols from scratch. Their goals allowed them to design protocols that provided just enough robustness for applications to function well and not get bogged down by irrelevant network traffic. This "good enough" architecture is indeed good enough that it persists today, more than twenty years later.
Sometimes, this author wonders what these initial designers felt as they laid out the foundations of the Internet. Though his forays into town planning are over, work continues on the Internet today, as designers continue to create new protocols for new applications and revise old ones to support this new work. Designing "good enough" protocols does not take more than a few years, but once implemented, they last--forever.
Reference:
[1] J.H. Saltzer et al., "End-to-End Arguments in System Design," ACM Transactions in Computer Systems, vol. 2, no. 4, pp. 277-288, November 1984.
[2] David D. Clark, "The Design Philosophy of the DARPA Internet Protocols," ACM SIGCOMM Computer Communication Review, vol. 18, issue 4, August 1988.
Subscribe to:
Posts (Atom)