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:-
- 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.
- 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.