Subject: [AVT] Comments on draft-ietf-avt-rtp-rapid-acquisition-for-rtp-05

From: Magnus Westerlund <[email-masked]>
Date: Wed, 09 Dec 2009 13:16:13 +0100

Hi,

I have reviewed draft-ietf-avt-rtp-rapid-acquisition-for-rtp-05 and have
some comments and questions. I have seen that the AVT list has received
more emails about this draft. I haven't read these yet. So if there are
duplication of issues you know why.

0. I now this is way to late to change anything. However, I wished that
AVT had done the RAMS protocol as a stand alone protocol. It is
primarily a protocol for dynamically establishing RTP sessions and a bit
of synch information. It is much more related to RTSP than RTP. Not that
RTSP is an obvious fit either. Using RTCP as a way of creating new RTP
sessions isn't a good fit. For example most of the security functions
for RTP and RTCP are based on the signaling to establish the right
contexts. Another issue is the need to know the SSRC, while you are
trying to rapidly aquire a whole RTP session, not a single media stream.
I think we will find more issues with this as RAMS are elaborated on.

1. Section 1.

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

I am reacting to "the SSRC of the session". Are you refering to the
media server(s) of the session? or the SSRC of the SSRC of the
Retransmission server? I am guessing the media servers. Please clarify
this and also make the text clear that there might be multiple media
sources (SSRCs).

2. Section 3:

Primary Multicast Stream: this is written in a form that indicates that
there can be only one. That is not an acceptable limitation for a
generic RTP solution. If you anyway are going with that limitation you
need to make that very clear. But I do object against making this limited.

3. Section 6.2, figure 2:

Isn't there missing RTCP flows from the RTP_RX towards the RS?

4. Section 6.2: Please make it clear that there might be multiple media
flows and how that is going to be handled. The interesting issue here is
that the burst are requested on a per SSRC basis, while the join is for
the whole session.

5. Section 6.2:

   9.  Terminate with RTCP BYE:  When RTP_Rx is receiving the burst, if
       RTP_Rx becomes no longer interested in the primary multicast
       stream, RTP_Rx SHALL issue an RTCP BYE message for the RTP
       retransmission session and another RTCP BYE message for the
       primary multicast session.

I think "no longer interested" is very sloppy language. RTCP BYE is only
to be sent when the receiver leaves the RTP session. If I understand
things correctly RTP session between the RS and the RTP_RX is only for a
particular acquisition. However, I think you need to clarify when you
expect to terminate the session. What about cases when you zapp back and
forth between two channels. Are there points in keeping an aquistion RTP
session around? Otherwise there might be interesting conflicts between
messages in flight if one channel change is terminated and another
initiated due to aggressive channel zapping.

Thus I think this should be clarified to say when the RTP_Rx and the RS
leaves and terminates the RTP session.

6. Section 6.3:

The proposal contains non-precise recommendations and many options.
Which will be a concern from congestion control perspective. You are not
even mandating mid-timescale usage of RTCP RR to control bursts and
detect failures resulting in bandwidth availability is not as expected.
As I see it even for controlled environments there is a need for the RS
to listen to RTP_Rx RTCP RRs for the burst and see that it is delivered
as planned. To make this practical the RTCP bandwidth and reporting for
the RTP_Rx need be configured well. AVPF, changed minimal interval seems
very appropriate for to monitor so that there are no failures.

7. Section 7.1.2:
"A certain range of TLV Types is reserved for private extensions
   (Refer to Section 12.5)."

Why not write out the range here?

8. Section 7.2:

Optional TLV element
      that denotes the minimum milliseconds of data that RTP_Rx desires
      to have in its buffer before allowing the data to be consumed by
      the application.

What is milliseconds of data? Are the amount of data measured in time to
nominally send the data, nominally receive it, or the nominal amount of
media playback time it represents?

9. Section 7.2: When it comes to buffering requirements in general they
are measured in time, while buffer implementations will either be total
byte restricited, with a implementation specific per packet overhead or
limited in number of packets if a more fixed per packet structured is
used. How did you come to the conclusion that time was a reasonable
measurement?

10. Section 7.2: Max Receive rate. Wouldn't a token bucket model be of
more utility to describe how the RS is allowed to burst at max? With
only a rate, the burstiness of the transmission is not made clear at
all. Applies also to Section 7.3 and the Type 34 message.

11. Section 7.4:    Extended RTP Seqnum of First Multicast Packet (32
bits):

If I understand this correctly this would be the extended RTP sequence
number for the new media stream that we attempts to do catch up with.
Thus, only the 16-bit from the first packet plus the number of wraps in
the burst is what is counted here? I would also assume that if one
leaves this media streams and later rejoins, these counters will have
been zeroed due to having terminated that session and later restarting
it. Are my assumptions correct? And should it be made more clear?

12. Section 8.1
   This document also defines a new SDP attribute ('rams-updates') that
   indicates whether RS supports updated request messages or not.

Is this attribute a media or a session level attribute or both? I did
find the answer in the IANA template. But please make it clear also in
this section.

13. The draft does not appear to discuss if you are allowed to use the
same feedback target (address+port) for multiple RTP sessions. As they
are regular RTCP feedback targets for the session I think that would be
unwise, although maybe possible to work with unique SSRCs over all these
sessions. However, it is likely to be fragile and difficult to configure
correctly. I think the intentions here must be made clear so that we
don't get interoperability issues due to different assumptions. That
both concerns the feedback targets and the unicast repair session
configurations.

14. Section 9: Why isn't this recommending RTP and RTCP muxing for the
RAMS session? That way the RTP_Rx to RS RTCP traffic will create the
binding and keep it alive, and the RS only needs to invert the address
information from RTCP when sending the retransmission data packets? Yes,
I understand that if the network lacks good source address validation
there is an attack vector. But even if Ali Begans draft proposes
extensions to make solve this security issues, it is no worse than what
is currently specified.

15. Section 11. Why does not the security consideration press harder the
need for source address validation for networks deploying RAMS. It is a
big difference in the attacks that can be performed if an attacker can't
insert spoofed source addresses or not.

16. Section 7.3:

   o  Earliest Multicast Join Time (32 bits):  Optional TLV element that
      specifies the time difference (i.e., delta time) between the
      arrival of this RAMS-I message and the earliest time instant when
      RTP_Rx could join the primary multicast session in RTP ticks.  A
      zero value in this field means that RTP_Rx can join the primary
      multicast session right away.

What is meant by joining? The time the RTP_Rx sends the IGMP message or
when the IGMP message should arrive at the next hop router, or when the
join operation is completed?

17. Missing examples of complete RAMS packets with multiple TLVs. I also
think a more complete system example with a timeline and the different
messages would be really helpfull here.

Cheers

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: Wed, 9 Dec 2009 09:25:38 -0800

Hi Magnus,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
> Sent: Wednesday, December 09, 2009 7:16 AM
> To: IETF AVT WG; [email-masked]
> Subject: [AVT] Comments on draft-ietf-avt-rtp-rapid-acquisition-for-rtp-05
> 
> Hi,
> 

Remember that we are using the whole retransmission architecture for RAMS to minimize the need for additional work.

