Re: [AVT] draft-ietf-avt-rapid-acquisition-for-rtp-07: Minor issues

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

Hi Magnus,

As always thanks for the detailed review. My comments are inline.

> -----Original Message-----
> From: Magnus Westerlund [mailto:[e-mail]]
> Sent: Wednesday, March 03, 2010 10:14 AM
> To: IETF AVT WG; [e-mail]
> Subject: draft-ietf-avt-rapid-acquisition-for-rtp-07: Minor issues
> 
> Hi,
> 
> Hera are a large number of minor issues that I found while reviewing the
> latest version.
> 
> 1. I think the document uses retransmissions a bit to freely in a number
> of cases. A RAMS burst is not a retransmission from the client
> perspective. Yes, it uses the retransmission payload format, but it is
> the first time the client has the opportunity to receive the packet.

If it had received the packet, there would not be a need for retransmission, right? From the server's viewpoint, it does not know whether the client was already receiving the multicast or not. If the client simply sent a regular NACK message before joining the SSM session, RS would respond to it as usual and there is nothing wrong with that. RAMS-R is just a special NACK to the server. 

I thought we discussed this concept in detail in our July 2008 meeting.

> 2. Figure 1: I found "Intermediary Network Element" saying very little
> here. Do you have a better term?

Not really, but we are open to suggestions. 
 
> 3. Figure 3:
> I think the diagram should remove the part that has retransmission after
> having joined the multicast session. That is a separate functionality
> that also seem to be missing some part of its specification in this
> context.

Right, but it is there to show retransmissions could be used to fill any gaps (as mentioned in the text) and if you look at it, it is an optional transaction. If there are no objections, we can remove it, though.
 
> 4. What happens with a RAMS-T if the NAT binding has timed out and the
> RAMS-T arrive with another source address+port than what the unicast was
> bound to? How do you bind such a RAMS-T to the correct context?

I will defer this one to the port mapping discussion.
 
> 5. Section 6.2,page 18, bullet 1:
> However, in the
>         unicast RTP retransmission session, RTP_Rx often needs to choose
>         its receive ports for RTP and RTCP.
> 
> I would suggest to remove "often"

OK.

> 6. Section 6.2, page 18, bullet 1:
> I am missing a reference to that the port mapping draft in this bullet.

I thought referencing to section 9 would be better for clarity and suffice.
 
> 7. Section 6.2, page 19, bullet 3:
> every time it says "multicast stream" can we include RTP in that so that
> it becomes: "multicast RTP stream"?

If you look at section 3, it is stated that way but I felt it was pretty redundant given that the whole work is around RTP and there is no non-RTP flow involved. But if you feel strong about it, np for me.

> 8. Section 6.2, page 19, bullet 3:
> In case the client fails to establish the unicast session it can't send
> a RAMS-I as response to the RAMS-R as the RS doesn't know where to send
> the packet. In this case the only way to send a response is to reverse

If the port mapping setup has failed, the client will not send RAMS-R anyway. So there is no problem here.

> the source and destination port, i.e. a symmetrical response to the
> request from the FT_AP to the clients source address and port from the
> RAMS-R.
>
> 9. Section 6.2, page 22, bullet 10:
> When it comes to RTCP BYE I think the sending of it to both sessions are
> bit confusing and would vary with use case. RTCP BYE basically says the
> client leaves the session. If it is sent to the FT_AP then it tells the

There are two rtcp ports, right? If you send it to the FT_Ap, it means you are leaving the mcast session. If you send it to the rtcp port of the unicast session, it means you are leaving the ucast session.

> RS that it leaves the multicast group also. In case the RTP_RX are
> continuing to be in multicast group it should send RTCP receiver reports
> to the FT_AP reporting on the multicast session. Thus sending a RTCP BYE
> to the FT_AP is the wrong thing to do if the RTP_RX only wants to
> terminate the burst.

Bullet 10 is covering the cases where the client is no longer interested in either the burst or the multicast stream. So, sending BYEs to those two ports is the correct thing to do IMO.

If the client just wants to end the burst, it uses RAMS-T.
 
> Also if the unicast session between the RS and the RTP_RX is going to be
> reused for a retransmission, then also sending an RTCP BYE also in the
> unicast is not appropriate.

Correct. BYE ends the session. If later the client wants to do retransmission, the NACK will establish the session again.

> 10. Section 6.4: I am missing client side termination in the list of
> actions.

Could you be more specific?
 
> 11. Section 7.2, third paragraph:
> Please also make it clear what both the SSRCs in the feedback header
> should be set using the name in the RFC 4585.

Not sure what you mean. The text should be clear. If the client is asking for two or more streams, there has to be an explicit signaling as described later in the section. 

