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

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Tue, 19 Apr 2011 18:10:43 +0200

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

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

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

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

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

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

 
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)

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