From CSCW Applications to Multicast Routing: An ... - Semantic Scholar

1 downloads 14548 Views 236KB Size Report
networks" and discuss an aspect-oriented programming approach to the e cient description ... Keywords: Computer Supported Cooperative Work, multicast routing, ... conferencing, concurrent engineering, and interactive distance learning areĀ ...
From CSCW Applications to Multicast Routing: An Integrated QoS Architecture Ibrahim Matta Mohamed Eltoweissy Karl Lieberherr College of Computer Science Department of Computer Science College of Computer Science Northeastern University Central Connecticut State University Northeastern University Boston, MA 02115 New Britain, CT 06050 Boston, MA 02115 [email protected]

[email protected]

[email protected]

Technical Report NU-CCS-97-09

May 1997

Abstract

In a global economy, Computer Supported Cooperative Work (CSCW) has the potential of providing the environment needed for groups of diverse users to cooperate to achieve their common goals. This potential has been under-utilized. One major obstacle is the lack of cooperation between CSCW systems and the underlying network services to accomodate the dynamic behavior of most CSCW applications. Multicast routing presents a strong case where current network services are inadequate for the trac generated in CSCW environments. In this paper, we demonstrate the need for CSCW-speci c routing and present an integrated QoS architecture where a router QoS manager, on behalf of a multicast routing manager, negotiates with host and CSCW-speci c QoS managers for ecient resource utilization and guaranteed QoS delivery. The multicast routing manager switches between routing trees or algorithms as warranted by the changes in the characteristics and requirements of the CSCW systems running at the hosts. We show how our architecture ts within the framework of the new \active networks" and discuss an aspect-oriented programming approach to the ecient description and exible implementation of adaptive application and network protocol behavior.

Keywords: Computer Supported Cooperative Work, multicast routing, quality-of-service, protocol architecture, aspect-oriented programming.

I. Matta's work was partially supported by NU-RSDF 377090. K. Lieberherr's work is supported by DARPA and Rome Laboratory under agreement F30602-96-0239 and NSF under grant CCR-9402486 and a grant from Xerox PARC. 

1

1 Introduction In Computer Supported Cooperative Work (CSCW) environments, group members collaborate by sharing applications and data and exchanging messages to jointly accomplish their goals. Computer conferencing, concurrent engineering, and interactive distance learning are typical examples of CSCW environments [8, 6, 5]. Collaborative activities, by and large, are distributed in nature and thus rely heavily on the underlying network infrastructure. In CSCW environments, trac from one or more senders is targeted to a selected set of recipients with varying Quality-of-Service (QoS) delivery constraints. This requires the underlying network to provide multicasting and QoS capabilities for ecient CSCW support. CSCW research has traditionally focused on the design of shared environment applications assuming that the underlying network will provide the needed communication services. On the other hand, network researchers have focused on the development of general services that are not tailored to the needs of individual applications. The lack of a common framework that integrates CSCW and network research impedes the wide spread use of computer-supported collaboration. Our approach is to provide an integrated architecture where both CSCW applications and network control entities actively share information and mutually adapt to changes in the environment. In this paper, we focus on the important issue of multicast routing support for CSCW environments. Speci cally, our contributions are the following. 

We discuss the characteristics of CSCW environments that impact the underlying network, and identify their networking requirements.



We demonstrate the unsuitability of existing multicast routing services to CSCW trac.



We present a exible integrated architecture where the application and the network cooperate to achieve an ecient multicast routing support for CSCW trac.



We highlight several implementation issues showing the use of Aspect Oriented Programming (AOP) as a tool to conveniently and exibly implement adaptive behaviors of applications and protocols. 2

The paper is organized as follows. In Sections 2 and 3, we discuss the characteristics and networking requirements of CSCW environments. In Sections 4 and 5, we review and assess current multicast routing algorithms. In Section 6, we present our integrated architecture. In Section 7, we discuss implementation issues. We conclude in Section 8 with related and future work.

2 Characteristics of CSCW Environments CSCW systems have several characteristics that, taken together, distinguish them from other systems requiring networking support. In what follows we discuss the characteristics of groups, applications and data that impact the networking infrastructure.

