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

[Magnus Westerlund <[e-mail]>]

Hi,

I have removed all points where there are agreement.



Ali C. Begen (abegen) skrev 2010-03-03 13:20:
>> From: Magnus Westerlund [mailto:[e-mail]]
>>
>> 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.

The reason I bring this up is that you also allow retransmission
requests on the packets in the burst. Where suddenly you have original
burst packets and retransmission of burst packets. Thus there is a point
in separating what is happening by clear wording.



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

I don't have any suggestion just now.

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

The problem I see is that it might be seen as part of the defined
mechanism of RAMS while it actually is a stand alone mechanism that
needs its own specification somewhere.

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

Ok, we discussed this a bit yesterday between Ali, Bill and Tom. This
actually goes into the full discussion if the RAMS-I and RAMS-T should
be sent in the same bi-directional flow as the RAMS-R or if they goes
together with the Unicast session created by the RAMS-R. Personally I
think the design would work better if they where considered its own
control flow. There are certain pro and cons here. There is a case where
the client will not know if its RAMS-R didn't reach the server or if the
included cookie failed, or pointed to a place which lacks NAT binding.
Because any response from the server goes over the unicast session
indicated by the cookie. On the upside the RAMS-T will be more easily
mapped into the correct context. If the above failures happen the client
will have to timeout and simply move on joining the multicast channel.

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

Section 9 is NAT considerations, while this needs to happen indepentent
if there is a NAT or not. Thus I would reference the actual mechanism we
will have.

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

There is actually a difference between RTP and RTCP and other possible
multicast streams. Yes it might appear redundant for the insider that
understands it but I am not certain it is redundant when you read it the
first time.

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

I meant if the client thinks that the mapping has succeded but the
actual server either refuses the cookie or the cookie results in a
session pointing into a black hole. But see bullet 4.

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

Correct.

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

I didn't find that being obvious and there is no discussion of the
alternatives.

> 
> If the client just wants to end the burst, it uses RAMS-T.

Yes.

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

I think tearing it down and then reopening it seems unnecessary. Can't
we just transfer from RAMS usage to retransmissions? I agree that we are
comming into undefined country because we are lacking the spec for
retransmission usage. But I think RAMS document should discuss the three
cases and the different actions:

1. User zaps on or turn of the service, thus neither multicast nor burst
is of interest. Thus send RAMS-T in unicast session and RTCP BYE in both
sessions.

2. The burst completes: The clients sends RAMS-T and RTCP BYE on unicast
session

3. The burst completes and the unicast session is desired to be used for
additional serivce, like retransmissions: Only send RAMS-T on unicast
session.


> 
>> 10. Section 6.4: I am missing client side termination in the list of
>> actions.
> 
> Could you be more specific?

If the client detects that the burst is causing severe congestion it can
simply send a RAMS-T to stop it. That is what i meant with client side
termination of the burst.

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

RFC 4585 does specify the SSRC field as:

   |                  SSRC of packet sender                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SSRC of media source                         |

You need to make clear how both fields are set using the terms that
exist in RFC 4585. I would make a note also about the SSRC of packet
sender just to be clear.

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

My point was not necessarily to change the label, rather the long text
explanation to it.

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

You need at least to say that the O/A behavior isn't specified. However,
I have realized more than once that if you define a SDP attribute it
will show up in the other usages than you envisioned. The reason I state
O/A is that there already exist IPTV deployments that use SIP for
service negotiation rather than necessarily only declarative usage. Thus
I do request offer/answer behavior definition of this SDP attribute. I
think that is very straight forward.

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

Obvious isn't the same as mandating support for it.

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

Hmm, I think I would need to go back reading things again to remember
these issues. I would recommend that you make clear all the small
details, rather then rely on others to make their interpretation.

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

You are resolving this and please ensure that the example makes it clear
that these ports trully don't need to be the same as they are decided by
different entities.



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

Ok, here is a detail that needs to made clear in the interaction between
retransmissions and RAMS.



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

Yes, the above sentence is true, but it is failing to mention that also
in the case of multiple SSRCs the client is not required to know the
SSRC. Thus some reformulation is required.

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

Agreed.

> 
>> 30. I think the document should have a worked example also with the RAMS
>> messages.
> 
> What is it exactly?

That the example not only establish the entities in the example. But
they goes on to show how the messages looks like that are sent from the
RTP_RX and the RS.

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

I think you gotten some reasonable suggestions from Dan Wing.

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

Maybe, that depends on the size of the burst vs how many NACK messages
you can include in a request. However, the RTCP SSM RFC does to my
knowledge not define the usage of unicast retransmission in a SSM
context. Thus the security consideration part does not really cover that
case.


One question I have considering how many of the comments relate to the
usage of unicast retransmissions in an SSM context. Are you going to
make a document that specifies this case into a workable solution?


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