The packet sender SSRC is always set to the SSRC of the client. The media sender SSRC is set based on whether the client is asking for a single or more streams, or whether it knows the SSRC a priori or not. 
 
> 12. Section 7.3, second paragraph:
> Please specify how both the SSRC values should be set.

In the RAMS-I message:
The media sender SSRC is set to the SSRC of the multicast stream.
The packet sender SSRC is also set to the SSRC of the multicast stream. I will make a note of this.
 
> 13. Section 7.3, page 33:
> I think there should be section heading between the second and third
> bullet on this page, as the two first bullets are defining fields of the
> message and the remaining bullets are defining TLVs.

Good suggestion.
 
> 14. Section 7.3, page 34, TLV 33:
> "If the burst request has been rejected as indicated in
>       the Response field, this field MAY be omitted or set to zero."
> 
> Is this option really needed? Can't you specify one behavior instead of
> options?

OK, let's mandate to signal 0 in that field if there are no objections.
 
> 15. Section 8.1:
> "'ssli' stands for Stream Synchronization Loss Indication"
> I can fully understand that you don't want to change the abbreviation.
> However, the long name seems really wrong to describe rapid acquisition
> of a stream. Can you find some creative rewriting of the long name to
> make it more appropriate?

Well, 'sli' was already taken. 'ssli' is not any longer than 'rpsi'.

What about:

rai - rapid acquisition indication?
 
> 16. Section 8.1:
> I think both the declarative and offer/answer behavior of the
> "rams-updates" attribute needs to be defined. I also think this the SDP
> attribute should be done in its own section.

Why do we need o/a? if the server supports it, it will show up in the SDP and clients may use it. If the server does not support it, it does not matter what the clients want.
 
> 17. Section 8.2,
> You require the SDP grouping framework. However, you don't specify which
> semantics shall be used.

I thought it was obvious but I will mention fid.
 
> 18. Section 8.2:
>    o  The RTP retransmissions [RFC4588]
> 
> Using the RFC title might be clearer here: RTP Retransmission Payload
> Format [RFC4588]

OK.
 
> 19. Section 8.2:
> 
> In general there need to be more detailed specification of how to
> utilize these RFCs to realize the RAMS solution.

Not sure I agree. Each of those RFCs already do a good job how they work in general. And throughout our draft, we explain how RAMS works. If there is anything specific you think missing in this section, let me know.

 
> 20. Section 8.3, second paragraph:
> "   In the example shown Figure 9, we have a primary multicast (source)
>    stream and a unicast retransmission stream.  The source stream is
>    multicast from a distribution source (with a source IP address of
>    198.51.100.1) to the multicast destination address of 233.252.0.2 and
>    port 41000.  A Retransmission Server including feedback target
>    functionality (with an address of 192.0.2.1 and port of 41001) is
>    specified with the 'rtcp' attribute."
> 
> I recommend using different ports for RTCP over multicast and to the FT.

OK, we can do that. But the current rule set by RFC 5760 is restrictive (+1 rule). See my earlier email to AVT.
 
> 21. Section 8.3:
> 
> There is a lot of specification in this example. Please move the
> specification parts to separate text from the example.

Can do another subsection.
 
> 22. Section 8.3:
> 
>    In the RAMS context, the parameter 'rtx-
>    time' specifies the time in milliseconds that the Retransmission
>    Server keeps an RTP packet in its cache available for retransmission
>    (measured from the time the packet was received by the Retransmission
>    Server).
> 
> First the text is not clear if this talks about the RAMS part or
> retransmissions after the RAMS. Also are there any issues in sharing
> this configuration parameter between the two usages? Using this

Nope, rtx-time pertains to both. At the end, it is the same set of packets used for both rams and regular retransmission.

> attribute for RAMS will force the same value to both usages as I see it.
> Is a separate attribute needed?

Nope, see above.
 
> 23. Section 8.3, page 38:
> 
> "In this example, both the conventional retransmission and rapid
>    acquisition support are enabled.  This is achieved by the "a=rtcp-
>    fb:98 nack ssli" line. "
> 
> I think this is wrong. To show both you need two different a=rtcp-fb
> lines to my understanding your SDP also shows it like that.

Good catch. It is an artifact remaining from an earlier version I believe. Two lines are needed to show support for both:

        a=rtcp-fb:98 nack
        a=rtcp-fb:98 nack ssli
 
> 24. Section 8.3, page 38:
> 
> If FT_Ap is
>    associated with only one RTP stream, the RTP receiver does not need
>    to learn the SSRC of that stream via an out-of-band method.
> 
> Also this sentence needs adjustment. Even if there is multiple RTP
> streams in the same RTP session you don't need to know the SSRC.