Group characteristics 

Membership: a group may belong to the same organization or multiple organizations. It may have vertical or horizontal exible or rigid structures. It may be small or large in size. It may also be divided into subgroups with both intra and inter-group interactions. Group members may have di erent specializations and/or expertise. They may assume di erent roles as senders or recipients of data or both. Membership in a group may be constant, alternatively group members may join or leave dynamically.



Focus: on the one hand, a group may be involved in a single task utilizing one application, on the other hand, it may be involved in a number of tasks employing multiple applications.



Interactions: cooperation ranges from spontaneous brainstorming interactions that rely on the intention of the participant, to prescriptive tasks where interactions are fully speci ed by the system. Group communications may take place at the same time (synchronously) or at di erent times (asynchronously). Group members may be physically or virtually remote or co-located. Group activities may be short-lived or take place over an extended period of time. Senders and recipients kind and degree of awareness1 of one another vary with the purpose of interaction.

Awareness refers to the information pertaining to the participants, the groups they belong to and the access they have to the data. 1

3

Application characteristics 

Functionality: CSCW has a broad application base. Message systems, multi-user editors, group-decision support systems, computer conferencing and coordination systems are all different classes of CSCW systems.



Architecture: using a centralized architecture, usually chosen for ease of maintaining consistency and adding late comers, the output of an application is distributed to group participants from a central location. Replicated architectures, on the other hand, require extra e ort to maintain consistency, however, locally initiated requests are handled locally and only input or state-changing information are transmitted across the network.

Data characteristics CSCW environments encompass a wide range of media and rich data content. Data may be time-dependent (video, sound, audio, animations) or time-independent (text, graphics, images), each with di erent trac patterns (bursty versus continuous), reliability, bandwidth and quality requirements [16].

Discussion Most groups are dynamic in nature, they may toggle between interaction modes and employ more than one application simultaneously. The goal is that the dynamic behavior exhibited in CSCW environments should not be restricted by the underlying network, at the same time, CSCW environments must expend every e ort to adapt to the changes in the underlying network infrastructure. To take into account and exploit the di erent characteristics of CSCW environments, we must recognize the interplay between these characteristics and the underlying network infrastructure. The demands on the networking infrastructure varies with the variations in CSCW environments. For example, message systems which support asynchronous communication between groups of users, in general, generate less trac and do not require the same responsiveness as conferencing systems that provide synchronous multimedia interactions between users. When applications are implemented using replicated architectures, they typically require less network bandwidth than 4

those implemented using centralized architectures. Applications that are oriented towards small, often localized, groups do not usually require the same elaborate network services as those oriented towards large groups. The network must scale well to both kinds of applications. To address the various kinds and degrees of awareness requirements, the network must exibly maintain and provide users with knowledge about network reliability and reachability. When the rate of join/leave is high or when participants form a heterogeneous group each with his/her own networking demands or when participants frequently change roles between being senders and recipients, the communication structures built by the network services might need to be modi ed, sometimes even replaced. Moreover, multi-media trac calls for resource considerations due to the high aggregate data rate. Also, the interactive nature of most audio and video CSCW applications implies a call for provision of bounded end-to-end delays between senders and recipients. In addition, to avoid distracting users, bounding the delay jitter (variation)2 is strongly desirable.

3 Requirements of CSCW Environments As a result of the aforementioned characteristics, CSCW environments have their own networking support requirements. 

Bandwidth: for the support of possibly large volumes of multi-media trac.



Responsiveness: for synchrony, awareness and coupling3.



Reliability: for fault tolerance, quality of presentation and coupling.



Scalability and resiliency: for handling large groups and frequent changes in group membership.



QoS guarantees: for the delivery of negotiated service levels.

Delay jitter is the di erence between the minimum and maximum source to destination end-to-end delay. Coupling is the alignment of di erent participants' interfaces (for example, to achieve WYSIWIS (What-YouSee-Is-What-I-See)). 2

3

5

To satisfy these requirements, several performance and quality indices should be communicated between the CSCW system and the underlying network. These include: throughput, end-to-end delay, delay jitter, error rate, link/tree setting overhead (setup time, state storage requirements, etc.), and partition failures4.

