1/65536 units would work and would be better than 1 ms currently specified.
1/65536 units are used for initial synchronization delay and that does not
need to be changed. However, the 15 microseond accuracy of a 1/65536
timestamp is marginal for measuring presentation time for some audio
applications and could be insufficient for future applications in other
fields. State of the art network synchronization is <<1 microsecond. We
should match that capability where it matters. It matters here and so I've
suggested a full 64-bit timestamp.

I will write an I-D to clearly specify and justify these requirements.

Kevin Gross

On Wed, May 9, 2012 at 3:25 AM, Huangyihong (Rachel) <
rachel.huang@huawei.com> wrote:

>  Hi,****
>
> ** **
>
> ** **
>
> ** **
>
> Best Regards!****
>
> Rachel****
>
> ** **
>
> *From:* xrblock-bounces@ietf.org [mailto:xrblock-bounces@ietf.org] *On
> Behalf Of *Qin Wu
> *Sent:* Wednesday, May 09, 2012 4:36 PM
> *To:* Kevin Gross
> *Cc:* xrblock@ietf.org
> *Subject:* Re: [xrblock] draft-asaeda-xrblock-rtcp-xr-synchronization
> comments (was: Re: Polling the WG for interests in adding new milestones)*
> ***
>
> ** **
>
> Hi,****
>
>  ----- Original Message ----- ****
>
> *From:* Kevin Gross <kevin.gross@avanw.com> ****
>
> *To:* Qin Wu <bill.wu@huawei.com> ****
>
> *Cc:* xrblock@ietf.org ** **
>
> *Sent:* Wednesday, May 09, 2012 1:17 AM****
>
> *Subject:* [xrblock] draft-asaeda-xrblock-rtcp-xr-synchronization
> comments (was: Re: Polling the WG for interests in adding new milestones)*
> ***
>
> ** **
>
> My comments on the draft: ****
>
> ** **
>
> Section 2: Add definition of "Initial synchronization Delay". Term is used
> in Section 1.****
>
>  [Qin]: Okay, but the "Initial synchronization Delay" appeared firstly in
> the RFC6051,maybe we can just simply refer to it.****
>
>  Section 2: Add definition of "General Synchronization Offset" which
> appears in sections 1 and 3. Is this the same as "synchronization offset"?
> ****
>
>  [Qin]: Yes.****
>
>  Section 3: Copyedit to fix grammar problems.****
>
>  [Qin]: Okay.****
>
>  ** **
>
> Section 3, 3rd paragraph: ..."there can be an arbitrary number of streams
> carried in different RTP streams..." do you mean arbitrary number of
> streams in RTP_sessions_?****
>
>  [Qin]: Yes.****
>
>  Section 4.2: Clarify "the arbitrary RTP stream". Do you mean "an
> arbitrary RTP stream"?****
>
>  [Qin]: Yes.****
>
>  Section 5.2: Milliseconds are not sufficient synchronization resolution
> for some multimedia applications. see -
> https://docs.google.com/document/d/1ANYd-MkQUtJi5_B8uwOwfazB0p1Qmr6X6r85dsmUTgo/edit.
> I suggest using a standard 64-bit NTP timestamp for this report as has been
> done in draft-ietf-xrblock-rtcp-xr-delay and draft-ietf-avtcore-idms.****
>
>  [Qin]: I need to go to look at the reference you provided first and get
> back to you.****
>
> ** **
>
> [Rachel]: Why not using 1/65535 second? 32-bit is enough for 1/65535
> second accuracy.****
>
>  ****
>
>  With regards to the comments below, the following points have been
> previously discussed regarding timestamp representations:****
>
>    1. It is desirable to use standard timestamp formats. NTP defines
>    timestamps of varying precision and range (RFC 5905 section 6). Some RTCP
>    applications use timestamps in 1/65536 second or millisecond units. ***
>    *
>    2. User-facing presentation time needs to be measured with greater
>    than 1/65536 second (15 microsecond) accuracy ****
>    3. Network delivery delays (in the presence of bufferbloat, for
>    instance) can reach several seconds ****
>    4. Payload (decode, encode and FEC) processing can take 10s of seconds
>    ****
>    5. Bandwidth efficiency is not a strong design driver for RTCP****
>
>  If it would be helpful, I could collect these points and the above use
> cases into an informative internet draft.****
>
>  [Qin]: Looks a good idea to me.:-)****
>
>  Kevin****
>
> ** **
>
> On Sun, Mar 18, 2012 at 9:09 PM, Qin Wu <bill.wu@huawei.com> wrote:****
>
> Hi, Roland:
> The fair question is what is the acceptable synchronization offset is for
> any streaming service?
>
> I tend to agree with you 16bit is more than enough for synchronization
> offset between
> two streams sent in two separated RTP streams since 16 bit field in the
> order of  millisecond
> can support Maximum synchronization delay 65.536 secs.
>
>
> Taken audio-video synchronization requirements described in BBF TR-126 as
> a example,audio stream and video stream
> belong to the same session, the acceptable synchronization offset is
> multiple tens of milliseconds,
> far less than 65.536 secs.
>
> However if we change 32bit into 16bit, we may face padding issue. For
> example, given the odd number of General sycnrhonization
> offset in 16bit carried in the same report blocks, we may need to add one
> additonal 16bit paading at the end of report block since
> following the constraint for report block defined in RFC3611, each report
> block should be multiple 32 bit words long.
>
> Also I like to point out "mod 65536 (2^16)" has nothing to do with 32 bit
> synchronization offset field but used to limit the maximimu number
> of multiple synchronization offset reporting.
>
> Regards!
> -Qin****
>
> ----- Original Message -----
> From: <Roland.Schott@telekom.de>
> To: <ron.even.tlv@gmail.com>; <xrblock@ietf.org>
> Sent: Friday, March 16, 2012 7:03 PM
> Subject: Re: [xrblock] Polling the WG for interests in adding new
> milestones
>
>
>
> Hi all,
>
> my feedback to draft-asaeda-xrblock-rtcp-xr-synchronization:
>
> Section 5.2. "Packet i Generalization offset":
> here are 32 bits used, 16 bits seem to be sufficient, because value is a
> result of a modulo operation "mod 65536".
> Possibility is to reduce field to 16 bits and use free bits as a reserved
> field.
>
>
> Possiblity:
> old:
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      | General Synchronization Offset of packet begin_seq+1 mod 65536|
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> new:
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |GSO pack. begin_seq+1 mod 65536|              rsvd             |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
> Regards
>
> Roland
>
>
> -----Ursprüngliche Nachricht-----
> Von: xrblock-bounces@ietf.org [mailto:xrblock-bounces@ietf.org] Im
> Auftrag von Roni Even
> Gesendet: Mittwoch, 14. März 2012 15:55
> An: 'Romascanu, Dan (Dan)'; 'Shida Schubert'; 'xrblock'
> Betreff: Re: [xrblock] Polling the WG for interests in adding new
> milestones
>
> Same here,
> Roni Even
>
> > -----Original Message-----
> > From: xrblock-bounces@ietf.org [mailto:xrblock-bounces@ietf.org] On
> > Behalf Of Romascanu, Dan (Dan)
> > Sent: Wednesday, March 14, 2012 2:49 PM
> > To: Shida Schubert; xrblock
> > Subject: Re: [xrblock] Polling the WG for interests in adding new
> > milestones
> >
> > Interested and willing to review on both I-Ds.
> >
> > Dan
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: xrblock-bounces@ietf.org [mailto:xrblock-bounces@ietf.org] On
> > > Behalf Of Shida Schubert
> > > Sent: Wednesday, March 14, 2012 1:06 PM
> > > To: xrblock
> > > Subject: [xrblock] Polling the WG for interests in adding new
> > > milestones
> > >
> > >
> > > All;
> > >
> > >  Below are drafts that have been discussed and received some
> > supports.
> > >
> > >  Charles and I would have to talk to AD about adding milestones for
> > > any new WG items but I want to poll the WG for interests before the
> > > meeting, so we can talk to AD face to face.
> > >
> > >  To make sure we get enough energy to complete the work we will be
> > > adopting, we as chairs want to hear who is willing to review and
> > > contribute not only interested.
> > >
> > >  So please indicate what you are willing to do for each of the drafts
> > > listed below next to the option listed.
> > >
> > >  draft-zorn-xrblock-rtcp-xr-al-stat
> > >
> > >  - Interested
> > >
> > >  - Interested and willing to review
> > >
> > >  - Interested and willing to review and contribute
> > >
> > > ***************************
> > >
> > >  draft-asaeda-xrblock-rtcp-xr-synchronization
> > >
> > >  - Interested
> > >
> > >  - Interested and willing to review
> > >
> > >  - Interested and willing to review and contribute
> > >
> > > Many Thanks & Regards
> > >   Shida
> > > _______________________________________________
> > > xrblock mailing list
> > > xrblock@ietf.org
> > > https://www.ietf.org/mailman/listinfo/xrblock
> > _______________________________________________
> > xrblock mailing list
> > xrblock@ietf.org
> > https://www.ietf.org/mailman/listinfo/xrblock
>
> _______________________________________________
> xrblock mailing list
> xrblock@ietf.org
> https://www.ietf.org/mailman/listinfo/xrblock
> _______________________________________________
> xrblock mailing list
> xrblock@ietf.org
> https://www.ietf.org/mailman/listinfo/xrblock
> _______________________________________________
> xrblock mailing list
> xrblock@ietf.org
> https://www.ietf.org/mailman/listinfo/xrblock****
>
> ** **
>  ------------------------------
>
> _______________________________________________
> xrblock mailing list
> xrblock@ietf.org
> https://www.ietf.org/mailman/listinfo/xrblock****
>
>