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

From: Kevin Gross <[email-masked]>
Date: Sat, 3 Nov 2012 09:06:23 -0600

Rachel,

Your first proposal fixes one of the two problems in that paragraph. We
still need to improve the definition of the reference point. Adding the RFC
6051 section number would help but I don't think that is defined well
enough there to allow an accurate measurement. Also, as Colin pointed out,
there needs to be a discussion of how to make the measurement when multiple
streams are involved.

The second proposal is looking good until we get to the new last sentence.
For maximum accuracy, we'd like to use the NTP timestamps directly if
they're available. If they're not available, we have to suggest something
else and there's bit more to it than what you've proposed in your last
sentence. If you need a specific suggestion, let me know and I'll have a
think.

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org

On Tue, Oct 30, 2012 at 9:26 PM, Huangyihong (Rachel) <
[email-masked]> wrote:

>  Hi Kevin,****
>
> ** **
>
> Best Regards!****
>
> Rachel****
>
> ** **
>
> *From:* Kevin Gross [mailto:[email-masked]]
> *Sent:* Wednesday, October 31, 2012 2:49 AM
> *To:* Hitoshi Asaeda
> *Cc:* Huangyihong (Rachel); [email-masked]; [email-masked]
>
> *Subject:* Re: [xrblock] Comments on
> draft-ietf-xrblock-rtcp-xr-synchronization-00****
>
>  ** **
>
> The accuracy requirement we've discussed for presentation times is 10
> microseconds or better. I apologize that I have not yet drafted an I-D I
> promised summarizing these requirements. Required range is on the order of
> several seconds, maybe up to a minute. We need most of the bits to the
> right of the decimal in the NTP timestamp but we don't need many to the
> left. The reason we included all 64 is because the 64-bit NTP timestamp is
> the smallest standard timestamp format that gives us the resolution
> required. A non-standard format as small as 40 bits would suffice but RTCP
> is not a particularly bandwidth constrained protocol and the standard
> format and 32-bit word alignment as proposed in the draft should simplify
> implementation.****
>
> ** **
>
> [Rachel]: Thanks for the clarifications. ****
>
> ** **
>
> It looks like I've overlooked issues with Synchronization Delay and
> Synchronization Offset in my previous review.****
>
> ** **
>
> The Synchronization Delay definition needs to provide a more specific
> description of what's being referred to in RFC 6051 for defining the
> reference point for this measurement. Specifically the draft needs to
> define "beginning of session". I don't find such a concept in RFC 6051. RFC
> 6051 section 2.1.1 defines when sessions are joined but probably not in
> enough detail to know how to do a measurement referenced to this point.***
> *
>
> ** **
>
> The text in 4.2 of the delay draft, "from the RTCP packets received on all
> of the components RTP sessions to the beginning of session" might lead some
> implementers to compute a negative Synchronization Delay. Revers the from
> and to clauses in the text or add a formula to clarify.****
>
> ** **
>
> [Rachel]: Good point. How about the following changes?****
>
> OLD TEXT:****
>
> “             The average delay, expressed in units of 1/65536 seconds,
> from the****
>
>       RTCP packets received on all of the components RTP sessions to the**
> **
>
>       beginning of session [RFC6051].****
>
> “****
>
> NEW TEXT:****
>
> “             The average delay, expressed in units of 1/65536 seconds,
> from the****
>
>       time when sessions are joined [RFC6051] to the****
>
>       RTCP packets received on all of the components RTP sessions.****
>
> “****
>
> ** **
>
> There seems to be a dimensional problem in the Synchronization Offset
> definition. Everything in the definition is in units of RTP clock but since
> we're using an NTP timestamp for the report, I assume this is supposed to
> define a quantity in units of NTP time.****
>
> ** **
>
> [Rachel] Okay. I would propose following changes.****
>
> OLD TEXT:****
>
> “****
>
>       That is to say,if Si is the RTP timestamp from the****
>
>       reporting RTP packet i, and Ri is the time of arrival in RTP****
>
>       timestamp units for reporting RTP packet i, Sj is the RTP****
>
>       timestamp from the reference RTP packet j, and Rj is the time of****
>
>       arrival in RTP timestamp units for reference RTP packet j, then****
>
>       the value of the synchronization offset D may be expressed as****
>
>          D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si)****
>
> “****
>
> ** **
>
> NEW TEXT:****
>
> “****
>
>         That is to say, if Si is the NTP timestamp from the****
>
>       reporting RTP packet i, and Ri is the time of arrival in ****
>
>       NTP timestamp units for reporting RTP packet i, Sj is the NTP****
>
>       timestamp from the reference RTP packet j, and Rj is the time of****
>
>       arrival in NTP timestamp units for reference RTP packet j, then****
>
>       the value of the synchronization offset D may be expressed as****
>
>          D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si)****
>
>               Where Si, Ri, Sj and Rj are calculated from theircorresponding
> ****
>
>      RTP timestamps.****
>
> “****
>
> ** **
>

