Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05

["Brandenburg, R. (Ray) van" <[e-mail]>]

Hi Magnus, All,

I promised to get back to you on the following point:

> 7. Section 6. Assuming that the normative definition will remain and 
> possibly also as a clarification to the ETSI specification: This 
> section is not making it sufficient clear that what an SC is supposed 
> to do is to pick one RTP packet it recevied, then report the values 
> for this particular packet. I think one should clarify this and also 
> making it clearer what the selection criteria for such a packet is.
> Should one focus on using maximum delayed packets, media delayed 
> packets or simply random selection? In addition we have the rules 
> about picking packets when multiple RTP sequence numbers have the same 
> TS value. I would recommned that one add some paragraphs before the 
> actual figure definition to discuss this.
> 
> RvB: Good point. In theory it shouldn't really matter. Up to now, we 
> have been assuming random selection, just picking a packet when the 
> RTCP rules allow you to send a report. I will check with my co-authors 
> to see whether they still think this is good enough. I will come back 
> to you on this one.

I checked with my co-authors and we agree that reporting on the 'last' RTP packet to arrive when the RTCP timer is sufficient. In cases where a particular video frame is divided over a number of packets, the client should report on the packet with the lowest sequence number. We will include such a text in the next iteration.

Best regards,

Ray


-----Original Message-----
From: Magnus Westerlund [mailto:[e-mail]] 
Sent: donderdag 28 juni 2012 8:50
To: Brandenburg, R. (Ray) van
Cc: [e-mail]; [e-mail]
Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05

On 2012-06-25 14:15, Brandenburg, R. (Ray) van wrote:
> Hi Magnus,
> 
> Many thanks for the very thorough review. You will find my comments 
> inline.
> 
> Ray
> 
> -----Original Message----- From: Magnus Westerlund 
> [mailto:[e-mail]] Sent: donderdag 21 juni 2012
> 15:53 To: [e-mail]; [e-mail]
> Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05
> 
> Hi,
> 
> This is my WG last call review as an individual. I think there is 
> quite a lot to address before this document is ready for publication 
> request.
> 
> 1. This document has 6 authors listed. This is one more than the 
> policy allows: http://www.rfc-editor.org/policy.html#policy.authlist
> 
> RvB: See my other mail.
> 
> 2. Abstract: "This document gives information on an RTCP Packet Type 
> and RTCP XR Block Type including associated SDP parameters for 
> Inter-Destination Media Synchronization (IDMS)."
> 
> Doesn't it define these packet/block types?
> 
> RvB: We will change the abstract to reflect the contents more 
> accurately. The draft defines the RTCP Packet Type and mandates the 
> use of the ETSI-defined XR Block Type, which is included in the draft 
> for sake of completeness.
> 
> 3. Section 3:
> 
> The ladder diagrams first line is wrongly indented.
> 
> RvB: OK.
> 
> 3. Section 3. Ladder diagram, maybe this diagram should have some 
> handle, like figure 1 with a label.
> 
> RvB: OK.
> 
> 4. Section 3. I am missing discussion on the overview level of clocks. 
> Yes it is present later, but I think the topic should be introduced 
> already here is section 3.
> 
> RvB: Good idea. We will include a short section to discuss this.
> 
> 5. Section 6. I think this section should make it clear how an SC can 
> include multiple report blocks for different received sources. In 
> general I think this may be a topic that needs to be lifted into the 
> overview. The issue I see is the following ones.
> 
> a) Within a multi-party communication session different media senders 
> include different reference clocks. Thus creating multiple 
> synchronization groups within the context of one multi-media 
> communication session.
> 
> b) even if they can agree on using the same clock reference they still 
> need to enable the fact that an end-point is acting as MSAS for some 
> media sources and SC for others. This should be made more clear.
> 
> RvB: I agree that these are both valid scenarios. However, I'm not 
> sure whether they pose a problem. In the case where an SC has to 
> report on multiple groups, it will just send multiple report blocks 
> (possibly concatenated using RTCP rules). Do I miss something here?

No, I don't think they represent any significant issues. It just that I think it is worth pointing out that this is expected and that implementations needs to handle such situations. Many implementors reads the spec and looks at the examples and if it is not spelled out that these are valid cases they might not implement to support them.

> 
> 6. Section 6 appears to be a normative definition of RTCP XR block 
> type 12. That block type is registered by IANA as belonging to ETSI
> 183 063 specification. Unless we have a formal liasion assigning the 
> change right to IETF I don't see how we can make an updated normative 
> specification of this XR block type. I see two options.
> 
> a) IETF are given the change right over the block type
> 
> b) IETF makes a normative reference to the ETSI specification of the 
> block type and then simply makes it clear that they only uses SPST=1.
> 
> RvB: I fully agree with the problems of trying to change the 
> specification. When starting this work, we have therefore decided to 
> go for your route B).

