Meeting QOS Guarantees by End-to-End QOS Monitoring ... - CiteSeerX

Meeting QOS Guarantees by End-to-End QOS Monitoring and Adaptation J.-F. Huard, I. Inoue, A. A. Lazar and H. Yamanaka Department of Electrical Engineering and Center for Telecommunications Research Columbia University, New York, NY, 10027-6699 http://www.ctr.columbia.edu/˜fjfhuard, inoue, aurel, hideakig Abstract The design and implementation of the transport layer of a native ATM protocol stack and its embedding into an overall architecture that provides end-to-end quality of service (QOS) is presented. Within this architecture, the typical transport functionalities are enlarged with QOS monitoring and adaptation mechanisms. A QOS-based application programming interface is proposed that shields application programmers from the complexity of QOS management and control. Both unicast and multicast connections supporting interactive multimedia applications are considered.

1. Introduction Over the past several years, substantial research effort has been invested in designing architectures in support of quality of service. Typically, the work has been carried out within the context of a single architectural layer [4]. In the telecommunications community, a fair amount of effort has been devoted to the design of connection oriented network architectures that support QOS guarantees for broadband networks based on ATM technology. Typically, these architectures guarantee losses and delays at the network access points. The Internet community has focused its effort into finding ways to upgrade the existing IP support of QOS (e.g., RSVP [19]) in a connectionless environment. In both cases, the responsibility to deliver the QOS to the application stays with the application programmer. This renders the application development difficult for most programmers. Although the two communities are converging, little work has been done to address the issue of end-to-end QOS; that is, from application to application, whether client-server or peer-to-peer. Current architectural frameworks lack a QOSbased application programming interface (API) and transport mechanisms that support end-to-end QOS. QOS-based APIs are required to shield applications from the complexity of QOS management and control, and the complexity of

information transport. Our work focuses on the identification of transport services and the implementation of mechanisms needed in the transport protocol for guaranteeing end-to-end QOS. By this we mean that mechanisms are provided for QOS mapping between application and network levels; on a fast time scale, we provide transport mechanisms for monitoring and adaptation of the data stream to rapid fluctuations of QOS; on a slow time scale, we provide an interface for renegotiation; and finally we provide a QOS-based transport API for provisioning, renegotiation and media transfer. This paper is organized as follows. In Section 2 we present the network QOS architecture used as a framework for this work. In Section 3, we propose a QOS architecture for transport that enables us to meet end-to-end QOS. In Section 4 we proposes mechanism for QOS monitoring and adapatation. Before concluding, Section 5 describes our first implementation of the proposed architecture and mechanisms.

2. Network QOS Architecture The basic framework for the creation and deployment of multimedia services with end-to-end quality of service guarantees has been formulated in [12]. The Binding Model provides an open architecture in which network resources are modeled as objects with well-defined interfaces. These objects can be operated upon via methods in order to control and manage network resources. The Binding Model is embedded into the Extended Reference Model (XRM) for multimedia networks [10, 11]. The XRM provides a framework for guaranteeing end-toend quality of service. Upon request from an application, a service controller verifies wheather a new call can be admitted into the network. This requires invoking the appropriate admission control method, finding a path from the source to the destination, asking the resource manager to allocate bandwidth and buffers, and finally passing the control to the transport layer in the end user system. In [14], the multime-

B

SRC

A

Schedulable Region

C

DEST

Multimedia Capacity Region

Figure 1. A schedulable region.

Figure 2. The networking capacity graph.

dia capacity region concept was established for providing QOS in the end system. In the network, a similar concept, namely the schedulable region, was formulated in [8]. In the next section we briefly explain these concepts in more detail.

control method for ensuring that a data flow can be established through all MCRs and SRs on the route between the source and destination. For example, in Figure 2, the flow goes through the MCR at the source (SRC), then the SRs between nodes A and B, and B and C, and finally through the MCR at the destination (DEST). Although admission control algorithms are expected to guarantee QOS at the cell level by regulating the number of calls in the network, the end user may experience transient degradations of the end-to-end QOS. For example, a link failure may cause such a QOS degradation. Furthermore, during a short time period, per-class or statistical QOS guarantees (see Section 2.2) might allow a QOS degradation of the service offered to a user while guaranteeing QOS to the other users. It is the role of the transport protocol to cope with these fast time scale fluctuations.

