[xrblock] Comments on draft-ietf-xrblock-rtcp-xr-synchronization-01

[Mario Montagud Climent <[e-mail]>]

Hi all,

We (Fernando Boronat and me) have reviewed the updated version of the  
draft-ietf-xrblock-rtcp-xr-synchronization-01 and read the issues  
associated to this draft that raised recently in the mailing list.
Here are our comments and suggestions:

Comments regarding the 'Initial Synchronization Delay' Metric:

- We still find a bit confusing the definition of this metric.

We are dealing with INTER-STREAM Synchronization Delay, so we think  
the word INTER-STREAM should be added in the definition of this metric  
for better clarity.

As we understand from the RFC 6051, an appropriate definition could  
be: "In multimedia streaming services, the (inter-stream)  
synchronization delay refers to the time difference between the moment  
a user joins a (multicast) multimedia session, probably involving more  
than one media streams (e.g., audio and video, or when using layered  
and/or multi-description codecs), and the instant when the correlated  
media streams can be synchronously presented to that user, i.e. when  
RTCP packets (including SDES and SR reports), or when the first RTP  
packets with header extensions including in-band synchronization  
metadata, have been received on all the involved RTP sessions in the  
multimedia session".

This draft applies the metric defined in RFC 6051 for receivers. As  
recently discussed in the mailing list, we also think that the method  
of measurement of this metric when a set of receivers are involved in  
a multimedia session (probably involving several RTP sessions) is not  
clear enough, mainly due to the use of "the instant when a member  
joins a media session" as the reference point.

In such a case, the receiver may probably join a group of RTP sessions  
(multimedia session), so we think that the "Initial Sync Delay" in  
this draft should be defined using as a reference point a specific  
reference RTP session. Otherwise, is it expected that a receiver will  
join all the correlated RTP sessions almost simultaneously?

We understand that the minimization of this metric is important in  
multimedia streaming services, e.g. for minimizing zapping delays, but  
we would like to see in this draft the utility of this RFISD block.  
For example, should the receiver of this report (we assume the media  
source) do something when receiving it? Is this RFISD block only used  
for informational purposes?

Furthermore, is it expected that all the receivers join the multimedia  
session (or the group of RTP sessions) almost simultaneously? For  
instance, there could be significant delay differences between the  
instants at which different receivers join the same multimedia session  
(or the set of RTP sessions). In such a case, the measurement of the  
inter-stream synchronization delay should not have the same reference  
point for all of the receivers. Do we need some mechanisms to  
establish the same reference point or to indicate the exact instant  
for the reference point in each receiver?

We also think that the terms "start/beginning of session" in the text  
should be replaced or better explained.

- We also think that using 1/65536 second units (giving 15 microsecond  
accuracy), instead of a 64-bit timestamp, should be accurate enough  
for Initial Sync Delay Reporting. But, wouldn?t be more practical and  
simpler the use of the same measurement units for both XR blocks?

- "SSRC of Media Source" -> Shouldn?t this draft specify a policy for  
choosing the component SSRC of a multimedia session to report on this  
metric? The draft indicates an arbitrary stream, maybe an option  
should be the SSRC identifier of a multimedia session with the longest  
RTCP reporting interval ...


Comments regarding the 'Synchronization Offset' Metric:

- We also agree that reporting synchronization offset per report basis  
(instead that for packet basis) can be sufficient.

- We think that the definition of this metric is clearer as it is now  
in the draft.

We agree with the importance of minimizing the "sync offset" for  
guaranteeing QoE. As specified in RFC 3550, synchronization between  
two media streams, i.e. inter-stream synchronization, can be achieved  
by using the source identification (i.e. the CNAME item), included in  
the SDES reports, and the NTP-RTP timestamps correlation info,  
included in the SRs, from the different media streams.

So, as for the other RFISD block, we would like to see the utility of  
this block in the draft. Should the receiver of the RFSO block (we  
assume the media source/s) do something (e.g. adaption mechanisms)  
when receiving it? Is this RFSO block only used for informational  
purposes? We think this should be clarified in the draft for both XR  
blocks.

