RESOURCES RESERVATION IN A REACTIVE

RESOURCES RESERVATION IN A REACTIVE QoS SCHEME †

††

†

†

S. Ardon , C.Diot , B. Landfeldt , A. Seneviratne †

University of NSW, Kensington 2001, AUSTRALIA, {seb,bjornl,aps}@eng.uts.edu.au ††

SPRINT ATL; 1 Adrian Court, Burlingame, CA 94010, USA; [email protected]

Abstract User Services Assistant (USA) is a novel reactive QoS agent that provides facilities for managing user to user QoS in Internet environments. By being reactive, it overcomes the problems associated with QoS management schemes that have been proposed to date, such as the mapping of the QoS parameters to end system parameters, and pre-determining the optimum way of degrading/upgrading the QoS. However, for the reactive QoS scheme to be fully functional, it is necessary to provide facilities for end to end parameter negotiation, and to obtain support for resource reservation from the underlying systems. This paper provides an evaluation of the reactive QoS management paradigm, and its network resource reservation requirements. We show that reactive QoS management schemes requires sender initiated resource reservation, and if such a scheme can be provided, it can be used to provide effective and practical QoS management by using an implementation of USA over a sender initiated resource reservation scheme. Keywords: End-to-end QoS management in the Internet, QoS Management Architecture, Application adaptation, Resource Reservation and Monitoring

1. Introduction User Services Assistant (USA)[1] is a novel QoS management scheme, which facilitates the management of end-to-end QoS for Internet applications. It differs from the QoS management schemes that have been proposed for Internet applications, as the objective of USA is to assist a user to start and manage a networked application, interactively. In contrast to previous approaches, USA is reactive and lets the user change the operational configuration to alter the received QoS. The reactive paradigm of USA considerably simplifies the QoS management by eliminating the need for mapping the application requirements into system resources, continuously monitoring of resources to ensure their availability, and pre-determining what to do when conditions change. In addition, the reactive paradigm makes the use of QoS managers intuitive and simple.

USA’s reactive paradigm, its viability and intuitiveness were demonstrated through a prototype realisation [1]. Furthermore, in [2] we showed that USA can be deployed without modifying applications to provide additional services, through remote negotiation in the current Internet environment. However, to obtain the full benefits of a reactive QoS architecture, it is necessary for the underlying systems, especially the network, to support resource reservation. There have been several Internet resource reservation proposals in the past few years [4][5][6][7]. However, the use of these schemes to provide end-to-end QoS has not been fully investigated in the literature. In this paper, we analyse the network resource management requirements of reactive QoS management systems, and show that its is necessary to have a reservation scheme which is initiated by the transmitter of data, i.e. “sender initiated” reservation. Then we analyse three such schemes that have been proposed in the literature recently, namely YESSIR, SRP and DRP. After justifying the choice of one DRP, we describe the prototype implementation of this protocol. Using this prototype together with the USA implementation reported in [1], we show the viability and the effectiveness of the reactive QoS management paradigm for managing end-to-end QoS of Internet applications. Some performance evaluations are provided to validate our approach.

2. Reactive QoS Management Reactive QoS management schemes are user-centric in that all decisions are made by their user. The QoS management entity (QoS agent) simply facilitates the management of the available facilities to the user. This model is used in obtaining “services” in everyday life. Consider the use of the services offered by a travel agency: •

When a person has decided to travel, s/he would have made some travel plans and have an approximate budget.

•

The travel agent will use this information, look at the availability of resources (seats and accommodation etc.), and provide the customer (traveller) with some options,

•

The customer will then make a choice, possibly after a number of iterations and changes to her/his travel plan and budget.

USA

GUI

•

