NETWORK ARCHITECTURES AND DESIGN PRINCIPLES

14.3.1 Network Architecture

As explained above, the architecture of a system describes the components of the system, what they do, and how they interact.²¹ In networking, the architecture of a network describes the components of the network, what they do, and how they interact.

14.3.2 Components of Computer Networks: End Hosts and Computers in the Core of the Network

At the highest level of a network architecture, designers distinguish two classes of components:²² end hosts and computers in the core of the network. While end hosts are computers that use the network, computers in the core of the network form the network.

End hosts support users and run application programs; they use the services of the network to communicate with one another. The home computers many people use to surf the Internet, smartphones such as the iPhone that allow users to use the Internet wherever they are, the web servers that carry the content provided by Yahoo! or The New York Times, or the servers through which users access their Gmail accounts are all examples of end hosts.

Computers in the core of the network form or implement the network.²³-²⁴ They estab­lish connectivity among the computers attached to the network. They include the cable modem termination system operated by a cable provider (to which a subscriber’s cable modem is connected to give them access to the Internet) and the routers that network providers use to forward Internet data from one physical network to another. Viewed from computers in the core of the network, end hosts are the sources and destinations of data.

Thus, the terms ‘end hosts’ and ‘core of the network’ denote a purely functional dis­tinction between users and providers of communication services.²⁵ They do not refer to topological relationships or to administrative ownership and control.

14.3.3 Design Principles: Layering and the End-to-end Arguments

The original architecture of the Internet that governed the Internet from its inception to the early 1990s was based on three design principles: the layering principle,²⁶ the broad version of the end-to-end arguments, and the narrow version of the end-to-end arguments.

14.3.3.1 The layering principle

In networks designed according to the layering principle, each computer, whether it is an end host or a computer in the core of the network, is further subdivided into archi­tectural components called layers.²⁷ Layers are thought of as being arranged in a vertical structure (Figure 14.1). Each layer has one or more architectural subcomponents called protocols.

Each protocol provides a well-defined set of services to the layer above, using the services of the layer below. To implement the services provided by the protocol, different instances of the same protocol located on different computers (protocol peers) cooper­ate by exchanging messages with one another. For example, web browsers like Firefox or

Figure 14.1 Architectural components of computer networks

Internet Explorer use the Hypertext Transfer Protocol (HTTP) to ask web servers such as the web server of The New York Times for a specific web page; the web server then uses the same protocol to send the desired web page back to the browser, which in turn displays it to the user.²⁸ While lower layers are implemented on end hosts and computers in the core of the network, higher layers only have to be implemented on end hosts.²⁹

As in any layered approach to design, a protocol that is assigned to a layer can use any of the other protocols in the same layer or in a lower one, but it cannot use a protocol in a higher layer.³⁰ As a result, protocols in lower layers are independent from protocols in higher layers.

In addition, the interaction between protocols is restricted by two additional con­straints on the architecture that are specific to layering in the networking context. First, a protocol at a specific layer at a receiver must receive exactly the same object as sent by its protocol peer at the source.³² This allows protocol designers to design protocols as if pro­tocol peers (i.e., the instances of a specific protocol located on different computers) com­municated directly. Designers do not have to worry about how the messages exchanged by protocol peers actually get from one protocol peer to the other, which greatly reduces the complexity of designing a protocol.

Second, a lower-layer protocol is not allowed to make any assumptions about the content or the meaning of the message (or, more technically, protocol data unit) passed to it by a higher-layer protocol for delivery to its higher-layer protocol peer.³³ The lower- layer protocol may neither access nor act on the information contained in a higher-layer protocol data unit. This constraint preserves the central feature of layering - the inde­pendence of higher layers from lower layers. Together with the broad version of the end- to-end arguments, it also results in a network that is application-blind, that is, unable to distinguish among the applications on the network.³⁴

14.3.2.1 The broad version of the end-to-end arguments

