Figure 1: RSVP requests a route [4].
Olli-Pekka Auvinen, Juha Pääjärvi
Laboratory of Telecommunications and Multimedia
Helsinki University of Technology
Olli.Auvinen@hut.fi
Juha.Paajarvi@hut.fi
Increasing bandwidth capacity especially in broadband networks like ATM and Gigabit Ethernet brings a new light into this kind of an approach. High performances of the new technologies make it possible to develop more and more sophisticated networks and progress has lead many to plan and develop a new kind of a generic network that can be used to distribute many different services in one single transmission media. This kind of an integration is a pivotal element of the broadband networks of tomorrow.
The real problem is the issue of variation when talking about different services. For sure, services vary in type and especially in requirements, so the generic network needs to be very flexible. Such flexibility is not trivial at all to implement in practice. The main problem is the limited bandwidth. The need for huge amount of bandwidth arises from all the various services that are being integrated into the single generic network environment. The service specific data distribution types are making their effect on the needed bandwidth too. The data flows may concern flows from one point to another or from one point to many other points. Additionally, reliability is another crucial requirement demanded by many applications and services - especially when real-time requirements are being introduced.
Quality of service and bandwidth allocation play an important role in the development of business in the generic network services. How the roles of operators, service providers and content providers are going to settle as the development advances, remains an unanswered question. From the operator's point of view, the new techniques especially in quality of service area bring an important element in providing the transmission services for the service providers. Not only many services can be entered into the same network, but the service specific traffic level requirements are being allowed to vary a lot. Service creation is one aspect that can be made easier in this scenario.
The limited bandwidth is one of the most important things that make, for instance, quality of service considerations so important. If there were always enough bandwidth, all the connections that needed to be made, could use constant fraction of the whole bandwidth. That fraction would be defined according to the maximum momentary bandwidth needed in the connection. This would of course leave a part of the bandwidth unused, but it would not mean a whole lot, since there would always be enough of it in hand.
Naturally there is not enough bandwidth in use nowadays and it seems that as the more of it comes into use, the more of it could be used. Of course the performace level arises all the time, but with quality of service development the bandwidth that is in hand can be used a lot better and better applications and services can be developed for the customers. Even if everyone knew that in a known period of time, the performace of the communications systems would grow enough for the services that one would like to implement, the developed services could already be developed and tested in the old systems with more optimal usage of the resources in hand. Surely this kind of an approach would lead to an advantage in the field of competition in data communications business, especially for the service providers.
The usage of resources in point-to-point connections is straightforward. If the traffic is switched, the required bandwidth is allocated from one switch to another all the way from the source point to the destination point. This type of allocation is mostly dependent from the required quality of service level. If the desired level is high, the constant bandwidth fraction of the entire bandwidth must be allocated, which is the worst-case scenario. If the level is low the bandwidth requirements may vary through time and a part of the allocated bandwidth may be used for other traffic.
In point-to-multipoint connections, the situation is a bit different. The required bandwidth depends on the locations of the destination points. Whenever the destination points are directly connected to the same switch, the allocated resources from the network are smaller compared to the situation where the destination points lie far apart. It is important to keep in mind that of a one single link in multicast connections, it is not needed to allocate more bandwidth than it is needed in point-to-point connections. What comes to the required quality of service level, the same applies to point-to-multipoint connections as to previously presented point-to-point connections.
The presented two types of connections are useful in many cases, mostly in applications that utilize the qualities of a connection type concerned. Services and applications are discussed in chapter 4.
Reliability can be thought in another way too. One part of it defines whether the requested data transmission is completed or is it left incomplete. This aspect does not give any role for the time that it takes to complete it. From this point of view, the transmission is reliable, if it is guaranteed to complete. The other part of reliability is that it is defined to complete in a period of time. This brings transmission deadlines into picture. These deadlines are particularly important when the real-time applications are being introduced. Some applications have to be real-time that they could be used at all.
In fact this kind of a switching is normally accomplished at OSI protocol stack layer 2, which is the link layer. Throughout this text this kind of a switching is regarded as layer 2 switching. Actually, layer 2 switching can simply be considered bridging and in this logic, layer 3 switching is routing [1].
All the traffic in RSVP belongs to one of the four service levels:
guaranteed,
predictive, controlled load and
best effort. The guaranteed
service level guarantees data flows without discards and with the requested
maximum latency, whenever the sender is able to keep the requested rate.
However jitter and average latency are not guaranteed. Predictive service
level guarantees the data flow without discards like in the guaranteed
level, but the latency is not guaranteed. In the controlled load service
level the data flow is guarateed to be routed as in a normal unloaded network,
whenever the connection is allowed. The lowest level of service is the
traditional best effort approach that does not guarantee anything, but
it tries to accomplish the requested transmission with the existing resources.
[3]
Figure 1: RSVP requests a route [4].
Currently only two levels of service are specified in IETF draft specification for RSVP protocol - guaranteed and controlled load levels. Best effort can naturally be provided by not using the RSVP at all since it is the normal TCP/IP data transmission service level. The work in RSVP standards is not completed yet and several aspects of it are yet to be specified. Many problems and unanswered questions are still remaining. This is partly due to the original TCP/IP protocol suite and that it was not designed with quality of service in mind.
Lately, a different kind of a solution has been proposed to providing QoS in the Internet. The Internet Protocol version 4 type of service (TOS) field has been suggested to be used in separation of the service classes. Nowadays the TOS field is rarely used and only to separate control packets from normal packets in routing decisions. Recycling TOS field in providing QoS has been debated in IETF lately and the suggested classes of service would contain assured service and premium service. Assured service has been described as "better-than-best-effort" service and it expects that significant percentage of the traffic labeled this ways is best-effort traffic. In turn, premium service would provide higher level of service and it could be used to transfer video and audio. [5]
Advantages for TOS utilization in prividing QoS are that it would not require radical reforms in the existing Internet and that the solution would be scalable. However, it remains to be seen, how reliable and high level QoS it would provide.
Because ATM offers the only established quality of service functionality to date it can be seen as a serious contender in the race of becoming the prevalent network technology of the future. The problem for ATM is that it is cell switching technology. Because of this it is difficult to use the full potential of ATM quality of service in TCP/IP traffic, which in turn is based on routed variable length packets. So although ATM has an inherent QoS support it cannot be used as such for TCP/IP traffic that would support QoS. The QoS parameters of ATM could though possess something to learn about when evaluating possible QoS parameters for new network technologies.
Gigabit Ethernet has many advantages. It might be the technology that is at last cheap enough, fast enough and simple enough to become the network technology that brings quality of service classification of traffic into everyday use. It is based on perhaps the most successful network technology ever and this promises a large market for the gigabit Ethernet routers (or switches as some vendors like to call them). In fact there is a great number of new gigabit companies and the market seems to be almost overcrowded [1]. The downside of the gigabit Ethernet is that there is no standard way of negotiating the quality of service parameters with the network. It is also very difficult to provide a constant service level through a network because routers do not have any mechanisms to co-operate; the route of packets taken across the network can change and this might have an impact to the level of service [6]. It remains to be seen as whether the QoS of gigabit Ethernet will ever meet the needs of the users.
Because there are no quality of service parameters associated with TCP/IP protocols someone came up with an idea of using layer 4 information in prioritization and routing of network traffic. By making routing and prioritization decisions based on port numbers one can give a higher priority to traffic that requires minimal latency. For example file transfers could be given low priority because file transfer does not need short response times. In contrast, if there existed some mission critical applications that needed to pass network even when it is congested, they could be given a high priority. [1]
The good thing about layer 4 switching is that it can already be utilized in existing TCP/IP networks. Products that implement layer 4 switching functionality already exist and they can be used to full extent. An organization could use layer 4 switching equipment to prioritize the most important network traffic for itself and in this way guarantee good enough level of service for those applications that are vital for it. The downside of layer 4 switches is that they cannot be used to achieve a genuine quality of service functionality for the whole internet. The prioritization decisions are made by the owners of the switch. Thus for example if a real-time video is considered, the required priority for the video stream cannot be requested. Instead every router (or layer 4 switch) along the way from the source of the video stream to the receiver would prioritize the packets that belong to the stream according to its own prioritization settings. This would lead to a situation where the resulting service level is dictated by the router with the lowest priority for the stream and the highest congestion.
Distinctive feature about the services is that they are to be delivered
in a single generic network as described before. If the generic network
was an ATM network in LAN emulation, it would imply that the contained
services would be delivered in the QoS levels needed for them. An example
situation in one network node is demonstrated in figure 2, where services
like video, SNA traffic and e-mail arrive at an ATM switch and are stored
in queues corresponding the various QoS levels assigned to the services.
Figure 2: Services distributed in varying QoS levels in ATM LAN
emulation [8].
Telephone call and radio broadcasting are two of the most popular voice based services that could be implemented as applications once the required bandwidth is in use. Telephone services could contain the normal PSTN type of services, intelligent network (IN) services and additionally the mobile communications could be included too.
Radio differs from the telecommunications services in that it is multicasting type of service in contrast to point-to-point connections used in the telecommunications systems. In the radio broadcast, the data transmission consists of single direction traffic just as all the multicast traffic usually does and whenever the radio channel is a public one, the radio transmission is broadcast to every single customer. In commercial radio channels there might be some scenarios where the channels would be broadcast only to the paying customers.
In the video picture transfer applications there are a few really obvious services like television picture transmission and video-on demand services. These could naturally be combined with voice transmission to elevate the level of the service. TV channel broadcasting differs little from the radio broadcasting; the transmission type is the same and the requirements are pretty similar.
Video conferencing is one particularly interesting service that could be utilized in computer supported collaborative work (CSCW). This kind of a service would require several multicast connections for a single conferencing session especially if there were more than two parties contributing in the session. This scenario would require one multicast connection for every single participant in the session with source point of the connection in the participant's side and one destination point per each other participant in the session. Video conference requires a lot of bandwidth and experiences have shown that the quality of service level has to be very high in order to get any results from the conferencing session and to get the users even use the whole service. This is the same problem in the most other real-time applications described before - the requirements are very high.
Besides the conventional services, the new possibilities for business could lie in normal data transmission and in digital cash. One useful service would be just to provide a transmission pipe between two points for the customers needing such special media. There could also be quality of sercice parameters describing the service level of such pipe and the more crucial the use case would be, the higher the QoS level provided would be. For a normal user, this kind of service would probably not be very useful, but there could be some enterpreneurers that could use this kind of a service. The digital cash itself is not anything that needs extra QoS in the capacity sense since the biggest problems encountering it lie in the security areas.
Speech transmission in telecommunications is a service that requires a guaranteed level of bit rate. To a single voice transmission line, there have to be a constant part of the bandwidth allocated so that the allocated part can be used for the speech transmissions at all times. In ATM QoS terms, this service class is called constant bit rate. This quality level is needed just to accomplish a normal dialog using two telephones. One could think that cutting down the quality level to enable the traffic flow throughput from a place to another in the congestion situations would allow using lower quality levels in speech transmissions at times. However, this approach points out to be a bad one because understanding the speech will be very hard once the quality level drops too much. When compared to the best effort service of the IP networks, QoS is a crucial element benefiting the voice transmissions.
In video transmission applications the situation is pretty much like the situation in the speech transmission applications. However, in video picture transmission, there are a few special compression mechanisms that allow using lower levels of QoS. Mostly these situations are those where there is only small amount of variation in the consecutive frames of the video stream. Whenever the picture transmission has to be guaranteed the required level has to be as high as in voice transmissions though. The benefits gained from QoS techniques resemble the advantages gained in voice transmission greatly.
In addition to these specialized data transmission needs there are general data transmission services that are affected by the QoS originated benefits. In providing the transmission pipes for example between two points the sophisticated QoS techniques allow more flexibility in creating different transmission services with varying charging. This can result in competitive edge in business for the operators that have products applying sophisticated QoS technologies.
For the service providers, the real-time services bring terrific opportunities to increase, for example, the popularity of services provided in the Internet. One very interesting service idea is the real-time games. Nowadays a big part of entertainment industry gains profits from the normal computer games. In addition to these conventional computer games there is nowadays network games some of which are even real-time. But because of the best effort service level of the Internet the games are limited. QoS techniques could break these limits and make much more sophisticated games possible in the Internet. This could be the boost that makes network games popular. Network games would be a great business too. There could be a small charge for each time when a game is started. Given the great number of users in the Internet the games could be profitable with very low prices.
For hardware and software vendors to survive, they must sell products that can handle these requirements. Quality of service is one of the key technologies in fulfilling the promise of multimedia in networks. In the Internet there has been practically no support for different levels of service. All the traffic has been treated as equal. For multimedia and real-time applications to be utilized in the Internet this must change.
The possibilities of bringing QoS support to the Internet have been discussed for a while now. There are few proposals on how to implement QoS in the Internet. It seems that to achieve a proper QoS support, the protocols of the Internet must be modified. The proposed Internet Protocol version 6 (IPv6) might solve this problem. At the moment the QoS solution of IPv6 is left open so that it can be adjusted to the future advances in QoS technology. On the other hand the QoS implementation of IPv6 has to be decided in some stage. After that it might be a major factor in the market deciding which QoS architectures lose and which win.
The following sections will give some views on what kind of an impact QoS and its development might have on computer business.
We think that neither ATM nor gigabit Ethernet are technologies that can bring QoS in the Internet in their current form. In essence the problem with current technologies is as follows. ATM has a good QoS architecture but, because it is a switching technology, it does not fit very well into the TCP/IP world. Gigabit Ethernet on the other hand is very good technology for TCP/IP networks but it has the problem of not providing the "industry strength" QoS like ATM.
The current situation allows for an external factor such as the next version of IP-protocol (IPv6) to affect the market shares of future network technologies. IPv6 has a header field called "flow label" that can be used to mark data flows like real-time video transfer [9]. An IP flow could be seen as an intermediate form of traffic between connectionless packet traffic like IP and connection oriented, switched traffic like the one conveyed by ATM. In the flow initialization phase for example RSVP could be used to reserve a constant portion of bandwidth for a flow. A switch or a router would then recognize the packets belonging to the flow by their flow label and give them the precedence they need. This feature of IPv6 could as well give gigabit Ethernet the advantage it needs to become the dominant network architechture allowing QoS in the Internet.
Perhaps the most interesting possibility would be the use of QoS to develop true information business. At the moment the different electronic currencies being developed can support conventional trade in the networks. This does not include the trade of bare content that would be delivered to the customer through the network. QoS together with working electronic currency might make it possible to provide new multimedia services in the Internet. For these kind of services it is absolutely critical that they are delivered with high quality. Otherwise the end-users will not pay for them. There should be no pauses in the video streams and no delays in the data transfer of real-time applications. These are the problems that QoS can solve. Benefits and possibilities offered by QoS for services and applications were discussed in chapter 4 with more detail.
One concern for the service provider is the sufficiency of bandwidth. If the desired capacity would be granted to the user that simply requests it, the network would easily be reserved all the time. In telephony terms the network would be busy. This problem raises the question of how to share the bandwidth with different users. Should there be a limit for the bandwidth possessed by a user at any moment? Should the decision of whether to grant the requested bandwidth or not be based on the needs of the services? Or should the bandwidth be just priced so that no-one can afford to buy out the available bandwidth?
These are questions that haven't really been addressed so far. When comparing the situation of future computer network that has QoS support with conventional telephone network one notices that there is no similar problem in the telephone network. The users usually have only one phone and thus they cannot load the network with more than one call at any one moment.
From the view point of free market economy the bandwidth should always be available if someone can afford to pay for it. This approach suggests that the bandwidth should be priced so that it reflects the availability and demand of the bandwidth. A suitable solution might be to price the capacity so that the more a user has bandwidth allocated for himself the more it costs per Mbps. In other words the pricing would be progressive. A practical approach to the availability problem of the network would be to restrict the amount of constant bandwidth traffic to a certain portion of the available bandwidth. There would always be for example at least one half of the maximum capacity for best effort class traffic. This would guarantee that the network would always be available although it would be congested in the worst situations.
Currently most ISPs charge access to the Internet by a constant amount on monthly basis. Some of them could also charge the access based on the amount of packets delivered but as much as we know this is pretty rare. This is because of the complexity of this kind of charging and the uncertainty it presents to the customers as regarding to the actual total amount of the resulting bill. The observation of requested QoS by a user of the network as the basis of billing would certainly not be any simplier than counting the packets delivered. Because of this it is still very uncertain if the QoS parameters will ever be used as the basis of charging in future networks. Anyway, they could be used and if they were not used to charge access to the network by ISPs, QoS parameters could be used to apportion the cost of network access inside an organization in a way that could be perceived as fair by all parts of that organization [3]. It might also be so that the cost of allocating bandwidth will be "hidden" inside the costs of the services requiring higher service levels from the network and thus the cost of bandwidth is invisible to the users.
For this architecture to work there should be routing and switching equipment that supports different QoS levels. This is the market that is expected to grow. It seems that the capacities of the competing technologies, mainly ATM and Ethernet, are improving all the time. It is though difficult to say if better capacity is to be an advantage for either one of these technologies, because they are advancing in quite similar steps. It might be that the factor deciding the winning network architecture of the future is the way QoS is implemented in that particular architecture and how well it scales up to big networks like the Internet.
The importance of QoS raises from the needs of new applications. These include multimedia applications such as video and audio delivery and real time applications such as telephone calls, video conferencing and real time network games. All these require that the network they use to transfer data provides the quality of service needed by them. In other words they require that the data is transferred in a timely manner with acceptable delays in the transmission.
Guaranteed service levels could make wide variety of new business possible in the Internet. Nowadays the Internet can support only traditional trade. QoS techniques should make it possible to sell and deliver pure informational content through the Internet even if they had high requirements as regarding the level of service.
It does not seem though that there is going to be working QoS techniques for the Internet in the near future. This is because the protocols and the equipment of the Internet were not designed to support different QoS levels. The replacement of protocols and equipment to support QoS seems to be very difficult and it might be that true QoS will not come before the Internet2.
| API | Application Programming Interface. |
| ATM | Asynchronous Transfer Mode. |
| HTTP | HyperText Transfer Protocol. Application layer protocol that is used to transfer hypertext documents in IP networks. |
| IETF | Internet Engineering Task Force. A group that is developing a part of the Internet (e.g. some subprotocol of IP). |
| LAN | Local Area Network. |
| Mbps | Megabits per second. A measure of speed of a network or bandwidth. |
| MPEG | Moving Picture Experts Group. A commitee formed by the ISO to develop standards for video and audio compression. |
| OSI | Open Systems Interconnection. The seven layer protocol suite developed in the ISO for communications in open systems environment. |
| PSTN | Public Switched Telephone Network. The traditional telephone network architecture. |
| QoS | Quality of Service. |
| RSVP | Resource reSerVation Protocol. IETF's Protocol for reserving the resources in Internet environment. |
| SNA | System Network Architecture. IBM's network architecture that allows connecting LAN systems to IBM mainframe computers. |
| TCP | Transmission Control Protocol. Transport layer protocol that is used in connection oriented traffic in IP networks. |
| TCP/IP network | Network that uses the protocol used in the global Internet. The name of the network comes from the two important protocols used in internets. Also: IP network. |
| TOS | Type Of Service. A header field in Internet Protocol version 4. |
| UDP | User Datagram Protocol. Transport layer protocol that is used in connectionless traffic in IP networks. |