2.1. The Networking Capacity Graph A call can be admitted into the network only if the requested QOS can be provided without violating the QOS agreement made with existing calls. Once a call is admitted, control algorithms, namely admission control, routing, flow control, scheduling and buffer management, must sustain the agreed QOS. The user is also expected to abidde by its QOS agreement. Guaranteeing QOS at the call level is the job of the admission controller. The latter must decide the acceptance or blocking of incoming traffic on a call-by-call basis. This is done using the concept of schedulable region (SR). The schedulable region S [8] defines how many calls of a given class the link can support, while guaranteeing the appropriate cell level QOS to each class. The SR, S , is an N dimensional space, where N is the number of traffic classes (such as audio, video, facsimile, data) recognized by the network. The resource state is defined by the occupancy vector x = (x1 ; x2; : : : ; xN ) representing the number of calls of each class that are active on the link. In order to guarantee the QOS to each class of traffic, the occupancy vector can only assume values that are inside the SR, i.e., x 2 S (see Figure 1). The task of the admission controller is, therefore, to accept or reject arriving calls based on the occupancy vector and the SR. Similarly, the multimedia capacity region (MCR) abstracts end system resources (such as disk storage and video processing). The SRs and MCRs are generically called the networking capacity regions. When interconnected, they form a networking capacity graph as shown in Figure 2. The service controller invokes the appropriate admission

2.2. Traffic Classes and QOS Guarantees In this section, two concepts about traffic classification and QOS guarantees that are appropriate in defining QOS requirements are introduced.

Type of service vs class of traffic. A type of service is defined by a set of QOS requirements (e.g., loss and delay) and traffic charateristics (e.g., peak rate) specified in terms of application level terminology. Typical services may be, for example, telephony voice, conversational video and highfidelity audio. A class of traffic is also defined by a set of QOS requirements and traffic specifications but at the network (multiplexing) level, and not directly associated with an application level service. Provided that there exists a mapping for every type of service offered at the application level into one or more classes of traffic at the network level, end-to-end QOS requirements lead to tractable algorithms for admission control.

3. The QOS Architecture for Transport

Time Delay

SI

Time Delay Distribution

Class II ε% Blocking Clipping

Average Throughput

S II

Time Delay

Gap Distribution

Time Delay Distribution

Class I

Gap Loss η

Class III Γ Average Time Delay T

Figure 3. The COMET traffic classes.

Per-session vs per-class QOS. QOS can be provided persession, where the QOS is guaranteed for each individual session or per-class, where the constraints are guaranteed for the aggregate traffic of a given class. In the per-session case, one must keep track of each individual session in progress in the network to make sure that the appropriate QOS is provided. For the per-class case, the isolation and monitoring of the different classes of traffic is needed at each node.

COMET traffic classes [15]. The QOS requirements considered in this work are delays and losses. In the XRM framework, QOS is specified at the (ATM) multiplexing level; that is, at the cell level and statistically per (network) class of traffic. The traffic classes are differentiated by the set of QOS parameters used (see Figure 3). Class I is characterized by zero loss rate, a bound S I on the support of the time delay distribution and a peak rate cI . Class II is defined by  % loss rate,  cells in gap loss, a bound S II on the time delay distribution and a peak rate cII . Finally, class III is chararterized by a bound T on the expected time delay with a peak rate cIII . Classes I and II are for modeling real-time traffic with no retransmissions allowed, while class III is for modeling non real-time traffic with retransmissions allowed.