Then the travel agent will do the necessary (resource) reservations. The distinguishing features of this process are firstly that the negotiation between the customer and the travel agent is based on resources availability at the time (airline timetables, catalogues, etc.). Secondly, the customer changes the initial plans and budget depending on the choice s/he is presented with. Thirdly, once the reservations are done, the travel agent is not responsible for problems that occur whilst the customer is travelling. Finally, if the customer is unsatisfied, s/he either has to adapt, or stop and negotiate a new contract with a representative of the service provider s/he is unhappy, with either directly or through the travel agent. The reactive QoS management emulates the above travel agent model by having a QoS agent, which provides services similar to a travel agent. When a user (customer) wants to use an application, it will inform the QoS agent of his/her requirements, but not in terms of a specific application. For example, s/he will merely indicate the wish to make a voice call. The QoS agent will look at the local resources, determine the appropriate applications and configurations, and inform the user of available options. Once the user makes a choice, the QoS agent, where appropriate, will make the local and remote resource reservation and launch the chosen application and move to the background. We contend that users will generally not accept a machine making a decision on behalf of them. Hence we insist on that the QoS agent never take a decision on behalf of the customer. However, it provides the flexibility to automate this process by having user profiles. Furthermore, USA does not require application modification [2]. Once an application is running, if the user wants to change the operational configuration for some reason, the QoS agent is “reactivated”. When this happens, the QoS agent checks the operational environment, compare it with the previous measured operational environment determines the available options and finally informs the user.

3. Architecture of Reactive QoS Management System USA (User Services Assistant) is a realisation of the above reactive QoS management The architecture of USA is shown Figure 1, and consists of the five primary entities. (described above)

Request MIB

Logic

Negotiation

Answer Validation

Starter

Monitoring

Local

Remote

Application

Resource Reservation

Figure 1: Architecture of USA Before applications can be used with USA, they need to be registered. The registration process stores information about the applications requirements in the USA MIB. The information in the MIB is then used to choose the applications and will only contain application-related information and features (i.e., there will be no minimum bandwidth requirements if it is not part of the application specification). Special application hardware/software requirements (e.g. need for a sound card and a microphone) are also stored in the MIB. The objective is to enable user to start a session with a command as simple as “talk://[email protected]”. Also it will provide a more experienced user to directly specify an application and the types of coding he wants to use e.g. talk://freephone/gsm/[email protected]. This dialog will be via the GUI. In addition, the GUI will also provide a button to reactivate the QoS manager when the application is running. The USA-user dialog will be initiated by the logic module and will be simple, providing at most a couple of alternatives to the user. In the case of the audio example above, it may suggest (based on some information provided by a carrier) to use a primer class network connection at 14 cents per second or ordinary service at 10 cents. This information will be obtained through the monitoring module. In case of an inter-personal communication application, a negotiation step takes place between peer USA entities. This negotiation allow the participating USA entities to check for the user availability and location and to negotiate a set of parameters like media encoding, network level of service and finally the applications to use. This will be done via the negotiation module. Upon completion of a successful negotiation, USA performs the necessary resource reservations and launches the application using the starter module. Detailed description of the GUI, logic, monitoring can be found in [1], and [2] respectively. This paper focuses on the starter module, specifically resource reservation.

4. Resource Reservation We believe that it is only necessary to provide 2 classes of service for adaptive, real-time applications: • •

Best Effort (BE): A data flow using this class is not given any guarantee regarding the Quality of Service. It is similar to the service offered today in the Internet.

Minimum committed bandwidth (MCB): A data flow using this class is guaranteed a minimum amount of bandwidth. If more bandwidth is available, the data flow will be allowed to use it. This excess traffic will then be treated as best effort. Note that this class of service does not provide any guarantee on the delay bounds for individual packets. It is quite similar to Control Load [3] but differs in that it explicitly allows a flow to benefit from unused bandwidth when available. We envision the use of MCB for both adaptive and nonadaptive applications. In both cases, the application will be able to use extra resources if available, while ensuring an acceptable level of quality by reserving the minimum required bandwidth for it to operate correctly. For example a voice application may be capable of using speech encoded as PCM (64kb/s), DVI (32kb/s) or GSM (9.6kb/s). The user may opt to use PCM because it provides better quality but only reserve 32kb/s to minimise cost. If more bandwidth is available, s/he will continue to use PCM. However, if the network gets congested and the performance becomes unacceptable, USA will provide her with the option of either changing the encoding to DVI or increasing the bandwidth reservation. A non-adaptive application such as interactive whiteboard will reserve the bandwidth necessary for it to operate. Thus constant bit rate applications can equally well be supported with MCB. The traffic control engines in all the routers on the data path will be configured using a signalling protocol together with USA. The signalling protocol will be responsible for describing the flow and the requested service for a given flow. Several signalling protocols have been reported in the literature. These protocols can be broadly classified into either sender or receive-initiated. Receiver-initiated schemes require the receiver of the data to setup the reservation for the required network resources. Depending on the application type, it might be desirable to specify the reservation level at the receiver or at the sender. Indeed non-elastic traffic requires a specific amount of bandwidth depending on the encoding (e.g., PCM requires 64kb/s). This makes the sender, the most qualified to initiate the reservation. The encoding to use can be eventually negotiated at a higher-level, through a session negotiation protocol. In contrast, elastic traffic do not need any level of resource reservation and can accommodate (almost) any data rate. Thus it is solely the user’ Quality of Service needs that will decide the level of resource reservation required. This makes receiver-based

