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

[Magnus Westerlund <[e-mail]>]

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-types.xml
>
> 
- Add the XR SDP parameter:
> http://www.iana.org/assignments/rtcp-xr-sdp-parameters/rtcp-xr-sdp-parameters.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]
----------------------------------------------------------------------