Guaranteeing Quality of Service for the Web using ATM

Werner Almesberger, Eric Gauthier, Jean-Yves Le Boudec, Philippe Oechslin (1),

Communication Networks Lab , Swiss Federal Institute of Technology, Lausanne, Switzerland.

Abstract

When using the Web over the TCP/IP protocol suite of the Internet there is (yet) no possibility to guarantee bandwidth or delay for a transmission. For multimedia documents, transmission with guaranteed quality of service (QoS) is very desirable. Also, commercial users and providers are interested in guaranteeing the quality of the service being paid for. ATM networks which are being deployed now are one means of solving this problem. They offer high bandwidths and QoS negotiation at connection establishment. We analyze how the Internet and ATM networks can interoperate to offer the best of both worlds to Web users while preserving compatibility with users which can not benefit of ATM connections. We present a solution built on a dual stack (IP & ATM). Finally we show how this solution can interwork with IP-only users to give them the benefits of partial ATM connectivity.

1. Introduction

1.1 The problem

 The problem we want to solve is to guarantee quality of network service to Web users. With the current implementation of the Internet the delay and throughput experienced when browsing the Web can vary greatly over time and location. These variations get more important as Web documents get richer in multimedia information. If an agent wants to display a multimedia stream while it is downloading it from a server, it will need the guarantee that the stream is delivered at least as fast as it is displayed. If the same agent wants to first download the multimedia document before visualizing it, it may still need the guarantee that the document will be received within a useful amount of time. If large documents are provided by commercial services, then the users will want the guarantee that they get a quality of service worth their money. This is also true for time critical documents like stock-exchange data.

Quality of network service is not actually a problem of the Web itself but much more of the network it is built upon. Therefore solutions are in better usage of available network services or in the development of new networks and services.

Solutions could be found using new IETF protocols like RSVP and NHRP (see Section 2 and Section 3). In this paper, however, we make the hypothesis that RSVP and NHRP will not soon be available and explore solutions using native ATM connections.

1.2 Background

The Internet Protocol (IP) is the network level protocol of the Internet. It follows the paradigms of connectionless datagram forwarding and best effort service. IP routers forward IP datagrams to intermediate routers until they eventually reach their destination. If the network is overloaded packets are dropped. These paradigms make it hard to control the QoS between two end users on the net. This is a well known problem and one solution for guaranteeing QoS is the recent RSVP protocol [Zhang].

Asynchronous Transfer Mode (ATM) is the standard for Broadband Integrated Service Digital Networks (B-ISDN). It is a connection oriented network based on fast packet switching. Communications between ATM end-systems require that a connection be setup prior to communication. ATM connections have a high throughput and a low latency since ATM cells are switched in hardware. In addition, connection setup enables resource reservation. These features make ATM connections well suited for audio and video transmissions.

1.3 Current and Future Work

One example of real-time multimedia communication within the Web can be found in [Chen]. This paper describes an agent called vosaic which allows to setup teleconferences through the Web. Interoperation between IP and ATM networks is being worked on at the IETF. The University of Illinois at Urbana-Champaign is developing IP over ATM using the X-ATM kernel [Tan], which is a derivative of the X-kernel. At the University of Waterloo a research project has been proposed with the goal to adapt HTTP to ATM. At the Communication Networks Laboratory of the Swiss Federal Institute of Technology we are currently implementing IP over ATM on Linux. We have chosen Linux because it gives us full access to the kernel and because the results can be distributed freely. This work is part of a new project called Web over ATM where we explore the interworking between IP and ATM, in regard to the Web as a main application.

1.4 Structure of this document

In Section 2 we describe how IP currently works over ATM networks and how the standards are evolving. In Section 3 we explain how the RSVP protocol reserves resources in IP networks. Section 4 introduces our solution with a dual stack approach while Section 5 discusses interoperability issues between our solution and non-ATM hosts. Section 6 is the conclusion of our paper.

