Subject: [AVT] the use of "media sender SSRC" in draft-ietf-avt-rapid-acquisition-for-rtp-05

From: "Michael Lague (mlague)" <[email-masked]>
Date: Tue, 1 Dec 2009 17:30:13 -0600

I have some concerns regarding the requirements expressed in
draft-ietf-avt-rapid-acquisition-for-rtp-05 for the specification of the
"media sender SSRC" in out-of-band media descriptions.

The following text is included in the Introduction of
draft-ietf-avt-rapid-acquisition-for-rtp-05:

   ...It is also worth noting that in order to issue
   the initial RTCP message to the feedback target, the SSRC of the
   session to be joined must be known prior to any packet reception, and
   hence, needs to be signaled out-of-band (or otherwise communicated to
   the RTP receiver in advance of the initiation of the rapid
   acquisition operation).  In a Session Description Protocol (SDP)
   description, the SSRC MUST be signaled through the 'ssrc' attribute
   [I-D.ietf-avt-rtcpssm].

Similarly, Section 6.2 of the draft states (in item 1.):

       Before joining the primary multicast session, a new joining
       RTP_Rx learns the addresses associated with the new multicast
       session (addresses for the multicast source, group and
       retransmission server) by out-of-band means.  Also note that
       since no RTP packets have been received yet for this session, the
       SSRC must be obtained out-of-band.  See Section 8 for details.

And again, Section 8.2 of the draft states:

   When an RTP receiver requires rapid acquisition for a new multicast
   session it wants to join, it sends an RAMS-R message to the feedback
   target of that primary multicast session.  This feedback message has
   to have the SSRC of the primary multicast stream for which rapid
   acquisition is requested for.  However, since this RTP receiver has
   not received any RTP packets from the primary multicast session yet,
   the RTP receiver MUST learn the SSRC value from the 'ssrc' attribute
   of the media description [I-D.ietf-avt-rtcpssm].  In addition to the
   SSRC value, the 'cname' source attribute MUST also be present in the
   SDP description [RFC5576].

However, I would like to observe that 1) in many deployments, the system
hosting the Multicast Source is distinct from the system hosting the
Retransmission Server (as shown in Figure 1 of the draft); 2) existing
systems which provide a Multicast Source may not have the means to
provision SSRC values, but instead may generate random SSRC values, as
indicated in RFC 3550; 3) such systems often regenerate a new SSRC value
for a media stream, when the system restarts; and 4) in redundancy
schemes for such systems, if a backup component takes over for a failing
primary component, the SSRC values for the media streams may change. 

Thus in such deployments it may not be possible to provide accurate SSRC
values for media streams in the SDP descriptions provided out-of-band to
receiving clients. 

But it should also be noted that if feedback target transport addresses
are provisioned for the Retransmission Server in such a way that each
transport address uniquely identifies one and only one RTP stream, then
a receiving client need not have prior knowledge of the SSRC value for
the stream, in order to request its rapid acquisition.

Therefore I would like to request a change in the wording of the draft,
to provide for the possibility of requesting rapid acquisition of a
stream without prior knowledge of the its SSRC, in those cases where the
SSRC is not needed to uniquely identify the stream.

For example, the excerpt from the Introduction might be replaced with:

   ...It is also worth noting that in deployments where each feedback
target
   transport address may be associated with more than one RTP stream, 
   the SSRC of the session to be joined must be specified in the initial

   RTCP message to the feedback target prior to any packet reception,
and
   hence, needs to be signaled out-of-band (or otherwise communicated to
   the RTP receiver in advance of the initiation of the rapid
   acquisition operation).  In a Session Description Protocol (SDP)
   description, the SSRC MUST be signaled through the 'ssrc' attribute
   [I-D.ietf-avt-rtcpssm].

Similarly, the excerpt in section 6.2 might be replaced with:

       Before joining the primary multicast session, a new joining
       RTP_Rx learns the addresses associated with the new multicast
       session (addresses for the multicast source, group and
       retransmission server) by out-of-band means.  In deployments
       where each feedback target transport address does not uniquely
       identify a single RTP stream, the SSRC for the stream to be 
       acquired must also be obtained out-of-band, since no RTP packets 
       have been received yet for this session. See Section 8 for
details.

To clarify the message flow, the following might paragraph might be
inserted in item 2. of section 6.2., between the second and third
paragraphs:

    In deployments where each feedback target transport address of the
