Re: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions(RAMS)" available

["Ali C. Begen (abegen)" <abegen at cisco.com>]

> > I would not say it would be "fairly straighforward." To make 
> > the multicast bursting effective, many parameters need to be 
> > adjusted properly and optimized. Ow, it can easily degrade 
> > the performance even at the expense of additional complexity.
> > 
> > A concern I have which is not addressed in your document is 
> > that to make the proposal make sense, Td needs to be small 
> > enough. But, to ensure that all receivers join the burst 
> > mcast session before the burst starts, Td cannot be very 
> > small and RS should not admit last-minute RAMS requests for 
> > that multicast burst (they need to wait for the next batch). 
> > This is because if some receivers miss the first few packets 
> > of the burst, their acquisition will fail. Also, how many 
> > clients can the retransmission server aggregate in a single 
> > burst batch in a practical scenario? The eligible requests 
> > should be received within +/- a few hundereds of 
> > milliseconds. How practical is this, I wonder.
> The neat thing is that during low load conditions Td can be 
> made very low such that in practice only one user is served 
> by each request. This can be implemented with either unicast 
> or multicast bursts that only serve one STB. As he load 
> increases Td increases and more users that send a requests 
> will be served by one multicast channel. As Td is limited 
> some requests will be too late but they can too be collected 
> and served by additional multicast feeds. Then depending on 
> the distribuion the tail may be handled with unicast bursts. 
> This is more or less an optimization issue on the servers.

Agree.

> The idea is not that the unicast and multicast alternatives 
> should compete with one another, rather they should 
> complement each other, due to the highly dynamic nature of 
> channel switching behavior in a population both alternatives 
> are useful. I do believe that the multicast solution can help 
> to reduce deplyment cost. 

It can. However, remember that in a highly-loaded environment, if RS cannot provide (unicast) acceleration, it can deny the request. For the sake of doing multicast bursting (to save bandwidth), if RRs experience a slower acquisition (due to a large Td, for example) compared to a simple join, that is not good.

> I have tried to look for statistics on channel switching 
> behavior and of what I have seen sofar the "peak-to-average" 
> ratio of channel swithing density can be more than 5. This is 
> seen in a master thesis with the title "TPTV traffic 
> measuring & modeling" by Geng Yu (have not found it published 
> anywhere yet). 

I don't think I have that study, either. But, there is a recent study in IMC 2008. Here is the link.
http://portal.acm.org/ft_gateway.cfm?id=1452529&type=pdf&coll=portal&dl=ACM

The results are in general more or less similar to what we found in one of our own studies. The figure you will find interesting is Figure 14. 

For the most popular channel, the entire data set shows that on average 14 viewers tune into that channel per second (Figure 14a). Of course, there are occasions where a lot more viewers may tune at approximately the same time (within the same second), but this is for the top-ranked channel and the number 14 includes all viewers in the data set, which is about 250K (This is what I got from the text). If we consider only a subset of these viewers will be served by the same RS, the concurrency we will get in a single server will be far smaller, impying that multicast burst will not be needed most of the time.

Different studies may suggest different numbers based on the regional characteristics. So, I don't think we should read too much into this study. If there are other studies, please post them here. So, we can make a better judgment.

> > The selection of a common burst bitrate is also critical. If 
> > everybody supports a different burst bitrate and there is a 
> > large variation, multicast bursting will perform poorly for 
> > the well-connected clients. One solution could be to include 
> > the receivers with an available bw that is smaller than R1 
> > and larger than R2 in the multicast pool. The very fast and 
> > very slow receivers should be still served via unicast.
> Sounds reasonable.
> 
> > 
> > My personal view is that the multicast bursting proposal will 
> > be a nice solution when the issues above (and possible 
> > others) are addressed, however, I think it should be a 
> > separate draft that normatively references the unicast draft. 
> > This way, we can keep the unicast draft more focused.
> Not sure that I agree here, it all depends on how the 
> signaling is standardized. For instance an STB likely needs 
> to declare its unicast/multicast preference or capability in 
> the RAMS-R as the SDP's are likely only declarative. 

There can be a TLV in the request to do this, no? 

BR,
-acbegen