Our work focuses on the identification of transport services and the implementation of mechanisms needed in the transport protocol for guaranteeing end-to-end QOS. By this we mean that mechanisms are provided for QOS mapping between application and network levels; on a fast time scale, we provide transport mechanisms for monitoring and adaptation of the data stream to rapid fluctuations of QOS; on a slow time scale, we provide an interface for renegotiation; and finally we provide a QOS-based transport API for provisioning, renegotiation and media transfer. The transport protocol is a set of mechanisms whose task is to ensure continuous QOS guarantees for the data stream presented to the application; that is, end-to-end QOS. Our work is based on the assumption that the cell level QOS is provided locally at each resource. A control subsystem (e.g., admission control mechanism) guarantees the end-toend network QOS on a slow time scale for a predefined number of traffic classes. The transport offers services with QOS specified per-session using application level terminology (e.g., JPEG video frame delay). For provisioning, monitoring and adaptation, the transport maps the application level QOS requirements into network level QOS requirements. This is addressed in Section 3.1. On a fast time scale, the transport monitors the end-to-end QOS of a specific call and adapts the data stream to fast time scale fluctuations of the QOS. The adaptation is done in real-time and should not affect the end-user perception of quality, provided that end-user resources are available. In our implementation, the xbind binding architecture [13] is used for signalling (connection management and resource allocation). However, our transport model is not constrained into using xbind. Any signalling subsystem may be used, provided that an equivalent functionality (service provisioning with QOS and multicasting) is available. Furthermore, our work is not limited to ATM networks; our transport protocol is independent of the network below it and can be used with any network that guarantees QOS at the network data unit level (see Figure 4). The main characteristic of our architecture and its implementation is that it is not layered in the OSI sense [17] (despite its apparent “layered” representation in Figure 4). The various mechanisms directly communicate for providing QOS. For a review of other models that provide QOS, see [2, 3, 4, 5] and the references therein.

3.1. QOS mapping On the slow time scale the end-to-end QOS is guaranteed at the service creation time by means of a calculus of networking capacity regions (MCRs and SRs). On the fast time scale, by QOS monitoring, the transport protocol

Application

Transport

ATM

Mobile

IP

Application QOS requirements specification of loss and delay in application level terminology based on transport services offered Transport services QOS loss and delay per session monitoring of TPDU adaptation based on type of services Network QOS loss and delay per class of traffic based on network PDU (cell / bit / IP packet)

Service types

COMET traffic classes

motion JPEG MPEG-I MPEG-II

Class II

CD audio reliable data raw class I

Figure 4. QOS architecture for transport.

Class I

Class III

raw class II raw class III

ensures that the network fluctuations are within acceptable limit and adapts to network loading appropriately. However, to perform monitoring, the QOS requirements specified in application level terminology need to be translated into transport level terminology, that is, for example, from video frame or audio packet to transport protocol data units (TPDUs). A further level of translation is needed between TPDUs and cells. This rescaling of QOS parameters is called QOS parameter mapping. A mapping between the type of services the transport protocol offers and the traffic classes the network offers is also needed. This we call QOS service mapping. At the application level, the QOS is guaranteed by ensuring that resources are available using the concept of MCR. The number of service types defines the dimensionality of the MCR the same way the number of traffic classes defines the dimensionality of the SR [8]. The transport services offered are, for example, motion JPEG video, MPEG-I video, MPEG-II video, CD audio and reliable data transmission. Raw services with QOS (class I, II and III) are also available as well as a best effort service. As the number of applications will grow so will the number of service types. Since specific definitions of application QOS is beyond the scope of this work, we assume a very generic set of application QOS requirements based on such essential elements as peak rate, error rate and delay distribution. Each application has its QOS own features: tolerable delay, video frame or audio packet loss and gap loss. Other parameters such as average rate, burst period, etc., may also be important. We are still investigating the issue of determining which other parameters are relevant. Currently, all three video services are mapped into class I, the CD audio into class II and the reliable data transmission into class III (see Figure 5). The transport protocol does not perform any retransmissions for video and audio services while it executes error control for reliable data transmission. For simplicity, the parameter mapping is done by rescaling the QOS parameters with the ratios of the different data units: application PDU, TPDU and cells.

Figure 5. Service-to-class mapping.

