1.3 The Network Edge

In the previous sections we presented a high-level description of the Internet and networking protocols. We are now going to delve a bit more deeply into the components of the Internet. We begin in this section at the edge of network and look at the components with which we are most familiar -- the computers (e.g., PCs and workstations) that we use on a daily basis. In the next section we will move from the network edge to the network core and examine switching and routing in computer networks. Then in Section 1.5 we will discuss the actual physical links that carry the signals sent between the computers and the switches.

1.3.1 End Systems, Clients and Servers

In computer networking jargon, the computers that we use on a daily basis are often referred to as or hosts or end systems. They are referred to as "hosts" because they host (run) application-level programs such as a Web browser or server program, or an e-mail program.  They are also referred to as "end systems" because they sit at the "edge" of the Internet, as shown in Figure 1.3-1. Throughout this book we will use the terms hosts and end systems interchangeably, that is, host = end system.

Hosts are sometimes further divided into two categories: clients and servers. Informally, clients often tend to be desktop PC's or workstations, while servers are more powerful machines.  But there is a more precise meaning of a client and a server in computer networking.  In the so-called client-server model,  a client program running on one end system requests and receives information from a server running on another end system.  This client-server model  is undoubtedly the most prevalent structure for Internet applications. We will study the client-server model in detail in Chapter 2. The Web, e-mail, file transfer, remote login (e.g., Telnet), newgroups and many other popular applications adopt the client-server model. Since a client typically runs on one computer and the server runs on another computer, client-server  Internet applications are, by definition, distributed applications.  The client and the server interact with each other by communicating (i.e., sending each other messages) over the Internet.  At this level of abstraction, the routers, links and other "pieces" of the Internet serve as a "black box" that transfers messages between the distributed, communicating components of an Internet application.  This is the level of abstraction depicted in Figure 1.3-1.

End system interaction
Figure 1.3-1: End system Interaction

Computers (e.g., a PC or a workstation), operating as clients and servers, are the most prevalent type of end system.  However, an increasing number of alternative devices, such as so-called network computers and thin clients [Thinworld 1998], Web TV's and set top boxes [Mills 1998], digital cameras, and other devices are being attached to the Internet as end systems.  An interesting discussion of the continuing evolution of Internet applications is [AT&T 1998].

1.3.2 Connectionless and Connection-Oriented Services

We have seen that end systems exchange messages with each other according to an application-level protocol in order to accomplish some task.  The links, routers and other pieces of the Internet provide the means to transport these messages between the end system applications.  But what are the characteristics of this communication service that is provided? The Internet, and more generally TCP/IP networks, provide two types of services to its applications: connectionless service and connection-oriented service. A developer creating an  Internet application (e.g., an email application, a file transfer application, a Web application or an Internet phone application) must program the application to use one of these two services.  Here, we only briefly describe these two services; we shall discuss them in much more detail in Chapter 3, which covers transport layer protocols.

Connection-Oriented Service

When an application uses the connection-oriented service, the client and the server (residing in different end systems) send control packets to each other before sending packets with real data (such as e-mail messages). This so-called handshaking procedure alerts the client and server, allowing them to prepare  for an onslaught of packets. It is interesting to note that this initial hand-shaking procedure is similar to the protocol used in human interaction. The exchange of "hi's" we saw in Figure 1.2-1 is an example of a human "handshaking  protocol" (even though  handshaking is not literally taking place between the two people).  The two TCP messages that are exchanged as part of the WWW interaction shown in Figure 1.2-1 are two of the three messages exchanged when TCP sets up a connection between a sender and receiver.  The third TCP message (not shown) that forms the final part of the TCP three-way handshake (see Section 3.7) is contained in the get message shown in Figure 1.2-1.

Once the handshaking procedure is finished, a "connection" is said to be established between the two end systems. But the two end systems are connected in a very loose manner, hence the terminology "connection-oriented". In particular, only the end systems themselves are aware of this connection; the packet switches (i.e., routers) within the Internet are completely oblivious to the connection. This is because a TCP connection is nothing more than allocated resources (buffers) and state variables in the end systems. The packet switches do not maintain any connection state information.

