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

"Huangyihong (Rachel)" <rachel.huang@huawei.com> Wed, 31 October 2012 03:28 UTC

Return-Path: <rachel.huang@huawei.com>
X-Original-To: xrblock@ietfa.amsl.com
Delivered-To: xrblock@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7421721F84EE for <xrblock@ietfa.amsl.com>; Tue, 30 Oct 2012 20:28:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNp0Wj8W7IEg for <xrblock@ietfa.amsl.com>; Tue, 30 Oct 2012 20:28:07 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 326A221F8421 for <xrblock@ietf.org>; Tue, 30 Oct 2012 20:28:06 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMF12174; Wed, 31 Oct 2012 03:28:04 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 31 Oct 2012 03:27:37 +0000
Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 31 Oct 2012 03:28:03 +0000
Received: from SZXEML539-MBX.china.huawei.com ([169.254.6.26]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.003; Wed, 31 Oct 2012 11:26:53 +0800
From: "Huangyihong (Rachel)" <rachel.huang@huawei.com>
To: Kevin Gross <kevin.gross@avanw.com>, Hitoshi Asaeda <asaeda@sfc.wide.ad.jp>
Thread-Topic: [xrblock] Comments on draft-ietf-xrblock-rtcp-xr-synchronization-00
Thread-Index: AQHNteJDO3kH4ui2j0OADO6r5WRb8ZfRE3TA//+rXgCAAO3hAIAA/Z1w
Date: Wed, 31 Oct 2012 03:26:51 +0000
Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB443AD0E7@szxeml539-mbx.china.huawei.com>
References: <51E6A56BD6A85142B9D172C87FC3ABBB443AB6A8@szxeml539-mbx.china.huawei.com> <12D5C620-EEE0-4FBC-B77C-165748978B97@csperkins.org> <51E6A56BD6A85142B9D172C87FC3ABBB443ACC48@szxeml539-mbx.china.huawei.com> <20121030.133804.10211661.asaeda@sfc.wide.ad.jp> <CALw1_Q3YkvxYCqNwuoL8se=a01j0x9tr2JLAagVDj=z1vxPkhA@mail.gmail.com>
In-Reply-To: <CALw1_Q3YkvxYCqNwuoL8se=a01j0x9tr2JLAagVDj=z1vxPkhA@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.41.163]
Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB443AD0E7szxeml539mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "csp@csperkins.org" <csp@csperkins.org>, "xrblock@ietf.org" <xrblock@ietf.org>
Subject: Re: [xrblock] Comments on draft-ietf-xrblock-rtcp-xr-synchronization-00
X-BeenThere: xrblock@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Metric Blocks for use with RTCP's Extended Report Framework working group discussion list <xrblock.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xrblock>, <mailto:xrblock-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xrblock>
List-Post: <mailto:xrblock@ietf.org>
List-Help: <mailto:xrblock-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xrblock>, <mailto:xrblock-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Oct 2012 03:28:10 -0000

Hi Kevin,

Best Regards!
Rachel

From: Kevin Gross [mailto:kevin.gross@avanw.com]
Sent: Wednesday, October 31, 2012 2:49 AM
To: Hitoshi Asaeda
Cc: Huangyihong (Rachel); csp@csperkins.org; xrblock@ietf.org
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 their corresponding
     RTP timestamps.
"