3.2. QOS-based Transport API In this section, we present our QOS-based transport API. Unlike BSD sockets and other popular transport APIs that do not support QOS, our API supports raw COMET QOS traffic classes as detailed in Section 2.2 and multimedia services with QOS (also as described above). The API (see Table 1) is simple, has calls for QOS provisioning, QOS control (renegotiation and violation notification) and media transfer. The API supports both unicast and multicast connections. The API assumes an architecture that isolates application from transport and signalling. Our philosophy is that the application programmer should be allowed to select the transport and signalling based on availability and on need. For example, there should be a library of transport protocols an application could be linked with, while selecting the signalling it desires. The application programmer should not be constrained by the choice the transport protocol. The calls for provisioning (tp establish(), tp createGrp() and tp addLeaf()) return an identifier (cid or grp) that is used as parameters by the media transfer and QOS control calls. For QOS control, while the application performs renegotiation with the network (via signalling), the transport is instructed of the new QOS parameters to monitor and adapt to via tp setQOS(). To poll the transport for QOS violation notification, the call tp notify() is used. For media transfer, the typical parameters are passed. An extra parameter, attr, is available in tp send() to inform the transport of the nature of the data. For example, for the MPEG-II service, the parameter is used to inform the transport of the frame type (I, P or B). For multicasting, it is assumed that only one receiver can be added or removed at any time. Transport resources for sending are initialized when tp createGrp() is in-

4.1. Feedback Channel cid grp cid res

= = = =

tp tp tp tp

QOS provisioning establish(QOS, EndPoint) createGrp(QOS) addLeaf(grp, EndPoint) release(cid | grp)

QOS control res = tp setQOS(cid | grp, QOS) res = tp notify(cid | grp, ¬if) Media transfer res = tp send(cid | grp, buf, len, attr) len = tp recv(cid, &buf, maxlen) Table 1. QOS-based transport API.

voked and end users are added to an existing group with tp addLeaf(). At last, a receiver joins a group by using tp establish(). The QOS for multicasting is the same for all members of the group. For that reason the QOS is specified during group provisioning and not when a member is added to the group. If a different QOS is needed, then another group needs to be created. However, the API can support multi-QOS per group; it suffices to add the leaf and then set the specific QOS using tp setQOS() with the leaf cid. Transport resources for both unicast and multicast are relased with tp release(). Finally, the QOS structure contains the service type, transport protocol and the QOS requirements (peak rate, delay, loss and gap loss) in the application terminology. The EndPoint structure contains the application endpoint identifier, e.g., VPI and VCI for ATM networks or IP address and port number for IP. The format of the data in the EndPoint structure is based on the selected transport protocol.

4. Transport Mechanism In this section we introduce the transport mechanisms for providing end-to-end QOS. The typical transport functionalities (flow and error control) are enlarged with fast time scale capabilities of QOS monitoring at the TPDU level and of service-based QOS adaptation. The monitoring of QOS is done at the receiving side. Upon QOS violation, a feedback message is sent to the sender. This end-to-end QOS feedback is a fundamental characteristic that distinguishes information transport from the other fast time scale control systems.

QOS monitoring and adaptation is a control operation. To adapt to fast time scale QOS fluctuations at the sending side, based on the measurements at the receiving side, a reliable, high speed feedback channel is required. Only low bandwidth control information is sent through this channel. For the case of duplex connections, inband signalling was a potential candidate for feedback; however, it requires the transport to demultiplex signalling information from the data. We decided not to follow this approach, at the cost of extra connection establishment overhead and resource utilization. Concerning multicast, all known feedback mechanisms are non-scalable, or seem to be so. To overcome the scalability problem of feedback in multicast, clever ways of sending back the information are required. This issue is addressed in Section 4.4.

