Re: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - multipleRAMS-R messages for the same unicast flow

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

> > This relates to the discussion about loss of RMS-I message during 
> > Bill's presentation in San Francisco. My understanding then 
> and also 
> > now is as follows. If during the burst, the burst bitrate 
> is changed 
> > by the RS due to whatever reason, and the RS has not sent 
> an RMS-I or 
> > the sent RMS-I was lost, it should not be a disater to the 
> client as 
> > it knows the its buffer status, and it can also know the 
> change of the 
> > burst bitrate and even the value of the changed burst bitrate if it 
> > wants. So why there is a problem here?
> >
> The client doesn't know if the burst is going to start or not,

The client knows that the burst started if burst packets are coming. Of
course the first RMS-I message is still important.

> or if the RS aborted the burst, or finished it. The 

Isn't that the RS only aborts the burst after receiving RMS-T or BYE
message? And no draft has mentioned using a message from RS to tell that it
will abort or finish the burst anyway. 

> client can't tell whether the RS failed to send an RAMS-I 
> because it lost the RAMS-R or because it thought it was 
> redundant - in a client/server protocol each request needs to 
> be replied to with a response for the state machines to clean 
> up correctly.

Agreed. 

BR, YK