Subject: Re: [AVTCORE] comments on draft-ietf-avtcore-idms-04

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Fri, 8 Jun 2012 07:44:18 +0000

Hi Roni,

Thanks for your valuable review. Comments inline. We will upload a new version somewhere next week.

Ray

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
Sent: vrijdag 25 mei 2012 0:56
To: [email-masked]
Subject: [AVTCORE] comments on draft-ietf-avtcore-idms-04

Hi,
I reviewed the draft and have some comments

1.       In section 6 you have the sentence "If the RTCP Packet Sender is an SC (SPST=1) or an MSAS (SPST=2)" but above the value 2 is not defined for this document. Do you expect systems that support this document to also support the ETSI XR report from the MSAS?
RvB: The idea is that this document defines SPST 1 and 2, while the ETSI document provides some optional extensions (e.g. SPST 3 and 4).

2.       In section 6 when defining Packet Presented NTP timestamp it says "This timestamp reflects the wall clock time at the moment the data contained in the first octet  of the associated RTP packet is presented to the user " I am not sure how to know this since the displayed information is not the RTP information but the decoded information so it is not clear what is the first byte. I think that maybe it will good to state in the definition here and in the packet received that it is the first byte of the first packet in the frame or the first byte in the rendered frame. I think that in section 7 you have a better definition.
RvB: Your right, I will change the definition to reflect that.

3.       About the SDP parameters in section 9 and 10. Are these negotiated between the MCs and the MSAS or just announced by the MSAS.  It will be good to clarify the usage
RvB: We will add a section to describe how the SDP parameters can be used. In summary: in most cases the SDP parameters are negotiated. However, in some cases (e.g. IPTV Multicast scenarios), they might be announced by the MSAS.

4.       I understand that you list the two SDP parameter but the SC need one of them depending if it supports the ETSI version or this one. Based on the previous question response it will be good to list the proposed SDP sent from the MSAS.
RvB: We will add a section with some recommendations on how the MSAS should deal with the different SDP parameters.

5.        I am also not sure how the MSAS will know if to send the RTCP message or the RTCP-XR message. It is mentioned in section 11 what it should do but not how the MSAS know which one to send.
RvB: This will be covered by the section proposed under 4)

6.       In section 13 it will be good to say that the security consideration of RFC 3611 apply here also.
RvB: I agree, I will add it.

7.       The IANA section is not clear explain one by one what to do with the four entities. As for the ETSI  ones (the RTCP-XR and SFP) do you want to change them or have a reference to this document, if not they are not needed as IANA consideration since there is no IANA action there.
RvB: The idea is that we don't change the ETSI ones to maintain compatibility. I will clarify this section to reflect that.

8.       You can remove section 16.
RvB: Ok.

Roni Even as Individual

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer

---

From: "Roni Even" <[email-masked]>
Date: Sun, 10 Jun 2012 10:12:39 +0300

Hi Ray,

Thanks for the response. I only have a suggestion on the first comment.

1.       In section 6 you have the sentence "If the RTCP Packet Sender is an
SC (SPST=1) or an MSAS (SPST=2)" but above the value 2 is not defined for
this document. Do you expect systems that support this document to also
support the ETSI XR report from the MSAS?

RvB: The idea is that this document defines SPST 1 and 2, while the ETSI
document provides some optional extensions (e.g. SPST 3 and 4).  

Roni: I had this comment since I was not sure from this section what is the
use for SPST=2. Maybe you can point here to section 11 where you explain it
or the new section if it will address this.

As a Chair: After you submit an update I can start a WGLC

Roni

From: Brandenburg, R. (Ray) van [mailto:[email-masked]] 
Sent: Friday, June 08, 2012 10:44 AM
To: Roni Even; [email-masked]
Subject: RE: [AVTCORE] comments on draft-ietf-avtcore-idms-04

Hi Roni,