4.2. QOS Monitoring By QOS monitoring we mean the set of mechanisms that are responsible for measuring the end-to-end QOS parameters. The measurements are performed in the transport layer on the receiving side of a connection; for example at the receivers of a video conference (before the data is delivered to the video display) or a web browser (since the data is transferred from the web server to the browser). The QOS parameters to be monitored are delays and losses. The monitoring has to be performed over a finite time interval called a measurement era. An important issue remains open at this time concerning the definition of a good measurement era. Should it depend on the traffic characteristics, the type of service and the traffic class? Should it be fixed or adaptive, jumping or sliding? etc. At the end of each era, if the QOS measurements show that the QOS is violated, a notification is sent via the feedback channel to the sender. The measurements may also be forwarded upon request of the adaptation mechanism. Optionally, on a slow time scale, the signalling can be asked for measurements. On the sending side, if required, sequence numbers and timestamps are put in the header of each or selected TPDUs. The mechanism to detect loss is contained in the sequence numbers. It is assumed that packets arrive in order. This is easily justified by the connection-oriented nature of ATM networks. It is assumed that a TPDU is lost (due to corruption or buffer overflow) if a sequence number is skipped. For delay, timestamps are used. Sender and receiver clocks are assumed to be synchronized. This can be easily achieved by the use of GPS hardware (global positioning system) that is becoming available at low cost. In the transport layer, the measurements are based on

TPDU delays and losses. For this reason, QOS parameter mapping into TPDU is also required. In particular, as the measurement era does, the TPDU length strongly affects the error rate as well as delay characteristics and is an important parameter to consider in the QOS monitoring and adaptation mechanisms.

gotiate its QOS requirements. Upon request of QOS renegotiation, the signalling subsystem replies with the currently available QOS and the application can accept or reject the new QOS or tear down the call if it is unsatisfied with the adaptation proposed by the signalling subsystem.

4.4. Multicast Connection 4.3. QOS Adaptation The role of QOS adaptation is to take remedial actions based on the measured QOS and the application QOS requirements. The QOS adaptation mechanisms are typically located on the sending side of a connection, but it is not excluded that they can be at receiving side (or elsewhere). As opposed to QOS monitoring mechanisms that reside in the transport, the QOS adaptation mechanisms can be associated with the transport, the application or the signalling system. Examples of mechanisms are flow control (in transport), MPEG-II coding rate adaptation (in the application) and QOS renegotiation (with signalling). For each type of service, an adaptation mechanism (or more) is proposed based on the type of QOS violation. When the QOS violations last for more than some pre-determined time period, the transport notifies the application. For example, for motion JPEG, if the loss rate is too high, the transport reduces the sending rate by discarding frames either at random or at regular intervals. If the losses were caused by buffer overflow, the net effect is a reduction of the congestion and therefore of frame loss. If the loss rate violation is sustained for more than a pre-determined time, the application is notified. When the application gets the QOS violation notification, it must reduce its graphic display size to maintain the frame rate or initiate a QOS renegotiation with the signalling entity. For MPEG-II video, when losses occur, the transport discards non important information (e.g., B or P frames) and sends important information twice (e.g., I frames). Alternatively, if hierachical coding is used [5], say by having a base layer (BL) and two enhancement layers (E1 and E2), then upon QOS violation, the lowest priority enhancement layer (E2) is not sent for a short time duration to let the network the chance to get back into a stable state. As in JPEG, if losses are sustained, the application is notified. For CD audio service, when the delay is too high, the number or samples per TPDU is reduced. This allows a smaller jitter but requires more transport and network resources. Again, the application is notified and it may decide to reduce the sampling rate of the number of bits per sample. For reliable data service, a filter estimates the available capacity for the connection [18]. Based on the estimated capacity, optimal flow control [9] is used to adjust the sending rate. In all case, when sustained QOS violations occur, the application is notified. The application can decide to rene-

For multicasting, we assume that cell copies are performed in the network, i.e., at the switching nodes. This is required because of the resource limitation at the source. The receiver’s mechanisms for QOS monitoring is the same as the one described above. However, the sender’s mechanism to receive multiple QOS measurements and to decide the appropriate action to be taken upon reception of a QOS violation notification remains to be worked out. Constant feedback from all the receivers impose a high feedback load at the sender when the number of receivers is large. Since our monitoring and measurement algorithm only replies when a QOS violation is detected or when the sender requested to do so, it reduces the feedback messages processing load required at the sender. A possible modification is to prohibit the receiver to send feedback at a higher rate than the one agreed upon at call establishment time. This means that fast QOS fluctuations are ignored if a return to the agreed requirements follows quickly. In this scenario, when a QOS violation message is sent, the receiver suspends the sending of further messages for a tolerable time, thereby reducing the feedback load for some acceptable time period and giving the sender the chance to adapt. For reliable multicast data communications, the flow control and error control mechanisms need to be modified even more and are still under investigation.

