From henk@ripe.net Mon Oct 4 01:17:47 2010 Return-Path: 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 907493A6F49 for ; Mon, 4 Oct 2010 01:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.295 X-Spam-Level: X-Spam-Status: No, score=-101.295 tagged_above=-999 required=5 tests=[AWL=-1.296, BAYES_50=0.001, 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 qg-AELMVTbUY for ; Mon, 4 Oct 2010 01:17:45 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id 817C63A6F62 for ; Mon, 4 Oct 2010 01:17:45 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1P2gFm-0007K6-1f for ippm@ietf.org; Mon, 04 Oct 2010 10:18:39 +0200 Received: from [193.0.21.124] (helo=guest193.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1P2gFl-0003Pl-Nc for ippm@ietf.org; Mon, 04 Oct 2010 10:18:34 +0200 Message-ID: <4CA98DD9.1030004@ripe.net> Date: Mon, 04 Oct 2010 10:18:33 +0200 From: Henk Uijterwaal Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: "ippm >> IETF IPPM WG" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5bacc4a2abb21a1b70c6c2709b40ddef1 X-RIPE-Spam-Level: -- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5bacc4a2abb21a1b70c6c2709b40ddef1 Subject: [ippm] Meeting in Beijing X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 08:17:47 -0000 IPPM group, We will meet in Beijing at IETF79. If you have any topics to discuss, please send us a note, Matt & Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ I confirm today what I denied yesterday. Anonymous Politician. From acmorton@att.com Wed Oct 6 14:10:31 2010 Return-Path: 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 664513A6DA6 for ; Wed, 6 Oct 2010 14:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.506 X-Spam-Level: X-Spam-Status: No, score=-105.506 tagged_above=-999 required=5 tests=[AWL=0.290, 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 GV7OcCep4-94 for ; Wed, 6 Oct 2010 14:10:22 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id C0CB63A71DE for ; Wed, 6 Oct 2010 14:10:19 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-5.tower-120.messagelabs.com!1286399478!48318221!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 5854 invoked from network); 6 Oct 2010 21:11:18 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-5.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Oct 2010 21:11:18 -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 o96LAhe9015654 for ; Wed, 6 Oct 2010 17:10:43 -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 o96LAbBf015574 for ; Wed, 6 Oct 2010 17:10:37 -0400 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klpd017.kcdc.att.com (8.14.4/8.14.4) with ESMTP id o96LBBnH008376 for ; Wed, 6 Oct 2010 16:11:11 -0500 Received: from mailgw1.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by klpd017.kcdc.att.com (8.14.4/8.14.4) with ESMTP id o96LB99k008364 for ; Wed, 6 Oct 2010 16:11:09 -0500 Message-Id: <201010062111.o96LB99k008364@klpd017.kcdc.att.com> Received: from acmt.att.com (ds135-16-251-236.dhcps.ugn.att.com[135.16.251.236](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20101006211109gw100ei1lke>; Wed, 6 Oct 2010 21:11:09 +0000 X-Originating-IP: [135.16.251.236] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 06 Oct 2010 17:11:32 -0400 To: ippm@ietf.org From: Al Morton Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ippm] Fwd: I-D Action:draft-morton-ippm-rt-loss-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 21:10:31 -0000 IPPM, I presented this draft in Maastrict, and would like to get some more comments on this updated version. regards, Al >From: Internet-Drafts@ietf.org >To: i-d-announce@ietf.org >Subject: I-D Action:draft-morton-ippm-rt-loss-01.txt >Date: Wed, 6 Oct 2010 13:45:03 -0700 (PDT) >X-BeenThere: i-d-announce@ietf.org >Sender: i-d-announce-bounces@ietf.org > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : Round-trip Loss Metrics > Author(s) : A. Morton > Filename : draft-morton-ippm-rt-loss-01.txt > Pages : 11 > Date : 2010-10-06 > >Many user applications and the transport protocols that make them >possible require two-way communications. To address this need, and >also for system simplicity, round-trip loss measurements are >frequently conducted in practice. The Two-Way Active Measurement >Protocol specified in RFC 5357 establishes a round-trip loss >measurement capability for the Internet. However, there is currently >no metric specified according to the RFC 2330 framework. > >This memo proposes/adds round-trip loss to the set of IP Performance >Metrics (IPPM). > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-morton-ippm-rt-loss-01.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From Barry.Constantine@jdsu.com Thu Oct 7 06:23:28 2010 Return-Path: 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 5435D3A6F33 for ; Thu, 7 Oct 2010 06:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.921 X-Spam-Level: X-Spam-Status: No, score=-5.921 tagged_above=-999 required=5 tests=[AWL=0.678, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 BGnNb+OqvFwV for ; Thu, 7 Oct 2010 06:23:27 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with SMTP id 4A4483A6E5E for ; Thu, 7 Oct 2010 06:23:26 -0700 (PDT) Received: from source ([209.36.247.244]) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTK3KDCw9BMl9SRnORofIGk2am6wxOBwk@postini.com; Thu, 07 Oct 2010 06:24:30 PDT Received: from milexhtca2.ds.jdsu.net ([10.75.2.122]) by Outbound1.jdsu.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Oct 2010 06:23:38 -0700 Received: from MILEXCH1.ds.jdsu.net ([fe80::6444:f010:6d40:bdb]) by milexhtca2.ds.jdsu.net ([::1]) with mapi; Thu, 7 Oct 2010 06:23:37 -0700 From: Barry Constantine To: Al Morton , "ippm@ietf.org" Date: Thu, 7 Oct 2010 06:23:35 -0700 Thread-Topic: [ippm] Fwd: I-D Action:draft-morton-ippm-rt-loss-01.txt Thread-Index: ActlmxC9LX6ihHJQQ8ahbqA0jDWzeAAhmYqQ Message-ID: <94DEE80C63F7D34F9DC9FE69E39436BE38BA5B6E3F@MILEXCH1.ds.jdsu.net> References: <201010062111.o96LB99k008364@klpd017.kcdc.att.com> In-Reply-To: <201010062111.o96LB99k008364@klpd017.kcdc.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Oct 2010 13:23:38.0054 (UTC) FILETIME=[D9E16660:01CB6622] Subject: Re: [ippm] Fwd: I-D Action:draft-morton-ippm-rt-loss-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 13:23:28 -0000 Hi Al, I reviewed the document and have one comment / question. Should this draft discuss implications of packet re-ordering to round trip = loss metrics (in the context of RFC4737)? Thanks, Barry =20 Principal Member of Technical Staff =20 JDSU Communication Test (formerly Acterna) Emerging Markets and Technology Research =20 One Milestone Center Court =20 Germantown, MD 20876 =20 (W) 240-404-2227 =20 (C) 301-325-7069 -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Al = Morton Sent: Wednesday, October 06, 2010 5:12 PM To: ippm@ietf.org Subject: [ippm] Fwd: I-D Action:draft-morton-ippm-rt-loss-01.txt IPPM, I presented this draft in Maastrict, and would like to get some more comments on this updated version. regards, Al >From: Internet-Drafts@ietf.org >To: i-d-announce@ietf.org >Subject: I-D Action:draft-morton-ippm-rt-loss-01.txt >Date: Wed, 6 Oct 2010 13:45:03 -0700 (PDT) >X-BeenThere: i-d-announce@ietf.org >Sender: i-d-announce-bounces@ietf.org > >A New Internet-Draft is available from the on-line Internet-Drafts=20 >directories. > > Title : Round-trip Loss Metrics > Author(s) : A. Morton > Filename : draft-morton-ippm-rt-loss-01.txt > Pages : 11 > Date : 2010-10-06 > >Many user applications and the transport protocols that make them >possible require two-way communications. To address this need, and >also for system simplicity, round-trip loss measurements are >frequently conducted in practice. The Two-Way Active Measurement >Protocol specified in RFC 5357 establishes a round-trip loss >measurement capability for the Internet. However, there is currently >no metric specified according to the RFC 2330 framework. > >This memo proposes/adds round-trip loss to the set of IP Performance >Metrics (IPPM). > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-morton-ippm-rt-loss-01.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From acmorton@att.com Thu Oct 7 07:12:42 2010 Return-Path: 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 1CAC23A6F62 for ; Thu, 7 Oct 2010 07:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.516 X-Spam-Level: X-Spam-Status: No, score=-105.516 tagged_above=-999 required=5 tests=[AWL=0.280, 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 DR3AICsw3oaO for ; Thu, 7 Oct 2010 07:12:40 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id A3FE03A7116 for ; Thu, 7 Oct 2010 07:12:40 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-10.tower-120.messagelabs.com!1286460821!27383733!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 10425 invoked from network); 7 Oct 2010 14:13:42 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-10.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Oct 2010 14:13:42 -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 o97ED61t020561 for ; Thu, 7 Oct 2010 10:13:06 -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 o97ED3DK020503 for ; Thu, 7 Oct 2010 10:13:03 -0400 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klpd017.kcdc.att.com (8.14.4/8.14.4) with ESMTP id o97EDcWZ017710 for ; Thu, 7 Oct 2010 09:13:38 -0500 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by klpd017.kcdc.att.com (8.14.4/8.14.4) with ESMTP id o97EDabS017704 for ; Thu, 7 Oct 2010 09:13:36 -0500 Message-Id: <201010071413.o97EDabS017704@klpd017.kcdc.att.com> Received: from acmt.att.com (ds135-16-251-236.dhcps.ugn.att.com[135.16.251.236](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20101007141336gw100ei1mfe>; Thu, 7 Oct 2010 14:13:36 +0000 X-Originating-IP: [135.16.251.236] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 07 Oct 2010 10:14:00 -0400 To: Barry Constantine , "ippm@ietf.org" From: Al Morton In-Reply-To: <94DEE80C63F7D34F9DC9FE69E39436BE38BA5B6E3F@MILEXCH1.ds.jds u.net> References: <201010062111.o96LB99k008364@klpd017.kcdc.att.com> <94DEE80C63F7D34F9DC9FE69E39436BE38BA5B6E3F@MILEXCH1.ds.jdsu.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [ippm] Fwd: I-D Action:draft-morton-ippm-rt-loss-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 14:12:42 -0000 Hi Barry, At 09:23 AM 10/7/2010, Barry Constantine wrote: >I reviewed the document and have one comment / question. > >Should this draft discuss implications of packet re-ordering to >round trip loss metrics (in the context of RFC4737)? I think so, there are certainly implications to the return path sampling process if the reordering occurs in the forward direction, and the Src and Dst sequence numbers will not line-up, even if there is no loss concurrent with the reordering... Thanks for your review. I'll try to update this again before the meeting. If I've overlooked some implications, let me know... Would you support this as a chartered WG item? Al From acmorton@att.com Thu Oct 7 12:52:43 2010 Return-Path: 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 E02B63A6FA3 for ; Thu, 7 Oct 2010 12:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.782 X-Spam-Level: X-Spam-Status: No, score=-104.782 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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 tVR1Qp2AuYCy for ; Thu, 7 Oct 2010 12:52:42 -0700 (PDT) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 6DD2F3A6F7E for ; Thu, 7 Oct 2010 12:52:42 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-8.tower-146.messagelabs.com!1286481216!20554120!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 26945 invoked from network); 7 Oct 2010 19:53:37 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-8.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Oct 2010 19:53:37 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o97Jrr7T013212 for ; Thu, 7 Oct 2010 15:53:54 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o97JrjlC012907 for ; Thu, 7 Oct 2010 15:53:46 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id o97JrSO3031798 for ; Thu, 7 Oct 2010 15:53:28 -0400 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id o97JrOtX031691 for ; Thu, 7 Oct 2010 15:53:24 -0400 Message-Id: <201010071953.o97JrOtX031691@alpd052.aldc.att.com> Received: from acmt.att.com (ds135-16-251-236.dhcps.ugn.att.com[135.16.251.236](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20101007195323gw100ei1oie>; Thu, 7 Oct 2010 19:53:23 +0000 X-Originating-IP: [135.16.251.236] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 07 Oct 2010 15:53:46 -0400 To: Matthew J Zekauskas , ippm@ietf.org From: Al Morton Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Subject: [ippm] Reordering Def in draft-ietf-ippm-reporting-05 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 19:52:44 -0000 Matt,

You asked that I take a look at:

4.5.  Reordering


   Reordering is the fraction of unique packets received for
which the
   sequence number of any given packet is less than the highest
sequence
   number largest sequence number of any packet previously
received.
           ^^^^^^^^^^^^^^^^^^^^^^^
I think you identified this redundant text during the meeting, right?          

   For the
purposes of determining the sequence number of the preceding
   packets in this definition, assume sequence numbers starting
with 1,
   and an extra packet at the start of the stream of received
packets,
   with a sequence number of 0, is considered to be present
(this extra
   packet, of course, is not counted for the purposes of
computing the
   fraction).

I think your word definition is pretty close, but there should be an
explicit designation of a reordered packet, IMO.  Also, the "unique" aspect
is a fairly subtle way to exclude any duplicate packet from being reordered. 
We could explain this fairly easily.

I suggest:

4.5. Reordering

|  Reordering is the fraction of unique packets received for which the sequence
|  number of a packet designated "reordered" is less than the highest sequence
|  number of any packet previously received, and the "unique" aspect excludes
|  any Duplicate packets (as described in section 4.4 above).
   For the purposes of determining the sequence number of the preceding
   packets in this definition, assume sequence numbers starting with 1,
   and an extra packet at the start of the stream of received packets,
   with a sequence number of 0, is considered to be present (this extra
   packet, of course, is not counted for the purposes of computing the
   fraction).

hope this helps,
Al

From Anura.Jayasumana@Colostate.edu Thu Oct 7 13:25:35 2010 Return-Path: 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 99EC43A6FE1 for ; Thu, 7 Oct 2010 13:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 H0YwTVS7TlZC for ; Thu, 7 Oct 2010 13:25:33 -0700 (PDT) Received: from smith.ACNS.ColoState.EDU (smith.acns.colostate.edu [129.82.100.169]) by core3.amsl.com (Postfix) with ESMTP id 47CFF3A6E6A for ; Thu, 7 Oct 2010 13:25:33 -0700 (PDT) Received: from jansen.ColoState.EDU (jansen.acns.colostate.edu [129.82.100.132]) by smith.ACNS.ColoState.EDU (8.13.8/8.12.11) with ESMTP id o97KQXOw029167; Thu, 7 Oct 2010 14:26:34 -0600 Received: from mail1.engr.colostate.edu (mail1.engr.colostate.edu [129.82.224.31]) by jansen.ColoState.EDU (8.13.1/8.13.1) with ESMTP id o97KQXWd002386; Thu, 7 Oct 2010 14:26:33 -0600 Received: from [127.0.0.1] (c201d3.engr.colostate.edu [129.82.230.237]) by mail1.engr.colostate.edu (Postfix) with ESMTPS id AC6F1469; Thu, 7 Oct 2010 14:26:32 -0600 (MDT) Message-ID: <4CAE2CF9.2070109@Colostate.edu> Date: Thu, 07 Oct 2010 14:26:33 -0600 From: Anura Jayasumana User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: ippm@ietf.org References: <201010071953.o97JrOtX031691@alpd052.aldc.att.com> In-Reply-To: <201010071953.o97JrOtX031691@alpd052.aldc.att.com> Content-Type: multipart/alternative; boundary="------------000602010800060905010706" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-07_09:2010-10-07, 2010-10-07, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1010070124 Subject: Re: [ippm] Reordering Def in draft-ietf-ippm-reporting-05 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 20:25:35 -0000 This is a multi-part message in MIME format. --------------000602010800060905010706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Additional information in this topic can be found in RFC5236 (http://www.faqs.org/rfcs/rfc5236.html) as well as at http://www.cnrl.colostate.edu/Projects/PacketReordering/packetreordering.html#Publications I think 5236 provides a cleaner way to handle this. -- Anura P. Jayasumana Professor, Electrical & Computer Engineering and Computer Science Department of Electrical and Computer Engineering Colorado State University Fort Collins, CO 80523 Phone: (970) 491-7855 On 10/7/2010 1:53 PM, Al Morton wrote: > Matt, > > You asked that I take a look at: > >> >> * 4.5. Reordering* >> >> Reordering is the fraction of unique packets received for >> which the >> sequence number of any given packet is less than the highest >> sequence >> number largest sequence number of any packet previously >> received. > ^^^^^^^^^^^^^^^^^^^^^^^ > I think you identified this redundant text during the meeting, right? > >> For the >> purposes of determining the sequence number of the preceding >> packets in this definition, assume sequence numbers starting >> with 1, >> and an extra packet at the start of the stream of received >> packets, >> with a sequence number of 0, is considered to be present >> (this extra >> packet, of course, is not counted for the purposes of >> computing the >> fraction). > > I think your word definition is pretty close, but there should be an > explicit designation of a reordered packet, IMO. Also, the "unique" > aspect > is a fairly subtle way to exclude any duplicate packet from being > reordered. > We could explain this fairly easily. > > I suggest: > > 4.5. Reordering > > | Reordering is the fraction of unique packets received for which the > sequence > | number of a packet designated "reordered" is less than the highest > sequence > | number of any packet previously received, and the "unique" aspect > excludes > | any Duplicate packets (as described in section 4.4 above). > For the purposes of determining the sequence number of the preceding > packets in this definition, assume sequence numbers starting with 1, > and an extra packet at the start of the stream of received packets, > with a sequence number of 0, is considered to be present (this extra > packet, of course, is not counted for the purposes of computing the > fraction). > > hope this helps, > Al > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm --------------000602010800060905010706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Additional information in this topic can be found in  RFC5236 (http://www.faqs.org/rfcs/rfc5236.html)
as well as at   http://www.cnrl.colostate.edu/Projects/PacketReordering/packetreordering.html#Publications

I think 5236 provides a cleaner way to handle this. 
-- 
Anura P. Jayasumana
Professor, Electrical & Computer Engineering
                           and Computer Science
Department of Electrical and Computer Engineering
Colorado State University
Fort Collins, CO 80523
Phone: (970) 491-7855


On 10/7/2010 1:53 PM, Al Morton wrote:
Matt,

You asked that I take a look at:

4.5.  Reordering

   Reordering is the fraction of unique packets received for
which the
   sequence number of any given packet is less than the highest
sequence
   number largest sequence number of any packet previously
received.
           ^^^^^^^^^^^^^^^^^^^^^^^
I think you identified this redundant text during the meeting, right?          

   For the
purposes of determining the sequence number of the preceding
   packets in this definition, assume sequence numbers starting
with 1,
   and an extra packet at the start of the stream of received
packets,
   with a sequence number of 0, is considered to be present
(this extra
   packet, of course, is not counted for the purposes of
computing the
   fraction).

I think your word definition is pretty close, but there should be an
explicit designation of a reordered packet, IMO.  Also, the "unique" aspect
is a fairly subtle way to exclude any duplicate packet from being reordered. 
We could explain this fairly easily.

I suggest:

4.5. Reordering

|  Reordering is the fraction of unique packets received for which the sequence
|  number of a packet designated "reordered" is less than the highest sequence
|  number of any packet previously received, and the "unique" aspect excludes
|  any Duplicate packets (as described in section 4.4 above).
   For the purposes of determining the sequence number of the preceding
   packets in this definition, assume sequence numbers starting with 1,
   and an extra packet at the start of the stream of received packets,
   with a sequence number of 0, is considered to be present (this extra
   packet, of course, is not counted for the purposes of computing the
   fraction).

hope this helps,
Al


_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
--------------000602010800060905010706-- From acmorton@att.com Fri Oct 8 05:05:13 2010 Return-Path: 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 704DA3A689D for ; Fri, 8 Oct 2010 05:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.391 X-Spam-Level: X-Spam-Status: No, score=-105.391 tagged_above=-999 required=5 tests=[AWL=0.405, 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 wAikZ2dMTzob for ; Fri, 8 Oct 2010 05:05:12 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 545B33A6858 for ; Fri, 8 Oct 2010 05:05:12 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-10.tower-161.messagelabs.com!1286539575!34867249!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 30187 invoked from network); 8 Oct 2010 12:06:16 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-10.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Oct 2010 12:06:16 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o98C6W08006654 for ; Fri, 8 Oct 2010 08:06:32 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o98C6Tas006635 for ; Fri, 8 Oct 2010 08:06:29 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id o98C6BB3002493 for ; Fri, 8 Oct 2010 08:06:11 -0400 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id o98C65wf002259 for ; Fri, 8 Oct 2010 08:06:05 -0400 Message-Id: <201010081206.o98C65wf002259@alpd052.aldc.att.com> Received: from acmt.att.com (vpn-135-70-204-199.vpn.east.att.com[135.70.204.199](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20101008120604gw100ei1p5e>; Fri, 8 Oct 2010 12:06:05 +0000 X-Originating-IP: [135.70.204.199] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 08 Oct 2010 08:06:28 -0400 To: Anura Jayasumana , ippm@ietf.org From: Al Morton In-Reply-To: <4CAE2CF9.2070109@Colostate.edu> References: <201010071953.o97JrOtX031691@alpd052.aldc.att.com> <4CAE2CF9.2070109@Colostate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [ippm] Reordering Def in draft-ietf-ippm-reporting-05 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 12:05:13 -0000 At 04:26 PM 10/7/2010, Anura Jayasumana wrote: >Additional information in this topic can be found in RFC5236 ^^^^^^^^^^^ Since we are doing IETF Standards Track development here, Anura, an informational publication of alternative ideas is not appropriate. Al From wwwrun@rfc-editor.org Sun Oct 10 17:10:38 2010 Return-Path: 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 03A0D3A6911; Sun, 10 Oct 2010 17:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.947 X-Spam-Level: X-Spam-Status: No, score=-101.947 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, 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 hsJ4LKjsgWb6; Sun, 10 Oct 2010 17:10:37 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 126103A693A; Sun, 10 Oct 2010 17:10:33 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E516CE0717; Sun, 10 Oct 2010 17:11:43 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20101011001143.E516CE0717@rfc-editor.org> Date: Sun, 10 Oct 2010 17:11:43 -0700 (PDT) Cc: ippm@ietf.org, rfc-editor@rfc-editor.org Subject: [ippm] RFC 6038 on Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 00:10:38 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6038 Title: Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features Author: A. Morton, L. Ciavattone Status: Standards Track Stream: IETF Date: October 2010 Mailbox: acmorton@att.com, lencia@att.com Pages: 18 Characters: 41273 Updates: RFC5357 I-D Tag: draft-ietf-ippm-twamp-reflect-octets-09.txt URL: http://www.rfc-editor.org/rfc/rfc6038.txt This memo describes two closely related features for the core specification of the Two-Way Active Measurement Protocol (TWAMP): an optional capability where the responding host returns some of the command octets or padding octets to the sender, and an optional sender packet format that ensures equal test packet sizes are used in both directions. [STANDARDS-TRACK] This document is a product of the IP Performance Metrics Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From lars.eggert@nokia.com Mon Oct 11 04:17:22 2010 Return-Path: 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 E87603A69A9 for ; Mon, 11 Oct 2010 04:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.435 X-Spam-Level: X-Spam-Status: No, score=-102.435 tagged_above=-999 required=5 tests=[AWL=-1.325, BAYES_05=-1.11, 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 SaX-IHpHMBl1 for ; Mon, 11 Oct 2010 04:17:20 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id 5F4753A69A4 for ; Mon, 11 Oct 2010 04:17:20 -0700 (PDT) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o9BBIVBb006886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 11 Oct 2010 14:18:31 +0300 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.3 at fit.nokia.com Content-Type: multipart/signed; boundary=Apple-Mail-11--748946147; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 11 Oct 2010 14:18:18 +0300 Message-Id: <5CFCD2B2-2E0E-448F-9C3C-3A629E95543E@nokia.com> To: "ippm@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Mon, 11 Oct 2010 14:18:19 +0300 (EEST) X-Nokia-AV: Clean Subject: [ippm] AD review: draft-ietf-ippm-tcp-throughput-tm-07 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 11:17:23 -0000 --Apple-Mail-11--748946147 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, summary: Not quite ready. My largest issues are: (1) questionable use of RFC2119 language throughout the document (suggestion: remove it) (2) big question marks around "traffic management tests"=20 (the ID acquired this material between -02 and -03) unclear if this is even in scope of the chartered work and if the approach can evaluate such schemes to any useful degree (3) inconsistencies and inaccuracies (see below) I'm also going to assign a transport directorate reviewer to this = document (or its next revision.) Lars INTRODUCTION, paragraph 6: > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in = this > document are to be interpreted as described in RFC 2119 [RFC2119]. There are many instances below where RFC2119 terms are IMO user inappropriately. Do you *really* need RFC2119 language in this Informational document? Section 1., paragraph 1: > Measuring TCP throughput provides a > meaningful measure with respect to the end user experience (and > ultimately reach some level of TCP testing interoperability which > does not exist today). In the last sentence, the parenthesized clause seems to have no relation to the rest of the sentence? Section 1., paragraph 2: > Additionally, end-users (business enterprises) seek to conduct > repeatable TCP throughput tests between enterprise locations. = Since > these enterprises rely on the networks of the providers, a common > test methodology (and metrics) would be equally beneficial to both > parties. The abstract says the goal of this draft is for measuring an "an end-to-end managed network environment". When end-users start to measure paths between locations, their measurements are not normally taken from an an end-to-end *managed* network environment. Are we focusing this ID on an end-to-end managed network environment, or is the intent to support more general end-user measurements? (Whatever it is, the ID needs to be consistent.) Section 1., paragraph 6: > This methodology proposes a test which SHOULD be performed in > addition to traditional Layer 2/3 type tests, which are conducted = to > verify the integrity of the network before conducting TCP tests. I don't think it's appropriate to use an RFC2119 term here. Section 1.1, paragraph 3: > - Customer Provided Equipment (CPE), refers to customer owned "customer owned" what? Section 1.1, paragraph 8: > * Bottleneck Bandwidth and Bandwidth are used synonomously in this > document. > ** Most of the time the Bottleneck Bandwidth is in the access portion > of the wide area network (CE - PE) Footnotes in RFCs don't work well. Suggest to include the comment in the list above. Also: Nit: s/synonomously/synonymously/ Section 2., paragraph 0: > Note that the NUT may consist of a variety of devices including = (and > NOT limited to): load balancers, proxy servers, WAN acceleration > devices. The detailed topology of the NUT MUST be considered when > conducting the TCP throughput tests, but this methodology makes no > attempt to characterize TCP performance related to specific network > architectures. I don't understand what "MUST be considered" means - the paragraph leaves it completely open in which way this consideration is supposed to happen. (Esp. problematic because you use an RFC2119 term.)=20 Section 2., paragraph 3: > - The methodology is not intended to definitively benchmark TCP > implementations of one OS to another, although some users MAY find > some value in conducting qualitative experiments. I don't think it's appropriate to use an RFC2119 term here. Section 2., paragraph 4: > - The methodology is not intended to provide detailed diagnosis > of problems within end-points or the network itself as related to > non-optimal TCP performance, although a results interpretation > section for each test step MAY provide insight into potential > issues within the network. I don't think it's appropriate to use an RFC2119 term here. Section 2., paragraph 5: > - The methodology does not propose a method to operate permanently > with high measurement loads. TCP performance and optimization data = of > operational networks MAY be captured and evaluated by using data of > the "TCP Extended Statistics MIB" [RFC4898]. I don't think it's appropriate to use an RFC2119 term here. Section 2., paragraph 9: > - Provide a practical test approach that specifies well understood, > end-user configurable TCP parameters such as TCP Window size, MSS > (Maximum Segment Size), number of connections, and how these affect > the outcome of TCP performance over a network. The window size for a flow is not typically end-user configurable. Neither is the MSS (because PMTUD/Nagle is in use.)=20 Section 2., paragraph 10: > - Provide specific test conditions (link speed, RTT, TCP Window = size, > etc.) and maximum achievable TCP throughput under TCP Equilibrium > conditions. Again, window size is not typically a configurable OS parameter. Section 2., paragraph 12: > - In test situations where the RECOMMENDED procedure does not yield > the maximum achievable TCP throughput result, this methodology > provides some possible areas within the end host or network that > SHOULD be considered for investigation (although again, this > methodology is not intended to provide a detailed diagnosis of = these > issues). I don't think it's appropriate to use an RFC2119 term here. Section 2.1, paragraph 5: > The following diagram depicts these phases. The diagram does not show a "retransmission phase". Section 2.1, paragraph 7: > This TCP methodology provides guidelines to measure the equilibrium > throughput which refers to the maximum sustained rate obtained by > congestion avoidance before packet loss conditions occur (which MAY > cause the state change from congestion avoidance to a = retransmission > phase). All maximum achievable throughputs specified in Section 3 = are > with respect to this equilibrium state. I don't think it's appropriate to use an RFC2119 term here. Section 2.2, paragraph 2: > The first metric is the TCP Transfer Time, which is simply the > measured time it takes to transfer a block of data across > simultaneous TCP connections. The concept is useful when > benchmarking traffic management techniques, where multiple > connections MAY be REQUIRED. I don't think it's appropriate to use RFC2119 terms here. (And I have no idea what "MAY be REQUIRED" is supposed to indicate.) Section 2.2, paragraph 7: > Table 2.2: Link Speed, RTT, TCP Throughput, Ideal TCP Transfer time Please give all link speeds in Mb/s, otherwise folks can't check the math. Please also give a formula that shows how exactly you computed these numbers (esp. since there are errors or inaccuracies, see below.) You really need to double-check the calculations here. Section 2.2, paragraph 8: > Link Maximum Achievable Ideal TCP Transfer time > Speed RTT (ms) TCP Throughput(Mbps) Time in seconds > = -------------------------------------------------------------------- > T1 20 1.17 684.93 > T1 50 1.40 570.61 > T1 100 1.40 570.61 Why is the performance the same for 50 and 100 ms RTT? Section 2.2, paragraph 9: > T3 10 42.05 19.03 > T3 15 42.05 19.03 > T3 25 41.52 18.82 Why is the transfer time faster for 25ms than for 15ms? Section 2.2, paragraph 10: > T3(ATM) 10 36.50 21.92 > T3(ATM) 15 36.23 22.14 > T3(ATM) 25 36.27 22.05 Why is the transfer time faster for 25ms than for 15ms? Section 2.2, paragraph 12: > * Calculation is based on File Size in Bytes X 8 / TCP = Throughput. > ** TCP Throughput is derived from Table 3.3. I see no asterisks in Table 2.2 - where do these remarks belong? Section 2.2, paragraph 20: > And the third metric is the Buffer Delay Percentage, which = represents > the increase in RTT during a TCP throughput test from the inherent > network RTT (baseline RTT). The baseline RTT is the round-trip = time > inherent to the network path under non-congested conditions. Note that the RTT across some paths is a factor of the load, esp. on paths that include wide-area radio links. Also, is the baseline RTT the shortest measured TCP RTT sample? Section 2.2, paragraph 21: > The Buffer Delay Percentage is defined as: > Average RTT during Transfer - Baseline RTT > ------------------------------------------ x 100 > Baseline RTT How do you measure the average RTT during the transfer? Do you want to average over all TCP RTT samples? If so, how do you get at these? Do you do out-of-band measurements? Section 2.2, paragraph 22: > As an example, the baseline RTT for the network path is 25 msec. > During the course of a TCP transfer, the average RTT across the > entire transfer increased to 32 msec. In this example, the Buffer > Delay Percentage WOULD be calculated as: OK, so by now I am convinced that this ID should simply refrain from using any RFC2119 terms. (Which, by the way, do not include "WOULD".) Section 1., paragraph 0: > 1. Identify the Path MTU. Packetization Layer Path MTU Discovery > or PLPMTUD, [RFC4821], MUST be conducted to verify the maximum > network path MTU. Conducting PLPMTUD establishes the upper limit = for > the MSS to be used in subsequent steps. You cannot run RFC4821 in isolation - it it a technique to be used when implementing a transport protocol. The Linux stack AFAIK does implement it, but many other stacks do not. The best you can do is identify the PMTU for a flow while or after that flow is being transmitted. (Because due to ECMP it may be five-tuple dependent.) Section 3., paragraph 0: > 3. TCP Connection Throughput Tests. With baseline measurements > of Round Trip Time and bottleneck bandwidth, a series of single and > multiple TCP connection throughput tests SHOULD be conducted to > baseline the network performance expectations. Which exact series should be tested here? (Even unclear after reading Section 3.3). Section 4., paragraph 0: > 4. Traffic Management Tests. Various traffic management and = queuing > techniques SHOULD be tested in this step, using multiple TCP > connections. Multiple connection testing SHOULD verify that the > network is configured properly for traffic shaping versus policing, > various queuing implementations, and RED. Even less precise than the previous paragraph. You really can't say "SHOULD" and then wave your hands on what exactly is to be done. (Even unclear after reading Section 3.4.) Section 4., paragraph 4: > - Most importantly, the TCP test host must be capable of generating > and receiving stateful TCP test traffic at the full link speed of = the What do you mean by "stateful"? Section 3.1., paragraph 0: > 3.1. Determine Network Path MTU It seems that you intend to describe a mechanism that runs RFC4821 before you run the actual throughput test. That's not really how stacks work; RFC4821 (if it's implemented at all) is integrated into the stack, because the PMTUD is flow-specific thanks to ECMP. *If* you want to describe a protocol wrapper for running RFC4821 in a standalone manner, you need to fully specify that wrapper (packet formats, state machine, etc.) instead of just outlining its operation. Section 3.2.1, paragraph 3: > During the actual sustained TCP throughput tests, RTT MUST be > measured along with TCP throughput. Buffer delay effects can be > isolated if RTT is concurrently measured. Out-of-band RTT measurements won't necessarily measure the RTT increase seen by the TCP stream, although they will measure the RTT increase sen by competing traffic (that happens to have chosen the same five-tuple as the OOB RTT measurement). What is the intent here? (In-band measurements are difficult on uninstrumented TCP stacks.) Section 3.2.1, paragraph 7: > - ICMP Pings MAY also be adequate to provide round trip time > estimations. Some limitations of ICMP Ping MAY include msec > resolution and whether the network elements respond to pings (or > block them). ICMP is often rate-limited and segregated into different queues, so it's not as reliable and accurate as in-band measurements. Section 3.3.1, paragraph 0: > 3.3.1 Calculate Ideal TCP Window Size Why does the "ideal" TCP window size even matter? First, most stacks do auto-tuning these days. Second, as long as the window is larger than what you need for the BDP, you should be fine. Isn't it enough to require that windows should be large enough? Section 3.3.1, paragraph 6: > Table 3.3: Link Speed, RTT and calculated BDP, TCP Throughput See my comments about Table 2.2. Section 3.3.4, paragraph 2: > - Network congestion causing packet loss which MAY be inferred from > a poor TCP Efficiency metric (100% =3D no loss) "No loss" for TCP means that you're receive window limited. A TCP flow that will always show some losses, otherwise it isn't fully using the path. Section 3.3.4, paragraph 3: > - Network congestion causing an increase in RTT which MAY be = inferred > from the Buffer Delay metric (0% =3D no increase in RTT over = baseline) Unless you're running a delay-based congestion controller, it will be really rare to see delay go up but no loss occurring. Section 3.4.1, paragraph 3: > Traffic shaping is generally configured for TCP data services and > can provide improved TCP performance since the retransmissions are > reduced, which in turn optimizes TCP throughput for the given > available bandwidth. It's not clear at all to me that traffic shaping will improve performance. If you simply buffer data past the allocated rate, TCP will not slow down until you drop, plus then you may have introduced a long delay-spike in the payload stream data. Section 3.4.1.1, paragraph 1: > By plotting the throughput achieved by each TCP connection, the = fair > sharing of the bandwidth is generally very obvious when traffic > shaping is properly configured for the bottleneck interface. For = the > previous example of 5 connections sharing 500 Mbps, each connection > would consume ~100 Mbps with a smooth variation. If traffic = policing > was present on the bottleneck interface, the bandwidth sharing MAY > not be fair and the resulting throughput plot MAY reveal "spikey" > throughput consumption of the competing TCP connections (due to the > retransmissions). The spikes aren't due to retransmissions, they're due to loss probabilities not being fully equal, so that some flows end up with a larger capacity share then others for a while. Section 3.4.2, paragraph 1: > Random Early Discard techniques are specifically targeted to = provide > congestion avoidance for TCP traffic. Before the network element > queue "fills" and enters the tail drop state, RED drops packets at > configurable queue depth thresholds. This action causes TCP > connections to back-off which helps to prevent tail drop, which in > turn helps to prevent global TCP synchronization. But mostly, it keeps the queues (=3D delay) short compared to FIFO. Section 3.4.2, paragraph 2: > Again, rate limited interfaces can benefit greatly from RED based > techniques. Without RED, TCP is generally not able to achieve the > full bandwidth of the bottleneck interface. With RED enabled, TCP > congestion avoidance throttles the connections on the higher speed > interface (i.e. LAN) and can reach equilibrium with the bottleneck > bandwidth (achieving closer to full throughput). I think this paragraph is overstating things. Yes, RED reduces the see-saw and can improve capacity utilization. But TCP can get within a few percent of link utilization even with FIFO (depends on the path parameters). Section 3.4.2, paragraph 3: > The ability to detect proper RED configuration is more easily > diagnosed when conducting a multiple TCP connection test. Multiple > TCP connections provide the multiple bursty sources that emulate = the > real-world conditions for which RED was intended. Multiple parallel bulk transfers to not provide multiple bursty sources. If you want burstiness, you need to start and stop many shorter flows according to some distribution. Section 3.4.2.1, paragraph 1: > The default queuing technique for most network devices is FIFO = based. > Without RED, the FIFO based queue will cause excessive loss to all = of > the TCP connections and in the worst case global TCP = synchronization. But only in the very artificial case of a few perfectly synchronized bulk transfers. With more statmux, there is little issue. --Apple-Mail-11--748946147 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQM/3DDmRp5mxHvrbX tRvSsDANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTA5MTAxNDAwMDAwMFoXDTEwMTAxNDIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC0xhcnMgRWdn ZXJ0MSQwIgYJKoZIhvcNAQkBFhVsYXJzLmVnZ2VydEBub2tpYS5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCrTp9sa04QO3gKan1sQGFAZ91BKjFdECaw29ZXHYOZSFW7JC/oyuAO x7pucJp9qDLYlv60I8zLJ1eocDn3bsjBWwAS65GGVT9NLiblzCd5DeWTkn9UD7OMvLL+Z1Z17sE0 jlmluQSCLjv0P7d6ZCpwVD2hWvuZu37fIQresIEYQLbZHXogwoCMhqwo8k8/WuwDbNcB9RiLq3JW FRjZILMmf5qFdExz1AZyG3OdFXe1F0vcxfHhbrGU5cVklV9XI3TfxVZciFNqnTuWsaHFxU0ZrwI0 njVtpLko1TW1vC5qS2ZIpWq7iDkIke+XL4IYTHlOdH7sM502qEE8JqadXjuTAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJraU8e1Ss8a Uj33lweT8ibOcmNLTNn2pnSi7p5BwNCFtrLNp9AdhcGYJfEQMOlanxc7dpQ7OWUbpub4jAYKyP47 hPQayKMJ73KcKmiN4Czj9g/uCTRwW3kiyhTo22Yl2MWGTM7WI39xTEQo4DOGs9EK6Ldb9zZU4oRl ZbaD1G/Lo33LYmuI8MfCLzTBtmT5MybyEnK17457+8bMLXoSFJfFGk5LPCn38SWdiAG/YH2A4had 3wvpd9Mpx38fxw/RZqlifRSTT8zlOwkq/u/+il9D4o2ruwMEMC1ZwPN3/w/u+QCw4o78wm24BOwU KyA6H4H1r9BoUZ1To1zXxwvuI+sxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9KwMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAxMTEx MTgxOVowIwYJKoZIhvcNAQkEMRYEFAzRLyfhtZ/iuVCMpwcB8ya4cNOoMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEDP9ww5kaeZsR76217Ub0rAwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9Kw MA0GCSqGSIb3DQEBAQUABIIBAIhcFK0T/PFNgKfDl7MQDX/sHV12rzbgxZFoMJ8rfTKjbUSU6vGF C2kJ0KUi+lqHRIqLnOQTFdxGnxE0nhuSksfOVqk0wGAKsXL/C1ad38CT6O+eDfQk5WqIRvj120hD NJCFCVUl2UH31vFY/9y5s/1/V50ZAZe7m33HxEGXzeTV8YV5F0j4zWlq7Nc9E0hpFvMqjxXTJ2Sm oKnkhZ0UM1DxpDwbjOIOWy5AzXq9yIsV2CdxBXZIedheOWMXvbkUY+UUrRjf/KHBYoHZ9QTDy6bV 7ysOSe1cRAGOHdF26k09Qwu81P7ZWoBbA56a+qsss6txxylTrcoL3GLxwPWDUpcAAAAAAAA= --Apple-Mail-11--748946147-- From Barry.Constantine@jdsu.com Mon Oct 11 05:12:19 2010 Return-Path: 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 934EF3A69E8 for ; Mon, 11 Oct 2010 05:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.964 X-Spam-Level: X-Spam-Status: No, score=-5.964 tagged_above=-999 required=5 tests=[AWL=0.635, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 J7tugpDHnSUG for ; Mon, 11 Oct 2010 05:12:00 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with SMTP id 9E6073A69E9 for ; Mon, 11 Oct 2010 05:11:47 -0700 (PDT) Received: from source ([209.36.247.244]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTLL/QtVXNnlGlQGoBfcGs7P9mSXaIDFx@postini.com; Mon, 11 Oct 2010 05:13:01 PDT Received: from milexhtca2.ds.jdsu.net ([10.75.2.122]) by Outbound1.jdsu.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Oct 2010 05:11:19 -0700 Received: from MILEXCH1.ds.jdsu.net ([fe80::6444:f010:6d40:bdb]) by milexhtca2.ds.jdsu.net ([::1]) with mapi; Mon, 11 Oct 2010 05:11:19 -0700 From: Barry Constantine To: Lars Eggert , "ippm@ietf.org WG" Date: Mon, 11 Oct 2010 05:11:18 -0700 Thread-Topic: [ippm] AD review: draft-ietf-ippm-tcp-throughput-tm-07 Thread-Index: ActpNg2j9cm09z4jRC6nGpSmGrVXZAABcXVg Message-ID: <94DEE80C63F7D34F9DC9FE69E39436BE38BA6A4F7C@MILEXCH1.ds.jdsu.net> References: <5CFCD2B2-2E0E-448F-9C3C-3A629E95543E@nokia.com> In-Reply-To: <5CFCD2B2-2E0E-448F-9C3C-3A629E95543E@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Oct 2010 12:11:19.0928 (UTC) FILETIME=[69CEE780:01CB693D] Subject: Re: [ippm] AD review: draft-ietf-ippm-tcp-throughput-tm-07 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 12:12:19 -0000 Hi Lars, Thank you for the thorough review. We will address all technical comments a= nd revise or clarify accordingly. I think we can get a draft-08 version ou= t by the end of this week. Regarding the use of RFC2119 language in this document, some comments were = made to do so and we added this to the draft-07. These comments may have been off-list and I'd have to dig around, but I see= m to recall the intent was to clarify what was essential (must do) and opti= onal (should do) and that is how the RFC2119 language came into play. Just to be clear, do Informational works generally (or always) refrain from= using RFC2119 language? Thanks, Barry -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Lar= s Eggert Sent: Monday, October 11, 2010 7:18 AM To: ippm@ietf.org WG Subject: [ippm] AD review: draft-ietf-ippm-tcp-throughput-tm-07 Hi, summary: Not quite ready. My largest issues are: (1) questionable use of RFC2119 language throughout the document (suggestion: remove it) (2) big question marks around "traffic management tests" (the ID acquired this material between -02 and -03) unclear if this is even in scope of the chartered work and if the approach can evaluate such schemes to any useful degree (3) inconsistencies and inaccuracies (see below) I'm also going to assign a transport directorate reviewer to this document = (or its next revision.) Lars INTRODUCTION, paragraph 6: > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. There are many instances below where RFC2119 terms are IMO user inappropriately. Do you *really* need RFC2119 language in this Informational document? Section 1., paragraph 1: > Measuring TCP throughput provides a > meaningful measure with respect to the end user experience (and > ultimately reach some level of TCP testing interoperability which > does not exist today). In the last sentence, the parenthesized clause seems to have no relation to the rest of the sentence? Section 1., paragraph 2: > Additionally, end-users (business enterprises) seek to conduct > repeatable TCP throughput tests between enterprise locations. Since > these enterprises rely on the networks of the providers, a common > test methodology (and metrics) would be equally beneficial to both > parties. The abstract says the goal of this draft is for measuring an "an end-to-end managed network environment". When end-users start to measure paths between locations, their measurements are not normally taken from an an end-to-end *managed* network environment. Are we focusing this ID on an end-to-end managed network environment, or is the intent to support more general end-user measurements? (Whatever it is, the ID needs to be consistent.) Section 1., paragraph 6: > This methodology proposes a test which SHOULD be performed in > addition to traditional Layer 2/3 type tests, which are conducted to > verify the integrity of the network before conducting TCP tests. I don't think it's appropriate to use an RFC2119 term here. Section 1.1, paragraph 3: > - Customer Provided Equipment (CPE), refers to customer owned "customer owned" what? Section 1.1, paragraph 8: > * Bottleneck Bandwidth and Bandwidth are used synonomously in this > document. > ** Most of the time the Bottleneck Bandwidth is in the access portion > of the wide area network (CE - PE) Footnotes in RFCs don't work well. Suggest to include the comment in the list above. Also: Nit: s/synonomously/synonymously/ Section 2., paragraph 0: > Note that the NUT may consist of a variety of devices including (and > NOT limited to): load balancers, proxy servers, WAN acceleration > devices. The detailed topology of the NUT MUST be considered when > conducting the TCP throughput tests, but this methodology makes no > attempt to characterize TCP performance related to specific network > architectures. I don't understand what "MUST be considered" means - the paragraph leaves it completely open in which way this consideration is supposed to happen. (Esp. problematic because you use an RFC2119 term.) Section 2., paragraph 3: > - The methodology is not intended to definitively benchmark TCP > implementations of one OS to another, although some users MAY find > some value in conducting qualitative experiments. I don't think it's appropriate to use an RFC2119 term here. Section 2., paragraph 4: > - The methodology is not intended to provide detailed diagnosis > of problems within end-points or the network itself as related to > non-optimal TCP performance, although a results interpretation > section for each test step MAY provide insight into potential > issues within the network. I don't think it's appropriate to use an RFC2119 term here. Section 2., paragraph 5: > - The methodology does not propose a method to operate permanently > with high measurement loads. TCP performance and optimization data of > operational networks MAY be captured and evaluated by using data of > the "TCP Extended Statistics MIB" [RFC4898]. I don't think it's appropriate to use an RFC2119 term here. Section 2., paragraph 9: > - Provide a practical test approach that specifies well understood, > end-user configurable TCP parameters such as TCP Window size, MSS > (Maximum Segment Size), number of connections, and how these affect > the outcome of TCP performance over a network. The window size for a flow is not typically end-user configurable. Neither is the MSS (because PMTUD/Nagle is in use.) Section 2., paragraph 10: > - Provide specific test conditions (link speed, RTT, TCP Window size, > etc.) and maximum achievable TCP throughput under TCP Equilibrium > conditions. Again, window size is not typically a configurable OS parameter. Section 2., paragraph 12: > - In test situations where the RECOMMENDED procedure does not yield > the maximum achievable TCP throughput result, this methodology > provides some possible areas within the end host or network that > SHOULD be considered for investigation (although again, this > methodology is not intended to provide a detailed diagnosis of these > issues). I don't think it's appropriate to use an RFC2119 term here. Section 2.1, paragraph 5: > The following diagram depicts these phases. The diagram does not show a "retransmission phase". Section 2.1, paragraph 7: > This TCP methodology provides guidelines to measure the equilibrium > throughput which refers to the maximum sustained rate obtained by > congestion avoidance before packet loss conditions occur (which MAY > cause the state change from congestion avoidance to a retransmission > phase). All maximum achievable throughputs specified in Section 3 are > with respect to this equilibrium state. I don't think it's appropriate to use an RFC2119 term here. Section 2.2, paragraph 2: > The first metric is the TCP Transfer Time, which is simply the > measured time it takes to transfer a block of data across > simultaneous TCP connections. The concept is useful when > benchmarking traffic management techniques, where multiple > connections MAY be REQUIRED. I don't think it's appropriate to use RFC2119 terms here. (And I have no idea what "MAY be REQUIRED" is supposed to indicate.) Section 2.2, paragraph 7: > Table 2.2: Link Speed, RTT, TCP Throughput, Ideal TCP Transfer time Please give all link speeds in Mb/s, otherwise folks can't check the math. Please also give a formula that shows how exactly you computed these numbers (esp. since there are errors or inaccuracies, see below.) You really need to double-check the calculations here. Section 2.2, paragraph 8: > Link Maximum Achievable Ideal TCP Transfer time > Speed RTT (ms) TCP Throughput(Mbps) Time in seconds > -------------------------------------------------------------------- > T1 20 1.17 684.93 > T1 50 1.40 570.61 > T1 100 1.40 570.61 Why is the performance the same for 50 and 100 ms RTT? Section 2.2, paragraph 9: > T3 10 42.05 19.03 > T3 15 42.05 19.03 > T3 25 41.52 18.82 Why is the transfer time faster for 25ms than for 15ms? Section 2.2, paragraph 10: > T3(ATM) 10 36.50 21.92 > T3(ATM) 15 36.23 22.14 > T3(ATM) 25 36.27 22.05 Why is the transfer time faster for 25ms than for 15ms? Section 2.2, paragraph 12: > * Calculation is based on File Size in Bytes X 8 / TCP Throughput. > ** TCP Throughput is derived from Table 3.3. I see no asterisks in Table 2.2 - where do these remarks belong? Section 2.2, paragraph 20: > And the third metric is the Buffer Delay Percentage, which represents > the increase in RTT during a TCP throughput test from the inherent > network RTT (baseline RTT). The baseline RTT is the round-trip time > inherent to the network path under non-congested conditions. Note that the RTT across some paths is a factor of the load, esp. on paths that include wide-area radio links. Also, is the baseline RTT the shortest measured TCP RTT sample? Section 2.2, paragraph 21: > The Buffer Delay Percentage is defined as: > Average RTT during Transfer - Baseline RTT > ------------------------------------------ x 100 > Baseline RTT How do you measure the average RTT during the transfer? Do you want to average over all TCP RTT samples? If so, how do you get at these? Do you do out-of-band measurements? Section 2.2, paragraph 22: > As an example, the baseline RTT for the network path is 25 msec. > During the course of a TCP transfer, the average RTT across the > entire transfer increased to 32 msec. In this example, the Buffer > Delay Percentage WOULD be calculated as: OK, so by now I am convinced that this ID should simply refrain from using any RFC2119 terms. (Which, by the way, do not include "WOULD".) Section 1., paragraph 0: > 1. Identify the Path MTU. Packetization Layer Path MTU Discovery > or PLPMTUD, [RFC4821], MUST be conducted to verify the maximum > network path MTU. Conducting PLPMTUD establishes the upper limit for > the MSS to be used in subsequent steps. You cannot run RFC4821 in isolation - it it a technique to be used when implementing a transport protocol. The Linux stack AFAIK does implement it, but many other stacks do not. The best you can do is identify the PMTU for a flow while or after that flow is being transmitted. (Because due to ECMP it may be five-tuple dependent.) Section 3., paragraph 0: > 3. TCP Connection Throughput Tests. With baseline measurements > of Round Trip Time and bottleneck bandwidth, a series of single and > multiple TCP connection throughput tests SHOULD be conducted to > baseline the network performance expectations. Which exact series should be tested here? (Even unclear after reading Section 3.3). Section 4., paragraph 0: > 4. Traffic Management Tests. Various traffic management and queuing > techniques SHOULD be tested in this step, using multiple TCP > connections. Multiple connection testing SHOULD verify that the > network is configured properly for traffic shaping versus policing, > various queuing implementations, and RED. Even less precise than the previous paragraph. You really can't say "SHOULD" and then wave your hands on what exactly is to be done. (Even unclear after reading Section 3.4.) Section 4., paragraph 4: > - Most importantly, the TCP test host must be capable of generating > and receiving stateful TCP test traffic at the full link speed of the What do you mean by "stateful"? Section 3.1., paragraph 0: > 3.1. Determine Network Path MTU It seems that you intend to describe a mechanism that runs RFC4821 before you run the actual throughput test. That's not really how stacks work; RFC4821 (if it's implemented at all) is integrated into the stack, because the PMTUD is flow-specific thanks to ECMP. *If* you want to describe a protocol wrapper for running RFC4821 in a standalone manner, you need to fully specify that wrapper (packet formats, state machine, etc.) instead of just outlining its operation. Section 3.2.1, paragraph 3: > During the actual sustained TCP throughput tests, RTT MUST be > measured along with TCP throughput. Buffer delay effects can be > isolated if RTT is concurrently measured. Out-of-band RTT measurements won't necessarily measure the RTT increase seen by the TCP stream, although they will measure the RTT increase sen by competing traffic (that happens to have chosen the same five-tuple as the OOB RTT measurement). What is the intent here? (In-band measurements are difficult on uninstrumented TCP stacks.) Section 3.2.1, paragraph 7: > - ICMP Pings MAY also be adequate to provide round trip time > estimations. Some limitations of ICMP Ping MAY include msec > resolution and whether the network elements respond to pings (or > block them). ICMP is often rate-limited and segregated into different queues, so it's not as reliable and accurate as in-band measurements. Section 3.3.1, paragraph 0: > 3.3.1 Calculate Ideal TCP Window Size Why does the "ideal" TCP window size even matter? First, most stacks do auto-tuning these days. Second, as long as the window is larger than what you need for the BDP, you should be fine. Isn't it enough to require that windows should be large enough? Section 3.3.1, paragraph 6: > Table 3.3: Link Speed, RTT and calculated BDP, TCP Throughput See my comments about Table 2.2. Section 3.3.4, paragraph 2: > - Network congestion causing packet loss which MAY be inferred from > a poor TCP Efficiency metric (100% =3D no loss) "No loss" for TCP means that you're receive window limited. A TCP flow that will always show some losses, otherwise it isn't fully using the path. Section 3.3.4, paragraph 3: > - Network congestion causing an increase in RTT which MAY be inferred > from the Buffer Delay metric (0% =3D no increase in RTT over baseline) Unless you're running a delay-based congestion controller, it will be really rare to see delay go up but no loss occurring. Section 3.4.1, paragraph 3: > Traffic shaping is generally configured for TCP data services and > can provide improved TCP performance since the retransmissions are > reduced, which in turn optimizes TCP throughput for the given > available bandwidth. It's not clear at all to me that traffic shaping will improve performance. If you simply buffer data past the allocated rate, TCP will not slow down until you drop, plus then you may have introduced a long delay-spike in the payload stream data. Section 3.4.1.1, paragraph 1: > By plotting the throughput achieved by each TCP connection, the fair > sharing of the bandwidth is generally very obvious when traffic > shaping is properly configured for the bottleneck interface. For the > previous example of 5 connections sharing 500 Mbps, each connection > would consume ~100 Mbps with a smooth variation. If traffic policing > was present on the bottleneck interface, the bandwidth sharing MAY > not be fair and the resulting throughput plot MAY reveal "spikey" > throughput consumption of the competing TCP connections (due to the > retransmissions). The spikes aren't due to retransmissions, they're due to loss probabilities not being fully equal, so that some flows end up with a larger capacity share then others for a while. Section 3.4.2, paragraph 1: > Random Early Discard techniques are specifically targeted to provide > congestion avoidance for TCP traffic. Before the network element > queue "fills" and enters the tail drop state, RED drops packets at > configurable queue depth thresholds. This action causes TCP > connections to back-off which helps to prevent tail drop, which in > turn helps to prevent global TCP synchronization. But mostly, it keeps the queues (=3D delay) short compared to FIFO. Section 3.4.2, paragraph 2: > Again, rate limited interfaces can benefit greatly from RED based > techniques. Without RED, TCP is generally not able to achieve the > full bandwidth of the bottleneck interface. With RED enabled, TCP > congestion avoidance throttles the connections on the higher speed > interface (i.e. LAN) and can reach equilibrium with the bottleneck > bandwidth (achieving closer to full throughput). I think this paragraph is overstating things. Yes, RED reduces the see-saw and can improve capacity utilization. But TCP can get within a few percent of link utilization even with FIFO (depends on the path parameters). Section 3.4.2, paragraph 3: > The ability to detect proper RED configuration is more easily > diagnosed when conducting a multiple TCP connection test. Multiple > TCP connections provide the multiple bursty sources that emulate the > real-world conditions for which RED was intended. Multiple parallel bulk transfers to not provide multiple bursty sources. If you want burstiness, you need to start and stop many shorter flows according to some distribution. Section 3.4.2.1, paragraph 1: > The default queuing technique for most network devices is FIFO based. > Without RED, the FIFO based queue will cause excessive loss to all of > the TCP connections and in the worst case global TCP synchronization. But only in the very artificial case of a few perfectly synchronized bulk transfers. With more statmux, there is little issue. From acmorton@att.com Mon Oct 11 05:27:05 2010 Return-Path: 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 E178A3A69EA; Mon, 11 Oct 2010 05:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.414 X-Spam-Level: X-Spam-Status: No, score=-105.414 tagged_above=-999 required=5 tests=[AWL=0.382, 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 WJHGq0fCeNte; Mon, 11 Oct 2010 05:27:05 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id F0C3D3A69B6; Mon, 11 Oct 2010 05:27:04 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-2.tower-167.messagelabs.com!1286800095!16756688!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 28712 invoked from network); 11 Oct 2010 12:28:15 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-2.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 Oct 2010 12:28:15 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o9BCSVNx002589; Mon, 11 Oct 2010 08:28:32 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o9BCST4P002582; Mon, 11 Oct 2010 08:28:29 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id o9BCSCHc016800; Mon, 11 Oct 2010 08:28:12 -0400 Received: from mailgw1.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id o9BCS55n016546; Mon, 11 Oct 2010 08:28:05 -0400 Message-Id: <201010111228.o9BCS55n016546@alpd052.aldc.att.com> Received: from acmt.att.com (vpn-135-70-228-37.vpn.east.att.com[135.70.228.37](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20101011122804gw100ei1sle>; Mon, 11 Oct 2010 12:28:05 +0000 X-Originating-IP: [135.70.228.37] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 11 Oct 2010 08:28:28 -0400 To: pmol@ietf.org From: Al Morton Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: bmwg@ietf.org, ippm@ietf.org Subject: [ippm] Repeated WGLC on draft-ietf-pmol-metrics-framework-05 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 12:27:06 -0000 PMOL WG, cc IPPM and BMWG WGs, This message begins a PMOL WG Last Call on the following draft: Title: Guidelines for Considering New Performance Metric Development Author(s) : A. Clark, B. Claise Filename : draft-ietf-pmol-metrics-framework-05.txt Pages : 21 Date : 2010-10-10 This memo describes a framework and guidelines for the development of performance metrics that are beyond the scope of existing working group charters in the IETF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pmol-metrics-framework-05.txt There has been discussion of this draft for over 3 years on the PMOL list and at meetings, both formal and informal. The previous WGLC closed on January 2, 2009. The Authors believe all comments to date have been addressed. Please weigh-in on whether or not this Draft should be forwarded to the Area Directors for publication as a Standards Track RFC. Send your comments to the PMOL list or the co-chairs. The Last Call will be open till November 8, 2010. thanks for your review and comments, Al Morton co-chair, PMOL WG From Anura.Jayasumana@colostate.edu Mon Oct 11 05:55:16 2010 Return-Path: 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 632E03A6A0C for ; Mon, 11 Oct 2010 05:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 Ke9zfb9ytZl1 for ; Mon, 11 Oct 2010 05:55:14 -0700 (PDT) Received: from smith.ACNS.ColoState.EDU (smith.acns.colostate.edu [129.82.100.169]) by core3.amsl.com (Postfix) with ESMTP id A09533A6A2B for ; Mon, 11 Oct 2010 05:55:14 -0700 (PDT) Received: from jansen.ColoState.EDU (jansen.acns.colostate.edu [129.82.100.132]) by smith.ACNS.ColoState.EDU (8.13.8/8.12.11) with ESMTP id o9BCuKrh014573; Mon, 11 Oct 2010 06:56:20 -0600 Received: from mail1.engr.colostate.edu (mail1.engr.colostate.edu [129.82.224.31]) by jansen.ColoState.EDU (8.13.1/8.13.1) with ESMTP id o9BCuKhi021646; Mon, 11 Oct 2010 06:56:20 -0600 Received: from [127.0.0.1] (20vpn38.vpn.colostate.edu.vpn.colostate.edu [129.82.20.38]) by mail1.engr.colostate.edu (Postfix) with ESMTP id 9128829; Mon, 11 Oct 2010 06:56:19 -0600 (MDT) Message-ID: <4CB3096A.2000100@colostate.edu> Date: Mon, 11 Oct 2010 06:56:10 -0600 From: Anura Jayasumana User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Al Morton References: <201010071953.o97JrOtX031691@alpd052.aldc.att.com> <4CAE2CF9.2070109@Colostate.edu> <201010081206.o98C65wf002259@alpd052.aldc.att.com> In-Reply-To: <201010081206.o98C65wf002259@alpd052.aldc.att.com> Content-Type: multipart/mixed; boundary="------------070000070005020707030500" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-11_07:2010-10-11, 2010-10-11, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1010110066 Cc: ippm@ietf.org Subject: Re: [ippm] Reordering Def in draft-ietf-ippm-reporting-05 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anura.Jayasumana@colostate.edu List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 12:55:16 -0000 This is a multi-part message in MIME format. --------------070000070005020707030500 Content-Type: multipart/alternative; boundary="------------050804060706050205010101" --------------050804060706050205010101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I was just pointing to more accurate and useful ways of defining and characterizing reordering (--- RFC 5236 and some peer reviewed literature that thoroughly compare the pros and cons of different metrics for reordering at http://www.cnrl.colostate.edu/Projects/PacketReordering/packetreordering.html#Publications -- -). There is no suggestion that 5236 be used in the development nor do I have any interest in getting anything to the "standard track".. The fact that people have voluntarily used RD and its subsequent derivatives in their work speaks for itself. However, I do find the statement "alternative ideas .. not appropriate" quite amusing - irrespective of their source. Wish you good luck in your Standard Track development - irrespective of what ideas you wish to include and exclude. Best! -- Anura P. Jayasumana Professor, Electrical & Computer Engineering and Computer Science Department of Electrical and Computer Engineering Colorado State University Fort Collins, CO 80523 Al Morton wrote: > At 04:26 PM 10/7/2010, Anura Jayasumana wrote: >> Additional information in this topic can be found in RFC5236 > ^^^^^^^^^^^ > Since we are doing IETF Standards Track development here, Anura, > an informational publication of alternative ideas is not appropriate. > > Al > >> Additional information in this topic can be found in RFC5236 >> (http://www.faqs.org/rfcs/rfc5236.html) >> as well as at >> http://www.cnrl.colostate.edu/Projects/PacketReordering/packetreordering.html#Publications >> >> I think 5236 provides a cleaner way to handle this. >> -- >> Anura P. Jayasumana >> Professor, Electrical & Computer Engineering >> and Computer Science >> Department of Electrical and Computer Engineering >> Colorado State University >> Fort Collins, CO 80523 >> Phone: (970) 491-7855 >> >> >> On 10/7/2010 1:53 PM, Al Morton wrote: >>> Matt, >>> >>> You asked that I take a look at: >>> >>>> >>>> * 4.5. Reordering* >>>> >>>> Reordering is the fraction of unique packets received for >>>> which the >>>> sequence number of any given packet is less than the highest >>>> sequence >>>> number largest sequence number of any packet previously >>>> received. >>>> >>> ^^^^^^^^^^^^^^^^^^^^^^^ >>> I think you identified this redundant text during the meeting, >>> right? >>> >>>> For the >>>> purposes of determining the sequence number of the preceding >>>> packets in this definition, assume sequence numbers starting >>>> with 1, >>>> and an extra packet at the start of the stream of received >>>> packets, >>>> with a sequence number of 0, is considered to be present >>>> (this extra >>>> packet, of course, is not counted for the purposes of >>>> computing the >>>> fraction). >>>> >>> >>> I think your word definition is pretty close, but there should be an >>> explicit designation of a reordered packet, IMO. Also, the "unique" >>> aspect >>> is a fairly subtle way to exclude any duplicate packet from being >>> reordered. >>> We could explain this fairly easily. >>> >>> I suggest: >>> >>> 4.5. Reordering >>> >>> | Reordering is the fraction of unique packets received for which >>> the sequence >>> | number of a packet designated "reordered" is less than the >>> highest sequence >>> | number of any packet previously received, and the "unique" aspect >>> excludes >>> | any Duplicate packets (as described in section 4.4 above). >>> For the purposes of determining the sequence number of the preceding >>> packets in this definition, assume sequence numbers starting with 1, >>> and an extra packet at the start of the stream of received packets, >>> with a sequence number of 0, is considered to be present (this extra >>> packet, of course, is not counted for the purposes of computing the >>> fraction). >>> >>> hope this helps, >>> Al >>> >>> >>> _______________________________________________ >>> ippm mailing list >>> ippm@ietf.org >>> https://www.ietf.org/mailman/listinfo/ippm >>> > --------------050804060706050205010101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I was just  pointing to  more accurate  and  useful ways of defining and characterizing reordering  (---  RFC 5236  and
some peer reviewed literature that  thoroughly compare the pros and cons of different metrics for reordering
at   http://www.cnrl.colostate.edu/Projects/PacketReordering/packetreordering.html#Publications -- -).

There is no suggestion that  5236 be used in the  development nor  do I have any interest in  getting anything   to the "standard track".. 
The fact that  people have voluntarily  used RD and its subsequent derivatives in their work speaks for itself.

However, I do find the statement "alternative ideas  ..  not appropriate" quite amusing -  irrespective of  their source.

Wish you good luck in your Standard Track development   - irrespective of what ideas you  wish to include and exclude.


Best!
-- 
Anura P. Jayasumana
Professor, Electrical & Computer Engineering
                           and Computer Science
Department of Electrical and Computer Engineering
Colorado State University
Fort Collins, CO 80523



Al Morton wrote:
At 04:26 PM 10/7/2010, Anura Jayasumana wrote:
Additional information in this topic can be found in  RFC5236
            ^^^^^^^^^^^
Since we are doing IETF Standards Track development here, Anura,
an informational publication of alternative ideas is not appropriate.

Al

Additional information in this topic can be found in  RFC5236 (http://www.faqs.org/rfcs/rfc5236.html)
as well as at   http://www.cnrl.colostate.edu/Projects/PacketReordering/packetreordering.html#Publications

I think 5236 provides a cleaner way to handle this. 
-- 
Anura P. Jayasumana
Professor, Electrical & Computer Engineering
                           and Computer Science
Department of Electrical and Computer Engineering
Colorado State University
Fort Collins, CO 80523
Phone: (970) 491-7855


On 10/7/2010 1:53 PM, Al Morton wrote:
Matt,

You asked that I take a look at:

4.5.  Reordering

   Reordering is the fraction of unique packets received for
which the
   sequence number of any given packet is less than the highest
sequence
   number largest sequence number of any packet previously
received.
           ^^^^^^^^^^^^^^^^^^^^^^^
I think you identified this redundant text during the meeting, right?          

   For the
purposes of determining the sequence number of the preceding
   packets in this definition, assume sequence numbers starting
with 1,
   and an extra packet at the start of the stream of received
packets,
   with a sequence number of 0, is considered to be present
(this extra
   packet, of course, is not counted for the purposes of
computing the
   fraction).

I think your word definition is pretty close, but there should be an
explicit designation of a reordered packet, IMO.  Also, the "unique" aspect
is a fairly subtle way to exclude any duplicate packet from being reordered. 
We could explain this fairly easily.

I suggest:

4.5. Reordering

|  Reordering is the fraction of unique packets received for which the sequence
|  number of a packet designated "reordered" is less than the highest sequence
|  number of any packet previously received, and the "unique" aspect excludes
|  any Duplicate packets (as described in section 4.4 above).
   For the purposes of determining the sequence number of the preceding
   packets in this definition, assume sequence numbers starting with 1,
   and an extra packet at the start of the stream of received packets,
   with a sequence number of 0, is considered to be present (this extra
   packet, of course, is not counted for the purposes of computing the
   fraction).

hope this helps,
Al


_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm

--------------050804060706050205010101-- --------------070000070005020707030500 Content-Type: text/x-vcard; charset=utf-8; name="Anura_Jayasumana.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Anura_Jayasumana.vcf" begin:vcard fn:Prof. Anura Jayasumana n:Jayasumana;Prof. Anura org:Colorado Sate University;Electrical & Computer Engineering; with jt appointment in Computer Science adr:;;;Fort Collins;CO;80523;USA email;internet:Anura.Jayasumana@Colostate.edu title:Professor tel;work:(970) 491-7855 tel;fax:(970) 491-2249 x-mozilla-html:TRUE url:http://www.engr.colostate.edu/~anura version:2.1 end:vcard --------------070000070005020707030500-- From acmorton@att.com Mon Oct 11 05:57:46 2010 Return-Path: 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 3D7FB3A6A2E; Mon, 11 Oct 2010 05:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.452 X-Spam-Level: X-Spam-Status: No, score=-105.452 tagged_above=-999 required=5 tests=[AWL=0.344, 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 1eLvZEIiENhf; Mon, 11 Oct 2010 05:57:45 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 3C32E3A6A2A; Mon, 11 Oct 2010 05:57:45 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-10.tower-167.messagelabs.com!1286801935!23674833!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 7961 invoked from network); 11 Oct 2010 12:58:56 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-10.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 Oct 2010 12:58:56 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o9BCxBnJ003491; Mon, 11 Oct 2010 08:59:12 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o9BCx39d003272; Mon, 11 Oct 2010 08:59:03 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id o9BCwhWm011613; Mon, 11 Oct 2010 08:58:46 -0400 Received: from mailgw1.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id o9BCwcg7011226; Mon, 11 Oct 2010 08:58:39 -0400 Message-Id: <201010111258.o9BCwcg7011226@alpd052.aldc.att.com> Received: from acmt.att.com (vpn-135-70-228-37.vpn.east.att.com[135.70.228.37](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20101011125838gw100ei1sqe>; Mon, 11 Oct 2010 12:58:38 +0000 X-Originating-IP: [135.70.228.37] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 11 Oct 2010 08:59:01 -0400 To: ippm@ietf.org, pmol@ietf.org From: Al Morton Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ippm] Fwd: [bmwg] WGLC: draft-ietf-bmwg-reset-02 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 12:57:46 -0000 IPPM, PMOL, Some folks may also find this draft & methods useful or interesting and wish to comment. Al >Date: Mon, 11 Oct 2010 08:39:49 -0400 >To: bmwg@ietf.org >From: Al Morton >Subject: [bmwg] WGLC: draft-ietf-bmwg-reset-02 >X-BeenThere: bmwg@ietf.org > >BMWG, > >This message begins the Second WG Last call on the draft: > > Title : Device Reset Characterization > Author(s) : R. Asati, et al. > Filename : draft-ietf-bmwg-reset-02.txt > Pages : 18 > Date : 2010-10-10 > >A URL for this draft is: >http://tools.ietf.org/html/draft-ietf-bmwg-reset-02 > >The Last Call will end on November 8, 2010. > >Since this is the second WGLC (1st closed July 21, 2010), >I ask folks to consider items where they commented earlier, >and make sure that the resolutions are satisfactory. >And it's not too late to read the draft for the first time. >Almost everyone of us has conducted this sort of testing and >should have an opinion on the methods. > >Please weigh-in on whether or not this Internet-Draft >should be given to the Area Directors and IESG for consideration and >publication as an Informational RFC. Send your comments >to this list and/or acmorton@att.com. > >Al >bmwg chair > >_______________________________________________ >bmwg mailing list >bmwg@ietf.org >https://www.ietf.org/mailman/listinfo/bmwg From Barry.Constantine@jdsu.com Mon Oct 11 15:16:16 2010 Return-Path: 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 B54F93A6B9B for ; Mon, 11 Oct 2010 15:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.001 X-Spam-Level: X-Spam-Status: No, score=-6.001 tagged_above=-999 required=5 tests=[AWL=0.598, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 tXIm8a00JZqC for ; Mon, 11 Oct 2010 15:16:15 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with SMTP id 8F7723A6B94 for ; Mon, 11 Oct 2010 15:16:15 -0700 (PDT) Received: from source ([209.36.247.244]) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTLOM+AqWmP4kafF+C7KXhn6G5kQmvYE9@postini.com; Mon, 11 Oct 2010 15:17:28 PDT Received: from milexhtca2.ds.jdsu.net ([10.75.2.122]) by Outbound1.jdsu.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Oct 2010 15:04:12 -0700 Received: from MILEXCH1.ds.jdsu.net ([fe80::6444:f010:6d40:bdb]) by milexhtca2.ds.jdsu.net ([::1]) with mapi; Mon, 11 Oct 2010 15:04:12 -0700 From: Barry Constantine To: Al Morton , "ippm@ietf.org" Date: Mon, 11 Oct 2010 15:04:10 -0700 Thread-Topic: [ippm] Fwd: I-D Action:draft-morton-ippm-rt-loss-01.txt Thread-Index: ActmKdlCxnQFqW83RQ64+r2R5vOq0gDZevEg Message-ID: <94DEE80C63F7D34F9DC9FE69E39436BE38BA6A5525@MILEXCH1.ds.jdsu.net> References: <201010062111.o96LB99k008364@klpd017.kcdc.att.com> <94DEE80C63F7D34F9DC9FE69E39436BE38BA5B6E3F@MILEXCH1.ds.jdsu.net> <201010071413.o97EDa0u017703@klpd017.kcdc.att.com> In-Reply-To: <201010071413.o97EDa0u017703@klpd017.kcdc.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Oct 2010 22:04:12.0923 (UTC) FILETIME=[3CF72CB0:01CB6990] Subject: Re: [ippm] Fwd: I-D Action:draft-morton-ippm-rt-loss-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 22:16:16 -0000 Hi Al, I would support this work, not interested in directly contributing, and wou= ld periodically provide comments. Thanks, Barry -----Original Message----- From: Al Morton [mailto:acmorton@att.com]=20 Sent: Thursday, October 07, 2010 10:14 AM To: Barry Constantine; ippm@ietf.org Subject: RE: [ippm] Fwd: I-D Action:draft-morton-ippm-rt-loss-01.txt Hi Barry, At 09:23 AM 10/7/2010, Barry Constantine wrote: >I reviewed the document and have one comment / question. > >Should this draft discuss implications of packet re-ordering to=20 >round trip loss metrics (in the context of RFC4737)? I think so, there are certainly implications to the return path sampling process if the reordering occurs in the forward direction, and the Src and Dst sequence numbers will not line-up, even if there is no loss concurrent with the reordering... Thanks for your review. I'll try to update this again before the meeting. If I've overlooked some implications, let me know... Would you support this as a chartered WG item? Al From yaakov_s@rad.com Tue Oct 12 00:16:42 2010 Return-Path: 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 ADE3A3A68E9; Tue, 12 Oct 2010 00:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.275 X-Spam-Level: X-Spam-Status: No, score=-102.275 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599, 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 V6jmuxj7sz7c; Tue, 12 Oct 2010 00:16:39 -0700 (PDT) Received: from antivir1.rad.co.il (mx1-q.rad.co.il [80.74.100.136]) by core3.amsl.com (Postfix) with ESMTP id D7CED3A682E; Tue, 12 Oct 2010 00:16:38 -0700 (PDT) Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir1.rad.co.il with ESMTP; 12 Oct 2010 09:17:51 +0200 Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Tue, 12 Oct 2010 09:16:50 +0200 From: Yaakov Stein To: Al Morton Date: Tue, 12 Oct 2010 09:16:55 +0200 Thread-Topic: [PMOL] Repeated WGLC on draft-ietf-pmol-metrics-framework-05 Thread-Index: ActpP6sOtyT7sjoIQt6WXDeL+HFgTwAmunWQ Message-ID: <48E7911F78327A449A9FB95637667286A8219E35@exrad4.ad.rad.co.il> References: <201010111228.o9BCS55n016546@alpd052.aldc.att.com> In-Reply-To: <201010111228.o9BCS55n016546@alpd052.aldc.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pmol@ietf.org" , IETF IPPM WG Subject: Re: [ippm] [PMOL] Repeated WGLC on draft-ietf-pmol-metrics-framework-05 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 07:16:42 -0000 I think there are important ideas here. Three minor comments: 1) The acronym PM is used by the OAM community for "Performance Management" (in contrast to FM which stands for "Fault Management"). Re-use for "Performance Metrics" in a related field (especially considering the weak intercommunications between the communitie= s) could lead to confusion. 2) I understand that the entity/directorate will be reviewing documents that define performance metrics. Who determines which documents need to be = reviewed ? For example, what about an ID from some WG in transport or security that in= passing defines a measured parameter ? (Some directorates look at every document th= at makes it to the IESG) 3) I am not a strong supporter of meta-documents - I much prefer RFCs with meaningful technical content to those that dictate = internal processes. I see this document as a "Tao" for the PMOL and IPPM communities. I remember that 2418 mentions the concept of directorate, and found a list of directorates here - http://www.ietf.org/iesg/directorat= e/=20 but do not recall RFCs for the security, transport, ... directorates, except for the quoted 5706. Since I was not involved in the discussions in PMOL, I would like to know i= f alternative mechanisms for making this information available (e.g., a Performance Metric wiki) have been discussed.=20 Y(J)S -----Original Message----- From: pmol-bounces@ietf.org [mailto:pmol-bounces@ietf.org] On Behalf Of Al = Morton Sent: Monday, October 11, 2010 14:28 To: pmol@ietf.org Cc: bmwg@ietf.org; ippm@ietf.org Subject: [PMOL] Repeated WGLC on draft-ietf-pmol-metrics-framework-05 PMOL WG, cc IPPM and BMWG WGs, This message begins a PMOL WG Last Call on the following draft: Title: Guidelines for Considering New Performance Metric Developm= ent Author(s) : A. Clark, B. Claise Filename : draft-ietf-pmol-metrics-framework-05.txt Pages : 21 Date : 2010-10-10 =09 This memo describes a framework and guidelines for the development of performance metrics that are beyond the scope of existing working group charters in the IETF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pmol-metrics-framework-05.tx= t There has been discussion of this draft for over 3 years on the PMOL list and at meetings, both formal and informal. The previous WGLC closed on January 2, 2009. The Authors believe all comments to date have been addressed. Please weigh-in on whether or not this Draft should be forwarded to the Area Directors for publication as a Standards Track RFC. Send your comments to the PMOL list or the co-chairs. The Last Call will be open till November 8, 2010. thanks for your review and comments, Al Morton co-chair, PMOL WG _______________________________________________ PMOL mailing list PMOL@ietf.org https://www.ietf.org/mailman/listinfo/pmol From henk@ripe.net Wed Oct 13 05:02:55 2010 Return-Path: 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 DF8AE3A6A02 for ; Wed, 13 Oct 2010 05:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, 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 fDo+ugyxRPx6 for ; Wed, 13 Oct 2010 05:02:54 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 5E4BB3A6A11 for ; Wed, 13 Oct 2010 05:02:54 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1P603w-0001qY-Nm for ippm@ietf.org; Wed, 13 Oct 2010 14:04:10 +0200 Received: from [193.0.21.124] (helo=guest193.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1P603w-0004jt-Gj for ippm@ietf.org; Wed, 13 Oct 2010 14:04:04 +0200 Message-ID: <4CB5A034.7010500@ripe.net> Date: Wed, 13 Oct 2010 14:04:04 +0200 From: Henk Uijterwaal Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: ippm@ietf.org References: <4C84A7B2.9010204@ripe.net> In-Reply-To: <4C84A7B2.9010204@ripe.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5df7676b57f364be49651e61627903e28 X-RIPE-Spam-Level: -- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5df7676b57f364be49651e61627903e28 Subject: Re: [ippm] Metrics registry discussion. X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 12:02:56 -0000 IPPM group, On 06/09/2010 10:34, Henk Uijterwaal wrote: > Please see below. In Maastricht, we discussed this topic without reaching > a conclusion. I did promise to take the discussion to the list though. > > So, this is call for comments about the registry and it's future. In > particular, I'd like to hear from people who are using the current registry, > who have developed a registry themselves for a particular application, > or who think that a different registry would be useful for them. > > Note that comments made on the list so-far or at the Maastricht meeting > have been noted. Please respond by October 15, so we can discuss > further steps by the Beijing meeting. There have been no comments on this, if you do have an opinion please speak up in the next day or two. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ I confirm today what I denied yesterday. Anonymous Politician. From Xiangsong.Cui@huawei.com Sun Oct 17 20:25:08 2010 Return-Path: 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 B12F03A6C80 for ; Sun, 17 Oct 2010 20:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.088 X-Spam-Level: X-Spam-Status: No, score=-0.088 tagged_above=-999 required=5 tests=[AWL=0.407, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 aAVFYYwv4593 for ; Sun, 17 Oct 2010 20:25:07 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 732533A6C7B for ; Sun, 17 Oct 2010 20:25:07 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAG009YXUVZYX@szxga04-in.huawei.com> for ippm@ietf.org; Mon, 18 Oct 2010 11:26:24 +0800 (CST) Received: from c00111037 ([10.111.16.128]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAG002S7UVZZ3@szxga04-in.huawei.com> for ippm@ietf.org; Mon, 18 Oct 2010 11:26:23 +0800 (CST) Date: Mon, 18 Oct 2010 11:26:23 +0800 From: Xiangsong Cui To: 'IETF IPPM WG' Message-id: <001f01cb6e74$3d7e4c20$b87ae460$%cui@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=utf-8 Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: ActtNraj5e9e0oaYQZCutjvByYIfkgBNSR3Q Subject: [ippm] Solicit feedback about network capacity draft, thanks in advance! X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 03:25:09 -0000 Hi, As you know, we had a long discussion on RFC5136, but we didn't get enough input for next step, http://www.ietf.org/mail-archive/web/ippm/current/msg02445.html, so I submit this draft, the draft may be accessed by http://tools.ietf.org/id/draft-cui-ippm-rfc5136bis-00.txt. Firstly, I would like to acknowledge Phil, Joseph and everyone who had made contribution to RFC5136, which is the basis of the new draft. And the main modifications in this draft consist of following points: 1, Clarification on definition of node, link, path, etc. 2, Clarification on IP-layer link capacity, path capacity, etc. 3, Router capacity and usage. Another point is that the informative reference [PDM] Dovrolis, C., Ramanathan, P., and D. Moore, "Packet Dispersion Techniques and a Capacity Estimation Methodology", IEEE/ACM Transactions on Networking 12(6): 963-977, December 2004. is removed in the draft, because this paper assumes a path definition which violates the path definition in RFC2330, while RFC2330 is a normative reference. This paper reads "Consider a network path as a sequence of firstcome first-served (FCFS) store-and-forward links that transfer packets from the sender to the receiver ." While in RFC2330, path is not the concatenation of links, but the sequence of node and link. Additionally, this paper clearly states: "Network operators commonly use tools such as MRTG [16] to monitor the utilization of their links with information obtained from the router management software. These techniques are based on counters maintained by routers, and they are normally *accurate*. Their drawback, however, is that they can only be performed with router access, and such access is usually limited to the corresponding network administrators. Instead, in this paper, we focus on an /end-to-end bandwidth monitoring/ approach that requires cooperation of only the *path end-points*. Even though end-to-end approaches are typically not as accurate as router-based measurements, they often are the only feasible approach for monitoring a path that crosses several networks." We are discussing metrics but not monitoring approach here, and I personally think when we are defining metrics we should prefer accuracy to feasibility, even though some metrics are theoretical number. Well, now I would like to know your thought on this item, your feedback is highly appreciated! Best regards, Xiangsong -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Saturday, October 16, 2010 9:32 PM To: Xiangsong.Cui@huawei.com Subject: New Version Notification for draft-cui-ippm-rfc5136bis-00 A new version of I-D, draft-cui-ippm-rfc5136bis-00.txt has been successfully submitted by Xiangsong Cui and posted to the IETF repository. Filename: draft-cui-ippm-rfc5136bis Revision: 00 Title: Defining Network Capacity Creation_date: 2010-10-16 WG ID: Independent Submission Number_of_pages: 28 Abstract: This document defines the metric of network capacity, including link capacity aspect, router capacity aspect and path capacity aspect. RFC5136 has defined link capacity and path capacity, where the router impact is implicitly considered in link capacity. However, in this document, router capacity is considerred as a separate factor of path capacity, no longer a factor of link capacity. This document explicitly describes the router capacity and its impact to network capacity, e.g. how to evaluate path capacity. This document is derived from RFC5136 and obsoletes RFC5136. The IETF Secretariat. From henk@ripe.net Tue Oct 19 00:37:33 2010 Return-Path: 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 0945B3A6A87 for ; Tue, 19 Oct 2010 00:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, 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 rvIh6yMvRRRd for ; Tue, 19 Oct 2010 00:37:31 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id 8A3103A69A1 for ; Tue, 19 Oct 2010 00:37:30 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1P86mc-0001Vl-RT for ippm@ietf.org; Tue, 19 Oct 2010 09:39:00 +0200 Received: from [193.0.21.124] (helo=geir.local) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1P86mc-00079J-FK for ippm@ietf.org; Tue, 19 Oct 2010 09:38:54 +0200 Message-ID: <4CBD4B0E.1030907@ripe.net> Date: Tue, 19 Oct 2010 09:38:54 +0200 From: Henk Uijterwaal Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: "ippm >> IETF IPPM WG" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d58fd3c768593a129be7df541450c2c7b3 X-RIPE-Spam-Level: -- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d58fd3c768593a129be7df541450c2c7b3 Subject: [ippm] 1st draft agenda for Beijing X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 07:37:33 -0000 IPPM group, Please see below, if there is anything you'd like to discuss, let us know. Matt & Henk - - - AGENDA IPPM Meeting @ IETF79 ============================ (Monday, 9:00 - 11:30) 0. 5' Administrativia Scribes: ## (Minutes, Scribe, Blue Sheet, Note Well, ...) 1. 5' Status of drafts not discussed today Ongoing work ============ 2. ... Possible new work ================= 3. 20' Comments on RFC5136/Xiangsong Cui draft-cui-ippm-rfc5136bis-00 4. 30' Metrics registry and the way forward. 5. ... N. AOB -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ I confirm today what I denied yesterday. Anonymous Politician. From acmorton@att.com Sun Oct 24 07:25:05 2010 Return-Path: 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 012083A6876 for ; Sun, 24 Oct 2010 07:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.483 X-Spam-Level: X-Spam-Status: No, score=-105.483 tagged_above=-999 required=5 tests=[AWL=0.313, 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 O2MmRkGf9966 for ; Sun, 24 Oct 2010 07:25:04 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 00AB63A6857 for ; Sun, 24 Oct 2010 07:25:03 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-6.tower-120.messagelabs.com!1287930405!50609298!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 25693 invoked from network); 24 Oct 2010 14:26:46 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-6.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Oct 2010 14:26:46 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o9OER3qU028310 for ; Sun, 24 Oct 2010 10:27:03 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o9OEQwSg028274 for ; Sun, 24 Oct 2010 10:26:58 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id o9OEQe06014177 for ; Sun, 24 Oct 2010 10:26:40 -0400 Received: from mailgw1.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id o9OEQbeZ014158 for ; Sun, 24 Oct 2010 10:26:37 -0400 Message-Id: <201010241426.o9OEQbeZ014158@alpd052.aldc.att.com> Received: from acmt.att.com (vpn-135-70-217-120.vpn.east.att.com[135.70.217.120](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20101024142636gw100ei174e>; Sun, 24 Oct 2010 14:26:37 +0000 X-Originating-IP: [135.70.217.120] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 24 Oct 2010 10:27:01 -0400 To: ippm@ietf.org From: Al Morton Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ippm] Fwd: New Version Notification for draft-ietf-ippm-metrictest-01 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 14:25:05 -0000 IPPM, We've put together an improved version of the metricstest draft. >Filename: draft-ietf-ippm-metrictest >Revision: 01 >Title: IPPM standard advancement testing >Creation_date: 2010-10-24 >WG ID: ippm >Number_of_pages: 39 > >Abstract: >This document specifies tests to determine if multiple independent >instantiations of a performance metric RFC have implemented the >specifications in the same way. This is the performance metric >equivalent of interoperability, required to advance RFCs along the >standards track. Results from different implementations of metric >RFCs will be collected under the same underlying network conditions >and compared using state of the art statistical methods. The goal is >an evaluation of the metric RFC itself, whether its definitions are >clear and unambiguous to implementors and therefore a candidate for >advancement on the IETF standards track. > Here's a list of the recent changes: Changes from WG -00 to WG -01 draft o Discussion on merits and requirements of a distributed lab test using only local load generators. o Proposal of metrics suitable for tests using the proposed measurement configuration. o Hint on delay caused by software based L2TPv3 implementation. o Added an appendix with a test configuration allowing remote tests comparing different implementations accross the network. o Proposal for maximum error of "equivalence", based on performance comparison of identical implementations. This may be useful for both ADK and non-ADK comparisons. regards, Ruediger and Al From root@core3.amsl.com Sun Oct 24 07:30:03 2010 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5D6943A6876; Sun, 24 Oct 2010 07:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101024143002.5D6943A6876@core3.amsl.com> Date: Sun, 24 Oct 2010 07:30:01 -0700 (PDT) Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-metrictest-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 14:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : IPPM standard advancement testing Author(s) : R. Geib, et al. Filename : draft-ietf-ippm-metrictest-01.txt Pages : 39 Date : 2010-10-24 This document specifies tests to determine if multiple independent instantiations of a performance metric RFC have implemented the specifications in the same way. This is the performance metric equivalent of interoperability, required to advance RFCs along the standards track. Results from different implementations of metric RFCs will be collected under the same underlying network conditions and compared using state of the art statistical methods. The goal is an evaluation of the metric RFC itself, whether its definitions are clear and unambiguous to implementors and therefore a candidate for advancement on the IETF standards track. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-metrictest-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ippm-metrictest-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-24071542.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 25 15:30:09 2010 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 98FF63A68E8; Mon, 25 Oct 2010 15:30:07 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101025223009.98FF63A68E8@core3.amsl.com> Date: Mon, 25 Oct 2010 15:30:08 -0700 (PDT) Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-reporting-metrics-04.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 22:30:09 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : Reporting Metrics: Different Points of View Author(s) : A. Morton, et al. Filename : draft-ietf-ippm-reporting-metrics-04.txt Pages : 25 Date : 2010-10-25 Consumers of IP network performance metrics have many different uses in mind. The memo provides "long-term" reporting considerations (e.g, days, weeks or months, as opposed to 10 seconds), based on analysis of the two key audience points-of-view. It describes how the audience categories affect the selection of metric parameters and options when seeking info that serves their needs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-reporting-metrics-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ippm-reporting-metrics-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-25151909.I-D@ietf.org> --NextPart-- From henk@ripe.net Tue Oct 26 08:05:10 2010 Return-Path: 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 82F143A685C for ; Tue, 26 Oct 2010 08:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, 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 5Qr6gEFZDLQp for ; Tue, 26 Oct 2010 08:05:09 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id D91603A6936 for ; Tue, 26 Oct 2010 08:05:08 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1PAl6p-0005Gz-Av for ippm@ietf.org; Tue, 26 Oct 2010 17:06:53 +0200 Received: from [193.0.21.124] (helo=geir.local) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1PAl6p-0004VV-1l for ippm@ietf.org; Tue, 26 Oct 2010 17:06:43 +0200 Message-ID: <4CC6EE82.8070508@ripe.net> Date: Tue, 26 Oct 2010 17:06:42 +0200 From: Henk Uijterwaal Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.11) Gecko/20101013 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: IETF IPPM WG X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d57454f1138f7ed484c9177ed92bbd71b8 X-RIPE-Spam-Level: -- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d57454f1138f7ed484c9177ed92bbd71b8 Subject: [ippm] Draft agenda for Beijing X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 15:05:10 -0000 IPPM Group, Please see below. Comments welcome, if you are presenting, then please send us your slides (preferably the evening before the meeting). Matt & Henk - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - AGENDA IPPM Meeting @ IETF79 ============================ Draft, Oct 26. (Monday, 9:00 - 11:30) 0. 5' Administrativia Scribes: É. (Minutes, Scribe, Blue Sheet, Note Well, ...) 1. 5' Status of drafts not discussed today Ongoing work ============ 2. 20' IPPM standard advancement testing (Al Morton) draft-ietf-ippm-metrictest-02 3. 10' Long term reporting draft (Al Morton) draft-ietf-ippm-reporting-metrics-04.txt 4. 10' Liaison statement from ITU-T Study Group 12. (Al Morton) Possible new work ================= 5. 30' Comments on RFC5136 (Xiangsong Cui) draft-cui-ippm-rfc5136bis-00 6. 30' Metrics registry and the way forward. * Introduction (Henk Uijterwaal) * draft-morton-ippm-rfc4148-obsolete (Al Morton) * draft-stephan-ippm-registry-ext (Emile Stephan) * Discussion 7. 15' Round Trip Loss Metrics (Al Morton) draft-morton-ippm-rt-loss-01 8. AOB Comments on draft-morton-bmwg-imix-genome-00.txt -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ I confirm today what I denied yesterday. Anonymous Politician. From Barry.Constantine@jdsu.com Wed Oct 27 12:37:29 2010 Return-Path: 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 2FB7F3A69C7 for ; Wed, 27 Oct 2010 12:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.034 X-Spam-Level: X-Spam-Status: No, score=-6.034 tagged_above=-999 required=5 tests=[AWL=0.565, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 zNfze8gY8aso for ; Wed, 27 Oct 2010 12:37:26 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with SMTP id 2DCC73A6910 for ; Wed, 27 Oct 2010 12:37:26 -0700 (PDT) Received: from source ([209.36.247.244]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTMh/5PS+txe+j61MCJTcvrqji7XNPBvZ@postini.com; Wed, 27 Oct 2010 12:39:16 PDT Received: from milexhtca1.ds.jdsu.net ([10.75.2.121]) by Outbound1.jdsu.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Oct 2010 12:37:08 -0700 Received: from MILEXCH1.ds.jdsu.net ([fe80::6444:f010:6d40:bdb]) by milexhtca1.ds.jdsu.net ([::1]) with mapi; Wed, 27 Oct 2010 12:37:08 -0700 From: Barry Constantine To: "ippm@ietf.org" Date: Wed, 27 Oct 2010 12:37:07 -0700 Thread-Topic: [ippm] I-D Action:draft-ietf-ippm-reporting-metrics-04.txt Thread-Index: Act0lLLl25Hp5BiaRniLMsBp0trXeABdiImg Message-ID: <94DEE80C63F7D34F9DC9FE69E39436BE38EB24AC76@MILEXCH1.ds.jdsu.net> References: <20101025223009.98FF63A68E8@core3.amsl.com> In-Reply-To: <20101025223009.98FF63A68E8@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Oct 2010 19:37:08.0692 (UTC) FILETIME=[57EC6140:01CB760E] Subject: Re: [ippm] I-D Action:draft-ietf-ippm-reporting-metrics-04.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 19:37:29 -0000 Hello, I had some time to review this work and found it interesting. Explaining t= he relationship of PDV from an RFC5481/3393 to Y.1540 is very useful. Also= , applying the ITU concept of availability is a good idea. Below are my comments: 4.1.2. It is difficult to specify what an application's threshold for dela= y is. Applications have many unknown behaviors and loss / delay is certain= ly one of them. I think the intent of this paragraph is good, but not sure= if it is practical. 4.2 Last sentence. Could not agree more with this point; satellite communi= cations is a classic example where error correction is used and it is highl= y desirable to know which packets were truly dropped versus ones that could= not be corrected. 5.1.1 Last paragraph. I had a hard time understanding the concept of the l= ast sentence and how it pertained to this section's theme. 5.2 For long term monitoring, the 95th percentile is considered one of key = value. It is mentioned in this section, but may be useful to expand on a l= ittle as was done for median (and why 95th percentile is useful versus maxi= mum). 7.3, section 2. There was a placeholder for equilibrium. Feel free to cop= y from the TCP framework draft if useful: "the equilibrium throughput refers to the maximum sustained rate obtained b= y congestion avoidance before packet loss conditions occur (which may cause= the state change from congestion avoidance to a retransmission phase)." "the equilibrium throughput reflects the maximum rate achieved by a TCP con= nection within the congestion avoidance phase on an end-end network path."= =20 7.4 last bullet. We defined a couple of useful metrics that you may want t= o consider adding here (TCP Efficiency and Buffer Delay %) also in the TCP = framework draft. 7.5 Variability, last two bullets. Plotting retransmissions and RTT during = the course of a BTC are excellent ways to understand causes of variability. I think this is a good work and I hope these comments are useful. Thanks, Barry -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Int= ernet-Drafts@ietf.org Sent: Monday, October 25, 2010 6:30 PM To: i-d-announce@ietf.org Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-reporting-metrics-04.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Performance Metrics Working Group of th= e IETF. Title : Reporting Metrics: Different Points of View Author(s) : A. Morton, et al. Filename : draft-ietf-ippm-reporting-metrics-04.txt Pages : 25 Date : 2010-10-25 Consumers of IP network performance metrics have many different uses in mind. The memo provides "long-term" reporting considerations (e.g, days, weeks or months, as opposed to 10 seconds), based on analysis of the two key audience points-of-view. It describes how the audience categories affect the selection of metric parameters and options when seeking info that serves their needs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-reporting-metrics-04.tx= t Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From acmorton@att.com Wed Oct 27 14:11:08 2010 Return-Path: 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 870993A6405 for ; Wed, 27 Oct 2010 14:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.536 X-Spam-Level: X-Spam-Status: No, score=-105.536 tagged_above=-999 required=5 tests=[AWL=0.260, 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 ZX86tJJHwB6y for ; Wed, 27 Oct 2010 14:11:00 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id 8B8D83A679F for ; Wed, 27 Oct 2010 14:10:58 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-8.tower-121.messagelabs.com!1288213966!33897244!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 11272 invoked from network); 27 Oct 2010 21:12:47 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-8.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Oct 2010 21:12:47 -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 o9RLC9iq021963 for ; Wed, 27 Oct 2010 17:12:09 -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 o9RLC5wR021885 for ; Wed, 27 Oct 2010 17:12:05 -0400 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klpd017.kcdc.att.com (8.14.4/8.14.4) with ESMTP id o9RLCg7v021824 for ; Wed, 27 Oct 2010 16:12:42 -0500 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by klpd017.kcdc.att.com (8.14.4/8.14.4) with ESMTP id o9RLCdVw021776 for ; Wed, 27 Oct 2010 16:12:39 -0500 Message-Id: <201010272112.o9RLCdVw021776@klpd017.kcdc.att.com> Received: from acmt.att.com (ds135-16-251-236.dhcps.ugn.att.com[135.16.251.236](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20101027211239gw100ei1hle>; Wed, 27 Oct 2010 21:12:39 +0000 X-Originating-IP: [135.16.251.236] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Oct 2010 17:13:03 -0400 To: Barry Constantine , "ippm@ietf.org" From: Al Morton In-Reply-To: <94DEE80C63F7D34F9DC9FE69E39436BE38EB24AC76@MILEXCH1.ds.jds u.net> References: <20101025223009.98FF63A68E8@core3.amsl.com> <94DEE80C63F7D34F9DC9FE69E39436BE38EB24AC76@MILEXCH1.ds.jdsu.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [ippm] I-D Action:draft-ietf-ippm-reporting-metrics-04.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 21:11:08 -0000 At 03:37 PM 10/27/2010, Barry Constantine wrote: >... >I think this is a good work and I hope these comments are useful. Thanks for your review, Barry, especially your comments in the new section 7 (Restricted Capacity). I'll reply with follow-up on the list when time permits, Al