The end-to-end arguments are design principles that help network architects decide how to allocate functions to the different layers of a network. The layering principle advises that the network’s functionality should be organized in layers and imposes certain con­straints on allowable interactions between layers. These constraints, however, do not necessarily determine in which layer specific functions should be placed. Thus, when designing a layered network, network architects still need to decide how exactly to divide the network’s functionality among layers, and the end-to-end arguments help with these decisions.³⁵

There are two versions of the end-to-end arguments that both shaped the original architecture of the Internet: the narrow version was first identified, named and described in a seminal paper by Saltzer et al. in 1981.³⁶ The broad version was the focus of later papers by the authors.³⁷ Although Saltzer et al.

While both versions shaped the Internet’s original architecture, only the broad version affects the economic environment for innovation. Therefore, this chapter focuses on the broad version.⁴⁰ According to the broad version, ‘specific application-level functions usually cannot, and preferably should not, be built into the lower levels of the system - the core of the network’.⁴¹ Instead, ‘a function or service should be carried out within a network layer only if it is needed by all clients of that layer, and it can be completely implemented in that layer’.⁴² Lower layers of the system, the core of the network, should provide only general services that are of broad utility across applications in order to support as many higher-layer applications as possible. The network should not be opti­mized to better support specific higher-layer applications. All application-specific func­tionality should be concentrated in the higher layers of the system, at the end hosts.⁴³ The broad version does not prevent functions from being implemented in the network if they cannot be completely and correctly implemented at the end hosts only.⁴⁴

Implementing application-specific functionality (i.e., functionality that is only needed by some applications) in lower layers of the network or optimizing the network for spe­cific applications will usually improve the performance of these applications. The lower layers of the network, however, are used by all applications; functionality implemented at these layers therefore also affects current and future applications that do not need the application-specific functionality or have needs that differ from the needs of the applica­tions for which the network was optimized.

Thus, the broad version prevents network architects from optimizing the network for specific applications in order to create a network that can support a larger, more diverse set of applications now and in the future.⁴⁵ The resulting reduction in the performance or efficiency of certain applications is the price for a system whose applications can evolve over time. In addition, the broad version supports application autonomy and is likely to increase the reliability of applications and the network.⁴⁶

The broad version thus represents a trade-off between long-term system evolvability, application autonomy, and reliability on the one hand, over certain types of performance optimizations on the other.⁴⁷ Network architects should use the broad version only if the system’s requirements imply that this trade-off is justified. If the system’s requirements imply a different resolution of this trade-off, the broad version of the end-to-end argu­ments should not be applied.

The trade-off underlying the broad version is familiar from other areas. Consider a gaming console and a personal computer. A gaming console has been optimized for gaming applications, but as a result of this optimization, its ability to support other applications is limited. For example, the joysticks and buttons of gaming controllers have been developed to meet the needs of gamers; they are not well suited to entering large amounts of text. By contrast, a personal computer is a general purpose system that has been designed to support a wide variety of applications with different needs. It has not been optimized for specific applications. While games may run more efficiently or may perform better on a gaming console, a personal computer can support more and more diverse applications, including those that have not been foreseen at the time of design.

Applying the layering principle and the broad version of the end-to-end argu­ments results in a network that is application-blind.⁴⁸ An application-blind network is unable to distinguish among the different applications running over it and, as a result, it is unable to make distinctions among data packets based on that informa­tion. This feature is often attributed to the layering principle or to the broad version of the end-to-end arguments directly; however, neither of these design principles deals explicitly with this question. Instead, the network’s inability to distinguish among applications is a direct consequence of these design principles. In a network based on the broad version of the end-to-end arguments, all application-specific functionality is concentrated in and restricted to higher layers at the end hosts. As a result, only the messages sent by higher-layer protocols at the end hosts carry application-specific functionality or content. In such a network, lower layers in the core of the network can identify the applications on the network only by accessing or making assump­tions about the messages of the higher-layer protocols carrying this information. This, however, would violate the second constraint of the layering principle, as applied to networking, which prescribes that a lower-layer protocol may not make any assump­tions about the content or meaning of the message it is transporting on behalf of higher-layer protocols and may neither access nor act on the information contained in these messages.⁴⁹

14.4