5. qStack Implementation Our implementation of the QOS architecture for transport, qStack, was originally based on a native mode ATM protocol stack [1]. The typical functionalities of the transport protocol (flow and error control) were enhanced with mechanisms to monitor QOS and to adapt the data stream to fluctuating QOS. Furthermore, services with QOS guarantees are currently offered. The Figure 6 illustrates the qStack implementation. There are three layers in the stack, application, transport and ATM adaptation layer. For signalling (resource allocation, connection setup, routing and some facilities for network QOS monitoring and renegotiation) we use xbind [13], a CORBA-based binding architecture. A service controller (an xbind subsystem) is responsible for interfacing the signalling with the application and the transport layers. The QOS-based API that we proposed in Section 3.2 is implemented at the interface between the transport and

5.2. Current Implementation tp_send (cid | grp, buf, len, attr) tp_recv (cid, &buf, maxlen)

Service Controller

xbind (signalling)

(a)

Application Transport AAL / ATM

(b)

tp_establish (QOS, EndPoint) tp_createGrp (QOS) tp_addLeaf (grp, EndPoint) tp_release(cid | grp) tp_setQOS (cid | grp, QOS) tp_notify (cid | grp, ¬if)

Figure 6. qStack implementation.

the service controller, and between the application and the service controller. The media transport API is defined at the interface between the application and the transport while the QOS control and QOS provisionning APIs are defined at the interface between the service controller and the transport.

5.1. Service Controller The service controller has two visible interfaces: one with the application (a) and one with the transport (b). It accepts requests from application and invokes the appropriate interfaces in the appropriate sequence. For example, when the controller receives a request to establish a connection from the application (through interface (a)), it maps the requested service QOS into COMET traffic class QOS parameters that xbind supports. It invokes the signalling subsystems to find an available route with the requested QOS, to allocate the requested resources, and to set up parameters at intermediate devices (e.g., links and switches) for scheduling and buffer management. If these steps have been carried out successfully, the service controller obtains the circuit identifier (VPI and VCI), initializes the transport protocol with the appropriate QOS provisioning call through interface (b) and gets back a connection identifier bound to the initialized transport resources. Finally, it passes back the connection identifier to the application that can use it for media transfer. The service controller also accepts requests and notifications from the transport. In particular, the transport can notify the controller of the QOS violation detected by the QOS monitoring mechanism, who in turn can notify the application. In summary, the service controller accepts interface primitives from application and transport. It translates interface dependent terminology and invokes appropriate interfaces with appropriate terminology in an appropriate sequence.

Currently the qStack implementation is working in user space. For scheduling between the application and the transport, pthreads are used (Chris Provenzano implementation of POSIX1003.4a Draft 8 pthread standard [16]). The ATM adaptation layer is provided by the FORE device driver. The service controller is part of xbind and is CORBAbased. The application and transport communicate with the service controller by message passing via IPC. The transport is in the form of a library statically linked. Full documentation and the binaries for xbind are available through WWW [7]. Applications (video conference system and ftp) based on this architecture are being developed. Furthermore, we are studying the QOS adaptation mechanisms required in a wireless ATM network [6].

6. Conclusion In this paper, we advanced an architecture that provides end-to-end QOS. Our framework to guarantee end-to-end QOS is based upon the concept of networking capacity graph and of networking capacity regions. These abstract resources with QOS guarantees. The design and implementation of qStack, the transport layer of a native ATM protocol stack and its embedding into xbind, were presented. Within this architecture, the typical transport functionalities were enlarged with QOS monitoring and adaptation mechanisms. A QOS-based API was proposed to shield application programmers from the complexity of QOS management and control. Both unicast and multicast connections supporting interactive multimedia applications were considered. In our architecture, mechanisms in any layers can communicate together for providing end-to-end QOS. This is realized in practice by signalling subsystems and orchestrated by the service controller. Our contributions consist in the identification of transport services and the implementation of mechanisms (QOS mapping, QOS monitoring, QOS adaptation and QOS-based API) needed in the transport protocol for guaranteeing endto-end QOS. For future work, we need to adapt the transport to wireless environments [6], design a feedback scheme for multicast that is scalable and derive equations (and mechanisms) for exact QOS mapping.