Ok, I have no issues with that, however it must be much more clear and explicit that the ETSI spec is the normative one.

> 
> 7. Section 6. Assuming that the normative definition will remain and 
> possibly also as a clarification to the ETSI specification: This 
> section is not making it sufficient clear that what an SC is supposed 
> to do is to pick one RTP packet it recevied, then report the values 
> for this particular packet. I think one should clarify this and also 
> making it clearer what the selection criteria for such a packet is.
> Should one focus on using maximum delayed packets, media delayed 
> packets or simply random selection? In addition we have the rules 
> about picking packets when multiple RTP sequence numbers have the same 
> TS value. I would recommned that one add some paragraphs before the 
> actual figure definition to discuss this.
> 
> RvB: Good point. In theory it shouldn't really matter. Up to now, we 
> have been assuming random selection, just picking a packet when the 
> RTCP rules allow you to send a report. I will check with my co-authors 
> to see whether they still think this is good enough. I will come back 
> to you on this one.

Good

> 
> 8. Section 6, PT field definition. This is not making clear that one 
> shall report the PT of the packet one is reporting on.
> 
> RvB: Ok.
> 
> 9. Section 6. Media Stream Correlation Identifier: 32 bits.  This 
> identifier is used to correlate synchronized media streams.  The value 
> 0 (all bits are set "0") indicates that this field is empty.
> The value 2^32-1 (all bits are set "1") is reserved for future use.
> If the RTCP Packet Sender is an SC (SPST=1) or an MSAS (SPST=2), then 
> the Media Stream Correlation Identifier maps on the Synchronization 
> Group Identifier (SyncGroupId) to which the report applies.
> 
> It is not clear what "maps" means here. Considering that the field 
> appears to carry the full syncgroupID I think another formulation 
> shall be used.
> 
> RvB: We will rephrase this paragraph to make it more clear.
> 
> 10. Section 6. "To solve this, an SC SHOULD report on RTP packets in 
> which a certain RTP timestamp shows up for the first time."
> 
> Does this means with the lowest sequence number or the packet first to 
> arrive with that TS?
> 
> RvB: The lowest sequence. We will clarify this sentence.
> 
> 11. Section 7 Title "RTCP Packet Type for IDMS (IDMS report)"
> 
> Why is the packet used to distribute the intended playout timing 
> called a "report". This is very confusing considering that the XR is a 
> report also.
> 
> RvB: Sorry, you're right. We'll come up with a better name.
> 
> 12. Section 7.
> 
> SSRC: 32 bits.  The SSRC of the media source SHALL be set to the value 
> of the SSRC identifier carried in the RTP header [RFC3550] of the RTP 
> packet to which the RTCP IDMS packet relates.
> 
> First of all I assume this field definition is for "SSRC of media 
> source" field.
> 
> RvB: Correct
> 
> a. What isn't clear is if it is at all valid that another SSRC "SSRC 
> of packet sender" than the "SSRC of media source" is allowed and shall 
> be considered valid.
> 
> RvB: We have always assumed the SSRC of Media Source scenario. Do you 
> think there is a good reason to support 'SSRC of packet sender' as 
> well?

No, I don't have a use case in mind. This could be useful if one has a separate node taking care of determining a number of source should be played out. At the same time I think it creates thorny security question etc. Today, you can build the authorization to set the playout time on the media source. With this you get in addition to authenticating source you also need to know that the third party setting the playout is authorized to do it on behalf of the media source. I would suggest to skip third party functionality at this point.

> 
> b. Secondly, when an end-point has multiple sources in the same RTP 
> session to send it appears they need to send multiple RTCP packets.
> 
> RvB: Do you mean a scenario where one source sends multiple RTP 
> streams (e.g. audio and video). In that case, it is only necessary to 
> do IDMS for one stream. The rest is lip-sync. The Media-level SDP part 
> describes which stream to perform IDMS for. I will check with my 
> co-authors whether they think it is useful to recommend either audio 
> or video streams here for this purpose.

Lets assume audio only RTP session. I can have two audio source. This means that the end-point needs to set playout for both its sources or rely on lip sync assuming they are using the same CNAME.

I think this opens up to several aspects:

a) The need to describe that you only need to actually provide playout time for one SSRC within a synchronization context, i.e. the SSRC having the same CNAME. I think this needs to be explicit that this can be done in this way. I think you also needs to say what to do if I get playout times for two SSRCs with the same CNAME and they don't match. This spans over both multiple RTP session and multiple SSRCs within a session.

b) The next is that you will receive playout reports from all SSRCs an end-point have in the session. Also here consistency is an important aspect, but I would expect that especially the receive time report will jitter at the same order of the transport jitter.



