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

From: Magnus Westerlund <[email-masked]>
Date: Wed, 03 Mar 2010 07:14:01 -0800

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.

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

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.

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?

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"

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

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

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

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.

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

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.

12. Section 7.3, second paragraph:
Please specify how both the SSRC values should be set.

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.

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?

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?

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.

17. Section 8.2,
You require the SDP grouping framework. However, you don't specify which
semantics shall be used.

18. Section 8.2:
   o  The RTP retransmissions [RFC4588]

Using the RFC title might be clearer here: RTP Retransmission Payload
Format [RFC4588]

19. Section 8.2:

In general there need to be more detailed specification of how to
utilize these RFCs to realize the RAMS solution.

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.

21. Section 8.3:

There is a lot of specification in this example. Please move the
specification parts to separate text from the example.

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
attribute for RAMS will force the same value to both usages as I see it.
Is a separate attribute needed?

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.

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.

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"

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?

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.

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.

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.

30. I think the document should have a worked example also with the RAMS
messages.

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

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.

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.

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.

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: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Wed, 3 Mar 2010 13:28:35 -0600

Magnus-

Thanks for the detailed review. A lot of this can be resolved with editorial changes.

We need to think about item 4 in the broader context of RTP unicast/multicast flows to see if this is a special RAMS case or a more general problem. At first, it smells like a RAMS special case, but I want to consider in detail. This may also have some tie in to your recent note on the interactions between RAMS-R, RAMS-T and RAMS-I and NAT. There may be a need to include a cookie, which brings us back to the discussions around draft-ietf-avt-ports-for-ucast-mcast-rtp-00.

We also need to consider the SDP comments. I am not an SDP expert, so hopefully others can chip in.

Bvs

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Wednesday, March 03, 2010 10:14 AM
To: IETF AVT WG; [email-masked]
Subject: draft-ietf-avt-rapid-acquisition-for-rtp-07: Minor issues

Hi,

3. Figure 3:

15. Section 8.1:

16. Section 8.1:

17. Section 8.2,

18. Section 8.2:

19. Section 8.2:

21. Section 8.3:

22. Section 8.3:

If FT_Ap is

31. Section 10.

32. Section 10, page 43:

33. Section 11.4,

34. Section 11.6:

Cheers

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 3 Mar 2010 13:20:16 -0800

Hi Magnus,

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

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

> here. Do you have a better term?

Not really, but we are open to suggestions. 
 
> that also seem to be missing some part of its specification in this

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.
 
> bound to? How do you bind such a RAMS-T to the correct context?

I will defer this one to the port mapping discussion.
 
> I would suggest to remove "often"

OK.

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

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

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

> to the FT_AP is the wrong thing to do if the RTP_RX only wants to

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

Could you be more specific?
 
> 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. 
 
> 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.
 
> message and the remaining bullets are defining TLVs.

Good suggestion.
 
> Is this option really needed? Can't you specify one behavior instead of

OK, let's mandate to signal 0 in that field if there are no objections.
 
> make it more appropriate?

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

What about:

rai - rapid acquisition indication?
 
> 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 require the SDP grouping framework. However, you don't specify which

I thought it was obvious but I will mention fid.
 
> Using the RFC title might be clearer here: RTP Retransmission Payload

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

> 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.
 
> specification parts to separate text from the example.

Can do another subsection.
 
> 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.

> Is a separate attribute needed?

Nope, see above.
 
> 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
 
> 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.

> I would change "is willing" to "intend"

OK.
 
> Shouldn't the reference be given in the first sentence rather than the

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

> is used, the clients are supposed to not collide with these addresses.

OK.
 
> retransmissions in SSM context.

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

What is it exactly?
 
> 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.

> differently. But some baseline is likely worth to lay down here.

Could be true or not. I can't really comment.
 
> 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?

> that are open for assignment.

OK.
 
> be more appropriate here. The client is served, but not as fully as he

Is the glass half empty or half full :)

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

Cheers, acbegen

---

From: Mark Baugher <[email-masked]>
Date: Sun, 7 Mar 2010 15:25:41 -0800

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

There are a variety of ways this can be done including through a 
conditional access system, but this could be considered out of
scope for this document.  If it is in scope, I would start with a
standard multicast key management system like GSAKMP or GDOI and
define the signaling for it.  Since it's not clear that these systems
will even be used, however, this is probably a waste of the authors'
time.

