|
|
|
Figure 1: Static bandwidth allocation:
sources send at a fixed rate and apportion
the link bandwidth equally. |
|
|
|
Figure 2: Dynamic bandwidth allocation:
sources dynamically adjust their transmission rate in response to receiver
interest and apportion the link bandwidth accordingly. |
The basic premise of SCUBA is to reflect receiver interest back to the sources in a multicast session using a scalable control protocol. Figures 1 and 2 illustrate the core problem and its high-level solution. In current MBone sessions, bandwidth is allocated in a fixed fashion as shown in Figure 1. Each sender transmits at some fixed rate, where the rates are chosen either manually or through sender-based adaptation. In either case, an equal amount of bandwidth is typically allocated to each source. Clearly, this outcome is undesirable if the sources are not equally important across all the receivers. But, by integrating receiver feedback into the adaptation process, we can weight each source's transmission rate in proportion to receiver interest. This approach is illustrated in Figure 2, where receivers generate feedback that controls each source's sending rate. In this case, source S0 transmits at a higher rate than source S1 because more receivers express interest in receiving the flow. Likewise, because there is no interest in source S2, its transmission is disabled entirely.
However, in a large multicast session composed of heterogeneous receivers with different capabilities, configurations, and preferences, how can we determine a single bandwidth partition that simultaneously satisfies all receivers? As above, one receiver might deem a source S0 most important while another prefers source S1. In light of conflicting feedback like this, we adopt a simple solution: participants reach consensus through voting. If half of the receivers wish to view source A and half wish to view source B, then a reasonable policy is to partition the available session bandwidth equally across the two sources. Now the problem becomes how to poll the receivers, assess the vote, and convey the outcome to each individual source.
Unfortunately, receivers cannot immediately generate notification messages when there is a state change or event in the session that would cause a shift in focus since uncontrolled control traffic like this could cause large, transient traffic loads. Instead, we scale back the rate at which receivers vote based on the multicast session size, much as the RTP [20] control protocol, RTCP, adjusts the rate of its control messages to maintain a constant control traffic load independent of session size. However, a lower messaging rate increases the response time and circumvents our fundamental goal of supporting effective human-to-human interaction (i.e., because slow convergence will prevent users from shifting their focus on a natural human time scale).
To alleviate this problem, we model SCUBA on the ``exit poll'' principle. In a large vote we can very accurately and with high confidence predict the outcome from only a small (unbiased) sample of the population. In SCUBA, therefore, we derive the source bandwidth partition from a relatively small sample of the receiver population.
