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

From: Mario Montagud Climent <[email-masked]>
Date: Sat, 03 Nov 2012 19:51:58 +0100

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)" <[email-masked]> 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: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, October 18, 2012 1:46 PM
> To: Qin Wu
> Cc: Huangyihong (Rachel); [email-masked]
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xrblock
>

---

From: Qin Wu <[email-masked]>
Date: Tue, 6 Nov 2012 03:24:54 +0000

Hi,Mario and Fernando:
Thank for your valuable reviews. Let me try to clarify your concerns.
Also please see my reply below inline.

Regards!
-Qin

-----邮件原件-----
发件人: Mario Montagud Climent [mailto:[email-masked]] 
发送时间: 2012年11月4日 2:52
收件人: [email-masked]
抄送: Huangyihong (Rachel); Hitoshi Asaeda; Qin Wu
主题: Comments on draft-ietf-xrblock-rtcp-xr-synchronization-01

Hi all,

[Qin]:The Initial Synchronization delay we are using for this metric is clearly 
Specified in RFC6051. The key feature is "Initial" rather than "inter-stream".
I don't believe it is referred to time different between two stream. Rather than,
It means how long it take to receive all the components of multimedia session
Or layer session. But I agree inter-stream is applied to synchronization offset metric
We defined in this draft.

[Qin]: Looks good to me except the wording about "inter-stream".

[Qin]: Agree with you opinion, we can't assume the receiver joins 
Multiple session simultaneously.

[Qin]: The information in this metric report can be used by the receiver of this
Report to compare actual initial synchronization delay to targets (i.e., a
   numerical objective or Service Level Agreement) to help ensure the
   quality of real-time application performance.

[Qin]: we allow different receivers report the different initial synchronization delay.
Since these receiver joins at different time. It doesn't matter since What we report is per receiver metric.

[Qin]: It looks good to me however what accuracy requirements for initial sync Delay have we?
Why the accuracy of the initial sync delay we currently define is not sufficient?

[Qin]: no, we may report on each media stream that belongs to the same multimedia session.

[Qin]: I think the information received from RFSo block is
   valuable to network managers in troubleshooting network and user
   experience issues.

[Qin]:Good question, we may choose
the SSRC identifier of one session in multimedia session with the longest  
RTCP reporting interval since RFSO deal with multiple sessions that belong to the same multimedia session.

[Qin]: I think we should allow both. What we need to do is to choose a reference stream 
Based on some criteria.

[Qin]: Okay, I tend to agree with your first proposal.

[Qin]: Not sure about this, would you like to clarify how to use presentation times to calculate sync offset?

[Qin]: We have proposed to change RTP time stamp into NTP timestamps.

[Qin]: these XR block may be sent in each RTCP report interval, if we not send them to the receiver of XRBLOCK,
the receiver will regard these XRBLOCK are lost, which is not what we expected.

[Qin]: For RFISD, both allows, but I think it more makes sense to send only once per media session.

[Qin]: Okay.

[Qin]: Okay.

- Section 1.

[Qin]: Okay.

[Qin]: Okay.

[Qin] Okay, will fix this in the later version.

[Qin]: Okay.

- Section 3.

[Qin]: Okay.

- Section 4.

[Qin]: Okay.

- Section 5.

[Qin]: Okay.

- Section 7.

[Qin]: Okay. Many thanks.

Hope it helps

Best Regards,

Fernando & Mario.

---

From: Mario Montagud Climent <[email-masked]>
Date: Thu, 08 Nov 2012 20:30:28 +0100

Hi Qin, Rachel, all,

See our comments inline.

Qin Wu <[email-masked]> escribió:

> -----????-----
> ???: Mario Montagud Climent [mailto:[email-masked]]
> ????: 2012?11?4? 2:52
> ???: [email-masked]
> ??: Huangyihong (Rachel); Hitoshi Asaeda; Qin Wu
> ??: Comments on draft-ietf-xrblock-rtcp-xr-synchronization-01
>
>
> Hi all,
>