---

From: Kevin Gross <[email-masked]>
Date: Sun, 4 Nov 2012 11:17:42 -0700

Oh, and we shouldn't forget that we need to address the issue of how to
represent the sign of the offset.

Kevin Gross
+1-303-447-0517
Media Network Consultant

On Sat, Nov 3, 2012 at 9:06 AM, Kevin Gross <[email-masked]> wrote:

>> enough detail to know how to do a measurement referenced to this point.**
>> **
>>
>> ** **
>>
>> The text in 4.2 of the delay draft, "from the RTCP packets received on
>> all of the components RTP sessions to the beginning of session" might lead
>> some implementers to compute a negative Synchronization Delay. Revers the
>> from and to clauses in the text or add a formula to clarify.****
>>
>> ** **
>>
>>       RTCP packets received on all of the components RTP sessions to the*
>> ***
>>

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Mon, 5 Nov 2012 00:06:25 +0000

Hi  Kevin,

I’ll appreciate if you could give any suggestions. Thanks in advance.

Best regard,
Rachel

发件人: Kevin Gross [mailto:[email-masked]]
发送时间: 2012年11月3日 23:06
收件人: Huangyihong (Rachel)
抄送: Hitoshi Asaeda; [email-masked]; [email-masked]
主题: Re: [xrblock] Comments on draft-ietf-xrblock-rtcp-xr-synchronization-00

Rachel,

Your first proposal fixes one of the two problems in that paragraph. We still need to improve the definition of the reference point. Adding the RFC 6051 section number would help but I don't think that is defined well enough there to allow an accurate measurement. Also, as Colin pointed out, there needs to be a discussion of how to make the measurement when multiple streams are involved.

The second proposal is looking good until we get to the new last sentence. For maximum accuracy, we'd like to use the NTP timestamps directly if they're available. If they're not available, we have to suggest something else and there's bit more to it than what you've proposed in your last sentence. If you need a specific suggestion, let me know and I'll have a think.

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com<http://www.avanw.com/>, www.X192.org<http://www.X192.org>

On Tue, Oct 30, 2012 at 9:26 PM, Huangyihong (Rachel) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Kevin,

Best Regards!
Rachel

