Re: [xrblock] IESG evaluation comments for draft-ietf-xrblock-rtcp-xr-meas-identity-07
Colin Perkins <csp@csperkins.org> Wed, 04 July 2012 20:57 UTC
Return-Path: <csp@csperkins.org>
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 58D7E21F860F for <xrblock@ietfa.amsl.com>; Wed, 4 Jul 2012 13:57:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.299
X-Spam-Level:
X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvitiGNMWY-X for <xrblock@ietfa.amsl.com>; Wed, 4 Jul 2012 13:57:43 -0700 (PDT)
Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by ietfa.amsl.com (Postfix) with ESMTP id A600221F8604 for <xrblock@ietf.org>; Wed, 4 Jul 2012 13:57:37 -0700 (PDT)
Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.11]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1SmWdw-0000Tx-a4; Wed, 04 Jul 2012 20:57:48 +0000
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: multipart/alternative; boundary="Apple-Mail=_2C0E14BB-FF39-4C40-A392-50F6DE2FB6C2"
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <EDC0A1AE77C57744B664A310A0B23AE240A1F99B@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
Date: Wed, 04 Jul 2012 21:57:46 +0100
Message-Id: <E0F06B27-7A37-43D4-AB31-4EFA5F587EE3@csperkins.org>
References: <92B7E61ADAC1BB4F941F943788C08828026EA0@xmb-aln-x08.cisco.com><79C3968C3AA34C17AD6B961221011102@china.huawei.com> <1341377261.26716.13.camel@gwz-laptop> <4DE251D9CDE64AB4A22D19C2C3D6A31E@china.huawei.com> <EDC0A1AE77C57744B664A310A0B23AE240A1F99B@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
To: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
X-Mailer: Apple Mail (2.1278)
Cc: "xrblock@ietf.org" <xrblock@ietf.org>
Subject: Re: [xrblock] IESG evaluation comments for draft-ietf-xrblock-rtcp-xr-meas-identity-07
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, 04 Jul 2012 20:57:44 -0000
Keith, I'd argue that using a familiar time format (32 or 64 bits NTP-format value as used in other bits of RTCP) is more important than saving 32 bits here. Colin On 4 Jul 2012, at 11:18, DRAGE, Keith (Keith) wrote: > One other option which I will just throw into the ring is that one could divide the existing 32 bits into 2 fields, one of which is a value and the other a multiplier. This has certainly been done in other protocols. > > Depends how much one feels the need to save bits. > > Keith > > From: xrblock-bounces@ietf.org [mailto:xrblock-bounces@ietf.org] On Behalf Of Qin Wu > Sent: 04 July 2012 06:55 > To: Glen Zorn; xrblock@ietf.org > Subject: Re: [xrblock] IESG evaluation comments for draft-ietf-xrblock-rtcp-xr-meas-identity-07 > > ----- Original Message ----- > From: Glen Zorn > To: xrblock@ietf.org > Sent: Wednesday, July 04, 2012 12:47 PM > Subject: Re: [xrblock] IESG evaluation comments for draft-ietf-xrblock-rtcp-xr-meas-identity-07 > > On Wed, 2012-07-04 at 10:19 +0800, Qin Wu wrote: > > ... > > > > > Second, the cumulative duration is defined in section 4.1 as follows: > > > > Measurement Duration (Cumulative) : 32 bits > > The duration, expressed in units of 1/65536 seconds, of the > > reporting interval applicable to Cumulative reports which use this > > Measurement Information block. The value of this field can be > > calculated by the receiver of the RTP media stream, for example, > > based on received RTP media packets or using RTCP method described > > in [RFC3550]. > > > > The units for the measurement was changed from millisecond to 1/65536 based on working group input. A side effect of this however, is that the maximum cumulative duration that can be expressed is 18.2 hours. This does not seem sufficient, as the cumulative duration may be up to the length of the RTP session.The proposal is to increase the field from 32 bits to 64 bits. > > [Qin]: Agree, we should not limit the cumulative duration to less than 18.2 hours. The proposal looks good to me. > Here is my input to fix this issue: > OLD TEXT: > " > Measurement Duration (Cumulative) : 32 bits > The duration, expressed in units of 1/65536 seconds, of the > reporting interval applicable to Cumulative reports which use this > Measurement Information block. The value of this field can be > calculated by the receiver of the RTP media stream, for example, > based on received RTP media packets or using RTCP method described > in [RFC3550]. > > " > NEW TEXT: > " > Measurement Duration (Cumulative) : 64 bits > The duration of the reporting interval applicable to Cumulative reports which use this > Measurement Information block. The value of this field is represented using a 64-bit > NTP-format timestamp as defined in [RFC5905], which is 64-bit unsigned fixed-point > number with the integer part in the first 32 bits and the fractional part in the last 32 bits. > It can be calculated by the receiver of the RTP media stream, for example, based on > received RTP media packets or using RTCP method described in [RFC3550]. > > " > > A fine idea, but the question in my mind is why we don't simply standardize on NTP format for all time values... > > > [Qin]: If my intepretation is correct, your question is why not apply NTP format to Measurement Duration (Interval) as well? > My understanding is: > the maximum measurement duration (Interval) 18.2 hours is more than enough,it is not necessary to get in line with 64 bit measurement duration (cumulative). > Another benefit for not applying NTP format to Measurement Duration (Interval) is to make good use of 32bit space allocated and reduce overhead waste. > ... > _______________________________________________ > xrblock mailing list > xrblock@ietf.org > https://www.ietf.org/mailman/listinfo/xrblock > _______________________________________________ > xrblock mailing list > xrblock@ietf.org > https://www.ietf.org/mailman/listinfo/xrblock -- Colin Perkins http://csperkins.org/
- [xrblock] IESG evaluation comments for draft-ietf… Charles Eckel (eckelcu)
- Re: [xrblock] IESG evaluation comments for draft-… Qin Wu
- Re: [xrblock] IESG evaluation comments for draft-… Glen Zorn
- Re: [xrblock] IESG evaluation comments for draft-… Qin Wu
- Re: [xrblock] IESG evaluation comments for draft-… DRAGE, Keith (Keith)
- Re: [xrblock] IESG evaluation comments for draft-… Colin Perkins
- Re: [xrblock] IESG evaluation comments for draft-… Qin Wu