2. IP over ATM

 The scalable bandwidth, the guaranteed QoS and its ability to integrated many different services make ATM a big competitor for future LANs, WANs and backbone networks. This has been recognized by the Internet Engineering Task Force (IETF) which has developed standards on how to overlay IP networks over ATM networks.

A first standard is the so-called classical IP over ATM defined mainly in RFC1577. In that scheme IP hosts are grouped in Logical IP Subnets (LIS) which are typically connected to a default IP router. The ATM network is treated much like a LAN and hosts within a LIS can connect through an address resolution protocol that maps IP addresses to ATM addresses. If a packet has to go to another host outside the LIS, it is sent to the default router which forwards it. The advantage of this solution is that it works in the same manner as existing IP networks, hence the name. The disadvantage is that packets may be sent through a set of routers and ATM connections even if a direct ATM connection would be possible.

A better solution under development is the Next Hop Resolution Protocol (NHRP). With this protocol, address resolution requests are propagated to different servers in the network. The reply to a request gives the information needed to establish a direct connection to the destination host or, if the host is not on the ATM network, to the closest router on the edge of the ATM network. NHRP currently has the status of an Internet draft.

The different schemes for IP over ATM will allow to run the Web transparently over ATM networks. However they don't provide any way to reserve resources or to guarantee QoS. The IETF has a solution for resource reservation in IP networks as we will see in the next section.

3. Resource reservation schemes for the Internet

Having identified resource reservation as a key aspect for transmission of real-time multimedia information the IETF has developed the Resource reSerVation Protocol [Zhang]. In RSVP, a receiver can request a resource reservation along the path between the source and the receiver. This reservation is subject to call acceptance control by all intermediate IP routers which support RSVP. Once a connection is established, the routers schedule the transmission of IP datagrams in function of the priority of the stream they belong to. RSVP has multicast capabilities. This means that resource reservations are not only made between two endpoints but within a multicast tree. RSVP is about to become a IETF standard.

Using RSVP a certain QoS can be guaranteed since resources are reserved at each intermediate hop. However, the datagrams still travel hop by hop. In an ATM environment it would be much more efficient to establish direct connections.

4. A simple solution: The dual stack approach

4.1 Why do we need a solution?

Coming back to our original problem it seems that a solution is going to emerge all by itself. Once the routers of the Internet will implement RSVP, Web agents and servers will be able to use this protocol to guarantee the QoS for the delivery of Web documents. If by that time NHRP is implemented in ATM parts of the Internet (LANs, WANs, backbones) then it will even be possible to bypass intermediate routers and to have direct connections between servers and agents. The drawbacks of this solution are complexity and penetration time. The solution is complex because two new protocols need to be implemented on all the routers of the network. Time considerations are even more important: Although RSVP is about to become a standard, it only provides for reservation of resources. It does not, however, give an exact definition of what resources are nor how they can be monitored and policed. NHRP on its side is still a draft and different issues need to be resolved before it can be proposed as a standard. Thus a complete solution using RSVP and NHRP is not yet operational.

We make the hypothesis that we are in a network were RSVP and NHRP are not yet available (which may be true for quite some time). Thus we will explore a solution which does not make use of these protocols.

4.2 The dual stack solution

When an agent on ATM contacts a server on ATM, the agent can provide its ATM address to the server. It would then clearly be inefficient to ask an intermediate layer of IP routers to route documents from the server to the agent if the server can connect directly to the agent. Our solution to the problem thus simply consists of opening a direct ATM connection between the server and the agent whenever a document has to be transmitted with guaranteed QoS. Two informations are needed for this: a) the server must know at which ATM address the agent can be reached directly, if at all, and b) the server must know whether a document is QoS-sensitive and what QoS must be requested. The first information can be included in the header of HTTP requests while the second information can be put in the header of HTML documents. To be able to open a connection with guaranteed QoS, the server software must also be able to interact directly with an ATM protocol stack. The server thus uses both a TCP/IP and an ATM protocol stack, hence the name of our solution.

