A common configuration for multimedia conferences entails one or more users participating across a slow, bottleneck link with the primary set of users participating across a higher performance ``well connected'' region of the network. For example, a user might tap into an MBone conference via ISDN or a high-speed modem; alternatively, multiple receivers might share a low-speed wireless link.
Media gateways [2] are one approach for managing network bandwidth in these environments. In this model, a gateway sits on the ``well-connected'' portion of the network and manages the bottleneck link by limiting the rate of incoming media streams through transcoding. In earlier work, we designed a gateway ``application programming interface'' (API) that enables fine-grained control of the rate of transmission on a per-source basis. We are now developing a comprehensive architecture for launching, configuring, and controlling gateways in arbitrary environments, including the constrained-link example mentioned above.
One of the difficult challenges in realizing our media gateway architecture was the design of the control protocol that runs between the low-bandwidth receivers and a gateway. The receivers must somehow interact with the gateway API to establish the bandwidth allocations across active sources. One obvious approach is to simply centralize the mechanism and force all network agents to rendezvous at a well known location. But this would introduce a central point of failure. A much better approach is to decentralize control through a distributed mechanism like SCUBA.
Integrating SCUBA with the media gateway architecture is relatively straightforward because each active transcoder embedded in the gateway can be modeled simply as a SCUBA source. From a receiver's point of view, there is no difference between a rate-controlled output on the original source or a rate-controlled output of a transcoder within a gateway. Therefore, we can run SCUBA locally among the receivers and the transcoders in the media gateways over a managed subset of the session. Again, the SCUBA protocol subsumes the functionality that would otherwise be implemented by a special-purpose protocol for managing the bandwidth of a locally-administered bottleneck link.
Figure 10 illustrates how SCUBA operates in tandem with a media gateway. Media streams from MBone sources S0, S1, and S2. are received by the gateway and are transcoded by per-source transcoders T0, T1, and T2. Each transcoder performs format and/or rate conversion on the input media stream and transmits the resulting output stream across the bottleneck link where it is received on the other side of the link by the receivers ( R0,...,R3). The original high-rate streams are not forwarded across the link.
By running SCUBA between the low bandwidth linked receivers and the gateway, scarce bottleneck bandwidth can be dynamically apportioned in an intelligent manner among the transcoders. In this way SCUBA provides a robust and distributed control mechanism for the gateway free from the vulnerabilities of centralized control.
