Subject: [AVT] Comments on draft-begen-avt-rams-scenarios-00

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sun, 8 Nov 2009 23:26:13 -0800

I would like to get the feeling of the WG on this draft and whether this draft should be considered and taken on as a WG item or not. If yes, for which intended status?

I am aware that if proper deployment models are adopted by the service providers, there is not much complication, but these "proper" deployment models need to be spelled out somewhere.

We omitted these details in the RAMS draft to focus on the core of the method and the SSM draft does not address all the concerns raised in this draft. So, my personal opinion is to take this work as an individual draft and publish it as informational, but I am open to suggestions.

Please share your comments.
-acbegen

---

From: Qin Wu <[email-masked]>
Date: Sat, 28 Nov 2009 17:42:19 +0800

Hi, Ali:
Read your scenario draft and do think there are some additional valuable scenarios which are not addressed in the RAMS draft.
please see my comments inline.

Regards!
-Qin

<snap>
draft-begen-avt-rams-scenarios-00 - Considerations for RAMS Scenarios 
<snap>
3.  Background

   In the following, we assume that there are two RTP streams (1 and 2)
   that are somehow associated with each other.  These could be audio
   and video elementary streams for the same TV channel, or they could
   be an MPEG2-TS stream and its Forward Error Correction (FEC) stream.

   It is important to note that a source-specific multicast (SSM)
   session is defined by its (distribution) source address and
   (destination) multicast group and there can be only one feedback
   target per SSM session [I-D.ietf-avt-rtcpssm].  So, if the RTP
   streams are distributed by different sources or over different
   multicast groups, they have to be in different SSM sessions.
   Different SSM sessions may share the same feedback target address
   and/or port.

   Different multicast RTP streams can be transmitted in the same RTP
   session (i.e., in a single UDP flow).  This is called SSRC
   multiplexing.  In this case, (de)multiplexing is done at the SSRC
   level.  Alternatively, different multicast RTP streams can be
   transmitted in different RTP sessions (i.e., in different UDP flows),
   which is called session multiplexing.  In practice, there are
   different deployment models for each multiplexing scheme.

   [Qin]:It is not clear to me how to understand "ssrc multiplexing" and "session multiplexing"? 
   how session is multiplexed when different multicast RTP streams is transmitted in different RTP session?
   and where is session multiplexed?
   how ssrc is multiplexed when different multicast RTP streams is transmitted in the same RTP session?
   where is ssrc multiplexed?
   would you like to clarify this?

<snap>

4.  Illustrative Scenarios