4 Multicast Routing Current multicast routing protocols di er in the kind of trac they can support and QoS they can provide. The routing of multicast trac requires the construction of a tree or a group of trees, referred to as the multicast path. When a source sends a packet, this packet is forwarded along the multicast path replicating the packet only when the paths to di erent destinations diverge, thereby taking advantage of common path segments. There are many algorithms to construct multicast paths (e.g. [21, 14, 18, 12, 20, 2]). Some minimize replication and bandwidth cost, others minimize path length or end-to-end delay, while others try heuristically to achieve a balance between cost and delay. Typically, a multicast path can consist of Shortest Path Trees (SPTs), a single (shared) Steiner Minimal Tree (SMT), or some intermediate structure such as core-based trees. An SPT is rooted at a source, and its branches are the links leading to the destinations. The computation of an SPT is easy, and can be implemented eciently in a distributed fashion using the underlying unicast routing algorithm (e.g. DVMRP, MOSPF, PIM-dense [14, 18]). SPTs minimize path length or end-to-end delay and, in general, better distribute trac over the network. An SMT is a minimal cost tree spanning all sources and destinations. The computation of an SMT is NP-complete, and several heuristic (near-optimal) algorithms exist [12, 20]. They all require a separate algorithm to run in addition to the underlying unicast routing algorithm. In addition to minimizing replication and bandwidth cost, SMTs minimize routing state cost5 and, in general, delay jitter. By trading o cost and delay, a number of multicast path construction algorithms have been Partition failure is the partial unreachability between participants. With SPTs, a separate tree is maintained for each source and group. Whereas with SMTs, only one tree is maintained for each group. 4

5

6

proposed, for example, center-based multicast algorithms where a center-based tree uses an SPT rooted at a node in the center of the group [19]. Finding the optimum center is NP-complete, and a number of heuristic center placement strategies have been proposed, for example, Core-Based Trees (CBT) [2] and PIM-sparse [4] (also designed to quickly switch to source-based trees). Kompella et al. in [11] attempt to construct a shared tree subject to a given upper bound on end-to-end delay.

5 The Need for CSCW-Speci c Routing To e ectively support collaboration, we need multicast routing that adapts to the dynamics of the characteristics and requirements of CSCW environments. This adaptation could be triggered by a QoS manager signaling the routing subsystem on behalf of the CSCW system because of 1) mismatch between measured/observed QoS and required QoS; 2) hints from the system due to changes in semantics (i.e. group, application and data characteristics and requirements). Adaptation could also be initiated by the network itself in response to changing network load conditions. To illustrate the need for adaptation, we present scenarios showing several events triggering the adaptation.

5.1 Example Scenarios Consider a CSCW system with end-to-end delay requirement of 13 and delay jitter of 7 running on the simple 3-node network shown in Figure 1(a). Two senders S1 and S2 are located at nodes A and C respectively, and three receivers one at each node. With a shared tree (Figure 1(b)), maximum end-to-end delay is 20 and delay jitter is 10, which do not satisfy the system's delay requirements. With source-rooted trees (Figure 1(c)), however, maximum end-to-end delay is 10 and delay jitter is zero. In this case, the routing algorithm should construct source-rooted trees.

Changing link costs Now assume the link costs change as in Figure 2(a). In this case, with source-rooted trees (Figure 2(b)), maximum end-to-end delay is 10 and delay jitter is 7. If the cost of link (C; A) becomes 11, then maximum end-to-end delay increases to 11 and jitter increases to 8. This violates the system's jitter requirement, then the routing algorithm could switch to the shared tree shown in 7

R3 B 10 R3 S1 R1

B 10

A

S2 R2

C (b)

10 10

10 S1 R1

10 10

10

10

A

C

10

S2 R2

R3

R3

B

B

(a) 10

S1

10 10

A

C

A

R2

R1

C

S2

10 (c)

Figure 1: Example network. R3

R3

B

B 3

9

S1

R3

A

10

C

A

R2

R1

B

(b) 3

5 A

10 11

3

9

S1 R1

C

10 10 11

C

R3

S2 R2

B 9

(a)

3 5

S1 R1

3

A

C (c)

