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

[Kevin Gross <[e-mail]>]

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.****
>
> “****
>
> ** **
>