From root@core3.amsl.com Thu Apr 8 12:15:17 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 09C063A6AE8; Thu, 8 Apr 2010 12:15:16 -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: <20100408191517.09C063A6AE8@core3.amsl.com> Date: Thu, 8 Apr 2010 12:15:17 -0700 (PDT) Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-twamp-session-cntrl-06.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, 08 Apr 2010 19:15:17 -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 : Individual Session Control Feature for TWAMP Author(s) : A. Morton, M. Chiba Filename : draft-ietf-ippm-twamp-session-cntrl-06.txt Pages : 18 Date : 2010-04-08 The IETF has completed its work on the core specification of TWAMP - the Two-Way Active Measurement Protocol. This memo describes an OPTIONAL feature for TWAMP, that gives the controlling host the ability to start and stop one or more individual test sessions using Session Identifiers. The base capability of the TWAMP protocol requires all test sessions previously requested and accepted to start and stop at the same time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-twamp-session-cntrl-06.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-twamp-session-cntrl-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-08121117.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Thu Apr 8 13:30:05 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 51E3B3A6A93; Thu, 8 Apr 2010 13:30:04 -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: <20100408203005.51E3B3A6A93@core3.amsl.com> Date: Thu, 8 Apr 2010 13:30:05 -0700 (PDT) Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-twamp-session-cntrl-07.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, 08 Apr 2010 20:30:05 -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 : Individual Session Control Feature for TWAMP Author(s) : A. Morton, M. Chiba Filename : draft-ietf-ippm-twamp-session-cntrl-07.txt Pages : 18 Date : 2010-04-08 The IETF has completed its work on the core specification of TWAMP - the Two-Way Active Measurement Protocol. This memo describes an OPTIONAL feature for TWAMP, that gives the controlling host the ability to start and stop one or more individual test sessions using Session Identifiers. The base capability of the TWAMP protocol requires all test sessions previously requested and accepted to start and stop at the same time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-twamp-session-cntrl-07.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-twamp-session-cntrl-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-08132747.I-D@ietf.org> --NextPart-- From wwwrun@rfc-editor.org Mon Apr 12 10:01:15 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 A15AA28C1D2; Mon, 12 Apr 2010 10:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 TSqJwALd78Nn; Mon, 12 Apr 2010 10:01:14 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id B643F28C146; Mon, 12 Apr 2010 09:55:00 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0A5C6E07BB; Mon, 12 Apr 2010 09:54:56 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20100412165456.0A5C6E07BB@rfc-editor.org> Date: Mon, 12 Apr 2010 09:54:56 -0700 (PDT) Cc: ippm@ietf.org, rfc-editor@rfc-editor.org Subject: [ippm] RFC 5835 on Framework for Metric Composition 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, 12 Apr 2010 17:01:15 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5835 Title: Framework for Metric Composition Author: A. Morton, Ed., S. Van den Berghe, Ed. Status: Informational Stream: IETF Date: April 2010 Mailbox: acmorton@att.com, steven.van_den_berghe@alcatel-lucent.com Pages: 38138 Characters: 38138 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ippm-framework-compagg-09.txt URL: http://www.rfc-editor.org/rfc/rfc5835.txt This memo describes a detailed framework for composing and aggregating metrics (both in time and in space) originally defined by the IP Performance Metrics (IPPM), RFC 2330, and developed by the IETF. This new framework memo describes the generic composition and aggregation mechanisms. The memo provides a basis for additional documents that implement the framework to define detailed compositions and aggregations of metrics that are useful in practice. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the IP Performance Metrics Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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 wwwrun@core3.amsl.com Mon Apr 12 10:23:33 2010 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 21EAE3A6A85; Mon, 12 Apr 2010 10:23:32 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100412172333.21EAE3A6A85@core3.amsl.com> Date: Mon, 12 Apr 2010 10:23:32 -0700 (PDT) Cc: Internet Architecture Board , ippm chair , ippm mailing list , RFC Editor Subject: [ippm] Protocol Action: 'Individual Session Control Feature for TWAMP' to Proposed Standard 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, 12 Apr 2010 17:23:34 -0000 The IESG has approved the following document: - 'Individual Session Control Feature for TWAMP ' as a Proposed Standard This document is the product of the IP Performance Metrics Working Group. The IESG contact person is Lars Eggert. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-twamp-session-cntrl-07.txt Technical Summary The IETF has completed its work on the core specification of TWAMP - the Two-Way Active Measurement Protocol. This memo describes a new feature for TWAMP, that gives the controlling host the ability to start and stop one or more individual test sessions using Session Identifiers. The base capability of the TWAMP protocol requires all test sessions previously requested and accepted to start and stop at the same time. Working Group Summary The normal WG process was followed and the document has been discussed for several years. The document as it is now, reflects WG consensus, with nothing special worth noticing. Personnel The document sheperd is Henk Uijterwaal (henk@ripe.net). Lars Eggert (lars.eggert@nokia.com) reviewed the document for the IESG. From mallman@icir.org Tue Apr 13 07:39:48 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 79B1A3A6A51 for ; Tue, 13 Apr 2010 07:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.261 X-Spam-Level: X-Spam-Status: No, score=-4.261 tagged_above=-999 required=5 tests=[AWL=-2.339, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, SUBJ_ALL_CAPS=2.077] 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 sl7RRv35G4Th for ; Tue, 13 Apr 2010 07:39:44 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 6505A28C1BC for ; Tue, 13 Apr 2010 07:39:31 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o3DEdPNS015988 for ; Tue, 13 Apr 2010 07:39:25 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 4E8D3D96AEB for ; Tue, 13 Apr 2010 10:39:25 -0400 (EDT) To: ippm@ietf.org From: Mark Allman Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Blue on Black MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma33306-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 13 Apr 2010 10:39:25 -0400 Sender: mallman@icir.org Message-Id: <20100413143925.4E8D3D96AEB@lawyers.icir.org> Subject: [ippm] IMC 2010 CFP X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 14:39:48 -0000 ----------ma33306-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [Folks- a quick reminder that the IMC deadline is coming up. Please do consider submitting. --allman (IMC 2010 PC chair)] Internet Measurement Conference (IMC) 2010 November 1 - 3, 2010 Melbourne, Australia The tenth Internet Measurement Conference is a three day event focusing on Internet measurement and analysis, building on the success of past IMCs. We invite submissions of papers that contribute to our understanding of the Internet's structure and behavior, as well as methods to collect or analyze Internet measurements. IMC accepts two kinds of papers: - Full papers (up to 14 two-column pages) describing original research, with succinctness appropriate to the topics and themes they discuss. - Short papers (up to 6 two-column pages for text and figures + 1 page for references) conveying work that is less mature but shows promise, articulating a high-level vision, describing challenging future directions, critiquing current measurement wisdom or offering results that do not merit a full submission. Key dates: - May 10, 2010: 8AM EDT: Registration of title and 250-word abstract - May 17, 2010: 8AM EDT: HARD submission deadline - July 28, 2010: Notification - November 1-3, 2010: Conference held in Melbourne, Australia Please see the full CFP here: http://conferences.sigcomm.org/imc/2010/cfp.html for full details. ----------ma33306-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkvEgh0ACgkQWyrrWs4yIs6P1QCfTM6sZJEN4+LS0unVq2eDY837 9UoAnja2Foby172JeRBAVXuuGedpkadP =O4hP -----END PGP SIGNATURE----- ----------ma33306-1-- From henk@ripe.net Wed Apr 14 03:02:14 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 907573A691C for ; Wed, 14 Apr 2010 03:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.125 X-Spam-Level: X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[AWL=-0.940, BAYES_40=-0.185] 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 t91SoCV3rImB for ; Wed, 14 Apr 2010 03:02:13 -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 D70473A68C1 for ; Wed, 14 Apr 2010 03:02:12 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.1.103]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1O1zQ0-0006cu-4I for ippm@ietf.org; Wed, 14 Apr 2010 12:02:05 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=geir.local) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1O1zPz-0004HD-Uk for ippm@ietf.org; Wed, 14 Apr 2010 12:02:00 +0200 Message-ID: <4BC59297.5080807@ripe.net> Date: Wed, 14 Apr 2010 12:01:59 +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.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: IETF IPPM WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d56afce58897ec09db33619e647c33dd2b X-RIPE-Spam-Level: ---- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d56afce58897ec09db33619e647c33dd2b Subject: [ippm] Fwd: WGLC for Spatial Composition of Metrics 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, 14 Apr 2010 10:02:14 -0000 IPPM group, This is a WGLC for the draft: Spatial Composition of Metrics This draft has been stable for a while and no issues have been raised. Publication of the framework draft does not require any changes to this document either. With the framework draft published as RFC 5835, we think that now is the time to start a WGLC on this draft. Please raise any remaining issues by Monday, May 10, 9:00 UTC. An URL for the draft is: http://datatracker.ietf.org/doc/draft-ietf-ippm-spatial-composition/ Note that the draft will expire during this LC. Authors, please submit a new version identical to the one that is there now. 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 ------------------------------------------------------------------------------ Nobody ever went broke underestimating the taste of the American public. H.L.Mencken From steve.baillargeon@videotron.ca Wed Apr 14 06:16: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 00E563A6AC0 for ; Wed, 14 Apr 2010 06:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.815 X-Spam-Level: X-Spam-Status: No, score=0.815 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457] 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 L1OAlB7uoX0k for ; Wed, 14 Apr 2010 06:16:04 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id A93D628C0E9 for ; Wed, 14 Apr 2010 06:15:47 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_Tlds5Z/6ioCWsT0+ylrcVg)" Received: from vl-mo-mpf01.ip.videotron.ca ([10.23.37.50]) by VL-MO-MR001.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug 3 2007; 32bit)) with ESMTP id <0L0V000SPBI4E030@VL-MO-MR001.ip.videotron.ca> for ippm@ietf.org; Wed, 14 Apr 2010 09:15:41 -0400 (EDT) Received: from videotron.ca (unknown [10.23.32.112]) by vl-mo-mpf01.ip.videotron.ca (Postfix) with ESMTP id 80235294080 for ; Wed, 14 Apr 2010 09:15:41 -0400 (EDT) Received: from [10.23.32.84] by VL-MO-MM004.ip.videotron.ca (mshttpd); Wed, 14 Apr 2010 15:15:41 +0200 From: steve.baillargeon@videotron.ca To: ippm@ietf.org Message-id: Date: Wed, 14 Apr 2010 15:15:41 +0200 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: en X-Accept-Language: en Priority: normal Subject: [ippm] Clarification on RFC5357 TWAMP Spec 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, 14 Apr 2010 13:22:59 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Tlds5Z/6ioCWsT0+ylrcVg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline Hi
 