4.1.  Scenario #1
   [Qin]: The title of section 4.1 is not clear to me that what scenario it describes?
   May I suggest to change the title into 
  "
  4.1 Scenario #1: Two RTP streams transmitted over different multicast groups
  "

   This is the scenario for session multiplexing where RTP streams 1 and
   2 are transmitted over different multicast groups.  A practical use
   case is where the first and second SSM session carries the primary
   video stream and its associated FEC stream, respectively.

   We run an individual RAMS session for each RTP stream that we want to
   rapidly acquire.  These RAMS sessions MAY run in parallel. 

   [Qin]: Another case is to run single RAMS session for two RTP streams, e.g.,
   video stream and FEC stream,in this case both SSM sessions use the same transport
   address for their feedback target or they use the same feedback target.
   If it is the case, two RAMS sessions run in prallel is 
   not the only case for scenario #1, am I right?
   
   If they are, the RTP receiver needs to pay attention to using the shared
   bandwidth appropriately among different RAMS sessions.  Note that
   there may be different feedback targets for these two SSM sessions.
   If that is the case, RTP streams 1 and 2 may have the same SSRC
   value.  However, if both SSM sessions use the same transport address
   (IP address and port) for their feedback targets (as shown in the SDP
   below), the SSRCs of the RTP streams 1 and 2 MUST be different from
   each other to avoid any ambiguity in the RAMS requests.
   
   [Qin]: It seems to me, the scenario 1 includes two use cases:
   case 1: Two RTP streams have the same SSRC
   case 2: Two RTP streams have the different SSRC.
  but exmaple of SDP in the figure only covers case 2.
   therefore the description of section4.1 is not consistent with the description of the figure mentioned below.
   I suggest to divide the scenario #1 into two scenarios.

       a=group:FEC-XR RTP1 RTP2
        m=video 40000 RTP/AVP 96
        c=IN IP4 233.252.0.1/127
        a=rtcp:41001 IN IP4 192.0.2.1
        a=ssrc:1 cname:[email-masked]
        a=mid:RTP1
        m=application 40000 RTP/AVP 97
        c=IN IP4 233.252.0.2/127
        a=rtcp:41001 IN IP4 192.0.2.1
        a=ssrc:2 cname:[email-masked]
        a=mid:RTP2
   
   [Qin]: It seems to me, the above figure gives us one example SDP for RS, in this example two RTP streams comes from the 

  different Media Sender,may use the same Feedback Target. But in some cases, two RTP streams may come from the different Media 

  Sender and use the different Feedback Targets. Also it is not clear how scenario looks like.
   May I suggest to revise the SDP for RS as the following figure:
   "
                   +--------------------+
                   |Retransmission      |
                   |   Server           | RTP Stream2
                   |      +++++++++++++++++++++++++++++++++
                   |      +             | RTP Stream1     +
                   |   +--+-------------+-------------+   +
                   |   |  +             |             |   +
 +-------+         | +----++            |          +--V---V-+
 | Media |+++++++++> |Burst|      +---+ | RAMS1    |        |
 |Sender1|   +-----> |Src1 |------|FT1|<---------->|        |
 |       |---+--+  | +-----+      +---+ |          |        |
 +-------+   |  |  |                    |          | RTP_Rx |
 +-------+   |  |  | +-----+      +---+ | RAMS2    |        |
 | Media |---+  +--> |Burst|------|FT2|<---------->|        |
 |Sender2|+++++++++> |Src2 |      +---+ |          |        |
 +-------+         | +---+-+            |          +--A--A--+
                   +---+-+--------------+             |  +
-----> RTP Stream 1    +-+----------------------------+  +
+++++> RTP Stream 2      +++++++++++++++++++++++++++++++++

   "
In this figure we can see this case as combination of the following two cases:
"
case 1: Two RTP streams have the same SSRC
case 2: Two RTP streams have the different SSRC.
"
   
   Note that the destination ports in the above SDP do not matter, and
   they could be the same or different.
 [Qin]:One more scenario separated from Scenario #1 described in section 4.1 should be
 "
                  +--------------------+
                  |Retransmission      |
           RTP    |   Server           |
+-------+ Stream1 | +-----+            | RTP Stream1
| Media |---------->|Burst|------------+--------------+
|Sender1|         | |Src1 |     +-----+|  RAMS1   +---V----+
+-------+         | +-----+     | FT1 |<--------->|        |
                  |             +-----+           | RTP_Rx |
+-------+  RTP    |             +-----+|  RAMS2   |        |
| Media |Stream2  | +-----+     | FT2 |<--------->|        |
|Sender2|---------->|Burst|     +-----+           +---A----+
+-------+         | |Src2 +------------+--------------+
                  | +-----+            |RTP Stream2
                  +--------------------+

"
the SDP example for this additional scenario would be
"
        a=group:FEC-XR RTP1 RTP2
        m=video 40000 RTP/AVP 96
        c=IN IP4 233.252.0.1/127
        a=rtcp:41001 IN IP4 192.0.2.1
        a=ssrc:1 cname:[email-masked]
        a=mid:RTP1
        m=application 40000 RTP/AVP 97
        c=IN IP4 233.252.0.2/127
        a=rtcp:41001 IN IP4 192.0.2.2
        a=ssrc:2 cname:[email-masked]
        a=mid:RTP2
"