Thanks for your valuable review. Comments inline. We will upload a new
version somewhere next week.

Ray

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni
Even
Sent: vrijdag 25 mei 2012 0:56
To: [email-masked]
Subject: [AVTCORE] comments on draft-ietf-avtcore-idms-04

Hi, 

2.       In section 6 you have the sentence "If the RTCP Packet Sender is an
SC (SPST=1) or an MSAS (SPST=2)" but above the value 2 is not defined for
this document. Do you expect systems that support this document to also
support the ETSI XR report from the MSAS?

RvB: The idea is that this document defines SPST 1 and 2, while the ETSI
document provides some optional extensions (e.g. SPST 3 and 4). 

3.       In section 6 when defining Packet Presented NTP timestamp it says
"This timestamp reflects the wall clock time at the moment the data
contained in the first octet  of the associated RTP packet is presented to
the user " I am not sure how to know this since the displayed information is
not the RTP information but the decoded information so it is not clear what
is the first byte. I think that maybe it will good to state in the
definition here and in the packet received that it is the first byte of the
first packet in the frame or the first byte in the rendered frame. I think
that in section 7 you have a better definition.

4.       About the SDP parameters in section 9 and 10. Are these negotiated
between the MCs and the MSAS or just announced by the MSAS.  It will be good
to clarify the usage

RvB: We will add a section to describe how the SDP parameters can be used.
In summary: in most cases the SDP parameters are negotiated. However, in
some cases (e.g. IPTV Multicast scenarios), they might be announced by the
MSAS.

5.       I understand that you list the two SDP parameter but the SC need
one of them depending if it supports the ETSI version or this one. Based on
the previous question response it will be good to list the proposed SDP sent
from the MSAS.

RvB: We will add a section with some recommendations on how the MSAS should
deal with the different SDP parameters.

6.        I am also not sure how the MSAS will know if to send the RTCP
message or the RTCP-XR message. It is mentioned in section 11 what it should
do but not how the MSAS know which one to send.

7.       In section 13 it will be good to say that the security
consideration of RFC 3611 apply here also.

8.       The IANA section is not clear explain one by one what to do with
the four entities. As for the ETSI  ones (the RTCP-XR and SFP) do you want
to change them or have a reference to this document, if not they are not
needed as IANA consideration since there is no IANA action there. 

RvB: The idea is that we don't change the ETSI ones to maintain
compatibility. I will clarify this section to reflect that.

9.       You can remove section 16.

RvB: Ok.

Roni Even as Individual

This e-mail and its contents are subject to the DISCLAIMER at
http://www.tno.nl/emaildisclaimer

---

From: "Stokking, H.M. (Hans)" <[email-masked]>
Date: Wed, 13 Jun 2012 09:07:29 +0000

Hi Roni,

I've come up with new text for section 11, including a description on usage of SDP parameters. This should deal with your original comments 4, 5 and 6. Basic idea here is: please use the RTCP IDMS report preferably, but please also be compatible with the TISPAN approach.

Please let us know if you agree with the text, we will then upload a new version of the draft (including the more minor changes as indicated by Ray earlier in response to your comments).

Hans

11 SDP parameters usage and compatibility with TISPAN

The SDP usage for IDMS follows the rules defined in RFC3611 in section 5 on SDP signalling, with the exception of what is stated here. The IDMS usage of RTCP is a (loosely coupled) collaborative parameter, in the sense that receivers sent their status information and in response (asynchronously) the MSAS sents synchronization instructions. Both the sync-group parameter (defined by ETSI TISPAN) and the rtcp-idms parameter (defined in this document) thus indicate the ability to sent and the ability to receive indicated RTCP messages. This section defines how these SDP parameters should be used, and thus also explains how compatibility with the TISPAN solution is arranged for.