In section 4.2, bottom of the page, the spec states "...The response MUST be generated as immediately as possible".
 
In section 4.2.1, first paragraph, the spec states "...The Session-Reflector SHOULD transmit the packets as immediately as possible".
 
I agree that a response MUST be generated for each received packet but can we leave the "immediate response" as a SHOULD? In other words, can we update the first statement and use a SHOULD in both sentences?
 
Thanks
Regards
Steve

--Boundary_(ID_Tlds5Z/6ioCWsT0+ylrcVg)-- From acmorton@att.com Wed Apr 14 06:53: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 D8C1A3A68BD for ; Wed, 14 Apr 2010 06:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.342 X-Spam-Level: X-Spam-Status: No, score=-105.342 tagged_above=-999 required=5 tests=[AWL=0.454, 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 zwfLXNEgrhnA for ; Wed, 14 Apr 2010 06:53:35 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 757863A6AF4 for ; Wed, 14 Apr 2010 06:53:04 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-3.tower-167.messagelabs.com!1271253176!20019482!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 26792 invoked from network); 14 Apr 2010 13:52:57 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-3.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Apr 2010 13:52:57 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o3EDqgX2031511 for ; Wed, 14 Apr 2010 09:52:42 -0400 Received: from klpd017.kcdc.att.com (klpd017.kcdc.att.com [135.188.40.86]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o3EDqcco031426 for ; Wed, 14 Apr 2010 09:52:39 -0400 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id o3EDqqWK015813 for ; Wed, 14 Apr 2010 08:52:52 -0500 Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id o3EDqlpH015733 for ; Wed, 14 Apr 2010 08:52:47 -0500 Message-Id: <201004141352.o3EDqlpH015733@klpd017.kcdc.att.com> Received: from acmt.att.com (dyp004254dys.mt.att.com[135.16.251.229](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100414135247gw100b8ihoe>; Wed, 14 Apr 2010 13:52:47 +0000 X-Originating-IP: [135.16.251.229] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 14 Apr 2010 09:51:54 -0400 To: steve.baillargeon@videotron.ca, ippm@ietf.org From: Al Morton In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [ippm] Clarification on RFC5357 TWAMP Spec 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, 14 Apr 2010 13:53:35 -0000 Steve, The requirement shouldn't be in two places, and use two different levels of requirement, so this might make a good Errata. It's definitely MUST for a response, and that's all over the memo. But "as immediately as possible" leaves a lot of wiggle-room and covers the unexpected to some degree. Al At 09:15 AM 4/14/2010, steve.baillargeon@videotron.ca wrote: >Hi > >In section 4.2, bottom of the page, the spec states "...The response >MUST be generated as immediately as possible". > >In section 4.2.1, first paragraph, the spec states "...The >Session-Reflector SHOULD transmit the packets as immediately as possible". > >I agree that a response MUST be generated for each received packet >but can we leave the "immediate response" as a SHOULD? In other >words, can we update the first statement and use a SHOULD in both sentences? > >Thanks >Regards >Steve > >_______________________________________________ >ippm mailing list >ippm@ietf.org >https://www.ietf.org/mailman/listinfo/ippm From acmorton@att.com Wed Apr 14 07:59:02 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 CE31A3A6942 for ; Wed, 14 Apr 2010 07:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.393 X-Spam-Level: X-Spam-Status: No, score=-105.393 tagged_above=-999 required=5 tests=[AWL=0.403, 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 4OTJfUvOHOUj for ; Wed, 14 Apr 2010 07:59:02 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 14A0A3A6767 for ; Wed, 14 Apr 2010 07:59:02 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-4.tower-120.messagelabs.com!1271257134!47409948!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 7049 invoked from network); 14 Apr 2010 14:58:55 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-4.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Apr 2010 14:58:55 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o3EEx6L7029259 for ; Wed, 14 Apr 2010 10:59:06 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o3EEx1PT029131 for ; Wed, 14 Apr 2010 10:59:01 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id o3EEwnL2019198 for ; Wed, 14 Apr 2010 10:58:49 -0400 Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.3/8.14.4) with ESMTP id o3EEwhgO018975 for ; Wed, 14 Apr 2010 10:58:43 -0400 Message-Id: <201004141458.o3EEwhgO018975@alpd052.aldc.att.com> Received: from acmt.att.com (dyp004254dys.mt.att.com[135.16.251.229](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100414145843gw100b8iife>; Wed, 14 Apr 2010 14:58:43 +0000 X-Originating-IP: [135.16.251.229] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 14 Apr 2010 10:57:48 -0400 To: Henk Uijterwaal , IETF IPPM WG From: Al Morton In-Reply-To: <4BC59297.5080807@ripe.net> References: <4BC59297.5080807@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [ippm] Fwd: WGLC for Spatial Composition of Metrics 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, 14 Apr 2010 14:59:02 -0000 At 06:01 AM 4/14/2010, Henk Uijterwaal wrote: >...An URL for the draft is: > > http://datatracker.ietf.org/doc/draft-ietf-ippm-spatial-composition/ > >Note that the draft will expire during this LC. Authors, please submit >a new version identical to the one that is there now. The new version is posted. Two references moved from I-D to RFC, so they were updated to avoid errors. Al From root@core3.amsl.com Wed Apr 14 08:00:02 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 4C3543A6942; Wed, 14 Apr 2010 08:00: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: <20100414150002.4C3543A6942@core3.amsl.com> Date: Wed, 14 Apr 2010 08:00:02 -0700 (PDT) Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-spatial-composition-11.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, 14 Apr 2010 15:00:02 -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 : Spatial Composition of Metrics Author(s) : A. Morton, E. Stephan Filename : draft-ietf-ippm-spatial-composition-11.txt Pages : 27 Date : 2010-04-14 This memo utilizes IPPM metrics that are applicable to both complete paths and sub-paths, and defines relationships to compose a complete path metric from the sub-path metrics with some accuracy w.r.t. the actual metrics. This is called Spatial Composition in RFC 2330. The memo refers to the Framework for Metric Composition, and provides background and motivation for combining metrics to derive others. The descriptions of several composed metrics and statistics follow. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-spatial-composition-11.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-spatial-composition-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-14075006.I-D@ietf.org> --NextPart-- From Donald.McLachlan@crc.ca Wed Apr 14 09:49:50 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 755E428C2A9 for ; Wed, 14 Apr 2010 09:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] 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 DQIjPfWg05lC for ; Wed, 14 Apr 2010 09:49:49 -0700 (PDT) Received: from mailgate01.crc.ca (mailgate01.crc.ca [142.92.160.36]) by core3.amsl.com (Postfix) with ESMTP id C4EB03A67EC for ; Wed, 14 Apr 2010 09:49:48 -0700 (PDT) Received: from mail01.crc.ca ([142.92.39.50]) by mailgate01.crc.ca (8.13.8/8.13.8) with ESMTP id o3EGnaCJ005054 for ; Wed, 14 Apr 2010 12:49:38 -0400 Received: from [142.92.34.101] (janus.dgrc.crc.ca [142.92.34.101]) by mail01.crc.ca (8.13.8/8.13.8) with ESMTP id o3EGnRAW026014; Wed, 14 Apr 2010 12:49:38 -0400 Message-ID: <4BC5F215.1050009@crc.ca> Date: Wed, 14 Apr 2010 12:49:25 -0400 From: Donald McLachlan User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.9.1.7) Gecko/20100115 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: ippm@ietf.org References: <4BC59297.5080807@ripe.net> In-Reply-To: <4BC59297.5080807@ripe.net> Content-Type: multipart/alternative; boundary="------------030404090205070708090201" X-Scanned-By: MIMEDefang 2.65 on 142.92.160.36 X-Scanned-By: MIMEDefang 2.65 on 142.92.39.50 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mailgate01.crc.ca [142.92.160.36]); Wed, 14 Apr 2010 12:49:40 -0400 (EDT) Subject: Re: [ippm] Fwd: WGLC for Spatial Composition of Metrics 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, 14 Apr 2010 16:49:50 -0000 This is a multi-part message in MIME format. --------------030404090205070708090201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Henk et al, Below are the comments I provided to Al Morton (slightly edited and minus 1 comment) on version 10 of the draft. Don -------- Original Message -------- Subject: Re: http://tools.ietf.org/wg/ippm/draft-ietf-ippm-spatial-composition/ Date: Tue, 06 Apr 2010 16:44:46 -0400 From: Donald McLachlan To: Al Morton Hi Al, I hope (at least some of) the following comments are useful. Don Section 2.1. First sentence. It reads: [...] between the source and the destination of the interest. Should it maybe read: [...] between the source and the destination of interest. Section 3.1. 4'th bullet. Ref to possible future work of another working group. Thus inaccessible to the reader. ... Section 4.1.8.1, Section 5.2.6 (and possibly others.) Question. Is it possible that (e.g. policy based routing or MPLS) could put pkts from A to C into different priority queues, than it would put pkts from A to B and from B to C, thus invalidating the composite metric results? Section 4.1.9. I don't like the example given. In the example given I expect any change in one-way delay is more likely due to the time taken for the (possibly heavily loaded) CPU to encrypt/decrypt the packets than just due to the change in the length of the packet. Not only that, but IMO, encrypting changes the definition of packets of type-P. While it would be mundane, I think saying ping (or OWAMP) packets of length L1 versus ping (or OWAMP) packets of L2 is a better example of packets of different length. Section 4.1.10. Should "similar" be quantified. E.g. same DCSP, proto, similar length, encryption, etc? Otherwise might DPI or policy affect routing or queuing, etc? Section 5.2 (or all of "chapter" 5) Poisson vs. Periodic streams. Question. While I understand the theoretical differences with using Poisson versus Periodic streams. In practice, has anyone ever measured one-way delay across an Internet path with both stream types and obtained statistically similar/different results? Is this chapter proposing that one can perform Poisson OWD measurements on one sub-path and periodic OWD measurements on a second sub-path and combine them to form a sane composite full-path metric? If so, that should be more clearly stated. If not, that should be stated. Section 5.2.6. Maybe replace bi-modal with multi-modal? Section 5.2.9. Even if the sub-path distribution is (multi) modal, if the sub-path is part of the real path, wouldn't the sample delays on the full path be subject to the same (multi-)modal delays of the sub-path? In which case is this really an issue? Section 6.1.4. Question. Would it also be possible to use a similar method to measure sub-path burst lost length, and combine them to obtain an empirical loss-length probability? Section 7.1.1, third bullet. Not only length in bits, but Type-P, the definition of which should maybe include DCSP, proto, src port, dst port, encryption, etc. IMO, anything which might change how the packet might be handled by routers along the path should be specified. Maybe this comment should be applied to Section 4.1.1 instead, and would thus covered by the first sentence of this Section, "In addtion to the parameters of section 4.1.1:". Section 7.1.1, fourth bullet. Section 7.1 says Type-P-One-way-pdv-refmin-Poisson/Periodic-Stream. This bullet refers to packet pairs - which is IPDV. If what is intended is IPDV, then the idea of min delay does not apply. If what is intended is PDV, then packet pairs does not apply. Assuming what is wanted is PDV, might I suggest: F, a selection function unambiguously defining the packets from the stream that are selected for the computation of this metric. F(packet), MUST have a valid Type-P-Finite-One-way-Delay less than Tmax (in other words, excluding packets which have undefined one-way delay) and MUST have been transmitted during the interval T, Tf. F(min_packet) MUST be the packet with the minimum valid value of Type-P-Finite-One-way-Delay for the stream, in addition to the criteria for F(packet). If multiple packets have equal minimum Type-P-Finite-One-way-Delay values, then the value for the earliest arriving packet SHOULD be used. Section 7.1.4, last sentence. Doesn't the PDV applicability statement speak of %-iles, or P.99? Was it a conscious decision to change the nomenclature to Quantile? (That said I prefer Quantile over %-ile and P.99). --------------030404090205070708090201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Henk et al,

Below are the comments I provided to Al Morton (slightly edited and minus 1 comment) on version 10 of the draft.

Don


-------- Original Message --------
Subject: Re: http://tools.ietf.org/wg/ippm/draft-ietf-ippm-spatial-composition/
Date: Tue, 06 Apr 2010 16:44:46 -0400
From: Donald McLachlan <Donald.McLachlan@crc.ca>
To: Al Morton <acmorton@att.com> 


Hi Al,

I hope (at least some of) the following comments are useful.

Don


Section 2.1.  First sentence. It reads:
   [...] between the source and the destination of the interest.
Should it maybe read:
   [...] between the source and the destination of interest.

Section 3.1.  4'th bullet.  Ref to possible future work of another 
working group.  Thus inaccessible to the reader. ...

Section 4.1.8.1, Section 5.2.6 (and possibly others.)  Question. Is it 
possible that (e.g. policy based routing or MPLS) could put pkts from A 
to C into different priority queues, than it would put pkts from A to B 
and from B to C, thus invalidating the composite metric results?

Section 4.1.9.  I don't like the example given.  In the example given I 
expect any change in one-way delay is more likely due to the time taken 
for the (possibly heavily loaded) CPU to encrypt/decrypt the packets 
than just due to the change in the length of the packet.  Not only that, 
but IMO, encrypting changes the definition of packets of type-P.  While 
it would be mundane, I think saying ping (or OWAMP) packets of length L1 
versus ping (or OWAMP) packets of L2 is a better example of packets of
different length.

Section 4.1.10. Should "similar" be quantified.  E.g. same DCSP, proto, 
similar length, encryption, etc?  Otherwise might DPI or policy affect 
routing or queuing, etc?

Section 5.2 (or all of "chapter" 5) Poisson vs. Periodic streams. 
Question.  While I understand the theoretical differences with using 
Poisson versus Periodic streams.  In practice, has anyone ever measured 
one-way delay across an Internet path with both stream types and 
obtained statistically similar/different results? Is this chapter 
proposing that one can perform Poisson OWD measurements on one sub-path 
and periodic OWD measurements on a second sub-path and combine them to 
form a sane composite full-path metric?  If so, that should be more 
clearly stated.  If not, that should be stated.

Section 5.2.6.  Maybe replace bi-modal with multi-modal?

Section 5.2.9. Even if the sub-path distribution is (multi) modal, if 
the sub-path is part of the real path, wouldn't the sample delays on the 
full path be subject to the same (multi-)modal delays of the sub-path?  
In which case is this really an issue?

Section 6.1.4.  Question.  Would it also be possible to use a similar 
method to measure sub-path burst lost length, and combine them to obtain 
an empirical loss-length probability?

Section 7.1.1, third bullet.  Not only length in bits, but Type-P, the 
definition of which should maybe include DCSP, proto, src port, dst 
port, encryption, etc.  IMO, anything which might change how the packet 
might be handled by routers along the path should be specified.  Maybe 
this comment should be applied to Section 4.1.1 instead, and would thus 
covered by the first sentence of this Section, "In addtion to the 
parameters of section 4.1.1:".

Section 7.1.1, fourth bullet. Section 7.1 says 
Type-P-One-way-pdv-refmin-Poisson/Periodic-Stream.  This bullet refers 
to packet pairs - which is IPDV.  If what is intended is IPDV, then the 
idea of min delay does not apply.  If what is intended is PDV, then 
packet pairs does not apply.

Assuming what is wanted is PDV, might I suggest:

F, a selection function unambiguously defining the packets from
     the stream that are selected for the computation of
     this metric.  F(packet), MUST
     have a valid Type-P-Finite-One-way-Delay less than Tmax (in other
     words, excluding packets which have undefined one-way delay) and
     MUST have been transmitted during the interval T, Tf.  F(min_packet) MUST be the packet with the
     minimum valid value of Type-P-Finite-One-way-Delay for the stream,
     in addition to the criteria for F(packet).  If multiple
     packets have equal minimum Type-P-Finite-One-way-Delay values,
     then the value for the earliest arriving packet SHOULD be used.


Section 7.1.4, last sentence.  Doesn't the PDV applicability statement 
speak of %-iles, or P.99?  Was it a conscious decision to change the 
nomenclature to Quantile?  (That said I prefer Quantile over %-ile and P.99).

--------------030404090205070708090201-- From Donald.McLachlan@crc.ca Wed Apr 14 10:30: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 0DD5B28C0F2 for ; Wed, 14 Apr 2010 10:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 F-5z4-S204Yu for ; Wed, 14 Apr 2010 10:30:45 -0700 (PDT) Received: from mailgate01.crc.ca (mailgate01.crc.ca [142.92.160.36]) by core3.amsl.com (Postfix) with ESMTP id B3D1F28C1C9 for ; Wed, 14 Apr 2010 10:30:30 -0700 (PDT) Received: from mail01.crc.ca ([142.92.39.50]) by mailgate01.crc.ca (8.13.8/8.13.8) with ESMTP id o3EHUMDb010664 for ; Wed, 14 Apr 2010 13:30:23 -0400 Received: from [142.92.34.101] (janus.dgrc.crc.ca [142.92.34.101]) by mail01.crc.ca (8.13.8/8.13.8) with ESMTP id o3EHUOVM032744; Wed, 14 Apr 2010 13:30:24 -0400 Message-ID: <4BC5FBAD.2090908@crc.ca> Date: Wed, 14 Apr 2010 13:30:21 -0400 From: Donald McLachlan User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.9.1.7) Gecko/20100115 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: ippm@ietf.org Content-Type: multipart/alternative; boundary="------------070301010206090900060506" X-Scanned-By: MIMEDefang 2.65 on 142.92.160.36 X-Scanned-By: MIMEDefang 2.65 on 142.92.39.50 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mailgate01.crc.ca [142.92.160.36]); Wed, 14 Apr 2010 13:30:24 -0400 (EDT) Subject: Re: [ippm] http://tools.ietf.org/html/draft-ietf-ippm-reporting-metrics-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: Wed, 14 Apr 2010 17:30:46 -0000 This is a multi-part message in MIME format. --------------070301010206090900060506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline All, Below are some comments on http://tools.ietf.org/html/draft-ietf-ippm-reporting-metrics-01 which I previously provided by e-mail to Al Morton. Don -------- Original Message -------- Subject: Re: IETF Anaheim. Date: Tue, 30 Mar 2010 11:51:08 -0400 From: Donald McLachlan To: Al Morton I've given http://tools.ietf.org/html/draft-ietf-ippm-reporting-metrics-01 a preliminary read. I will re-read it later but here are some initial comments. Re: section 4.1.3. For all sorts of reasons (listed in "PDV" RFC) I find PDV a much more useful metric than IPDV, and any/all received packets are then valid, unlike the IPDV if/when every second packet is lost, no measurements pairs are valid. Thus I wonder whether it isn't better to remove IPDV from this doc and just mention PDV? Re: section 4.2. should/could it also report the mode (or modes if there are multiple equal peaks.) Should/could it also report several PDF percentile values. Re: section 5. Raw vs. Restricted Capacity. The document (vis-a-vis data uniqueness) implies, but does not state, that results from TCP tests report values closer to the Restricted Capacity capacity because TCP only returns 1 copy of duplicate data to the application layer. Whereas UDP tests (esp with checksums disabled) report values closer to Raw Capacity. Re: section 7.2. Re: temporal aggregation. It might be worth noting to avoid possible synchronisation with network events by randomising the start times. e.g. if one started 20 second tests once every 10 minutes via cron, it could sync with other periodic "top of the minute" load and bias the results. Automated tests should start on pseudo-random (Poisson-like?) start times. Then the aggregate should more correctly reflect reality. All for now, Don --------------070301010206090900060506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
All,

Below are some comments on http://tools.ietf.org/html/draft-ietf-ippm-reporting-metrics-01 which I  previously provided by e-mail to Al Morton.

Don


-------- Original Message --------
Subject: Re: IETF Anaheim.
Date: Tue, 30 Mar 2010 11:51:08 -0400
From: Donald McLachlan <Donald.McLachlan@crc.ca>
To: Al Morton <acmorton@att.com> 


I've given 
http://tools.ietf.org/html/draft-ietf-ippm-reporting-metrics-01 a 
preliminary read.  I will re-read it later but here are some initial 
comments.

Re: section 4.1.3.  For all sorts of reasons (listed in "PDV" RFC) I 
find PDV a much more useful metric than IPDV, and any/all received 
packets are then valid, unlike the IPDV if/when every second packet is 
lost, no measurements pairs are valid.  Thus I wonder whether it isn't 
better to remove IPDV from this doc and just mention PDV?

Re: section 4.2. <begin edit> should/could it also report the mode (or modes if there are 
multiple equal peaks.)  Should/could it
also report several PDF percentile values. <end edit>

Re: section 5. Raw vs. Restricted Capacity.  The document (vis-a-vis 
data uniqueness) implies, but does not state, that results from TCP 
tests report values closer to the Restricted Capacity capacity because 
TCP only returns 1 copy of duplicate data to the application layer. 
Whereas UDP tests (esp with checksums disabled) report values closer to 
Raw Capacity.

Re: section 7.2. Re: temporal aggregation.  It might be worth noting to 
avoid possible synchronisation with network events by randomising the 
start times.  e.g. if one started 20 second tests once every 10 minutes 
via cron, it could sync with other periodic "top of the minute" load and 
bias the results.  Automated tests should start on pseudo-random
(Poisson-like?) start times.  Then the aggregate should more correctly 
reflect reality.

All for now,
Don
--------------070301010206090900060506-- From root@core3.amsl.com Fri Apr 16 04:30:02 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 DD48F3A6B52; Fri, 16 Apr 2010 04: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: <20100416113001.DD48F3A6B52@core3.amsl.com> Date: Fri, 16 Apr 2010 04:30:01 -0700 (PDT) Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-00.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: Fri, 16 Apr 2010 11:30:02 -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 : TCP Throughput Testing Methodology Author(s) : B. Constantine, et al. Filename : draft-ietf-ippm-tcp-throughput-tm-00.txt Pages : 18 Date : 2010-04-16 This memo describes a methodology for measuring sustained TCP throughput performance in an end-to-end managed network environment. This memo is intended to provide a practical approach to help users validate the TCP layer performance of a managed network, which should provide a better indication of end-user application level experience. In the methodology, various TCP and network parameters are identified that should be tested as part of the network verification at the TCP layer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-tcp-throughput-tm-00.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-tcp-throughput-tm-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-16042204.I-D@ietf.org> --NextPart-- From steve.baillargeon@videotron.ca Sun Apr 18 10:25:20 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 9B9553A6A88 for ; Sun, 18 Apr 2010 10:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.861 X-Spam-Level: X-Spam-Status: No, score=0.861 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_50=0.001, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457] 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 XExwoACXUmRW for ; Sun, 18 Apr 2010 10:25:19 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id CDA9B3A6925 for ; Sun, 18 Apr 2010 10:25:19 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_bePqRBiBT5A1wmvAtCcwfQ)" Received: from vl-mo-mpf01.ip.videotron.ca ([10.23.37.50]) by VL-MO-MR004.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0L13003LY1PZUU70@VL-MO-MR004.ip.videotron.ca> for ippm@ietf.org; Sun, 18 Apr 2010 13:25:11 -0400 (EDT) Received: from videotron.ca (unknown [10.23.32.114]) by vl-mo-mpf01.ip.videotron.ca (Postfix) with ESMTP id 5A7FF294080 for ; Sun, 18 Apr 2010 13:25:11 -0400 (EDT) Received: from [10.23.32.86] by VL-MH-MM002.ip.videotron.ca (mshttpd); Sun, 18 Apr 2010 19:25:11 +0200 From: steve.baillargeon@videotron.ca To: ippm@ietf.org Message-id: Date: Sun, 18 Apr 2010 19:25:11 +0200 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: en X-Accept-Language: en Priority: normal Subject: [ippm] Comments for draft-ietf-ippm-twamp-reflect-octets-04 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, 18 Apr 2010 17:25:20 -0000 This is a multi-part message in MIME format. --Boundary_(ID_bePqRBiBT5A1wmvAtCcwfQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline

Hi Al

 

The last paragraph in draft-ietf-ippm-twamp-reflect-octets-04 section 3.1 is currently written as follows:

 

If the Control-Client intends to operate all test sessions invoked with this control connection using one or both of the new modes, it MUST set the Modes Field bit corresponding to that function in the Setup Response message.

 

I have two comments on this paragraph:

 

  • I believe you should replace the word Modes Field with Mode Field. The Modes Field is for the server greeting message and the Mode Field is for the Setup Response message.
  • In the OWAMP/TWAMP specs, it is stated that the client MUST respond with a Setup Response message with includes the Mode Field and one or zero bits MUST be set within last three bits.  In the new draft, you have stated that the last 7 bit positions of the Modes 32-bit Field are used but I think you have omitted to indicate that multiple bits can now be set in the Mode field sent by the client in the Setup Response message. I think it is best to explicitly state that multiple bits can now be set in the Mode field but not all possible combinations are possible.

 

Thank you

 

-Steve

--Boundary_(ID_bePqRBiBT5A1wmvAtCcwfQ)-- From henk@ripe.net Mon Apr 19 01:38: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 386143A6900 for ; Mon, 19 Apr 2010 01:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.776 X-Spam-Level: X-Spam-Status: No, score=-0.776 tagged_above=-999 required=5 tests=[AWL=-0.777, BAYES_50=0.001] 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 yQrhlLRx231D for ; Mon, 19 Apr 2010 01:38:07 -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 513073A68C8 for ; Mon, 19 Apr 2010 01:38:05 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.1.103]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1O3mUG-0007ov-Gu for ippm@ietf.org; Mon, 19 Apr 2010 10:37:55 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=guest-85.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1O3mUG-0007vc-C0; Mon, 19 Apr 2010 10:37:48 +0200 Message-ID: <4BCC165C.2060005@ripe.net> Date: Mon, 19 Apr 2010 10:37:48 +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.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Henk Uijterwaal References: <4BAAA36C.2010805@ripe.net> In-Reply-To: <4BAAA36C.2010805@ripe.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d53c7fd7095f908a2380c936fb32121b7c X-RIPE-Spam-Level: ---- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d53c7fd7095f908a2380c936fb32121b7c Cc: IETF IPPM WG Subject: Re: [ippm] WGLC for draft 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, 19 Apr 2010 08:38:08 -0000 IPPM Group, > This is a WGLC for the draft: TWAMP Reflect Octets and Symmetrical Size > Features > > The draft appears to to be stable and no issues have been raised. We > like to > start a WGLC in order to move it forward. Please raise any remaining > issues by > Monday, April 19, 9:00 UTC > > An URL for the draft is: > > http://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-reflect-octets/ There was one comment (from Steve Baillargeon) on this draft. I think his comments can be addressed by the authors without further discussion. As soon as that is done, we'll send the draft to the IESG. 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 ------------------------------------------------------------------------------ Nobody ever went broke underestimating the taste of the American public. H.L.Mencken From acmorton@att.com Mon Apr 19 08:26:26 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 4A31428C16F for ; Mon, 19 Apr 2010 08:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.737 X-Spam-Level: X-Spam-Status: No, score=-104.737 tagged_above=-999 required=5 tests=[AWL=-0.399, 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 8gIFxDxbkfLT for ; Mon, 19 Apr 2010 08:26:25 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id 48B2B28C19B for ; Mon, 19 Apr 2010 08:12:31 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-6.tower-121.messagelabs.com!1271689941!32338787!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 6710 invoked from network); 19 Apr 2010 15:12:21 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-6.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Apr 2010 15:12:21 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o3JFC69S018541 for ; Mon, 19 Apr 2010 11:12:06 -0400 Received: from klpd017.kcdc.att.com (klpd017.kcdc.att.com [135.188.40.86]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o3JFC07k018363 for ; Mon, 19 Apr 2010 11:12:00 -0400 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id o3JFCEQe031383 for ; Mon, 19 Apr 2010 10:12:14 -0500 Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id o3JFC9AF031245 for ; Mon, 19 Apr 2010 10:12:09 -0500 Message-Id: <201004191512.o3JFC9AF031245@klpd017.kcdc.att.com> Received: from acmt.att.com (dyp004254dys.mt.att.com[135.16.251.229](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100419151209gw100b8i42e>; Mon, 19 Apr 2010 15:12:09 +0000 X-Originating-IP: [135.16.251.229] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 19 Apr 2010 11:11:02 -0400 To: steve.baillargeon@videotron.ca, ippm@ietf.org From: Al Morton In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Subject: Re: [ippm] Comments for draft-ietf-ippm-twamp-reflect-octets-04 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, 19 Apr 2010 15:26:26 -0000 At 01:25 PM 4/18/2010, steve.baillargeon@videotron.ca wrote:
...
  • ...I think it is best to explicitly state that multiple bits can now be set in the Mode field but not all possible combinations are possible.