The Internet's connection oriented service comes bundled with several other services, including reliable data transfer, flow control and congestion control. By reliable data transfer, we mean that an application can rely on the connection to deliver all of its data without error and in the proper order. Reliability in the Internet is achieved through the use of acknowledgments and retransmissions. To get a preliminary idea about how the Internet implements the reliable transport service, consider an application that has established a connection between end systems A and B. When end system B receives a packet from A, it sends  an acknowledgment; when end system A receives the acknowledgment, it knows that the corresponding packet has definitely been received.  When end system A doesn't receive an acknowledgment, it assumes that the packet it sent was not received by B; it therefore retransmits the packet.Flow control  makes sure that neither side of a connection overwhelms the other side by sending too many packets too fast. Indeed, the application at one one side of the connection may not be able to process information as quickly as it receives the information. Therefore, there is a risk of overwhelming either side of an application. The flow-control service forces the sending end system to reduce its rate whenever there is such a risk. We shall see in Chapter 3 that the Internet implements the flow control service by using sender and receiver buffers in the communicating end systems. The Internet's congestion control service helps prevent the Internet from entering a state of grid lock. When a router becomes congested, its buffers can overflow and packet loss can occur. In such circumstances, if every pair of communicating end systems continues to pump packets into the network as fast as they can, gridlock sets in and few packets are delivered to their destinations. The Internet avoids this problem by forcing end systems to diminish the rate at which they send packets into the network during periods of congestion. End systems are alerted to the existence of severe congestion when they stop receiving acknowledgments for the packets they have sent.

We emphasize here that although the Internet's connection-oriented service comes bundled with reliable data transfer, flow control and congestion control, these three features are by no means essential components of a connection-oriented service. A different type of computer network may provide a connection-oriented service to its applications without bundling in one or more of these features. Indeed, any protocol that performs handshaking between the communicating entities before transferring data is a connection-orieinted service [Iren].

The Internet's connection-oriented service has a name -- TCP (Transmission Control Protocol); the initial version of the TCP protocol is defined in the Internet Request for Comments RFC 793 [RFC 793]. The services that TCP provides to an application include reliable transport, flow control and congestion control.  It is important to note that an application need only care about the services that are  provided; it need not to worry about how TCP actually implements reliability, flow control, or congestion control.  We, of course, are very interested in how TCP implements these services and we shall cover these topics in detail in Chapter 3.

Connectionless Service

There is no handshaking with the Internet's connectionless service. When one side of an application wants to send packets to another side of an application, the sending application simply sends the packets.  Since there is no handshaking procedure prior to the transmission of the packets, data can be delivered faster. But there are no acknowledgments either, so a source never knows for sure which packets arrive at the destination. Moreover, the service makes no provision for flow control or congestion control. The Internet's connectionless service is provided by UDP (User Datagram Protocol);  UDP is defined in the Internet Request for Comments RFC 768 [RFC 768].

Most of the more familiar Internet applications use TCP, the Internet's connection-oriented service. These applications include Telnet (remote login), SMTP (for electronic mail), FTP (for file transfer), and HTTP (for the Web). Nevertheless, UDP, the Internet's connectionless service, is used by many applications, including many of the emerging multimedia applications, such as Internet phone, audio-on-demand, and video conferencing.


[AT&T 1998] "Killer Apps," AT&T WWW page http://www.att.com/attlabs/brainspin/networks/killerapps.html
[Iren] S.Iren, P.Amer, P.Conrad, "The Transport Layer: Tutorial and Survey," ACM Computing  Surveys, June 1999
[Thinworld 1998]   Thinworld homepage, http://www.thinworld.com/
[Mills 1998] S. Mills, "TV set-tops set to take off ", CNET News.com, Oct. 1998
[RFC 768] J. Postel, " Datagram Protocol," RFC 768, Aug. 1980.
[RFC 793] J. Postel, "Transmission Control Protocol," RFC 793, September 1981.

Return to Table of Contents

Copyright Keith W. Ross and Jim Kurose 1996-2000