> I think we will find more issues with this as RAMS are elaborated on.

You should read the existing emails. SSRC has been discussed a lot already and we will make some changes regarding it.

BTW, I'd like to propose a small change in the title. We are rapidly acquiring RTP streams not sessions. So, if there are no objections, I suggest we change the title.
 
> this and also make the text clear that there might be multiple media

The media source SSRC of the RTP stream we want to rapidly acquire. In the last meeting we discussed this and keeping a consistent SSRC for each source stream might be difficult in certain deployments. We will make changes in the draft.
 
> need to make that very clear. But I do object against making this limited.

There is no limitation. There can be multiple RTP streams within the same multicast group. But, RAMS is per stream. IF there are two streams you want to rapidly acquire, you run two RAMS sessions.
 
> Isn't there missing RTCP flows from the RTP_RX towards the RS?

We already show them. There is no arrow next to the router since the router is not the consumer of such messages.

> that the burst are requested on a per SSRC basis, while the join is for

Right. This is discussed in http://tools.ietf.org/html/draft-begen-avt-rams-scenarios-00

The note you want is at the end of Section 8. I believe when we should change the draft tile and put a note in the introduction, too.
 
> I think "no longer interested" is very sloppy language. RTCP BYE is only

What do you suggest?

> session around? Otherwise there might be interesting conflicts between

No, if that acquisition is canceled, the session is killed. 

> initiated due to aggressive channel zapping.

Indeed. 
 
> very appropriate for to monitor so that there are no failures.

Well, if desired, the receiver may send an updated RAMS-R with updated bitrate for example. While the current draft mentions the possibility of doing retransmissions on the lost burst packets, I agree with your comments that the specifics are not detailed to develop a working model. Doing retransmissions on the burst packets actually complicates a lot of things, increases delay (which is aimed to be reduced), results in changes in the burst transmission causing changes in the join time, burst completing time, etc. We might wanna re-consider our text about doing such retransmissions.
 
> Why not write out the range here?

Sure.
 
> media playback time it represents?

Good question. And I'd think it would depend on the application.

Generally speaking, it should be the time to send the data (which should be equal to the time to receive it). Think of it for generating enough buffer for retransmissions, FEC, de-jittering, etc.

> used. How did you come to the conclusion that time was a reasonable

There was a thread about this a few months ago. Since the average bitrates are known prior to bursting, time domain requirements made more sense.
 
> all. Applies also to Section 7.3 and the Type 34 message.

Right, it does not address the burstiness of the burst. But, the stuff we are sending is already a burst. As long as the server does not exceed it, the receiver should be ok.
 
> the burst is what is counted here? I would also assume that if one

Yes. That is my intention.

> it. Are my assumptions correct? And should it be made more clear?

Correct.
 
> find the answer in the IANA template. But please make it clear also in

OK.
 
> both concerns the feedback targets and the unicast repair session

This relates to the SSRC discussion. I believe that FTs should be unique per RTP stream (in this case, we don't need to signal SSRCs in the SDP and we don't need to coordinate potentially a large number of sources). If FTs are shared, one has to make sure that the SSRCs are different for those streams and they need to be known accurately by the receivers (signaling them in the SDP is a requirement in this case).

This was discussed in http://tools.ietf.org/html/draft-begen-avt-rams-scenarios-00 and presented in the last meeting.

Currently, the RAMS draft does not say much about this. But, I believe we need to make these very clear in the revision. See the email thread for wording suggestions.
 
> extensions to make solve this security issues, it is no worse than what

Our other draft addressing this issue will have a strong recommendation for muxing. But to make things work, muxing is not mandatory.

> insert spoofed source addresses or not.

The spoofed addresses are a big problem for anything, right? They need to be dealt with regardless of RAMS exists or not.
 
> join operation is completed?

The former. When the receiver sends the IGMP join message.
 
> messages would be really helpfull here.

This sounds like a good idea.

Thanks,
-acbegen

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 10 Dec 2009 13:28:47 +0100

Hi Ali,

More comments around your response. I have removed issues where we seem
to be in agreement.

> Remember that we are using the whole retransmission architecture for RAMS to minimize the need for additional work.

Yes, but that could still have been possible. What I dislike is the
usage of RTCP for session creation. But, my comment is 2 years to late.

> You should read the existing emails. SSRC has been discussed a lot already and we will make some changes regarding it.

Yes, I have read up on Michael's thread. I wasn't clear on what the
final outcome is here. However, I similar issues about how the RTP
sessions are mapped between SSM and what is generated by the RS and how
feedback targets are handled was evident in that discussion.

> BTW, I'd like to propose a small change in the title. We are rapidly acquiring RTP streams not sessions. So, if there are no objections, I suggest we change the title.

That is probably correct from a solution stand point. But I don't know
how you arrived at that limitation compared to what I would expect the
requirement to be. That would be to rapidly join the RTP session sent
over SSM. Not single media streams within the RTP session.

> The media source SSRC of the RTP stream we want to rapidly acquire. In the last meeting we discussed this and keeping a consistent SSRC for each source stream might be difficult in certain deployme…

Thanks, clarification was all I asked for.

> There is no limitation. There can be multiple RTP streams within the same multicast group. But, RAMS is per stream. IF there are two streams you want to rapidly acquire, you run two RAMS sessions.

Here I think it is important that the draft makes it clear this fact. We
have lots of evidence that implementors do not understand that there
might be multiple SSRCs in a session and how to handle that. I do expect
certain deployments to make limitations here, but not the IETF
specification.

I don't understand what RAMS sessions are. Lets look a bit more into this..

A SSM session has two SSRCs, SSRC-S1, and SSRC-S2.

The RTP_Rx will then send two RAM-R RTCP packets to RS on the RS A:P
provided as feedback target for that SSM session.

Will these two requests result in one or two RTP sessions between the RS
and RTP_Rx? I would say a single one as they are related to a single RTP
session. However, that require that you make it clear that the same
RTP_Rx source ports and address are used for both RAMS-R requests.

There are several details in this that are important for both
interoperability and functionality. If we specify this wrongly now it
will result in limitations on RTP sessions in the future. That is why I
care so much about this.

> We already show them. There is no arrow next to the router since the router is not the consumer of such messages.

Okay, I see the arrow from the router to the RS, but without the arrow
from the RTP_Rx it is not clear that it is the origin of the RTCP flow
rather than the Router.

> The note you want is at the end of Section 8. I believe when we should change the draft tile and put a note in the introduction, too.

I think you need to discuss this in this document. You can't put this
off. Multiple SSRCs are a core functionality of RTP. Please make the
document clear on how to handle them.

>> leaves and terminates the RTP session.

I would make clear the criteria for the termination of the RTP session
between the RS and RTP_RX and how that is accomplished. It seems that
you shouldn't terminate the session while still having outstanding RAMS
request. Also ongoing burst should be terminated before terminating the
RTP session. Then sending RTCP BYE.

Due to that a client can resuse its source address and port, we can have
new RTP sessions where there just one terminated. This needs
consideration also. Especially in regards to RTCP state.