reservation more appropriate. However, this information can be communicated to the sender during session negotiation. Receiver-oriented signalling protocols like RSVP[4], requires the sender to advertise their traffic characteristics so that the receivers have knowledge of the traffic specification, and reservation requests can be reverserouted back to the sender, using the same path as the data flow. These advertisement messages (PATH messages in RSVP) not only introduce a protocol overhead but also require the routers to maintain an additional state per sender. This overhead can be avoided by using a sender-initiated protocol. Moreover, it is particularly relevant since USA already include session–negociation capabilities [2], we thus can save the overhead and complexity associated with receiver-initiated reservation by using a sender-based protocol. These considerations led us to consider the use of a senderinitiated scheme. Of the sender initiated schemes, “YEt another Sender Session Internet Reservation" protocol (YESSIR) [5], Scalable Resource Reservation Protocol (SRP) [6], and Dynamic Resource-reservation Protocol (DRP) [7], are regarded as being the most promising. YESSIR was developed as a lightweight alternative to RSVP for real-time applications. It uses Real-Time Transport Protocol (RTP) and its companion Real-Time Control Protocol (RTCP) to set up the reservation. The major drawback of YESSIR for realising the reservation in a generic QoS management system like USA is the unnecessary overheads that occur as a result of it relying on RTP. SRP allows the applications to set-up the control-load service and does not keep per-flow states in the routers. SRP messages are sent in-band with the data, by modifying the IP header. Routers and end-hosts using an estimation algorithm then calculate the level of service (e.g. bandwidth). The algorithm predicts future resource usage using previously observed traffic characteristics. The fact that SRP relies on modified IP headers, and that it has embedded traffic control mechanisms, makes it unsuitable for USA. For flexibility and portability, USA and its network signalling protocol have to work with the widest variety of traffic control infrastructures possible. Consequently, we chose DRP. Its operation and implementation is described in the following sections.

5. DRP overview DRP is a signalling protocol for resource reservation for providing quality of service in an IP environment [7]. It incorporates many of the RSVP principles (e.g. the soft state nature of installed reservations) along with the dynamic, sender-initiated reservation principle of ABT/IT [9]. Although DRP is suitable for either unicast or multicast data transmission, the examples we give in this section are for the general case of multicast.

A typical operation of the DRP protocol is illustrated in figure 21. A sender USA entity initiates a reservation by sending a DRP RES message to the destination. This message is intercepted at every DRP-capable router between the source and the destination. These DRP capable routers perform admission control. A RES message contains a SESSION object to describe the flow for which the reservation applies to (e.g. destination IP address along with TCP or UDP port numbers). The reservation requirements, i.e. the flow specification, are determined during the negotiation phase as explained previously. This information will either be available in the MIB or can be determined by USA. In addition, it is also possible to intercept the application traffic to gain knowledge of the SESSION parameters as described in [2]. Once the RES message has passed the admission control test, the reservations are installed on the routers similarly to RSVP. If a bi-directional reservation is needed, the remote USA entity will perform another reservation in the reverse direction. USA

Sender

DRP RE

S

S

RE

RE

RE

S

S

USA

USA

Receiver

Receiver

