Network Support for Scalable Distributed ... - Semantic Scholar

5 downloads 36376 Views 152KB Size Report
Apr 10, 1996 - Messages are sent with a sequence number plus a timestamp. .... The virtual world bulk load protocol could be based in a number of existing protocols for ..... SDAP. HTTP. SMTP. TCP. UDP. IP. Integrated Services Forwarding.
Network Support for Scalable Distributed Multiparty Virtual Reality Jon Crowcroft Mark Handley University College London 10 Apr 1996 Abstract This paper is about the design and implemenation of a protocol to support scalable distributed multiparty virtual reality systems. The paper covers the service requirements for the protocol, the range of protocol semantics, and the congestion avoidance scheme proposed for use with such systems. The goal is to show how multicast can be used in a variety of ways to construct a novel system that can admit very large numbers of simulataneous participants in an heterogeneous network.

1 Introduction Distributed VR is a relatively new area of research. Virtual reality systems are now largely software components, rather than requiring the dedicated head-up-display input controllers and renderer hardware of the past. Current high-end workstations can now render scenes described in VRML and other languages in near real time. The introduction of audio and video input and output on desktop machines led to the deployment of software based multimediaconferencing, we expect to see the deployment of multi-user virtual environments over the Internet shortly. In this paper, we present an architecture for distributed virtual reality. We outline the necessary network support and a transport protocol, and the way that distributed virtual reality applications would interact (the API if you like) with each other using these mechanisms. It is a goal of the architecture to provide policy free mechanisms for distributed VR application builders. It is not a goal to make it easy to program such applications, since it is all too easy in providing easy-toprogram distributed system tools that let the application builder overload the network, and at the same time provide suboptimal performance for the user. The architecture provides necessary and sucient hooks only for distributed VR.

2 Related Work Multicast routing is a mature area of research in the Internet. The system that we now call the \Mbone"[7] has its roots in the research by Cheriton and Deering where they developed the Internet multicast model, including the idea of host groups[1] and the basic service model for IP multicast[2]. It is now widely deployed in the network, and available in most common host operating systems and routers. 1

Some functions in a distributed system can best be performed in intermediate nodes or routers, whilst others can best be performed in end systems or hosts. The end to end principle[9] is used to select where to place a function. The principle is that a function that requires end system knowledge to carry out correctly should only exist in the end systems; where it appears in the network, it should only be as a performance enhancement. Two principles behind the design of high performance, low cost protocols that have proved themselves in this environment are Application Layer Framing (ALF) and Integrated Layer Processing (ILP)[6]. These state simply that: the unit of synchronisation and recovery should as far as possible be the same as the unit of communication (packet); and that where possible, modular functionality that is speci ed in layered form should not be implemented as such, and that new designs communications systems should factor this in so that processing associated with layered modules can be integrated in one pass. Combining these principles with the use of multicast for many-to-many communication, a number of further techniques have arisen for protocol design: 