> Could be true or not. I can't really comment.

In the IPTV realm, there are a number of competing conditional access
systems that might be used for proprietary establishment of an SRTP
master key and master salt.  These are the most likely methods by
which a key might be installed.  And there are a number of standard
techniques mentioned above.

>> work less well.

Are you saying that there is no way to secure against this?

Mark

>> Due to that the RAMS extensions are more a control

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sun, 7 Mar 2010 16:05:40 -0800

Hi Magnus,

We are addressing the other minor issues in the -08 version, which I
hope will be submitted before the deadline.

> exist than what is primarily discussed in the RTCP SSM RFC.

Dan W. has suggested the following text. If you are happy with it, let
me know so that we can put it in the draft before Monday's deadline. I
am afraid we are not addressing all potential man-in-the-middle attacks.

-acbegen

To protect the RTCP messages from man-in-the-middle and replay attacks,
the RTP receivers and Retransmission Server SHOULD perform a DTLS-SRTP
handshake [I-D.ietf-avt-dtls-srtp] over the RTCP channel.  Because there
is no integrity-protected signaling channel between an RTP receiver and
the Retransmission Server, the Retransmission Server MUST maintain a
list of certificates owned by legitimate RTP receivers, or their
certificates MUST be signed by a trusted Certificate Authority. Once the
DTLS-SRTP security is established, non-SRTCP-protected messages received
from a particular RTP receiver are ignored by the Retransmission Server.
To reduce the impact of DTLS-SRTP overhead when communicating with
different feedback targets on the same Retransmission Server, it is
RECOMMENDED that RTP receivers and the Retransmission Server both
support TLS Session Resumption without Server-side State [RFC5077].

---

From: Roni Even <[email-masked]>
Date: Mon, 15 Mar 2010 15:02:25 +0200

Hi,

> 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 

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. 

Roni: I agree with Magnus, I think that the discussion here  is not if this
is something called retransmission but is this RFC4588 retransmission or is
RAMS using RFC4588 payload to convey the rapid acquisition data. My view and
I think this is what Magnus is saying is that RAMS is using RFC 4588 payload
but is not sending retransmission packets as specified in RFC 4588:
"Retransmission packet: an RTP packet that is to be used by the receiver
instead of a lost original packet.  Such a retransmission packet is said to
be associated with the original RTP packet."

The receiver has not lost an original packet yet. I also think that saying
that RAMS is using the RFC 4588 payload will also address others issues like
different between SSRC usage in RFC 4588 and RAMS.

Roni Even
As Individual

---

From: Roni Even <[email-masked]>
Date: Mon, 15 Mar 2010 20:55:56 +0200

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

The feedback header in RFC 4585 has two SSRC defined: SSRC of packet sender
and  SSRC of media source.
In the section Magnus mentions you use "media sender SSRC field". Use the
names from RFC 4585.

Roni Even
As Individual

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 22 Mar 2010 10:39:23 -0700

> support TLS Session Resumption without Server-side State [RFC5077].

Yes, at my knowledge level this does seem to be a very reasonable
mitigation method.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 24 Mar 2010 11:27:46 -0700

Hi,

I have removed all points where there are agreement.

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

> Not really, but we are open to suggestions.

I don't have any suggestion just now.

> 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 rem…

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

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

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

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.

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

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

Correct.

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

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

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

> 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 prior…

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.

> rai - rapid acquisition indication?

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

> 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 thought it was obvious but I will mention fid.

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

> 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 sec…

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.

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

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

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

> 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

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.

> Could be true or not. I can't really comment.

I think you gotten some reasonable suggestions from Dan Wing.

> 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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sat, 27 Mar 2010 17:45:54 -0700

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

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

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.
 
> will have to timeout and simply move on joining the multicast channel.

Yup.
 
> if there is a NAT or not. Thus I would reference the actual mechanism we

OK, will add it.
 
> additional serivce, like retransmissions: Only send RAMS-T on unicast

This is the default behavior but others are possible (but unlikely). 
 
> termination of the burst.

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

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

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.
 
> Obvious isn't the same as mandating support for it.

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

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

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

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