next up previous contents
Next: Transport Protocols Up: Internetworking Multimedia Previous: Summary

Part II
Middleware

The advent of the Internet, with novel facilities such as multicast has led to the separation of the protocols used for conference media streams from the protocols used to setup and control various aspects of a conference, as mentioned above, such as membership, session information, media activity, floor control and so on, as we shall see i nthe next few chapters.

But the usefulness of the IP multicast service has made itself felt in the control protocols too. A number of sites have used multicast as the way to disseminate control information within a conference. Again, as with the media streams, the advantages in terms of scalability are manifold.

Alongside the multicast group used to carry the media themselves, another associated multicast group can be used to disseminate this control information. The model is that of a computer bus, on which messages can be placed, and received by any device attached to the backplane. This Bus Model is used in two related ways:

1.
The LBL tools [Jacobson, 94] use this as a local bus, to distribute information between applications at a given site to coordinate the control activities that are common. For example, if a user runs a video, audio and a whiteboard application, there is little point in each of these applications sending activity messages separately. They can be combined. Also, when a user is participating in multiple conferences, the coordination of ownership of devices such as exclusive use audio input and output can be carried out through messages on the local conference control bus.

2.
UCL researchers have carried this, and the basic wide area session message use of multicast to a general extreme, where the entire Mbone is used to coordinate all conference control messages using a conference control channel. This is illustrated below as the Multicast Control Bus.

The Local Bus can also be used to carry out receiver synchronization, If a machine is receiving different media streams with different delay variations that belong in the same session, then the adaptive playout buffer sizes can be exchanged by multicasting their status on the local Mbone (local to the receiver machine only), and used to add in a constant so that all streams are played out in synchronization, with no need for any complex end to end protocol to carry out complex delay bound calculations, as is used in many other systems.

The growth in the Mbone has led to some navigation difficulties (just as there are in the World Wide Web, and in Usenet News Groups). This has led to the creation of a Session Directory Service. This has several functions:

1.
A user creating a conference needs to choose a multicast address that is not in use. The session directory system has two ways of doing this: firstly, it allocates addresses using a pseudo-random strategy based on how widespread the conference is going to be according to the user, and where the creator is; secondly, it multicasts the session information out, and if it detects a clash from an existing session announcement, it changes its allocation. This is currently the main mechanism for the management of allocation and listing of dynamic multicast addresses.

2.
Users need to know what conferences there are on the Mbone, what multicast addresses they are using, and what media are in use on them. They can use the session directory messages to discover all of this. The latest versions of multicast include a facility for administrative scoping, which allows session creators to designate a logical region of interest outside of which traffic will not (necessarily) flow. This is mainly used to limit the network capacity used rather than as a privacy enhancement, since there is little guarantee that someone does not subvert the internet multicast routing anyhow, so it cannot give a guarantee of protection against accidental or deliberate disclosure. It can however protect cooperating users and sites from being overrun by irrelevant video and audio traffic.

3.
Furthermore, the session directory tools currently implemented will launch applications for the user.

Conference Control [Schooler, 92] refers to the set of tasks concerned with managing the tools that mediate between users. This includes controlling access and membership, controlling starting and stopping media including coordinating this with any floor control mechanism, reporting activity by a user of a given media type, and so on.

Early Conference control systems in the Internet were modeled around telephony and the T.120/T.GCC style of management, where each and every control action is specified for a unique participant, and each and every action is specified to each and every participant. Such systems were targeted at closed, secure, managed, and generally floor controlled (chaired) conferences. Often, the conference control architecture was dictated by the low level network call control model, or even by the media distribution technology (as with MCU based T.120 based videoconference systems).

The Mbone style of conferencing separates out this functionality, but in no way precludes using tight coupling of control actions, participants and media. Indeed, the use of the local and wide area bus model to propagate control actions leads naturally to efficient scaling of all styles of conference. Yet again, we note the user expectation is of potential dynamics in membership, and quality of conferences. This is an advantage over hardwired groups and quality, since it is less constraining to designers of conferencing tools. They can always add constraints later.

The use of a single approach that seemlesslessly scales from small to large systems, from homogeneous, to heterogeneous, and from one style of use to another, is clearly a desirable engineering goal.

In following chapters, we will look at these various technologies.


next up previous contents
Next: Transport Protocols Up: Internetworking Multimedia Previous: Summary
Jon CROWCROFT
1998-12-03