Figure 2. Operation of DRP in an Internet environment

5.1 Sender-initiated reservations in DRP

chosen at a router interface will be the “highest” QoS class specified by the receivers as shown in figure 3. This allows a receiver to benefit from the class of QoS it is willing to receive while optimising the utilisation of network resources. However DRP does not allow the receiver to accurately control the end-to-end delay as with RSVP. The reason is that the delay bound is determined by the nature of the senders traffic, which makes the sending application the most qualified to specify it [7]. This feature can be exploited in USA to optimise the network resources usage in case the sender is the remote-end (e.g. a receiver in a videoconference). As an example, the receiving USA entity can choose to downgrade the reservation class (from GS to CL or from CL to BE) according to the pricing policy.

5.3 Scalability in large multicast groups DRP uses RTN messages that are reverse-routed from receivers to senders, in order to allow receivers to downgrade their reservation class as explained before. In addition, it also enables the accumulation of certain path characteristics for a router to calculate the level of resource to allocate in the case of a guaranteed service reservation. In this respect, RTN messages fill a role similar to RSVP PATH messages but do not require an additional state to be maintained in the routers. In a large-scale multipoint-tomultipoint application, the use of a single shared tree for all senders to a multicast group will consume less resources than a separate source-based tree for each sender. In such a scenario, DRP exhibit a much better scalability property than RSVP by allowing a full merging of RTN messages. This merging ensures that the total number of reservation state entries is equal to the number of on-tree logical interfaces. With RSVP instead, the total number of PATH state entries to be stored in a router or end-host participating in the multicast group is equal to the total number of senders to the group.

The transmitter sends DRP reservation packets (RES) at any time during or prior to data transmission. This dynamic set up of the reservation allows fast modification of the reservation parameters during the data transfer phase.

End-host

Sender Routers Receivers requested reservation class

GS,CL

Reservation class installed on a router outgoing interface

GS

5.2 Heterogeneous reservation classes within a single session Upon receipt of a RES message, a receiver is free to downgrade the class of the just installed reservation. Downgrading is done as follows: Guaranteed Service (GS) > Control Load (CL) > Best Effort (BE). Thus, DRP allows different classes of QoS to co-exist within a single session. In case of multiple reservations, the QoS class

GS,CL

CL

CL GS

CL

GS

LAN

Receivers GS

CL

CL

GS

GS

Figure 3: Heterogeneity of reservation class for receivers of a same session Further details about DRP protocol processing rules and messages format can be found in [7].

1

For clarity, the figure only shows DRP operation for unidirectional communication

2

6. Prototype Implementation We have designed a prototype implementation of DRP (both for end-host and router) under Linux to evaluate the USA framework. Our implementation consists of a userspace daemon, that uses the Traffic Control capabilities and the new socket options of the recent Linux kernels (i.e. 2.2.x) [14]. Our DRP implementation and its experimental environment in an end-host are illustrated in Figure 4. Note that this figure represent the specific end-host as opposed to the case of a router which would not include USA and only run DRPd.

unsatisfied . This implementation of MCB is still experimental. Root class (100%)

DRP control 10Kbit/s Prio 1

A

1 B

40%

60%

C x

DRP share [MCB] Prio 2

D

Best effort Prio 3

z

y

USA Api Reservation

Figure 5. CBQ hierarchy used to implement Minimum Committed Bandwidth

Linux TC API

User Kernel

Admission control

classifier

Flow n

DRPd

Flow 2

Applications

Flow 1

...

estimator

Packet Scheduler(CBQ)

Network interface

Figure 4. End-host implementation of resource reservation in USA DRP RES and RTN messages are raw IP packets with a new protocol number. They carry the IP router alert [10] option in their header so that intermediate DRP-compliant nodes on the path can intercept and process them. The nonDRP routers will forward them as any IP packet. This makes DRP capable of operating through non-DRP clouds similarly to RSVP. However, in such cases, there will be limited benefits in using reservations. Our implementation relies on the traffic control capabilities of new Linux kernels. This includes several packetscheduling algorithms and several packet classifiers that can be configured to implement a variety of traffic control engines. We are using Class-Based Queuing [12] to perform packet scheduling. We implement the minimum committed bandwidth with the CBQ hierarchy shown in figure 5. The DRP control class (B) is a high-priority class where we map DRP protocol messages. It is low-bandwidth class that enables DRP messages to arrive at destination even when going through congested links. The second class is the DRP Minimum Committed Bandwidth. This class has the second highest priority. The Best Effort Class is allowed to borrow bandwidth from the root class. Of course this is possible only if the DRP class is not

