Re: [AVT] RTCP message semantics for RAMS, was Discussion and Proposals for RAMS draft supporting the multi-SSRC SSM case

["Ali C. Begen (abegen)" <[e-mail]>]

Hi Magnus,

> -----Original Message-----
> From: Magnus Westerlund [mailto:[e-mail]]
> Sent: Tuesday, January 19, 2010 10:10 AM
> To: Ali C. Begen (abegen)
> Cc: VAN CAENEGEM Tom; [e-mail]; Bill Ver Steeg (versteb)
> Subject: RTCP message semantics for RAMS, was [AVT] Discussion and Proposals for RAMS
> draft supporting the multi-SSRC SSM case
> 
> Hi,
> 
> After reviewing both Ali's and Tom's respond I think I need to write an
> more extensive explanation of what I see as the problem with using the
> transport layer FB message for RAMS-R messages.
> 
> First of all I fully agree that using AVPF's timing model for sending
> RTCP messages is the appropriate function here. It is the message type
> and its semantic that I see as being an issue. Regarding the sending of
> RTCP messages, I interpreted Tom's message as disregarding any timing
> rules for the first RAMS-R message. As Colin Perkins commented on
> earlier that needs some motivation if that is going to be done.

My answer is simple. Since the client has not joined the SSM session or a unicast session yet, technically it may send its first feedback message (RAMS-R) right away. It does not know the size of the group, etc. so it cannot actually compute anything useful. It simply sends this message when it needs to, which is right at the beginning.

I am not sure what kind of motivation is needed here other than saying that the whole point behind the RAMS approach is to cut down the delays in acquiring the mcast streams.

> Disregarding the initial offset in cases where there can be flash crowds
> has potential issues. Note, that I am not saying that it is not

Does not matter if everybody delays their RAMS-R message by a margin. The time instances when say a million users send RAMS-R messages are independent from each other from our viewpoint. Yes, they are correlated (e.g., people do more zapping when it is the commercial time) which means the zappings are not totally independent, but even if everybody adds a delay before sending RAMS-R, it does not do any good to avoid the flash crowds. The point is that the session is not started until RAMS-R is sent and the server responds. So, initial offset rule does not apply.

> possible, and may be even appropriate, however as that will be going
> away from AVPF in that regards there should be motivation of that.
> 
> Back to the semantics of the RAMS-R. My view of the RAMS-R message is
> that it has the following semantics: I am X and can please anyone that
> listen in this session fulfill my request to provide a burst to join the
> SSM session that is related to this feedback target address?

I still don’t see how this is any different from a NACK message asking for bunch of missing packets (possibly from one or more RTP streams) since the client has not been listening to the mcast port(s) to receive the packets in the first place.
 
> That is quite different from the feedback semantics present in AVPF that
> I see as: I am X and I have the following feedback about the RTP stream
> from source Y. Or what CCM's request versions do: I am X and I would
> like source Y to comply to the following restrictions.
> 
> The above difference in semantics is why I propose that RAMS would
> better fit a new RTCP packet type. It could be a generic type for any
> feedback that fulfills the semantics. However, I think that would add a
> lot of delay. Thus I would propose a RAMS specific RTCP packet type that
> only deals with RAMS function. But being allowed to be following the
> same rules as feedback messages in AVPF.

I am still awaiting to see how we can *update* 4585 and whether it is worth it. It is unfortunate that 4585 has not foreseen the need for scenarios like RAMS. It could define its message formats in a better way. 
 
> I don't think this adds a lot of delay as you anyway needs to redefine
> some functionality around the fact that you need to take any RTP session
> into mind, rather than the specific case of sessions with a single MPEG
> TS stream in them.
>
> Yes, I think it is unfortunate that I come in at this late stage to find
> this significant issue in the spec. I much rather wished that all
> details was fine. I will do my best to help resolving these issues, like
> being responsive on email. But for cases where we do have disagreement
> we do need input from other people. That is why I asked for such.

So much is dependent on the timely publication of this draft. So, I'd urge that we agree on a solution soon.

Cheers, acbegen

 
> Cheers
> 
> Magnus Westerlund
> 
> IETF Transport Area Director
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------