As described in Section 1.4, ETSI TISPAN has described its mechanism for IDMS in [TS183063].  One of the main differences between the TISPAN document and this document is the fact that the TISPAN solution uses an RTCP XR block for both the SC->MSAS message and the MSAS->SC message (by selecting SPST-type 2), while this document specifies a new RTCP Packet Type for the MSAS->SC message.  The message from MSAS to SC is not in any way a report on how a receiver sees a session, and therefore a separate RTCP packet type is more appropriate than the XR block solution chosen in ETSI TISPAN. To achieve compatibility, MSAS implementations SHOULD implement both the TISPAN RTCP block and the new RTCP IDMS report for MSAS->SC messages. SCs MAY implement support for both types of messages. For the MSAS->SC signaling, it is recommended to use the RTCP IDMS report defined in this document.  The TISPAN RTCP XR block with SPST=2 MAY be used for purposes of compatibility with the TISPAN solution, but MUST NOT be used if all nodes involved support the new RTCP IDMS report.

Most of the times, the IDMS SDP parameters will be used in the offer/answer context. Receivers will indicate in their SDP which RTCP messages they support.

For a unicast situation, three situations are possible in offer/answer context:
- If a receiver indicates at least the rtcp-idms SDP parameter, the MSAS SHOULD reply with only the rtcp-idms parameter and use only the RTCP IDMS report for MSAS->SC communication.
- If a receiver indicates only the sync-group SDP parameter, and the MSAS also supports this, it SHOULD reply with only the sync-group parameter and use only the RTCP XR block with SPST=2 for MSAS->SC communication.
- If a receiver indicates only the sync-group SDP parameter, and the MSAS does not support this, the media sender MUST ignore the parameter. This receiver will not become part of the synchronization session.

Note that it is possible that for a certain synchronization group, that the MSAS sends RTCP IDMS packets to one receiver and RTCP XR IDMS blocks with SPST=2 to another receiver.

In a multicast situation using the offer/answer context, it will work a bit differently. The negotiation is the same as in the unicast situation. But, the MSAS will multicast all RTCP messages to all receivers. So:
- If all receivers support the RTCP IDMS report, the MSAS SHOULD only sent the RTCP IDMS report for MSAS->SC messages.
- If not all receivers support the RTCP IDMS report, but all receivers support the TISPAN solution, the MSAS SHOULD only sent the RTCP XR block with SPST=2 for MSAS->SC messages.
- If some receivers support only the RTCP IDMS report and other receivers support only the TISPAN solution, the MSAS SHOULD sent both the RTCP IDMS report and the RTCP XR block with SPST=2 for MSAS->SC messages. This is less efficient, since the information sent is duplicated, but this is the only way to include all receivers in a synchronization session in this scenario.

In certain multicast situations, there is no offer/answer context. In that case, the MSAS SHOULD use only the RTCP IDMS packet type and thus use only the SDP parameter rtcp-idms. Receivers that do not support the RTCP IDMS packet will just ignore both the SDP parameter and the RTCP IDMS packets, and will thus not join the synchronization session. For compatability with the TISPAN solution, the MSAS MAY choose to use the RTCP XR IDMS block type instead, using the SDP parameter sync-group. The media sender SHOULD NOT use both parameters at the same time in this case of no offer/answer context.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
Sent: zondag 10 juni 2012 9:13
To: Brandenburg, R. (Ray) van; [email-masked]
Subject: Re: [AVTCORE] comments on draft-ietf-avtcore-idms-04

Hi Ray,

1.      In section 6 you have the sentence "If the RTCP Packet Sender is an SC (SPST=1) or an MSAS (SPST=2)" but above the value 2 is not defined for this document. Do you expect systems that support this document to also support the ETSI XR report from the MSAS?
RvB: The idea is that this document defines SPST 1 and 2, while the ETSI document provides some optional extensions (e.g. SPST 3 and 4).
Roni: I had this comment since I was not sure from this section what is the use for SPST=2. Maybe you can point here to section 11 where you explain it or the new section if it will address this.