Figure 2: Changing link costs.

8

S2 R2

S2

Figure 2(c). In this case, maximum end-to-end delay is 12 and jitter is 5 (both are within the system's delay requirements).

Increased number of senders Consider again the situation in Figure 2(a). Now assume the user on node B starts sending in addition to receiving. With source-rooted trees, a tree rooted at B will be added but the maximum end-to-end delay and jitter remain at 10 and 7 respectively. Although the system's delay requirements are still met, the network might choose to switch to a shared tree (cf. Figure 2(c)) to reduce state information from 3 trees to only one.

Increased bandwidth requirements Suppose the system's bandwidth requirements increase so that the link costs change from what is shown in Figure 2(a) back to the situation in Figure 1(a). In this case, the shared routing tree changes from what is shown in Figure 2(c) to Figure 1(b) violating the system's delay requirements. The routing algorithm should then switch to source-rooted trees.

Changes in communication topology Figure 3 illustrates the e ect of communication topology. A source-rooted subtree could initially be used for communication within each group. Once this clustered communication turns to peerto-peer communication, this results in many nodes becoming both sender and receiver. The routing manager could then switch to a single shared tree to reduce state information overhead.

5.2 Remarks It is clear from the above scenarios, that the multicast routing behavior would depend on several factors. As the number of senders increases, state information overhead increases with sourcerooted trees, and construction of a shared tree would be more cost-e ective. As the number of receivers increases, a shared tree might be used to reduce delay jitter or source-rooted trees might be used to reduce end-to-end delay depending on the system's requested QoS. As the bandwidth 9

group 2

group 1

group leaders

Figure 3: Example communication topology. requirements increase, a shared tree might become overloaded, which may warrant a switch to source-rooted trees. With clustered communication, a hierarchy of trees for the various clusters could be constructed, where an appropriate tree type is used within each cluster. Other factors such as changes in network topology and trac pattern would clearly a ect the multicast routing behavior. For example, changes in the trac pattern could be the result of adding new applications to the ongoing group session, toggling between brainstorming and prespeci ed interactions, etc. A predictive scheme based on monitoring the rate of join could be used to do advance tree updates and thus reduce setup time. For example, for a real-time application with high join rate, Kompella's algorithm [11] augmented with prediction techniques may be utilized.

6 Integrated QoS Architecture Our design decisions are strongly in uenced by the desire to evolve an architecture that is scalable and exible, that o ers high performance, and that well supports multimedia and diverse group interactions.

6.1 Proposed Architecture Figure 4 shows our architecture. A CSCW application communicates its characteristics and requirements, such as its communication topology (peer-to-group, group-to-peer, etc.), delay, etc., to the CSCW QoS manager via a QoS Application Programming Interface (API). This CSCW QoS 10

manager understands application-speci c attributes, and maps them to application-independent attributes. These attributes are passed to the host QoS manager, which in turn maps them to lower-level attributes. The host QoS manager oversees and communicates with other components to make sure that the application's requirements are satis ed and that the network is aware of changes to those requirements. Peer QoS managers at the source and destination hosts may need to cooperate requesting the allocation of necessary resources from their operating systems and network subsystems. The host QoS manager communicates the requirements of the various applications to the router QoS manager, which is responsible for allocating necessary resources within the network by interacting with its peers. Host

CSCW application

CSCW application

CSCW QoS manager

Host

CSCW QoS manager

operating system host QoS manager

host QoS manager

network subsystem

Router

Router

router QoS manager

local route computation

router QoS manager

multicast routing manager

multicast routing manager

multicast routing protocol

multicast routing protocol

Figure 4: Integrated QoS Architecture. It is the job of the multicast routing managers at the routers to adapt their behavior in response to network load or requests from router QoS managers. A request coming from a router QoS manager can be the result of an application entity not satis ed because the observed/measured QoS is not matching the requested QoS, or an application expressing its desire to pin the delivered QoS. In the latter case, the current delivery path (on which resources may be reserved) is pinned 11

to maintain the QoS delivered. The multicast routing managers will then honor this pinning even when they adapt, unless a request for unpinning is later received. A dissatis ed application may also request the computation of an alternate path. In this case, the multicast routing manager invokes a route computation algorithm that locally updates the multicast tree as in [22].

6.2 Switching between Multicast Trees/Algorithms Our architecture supports multiple (parameterized) multicast routing protocols. This allows a multicast routing manager to exibly switch to a di erent multicast tree(s). This switching requires coordination between multicast managers, and a transitional period where the old tree(s) and new tree(s) both exist. During this transitional period, a dual cast approach could be used [1]. With this approach, the rst router getting a data packet and lying on both old and new trees needs to duplicate the packet and propagate it on each of the two trees. It will also mark the data packet to indicate whether it should be routed on the old tree or the new tree. Subsequent routers will forward the data packet on the correct tree based on its marking. This duplication provides reliability while the new tree is under construction, but requires a high-level mechanism that detects duplicates. After enough time expires, the old tree is deleted. Switching to a di erent multicast routing protocol requires an additional mechanism to secure its initiation at all routers. Our approach is to use a \broadcast-echo" mechanism that ensures that messages sent by the new routing daemon will be received by its peer daemon running on a neighbor router. This mechanism works as follows: a router initiates the switch by broadcasting a \switch" message to all neighbor routers, and enters a \switching" state. This process is repeated as the switch message travels. Each router receiving a switch message broadcasts it to all its neighbor routers except the sender to which it sends back an \echo" message. The router then enters the switching state. In a switching state, a router accepts and bu ers any new routing messages (corresponding to the new multicast routing algorithm). Once a router receives an echo message from each of its downstream neighbor routers, it leaves the switching state and starts processing the new routing messages that are bu ered. Note that receiving an echo message from each downstream neighbor means that all neighbors have been 12

noti ed of the switch and are now running the new routing daemon.

6.3 Active Network Architecture Our proposed integrated QoS architecture ts well within the framework of \active networks" [17, 3]. Active networking is a concept which seeks to make network behavior programmable by users. By embedding programmable elements in switches/routers, users can be given more control over how the network treats their data in the presence of congestion and how it can provide special services (e.g. video compression) that are inconvenient or expensive to provide in hosts. Active networks also allow individual users, or groups of users, to inject customized programs into the nodes of the network. A CSCW system can buy/reserve some bandwidth and processing resources from the network. The system can then inject its own multicast routing algorithm to be applied on its own packets. If the system is satis ed with the delivered QoS and could live with less, it can renegotiate with its QoS manager for less resources (and lower price).

7 Aspect Oriented Programming CSCW environments often involve multimedia applications which impose QoS delivery constraints on the hosts and network. Thus adaptive control protocols must be employed which eciently multiplex several applications while satisfying their requested QoS. Because we have two contradictory goals: ecient resource utilization and guaranteed QoS delivery, a solution that strikes a good balance between the two would provide so-called \soft guarantees". That is, the application should expect that the communication system will occasionally violate its promises. In this case, the application should adapt its behavior to accommodate the current QoS. The latter may be observed by the application itself or by the QoS manager and be communicated to the application. For example, an MPEG video application can adapt its compression strategy (e.g., ratio of I frames to P and B frames) based on currently delivered QoS. An application might also adapt because its own objectives change within the same session [10]. For example, an audio receiver could switch from an interactive mode to a seminar mode. In interactive mode, the receiver might be willing to tolerate slightly greater packet loss in exchange 13

for lower playout delays and better interactivity. While in a seminar mode, the receiver might not be concerned about delay and want to minimize packet loss in order to get the best possible reception. For applications to be able to express their QoS demands and adaptive behavior in an abstract, unambiguous and exible way, Aspect Oriented Programming (AOP) [7] could be used. An AOP application consists of several aspectual descriptions with one expressing the core behavior (using, for example, C++ or Java or a procedural language). The other aspectual descriptions deal with issues relevant to the application, for example, QoS, communication or synchronization. AOP has several roots, one of them is adaptive programming (AP) [13]. To illustrate, we show in Figure 5 a simpli ed QoS aspect language for a generic video application, which adapts its coding parameters based on currently delivered QoS. In this example, to make the application QoS-sensitive, we have added a QosAspectDescription object into the Receiver object. The meaning is that the QosComputation object in the QosAspectDescription will update the current QosProperty object, which will then update the CodingBehavior of the application according to the information in the selection table. The selected CodingBehavior will then be used by the application to do the encoding. The join points between the aspect description and the application behavior are the coding behavior names. This simple example illustrates the ease of maintenance when AOP is used to describe adaptive applications. To deal with QoS, we just have to add a QosAspectDescription object, implement the coding behaviors referenced in the selection table and use the selected CodingBehavior object in the application to do the appropriate coding in response to changing QoS. To change the coding selection mechanism, we only have to update some data: the selection table. AOP could similarly be used to obtain exible implementation of adaptive network protocol behavior. For example, a routing manager could periodically execute code that selects an appropriate routing behavior based on observed QoS.

14

// aspect classes QosAspectDescription = QosComputation QosProperty // initially unde ned, updated by QosComputation SelectionTable CodingBehavior. SelectionTable = List(Mapping). Mapping = "if" QosProperty "in" Range "then" BehaviorName. List(S)  fSg. // end aspect classes // application classes Application = Display Camera. Camera = Sender CodingBehavior. Display = Receiver. Sender = Frame Rate. Frame = SendingTime Info. Receiver = QosAspectDescription Sender. CodingBehavior : Coding1 j Coding2 *common* BehaviorName. Coding1 = . Coding2 = .

Figure 5: A simpli ed QoS aspect language for a generic adaptive video application.

8 Conclusions Motivated by the characteristics and requirements of CSCW environments, we presented a general integrated QoS architecture. In this architecture, applications and the network cooperate so as to strike a good balance between their contradicting goals: guaranteed QoS delivery and ecient resource utilization. This cooperation requires that applications be able to easily express important application-level information to the network, and the network be able to negotiate with applications 15

di erent levels of service which they can tolerate. For this purpose, QoS managers are introduced that understand the utility of the application's attributes through proper mapping, and allocate resources accordingly. In addition, a QoS manager will communicate to the application changes in the environment, negotiate with the network for network-level QoS on behalf of the application and coordinate with other QoS managers how to manage trac over the network. The design of e ective QoS management requires ecient resource allocation mechanisms. We focused on the multicast network routing support and showed how it must adapt to changes in CSCW environments. We next discuss related work and how it di ers from our work. Aggrawal et al. in [1] present an architecture where a near-optimal shared tree is constructed. The multicast routing algorithm accomodates dynamic group membership, and periodically recomputes the tree to restore its near optimality. The architecture does not address the need for multiple multicast algorithms or issues related to major characteristics and requirements of CSCW environments (for example, clustering, QoS requirements). Zappala et al. in [22] propose an architecture where the multicast tree is locally updated in response to a receiver-initiated request. This local route computation is readily supported in our architecture. Compared to [22], our architecture is more general and addresses CSCW characteristics and requirements such as group QoS requirements (e.g. delay jitter). Hall et al. in [9] present a middleware communication layer that provides tools for building CSCW applications. The paper does not address the interactions that should exist between the CSCW system and the underlying network. Nahrstedt et al. in [15] describe a QoS architecture and the required mappings from application-level requirements to system-level and network-level requirements. The paper does not address network control protocols, speci cally routing. We have advocated the use of AOP as the programming paradigm for our QoS architecture. Aspect oriented languages could be used to describe the attributes (aspects) of the applications and network protocols in a exible manner. Di erent aspects for QoS, communication, synchronization, etc., can be de ned in a loosely coupled way, allowing for ease of management and reusability. The aspect oriented approach is particularly useful for expressing attributes which adapt to network conditions. Zinky et al. in [23] apply an AOP style approach to QoS in a \Quality of Service for 16

CORBA Objects (QuO)" architecture. It presents a Contract Description Language (CDL) for de ning expected usage patterns and QoS requirements of an object. It also presents a Resource Description Language (RDL) that abstracts the physical resources used by an object, thus providing for exible binding to real devices at run-time. Both CDL and RDL can be viewed as aspect description languages. [23] only describes QoS support at the CORBA layer. It does not address issues related to network protocols. As future work, we plan to experiment with a simulation model implementing our architecture, and to study aspect oriented languages to develop adaptive robust code for CSCW applications and multicast routing protocols. We will also investigate the interactions between CSCW systems and other network services, for example, error and ow control.

Acknowledgments We would like to thank Ioannis Stavrakakis, Elias Manolakos and Boaz Patt-Shamir for valuable discussions and ideas.

References

[1] S. Aggrawal and S. Paul. A Flexible Protocol Architecture for Multi-Party Conferencing. In Proc. IEEE ICCCN, pages 81{91, 1996. [2] A. Ballardie, P. Francis, and J. Crowcroft. Core Based Trees. In Proc. SIGCOMM '93, San Francisco, California, September 1993. [3] S. Bhattacharjee, K. Calvert, and E. W. Zegura. On Active Networking and Congestion. GIT-CC-96-02, Georgia Institute of Technology, College of Computing, Atlanta, GA 30332, 1996. [4] S. Deering, D. Estrin, D. Farrinacci, V. Jacobson, C. Liu, and L. Wei. Protocol Independent Multicast (PIM): Protocol Speci cation. Internet Draft, 1995. [5] P. Dewan and J. Riedl. Toward Computer-Supported Concurrent Software Engineering. IEEE Computer, 26(1):12{15, January 1993. [6] C. Ellis, S. Gibbs, and G. Rein. Groupware: Some Issues and Experiences. Communications of the ACM, 34(1):38{58, January 1990. [7] G. Kiczales et al. http://www.parc.xerox.com/spl/projects/aop/position.html. [8] I. Grief, editor. Computer-Supported Cooperative Work: A Book of Readings. Morgan Kaufman Publishers, San Meteo, California, 1988. [9] R.W. Hall, A. Mathur, F. Jahanian, A. Prakash, and C. Rassmussen. Corona: A Communication Service for Scalable, Reliable Group Collaboration Systems. In Proc. ACM CSCW, pages 140{149, November 1996. [10] V. Jacobson. Multimedia Conferencing on the Internet. SIGCOMM '94 Tutorial, August 1994. [11] V.P. Kompella, J.C. Pasquale, and G.C. Polyzos. Multicast Routing for Multimedia Communication. IEEE/ACM Transactions on Networking, 1(3):286{292, June 1993.

17

[12] L. Kou, G. Markowsky, and L. Berman. A Fast Algorithm for Steiner Trees. Acta Informatica, 15:141{ 145, 1981. [13] K.J. Lieberherr. Adaptive Object-Oriented Software: The Demeter Method with Propagation Patterns. PWS Publishing Company, 1996. [14] J. Moy. Multicast Extensions to OSPF. Internet draft, Network Working Group, September 1992. [15] K. Nahrstedt and J.M. Smith. The QoS Broker. IEEE Multimedia, 2(1):53{67, Spring 1995. [16] J. Pasquale, G. Polyzos, G. Xylomenos, and V. Kompella. The Multimedia Multicasting problem. TR:CS93-313, University of California, San Diego, February 1996. [17] D.L. Tennenhouse, J.M. Smith, W.D. Sincoskie, D.J. Wetherall, and G.J. Minden. A Survey of Active Network Research. IEEE Communications Magazine, 35(1):80{86, January 1997. [18] D. Waitzman, C. Partridge, and S. Deering. Distance Vector Multicast Routing Protocol. Request for Comment RFC-1175, November 1988. [19] D.W. Wall. Mechanisms for Broadcast and Selective Broadcast. PhD thesis, Stanford University, Department of Computer Science, 1982. [20] B. Waxman. Routing of Multipoint Connections. IEEE J. Select. Areas Commun., SAC-6(9):1617{1622, December 1988. [21] L. Wei and D. Estrin. A Comparison of Multicast Trees and Algorithms, 1993. Draft manuscript. [22] D. Zappala, B. Braden, D. Estrin, and S. Shenker. Interdomain Multicast Routing Support for Integrated Services Networks. Internet Draft, March 1997. [23] J.A. Zinky, D.E. Bakken, and R.D. Schantz. Architectural Support for Quality of Service for CORBA Objects. Theory and Practice of Systems, 3(1), January 1997.

18