Subject: [xrblock] draft-asaeda-xrblock-rtcp-xr-synchronization comments (was: Re: Polling the WG for interests in adding new milestones)

From: Kevin Gross <[email-masked]>
Date: Tue, 8 May 2012 11:17:57 -0600

My comments on the draft:

Section 2: Add definition of "Initial synchronization Delay". Term is used
in Section 1.

Section 2: Add definition of "General Synchronization Offset" which appears
in sections 1 and 3. Is this the same as "synchronization offset"?

Section 3: Copyedit to fix grammar problems.

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_?

Section 4.2: Clarify "the arbitrary RTP stream". Do you mean "an arbitrary
RTP stream"?

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.

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.

Kevin

On Sun, Mar 18, 2012 at 9:09 PM, Qin Wu <[email-masked]> 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: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> 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: [email-masked] [mailto:[email-masked]] 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: [email-masked] [mailto:[email-masked]] 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: [email-masked] [mailto:[email-masked]] 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
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/xrblock
> > _______________________________________________
> > xrblock mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/xrblock
>
> _______________________________________________
> xrblock mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xrblock
> _______________________________________________
> xrblock mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xrblock
> _______________________________________________
> xrblock mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xrblock
>

---

From: Qin Wu <[email-masked]>
Date: Wed, 9 May 2012 16:36:00 +0800

Hi,
  ----- Original Message ----- 
  From: Kevin Gross 
  To: Qin Wu 
  Cc: [email-masked] 
  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)

  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.

[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.

  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

    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: <[email-masked]>
    To: <[email-masked]>; <[email-masked]>
    Sent: Friday, March 16, 2012 7:03 PM
    Subject: Re: [xrblock] Polling the WG for interests in adding new milestones

    Hi all,

    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:

    new:

    Regards

    Roland

    -----Ursprüngliche Nachricht-----
    Von: [email-masked] [mailto:[email-masked]] 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

------------------------------------------------------------------------------

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Wed, 9 May 2012 09:25:45 +0000

Hi,

Best Regards!
Rachel

From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Wednesday, May 09, 2012 4:36 PM
To: Kevin Gross
Cc: [email-masked]
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<mailto:[email-masked]>
To: Qin Wu<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
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)

[Rachel]: Why not using 1/65535 second? 32-bit is enough for 1/65535 second accuracy.

  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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Roland:
The fair question is what is the acceptable synchronization offset is for any streaming service?

Regards!
-Qin
----- Original Message -----
From: <[email-masked]<mailto:[email-masked]>>
To: <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>
Sent: Friday, March 16, 2012 7:03 PM
Subject: Re: [xrblock] Polling the WG for interests in adding new milestones

Hi all,

Possiblity:
old:

new:

Regards

Roland

-----Ursprüngliche Nachricht-----
Von: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] 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

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
> > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
> > Behalf Of Shida Schubert
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

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

________________________________
_______________________________________________
xrblock mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/xrblock

---

From: Kevin Gross <[email-masked]>
Date: Wed, 9 May 2012 08:57:49 -0600

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) <
[email-masked]> wrote:

>  Hi,****
>
> ** **
>
> ** **
>
> ** **
>
> Best Regards!****
>
> Rachel****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Qin Wu
> *Sent:* Wednesday, May 09, 2012 4:36 PM
> *To:* Kevin Gross
> *Cc:* [email-masked]
> *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 <[email-masked]> ****
>
> *To:* Qin Wu <[email-masked]> ****
>
> *Cc:* [email-masked] ** **
>
> *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: ****
>
> ** **
>
> 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.****
>
>  ** **
>
> 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 -
> 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.****
>
>  ****
>
> previously discussed regarding timestamp representations:****
>
>    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 ****
>    instance) can reach several seconds ****
>    ****
>    5. Bandwidth efficiency is not a strong design driver for RTCP****
>
> 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 <[email-masked]> wrote:****
>
> Hi, Roland:
> -Qin****
> https://www.ietf.org/mailman/listinfo/xrblock****
>
> ** **
>  ------------------------------
>
> https://www.ietf.org/mailman/listinfo/xrblock****
>
>