Multicasting everything is a good idea. In applications with relatively high packet rates, the use of multicast for control information as well as for user data is not a high load, and can greatly simplify convergence of protocols for correctness, as well as performance and synchronisation. As error rates in modern networks have decreased, end to end recovery from packet loss or re-ordering has been seen to be a more optimal design than hop-by-hop recovery. As we move from one-to-one, through one-to-many and on to many-to-many applications, we can see that the same principle has to be changed. Neither the original sender nor the network can deal with the task of delivering packets in order, and senders cannot know when (or which) receivers are missing packets. It is not a good idea to use a positive-acknowledgement plus timeout-retransmission scheme for multicast applications because of the well known \implosion" problem (congestive collapse caused by multiple acknowledgements returning to the sender or senders)[13]. Scalable reliable multicast[4] is a technique that has seen wide deployment in LBL's whiteboard application (the so-called \wb"). Wb uses the principles above to provide a reliable delivery. The protocol and repair algorithm are brie y as follows (paraphrased from[14]): Messages are sent with a sequence number plus a timestamp. There are three basic types of messages: data messages, negative acknowledgements and heartbeat messages. All participants keep state for all other participants, which includes the following: 1. Source address, plus last seen in order sequence number 2. The estimated distance (delay) from this participant to each of the others. In addition, participants keep a number of the most recently received messages available.1 On detecting a missing packet from a gap in the sequence number space (between last received in order and newly received packet), a receiver prepares to send (multicast) a negative acknowledgement, which acts as a request for a repair from any other participant. However, the receiver defers from sending the negative acknowledgement for a time. This time is set so as to cause the set of potential participants sending a negative to (implicitly) conspire so that usually only one (or a small number) of them make the request. To do this, the timer is drawn from a uniform distribution over the range [c1*dsa, (c1+c2)*dsa], where c1 and c2 are constants and da is the requesting participant's estimate of the delay to the source. This time is subject to a binary exponential backo in the usual manner if there is no response. Participants that receive the request for repair, and wish to try and honour it also dally before sending the repair. Their hiatus is drawn from the distribution [d1*dab, (d1+d2)*dab], to ensure that it is likely that only one (or at least only a few) send the repair.

1 This may in fact be a feature of the way that the application is structured in any case. For example, if the application state is the same as the e ect of the sequence of messages (as is the case with a whiteboard), then it may be possible to cast a repair in terms of application state - i.e. to reconstruct a message that has the same e ect as the missing one.

2









Repair request messages suppress repair requests from other sites missing the same packet. Repair responses suppress other responses (as well as hopefully satisfying the request!). Finally, the delay estimation is based on the same algorithm used in NTP[15]. Heartbeat messages are sent by each participant carrying a list of other participants, together with the timestamp from the last message seen from each participant t1, and the di erence, d, t3-t2, between its arrival time, t2 and the heartbeat send time t3. On receiving a heartbeat message at t4, the delay can be estimated as (t4 - t1 - d)/2. This can be calculated using a rolling average, and the mean di erence kept for safety if required. (So long as paths are reasonably symmetric, and clock rates not too di erent, this gives suces for the repair algorithm above). Some applications require packets to have a particular inter-arrival rate. So long as the network can support the average rate (i.e. there is no long term congestion), \Receiver makes good" is generally a low cost solution to dealing with jitter or partial packet re-ordering. It is hard to provide a globally transmission clock in large heterogeneous networks. Essentially, if timestamped, and a receiver clock does not drift or wander w.r.t a sender clock too quickly, a receiver can run an adaptive playout bu er to restore the playout times of packets. The size of the playout bu er is essentially twice the inter-arrival variation, to ensure a signi cant percentage of packets arrive within the worst case time. A rolling average of the inter-arrival times (kept in any case if the algorithm described above is in use). If the mean delay varies (due to increased or decreased load on the network, or due to route changes) then quiet times can be used to make adjustments. Cheriton[10] describes a a scheme called log based receiver repair which was devised for distributed simulations in the DIS (the DSINet is an ARPA funded program of work whose target is the development of a suite of systems to support the Synthetic Theatre of War demonstration in 1997. from which much of this research stems). This is similar in spirit to the SRM approach, but has separate log servers rather than expecting all applications to participate in the repair algorithm. The upside of this is that a larger history may be kept (and for applications where the entire history is necessary to reconstruct current state, it may be too costly to distribute to all sites). The downside is that a distinguished server type needs a distinguished protocol to maintain replicant servers and so forth. Synchronisation of messages from di erent sources is generally a bad thing.[11] Open loop protocols such as the types we have described above (and many other heartbeat style protocols such as routing update and reachability protocols) are prone to synchronise send times. This can be avoided by careful selection of randomising timers based on unique participant data (own address is a good example). Multicast applications cannot use positive feedback for reliability. Nor can they use positive explicit feedback for congestion or ow control. Instead, implicit, and aggregated information may be more e ective. One scheme for congestion Control and multicast is described by Wakeman et al[5]. It is important to be exible. Depending on whether group communication can proceed at the speed of the slowest participant (or link to them) or the average, or be completely heterogeneous, we need di erent schemes for ow and congestion control. We can separate these also in to sender and receiver based adaption, and the next item refers to work in this area. In Wakeman's scheme, the sender elicits responses fro ma receiver set at a given distance by multicasting out a packet with a sliding key, which essentially acts as a selector key to choose some small percentage of recipients to act as samples to report on trac conditions seen at their point in the network w.r.t the sender. In the LBL work, this idea is generalized: Multicast receivers keep state about all senders. As with SRM, periodically, they send heartbeat messages, which contain this state (perhaps spreading the state over a set of heartbeat messages to keep the size of the updates small. This state can be used by senders to estimate the conditions at all points in the network. To keep heartbeat/session trac to a reasonable level, the rate of the beat is reduced in proportion to the number of participants. Although this means that the rate of samples from any given system is decreased for a larger group, the number of samples stays the same. In fact, as a group gets larger, it is statistically reasonable to assume that it is more evenly and widely distributed, and may give better and better samples concerning trac conditions throughout the multicast distribution fabric. 3





