Subject: Re: [avtext] draft-begen-avtext-rams-scenarios-00 : comments

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sun, 1 May 2011 12:45:43 -0700

Hi Tom,

Thanks for the review. 

> -----Original Message-----
> From: Van Caenegem, Tom (Tom) [mailto:[email-masked]]
> Sent: Tuesday, April 19, 2011 12:11 PM
> To: [email-masked]
> Cc: Ali C. Begen (abegen)
> Subject: draft-begen-avtext-rams-scenarios-00 : comments
> 
> Hi Ali,
> 
> I read through the draft draft-begen-avtext-rams-scenarios-00.
> 
> -One general comment I have is that you mention multiple times "RAMS session", while "RAMS session" is not defined in the
> RAMS draft. Maybe it would be good to clarify this.

I am actually looking for a better term here. Any suggestions? Or yes, we will need to define it.
 
> E.g. in the Intro section, you say:
> "In
>    scenarios where multiple RAMS sessions will be simultaneously run by
>    an RTP receiver, they need to be coordinated."
> I suggest to say:
> 
> "In
>    scenarios where multiple RAMS sessions, each initiated with an individual RAMS-R message to a different feedback target
> FT-ap,
> will be simultaneously run by an RTP receiver, they need to be coordinated by the RTP receiver."
> 
> 
> -because the draft focuses on co-ordinated RAMS sessions/scenarios, maybe add this in the title of the draft?

Good idea.
 
> -I do not identify easily what are the guidelines this draft proposes (as mentioned in the intro/abstract). Is this about which
> multiplexing scenario is best in terms of combination with RAMS, in terms of flexibility ?.. Perhaps just stick to describing
> different scenarios, without mentioning guidelines?

Maybe, it was supposed to be more on the guidelines side. Any suggestions to improve the doc in that direction?
 
> These are more detailed comments:
> 
> Section introduction
> "However, the specification has mostly focused
>    on the simplest case, which is when the RTP receiver acquires only
>    one multicast stream at a time, to explain the protocol details."
> 
> I would rephrase this as follows:
> 
> The specification does not discuss scenarios where an RTP receiver makes use of RAMS to rapidly acquire multiple and
> associated multicast streams in parallel, or where different RTP sessions are part of the same SSM. E.g. the example section
> 8.3 in the specification addresses only the simple case of an RTP receiver rapidly acquiring only one multicast stream based
> on an SDP which describes a single SSM composed of a single RTP stream."

OK, some rewording is in order here.
 
> section 4.3 : see my comments for section 6.3.. I do not understand scenario 3
> 
> section 4.4:
> 
> "and the
>    retransmission and RAMS operations will not be able to be applied
>    based on the payload type"
> DELETE: "retransmission"  (..because retransmission is based on RTP SN.. no need to distinguish among PT?)

OK.
 
> section 5:
> "However, since this is not an easy requirement to satisfy,
>    RAMS specification forbids to have more than one RTP session to be
>    associated with a specific feedback target"
> 
> ADD: ..with a specific FB target on a specific port.

Better said "with a specific FTAp"  
 
> 
> section 6.1
> 
> "This is the preferred deployment model for FEC.  Having FEC in a
>    different multicast group provides flexibility for not only the RTP
>    receivers that are not FEC capable but also the ones that are FEC
>    capable but are not willing to receive FEC during the rapid
>    acquisition."
> 
> SUGGEST to DELETE:
> This is the preferred deployment model for FEC.

This is not much subjective AFAICT. Any strong reason why we should delete it? This is also what we "recommend" in FEC Framework.
 
> REPHRASE : Having FEC in a
>    different multicast group provides two flexibility points:  RTP
>    receivers that are not FEC capable can receive the primary video stream without FEC, and RTP receivers that are FEC
>    capable can decide to not receive FEC during the rapid
>    acquisition (but still join the FEC stream after RAMS for the primary video stream has finished).

OK. 
 
> "In this case, the RTP receiver can request a Max
>    Receive Bitrate of 22 Mbps in the RAMS Request message"
> 
> ADD: ..in the RAMS request message for the prmary video stream.

Good idea. 
 
> section 6.2:
> 
> "The
>    only difference from scenario #1 is that here the join time is the
>    same for both the primary video and FEC streams".
> 
> REPHRASE: .. is that here the join time is default the same for the primary video and FEC stream.
> 
> (editor note: also in  scenario 1 the join time can be the same)

I see you point. I will make this clearer. 
 
> section 6.3
> 
> "This is similar to scenario #2.  However, since we cannot explicitly
>    specify the bitrates for the primary and FEC streams, the RTP
>    receiver can request to rapidly acquire both streams in parallel.  In
>    this case, two separate RAMS Request messages have to be sent by the
>    RTP receiver to the feedback target."
> 
> 
> ..I am a bit confused here. Fact is that, following the RAMS specification, normally a single RAMS-R message is sent. If we

Right, a single RAMS-R asking for all SSRCs would work. When you indicate the max receive bitrate, individual streams will be accelerated relatively. If that is what one wants, it is fine.

> know the SSRCs of each stream, an RTP receiver can just request the primary video stream. However, a single RAMS-R does
> not allow to specify e.g. "max receive bit rate" per stream.. but I do not think this is desired anyhow, as it will be the source
> of the two sub streams that determine the relative bursting of the two streams.

So, looks like some revision is needed here. 

> If we do not know the SSRC values, we cannot request separately the SSRC streams using a single RAMS-R.
> ..but why do we need to send two separate RAMS-R messages... and how will you do that when there is only a single FT-ap?

Yeah, something is not worded accurately here.  I will try to make this clearer.

Thanks.
-acbegen