4.2.  Scenario #2
   [Qin]: The appropriate title would be
   "
   two RTP streams transmitted over the same multicast group with different destination ports
   "

   This is the scenario for session multiplexing where RTP streams 1 and
   2 are transmitted over the same multicast group with different
   destination ports.  A practical use case is where the SSM session
   carries the primary video and audio streams, each destined to a
   different port.

   Similar to scenario #1, we run individual RAMS sessions for each RTP
   stream that we want to rapidly acquire.  Compared to the previous
   scenario, the only difference is that in this case the join times for
   both streams need to be coordinated as they are on the same multicast
   session.

        m=video 40000 RTP/AVP 96
        c=IN IP4 233.252.0.1/127
        a=rtcp:41001 IN IP4 192.0.2.1
        a=ssrc:1 cname:[email-masked]
        a=mid:RTP1
        m=audio 40001 RTP/AVP 97
        c=IN IP4 233.252.0.1/127
        a=rtcp:41001 IN IP4 192.0.2.1
        a=ssrc:2 cname:[email-masked]
        a=mid:RTP2
   [Qin]: Not sure the meaning of "a=mid", suggest to provide reference for SDP sematics for "a=mid:"?
   [Qin]:It is not clear how to inteprete this SDP example for the scenario #2.
   My suggestion is to revise the SDP example in section 4.2 as follows:
   "
                  +--------------------+
                  |Retransmission      |
                  |   Server           |
                  |                    | RTP Stream1
                  |   +----------------+---------------+
          RTP     |   |                |               |
        Stream1:Port1----+       +---+ |  RAMS1   +----V---+
+-------+   |----->|     |-------|FT1|<---------->|        |
| Media |   |     ||Burst|       +---+ |          |        |
|Sender |---+     || Src |             |          | RTP_Rx |
+-------+   |     ||     |       +---+ |  RAMS2   |        |
            |----->|     |-------|FT2|<---------->|        |
          RTP     |+-----+       +---+ |          +----A---+
        Stream2:Port2 |                |               |
                  +---+----------------+ RTP Stream2   |
                      +--------------------------------|

   "
   Note that the destination ports in the above SDP MUST be distinct per
   [I-D.ietf-mmusic-rfc3388bis].

   If RTP streams 1 and 2 share the same distribution source, then there
   is only one SSM session, which means that there can be only one
   feedback target.  This requires RTP streams 1 and 2 to have their own
   unique SSRC values (as shown in the SDP above).  If RTP streams 1 and
   2 do not share the same distribution source, meaning that their
   respective SSM sessions may use different feedback target transport
   addresses, then their SSRC values do not have to be different from
   each other.

4.3.  Scenario #3
   [Qin]: The appropriate title would be
   "
   Two RTP streams transimittd over the same multicast group to the same destination port
   "
   
   This is the scenario for SSRC multiplexing where both RTP streams are
   transmitted over the same multicast group to the same destination
   port.  This is a less practical scenario but it could be used where
   the SSM session carries the primary video and audio streams, destined
   to the same port.

   Similar to scenario #2, we run individual RAMS sessions and the join
   time needs to be coordinated.  In this case, there is only one
   distribution source and the destination multicast address is shared.
   Thus, there is only one SSM session and one feedback target.

        m=video 40000 RTP/AVP 96 97
        c=IN IP4 233.252.0.1/127
        a=rtcp:41001 IN IP4 192.0.2.1
        a=ssrc:1 cname:[email-masked]
        a=ssrc:2 cname:[email-masked]
        a=mid:Channel1
   [Qin]:It is not clear in this SDP example, two RTP streams are using the same destination port.
   My suggestion is to revise the figure in section 4.3 as follows:
   "

                  +--------------------+
                  |Retransmission      |
                  |   Server           | RTP Stream1
                  |     ---------------+---------------+
                  |     |              |               |
          RTP     |     |              |               |
        Stream1:Port1+--+--+    +----+ |          +----V---+
+-------+   |------->|     |    |    | |          |        |
| Media |   |     |  |Burst|    |    | |   RAMS   |        |
|Sender |---+     |  | Src |    | FT |<---------->| RTP_Rx |
+-------+   |     |  |     |    |    | |          |        |
            |------->|     |    |    | |          |        |
          RTP     |  +-----+    +----+ |          +----A---+
        Stream2:Port1   |              |               |
                  +-----+--------------+               |
                        |                RTP Stream2   |
                        +------------------------------+

   "