McCanne, on his work on multicast video, has looked at layered media encodings, and how they may be mapped onto multiple groups.[12] In this work, di erent levels of quality (or urgency, or interest) are sent to di erent group addresses. The number of levels, and amount that is sent in each can be adjusted using schemes such as the one described just before. However, receivers can independently adjust the rate of trac that arrives at them simply by joining (to increase) or leaving (to decrease) one of more groups, corresponding to the appropriate coding levels. Flow and Congestion Signal actions are generally the same for multicast applications as for unicast. The stable, and safe algorithm used in TCP since 1988[18], with a slow start cycle, a congestion control cycle with exponential backo and linear increase, and a fast retransmit cycle to avoid short lived congestion can be employed.

The rest of this paper is structured as follows: In the next section, we outline the structure of a distributed virtual reality system. After that we look at some of the real requirements from distributed VR, both from systems and the human perspective. Following that we present the transport protocol. Finally we look at further work that needs to be done.

3 General Idea and Problems Virtual Reality systems are really glori ed renderers combined with simulations, and some fancy display and pointer technology. The software components typically include the roughly what you would expect, as illustrated in gure 1. The performance requirements for distributing VR are surprising. Once a system is up and running, it transpires that objects are introduced/created and destroyed, with relatively low frequency. If a distributed VR system runs the collision detection and rendering at all receivers, it is only POV and object locations and attitudes that need updating. Here, though, there may be an extremely stringent latency requirement because of multiple interactions with other objects. We need three main components to a protocol to distribute this functionality: 1. A Virtual World bulk load protocol 2. An object naming system 3. An update protocol The virtual world bulk load protocol could be based in a number of existing protocols for large scale informationn dissemaintation. We assume that virtual worlds are potentially very large databases (although many VRML examples are not that large, we would anticipate this changing as time progresses and people develop a richer taste in virtual environments). However, it may be possible to use the update protocol that we are devising here too, if it is engineered for high throughput as well as low latency. The object naming system requires hierarchical naming and wildcarding, as well as a clean mapping from object to multicast group. Such a system has been devised in earlier work, and is partially implemented in the CCCP system[17]. The update protocol is what we will concentrate on here. Essentially, we propose an extension of SRM, together with the congestion avoidance mechanisms taken from Wakeman and McCanne's work. We propose basing the protocol on RTP, as is described in Parnes' work[14], since it is likely that eventually VR worlds may include media such as audio and video, and we see no reason to use a di erent packet header to support point of view and object motion, and new object upload. We propose that the constants of repair can be adjusted in favour of fast recovery rather than low numbers of repeated requests and repairs, since the load caused by this (given the size of repairs) is relatively small. 4

The sender application needs to specify the semantics of the operation, and this is conveyed in single eld in the protocol so that receivers can work out whether a repair request is relevant or whether a new update will overwrite the e ect anyhow.