RS
    uniquely identifies a single RTP stream, the RS MAY ignore the media
    sender SSRC of the RAMS-R request, and may instead use the SSRC of
the
    RTP stream associated with the feedback target transport address on 
    which the request was received. In such deployments the 'ssrc'
attribute
    MAY be omitted from the media description which is conveyed
out-of-band
    to RTP receivers. However, if the transport address alone does not
uniquely
    identify a single RTP stream, and the media sender SSRC in the
request
    does not match any of the associated streams, then the RS must
ignore 
    the request.

And finally, the excerpt in Section 8.2 might be replaced with:

   When an RTP receiver requires rapid acquisition for a new multicast
   session it wants to join, it sends an RAMS-R message to the feedback
   target of that primary multicast session.  In deployments where each
   feedback target transport address is associated with only one RTP
stream,
   the RTP receiver does not need to learn the SSRC of the stream via an
   out-of-band method, and MAY specify zero for the media sender SSRC
(although
   zero is a valid SSRC value). In all other cases, the RAMS-R feedback
message 
   has to have the SSRC of the primary multicast stream for which rapid
   acquisition is requested.  However, since this RTP receiver has not 
   yet received any RTP packets from the primary multicast session, the
   RTP receiver MUST in this case learn the SSRC value from the 'ssrc' 
   Attribute of the media description [I-D.ietf-avt-rtcpssm].  In
addition 
   to the SSRC value, the 'cname' source attribute MUST also be present 
   in the SDP description [RFC5576].

--Mike Lague
  ([email-masked])

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 11 Dec 2009 17:30:05 +0100

Hi Everyone,

After having read this thread and the discussion with Ali around my
comments I have some conclusions and suggestions.

To me it appears the fundamental issue around the whole SSRC is the
scope of how RAMS has been presented. The design is for catching up on a
single media stream within an RTP session. I believe that is
fundamentally flawed.

If an RTP receiver wants to join an ongoing RTP session it shouldn't be
required to know about the SSRCs of the sources active in the session.
It should simply ask the local server to bring me up to speed quickest
possible. As there appear to be some confusion what is meant with an RTP
session, I would clarify here that I refer to what is normally delivered
on a single multicast address to specific ports (one for RTP, one for
RTCP). See my other email for additional discussion around the RTP
session in the context of RAMS for more in-depth discussion of this.

I am very interested if any can identified a use-case around SSM where
you wouldn't like to join all the RTP streams within an RTP session, if
there actually was multiple SSRC used for transmitting? If you had ASM,
then I agree that this might be somewhat different. However, from the
point of an receiver that hasn't started listening on a session, it has
no knowledge about which flows it needs to get going in the session.

Thus I think the reasonable approach for the semantics of a RAMS request
would be:

- I want to join the following channel: Identified by the target address
I send the request to.
- I want all relevant RTP flows for this RTP session.
- I also want all the relevant RTCP state that I need to join the session.

My interpretation is that using the Feedback RTCP packet type is
actually wrong in this context. I think RAMS should use another RTCP
packet type so it isn't required to include a SSRC for which flow the
request relate to. Because in my view it isn't related to a flow at all.

I know this is a very serious change to the RAMS protocol. However, to
me it appears that we will have long term issues with the current
semantics.

I guess this hasn't been well considered due to that the first target
for using RAMS has been RTP transported MPEG-2 TS where there are only a
single RTP stream and SSRC in a singular RTP session for each individual
multimedia presentation (TV channel). If you consider this from the
perspective of a more versatile usage of the RTP sessions to deliver
multimedia presentations over SSM then you find the issues.

Regards

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 11 Dec 2009 13:08:57 -0800

Hi Magnus,

I understand your concerns. Let's see if we can agree on the text.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
> Sent: Friday, December 11, 2009 11:30 AM
> To: Michael Lague (mlague)
> Cc: Rob Drisko (rdrisko); [email-masked]
> Subject: Re: [AVT] the use of "media sender SSRC" indraft-ietf-avt-rapid-acquisition-for-
> rtp-05
> 
> Hi Everyone,
> 

Just a side note, the primary application area for RAMS is acquiring MPEG2 transport streams. In almost all cases, an MPEG2-TS stream will be a single RTP stream (with video, audio, etc.). So, the SSM multicast session will be carrying a single RTP stream most of the time. But, of course, we cannot limit ourselves to this scenario.

There can be multiple RTP streams in a single SSM session. If they are going to different ports, we can define different FTAp's for each of them (per the RTCPSSM draft). So, running multiple RAMS bursts independently (or in parallel) is certainly possible. This provides flexibility. 

The client might be naïve. Yet it can certainly infer which streams are in the same SSM group (so are correlated to each other one way or another) from the SDP description. We wanna keep RAMS per RTP stream (instead of doing it per the group of all RTP streams in the same SSM group) because not always the receiver will be interested in rapidly acquiring all of the streams. If resources are limited, there won't be much point in asking for multiple bursts at the same time anyway.

For example, if I have one audio and one video stream multicast in the same SSM group. I might wanna accelerate only the video stream if my resources are limited. I can certainly run two RAMS bursts (audio and video) in parallel (but independent) if I have enough bandwidth.

> required to know about the SSRCs of the sources active in the session.

I agree. So, that's keeping a separate FTAp for each RTP stream makes a lot of sense. This way it does not need to know the SSRCs but it needs to know which streams it will need.

> session in the context of RAMS for more in-depth discussion of this.

The case I believe you want us to address is when there SSRC-multiplexed RTP streams in the same SSM group. If each such RTP stream goes to a different port, what I wrote above should work just fine. If there are multiple RTP streams going to the same port, then, yes, the approach I wrote above will require the receiver to know the SSRCs since there will be one FTAp serving for multiple SSRCs.

I understand you want to make the client not worry about the SSRCs, but I strongly believe that the flexibility in our current approach is a better trade-off.
 
> there actually was multiple SSRC used for transmitting? If you had ASM,

Requesting RAMS for a stream and receiving it upon join are totally different things. There may be streams in an SSM group that I want to receive upon join but maybe I don’t wanna do rapid acquisition for. I gave you an example above (video+audio). Another example, some deployments combine the FEC stream in the same SSM session. Why would you wanna do RAMS for an FEC stream?

> - I want all relevant RTP flows for this RTP session.

See above.

> - I also want all the relevant RTCP state that I need to join the session.

RTCP reports will eventually be sent from the distribution source upon join.
 
> me it appears that we will have long term issues with the current

I disagree. We need to clearly identify in the text why we are doing it this way as opposed to other ways. If you prefer, we may say why it is not a good idea to include the FEC stream with the source stream in the same SSM session and how it complicates things.
 
> multimedia presentations over SSM then you find the issues.

:) I prepared the draft-begen-avt-rams-scenarios draft a long time ago but other open issues had a higher priority. 

Thanks and cheers, acbegen.

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 14 Dec 2009 14:44:33 +0100

Hi,

Thanks for the rapid response.

Ali, I think we have certain degree of terminology issues here. Let me
try to explain my interpretation of the terminology.

RTP stream: The RTP packets related to a single SSRC in a single RTP
session.

RTP session: Related to a single media, like audio or video. For SSM
delivered to a single multicast address + port.

The Multimedia session: The collection of all RTP sessions needed to
form a multi-media presentation (interpreting presentation in the widest
sense).

Based on that I think

> There can be multiple RTP streams in a single SSM session. If they are going to different ports, we can define different FTAp's for each of them (per the RTCPSSM draft). So, running multiple RAMS b…

Well, if they are going to different ports, they are different RTP
sessions, like one RTP session for video, one for audio and one for
subtitles.

> The client might be naïve. Yet it can certainly infer which streams are in the same SSM group (so are correlated to each other one way or another) from the SDP description. We wanna keep RAMS per R…

Yes, I agree that the client is reasonably naive. It knows that it needs
to join a Multi-media session, it does that by joining the relevant RTP
sessions. That way cases like different language tracks or subtitles may
not all be joined. Thus I think the right level of choice is the RTP
session.

> For example, if I have one audio and one video stream multicast in the same SSM group. I might wanna accelerate only the video stream if my resources are limited. I can certainly run two RAMS burst…

The issue I have with requesting different RAMS burst for different
SSRCs in the same session is that the server knows how much bandwidth
there are in each etc. But, the RTP_Rx has no knowledge about this.

> I agree. So, that's keeping a separate FTAp for each RTP stream makes a lot of sense. This way it does not need to know the SSRCs but it needs to know which streams it will need.

Good, that we agree on this. However, how are you going to address the
multiple SSRCs in the same RTP session case?

> I understand you want to make the client not worry about the SSRCs, but I strongly believe that the flexibility in our current approach is a better trade-off.

Yes, can't there be a way to explicitly indicate that the request is for
all SSRC's within the RTP session?  I think that would be the default.
I wished you kept the 24 bits after the SFMT for flags related to the
message. But I guess a TLV would do just as well.

> Requesting RAMS for a stream and receiving it upon join are totally different things. There may be streams in an SSM group that I want to receive upon join but maybe I don’t wanna do rapid acquisit…

As I have clarified we have a terminology issue, so I think we are in
agreement about separating audio and video to the application logic.
Although I think in most cases you still want to have both. But I see
them as two different RTP sessions and thus not an issue requiring more
discussion. I think that is valid also for the FEC case. Including the
FEC in the same RTP session as the source is commonly not done, although
it might be sent over the same SSM session.

I would note that using RAMS also for the FEC does make sense in cases
where you don't use NACK. As you may still have packet losses in the
burst that needs to be compensated for. Thus I do expect FEC to be
bursted also.

> RTCP reports will eventually be sent from the distribution source upon join.

Well, that is a bit late if you have playback starting prior to joining
the SSM group.

> I disagree. We need to clearly identify in the text why we are doing it this way as opposed to other ways. If you prefer, we may say why it is not a good idea to include the FEC stream with the sou…

I agree with further clarifications. However, as I haven't seen the text
and may not totally have grasped the solution for how to request without
knowing the SSRC.

As I see it there are a need to able to request a burst that allows you
to join the RTP session on the SSM for all the important streams that
are present in that session. Even if you know about which streams are
present, the RTP_Rx lacks information on how to divide its bit-rate
between multiple sources in the RTP session as that is dynamic information.

Thus I see a problem with the current structure of the RAMS message.
Yes, I think I can see some point with requesting one or some SSRCs,
however, that it the special case, rather than the other way around.

Cheers

Magnus Westerlund

---

From: Roni Even <[email-masked]>
Date: Wed, 16 Dec 2009 17:07:12 +0200

Magnus,
I think you are making good points and in my view the problem is that RAMS
was trying to design using RFC 4588 instead of a new solution. I think that
using a different approach would allow sending the burst information using
the original payload structure instead of retransmission packaging. This
will be a big change in the RAMS document.

Roni Even as Individual

> Sent: Friday, December 11, 2009 6:30 PM
> Subject: Re: [AVT] the use of "media sender SSRC" in draft-ietf-avt-
> rapid-acquisition-for-rtp-05
> 
> Hi Everyone,
>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 18 Dec 2009 15:47:52 +0100

> will be a big change in the RAMS document.

Roni, Ali and Others

I wished that I had involved myself in this at the start. Because I
think we can have produced something much better that would have less
impact on RTP and RTCP and also resolve the addressing issues also. I am
sensitive to major redesigns at this late stage.

I spoke to Ali earlier this week and he managed to straighten out a
misunderstanding from my part. However, I still think there are a
mismatch in semantics. I still believe the right semantics to request is
please help me join the RTP session X on multicast group Y as soon as
possible. That includes providing the RTP_Rx with all SSRC needed in
that session.

I think this semantics can be implemented in the current proposal
reasonably simple and still be made backwards compatible with the
previous proposal as long as the session has a single RTP stream being
sent over the multicast.

The proposal is as follows:

A new implementation following the proposal will include a TLV in the
RAMS-R that indicates that I want to join the whole session. When
included the SSRC in the header is ignored. The RS determines all the
SSRCs and their related packets that needs to be burst to be able to
join the multicast session. That way the server determines the
distribution of bandwidth between sources etc and the client that lacks
information about that doesn't have to do anything.

The RS responds with the RAMS-I which include an additional TLV or TLVs
that contain the per SSRC information. Just like the single source TLV
for RTP_Seqnum, there is a need for one that can include SSRC to RTP
sequence number information for each SSRC that is going to be burst. The
already existing TLVs for Earliest multicast join time, Burst duration,
max transmitt bit-rate are already specified in such a way that they can
be applied for the whole RTP session and all SSRCs jointly. The RTP
seqnum TLV is included for backwards compatibility with correct
information for one of the SSRCs in the session. If there are only a
single one in the session, the multiple source information TLV can be
skipped.

For the RAMS-T message the same TLV indicating that it applies to any
stream in the RAMS-R can be reused here for Terminating all SSRCs.

As I see this solution as being both backwards compatible and allowing
for a migration path for already deployed equipment and allows the RAMS
solution to be a generic RTP session mechanism instead of something that
only applies to MPEG-2 TS RTP sessions.