- The draft specifies a new XR block for reporting Synchronization  
Offset between correlated media streams. One of the streams is  
selected as the reference, so we think that some criteria for choosing  
that reference (i.e., master) media stream should be added in the  
draft. Otherwise, different receivers could select different streams  
as the reference one.

Now, the dhe draft indicates (on page 6) that the reference stream  
"can be chosen as the arbitrary stream with minimum delay according to  
the common criterion defined in section 6.2.2.1 of [Y.1540]".

Using this mechanisms, different receivers could select different  
streams as the reference one. Could this be problematic?

Another question is: should each one of the receivers report on the  
"sync offset" for each one of the involved slave streams (in the  
multimedia or layered session) regarding the reference stream (i.e.,  
the one with offset zero)? Or, alternatively, is it sufficient on  
reporting the "sync offset" between the most lagged and most advanced  
streams? In such a case, which SSRC should be the reporting stream for  
the RFSO? We think this should be clarified in the draft.


- About the inclusion of signed or un-signed timestamps values for the  
"Sync Offset" metric, we see very reasonable the discussions raised  
recently in the mailing list.

This draft does not specify definitive criteria on selecting the  
reference media stream. The document indicates (on page 6) that the  
reference stream "can be chosen as the arbitrary stream with minimum  
delay according to the common criterion defined in section 6.2.2.1 of  
[Y.1540]".

Maybe, if we do not want to include signed values or omit the  
"Lag/Lead" bit, the simplest solution could be to select the slowest  
(i.e. most lagged) or the fastest (i.e. more advanced) stream as the  
reference stream. This reference stream can be identified by the  
receiver of this report because its SSRC is included (SSRC of  
Reference) in the RFSO block. This way, the offset value will also  
have the same interpretation: the time difference between the  
reference (i.e. most lagged/advanced) and the reporting stream,  
identified by "SSRC of Source".

Selecting the stream with the lowest delay as the reference could be  
an issue for live streams, since receivers cannot speed up a (slave)  
live stream to become synchronized.

If we do not want this unique use case, i.e. if we want the reference  
stream can be an arbitrary stream, then we will need to decide on one  
of the proposals discussed in the mailing list for that, for example,  
the one currently included in the draft.

- And, finally, in our opinion, a very important issue is:

This draft specifies the Synchronization Offset between correlated  
media streams taking into account the arrival times of RTP packets for  
the considered streams (see formula on page 8).

Working on reception times could not be enough accurate for use cases  
with stringent inter-stream synchronization requirements, especially  
when different types of media streams are involved. This is because  
the different RTP streams could experience variable delays at the  
receiver side, i.e. from the reception instant of RTP packets until  
the instant at which the media units (e.g. video frames or audio  
samples) included in these RTP packets are played out, mainly due to  
different de-packetizing, de-payloading, de-coding, rendering,  
processing delays, etc.  So, if we want to report on accurate sync  
offset values, we should consider presentation times for the involved  
media streams, as in our IDMS draft. Do you think this requirement is  
also needed for this draft?

Another issue when measuring "sync offset" (per report basis)  
considering RTP arrival times is that this measurement can be  
significantly affected by the existence of network jitter. As the  
streams are sent independently, the RTP packets (or the specific RTP  
packet for which this metric is reported) of media stream A could  
experience low jitter delays, whilst the RTP packets (or the specific  
RTP packet for which this metric is reported) of media stream B could  
(sporadically) experience high jitter delays, so this would lead to  
the reporting of high and variable "sync offsets" values. So, this  
will not provide a smooth, but a variable, measurement.

- For both XR blocks defined in this draft, it is stated that: "If the  
measurement is unavailable, the value of this field with all bits set  
to 1 SHOULD be reported". But, if the measurements are unavailable,  
why these XR blocks are needed? Would not it be better to simply not  
sending these XR blocks?

- Finally, we think that this draft should indicate when the proposed  
XR blocks are sent. Should the RFISD block be sent only once per media  
session? Should the RFSO block be sent in each RTCP report interval in  
a compound RTCP packet?

Proposed minor changes to the text:

