The MICE Design of Conferencing Communications Channel

In this section, we will discuss some of the lessons that we have garnered from previous work involving computer based multimedia conferencing, and use these as a basis for developing an architecture for the next generation of conference control applications, suitable for conferencing over wide area networks. We show that a simple protocol acting over a conference specific communications channel, named the Conference Control Channel or CCC, will perform all tasks within the scope of conference control. The previous generation of conferencing tools, such as CAR, mmconf, etherphone and the Touring Machine ([#handley##1#], [#crowley##1#], [#schooler##1#], [#arango##1#]), were based on centralised architectures, where a central application on a central machine acted as the repository for all information relating to the conference. Although simple to understand and simple to implement, this model proved to have a number of disadvantages, the most important of which was the disregard for the failure modes arising from conferencing over the wide area. An alternative approach to the centralised model is the loosely coupled model promoted by Van Jacobson and exemplified by the vat[#casner##1#][#vat##1#] and wb[#vic##1#] applications. In the ``loose session model'', the network is regarded as inherently unreliable. Our observations of the Mbone show that humans can cope with a degree of inconsistency that arises from partitioned networks and lost messages, as long as the distributed state will tend to converge in time. This model makes less demands on the network, and recognises the possibility of failure modes up front. We have taken these and the other lessons we have derived from experience with conferencing tools, and derived two important aims that any conference control architecture should meet:-
  1. The conference architecture should be flexible enough so that any mode of operation of the conference can be used and any application can be brought into use. The architecture should impose the minimum constraints on how an application is designed and implemented.
  2. The architecture should be scalable, so that ``reasonable'' performance is achieved across conferences involving people in the same room, through to conferences spanning continents with different degrees of connectivity, and large numbers of participants. To support this aim, it is necessary explicitly to recognise the failure modes that can occur, and examine how they will affect the conference, and then attempt to design the architecture to minimise their impact.
We model a conference as composed of an (possibly unknown) number of people at geographically distributed sites, using a variety of applications. These applications can be at a single site, and have no communication with other applications or instantiations of the same application across multiple sites. If an application shares information across remote sites, we distinguish between the cases when the participating processes are tightly coupled - the application cannot run unless all processes are available and contactable - and when the participating processes are loosely coupled, in that the processes can run when some of the sites become unavailable. A tightly coupled application is considered to be a single instantiation spread over a number of sites, whilst loosely coupled and independent applications have a number of unique instantiations, although they possibly use the same application specific information (such as which multicast address to use...). The tasks of conference control break down in the following way:
  • <#1896#> Application control<#1896#> - Applications as defined above need to be started with the correct initial state, and the knowledge of their existence must be propagated across all participating sites. Control over the starting and stopping can either be local or remote.
  • <#1897#> Membership control<#1897#> - Who is currently in the conference and has access to what applications.
  • <#1898#> Floor management<#1898#> - Who or what has control over the input to particular applications.
  • <#1899#> Network management<#1899#> - Requests to set up and tear down media connections between end-points (no matter whether they be analogue through a video switch, a request to set up an atm virtual circuit, or using RSVP[#rsvp##1#] over the internet), and requests from the network to change bandwidth usage because of congestion.
  • <#1901#> Meta-conference management<#1901#> - How to initiate and finish conferences, how to advertise their availability, and how to invite people to join.
We maintain that the problem of meta-conference management is outside the bounds of the conference control architecture, and should be addressed using tools such as sd, traditional directory services or through external mechanisms such as email. The conference control system is intended to maintain consistency of state amongst the participants as far as is practical and not to address the social issues of how to bring people together, and co-ordinate initial information such as encryption keys. We then take these tasks as the basis for defining a set of simple protocols that work over a communication channel. We define a simple class hierarchy, with an application type as the parent class and subclasses of network manager, member and floor manager, and define generic protocols that are used to talk between these classes and the application class, and an inter-application announcement protocol. We derive the necessary characteristics of the protocol messages as reliable/unreliable and confirmed/unconfirmed (where `unconfirmed' indicates whether responses saying ``I heard you'' come back, rather than indications of reliability). It is easily seen that both tightly and loosely coupled models of conferencing can be encompassed if the communication channel is secure. We have abstracted a messaging channel, using a simple distributed inter-process communication system, providing confirmed/unconfirmed and reliable/unreliable semantics. The naming of sources and destinations is based upon application level naming, allowing wildcarding of fields such as instantiations (thus allowing messages to be sent to all instantiations of a particular type of application). Finally, we briefly describes the design of the high level components of the messaging channel (named variously the CCC or the triple-C). Mapping of the application level names to network level entities is performed using a distributed naming service, based upon multicast once again, and drawing upon the extensive experience already gained in the distributed operating systems field in designing highly available name services.