Multicast Requirements for Distributed Applications

A Multicast Datagram Network Service in Wide Area Networks is a relatively new technique based on forming host groups and enhancing routers to form special purpose forwarding information bases to these groups. This is mainly so that the number of copies of packets sent to replicated services may be reduced to near optimum in the same manner as on networks with a physical broadcast technology (e.g. Satellite and Ethernets). [#mospf##1#] [#dvmrp##1#] Multi-media conferencing is an application that often involves more than two end systems, and could take advantage of a multicast network service. However, multimedia systems often employ application level distribution. For instance, the voice portion of a conference is often sent by each participant to a central mixing service, which then sends the mixed portion to each member. To be optimally placed for each client, the mixing server may well be pessimally placed to use multicast to redistribute the mixed voice, compared with a forest of multicast trees rooted at each sender, or rooted at each destination group. With the video portion of a conference, it is often quad multiplexed by CODECs (video COder DECoder), in a similar manner to audio mixing, or else bandwidth requirements preclude anyone but the floor holder of a conference being visible. Clients of Replicated Databases distribute the same updates and retrieve the same records from more than one copy of the service and could also make use of a multicast network service. However, many transaction systems involve 2 or 3 phase commit protocols with each server in the replicated system for writing (although for reading, a majority read may suffice - however we need to know what the majority is). In this note we examine the snares and delusions that must be avoided when a multicast application uses a multicast network service. In particular, we distinguish between the savings of using a multicast system for data packet replication and the overheads in establishing and maintaining group membership and group reachability. In this case, there are two modes that could make use of multicast:
  1. A multicast ;SPM_quot;rwho;SPM_quot; that the conference service cache the result. We can also use this to find out the people we can conference with.
  2. Do a multicast to find out about the user when needed. Stations that has multimedia conference capabilities can then join the multicast group. Alternatively, only users that wants to be found will join the multicast group.
In the CAR experimental platform, shared applications can be either collaboration transparent or aware. Conference discovery can either use multicast to construct a conference finding service, or can use that as an optimisation between a real directory system and the application. All conference instance will be stored in the directory and local ones cache at the conference finding deamon. Conference finding request will always be sent out on a local multicast address. Local conference will then return using the cache result at the conference finding deamon. Non local conference then lookup the real directory using DAP (Directory Access Protocol). In the next section, we briefly examine a centralised architecture for multimedia collaboration. Then we study in turn the use of multicast support for shared windows, audio, video and shared applications.