From: Kevin Gross [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, October 31, 2012 2:49 AM
To: Hitoshi Asaeda
Cc: Huangyihong (Rachel); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

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

The accuracy requirement we've discussed for presentation times is 10 microseconds or better. I apologize that I have not yet drafted an I-D I promised summarizing these requirements. Required range is on the order of several seconds, maybe up to a minute. We need most of the bits to the right of the decimal in the NTP timestamp but we don't need many to the left. The reason we included all 64 is because the 64-bit NTP timestamp is the smallest standard timestamp format that gives us the resolution required. A non-standard format as small as 40 bits would suffice but RTCP is not a particularly bandwidth constrained protocol and the standard format and 32-bit word alignment as proposed in the draft should simplify implementation.

[Rachel]: Thanks for the clarifications.

It looks like I've overlooked issues with Synchronization Delay and Synchronization Offset in my previous review.

The Synchronization Delay definition needs to provide a more specific description of what's being referred to in RFC 6051 for defining the reference point for this measurement. Specifically the draft needs to define "beginning of session". I don't find such a concept in RFC 6051. RFC 6051 section 2.1.1 defines when sessions are joined but probably not in enough detail to know how to do a measurement referenced to this point.

The text in 4.2 of the delay draft, "from the RTCP packets received on all of the components RTP sessions to the beginning of session" might lead some implementers to compute a negative Synchronization Delay. Revers the from and to clauses in the text or add a formula to clarify.

[Rachel]: Good point. How about the following changes?
OLD TEXT:
“             The average delay, expressed in units of 1/65536 seconds, from the
      RTCP packets received on all of the components RTP sessions to the
      beginning of session [RFC6051].
“
NEW TEXT:
“             The average delay, expressed in units of 1/65536 seconds, from the
      time when sessions are joined [RFC6051] to the
      RTCP packets received on all of the components RTP sessions.
“

There seems to be a dimensional problem in the Synchronization Offset definition. Everything in the definition is in units of RTP clock but since we're using an NTP timestamp for the report, I assume this is supposed to define a quantity in units of NTP time.

[Rachel] Okay. I would propose following changes.
OLD TEXT:
“
      That is to say,if Si is the RTP timestamp from the
      reporting RTP packet i, and Ri is the time of arrival in RTP
      timestamp units for reporting RTP packet i, Sj is the RTP
      timestamp from the reference RTP packet j, and Rj is the time of
      arrival in RTP timestamp units for reference RTP packet j, then
      the value of the synchronization offset D may be expressed as
         D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si)
“

NEW TEXT:
“
        That is to say, if Si is the NTP timestamp from the
      reporting RTP packet i, and Ri is the time of arrival in
      NTP timestamp units for reporting RTP packet i, Sj is the NTP
      timestamp from the reference RTP packet j, and Rj is the time of
      arrival in NTP timestamp units for reference RTP packet j, then
      the value of the synchronization offset D may be expressed as
         D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si)
              Where Si, Ri, Sj and Rj are calculated from their corresponding
     RTP timestamps.
“

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Mon, 5 Nov 2012 00:16:44 +0000

Hi Kevin,

发送时间: 2012年11月5日 2:18

Oh, and we shouldn't forget that we need to address the issue of how to represent the sign of the offset.

[Rachel]: Yes. I think Colin’s proposal, a signed 64-bit NTP timestamps format, makes sense. Since we don’t need many of the bits to the left of the decimal in the NTP timestamp even considering accuracy requirement.  Right?

Kevin Gross
+1-303-447-0517
Media Network Consultant

On Sat, Nov 3, 2012 at 9:06 AM, Kevin Gross <[email-masked]<mailto:[email-masked]>> wrote:
Rachel,

Kevin Gross
+1-303-447-0517<tel:%2B1-303-447-0517>
Media Network Consultant
AVA Networks - www.AVAnw.com<http://www.avanw.com/>, www.X192.org<http://www.X192.org>

Best Regards!
Rachel

NEW TEXT:
“

---

From: Qin Wu <[email-masked]>
Date: Tue, 6 Nov 2012 05:01:37 +0000

Hi,
For a group of session, maybe we can pick the session with longest report interval as the reference session and choose the joining time by the participant for that reference session as starting point for measurement.

Regards!
-Qin
发件人: [email-masked] [mailto:[email-masked]] 代表 Colin Perkins
发送时间: 2012年10月31日 19:07
收件人: Kevin Gross
抄送: [email-masked]
主题: Re: [xrblock] Comments on draft-ietf-xrblock-rtcp-xr-synchronization-00

On 30 Oct 2012, at 18:49, Kevin Gross wrote:
The accuracy requirement we've discussed for presentation times is 10 microseconds or better. I apologize that I have not yet drafted an I-D I promised summarizing these requirements. Required range is on the order of several seconds, maybe up to a minute. We need most of the bits to the right of the decimal in the NTP timestamp but we don't need many to the left. The reason we included all 64 is because the 64-bit NTP timestamp is the smallest standard timestamp format that gives us the resolution required. A non-standard format as small as 40 bits would suffice but RTCP is not a particularly bandwidth constrained protocol and the standard format and 32-bit word alignment as proposed in the draft should simplify implementation.

The definition in RFC 6051 Section 2.1.1 gives a join time for a single session for a sender, but this draft could define a similar metric for a receiver. In any case, that gives the join time for a single RTP session, but the initial synchronisation delay metric is likely for a group of RTP sessions, and so needs to be defined with reference to some specific RTP session.

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com<http://www.avanw.com/>, www.X192.org<http://www.X192.org/>

On Mon, Oct 29, 2012 at 10:38 PM, Hitoshi Asaeda <[email-masked]<mailto:[email-masked]>> wrote:
Hi Colin and Rachel,

>>>> Hi folks,
>>>>
>>>> I have 2 comments for draft-ietf-xrblock-rtcp-xr-synchronization:
>>>>
>>>> 1.       In RTP flows synchronization offset metric block, only one SSRC set to the SSRC of the reference RTP stream has been specified. IMO,  the SSRC of the reporting stream should be also required.
>>>> 2.       Synchronization offset is a 64-bit unsigned fixed-point number. No indication shows which stream, the reporting stream or the reference stream,  is lag behind. So I propose to split one bit from "Reserved" field to indicate the offset direction.
>>>
>>> It would probably be easier to implement if you made the Synchronisation Offset a signed 64 bit value, rather than an unsigned 64 bit value and a separate sign bit.
>>>
>> [Rachel]: The reason I proposed that is because the synchronization offset is represented using the timestamp format of NTP (a 64-bit unsigned fixed-point number), which I think it's better to keep it unchanged.  Are you suggesting to use a nonstandard format instead of the standard NTP format? But you're right that it may be easier for implementations to use a signed value to tell fast or slow from 2 streams.
>
>
> Thinking about this more, I'm confused why you need a 64 bit NTP format timestamp here. With the addition of a sign bit, this choice allows you to represent synchronisation offsets up to 136 years in either direction with picosecond accuracy. That range seems unnecessary. What is the actual requirement?
>
> [Rachel]: The reason of using 64 bit NTP format timestamp is for accuracy, which has been discussed in the list before ( http://www.ietf.org/mail-archive/web/xrblock/current/msg00504.html ). But I agree with you that an additional sign bit is unnecessary. Your proposal makes sense here.
Well, the reason we use a 64 bit NTP format timestamp is just its
simplicity. While we don't need such long format, it'd be easier to
reuse it for the implementation, I thought.
But I also don't have no objection to make it signed.

Regards,
--
Hitoshi Asaeda
_______________________________________________
xrblock mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/xrblock

--
Colin Perkins
http://csperkins.org/

---

From: Kevin Gross <[email-masked]>
Date: Tue, 6 Nov 2012 13:34:30 -0500

Sounds promising. Can you suggest some revisions for the draft?

Kevin Gross
+1-303-447-0517
Media Network Consultant

On Tue, Nov 6, 2012 at 12:01 AM, Qin Wu <[email-masked]> wrote:

>  Hi,****
>
> For a group of session, maybe we can pick the session with longest report
> interval as the reference session and choose the joining time by the
> participant for that reference session as starting point for measurement.*
> ***
>
> ** **
>
> Regards!****
>
> -Qin****
>
> *发件人:* [email-masked] [mailto:[email-masked]] *代表 *Colin
> Perkins
> *发送时间:* 2012年10月31日 19:07
> *收件人:* Kevin Gross
> *抄送:* [email-masked]
> *主题:* Re: [xrblock] Comments on
> On 30 Oct 2012, at 18:49, Kevin Gross wrote:****
>
> The definition in RFC 6051 Section 2.1.1 gives a join time for a single
> session for a sender, but this draft could define a similar metric for a
> receiver. In any case, that gives the join time for a single RTP session,
> but the initial synchronisation delay metric is likely for a group of RTP
> sessions, and so needs to be defined with reference to some specific RTP
> session.****
>
>
>
> ****
>
> Kevin Gross****
> +1-303-447-0517****
> Media Network Consultant****
>
> AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org****
>
>
>
> ****
>
> On Mon, Oct 29, 2012 at 10:38 PM, Hitoshi Asaeda <[email-masked]>
> wrote:****
>
> Hi Colin and Rachel,****
>
>
> >>>> Hi folks,
> >>>>
> >>>> 1.       In RTP flows synchronization offset metric block, only one
> SSRC set to the SSRC of the reference RTP stream has been specified. IMO,
>  the SSRC of the reporting stream should be also required.
> >>>> 2.       Synchronization offset is a 64-bit unsigned fixed-point
> number. No indication shows which stream, the reporting stream or the
> reference stream,  is lag behind. So I propose to split one bit from
> "Reserved" field to indicate the offset direction.
> >>>
> >>> It would probably be easier to implement if you made the
> Synchronisation Offset a signed 64 bit value, rather than an unsigned 64
> bit value and a separate sign bit.
> >>>
> >> [Rachel]: The reason I proposed that is because the synchronization
> offset is represented using the timestamp format of NTP (a 64-bit unsigned
> fixed-point number), which I think it's better to keep it unchanged.  Are
> you suggesting to use a nonstandard format instead of the standard NTP
> format? But you're right that it may be easier for implementations to use a
> signed value to tell fast or slow from 2 streams.
> >
> >
> > Thinking about this more, I'm confused why you need a 64 bit NTP format
> timestamp here. With the addition of a sign bit, this choice allows you to
> represent synchronisation offsets up to 136 years in either direction with
> picosecond accuracy. That range seems unnecessary. What is the actual
> requirement?
> >
> > [Rachel]: The reason of using 64 bit NTP format timestamp is for
> accuracy, which has been discussed in the list before (
> http://www.ietf.org/mail-archive/web/xrblock/current/msg00504.html ). But
> I agree with you that an additional sign bit is unnecessary. Your proposal
> makes sense here.****
>
> Hitoshi Asaeda****
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xrblock****
>
> ** **
>
> ** **
>
> ** **
>
> -- ****
>
> Colin Perkins****
>
> http://csperkins.org/****
>
> ** **
>
> ** **
>
> ** **
>

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Tue, 6 Nov 2012 19:02:08 +0000

But how could we know which session will have the longest report interval before all the RTP sessions have established?

发件人: [email-masked] [mailto:[email-masked]] 代表 Kevin Gross
发送时间: 2012年11月7日 2:35
收件人: Qin Wu
抄送: Colin Perkins; [email-masked]
主题: Re: [xrblock] 答复: Comments on draft-ietf-xrblock-rtcp-xr-synchronization-00

Kevin Gross
+1-303-447-0517
Media Network Consultant

On Tue, Nov 6, 2012 at 12:01 AM, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:
Hi,
For a group of session, maybe we can pick the session with longest report interval as the reference session and choose the joining time by the participant for that reference session as starting point for measurement.

Regards!
-Qin
发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] 代表 Colin Perkins
发送时间: 2012年10月31日 19:07
收件人: Kevin Gross
抄送: [email-masked]<mailto:[email-masked]>
主题: Re: [xrblock] Comments on draft-ietf-xrblock-rtcp-xr-synchronization-00

Kevin Gross

Regards,

--
Colin Perkins
http://csperkins.org/

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Tue, 6 Nov 2012 20:28:37 +0000

I think maybe another proposal is that we could just choose the time when the first/ last RTP session is joined as the beginning of the multimedia session.

Kevin Gross
+1-303-447-0517
Media Network Consultant

Regards!
-Qin

Kevin Gross

Regards,

--
Colin Perkins
http://csperkins.org/