Further research needs to be done to show how it would be possible to implement Minimum Committed Bandwidth with different packet schedulers such as Weighted Fair Queuing. The 60/40 split used between Best effort and MCB classes is arbitrary. The network administrator should define this value. The new socket options allow a user-space application to obtain information about which interface a packet comes from, and on which interface a packet should be sent. Furthermore, the concept of virtual interface allows a userspace program to treat a multicast tunnel endpoint as a normal interface. This allows DRP to run over a multicast router transparently without any specific routing support from the Multicast routing daemon.

7. Experimental Results & Analysis We conducted a series of experiments to validate the behaviour of our DRP implementation and to evaluate our reactive QoS management paradigm. Our experimental setup is illustrated on Figure 6. We observe the behaviour of an audio session using VAT [16] with a PCM (64Kbps) audio encoding. The audio stream travels through two Linux routers that are running DRPd. The network interface cards are common 10Mbps SMC Ultra Ethernet cards except for the last link to the receiver, which is a lower-speed radio link (2Mbit/s), using wavelan interface cards from Lucent. The routers are Pentiums 166MHz PCs running RedHat Linux 5.2 and kernels 2.2.3. The end hosts are Pentiums II PCs 233Mhz running the same Operating System. We generate background traffic from the higher speed link to simulate congestion at interface IA. This allowed us to examine the behaviour of the Linux traffic control engine.

2

Refer to [12] for full description of Class Base Queuing glossary

DRPd

Router

travel down the tree and sets up a 40Kpbs control-load reservation for the audio stream.

Router

DRPd

• 0 < t < t1 : Some extra bandwidth is available in the root class, the audio stream is allowed to borrow it and thus enjoy the 64kbps it needs.

VAT (receiver)

DRPd

DRPd IA

• t1 < t < t2 : The background traffic source is started and congests the router. Since it is allowed to borrow from the root class and since the MCB class is underlimit, the MCB class is regulated to receive only the reserved 40Kbps. As a result the audio stream experiences a 20Kpbs drop as shown on figure 8.

10Mbps Ethernet 10Mbps Ethernet 2Mbps Wavelan

Background traffic source Background traffic sink

Figure 6. Experimental setup It consists of a UDP data transfer at the maximum speed (link speed) using the ttcp program. We run a tcpdump probe in the second router, listening on the wavelan interface. The output of this probe is interpreted to calculate the instantaneous throughput for each flow using a 250ms window. We conducted 2 experiments and for each of them we derived the throughput information for each flow (background traffic and VAT Audio stream). In the first scenario (Figure 7), no resource reservation is made, the audio stream is treated as Best Effort traffic. At t = t1 when the background traffic source starts to send data, the output queues on IA become congested. Since the background traffic source sends at a much higher rate than the audio streams, almost all packets from the audio stream are dropped at the congested router. As a result, the audio session experiences nearly zero bandwidth in the period between t1 and t2, as seen on figure 7.

Throughput (Kbit/s)

2000

Background traffic

1500

• t2 < t < t3 : As consequence of this drop, the user becomes dissatisfied with the audio quality, and reactivates USA at t=t2. USA uses the monitoring modules and reports the drop in bandwidth since the initial measurement. The user then chooses the highest level of QoS for this session, which is mapped in the MIB to a full 64kpbs reservation. USA instructs the reservation module to modify the existing reservation, and increase it to 64Kbps. The DRP RES message reaches the last-hop router at t=t3 modifying the reservation on IA, which result in the increase of bandwidth enjoyed by the audio stream as can be seen from the figure. • t3 < t < t4 64Kbps

:

The audio stream enjoy the reserved

2000

Throughput (Kbit/s)

