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

Kevin Gross <kevin.gross@avanw.com> Tue, 06 November 2012 18:35 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 BA9D921F8A6C for <xrblock@ietfa.amsl.com>; Tue, 6 Nov 2012 10:35:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.072
X-Spam-Level: **
X-Spam-Status: No, score=2.072 tagged_above=-999 required=5 tests=[AWL=-3.581, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345]
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 UDDJRlKyFESG for <xrblock@ietfa.amsl.com>; Tue, 6 Nov 2012 10:34:59 -0800 (PST)
Received: from oproxy8-pub.bluehost.com (oproxy8-pub.bluehost.com [69.89.22.20]) by ietfa.amsl.com (Postfix) with SMTP id 5E4D721F88FE for <xrblock@ietf.org>; Tue, 6 Nov 2012 10:34:59 -0800 (PST)
Received: (qmail 20416 invoked by uid 0); 6 Nov 2012 18:34:32 -0000
Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy8.bluehost.com with SMTP; 6 Nov 2012 18:34:32 -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=BeSUxE4pi1OXm910uMDGQ6tvDnop5VA7q/Ytkg2IteY=; b=gK1gA5TySg+wvFleEC0OBNlVQ/+gKtJ5k8i0N3h1ixtSVephCEEkXBYlbO7sVkQVNluRk0iV4xHZLyXTpOZhPKxf744aCNOO1B0RGfN04NzyhAaIHD8Xi2/Za2O9D4Vt;
Received: from [209.85.215.172] (port=33491 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 1TVnyq-000342-17 for xrblock@ietf.org; Tue, 06 Nov 2012 11:34:32 -0700
Received: by mail-ea0-f172.google.com with SMTP id k13so346508eaa.31 for <xrblock@ietf.org>; Tue, 06 Nov 2012 10:34:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.14.174.194 with SMTP id x42mr6225951eel.22.1352226870619; Tue, 06 Nov 2012 10:34:30 -0800 (PST)
Received: by 10.223.152.201 with HTTP; Tue, 6 Nov 2012 10:34:30 -0800 (PST)
In-Reply-To: <B8F9A780D330094D99AF023C5877DABA43048570@szxeml523-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> <6E0EAB29-CDC1-4AF8-BC3B-862400703B77@csperkins.org> <B8F9A780D330094D99AF023C5877DABA43048570@szxeml523-mbx.china.huawei.com>
Date: Tue, 6 Nov 2012 13:34:30 -0500
Message-ID: <CALw1_Q2_khDbqGME1mw571vk0TibLfVjjmNMkL=sudr5btTpUw@mail.gmail.com>
From: Kevin Gross <kevin.gross@avanw.com>
To: Qin Wu <bill.wu@huawei.com>
Content-Type: multipart/alternative; boundary=047d7b621ede47704604cdd7dae7
X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.215.172 authed with kevin.gross@avanw.com}
Cc: Colin Perkins <csp@csperkins.org>, "xrblock@ietf.org" <xrblock@ietf.org>
Subject: Re: [xrblock] =?gb2312?b?tPC4tDogIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYteHJi?= =?gb2312?b?bG9jay1ydGNwLXhyLXN5bmNocm9uaXphdGlvbi0wMA==?=
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: Tue, 06 Nov 2012 18:35:00 -0000

Sounds promising. Can you suggest some revisions for the draft?

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



On Tue, Nov 6, 2012 at 12:01 AM, Qin Wu <bill.wu@huawei.com> wrote:

>  Hi,****
>
> For a group of session, maybe we can pick the session with longest report
> interval as the reference session and choose the joining time by the
> participant for that reference session as starting point for measurement.*
> ***
>
> ** **
>
> Regards!****
>
> -Qin****
>
> *发件人:* xrblock-bounces@ietf.org [mailto:xrblock-bounces@ietf.org] *代表 *Colin
> Perkins
> *发送时间:* 2012年10月31日 19:07
> *收件人:* Kevin Gross
> *抄送:* xrblock@ietf.org
> *主题:* Re: [xrblock] Comments on
> draft-ietf-xrblock-rtcp-xr-synchronization-00****
>
> ** **
>
> On 30 Oct 2012, at 18:49, Kevin Gross wrote:****
>
> 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 definition in RFC 6051 Section 2.1.1 gives a join time for a single
> session for a sender, but this draft could define a similar metric for a
> receiver. In any case, that gives the join time for a single RTP session,
> but the initial synchronisation delay metric is likely for a group of RTP
> sessions, and so needs to be defined with reference to some specific RTP
> session.****
>
>
>
> ****
>
> 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****
>
> ** **
>
> ** **
>
> ** **
>
> -- ****
>
> Colin Perkins****
>
> http://csperkins.org/****
>
> ** **
>
> ** **
>
> ** **
>