4 Virtual Reality Operations, User Views and Networ Considerations For a distributerd multi-party application, there are a number of constraints which we might try to satisfy.    

Convergence, or does the interface show a system that reaches eventual consistency. Determinism, or does the system behave according to users' expectations of the underlying model. Multiple Modi ers - does the system allow more than a single user to modify an object (write/update state associated with an object). Interactivity - does the system let users lock an object so that they then have exclusive write/update access.

A key point in the design of the system is that when operating over a network with loss, reordering, and di erent levels of throughput/latency between di erent senders and recipients, it is clear that it is impossible to satisfy all four of these at any one time. It should be sucient to relax one of the constraints at one time, but it will dependent on a particular application and user requirements which, constraint is the appropriate one to relax. Network conditions that pertain to erach of these contraints are: 

  

Capacity - bits per second - may di er between a sender and a set of recipients - a distribution tree rooted at each sender will have paths to recipients, and di erent parts of the sub tree may have di erent capacity. Errors/Loss - packet loss may be due to noise on the line, transient outage, or temporary congestion. Again, in a multi-party application, this may be di erent for di erent receivers. Availability - networks can partition. Some senders or recipients may crash, or reboot at di erent times during a multi-party session. Delay - delays over long-haul networks2 , even without queues, can be signi cant. Again, they will usually di er from one recipient to the next.

4.1 Application Model Initially, we are making the big assumption here, that the model run at each site/host is the same, and that the only di erences are POVs and the user at each host. However, it is not necessary for all users at all sites to \see" all objects. In fact, real estate probably precludes this. This means that certain (large) optimisations are possible in terms of delivering operation/messages to each host. The set of typical operations between a VR application and the underlying system range from moving point of view to moving objects themselves and altering the attitudes. A more advanced approach, one could consider sending trajectories around, and having receivers apply the model world to the object. (eg. gravity, wind, friction, etc etc). 2

and is it really worth video conferencing with your next door neighbour?

5

Messages may be idempotent (describe an absolute position for an object, or position and velocity, and so on), or not (maybe they just say how far the object has moved). Interactions between users of a distributed VR application are complex. An object must in some senses have an "owner". This may be the user at a site (e.g. if the object is the POV itself, or the glove/pointer, etc), or an object currently under the control of a user. Thus we should associate a set of objects (and users) with a portion of the multicast address space - the idea is that a user is in some locale and that only operations relative to that locale need be delivered to their system. Furthermore, there most be some notion of \real" virtual world distance. The set of objects in VR in a locale that are \near" a user are subject to interactions which can reasonably be modelled without having to worry about propagation delay across the net. Beyond some distance, and the time to get a message fro mthe originator of the action to the hosts that a set of POVs that include this locale may simply be too high to consider. For example, imagine playing catch in a virtual world simulated between two machines on the net. The time for the ball to reach the ground is less than the time for the message to cross a terrestrial line more than a few thousand miles. However, it may be possible to introduce some element of representation of distance into the user interface - two approaches suggest themselves based on physics models of the real world: 1. Uncertainty - as an object gets further away, we can introduce less certainty about its position (note that the SRM protocol above gives us enough information to do this accurately!). 2. Relativity - we could warp spacetime in the virtual environment to produce a similar e ect to gravity - action at a distance could become much slower. Given this, di erent VR applications may need to relax a di erent one of the four constraints, possibly at di erent times. In fact, we can envisage single applications that need to relax di erent constraints for di erent objects at di erent times.

5 The Distributed Virtual Reality Multicast Protocol, DVRMP DVRMP runs on top of RTP[8] and UDP. All DVRMP messages are multicast. As in Parnes' proposal, we use RTP data packets as is, for data. If reliability is needed, the RTP PT eld is used to indicate SRM, otherwise it simply conveys normal data. 0

1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The SSRC is the source VR application. the CSRC can be used for input from speci c devices. We use RTCP as is for session quality reports, and respect the PARNES protocol for reliability: 6

SRM RTCP Packet:

0