From: Brandenburg, R. (Ray) van [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Friday, June 08, 2012 10:44 AM
To: Roni Even; [email-masked]<mailto:[email-masked]>
Subject: RE: [AVTCORE] comments on draft-ietf-avtcore-idms-04

Hi Roni,

Ray

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Roni Even
Sent: vrijdag 25 mei 2012 0:56
To: [email-masked]<mailto:[email-masked]>
Subject: [AVTCORE] comments on draft-ietf-avtcore-idms-04

Hi,

2.      In section 6 you have the sentence "If the RTCP Packet Sender is an SC (SPST=1) or an MSAS (SPST=2)" but above the value 2 is not defined for this document. Do you expect systems that support this document to also support the ETSI XR report from the MSAS?
RvB: The idea is that this document defines SPST 1 and 2, while the ETSI document provides some optional extensions (e.g. SPST 3 and 4).
3.      In section 6 when defining Packet Presented NTP timestamp it says "This timestamp reflects the wall clock time at the moment the data contained in the first octet  of the associated RTP packet is presented to the user " I am not sure how to know this since the displayed information is not the RTP information but the decoded information so it is not clear what is the first byte. I think that maybe it will good to state in the definition here and in the packet received that it is the first byte of the first packet in the frame or the first byte in the rendered frame. I think that in section 7 you have a better definition.
RvB: Your right, I will change the definition to reflect that.
4.      About the SDP parameters in section 9 and 10. Are these negotiated between the MCs and the MSAS or just announced by the MSAS.  It will be good to clarify the usage
RvB: We will add a section to describe how the SDP parameters can be used. In summary: in most cases the SDP parameters are negotiated. However, in some cases (e.g. IPTV Multicast scenarios), they might be announced by the MSAS.
5.      I understand that you list the two SDP parameter but the SC need one of them depending if it supports the ETSI version or this one. Based on the previous question response it will be good to list the proposed SDP sent from the MSAS.
RvB: We will add a section with some recommendations on how the MSAS should deal with the different SDP parameters.
6.       I am also not sure how the MSAS will know if to send the RTCP message or the RTCP-XR message. It is mentioned in section 11 what it should do but not how the MSAS know which one to send.
RvB: This will be covered by the section proposed under 4)
7.      In section 13 it will be good to say that the security consideration of RFC 3611 apply here also.
RvB: I agree, I will add it.
8.      The IANA section is not clear explain one by one what to do with the four entities. As for the ETSI  ones (the RTCP-XR and SFP) do you want to change them or have a reference to this document, if not they are not needed as IANA consideration since there is no IANA action there.
RvB: The idea is that we don't change the ETSI ones to maintain compatibility. I will clarify this section to reflect that.
9.      You can remove section 16.
RvB: Ok.

Roni Even as Individual

---

From: "Roni Even" <[email-masked]>
Date: Wed, 13 Jun 2012 15:35:23 +0300

Hi Hans,

Please upload a new version and I will start a last call. 

Roni

From: Stokking, H.M. (Hans) [mailto:[email-masked]] 
Sent: Wednesday, June 13, 2012 12:07 PM
To: Roni Even; [email-masked]
Subject: RE: [AVTCORE] comments on draft-ietf-avtcore-idms-04

Hi Roni,

I've come up with new text for section 11, including a description on usage
of SDP parameters. This should deal with your original comments 4, 5 and 6.
Basic idea here is: please use the RTCP IDMS report preferably, but please
also be compatible with the TISPAN approach.

Please let us know if you agree with the text, we will then upload a new
version of the draft (including the more minor changes as indicated by Ray
earlier in response to your comments).

Hans

