BOX 4.1 Some Potentially Disruptive Ideas About Network Architecture and Design
Workshop participants discussed a number of architectural/design issues that could stimulate disruptive network designs. The items that follow, though not necessarily points of consensus among the authoring committee, were identified as interesting questions worthy of further consideration and perhaps useful directions for future networking research.
Where Should the Intelligence in the Network Reside?
The traditional Internet model pushes the intelligence to the edge, and calls for a simple data forwarding function in the core of the network. Does this continue to be the correct model? A number of ad hoc functions are appearing in the network, such as NAT boxes, firewalls, and content caches. There are devices that transform packets, and places where the network seems to operate as an overlay on itself (e.g., virtual private networks). Do these trends signal the need to rethink how function is located within the network? What aspects of modularity need to be emphasized in the design of functions: protocol layering, topological regions, or administrative regions? Is there a need for a more complex model for how applications should be assembled from components located in different parts of the network? There was a sense in discussions at the workshop that the Active Networks research may have explored some of these issues, but that the architectural questions remain unanswered.
Is the End-to-End Model the Right Conceptual Framework?
The end-to-end model implies that the center of the network is a transparent forwarding medium, and that the two ends have fully compatible functions that interwork with each other. From the perspective of most application developers and, in some sense, from the perspective of users, this model is not accurate. There is often a lot of practical complexity in a communication across the network, with caches, mirrors, intermediate servers, firewalls, and so on. From a user perspective, a better model of network communication might be a “limited horizon” model, in which the application or user can see the detail of what is happening locally but beyond that can interact with the network only at a very abstract level. Could such a view help clarify how the network actually works and how application designers should think about structure?
How Can Faults Be Better Isolated and Diagnosed?
When something breaks in the Internet, the Internet’s very decentralized structure makes it hard to figure out what went wrong and even harder to assign responsibility. Users seem to be expected to participate in fault isolation (many of them know how to run ping and trace-route but find it odd that they should be expected to do so). This perspective suggests that the Internet design might be deficient in that it does not pay proper attention to the way faults can be detected, isolated, and fixed, and that it puts this burden on the user rather than the network operator. The fact that this situation might arise from an instance of the end-to-end argument further suggests that the argument may be flawed.
Are Data a First-class Object Inside the Network?
The traditional model of the Internet is that it moves bytes between points of attachment but does not keep track of the identity of these bytes. From the perspective of the user, however, the namespace of data, with URLs as an example, is a part of the network. The users view the network as having a rather data-centric nature in practice, and they are surprised that the network community does not pay more attention to the naming, search, location, and management of data items. Should content-based addressing be a network research problem?
Does the Internet Have a Control Plane?
The original design of the Internet stresses the data-transport function but minimizes attention to management protocols, signaling, and control. A number of ad hoc mechanisms supply these functions, but they do not receive the research attention and architectural definition that the data movement functions do. This seems out of balance and may limit what can be achieved in the Internet today.
Abstractions of Topology and Performance
The Internet hides all details of topology and link-by-link measures of performance (for example, bandwidth, delay, congestion, and loss rates) beneath the IP layer. The simple assumption is that the application need not know about this, and if it does need such information, it can obtain it empirically (by trying to do something and observing the results). As more complicated applications such as content