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.

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.

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.

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 <asaeda@sfc.wide.ad.jp>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
> xrblock@ietf.org
> https://www.ietf.org/mailman/listinfo/xrblock
>