The Internet was once intended to support multiple types of service [Cole, 81], but this intent was lost in the mists of time as its most basic, best effort service model became hugely successful throughout the last decade.
This service model is the contract, or perhaps in the Internet case, the lack of contract that exists between the network provided and its users.
A good analogy for a service model is that of a transportation system: we do not expect the roads to take us to a destination, we expect them to allow us to drive there, but we do expect a train or a plane to take us to a destination. These represent to different levels of service guarantees. We can take the analogy further if we add that we have no expectation from the existence of roads about journey times, but we have an expectation from the existence of timetables for our train journey times (although the British reader could be forgiven for not taking this seriously:-). Thus we can see that a service model refers both to the interface and to the performance that a system gives us. In this sense, it is more subtle and rich than most contracts.
In networks that are able to carry a range of different types of traffic from different applications, this contract is usually expressed in terms of a set of performance measures. In table 2.1 below, we illustrate a range of models used for service specification.
The most detailed way of expressing performance is through Quality of Service parameters (these might be more properly understood if they were called Quantity of Service parameters!). Quality of Service typically defines which paameter(s) in a set are relevant to a particulkar service contract and then defines valid ranges for values for those. Going back to our transport analogy, a train ticket might allow 1 person to travel, or it might allow a car on the train with all its passengers, or it might be a season ticket. Then the ticket may specify a particular seat on a particular train with a particular journey time, at the most specific.
In its simplest form, one might express the applications in terms of whether each end was a human or a computer, and whether the medium was data, audio or video. For example, a file transfer is of data between two computers, whilst remote terminal access requires moving data between a computer and a human, and an audio conference requires you to move audio between two (or more) humans and so forth. The difference between human and computer reception lies in two places: the way human perception of sound and vision cannot be told to wait - there is a minimum rate for delivering continuous media (hence its name); the way people interact - there is a maximum delay between utterance and comprehension, above which natural conversation becomes impossible. Of course, there are computer-to-computer networked applications that require delay bounds (e.g. telemetry or process control), but multimedia typically is delivered to or between humans, and that is what this book is concentrating on.
The Internet has had no basic, widely implemented way of expressing these rate and delay parameters, qualitatively or quantitatively. This is because the very fundamental way that one accesses the Internet to convey anything from source to destination(s) is without warning. Essentially, any computer connected to the Internet may attempt to communicate with any other computer(s) at any moment.
This is in direct contrast to traditional telecommunications networks used for example for telephony. The plain old telephone network requires users to do three things:
These requirements have the consequence that the telephone network gets warnings that a customer is about to use it (and the network has the opportunity to say no), and that once the network has said yes, neither the sender, nor the receiver can use up any more network resources (unless they have another line; but that is just like there being another user).
This means that the telephone network can be provisioned (dimensioned is another term used for this) reasonably easily for the expected number of calls at any time. Each call represents a fixed resource commitment. An unexpectedly high number of attempted calls (say on a popular holiday) can simply result in some calls being blocked (not getting through due to lack of internal resources). The relevant parameters for desiging a telephone network are shown in the table 2.2 below.
|
These parameters allow one to design a network for a given call blocking probability. Essentially, for a given level of user expectation (or dissatisfaction), it is possible to cost out a given infrastructure.
Call blocking is just another manifestation of congestion or overload, except that the degradation of service is to the users who get none, ratehr than to users who have already established access to the network. Some telephony systems actually suffer from overload during high call rates (flash call overload, e.g. during television dial-in programs), and use an adaptive ``call gapping'' procedure to reduce the rate of progression of call control itself.
Another type of network beloved of telecommunications companies is what is called the leased line. This makes an even stronger commitment in terms of resource (and assumes an even stronger requirement for this guarantee) between the network and the user in that this is a service that is in place from when it is installed as opposed to when the call is placed. In other words, the opportunity to say no is not there after the lease has been signed. A form of congestion exists for leased line networks which is that the provider may not be able to deploy a line fast enough for a given consumer; this is an extreme example of call blocking!
The Internet model is commonly referred to as a best effort service. Each request to send is honoured by the network as best it can. This works for communication of data between computers (usually) since the receiver can always wait for data that is late, and the sender can usually resend any data that is lost or distorted in transmission, however long it takes to discover this loss. This ability to cope with variable delivery rates and delays is often termed elasticity. If you picture the communications pipe between sender and recipient as a tube made of elastic carrying some liquid, then the delay and decrease in delivery rate is just like what happens if you stretch the tube - it gets longer and thinner. We illustrate the difference between Circuit based and Internet based networks in the table 2.3 below. This is extensively discussed in section 5.3 in chapter five.
|
The problems with using this type of technology to convey audio and video are twofold: that if the sender and/or receiver are humans, they cannot tolerate arbitrary delays; if the rate at which video and audio arrive is to low, the signal becomes incomprehensible. Using the elastic pipe analogy - if a fire engine was trying to put out a fire with such a water pipe, whenever it got stretched too much, the water would arrive too little, too late. We illustrate the range of service requirements for some example application usage in terms of the time or space between accesses to successive units of data in figure 2.2 below.
