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

Hitoshi Asaeda <> Tue, 30 October 2012 04:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 35B0321F84E1 for <>; Mon, 29 Oct 2012 21:38:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -99.096
X-Spam-Status: No, score=-99.096 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KMRQHVS12baI for <>; Mon, 29 Oct 2012 21:38:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3B9F121F84CF for <>; Mon, 29 Oct 2012 21:38:11 -0700 (PDT)
Received: from localhost (unknown []) by (Postfix) with ESMTPSA id EC90E2780AA; Tue, 30 Oct 2012 13:38:02 +0900 (JST)
Date: Tue, 30 Oct 2012 13:38:04 +0900
Message-Id: <>
From: Hitoshi Asaeda <>
In-Reply-To: <>
References: <> <> <>
X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: Re: [xrblock] Comments on draft-ietf-xrblock-rtcp-xr-synchronization-00
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Metric Blocks for use with RTCP's Extended Report Framework working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Oct 2012 04:38:12 -0000

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 ( ). 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.

Hitoshi Asaeda