4.4.  Scenario #4

   This is the scenario for payload-type multiplexing.
   [Qin]: The appropriate title would be
   "
   Payload-type multiplexing in one RTP stream for the same multicast group 
   "
   In this case, instead of two, we have only one RTP stream (and one
   RTP session) carrying both payload types (e.g., media payload and its
   FEC data).  While this scheme is permissible per [RFC3550], it has
   several drawbacks.  For example, RTP packets carrying different
   payload formats will share the same sequence numbering space, and the
   retransmission and RAMS operations will not be able to be applied
   based on the payload type.  For other drawbacks and details, see
   Section 5.2 of [RFC3550].

   [Qin]: From your analysis and conclusion, the scenario #4 is not recommended, right?
   My suggestion is to add the following figure in this section:
   "

                     +----------------+
                     |Retransmission  |    RTP Stream
                     |   Server       | (Media1,Media2)
                     |     +----------+------------------+
                     |     |          |                  |
            RTP      |  +--+--+ +----+|                  |
+-------+ Stream     |  |     | |    ||                  |
| Media |(Media1,Media2)|Burst| |    ||     RAMS      +--V---+
|Sender |----------->|  | Src | | FT || ------------->|RTP_Rx|
+-------+            |  |     | |    ||               +------+
                     |  |     | |    ||
                     |  +-----+ +----+|
                     +----------------+

   "
5.  Feedback Target and SSRC Signaling Issues

   The RAMS protocol uses the common packet format from [RFC4585], which
   has a field to signal the media source SSRC.  Thus, currently we
   require the RAMS Request messages to have this field properly filled.
   The SSRCs for the RTP streams can be signaled out-of-band in the SDP,
   or could be learned from the RTP packets once the transmission
   starts.
   [Qin]: Who learns SSRC for the RTP streams? RTP Receiver, right?

   In our scenario, the latter cannot be used.
   Signaling the media source SSRC value will help the feedback target
   correctly identify the RTP stream to be acquired.  If a feedback
   target is serving multiple SSM sessions on a particular port, all the
   RTP streams in these SSM sessions MUST have a unique SSRC value.
   Otherwise, the feedback target cannot discern the incoming RTCP
   feedback messages.

   If there are no provisions to assign unique SSRC values to the RTP
   streams in a deployment, the feedback target transport addresses MUST
   be assigned appropriately.  Unique feedback target addresses can be
   used without any issues if the deployment only covers scenario #1.
   Using unique feedback target transport addresses may or may not be
   sufficient in scenario #2.  In scenario #3, there is one feedback
   target.  Thus, SSRCs must be unique among the RTP streams that a
   particular feedback target (IP address and port) is responsible for.

6.    FEC during RAMS and Bandwidth Issues
   
   [Qin]: I am wondering whether Bandwidth feature is one part of FEC, if in that case,
   besides bandwidth, what other features should be considered for FEC during RAMS?
   
   Suppose that RTP stream 1 denotes the primary video stream that has a
   bitrate of 10 Mbps and RTP stream 2 denotes the FEC stream that has a
   bitrate of 1 Mbps.  Also assume that the RTP receiver knows that it
   can receive data at a maximum bitrate of 22 Mbps.  SDP can specify
   the bitrate ("b=" line in Kbps) of each media session (per "m="
   line).