1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|CM | Count | PT=SRM=205 | length | header +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Hearbeats (CM = 0) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence number | Not Used | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ NACKs/Repair Requests (CM = 1_ 0

1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence number | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Followed by 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC_1 |block1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Last time-stamp(LTQ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DLTQ | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_2 |block2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

More than one multicast group is used. Session messages are used within one multicast group to advertise the existence of participants and objects. Objects have owners. At any one time, the owner is the source of the session messages about an object. Messages can be marked as reliable or not reliable, however, this is not binding on recipients. Recipients can operate the repair algorithm on reliable object messages in the normal way. Other messages are deemed

7

ephemeral, and can be lost (or discarded) at will3.

6 Congestion A key question about reliable (and non-reliable, e.g. video/audio) multicast trac is that of congestion control. Unicast applications are typically subject to congestion avoidance or control schems such as the Van Jacobson/citevan:88 scheme in TCP, or more explicit mechanisms such as are employed by DECNET'S TP4 transport using the \congestion experienced" bit in the network level header to convey problems. A Native ATM stack might be designed to do something similar with the ABR service RM cell explicit rate indication. However, multicast cannot scale to even modest numbers of receivers with such schemes. Wakeman[19] proposed a mechanism for adaptive video sources. McCanne[12] proposes a receiver driven mechanism for layered coded video or other media. Virtual Reality sources (as with all such ALF style applications) should be at liberty to use the congestion signal, depending on the application. But the question is still one of, given a signal, what action should be taken? There are two places to consider: 1. Intra-tree congestion 2. Inter-tree congestion Given a distrution tree from a source, it is possible that one or more links on the tree may become congested. The descision must be made whether to accondate the slowest (lowest common denominator) link, or to split of levels of coding, or to compromise. A scheme should also be safe and stable. Both Wakeman and McCanne's schemes are applicable. Given multiple sources competing for a link that happens to be shared between two (or more) distribution trees, TCP is known to be appropximately fair (over time, and allowing for the dei erence in delay between a shared bottleneck and seperate sources), which could be normalized for. However, let's consider a distributon tree with N recipieients from two sources, S1 and S2. Now if S1 is a TCP source, it will generate Order N * ln(N) (actually log base degree of the tree, G) link's worth of trac, whilst the multicast source S2 would generate Order G*N. Should the multicast source get 1 mth share on the overloaded link, or 50%? Clearly, the latter is a more reasonable answer. Yet how to provide a feedback scheme that has this e ect? and further, how to devise such a scheme so that it is normalized to the receiver set size, and to the delays from source to bottleneck? All grist for future research!

7 Group Dynmamics VR needs low latency. It may have large nukbers of recipienets. Thios seems to imply some form of source based, dense mode, distribution tree. On the opther hand, the locus of interest may be both small, and sparse, and fast changing. This seems, by contrast to imply that a sparse mode tree is needed. 3 this limits the amount of storage necessary for receivers participating in a possible repair. It is derived fro mthe fact that there are many kinds of ways to send descriptions of object locations, velocity, trajectory. Some are coded so that loss of a single message makes it hard to recover, whilst others are largely simply lists of deltas, and recovery may be reasonably easy, whilst others are explicit coordinates, and only the latest message is relevant.

8

It is clear that more study us needed on Distributed VR using prototypes to see what exactly are the group dynamics that merge from typical applications. However, I think it is clear that we will need a hierarchical address space, with a two level allocation scheme, one level operating relatively slowly to form distribution trees, and the second i nthe manner of RSVP dynamic lters, to rapidly enable and disable paths to receivers as they wish to turn on and o the ow of data. This is not quite so ciritical as the \fast leavele" requirement for high resolution video, sonce the data rates are quite modest, but given the number of potneital sources, the aggregate data rate within the network could become large if we do not have ecient ways of suppressing unwanted feeds.

8 Prototype Code/Performance 9 Further Work Some performance analysis of the use of SRM for low latency repair is needed.

10 Acknowledgements Thanks for Mel Slater and folks at Division for discussions.

References [1] IGMP Steve Deering Multicast Routing in Internetworks and Extended LANs, ACM SIGCOMM 88, August 1988, pp 55-64 and Host Extensions for IP Multicasting, RFC 1112 [2] S.Deering and D.Cheriton. \Multicast routing in datagram internetworks and extended LANs." ACM Transactions on Computer Systems, pages 85{111, May 1990. [3] DVMRP RFC 1075 S. Deering, C. Partridge, D. Waitzman, "Distance Vector Multicast Routing Protocol", 11/01/1988. [4] S. Floyd, V. Jacobson, S. McCanne, C-G. Liu, L. Zhang, \A Reliable Multicast Framework for Lightweight Sessions and Application Level Framing", Proc ACM SIGCOMM 1995, Cambridge, Mass. [5] J. Bolot, I.Wakeman, T.Turletti, \Scalable feedback control for multicast video distribution in the Internet", Proc ACM SIGCOMM 1994, London,UK [6] D.D. Clark, D.L. Tennenhouse, \Architectural Considerations for a New Generation of Protocols", Proc ACM SIGCOMM 1990, Philadelphia, Pennsylvania [7] M.R. Macedonia, , D.P. Brutzman, \Mbone Provides Audio and Video Across the Internet", IEEE Computer, Vol.27 No.4, April 1994, pp. 30-36. [8] RTP H. Schulzrinne, S.Casner, R.Frederick and V.Jacobson RTP: A Transport Protocol for Real-Time Applications Internet Draft draft-ietf-avt-rtp-07.txt, Work In Progress, Late 1995. [9] E2E J.Saltzer, D.Reed, D.Clark \End-to-End Arguments in System Design" ACM Transactions on Computer Systems, 2, 4, pp 277-288 November 1984 [10] LOG H.Holbrook, S.Singhal and D.Cheriton \Log-Based Receiver-Reliable Multicast for Distributed Interactive Simulation" ACM SIGCOMM 1995 Vol 25, No. 4, pages 328-341 9

[11] SYNC \On the Synchronisation of Periodic Routing Messages" Proc ACM SIGCOMM, 93 San Francisco 1993. [12] RLM \Receiver-driven Layered Multicast", S. McCanne, V. Jacobson, and M. Vetterli, (Univ. of California, Berkeley and Lawrence Berkeley National Laboratory) ACM SIGCOMM, Stanford, Cal, August 1996 [13] MTP Crowcroft, J., Paliwoda, K, \A Multicast Transport Protocol" Proceedings of the ACM SIGCOMM 88 Symposium [14] RTPSRM Peter Parnes, LuTH/CDT \RTP extension for Scalable Reliable Multicast" draft-parnesavt-srm-00.txt, Work in Progress. [15] NTP David Mills, \Improved Algorithms for Synchronising Computer Network Clocks, Proceedings of SIGCOMM 94, London Vol 24, No. 4 pp 317-327 [16] VRML Those nice vrml people at SDSC [17] CCCP M.Handley, I. Wakeman, J.Crowcroft The Conference Control Channel Protocol Proc of ACM SIGCOMM 95 Vol 25, No. 4, pp 275-287 [18] TCP Van Jacobson Congestion Avoidance and Control Vol 18, No. 4, pages 314-329, ACM SIGCOMM 1988, Stanford, USA [19] WAKE Jean Bolot, Thierry Turletti, Ian Wakeman Scalable Feedback Control for Multicast Video Distribution in the Internet Vol 24, No. 4, pp 58-67 ACM SIGCOMM 1994, London 1994

10

VR Application

11 Figure 1: Virtual Reality Software Structure

Object Data Base (== Linda Tuple Space)

To POV/Collision Detection

Other Systems

Renderer

Distributed MM Control

RSVP

Audio

Session Directory

Video

DVRMP

SDP

RTP and RTCP

SDAP

UDP

HTTP

SMTP

TCP IP

Integrated Services Forwarding

Figure 2: The Distributed Virtual Reality Multicast Protocol Stack

12