[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions(RAMS)" available
Hi
Some more comments below
Regards
/Ingemar
> -----Original Message-----
> From: Ali C. Begen (abegen) [mailto:abegen at cisco.com]
> Sent: den 25 april 2009 22:51
> To: Ingemar Johansson S; avt at ietf.org
> Cc: Bill Ver Steeg (versteb)
> Subject: RE: [AVT] New draft of "Rapid Acquisition of
> Multicast RTP Sessions(RAMS)" available
>
> > > 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.
My feeling here is that a multicast solution for RAMS would help to keep
the load on a lower level and thus will avoid that a RAMS request is
denied.
>
> > 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.
I don't have any public links to the other reports (sorry) but I would
guess that the results are approximately similar. I see however one risk
in trying to compute median and mean from data that may have a very
large standard deviation like one can suspect in cases like this where
the the behavior is very bursty.
>
> > > 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?
Possible, need to investigate this option closer.
>
> BR,
> -acbegen
>