> 
> 13. Section 7.
> 
> It is not clear if there are any restrictions on the values to be 
> included in the RTCP packet. Must the sender of it include information 
> for a already sent packet, a future packet or can it even be a virtual 
> packet that is never sent?
> 
> I understand that one can scale the figures in this packet to 
> determine what the correct value should be given a received RTP packet 
> and its timestamp. But, are I allowed to calculate a correct time 
> value a year into the future that is then expected to be scaled back. 
> Or is the RTP timestamp value included in the packet in itself an 
> indication for when this information was current?
> 
> RvB: Good point. Because RTP timestamps wrap around, choosing a time 
> far into future may cause problems. So indeed, the timestamp chosen 
> needs to be a (relatively) current one. We will change the section to 
> reflect this.
> 
> 14. Section 8. [I-D.draft-williams-avtcore-clksrc] defines a set of 
> SDP parameters for signaling the clock synchronization source or 
> sources available to and used by the individual receivers.  Using 
> these paramenters, an SC can indicate which synchronization source is 
> being used at the moment, the last time the SC synchronized with this 
> source and the synchronization frequency.  An SC can also indicate any 
> other synchronization sources available to it.  This allows multiple 
> SCs in an IDMS session to use the same or a similar clock source for 
> their session.
> 
> So the clksrc draft appear to indended to define the usage of a=ssrc 
> to make it clear which clock source a particular SSRC uses. What isn't 
> clear from this text is that when providing reporting that all nodes 
> sending a report or a configuration must use their view of that 
> particular clock source. I think the implications of having multiple 
> clock sources in an RTP session must be made clearer. As the used 
> clock comes into play both when configuring, reporting and adjusting 
> time scales for playout.
> 
> RvB: I'm not completely following you here. The synchronization source 
> mentioned here is a wall clock source (e.g. NTP), and not a media 
> clock source. The reference to the clcksrc document is just to provide 
> the reader with the means to perform clock synchronization (and thus 
> improve the accuracy of IDMS). Does this help?

Correct, I hadn't thought through this sufficiently. All SSRCs in one or more RTP session using the same CNAME MUST use the same wall clock, i.e.
same clksrc. If you have different ones you need to use different CNAMES. So it is actually CNAMES and clock sources that should be bound in the signalling.

>From that perspective an end-point could use multiple CNAMES and thus have different clock sources present in the same session. A prime example would be a central node that forwards streams, but do not resynchronize them into a single CNAME. Such an end-point would in an O/A SDP signalling have need to express the different clock source for the other participants in the session.



> 
> 15. Section 9:
> 
> SyncGroupId = 1*DIGIT ; Numerical value from 0 through 4294967294
> 
> As the syncgroupID is limited to 10 digits, why not make that clear in 
> the ABNF also using 1*10DIGIT as the definition.
> 
> Applies also to Section 10.
> 
> RvB: Ok.
> 
> 16. Section 11.
> 
> As someone else noted. This section really needs to be split into 
> Offer/Answer rules and one on TISPAN interop.
> 
> RvB: Agree. We will change this in the next iteration.
> 
> 16. Section 11. Offer/Answer rules It is not clear how one deals with 
> the potential existence of multiple sync groups or how the ID is 
> negotiated. Especially when you in a multi-party negotiate with an 
> application server.
> 
> I also think it should make clear how it works in declarative cases, 
> like RTSP SDPs.
> 
> RvB: We will take up this point in the new version (see previous 
> comment).
> 
> 17. Section 14.
> 
> This IANA registration is insufficient. It needs to be more precise in 
> which regestries that are to be used.
> 
> RvB: Ok. Thanks for you examples.
> 
> To my understand the following actions are required:
> 
> register a media level SDP attribute: This is okay considering the 
> template but one could clarify that the registry intended is the one 
> titled "att-field  (media level only)"
> http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml#sdp-
> parameters-9
>
> 
> 
> One RTCP Control Packet types (PT): 
> http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xml#rtp-
> parameters-3
>
>  And if the XR block type is to be normatively defined by this 
> document then two registrations are needed:
> 
> - New or update of RTCP XR Block Type 
> http://www.iana.org/assignments/rtcp-xr-block-types/rtcp-xr-block-type
> s.xml
>
> 
- Add the XR SDP parameter:
> http://www.iana.org/assignments/rtcp-xr-sdp-parameters/rtcp-xr-sdp-par
> ameters.xml
>
>  18. References. Should [I-D.draft-gross-leap-second] be normative? 
> It is not written in a RFC 2119 style an requirement to take this 
> document into account, so maybe informative is correct.
> 
> RvB: I propose going for informative. The leap-second draft is just a 
> way of increasing the accuracy of IDMS. And since it is meant as an 
> update to RFC3550, can be considered part of RTCP and not specifically 
> targeted at IDMS.

I think that is fine.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------



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