- Abstract: "and associated with SDP parameters" -> "and the  
associated SDP parameters".

Should the SDP acronym be defined in the abstract?

- Section 1.

The second paragraph should be re-written for better clarity. In our  
opinion the terms "to establish multimedia session?, ?start of RTP  
sessions" or "acquires all components of RTP sessions" should be  
clarified all over the document.

"with the same RTCP CNAME included in RTCP SDES packets" -> "with the  
same CNAME item included in RTCP SDES packets"

Is the term "General" needed in the definition of the XR block: "RTP  
Flow General Synchronization Offset Report Block"? If so, shouldn?t be  
its BT identifier RFGSO, instead of RFSO? In some places of the text,  
it appears without the word "General".

- Section 2. See our comments about the definition of the metrics.

"or in different media types" -> "or OF different media types"

"time difference of" -> "time difference BETWEEN"

- Section 3.

(line 3) "or the multimedia session" -> "or a multimedia session  
(probably involving more than one correlated RTP sessions)"

"The component RTP session" -> "The component RTP sessions"

"in multimedia session" -> "in a multimedia session"

"is contributed to such initial synchronization playout" ->  
"contributes to such initial delay for synchronizing playout".

"In the presence/absence of packet loss" -> "In the presence/absence  
of RTCP packet loss"

(line 21) "needs to based" -> "needs to be based"

"For example, one audio stream and one video stream belong to the same  
session and audio stream are transmitted lag behind video stream for  
multiple tens of milliseconds" -> "For example, one audio stream and  
one video stream belonging to the same session, and the audio stream  
is transmitted behind the video stream for multiple tens of  
milliseconds (i.e. the audio stream is lagged regarding the video  
stream)"

"between video stream and audio stream" -> "between the video and the  
audio streams"

- Section 4.

"RTP Flows Initial Synchronization Delay Report Block" vs "RTP Flow  
Initial Synchronization Delay  Metrics Block" -> The same name should  
be used all over the document.

- Section 5.

(line 3) "is sent" -> "can be sent"

"reports synchronization offset of the arbitrary two RTP streams" ->  
see our comments above.

- Section 6.1. The SDP acronym is already defined before.

- Section 7.

"for RTCP XR" -> "for RTCP XR blocks"

Hope it helps

Best Regards,

Fernando & Mario.



"Huangyihong (Rachel)" <[e-mail]> escribió:

> Hi folks,
>
> We have just updated draft-ietf-xrblock-rtcp-xr-synchronization. In  
> this version, we addressed the issues raised recently in the mailing  
> list. If you have any different opinions, please let us know.
>
> Best Regards!
> Rachel
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Thursday, October 18, 2012 1:46 PM
> To: Qin Wu
> Cc: Huangyihong (Rachel); [e-mail]
> Subject: New Version Notification for  
> draft-ietf-xrblock-rtcp-xr-synchronization-01.txt
>
>
> A new version of I-D, draft-ietf-xrblock-rtcp-xr-synchronization-01.txt
> has been successfully submitted by Qin Wu and posted to the
> IETF repository.
>
> Filename:	 draft-ietf-xrblock-rtcp-xr-synchronization
> Revision:	 01
> Title:		 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for  
> Synchronization Delay and Offset Metrics Reporting
> Creation date:	 2012-10-18
> WG ID:		 xrblock
> Number of pages: 11
> URL:              
> http://www.ietf.org/internet-drafts/draft-ietf-xrblock-rtcp-xr-synchronization-01.txt
> Status:           
> http://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-synchronization
> Htmlized:         
> http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-synchronization-01
> Diff:             
> http://www.ietf.org/rfcdiff?url2=draft-ietf-xrblock-rtcp-xr-synchronization-01
>
> Abstract:
>    This document defines two RTP Control Protocol (RTCP) Extended Report
>    (XR) Blocks and associated with SDP parameters that allow the
>    reporting of synchronization delay and offset metrics for use in a
>    range of RTP applications.
>
>
>
>
> The IETF Secretariat
>
> _______________________________________________
> xrblock mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/xrblock
>