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

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

RAMS will be revised soon based on the feedback received from Magnus. Some changes will also be based on the port mapping and rtcp ssm port draft developments. There were a few other people who promised to return their feedback shortly. It would be great if those folks could provide them next week. 

After that, we will submit the revision and be ready for the 2nd wglc.

Further comments are inline.

-acbegen

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

It is a retransmission of a missing retransmission (4588 does not allow that). If a missing burst packet is retransmitted, it is done via the regular NACK on the primary.
 
> >> 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.

I am fine to remove that part.

And based on the AVT discussion, retransmission in SSM sessions will be discussed in a separate specification after we handle the port mapping issues.
 
> >
> >> 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.

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

OK, will add it.
 
> >
> >> 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.

This is the default behavior but others are possible (but unlikely). 
 
> 
> >
> >> 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.

Hmm, ok. Will add some wording around this.
 
> >
> >> 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.

The latest rev made these 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.

I prefer to say "O/A is not specified." The reason is I cannot think of any good reason to include this feature in the O/A model.
 
> >
> >> 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.

This was already addressed.
 
> >
> >> 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.


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

OK, will check that section again.
 
> >> 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?

Looks like we really need a separate spec for retransmissions. I wish we did that before RAMS so that we could just refer to it in the RAMS draft.

Thanks again for the detailed review.

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