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

[Kevin Gross <[e-mail]>]

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

Kevin Gross
[phone]
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org



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

> 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
> [phone]
> 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) <
> [e-mail]> wrote:
>
>>  Hi Kevin,****
>>
>> ** **
>>
>> Best Regards!****
>>
>> Rachel****
>>
>> ** **
>>
>> *From:* Kevin Gross [mailto:[e-mail]]
>> *Sent:* Wednesday, October 31, 2012 2:49 AM
>> *To:* Hitoshi Asaeda
>> *Cc:* Huangyihong (Rachel); [e-mail]; [e-mail]
>>
>> *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.****
>>
>> “****
>>
>> ** **
>>
>
>