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

Kevin Gross <kevin.gross@avanw.com> Sun, 04 November 2012 18:18 UTC

Return-Path: <kevin.gross@avanw.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 70EFA21F843A for <xrblock@ietfa.amsl.com>; Sun, 4 Nov 2012 10:18:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.042
X-Spam-Level:
X-Spam-Status: No, score=-1.042 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_32=0.6]
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 02QpRWngRD8n for <xrblock@ietfa.amsl.com>; Sun, 4 Nov 2012 10:18:08 -0800 (PST)
Received: from oproxy8-pub.bluehost.com (oproxy8-pub.bluehost.com [69.89.22.20]) by ietfa.amsl.com (Postfix) with SMTP id 2EF0921F879C for <xrblock@ietf.org>; Sun, 4 Nov 2012 10:18:08 -0800 (PST)
Received: (qmail 14027 invoked by uid 0); 4 Nov 2012 18:17:44 -0000
Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy8.bluehost.com with SMTP; 4 Nov 2012 18:17:44 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=/W54JJosSLknk/GP3WF8j4Pim66rWclxxaMbx4ei/cY=; b=IRHwmHcWnL6bstvJd26vJVrz6mUSE69sGddUMVNyJCxhxqEFoDOgx7azmsBMmrqCZW+ty+8s+X0rfGXJyQZmQuepxUTnoIsJeCMpaZN38WgyfygdvgLm+dr8itrx+VSn;
Received: from [209.85.215.172] (port=32940 helo=mail-ea0-f172.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from <kevin.gross@avanw.com>) id 1TV4lT-0001Gz-LV for xrblock@ietf.org; Sun, 04 Nov 2012 11:17:44 -0700
Received: by mail-ea0-f172.google.com with SMTP id k13so2271827eaa.31 for <xrblock@ietf.org>; Sun, 04 Nov 2012 10:17:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.14.200.134 with SMTP id z6mr28196660een.33.1352053062288; Sun, 04 Nov 2012 10:17:42 -0800 (PST)
Received: by 10.223.152.201 with HTTP; Sun, 4 Nov 2012 10:17:42 -0800 (PST)
In-Reply-To: <CALw1_Q0Ub5k8WRNQJRhuKYSRMEdcxP-D+=4HLfEiy-3HSwX7ww@mail.gmail.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> <51E6A56BD6A85142B9D172C87FC3ABBB443AD0E7@szxeml539-mbx.china.huawei.com> <CALw1_Q0Ub5k8WRNQJRhuKYSRMEdcxP-D+=4HLfEiy-3HSwX7ww@mail.gmail.com>
Date: Sun, 4 Nov 2012 11:17:42 -0700
Message-ID: <CALw1_Q2-eQ0htXed8Q2Vu553nXT7dQQ65QSfgur9L43WdQ3QzA@mail.gmail.com>
From: Kevin Gross <kevin.gross@avanw.com>
To: "Huangyihong (Rachel)" <rachel.huang@huawei.com>
Content-Type: multipart/alternative; boundary=047d7b343a727ec64a04cdaf628d
X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.215.172 authed with kevin.gross@avanw.com}
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: Sun, 04 Nov 2012 18:18:09 -0000

Oh, and we shouldn't forget that we need to address the issue of how to
represent the sign of the offset.

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org



On Sat, Nov 3, 2012 at 9:06 AM, Kevin Gross <kevin.gross@avanw.com> wrote:

> Rachel,
>
> Your first proposal fixes one of the two problems in that paragraph. We
> still need to improve the definition of the reference point. Adding the RFC
> 6051 section number would help but I don't think that is defined well
> enough there to allow an accurate measurement. Also, as Colin pointed out,
> there needs to be a discussion of how to make the measurement when multiple
> streams are involved.
>
> The second proposal is looking good until we get to the new last sentence.
> For maximum accuracy, we'd like to use the NTP timestamps directly if
> they're available. If they're not available, we have to suggest something
> else and there's bit more to it than what you've proposed in your last
> sentence. If you need a specific suggestion, let me know and I'll have a
> think.
>
> Kevin Gross
> +1-303-447-0517
> Media Network Consultant
> AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org
>
>
>
> On Tue, Oct 30, 2012 at 9:26 PM, Huangyihong (Rachel) <
> rachel.huang@huawei.com> wrote:
>
>>  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 theircorresponding
>> ****
>>
>>      RTP timestamps.****
>>
>> “****
>>
>> ** **
>>
>
>