Re: [AVT] Review of draft-versteeg-avt-rapid-synchronization-for-rtp-02

[Ye-Kui Wang <yekuiwang at huawei.com>]

Hi Ali, Roni, 

Just to share my understanding of one point. 

> > > 8. In 6.4 "In the case RR starts receiving an RTP burst 
> but it does 
> > > not receive a corresponding RMS-I message  within a reasonable 
> > > amount of time, RR MAY either discard the burst data and stop the 
> > > burst by sending an RTCP BYE message to RS, or decide not to 
> > > interrupt the RTP burst and be prepared to join the primary 
> > > multicast session at an appropriate time it determines or 
> indicated 
> > > in a subsequent RMS-I message."
> > > 
> > > I think that since another RMS-I is not mandatory this will be a 
> > > good reason to have a rate adaption message from RR to RS 
> as defined 
> > > in
> > the Peilin
> > > draft.
> > 
> > Not sure if I follow.
> > 
> > Roni: my view is that a message from RR in the case when it gets an 
> > RTP flow without RMS-I will solve this state.
>  
> What type of message from RR?
>   

Independent of the use of RTCP BYE, I think that having a message, as
explained in the following, from the RR would be useful, and is
complementary to the design in
draft-versteeg-avt-rapid-synchronization-for-rtp-02.

The message simply contains a bitrate value, indicating a burst bitrate
desired by the RR. The RR may derive the value according to its buffer
fullness, its knowledge of the charateristics of incoming bitstreams, as
well as its knowledge of the underlying network situations. The RR may also
perform certain probing actions to get the status of the underlying network.
The RS may use this indicated value for sending the burst, or may adjust the
value according to the RS' knowledge to the charateristics of the bitstreams
to be sent out, as well as other information. In either case, the RS may
send an RMS-I to indicate the bit rate being used. 

This allows the analysis of a desired burst rate to be performed by 1) the
RS, 2) the RR, or 3) the RS and the RR in combination. Such a flexibility
would enable the RS to be scalable to the number of RRs it needs to serve.
When the number of RRs for one RS is small, the system can be configured to
let the RS have more RCTP receiver reports and hence more information for
analysis of a desired burst rate. When the number of RRs for one RS is big,
the system can be configured to let the RS have less RTCP receiver reports
but let the RRs to perform the analysis of a desired burst rate. At the same
time,  the computation burden to the RS for simultaneously analyzing desired
burst rates for all the invovlved RRs can be avoided. 

The process is more or less similar to the Reference Picture Selection
Indication (RPSI) message specified in RFC 4585. The analysis of a desired
reference picture to use may be performe either by the sender (according to
detailed RTCP receiver reports) or by the receiver (in this case detailed
RTCP receiver reports are not needed). 

BR, YK