The SDP usage for IDMS follows the rules defined in RFC3611 in section 5 on
SDP signalling, with the exception of what is stated here. The IDMS usage of
RTCP is a (loosely coupled) collaborative parameter, in the sense that
receivers sent their status information and in response (asynchronously) the
MSAS sents synchronization instructions. Both the sync-group parameter
(defined by ETSI TISPAN) and the rtcp-idms parameter (defined in this
document) thus indicate the ability to sent and the ability to receive
indicated RTCP messages. This section defines how these SDP parameters
should be used, and thus also explains how compatibility with the TISPAN
solution is arranged for.

As described in Section 1.4, ETSI TISPAN has described its mechanism for
IDMS in [TS183063].  One of the main differences between the TISPAN document
and this document is the fact that the TISPAN solution uses an RTCP XR block
for both the SC->MSAS message and the MSAS->SC message (by selecting
SPST-type 2), while this document specifies a new RTCP Packet Type for the
MSAS->SC message.  The message from MSAS to SC is not in any way a report on
how a receiver sees a session, and therefore a separate RTCP packet type is
more appropriate than the XR block solution chosen in ETSI TISPAN. To
achieve compatibility, MSAS implementations SHOULD implement both the TISPAN
RTCP block and the new RTCP IDMS report for MSAS->SC messages. SCs MAY
implement support for both types of messages. For the MSAS->SC signaling, it
is recommended to use the RTCP IDMS report defined in this document.  The
TISPAN RTCP XR block with SPST=2 MAY be used for purposes of compatibility
with the TISPAN solution, but MUST NOT be used if all nodes involved support
the new RTCP IDMS report.

Most of the times, the IDMS SDP parameters will be used in the offer/answer
context. Receivers will indicate in their SDP which RTCP messages they
support. 

For a unicast situation, three situations are possible in offer/answer
context:

- If a receiver indicates at least the rtcp-idms SDP parameter, the MSAS
SHOULD reply with only the rtcp-idms parameter and use only the RTCP IDMS
report for MSAS->SC communication.

- If a receiver indicates only the sync-group SDP parameter, and the MSAS
also supports this, it SHOULD reply with only the sync-group parameter and
use only the RTCP XR block with SPST=2 for MSAS->SC communication.

- If a receiver indicates only the sync-group SDP parameter, and the MSAS
does not support this, the media sender MUST ignore the parameter. This
receiver will not become part of the synchronization session.

Note that it is possible that for a certain synchronization group, that the
MSAS sends RTCP IDMS packets to one receiver and RTCP XR IDMS blocks with
SPST=2 to another receiver.

In a multicast situation using the offer/answer context, it will work a bit
differently. The negotiation is the same as in the unicast situation. But,
the MSAS will multicast all RTCP messages to all receivers. So:

- If all receivers support the RTCP IDMS report, the MSAS SHOULD only sent
the RTCP IDMS report for MSAS->SC messages.

- If not all receivers support the RTCP IDMS report, but all receivers
support the TISPAN solution, the MSAS SHOULD only sent the RTCP XR block
with SPST=2 for MSAS->SC messages.

- If some receivers support only the RTCP IDMS report and other receivers
support only the TISPAN solution, the MSAS SHOULD sent both the RTCP IDMS
report and the RTCP XR block with SPST=2 for MSAS->SC messages. This is less
efficient, since the information sent is duplicated, but this is the only
way to include all receivers in a synchronization session in this scenario.

In certain multicast situations, there is no offer/answer context. In that
case, the MSAS SHOULD use only the RTCP IDMS packet type and thus use only
the SDP parameter rtcp-idms. Receivers that do not support the RTCP IDMS
packet will just ignore both the SDP parameter and the RTCP IDMS packets,
and will thus not join the synchronization session. For compatability with
the TISPAN solution, the MSAS MAY choose to use the RTCP XR IDMS block type
instead, using the SDP parameter sync-group. The media sender SHOULD NOT use
both parameters at the same time in this case of no offer/answer context.

Hi Ray,

 

Roni

Hi Roni,

Ray

Hi, 

RvB: Ok.

Roni Even as Individual