6.1.  Scenario #1
   
   [Qin]: It is not clear to me how this scenario #1 described in section 6.1 is
   related to the scenario #1 described in section 4.1.
   In my understanding, section 6.1 is using the same scenario described in the section 4.1
   and focusing on how FEC and Bandwidth are considered in this scenario, right?
   If in that case, some explaination texts are required to clarify the relationship between
   scenario #1 described in section 6.1 and scneario #1 described in section4.1.

   This is the scenario for session multiplexing where RTP streams 1 and
   2 are transmitted over different multicast groups.

   This is the preferred deployment model for FEC.  Having FEC in a
   different multicast group provides flexibility for both RTP receivers
   that are not FEC capable or the ones that are not willing to receive
   FEC during the RAMS session.

        a=group:FEC-XR RTP1 RTP2
        m=video 40000 RTP/AVP 96
        c=IN IP4 233.252.0.1/127
        a=rtpmap:96 MP2T/90000
        b=TIAS:10000
        a=mid:RTP1
        m=application 40000 RTP/AVP 97
        c=IN IP4 233.252.0.2/127
        a=rtpmap:97 1d-interleaved-parityfec/90000
        b=TIAS:1000
        a=mid:RTP2

   If the RTP receiver does not want to receive FEC until the
   acquisition of the primary video stream is completed, the total
   available bandwidth can be used for faster acquisition of the primary
   video stream.  In this case, the RTP receiver may request a Max
   Receive Bitrate of 22 Mbps in the RAMS Request message.  Once RAMS
   has been completed, the RTP receiver MAY join the FEC multicast
   session, if desired.

   If the RTP receiver wants to rapidly acquire both primary and FEC
   streams, it needs to allocate the total bandwidth among the two RAMS
   sessions and indicate individual Max Receive Bitrate values in each
   respective RAMS Request message.  Since less bandwidth will be used
   to acquire the primary video stream, the acquisition of the primary
   video session will take a longer time on the average.

   While the RTP receiver can update the Max Receive Bitrate values
   during the course of the RAMS session, this approach is more error-
   prone due to the possibility of losing the update messages.

6.2.  Scenario #2

   This is the scenario for session multiplexing where RTP streams 1 and
   2 are transmitted over the same multicast group with different
   destination ports.

        a=group:FEC-XR RTP1 RTP2
        m=video 40000 RTP/AVP 96
        c=IN IP4 233.252.0.1/127
        a=rtpmap:96 MP2T/90000
        b=TIAS:10000
        a=mid:RTP1
        m=application 40001 RTP/AVP 97
        c=IN IP4 233.252.0.1/127
        a=rtpmap:97 1d-interleaved-parityfec/90000
        b=TIAS:1000
        a=mid:RTP2

   Similar to scenario #1, the RTP receiver can first ask for RAMS for
   the primary video stream at the full receive bitrate.  But, upon the
   multicast join, the available bandwidth for the burst drops to 11
   Mbps instead of 12 Mbps. 
  
  [Qin]:How does bandwidth 12 Mbps comes from? 22 Mbps?

   Regardless of whether FEC is desired or not
   by the RTP receiver, its bitrate needs to be taken into account once
   the RTP receiver joins the multicast.

   If the RTP receiver wants to rapidly acquire both primary and FEC
   streams, the same conditions explained for scenario #1 apply.  The
   only difference from scenario #1 is that here the join time is the
   same for both the primary video and FEC streams.

6.3.  Scenario #3

   This is the scenario for SSRC multiplexing where both RTP streams are
   transmitted over the same multicast group to the same destination
   port.

        m=video 40000 RTP/AVP 96 97
        c=IN IP4 233.252.0.1/127
        a=rtpmap:96 MP2T/90000
        a=rtpmap:97 1d-interleaved-parityfec/90000
        b=TIAS:11000
        a=mid:Channel1

   This is similar to scenario #2.  However, since we cannot explicitly
   specify the bitrates for the primary and FEC streams, the RTP
   receiver may 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.

   Note that based on the "a=fmtp" line for the FEC stream, 

   [Qin]: It seems "a=fmtp" is not depicted in the above example of section 6.3?
   not sure where  "a=fmtp"  come from, suggest to provide reference such as RFC2327.

   it may be
   possible to infer the bitrate of this FEC stream and set the Max
   Receive Bitrate value accordingly.

<snap>
----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[email-masked]>
To: <[email-masked]>
Sent: Monday, November 09, 2009 3:26 PM
Subject: [AVT] Comments on draft-begen-avt-rams-scenarios-00

> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt