Subject: [AVT] Discussion and Proposals for RAMS draft supporting the multi-SSRC SSM case

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Thu, 7 Jan 2010 12:44:10 +0100

Hi,

There have been some email discussions before the holiday period whether
and how the RAMS draft should address the case where a SSM consists of a
multiplex of different SSRC RTP streams.  I would like to bring foward
some proposals on this matter for further discussion. When sufficient
agreement can be reached, we can integrate them inside the RAMS internet
draft. 

Note first the following: the RAMS messages are considered RTCP FB
messages, and must follow the message header format as specified in RFC
4585. In particular, the RTCP FB message header contains a (single)
"media sender SSRC"  field.  The original intent was hence that in case
a SSM consists of different SSRCs, for each SSRC inside the SSM for
which an RTP receiver requests a rapid acquisition, a separate RAMS-R,
RAMS-I and RAMS-T message needs to be issued, even though there is only
one RTP retransmission session (comprising all requested SSRC packet
streams formatted as retransmission packets). 

The new proposal is to use a single RAMS-R message, but a new "SSRC" TLV
is defined that can be part of the RAMS-R message payload and which
"overrules" the "media sender SSRC" field in the RAMS-R message header.
For each SSRC the RTP receiver requests rapid acquisition, the
appropriate "SSRC TLV" is inserted.  To address one of the comments of
Magnus,  it is also proposed that a RTP receiver can also signal
"provide me with all or whatever SSRC packet stream that is inside the
SSM". This could also be a dedicated new TLV (with no "value" contents),
and which would again overrule the "media sender SSRC" field in the
RAMS-R message. This new TLV could also be used for SSM which carries
only a single SSRC, and hence it does take away the need for signalling
the SSRC value out-of-band to the RTP receivers prior to the RAMS
interactions.

Note that the existing TLVs that are defined in the RAMS draft  for
RAMS-R (max bit rate, min and max buffering) would be applicable to the
whole RTP burst retransmission session, and would not be signaled on a
per-SSRC basis.

Note also that the Retransmission Server in principle could respond with
only a subset of the requested SSRCs in the burst. This would then be
indicated in the RAMS-I message(s) (see further)

There are now two different ways by which the RAMS process could further
proceed: either the RAMS-I and RAMS-T RTCP FB messages are further
transmitted on a per SSRC basis OR only one RAMS-I and one RAMS-T
message is exchanged:

1) Dedicated  per-SSRC  RAMS-I and RAMS-T messages

For each SSRC that will be part of the RTP retransmission burst session,
the Retransmission Server sends a dedicated RAMS-I message (SSRC is
indicated in the "media sender SSRC" field). The Retransmission Server
may have the freedom to select the SSRCs from the SSM it wants to
service, even though an RTP receiver requested all SSRCs in the RAMS-R
message.  Note that from all TLVs defined in the current RAMS draft only
the "SN of 1st packet in the retransmission session -pertaining to that
SSRC" TLV needs to be embedded in each RAMS-I message. The other TLVs
(burst duration, max bit rate, MC join time) only need to be inserted in
only one RAMS-I message and their meaning is not specifically tied to
the SSRC stream that is associated with this RAMS-I message, but to the
whole burst.  Whether the RS should also send an "empty" RAMS-I with
negative response in the "response field" if it does not include a
specific SSRC in the burst when this SSRC was requested by the RTP
receiver, needs to be discussed.

In a similar way the RTP receiver should also send a dedicated RAMS-T
message per SSRC received in the RAMS burst, where for each SSRC, the
"SN of the 1st packet received in the SSM" TLV  can be included.

2) Single RAMS-I and RAMS-T messages

Similar as for the RAMS-R message , the Retransmission Server sends only
a single RAMS-I message. The same procedure applies as for the RAMS-R:
for each  SSRC that will be part of the burst, a "SSRC" TLV is embedded
in the RAMS-I message, and this TLV overrules the "media sender SSRC"
value in the RAMS-I message header. With each "SSRC" TLV, also a  ""SN
of 1st packet in the retransmission session" TLV is inserted. The other
TLVs currently defined in the RAMS draft can also be included in the
RAMS-I message (but only once!). We may need to think about a new
response code that says "request can only be partially resolved" when
not all requested SSRCs are embedded in the burst.

Also an RTP receiver needs to issue only one single RAMS-T message which
contains again dedicated "SSRC" TLVs-overruling the "media sender SSRC"
in the message header- and per SSRC,  the "SN of the 1st packet received
in the SSM" TLV can be included. IMO we should mandate that at least the
SN of the 1st packet received in the SSM (whichever SSRC that may be),
but signaling all 1st SNs of all SSRCs received in the SMM would delay
the transmission of this message and make it perhaps less relevant for
the RS.

Solution two is my favourite as it reduces the messaging load and brings
more uniformity across the different RAMS messages for the multi-SSRC
SSM case.
Comments appreciated!

Tom

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 15 Jan 2010 13:40:42 +0100

Hi Tom,

I think the proposal you have and going with alternative 2 is the right
way forward to resolve the raised issues around both multi-SSRC RTP
sessions and the cases when you don't know the SSRC.

I would note that due to that commonly the SSRC in the FB packet header
will be wrong, I would suggest that RAMS go with a new RTCP packet type.
I am not strongly arguing for this, it would be the correct from a
semantics point of view. The question is if this makes the
interoperability issues with already deployed, equipment so extremely
bad that it should be avoided. I think the ones having products in the
market really should comment on how problematic this will be for them.

I would note that it is primarily the server that needs to be backwards
compatible, while clients can simply implement the standards solution.
Using a new RTCP packet type and still reserve a FB type code-point
would minimize interoperability issues.

Cheers

Magnus

VAN CAENEGEM Tom skrev 2010-01-07 12:44:
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

-- 

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: Sat, 16 Jan 2010 08:26:28 -0800

Magnus, All,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
> Sent: Friday, January 15, 2010 4:41 AM
> To: VAN CAENEGEM Tom
> Cc: [email-masked]; Bill Ver Steeg (versteb)
> Subject: Re: [AVT] Discussion and Proposals for RAMS draft supporting the multi-SSRC SSM
> case
> 
> Hi Tom,
> 

My personal opinion is to introduce new semantics to RAMS-R but still keep the RAMS-I and RAMS-T separate for each RTP stream.

The new RAMS-R can request a single, or all or a subset of the RTP streams (SSRCs) served by a given FTAp. The server generates separate bursts for each SSRC, so it should also send separate RAMS-I messages for each SSRC requested. This keeps the syntax of RAMS-I as it is now. Similarly, the receiver sends separate RAMS-T messages for each SSRC it received via RAMS.

I understand this increases the number of messages to be sent. But, what is the big deal? Just pack all those RAMS-I messages in a single RTCP packet. It is not like it will increase it by 100 or even by 5. In our primary application, there is one RTP stream so there won’t be any difference at all. For RAMS-T, there might be a small delay difference between the received mcast streams, so aggregating all RAMS-T in a single RTCP packet may not be a great idea in some cases. If it is not, then send separate RAMS-T messages. I still don’t see any issues here. The advantage, though, is each RAMS-I/T is tied to a single SSRC. Simple to generate, process and monitor.

Using separate RAMS-I messages also provides a lot of flexibility. Each field including the response codes may be specified in per SSRC. If we put everything in a single RAMS-I, how do we set the response code field when the server does not serve everything the receiver requested? We should not be going after saving a few bits IMO.
 
> will be wrong, I would suggest that RAMS go with a new RTCP packet type.

Yes, we considered this issue. But, the text in 4585 makes this difficult. We have to use the AVPF profile in the retransmission session and 4585 says anyone using the AVPF profile must stick to this feedback packet format.

If you know how to get around this issue, please let us know.

> market really should comment on how problematic this will be for them.

This change would of course changes in the server code but the changes we are making will already require changes anyway. So, I don't think this is the showstopper. The problem is the text in 4585.

---

From: Roni Even <[email-masked]>
Date: Sun, 17 Jan 2010 12:38:41 +0200

Hi,
I think that the issue of multi-SSRC SSM case need to be discussed with the
issue of SSRC in the signaling. 
The first issue as mentioned by Ali is the SSRC of the media sender in the
AVPF RTCP header.
The other issue I see is that if the receiver does not know the SSRCs how
can he requests multiple SSRC RAMS-R or a single SSRCs when there are
multi-SSRCs unless he asks for all.

There was a discussion about cases where the SSRC may not be known to the
receiver. http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-19 discusses the
issue of changing the SSRC by the sender (due to collision) in section 6.5 "
Sender SSRC information MAY be communicated out-of-band, e.g., by means of
SDP media descriptions.  Therefore, senders SHOULD NOT change their own SSRC
aggressively or unnecessarily." So we need to be sure that we are addressing
a protocol need here and not a specific implementation issue.

Roni Even
As individual

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ali C. Begen (abegen)
> Sent: Saturday, January 16, 2010 6:26 PM
> To: Magnus Westerlund; VAN CAENEGEM Tom
> Subject: Re: [AVT] Discussion and Proposals for RAMS draft supporting
> the multi-SSRC SSM case
> 
> Magnus, All,
> 
> My personal opinion is to introduce new semantics to RAMS-R but still
> keep the RAMS-I and RAMS-T separate for each RTP stream.
> 
> The new RAMS-R can request a single, or all or a subset of the RTP
> streams (SSRCs) served by a given FTAp. The server generates separate
> bursts for each SSRC, so it should also send separate RAMS-I messages
> for each SSRC requested. This keeps the syntax of RAMS-I as it is now.
> Similarly, the receiver sends separate RAMS-T messages for each SSRC it
> received via RAMS.
> 
> I understand this increases the number of messages to be sent. But,
> what is the big deal? Just pack all those RAMS-I messages in a single
> RTCP packet. It is not like it will increase it by 100 or even by 5. In
> our primary application, there is one RTP stream so there won’t be any
> difference at all. For RAMS-T, there might be a small delay difference
> between the received mcast streams, so aggregating all RAMS-T in a
> single RTCP packet may not be a great idea in some cases. If it is not,
> then send separate RAMS-T messages. I still don’t see any issues here.
> The advantage, though, is each RAMS-I/T is tied to a single SSRC.
> Simple to generate, process and monitor.
> 
> Using separate RAMS-I messages also provides a lot of flexibility. Each
> field including the response codes may be specified in per SSRC. If we
> put everything in a single RAMS-I, how do we set the response code
> field when the server does not serve everything the receiver requested?
> We should not be going after saving a few bits IMO.
> 
> Yes, we considered this issue. But, the text in 4585 makes this
> difficult. We have to use the AVPF profile in the retransmission
> session and 4585 says anyone using the AVPF profile must stick to this
> feedback packet format.
> 
> This change would of course changes in the server code but the changes
> we are making will already require changes anyway. So, I don't think
> this is the showstopper. The problem is the text in 4585.
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 18 Jan 2010 14:03:27 +0100

Hi Ali,

I find what you write about RAMS-I and RAMS-T to be very reasonable. So
far no issues with you drafting some text for a solution based on that
line of thinking.

> Yes, we considered this issue. But, the text in 4585 makes this difficult. We have to use the AVPF profile in the retransmission session and 4585 says anyone using the AVPF profile must stick to th…

I think you should simply acknowledge that you are updating the AVPF
profile anyway and could thus define that AVPF is not only for Feedback
messages as defined in RFC 4585, but also for certain Request messages.

The reason I say so is that the RAMS-R are clearly a request message,
not a feedback message. This as the sender has not received anything it
can provide feedback on. Secondly, semantically we have usage where the
request clearly is from someone to anyone that can respond to this.

If I make the comparison to CCM where we clearly have requests but they
are always used in a context where we can direct them at a particular
entity which makes them fit the AVPF defined feedback messages.

I think it is reasonable to explicitly redefine AVPF in this context,
but I love to hear other people opinion on this.

> This change would of course changes in the server code but the changes we are making will already require changes anyway. So, I don't think this is the showstopper. The problem is the text in 4585.

Good, I would argue for doing "the right thing" ;-) here. We can
redefine AVPF if we have consensus to do that now that we are extending
the usage scope of the profile.

Cheers

Magnus Westerlund

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Mon, 18 Jan 2010 16:13:09 +0100

Hi Magnus,

I see no reason why we should redefine anything surrounding AVTF profile (RFC4585) because of the RAMS solution that we have defined and discussed sofar.

The core concept behind a Feedback message is that this message is related to an event, and hence the RTCP message transmission that is triggered by this event should not be delayed, hence the AVPF profile. This makes the RAMS-R message belonging to the category of FB messages. 

The specific case of RAMS-R message is that this RTCP FB message is transmitted by a RTP Rx prior to receiving the RTP stream. Because this FB message is sent unicast to the feedback target and actually prior to the establishment of the corresponding primary RTP SSM session, the message can be sent immediately by the RTP receiver, when triggered by the application logic.

Your main concern was that the (single) "media sender SSRC" field is not adequate for SSMs with multiple RTP streams (1), and this field also imposes problems when the SSRC would not be known to the RTP receiver (2). Solutions have been proposed that address both concerns:

Solutions addressing (1) are:
1a)add dedicated SSRC TLVs in RAMS-R message (and RAMS-I or RAMS-T) overruling the "media sender SSRC" field in the RTCP FB RAMS-R message. I do not see this as a conflict with RFC 4585.
1b)have the  RTP receiver issuing RAMS-R messages on a per SSRC basis.
Both solutions also allow an RTP receiver to make a selection of which SSRC packets should be inside the retransmission session, when it knows the SSRCs and what they carry, but solution 1b is preferred IMO.
Independent whether 1a or 1b is the agreed upon solution, what then still needs to be discussed is whether "per SSRC" parameters (birate, buffering) can be conveyed in the RAMS-R message (and RAMS-I), or whether it makes more sense to define aggregated parameter values that address all SSRCs that will be part of the retransmission session (IMO the former would be too complex).

To address (2),  the "send me all SSRCs from the primary SSM" TLV is proposed, again overruling the "media sender SSRC". There are situations where such request cannot be unambiguously resolved by the RS (e.g. when the RS services different SSMs on the same feedback port), and this must cause the RS to send an error message in the RAMS-I (we can easily add any error message to provide as much as possible information to the receiver) as response on receiving such an ambiguous RAMS-R.  

We started to discuss on the list whether multiple RAMS-I and RAMS-T make sense in a multi SSRC SSM context, yes or no, but this can be resolved fairly fast as well, IMO.

Again, I see no reason for revising RFC 4588. And what would it bring us to define a new message format belonging to a new category specifically for RAMS-R?

It would also delay significantly the RAMS work, which progressed well over the last 18 months. Solutions "based" on the RAMS concept are being deployed in the field and IPTV standards organisations/fora in need of a standardised fast channel change  solution -with active support from the vendors-will be far from thrilled when the RAMS work is delayed for no good reason.

Kind regards,
Tom

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: maandag 18 januari 2010 14:03
To: Ali C. Begen (abegen)
Cc: VAN CAENEGEM Tom; [email-masked]; Bill Ver Steeg (versteb)
Subject: Re: [AVT] Discussion and Proposals for RAMS draft supporting the multi-SSRC SSM case

Hi Ali,

I find what you write about RAMS-I and RAMS-T to be very reasonable. So far no issues with you drafting some text for a solution based on that line of thinking.

>> I would note that due to that commonly the SSRC in the FB packet 
>> header will be wrong, I would suggest that RAMS go with a new RTCP packet type.
> 

I think you should simply acknowledge that you are updating the AVPF profile anyway and could thus define that AVPF is not only for Feedback messages as defined in RFC 4585, but also for certain Request messages.

The reason I say so is that the RAMS-R are clearly a request message, not a feedback message. This as the sender has not received anything it can provide feedback on. Secondly, semantically we have usage where the request clearly is from someone to anyone that can respond to this.

If I make the comparison to CCM where we clearly have requests but they are always used in a context where we can direct them at a particular entity which makes them fit the AVPF defined feedback messages.

I think it is reasonable to explicitly redefine AVPF in this context, but I love to hear other people opinion on this.

>> bad that it should be avoided. I think the ones having products in 
>> the market really should comment on how problematic this will be for them.
> 

Good, I would argue for doing "the right thing" ;-) here. We can redefine AVPF if we have consensus to do that now that we are extending the usage scope of the profile.

Cheers

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 18 Jan 2010 08:31:30 -0800

Hi Magnus,

> Sent: Monday, January 18, 2010 8:03 AM

Cool.
 
> > Yes, we considered this issue. But, the text in 4585 makes this difficult. We have to
> use the AVPF profile in the retransmission session and 4585 says anyone using the AVPF
> profile must stick to this feedback packet format.
> 

OK, what if I tell you that I see RAMS-R as a feedback message just like a NACK message but one that does not tell the specific packets the client is missing. It is like a "joker" NACK that makes the server figure out what should be sent. So, given NACK is a feedback message, RAMS-R can be considered as a feedback message. If you think NACK is a (retransmission) request message (but not feedback), then 4585 has more major issues :)

> but I love to hear other people opinion on this.

Sure, we can try that but the gain is not significant IMO. And I agree with Tom, this will add an undesired delay.
 
> > This change would of course changes in the server code but the changes we are making
> will already require changes anyway. So, I don't think this is the showstopper. The
> problem is the text in 4585.
> >
> 

Let's see what others think.

Cheers, acbegen

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 19 Jan 2010 16:09:48 +0100

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

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

Cheers

Magnus Westerlund

---

From: Roni Even <[email-masked]>
Date: Tue, 19 Jan 2010 23:47:16 +0200

Hi,
I think that we need to go back to the architecture and solution in the
first proposals for RAMS (IETF 72 and 73).
My understanding at the time was that the semantic of the first message is
that there was a picture loss (even using PLI message for that). This looks
similar to an endpoint joining a video conference and asking for video fast
update. The assumption was that the receiver has the information about the
source including the SSRC of the media source using out of band mechanism.
If we keep this assumption that the SSRC is known and send a RAMS-R message
for each RTP stream (option 1b from Tom) than we are still on the same
ground as the initial proposal. In this case we are still, in my view,
within the RFC 4585 and RFC 4588 semantics.

If the idea is to use one message for multiple streams and un-known SSRCs we
are going away from RFC 4585 and Magnus is right.

Roni Even
As individual

> Sent: Tuesday, January 19, 2010 5:10 PM
> Subject: [AVT] RTCP message semantics for RAMS, was Discussion and
> Proposals for RAMS draft supporting the multi-SSRC SSM case
> 
> Hi,
>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 Jan 2010 10:30:49 +0100

> are going away from RFC 4585 and Magnus is right.

Roni, I don't see how we can go with the assumption that the SSRC is
known. It doesn't really work in the environments where this is intended
to be used.

I would also point out that the RAMS-R is also a request to create an
new RTP session for the transfer of the burst. Thus using PLI seems very
inappropriate as we know we are going to need to add extra data to get
the port mappings working.

Cheers

Magnus Westerlund
(as individual)

---

From: Roni Even <[email-masked]>
Date: Wed, 20 Jan 2010 12:09:14 +0200

Magnus,
The SSRC should be known as part of the Session announcement (out of band)
this was the assumption in the initial work and this is inline with rtcpssm
(see section 6.5). There was a comment that due to implementation or
deployment issues it may be difficult to know the SSRC but I am not sure
that it cannot be known to the receiver if SSRC changes will be according to
rtcpssm.

As for you second point, the claim by the authors was that this is a
retransmission session and you can also call a retransmission request as one
that create a new RTP session. The individual draft used PLI and afterwards
a second RTCP message that conveyed further information. 
The issue of port mapping is applicable also to the case of rtcpssm with
unicast retransmission even without RAMS (using unicast retransmission for
multicast is discussed in RFC 4588 section 3.1 but the text does not address
the port mapping issue)

Roni Even
As Individual

> Sent: Wednesday, January 20, 2010 11:31 AM
> To: Roni Even
> Cc: 'Ali C. Begen (abegen)'; 'VAN CAENEGEM Tom'; [email-masked]; 'Bill
> Ver Steeg (versteb)'
> Subject: Re: [AVT] RTCP message semantics for RAMS, was Discussion and

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 Jan 2010 11:42:43 +0100

> that it cannot be known to the receiver if SSRC changes will be according to

I don't think I agree that RTCP SSM was done with any assumptions about
SSRC need to be known. Rather the opposite we (I say we as, as although
I am not an author I am one of the most frequent commenter on that spec)
tried our best to ensure that regular SSRC collision detection worked.
The only change there compared to regular RTP was that a media sender
does not move out of the way of a receiver only participant immediately
and expect that one to move.

The Media Senders in an RTCP SSM group can benefit from doing
pre-synchronization of their SSRCs, however that is only the media
senders. There are no need to provide the RTP receivers at the end of
the SSM tree with the SSRC, it is only to reduce the risk for collision
and the need for handling that.

RTCP SSM works just fine without providing the receivers with any SSRC.

RAMS currently doesn't and I are of the strong opinion that this is a
bad design that complicates the system and makes the usage of RTP less
applicable than it should be for this type of application.

> multicast is discussed in RFC 4588 section 3.1 but the text does not address

I don't agree with the authors that it is a regular RTP retransmission
either. RFC 4588 is based on an explicit out-of-band creation of the RTP
session that the RTP retransmission packets are sent in for Session
multiplex usage.

What is new in RAMS and also its usage of RTP retransmission is the
dynamic RTP session creation. Something that hasn't previously been done
using RTCP, only RTP/RTCP external protocols.

When it comes to RTP RTX and Session multiplexing you can clearly use
SIP/SDP to setup a receiver with an SSM delivered main session and a
point to feedback target unicast session. Yes, there are no examples on
this, but that part is straight forward. But that doesn't fit well with
applications that RAMS targets. The session configuration information
for RAMS use cases are both not dynamically created at the time a
participant wants to join the SSM session, nor synchronized with the
local feedback target.

The goals with RAMS is to provide a service that speeds up joining of
SSM distributed RTP sessions without reducing the scalability compared
to just SSM and local feedback targets for RTCP gathering. And I want
this to work for all type of RTP sessions, not RTP sessions with a
single SSRC.

Cheers

Magnus Westerlund
(as individual)

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 20 Jan 2010 03:24:39 -0800

Hi Magnus,

> Sent: Tuesday, January 19, 2010 10:10 AM
> Subject: RTCP message semantics for RAMS, was [AVT] Discussion and Proposals for RAMS
> draft supporting the multi-SSRC SSM case
> 
> Hi,
> 

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

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

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

Cheers, acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 20 Jan 2010 03:24:56 -0800

> Sent: Wednesday, January 20, 2010 5:43 AM
> To: Roni Even
> Cc: 'VAN CAENEGEM Tom'; [email-masked]; Bill Ver Steeg (versteb)
> Subject: Re: [AVT] RTCP message semantics for RAMS, was Discussion and Proposals for RAMS

Correct.
 
> applicable than it should be for this type of application.

I would not say RAMS does not currently work. It works just fine when SSRCs are announced in the SDP. It works perfectly even when SSRCs are not announced in the SDP provided that each FTAp is serving for only one SSRC.

There are some complications when there are multiple SSRCs served by a single FTAp. Initially, we wanted to avoid such usage by mandating to run a separate RAMS for each RTP stream rather than the whole RTP session (which may have one or more RTP streams). We can certainly do so by limiting the scope of the RAMS draft but I hope we won’t get to that point. And I don’t think we need to. The latest extensions we proposed (on the list) for the RAMS-R message (still following the 4585 format and rules) are a good compromise IMO.

> using RTCP, only RTP/RTCP external protocols.

How is it any different when the server starts a new ret session when responding to a NACK vs RAMS-R? In both cases, the ret session is created on the fly (i.e., dynamic). Are you concerned about the port-mapping issues?

-acbegen

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 Jan 2010 13:59:50 +0100

> I would not say RAMS does not currently work. It works just fine when SSRCs are announced in the SDP. It works perfectly even when SSRCs are not announced in the SDP provided that each FTAp is serv…

Correct, that if you announce all the SSRC's it does work to certain
degree. My issue with that case is that the client is not the right
entity to determine who the available bandwidth are going to be divided
up. The client is clearly lacking information making it near impossible
to ensure that any multi-SSRC case results in synchronized bursts. Thus
either creating overlap of wholes in the data stream.

When it comes to cases where the SSRC is not announced, even in the
single SSRC case I would say that RAMS-R will violate the AVPF to a
certain degree. The FB messages common header:

   SSRC of media source: 32 bits
      The synchronization source identifier of the media source that
      this piece of feedback information is related to.

As you don't know that you can't fill it in correctly. Thus at least
that needs redefining to consider wildcard. As no SSRC was reserved for
wildcard this is a difficult problem. I think that using the requestors
own SSRC is probably the best one can do. That at least would in this
context clearly signal that I want something else. Because you don't
need to send RAMS FBs to my knowledge about your own streams.

CCM (RFC5104) has already before ignored the common header SSRC field.
But unless something is changed RAMS sometime uses this field with
explicit values and sometime as wildcard. This clearly needs a clear
definition.

I am not stating that it is impossible to shoehorn in, however I think
from a semantics perspective that RAMS are rather far away from the
semantic of AVPF FBs as defined in RFC 4585.

> There are some complications when there are multiple SSRCs served by a single FTAp. Initially, we wanted to avoid such usage by mandating to run a separate RAMS for each RTP stream rather than the…

And as I have argued for multiple SSRC cases a single request with
semantics of give me what I need to join the session allows the FT to
take all necessary streams into account and divide up the available
bandwidth in a reasonable way.

> How is it any different when the server starts a new ret session when responding to a NACK vs RAMS-R? In both cases, the ret session is created on the fly (i.e., dynamic). Are you concerned about t…

I am not saying that they are different. I am saying that both was not
considered in RFC 4588. In RFC 4588 the retransmission is negotiated
prior to the session start and also which RTP session and its addressing
information exist prior.

In the application context RAMS are considering and also desires to have
retransmissions in the there is a need for a dynamic session creation.
This is new functionality independent if we discuss rapid aquistion of
multicast streams or retransmissions related to a SSM session with a
feedback target without out-of-band negotiation of that session.

Cheers

Magnus Westerlund
(As individual)

---

From: Roni Even <[email-masked]>
Date: Wed, 20 Jan 2010 15:21:24 +0200

Hi Magnus,
I did not mean that SSRC is required for rtcpssm, I was just pointing out
that SSRC collision is addressed and that rtcpssm recommends that the media
sender SSRC will be kept since the media sender information may be sent out
of band like is happing in this case. An example of dependency on SSRC and
handling changing of SSRC (due to collision but may be due to other reasons)
as may happen in SVC (H.264 scalable video) is in RFC 5576 and requires
delivery of new SDP when a change occurs.

Roni Even
As individual

> Sent: Wednesday, January 20, 2010 12:43 PM
> To: Roni Even
> Cc: 'VAN CAENEGEM Tom'; [email-masked]; 'Bill Ver Steeg (versteb)'

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Wed, 20 Jan 2010 15:06:25 +0100

Hi Magnus,

Interesting, I was not aware that RFC5104 did ignore the common header SSRC field. I now understand that in RFC5104, in  the new FB messages, the SSRC is filled out as zero and the FCI (payload) entry/entries of the FB messages contain(s) a dedicated SSRC. 

So, if this was accepted for RFC 5104, I see no reason why a similar technique could not be accepted for RAMS signalling? 
In the multi-SSRC SSM case where an RTP receiver requests multiple RTP streams confined in the same SSM by means of a single RAMS-R, the common header SSRC is then set to zero, and SSRC TLVs are embedded instead.

By the way, independent whether we use a single RAMS-R message or multiple RAMS-R messages for multi-SSRC SSM case, I do not think there is much value for the RTP receiver to signal per SSRC the bitrate and buffer requirement to the RS in the RAMS-I message(s). This will make it way complex for the RS and the synchronisation at the receiver side of all SSRC streams may fail on the application level. The values in the TLVs defined for signaling max. bit rate and min/max buffering by the RTP receiver should apply to the collection of SSRC RTP bursts inside the retransmission session.   

My understanding from Roni's comments is that if the working assumption is that SSRC's are signaled to the RTP receivers prior to the RAMS signaling, we are not in conflict with RFC 4585 and RFC 4588 (and neither with rtcp ssm).

Tom

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: woensdag 20 januari 2010 14:00
To: Ali C. Begen (abegen)
Cc: Roni Even; VAN CAENEGEM Tom; [email-masked]; Bill Ver Steeg (versteb)
Subject: Re: [AVT] RTCP message semantics for RAMS, was Discussion and Proposals for RAMS draft supporting the multi-SSRC SSM case

Ali C. Begen (abegen) skrev 2010-01-20 12:24:
>> Subject: Re: [AVT] RTCP message semantics for RAMS, was Discussion 
>> and Proposals for RAMS draft supporting the multi-SSRC SSM case
>>
>>> The SSRC should be known as part of the Session announcement (out of 
>>> band) this was the assumption in the initial work and this is inline 
>>> with rtcpssm (see section 6.5). There was a comment that due to 
>>> implementation or deployment issues it may be difficult to know the 
>>> SSRC but I am not sure that it cannot be known to the receiver if 
>>> SSRC changes will be according to rtcpssm.
>>
>> I don't think I agree that RTCP SSM was done with any assumptions 
>> about SSRC need to be known. Rather the opposite we (I say we as, as 
>> although I am not an author I am one of the most frequent commenter 
>> on that spec) tried our best to ensure that regular SSRC collision detection worked.
>> does not move out of the way of a receiver only participant 
>> immediately and expect that one to move.
>>
>> the SSM tree with the SSRC, it is only to reduce the risk for 
>> collision and the need for handling that.
>>
>> bad design that complicates the system and makes the usage of RTP 
>> less applicable than it should be for this type of application.
> 

Correct, that if you announce all the SSRC's it does work to certain degree. My issue with that case is that the client is not the right entity to determine who the available bandwidth are going to be divided up. The client is clearly lacking information making it near impossible to ensure that any multi-SSRC case results in synchronized bursts. Thus either creating overlap of wholes in the data stream.

When it comes to cases where the SSRC is not announced, even in the single SSRC case I would say that RAMS-R will violate the AVPF to a certain degree. The FB messages common header:

As you don't know that you can't fill it in correctly. Thus at least that needs redefining to consider wildcard. As no SSRC was reserved for wildcard this is a difficult problem. I think that using the requestors own SSRC is probably the best one can do. That at least would in this context clearly signal that I want something else. Because you don't need to send RAMS FBs to my knowledge about your own streams.

CCM (RFC5104) has already before ignored the common header SSRC field.
But unless something is changed RAMS sometime uses this field with explicit values and sometime as wildcard. This clearly needs a clear definition.

I am not stating that it is impossible to shoehorn in, however I think from a semantics perspective that RAMS are rather far away from the semantic of AVPF FBs as defined in RFC 4585.

> 
> There are some complications when there are multiple SSRCs served by a single FTAp. Initially, we wanted to avoid such usage by mandating to run a separate RAMS for each RTP stream rather than the whole RTP session (which may have one or more RTP streams). We can certainly do so by limiting the scope of the RAMS draft but I hope we won't get to that point. And I don't think we need to. The latest extensions we proposed (on the list) for the RAMS-R message (still following the 4585 format and rules) are a good compromise IMO.

And as I have argued for multiple SSRC cases a single request with semantics of give me what I need to join the session allows the FT to take all necessary streams into account and divide up the available bandwidth in a reasonable way.

>>> retransmission session and you can also call a retransmission 
>>> request as one that create a new RTP session. The individual draft 
>>> used PLI and afterwards a second RTCP message that conveyed further information.
>>> The issue of port mapping is applicable also to the case of rtcpssm 
>>> with unicast retransmission even without RAMS (using unicast 
>>> retransmission for multicast is discussed in RFC 4588 section 3.1 
>>> but the text does not address the port mapping issue)
>>>
>>
>> I don't agree with the authors that it is a regular RTP 
>> retransmission either. RFC 4588 is based on an explicit out-of-band 
>> creation of the RTP session that the RTP retransmission packets are 
>> sent in for Session multiplex usage.
>>
>> dynamic RTP session creation. Something that hasn't previously been 
>> done using RTCP, only RTP/RTCP external protocols.
> 

I am not saying that they are different. I am saying that both was not considered in RFC 4588. In RFC 4588 the retransmission is negotiated prior to the session start and also which RTP session and its addressing information exist prior.

In the application context RAMS are considering and also desires to have retransmissions in the there is a need for a dynamic session creation.
This is new functionality independent if we discuss rapid aquistion of multicast streams or retransmissions related to a SSM session with a feedback target without out-of-band negotiation of that session.

Cheers

Magnus Westerlund
(As individual)

---

From: Tom Taylor <[email-masked]>
Date: Wed, 20 Jan 2010 11:22:39 -0500

Just a quick summary of points here. I think there is agreement that the 
bandwidth constraints should apply to the session as a whole and not to 
individual streams. That is definitely an argument against RAMS-R per SSRC.

What Magnus contends is that the semantics are not those of feedback. There 
would seem to be an advantage in cutting yourself loose from constraints imposed 
by the FB message type and defining a new one instead, but obviously additional 
specification would be required. I suppose your concern is that this could add 
perhaps another month's delay.

Tom Taylor
as Chair

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 Jan 2010 17:48:39 +0100

> 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 t…

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.

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

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

Answered in another email.

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

I agree that it is unfortunate, but that doesn't allows to ignore if the
semantics are inappropriate.

> 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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 20 Jan 2010 10:08:19 -0800

> > How is it any different when the server starts a new ret session when responding to a
> NACK vs RAMS-R? In both cases, the ret session is created on the fly (i.e., dynamic). Are
> you concerned about the port-mapping issues?
> 

I was not following the AVT list when RTCPSSM draft was being developed. But, I cannot imagine that anybody has not considered doing unicast retransmissions in SSM sessions by following the rtcpssm draft and 4588. That is one of the top use cases for rtcpssm draft IMO. Similar ideas have been floating around in RMT WG for a long time. So I am surprised to hear that these issues were not raised at that time.

Cheers, acbegen.

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 20 Jan 2010 11:39:52 -0800

I would like to get the official definition of "feedback" from the AVT WG. Lets first agree on that. Does the WG think feedback can only be related to things that occurred in the past? Or, can the feedback relate to anything pertaining to any given RTP session?

-acbegen

> From: Tom Taylor [mailto:[email-masked]]
> Sent: Wednesday, January 20, 2010 11:23 AM
> To: VAN CAENEGEM Tom; Ali C. Begen (abegen); Bill Ver Steeg (versteb)
> Cc: Magnus Westerlund; [email-masked]; Roni Even
> > Interesting, I was not aware that RFC5104 did ignore the common header SSRC field. I now
> understand that in RFC5104, in  the new FB messages, the SSRC is filled out as zero and
> the FCI (payload) entry/entries of the FB messages contain(s) a dedicated SSRC.
> >
> > In the multi-SSRC SSM case where an RTP receiver requests multiple RTP streams confined
> in the same SSM by means of a single RAMS-R, the common header SSRC is then set to zero,
> and SSRC TLVs are embedded instead.
> >
> > By the way, independent whether we use a single RAMS-R message or multiple RAMS-R
> messages for multi-SSRC SSM case, I do not think there is much value for the RTP receiver
> to signal per SSRC the bitrate and buffer requirement to the RS in the RAMS-I message(s).
> This will make it way complex for the RS and the synchronisation at the receiver side of
> all SSRC streams may fail on the application level. The values in the TLVs defined for
> signaling max. bit rate and min/max buffering by the RTP receiver should apply to the
> collection of SSRC RTP bursts inside the retransmission session.
> >
> > My understanding from Roni's comments is that if the working assumption is that SSRC's
> are signaled to the RTP receivers prior to the RAMS signaling, we are not in conflict with
> RFC 4585 and RFC 4588 (and neither with rtcp ssm).
> >
> > Tom
> >
> >
> >
> > Subject: Re: [AVT] RTCP message semantics for RAMS, was Discussion and Proposals for
> RAMS draft supporting the multi-SSRC SSM case
> >
> >> I would not say RAMS does not currently work. It works just fine when SSRCs are
> announced in the SDP. It works perfectly even when SSRCs are not announced in the SDP
> provided that each FTAp is serving for only one SSRC.
> >
> >
> > Correct, that if you announce all the SSRC's it does work to certain degree. My issue
> with that case is that the client is not the right entity to determine who the available
> bandwidth are going to be divided up. The client is clearly lacking information making it
> near impossible to ensure that any multi-SSRC case results in synchronized bursts. Thus
> > When it comes to cases where the SSRC is not announced, even in the single SSRC case I
> would say that RAMS-R will violate the AVPF to a certain degree. The FB messages common
> header:
> >
> > As you don't know that you can't fill it in correctly. Thus at least that needs
> redefining to consider wildcard. As no SSRC was reserved for wildcard this is a difficult
> problem. I think that using the requestors own SSRC is probably the best one can do. That
> at least would in this context clearly signal that I want something else. Because you
> don't need to send RAMS FBs to my knowledge about your own streams.
> >
> > But unless something is changed RAMS sometime uses this field with explicit values and
> sometime as wildcard. This clearly needs a clear definition.
> >
> > I am not stating that it is impossible to shoehorn in, however I think from a semantics
> perspective that RAMS are rather far away from the semantic of AVPF FBs as defined in RFC
> 4585.
> >
> >> There are some complications when there are multiple SSRCs served by a single FTAp.
> Initially, we wanted to avoid such usage by mandating to run a separate RAMS for each RTP
> stream rather than the whole RTP session (which may have one or more RTP streams). We can
> certainly do so by limiting the scope of the RAMS draft but I hope we won't get to that
> point. And I don't think we need to. The latest extensions we proposed (on the list) for
> the RAMS-R message (still following the 4585 format and rules) are a good compromise IMO.
> >
> > And as I have argued for multiple SSRC cases a single request with semantics of give me
> what I need to join the session allows the FT to take all necessary streams into account
> and divide up the available bandwidth in a reasonable way.
> >
> >>
> > I am not saying that they are different. I am saying that both was not considered in RFC
> 4588. In RFC 4588 the retransmission is negotiated prior to the session start and also
> which RTP session and its addressing information exist prior.
> >
> > In the application context RAMS are considering and also desires to have retransmissions
> in the there is a need for a dynamic session creation.
> > This is new functionality independent if we discuss rapid aquistion of multicast streams
> or retransmissions related to a SSM session with a feedback target without out-of-band
> negotiation of that session.
> >
> > Cheers
> >
> > Magnus Westerlund
> > (As individual)
> >

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 20 Jan 2010 11:52:09 -0800

> Sent: Wednesday, January 20, 2010 11:49 AM
> Subject: Re: RTCP message semantics for RAMS, was [AVT] Discussion and Proposals for RAMS
> > 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.
> 

Well, it is unfortunate that 4588 had that rule then. But delaying the transmission of RAMS-R by Tmin actually does not help at all to avoid the flash crowd problem you mentioned since the individual clients operate independently. 
 
> >
> > 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.
> >
> 

We have done a lot of analysis. It is a fact that there is a huge correlation in the temporal domain if your consider channel changes in a TV platform, but applying a Tmin delay does not offer any improvements. The same correlation will be in effect when everybody delays their RAMS-R messages by Tmin. Even if you randomize Tmin between say 0 and 1 second, it won't get you anything.

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

Correct. 
 
> this. I now this goes into dimensioning, but the issue needs discussion.

Where do you think we should put this discussion? This really gets into the implementation issues but I suppose somewhere we introduce the RAMS-R message we can explain why we use Tmin=0.

-acbegen

---

From: Roni Even <[email-masked]>
Date: Thu, 21 Jan 2010 00:37:56 +0200

Ali,
Unicast retransmission of single source multicast using unicast streams is
mentioned in second paragraph of section 3.1 of RFC 4588 when talking about
session multiplexing but there is no text explaining this and the second
example in section 9 shows a multicast session used also for retransmission.

Roni Even

> From: Ali C. Begen (abegen) [mailto:[email-masked]]
> Sent: Wednesday, January 20, 2010 8:08 PM
> To: Magnus Westerlund
> Subject: RE: [AVT] RTCP message semantics for RAMS, was Discussion and
> I was not following the AVT list when RTCPSSM draft was being
> developed. But, I cannot imagine that anybody has not considered doing
> unicast retransmissions in SSM sessions by following the rtcpssm draft
> and 4588. That is one of the top use cases for rtcpssm draft IMO.
> Similar ideas have been floating around in RMT WG for a long time. So I
> am surprised to hear that these issues were not raised at that time.
> 
> Cheers, acbegen.
>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 22 Jan 2010 15:30:28 +0100

> I was not following the AVT list when RTCPSSM draft was being developed. But, I cannot imagine that anybody has not considered doing unicast retransmissions in SSM sessions by following the rtcpssm…

I don't think we thought this through very well. RTCP SSM plus RFC 4588
works well for doing repair on the larger scale, but retransmitting over
SSM. It also works if you can pre-establish a point to point unicast
session, for example using SIP or RTSP.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 22 Jan 2010 15:31:41 +0100

> example in section 9 shows a multicast session used also for retransmission.

Yes, the case was glanced over because it was not any of the
participants important use case.

Cheers

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 22 Jan 2010 06:36:25 -0800

Do you think AVT needs a separate draft for doing unicast retransmissions in SSM sessions? Most of our current issues would have already been resolved if such a draft had existed.

-acbegen

> Sent: Friday, January 22, 2010 9:32 AM
> To: Roni Even
> Cc: Ali C. Begen (abegen); 'VAN CAENEGEM Tom'; [email-masked]; Bill Ver
> Steeg (versteb)

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 22 Jan 2010 15:38:46 +0100

> We have done a lot of analysis. It is a fact that there is a huge correlation in the temporal domain if your consider channel changes in a TV platform, but applying a Tmin delay does not offer any…

Yes, I can understand that this is the case. Tmin=1 s only dispers the
request during that interval, if the peak of RAMS requests will arrive
during an time interval that is longer than tmin it doesn't help much,
unless the distribution is such that smoothing it would help the system
handle it.

> Where do you think we should put this discussion? This really gets into the implementation issues but I suppose somewhere we introduce the RAMS-R message we can explain why we use Tmin=0.

You need both an explicit definition that one shall use Tmin = 0 for the
RAMS-R request and some motivational text why that is the right choice.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 22 Jan 2010 15:40:24 +0100

> I would like to get the official definition of "feedback" from the AVT WG. Lets first agree on that. Does the WG think feedback can only be related to things that occurred in the past? Or, can the…

When I asked for the WG's feedback I was asking for feedback from anyone
that isn't the document authors or me. I definitely would like to here
Joerg Ott's and Colin Perkin's view on this.

I realize that I am likely to have to accept that RAMS uses the Feedback
format. I would recommend that you as authors work on text assuming that
for the moment while this is being discussed. If the WG comes to another
conclusion you will not have lost a lot of time, due to that most text
will anyway be needed.

I would like to point out that I would strongly recommend that if FB
format is used, the destination SSRC is the SSRC of the requestor to
mean that it is a wild card. That way you minimize the issue of causing
collision with the actually used SSRC's in the session.

Cheers

Magnus Westerlund

---

From: Roni Even <[email-masked]>
Date: Fri, 22 Jan 2010 16:52:00 +0200

Ali,
Maybe updating RFC 4588 or part of port mapping since this is tied also to
port mapping
Roni

> Sent: Friday, January 22, 2010 4:36 PM
> To: Magnus Westerlund; Roni Even
> Do you think AVT needs a separate draft for doing unicast
> retransmissions in SSM sessions? Most of our current issues would have
> already been resolved if such a draft had existed.
> 
> -acbegen
> 
> and
> > > mentioned in second paragraph of section 3.1 of RFC 4588 when
> talking
> > about

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Fri, 22 Jan 2010 15:53:58 +0100

Hi Magnus,

Can you explain more:

"I would like to point out that I would strongly recommend that if FB format is used, the destination SSRC is the SSRC of the requestor to mean that it is a wild card. That way you minimize the issue of causing collision with the actually used SSRC's in the session."

Would that be a specific usage of the SSRC field (we talk about the "media sender SSRC" field in the packet header of the RTCP FB message, right?) in the context of RAMS only? Why do you prefer this above setting this field to "zero" for RAMS-R messages, as was done in RFC 5104? Is it because you want to have a solution even when the SSRC is not known to the RTP receiver?

Tom 

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: vrijdag 22 januari 2010 15:40
To: Ali C. Begen (abegen)
Cc: Tom Taylor; VAN CAENEGEM Tom; Bill Ver Steeg (versteb); [email-masked]; Roni Even
Subject: Re: [AVT] RTCP message semantics for RAMS, was Discussion and Proposals for RAMS draft supporting the multi-SSRC SSM case

> I would like to get the official definition of "feedback" from the AVT WG. Lets first agree on that. Does the WG think feedback can only be related to things that occurred in the past? Or, can the…

When I asked for the WG's feedback I was asking for feedback from anyone that isn't the document authors or me. I definitely would like to here Joerg Ott's and Colin Perkin's view on this.

I realize that I am likely to have to accept that RAMS uses the Feedback format. I would recommend that you as authors work on text assuming that for the moment while this is being discussed. If the WG comes to another conclusion you will not have lost a lot of time, due to that most text will anyway be needed.

I would like to point out that I would strongly recommend that if FB format is used, the destination SSRC is the SSRC of the requestor to mean that it is a wild card. That way you minimize the issue of causing collision with the actually used SSRC's in the session.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 22 Jan 2010 16:07:26 +0100

> Would that be a specific usage of the SSRC field (we talk about the "media sender SSRC" field in the packet header of the RTCP FB message, right?) in the context of RAMS only? Why do you prefer thi…

The reason is that for RAMS-R in the case that you know the SSRC and you
want the request to apply to that specific SSRC, then using the media
sender SSRC field makes sense. Because I have gotten the impression that
functionality will not be removed when adding multi-SSRC and
wild-carding support to RAMS.

If you want wild card media sender SSRC setting the requestor SSRC and
the media sender SSRC field to the same will be an easiliy identifiable
pattern, even in cases of the client having SSRC collisions.

Thats why I think it is a good idea.

Cheers

Magnus Westerlund
(As individual)

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 22 Jan 2010 16:12:08 +0100

> Do you think AVT needs a separate draft for doing unicast retransmissions in SSM sessions? Most of our current issues would have already been resolved if such a draft had existed.

Yes, I think there need to be a specification of how to establish the
unicast RTP session for the retransmissions between the client and the
Feedback Target.

As I see the alternative is to use an out-of-band signalling mechanism
to establish that session between the feedback target and the client.

As the Retransmission is a potentially separate issue from the RAMS I
would say that a separate draft is likely a good idea. I also think that
solution do need to take the NAT traversal issues into account. Without
NAT traversal that spec is a piece of mostly useless junk.

Cheers

Magnus Westerlund

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Fri, 22 Jan 2010 16:46:03 +0100

All,

In DVB we have defined the retransmission for SSM in an IPTV scenario where  RFC 4585, RFC 4588 and rtcp-ssm are the references for this specification. In the process of drafting the spec, we did communicate our solution to IETF AVT about two years ago, but back then there was not that much interest.

In the DVB solution, the port that is used in the RTP unicast retransmission session is imposed either by the server side (1), or alternatively the RTP receiver controls this port (2) by a scheme in which the Retransmission session has the same port number as the port used in the RTCP unicast feedback packets, allowing  NAT traversal, but requiring that RTP and RTCP are muxed on the same port in the retransmission session. 

Note that the solution (1) may work out as well, because in a DVB IPTV system the port to be used are signaled well in advance  as all DVB IPTV service parameters are delivered all together out-of-band (SD&S protocol). They need to be retrieved before IPTV services can be consumed by the STB, and hence before the RTP receiver (STB) is able to connect to the IPTV streams (SSM or unicast). Hence these ports -or port- can be "reserved" by the STB. 

The in-band port mapping/signalling proposal/idea from Ali is a solution that provides more flexibility at least at server side, compared to the option (2) in DVB. But apart from defining a scheme how an RTP receiver can in-band communicate the port(s) it wants when a FB target also acts as sender (i.e. the port mapping proposal), what else needs to be addressed in such a draft? Can you explain that?

Tom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: vrijdag 22 januari 2010 16:12
To: Ali C. Begen (abegen)
Cc: Bill Ver Steeg (versteb); VAN CAENEGEM Tom; [email-masked]; Roni Even
Subject: Re: [AVT] RTCP message semantics for RAMS, was Discussion and Proposals for RAMS draft supporting the multi-SSRC SSM case

> Do you think AVT needs a separate draft for doing unicast retransmissions in SSM sessions? Most of our current issues would have already been resolved if such a draft had existed.

Yes, I think there need to be a specification of how to establish the unicast RTP session for the retransmissions between the client and the Feedback Target.

As I see the alternative is to use an out-of-band signalling mechanism to establish that session between the feedback target and the client.

As the Retransmission is a potentially separate issue from the RAMS I would say that a separate draft is likely a good idea. I also think that solution do need to take the NAT traversal issues into account. Without NAT traversal that spec is a piece of mostly useless junk.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 22 Jan 2010 17:16:47 +0100

Hi Tom,

> In the DVB solution, the port that is used in the RTP unicast retransmission session is imposed either by the server side (1), or alternatively the RTP receiver controls this port (2) by a scheme i…

However, proposal 2 does not work directly due to that it confuses
together the RTCP related to the SSM sessions which is what is indicated
to go to that particular Ap on the Feedback target and the RTCP related
to the unicast session. Thus there needs to be separation between these
two. Thus there need to be at least a port separation on one side to
accomplish that.

> Note that the solution (1) may work out as well, because in a DVB IPTV system the port to be used are signaled well in advance  as all DVB IPTV service parameters are delivered all together out-of-…

For the server imposed port, that works fine for STBs and where there
are no NAT or Firewall between the STB and the feedback target. I don't
find that particular realistic in any deployments except dedicated ones.

> The in-band port mapping/signalling proposal/idea from Ali is a solution that provides more flexibility at least at server side, compared to the option (2) in DVB. But apart from defining a scheme…

I don't think there is that much more. There is the discussion on the
requirement for RTP session separation between the RTCP SSM feedback and
the unicast sessions and its related. Then there is the mechanism to
establish this unicast session. From a FW and NAT traversal solution I
am a strong believer in late binding to do that.

I never claimed it would be a huge draft, only that it is needed and
that there are generic pieces here thus separating it out form RAMS and
making it common to RTX and RAMS is a good idea.

Cheers

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 22 Jan 2010 08:29:13 -0800

As Roni suggested earlier, I believe we should add some explicit text into our port mapping draft so that it becomes *explicitly* a more generic solution.

-acbegen

> Sent: Friday, January 22, 2010 11:17 AM
> To: VAN CAENEGEM Tom
> Cc: Ali C. Begen (abegen); Bill Ver Steeg (versteb); [email-masked]; Roni
> Even
> > In DVB we have defined the retransmission for SSM in an IPTV scenario
> where  RFC 4585, RFC 4588 and rtcp-ssm are the references for this
> specification. In the process of drafting the spec, we did communicate
> our solution to IETF AVT about two years ago, but back then there was
> not that much interest.
> >
> > In the DVB solution, the port that is used in the RTP unicast
> retransmission session is imposed either by the server side (1), or
> alternatively the RTP receiver controls this port (2) by a scheme in
> which the Retransmission session has the same port number as the port
> used in the RTCP unicast feedback packets, allowing  NAT traversal, but
> requiring that RTP and RTCP are muxed on the same port in the
> retransmission session.
> >
> 
> > Note that the solution (1) may work out as well, because in a DVB
> IPTV system the port to be used are signaled well in advance  as all
> DVB IPTV service parameters are delivered all together out-of-band
> (SD&S protocol). They need to be retrieved before IPTV services can be
> consumed by the STB, and hence before the RTP receiver (STB) is able to
> connect to the IPTV streams (SSM or unicast). Hence these ports -or
> port- can be "reserved" by the STB.
> 
> > The in-band port mapping/signalling proposal/idea from Ali is a
> solution that provides more flexibility at least at server side,
> compared to the option (2) in DVB. But apart from defining a scheme how
> an RTP receiver can in-band communicate the port(s) it wants when a FB
> target also acts as sender (i.e. the port mapping proposal), what else
> needs to be addressed in such a draft? Can you explain that?
>

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Fri, 22 Jan 2010 12:23:15 -0600

Regarding delaying/randomizing the RAMS-R-

If we introduce mandatory machinery to delay/randomize RAMS-R messages,
we are defeating the purpose of the protocol. The intent is to reduce
the stream acquisition time. The typical design goal is to reduce
acquisition time from something on the order of a few seconds to
something on the order of a second (or less). 

Note that even in the absence of RAMS, there are non-trivial scaling
constraints on the IGMP/MLD bursts.
In the use case that most people are considering (IPTV), there is a
natural temporal correlation between stream acquisition events. They
tend to cluster at event boundaries and at commercials. The system must
be scaled to either support the resultant traffic bursts or to degrade
gracefully in the event of a burst that is too large to handle. Once
again, this constraint exists for the IGMP/MLD case, whether RAMS is
used or not. 

Bill VerSteeg

-----Original Message-----
From: Ali C. Begen (abegen) 
Sent: Wednesday, January 20, 2010 2:52 PM
To: Magnus Westerlund
Cc: VAN CAENEGEM Tom; [email-masked]; Bill Ver Steeg (versteb)
Subject: RE: RTCP message semantics for RAMS, was [AVT] Discussion and

>    Tmin is initialized to 1.0 seconds.

Well, it is unfortunate that 4588 had that rule then. But delaying the
transmission of RAMS-R by Tmin actually does not help at all to avoid
the flash crowd problem you mentioned since the individual clients
operate independently. 
 
> reasonable parameters the Tmin can be set to zero, or to another
smaller

We have done a lot of analysis. It is a fact that there is a huge
correlation in the temporal domain if your consider channel changes in a
TV platform, but applying a Tmin delay does not offer any improvements.
The same correlation will be in effect when everybody delays their
RAMS-R messages by Tmin. Even if you randomize Tmin between say 0 and 1
second, it won't get you anything.

Correct. 
 
> this. I now this goes into dimensioning, but the issue needs
discussion.

Where do you think we should put this discussion? This really gets into
the implementation issues but I suppose somewhere we introduce the
RAMS-R message we can explain why we use Tmin=0.

-acbegen

---

From: Peilin Yang <[email-masked]>
Date: Mon, 25 Jan 2010 18:42:52 +0800

Hi all,

I also agree with Magnus's suggestion. The multi-SSRC SSM case should be considered in RAMS.
I remembered that Tom also has two alternatives as follows.
1a)add dedicated SSRC TLVs in RAMS-R message (and RAMS-I or RAMS-T) overruling the "media sender SSRC" field in the RTCP FB RAMS-R message. I do not see this as a conflict with RFC 4585.
1b)have the  RTP receiver issuing RAMS-R messages on a per SSRC basis.

IMO. I am more inclined to Magnus's approach to use a wild card to avoid the collision with actually used SSRC's in the session. Yet I also suggest to add a new TLV in RAMS-R message to indicate which SSRCs should be retransmitted. For example, we may use multiast group address of multicast session. 

I personally think  there is no actuall difference between RAMS-R and  IGMP/MLD essentially. Both of them implement channel change. The only difference is that RAMS-R implement fast channel change. Since  IGMP/MLD use multicast group address to switch from one multicast session to another. IMHO, we may use multiast group address of multicast session to indicate at the multi-SSRC case.  Yet, it will bring an issue, if multicast group address is used, RS must keep the multiast group information for every cached priamry multicast stream.

Best regards,
Peilin

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Magnus Westerlund
发送时间: 2010年1月22日 22:40
收件人: Ali C. Begen (abegen)
抄送: Tom Taylor; Roni Even; VAN CAENEGEM Tom; [email-masked]; Bill Ver Steeg (versteb)
主题: Re: [AVT] RTCP message semantics for RAMS, was Discussion and Proposals for RAMS draft supporting the multi-SSRC SSM case

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 26 Jan 2010 13:27:51 +0100

> As Roni suggested earlier, I believe we should add some explicit text into our port mapping draft so that it becomes *explicitly* a more generic solution.

Agreed

Magnus Westerlund
(As individual)

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 26 Jan 2010 13:31:10 +0100

> something on the order of a second (or less). 

I agree that it would be a contradicting to the goals to use it.
However, as I said you need to document the reasoning and motivation why
it SHALL NOT be used on the initial request.

> again, this constraint exists for the IGMP/MLD case, whether RAMS is

Yes, I agree with that there are limitations. You do need to describe
this in the document and provide an applicability statement for the RAMS
draft that makes this clears.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 26 Jan 2010 14:19:34 +0100

> IMO. I am more inclined to Magnus's approach to use a wild card to avoid the collision with actually used SSRC's in the session. Yet I also suggest to add a new TLV in RAMS-R message to indicate wh…

In the second sentence are you referring to RAMS-I?

I fully support that SSRCs that is going to be part of the burst needs
to be included in some RAMS-I message. However, I don't understand why
you write "Retransmission", did you mean burst here?

I don't understand what you mean with the last sentence: "For example,
we may use multiast group address of multicast session."

> I personally think  there is no actuall difference between RAMS-R and  IGMP/MLD essentially. Both of them implement channel change. The only difference is that RAMS-R implement fast channel change.…

I do not share your view here. There is big difference between IGMP/MLD
that operates on IP and Routing level and which dodges all the transport
questions. As RAMS-R is being worked on in the transport level and as a
RTP mechanism on RTP session level there are big differences.

When joining a Multicast group containing for example a TV-channel you
will get all the RTP sessions and all the RTP streams present in case of
multiple SSRC sending within a RTP session sent on the multicast group.
That is a big contrast with the RAMS that as previously specified worked
on a single SSRC level. Where we now is working towards a multi-SSRC
solution that do at least enables RAMS to work consistently on RTP
session level. Bringing IGMP and RAMS closer in functionality. But there
is still a gap between IGMP on multicast level and RAMS on RTP session
level that will operate on multicast+UDP port.

Cheers

Magnus Westerlund

---

From: Peilin Yang <[email-masked]>
Date: Wed, 27 Jan 2010 13:53:39 +0800

Hi Magnus,

Thank you very much for replying my comments.

You are right. RAMS-I  needs  a wild card to avoid the collision. 
Actually, I think RAMS-R also needs a dedicated information to indicate a RTP session with multiple SSRC. If we still use a "media sender SSRC" in RAMS-R to stand for all multi-SSRC. It also bring the collision unless there is an "explict" text to clarify the multi-SSRC case compared to  a single SSRC in RS.  

Regards,

Peilin

-----Original-----
发件人: Magnus Westerlund [mailto:[email-masked]] 
发送时间: 2010年1月26日 21:20
收件人: Peilin Yang
抄送: 'Tom Taylor'; 'Roni Even'; 'VAN CAENEGEM Tom'; [email-masked]; 'Bill Ver Steeg (versteb)'; 'Ali C. Begen (abegen)'
主题: Re: [AVT] RTCP message semantics for RAMS, was Discussion and Proposals for RAMS draft supporting the multi-SSRC SSM case

I fully support that SSRCs that is going to be part of the burst needs to be included in some RAMS-I message. However, I don't understand why you write "Retransmission", did you mean burst here?

I don't understand what you mean with the last sentence: "For example, we may use multiast group address of multicast session."

> I personally think  there is no actuall difference between RAMS-R and  IGMP/MLD essentially. Both of them implement channel change. The only difference is that RAMS-R implement fast channel change.…

I do not share your view here. There is big difference between IGMP/MLD that operates on IP and Routing level and which dodges all the transport questions. As RAMS-R is being worked on in the transport level and as a RTP mechanism on RTP session level there are big differences.

When joining a Multicast group containing for example a TV-channel you will get all the RTP sessions and all the RTP streams present in case of multiple SSRC sending within a RTP session sent on the multicast group.
That is a big contrast with the RAMS that as previously specified worked on a single SSRC level. Where we now is working towards a multi-SSRC solution that do at least enables RAMS to work consistently on RTP session level. Bringing IGMP and RAMS closer in functionality. But there is still a gap between IGMP on multicast level and RAMS on RTP session level that will operate on multicast+UDP port.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 27 Jan 2010 09:12:06 +0100

> Actually, I think RAMS-R also needs a dedicated information to indicate a RTP session with multiple SSRC. If we still use a "media sender SSRC" in RAMS-R to stand for all multi-SSRC. It also bring…

So I envision a wild card in RAMS-R messages with a possible TLV to make
it clear that you handle multi-SSRC cases for backwards compatibility.

The RAMS-I needs to indicate the SSRCs that will be sent in the burst. I
do have a preference for one RAMS-I message with TLVs to carry the SSRC
specific information.

I think we are in agreement. I think the right thing to do now is to
await a draft update that takes this discussion into account. Then we
can see if there are finer points in the text that we do want discuss
and propose alternative wording on.

Magnus Westerlund

---

From: Peilin Yang <[email-masked]>
Date: Thu, 28 Jan 2010 14:38:54 +0800

Agree.

Best regards,

Peilin
-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Wednesday, January 27, 2010 4:12 PM
To: Peilin Yang
Cc: 'Tom Taylor'; 'Roni Even'; 'VAN CAENEGEM Tom'; [email-masked]; 'Bill Ver
Steeg (versteb)'; 'Ali C. Begen (abegen)'
Subject: Re: [AVT] RTCP message semantics for RAMS, was Discussion and
Proposals for RAMS draft supporting the multi-SSRC SSM case

Peilin Yang skrev 2010-01-27 06:53:
> Actually, I think RAMS-R also needs a dedicated information to indicate a
RTP session with multiple SSRC. If we still use a "media sender SSRC" in
RAMS-R to stand for all multi-SSRC. It also bring the collision unless there
is an "explict" text to clarify the multi-SSRC case compared to  a single
SSRC in RS.  

So I envision a wild card in RAMS-R messages with a possible TLV to make it
clear that you handle multi-SSRC cases for backwards compatibility.

The RAMS-I needs to indicate the SSRCs that will be sent in the burst. I do
have a preference for one RAMS-I message with TLVs to carry the SSRC
specific information.

I think we are in agreement. I think the right thing to do now is to await a
draft update that takes this discussion into account. Then we can see if
there are finer points in the text that we do want discuss and propose
alternative wording on.

Magnus Westerlund