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, 06 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] 答复: 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: 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/**** > > ** ** > > ** ** > > ** ** >
- [xrblock] Comments on draft-ietf-xrblock-rtcp-xr-… Claire Bi(jiayu)
- Re: [xrblock] Comments on draft-ietf-xrblock-rtcp… Qin Wu
- [xrblock] Comments on draft-ietf-xrblock-rtcp-xr-… Huangyihong (Rachel)
- [xrblock] Fw: Comments on draft-ietf-xrblock-rtcp… Qin Wu
- Re: [xrblock] Fw: Comments on draft-ietf-xrblock-… Huangyihong (Rachel)
- Re: [xrblock] Comments on draft-ietf-xrblock-rtcp… Colin Perkins
- Re: [xrblock] Comments on draft-ietf-xrblock-rtcp… Huangyihong (Rachel)
- Re: [xrblock] Comments on draft-ietf-xrblock-rtcp… Colin Perkins
- Re: [xrblock] Comments on draft-ietf-xrblock-rtcp… Huangyihong (Rachel)
- Re: [xrblock] Comments on draft-ietf-xrblock-rtcp… Hitoshi Asaeda
- Re: [xrblock] Comments on draft-ietf-xrblock-rtcp… Kevin Gross
- Re: [xrblock] Comments on draft-ietf-xrblock-rtcp… Huangyihong (Rachel)
- Re: [xrblock] Comments on draft-ietf-xrblock-rtcp… Colin Perkins
- Re: [xrblock] Comments on draft-ietf-xrblock-rtcp… Kevin Gross
- Re: [xrblock] Comments on draft-ietf-xrblock-rtcp… Kevin Gross
- Re: [xrblock] Comments on draft-ietf-xrblock-rtcp… Huangyihong (Rachel)
- Re: [xrblock] Comments on draft-ietf-xrblock-rtcp… Huangyihong (Rachel)
- [xrblock] 答复: Comments on draft-ietf-xrblock-rtcp… Qin Wu
- Re: [xrblock] 答复: Comments on draft-ietf-xrblock-… Kevin Gross
- [xrblock] 答复: 答复: Comments on draft-ietf-xrblock-… Huangyihong (Rachel)
- [xrblock] 答复: 答复: Comments on draft-ietf-xrblock-… Huangyihong (Rachel)