This little modification allows a tremendous gain in guaranteed quality delivery without compromising the interoperability with non-ATM servers or agents. The QoS guarantee enables information providers to deliver high-quality documents, like video on demand or real-time transmissions of live events which can be charged on a quality basis. A 5Mbit data stream could be charged higher than a 1Mbit stream, with the guarantee that the user really gets what he pays for (WYPIWYG).

Availability of a dual stack

As of today, Web servers or agents connected to ATM networks typically use classical IP over ATM. To implement IP over ATM, their host must implement all the functionalities needed to make pure ATM connections. Vendors of ATM Network Interface Cards (NICs) usually also provide a pure ATM API beside the standard IP API. This provides a way of establishing pure ATM connections between servers and agents running on ATM networks. Furthermore, a standard ATM API is currently being defined by the ATM Forum [ATM95].

4.3 Implementation of our solution

Adding information

As we saw above, two kinds of information are needed for our solution. One has to be given by the client and the other one in the documents.

Agent: The fact that an agent is able to use a dual stack is clearly related to the agent and not to the data that will be transmitted. Therefore, we propose to add this information in the 'UserAgent:' field of HTTP requests. This fields allows extra information besides the product name and version. An agent capable of receiving documents over a direct ATM connection can indicate it by putting the keyword ATM in this field. If it wants the server to open an ATM connection it adds the public and private ATM addresses of the agent to the ATM keyword. (Public and private ATM networks do not use the same addressing scheme and interoperation is only possible if the public ATM address of a gateway to the private ATM network of the destination is given.) The version number is be 1.0. The public address is given in ascii decimal digits and the private address in ascii hex digits. The keyword ATM and the two addresses are separated by ascii dots. When no address is given the ATM keyword appears without addresses.

example (with address): 

 UserAgent:  MyAgent/1.0  ATM.PublicAddress.PrivateAddress/1.0
example (without address): 
 UserAgent:  MyAgent/1.0  ATM/1.0
Server: When the server responds to a dual-stack agent it adds an ATM field in the header of the response to indicate its address. The format of the address is the same as for the agent: 
 ATM:PublicAddress.PrivateAddress
Document: The server must recognize QoS sensitive documents and know the QoS requirements of these documents. We propose to add this information into the header of HTML documents. This can be done using <meta> elements. The name of the elements is "ATM-QoS-XXX" where XXX is the abbreviation for a traffic or QoS parameter according to the User Network Interface (UNI) specification of the ATM forum [UNI3.1]. The content field contains the value of the parameter in digital ascii representation.

example (sustainable cell rate = 2000 cells per second): 


 <meta HTTP-EQUIV="ATM-QoS-SCR" content="2000">

The HTTP request and response

The only particularity of HTTP requests made by a dual stack agent will be the ATM address in the user agent field. Thus it interoperates seamlessly with standard servers. If the agent makes a request to a dual stack server, the server recognizes the ATM keyword and watches document headers for QoS specifications. If the agent requests a document which has no QoS specifications then the server delivers it in the standard fashion. If the agent requests a document with QoS specifications and indicates its ATM address, the server will set up an ATM connection (see below). If the agent does not indicate its ATM address then the server only sends the HTTP headers over the TCP/IP network, as if the agent had used the HEAD method rather than the GET method. The actual content of the document is sent over an ATM connection. From the header fields the agent can know what the QoS specification are and how long the document is.

Data transport

In section 4.2 we have assumed that some ATM API would be available on the hosts to establish direct ATM connections. Establishing a connection, however, is only half of the job. Once a connection is established, some protocol has to be used to transport the data over the connection. We have chosen UDP and TCP for pragmatic reasons. They are the standard protocols used on the Internet and are thus thus already be available on the hosts. An ideal scheme would be that the agent and the server negotiate the best transport protocol among a set of protocols available to them, depending on the type of data to transmit. This negotiation is however out of the scope of this paper.

