IETF Logo Mail Archive

Re: [ippm] I-D Action:draft-ietf-ippm-metrictest-00.txt

Al Morton <acmorton@att.com> Tue, 06 July 2010 12:34 UTC

Return-Path: <acmorton@att.com>
X-Original-To: ippm@core3.amsl.com
Delivered-To: ippm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCFEC3A68D7 for <ippm@core3.amsl.com>; Tue, 6 Jul 2010 05:34:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.796
X-Spam-Level:
X-Spam-Status: No, score=-105.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTO6xKZqnAJ7 for <ippm@core3.amsl.com>; Tue, 6 Jul 2010 05:34:11 -0700 (PDT)
Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 1F0963A6887 for <ippm@ietf.org>; Tue, 6 Jul 2010 05:34:11 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: acmorton@att.com
X-Msg-Ref: server-10.tower-161.messagelabs.com!1278419652!29300014!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [144.160.20.146]
Received: (qmail 32144 invoked from network); 6 Jul 2010 12:34:12 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-10.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Jul 2010 12:34:12 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o66CXmsE007267 for <ippm@ietf.org>; Tue, 6 Jul 2010 08:33:48 -0400
Received: from klpd017.kcdc.att.com (klpd017.kcdc.att.com [135.188.40.86]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o66CXiqw007210 for <ippm@ietf.org>; Tue, 6 Jul 2010 08:33:44 -0400
Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id o66CY8rK017445 for <ippm@ietf.org>; Tue, 6 Jul 2010 07:34:08 -0500
Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id o66CY3ok017261 for <ippm@ietf.org>; Tue, 6 Jul 2010 07:34:03 -0500
Message-Id: <201007061234.o66CY3ok017261@klpd017.kcdc.att.com>
Received: from acmt.att.com (dn135-16-251-71.dhcpn.ugn.att.com[135.16.251.71](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100706123402gw100s4pe0e>; Tue, 6 Jul 2010 12:34:03 +0000
X-Originating-IP: [135.16.251.71]
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 06 Jul 2010 08:34:21 -0400
To: Jerome Benoit <jerome.benoit@grenouille.com>, ippm@ietf.org
From: Al Morton <acmorton@att.com>
In-Reply-To: <20100706141933.c765da1b.jerome.benoit@grenouille.com>
References: <20100705074502.DF8063A6967@core3.amsl.com> <20100706141933.c765da1b.jerome.benoit@grenouille.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Subject: Re: [ippm] I-D Action:draft-ietf-ippm-metrictest-00.txt
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ippm>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Jul 2010 12:34:12 -0000

Jerome,

Thanks for your comments, see below.

Al

At 08:19 AM 7/6/2010, Jerome Benoit wrote:

> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-ippm-metrictest-00.txt
>
>Do you plan do add inaccuracy introduced by runtime on each
>implementation ?

Sorry, but it's not clear to me where your comment applies.

Each of the metric RFCs cover error sources and error reporting,
so (if I understand your question) this is one of the areas to
check and see if implementing developers understood the requirements.

>Do you plan to you plan to test implementation that
>will not follow IETF OWAMP (or TWAMP) RFC but will largely inspired by
>them (NAT friendliness of theses RFC make them difficult to follow
>when you want to send probes from the network edge et behind a CPE) ?
Yes, this draft starts from the premise that measurement results from
different implementations will be compared. Neither OWAMP or TWAMP
are required.

v2.23.0 | Report a Bug | By Email