OK. 

Will post the requested changes, and try to anticipate some
IESG and IANA comments thanks to experience with the Individual Session
control draft.

Al


From root@core3.amsl.com Tue Apr 20 07:00:02 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 362A628C11D; Tue, 20 Apr 2010 07:00:02 -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: <20100420140002.362A628C11D@core3.amsl.com> Date: Tue, 20 Apr 2010 07:00:02 -0700 (PDT) Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-twamp-reflect-octets-05.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: Tue, 20 Apr 2010 14:00:02 -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 : TWAMP Reflect Octets and Symmetrical Size Features Author(s) : A. Morton, L. Ciavattone Filename : draft-ietf-ippm-twamp-reflect-octets-05.txt Pages : 19 Date : 2010-04-20 The IETF has completed its work on the core specification of TWAMP - the Two-Way Active Measurement Protocol. This memo describes two closely-related features for TWAMP: an optional capability where the responder host returns some of the command octets or padding octets to the controller, and an optional sender packet format that ensures equal test packet sizes are used in both directions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-twamp-reflect-octets-05.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-twamp-reflect-octets-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-20065545.I-D@ietf.org> --NextPart-- From matt@internet2.edu Fri Apr 23 12:46:18 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 6975B3A6ADC for ; Fri, 23 Apr 2010 12:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 kuMhG+yKsedf for ; Fri, 23 Apr 2010 12:46:17 -0700 (PDT) Received: from magus.merit.edu (magus.merit.edu [198.108.1.13]) by core3.amsl.com (Postfix) with ESMTP id D2BFC3A6ADB for ; Fri, 23 Apr 2010 12:46:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by magus.merit.edu (Postfix) with ESMTP id 1EE7C225A55 for ; Fri, 23 Apr 2010 15:46:03 -0400 (EDT) X-Virus-Scanned: amavisd-new at magus.merit.edu Received: from magus.merit.edu ([127.0.0.1]) by localhost (magus.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCnFb08Ixezd for ; Fri, 23 Apr 2010 15:46:02 -0400 (EDT) Received: from matt.local (ool-4357e3cf.dyn.optonline.net [67.87.227.207]) (Authenticated sender: matt@internet2.edu) by magus.merit.edu (Postfix) with ESMTP id 87DAE225A3F for ; Fri, 23 Apr 2010 15:46:02 -0400 (EDT) Message-ID: <4BD1F8FA.5040105@internet2.edu> Date: Fri, 23 Apr 2010 15:46:02 -0400 From: Matthew J Zekauskas User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: IETF IPPM WG X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [ippm] Minutes for IPPM session at IETF 77 uploaded 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, 23 Apr 2010 19:46:18 -0000 The minutes for IPPM at IETF 77 have been uploaded to the materials page, and you can find them along with the presentations here: The audio recording for this session is at . Please let the list or the Chairs know if you have any corrections to the minutes. --Matt From steve.baillargeon@videotron.ca Mon Apr 26 09:21:54 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 E02E328C195 for ; Mon, 26 Apr 2010 09:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.065 X-Spam-Level: ** X-Spam-Status: No, score=2.065 tagged_above=-999 required=5 tests=[AWL=-1.436, BAYES_99=3.5, HTML_MESSAGE=0.001] 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 rmWA9ZVRxcFG for ; Mon, 26 Apr 2010 09:21:53 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id 371A628C18A for ; Mon, 26 Apr 2010 09:21:34 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_NEJL3a72RdguL2k8r4BKBg)" Received: from vl-mo-mpf01.ip.videotron.ca ([10.23.37.50]) by VL-MO-MR002.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0L1H005LFS3L3O50@VL-MO-MR002.ip.videotron.ca> for ippm@ietf.org; Mon, 26 Apr 2010 12:21:22 -0400 (EDT) Received: from videotron.ca (unknown [10.23.32.117]) by vl-mo-mpf01.ip.videotron.ca (Postfix) with ESMTP id E6DFD29407E for ; Mon, 26 Apr 2010 12:21:21 -0400 (EDT) Received: from [10.23.32.88] by VL-MH-MM004.ip.videotron.ca (mshttpd); Mon, 26 Apr 2010 12:21:21 -0400 From: steve.baillargeon@videotron.ca To: ippm@ietf.org Message-id: Date: Mon, 26 Apr 2010 12:21:21 -0400 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: en X-Accept-Language: en Priority: normal Subject: [ippm] Comments for draft-ietf-ippm-twamp-reflect-octets-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, 26 Apr 2010 16:21:54 -0000 This is a multi-part message in MIME format. --Boundary_(ID_NEJL3a72RdguL2k8r4BKBg) Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable Content-disposition: inline Hi Al Here are some comments on the latest draft=2E =3C!-- /* Style Definitions */ p=2EMsoNormal=2C li=2EMsoNormal=2C div= =2EMsoNormal =7Bmso-style-parent=3A=22=22=3B margin=3A0in=3B margin-b= ottom=3A=2E0001pt=3B mso-pagination=3Awidow-orphan=3B font-size=3A12=2E= 0pt=3B font-family=3A=22Times New Roman=22=3B mso-fareast-font-family=3A= =22Times New Roman=22=3B mso-bidi-language=3AHE=3B=7D =40page Section1 = =7Bsize=3A8=2E5in 11=2E0in=3B margin=3A1=2E0in 1=2E25in 1=2E0in 1=2E25= in=3B mso-header-margin=3A=2E5in=3B mso-footer-margin=3A=2E5in=3B mso= -paper-source=3A0=3B=7D div=2ESection1 =7Bpage=3ASection1=3B=7D --=3E = - It will be best to explicitly indicate that both the control and test= protocols can reflect octets in an independent manner even if it is ind= irectly stated in the introduction=2E - The definition for the =93Serve= r octets=94 field shall indicate where those bits should appear in the P= acket Padding (to be reflected) field=2E - The spec should state that a= zero value in the =93Server octets=94 field means the Server does not d= esire these octets to be reflected=2E - The spec should state that a no= n-zero value in the =93Server octets=94 field means the Server desires t= hese octets to be reflected=2E The actual position of these octets in th= e padding octets of the test packets shall be clarified=2E - A defintio= n for Client octets field should be provided and indicates that is the e= qual to Octets to be reflected field (from Request-TW-Session)=2E - Th= e spec should indicate when the Client octets field shall appear in the = Packet Padding (to be reflected) field=2E Based on the example provided=2C= it looks like the usage of this field is optional and/or implementation= -specific when reflecting octets in test packets=2E If so=2C please indi= cate it=2E = Thank you Regards Steve Baillargeon --Boundary_(ID_NEJL3a72RdguL2k8r4BKBg) Content-type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable Content-disposition: inline Hi Al=3Cbr=3EHere are some comments on the latest draft=2E=3Cbr=3E=3Cbr=3E= =3Cmeta http-equiv=3D=22Content-Type=22 content=3D=22text/html=3B charse= t=3Dutf-8=22=3E=3Cmeta name=3D=22ProgId=22 content=3D=22Word=2EDocument=22= =3E=3Cmeta name=3D=22Generator=22 content=3D=22Microsoft Word 11=22=3E=3C= meta name=3D=22Originator=22 content=3D=22Microsoft Word 11=22=3E=3Clink= rel=3D=22File-List=22 href=3D=22file=3A///D=3A=255CProfiles=255CSTEEVE=25= 5CLOCALS=257E1=255CTemp=255Cmsohtml1=255C01=255Cclip=5Ffilelist=2Exml=22= =3E=3C!--=5Bif gte mso 9=5D=3E=3Cxml=3E =3Cw=3AWordDocument=3E =3Cw=3A= View=3ENormal=3C/w=3AView=3E =3Cw=3AZoom=3E0=3C/w=3AZoom=3E =3Cw=3AP= unctuationKerning/=3E =3Cw=3AValidateAgainstSchemas/=3E =3Cw=3ASaveI= fXMLInvalid=3Efalse=3C/w=3ASaveIfXMLInvalid=3E =3Cw=3AIgnoreMixedConte= nt=3Efalse=3C/w=3AIgnoreMixedContent=3E =3Cw=3AAlwaysShowPlaceholderTe= xt=3Efalse=3C/w=3AAlwaysShowPlaceholderText=3E =3Cw=3ACompatibility=3E= =3Cw=3ABreakWrappedTables/=3E =3Cw=3ASnapToGridInCell/=3E =3Cw= =3AWrapTextWithPunct/=3E =3Cw=3AUseAsianBreakRules/=3E =3Cw=3ADont= GrowAutofit/=3E =3C/w=3ACompatibility=3E =3Cw=3ABrowserLevel=3EMicro= softInternetExplorer4=3C/w=3ABrowserLevel=3E =3C/w=3AWordDocument=3E =3C= /xml=3E=3C!=5Bendif=5D--=3E=3C!--=5Bif gte mso 9=5D=3E=3Cxml=3E =3Cw=3A= LatentStyles DefLockedState=3D=22false=22 LatentStyleCount=3D=22156=22=3E= =3C/w=3ALatentStyles=3E =3C/xml=3E=3C!=5Bendif=5D--=3E=3Cstyle=3E =3C!= -- /* Style Definitions */ p=2EMsoNormal=2C li=2EMsoNormal=2C div=2EMs= oNormal =7Bmso-style-parent=3A=22=22=3B margin=3A0in=3B margin-bottom= =3A=2E0001pt=3B mso-pagination=3Awidow-orphan=3B font-size=3A12=2E0pt=3B= font-family=3A=22Times New Roman=22=3B mso-fareast-font-family=3A=22T= imes New Roman=22=3B mso-bidi-language=3AHE=3B=7D =40page Section1 =7B= size=3A8=2E5in 11=2E0in=3B margin=3A1=2E0in 1=2E25in 1=2E0in 1=2E25in=3B= mso-header-margin=3A=2E5in=3B mso-footer-margin=3A=2E5in=3B mso-pape= r-source=3A0=3B=7D div=2ESection1 =7Bpage=3ASection1=3B=7D --=3E =3C/st= yle=3E=3C!--=5Bif gte mso 10=5D=3E =3Cstyle=3E /* Style Definitions */ = table=2EMsoNormalTable =7Bmso-style-name=3A=22Table Normal=22=3B mso-= tstyle-rowband-size=3A0=3B mso-tstyle-colband-size=3A0=3B mso-style-no= show=3Ayes=3B mso-style-parent=3A=22=22=3B mso-padding-alt=3A0in 5=2E4= pt 0in 5=2E4pt=3B mso-para-margin=3A0in=3B mso-para-margin-bottom=3A=2E= 0001pt=3B mso-pagination=3Awidow-orphan=3B font-size=3A10=2E0pt=3B fo= nt-family=3A=22Times New Roman=22=3B mso-ansi-language=3A=230400=3B ms= o-fareast-language=3A=230400=3B mso-bidi-language=3A=230400=3B=7D =3C/s= tyle=3E =3C!=5Bendif=5D--=3E =3Cp class=3D=22MsoNormal=22=3E- It will b= e best to explicitly indicate that both the control and test protocols c= an reflect octets in an independent manner even if it is indirectly stat= ed in the introduction=2E=3C/p=3E =3Cp class=3D=22MsoNormal=22=3E- The = definition for the =93Server octets=94 field shall indicate where those = bits should appear in the Packet Padding (to be reflected) field=2E=3C/p= =3E =3Cp class=3D=22MsoNormal=22=3E- The spec should state that a zero = value in the =93Server octets=94 field means the Server does not desire = these octets to be reflected=2E=3C/p=3E =3Cp class=3D=22MsoNormal=22=3E= - The spec should state that a non-zero value in the =93Server octets=94= field means the Server desires these octets to be reflected=2E The actu= al position of these octets in the padding octets of the test packets sh= all be clarified=2E=3C/p=3E =3Cp class=3D=22MsoNormal=22=3E- A defintio= n for Client octets field should be provided and indicates that is the e= qual to Octets to be reflected field (from Request-TW-Session)=2E =3C/p=3E= =3Cp class=3D=22MsoNormal=22=3E- The spec should indicate when the Cli= ent octets field shall appear in the Packet Padding (to be reflected) fi= eld=2E Based on the example provided=2C it looks like the usage of this = field is optional and/or implementation-specific when reflecting octets = in test packets=2E If so=2C please indicate it=2E=3C/p=3E =3Cbr=3EThank= you=3Cbr=3E=3Cbr=3ERegards=3Cbr=3ESteve Baillargeon=3Cbr=3E --Boundary_(ID_NEJL3a72RdguL2k8r4BKBg)-- From acmorton@att.com Mon Apr 26 09:26:24 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 975D928C183 for ; Mon, 26 Apr 2010 09:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.433 X-Spam-Level: X-Spam-Status: No, score=-105.433 tagged_above=-999 required=5 tests=[AWL=0.363, 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 91jm0D52PZON for ; Mon, 26 Apr 2010 09:26:19 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 8E6EA28C1A1 for ; Mon, 26 Apr 2010 09:25:32 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-9.tower-161.messagelabs.com!1272299119!24748723!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 5313 invoked from network); 26 Apr 2010 16:25:20 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-9.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Apr 2010 16:25:20 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o3QGP3lI025030 for ; Mon, 26 Apr 2010 12:25:03 -0400 Received: from klpd017.kcdc.att.com (klpd017.kcdc.att.com [135.188.40.86]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o3QGOwEo024948 for ; Mon, 26 Apr 2010 12:24:58 -0400 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id o3QGPDwe005203 for ; Mon, 26 Apr 2010 11:25:13 -0500 Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id o3QGP8dr005088 for ; Mon, 26 Apr 2010 11:25:08 -0500 Message-Id: <201004261625.o3QGP8dr005088@klpd017.kcdc.att.com> Received: from acmt.att.com (dyp004254dys.mt.att.com[135.16.251.229](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100426162508gw100b8isse>; Mon, 26 Apr 2010 16:25:08 +0000 X-Originating-IP: [135.16.251.229] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 26 Apr 2010 12:23:46 -0400 To: steve.baillargeon@videotron.ca, ippm@ietf.org From: Al Morton In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [ippm] Comments for draft-ietf-ippm-twamp-reflect-octets-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, 26 Apr 2010 16:26:24 -0000 Thanks Steve, these are good comments, and we'll resolve them as you suggest in the next draft. Al At 12:21 PM 4/26/2010, steve.baillargeon@videotron.ca wrote: >Content-type: multipart/alternative; > boundary="Boundary_(ID_NEJL3a72RdguL2k8r4BKBg)" >Content-language: en > >Hi Al >Here are some comments on the latest draft. > >- It will be best to explicitly indicate that both the control and >test protocols can reflect octets in an independent manner even if >it is indirectly stated in the introduction. > >- The definition for the "Server octets" field shall indicate where >those bits should appear in the Packet Padding (to be reflected) field. > >- The spec should state that a zero value in the "Server octets" >field means the Server does not desire these octets to be reflected. > >- The spec should state that a non-zero value in the "Server octets" >field means the Server desires these octets to be reflected. The >actual position of these octets in the padding octets of the test >packets shall be clarified. > >- A defintion for Client octets field should be provided and >indicates that is the equal to Octets to be reflected field (from >Request-TW-Session). > >- The spec should indicate when the Client octets field shall appear >in the Packet Padding (to be reflected) field. Based on the example >provided, it looks like the usage of this field is optional and/or >implementation-specific when reflecting octets in test packets. If >so, please indicate it. > >Thank you > >Regards >Steve Baillargeon >_______________________________________________ >ippm mailing list >ippm@ietf.org >https://www.ietf.org/mailman/listinfo/ippm From wwwrun@core3.amsl.com Mon Apr 26 08:24:50 2010 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id EE32228C1CE; Mon, 26 Apr 2010 08:24:49 -0700 (PDT) To: barry.constantine@jdsu.com, gilles.forget@sympatico.ca, ljorgenson@apparentnetworks.com, reinhard@schrageconsult.com From: IETF Secretariat Message-Id: <20100426152449.EE32228C1CE@core3.amsl.com> Date: Mon, 26 Apr 2010 08:24:49 -0700 (PDT) X-Mailman-Approved-At: Tue, 27 Apr 2010 10:20:35 -0700 Cc: ippm@ietf.org, henk@ripe.net, matt@internet2.edu, ietfdbh@comcast.net, ipr-announce@ietf.org Subject: [ippm] Posting of IPR Disclosure related to Barry Constantine's Statement about IPR related to draft-ietf-ippm-tcp-throughput-tm-00 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, 26 Apr 2010 15:24:50 -0000 Dear Barry Constantine, Gilles Forget, Loki Jorgenson, Reinhard Schrage: An IPR disclosure that pertains to your Internet-Draft entitled "TCP Throughput Testing Methodology" (draft-ietf-ippm-tcp-throughput-tm) was submitted to the IETF Secretariat on 2010-04-26 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1319/). The title of the IPR disclosure is "Barry Constantine's Statement about IPR related to draft-ietf-ippm-tcp-throughput-tm-00." The IETF Secretariat From jerome.benoit@grenouille.com Tue Apr 27 15:11: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 1C51628C0CE for ; Tue, 27 Apr 2010 15:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.864 X-Spam-Level: ** X-Spam-Status: No, score=2.864 tagged_above=-999 required=5 tests=[BAYES_80=2, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] 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 Coc56hbk1ZIK for ; Tue, 27 Apr 2010 15:11:28 -0700 (PDT) Received: from laposte.grenouille.com (ns37873.ovh.net [91.121.8.57]) by core3.amsl.com (Postfix) with ESMTP id 1C1563A6812 for ; Tue, 27 Apr 2010 15:11:20 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.grenouille.com (Postfix) with ESMTP id 602677F1EB for ; Wed, 28 Apr 2010 00:11:03 +0200 (CEST) X-Virus-Scanned: spam & virus filtering at laposte.grenouille.com Received: from laposte.grenouille.com ([127.0.0.1]) by localhost (ns37873.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEwGESM0ZJmC for ; Wed, 28 Apr 2010 00:11:01 +0200 (CEST) Received: from nemesis.grenouille.com (bea13-2-82-239-143-199.fbx.proxad.net [82.239.143.199]) by laposte.grenouille.com (Postfix) with ESMTP id 7078A7F103 for ; Wed, 28 Apr 2010 00:11:01 +0200 (CEST) Received: from localhost (localhost [IPv6:::1]) by nemesis.grenouille.com (Postfix) with SMTP id 33B3360187 for ; Wed, 28 Apr 2010 00:11:00 +0200 (CEST) Date: Wed, 28 Apr 2010 00:10:59 +0200 From: Jerome Benoit To: ippm@ietf.org Message-Id: <20100428001059.87143bf9.jerome.benoit@grenouille.com> Organization: grenouille.com X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Wed__28_Apr_2010_00_10_59_+0200_Vo/HMLB+9m3OMsUT" Subject: [ippm] RFC 2679 : comment on time handling 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, 27 Apr 2010 22:11:35 -0000 --Signature=_Wed__28_Apr_2010_00_10_59_+0200_Vo/HMLB+9m3OMsUT Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 3.5 "Since delay values will often be as low as the 100 usec to 10 msec range, it will be important for Src and Dst to synchronize very closely. GPS systems afford one way to achieve synchronization to within several 10s of usec. Ordinary application of NTP may allow synchronization to within several msec, but this depends on the stability and symmetry of delay properties among those NTP agents used, and this delay is what we are trying to measure. A combination of some GPS-based NTP servers and a conservatively designed and deployed set of other NTP servers should yield good results, but this is yet to be tested." 3.6 "Arrange that Src and Dst are synchronized; that is, that they have clocks that are very closely synchronized with each other and each fairly close to the actual time." I fail to understand the strong requirement for Src et Dst host to be synchronised very closely.=20 My point of view :=20 In IPPM, timestamps are always expressed in unix time-stamp format (RFC1305) to start measurement time on Src host, so yes, you need Dst and Src host to synchronized.=20 Now let's imagine you can't have both synchronised, the Dst host is, just it. Why do not rely only the wire-time of the Dst to do the timestamping (Server and Session-Receiver are the same here). Uncertainty on time-stamping calibration must take in account more elements (packets travel time, runtime cf. below) but you can compute it.=20 I really think it's important to develop measurements where you can't trust measurements Src host clock. You can only have on the Src host clock : - resolution=20 - accuracy error calibration (or say skew probability distribution) =20 Given that, you only send to the Src host a time difference between the desired measurement start time-stamp and Src client session to fetch the measurement configuration. It include runtime uncertainty, it's far from perfect but it's a more realistic scenario when you what end user to do measurements ... Cheers. =20 --=20 J=E9r=F4me Benoit aka fraggle La M=E9t=E9o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D --Signature=_Wed__28_Apr_2010_00_10_59_+0200_Vo/HMLB+9m3OMsUT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEARECAAYFAkvXYPMACgkQ+qDLUJ/pFh1/swCgqPzMbT84qZ541k2zOZnlmZIQ 9HIAoNsNr9m8Kba5Cg/2F8+ZdcR4k78P =Tdqh -----END PGP SIGNATURE----- --Signature=_Wed__28_Apr_2010_00_10_59_+0200_Vo/HMLB+9m3OMsUT-- From henk@ripe.net Thu Apr 29 02:06: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 963493A6835 for ; Thu, 29 Apr 2010 02:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[AWL=-0.678, BAYES_50=0.001] 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 EOEHKsXiiJyU for ; Thu, 29 Apr 2010 02:06:18 -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 54FA03A6862 for ; Thu, 29 Apr 2010 02:06:12 -0700 (PDT) Received: from dodo.ripe.net ([193.0.1.102]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1O7Pgu-0005Pm-0g for ippm@ietf.org; Thu, 29 Apr 2010 11:05:57 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=geir.local) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1O7Pgt-0007f1-SE for ippm@ietf.org; Thu, 29 Apr 2010 11:05:51 +0200 Message-ID: <4BD94BEF.9050801@ripe.net> Date: Thu, 29 Apr 2010 11:05:51 +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.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: ippm@ietf.org References: <20100428001059.87143bf9.jerome.benoit@grenouille.com> In-Reply-To: <20100428001059.87143bf9.jerome.benoit@grenouille.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5fa2389eb58fe810a55fe929e66da4738 X-RIPE-Spam-Level: ---- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5fa2389eb58fe810a55fe929e66da4738 Subject: Re: [ippm] RFC 2679 : comment on time handling 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, 29 Apr 2010 09:06:19 -0000 Jerome, I'm not quite sure if I can follow your reasoning but the key seems to be: > "Arrange that Src and Dst are synchronized; that is, that they have > clocks that are very closely synchronized with each other and each > fairly close to the actual time." > > I fail to understand the strong requirement for Src et Dst host to be > synchronised very closely. In 2679 we want to do 1 way delay measurements from one host to another, where the path between the two is unknown. The delay is determined by unknown cable lenghts and queuing effects in routers (where in particular the latter will vary from 1 measurement to another). The only way one can do this, is by calibrating the clocks at both ends against a known time standard. If not, then it is impossible to tell if an extra delay is caused by one of the clocks being off by some fraction of a millisecond, or by an extra 100 km of fiber between the src and dst, or by the packet being in a buffer a little bit longer. You are right if you say that it is sufficient to know the difference between the clocks and time standard and correct for this later, but this is effectively the same as synchronizing the clocks against a reference. 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 ------------------------------------------------------------------------------ Nobody ever went broke underestimating the taste of the American public. H.L.Mencken From jerome.benoit@grenouille.com Thu Apr 29 12:54: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 4964D3A6978 for ; Thu, 29 Apr 2010 12:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.865 X-Spam-Level: * X-Spam-Status: No, score=1.865 tagged_above=-999 required=5 tests=[AWL=0.999, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] 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 YE9KHKy1yNvh for ; Thu, 29 Apr 2010 12:54:41 -0700 (PDT) Received: from laposte.grenouille.com (ns37873.ovh.net [91.121.8.57]) by core3.amsl.com (Postfix) with ESMTP id 075393A67DA for ; Thu, 29 Apr 2010 12:54:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.grenouille.com (Postfix) with ESMTP id 43A247F210 for ; Thu, 29 Apr 2010 21:54:26 +0200 (CEST) X-Virus-Scanned: spam & virus filtering at laposte.grenouille.com Received: from laposte.grenouille.com ([127.0.0.1]) by localhost (ns37873.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUibGz+2s9lg for ; Thu, 29 Apr 2010 21:54:24 +0200 (CEST) Received: from nemesis.grenouille.com (bea13-2-82-239-143-199.fbx.proxad.net [82.239.143.199]) by laposte.grenouille.com (Postfix) with ESMTP id 85E827F20E for ; Thu, 29 Apr 2010 21:54:24 +0200 (CEST) Received: from localhost (localhost [IPv6:::1]) by nemesis.grenouille.com (Postfix) with SMTP id E251A60395 for ; Thu, 29 Apr 2010 21:54:23 +0200 (CEST) Date: Thu, 29 Apr 2010 21:54:23 +0200 From: Jerome Benoit To: ippm@ietf.org Message-Id: <20100429215423.fe1f2ac4.jerome.benoit@grenouille.com> In-Reply-To: <4BD94BEF.9050801@ripe.net> References: <20100428001059.87143bf9.jerome.benoit@grenouille.com> <4BD94BEF.9050801@ripe.net> Organization: grenouille.com X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Thu__29_Apr_2010_21_54_23_+0200_eae=DhHRTVoLrMEk" Subject: Re: [ippm] RFC 2679 : comment on time handling 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, 29 Apr 2010 19:54:42 -0000 --Signature=_Thu__29_Apr_2010_21_54_23_+0200_eae=DhHRTVoLrMEk Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Le Thu, 29 Apr 2010 11:05:51 +0200, Henk Uijterwaal a =E9crit : > Jerome, >=20 > I'm not quite sure if I can follow your reasoning but the key seems > to be: I will try to make myself clearer :) I work on the following architecture :=20 * Logical design=20 S1 is the server, the server do - measurement configuration diffusion - measurement probes receiver (any kind) {A1,...,An} are the set of measurement agents, they can do any kind of measurement (yes, we're in an ideal world ;-) * Time handling in the logical design=20 S1 is synchronized via NTP or GPS, system clock is UTC, accuracy is know, resolution also, etc. and any kind of inaccuracy on the wire-time can be at least calibrated via standard mechanisms.=20 {A1,...,An} are in an unknown state : we do not know if system clock is UTC, we do not know the clock resolution, etc.=20 * Tim-stamping inaccuracy calibration =20 S1 ask {A1,...,An} agents do to the following "measurement" :=20 S1 compute a ramdom time-stamp series {T1,...Tn} in the future, this series will be used to ask the n agents to send one UDP packet to S1. Agents contact S1 to fetch the "measurement"'s configuration but in the configuration we do not put the time-stamp, we put Di =3D Ti - S1-first_configuration_packets-wire-time (resolution matter here). Ai then know that in Di (s|ms| ns) it will have to send one UDP packet to S1 and then have computed locally a time-stamp LTi for the measurement. =20 Ai send the packet, Ai compute difference between LTi and the packet wire-time (with a local capture for example) : Ai-wire-time-difference S1 receive the packet (hopefully).=20 S1 gather all Ai-wire-time-difference.=20 Repeat, repeat, and so on. The idea is : when server ask agents to do measurements, if we can compute the error on remote agents wire-time time-stamping without requiring them to be synchronized, we can do measurement without the need to have both Src and Dst synchronized. =20 S1 ask Ai to send a packets train (Poisson-like or whatever) {(P1,T1),...,(Pn,Tn)}, if on each agents we know the wire-time inaccuracy for Ti wished packets departure time-stamp, it's enough.=20 There's a lot of details I've skipped but I wanted to expose the general idea.=20 Regards, --=20 J=E9r=F4me Benoit aka fraggle La M=E9t=E9o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D --Signature=_Thu__29_Apr_2010_21_54_23_+0200_eae=DhHRTVoLrMEk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEARECAAYFAkvZ4+8ACgkQ+qDLUJ/pFh0NvQCgvv41WQWLANfWvl3K7I0HXdbq mwEAoJYW9laKHys7bUE2zonP1SoYSy1X =jydy -----END PGP SIGNATURE----- --Signature=_Thu__29_Apr_2010_21_54_23_+0200_eae=DhHRTVoLrMEk--