An Extensible RTCP Control Framework for Large Multimedia Distributions


Julian Chesterfield and Eve M. Schooler
In Proceedings of NCA 2003



Summary:
This paper focuses on providing the ability for the Real-time Transport Protocol (RTCP) to scale as the number of receivers grows. Currently, RTCP does not effectively deal with shared bandwidth requirements that may be necessary for specific applications when they are reporting back to the source. As group membership grows, it is expected that receiver feedback reports scale down. In addition, the one-to-many interface proposed by such techniques as Source Specific Multicast (SSM) and satellite networks creates an asymmetric distribution infrastructure, causing bottlenecks on the routing architecture. In order to overcome these challenges, the authors propose two main scalable techniques as well as modifications to the RTCP framework while attempting to keep the same semantics of the original protocol:
  1. Instead of using multicast to provide feedback from receiver to source, use unicast (as in SSM).
  2. Have the source reflect feedback messages (such that group members can still communicate) via a unidirectional multicast.
  3. Instead of reflecting all feedback, create an aggregate summary, a term they call "summarisation." This will select the important information from feedback reports to reflect to all receivers.
  4. Deploy a hierarchical collection of summarisation nodes.
In general, a summarisation is a report packet which represents the distribution of feedback messages. Summarisation is implemented via a biasing step, whereby "important" feedback is retained to be reflected out on the unidirectional multicast. This distribution allows for significant factors of compression, as opposed to merely reflecting all receiver information. This compression, in turn, allows the bandwidth of the session to be allocated more for data transfers rather than control messages being relayed back and forth. To further show that compressing feedback messages for multicast is a good idea, they show that the bandwidth consumed for summarization as the group membership increases is orders of magnitude less than that for simple reflection. This allows applications that are dependent on a constant allocation of bandwidth to still function as group membership increases.
In order to further reduce bandwidth consumption, a hierarchical topology is proposed. Each node in this scheme will perform its own summarisation step before reporting back to a higher level node, with the source being the root of the hierarchy. Each summarisation node will then be responsible solely for its decedents, combining incoming summarisation reports and reporting the new further compressed summarisation report as necessary.

Critique:
While I believe this is a decent paper (these changes are under consideration by the IETF), I believe they have neglected a few points.
  1. They completely glossed over how to know create biased/unbiased groups. They say this is given information. The unbiased information is then to be broadcast to all receivers by placing the information into a summarisation report. The question remains, however, as to how to determine what is important. This may be application specific, but their claim that these modifications are scalable would leave me to believe that they cannot assume a specific target application. The biasing step is the key to their claim that summarisation reports will reduce bandwidth, and they assume that a distribution can be found that will encompass all necessary information. They specifically said that grouping receivers is "based on the prior accrual of receiver feedback data into a summary distribution and the subsequent choice of an interesting part or parts of the distribution from which to sample." How do you determine what's interesting? Can this be done dynamically? Is this a manual process? Is this application specific?
  2. After a list of important data is determined, the receivers are responsible for determining whether they have been biased or unbiased. The receivers need to know which group they belong to in order to determine what bandwidth they should operate at, or whether they need to report or not. Forcing this determination on the receiver seems like it complicates the system. Wouldn't it be easier for the source to tell the receiver what category it falls under? I could be wrong on this point. For this biasing scheme to work, this computation has to be done somewhere. I figure it would be easier to do it at the sender since it is already determining what is of interest and what is not.
  3. They only consider a single-source system. Are these same techniques applicable to multi-source application? They say most applications are single-source, so that is their focus. Does a multi-source system require different protocols and modifications?
  4. As was pointed out by Dr. Turner, more than half of Figure 3 is useless. A reporting interval of more than 10 seconds most likely will severely hamper performance for applications that use RTP. Even 10 seconds is probably too long.


Michael Attig