[F & M] We didn't refer to the time difference (offset) between  
different streams, but to the time difference between joining a  
multimedia session (or a reference RTP session) and the instant at  
which all involved media streams can be initially presented to the  
users in a synchronous way. Therefore, we think this metric gives the  
INITIAL delay for INTER-STREAM synchronization, because all the  
involved media streams cannot be synchronously presented to the users  
until the info needed for synchronizing all of them (included in RTCP  
packets or in RTP header extensions, as specified in RFC 6051) has  
been received on all the component RTP sessions. This was our  
rationale for including the term INTER-STREAM in this definition.

> Multiple session simultaneously.

[F&M] OK

>    quality of real-time application performance.

[F&M] We suggest adding a similar paragraph to the draft.

> Since these receiver joins at different time. It doesn't matter  
> since What we report is per receiver metric.

[F & M] Ok. But, in this way, if different receivers, even under  
similar network conditions (e.g., delays, jitter?), join the session  
at different instants, but inside the same RTCP report interval (i.e.,  
between two consecutive RTCP packets sent by the media source for that  
session), there could be significant differences between the "Initial  
Sync Delays" reported by each one of them. For example, depending on  
the joining time, a receiver A could receive the RTCP packets from all  
the RTP sessions with larger/lower initial delay than another receiver  
B if the latter joined the session before/later than the former.

Even though you only want to "compare actual initial synchronization  
delay to targets (i.e., a numerical objective or Service Level  
Agreement)", as pointed out in your previous comment, could the above  
situation be problematic?

> Why the accuracy of the initial sync delay we currently define is  

[F & M] We think this accuracy is sufficient. Our comment was because  
of simplicity (this way, both reports could employ the same  
measurement unit).

> [Qin]: no, we may report on each media stream that belongs to the  

[F & M] Not sure we are following you here. Must one RFSI block be  
sent per each SSRC (of each one of the involved RTP sessions) in a  
multimedia session? Should not be easier to report only on one  
reference RTP session?

We see different options for selecting the reference RTP session for  
the "initial sync delay" (i.e. the reference point for this  
measurement).

One option could be selecting the session with the longest RTCP  
reporting interval, as you proposed. Here, we think the "delay for  
RTCP reporting interval" concept must be defined accordingly to avoid  
a possible misleading. On one hand, we can see the delay for the RTCP  
reporting interval for a media session as the time difference between  
two successive RTCP packets from this media session. On the other  
hand, we can also see, from the receiver point of view, the delay for  
the RTCP reporting interval as the time difference between joining a  
media session and receiving the first RTCP packet from that media  
session. In the latter case, the delay for the RTCP reporting interval  
will depend on the specific joining time for that each receiver (each  
receiver can join a session in a different instant during the RTCP  
reporting interval). We propose to clarify this in the draft, if  
adopted.

Another option could be "choosing the time when the first/ last RTP  
session is joined as the beginning of the multimedia session", as  
Rachel proposed.

We see as a more feasible option to choose the time when a receiver  
joins the FIRST RTP session of the multimedia session as the  
starting/reference point for the "initial sync delay" measurements.  
The use of the RTCP reporting delay for choosing a reference session  
could be problematic.

But, in the way we are proposing, we are assuming that the joining  
time for the first RTP session can be known for all the other RTP  
sessions involved in the multimedia session (if we do not want to  
assume this info can be accessible between the RTP sessions, we will  
have to assume that the joining time is almost the same for all the  
RTP sessions).

> belong to the same multimedia session.

[F & M] Thanks. We are not sure about the suitability of this  
assumption. We do not see why the "stream with the longest RTCP  
reporting interval" should be selected as the reference stream for the  
"sync offset" measurement because of the above discussion. We think  
other mechanisms should be discussed. Possible options include the  
most lagged/advanced RTP media streams (i.e. the ones with the  
highest/lowest reception or presentation, i.e. end-to-end, delays) or  
a fixed reference stream selected based on other criteria.

Besides, the delay for the RTCP reporting interval does not have to be  
necessarily linked to the delay for the RTP media stream. A media  
session could have the longest RTCP reporting interval, but the delay  
for its RTP media stream could be acceptable.

For the "sync offset", we think it is better that the reference stream  
is selected based on the experienced delay for the involved RTP  
streams, because the sync offset is measured for the RTP streams, and  
the associated sync adjustments to minimize this offset are also  
performed on the RTP streams.

> [Qin]: Okay, I tend to agree with your first proposal.

[F&M] Thanks
> [Qin]: Not sure about this, would you like to clarify how to use  
> presentation times to calculate sync offset?
>

[F & M] In order to use presentation times, we would need to track RTP  
packets from their arrival to their presentation (or play out) times.  
This can be seen as a form of layer-violation in some RTP  
implementations, as previously discussed in the AVTCORE list for our  
IDMS draft. That is the reason why, in our IDMS draft, reporting on  
presentation times is optional, but reporting on arrival times is  
mandatory.

But, if presentation times are supported, the sync offset could be  
easily (and more accurately) calculated than in the current proposal.  
The calculation is as follows:

Different times for stream A: t_i_A (transmission time, i.e. RTP  
timestamp of i-th RTP packet of stream A), r_i_A (NTP-based arrival  
time of i-th RTP packet of stream A), p_i_A (NTP-based presentation  
time of i-th RTP packet of stream A)

Different times for stream B: t_j_B (transmission time, i.e. RTP  
timestamp of j-th RTP packet of stream B), r_j_B (NTP-based arrival  
time of j-th RTP packet of stream B), p_j_B (NTP-based presentation  
time of j-th RTP packet of stream B).

Therefore, the sync offset between stream A and B can be calculated as:

- Using presentation times: (p_i_A - t_i_A) - (p_j_B - t_j_B), this  
gives the end-to-end delay variability

- Using reception times: (r_i_A - t_i_A) - (r_j_B - t_j_B), this gives  
the network delay variability

* Note that we are assuming that RTP timestamps can be mapped to  
NTP-format timestamps (for the RTP transmission timestamps), based on  
the correlation timing info included in RTCP SRs.

Therefore, we think that using presentation timestamps the measurement  
of the "sync offset" metric will be more accurate (and smoother) than  
using reception times, because of the variable delays at the  
distribution and at the receiver sides.

> [Qin]: these XR block may be sent in each RTCP report interval, if  
> we not send them to the receiver of XRBLOCK,

[F & M] We assume that these RTCP report blocks will be sent in  
compound RTCP packets. Regarding the RFSI block, we assume that it is  
only needed once per session (since it reports on INITIAL Sync Delay,  
it is not needed during the session lifetime). Regarding the RFSO  
block, we think that two options could be employed: 1) to send this  
block in each RTCP report interval, independently of the value of the  
"sync offset"; 2) to send this block only if the value of the "sync  
offset" exceeds a configurable allowed asynchrony threshold.

Therefore, if these XR blocks are not included in the received RTCP  
compound packet, we think it can be assumed that the metrics these  
blocks report on are not available, without the need of sending the  
block reports (because in such a case, these reports do not contain  
any further statistics).

Best Regards,

Fernando & Mario.

---

From: Qin Wu <[email-masked]>
Date: Thu, 15 Nov 2012 17:03:08 +0800

Hi,Mario:
Thank for your long length comments.:-) I remove the comments we have no issues. 
Please see my reply inline below.

Regards!
-Qin
----- Original Message ----- 
From: "Mario Montagud Climent" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>; "Huangyihong (Rachel)" <[email-masked]>; "Hitoshi Asaeda" <[email-masked]>
Sent: Friday, November 09, 2012 3:30 AM
Subject: Re: ??: Comments on draft-ietf-xrblock-rtcp-xr-synchronization-01

> rationale for including the term INTER-STREAM in this definition.

[Qin]: my understanding is the initial synchronization delay we care about is total 
time difference between the first stream is joined and all the streams are syncronized. 
We don't care about the initial synchronization delay between any either two streams
 in the multimedia session.

So add "inter-stream" may confuse people we are measuring time difference or synchronization
offset between two streams.

[Qin]: Okay.

> of simplicity (this way, both reports could employ the same  

[Qin]: Looks good to me. Let's see what other people think.

> [F & M] Not sure we are following you here. 

>Must one RFSI block be  

[Qin]: Sorry, I thought you comment on synchronization offset. I take back what I said here.
I think you are correct. It is more reasonable to report only on one reference RTP session.
> have to assume that the joining time is almost the same for all the  
[Qin]: Good points, In the meeting, we did discuss this issue, we think choosing RTP session
with longest interval is not reasonable since report interval may change with session size.
We believe choosing the time when the first RTP session is joined is a good choice
for the measurement starting point.

> a fixed reference stream selected based on other criteria.

[Qin]: Looks better than my proposal. :-)

> performed on the RTP streams.

[Qin]: Agree.

> distribution and at the receiver sides.

[Qin]: Your proposal is using presentation timestamp which is quite different what
we are currectly proposing in the draft. We will verify your proposal to see which approach
is better.

> block reports (because in such a case, these reports do not contain  

[Qin]: What about these RTCP report block is not sent in the compound RTCP packet?

---

From: Mario Montagud Climent <[email-masked]>
Date: Mon, 26 Nov 2012 14:43:19 +0100

Hi Qin, all,

We were happy to help! :)

See our comments inline.

Qin Wu <[email-masked]> escribió:

> Cc: <[email-masked]>; "Huangyihong (Rachel)"  
> <[email-masked]>; "Hitoshi Asaeda" <[email-masked]>

[F&M] If you think adding "inter-stream" can confuse the readers, this  
is OK for us.
But in compound sessions, we think "inter-stream" sync relates to the  
timing offset between all involved media streams, not only between two  
streams. Anyway, it is up to you.

> [Qin]: Looks good to me. Let's see what other people think.

[F&M] Ok

> I think you are correct. It is more reasonable to report only on one  

[F&M] Ok :) Thanks!

> for the measurement starting point.

[F&M] Ok

> [Qin]: Looks better than my proposal. :-)

[F&M] Ok. Thanks!

> proposal to see which approach

[F&M] Ok.

> [Qin]: What about these RTCP report block is not sent in the  

[F&M] Do you mean sending these reports as immediate and reduced-size  
RTCP packets?

Best Regards,

Fernando & Mario

---

From: Qin Wu <[email-masked]>
Date: Tue, 27 Nov 2012 10:37:12 +0800

Thanks Moria.:-)!
Please see my reply to your last comment.

Regards!
-Qin
----- Original Message ----- 
From: "Mario Montagud Climent" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>; "Huangyihong (Rachel)" <[email-masked]>; "Hitoshi Asaeda" <[email-masked]>
Sent: Monday, November 26, 2012 9:43 PM
Subject: Re: ??: Comments on draft-ietf-xrblock-rtcp-xr-synchronization-01

> [F&M] Do you mean sending these reports as immediate and reduced-size  

[Qin]: You misunderstand what I said. Sorry for bringing you confusion.
I think for the option 1) to send this
block in each RTCP report interval, independently of the value of the
"sync offset", the RTCP report block MUST be sent to the XR BLOCK receiver 
in each report interval, otherwise XR Block receiver will assume RTCP report block is
lost rather than measurement is not available, one extreme case, is all the XR report blocks 
carried in the same compound packet is lost. So if the sender of XR block fail to measure
 the results, the sender of XR block still send
the XR report block with all bits set to 1 to show that the measurement is available.

However for option 2) you mentioned, i.e., to send this block only if the value of the "sync
offset" exceeds a configurable allowed asynchrony threshold. In this case, I agree with you
the XR Block sender can choose not to send report block in the Compound packet.

We will think about whether we should support only option 1 ) or need to support both option1) and option 2).