References [1] R. Ahuja, S. Keshav, and H. Saran. Design, implementation, and performance of a native mode ATM transport layer. In Proc. IEEE Infocom., San Francisco, CA, USA, Mar. 1996.

[2] C. Aurrecoechea, A. Campbell, and L. Hauw. A review of QoS architectures. In 4th International Workshop on Quality of Service, Mar. 1996. [3] A. Banerjea, D. Ferrari, B. A. Mah, M. Moran, D. C. Verma, and H. Zhang. The Tenet real-time protocol suite: Design, implementation and experiences. IEEE/ACM Trans. Networking, 4(1):1–10, Feb. 1996. [4] A. Campbell and G. Coulson. Experience with an adaptive multimedia transport system in a quality of service architecture. Technical report, Center for Telecommunications Research, Columbia University, New York, NY, Jan. 1996. [5] A. Campbell, A. Eleftheriadis, and C. Aurrecoechea. Endto-end QoS management of adaptive flows. In IEEE Symposium of Multimedia Communications and Video Coding, Oct. 1995. [6] A. T. Campbell. Towards end-to-end progarmmability for QoS controlled mobility in ATM networks and their wireless extensions. In Submitted to 3rd International Workshop on Mobile Multimedia Communications, Sept. 1996. [7] COMET Group. xbind: http://www.ctr.columbia.edu/comet/xbind/xbind.html. [8] J. M. Hyman, A. A. Lazar, and G. Pacifici. Real-time scheduling with quality of service constraints. IEEE J. Select. Areas Commun., 9(7), Sept. 1991. [9] A. A. Lazar. Optimal flow control of a class of queueing networks in equilibrium. IEEE Trans. Autom. Control, AC28(11):1001–1007, Nov. 1983. [10] A. A. Lazar. A real-time management, control and information transport architecture for broadband networks. In Proc. of the Int’l Zurich Sem. on Digital Commun., Zurich, Switzerland, Mar. 1992. [11] A. A. Lazar. Challenges in multimedia networking. In Proceedings of the International Hi-Tech Forum, Osaka ‘94, pages 24–33, Osaka, Japan, Feb. 1994. [12] A. A. Lazar, K.-S. Lim, and F. Marconcini. Binding model: Motivation and description. Technical Report 411–95–17, Center for Telecommunications Research, Columbia University, New York, NY, June 1996. [13] A. A. Lazar, K.-S. Lim, and F. Marconcini. Realizing a foundation for ATM interoperability with the binding architecture. IEEE J. Select. Areas Commun., 1996. Special Issue on Distributed Multimedia Systems, (to appear). [14] A. A. Lazar, L. H. Ngoh, and A. Sahai. Multimedia networking abstractions with quality of service guarantees. In Proceedings of the SPIE Conference on Multimedia Computing and Networking, San Jose, CA, Feb. 1995. [15] A. A. Lazar and G. Pacifici. Control of resources in broadband networks with quality of service guarantees. IEEE Communications Mag., 29(10):66–73, Oct. 1991. [16] C. Provenzano. Pthreads: http://www.mit.edu:8001/people/proven/pthreads.html. [17] M. Schwartz. Telecommunication Networks: Protocols, Modeling and Analysis. Addison-Wesley, Reading, Mass., 1987. [18] F. Vakil and A. A. Lazar. Flow control protocols for integrated networks with partially observed voice traffic. IEEE Trans. Autom. Control, AC-32(1), Jan. 1987.

[19] L. Zhang, B. Braden, S. Berson, S. Herzog, and S. Jamin. Resource ReSerVation Protocol (RSVP) – version 1 functional specification, Feb. 1996. Internet draft, expiration: Aug. 1996.