One way of running TCP over a pure ATM connection would be to use TUNIC (TCP over non-existent IP Connection) [Cole]. As TUNIC is not standardized this solution would require the development of a non-standard implementation. Rather than to reimplement TCP we therefore propose another solution which reuses the TCP of the hosts by making a slight modification to its IP layer. This solution allows to use the same socket interface for data going over the TCP/IP network and over the ATM network. It hinges on ARP (address resolution protocol) tables of the IP layer The address resolution protocol maps IP addresses to LLC addresses on the network to which a host is attached. To avoid to make ARP lookups for every packet sent out, address mappings are kept in an ARP table. When IP is run over ATM then the ARP table maps IP addresses to VCI/VPI pairs. Our solution requires that entries in this table can be set and locked by the server or client application. It also requires the possibility to add QoS parameters and socket identifiers in ARP table entries.

The exact procedure for the establishment of an ATM connection is as follows: When the agent requests a document it puts the ATM keyword in its userAgent field without indicating its address. If the requested document has QoS indication the server will only deliver the header of the document as if the HEAD method had been used. Having received the header of the document, with the ATM-QoS-XXX fields, the Agent can chose to download the document over ATM or IP. To request the document over ATM it repeats the same request but adds its ATM address to the userAgent field. To request the document over IP it makes the same request without the ATM keyword. Figure 1 illustrates the requests and responses.

Figure 1. Establishment of ATM connections between a dual-stack agent and dual-stack server.

1. The agent requests a document with its userAgent field set to 'ATM'. 2. The server notices the QoS specifications in the document and only sends the header of the document to the Agent. 3. The agent puts the server's IP and ATM addresses, the QoS parameters and the identifier of the socket used to make the request into the ARP table of IP. 4. The agent sends the same requests but adds its ATM address to the userAgent field. When IP wants to transmit this request it finds the IP address of the server in its ARP talbe. If the data is coming from the socket corresponding to the socket identifier in the table entry, it establishes an ATM connection to the server, using the QoS parameters from the table entry. The ATM connection is established to the IP access point of the server and the VCI, VPI pair is introduced into the ARP table. Any further IP packets for the server will be sent through this ATM connection. 5. The second request is received by the server as if it came over the IP network. Seeing the ATM address in the request, the server adds an entry in the ARP table with the IP and ATM addresses of the Agent, the socket identifier of the server socket and the requested QoS parameters. 6. The server then sends the document to the agent and IP, using the new ARP table entry, opens an ATM connection to the agent. The document is then be delivered over pure ATM with the requested QoS.

5. Interoperability with non-ATM systems

There are no fundamental interworking problems of our dual stack approach with non-ATM hosts. Dual stack agents or servers can use their IP stack to communicate with non-ATM users. However, if most of the connection between two hosts is based on an ATM network and the IP based portion is small and controllable (eg. a Customer Premises Network, CPN), then the usage of an HTTP proxy can give the advantages of the partial ATM connection to the IP based host.

A proxy HTTP server is an intermediate host which forwards HTTP requests from agents to servers. One use of HTTP proxies is to have a centralized point for caching of HTML pages. Another use are firewalls where direct connections between a CPN and the Internet are avoided. In our case an IP based agent would connect to a dual stack HTTP proxy over a fast IP network. The proxy would then receive QoS sensitive documents over ATM and forward them to the agent over the TCP/IP network.

The fact that proxy HTTP servers are at the application level may induce a limitation in performance. More efficient solutions could be found by developing ATM-IP gateways at the router level. This would require more general solutions than just Web oriented ones and is not in the scope of this paper.

6. Conclusions

We have given a simple solution to add QoS guarantees to the delivery of Web documents between hosts connected by ATM. The solution requires little modification of HTTP servers and clients, they basically need to know how to use an ATM API and to recognize each other. As TUNIC is not yet available our solution requires a simple modification to the TCP/IP code of the server and agent hosts. Our solution allows to distribute Web documents with a guaranteed QoS. This is important for real-time multimedia documents as well as for commercial providers offering WYPIWYG services for ATM connected users. We have also shown how non-ATM users will be able to benefit from partial ATM connectivity by using an ATM proxy.

(1) Contact author: Philippe Oechslin (oechslin@lrc.epfl.ch)