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

["Ali C. Begen (abegen)" <[e-mail]>]

Hi Magnus,

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

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

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

I should not have used the word "session." 
 
> 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.

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

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

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.

> >
> >> 3. Section 6.2, figure 2:
> >>
> >> 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.
> 
> 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.

Let me see what I can do about that.
  
> >
> >> 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.
> >
> > 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 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.

See below.
 
> >
> >> 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
> >
> > What do you suggest?
> >
> >> 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
> >
> > No, if that acquisition is canceled, the session is killed.
> >
> >> messages in flight if one channel change is terminated and another
> >> initiated due to aggressive channel zapping.
> >
> > Indeed.
> >
> >> Thus I think this should be clarified to say when the RTP_Rx and the RS
> >> 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

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

> request. Also ongoing burst should be terminated before terminating the
> 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.

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

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.
 
> >>
> >> 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.
> >
> > 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.
> 
> This is not only a question about retransmission. But also of monitoring
> and the need to react on when there are evidence of congestion.

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.

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

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

It may or may not be. 
 
> >> 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.
> >
> > 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?

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

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

The only way to identify them is to signal them in the SDP.
 
> > 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.
> 
> 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.
 
> >
> >> 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.
> >
> > 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?

Right.
 
-acbegen