Summary: Receiver-driven Layered Multicast

This paper describes a method of distributing content encoded with a layered
compression algorithm using multicast. The idea is that senders encode a
multimedia stream as (A, B, C). Clients wanting to see the lowest quality
stream just need A, those wanting the medium quality need A+B, and those
wanting full quality need A+B+C. Each component is broadcast on its own
multicast group. From the sender's perspective, the protocol is pretty much
ordinary IP Multicast.

The bulk of the logic in this system sits on in the receiver. The idea here
is that receivers will probe the network occasionally in order to determine
if there is free bandwidth. When extra bandwidth is available, they will
subscribe to the next optional channel, allowing the quality of the
presentation to increase. Similarly, when congestion is detected, receivers
will drop the highest channel, wait for the network to stabilize, and see if
this has corrected the congestion. While this would degrade the quality of
the multimedia stream, it would reduce stutters and other degradation brought
on by congestion.

Of course, this system wouldn't behave well if each receiver probed the
network independently, as under many network topologies this would result in
the bottleneck link frequently being overloaded. Therefore, the hosts send
out a multicast message when they begin a bandwidth probe experiment. This
way, they can learn from each other's "failed" bandwidth probes, and avoid
unnecessarily probing the link again.

Something that concerned me with this architecture was determining when you
should "pay attention" to an experiment-notification message, and when you
should not. For example, assume that you see someone on the other side of
the network is beginning an experiment, and then you notice that you begin to
experience congestion. Was this due to the other host's bandwidth probing
(in which case you should learn from it), or was it simply coincidence? Even
if these coincidents don't happen often, it would still be useful to prune
the experiment notification messages after a certain distance simply to avoid
unnecessary traffic.

Without knowledge of the topology it can be difficult to tell which which
hosts are worth watching carefully, and which aren't. However, the protocol
should not assume it can get topology data. Using simple rules like "listen
for bandwidth probes from all hosts with IPs on the same subnet" might be
sufficient, but it doesn't seem that the paper presented data one way or the
other.
Received on Tue Oct 31 2006 - 02:50:40 EST