> Well, if desired, the receiver may send an updated RAMS-R with updated bitrate for example. While the current draft mentions the possibility of doing retransmissions on the lost burst packets, I ag…

This is not only a question about retransmission. But also of monitoring
and the need to react on when there are evidence of congestion.

> Generally speaking, it should be the time to send the data (which should be equal to the time to receive it). Think of it for generating enough buffer for retransmissions, FEC, de-jittering, etc.

Yes, I agree that it difficult. However, the current specification does
not define what the time really is. If you are going to instrument the
implementation to measure how well this element is meet. Then what are
the events that are instrumented?

Clear definition is needed.

> There was a thread about this a few months ago. Since the average bitrates are known prior to bursting, time domain requirements made more sense.

I agree that the RS can measure this more easily. However, the receiver
can't easily convert it into a buffer requirement. But maybe the
uncertainty of up to 50% of actually needed memory is not a big issue?

> Right, it does not address the burstiness of the burst. But, the stuff we are sending is already a burst. As long as the server does not exceed it, the receiver should be ok.

Okay, can you make clear what timescales you expect the averaging to be
on when considering the bit-rate?

> This relates to the SSRC discussion. I believe that FTs should be unique per RTP stream (in this case, we don't need to signal SSRCs in the SDP and we don't need to coordinate potentially a large n…

I disagree with you somewhat. I think the right choice is to have one FT
(specific Adress+Port) per SSM transmitted RTP session. The SSM
extension does not allow you to define a RTCP feedback target on the
granularity of one SSRC within a RTP session.

Thus you will still have the issue of identifying the SSRC(s) in the RTP
session.

> Currently, the RAMS draft does not say much about this. But, I believe we need
to make these very clear in the revision. See the email thread for
wording suggestions.

I am awaiting text on this as I didn't clearly understand what was proposed.

> Our other draft addressing this issue will have a strong recommendation for muxing. But to make things work, muxing is not mandatory.

You mean to make the backwards compatible with what is out in the field?

> The spoofed addresses are a big problem for anything, right? They need to be dealt with regardless of RAMS exists or not.

Yes, source address validation is important. However, here you might
need to do it closer to the sender than you might be doing in other
cases. And source address valdidation has last I heard something only
deployed for around 1/4 of all IPv4 addresses. As the protocol is
vulnerable if source address validation isn't present I think you should
point out the need for it to protect against certain attacks.

> The former. When the receiver sends the IGMP join message. 

Ok, please make this clear in the document.

> This sounds like a good idea.

Great

Thanks

Magnus Westerlund

---

From: Joshua Gahm <[email-masked]>
Date: Thu, 10 Dec 2009 08:45:51 -0500

Ali -

One comment inline, regarding item 6.

On Dec 9, 2009, at 12:25 PM, Ali C. Begen (abegen) wrote:

> Remember that we are using the whole retransmission architecture for  
> RAMS to minimize the need for additional work.
>
> You should read the existing emails. SSRC has been discussed a lot  
> already and we will make some changes regarding it.
>
> BTW, I'd like to propose a small change in the title. We are rapidly  
> acquiring RTP streams not sessions. So, if there are no objections,  
> I suggest we change the title.
>
>> 1. Section 1.
>>
> The media source SSRC of the RTP stream we want to rapidly acquire.  
> In the last meeting we discussed this and keeping a consistent SSRC  
> for each source stream might be difficult in certain deployments. We  
> will make changes in the draft.
>
>> 2. Section 3:
>>
> There is no limitation. There can be multiple RTP streams within the  
> same multicast group. But, RAMS is per stream. IF there are two  
> streams you want to rapidly acquire, you run two RAMS sessions.
>
> We already show them. There is no arrow next to the router since the  
> router is not the consumer of such messages.
>
>>
> The note you want is at the end of Section 8. I believe when we  
> should change the draft tile and put a note in the introduction, too.
>
>> 5. Section 6.2:
>>
> Well, if desired, the receiver may send an updated RAMS-R with  
> updated bitrate for example. While the current draft mentions the  
> possibility of doing retransmissions on the lost burst packets, I  
> agree with your comments that the specifics are not detailed to  
> develop a working model. Doing retransmissions on the burst packets  
> actually complicates a lot of things, increases delay (which is  
> aimed to be reduced), results in changes in the burst transmission  
> causing changes in the join time, burst completing time, etc. We  
> might wanna re-consider our text about doing such retransmissions.

I very much agree with your comment that allowing retransmissions to  
be sent during the RAMS burst makes a lot of things more complicated.   
I think the draft should simply prohibit sending of retransmissions  
during the burst.  This could be done by saying that the RTP Rx MUST  
or SHOULD not request retransmissions during the burst and the RS MUST  
or SHOULD not send retransmissions during the burst if requests are  
received.  If we do want to allow retransmissions to be sent during  
the burst, then the draft is going to have to specify if the RS MUST/ 
SHOULD/MAY revise the burst to allow "spaces" in which to send the  
requested retransmissions.  And if the RS revises the burst, if it  
MUST/SHOULD/MAY send an updated RAMS-I message to reflect the changes.

> Generally speaking, it should be the time to send the data (which  
> should be equal to the time to receive it). Think of it for  
> generating enough buffer for retransmissions, FEC, de-jittering, etc.
>
>
> There was a thread about this a few months ago. Since the average  
> bitrates are known prior to bursting, time domain requirements made  
> more sense.
>
> Right, it does not address the burstiness of the burst. But, the  
> stuff we are sending is already a burst. As long as the server does  
> not exceed it, the receiver should be ok.
>
> This relates to the SSRC discussion. I believe that FTs should be  
> unique per RTP stream (in this case, we don't need to signal SSRCs  
> in the SDP and we don't need to coordinate potentially a large  
> number of sources). If FTs are shared, one has to make sure that the  
> SSRCs are different for those streams and they need to be known  
> accurately by the receivers (signaling them in the SDP is a  
> requirement in this case).
>
> Currently, the RAMS draft does not say much about this. But, I  
> believe we need to make these very clear in the revision. See the  
> email thread for wording suggestions.
>
> Our other draft addressing this issue will have a strong  
> recommendation for muxing. But to make things work, muxing is not  
> mandatory.
>
>
> The spoofed addresses are a big problem for anything, right? They  
> need to be dealt with regardless of RAMS exists or not.
>
>> 16. Section 7.3:
>>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 10 Dec 2009 07:43:06 -0800

> or SHOULD not send retransmissions during the burst if requests are

I am fine with either (MUST NOT or SHOULD NOT).

> MUST/SHOULD/MAY send an updated RAMS-I message to reflect the changes.

I believe this is a too complex topic to define the rules that will make the different implementations co-exist nicely in a deployment. We should allow retransmissions only after the burst is completed so that the burst will not be affected (and there won't be any need for a new RAMS-I) by any such request from the receiver.

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 10 Dec 2009 08:33:50 -0800

Hi Magnus,

> feedback targets are handled was evident in that discussion.

So, the revised text will remove the requirement for signaling the SSRCs in the SDP in deployments where each feedback target (Address+Port) serves for only one RTP stream. In such cases, we don't care whether the receivers know the SSRCs a priori. 

In contrast, if the feedback targets will serve for multiple RTP streams, they all need to have their unique SSRCs and these SSRCs must be signaled to the receivers before they send any request (in the SDP).
 
> >
> > BTW, I'd like to propose a small change in the title. We are rapidly acquiring RTP
> streams not sessions. So, if there are no objections, I suggest we change the title.
> >
> 

By design, RAMS is per RTP stream not session. If there are multiple RTP streams, they need to be acquired in different RAMS processes/sessions/bursts or whatever we wanna call it. I showed many examples in the draft (http://tools.ietf.org/html/draft-begen-avt-rams-scenarios-00).
 
> > There is no limitation. There can be multiple RTP streams within the same multicast
> group. But, RAMS is per stream. IF there are two streams you want to rapidly acquire, you
> run two RAMS sessions.
> 

I should not have used the word "session." 
 
> provided as feedback target for that SSM session.

Are these RTP streams only in the same SSM group but are destined to different ports or are they sent to the same multicast group and dest port?

If the former, there can be two different FTs. If the latter, we have a single FT that serves for both streams.
 
> RTP_Rx source ports and address are used for both RAMS-R requests.

If you have two different FTs, then you need to send two separate RAMS-R messages anyway. If you are running a single FT for both streams, you need to know their SSRCs (from the SDP) and put that info in again separate RAMS-R messages. 

A single RAMS-R request will not get you two separate bursts. This is by design. It gives you the flexibility of choosing the specific streams you want to get acceleration for. Also note that there is nothing stopping you from requesting multiple bursts concurrently. 

I'd certainly suggest you to read and comment on:
http://tools.ietf.org/html/draft-begen-avt-rams-scenarios-00 
 
> will result in limitations on RTP sessions in the future. That is why I

Could not agree more. Actually, the rams scenarios draft lists several things one can do with RAMS. But, the common feedback I received after the presentation was to make the best design approach very clear in the document and discourage the usage of other approaches by presenting their disadvantages.

> from the RTP_Rx it is not clear that it is the origin of the RTCP flow

Let me see what I can do about that.
  
> > The note you want is at the end of Section 8. I believe when we should change the draft
> tile and put a note in the introduction, too.
> 

See below.
 
> you shouldn't terminate the session while still having outstanding RAMS

The unicast session can be terminated at any desired time by sending BYE. RAMS-T only terminates the burst not the session.

> RTP session. Then sending RTCP BYE.

BYE terminates any existing burst transmission and then the session. So, I don’t think there is a problem here. If only the burst is desired to be terminated, we use RAMS-T. The session can be kept alive for possible retransmissions in the future.

> consideration also. Especially in regards to RTCP state.

Agree. After BYE is sent, some packets might still be received but they need to be discarded. Even a new RTP session is created via a new RAMS-R, those older packets will not match the new requested stream.
 
> > Well, if desired, the receiver may send an updated RAMS-R with updated bitrate for
> example. While the current draft mentions the possibility of doing retransmissions on the
> lost burst packets, I agree with your comments that the specifics are not detailed to
> develop a working model. Doing retransmissions on the burst packets actually complicates a
> lot of things, increases delay (which is aimed to be reduced), results in changes in the
> burst transmission causing changes in the join time, burst completing time, etc. We might
> wanna re-consider our text about doing such retransmissions.
> 

Doing sudden retransmissions during the burst will create this problem. The congestion may be due to other reasons and if the receiver can observe it (via packet loss), it can ask for a bitrate reduction but we previously agreed that the draft should not get into how the available bw could be accurately measured.

> > Generally speaking, it should be the time to send the data (which should be equal to the
> time to receive it). Think of it for generating enough buffer for retransmissions, FEC,
> de-jittering, etc.
> >
> 

The requirement here is that if such a TLV exists, the server needs to make sure that the burst it will send will be able to accumulate at least this much data on the receiver side before the data is sent to the application. Of course, the receiver may always delay the delivery to the app layer but that adds up more delay. If the server has multiple options to start the burst from, it should select the one that provides the fastest acquisition while respecting the receiver's needs.
 
> > There was a thread about this a few months ago. Since the average bitrates are known
> prior to bursting, time domain requirements made more sense.
> >
> 

It may or may not be. 
 
> > Right, it does not address the burstiness of the burst. But, the stuff we are sending is
> already a burst. As long as the server does not exceed it, the receiver should be ok.
> 

I suppose the best we can say that the burst is sent at a constant bit rate not to exceed the limit specified in this TLV.
 
> > This relates to the SSRC discussion. I believe that FTs should be unique per RTP stream
> (in this case, we don't need to signal SSRCs in the SDP and we don't need to coordinate
> potentially a large number of sources). If FTs are shared, one has to make sure that the
> SSRCs are different for those streams and they need to be known accurately by the
> receivers (signaling them in the SDP is a requirement in this case).
> >
> 

Right, it does not. But, that brings me back to the point that SSRC-muxing does not play well here. It requires you to know the SSRCs before making any request. Assuming that you know the SSRCs, each SSRC must be independently accelerated. The control signaling in RAMS requires this.
 
> Thus you will still have the issue of identifying the SSRC(s) in the RTP

The only way to identify them is to signal them in the SDP.
 
> I am awaiting text on this as I didn't clearly understand what was proposed.

The text will be very similar to what I wrote earlier in this email.
 
> > Our other draft addressing this issue will have a strong recommendation for muxing. But
> to make things work, muxing is not mandatory.
> >
> 

Right.
 
-acbegen

---

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

Hi Ali,

I had a number of issues that I liked to follow up. I have split them
into different emails to make the discussion easier.

Cheers

Magnus Westerlund

---

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

Hi,

The long email with repeated discussion become to difficult to follow.
So I have split the discussion into individual topics:

This email concerns about the RTP session definition in the face of
RAMS. I think it is very important to make this clear as it affects how
RTP and RTCP should be correctly used.

Lets start out with the really high level definition of an RTP session:
All RTP and RTCP packets that relate to a joint SSRC space.

In Any Source Multicast that is usually all packets sent to a particular
multicast address and one port for RTP and one for RTCP. For SSM this
are still true but it also includes all the RTCP sent to the feedback
targets.

When you add RAMS it appears that you are in fact also adding the RTP
and RTCP traffic that is sent from the feedback target (RS) to the RTP
receiver as they are operating in the same SSRC space. In summary the
RTP session consist of the following type of flows:

1. RTP flows from Media sender over SSM to multicast address A1 and port
 A1p1.
2. RTCP flows from Media Sender over SSM to multicast address A1 and
port A1p2
3. For each receiver the RTCP flow from RTP_Rx to RTCP feedback target
(RS) present at unicast address A2 and port p3.
4. The RTCP flow from RS to RTP_Rx
5. The RTP flow from RS to RTP_Rx

I think that makes sense as type 5 flows are either a repair stream or
an join burst directly related to type 1 flows. The type 3 flow is
reporting or making request related to the whole session. It will
contain reports on both type 1 flows and the type 5 flow.

Seen from this perspective the RAMS request does not actually create a
new session. It requests a temporarily deliver session that is the type
5 flow. Thus I am disagreeing with what the document currently says. The
document states that there is one RTP session over SSM with a feedback
target for RTP_Rx RTCP (flows 1,2, and parts of 3), and another that is
for the Retransmissions and Bursts (Flows 4 and 5, and parts of 3).
However, as there is a sharing of the RTP_RX to RS RTCP channel I don't
see other than they needs to be considered together and being a joint
session.

The flows of type 4 and 5 has an unusual property. They are only
temporarily existing and does not exist prior to a RAMS-R or NACK
requesting a transmission. The big question here is a well handled
creation and termination of them. Here I think we need to separate the
cases when there is retransmission or not.

The issue with creation is both ensured delivery in the cases of
existence of NAT/FW and such that it doesn't open up for using the RS as
a denial of service tool.

The issue with termination is that if an RS deletes its states and then
quickly reuses the same SSRC the RTP_Rx may still have state for that
source. That can become very confusing for the client if RTP sequence
number jumps backwards etc. I see two alternative for the RS. Either
keep the state around for longer than 5 reporting intervals after last
transmission of either RTP or RTCP. That would ensure that any
subsequent request from that client are looking like two really
consecutive bursts with consistent reporting or timeout and
re-establishement. The second is to remember the SSRC value used and
don't reuse that for a long enough period.

Without retransmission:
Flow Creation: RAMS-R.
Flow Termination: After completing the burst. The RS sends an final RTCP
SR report and an RTCP BYE for the RS's SSRC. The RTCP_Rx will timeout
any state sometime later.

With Retransmission:
Flow Creation: RAMS-R or NACK. Here I think that creation of the flow
using NACK has some clear flaws. The issue is determining the RTP_Rx
address and ports for the RTP and RTCP flows. Where we have the space to
extend the RAMS messages to handle what is necessary for binding the
address, that seems impossible for the NACK. Thus, it appears that one
would require to use RAMS messages to first create the delivery channel
to the RTP_Rx before issuing a NACK.

Also termination here is much more complicated. If the RTP_Rx want to
continue to use the established channel for any NACKs then that needs to
be handled. Explicit signaling of that preference seems appropriate.
Although certain soft-state solutions may also work. Also here the
NAT/FW traversal needs to be taken into account. Keeping the channel
open will be the main challenge.

I think the most straight forward is explicit signalling in the RAMS-R
to indicate if the request is for a channel or a burst or both.
Secondly, the RAMS part needs to enable both the RTP_Rx and the RS to
request, or indicate closure of the channel.

Summary:

1. Need to come to conclusion what the RTP session(s) really includes
2. The sending of RTCP BYE for the RS SSRC needs to be clarified
3. Clear rules about when the delivery channel from the RS to the RTP_Rx
is created and how it is terminated.
4. Figure out what the best way is to establish the delivery channel for
NACK usage.

Regards

Magnus Westerlund

---

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

This mail concerns congestion control and adaptation.

I know this is a complex topic. However, I am quite convinced that you
will not get through IESG without significantly more clear discussion of
this in the document. First of all you need to be clear about the
assumptions that you are working under. Even in a controlled environment
there should be safeguards. I think well configured RTCP bandwidths (and
thus intervals) and reporting on the flows by the RTP_Rx using regular
RTCP RR is a mandatory to implement monitoring. When I say well
configured, I would expect one RTCP report every 2-5 RTTs, maximum every
10. Considering that we are talking about streams in most cases of more
than 1 mbps that RTCP bandwidth isn't that much. It is also going
upstream compared to the media.

If the RS detects an significant issue it needs to adapt the burst
bandwidth down and update the target when it finish delivery. I think
you have the RAMS mechanism necessary for that. Just bring that together
in the text.

Cheers

Magnus Westerlund

---

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

Hi,

This email concerns NAT/FW traversal and indication of where the RS's
RTP stream is going. .

Even if it has been discussed in the group I think we all will make a
huge error if we don't ensure that this works from day one. That as the
complexities on the solution is highly dependent on how the basic
solution looks like. I think there are details in the current proposals
that makes things much more difficult or complex.

First of all the current (non-solution) for specifying where the burst
and any retransmissions are going to be sent is based on media sender
side picking ports. I don't see this working at all. That as there are
no method for the dynamically associating this. Static configuration
does also not work, because you don't need a single port. You need two
port for each tv-channel you are going to listen to. Unless you use
different sessions for different channels you risk that the RTP_Rx can't
separate the traffic from different channels. Using the same port for
all different SSM groups would remove the multiplexing point between
sessions. Thus requiring SSRC coordination between RTP sessions.

This is basically ignoring the fundamentals of RTP.

I would definitely recommend to bring the dynamic acquisition into the
main draft. I would multiplex RTP and RTCP on the same port. That has
several benefits for the relatively low cost of an extra demux in the
receiver to separate the RTP and RTCP packets. The benefits are: Only a
single port and binding used, no risk of having one work and not the
other. It will also automatically be kept alive by RTP_Rx to RS RTCP
traffic. That will be sent more often than any timeout for UDP.

To gain sufficient security I would add a cookie. The RS would add its
cookie in the RAMS-I message. The RS cookie goes back in a new RAMS-C
(confirm) message. Unfortunately that delays the media transmission with
one RTT. That is similar to what Ali proposes in
draft-begen-avt-ports-for-ucast-mcast-rtp.

Regards

Magnus Westerlund

---

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

Hi,

This is a new issue that Joacim Halén, a colleague of mine found.

The issue arises if a RTP_Rx has tried terminating a burst by sending a
RAMS-T. However that RAMS-T message is lost. Then the RTP_Rx request an
RAMS-R for another burst. It seems very reasonable that a RS refuses to
accept the request when it already has an ongoing request. However, the
current response codes that exist are not a good match for this case. I
would assume that you would answer with a 504 or a 501 in that case.

My proposal is that a new response code is added:

508 Request denied due to already ongoing burst.

Regards

Magnus Westerlund

---

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

So, you are suggesting the ret server needs to adjust the burst bitrate depending on the receiver reports sent by the receiver. Sure, but remember that the bursts typically will not be much longer than 5-10 RTTs, so that kind of adaptation may not work in practice. Instead we allow updated RAMS-R messages that can have a "max receive bitrate" field to notify the server, which is a faster way to do rate adjustments.

Cheers, acbegen.

> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Friday, December 11, 2009 11:31 AM
> To: Ali C. Begen (abegen)
> Cc: IETF AVT WG
> Subject: draft-ietf-avt-rtp-rapid-acquisition-for-rtp-05: Congestion Control
>

---

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

Hi Magnus,

> Subject: draft-ietf-avt-rtp-rapid-acquisition-for-rtp-05: Error code due to ongoing
> requests
> 
> Hi,
> 

FYI, RAMS-T may be sent multiple times.

> accept the request when it already has an ongoing request. However, the

Well, how do we know that the receiver is not actually interested in two different streams? This certainly can be the case. A single is asking for multiple RAMS requests or multiple receivers behind the same NAT (sharing a public IP) doing independent RAMS requests.

> 508 Request denied due to already ongoing burst.

We can add this, np. But, the server has to make sure that the new request is somehow overriding any existing on-going request, which is actually something we can't make sure IMO.

-acbegen

---

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

Hi Magnus,

> Cc: IETF AVT WG; [email-masked]
> Subject: draft-ietf-rtp-rapid-acquisition-for-rtp-05: RTP session considerations
> 
> Hi,
> 

Right. 
 
> RTP session consist of the following type of flows:

We consider two sessions in RAMS. One for the primary video and its RTCP reports (sender and receiver). The other one is the unicast (retransmission) session between RS and the receiver.

See slide 4 of:
http://tools.ietf.org/agenda/76/slides/avt-12.pdf 

The red and green denote different sessions. The green session is established upon a feedback (nack or rams-r) sent in the red session. 
 
> 2. RTCP flows from Media Sender over SSM to multicast address A1 and

Just like in the slide above.

> (RS) present at unicast address A2 and port p3.

The port on the feedback target is also p2, right?

> 4. The RTCP flow from RS to RTP_Rx

This is a two-way RTCP.

> 5. The RTP flow from RS to RTP_Rx

Indeed. This is one way.
 
> contain reports on both type 1 flows and the type 5 flow.

Flow 3 (the unicast feedback on the primary/red session) only carries the stuff related to the primary multicast stream, not the unicast burst or retransmission stream. To send feedback on the unicast stream, we use flow 4.
 
> see other than they needs to be considered together and being a joint

I respectfully disagree. I understand the unicast session (as I refer to it) is strongly tied to the primary session (as I refer to it), but considering them one big session complicates many things and does not bring any advantages. 
 
> quickly reuses the same SSRC the RTP_Rx may still have state for that

If the unicast session is terminated for some reason, the next NACK will re-instantiate it as a new session. But, under normal conditions, that session will stay alive due to ongoing NACKs/retransmissions or keep-alive messages, but it does not have to.

> number jumps backwards etc. I see two alternative for the RS. Either

Yeah. If the receiver uses the same port pair (RTP/RTCP) in every unicast session, there is a possibility that the RTCP session may stay alive on the server side because of a lost BYE. And when the receiver comes back to the same FTAp (e.g., it zapped away and zapped back in), the remaining RTCP stats, seqnums may confuse the receiver.

To address this, we allow multiple BYEs to be sent. And furthermore, the client may use different port pair for every new unicast session. However, this may increase the delay when/if we implement the cookie proposal for NAT traversal.

> consecutive bursts with consistent reporting or timeout and

You are trying to overcome the problems associated with losing the BYE message, which should happen rarely.

> don't reuse that for a long enough period.

We do session multiplexing between the primary session and unicast session. So, the SSRC the server will use will be the same.
 
> any state sometime later.

This session does not have to be terminated. From this viewpoint, I don't see any difference between starting that session with a nack or rams-r.
 
> to the RTP_Rx before issuing a NACK.

What about the receivers who are only retransmission-capable but not rams-capable? For them, the unicast session will be created when the server receives a NACK and responds to it. This has nothing to do with this draft. There will be receivers out there in the field that will only support RTCPSSM and RFC 4588.
 
> be handled. Explicit signaling of that preference seems appropriate.

Why? If the receiver does not send a BYE, the session will stay open. The server will drop the state after 5 RTCP intervals unless it hears back from the receiver.

> open will be the main challenge.

What about keep-alives?

> 4. Figure out what the best way is to establish the delivery channel for

Thanks for the very insightful comments. I hoped I provided good responses. I believe, if we can agree on the "session" definition here, we can address all the issues fairly easily.

Cheers, acbegen.

---

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

Hi Magnus,

> Subject: draft-ietf-avt-rtp-rapid-acquisition-for-rtp-05: NAT/FW traversal
> 
> Hi,
> 

I believe the current draft captures the design points fairly well.
http://tools.ietf.org/html/draft-begen-avt-ports-for-ucast-mcast-rtp 
 
We need ports for the primary multicast distribution. We need other ports for the unicast session. Multicast traffic is one way, so it has no NAT issues. For the unicast session, there is no offer/answer phase. But, we would like the receiver to be able to use its preferred ports. Considering that there may be multiple receivers behind the same NAT sharing the same public IP address, the server should be able to send the unicast RTP/RTCP packets to desired ports.
 
> main draft. I would multiplex RTP and RTCP on the same port. That has

This brings advantages, I agree, but does not solve our issues (see below). I am ok if we strongly recommend muxing but I don't think we should mandate it.

> other. It will also automatically be kept alive by RTP_Rx to RS RTCP

Note that the feedback we sent for the primary multicast stream will not keep the NAT bindings open for the unicast session. It may but we cannot rely on that since the RTCP ports for the primary and unicast sessions on the server side (P2 and P4 in my diagram, respectively) will be different, and from NAT's viewpoint, there will be different bindings for each.

> draft-begen-avt-ports-for-ucast-mcast-rtp.

Cookie adds delay, that is the trade-off. 

Here are two other ideas we are considering (in addition to the one we already have in the draft). These are not in the draft yet, but will be included in the revision (based on the feedback).

Alternative 1 (Receiver-side cookies):
See the slides at ftp://ftpeng.cisco.com/abegen/Receiver-Driven_Cookie.pdf

Alternative 2 (Server-side cookies):
The idea is to allow the receivers to create as many cookies as they need at the beginning (before doing any RAMS/retransmissions) for each port pair (if not port-muxing) they are planning to use. The cookies will be per server not feedback target port. So, as long as the receiver uses the same local port pair with the right cookie, it will be able to use it for any unicast session with the particular retransmission server. 

This is similar to what we currently have in the draft. The difference is that the cookie(s) are generated/received right at the beginning so we don't incur the 1xRTT additional delay every time we start a new unicast session. This is only possible if the receiver is behind a nat that assigns the same public IP address/port for the messages sent from the same internal IP address and port even when it is talking to different destinations. If the public IP addresses/ports the receiver gets differ, we fall back to the approach described in the current draft.
 
Comments/feedback are welcome.

Cheers, acbegen.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 14 Dec 2009 10:46:03 +0100

Hi Ali,

Sorry, if I am confusing sometimes. I do notice that I am on steep
learning curve for this technology. But it do appear that there are some
serious issues with how you use RTP and RTCP that needs to be worked out.

After considering your comments and some more thinking about this I can
see two RTP sessions work. In fact I for certain aspects you require it.
 But there must be a separation of the RTCP that are reporting on the
SSM session to the feedback target, and another that is for the unicast
session. Mixing them together is highly problematic as you can't
determine in which context you are reporting. Especially not as you must
use the same SSRC for the burst and in the SSM part. There is a strong
binging between these sessions.

Thus I see a setup where the RS has one feedback target address + port
for the SSM part, and another that is for request related to bursts and
creations of the dynamic transmission. I note that the RTP
retransmission spec requires you to send NACK requests in the original
session.

To make things clear the flows I am proposing would look like this:

SSM RTP session:
MS->MC: RTP streams destination: MC_addr:port1
MS->MC: RTCP streams destination: MC_addr:port2
RTP_RX->RS: RTCP feedback and NACK to RS_addr:port3, source
RTP_RX_addr:port4

Unicast session:
RS->RTP_RX: Burst and retransmission RTP packets dest: RTP_RX_addr:port5
RS->RTP_RX: RTCP SR on the burst and retransmission packets destination
RTP_RX_addr:port5 from RS_addr:port6
RTP_RX->RS: RTCP with RAMS-requests to RS_addr:port6 from source
RTP_RX_addr:port5

The above maintains the necessary RTCP separation. It uses RAMS request
to create the second session and uses return routability to find the
address with RTP and RTCP multiplexing.

Due to these strong binding I see that there needs to be much more
clarify in how this is described. Usage of the SSRCs, to where the RTCP
reporting is done. How the session is terminated and how things time
out. Especially if you allow retransmission also, but also the Burst
case is problematic in environments with quick zapping back and forth
between TV channels.

Some direct response to your questions around the finer points that I
think are still valid.

> If the unicast session is terminated for some reason, the next NACK will re-instantiate it as a new session. But, under normal conditions, that session will stay alive due to ongoing NACKs/retransm…

The current RTP retransmission scheme doesn't allow this, as it MUST be
sent in the RTCP for the main session. And mixing them mixes up the
reports from the unicast and SSM session. As I see it some change will
need to happen here. However, I would suggest that one uses a RAMS type
request to create the unicast session but request the NACK according to
the rules to the SSM feedback target address.

> To address this, we allow multiple BYEs to be sent. And furthermore, the client may use different port pair for every new unicast session. However, this may increase the delay when/if we implement…

Yes, making clear how to timeout and which parts is expected to do
which. The roles here in regards to termination needs to be made clear.
The RTP_Rx knows if it is going to use retransmission or not if RS
offers that service. The RTP_Rx also knows when it received all of the
burst. So in this case it knows how to leave. The RS has incentatives to
close the session. But it doesn't have the information when it can do
that safely. Thus, I think reasonably conservative timers here is what
it needed.

When it comes to retransmission I think it needs to be done explicitly
so that the RS knows if it is expected to keep the channel open as long
as it see liveness indication from the RTP_Rx also on this unicast
channel. I assume that you will send regular RTCP RRs on the unicast
channel to announce your presence even if no retransmissions happens.

> We do session multiplexing between the primary session and unicast session. So, the SSRC the server will use will be the same.

Even if it happens rarely, you still need procedures for it.

> This session does not have to be terminated. From this viewpoint, I don't see any difference between starting that session with a nack or rams-r.

The issue is that the NACK goes in the SSM related RTCP channel, not the
unicast one.

> What about the receivers who are only retransmission-capable but not rams-capable? For them, the unicast session will be created when the server receives a NACK and responds to it. This has nothing…

Yes, but the RTP session establishment for them are not defined. It
simply is not specified how to get the delivery destination for the
unicast session between the RS and the RTP_Rx unless they uses SIP to
negotiate that. Using declarative SDP does not work, as the network
can't determine which unicast address or ports the RTP_Rx is going to
use for this.

As I see it you can either use a RAMS style dynamic session creation
method or an out-of-band RS to RTP_RX negotiation method, like SIP
offer/answer.

What is in the slides that you referenced or in the draft example does
not work.

> Why? If the receiver does not send a BYE, the session will stay open. The server will drop the state after 5 RTCP intervals unless it hears back from the receiver.

I agree that is one way. However, you are specifying to use RTCP for
dynamic session creation. That is new, and you need to specify that
termination of that session context will happen under certain
constraints. Like that a session peers hasn't seen any liveness signs in
either RTP or RTCP for 5 reporting intervals.

>> open will be the main challenge.

Yes, RTCP if muxed with RTP is a great keep-alive. Others can be used
also, but I do notice that they must come from the RTP_Rx on the inside
of the NAT/FW. I only noticed that you do need to spend resources to
keep it alive.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 14 Dec 2009 10:55:16 +0100

> So, you are suggesting the ret server needs to adjust the burst bitrate depending on the receiver reports sent by the receiver. Sure, but remember that the bursts typically will not be much longer…

I agree that there is no way you can get slow start etc to work well
enough in this case. However, I do think a safety net in form of
receiver feedback is important here. That is kind of the lowest level.

I think updated request with new bandwidth limitation is also a solution
here. But, remember that you likely need to specify something on when
the client are intended to react here.

My main point is that you will not get this document through IESG
without some more thinking and writing into this issue. Also limitations
to applicability are needed. RAMS are intended for managed environments
and with reasonably well placed RSs. Yes, most cases can't guarantee
that there are no competing traffic compared to what is engineered. In
cases traffic prioritization is being used that helps. That should be
made clear.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 14 Dec 2009 11:19:48 +0100

Hi Ali,

I might be missing something about how the base line unicast session
establishment works. As I have understood it the receiver is supposed to
open the port indicated in the m= lines and a=rtcp attribute, but these
are also the ports the server is going to use.

        m=video 41002 RTP/AVPF 99
        i=Unicast Retransmission Stream #2 (Ret. and Rapid Acq. Support)
        c=IN IP4 192.0.2.1
        a=recvonly
        a=rtpmap:99 rtx/90000
        a=rtcp:41003

Thus the RTP_Rx is supposed to receive the RTP burst on local
interface:port 41002, and RTCP on local interface port 41003. The RS
learns the address from the RAMS-R request. Which will be the address of
the outer-most NAT relative to the RS if any is present.

> We need ports for the primary multicast distribution. We need other ports for the unicast session. Multicast traffic is one way, so it has no NAT issues. For the unicast session, there is no offer/…

Sorry, I don't understand the end of your paragraph. As I see it the
RTP_Rx side ports can't be pre-determined. Even locally on the machine
there is no guarantee that you can get a port number the server decides.
There might already be another UDP based protocol using that port. When
multiple RTP_Rx are behind the same NAT that is nearly impossible to get
well working. Thus, dynamic binding is the only way I see working reliably.

> Note that the feedback we sent for the primary multicast stream will not keep the NAT bindings open for the unicast session. It may but we cannot rely on that since the RTCP ports for the primary a…

But, you send RTCP RR traffic for the unicast traffic also to the RS.
Even if there is nothing to report on, you should send the RTCP RR with
empty report blocks. That is part of standard RTCP. That way you will
have keep-alive traffic flowing from the RTP_Rx to the RS. That is why I
think muxing helps so much. It removes the need for keep-alive mechanism
for the RTP flow.

> See the slides at ftp://ftpeng.cisco.com/abegen/Receiver-Driven_Cookie.pdf

I don't see how receiver side generated cookies helps protect against
the receiver being an attacker that spoofs the source address of its
RTCP packets to generate a DoS attack on the spoofed source address. It
does help against miss association between RTP and RTCP. A problem I
don't think you will have if you multiplex them on the same port. It
does protect against an attacker inserting requests into an already
existing context with the target of the attack. For that reason I see
some value in them.

> This is similar to what we currently have in the draft. The difference is that the cookie(s) are generated/received right at the beginning so we don't incur the 1xRTT additional delay every time we…

I think there is value in pre-generating cookies to speed up any
subsequent request after the first one. If you can make the delivery of
the cookies/shared secret needed to generate them to the RTP_Rx you can
get good enough security to run the RS to RTP_Rx checks more as a safety
precaution and start deliver media without additional delay.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 14 Dec 2009 11:28:38 +0100

Hi,

Apparently my brain wasn't fully up to speed when I wrote this. I do
understand we are in agreement now how the RTCP flows should go, based
on the slides your reference.

Still the issues around how you use these two RTCP flows are still
existing.

Cheers

Magnus

-- 

Magnus Westerlund

---

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

> FYI, RAMS-T may be sent multiple times.

Yes, but indepently of how many retransmissions there are, there will
never be 0 risk of this not happening.

> Well, how do we know that the receiver is not actually interested in two different streams? This certainly can be the case. A single is asking for multiple RAMS requests or multiple receivers behin…

Sure, this is a real concern. However, at the same time, there is
clearly deployments where you know that you can't support more than one
or two simultaneous streams due to the link technology between the RS
and RTP_Rx. In these case having an answer saying that the server has
administratively prohibited your request due to other outstanding
requests that gives more information.

>> 508 Request denied due to already ongoing burst.

Maybe another explanation that is more generic around this is needed.

508 Request administratively denied due to too many ongoing streams to
IP-address.

> We can add this, np. But, the server has to make sure that the new request is somehow overriding any existing on-going request, which is actually something we can't make sure IMO.

My understanding would be that the new request would be denied if the
client has failed to terminate the previous one. By getting this
response, the client can issue new copies of the RAMS-T and then try the
RAMS-R again.

Cheers

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 16 Dec 2009 07:24:58 -0800

OK, we better define a new error message here that says the burst was denied due to a policy. When it will be used will depend on the policy on the server.

-acbegen

> Sent: Monday, December 14, 2009 5:34 AM
> Subject: Re: draft-ietf-avt-rtp-rapid-acquisition-for-rtp-05: Error code due to ongoing
> requests
> 
> > Well, how do we know that the receiver is not actually interested in two different
> streams? This certainly can be the case. A single is asking for multiple RAMS requests or
> multiple receivers behind the same NAT (sharing a public IP) doing independent RAMS
> requests.
> 
> > We can add this, np. But, the server has to make sure that the new request is somehow
> overriding any existing on-going request, which is actually something we can't make sure
> IMO.
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 16 Dec 2009 07:25:02 -0800

Hi Magnus,

Agree, we can put some wording around what possible solutions exist and state that the solution will depend on the application and the features of the network. We would welcome some text from you if there are specific things you think should exist in the document.

-acbegen

> Sent: Monday, December 14, 2009 4:55 AM
> Subject: Re: draft-ietf-avt-rtp-rapid-acquisition-for-rtp-05: Congestion Control
> 
> > So, you are suggesting the ret server needs to adjust the burst bitrate depending on the
> receiver reports sent by the receiver. Sure, but remember that the bursts typically will
> not be much longer than 5-10 RTTs, so that kind of adaptation may not work in practice.
> Instead we allow updated RAMS-R messages that can have a "max receive bitrate" field to
> notify the server, which is a faster way to do rate adjustments.
>

---

From: Roni Even <[email-masked]>
Date: Thu, 17 Dec 2009 23:14:40 +0200

Hi,
I agree with Magnus and voiced my concerns in the past that basing the
solution on the server declaring the unicast ports that the RTP_Rx will use
for receiving the burst will fail in NATed environment. Yet it can be
addressed in a separate draft, referenced in RAMS (Maybe as normative
reference), that will also try to address the problem for NACK. RFC 4588
does not address this topic and the example in section 10.2 uses multicast
for the retransmission stream.
Roni Even
As individual

> Sent: Monday, December 14, 2009 12:20 PM
> Subject: Re: [AVT] draft-ietf-avt-rtp-rapid-acquisition-for-rtp-05:
> NAT/FW traversal
> 
> Hi Ali,
> 
> > We need ports for the primary multicast distribution. We need other
> ports for the unicast session. Multicast traffic is one way, so it has
> no NAT issues. For the unicast session, there is no offer/answer phase.
> But, we would like the receiver to be able to use its preferred ports.
> Considering that there may be multiple receivers behind the same NAT
> sharing the same public IP address, the server should be able to send
> the unicast RTP/RTCP packets to desired ports.
> 
> > This brings advantages, I agree, but does not solve our issues (see
> below). I am ok if we strongly recommend muxing but I don't think we
> should mandate it.
> >
> > Note that the feedback we sent for the primary multicast stream will
> not keep the NAT bindings open for the unicast session. It may but we
> cannot rely on that since the RTCP ports for the primary and unicast
> sessions on the server side (P2 and P4 in my diagram, respectively)
> will be different, and from NAT's viewpoint, there will be different
> bindings for each.
> >
> 
> > Here are two other ideas we are considering (in addition to the one
> we already have in the draft). These are not in the draft yet, but will
> be included in the revision (based on the feedback).
> >
> > The idea is to allow the receivers to create as many cookies as they
> need at the beginning (before doing any RAMS/retransmissions) for each
> port pair (if not port-muxing) they are planning to use. The cookies
> will be per server not feedback target port. So, as long as the
> receiver uses the same local port pair with the right cookie, it will
> be able to use it for any unicast session with the particular
> retransmission server.
> >
> > This is similar to what we currently have in the draft. The
> difference is that the cookie(s) are generated/received right at the
> beginning so we don't incur the 1xRTT additional delay every time we
> start a new unicast session. This is only possible if the receiver is
> behind a nat that assigns the same public IP address/port for the
> messages sent from the same internal IP address and port even when it
> is talking to different destinations. If the public IP addresses/ports
> the receiver gets differ, we fall back to the approach described in the
> current draft.
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 17 Dec 2009 13:27:09 -0800

There is no disagreement on this topic. We already have a few proposals on the table and if those who are interested in this work can comment on the proposals, we can move forward and try to finish the draft by the next meeting.

-acbegen

> From: Roni Even [mailto:[email-masked]]
> Sent: Thursday, December 17, 2009 4:15 PM
> To: 'Magnus Westerlund'; Ali C. Begen (abegen)
> Cc: 'IETF AVT WG'
> Subject: RE: [AVT] draft-ietf-avt-rtp-rapid-acquisition-for-rtp-05: NAT/FWtraversal
> 
> Hi,

---

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

Hi,

Clearly there need to be a solution for establishing the RTP and RTCP
flows between RTP_Rx and RS for the transmission. For the RAMS draft I
think we need a normative reference to the solution for establishing
these session when needed. It is clearly a dynamic creation process. So
lets try to pick a document as basis for developing that solution to
allow the rapid-acquisition document to go forward as well as possible.

Cheers

Magnus Westerlund

---

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

Thanks

Magnus Westerlund

---

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

> Agree, we can put some wording around what possible solutions exist and state that the solution will depend on the application and the features of the network. We would welcome some text from you i…

Yes, I will try to help with text as soon as I am back from my vacation
next year.

Cheers

Magnus Westerlund