This chapter introduces concepts related to computer networks to the reader and explains how these concepts relate to video-streaming. The computer network is the underlying infrastructure for a real-time media streaming system. To fully understand the "problems" faced by video-streaming, one must first realize that it is the design and layout of the network that will affect its performance.
The merging of computers and communications has had a profound effect on the way computer systems are designed today. Instead of designating a single computer to serve every computational need for an organization, a large number of separate but interconnected computers are now being used to distribute all the individual jobs. These interconnected computers are collectively known today as computer networks. The design and organization of these networks will be the topic of discussion in this chapter.
The term "computer networks" within
the context of this thesis refers to an interconnected
collection of autonomous computer systems. Two computers
are interconnected if they are capable of exchanging information
through copper wire, fiber optics, satellites, or microwaves.
By autonomous, we mean that each computer is independent of other.
If any computer can forcibly start, stop, or control another
computer, then these computers are not autonomous.
Networks can exist anywhere in the world. They may even run on different hardware and software. People who are connected to one of these networks often want to communicate with others who are on another network. Hence, there is a need to organize these different (and sometimes incompatible) networks into a collection of interconnected networks, called internetworks or just internet.
The Internet (note the uppercase I) that we know today is a specific worldwide internet, widely used to connect universities, government offices, companies and private individuals.
The design of the first computer networks, was more concerned with the hardware than the software. As technology progressed however, network software eventually became more structured. Moreover, the notion of a hierarchy of protocols became important for a computer network.
Most networks today are organized as a series of stacked layers, with each layer stacked over another layer below it. This is done to increase scalability and to simplify the systems design. The architecture is considered scalable if it is able to accommodate a number of layers in either large or small scales. For example, a computer that runs an Internet application may require all of the layers that were defined for the architectural model. Similarly, a computer that acts as a router may not need all of these layers. Systems design is furthermore simplified because with a layered architecture, the design has to only concern the layer in question and not worry about the architecture in a macro sense.
The depth and functionality of this stack differs from network to network. However, regardless of the differences among all networks, the purpose of each layer is to provide certain services (job responsibilities) to the layer above it, shielding the upper layers from the intricate details of how the services offered are implemented.
Every computer in a network possesses within
it a generic stack. A logical communication may exist
between any two computers through the layers of the same "level".
Layer-n on one computer may converse with layer-n on another
computer. There are rules and conventions used in the communication
known collectively as the layer-n protocol. A protocol
is an agreement between the conversing parties on how communication
should proceed.
In reality, however, data are not directly transferred from layer-n on one computer to layer-n on another computer. Rather, each layer passes data and control information to the layer directly below until the lowest layer is reached. Below layer-1 (the bottom layer), is the physical medium (the hardware) through which the actual transaction takes place. In Figure 2-1, logical communication is shown by a broken-line arrow and physical communication by a solid-line arrow.
Between every pair of adjacent layers is an interface. The interface is a specification that determines how the data should be passed between the layers. It defines what primitive operations and services the lower layer should offer to the upper layer. One of the most important considerations when designing a network is to design clean-cut interfaces between the layers. To create such an interface between the layers would require each layer to perform a specific collection of well-understood functions. A clean-cut interface make it easier to replace the implementation of one layer with another implementation because all that is required of the new implementation is that it offers exactly the same set of services to its neighboring layer above as the old implementation did.
Now, consider a five-layer network (shown
in Figure 2-2) that has been designed to provide communication
to the top layer of the network stack. An application process
in layer 5 produces a message M and then passes it to layer 4.
Layer 4 prepends a header to the message for identification
and passes the resulting data to layer 3. The header (H4)
may include control information that allows layer 4 on the destination
machine to properly deliver the message to the application layer
above. For example, if layer 3 and/or the layers below it disregard
the order of transmission/receipt, the control information in
layer 4's header should include the sequencing of the messages
that were passed to it from layer 5.
While there may be no limit to the size of messages transmitted in the layer 4 protocol, there may, however, be a limit imposed by the layer 3 protocol. Should layer 3 decide to split up the resulting message (a concatenation of H4 and M) from layer 4 into several units (packets) before passing it to the lower layer for transmission, the control information in the prefixed layer 3 header (H3) would have to include the order in which the message was split. In the case shown in Figure 2.2, M is split into two units, M1 and M2. It is important for layer 3 to maintain such header information because on arrival at the destination's peer layer, these units need to be reassembled into the original message.
Layer 2, upon receiving the resulting pieces of packet from layer 3, would not only add a header to each piece (to indicate to its peer that the outgoing unit is a layer 2 message), but also add a trailer to indicate the termination of that message unit before giving it to layer 1 for physical transmission.
At the receiving end the message moves upward from layer to layer, and as it progresses, the headers are stripped off. None of these headers for the layers below n would be passed up to layer-n. For example, a layer 2 header would be stripped off at layer 2 before the message is passed up to layer 3.
An important concept to understand from this example is the relationship between the logical and actual communication, and the difference between protocols and interfaces. For example, the peer processes (source and destination) in layer 3 may conceptually think of their communication as being horizontal using the layer 3 protocol. Each side could have a procedure called SendToOtherSide and ReceiveFromOtherSide, and while these procedures may seem to the layer 3 processes as if they are communicating directly with each other, these procedures are actually communicating with the lower layers across the interface between layers 2 and 3.
This notion of a layered architecture is crucial
to all network designs. The intricate task of designing a complete
network can be broken into several smaller, more manageable design
problems, namely the design of the individual layers.
The TCP/IP Reference Model, named after its
two primary protocols, is the network architecture used by the
Internet. First defined in 1974 by (Cerf and Kahn), one of the
major design goals was to create the ability to connect multiple
networks together in a seamless way. At the same time, a flexible
architecture was needed since a wide range of applications was
envisioned for the network, such as file transfer, electronic
mail and of course, real-time video transmission.
These requirements led to the design of a four-layer-protocol architecture: the application, transport, network and host-to-network layers (Figure 2.3).
At the bottom of the protocol stack is the host-to-network layer. This layer is in fact a great void. The TCP/IP reference model does not provide much detail about this layer. However, the model points out that the host computer has to connect to the network using some protocol so that it can send packets from the above layer to its destination. The main reason for the lack of definition for this layer is network compatibility. Since it is the goal of this model to provide the ability to connect multiple heterogeneous networks together in a seamless way, the TCP/IP model has to allow room for the different hardware configurations that are present in different network settings.
Above the host-to-network layer is the network layer. This layer is the linchpin that holds the whole architecture together. There is but one protocol that has been defined for this layer; it is called the Internet Protocol (IP). The job of the network layer is to deliver IP packets to their destinations. Clearly, the main job of this layer is to route the packets to their destinations while avoiding network congestion. Hence, addressing is a useful concept here. Each IP packet is designated to travel to a host computer, so IP addresses are assigned to each host that participates on the network.
Next, comes the transport layer. It has been designed to allow peer entities to carry out a conversation. There are two end-to-end protocols defined here: Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). The former is a protocol that provides guaranteed and connection-oriented services to the layer above. In other words, TCP ensures that a stream of data is delivered in order and without error from its source to its destination on the network. This service is modeled after the telephone system, where a connection needs to be established before a "conversation" can take place. Once a connection is established, it is used to send messages, one after another. The connection is only released when the communication process of sending and receiving is complete. One can think of a connection as a tube: bits of data are pushed in by a sender at one end and taken out in the same order by a receiver at the other end. This flow of data is bi-directional.
UDP on the other hand, provides best-effort and connectionless services to applications that do not want to use TCP. A best-effort service suggests that this protocol will attempt, with an affordable effort, to provide a service that is acceptable but delivery is not guaranteed. So in some sense, UDP is unreliable although its service is faster than TCP service (the next section will make a performance comparison between UDP and TCP services). Moreover, the connectionless service that UDP provides will route each message independent of the rest. Unlike a connection-oriented service, two packets that were sent to the same destination may not arrive in the same order as they were sent.
In both transport protocol categories, the notion of a named port is always used. This named port provides both UDP- and TCP-based applications a way to address the source and destination entities, the way the IP layer addresses a host using an IP address. This is an important notion because a host computer is capable of providing concurrent services, using either UDP or TCP, or even both protocols. If there were more than one service instance, the host should have as many port instances as the number of services present. With each port associated to a service, the computer system can easily de-multiplex an arriving message to the right service.
TCP allows fragmentation of data into discrete messages before passing them to the network layer. Symmetrically, defragmentation of data on the receiving end would be in order. TCP also handles flow control to ensure that a fast sender will not choke a slow receiver with more messages than it can cope. UDP, on the other hand, does not provide such services. It is however, widely used by applications for one-shot deliveries where speed is more important than accuracy.
At the very top of the protocol stack is the
application layer. It supports various high-level protocols,
such as TELNET (virtual terminal), FTP (file transfer), SMTP (electronic
mail) and HTTP (the World Wide Web). As a matter of fact, this
architecture was designed so that countless protocols can be added
to the application layer!
The service that UDP provides is faster than TCP's service. A comparison in performance between the two services was carried out using two sets of test programs, one for UDP and the other for TCP. The code listings of these programs can be found in Appendix E and Appendix F. Each set contains client and server programs. Each set will time the duration taken to complete the process of sending and receiving a file (an MPEG video file, in this experiment). The preconditions for both sets are the same. The only difference between the two was the protocol service used. That is, the MPEG file sent in both tests was the same. So were the algorithms that were used for sending and receiving. Furthermore, the client and server programs ran on the same computers in both test cases.
The following tables show the results from the trial runs using a 7-second MPEG file with the size of 1MB:
| Trials | Send time (seconds) | Receive time (seconds) |
| 1 | 29.99 | 30.53 |
| 2 | 32.36 | 32.99 |
| 3 | 29.89 | 30.51 |
| 4 | 31.03 | 31.70 |
| 5 | 28.78 | 29.42 |
| Average | 30.41 | 31.03 |
UDP-based Trial Runs
| Trials | Send time (seconds) | Receive time (seconds) |
| 1 | 3.46 | 3.63 |
| 2 | 3.44 | 3.46 |
| 3 | 1.15 | 0.18 |
| 4 | 1.12 | 0.13 |
| 5 | 1.15 | 0.14 |
| Average | 2.06 | 1.51 |
The results clearly show that on average,
the time it takes to transmit packets over UDP is considerably
less than over TCP.
The most common way of implementing an application-layer program for the network based on the TCP/IP Reference Model is to use the Socket Application Programming Interface. First introduced in 1981, Berkeley University's Socket API is an interface between the transport and application layers that provides a programming model through which the lower layers of the network communicate with the application layer. Using this API, the transport layer's TCP and UDP services become accessible to the calling application. In fact, the interface is application-created so these services can be requested by name and identified by uniquely named ports. By owning a Socket interface, a local application process can also send and receive messages to and from its remote process.
Each application process wishing to communicate over the network has to first explicitly create a socket. A socket is simply a communication endpoint for the application that creates it and can be seen only by the creator, or the local computer system. To stop an ongoing communication, the application has to release its socket. Refer to Figure 2.4a for the explicit code used to set up and release a socket. Conceptually, as shown in Figure 2.5, the socket interface resides between the transport and application layer. This interface is responsible for providing the application a set of function calls that a programmer can manipulate. The functions most commonly used are as follows: create a socket (socket), bind a socket (bind), extinguish a socket (close), send a message (send, sendto) and receive a message (recv, recvfrom). A socket in use has an address attached to it so that remote processes can refer to it by name. The binding procedure is made through the bind call (see Figure 2.4a for the explicit details). The previous section addressed the notion of ports. In the Socket API each socket will need to be associated with an address as well as a universal port identifier. The bind system call of the Socket API enables such an association to be made. To send a message, a connection-oriented application can use send to transfer its data to the remote site. Similarly, a connection-oriented application can use receive to wait for incoming data (see Figure 2.4b). For connectionless applications, the client and server sockets exchange datagrams that are addressed individually. In this case, the sendto and recvfrom calls are used to send and receive data (see Figure 2.4c).
The socket API also provides function calls to manage connection
establishments for those applications requiring connection-oriented
services. At the server end, the server process is required to
call listen and accept in order to establish a connection.
The client at the other end, requests that a connection be set
up by calling connect (Figure 2.4d).
Since the programming work in this thesis uses a connectionless
service (UDP) in the client-server communication, let us examine
a programming model that makes use of the Socket API.
Figure 2.6 illustrates a server-client relationship. The first
step that both ends take is to create a socket on each side.
This is followed by a call to bind the socket to a unique address
and port identifier. Since a server is responsible for providing
the application service, it waits to receive information from
the client. The client must, therefore, know how to locate the
server in the first place. The user usually knows the IP address
and port number of the server beforehand. Using that information
the client then sends the first message to the server. Upon receipt,
the server interprets the message and acts appropriately. Usually,
a server responses to the client by sending the outcome that resulted
from the client's request. This sending and receiving process
continues in a loop until either the server or the client requests
a termination of the communication. Both ends clean up the socket
by doing a close.
Like any other network applications, the video streaming system written for this thesis has been developed for the application layer of the TCP/IP reference model. Since time constraint is an issue, UDP was chosen instead of TCP to avoid the overhead costs associated with the latter. By using UDP, the real-time streaming application can assess the reliability of the channel and recover what it thinks is necessary to function, without the expenses that would have been incurred has TCP been used. To address the reliability issues presented by UDP, the application establishes its own protocol for communication between sender and receiver