Please find the oversight that I made?

Cheers

Magnus Westerlund
(as individual)

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Fri, 18 Dec 2009 17:28:59 +0100

Hi Magnus,

I think your proposal makes sense, but then I would even go for a more flexible solution that combines the flexibility of the existing draft (allowing burst requesting on a per SSRC basis) without the involved  overhead and correlation complexities.
I propose to define TLVs for the RAMS-R which contain the SSRCs of which the related packets should be inside the -single- RAMS burst. The use cases for this were mentioned before:  not all SSRC-streams are of interest in the context of rapid aquisition and it does allow to save bandwidth consumption by the burst  (in fact in some cases the burst may in that case  even consume the same amount of bandwidth as the SSM session itself...)
This could be a single TLV that lists all desired SSRCs. The same TLV could also be used to address your proposal, but without listing all SSRCs, which provides the flexibility that the SSRCs do not need to be known by the RR (for the new proposal I make here, this knowledge is obviously required).
When this new TLV is embedded in the RAMS-R, indeed the media sender SSRC in the RAMS-R message header should be ignored.
All existing and defined TLVs can be maintained, with a few minor revisions:

-we may need to define new response codes:  when a RS does not support bursts that contain only a subset of SSRC streams as requested by the RTP receiver, it may be useful that this is signaled to the RTP receiver in the RAMS-I
-burst duration and MC join time TLVs (optional part of the RAMS-I) are expressed in RTP time ticks, and as each SSRC stream may have different RTP clock, this should be expressed in uniform time units such as seconds.

One other item we need to think about is that the RAMS-I message is also a RTCP FB message that has a packet sender SSRC field and a Media Sender SSRC field. It is not clear to me which SSRC values need to be filled out there, when a SSM session has multiple SSRC streams inside.

Regards
Tom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: vrijdag 18 december 2009 15:48
To: Roni Even
Cc: 'Rob Drisko (rdrisko)'; [email-masked]
Subject: Re: [AVT] the use of "media sender SSRC"in draft-ietf-avt-rapid-acquisition-for-rtp-05

Roni Even skrev:
> Magnus,
> I think you are making good points and in my view the problem is that 
> RAMS was trying to design using RFC 4588 instead of a new solution. I 
> think that using a different approach would allow sending the burst 
> information using the original payload structure instead of 
> retransmission packaging. This will be a big change in the RAMS document.
> 
> Roni Even as Individual

Roni, Ali and Others

I wished that I had involved myself in this at the start. Because I think we can have produced something much better that would have less impact on RTP and RTCP and also resolve the addressing issues also. I am sensitive to major redesigns at this late stage.

I spoke to Ali earlier this week and he managed to straighten out a misunderstanding from my part. However, I still think there are a mismatch in semantics. I still believe the right semantics to request is please help me join the RTP session X on multicast group Y as soon as possible. That includes providing the RTP_Rx with all SSRC needed in that session.

I think this semantics can be implemented in the current proposal reasonably simple and still be made backwards compatible with the previous proposal as long as the session has a single RTP stream being sent over the multicast.

A new implementation following the proposal will include a TLV in the RAMS-R that indicates that I want to join the whole session. When included the SSRC in the header is ignored. The RS determines all the SSRCs and their related packets that needs to be burst to be able to join the multicast session. That way the server determines the distribution of bandwidth between sources etc and the client that lacks information about that doesn't have to do anything.

The RS responds with the RAMS-I which include an additional TLV or TLVs that contain the per SSRC information. Just like the single source TLV for RTP_Seqnum, there is a need for one that can include SSRC to RTP sequence number information for each SSRC that is going to be burst. The already existing TLVs for Earliest multicast join time, Burst duration, max transmitt bit-rate are already specified in such a way that they can be applied for the whole RTP session and all SSRCs jointly. The RTP seqnum TLV is included for backwards compatibility with correct information for one of the SSRCs in the session. If there are only a single one in the session, the multiple source information TLV can be skipped.

For the RAMS-T message the same TLV indicating that it applies to any stream in the RAMS-R can be reused here for Terminating all SSRCs.

As I see this solution as being both backwards compatible and allowing for a migration path for already deployed equipment and allows the RAMS solution to be a generic RTP session mechanism instead of something that only applies to MPEG-2 TS RTP sessions.

Cheers

Magnus Westerlund
(as individual)