VAT (sender)

1500

1000

Background traffic

500

0 0

1000

20

30

40

Time (s)

50

60

70

0

0

10

20

30

40

50

Time (s)

60

100 90

VAT traffic

Throughput (Kbit/s)

500

60 50 40 30

VAT traffic

20 10

80

Throughput (Kbit/s)

10

80

0

70

0

10

20

t1

60

t2

30

t3

40

50

t4

Time (s)

60

50 40 30

Fig 8: 40kpbs initial reservation, and re-negotiation to 64Kbps

20 10 0 0

10

t1

20

30

t2

40

50

Time (s)

60

Figure 7. No resource reservation In the second scenario (figure 8), the user selects intermediate level of QoS through USA. This is mapped in the MIB to a 40Kbps minimum committed bandwidth reservation and Vat still using the 64kbps PCM codec. USA invokes the DRP daemon with the correct TSPEC and session parameters. DRPd then sends RES messages (not shown on the figure) destined to the receiver, which

8. Conclusion We have presented a novel reactive framework for providing end-to-end quality of service to the users in Internet environments, referred to as User Services Assistant. One of the primary requirements for providing this service is a resource reservation scheme at the network level. This paper demonstrated the possibility of achieving this with a sender-initiated resource reservation scheme, namely Dynamic Resource-reservation Protocol. A

prototype implementation of DRP together with USA was then used to show the feasibility of using DRP for dynamic resource reservation in reactive QoS schemes. Early experience using this prototype indicates that USA provides a valuable service to Internet uses. We believe that this will become even more useful when the operational environment will provide a multitude of configuration options in the future. However, to formally evaluate the benefits of the reactive framework and the sender initiated reservations, it is necessary to introduce “real” costs for increasing the quality.

9. References [1]

B. Landfeldt, A. Seneviratne, and C. Diot, ‘USA: User Service Agent, a New QoS Management Framework’, Int. Workshop in Quality of Service Management, USA, May 1998.

[2]

R. DeSilva, B. Landfeldt, S. Ardon, A. Seneviratne, C. Diot - “Managing Application Level Quality of Service through TOMTEN”. To appear in Journal of Computer Network and ISDN systems. Wroclawski J., “Specification of the Control-Load Network Element Service”, draft-ietf-intserv-ctrlload-svc-04.txt, November 1996. RFC2205; B. Braden, (Ed); L. Zhang, S. Berson, S. Herzog, S. Jamin,”Resource ReSerVation Protocol, September 1997.

[3]

[4]

[5]

P. Pan, and H. Schulzrinne, ”YESSIR: A Simple Reservation Mechanism for the Internet”, IBM Technical Report RC20697, 1997.

[6]

W. Almesberger, T. Ferrari, J.Y. Leboudec, “SRP: A scalable Resource Reservation Protocol for the Internet”, Technical Report 97/234, DI-EPFL March 1998 P. White, J. Crowcroft, “A case for dynamic senderbased reservations in the Internet” Journal of High Speed Networks, 1998.

[7]

[8]

Stalling, “ISDN, B-ISDN and Frame Relay”, Prentice Hall, 1997.

[9]

ATM Forum, ATM user network interface (UNI) specification version 4.0, AF-UNI 4.0, 1996 [10] RFC2113; D. Katz, “IP Router Options”, 1998. [11] S. Seshan, M. Stemm and R. Katz. “SPAND:Shared Passive Network Performance Discovery”. In Proc 1st Usenix Symposium on Internet Technologies and Systems (USITS '97) Monterey, CA December 1997 [12] Sally Floyd and Van Jacobson, “Link Sharing and Resource management Models for Packet Networks”, IEEE/ACM Transaction on Networking, Vol.3, No.4 August 1995 [13] RFC 2212; S. Shenker, C. Partidge, R. Guerin. “Specification of Guaranteed Quality of Service”

[14] Linux Kernel official http://www.kernel.org

release

site.

[15] S. Keshav “An engineering approach to computer networking” Addison-Wesley computing series [16] VAT, Video Audio Conferencing Tools, Lawrence Berkeley Laboratory, University of California, Berkeley, CA.