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

[Magnus Westerlund <[e-mail]>]

Ali C. Begen (abegen) skrev 2010-01-20 12:24:
> 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 disagree, the reason is that you are sending traffic into a
multi-party context. You now you are sending RTCP packets to a multicast
feedback target. Thus you can not set the scheduling of the initial
packet using Tmin = zero. Section 3.5.1 in RFC 4585 does make it clear:

   Furthermore, the initialization of the RTCP variables as per [1]
   applies except for the initial value for Tmin.  For a point-to-point
   session, the initial Tmin is set to 0.  For a multiparty session,
   Tmin is initialized to 1.0 seconds.

> 
> 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.
> 

I agree that using a random initial timer do reduce the benefits of RAMS
somewhat. However, due to that there is clearly application reasons why
there can be synchronization of RAMS request there needs be analyses on
how bad this issue is. It might be easy to show that for the set of
reasonable parameters the Tmin can be set to zero, or to another smaller
value.

>> 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.

I think I mostly agree with you. The peak of the channel join events
will likely be a some seconds wide, and the initial join randomization
does this over a second wide. And from that point I think you are
correct that there is little benefit in the intial randomization.

However, I think you need to include motivation why it should be like
this. I now this goes into dimensioning, but the issue needs discussion.
> 
>> 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.

Answered in another email.

>  
>> 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 agree that it is unfortunate, but that doesn't allows to ignore if the
semantics are inappropriate.

>  
>> 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.

Fully agree!

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]
----------------------------------------------------------------------