Right but the sentence above is still true. It is there because many deployments will likely prefer that option to avoid complications regarding learning/announcing the SSRCs.

 
> 25. Section 8.3, page 38:
> 
> However, if the RTP receiver is
>    willing to request a particular subset of the primary multicast
>    streams, it must learn their SSRC identifiers and list them in the
>    RAMS-R message.
> 
> I would change "is willing" to "intend"

OK.
 
> 26. Section 8.3, page 38:
> 
> Since this RTP receiver has not yet received any RTP
>    packets for the primary multicast stream(s), the RTP receiver must in
>    this case learn the SSRC value(s) from the 'ssrc' attribute of the
>    media description.  In addition to the SSRC value, the 'cname' source
>    attribute must also be present in the SDP description [RFC5576].
> 
> 
> Shouldn't the reference be given in the first sentence rather than the
> second one?

To be 100% correct, they both need the citation but putting it in the latter does the job, I guess.

 
> 27. Section 8.3, page 38:
> 
>    Note that listing the SSRC values for the primary multicast streams
>    in the SDP file does not create a problem in SSM sessions when an
>    SSRC collision occurs.  This is because in SSM sessions, an RTP
>    receiver that observed an SSRC collision with a media sender MUST
>    change its own SSRC [I-D.ietf-avt-rtcpssm] by following the rules
>    defined in [RFC3550].
> 
> I think this paragraph is incomplete. I would add that if the "a=ssrc"
> is used, the clients are supposed to not collide with these addresses.

OK.
 
> 28. Section 8.3, page 40:
> 
> The last m= line and the following lines. I think how this part really
> should look is dependent on how we specify the solution in other
> documents, the port mapping and the usage of port mapping for regular
> retransmissions in SSM context.

Agree.
 
> 29. Section 8.3, page 40:
>    In this section, we considered the simplest scenario where the
>    primary multicast RTP session carried only one stream and the RTP
>    receiver wanted to rapidly acquire this stream only.  Best practices
>    for scenarios where the primary multicast RTP session carries two or
>    more streams or the RTP receiver wants to acquire one or more streams
>    from multiple primary multicast RTP sessions at the same time are
>    presented in [I-D.begen-avt-rams-scenarios].
> 
> So several RTP streams in an RTP session shouldn't affect the media
> blocks in the SDP other than possibly through more RTP payload types.
> More sessions clearly results in more media lines with associated
> attributes. And the difference here as I see it is that the
> interpretation of the SDP grouping of media lines becomes more important.

Yes, and the client also needs to pay attention to when it wants to acquire streams from different SSM sessions at the same time (e.g., video + FEC), or two video streams from two SSMs.
 
> 30. I think the document should have a worked example also with the RAMS
> messages.

What is it exactly?
 
> 31. Section 10.
> The security mitigation for the authentication of the RTCP messages
> between the RTP_RX and the RS is SRTP. However, the document fails to
> indicate anything on how you would successfully configure the SRTP with
> keying information. Can you provide some insight into how this would
> work in RAMS scenario? I am more interested if you think there exist a
> keying method that fits the trust model and scenarios? And if it does

I need some help on this. I am not really an SRTP guy.

> that it might be worth indicating that in the draft as a recommended
> method. I know there will some that has different trust that can do it
> differently. But some baseline is likely worth to lay down here.

Could be true or not. I can't really comment.
 
> 32. Section 10, page 43:
>    In addition to the denial-of-service attacks, man-in-the-middle and
>    replay attacks can also be harmful.  However, RAMS itself does not
>    bring any new risks or threats other than the ones discussed in
>    [I-D.ietf-avt-rtcpssm].
> 
> I think the document fails to describe the increased risk for other
> attacks that isn't focused on blasting a lot of packets on to some
> target. For example an on-path attacker can beyond preventing the RTP_RX
> to get service, it may discretely change parameters to make the service
> work less well. Due to that the RAMS extensions are more a control
> protocol than a feedback protocol a different level of security threats
> exist than what is primarily discussed in the RTCP SSM RFC.

A single RTCP packet carrying multiple NACK messages each reporting multiple missing packets will generate a lot more packets than a single RTCP packet carrying RAMS-R. No?

> 33. Section 11.4,
> The range 4-254 in the table could be labeled "Assignable" to make that
> clear. Same comment applies to the other ranges in the following section
> that are open for assignment.

OK.
 
> 34. Section 11.6:
> Response code 511: Is that truly of the right type? Shouldn't a 2xx code
> be more appropriate here. The client is served, but not as fully as he
> expected.

Is the glass half empty or half full :)

In the RAMS context, I believe this response fits better to 5xx.

Cheers, acbegen
 
> Cheers
> 
> Magnus Westerlund
> 
> IETF Transport Area Director
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------