From henk@ripe.net Wed Jun 2 00:52:07 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 31F0B3A6A15 for ; Wed, 2 Jun 2010 00:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[AWL=-0.820, BAYES_05=-1.11] 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 yxJadAxaixPu for ; Wed, 2 Jun 2010 00:52:06 -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 BA5893A67EC for ; Wed, 2 Jun 2010 00:52: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 1OJijq-0007wI-BC for ippm@ietf.org; Wed, 02 Jun 2010 09:51:51 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=guest-84.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OJijq-0007MW-7E for ippm@ietf.org; Wed, 02 Jun 2010 09:51:46 +0200 Message-ID: <4C060D95.5060302@ripe.net> Date: Wed, 02 Jun 2010 09:51:49 +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: e0cdef1f45f89a40ad608d255b27e7d579e0e4f4f446291da3ffab839c3cecb0 X-RIPE-Spam-Level: ---- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d579e0e4f4f446291da3ffab839c3cecb0 Subject: [ippm] 2nd WGLC for draft 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, 02 Jun 2010 07:52:07 -0000 IPPM group, This is a WGLC for the draft: Spatial Composition of Metrics A number of small issues were raised during the first WGLC. This version addresses them. We'd like to give everybody a chance to confirm that the comments have been correctly incorported. Please raise any issues on the draft by Monday June 14, 9:00 UTC. An URL for the draft is: http://datatracker.ietf.org/doc/draft-ietf-ippm-spatial-composition/ Matt & Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ I confirm today what I denied yesterday. Anonymous Politician. From henk@ripe.net Wed Jun 2 00:52:56 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 B46653A6A4A for ; Wed, 2 Jun 2010 00:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599] 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 89RnaNhtFKTt for ; Wed, 2 Jun 2010 00:52:55 -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 933DC3A6A3E for ; Wed, 2 Jun 2010 00:52:55 -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 1OJike-00080U-Or for ippm@ietf.org; Wed, 02 Jun 2010 09:52:42 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=guest-84.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OJike-0007OX-HS for ippm@ietf.org; Wed, 02 Jun 2010 09:52:36 +0200 Message-ID: <4C060DC6.1030306@ripe.net> Date: Wed, 02 Jun 2010 09:52:38 +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: e0cdef1f45f89a40ad608d255b27e7d526ad3e807eda80ac3e0e132dff264bc8 X-RIPE-Spam-Level: ---- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d526ad3e807eda80ac3e0e132dff264bc8 Subject: [ippm] 2nd WGLC for draft TWAMP Reflect Octets 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, 02 Jun 2010 07:52:56 -0000 IPPM Group, This is a second WGLC for the draft: TWAMP Reflect Octets and Symmetrical Size Features A number of small issues were raised during the first WGLC. This version addresses them. We'd like to give everybody a chance to confirm that the comments have been correctly incorported. Please raise any issues on the draft by Monday June 14, 9:00 UTC. An URL for the draft is: http://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-reflect-octets/ Matt & Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ I confirm today what I denied yesterday. Anonymous Politician. From Barry.Constantine@jdsu.com Tue Jun 8 06:17:12 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 9292E28C19F; Tue, 8 Jun 2010 06:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UUiwMmh1yun; Tue, 8 Jun 2010 06:17:11 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with SMTP id 9660128C193; Tue, 8 Jun 2010 06:17:10 -0700 (PDT) Received: from source ([209.36.247.244]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTA5C17DDz9gFeOY/0mK5jJ7KTnsoMZ20@postini.com; Tue, 08 Jun 2010 06:17:13 PDT Received: from milexhtca2.ds.jdsu.net ([10.75.2.122]) by Outbound1.jdsu.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Jun 2010 06:15:51 -0700 Received: from MILEXCH1.ds.jdsu.net ([fe80::6444:f010:6d40:bdb]) by milexhtca2.ds.jdsu.net ([::1]) with mapi; Tue, 8 Jun 2010 06:15:51 -0700 From: Barry Constantine To: Gilles Forget , "Internet-Drafts@ietf.org" , "i-d-announce@ietf.org" Date: Tue, 8 Jun 2010 06:15:49 -0700 Thread-Topic: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-02.txt Thread-Index: Acr2jkLMHgrzQ3HfRBW9dg/LavleVQABzTkwBB3KDRA= Message-ID: <94DEE80C63F7D34F9DC9FE69E39436BE38B7AC42DB@MILEXCH1.ds.jdsu.net> References: <20100518133001.E8A353A6B41@core3.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Jun 2010 13:15:51.0704 (UTC) FILETIME=[B7EE4980:01CB070C] Cc: "ippm@ietf.org" Subject: Re: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-02.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, 08 Jun 2010 13:17:12 -0000 Ok Gilles, Got that, a new version (-03) should soon be released and this will be inco= rporated. Thanks, Barry =20 Principal Member of Technical Staff =20 JDSU Communication Test (formerly Acterna) Emerging Markets and Technology Research =20 One Milestone Center Court =20 Germantown, MD 20876 =20 (W) 240-404-2227 =20 (C) 301-325-7069 -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Gil= les Forget Sent: Tuesday, May 18, 2010 10:23 AM To: Internet-Drafts@ietf.org; i-d-announce@ietf.org Cc: ippm@ietf.org Subject: Re: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-02.txt Bonjour Barry, I'm not sure about the first paragraph of the Path MTU section. To be more specific, I think that the words between parentheses should be replace by : (at what packet length will fragmentation start to occur) 3.1. Determine Network Path MTU TCP implementations should use Path MTU Discovery techniques (PMTUD), but this technique does not always prove reliable in real world=20 situations. Since PMTUD relies on ICMP messages (to inform the host that unfragmented transmission cannot occur), it's not always reliable since many network managers completely disable ICMP. Thanks, Gilles Forget, CCNP. -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: May-18-10 9:30 AM To: i-d-announce@ietf.org Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-02.txt 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 th= e IETF. Title : TCP Throughput Testing Methodology Author(s) : B. Constantine, et al. Filename : draft-ietf-ippm-tcp-throughput-tm-02.txt Pages : 19 Date : 2010-05-18 This memo describes a methodology for measuring sustained TCP throughput performance in an end-to-end managed network environment. =20 This memo is intended to provide a practical approach to help users validat= e the TCP layer performance of a managed network, which should provide a better indication of end-user application level experience. =20 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-02.tx= t Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From lars.eggert@nokia.com Tue Jun 8 06:48: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 698E028C1BD for ; Tue, 8 Jun 2010 06:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.574 X-Spam-Level: X-Spam-Status: No, score=-4.574 tagged_above=-999 required=5 tests=[AWL=-0.575, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7dFGoTSJ9so for ; Tue, 8 Jun 2010 06:48:34 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id E1D5628C1B1 for ; Tue, 8 Jun 2010 06:48:33 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o58DmD2d016026; Tue, 8 Jun 2010 16:48:32 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Jun 2010 16:48:19 +0300 Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Jun 2010 16:48:19 +0300 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o58DmI60001145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jun 2010 16:48:18 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.1 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/signed; boundary=Apple-Mail-6--802535611; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4C060DC6.1030306@ripe.net> Date: Tue, 8 Jun 2010 16:48:11 +0300 Message-Id: <126BB105-7DE2-4888-B798-D6F0BAF9314D@nokia.com> References: <4C060DC6.1030306@ripe.net> To: Henk Uijterwaal X-Mailer: Apple Mail (2.1078) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.fit.nokia.com); Tue, 08 Jun 2010 16:48:11 +0300 (EEST) X-OriginalArrivalTime: 08 Jun 2010 13:48:19.0464 (UTC) FILETIME=[40E2E080:01CB0711] X-Nokia-AV: Clean Cc: IETF IPPM WG Subject: [ippm] AD review: draft-ietf-ippm-twamp-reflect-octets-06 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, 08 Jun 2010 13:48:35 -0000 --Apple-Mail-6--802535611 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Summary: Good to go, modulo some IANA issues. INTRODUCTION, paragraph 4: > The IETF has completed its work on the core specification of TWAMP - > the Two-Way Active Measurement Protocol. Suggest to remove statements that may change over time (like this one) before publication of this document as an archival RFC. (Same elsewhere in the document.) Section 3.1., paragraph 1: > TWAMP connection establishment follows the procedure defined in > section 3.1 of [RFC4656] and section 3.1 of [RFC5357]. The new > features require two new bit positions (and values) to identify the > ability of the Server/Session-Reflector to reflect specific octets > back to the Control-Client/Session-Sender, and to support the new > Session-Sender packet format in TWAMP-Test Protocol. The entire remainder of Section 3.1 should IMO be merged into the IANA Considerations section, which duplicates much of this information already and is the usual place for it. Section 3.4., paragraph 2: > With the publication of this memo as an RFC, the last 7 bit positions > of the Modes 32-bit Field are used. A Control-Client conforming to > this extension of [RFC5357] MAY ignore the values in the higher bits > of the Modes Field, or it MAY support other features that are > communicated in those bit positions. The other bits are available > for future protocol extensions. Do we really need to say this? Section 4.1.3., paragraph 4: > TWAMP-Test Padding Trucation Nit: s/Trucation/Truncation/ Section 6.1., paragraph 0: > 6.1. Registry Specification Section seems unneeded, given that the registry already exists. Section 6.2., paragraph 0: > 6.2. Registry Management Section seems unneeded, given that the registry already exists. Section 6.3., paragraph 0: > 6.3. Experimental Numbers Section seems unneeded, given that the registry already exists. --Apple-Mail-6--802535611 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDYwODEzNDgxMVowIwYJKoZIhvcNAQkEMRYEFAW2rz7TyhqUsRjRipRc/+GpQNmSMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQC5D/0ZKWXsLEKce1e1/gVQ/+jJlIGrYL5g2eE9yvYNFn3L21fmrYZ+nroV07SGXhtfXy5/ 72bwUeuDXXnD5uxp0xBEE5If2FfaimE2PFd+DAKNqCS6I4CKxTT70pcudOTDnvcnAoENRn1G0mhA 8PEJxnben2J8UwmocMc4vzuoNLUHIhn3x9iF2QH4j9ij04giyy/HAxDebdK9Of4k84o/vgPVI6lD 3x4cWkhY+X7rxteem8d+5GB/oegE5vyCiP5PHdgX29T1lOFL82wZHMsgciVSADdu8/NbZJGCS/Kl pAO28aTQPJMm3qw/e6haqrsCeaV2YXE210PF1pbURqs3AAAAAAAA --Apple-Mail-6--802535611-- From Donald.McLachlan@crc.ca Tue Jun 8 08:00:39 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 182303A69BE for ; Tue, 8 Jun 2010 08:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 qS03FKTksonN for ; Tue, 8 Jun 2010 08:00:38 -0700 (PDT) Received: from mailgate01.crc.ca (mailgate01.crc.ca [142.92.160.36]) by core3.amsl.com (Postfix) with ESMTP id 016793A697D for ; Tue, 8 Jun 2010 08:00:37 -0700 (PDT) Received: from mailhub.crc.gc.ca ([142.92.39.50]) by mailgate01.crc.ca (8.13.8/8.13.8) with ESMTP id o58F0aMZ029263; Tue, 8 Jun 2010 11:00:37 -0400 Received: from [142.92.34.101] (janus.dgrc.crc.ca [142.92.34.101]) by mailhub.crc.gc.ca (8.13.8/8.13.8) with ESMTP id o58F0acB023668; Tue, 8 Jun 2010 11:00:36 -0400 Message-ID: <4C0E5B14.6030406@crc.ca> Date: Tue, 08 Jun 2010 11:00:36 -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: Barry Constantine , Gilles Forget References: <20100518133001.E8A353A6B41@core3.amsl.com> <94DEE80C63F7D34F9DC9FE69E39436BE38B7AC42DB@MILEXCH1.ds.jdsu.net> In-Reply-To: <94DEE80C63F7D34F9DC9FE69E39436BE38B7AC42DB@MILEXCH1.ds.jdsu.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.65 on 142.92.160.36 X-Scanned-By: MIMEDefang 2.68 on 142.92.39.50 Content-Disposition: inline X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mailgate01.crc.ca [142.92.160.36]); Tue, 08 Jun 2010 11:00:38 -0400 (EDT) Cc: ippm@ietf.org Subject: Re: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-02.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, 08 Jun 2010 15:00:39 -0000 Gilles and Barry, Re: 3.1. Determine Network Path MTU TCP implementations should use Path MTU Discovery techniques (PMTUD), but this technique does not always prove reliable in real world situations. Since PMTUD relies on ICMP messages (to inform the host that unfragmented transmission cannot occur), it's not always reliable since many network managers completely disable ICMP. Gilles proposed: I'm not sure about the first paragraph of the Path MTU section. To be more specific, I think that the words between parentheses should be replace by : (at what packet length will fragmentation start to occur) I thought about e-mailing when Gilles first posted this comment. Actually, doesn't the ICMP message mean a packet was not transmitted because the DF bit was set and the packet size exceeded the MTU. Additionally, the ICMP message reports what the MTU size/limit is. On 06/08/10 09:15, Barry Constantine wrote: > Ok Gilles, > > Got that, a new version (-03) should soon be released and this will be incorporated. > > Thanks, > > Barry > > > > Principal Member of Technical Staff > > > > JDSU Communication Test (formerly Acterna) > > Emerging Markets and Technology Research > > One Milestone Center Court > > Germantown, MD 20876 > > (W) 240-404-2227 > > (C) 301-325-7069 > > > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Gilles Forget > Sent: Tuesday, May 18, 2010 10:23 AM > To: Internet-Drafts@ietf.org; i-d-announce@ietf.org > Cc: ippm@ietf.org > Subject: Re: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-02.txt > > Bonjour Barry, > > I'm not sure about the first paragraph of the Path MTU section. > To be more specific, I think that the words between parentheses should be > replace by : > (at what packet length will fragmentation start to occur) > > 3.1. Determine Network Path MTU > > TCP implementations should use Path MTU Discovery techniques (PMTUD), > but this technique does not always prove reliable in real world > situations. Since PMTUD relies on ICMP messages (to inform the host > that unfragmented transmission cannot occur), it's not always > reliable since many network managers completely disable ICMP. > > Thanks, > Gilles Forget, CCNP. > > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: May-18-10 9:30 AM > To: i-d-announce@ietf.org > Cc: ippm@ietf.org > Subject: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-02.txt > > 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-02.txt > Pages : 19 > Date : 2010-05-18 > > 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-02.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. > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > From Barry.Constantine@jdsu.com Tue Jun 8 08:16:21 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 3DD1428C186 for ; Tue, 8 Jun 2010 08:16:21 -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 YGK7G1jiiHiv for ; Tue, 8 Jun 2010 08:16:17 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with SMTP id DC8CA3A69CE for ; Tue, 8 Jun 2010 08:16:02 -0700 (PDT) Received: from source ([209.36.247.244]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKTA5es9M7GcNv5pNQ+cdnLXDiFSRKstcX@postini.com; Tue, 08 Jun 2010 08:16:10 PDT Received: from milexhtca2.ds.jdsu.net ([10.75.2.122]) by Outbound1.jdsu.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Jun 2010 08:14:34 -0700 Received: from MILEXCH1.ds.jdsu.net ([fe80::6444:f010:6d40:bdb]) by milexhtca2.ds.jdsu.net ([::1]) with mapi; Tue, 8 Jun 2010 08:14:33 -0700 From: Barry Constantine To: Donald McLachlan , Gilles Forget Date: Tue, 8 Jun 2010 08:14:32 -0700 Thread-Topic: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-02.txt Thread-Index: AcsHG1z2KBTTzO8cQA21AHMSVy1fQQAAd7kA Message-ID: <94DEE80C63F7D34F9DC9FE69E39436BE38B7AC441C@MILEXCH1.ds.jdsu.net> References: <20100518133001.E8A353A6B41@core3.amsl.com> <94DEE80C63F7D34F9DC9FE69E39436BE38B7AC42DB@MILEXCH1.ds.jdsu.net> <4C0E5B14.6030406@crc.ca> In-Reply-To: <4C0E5B14.6030406@crc.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Jun 2010 15:14:34.0598 (UTC) FILETIME=[4D81A860:01CB071D] Cc: "ippm@ietf.org" Subject: Re: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-02.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, 08 Jun 2010 15:16:21 -0000 So Donald, Are you suggesting that the text remain as originally submitted? Thanks, Barry =20 Principal Member of Technical Staff =20 JDSU Communication Test (formerly Acterna) Emerging Markets and Technology Research =20 One Milestone Center Court =20 Germantown, MD 20876 =20 (W) 240-404-2227 =20 (C) 301-325-7069 -----Original Message----- From: Donald McLachlan [mailto:Donald.McLachlan@crc.ca]=20 Sent: Tuesday, June 08, 2010 11:01 AM To: Barry Constantine; Gilles Forget Cc: ippm@ietf.org Subject: Re: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-02.txt Gilles and Barry, Re: 3.1. Determine Network Path MTU TCP implementations should use Path MTU Discovery techniques (PMTUD), but this technique does not always prove reliable in real world situations. Since PMTUD relies on ICMP messages (to inform the host that unfragmented transmission cannot occur), it's not always reliable since many network managers completely disable ICMP. Gilles proposed: I'm not sure about the first paragraph of the Path MTU section. To be more specific, I think that the words between parentheses should be replace by : (at what packet length will fragmentation start to occur) I thought about e-mailing when Gilles first posted this comment. =20 Actually, doesn't the ICMP message mean a packet was not transmitted=20 because the DF bit was set and the packet size exceeded the MTU.=20 Additionally, the ICMP message reports what the MTU size/limit is. On 06/08/10 09:15, Barry Constantine wrote: > Ok Gilles, > > Got that, a new version (-03) should soon be released and this will be in= corporated. > > Thanks, > > Barry > > > > Principal Member of Technical Staff > > > > JDSU Communication Test (formerly Acterna) > > Emerging Markets and Technology Research > > One Milestone Center Court > > Germantown, MD 20876 > > (W) 240-404-2227 > > (C) 301-325-7069 > > > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of G= illes Forget > Sent: Tuesday, May 18, 2010 10:23 AM > To: Internet-Drafts@ietf.org; i-d-announce@ietf.org > Cc: ippm@ietf.org > Subject: Re: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-02.txt > > Bonjour Barry, > > I'm not sure about the first paragraph of the Path MTU section. > To be more specific, I think that the words between parentheses should be > replace by : > (at what packet length will fragmentation start to occur) > > 3.1. Determine Network Path MTU > > TCP implementations should use Path MTU Discovery techniques (PMTUD), > but this technique does not always prove reliable in real world > situations. Since PMTUD relies on ICMP messages (to inform the host > that unfragmented transmission cannot occur), it's not always > reliable since many network managers completely disable ICMP. > > Thanks, > Gilles Forget, CCNP. > > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: May-18-10 9:30 AM > To: i-d-announce@ietf.org > Cc: ippm@ietf.org > Subject: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-02.txt > > 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-02.txt > Pages : 19 > Date : 2010-05-18 > > 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 valid= ate > 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 tha= t > 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-02.= 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. > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > =20 From gilles.forget@sympatico.ca Tue Jun 8 10:17:25 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 5B7E93A69EB for ; Tue, 8 Jun 2010 10:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.804 X-Spam-Level: X-Spam-Status: No, score=0.804 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803] 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 iQ0qMmD19ZuR for ; Tue, 8 Jun 2010 10:17:24 -0700 (PDT) Received: from blu0-omc4-s22.blu0.hotmail.com (blu0-omc4-s22.blu0.hotmail.com [65.55.111.161]) by core3.amsl.com (Postfix) with ESMTP id 445DB3A68C3 for ; Tue, 8 Jun 2010 10:17:24 -0700 (PDT) Received: from BLU0-SMTP8 ([65.55.111.135]) by blu0-omc4-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Jun 2010 10:17:25 -0700 X-Originating-IP: [64.228.82.34] X-Originating-Email: [gilles.forget@sympatico.ca] Message-ID: Received: from gforgetT400 ([64.228.82.34]) by BLU0-SMTP8.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Jun 2010 10:17:24 -0700 From: "Gilles Forget" To: "'Donald McLachlan'" , "'Barry Constantine'" References: <20100518133001.E8A353A6B41@core3.amsl.com> <94DEE80C63F7D34F9DC9FE69E39436BE38B7AC42DB@MILEXCH1.ds.jdsu.net> <4C0E5B14.6030406@crc.ca> In-Reply-To: <4C0E5B14.6030406@crc.ca> Date: Tue, 8 Jun 2010 13:17:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsHG2RknHbwujvrRFmZNjkEXWUCJwADRFhQ Content-Language: en-ca X-OriginalArrivalTime: 08 Jun 2010 17:17:24.0688 (UTC) FILETIME=[766C2500:01CB072E] Cc: ippm@ietf.org Subject: Re: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-02.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, 08 Jun 2010 17:17:25 -0000 Donald and Barry, Donald, you are absolutely right about the fact that the ICMP reply message will indicate the MTU size. Barry, to me the confusion comes from the double negative in the sentence "to inform the host that unfragmented transmission cannot occur". I think, we all agree on the inefficiency of packet fragmentation and that is why we need to find the path MTU before we do any throughput testing. May I suggest "to inform the host about the MTU size". I just want to avoid the double negative. Thanks, Gilles. -----Original Message----- From: Donald McLachlan [mailto:Donald.McLachlan@crc.ca] Sent: June-08-10 11:01 AM To: Barry Constantine; Gilles Forget Cc: ippm@ietf.org Subject: Re: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-02.txt Gilles and Barry, Re: 3.1. Determine Network Path MTU TCP implementations should use Path MTU Discovery techniques (PMTUD), but this technique does not always prove reliable in real world situations. Since PMTUD relies on ICMP messages (to inform the host that unfragmented transmission cannot occur), it's not always reliable since many network managers completely disable ICMP. Gilles proposed: I'm not sure about the first paragraph of the Path MTU section. To be more specific, I think that the words between parentheses should be replace by : (at what packet length will fragmentation start to occur) I thought about e-mailing when Gilles first posted this comment. Actually, doesn't the ICMP message mean a packet was not transmitted because the DF bit was set and the packet size exceeded the MTU. Additionally, the ICMP message reports what the MTU size/limit is. On 06/08/10 09:15, Barry Constantine wrote: > Ok Gilles, > > Got that, a new version (-03) should soon be released and this will be incorporated. > > Thanks, > > Barry > > > > Principal Member of Technical Staff > > > > JDSU Communication Test (formerly Acterna) > > Emerging Markets and Technology Research > > One Milestone Center Court > > Germantown, MD 20876 > > (W) 240-404-2227 > > (C) 301-325-7069 > > > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Gilles Forget > Sent: Tuesday, May 18, 2010 10:23 AM > To: Internet-Drafts@ietf.org; i-d-announce@ietf.org > Cc: ippm@ietf.org > Subject: Re: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-02.txt > > Bonjour Barry, > > I'm not sure about the first paragraph of the Path MTU section. > To be more specific, I think that the words between parentheses should be > replace by : > (at what packet length will fragmentation start to occur) > > 3.1. Determine Network Path MTU > > TCP implementations should use Path MTU Discovery techniques (PMTUD), > but this technique does not always prove reliable in real world > situations. Since PMTUD relies on ICMP messages (to inform the host > that unfragmented transmission cannot occur), it's not always > reliable since many network managers completely disable ICMP. > > Thanks, > Gilles Forget, CCNP. > > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: May-18-10 9:30 AM > To: i-d-announce@ietf.org > Cc: ippm@ietf.org > Subject: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-02.txt > > 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-02.txt > Pages : 19 > Date : 2010-05-18 > > 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-02.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. > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > From Donald.McLachlan@crc.ca Wed Jun 9 07:04: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 B63253A679F for ; Wed, 9 Jun 2010 07:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] 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 ft9wdDELo40g for ; Wed, 9 Jun 2010 07:04:23 -0700 (PDT) Received: from mailgate01.crc.ca (mailgate01.crc.ca [142.92.160.36]) by core3.amsl.com (Postfix) with ESMTP id 48F0E3A697A for ; Wed, 9 Jun 2010 07:04:23 -0700 (PDT) Received: from mailhub.crc.gc.ca ([142.92.39.50]) by mailgate01.crc.ca (8.13.8/8.13.8) with ESMTP id o59E4EVn007710; Wed, 9 Jun 2010 10:04:18 -0400 Received: from [142.92.34.101] (janus.dgrc.crc.ca [142.92.34.101]) by mailhub.crc.gc.ca (8.13.8/8.13.8) with ESMTP id o59E40pu009622; Wed, 9 Jun 2010 10:04:00 -0400 Message-ID: <4C0F9F50.6050106@crc.ca> Date: Wed, 09 Jun 2010 10:04:00 -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: Barry Constantine References: <20100518133001.E8A353A6B41@core3.amsl.com> <94DEE80C63F7D34F9DC9FE69E39436BE38B7AC42DB@MILEXCH1.ds.jdsu.net> <4C0E5B14.6030406@crc.ca> <94DEE80C63F7D34F9DC9FE69E39436BE38B7AC441C@MILEXCH1.ds.jdsu.net> In-Reply-To: <94DEE80C63F7D34F9DC9FE69E39436BE38B7AC441C@MILEXCH1.ds.jdsu.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.65 on 142.92.160.36 X-Scanned-By: MIMEDefang 2.68 on 142.92.39.50 Content-Disposition: inline X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mailgate01.crc.ca [142.92.160.36]); Wed, 09 Jun 2010 10:04:21 -0400 (EDT) Cc: "ippm@ietf.org" Subject: Re: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-02.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, 09 Jun 2010 14:04:24 -0000 Hi Barry, Maybe I'm being pedantic but in the original text I did not like the double "since"s, and the double "reliable"s, and I thought the text (even with Gilles' comment) did not describe the PMTUD / ICMP interaction very accurately. I think either one assumes the reader understands the interaction between PMTUD and ICMP or one assumes the reader does not. In the first case, I think the paragraph could be shorter and clearer: 3.1. Determine Network Path MTU TCP implementations should use Path MTU Discovery techniques (PMTUD). PMTUD relies on ICMP 'need to frag' messages to learn the path MTU. Unfortunately, because many network managers naively completely disable ICMP, this technique does not always prove reliable in real world situations. [ Note: I also added the work naively. ] In the second case, I think the paragraph needs more details. In this case maybe the following text is better: Re: 3.1. Determine Network Path MTU TCP implementations should use Path MTU Discovery techniques (PMTUD). PMTUD relies on ICMP 'need to frag' messages to learn the path MTU. When a device has a packet to send which has the Don't Fragment (DF) bit in the IP header set and the packet is larger than the Maximum Transmission Unit (MTU) of the next hop link, the packet is dropped and the device sends an ICMP 'need to frag' message back to the host that originated the packet. The ICMP 'need to frag' message includes the next hop MTU which PMTUD uses to tune the TCP Maximum Segment Size (MSS). Unfortunately, because many network managers naively completely disable ICMP, this technique does not always prove reliable in real world situations. Personally I prefer the shorter version. Don On 06/08/10 11:14, Barry Constantine wrote: > So Donald, > > Are you suggesting that the text remain as originally submitted? > > Thanks, > > Barry > > > > Principal Member of Technical Staff > > > > JDSU Communication Test (formerly Acterna) > > Emerging Markets and Technology Research > > One Milestone Center Court > > Germantown, MD 20876 > > (W) 240-404-2227 > > (C) 301-325-7069 > > > -----Original Message----- > From: Donald McLachlan [mailto:Donald.McLachlan@crc.ca] > Sent: Tuesday, June 08, 2010 11:01 AM > To: Barry Constantine; Gilles Forget > Cc: ippm@ietf.org > Subject: Re: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-02.txt > > Gilles and Barry, > > Re: 3.1. Determine Network Path MTU > > TCP implementations should use Path MTU Discovery techniques (PMTUD), > but this technique does not always prove reliable in real world > situations. Since PMTUD relies on ICMP messages (to inform the host > that unfragmented transmission cannot occur), it's not always > reliable since many network managers completely disable ICMP. > > Gilles proposed: > > I'm not sure about the first paragraph of the Path MTU section. > To be more specific, I think that the words between parentheses should be > replace by : > (at what packet length will fragmentation start to occur) > > > I thought about e-mailing when Gilles first posted this comment. > Actually, doesn't the ICMP message mean a packet was not transmitted > because the DF bit was set and the packet size exceeded the MTU. > Additionally, the ICMP message reports what the MTU size/limit is. > > > On 06/08/10 09:15, Barry Constantine wrote: > >> Ok Gilles, >> >> Got that, a new version (-03) should soon be released and this will be incorporated. >> >> Thanks, >> >> Barry >> >> >> >> Principal Member of Technical Staff >> >> >> >> JDSU Communication Test (formerly Acterna) >> >> Emerging Markets and Technology Research >> >> One Milestone Center Court >> >> Germantown, MD 20876 >> >> (W) 240-404-2227 >> >> (C) 301-325-7069 >> >> >> -----Original Message----- >> From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Gilles Forget >> Sent: Tuesday, May 18, 2010 10:23 AM >> To: Internet-Drafts@ietf.org; i-d-announce@ietf.org >> Cc: ippm@ietf.org >> Subject: Re: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-02.txt >> >> Bonjour Barry, >> >> I'm not sure about the first paragraph of the Path MTU section. >> To be more specific, I think that the words between parentheses should be >> replace by : >> (at what packet length will fragmentation start to occur) >> >> 3.1. Determine Network Path MTU >> >> TCP implementations should use Path MTU Discovery techniques (PMTUD), >> but this technique does not always prove reliable in real world >> situations. Since PMTUD relies on ICMP messages (to inform the host >> that unfragmented transmission cannot occur), it's not always >> reliable since many network managers completely disable ICMP. >> >> Thanks, >> Gilles Forget, CCNP. >> >> -----Original Message----- >> From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of >> Internet-Drafts@ietf.org >> Sent: May-18-10 9:30 AM >> To: i-d-announce@ietf.org >> Cc: ippm@ietf.org >> Subject: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-02.txt >> >> 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-02.txt >> Pages : 19 >> Date : 2010-05-18 >> >> 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-02.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. >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> >> > From Donald.McLachlan@crc.ca Wed Jun 9 07:04: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 DB55E3A6974 for ; Wed, 9 Jun 2010 07:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599] 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 DFbGIAy28fk0 for ; Wed, 9 Jun 2010 07:04:23 -0700 (PDT) Received: from mailgate01.crc.ca (mailgate01.crc.ca [142.92.160.36]) by core3.amsl.com (Postfix) with ESMTP id 48FA23A6986 for ; Wed, 9 Jun 2010 07:04:23 -0700 (PDT) Received: from mailhub.crc.gc.ca ([142.92.39.50]) by mailgate01.crc.ca (8.13.8/8.13.8) with ESMTP id o59E4Nwb007720; Wed, 9 Jun 2010 10:04:24 -0400 Received: from [142.92.34.101] (janus.dgrc.crc.ca [142.92.34.101]) by mailhub.crc.gc.ca (8.13.8/8.13.8) with ESMTP id o59E4LQj009698; Wed, 9 Jun 2010 10:04:22 -0400 Message-ID: <4C0F9F65.4090207@crc.ca> Date: Wed, 09 Jun 2010 10:04: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: Barry Constantine References: <20100518133001.E8A353A6B41@core3.amsl.com> <94DEE80C63F7D34F9DC9FE69E39436BE38B7AC42DB@MILEXCH1.ds.jdsu.net> <4C0E5B14.6030406@crc.ca> <94DEE80C63F7D34F9DC9FE69E39436BE38B7AC441C@MILEXCH1.ds.jdsu.net> In-Reply-To: <94DEE80C63F7D34F9DC9FE69E39436BE38B7AC441C@MILEXCH1.ds.jdsu.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.65 on 142.92.160.36 X-Scanned-By: MIMEDefang 2.68 on 142.92.39.50 Content-Disposition: inline X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mailgate01.crc.ca [142.92.160.36]); Wed, 09 Jun 2010 10:04:24 -0400 (EDT) Cc: "ippm@ietf.org" Subject: Re: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-02.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, 09 Jun 2010 14:04:25 -0000 Hi Barry, Maybe I'm being pedantic but in the original text I did not like the double "since"s, and the double "reliable"s, and I thought the text (even with Gilles' comment) did not describe the PMTUD / ICMP interaction very accurately. I think either one assumes the reader understands the interaction between PMTUD and ICMP or one assumes the reader does not. In the first case, I think the paragraph could be shorter and clearer: 3.1. Determine Network Path MTU TCP implementations should use Path MTU Discovery techniques (PMTUD). PMTUD relies on ICMP 'need to frag' messages to learn the path MTU. Unfortunately, because many network managers naively completely disable ICMP, this technique does not always prove reliable in real world situations. [ Note: I also added the word naively. ] In the second case, I think the paragraph needs more details. In this case maybe the following text is better: Re: 3.1. Determine Network Path MTU TCP implementations should use Path MTU Discovery techniques (PMTUD). PMTUD relies on ICMP 'need to frag' messages to learn the path MTU. When a device has a packet to send which has the Don't Fragment (DF) bit in the IP header set and the packet is larger than the Maximum Transmission Unit (MTU) of the next hop link, the packet is dropped and the device sends an ICMP 'need to frag' message back to the host that originated the packet. The ICMP 'need to frag' message includes the next hop MTU which PMTUD uses to tune the TCP Maximum Segment Size (MSS). Unfortunately, because many network managers naively completely disable ICMP, this technique does not always prove reliable in real world situations. Personally I prefer the shorter version. Don On 06/08/10 11:14, Barry Constantine wrote: > So Donald, > > Are you suggesting that the text remain as originally submitted? > > Thanks, > > Barry > > > > Principal Member of Technical Staff > > > > JDSU Communication Test (formerly Acterna) > > Emerging Markets and Technology Research > > One Milestone Center Court > > Germantown, MD 20876 > > (W) 240-404-2227 > > (C) 301-325-7069 > > > -----Original Message----- > From: Donald McLachlan [mailto:Donald.McLachlan@crc.ca] > Sent: Tuesday, June 08, 2010 11:01 AM > To: Barry Constantine; Gilles Forget > Cc: ippm@ietf.org > Subject: Re: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-02.txt > > Gilles and Barry, > > Re: 3.1. Determine Network Path MTU > > TCP implementations should use Path MTU Discovery techniques (PMTUD), > but this technique does not always prove reliable in real world > situations. Since PMTUD relies on ICMP messages (to inform the host > that unfragmented transmission cannot occur), it's not always > reliable since many network managers completely disable ICMP. > > Gilles proposed: > > I'm not sure about the first paragraph of the Path MTU section. > To be more specific, I think that the words between parentheses should be > replace by : > (at what packet length will fragmentation start to occur) > > > I thought about e-mailing when Gilles first posted this comment. > Actually, doesn't the ICMP message mean a packet was not transmitted > because the DF bit was set and the packet size exceeded the MTU. > Additionally, the ICMP message reports what the MTU size/limit is. > > > On 06/08/10 09:15, Barry Constantine wrote: > >> Ok Gilles, >> >> Got that, a new version (-03) should soon be released and this will be incorporated. >> >> Thanks, >> >> Barry >> >> >> >> Principal Member of Technical Staff >> >> >> >> JDSU Communication Test (formerly Acterna) >> >> Emerging Markets and Technology Research >> >> One Milestone Center Court >> >> Germantown, MD 20876 >> >> (W) 240-404-2227 >> >> (C) 301-325-7069 >> >> >> -----Original Message----- >> From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Gilles Forget >> Sent: Tuesday, May 18, 2010 10:23 AM >> To: Internet-Drafts@ietf.org; i-d-announce@ietf.org >> Cc: ippm@ietf.org >> Subject: Re: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-02.txt >> >> Bonjour Barry, >> >> I'm not sure about the first paragraph of the Path MTU section. >> To be more specific, I think that the words between parentheses should be >> replace by : >> (at what packet length will fragmentation start to occur) >> >> 3.1. Determine Network Path MTU >> >> TCP implementations should use Path MTU Discovery techniques (PMTUD), >> but this technique does not always prove reliable in real world >> situations. Since PMTUD relies on ICMP messages (to inform the host >> that unfragmented transmission cannot occur), it's not always >> reliable since many network managers completely disable ICMP. >> >> Thanks, >> Gilles Forget, CCNP. >> >> -----Original Message----- >> From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of >> Internet-Drafts@ietf.org >> Sent: May-18-10 9:30 AM >> To: i-d-announce@ietf.org >> Cc: ippm@ietf.org >> Subject: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-02.txt >> >> 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-02.txt >> Pages : 19 >> Date : 2010-05-18 >> >> 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-02.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. >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> >> > From alexander.zimmermann@nets.rwth-aachen.de Wed Jun 9 07:38:32 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 09E9D3A698D for ; Wed, 9 Jun 2010 07:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 4TblUWen1QBE for ; Wed, 9 Jun 2010 07:38:27 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 5216E28C0FB for ; Wed, 9 Jun 2010 07:38:27 -0700 (PDT) MIME-version: 1.0 Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0L3R0080B4O3RA10@mta-2.ms.rz.RWTH-Aachen.de> for ippm@ietf.org; Wed, 09 Jun 2010 16:38:27 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.53,391,1272837600"; d="sig'?scan'208";a="32241758" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Wed, 09 Jun 2010 16:38:27 +0200 Received: from miami.nets.rwth-aachen.de ([unknown] [137.226.12.180]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L3R007IG4O35W70@relay-auth-2.ms.rz.rwth-aachen.de> for ippm@ietf.org; Wed, 09 Jun 2010 16:38:27 +0200 (CEST) Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-13--713122618 From: Alexander Zimmermann In-reply-to: <4C0F9F65.4090207@crc.ca> Date: Wed, 09 Jun 2010 16:38:24 +0200 Content-transfer-encoding: 7bit Message-id: References: <20100518133001.E8A353A6B41@core3.amsl.com> <94DEE80C63F7D34F9DC9FE69E39436BE38B7AC42DB@MILEXCH1.ds.jdsu.net> <4C0E5B14.6030406@crc.ca> <94DEE80C63F7D34F9DC9FE69E39436BE38B7AC441C@MILEXCH1.ds.jdsu.net> <4C0F9F65.4090207@crc.ca> To: Donald McLachlan X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1078) Cc: Barry Constantine , "ippm@ietf.org" Subject: Re: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-02.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, 09 Jun 2010 14:38:32 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-13--713122618 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Folks, sorry for hijacking your discussion... Your section 3.1. says: TCP implementations should use Path MTU Discovery techniques (PMTUD). PMTUD relies on ICMP... This is not completely true since with RFC4821, we can discover the PMTU without ICMP too. Maybe it's not a bad idea to include some words about this fact into the paragraph. Just my 2c. Alex=20 Am 09.06.2010 um 16:04 schrieb Donald McLachlan: >=20 > Hi Barry, >=20 > Maybe I'm being pedantic but in the original text I did not like the > double "since"s, and the double "reliable"s, and I thought the text > (even with Gilles' comment) did not describe the PMTUD / ICMP > interaction very accurately. >=20 > I think either one assumes the reader understands the interaction > between PMTUD and ICMP or one assumes the reader does not. In the = first > case, I think the paragraph could be shorter and clearer: >=20 > 3.1. Determine Network Path MTU >=20 > TCP implementations should use Path MTU Discovery techniques = (PMTUD). > PMTUD relies on ICMP 'need to frag' messages to learn the path MTU. > Unfortunately, because many network managers naively completely > disable ICMP, this technique does not always prove reliable in real > world situations. >=20 > [ Note: I also added the word naively. ] >=20 > In the second case, I think the paragraph needs more details. In this > case maybe the following text is better: >=20 > Re: 3.1. Determine Network Path MTU >=20 > TCP implementations should use Path MTU Discovery techniques = (PMTUD). > PMTUD relies on ICMP 'need to frag' messages to learn the path MTU. > When a device has a packet to send which has the Don't Fragment = (DF) > bit in the IP header set and the packet is larger than the Maximum > Transmission Unit (MTU) of the next hop link, the packet is dropped > and the device sends an ICMP 'need to frag' message back to the = host > that originated the packet. The ICMP 'need to frag' message = includes > the next hop MTU which PMTUD uses to tune the TCP Maximum Segment > Size (MSS). Unfortunately, because many network managers naively > completely disable ICMP, this technique does not always prove = reliable > in real world situations. >=20 > Personally I prefer the shorter version. >=20 > Don >=20 >=20 > On 06/08/10 11:14, Barry Constantine wrote: >> So Donald, >>=20 >> Are you suggesting that the text remain as originally submitted? >>=20 >> Thanks, >>=20 >> Barry >>=20 >>=20 >>=20 >> Principal Member of Technical Staff >>=20 >>=20 >>=20 >> JDSU Communication Test (formerly Acterna) >>=20 >> Emerging Markets and Technology Research >>=20 >> One Milestone Center Court >>=20 >> Germantown, MD 20876 >>=20 >> (W) 240-404-2227 >>=20 >> (C) 301-325-7069 >>=20 >>=20 >> -----Original Message----- >> From: Donald McLachlan [mailto:Donald.McLachlan@crc.ca] >> Sent: Tuesday, June 08, 2010 11:01 AM >> To: Barry Constantine; Gilles Forget >> Cc: ippm@ietf.org >> Subject: Re: [ippm] I-D = Action:draft-ietf-ippm-tcp-throughput-tm-02.txt >>=20 >> Gilles and Barry, >>=20 >> Re: 3.1. Determine Network Path MTU >>=20 >> TCP implementations should use Path MTU Discovery techniques = (PMTUD), >> but this technique does not always prove reliable in real world >> situations. Since PMTUD relies on ICMP messages (to inform the = host >> that unfragmented transmission cannot occur), it's not always >> reliable since many network managers completely disable ICMP. >>=20 >> Gilles proposed: >>=20 >> I'm not sure about the first paragraph of the Path MTU section. >> To be more specific, I think that the words between parentheses = should be >> replace by : >> (at what packet length will fragmentation start to occur) >>=20 >>=20 >> I thought about e-mailing when Gilles first posted this comment. >> Actually, doesn't the ICMP message mean a packet was not transmitted >> because the DF bit was set and the packet size exceeded the MTU. >> Additionally, the ICMP message reports what the MTU size/limit is. >>=20 >>=20 >> On 06/08/10 09:15, Barry Constantine wrote: >>=20 >>> Ok Gilles, >>>=20 >>> Got that, a new version (-03) should soon be released and this will = be incorporated. >>>=20 >>> Thanks, >>>=20 >>> Barry >>>=20 >>>=20 >>>=20 >>> Principal Member of Technical Staff >>>=20 >>>=20 >>>=20 >>> JDSU Communication Test (formerly Acterna) >>>=20 >>> Emerging Markets and Technology Research >>>=20 >>> One Milestone Center Court >>>=20 >>> Germantown, MD 20876 >>>=20 >>> (W) 240-404-2227 >>>=20 >>> (C) 301-325-7069 >>>=20 >>>=20 >>> -----Original Message----- >>> From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf = Of Gilles Forget >>> Sent: Tuesday, May 18, 2010 10:23 AM >>> To: Internet-Drafts@ietf.org; i-d-announce@ietf.org >>> Cc: ippm@ietf.org >>> Subject: Re: [ippm] I-D = Action:draft-ietf-ippm-tcp-throughput-tm-02.txt >>>=20 >>> Bonjour Barry, >>>=20 >>> I'm not sure about the first paragraph of the Path MTU section. >>> To be more specific, I think that the words between parentheses = should be >>> replace by : >>> (at what packet length will fragmentation start to occur) >>>=20 >>> 3.1. Determine Network Path MTU >>>=20 >>> TCP implementations should use Path MTU Discovery techniques = (PMTUD), >>> but this technique does not always prove reliable in real world >>> situations. Since PMTUD relies on ICMP messages (to inform the = host >>> that unfragmented transmission cannot occur), it's not always >>> reliable since many network managers completely disable ICMP. >>>=20 >>> Thanks, >>> Gilles Forget, CCNP. >>>=20 >>> -----Original Message----- >>> From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf = Of >>> Internet-Drafts@ietf.org >>> Sent: May-18-10 9:30 AM >>> To: i-d-announce@ietf.org >>> Cc: ippm@ietf.org >>> Subject: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-02.txt >>>=20 >>> 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. >>>=20 >>>=20 >>> Title : TCP Throughput Testing Methodology >>> Author(s) : B. Constantine, et al. >>> Filename : draft-ietf-ippm-tcp-throughput-tm-02.txt >>> Pages : 19 >>> Date : 2010-05-18 >>>=20 >>> 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. >>>=20 >>> A URL for this Internet-Draft is: >>> = http://www.ietf.org/internet-drafts/draft-ietf-ippm-tcp-throughput-tm-02.t= xt >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>>=20 >>> _______________________________________________ >>> ippm mailing list >>> ippm@ietf.org >>> https://www.ietf.org/mailman/listinfo/ippm >>> _______________________________________________ >>> ippm mailing list >>> ippm@ietf.org >>> https://www.ietf.org/mailman/listinfo/ippm >>>=20 >>>=20 >>=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm --Apple-Mail-13--713122618 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkwPp2AACgkQdyiq39b9uS7h7wCg5W0bY6U7NP0Fs57yzF7MX2Jc nx4An0OV8ZtGBelXZfXVBBT48+JqmzXe =EW+U -----END PGP SIGNATURE----- --Apple-Mail-13--713122618-- From Barry.Constantine@jdsu.com Wed Jun 9 08:36: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 A13DA3A67F6 for ; Wed, 9 Jun 2010 08:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.732 X-Spam-Level: X-Spam-Status: No, score=-5.732 tagged_above=-999 required=5 tests=[AWL=0.867, 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 mNvZfWxGyRf3 for ; Wed, 9 Jun 2010 08:36:01 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with SMTP id 8B8D128C123 for ; Wed, 9 Jun 2010 08:35:54 -0700 (PDT) Received: from source ([209.36.247.244]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTA+03KAqa7JXDTD2uxlzD3tfEXE4xei8@postini.com; Wed, 09 Jun 2010 08:35:59 PDT Received: from milexhtca1.ds.jdsu.net ([10.75.2.121]) by Outbound1.jdsu.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Jun 2010 08:33:53 -0700 Received: from MILEXCH1.ds.jdsu.net ([fe80::6444:f010:6d40:bdb]) by milexhtca1.ds.jdsu.net ([::1]) with mapi; Wed, 9 Jun 2010 08:33:53 -0700 From: Barry Constantine To: Alexander Zimmermann , Donald McLachlan Date: Wed, 9 Jun 2010 08:33:51 -0700 Thread-Topic: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-02.txt Thread-Index: AcsH4W3tH1YZMI+aS4a4HupIG4mcLgAB3pUg Message-ID: <94DEE80C63F7D34F9DC9FE69E39436BE38B7AC4E56@MILEXCH1.ds.jdsu.net> References: <20100518133001.E8A353A6B41@core3.amsl.com> <94DEE80C63F7D34F9DC9FE69E39436BE38B7AC42DB@MILEXCH1.ds.jdsu.net> <4C0E5B14.6030406@crc.ca> <94DEE80C63F7D34F9DC9FE69E39436BE38B7AC441C@MILEXCH1.ds.jdsu.net> <4C0F9F65.4090207@crc.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Jun 2010 15:33:53.0914 (UTC) FILETIME=[2AECFDA0:01CB07E9] Cc: "ippm@ietf.org" Subject: Re: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-02.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, 09 Jun 2010 15:36:28 -0000 Alexander, your feedback and Donald's are most welcome! Let me sort through these comments and try to come up with a paragraph that= satisfies all. -03 version is coming out soon and I will make the changes in this version. Again, thanks for your comments and appreciate more in any other sections t= hat you can review. Thanks, Barry =20 Principal Member of Technical Staff =20 JDSU Communication Test (formerly Acterna) Emerging Markets and Technology Research =20 One Milestone Center Court =20 Germantown, MD 20876 =20 (W) 240-404-2227 =20 (C) 301-325-7069 -----Original Message----- From: Alexander Zimmermann [mailto:alexander.zimmermann@nets.rwth-aachen.de= ]=20 Sent: Wednesday, June 09, 2010 10:38 AM To: Donald McLachlan Cc: Barry Constantine; ippm@ietf.org Subject: Re: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-02.txt Hi Folks, sorry for hijacking your discussion... Your section 3.1. says: TCP implementations should use Path MTU Discovery techniques (PMTUD). PMTUD relies on ICMP... This is not completely true since with RFC4821, we can discover the PMTU without ICMP too. Maybe it's not a bad idea to include some words about this fact into the paragraph. Just my 2c. Alex=20 Am 09.06.2010 um 16:04 schrieb Donald McLachlan: >=20 > Hi Barry, >=20 > Maybe I'm being pedantic but in the original text I did not like the > double "since"s, and the double "reliable"s, and I thought the text > (even with Gilles' comment) did not describe the PMTUD / ICMP > interaction very accurately. >=20 > I think either one assumes the reader understands the interaction > between PMTUD and ICMP or one assumes the reader does not. In the first > case, I think the paragraph could be shorter and clearer: >=20 > 3.1. Determine Network Path MTU >=20 > TCP implementations should use Path MTU Discovery techniques (PMTUD). > PMTUD relies on ICMP 'need to frag' messages to learn the path MTU. > Unfortunately, because many network managers naively completely > disable ICMP, this technique does not always prove reliable in real > world situations. >=20 > [ Note: I also added the word naively. ] >=20 > In the second case, I think the paragraph needs more details. In this > case maybe the following text is better: >=20 > Re: 3.1. Determine Network Path MTU >=20 > TCP implementations should use Path MTU Discovery techniques (PMTUD). > PMTUD relies on ICMP 'need to frag' messages to learn the path MTU. > When a device has a packet to send which has the Don't Fragment (DF) > bit in the IP header set and the packet is larger than the Maximum > Transmission Unit (MTU) of the next hop link, the packet is dropped > and the device sends an ICMP 'need to frag' message back to the host > that originated the packet. The ICMP 'need to frag' message includes > the next hop MTU which PMTUD uses to tune the TCP Maximum Segment > Size (MSS). Unfortunately, because many network managers naively > completely disable ICMP, this technique does not always prove reliable > in real world situations. >=20 > Personally I prefer the shorter version. >=20 > Don >=20 >=20 > On 06/08/10 11:14, Barry Constantine wrote: >> So Donald, >>=20 >> Are you suggesting that the text remain as originally submitted? >>=20 >> Thanks, >>=20 >> Barry >>=20 >>=20 >>=20 >> Principal Member of Technical Staff >>=20 >>=20 >>=20 >> JDSU Communication Test (formerly Acterna) >>=20 >> Emerging Markets and Technology Research >>=20 >> One Milestone Center Court >>=20 >> Germantown, MD 20876 >>=20 >> (W) 240-404-2227 >>=20 >> (C) 301-325-7069 >>=20 >>=20 >> -----Original Message----- >> From: Donald McLachlan [mailto:Donald.McLachlan@crc.ca] >> Sent: Tuesday, June 08, 2010 11:01 AM >> To: Barry Constantine; Gilles Forget >> Cc: ippm@ietf.org >> Subject: Re: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-02.txt >>=20 >> Gilles and Barry, >>=20 >> Re: 3.1. Determine Network Path MTU >>=20 >> TCP implementations should use Path MTU Discovery techniques (PMTUD)= , >> but this technique does not always prove reliable in real world >> situations. Since PMTUD relies on ICMP messages (to inform the host >> that unfragmented transmission cannot occur), it's not always >> reliable since many network managers completely disable ICMP. >>=20 >> Gilles proposed: >>=20 >> I'm not sure about the first paragraph of the Path MTU section. >> To be more specific, I think that the words between parentheses sho= uld be >> replace by : >> (at what packet length will fragmentation start to occur) >>=20 >>=20 >> I thought about e-mailing when Gilles first posted this comment. >> Actually, doesn't the ICMP message mean a packet was not transmitted >> because the DF bit was set and the packet size exceeded the MTU. >> Additionally, the ICMP message reports what the MTU size/limit is. >>=20 >>=20 >> On 06/08/10 09:15, Barry Constantine wrote: >>=20 >>> Ok Gilles, >>>=20 >>> Got that, a new version (-03) should soon be released and this will be = incorporated. >>>=20 >>> Thanks, >>>=20 >>> Barry >>>=20 >>>=20 >>>=20 >>> Principal Member of Technical Staff >>>=20 >>>=20 >>>=20 >>> JDSU Communication Test (formerly Acterna) >>>=20 >>> Emerging Markets and Technology Research >>>=20 >>> One Milestone Center Court >>>=20 >>> Germantown, MD 20876 >>>=20 >>> (W) 240-404-2227 >>>=20 >>> (C) 301-325-7069 >>>=20 >>>=20 >>> -----Original Message----- >>> From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of= Gilles Forget >>> Sent: Tuesday, May 18, 2010 10:23 AM >>> To: Internet-Drafts@ietf.org; i-d-announce@ietf.org >>> Cc: ippm@ietf.org >>> Subject: Re: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-02.txt >>>=20 >>> Bonjour Barry, >>>=20 >>> I'm not sure about the first paragraph of the Path MTU section. >>> To be more specific, I think that the words between parentheses should = be >>> replace by : >>> (at what packet length will fragmentation start to occur) >>>=20 >>> 3.1. Determine Network Path MTU >>>=20 >>> TCP implementations should use Path MTU Discovery techniques (PMTUD= ), >>> but this technique does not always prove reliable in real world >>> situations. Since PMTUD relies on ICMP messages (to inform the hos= t >>> that unfragmented transmission cannot occur), it's not always >>> reliable since many network managers completely disable ICMP. >>>=20 >>> Thanks, >>> Gilles Forget, CCNP. >>>=20 >>> -----Original Message----- >>> From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of >>> Internet-Drafts@ietf.org >>> Sent: May-18-10 9:30 AM >>> To: i-d-announce@ietf.org >>> Cc: ippm@ietf.org >>> Subject: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-02.txt >>>=20 >>> 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 o= f the >>> IETF. >>>=20 >>>=20 >>> Title : TCP Throughput Testing Methodology >>> Author(s) : B. Constantine, et al. >>> Filename : draft-ietf-ippm-tcp-throughput-tm-02.txt >>> Pages : 19 >>> Date : 2010-05-18 >>>=20 >>> This memo describes a methodology for measuring sustained TCP throughpu= t >>> performance in an end-to-end managed network environment. >>> This memo is intended to provide a practical approach to help users val= idate >>> 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 t= hat >>> should be tested as part of the network verification at the TCP layer. >>>=20 >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-ippm-tcp-throughput-tm-0= 2.txt >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>>=20 >>> _______________________________________________ >>> ippm mailing list >>> ippm@ietf.org >>> https://www.ietf.org/mailman/listinfo/ippm >>> _______________________________________________ >>> ippm mailing list >>> ippm@ietf.org >>> https://www.ietf.org/mailman/listinfo/ippm >>>=20 >>>=20 >>=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From root@core3.amsl.com Fri Jun 11 05:15:12 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 6DC403A69F6; Fri, 11 Jun 2010 05:15:11 -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: <20100611121512.6DC403A69F6@core3.amsl.com> Date: Fri, 11 Jun 2010 05:15:12 -0700 (PDT) Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-03.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, 11 Jun 2010 12:15:13 -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-03.txt Pages : 17 Date : 2010-06-11 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-03.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-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-11051357.I-D@ietf.org> --NextPart-- From Barry.Constantine@jdsu.com Fri Jun 11 05:20:49 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 9FDE83A676A for ; Fri, 11 Jun 2010 05:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 uenPrT4df7cH for ; Fri, 11 Jun 2010 05:20:48 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with SMTP id 1B07C3A67EB for ; Fri, 11 Jun 2010 05:20:48 -0700 (PDT) Received: from source ([209.36.247.244]) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTBIqIm3sgk4Y3XfXSt96uNPdQ5H/SL7B@postini.com; Fri, 11 Jun 2010 05:20:51 PDT Received: from milexhtca2.ds.jdsu.net ([10.75.2.122]) by Outbound1.jdsu.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Jun 2010 05:20:49 -0700 Received: from MILEXCH1.ds.jdsu.net ([fe80::6444:f010:6d40:bdb]) by milexhtca2.ds.jdsu.net ([::1]) with mapi; Fri, 11 Jun 2010 05:20:49 -0700 From: Barry Constantine To: "ippm@ietf.org" Date: Fri, 11 Jun 2010 05:20:47 -0700 Thread-Topic: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-03.txt Thread-Index: AcsJX/FpOa9CMhmfQ+OYSOn28+xD4gAAB0Pg Message-ID: <94DEE80C63F7D34F9DC9FE69E39436BE38B7B48E8E@MILEXCH1.ds.jdsu.net> References: <20100611121512.6DC403A69F6@core3.amsl.com> In-Reply-To: <20100611121512.6DC403A69F6@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Jun 2010 12:20:49.0926 (UTC) FILETIME=[87283260:01CB0960] Subject: Re: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-03.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, 11 Jun 2010 12:20:49 -0000 Hello, In this version: - Added two rudimentary TCP metrics that have been proven useful during lab= testing=20 - PMTUD (RFC4821) section was modified based upon comments - MSS section was removed since we determined value to be limited after con= ducting lab tests Thanks, Barry -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Int= ernet-Drafts@ietf.org Sent: Friday, June 11, 2010 8:15 AM To: i-d-announce@ietf.org Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-03.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Performance Metrics Working Group of th= e IETF. Title : TCP Throughput Testing Methodology Author(s) : B. Constantine, et al. Filename : draft-ietf-ippm-tcp-throughput-tm-03.txt Pages : 17 Date : 2010-06-11 This memo describes a methodology for measuring sustained TCP=20 throughput performance in an end-to-end managed network environment. =20 This memo is intended to provide a practical approach to help users=20 validate the TCP layer performance of a managed network, which should=20 provide a better indication of end-user application level experience. =20 In the methodology, various TCP and network parameters are identified=20 that should be tested as part of the network verification at the TCP=20 layer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-tcp-throughput-tm-03.tx= t Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From henk@ripe.net Mon Jun 14 03:01:49 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 094983A6893 for ; Mon, 14 Jun 2010 03:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=0.565, BAYES_00=-2.599] 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 hq7KcR89wz+c for ; Mon, 14 Jun 2010 03:01:48 -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 AC2DF3A6891 for ; Mon, 14 Jun 2010 03:01:47 -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 1OO6U8-00037c-4H for ippm@ietf.org; Mon, 14 Jun 2010 12:01:49 +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 1OO6U7-0000Mf-SF for ippm@ietf.org; Mon, 14 Jun 2010 12:01:39 +0200 Message-ID: <4C15FE03.10507@ripe.net> Date: Mon, 14 Jun 2010 12:01:39 +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: <4C060DC6.1030306@ripe.net> In-Reply-To: <4C060DC6.1030306@ripe.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5fe7868e84d156e266760d30cd86e23e7 X-RIPE-Spam-Level: ---- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5fe7868e84d156e266760d30cd86e23e7 Subject: Re: [ippm] 2nd WGLC for draft TWAMP Reflect Octets 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, 14 Jun 2010 10:01:49 -0000 IPPM group, > This is a second WGLC for the draft: > > TWAMP Reflect Octets and Symmetrical Size Features > > A number of small issues were raised during the first WGLC. This version > addresses them. We'd like to give everybody a chance to confirm that the > comments have been correctly incorported. Please raise any issues on the > draft by Monday June 14, 9:00 UTC. An URL for the draft is: No issues have been raised, so this draft will be moved forward. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ I confirm today what I denied yesterday. Anonymous Politician. From henk@ripe.net Mon Jun 14 03:17:39 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 7971A3A6847 for ; Mon, 14 Jun 2010 03:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[AWL=-0.397, BAYES_20=-0.74] 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 WlsYEsFg-bmK for ; Mon, 14 Jun 2010 03:17:35 -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 DA3773A687F for ; Mon, 14 Jun 2010 03:17:34 -0700 (PDT) Received: from dodo.ripe.net ([193.0.1.102]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OO6jS-00069L-Fq for ippm@ietf.org; Mon, 14 Jun 2010 12:17:36 +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 1OO6jS-0004OI-9Q for ippm@ietf.org; Mon, 14 Jun 2010 12:17:30 +0200 Message-ID: <4C1601BA.2040309@ripe.net> Date: Mon, 14 Jun 2010 12:17:30 +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: <4C060D95.5060302@ripe.net> In-Reply-To: <4C060D95.5060302@ripe.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d52d7dd7e035825cd44f933b04bb764849 X-RIPE-Spam-Level: ---- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d52d7dd7e035825cd44f933b04bb764849 Subject: Re: [ippm] 2nd WGLC for draft 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: Mon, 14 Jun 2010 10:17:39 -0000 IPPM group, > This is a WGLC for the draft: Spatial Composition of Metrics > > A number of small issues were raised during the first WGLC. This version > addresses them. We'd like to give everybody a chance to confirm that the > comments have been correctly incorported. Please raise any issues on the > draft by Monday June 14, 9:00 UTC. An URL for the draft is: > > http://datatracker.ietf.org/doc/draft-ietf-ippm-spatial-composition/ One issue was raised on this draft. Emile Stephan asked if (some of) the metrics should be registered in the IANA IPPM Metrics Registry. There are two issues with this. They could be summarized as: a) Adding these metrics to the registry will take a considerable amount of time and effort. Perhaps it would be sufficient to add only a subset but this raises the issues which subset to select. On the other hand, it is not clear if/how/by whom the registry is being used at the moment. b) Currently, the registry only contains metric names. There have been suggestions to expand it with parameters and other information. This would be useful for the metrics in this document. Expanding the registry will require discussion in the group first. Adding metrics to an expanded registry, of course, means redoing most of the work done for the current registry. Solving either one of these issues is clearly outside the scope of a WGLC. In order to proceed, the authors and chairs think that it is best to move this draft forward with a note saying that the registry has to be revisited once the issues surrounding the registry have been settled. We have also asked Emile to raise the issues regarding the registry on the list, so we can discuss them. No other issues were raised regarding this draft. Matt & Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ I confirm today what I denied yesterday. Anonymous Politician. From acmorton@att.com Wed Jun 16 08:56:22 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 788AA3A6820 for ; Wed, 16 Jun 2010 08:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.896 X-Spam-Level: X-Spam-Status: No, score=-102.896 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, J_CHICKENPOX_34=0.6, 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 zdRBtTjZwTfJ for ; Wed, 16 Jun 2010 08:56:17 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 1C4423A691F for ; Wed, 16 Jun 2010 08:56:17 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-6.tower-161.messagelabs.com!1276703779!33137660!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 13913 invoked from network); 16 Jun 2010 15:56:19 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-6.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Jun 2010 15:56:19 -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 o5GFuX39007938 for ; Wed, 16 Jun 2010 11:56:33 -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 o5GFuSkV007809 for ; Wed, 16 Jun 2010 11:56:28 -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 o5GFuDpx031291 for ; Wed, 16 Jun 2010 11:56:13 -0400 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id o5GFu7Vr031032 for ; Wed, 16 Jun 2010 11:56:07 -0400 Message-Id: <201006161556.o5GFu7Vr031032@alpd052.aldc.att.com> Received: from acmt.att.com (martym.mt.att.com[135.16.251.71](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100616155602gw100s4p3ne>; Wed, 16 Jun 2010 15:56:07 +0000 X-Originating-IP: [135.16.251.71] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 16 Jun 2010 11:54:35 -0400 To: Lars Eggert , Henk Uijterwaal From: Al Morton In-Reply-To: <126BB105-7DE2-4888-B798-D6F0BAF9314D@nokia.com> References: <4C060DC6.1030306@ripe.net> <126BB105-7DE2-4888-B798-D6F0BAF9314D@nokia.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_15247825==_" X-Mailman-Approved-At: Wed, 16 Jun 2010 08:57:17 -0700 Cc: lencia@att.com, IETF IPPM WG Subject: Re: [ippm] AD review: draft-ietf-ippm-twamp-reflect-octets-06 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, 16 Jun 2010 15:56:22 -0000 --=====================_15247825==_ Content-Type: text/plain; charset="us-ascii"; format=flowed At 09:48 AM 6/8/2010, Lars Eggert wrote: >Summary: Good to go, modulo some IANA issues. Lars, In version 07 (not yet submitted), we've implemented most of your comments below. The only exceptions (with our justification) are: - We left in the last paragraph of section 3.4, since we still think that a short heads-up to implementors is appreciated. - We combined the IANA material in that section, but didn't move any protocol requirements there, and kept section 6.1 as it has helped the IANA folks to understand our future plans for the registry. Thanks for your comments, the IANA section continues to be a difficult curve for us to negotiate at the end. Regards, Len and Al >INTRODUCTION, paragraph 4: > > The IETF has completed its work on the core specification of TWAMP - > > the Two-Way Active Measurement Protocol. > > Suggest to remove statements that may change over time (like this one) > before publication of this document as an archival RFC. (Same > elsewhere in the document.) > > >Section 3.1., paragraph 1: > > TWAMP connection establishment follows the procedure defined in > > section 3.1 of [RFC4656] and section 3.1 of [RFC5357]. The new > > features require two new bit positions (and values) to identify the > > ability of the Server/Session-Reflector to reflect specific octets > > back to the Control-Client/Session-Sender, and to support the new > > Session-Sender packet format in TWAMP-Test Protocol. > > The entire remainder of Section 3.1 should IMO be merged into the IANA > Considerations section, which duplicates much of this information > already and is the usual place for it. > > >Section 3.4., paragraph 2: > > With the publication of this memo as an RFC, the last 7 bit positions > > of the Modes 32-bit Field are used. A Control-Client conforming to > > this extension of [RFC5357] MAY ignore the values in the higher bits > > of the Modes Field, or it MAY support other features that are > > communicated in those bit positions. The other bits are available > > for future protocol extensions. > > Do we really need to say this? > > >Section 4.1.3., paragraph 4: > > TWAMP-Test Padding Trucation > > Nit: s/Trucation/Truncation/ > > >Section 6.1., paragraph 0: > > 6.1. Registry Specification > > Section seems unneeded, given that the registry already exists. > > >Section 6.2., paragraph 0: > > 6.2. Registry Management > > Section seems unneeded, given that the registry already exists. > > >Section 6.3., paragraph 0: > > 6.3. Experimental Numbers > > Section seems unneeded, given that the registry already exists. > > > > >_______________________________________________ >ippm mailing list >ippm@ietf.org >https://www.ietf.org/mailman/listinfo/ippm --=====================_15247825==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="draft-ietf-ippm-twamp-reflect-octets-diff6-7.html" Diff: draft-ietf-ippm-twamp-reflect-octets-06.txt - draft-ietf-ippm-twamp-reflect-octets-07.txt
< draft-ietf-ippm-twamp-reflect-octets-06.txt   draft-ietf-ippm-twamp-reflect-octets-07.txt >
Network Working Group A. Morton Network Working Group A. Morton
Internet-Draft L. Ciavattone Internet-Draft L. Ciavattone
Updates: 5357 (if approved) AT&T Labs Updates: 5357 (if approved) AT&T Labs
Intended status: Standards Track May 30, 2010 Intended status: Standards Track June 15, 2010
Expires: December 1, 2010 Expires: December 17, 2010
TWAMP Reflect Octets and Symmetrical Size Features TWAMP Reflect Octets and Symmetrical Size Features
draft-ietf-ippm-twamp-reflect-octets-06 draft-ietf-ippm-twamp-reflect-octets-07
Abstract Abstract
The IETF has completed its work on the core specification of TWAMP - This memo describes two closely-related features for the core
the Two-Way Active Measurement Protocol. This memo describes two specification of TWAMP - the Two-Way Active Measurement Protocol: an
closely-related features for TWAMP: an optional capability where the optional capability where the responding host returns some of the
responder host returns some of the command octets or padding octets command octets or padding octets to the sender, and an optional
to the controller, and an optional sender packet format that ensures sender packet format that ensures equal test packet sizes are used in
equal test packet sizes are used in both directions. both directions.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 1, 2010. This Internet-Draft will expire on December 17, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 13 skipping to change at page 3, line 13
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 4 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 4
3. TWAMP Control Extensions . . . . . . . . . . . . . . . . . . . 5 3. TWAMP Control Extensions . . . . . . . . . . . . . . . . . . . 5
3.1. Connection Setup with New Features . . . . . . . . . . . . 5 3.1. Connection Setup with New Features . . . . . . . . . . . . 5
3.2. Reflect Octets: Request-TW-Session Packet Format . . . . . 6 3.2. Reflect Octets: Request-TW-Session Packet Format . . . . . 6
3.3. Reflect Octets: Accept Session Packet Format . . . . . . . 8 3.3. Reflect Octets: Accept Session Packet Format . . . . . . . 8
3.4. Additional considerations . . . . . . . . . . . . . . . . 10 3.4. Additional considerations . . . . . . . . . . . . . . . . 9
4. Extended TWAMP Test . . . . . . . . . . . . . . . . . . . . . 10 4. Extended TWAMP Test . . . . . . . . . . . . . . . . . . . . . 9
4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 10 4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Packet Timings . . . . . . . . . . . . . . . . . . . . 10 4.1.1. Packet Timings . . . . . . . . . . . . . . . . . . . . 9
4.1.2. Reflect Octets: Packet Formats and Contents . . . . . 10 4.1.2. Reflect Octets: Packet Formats and Contents . . . . . 10
4.1.3. Reflect Octets: Interaction with Padding Truncation . 12 4.1.3. Reflect Octets: Interaction with Padding Truncation . 11
4.1.4. Symmetrical Size: Session-Sender Packet Format . . . . 13 4.1.4. Symmetrical Size: Session-Sender Packet Format . . . . 12
4.1.5. Symmetrical Size AND Reflect Octets: 4.1.5. Symmetrical Size AND Reflect Octets:
Session-Sender Packet Format . . . . . . . . . . . . . 14 Session-Sender Packet Format . . . . . . . . . . . . . 13
4.2. Reflector Behavior . . . . . . . . . . . . . . . . . . . . 15 4.2. Reflector Behavior . . . . . . . . . . . . . . . . . . . . 14
4.2.1. Reflect Octets: Session-Reflector Packet Format 4.2.1. Reflect Octets: Session-Reflector Packet Format
and Contents . . . . . . . . . . . . . . . . . . . . . 16 and Contents . . . . . . . . . . . . . . . . . . . . . 15
4.2.2. Symmetrical Size: Session-Reflector Packet Format . . 17 4.2.2. Symmetrical Size: Session-Reflector Packet Format . . 16
4.2.3. Symmetrical Size AND Reflect Octets: 4.2.3. Symmetrical Size AND Reflect Octets:
Session-Sender Packet Format . . . . . . . . . . . . . 17 Session-Sender Packet Format . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6.1. Registry Specification . . . . . . . . . . . . . . . . . . 18 6.1. Registry Specification . . . . . . . . . . . . . . . . . . 17
6.2. Registry Management . . . . . . . . . . . . . . . . . . . 18 6.2. Registry Contents . . . . . . . . . . . . . . . . . . . . 17
6.3. Experimental Numbers . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
6.4. Registry Contents . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.2. Informative References . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
The IETF has completed its work on the core specification of TWAMP - TWAMP - the Two-Way Active Measurement Protocol [RFC5357] is an
the Two-Way Active Measurement Protocol [RFC5357]. TWAMP is an
extension of the One-way Active Measurement Protocol, OWAMP extension of the One-way Active Measurement Protocol, OWAMP
[RFC4656]. The TWAMP specification gathered wide review as it [RFC4656]. The TWAMP specification gathered wide review as it
approached completion, and the by-products were several approached completion, and the by-products were several
recommendations for new features in TWAMP. There are a growing recommendations for new features in TWAMP.
number TWAMP implementations at present, and wide-spread usage is
expected. There are even devices that are designed to test
implementations for protocol compliance.
This memo describes two closely-related features for TWAMP. This memo describes two closely-related features for TWAMP.
One is the OPTIONAL capability for the responder host to return a One is the OPTIONAL capability for the responder host to return a
limited number of unassigned (padding) octets to the Control-Client limited number of unassigned (padding) octets to the Control-Client
or Session-Sender entities in both the TWAMP-Control and TWAMP-Test or Session-Sender entities in both the TWAMP-Control and TWAMP-Test
protocols. With this capability, the Control-Client or Session- protocols. With this capability, the Control-Client or Session-
Sender can embed octets of information it deems useful and have the Sender can embed octets of information it deems useful and have the
assurance that the corresponding reply/test packet will contain that assurance that the corresponding reply/test packet will contain that
information when it is reflected and returned (by the Server or information when it is reflected and returned (by the Server or
skipping to change at page 4, line 45 skipping to change at page 4, line 41
features described in this memo to claim compliance with [RFC5357]. features described in this memo to claim compliance with [RFC5357].
Throughout this memo, the bits marked MBZ (Must Be Zero) MUST be set Throughout this memo, the bits marked MBZ (Must Be Zero) MUST be set
to zero by senders and MUST be ignored by receivers. Also, the HMAC to zero by senders and MUST be ignored by receivers. Also, the HMAC
(Hashed Message Authentication Code) MUST be calculated as defined in (Hashed Message Authentication Code) MUST be calculated as defined in
Section 3.2 of [RFC4656]. Section 3.2 of [RFC4656].
2. Purpose and Scope 2. Purpose and Scope
The purpose of this memo is to define two OPTIONAL closely-related The purpose of this memo is to define two OPTIONAL closely-related
features for TWAMP [RFC5357]. The features enhance the TWAMP features for TWAMP [RFC5357]. The features enhance the TWAMP host's
responder's capabilities to perform simple operations on control and capabilities to perform a simple operation on control and test
test packets: the reflection of octets or padding and symmetrical packets: the reflection of octets or padding, and the capability to
sizes of fields in the TWAMP-Test packets. Motivations include ensure symmetrical size TWAMP-Test packets. Motivations include
permitting the controller host to tag packets with an index for permitting the controller host to tag packets with an index for
simplified identification, and/or assert that the same size test simplified identification, and/or assert that the same size test
packets will be used in each direction. packets will be used in each direction.
The scope of the memo is limited to specifications of the following The scope of the memo is limited to specifications of the following
features: features:
o Reflect Octets: the capability of the Server/Session-Reflector to o Reflect Octets: the capability of the Server/Session-Reflector to
reflect specific octets back to the Client/Session-Sender. reflect specific octets back to the Client/Session-Sender, and a
similar service provided by the Client and Session-Sender.
o Symmetrical Size: the capability to ensure that TWAMP-Test o Symmetrical Size: the capability to ensure that TWAMP-Test
protocol uses the same packet size in both directions through protocol uses the same packet size in both directions through
support of a new TWAMP-Test Session-Sender test packet format in support of a new TWAMP-Test Session-Sender test packet format in
both the Session-Sender and the Session-Reflector. Only the both the Session-Sender and the Session-Reflector. Only the
Session-Sender test packet format is new. Session-Sender test packet format is new.
This memo extends the modes of operation through assignment of two This memo extends the modes of operation through assignment of two
new values in the Modes Field (see section 3.1 of[RFC4656] for the new values in the Modes Field (see section 3.1 of[RFC4656] for the
format of the Server Greeting message), while retaining backward format of the Server Greeting message), while retaining backward
skipping to change at page 5, line 47 skipping to change at page 5, line 45
recognized extension mechanism. The following sections describe two recognized extension mechanism. The following sections describe two
such extensions. such extensions.
3.1. Connection Setup with New Features 3.1. Connection Setup with New Features
TWAMP connection establishment follows the procedure defined in TWAMP connection establishment follows the procedure defined in
section 3.1 of [RFC4656] and section 3.1 of [RFC5357]. The new section 3.1 of [RFC4656] and section 3.1 of [RFC5357]. The new
features require two new bit positions (and values) to identify the features require two new bit positions (and values) to identify the
ability of the Server/Session-Reflector to reflect specific octets ability of the Server/Session-Reflector to reflect specific octets
back to the Control-Client/Session-Sender, and to support the new back to the Control-Client/Session-Sender, and to support the new
Session-Sender packet format in TWAMP-Test Protocol. With this added Session-Sender packet format in TWAMP-Test Protocol. See the IANA
feature, the complete set of TWAMP Modes Field bit positions and section for details on the assigned values and bit positions.
values would be as follows:
Value Description Reference/Explanation
0 Reserved
1 Unauthenticated RFC4656, Section 3.1
2 Authenticated RFC4656, Section 3.1
4 Encrypted RFC4656, Section 3.1
8 Unauth. TEST protocol, RFC5681, Section 3.1
Encrypted CONTROL
16 Individual Session RFC????, Section 3.1
Control
--------------------------------------------------------
xxx Reflect Octets new bit position (X)
Capability
yyy Symmetrical Size new bit position (Y)
Sender Test Packet Format
In the original OWAMP Modes Field, setting bit positions 0, 1 or 2
indicated the security mode of the Control protocol, and the Test
protocol inherited the same mode (see section 4 of [RFC4656]). In
[RFC5618], bit position 3 allows unauthenticated TWAMP Test protocol
to be used with encryption on the TWAMP-Control protocol in a mixed
mode of operation.
The Server sets one or both of the new bit positions (X and Y) in the
Modes Field of the Server Greeting message to indicate its
capabilities and willingness to operate in either of these modes (or
both) if desired.
>>>IANA: change xxx, yyy, X, Y, and RFC???? to the assigned values The Server sets one or both of the new bit positions in the Modes
<<< Field of the Server Greeting message to indicate its capabilities and
willingness to operate in either of these modes (or both) if desired.
If the Control-Client intends to operate all test sessions invoked If the Control-Client intends to operate all test sessions invoked
with this control connection using one or both of the new modes, it with this control connection using one or both of the new modes, it
MUST set the Mode Field bit corresponding to each function in the MUST set the Mode Field bit corresponding to each function in the
Setup Response message. With this and other extensions, the Control- Setup Response message. With this and other extensions, the Control-
Client MAY set multiple Mode Field bits in the Setup Response Client MAY set multiple Mode Field bits in the Setup Response
message. message.
3.2. Reflect Octets: Request-TW-Session Packet Format 3.2. Reflect Octets: Request-TW-Session Packet Format
skipping to change at page 13, line 13 skipping to change at page 12, line 13
directions are shown in the table below: directions are shown in the table below:
+-------------------+----------------------+---------------------+ +-------------------+----------------------+---------------------+
| Octets in: | Unauthenticated Mode | Auth/Encrypted Mode | | Octets in: | Unauthenticated Mode | Auth/Encrypted Mode |
+-------------------+----------------------+---------------------+ +-------------------+----------------------+---------------------+
| Reflector Header | 41 | 104 | | Reflector Header | 41 | 104 |
| Sender Header | 14 | 48 | | Sender Header | 14 | 48 |
| Truncated Padding | 27 | 56 | | Truncated Padding | 27 | 56 |
+-------------------+----------------------+---------------------+ +-------------------+----------------------+---------------------+
TWAMP-Test Padding Trucation TWAMP-Test Padding Truncation
When using the Reflect Octets mode simultaneously with the When using the Reflect Octets mode simultaneously with the
RECOMMENDED truncation process in TWAMP section 4.2.1 [RFC5357], the RECOMMENDED truncation process in TWAMP section 4.2.1 [RFC5357], the
Session-Sender MUST append at least 27 octets of padding plus the Session-Sender MUST append at least 27 octets of padding plus the
"Length of the padding to reflect" octets when operating in "Length of the padding to reflect" octets when operating in
Unauthenticated mode. The Session-Sender MUST append at least 56 Unauthenticated mode. The Session-Sender MUST append at least 56
octets of padding plus the "Length of the padding to reflect" octets octets of padding plus the "Length of the padding to reflect" octets
when operating in Authenticated and Encrypted modes. when operating in Authenticated and Encrypted modes.
4.1.4. Symmetrical Size: Session-Sender Packet Format 4.1.4. Symmetrical Size: Session-Sender Packet Format
skipping to change at page 18, line 25 skipping to change at page 17, line 25
Set-up Response messages, as described in section 3.1 of [RFC5357], Set-up Response messages, as described in section 3.1 of [RFC5357],
consistent with section 3.1 of [RFC4656], and extended by this memo. consistent with section 3.1 of [RFC4656], and extended by this memo.
Modes are indicated by setting bits in the 32-bit Modes field that Modes are indicated by setting bits in the 32-bit Modes field that
correspond to values in the Modes registry. For the TWAMP-Modes correspond to values in the Modes registry. For the TWAMP-Modes
registry, we expect that new features will be assigned increasing registry, we expect that new features will be assigned increasing
registry values that correspond to single bit positions, unless there registry values that correspond to single bit positions, unless there
is a good reason to do otherwise (more complex encoding than single is a good reason to do otherwise (more complex encoding than single
bit positions may be used in the future, to access the 2^32 value bit positions may be used in the future, to access the 2^32 value
space). space).
6.2. Registry Management 6.2. Registry Contents
This registry must be updated only by "IETF Consensus" as specified
in [RFC5226](an RFC documenting registry use that is approved by the
IESG).
6.3. Experimental Numbers
No experimental values are currently assigned for the Modes Registry.
6.4. Registry Contents
TWAMP Modes Registry is recommended to be augmented as follows: TWAMP Modes Registry is recommended to be augmented as follows:
Value Description Semantics Definition Value Description Semantics Definition
0 Reserved 0 Reserved
1 Unauthenticated RFC4656, Section 3.1 1 Unauthenticated RFC4656, Section 3.1
2 Authenticated RFC4656, Section 3.1 2 Authenticated RFC4656, Section 3.1
skipping to change at page 19, line 24 skipping to change at page 17, line 48
8 Unauth. TEST protocol, RFC5618, Section 3.1 (3) 8 Unauth. TEST protocol, RFC5618, Section 3.1 (3)
Auth. CONTROL Auth. CONTROL
16 Individual Session RFC????, Section 3.1 16 Individual Session RFC????, Section 3.1
Control bit position (4) Control bit position (4)
-------------------------------------------------------- --------------------------------------------------------
xxx Reflect Octets this memo, section 3.1 xxx Reflect Octets this memo, section 3.1
Capability new bit position (X) Capability new bit position (X)
yyy Symmetrical Size this memo, section 3.1 yyy Symmetrical Size this memo, section 3.1
Sender Test Packet Format new bit position (Y) Sender Test Packet Format new bit position (Y)
The suggested values are >>>IANA: change xxx, yyy, X, Y, and RFC???? to the assigned values
The suggested values are
X=5, xxx=32 X=5, xxx=32
Y=6, yyy=64 Y=6, yyy=64 <<<<
7. Acknowledgements 7. Acknowledgements
The authors thank Steve Baillargeon, Walt Steverson, and Stina Ross The authors thank Steve Baillargeon, Walt Steverson, and Stina Ross
for helpful review and comments. for helpful review and comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
 End of changes. 20 change blocks. 
89 lines changed or deleted 48 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--=====================_15247825==_ Content-Type: application/octet-stream; name="draft-ietf-ippm-twamp-reflect-octets-07.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-ippm-twamp-reflect-octets-07.txt" CgoKTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgQS4gTW9ydG9uCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgTC4gQ2lhdmF0dG9uZQpVcGRhdGVzOiA1MzU3IChpZiBhcHBy b3ZlZCkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBVCZUIExhYnMKSW50ZW5k ZWQgc3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICBKdW5l IDE1LCAyMDEwCkV4cGlyZXM6IERlY2VtYmVyIDE3LCAyMDEwCgoKICAgICAgICAgICBUV0FNUCBS ZWZsZWN0IE9jdGV0cyBhbmQgU3ltbWV0cmljYWwgU2l6ZSBGZWF0dXJlcwogICAgICAgICAgICAg ICAgZHJhZnQtaWV0Zi1pcHBtLXR3YW1wLXJlZmxlY3Qtb2N0ZXRzLTA3CgpBYnN0cmFjdAoKICAg VGhpcyBtZW1vIGRlc2NyaWJlcyB0d28gY2xvc2VseS1yZWxhdGVkIGZlYXR1cmVzIGZvciB0aGUg Y29yZQogICBzcGVjaWZpY2F0aW9uIG9mIFRXQU1QIC0gdGhlIFR3by1XYXkgQWN0aXZlIE1lYXN1 cmVtZW50IFByb3RvY29sOiBhbgogICBvcHRpb25hbCBjYXBhYmlsaXR5IHdoZXJlIHRoZSByZXNw b25kaW5nIGhvc3QgcmV0dXJucyBzb21lIG9mIHRoZQogICBjb21tYW5kIG9jdGV0cyBvciBwYWRk aW5nIG9jdGV0cyB0byB0aGUgc2VuZGVyLCBhbmQgYW4gb3B0aW9uYWwKICAgc2VuZGVyIHBhY2tl dCBmb3JtYXQgdGhhdCBlbnN1cmVzIGVxdWFsIHRlc3QgcGFja2V0IHNpemVzIGFyZSB1c2VkIGlu CiAgIGJvdGggZGlyZWN0aW9ucy4KClJlcXVpcmVtZW50cyBMYW5ndWFnZQoKICAgVGhlIGtleSB3 b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1Qi LAogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJP UFRJT05BTCIgaW4gdGhpcwogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVz Y3JpYmVkIGluIFJGQyAyMTE5IFtSRkMyMTE5XS4KClN0YXR1cyBvZiB0aGlzIE1lbW8KCiAgIFRo aXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0 aGUKICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4KCiAgIEludGVybmV0LURyYWZ0 cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nCiAgIFRh c2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmli dXRlCiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9m IGN1cnJlbnQgSW50ZXJuZXQtCiAgIERyYWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1 bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAgIGFuZCBtYXkgYmUgdXBk YXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55CiAg IHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVm ZXJlbmNlCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGlu IHByb2dyZXNzLiIKCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gRGVjZW1i ZXIgMTcsIDIwMTAuCgpDb3B5cmlnaHQgTm90aWNlCgogICBDb3B5cmlnaHQgKGMpIDIwMTAgSUVU RiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUKICAgZG9jdW1lbnQgYXV0 aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuCgogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3Qg dG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsCgoKCk1vcnRvbiAmIENpYXZhdHRv bmUgICAgIEV4cGlyZXMgRGVjZW1iZXIgMTcsIDIwMTAgICAgICAgICAgICAgICBbUGFnZSAxXQoM CkludGVybmV0LURyYWZ0ICAgICAgIFJlZmxlY3QgT2N0ZXRzICYgU3ltbWV0cmljIFNpemUgICAg ICAgICAgIEp1bmUgMjAxMAoKCiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVu dHMKICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9u IHRoZSBkYXRlIG9mCiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2 aWV3IHRoZXNlIGRvY3VtZW50cwogICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciBy aWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QKICAgdG8gdGhpcyBkb2N1bWVudC4g IENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QKICAgaW5j bHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24g NC5lIG9mCiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0 aG91dCB3YXJyYW50eSBhcwogICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vu c2UuCgogICBUaGlzIGRvY3VtZW50IG1heSBjb250YWluIG1hdGVyaWFsIGZyb20gSUVURiBEb2N1 bWVudHMgb3IgSUVURgogICBDb250cmlidXRpb25zIHB1Ymxpc2hlZCBvciBtYWRlIHB1YmxpY2x5 IGF2YWlsYWJsZSBiZWZvcmUgTm92ZW1iZXIKICAgMTAsIDIwMDguICBUaGUgcGVyc29uKHMpIGNv bnRyb2xsaW5nIHRoZSBjb3B5cmlnaHQgaW4gc29tZSBvZiB0aGlzCiAgIG1hdGVyaWFsIG1heSBu b3QgaGF2ZSBncmFudGVkIHRoZSBJRVRGIFRydXN0IHRoZSByaWdodCB0byBhbGxvdwogICBtb2Rp ZmljYXRpb25zIG9mIHN1Y2ggbWF0ZXJpYWwgb3V0c2lkZSB0aGUgSUVURiBTdGFuZGFyZHMgUHJv Y2Vzcy4KICAgV2l0aG91dCBvYnRhaW5pbmcgYW4gYWRlcXVhdGUgbGljZW5zZSBmcm9tIHRoZSBw ZXJzb24ocykgY29udHJvbGxpbmcKICAgdGhlIGNvcHlyaWdodCBpbiBzdWNoIG1hdGVyaWFscywg dGhpcyBkb2N1bWVudCBtYXkgbm90IGJlIG1vZGlmaWVkCiAgIG91dHNpZGUgdGhlIElFVEYgU3Rh bmRhcmRzIFByb2Nlc3MsIGFuZCBkZXJpdmF0aXZlIHdvcmtzIG9mIGl0IG1heQogICBub3QgYmUg Y3JlYXRlZCBvdXRzaWRlIHRoZSBJRVRGIFN0YW5kYXJkcyBQcm9jZXNzLCBleGNlcHQgdG8gZm9y bWF0CiAgIGl0IGZvciBwdWJsaWNhdGlvbiBhcyBhbiBSRkMgb3IgdG8gdHJhbnNsYXRlIGl0IGlu dG8gbGFuZ3VhZ2VzIG90aGVyCiAgIHRoYW4gRW5nbGlzaC4KCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCk1vcnRvbiAmIENpYXZhdHRvbmUgICAgIEV4cGlyZXMgRGVjZW1iZXIgMTcsIDIw MTAgICAgICAgICAgICAgICBbUGFnZSAyXQoMCkludGVybmV0LURyYWZ0ICAgICAgIFJlZmxlY3Qg T2N0ZXRzICYgU3ltbWV0cmljIFNpemUgICAgICAgICAgIEp1bmUgMjAxMAoKClRhYmxlIG9mIENv bnRlbnRzCgogICAxLiAgSW50cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQKICAgMi4gIFB1cnBvc2UgYW5kIFNjb3BlICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0CiAgIDMuICBUV0FNUCBDb250 cm9sIEV4dGVuc2lvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQog ICAgIDMuMS4gIENvbm5lY3Rpb24gU2V0dXAgd2l0aCBOZXcgRmVhdHVyZXMgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDUKICAgICAzLjIuICBSZWZsZWN0IE9jdGV0czogUmVxdWVzdC1UVy1TZXNz aW9uIFBhY2tldCBGb3JtYXQgLiAuIC4gLiAuICA2CiAgICAgMy4zLiAgUmVmbGVjdCBPY3RldHM6 IEFjY2VwdCBTZXNzaW9uIFBhY2tldCBGb3JtYXQgLiAuIC4gLiAuIC4gLiAgOAogICAgIDMuNC4g IEFkZGl0aW9uYWwgY29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDkKICAgNC4gIEV4dGVuZGVkIFRXQU1QIFRlc3QgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICA5CiAgICAgNC4xLiAgU2VuZGVyIEJlaGF2aW9yICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQogICAgICAgNC4xLjEuICBQYWNr ZXQgVGltaW5ncyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkKICAg ICAgIDQuMS4yLiAgUmVmbGVjdCBPY3RldHM6IFBhY2tldCBGb3JtYXRzIGFuZCBDb250ZW50cyAg LiAuIC4gLiAuIDEwCiAgICAgICA0LjEuMy4gIFJlZmxlY3QgT2N0ZXRzOiBJbnRlcmFjdGlvbiB3 aXRoIFBhZGRpbmcgVHJ1bmNhdGlvbiAgLiAxMQogICAgICAgNC4xLjQuICBTeW1tZXRyaWNhbCBT aXplOiBTZXNzaW9uLVNlbmRlciBQYWNrZXQgRm9ybWF0IC4gLiAuIC4gMTIKICAgICAgIDQuMS41 LiAgU3ltbWV0cmljYWwgU2l6ZSBBTkQgUmVmbGVjdCBPY3RldHM6CiAgICAgICAgICAgICAgIFNl c3Npb24tU2VuZGVyIFBhY2tldCBGb3JtYXQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMwog ICAgIDQuMi4gIFJlZmxlY3RvciBCZWhhdmlvciAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMTQKICAgICAgIDQuMi4xLiAgUmVmbGVjdCBPY3RldHM6IFNlc3Npb24tUmVm bGVjdG9yIFBhY2tldCBGb3JtYXQKICAgICAgICAgICAgICAgYW5kIENvbnRlbnRzIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE1CiAgICAgICA0LjIuMi4gIFN5bW1l dHJpY2FsIFNpemU6IFNlc3Npb24tUmVmbGVjdG9yIFBhY2tldCBGb3JtYXQgIC4gLiAxNgogICAg ICAgNC4yLjMuICBTeW1tZXRyaWNhbCBTaXplIEFORCBSZWZsZWN0IE9jdGV0czoKICAgICAgICAg ICAgICAgU2Vzc2lvbi1TZW5kZXIgUGFja2V0IEZvcm1hdCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDE2CiAgIDUuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAxNgogICA2LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTcKICAgICA2LjEuICBSZWdpc3Ry eSBTcGVjaWZpY2F0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE3CiAg ICAgNi4yLiAgUmVnaXN0cnkgQ29udGVudHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAxNwogICA3LiAgQWNrbm93bGVkZ2VtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTgKICAgOC4gIFJlZmVyZW5jZXMgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE4CiAgICAgOC4xLiAg Tm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAxOAogICAgIDguMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMTgKICAgQXV0aG9ycycgQWRkcmVzc2VzIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE4CgoKCgoKCgoKCgoKCgoKCgoKCgpN b3J0b24gJiBDaWF2YXR0b25lICAgICBFeHBpcmVzIERlY2VtYmVyIDE3LCAyMDEwICAgICAgICAg ICAgICAgW1BhZ2UgM10KDApJbnRlcm5ldC1EcmFmdCAgICAgICBSZWZsZWN0IE9jdGV0cyAmIFN5 bW1ldHJpYyBTaXplICAgICAgICAgICBKdW5lIDIwMTAKCgoxLiAgSW50cm9kdWN0aW9uCgogICBU V0FNUCAtIHRoZSBUd28tV2F5IEFjdGl2ZSBNZWFzdXJlbWVudCBQcm90b2NvbCBbUkZDNTM1N10g aXMgYW4KICAgZXh0ZW5zaW9uIG9mIHRoZSBPbmUtd2F5IEFjdGl2ZSBNZWFzdXJlbWVudCBQcm90 b2NvbCwgT1dBTVAKICAgW1JGQzQ2NTZdLiAgVGhlIFRXQU1QIHNwZWNpZmljYXRpb24gZ2F0aGVy ZWQgd2lkZSByZXZpZXcgYXMgaXQKICAgYXBwcm9hY2hlZCBjb21wbGV0aW9uLCBhbmQgdGhlIGJ5 LXByb2R1Y3RzIHdlcmUgc2V2ZXJhbAogICByZWNvbW1lbmRhdGlvbnMgZm9yIG5ldyBmZWF0dXJl cyBpbiBUV0FNUC4KCiAgIFRoaXMgbWVtbyBkZXNjcmliZXMgdHdvIGNsb3NlbHktcmVsYXRlZCBm ZWF0dXJlcyBmb3IgVFdBTVAuCgogICBPbmUgaXMgdGhlIE9QVElPTkFMIGNhcGFiaWxpdHkgZm9y IHRoZSByZXNwb25kZXIgaG9zdCB0byByZXR1cm4gYQogICBsaW1pdGVkIG51bWJlciBvZiB1bmFz c2lnbmVkIChwYWRkaW5nKSBvY3RldHMgdG8gdGhlIENvbnRyb2wtQ2xpZW50CiAgIG9yIFNlc3Np b24tU2VuZGVyIGVudGl0aWVzIGluIGJvdGggdGhlIFRXQU1QLUNvbnRyb2wgYW5kIFRXQU1QLVRl c3QKICAgcHJvdG9jb2xzLiAgV2l0aCB0aGlzIGNhcGFiaWxpdHksIHRoZSBDb250cm9sLUNsaWVu dCBvciBTZXNzaW9uLQogICBTZW5kZXIgY2FuIGVtYmVkIG9jdGV0cyBvZiBpbmZvcm1hdGlvbiBp dCBkZWVtcyB1c2VmdWwgYW5kIGhhdmUgdGhlCiAgIGFzc3VyYW5jZSB0aGF0IHRoZSBjb3JyZXNw b25kaW5nIHJlcGx5L3Rlc3QgcGFja2V0IHdpbGwgY29udGFpbiB0aGF0CiAgIGluZm9ybWF0aW9u IHdoZW4gaXQgaXMgcmVmbGVjdGVkIGFuZCByZXR1cm5lZCAoYnkgdGhlIFNlcnZlciBvcgogICBT ZXNzaW9uLVJlZmxlY3Rvci4KCiAgIFRoZSBtZW1vIGFsc28gYWRkcyBhbiBPUFRJT05BTCBjYXBh YmlsaXR5IHRvIGFzc3VyZSB0aGF0IHJlZmxlY3RlZAogICB0ZXN0IHBhY2tldHMgYXJlIHRoZSBz YW1lIHNpemUgaW4gYm90aCBkaXJlY3Rpb25zIG9mIHRyYW5zbWlzc2lvbi4KICAgVGhpcyBpcyBh Y2NvbXBsaXNoZWQgYnkgc3BlY2lmeWluZyBhIG5ldyBUV0FNUC1UZXN0IFNlc3Npb24tU2VuZGVy CiAgIHBhY2tldCBmb3JtYXQuCgogICBUaGlzIG1lbW8gaXMgYW4gdXBkYXRlIHRvIHRoZSBUV0FN UCBjb3JlIHByb3RvY29sIHNwZWNpZmllZCBpbgogICBbUkZDNTM1N10uICBNZWFzdXJlbWVudCBz eXN0ZW1zIGFyZSBub3QgcmVxdWlyZWQgdG8gaW1wbGVtZW50IHRoZQogICBmZWF0dXJlcyBkZXNj cmliZWQgaW4gdGhpcyBtZW1vIHRvIGNsYWltIGNvbXBsaWFuY2Ugd2l0aCBbUkZDNTM1N10uCgog ICBUaHJvdWdob3V0IHRoaXMgbWVtbywgdGhlIGJpdHMgbWFya2VkIE1CWiAoTXVzdCBCZSBaZXJv KSBNVVNUIGJlIHNldAogICB0byB6ZXJvIGJ5IHNlbmRlcnMgYW5kIE1VU1QgYmUgaWdub3JlZCBi eSByZWNlaXZlcnMuICBBbHNvLCB0aGUgSE1BQwogICAoSGFzaGVkIE1lc3NhZ2UgQXV0aGVudGlj YXRpb24gQ29kZSkgTVVTVCBiZSBjYWxjdWxhdGVkIGFzIGRlZmluZWQgaW4KICAgU2VjdGlvbiAz LjIgb2YgW1JGQzQ2NTZdLgoKCjIuICBQdXJwb3NlIGFuZCBTY29wZQoKICAgVGhlIHB1cnBvc2Ug b2YgdGhpcyBtZW1vIGlzIHRvIGRlZmluZSB0d28gT1BUSU9OQUwgY2xvc2VseS1yZWxhdGVkCiAg IGZlYXR1cmVzIGZvciBUV0FNUCBbUkZDNTM1N10uICBUaGUgZmVhdHVyZXMgZW5oYW5jZSB0aGUg VFdBTVAgaG9zdCdzCiAgIGNhcGFiaWxpdGllcyB0byBwZXJmb3JtIGEgc2ltcGxlIG9wZXJhdGlv biBvbiBjb250cm9sIGFuZCB0ZXN0CiAgIHBhY2tldHM6IHRoZSByZWZsZWN0aW9uIG9mIG9jdGV0 cyBvciBwYWRkaW5nLCBhbmQgdGhlIGNhcGFiaWxpdHkgdG8KICAgZW5zdXJlIHN5bW1ldHJpY2Fs IHNpemUgVFdBTVAtVGVzdCBwYWNrZXRzLiAgTW90aXZhdGlvbnMgaW5jbHVkZQogICBwZXJtaXR0 aW5nIHRoZSBjb250cm9sbGVyIGhvc3QgdG8gdGFnIHBhY2tldHMgd2l0aCBhbiBpbmRleCBmb3IK ICAgc2ltcGxpZmllZCBpZGVudGlmaWNhdGlvbiwgYW5kL29yIGFzc2VydCB0aGF0IHRoZSBzYW1l IHNpemUgdGVzdAogICBwYWNrZXRzIHdpbGwgYmUgdXNlZCBpbiBlYWNoIGRpcmVjdGlvbi4KCiAg IFRoZSBzY29wZSBvZiB0aGUgbWVtbyBpcyBsaW1pdGVkIHRvIHNwZWNpZmljYXRpb25zIG9mIHRo ZSBmb2xsb3dpbmcKICAgZmVhdHVyZXM6CgoKCgpNb3J0b24gJiBDaWF2YXR0b25lICAgICBFeHBp cmVzIERlY2VtYmVyIDE3LCAyMDEwICAgICAgICAgICAgICAgW1BhZ2UgNF0KDApJbnRlcm5ldC1E cmFmdCAgICAgICBSZWZsZWN0IE9jdGV0cyAmIFN5bW1ldHJpYyBTaXplICAgICAgICAgICBKdW5l IDIwMTAKCgogICBvICBSZWZsZWN0IE9jdGV0czogdGhlIGNhcGFiaWxpdHkgb2YgdGhlIFNlcnZl ci9TZXNzaW9uLVJlZmxlY3RvciB0bwogICAgICByZWZsZWN0IHNwZWNpZmljIG9jdGV0cyBiYWNr IHRvIHRoZSBDbGllbnQvU2Vzc2lvbi1TZW5kZXIsIGFuZCBhCiAgICAgIHNpbWlsYXIgc2Vydmlj ZSBwcm92aWRlZCBieSB0aGUgQ2xpZW50IGFuZCBTZXNzaW9uLVNlbmRlci4KCiAgIG8gIFN5bW1l dHJpY2FsIFNpemU6IHRoZSBjYXBhYmlsaXR5IHRvIGVuc3VyZSB0aGF0IFRXQU1QLVRlc3QKICAg ICAgcHJvdG9jb2wgdXNlcyB0aGUgc2FtZSBwYWNrZXQgc2l6ZSBpbiBib3RoIGRpcmVjdGlvbnMg dGhyb3VnaAogICAgICBzdXBwb3J0IG9mIGEgbmV3IFRXQU1QLVRlc3QgU2Vzc2lvbi1TZW5kZXIg dGVzdCBwYWNrZXQgZm9ybWF0IGluCiAgICAgIGJvdGggdGhlIFNlc3Npb24tU2VuZGVyIGFuZCB0 aGUgU2Vzc2lvbi1SZWZsZWN0b3IuICBPbmx5IHRoZQogICAgICBTZXNzaW9uLVNlbmRlciB0ZXN0 IHBhY2tldCBmb3JtYXQgaXMgbmV3LgoKICAgVGhpcyBtZW1vIGV4dGVuZHMgdGhlIG1vZGVzIG9m IG9wZXJhdGlvbiB0aHJvdWdoIGFzc2lnbm1lbnQgb2YgdHdvCiAgIG5ldyB2YWx1ZXMgaW4gdGhl IE1vZGVzIEZpZWxkIChzZWUgc2VjdGlvbiAzLjEgb2ZbUkZDNDY1Nl0gZm9yIHRoZQogICBmb3Jt YXQgb2YgdGhlIFNlcnZlciBHcmVldGluZyBtZXNzYWdlKSwgd2hpbGUgcmV0YWluaW5nIGJhY2t3 YXJkCiAgIGNvbXBhdGliaWxpdHkgd2l0aCB0aGUgY29yZSBUV0FNUCBbUkZDNTM1N10gaW1wbGVt ZW50YXRpb25zLiAgVGhlIHR3bwogICBuZXcgdmFsdWVzIGNvcnJlc3BvbmQgdG8gdGhlIHR3byBm ZWF0dXJlcyBkZWZpbmVkIGluIHRoaXMgbWVtby4KCiAgIFdoZW4gdGhlIFNlcnZlciBhbmQgQ29u dHJvbC1DbGllbnQgaGF2ZSBhZ3JlZWQgdG8gdXNlIHRoZSBSZWZsZWN0CiAgIE9jdGV0cyBtb2Rl IGR1cmluZyBjb250cm9sIGNvbm5lY3Rpb24gc2V0dXAsIHRoZW4gdGhlIENvbnRyb2wtQ2xpZW50 LAogICB0aGUgU2VydmVyLCB0aGUgU2Vzc2lvbi1TZW5kZXIsIGFuZCB0aGUgU2Vzc2lvbi1SZWZs ZWN0b3IgTVVTVCBhbGwKICAgY29uZm9ybSB0byB0aGUgcmVxdWlyZW1lbnRzIG9mIHRoYXQgbW9k ZSwgYXMgaWRlbnRpZmllZCBiZWxvdy4KCiAgIFdoZW4gdGhlIFNlcnZlciBhbmQgQ29udHJvbC1D bGllbnQgaGF2ZSBhZ3JlZWQgdG8gdXNlIHRoZSBTeW1tZXRyaWNhbAogICBTaXplIG1vZGUgZHVy aW5nIGNvbnRyb2wgY29ubmVjdGlvbiBzZXR1cCwgdGhlbiB0aGUgQ29udHJvbC1DbGllbnQsCiAg IHRoZSBTZXJ2ZXIsIHRoZSBTZXNzaW9uLVNlbmRlciwgYW5kIHRoZSBTZXNzaW9uLVJlZmxlY3Rv ciBNVVNUIGFsbAogICBjb25mb3JtIHRvIHRoZSByZXF1aXJlbWVudHMgb2YgdGhhdCBtb2RlLCBh cyBpZGVudGlmaWVkIGJlbG93LgoKCjMuICBUV0FNUCBDb250cm9sIEV4dGVuc2lvbnMKCiAgIFRX QU1QLUNvbnRyb2wgcHJvdG9jb2wgW1JGQzUzNTddIHVzZXMgdGhlIE1vZGVzIEZpZWxkIHRvIGlk ZW50aWZ5IGFuZAogICBzZWxlY3Qgc3BlY2lmaWMgY29tbXVuaWNhdGlvbiBjYXBhYmlsaXRpZXMs IGFuZCB0aGlzIGZpZWxkIGlzIGEKICAgcmVjb2duaXplZCBleHRlbnNpb24gbWVjaGFuaXNtLiAg VGhlIGZvbGxvd2luZyBzZWN0aW9ucyBkZXNjcmliZSB0d28KICAgc3VjaCBleHRlbnNpb25zLgoK My4xLiAgQ29ubmVjdGlvbiBTZXR1cCB3aXRoIE5ldyBGZWF0dXJlcwoKICAgVFdBTVAgY29ubmVj dGlvbiBlc3RhYmxpc2htZW50IGZvbGxvd3MgdGhlIHByb2NlZHVyZSBkZWZpbmVkIGluCiAgIHNl Y3Rpb24gMy4xIG9mIFtSRkM0NjU2XSBhbmQgc2VjdGlvbiAzLjEgb2YgW1JGQzUzNTddLiAgVGhl IG5ldwogICBmZWF0dXJlcyByZXF1aXJlIHR3byBuZXcgYml0IHBvc2l0aW9ucyAoYW5kIHZhbHVl cykgdG8gaWRlbnRpZnkgdGhlCiAgIGFiaWxpdHkgb2YgdGhlIFNlcnZlci9TZXNzaW9uLVJlZmxl Y3RvciB0byByZWZsZWN0IHNwZWNpZmljIG9jdGV0cwogICBiYWNrIHRvIHRoZSBDb250cm9sLUNs aWVudC9TZXNzaW9uLVNlbmRlciwgYW5kIHRvIHN1cHBvcnQgdGhlIG5ldwogICBTZXNzaW9uLVNl bmRlciBwYWNrZXQgZm9ybWF0IGluIFRXQU1QLVRlc3QgUHJvdG9jb2wuICBTZWUgdGhlIElBTkEK ICAgc2VjdGlvbiBmb3IgZGV0YWlscyBvbiB0aGUgYXNzaWduZWQgdmFsdWVzIGFuZCBiaXQgcG9z aXRpb25zLgoKICAgVGhlIFNlcnZlciBzZXRzIG9uZSBvciBib3RoIG9mIHRoZSBuZXcgYml0IHBv c2l0aW9ucyBpbiB0aGUgTW9kZXMKICAgRmllbGQgb2YgdGhlIFNlcnZlciBHcmVldGluZyBtZXNz YWdlIHRvIGluZGljYXRlIGl0cyBjYXBhYmlsaXRpZXMgYW5kCiAgIHdpbGxpbmduZXNzIHRvIG9w ZXJhdGUgaW4gZWl0aGVyIG9mIHRoZXNlIG1vZGVzIChvciBib3RoKSBpZiBkZXNpcmVkLgoKCgoK TW9ydG9uICYgQ2lhdmF0dG9uZSAgICAgRXhwaXJlcyBEZWNlbWJlciAxNywgMjAxMCAgICAgICAg ICAgICAgIFtQYWdlIDVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgUmVmbGVjdCBPY3RldHMgJiBT eW1tZXRyaWMgU2l6ZSAgICAgICAgICAgSnVuZSAyMDEwCgoKICAgSWYgdGhlIENvbnRyb2wtQ2xp ZW50IGludGVuZHMgdG8gb3BlcmF0ZSBhbGwgdGVzdCBzZXNzaW9ucyBpbnZva2VkCiAgIHdpdGgg dGhpcyBjb250cm9sIGNvbm5lY3Rpb24gdXNpbmcgb25lIG9yIGJvdGggb2YgdGhlIG5ldyBtb2Rl cywgaXQKICAgTVVTVCBzZXQgdGhlIE1vZGUgRmllbGQgYml0IGNvcnJlc3BvbmRpbmcgdG8gZWFj aCBmdW5jdGlvbiBpbiB0aGUKICAgU2V0dXAgUmVzcG9uc2UgbWVzc2FnZS4gIFdpdGggdGhpcyBh bmQgb3RoZXIgZXh0ZW5zaW9ucywgdGhlIENvbnRyb2wtCiAgIENsaWVudCBNQVkgc2V0IG11bHRp cGxlIE1vZGUgRmllbGQgYml0cyBpbiB0aGUgU2V0dXAgUmVzcG9uc2UKICAgbWVzc2FnZS4KCjMu Mi4gIFJlZmxlY3QgT2N0ZXRzOiBSZXF1ZXN0LVRXLVNlc3Npb24gUGFja2V0IEZvcm1hdAoKICAg VGhlIGJpdHMgZGVzaWduYXRlZCBmb3IgdGhlIFJlZmxlY3QgT2N0ZXRzIGZlYXR1cmUgaW4gdGhl IFJlcXVlc3QtVFctCiAgIFNlc3Npb24gY29tbWFuZCBhcmUgYXMgc2hvd24gaW4gdGhlIHBhY2tl dCBmb3JtYXQgYmVsb3cuCgogICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAg ICAgIDIgICAgICAgICAgICAgICAgICAgMwogICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxCiAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAg ICA1ICAgICAgICB8ICBNQlogIHwgSVBWTiAgfCAgQ29uZi1TZW5kZXIgIHwgQ29uZi1SZWNlaXZl ciB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICAgICAgICBOdW1iZXIgb2YgU2NoZWR1bGUg U2xvdHMgICAgICAgICAgICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIC4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuCiAgIC4g ICAgICAgICAgIC4uLiBNYW55IGZpZWxkcyAoNjYgb2N0ZXRzKSBub3Qgc2hvd24gLi4uICAgICAg ICAgICAuCiAgIC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAuCiAgIC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAg ICAgICAgICAgIFBhZGRpbmcgTGVuZ3RoICAoNCBvY3RldHMpICAgICAgICAgICAgICAgICB8CiAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rCiAgIHwgICAgICAgICAgICAgICAgICAgICAgU3RhcnQgVGltZSwgKDggb2N0ZXRz KSAgICAgICAgICAgICAgICAgICB8CiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAg ICAgICAgICAgICAgICAgIFRpbWVvdXQsICg4IG9jdGV0cykgICAgICAgICAgICAgICAgICAgICB8 CiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICAgICAgICAgICAgIFR5cGUt UCBEZXNjcmlwdG9yICAgICAgICAgICAgICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAg IE9jdGV0cyB0byBiZSByZWZsZWN0ZWQgICAgfCAgTGVuZ3RoIG9mIHBhZGRpbmcgdG8gcmVmbGVj dCB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICAgICAgICAgICAgIE1CWiAoNCBvY3RldHMp ICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwg ICAgICAgICAgICAgICAgICAgICAgIEhNQUMgKDE2IG9jdGV0cykgICAgICAgICAgICAgICAgICAg ICAgICB8CiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8CiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCgogICBUaGUgIlBhZGRp bmcgTGVuZ3RoIiBGaWVsZCAqY29udGludWVzKiB0byBzcGVjaWZ5IHRoZSBudW1iZXIgb2YKICAg cGFkZGluZyBvY3RldHMgdGhhdCB0aGUgU2Vzc2lvbi1TZW5kZXIgd2lsbCBhcHBlbmQgdG8gQUxM IFRXQU1QLVRlc3QKICAgcGFja2V0cyBhc3NvY2lhdGVkIHdpdGggdGhpcyB0ZXN0IHNlc3Npb24u ICBTZWUgYmVsb3cgZm9yCiAgIGNvbnNpZGVyYXRpb25zIG9uIHRoZSBtaW5pbXVtIGxlbmd0aCBv ZiB0aGUgcGFkZGluZyBvY3RldHMsIGZvbGxvd2luZwoKCgpNb3J0b24gJiBDaWF2YXR0b25lICAg ICBFeHBpcmVzIERlY2VtYmVyIDE3LCAyMDEwICAgICAgICAgICAgICAgW1BhZ2UgNl0KDApJbnRl cm5ldC1EcmFmdCAgICAgICBSZWZsZWN0IE9jdGV0cyAmIFN5bW1ldHJpYyBTaXplICAgICAgICAg ICBKdW5lIDIwMTAKCgogICB0aGUgZGVmaW5pdGlvbnMgb2YgdGhlIHR3byBuZXcgZmllbGRzIHRo YXQgZm9sbG93IHRoZSBUeXBlLVAKICAgRGVzY3JpcHRvci4KCiAgIE5vdGUgdGhhdCB0aGUgbnVt YmVyIG9mIHBhZGRpbmcgb2N0ZXRzIGFwcGVuZGVkIHRvIHRoZSBTZXNzaW9uLQogICBSZWZsZWN0 b3IncyB0ZXN0IHBhY2tldCBkZXBlbmRzIG9uIHN1cHBvcnQgZm9yIHRoZSBSRUNPTU1FTkRFRAog ICB0cnVuY2F0aW9uIHByb2Nlc3MgaW4gVFdBTVAgc2VjdGlvbiA0LjIuMSBbUkZDNTM1N10uCgog ICBUaGUgIk9jdGV0cyB0byBiZSByZWZsZWN0ZWQiIEZpZWxkIFNIQUxMIGJlIDIgb2N0ZXRzIGxv bmcsIGFzIHNob3duCiAgIGFuZCBjb250YWlucyB0aGUgb2N0ZXRzIHRoYXQgdGhlIFNlcnZlciBN VVNUIHJlZmxlY3QgaW4gdGhlIEFjY2VwdAogICBTZXNzaW9uIG1lc3NhZ2UgYXMgc3BlY2lmaWVk IGJlbG93LgoKICAgVGhlICJMZW5ndGggb2YgcGFkZGluZyB0byByZWZsZWN0IiBGaWVsZCBTSEFM TCBiZSAyIG9jdGV0cyBsb25nLCBhbmQKICAgY29udGFpbiBhbiB1bnNpZ25lZCBiaW5hcnkgdmFs dWUgaW4gdW5pdHMgb2Ygb2N0ZXRzLiAgVGhpcyBmaWVsZAogICBjb21tdW5pY2F0ZXMgdGhlIGxl bmd0aCBvZiB0aGUgcGFkZGluZyBpbiB0aGUgVFdBTVAtVGVzdCBQYWNrZXQgdGhhdAogICB0aGUg U2Vzc2lvbi1TZW5kZXIgZXhwZWN0cyB0byBiZSByZWZsZWN0ZWQsIGFuZCB0aGUgbGVuZ3RoIG9m IG9jdGV0cwogICB0aGF0IHRoZSBTZXNzaW9uLVJlZmxlY3RvciBTSEFMTCByZXR1cm4gaW4gaW5j bHVkZSBpbiBpdHMgVFdBTVAtVGVzdAogICBwYWNrZXQgZm9ybWF0IChzZWUgc2VjdGlvbiA0LjIp LiAgQnkgaW5jbHVkaW5nIHRoaXMgbGVuZ3RoIGZpZWxkIGluCiAgIHRoZSBSZXF1ZXN0LVRXLVNl c3Npb24gbWVzc2FnZSwgYSBTZXJ2ZXIgaXMgYWJsZSB0byBkZXRlcm1pbmUgaWYgaXQKICAgY2Fu IGNvbXBseSB3aXRoIGEgc3BlY2lmaWMgcmVxdWVzdCB0byByZWZsZWN0IHBhZGRpbmcgaW4gdGhl IFRXQU1QLQogICBUZXN0IHBhY2tldHMsIGFuZCB0byBhcnJhbmdlIGZvciB0aGUgU2Vzc2lvbi1S ZWZsZWN0b3IgcHJvY2Vzc2luZyBpbgogICBhZHZhbmNlLgoKICAgVGhlICJQYWRkaW5nIExlbmd0 aCIgU0hPVUxEIGJlID49IDI3IG9jdGV0cyB3aGVuIHNwZWNpZnlpbmcgYSB0ZXN0CiAgIHNlc3Np b24gdXNpbmcgdGhlIFVuYXV0aGVudGljYXRlZCBUV0FNUC1UZXN0IG1vZGUsIHRvIGFsbG93IGZv ciB0aGUKICAgUkVDT01NRU5ERUQgdHJ1bmNhdGlvbiBwcm9jZXNzIGluIFRXQU1QIHNlY3Rpb24g NC4yLjEgW1JGQzUzNTddLgoKICAgVGhlICJQYWRkaW5nIExlbmd0aCIgU0hPVUxEIGJlID49IDU2 IG9jdGV0cyB3aGVuIHNwZWNpZnlpbmcgYSB0ZXN0CiAgIHNlc3Npb24gdXNpbmcgdGhlIEF1dGhl bnRpY2F0ZWQgb3IgRW5jcnlwdGVkIFRXQU1QLVRlc3QgbW9kZXMsIHRvCiAgIGFsbG93IGZvciB0 aGUgUkVDT01NRU5ERUQgdHJ1bmNhdGlvbiBwcm9jZXNzIGluIFRXQU1QIHNlY3Rpb24gNC4yLjEK ICAgW1JGQzUzNTddLgoKICAgVGhlICJQYWRkaW5nIExlbmd0aCIgU0hBTEwgYmUgPiB0aGUgIkxl bmd0aCBvZiBwYWRkaW5nIHRvIHJlZmxlY3QiCiAgIHdoZW4gc3BlY2lmeWluZyBhIHRlc3Qgc2Vz c2lvbiB1c2luZyB0aGUgT1BUSU9OQUwgUmVmbGVjdCBPY3RldHMKICAgbW9kZS4KCiAgIEluIFVu YXV0aGVudGljYXRlZCBUV0FNUC1UZXN0IG1vZGUsIHRoZSAiUGFkZGluZyBMZW5ndGgiIFNIQUxM IGJlID49CiAgIDI3ICsgIkxlbmd0aCBvZiBwYWRkaW5nIHRvIHJlZmxlY3QiIG9jdGV0cyB3aGVu IHNwZWNpZnlpbmcgYSB0ZXN0CiAgIHNlc3Npb24gdXNpbmcgQk9USCB0aGUgT1BUSU9OQUwgUmVm bGVjdCBPY3RldHMgbW9kZSBhbmQgdGhlCiAgIFJFQ09NTUVOREVEIHRydW5jYXRpb24gcHJvY2Vz cyBpbiBUV0FNUCBzZWN0aW9uIDQuMi4xIFtSRkM1MzU3XS4KCiAgIEluIEF1dGhlbnRpY2F0ZWQg b3IgRW5jcnlwdGVkIFRXQU1QLVRlc3QgbW9kZXMsIHRoZSAiUGFkZGluZyBMZW5ndGgiCiAgIFNI QUxMIGJlID49IDU2ICsgIkxlbmd0aCBvZiBwYWRkaW5nIHRvIHJlZmxlY3QiIG9jdGV0cyB3aGVu CiAgIHNwZWNpZnlpbmcgYSB0ZXN0IHNlc3Npb24gdXNpbmcgQk9USCB0aGUgT1BUSU9OQUwgUmVm bGVjdCBPY3RldHMgbW9kZQogICBhbmQgdGhlIFJFQ09NTUVOREVEIHRydW5jYXRpb24gcHJvY2Vz cyBpbiBUV0FNUCBzZWN0aW9uIDQuMi4xCiAgIFtSRkM1MzU3XS4KCgoKCgoKTW9ydG9uICYgQ2lh dmF0dG9uZSAgICAgRXhwaXJlcyBEZWNlbWJlciAxNywgMjAxMCAgICAgICAgICAgICAgIFtQYWdl IDddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgUmVmbGVjdCBPY3RldHMgJiBTeW1tZXRyaWMgU2l6 ZSAgICAgICAgICAgSnVuZSAyMDEwCgoKMy4zLiAgUmVmbGVjdCBPY3RldHM6IEFjY2VwdCBTZXNz aW9uIFBhY2tldCBGb3JtYXQKCiAgIFRoZSBiaXRzIGRlc2lnbmF0ZWQgZm9yIHRoZSBSZWZsZWN0 IFBhZGRpbmcgZmVhdHVyZSBpbiB0aGUgQWNjZXB0CiAgIFNlc3Npb24gY29tbWFuZCBhcmUgYXMg c2hvd24gaW4gdGhlIHBhY2tldCBmb3JtYXQgYmVsb3cuCgogICAgMCAgICAgICAgICAgICAgICAg ICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMwogICAgMCAxIDIgMyA0 IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxCiAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rCiAgIHwgICAgQWNjZXB0ICAgICB8ICAgICAgTUJaICAgICAgfCAgICAgICAgICAg IFBvcnQgICAgICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy18CiAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwgICAgICAg ICAgICAgICAgICAgICAgICBTSUQgKDE2IG9jdGV0cykgICAgICAgICAgICAgICAgICAgICAgICB8 CiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8CiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgUmVmbGVjdGVk IG9jdGV0cyAgICAgICAgfCAgICAgICAgIFNlcnZlciBvY3RldHMgICAgICAgICB8CiAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rCiAgIHwgICAgICAgICAgICAgICAgICAgICAgIE1CWiAoOCBvY3RldHMpICAgICAgICAgICAg ICAgICAgICAgICAgICB8CiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwg ICAgICAgICAgICAgICAgICAgICAgIEhNQUMgKDE2IG9jdGV0cykgICAgICAgICAgICAgICAgICAg ICAgICB8CiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8CiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCgoKICAgVGhlICJSZWZs ZWN0ZWQgb2N0ZXRzIiBmaWVsZCBTSEFMTCBjb250YWluIHRoZSBvY3RldHMgZnJvbSB0aGUKICAg UmVxdWVzdC1UVy1TZXNzaW9uICJPY3RldHMgdG8gYmUgcmVmbGVjdGVkIiBGaWVsZCwgYW5kIGJl IDIgb2N0ZXRzCiAgIGxvbmcsIGFzIHNob3duLgoKICAgVGhlICJTZXJ2ZXIgb2N0ZXRzIiBmaWVs ZCBTSEFMTCBjb250YWluIGluZm9ybWF0aW9uIHRoYXQgdGhlIFNlcnZlcgogICBpbnRlbmRzIHRv IGJlIHJldHVybmVkIGluIHRoZSBUV0FNUC1UZXN0IHBhY2tldCBwYWRkaW5nIHRvLWJlLQogICBy ZWZsZWN0ZWQgRmllbGQsIE9SIFNIQUxMIGJlIHplcm8sIGFuZCBiZSAyIG9jdGV0cyBsb25nLCBh cyBzaG93bi4KICAgQWx0aG91Z2ggdGhlIFNlcnZlciBkZXRlcm1pbmVzIHRoZSBTSUQsIHRoaXMg ZmllbGQgaXMgdmVyeSBsb25nICgxNgogICBvY3RldHMpIGFuZCBkb2VzIG5vdCBub3JtYWxseSBh cHBlYXIgaW4gVFdBTVAtVGVzdCBwYWNrZXRzLiAgVGhlCiAgIGZvbGxvd2luZyBpdGVtcyBNVVNU IGJlIHBhcnQgb2YgY29tcGxpYW50IGltcGxlbWVudGF0aW9ucyB1c2luZyB0aGUKICAgUmVmbGVj dCBPY3RldHMgZmVhdHVyZToKCiAgIG8gIFdoZW4gYSBTZXJ2ZXIgZG9lcyBub3QgcmVxdWlyZSBv Y3RldHMgdG8gYmUgcmV0dXJuZWQgaW4gVFdBTVAtVGVzdAogICAgICBwYWNrZXRzLCBpdCBNVVNU IHNlbmQgYWxsIHplcm9zIGluIHRoZSBTZXJ2ZXIgb2N0ZXRzIGZpZWxkCgogICBvICBXaGVuIGEg U2VydmVyIGludGVuZHMgb2N0ZXRzIHRvIGJlIHJldHVybmVkIGluIFRXQU1QLVRlc3QgcGFja2V0 cywKICAgICAgaXQgTVVTVCBzZW5kIGEgbm9uLXplcm8gdmFsdWUgaW4gdGhlIFNlcnZlciBvY3Rl dHMgZmllbGQsIGFuZCB0aGUKICAgICAgVFdBTVAtVGVzdCBTZW5kZXIgTVVTVCBpbmNsdWRlIHRo b3NlIG9jdGV0cyBhdCB0aGUgYmVnaW5uaW5nIG9mCiAgICAgIHRoZSAiUGFja2V0IFBhZGRpbmcg KHRvIGJlIHJlZmxlY3RlZCkiIGZpZWxkCgoKCgoKTW9ydG9uICYgQ2lhdmF0dG9uZSAgICAgRXhw aXJlcyBEZWNlbWJlciAxNywgMjAxMCAgICAgICAgICAgICAgIFtQYWdlIDhdCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgUmVmbGVjdCBPY3RldHMgJiBTeW1tZXRyaWMgU2l6ZSAgICAgICAgICAgSnVu ZSAyMDEwCgoKICAgbyAgU2VjdGlvbiA0LjEuMiBkZWZpbmVzIGhvdyBTZXJ2ZXIgb2N0ZXRzIE1V U1QgYmUgaW5jbHVkZWQgaW4gdGhlCiAgICAgIFRXQU1QLVRlc3QgcGFja2V0IHBhZGRpbmcgd2hl biB0aGlzIHNlcnZpY2UgaXMgZGVzaXJlZCBieSB0aGUKICAgICAgU2VydmVyIChpbmRpY2F0ZWQg aW4gdGhlIHNlY29uZCBvZiB0d28gZmlndXJlcyBpbiB0aGUgc2VjdGlvbikKCiAgIFdoZW4gc3Vw cG9ydGluZyB0aGUgUkVDT01NRU5ERUQgdHJ1bmNhdGlvbiBwcm9jZXNzIGluIFRXQU1QIHNlY3Rp b24KICAgNC4yLjEgW1JGQzUzNTddLCBJRiBjYWxjdWxhdGlvbnMgb24gdGhlIFBhZGRpbmcgbGVu Z3RocyByZXZlYWwgdGhhdAogICB0aGVyZSBhcmUgaW5zdWZmaWNpZW50IG9jdGV0cyBzdXBwbGll ZCB0byBwcm9kdWNlIGVxdWFsLWxlbmd0aAogICBTZXNzaW9uLVNlbmRlciBhbmQgU2Vzc2lvbi1S ZWZsZWN0b3IgdGVzdCBwYWNrZXRzLCB0aGVuIHRoZSBBY2NlcHQKICAgRmllbGQgTVVTVCBiZSBz ZXQgdG8gMyA9IHNvbWUgYXNwZWN0IG9mIHRoZSByZXF1ZXN0IGlzIG5vdCBzdXBwb3J0ZWQuCgoz LjQuICBBZGRpdGlvbmFsIGNvbnNpZGVyYXRpb25zCgogICBUaGUgdmFsdWUgb2YgdGhlIE1vZGVz IEZpZWxkIHNlbnQgYnkgdGhlIFNlcnZlciBpbiB0aGUgU2VydmVyCiAgIEdyZWV0aW5nIG1lc3Nh Z2UgaXMgdGhlIGJpdC13aXNlIE9SIG9mIHRoZSBtb2RlIHZhbHVlcyB0aGF0IGl0IGlzCiAgIHdp bGxpbmcgdG8gc3VwcG9ydCBkdXJpbmcgdGhpcyBzZXNzaW9uLgoKICAgV2l0aCB0aGUgcHVibGlj YXRpb24gb2YgdGhpcyBtZW1vIGFzIGFuIFJGQywgdGhlIGxhc3QgNyBiaXQgcG9zaXRpb25zCiAg IG9mIHRoZSBNb2RlcyAzMi1iaXQgRmllbGQgYXJlIHVzZWQuICBBIENvbnRyb2wtQ2xpZW50IGNv bmZvcm1pbmcgdG8KICAgdGhpcyBleHRlbnNpb24gb2YgW1JGQzUzNTddIE1BWSBpZ25vcmUgdGhl IHZhbHVlcyBpbiB0aGUgaGlnaGVyIGJpdHMKICAgb2YgdGhlIE1vZGVzIEZpZWxkLCBvciBpdCBN QVkgc3VwcG9ydCBvdGhlciBmZWF0dXJlcyB0aGF0IGFyZQogICBjb21tdW5pY2F0ZWQgaW4gdGhv c2UgYml0IHBvc2l0aW9ucy4gIFRoZSBvdGhlciBiaXRzIGFyZSBhdmFpbGFibGUKICAgZm9yIGZ1 dHVyZSBwcm90b2NvbCBleHRlbnNpb25zLgoKCjQuICBFeHRlbmRlZCBUV0FNUCBUZXN0CgogICBU aGUgVFdBTVAgdGVzdCBwcm90b2NvbCBpcyBzaW1pbGFyIHRvIHRoZSBPV0FNUCBbUkZDNDY1Nl0g dGVzdAogICBwcm90b2NvbCB3aXRoIHRoZSBleGNlcHRpb24gdGhhdCB0aGUgU2Vzc2lvbi1SZWZs ZWN0b3IgdHJhbnNtaXRzIHRlc3QKICAgcGFja2V0cyB0byB0aGUgU2Vzc2lvbi1TZW5kZXIgaW4g cmVzcG9uc2UgdG8gZWFjaCB0ZXN0IHBhY2tldCBpdAogICByZWNlaXZlcy4gIFRXQU1QIHNlY3Rp b24gNFtSRkM1MzU3XSBkZWZpbmVzIHR3byBhZGRpdGlvbmFsIHRlc3QKICAgcGFja2V0IGZvcm1h dHMgZm9yIHBhY2tldHMgdHJhbnNtaXR0ZWQgYnkgdGhlIFNlc3Npb24tUmVmbGVjdG9yLiAgVGhl CiAgIGFwcHJvcHJpYXRlIGZvcm1hdCBkZXBlbmRzIG9uIHRoZSBzZWN1cml0eSBtb2RlIGNob3Nl bi4gIFRoZSBuZXcKICAgbW9kZXMgc3BlY2lmaWVkIGhlcmUgdXRpbGl6ZSBzb21lIG9mIHRoZSBw YWRkaW5nIG9jdGV0cyB3aXRoaW4gZWFjaAogICB0ZXN0IHBhY2tldCBmb3JtYXQsIG9yIHJlcXVp cmUgdHJ1bmNhdGlvbiBvZiB0aG9zZSBvY3RldHMgZGVwZW5kaW5nCiAgIG9uIHRoZSBzZWN1cml0 eSBtb2RlIGluIHVzZS4KCjQuMS4gIFNlbmRlciBCZWhhdmlvcgoKICAgVGhpcyBzZWN0aW9uIGRl c2NyaWJlcyBleHRlbnNpb25zIHRvIHRoZSBiZWhhdmlvciBvZiB0aGUgVFdBTVAKICAgU2Vzc2lv bi1TZW5kZXIuCgo0LjEuMS4gIFBhY2tldCBUaW1pbmdzCgogICBUaGUgU2VuZCBTY2hlZHVsZSBp cyBub3QgdXRpbGl6ZWQgaW4gVFdBTVAsIGFuZCB0aGlzIGlzIHVuY2hhbmdlZCBpbgogICB0aGlz IG1lbW8uCgoKCgoKCk1vcnRvbiAmIENpYXZhdHRvbmUgICAgIEV4cGlyZXMgRGVjZW1iZXIgMTcs IDIwMTAgICAgICAgICAgICAgICBbUGFnZSA5XQoMCkludGVybmV0LURyYWZ0ICAgICAgIFJlZmxl Y3QgT2N0ZXRzICYgU3ltbWV0cmljIFNpemUgICAgICAgICAgIEp1bmUgMjAxMAoKCjQuMS4yLiAg UmVmbGVjdCBPY3RldHM6IFBhY2tldCBGb3JtYXRzIGFuZCBDb250ZW50cwoKICAgVGhlIFNlc3Np b24tU2VuZGVyIHBhY2tldCBmb3JtYXQgYW5kIGNvbnRlbnQgZm9sbG93IHRoZSBzYW1lCiAgIHBy b2NlZHVyZSBhbmQgZ3VpZGVsaW5lcyBhcyBkZWZpbmVkIGluIHNlY3Rpb24gNC4xLjIgb2YgW1JG QzQ2NTZdIChhcwogICBpbmRpY2F0ZWQgaW4gc2VjdGlvbiA0LjEuMiBvZiBUV0FNUCBbUkZDNTM1 N10pLgoKICAgVGhlIFJlZmxlY3Qgb2N0ZXRzIG1vZGUgcmUtZGVzaWduYXRlcyB0aGUgb3JpZ2lu YWwgVFdBTVAtVGVzdCAoYW5kCiAgIE9XQU1QLVRlc3QpIFBhY2tldCBQYWRkaW5nIEZpZWxkIChz ZWUgc2VjdGlvbiA0LjEuMiBvZiBbUkZDNDY1Nl0pLCBhcwogICBzaG93biBiZWxvdyBmb3IgdW5h dXRoZW50aWNhdGVkIG1vZGU6CgogICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAg ICAgICAgIDIgICAgICAgICAgICAgICAgICAgMwogICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEg MiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxCiAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwg ICAgICAgICAgICAgICAgICAgICAgICBTZXF1ZW5jZSBOdW1iZXIgICAgICAgICAgICAgICAgICAg ICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIFRpbWVzdGFt cCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAg IHwgICAgICAgICBFcnJvciBFc3RpbWF0ZSAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICArCiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwgICAgICAgICAgICAgICAgICBQ YWNrZXQgUGFkZGluZyAodG8gYmUgcmVmbGVjdGVkKSAgICAgICAgICAgICB8CiAgIC4gICAgICAg ICAgICAgICAobGVuZ3RoIGluIG9jdGV0cyBzcGVjaWZpZWQgaW4gY29tbWFuZCkgICAgICAgICAu CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rCiAgIC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAuCiAgIC4gICAgICAgICAgICAgICAgICBBZGRpdGlvbmFs IFBhY2tldCBQYWRkaW5nICAgICAgICAgICAgICAgICAgICAuCiAgIC4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuCiAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rCgogICBUaGUgIlBhY2tldCBQYWRkaW5nICh0byBiZSByZWZsZWN0ZWQpIiBGaWVsZCBTSEFM TCBjb3JyZXNwb25kIHRvIHRoZQogICBsZW5ndGggb2Ygb2N0ZXRzIHNwZWNpZmllZCBpbiB0aGUg UmVxdWVzdC1UVy1TZXNzaW9uICJMZW5ndGggb2YKICAgcGFkZGluZyB0byByZWZsZWN0IiBGaWVs ZCB0byB0aGlzIHRlc3Qgc2Vzc2lvbi4gIFRoZXNlIGFyZSB0aGUgb2N0ZXRzCiAgIHRoYXQgdGhl IFNlc3Npb24tU2VuZGVyIGV4cGVjdHMgd2lsbCBiZSByZXR1cm5lZCBieSB0aGUgU2Vzc2lvbi0K ICAgUmVmbGVjdG9yLgoKICAgVGhlIGxlbmd0aCBvZiB0aGUgIkFkZGl0aW9uYWwgUGFja2V0IFBh ZGRpbmciIEZpZWxkIGlzIHRoZSBkaWZmZXJlbmNlCiAgIGJldHdlZW4gdHdvIGZpZWxkcyBpbiB0 aGUgUmVxdWVzdC1UVy1TZXNzaW9uIGNvbW1hbmQsIGFzIGZvbGxvd3M6CgogICAiQWRkaXRpb25h bCBQYWNrZXQgUGFkZGluZyIsIGluIG9jdGV0cyA9CgogICAiUGFkZGluZyBMZW5ndGgiIC0gIkxl bmd0aCBvZiBwYWRkaW5nIHRvIHJlZmxlY3QiCgogICBXaGVuIGEgU2VydmVyIGludGVuZHMgb2N0 ZXRzIHRvIGJlIHJldHVybmVkIGluIFRXQU1QLVRlc3QgcGFja2V0cywgaXQKICAgTVVTVCBzZW5k IGEgbm9uLXplcm8gdmFsdWUgaW4gdGhlIFNlcnZlciBvY3RldHMgZmllbGQsIGFuZCB0aGUgVFdB TVAtCiAgIFRlc3QgU2Vzc2lvbi1TZW5kZXIgTVVTVCBpbmNsdWRlIHRob3NlIG9jdGV0cyBpbiB0 aGUgZmlyc3QgMiBvY3RldHMKICAgb2YgdGhlICJQYWNrZXQgUGFkZGluZyAodG8gYmUgcmVmbGVj dGVkKSIgRmllbGQgYXMgc2hvd24gYmVsb3c6CgoKCgoKTW9ydG9uICYgQ2lhdmF0dG9uZSAgICAg RXhwaXJlcyBEZWNlbWJlciAxNywgMjAxMCAgICAgICAgICAgICAgW1BhZ2UgMTBdCgwKSW50ZXJu ZXQtRHJhZnQgICAgICAgUmVmbGVjdCBPY3RldHMgJiBTeW1tZXRyaWMgU2l6ZSAgICAgICAgICAg SnVuZSAyMDEwCgoKICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAy ICAgICAgICAgICAgICAgICAgIDMKICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUg NiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICBTZXJ2ZXIgb2N0ZXRzICAgICAgICAgfAog ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKwogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfAogICB8ICAgICAgICAgICAgICAgICAgUGFja2V0IFBhZGRp bmcgKHRvIGJlIHJlZmxlY3RlZCkgICAgICAgICAgICAgfAogICAuICAgICAgICAgICAgICAgKGxl bmd0aCBpbiBvY3RldHMgc3BlY2lmaWVkIGVsc2V3aGVyZSkgICAgICAgICAgLgogICAuICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg LgogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKwoKICAgVGhlICJTZXJ2ZXIgb2N0ZXRzIiBmaWVsZCBjb250YWlucyB0aGUg c2FtZSBpbmZvcm1hdGlvbiB0aGF0IHRoZQogICBTZXJ2ZXIgcmV0dXJuZWQgdG8gdGhlIENvbnRy b2wtQ2xpZW50IGluIHRoZSBBY2NlcHQtU2Vzc2lvbiBtZXNzYWdlCiAgIGNvcnJlc3BvbmRpbmcg dG8gdGhpcyBzcGVjaWZpYyB0ZXN0IHNlc3Npb24gKHNlZSBzZWN0aW9uIDMuMykuICBBdAogICB0 aGUgU2Vzc2lvbi1SZWZsZWN0b3IsIHRoZXNlIG9jdGV0cyBNVVNUIGJlIHJlZmxlY3RlZCB0aGUg c2FtZSBhcyB0aGUKICAgcmVzdCBvZiB0aGUgIlBhY2tldCBQYWRkaW5nICh0byBiZSByZWZsZWN0 ZWQpIiBmaWVsZC4KCiAgIE5vdGUgdGhhdCBpdCBpcyBwZXJtaXNzaWJsZSBmb3IgdGhlIFNlc3Np b24tU2VuZGVyIHRvIGluc2VydCB0aGUgc2FtZQogICBvY3RldHMgdXNlZCBpbiB0aGUgIk9jdGV0 cyB0byBiZSByZWZsZWN0ZWQiIGZpZWxkIG9mIHRoZSBSZXF1ZXN0LVRXLQogICBTZXNzaW9uIGNv bW1hbmQgZWxzZXdoZXJlIGluIHRoZSAiUGFja2V0IFBhZGRpbmcgKHRvIGJlIHJlZmxlY3RlZCki CiAgIGZpZWxkLgoKNC4xLjMuICBSZWZsZWN0IE9jdGV0czogSW50ZXJhY3Rpb24gd2l0aCBQYWRk aW5nIFRydW5jYXRpb24KCiAgIFdoZW4gdGhlIFJlZmxlY3QgT2N0ZXRzIG1vZGUgaXMgc2VsZWN0 ZWQsIGFuZCB0aGUgUkVDT01NRU5ERUQKICAgdHJ1bmNhdGlvbiBwcm9jZXNzIGluIFRXQU1QIHNl Y3Rpb24gNC4yLjEgW1JGQzUzNTddIGlzIHN1cHBvcnRlZCwgdGhlCiAgIFNlc3Npb24tU2VuZGVy IE1VU1QgYW50aWNpcGF0ZSBhIG1pbmltdW0gcGFkZGluZyByZXF1aXJlZCB0byBhY2hpZXZlCiAg IGVxdWFsIHNpemUgdGVzdCBwYWNrZXRzIGluIGJvdGggZGlyZWN0aW9ucy4gIFRoZSBhbW91bnQg b2YgcGFkZGluZwogICBuZWVkZWQgdG8gYWNoaWV2ZSBzeW1tZXRyaWNhbCBwYWNrZXQgc2l6ZSBk ZXBlbmRzIG9uIEJPVEggdGhlCiAgIHNlY3VyaXR5IG1vZGUgKFVuYXV0aGVudGljYXRlZC9BdXRo ZW50aWNhdGVkL0VuY3J5cHRlZCkgYW5kIHdoZXRoZXIKICAgdGhlIFJlZmxlY3QgT2N0ZXRzIG1v ZGUgaXMgc2VsZWN0ZWQgc2ltdWx0YW5lb3VzbHkuCgogICBXaGVuIHVzaW5nIHRoZSBSRUNPTU1F TkRFRCB0cnVuY2F0aW9uIHByb2Nlc3MgaW4gVFdBTVAgc2VjdGlvbiA0LjIuMQogICBbUkZDNTM1 N10gYWxvbmUsIHRoZSBTZXNzaW9uLVNlbmRlciBNVVNUIGFwcGVuZCBzdWZmaWNpZW50IFBhY2tl dAogICBQYWRkaW5nIG9jdGV0cyB0byBhbGxvdyB0aGUgc2FtZSBJUCBwYWNrZXQgcGF5bG9hZCBs ZW5ndGhzIHRvIGJlIHVzZWQKICAgaW4gZWFjaCBkaXJlY3Rpb24gb2YgdHJhbnNtaXNzaW9uICh0 aGlzIGlzIHVzdWFsbHkgZGVzaXJhYmxlKS4gIFRvCiAgIGNvbXBlbnNhdGUgZm9yIHRoZSBTZXNz aW9uLVJlZmxlY3RvcidzIGxhcmdlciB0ZXN0IHBhY2tldCBmb3JtYXQsIHRoZQogICBTZXNzaW9u LVNlbmRlciBNVVNUIGFwcGVuZCBhdCBsZWFzdCAyNyBvY3RldHMgb2YgcGFkZGluZyBpbgogICBV bmF1dGhlbnRpY2F0ZWQgbW9kZSwgYW5kIGF0IGxlYXN0IDU2IG9jdGV0cyBpbiBBdXRoZW50aWNh dGVkIGFuZAogICBFbmNyeXB0ZWQgbW9kZXMuICBUaGUgc2l6ZXMgb2YgVFdBTVAgVGVzdCBwcm90 b2NvbCBwYWNrZXRzIGFuZCB0aGUKICAgcmVzdWx0aW5nIHRydW5jYXRlZCBwYWRkaW5nIHRvIGFj aGlldmUgZXF1YWwgcGFja2V0IHNpemVzIGluIGJvdGgKICAgZGlyZWN0aW9ucyBhcmUgc2hvd24g aW4gdGhlIHRhYmxlIGJlbG93OgoKCgoKCgoKCgpNb3J0b24gJiBDaWF2YXR0b25lICAgICBFeHBp cmVzIERlY2VtYmVyIDE3LCAyMDEwICAgICAgICAgICAgICBbUGFnZSAxMV0KDApJbnRlcm5ldC1E cmFmdCAgICAgICBSZWZsZWN0IE9jdGV0cyAmIFN5bW1ldHJpYyBTaXplICAgICAgICAgICBKdW5l IDIwMTAKCgogICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICB8IE9jdGV0cyBpbjogICAgICAgIHwgVW5hdXRoZW50 aWNhdGVkIE1vZGUgfCBBdXRoL0VuY3J5cHRlZCBNb2RlIHwKICAgICstLS0tLS0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICAgfCBS ZWZsZWN0b3IgSGVhZGVyICB8IDQxICAgICAgICAgICAgICAgICAgIHwgMTA0ICAgICAgICAgICAg ICAgICB8CiAgICB8IFNlbmRlciBIZWFkZXIgICAgIHwgMTQgICAgICAgICAgICAgICAgICAgfCA0 OCAgICAgICAgICAgICAgICAgIHwKICAgIHwgVHJ1bmNhdGVkIFBhZGRpbmcgfCAyNyAgICAgICAg ICAgICAgICAgICB8IDU2ICAgICAgICAgICAgICAgICAgfAogICAgKy0tLS0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0rCgogICAgICAg ICAgICAgICAgICAgICAgIFRXQU1QLVRlc3QgUGFkZGluZyBUcnVuY2F0aW9uCgogICBXaGVuIHVz aW5nIHRoZSBSZWZsZWN0IE9jdGV0cyBtb2RlIHNpbXVsdGFuZW91c2x5IHdpdGggdGhlCiAgIFJF Q09NTUVOREVEIHRydW5jYXRpb24gcHJvY2VzcyBpbiBUV0FNUCBzZWN0aW9uIDQuMi4xIFtSRkM1 MzU3XSwgdGhlCiAgIFNlc3Npb24tU2VuZGVyIE1VU1QgYXBwZW5kIGF0IGxlYXN0IDI3IG9jdGV0 cyBvZiBwYWRkaW5nIHBsdXMgdGhlCiAgICJMZW5ndGggb2YgdGhlIHBhZGRpbmcgdG8gcmVmbGVj dCIgb2N0ZXRzIHdoZW4gb3BlcmF0aW5nIGluCiAgIFVuYXV0aGVudGljYXRlZCBtb2RlLiAgVGhl IFNlc3Npb24tU2VuZGVyIE1VU1QgYXBwZW5kIGF0IGxlYXN0IDU2CiAgIG9jdGV0cyBvZiBwYWRk aW5nIHBsdXMgdGhlICJMZW5ndGggb2YgdGhlIHBhZGRpbmcgdG8gcmVmbGVjdCIgb2N0ZXRzCiAg IHdoZW4gb3BlcmF0aW5nIGluIEF1dGhlbnRpY2F0ZWQgYW5kIEVuY3J5cHRlZCBtb2Rlcy4KCjQu MS40LiAgU3ltbWV0cmljYWwgU2l6ZTogU2Vzc2lvbi1TZW5kZXIgUGFja2V0IEZvcm1hdAoKICAg V2hlbiB0aGUgU3ltbWV0cmljYWwgU2l6ZSBtb2RlIGlzIHNlbGVjdGVkLCB0aGUgU2Vzc2lvbi1T ZW5kZXIgU0hBTEwKICAgdXNlIHRoZSBmb2xsb3dpbmcgVFdBTVAtVGVzdCBQYWNrZXQgRm9ybWF0 IGluIFVuYXV0aGVudGljYXRlZCBtb2RlOgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCk1v cnRvbiAmIENpYXZhdHRvbmUgICAgIEV4cGlyZXMgRGVjZW1iZXIgMTcsIDIwMTAgICAgICAgICAg ICAgIFtQYWdlIDEyXQoMCkludGVybmV0LURyYWZ0ICAgICAgIFJlZmxlY3QgT2N0ZXRzICYgU3lt bWV0cmljIFNpemUgICAgICAgICAgIEp1bmUgMjAxMAoKCiAgIFVuYXV0aGVudGljYXRlZCBNb2Rl CiAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAg ICAgICAgICAzCiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx IDIgMyA0IDUgNiA3IDggOSAwIDEKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgfCAgICAgICAgICAgICAgICAgICAg ICAgIFNlcXVlbmNlIE51bWJlciAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsK ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgVGltZXN0YW1wICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwKICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgfCAgICAgICAgIEVycm9yIEVz dGltYXRlICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICsKICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwKICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCAgICAgICAgICAgICAgICAgICAgICAgICBN QlogKDI3IG9jdGV0cykgICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwKICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwKICAgKyAgICAgICAgICAgICAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgfCAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgKy0rLSstKy0rLSst Ky0rLSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICsKICAg LiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIC4KICAgLiAgICAgICAgICAgICAgICAgICAgICAgIFBhY2tldCBQYWRkaW5nICAgICAg ICAgICAgICAgICAgICAgICAgIC4KICAgLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4KICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKCiAgIFRoaXMgZmVh dHVyZSBSRVFVSVJFUyBvbmx5IGEgbmV3IFNlc3Npb24tU2VuZGVyIHRlc3QgcGFja2V0IGZvcm1h dCwKICAgdGhlIFNlc3Npb24tUmVmbGVjdG9yIHRlc3QgcGFja2V0IGZvcm1hdCBpcyB1bmNoYW5n ZWQuCgo0LjEuNS4gIFN5bW1ldHJpY2FsIFNpemUgQU5EIFJlZmxlY3QgT2N0ZXRzOiBTZXNzaW9u LVNlbmRlciBQYWNrZXQKICAgICAgICBGb3JtYXQKCiAgIFdoZW4gQk9USCB0aGUgU3ltbWV0cmlj YWwgU2l6ZSBtb2RlIGFuZCB0aGUgUmVmbGVjdCBPY3RldHMgbW9kZSBhcmUKICAgc2VsZWN0ZWQs IHRoZSBTZXNzaW9uLVNlbmRlciBTSEFMTCB1c2UgdGhlIGZvbGxvd2luZyBUV0FNUC1UZXN0CiAg IFBhY2tldCBGb3JtYXQgaW4gVW5hdXRoZW50aWNhdGVkIG1vZGU6CgoKCgoKCgoKCgoKCgoKCgoK TW9ydG9uICYgQ2lhdmF0dG9uZSAgICAgRXhwaXJlcyBEZWNlbWJlciAxNywgMjAxMCAgICAgICAg ICAgICAgW1BhZ2UgMTNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgUmVmbGVjdCBPY3RldHMgJiBT eW1tZXRyaWMgU2l6ZSAgICAgICAgICAgSnVuZSAyMDEwCgoKICAgVW5hdXRoZW50aWNhdGVkIE1v ZGUKICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAg ICAgICAgICAgIDMKICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAw IDEgMiAzIDQgNSA2IDcgOCA5IDAgMQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgICAgICAgICAgICAgICAg ICAgICAgU2VxdWVuY2UgTnVtYmVyICAgICAgICAgICAgICAgICAgICAgICAgfAogICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst KwogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICBUaW1lc3RhbXAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfAogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgICAgICAgRXJyb3Ig RXN0aW1hdGUgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgKwogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfAogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8ICAgICAgICAgICAgICAgICAgICAgICAg IE1CWiAoMjcgb2N0ZXRzKSAgICAgICAgICAgICAgICAgICAgICAgfAogICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfAogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfAogICArICAgICAgICAgICAgICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICArLSstKy0rLSst Ky0rLSstKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKwog ICB8ICAgICAgICAgICAgICAgICAgUGFja2V0IFBhZGRpbmcgKHRvIGJlIHJlZmxlY3RlZCkgICAg ICAgICAgICAgfAogICAuICAgICAgICAgICAgICAgKGxlbmd0aCBpbiBvY3RldHMgc3BlY2lmaWVk IGluIGNvbW1hbmQpICAgICAgICAgLgogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAuICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLgogICAuICAgICAg ICAgICAgICAgICAgQWRkaXRpb25hbCBQYWNrZXQgUGFkZGluZyAgICAgICAgICAgICAgICAgICAg LgogICAuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgLgogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKwoKICAgSW4gdGhpcyBjb21iaW5lZCBtb2RlLCB0aGUg UGFja2V0IFBhZGRpbmcgdG8gYmUgcmVmbGVjdGVkIGZvbGxvd3MgdGhlCiAgIDI3IE1CWiBvY3Rl dHMuICBJbiBBdXRoZW50aWNhdGVkIG9yIEVuY3J5cHRlZCBtb2RlcywgdGhlIFBhY2tldAogICBQ YWRkaW5nIHRvIGJlIHJlZmxlY3RlZCBmb2xsb3dzIHRoZSA1NiBNQlogb2N0ZXRzLgoKNC4yLiAg UmVmbGVjdG9yIEJlaGF2aW9yCgogICBUaGUgVFdBTVAgUmVmbGVjdG9yIGZvbGxvd3MgdGhlIHBy b2NlZHVyZXMgYW5kIGd1aWRlbGluZXMgaW4gc2VjdGlvbgogICA0LjIgb2YgW1JGQzUzNTddLCB3 aXRoIHRoZSBmb2xsb3dpbmcgYWRkaXRpb25hbCBmdW5jdGlvbnM6CgogICBvICBSZWZsZWN0IE9j dGV0cyBtb2RlOiBEZXNpZ25hdGVkIG9jdGV0cyBpbiB0aGUgIlBhY2tldCBQYWRkaW5nICh0bwog ICAgICBiZSByZWZsZWN0ZWQpIiBmaWVsZCBvZiB0aGUgU2Vzc2lvbi1TZW5kZXIncyB0ZXN0IHBh Y2tldCBNVVNUIGJlCiAgICAgIGluY2x1ZGVkIGluIHRoZSBTZXNzaW9uLVJlZmxlY3RvcidzIHRl c3QgcGFja2V0LgoKICAgbyAgU3ltbWV0cmljYWwgU2l6ZSBtb2RlOiBUaGUgU2Vzc2lvbi1SZWZs ZWN0b3IgTVVTVCBvcGVyYXRlIHVzaW5nCiAgICAgIHRoZSBTZXNzaW9uX1JlZmxlY3RvciBQYWNr ZXQgRm9ybWF0IGRlZmluZWQgaW4gc2VjdGlvbiA0LjEuNCwKICAgICAgd2hlcmUgdGhlIFBhZGRp bmcgT2N0ZXRzIGFyZSBzZXBhcmF0ZWQgZnJvbSB0aGUgaW5mb3JtYXRpb24KICAgICAgZmllbGRz LgoKCgoKCgpNb3J0b24gJiBDaWF2YXR0b25lICAgICBFeHBpcmVzIERlY2VtYmVyIDE3LCAyMDEw ICAgICAgICAgICAgICBbUGFnZSAxNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICBSZWZsZWN0IE9j dGV0cyAmIFN5bW1ldHJpYyBTaXplICAgICAgICAgICBKdW5lIDIwMTAKCgo0LjIuMS4gIFJlZmxl Y3QgT2N0ZXRzOiBTZXNzaW9uLVJlZmxlY3RvciBQYWNrZXQgRm9ybWF0IGFuZCBDb250ZW50cwoK ICAgVGhlIFJlZmxlY3QgUGFkZGluZyBmZWF0dXJlIHJlLWRlc2lnbmF0ZXMgdGhlIHBhY2tldCBw YWRkaW5nIGZpZWxkLAogICBhcyBzaG93biBiZWxvdy4gIFdoZW4gdGhlIFJlZmxlY3QgT2N0ZXRz IG1vZGUgaXMgc2VsZWN0ZWQsIHRoZQogICBTZXNzaW9uLVNlbmRlciBTSEFMTCB1c2UgdGhlIGZv bGxvd2luZyBUV0FNUC1UZXN0IFBhY2tldCBGb3JtYXQgaW4KICAgVW5hdXRoZW50aWNhdGVkIG1v ZGU6CgogICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAg ICAgICAgICAgICAgMwogICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxCiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgfCAgICAgICAgICAgICAg ICAgICAgICAgIFNlcXVlbmNlIE51bWJlciAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rCiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICBUaW1lc3RhbXAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfAogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICB8ICAgICAg ICAgRXJyb3IgRXN0aW1hdGUgICAgICAgIHwgICAgICAgICAgIE1CWiAgICAgICAgICAgICAgICAg fAogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsKICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIFJlY2VpdmUgVGlt ZXN0YW1wICAgICAgICAgICAgICAgICAgICB8CiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAg IHwgICAgICAgICAgICAgICAgICAgICAgICBTZW5kZXIgU2VxdWVuY2UgTnVtYmVyICAgICAgICAg ICAgICAgICB8CiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKwogICAgfCAgICAgICAgICAgICAgICAgICAgICBTZW5kZXIg VGltZXN0YW1wICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKwogICAgfCAgICAgIFNlbmRlciBFcnJvciBFc3RpbWF0ZSAgICB8ICAgICAgICAgICBNQlog ICAgICAgICAgICAgICAgIHwKICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICB8ICBTZW5kZXIgVFRMICAgfCAgICAg ICAgIFBhY2tldCBQYWRkaW5nIChmcm9tIFNlc3Npb24tU2VuZGVyKSAgfAogICAgKy0rLSstKy0r LSstKy0rLSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICsK ICAgIC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAuCiAgICArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICArLSstKy0rLSstKy0rLSstKwogICAgfCAgICAgICAgICBQYWNrZXQgUGFkZGluZyAo ZnJvbSBTZXNzaW9uLVNlbmRlcikgfCAgICAgICAgICAgICAgIHwKICAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgICAgICAgICAgICAgICArCiAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfAogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwKICAgIC4gICAgICAgICAgICAgICAgICBBZGRpdGlvbmFsIFBh Y2tldCBQYWRkaW5nICAgICAgICAgICAgICAgICAgICAuCiAgICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICBUaGUgIlBh Y2tldCBQYWRkaW5nIChmcm9tIFNlc3Npb24tU2VuZGVyKSIgZmllbGQgTVVTVCBiZSB0aGUgc2Ft ZQogICBvY3RldHMgYXMgdGhlICJQYWNrZXQgUGFkZGluZyAodG8gYmUgcmVmbGVjdGVkKSIgZmll bGQgaW4gdGhlCiAgIFNlc3Npb24tU2VuZGVyJ3MgdGVzdCBwYWNrZXQsIGFuZCB0aGVyZWZvcmUg TVVTVCBjb25mb3JtIHRvIHRoZQogICBsZW5ndGggc3BlY2lmaWVkIGluIHRoZSBSZXF1ZXN0LVRX LVNlc3Npb24gbWVzc2FnZS4KCiAgIFdoZW4gdGhlIFNlcnZlciBoYXMgcmV0dXJuZWQgYSBub24t emVybyB2YWx1ZSBpbiB0aGUgIlNlcnZlciBvY3RldHMiCiAgIGZpZWxkIG9mIHRoZSBBY2NlcHQg U2Vzc2lvbiBtZXNzYWdlIChhcyBkZXNjcmliZWQgaW4gc2VjdGlvbiAzLjMpLAogICB0aGVuIHRo ZSBTZXNzaW9uLVJlZmxlY3RvciBTSEFMTCByZWZsZWN0IHRoZXNlIG9jdGV0cyB0aGUgc2FtZSBh cyB0aGUKICAgcmVzdCBvZiB0aGUgIlBhY2tldCBQYWRkaW5nICh0byBiZSByZWZsZWN0ZWQpIiBG aWVsZC4KCiAgIFdoZW4gc2ltdWx0YW5lb3VzbHkgdXNpbmcgdGhlIFJFQ09NTUVOREVEIHRydW5j YXRpb24gcHJvY2VzcyBpbiBUV0FNUAoKCgpNb3J0b24gJiBDaWF2YXR0b25lICAgICBFeHBpcmVz IERlY2VtYmVyIDE3LCAyMDEwICAgICAgICAgICAgICBbUGFnZSAxNV0KDApJbnRlcm5ldC1EcmFm dCAgICAgICBSZWZsZWN0IE9jdGV0cyAmIFN5bW1ldHJpYyBTaXplICAgICAgICAgICBKdW5lIDIw MTAKCgogICBzZWN0aW9uIDQuMi4xIFtSRkM1MzU3XSBBTkQgUmVmbGVjdCBvY3RldHMgbW9kZSwg dGhlIFNlc3Npb24tCiAgIFJlZmxlY3RvciBNVVNUIHJlZmxlY3QgdGhlIGRlc2lnbmF0ZWQgb2N0 ZXRzIGZyb20gdGhlIFNlc3Npb24tCiAgIFNlbmRlcidzIHRlc3QgcGFja2V0IGluIHRoZSAiUGFj a2V0IFBhZGRpbmcgKGZyb20gU2Vzc2lvbi1TZW5kZXIpIgogICBGaWVsZCwgYW5kIE1BWSByZS11 c2UgYWRkaXRpb25hbCBQYWNrZXQgUGFkZGluZyBmcm9tIHRoZSBTZXNzaW9uLQogICBTZW5kZXIu ICBUaGUgU2Vzc2lvbi1SZWZsZWN0b3IgTVVTVCB0cnVuY2F0ZSB0aGUgcGFkZGluZyBzdWNoIHRo YXQKICAgdGhlIGhpZ2hlc3QgbnVtYmVyIG9jdGV0cyBhcmUgZGlzY2FyZGVkLCBhbmQgdGhlIHRl c3QgcGFja2V0IGxlbmd0aAogICBlcXVhbHMgdGhlIFNlc3Npb24tU2VuZGVyJ3MgcGFja2V0IGxl bmd0aC4gIFdoZW4gdXNpbmcgdGhlCiAgIFJFQ09NTUVOREVEIHRydW5jYXRpb24gcHJvY2Vzcywg dGhlIFNlc3Npb24tUmVmbGVjdG9yIE1VU1QgdHJ1bmNhdGUKICAgZXhhY3RseSAyNyBvY3RldHMg b2YgcGFkZGluZyBpbiBVbmF1dGhlbnRpY2F0ZWQgbW9kZSwgYW5kIGV4YWN0bHkgNTYKICAgb2N0 ZXRzIGluIEF1dGhlbnRpY2F0ZWQgYW5kIEVuY3J5cHRlZCBtb2Rlcy4KCiAgIFRoZSBTZXNzaW9u LVJlZmxlY3RvciBNQVkgcmUtdXNlIHRoZSBTZW5kZXIncyBQYWNrZXQgUGFkZGluZyAoc2luY2UK ICAgdGhlIHJlcXVpcmVtZW50cyBmb3IgcGFkZGluZyBnZW5lcmF0aW9uIGFyZSB0aGUgc2FtZSBm b3IgZWFjaCkuCgo0LjIuMi4gIFN5bW1ldHJpY2FsIFNpemU6IFNlc3Npb24tUmVmbGVjdG9yIFBh Y2tldCBGb3JtYXQKCiAgIFdoZW4gU3ltbWV0cmljYWwgU2l6ZSBtb2RlIGlzIHNlbGVjdGVkLCB0 aGUgU2Vzc2lvbi1TZW5kZXIgcGFja2V0CiAgIGZvcm1hdHMgZm9yIHVuYXV0aGVudGljYXRlZCBh bmQgYXV0aGVudGljYXRlZC9lbmNyeXB0ZWQgbW9kZXMgYXJlCiAgIGlkZW50aWNhbCB0byB0aGUg Y29yZSBUV0FNUCBzcGVjaWZpY2F0aW9uLCBzZWN0aW9uIDQuMi4xIG9mCiAgIFtSRkM1MzU3XS4g IFRodXMsIHRoZSBTZXNzaW9uLVJlZmxlY3RvciB0ZXN0IHBhY2tldCBmb3JtYXQgaXMKICAgdW5j aGFuZ2VkLgoKICAgVGhlIFNlc3Npb24tUmVmbGVjdG9yIE1VU1QgY29uc3RydWN0IGl0cyB0ZXN0 IHBhY2tldCB1c2luZyB0aGUKICAgaW5mb3JtYXRpb24gaW4gdGhlIFNlc3Npb24tU2VuZGVyJ3Mg dGVzdCBwYWNrZXQuICBUaGUgbGVuZ3RoIG9mIHRoZQogICBTZXNzaW9uLVJlZmxlY3RvcidzIHRl c3QgcGFja2V0IFNIQUxMIGVxdWFsIHRoZSBsZW5ndGggb2YgdGhlCiAgIFNlc3Npb24tU2VuZGVy J3MgdGVzdCBwYWNrZXQuCgo0LjIuMy4gIFN5bW1ldHJpY2FsIFNpemUgQU5EIFJlZmxlY3QgT2N0 ZXRzOiBTZXNzaW9uLVNlbmRlciBQYWNrZXQKICAgICAgICBGb3JtYXQKCiAgIFdoZW4gQk9USCB0 aGUgU3ltbWV0cmljYWwgU2l6ZSBtb2RlIGFuZCB0aGUgUmVmbGVjdCBPY3RldHMgbW9kZSBhcmUK ICAgc2VsZWN0ZWQsIHRoZSBTZXNzaW9uLVJlZmxlY3RvciBNVVNUIG9wZXJhdGUgdXNpbmcgdGhl CiAgIFNlc3Npb25fUmVmbGVjdG9yIFBhY2tldCBGb3JtYXQgZGVmaW5lZCBpbiBzZWN0aW9uIDQu MS41LCB3aGVyZSB0aGUKICAgUGFkZGluZyBPY3RldHMgYXJlIHNlcGFyYXRlZCBmcm9tIHRoZSBp bmZvcm1hdGlvbiBmaWVsZHMsIGFuZCB0aGUKICAgUGFkZGluZyB0byBiZSBSZWZsZWN0ZWQgZmll bGQgcHJlY2VkZXMgdGhlIEFkZGl0aW9uYWwgUGFkZGluZy4KCiAgIFRoZSBTZXNzaW9uLVJlZmxl Y3RvciBTSEFMTCB1c2UgdGhlIHNhbWUgVFdBTVAtVGVzdCBQYWNrZXQgRm9ybWF0IGFzCiAgIHNw ZWNpZmllZCBpbiBzZWN0aW9uIDQuMi4xIGFib3ZlLgoKCjUuICBTZWN1cml0eSBDb25zaWRlcmF0 aW9ucwoKICAgVGhlc2UgZXh0ZW5kZWQgbW9kZXMgb2Ygb3BlcmF0aW9uIGRvIG5vdCBhcHBlYXIg dG8gcGVybWl0IGFueSBuZXcKICAgYXR0YWNrcyBvbiBob3N0cyBjb21tdW5pY2F0aW5nIHdpdGgg Y29yZSBUV0FNUCBbUkZDNTM1N10uCgogICBUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgdGhh dCBhcHBseSB0byBhbnkgYWN0aXZlIG1lYXN1cmVtZW50IG9mCiAgIGxpdmUgbmV0d29ya3MgYXJl IHJlbGV2YW50IGhlcmUgYXMgd2VsbC4gIFNlZSBbUkZDNDY1Nl0gYW5kCiAgIFtSRkM1MzU3XS4K CgoKTW9ydG9uICYgQ2lhdmF0dG9uZSAgICAgRXhwaXJlcyBEZWNlbWJlciAxNywgMjAxMCAgICAg ICAgICAgICAgW1BhZ2UgMTZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgUmVmbGVjdCBPY3RldHMg JiBTeW1tZXRyaWMgU2l6ZSAgICAgICAgICAgSnVuZSAyMDEwCgoKNi4gIElBTkEgQ29uc2lkZXJh dGlvbnMKCiAgIFRoaXMgbWVtbyBhZGRzIHR3byBtb2RlcyB0byB0aGUgSUFOQSByZWdpc3RyeSBm b3IgdGhlIFRXQU1QIE1vZGVzCiAgIEZpZWxkLCBhbmQgZGVzY3JpYmVzIGJlaGF2aW9yIHdoZW4g dGhlIG5ldyBtb2RlcyBhcmUgdXNlZC4gIFRoaXMKICAgZmllbGQgaXMgYSByZWNvZ25pemVkIGV4 dGVuc2lvbiBtZWNoYW5pc20gZm9yIFRXQU1QLgoKNi4xLiAgUmVnaXN0cnkgU3BlY2lmaWNhdGlv bgoKICAgSUFOQSBoYXMgY3JlYXRlZCBhIFRXQU1QLU1vZGVzIHJlZ2lzdHJ5IChhcyByZXF1ZXN0 ZWQgaW4gW1JGQzU2MThdKS4KICAgVFdBTVAtTW9kZXMgYXJlIHNwZWNpZmllZCBpbiBUV0FNUCBT ZXJ2ZXIgR3JlZXRpbmcgbWVzc2FnZXMgYW5kCiAgIFNldC11cCBSZXNwb25zZSBtZXNzYWdlcywg YXMgZGVzY3JpYmVkIGluIHNlY3Rpb24gMy4xIG9mIFtSRkM1MzU3XSwKICAgY29uc2lzdGVudCB3 aXRoIHNlY3Rpb24gMy4xIG9mIFtSRkM0NjU2XSwgYW5kIGV4dGVuZGVkIGJ5IHRoaXMgbWVtby4K ICAgTW9kZXMgYXJlIGluZGljYXRlZCBieSBzZXR0aW5nIGJpdHMgaW4gdGhlIDMyLWJpdCBNb2Rl cyBmaWVsZCB0aGF0CiAgIGNvcnJlc3BvbmQgdG8gdmFsdWVzIGluIHRoZSBNb2RlcyByZWdpc3Ry eS4gIEZvciB0aGUgVFdBTVAtTW9kZXMKICAgcmVnaXN0cnksIHdlIGV4cGVjdCB0aGF0IG5ldyBm ZWF0dXJlcyB3aWxsIGJlIGFzc2lnbmVkIGluY3JlYXNpbmcKICAgcmVnaXN0cnkgdmFsdWVzIHRo YXQgY29ycmVzcG9uZCB0byBzaW5nbGUgYml0IHBvc2l0aW9ucywgdW5sZXNzIHRoZXJlCiAgIGlz IGEgZ29vZCByZWFzb24gdG8gZG8gb3RoZXJ3aXNlIChtb3JlIGNvbXBsZXggZW5jb2RpbmcgdGhh biBzaW5nbGUKICAgYml0IHBvc2l0aW9ucyBtYXkgYmUgdXNlZCBpbiB0aGUgZnV0dXJlLCB0byBh Y2Nlc3MgdGhlIDJeMzIgdmFsdWUKICAgc3BhY2UpLgoKNi4yLiAgUmVnaXN0cnkgQ29udGVudHMK CiAgIFRXQU1QIE1vZGVzIFJlZ2lzdHJ5IGlzIHJlY29tbWVuZGVkIHRvIGJlIGF1Z21lbnRlZCBh cyBmb2xsb3dzOgoKICAgVmFsdWUgIERlc2NyaXB0aW9uICAgICAgICAgICAgIFNlbWFudGljcyBE ZWZpbml0aW9uCiAgIDAgICAgICBSZXNlcnZlZAoKICAgMSAgICAgIFVuYXV0aGVudGljYXRlZCAg ICAgICAgIFJGQzQ2NTYsIFNlY3Rpb24gMy4xCgogICAyICAgICAgQXV0aGVudGljYXRlZCAgICAg ICAgICAgUkZDNDY1NiwgU2VjdGlvbiAzLjEKCiAgIDQgICAgICBFbmNyeXB0ZWQgICAgICAgICAg ICAgICBSRkM0NjU2LCBTZWN0aW9uIDMuMQoKICAgOCAgICAgIFVuYXV0aC4gVEVTVCBwcm90b2Nv bCwgIFJGQzU2MTgsIFNlY3Rpb24gMy4xICgzKQogICAgICAgICAgQXV0aC4gQ09OVFJPTAogICAx NiAgICAgSW5kaXZpZHVhbCBTZXNzaW9uICAgICAgUkZDPz8/PywgU2VjdGlvbiAzLjEKICAgICAg ICAgIENvbnRyb2wgICAgICAgICAgICAgICAgIGJpdCBwb3NpdGlvbiAoNCkKICAgLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KICAgeHh4ICAg IFJlZmxlY3QgT2N0ZXRzICAgICAgICAgIHRoaXMgbWVtbywgc2VjdGlvbiAzLjEKICAgICAgICAg IENhcGFiaWxpdHkgICAgICAgICAgICAgIG5ldyBiaXQgcG9zaXRpb24gKFgpCiAgIHl5eSAgICBT eW1tZXRyaWNhbCBTaXplICAgICAgICB0aGlzIG1lbW8sIHNlY3Rpb24gMy4xCiAgICAgICAgICBT ZW5kZXIgVGVzdCBQYWNrZXQgRm9ybWF0IG5ldyBiaXQgcG9zaXRpb24gKFkpCgoKICAgPj4+SUFO QTogY2hhbmdlIHh4eCwgeXl5LCBYLCBZLCBhbmQgUkZDPz8/PyB0byB0aGUgYXNzaWduZWQgdmFs dWVzCgogICBUaGUgc3VnZ2VzdGVkIHZhbHVlcyBhcmUKCgoKCk1vcnRvbiAmIENpYXZhdHRvbmUg ICAgIEV4cGlyZXMgRGVjZW1iZXIgMTcsIDIwMTAgICAgICAgICAgICAgIFtQYWdlIDE3XQoMCklu dGVybmV0LURyYWZ0ICAgICAgIFJlZmxlY3QgT2N0ZXRzICYgU3ltbWV0cmljIFNpemUgICAgICAg ICAgIEp1bmUgMjAxMAoKCiAgIFg9NSwgeHh4PTMyCgogICBZPTYsIHl5eT02NCA8PDw8CgoKNy4g IEFja25vd2xlZGdlbWVudHMKCiAgIFRoZSBhdXRob3JzIHRoYW5rIFN0ZXZlIEJhaWxsYXJnZW9u LCBXYWx0IFN0ZXZlcnNvbiwgYW5kIFN0aW5hIFJvc3MKICAgZm9yIGhlbHBmdWwgcmV2aWV3IGFu ZCBjb21tZW50cy4KCgo4LiAgUmVmZXJlbmNlcwoKOC4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMK CiAgIFtSRkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRv IEluZGljYXRlCiAgICAgICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMg MjExOSwgTWFyY2ggMTk5Ny4KCiAgIFtSRkM0NjU2XSAgU2hhbHVub3YsIFMuLCBUZWl0ZWxiYXVt LCBCLiwgS2FycCwgQS4sIEJvb3RlLCBKLiwgYW5kIE0uCiAgICAgICAgICAgICAgWmVrYXVza2Fz LCAiQSBPbmUtd2F5IEFjdGl2ZSBNZWFzdXJlbWVudCBQcm90b2NvbAogICAgICAgICAgICAgIChP V0FNUCkiLCBSRkMgNDY1NiwgU2VwdGVtYmVyIDIwMDYuCgogICBbUkZDNTIyNl0gIE5hcnRlbiwg VC4gYW5kIEguIEFsdmVzdHJhbmQsICJHdWlkZWxpbmVzIGZvciBXcml0aW5nIGFuCiAgICAgICAg ICAgICAgSUFOQSBDb25zaWRlcmF0aW9ucyBTZWN0aW9uIGluIFJGQ3MiLCBCQ1AgMjYsIFJGQyA1 MjI2LAogICAgICAgICAgICAgIE1heSAyMDA4LgoKICAgW1JGQzUzNTddICBIZWRheWF0LCBLLiwg S3J6YW5vd3NraSwgUi4sIE1vcnRvbiwgQS4sIFl1bSwgSy4sIGFuZCBKLgogICAgICAgICAgICAg IEJhYmlhcnosICJBIFR3by1XYXkgQWN0aXZlIE1lYXN1cmVtZW50IFByb3RvY29sIChUV0FNUCki LAogICAgICAgICAgICAgIFJGQyA1MzU3LCBPY3RvYmVyIDIwMDguCgogICBbUkZDNTYxOF0gIE1v cnRvbiwgQS4gYW5kIEsuIEhlZGF5YXQsICJNaXhlZCBTZWN1cml0eSBNb2RlIGZvciB0aGUKICAg ICAgICAgICAgICBUd28tV2F5IEFjdGl2ZSBNZWFzdXJlbWVudCBQcm90b2NvbCAoVFdBTVApIiwg UkZDIDU2MTgsCiAgICAgICAgICAgICAgQXVndXN0IDIwMDkuCgo4LjIuICBJbmZvcm1hdGl2ZSBS ZWZlcmVuY2VzCgoKCgoKCgoKCgoKCgoKCgpNb3J0b24gJiBDaWF2YXR0b25lICAgICBFeHBpcmVz IERlY2VtYmVyIDE3LCAyMDEwICAgICAgICAgICAgICBbUGFnZSAxOF0KDApJbnRlcm5ldC1EcmFm dCAgICAgICBSZWZsZWN0IE9jdGV0cyAmIFN5bW1ldHJpYyBTaXplICAgICAgICAgICBKdW5lIDIw MTAKCgpBdXRob3JzJyBBZGRyZXNzZXMKCiAgIEFsIE1vcnRvbgogICBBVCZUIExhYnMKICAgMjAw IExhdXJlbCBBdmVudWUgU291dGgKICAgTWlkZGxldG93biwsIE5KICAwNzc0OAogICBVU0EKCiAg IFBob25lOiArMSA3MzIgNDIwIDE1NzEKICAgRmF4OiAgICsxIDczMiAzNjggMTE5MgogICBFbWFp bDogYWNtb3J0b25AYXR0LmNvbQogICBVUkk6ICAgaHR0cDovL2hvbWUuY29tY2FzdC5uZXQvfmFj bWFjbS8KCgogICBMZW4gQ2lhdmF0dG9uZQogICBBVCZUIExhYnMKICAgMjAwIExhdXJlbCBBdmVu dWUgU291dGgKICAgTWlkZGxldG93biwsIE5KICAwNzc0OAogICBVU0EKCiAgIFBob25lOiArMSA3 MzIgNDIwIDEyMzkKICAgRmF4OgogICBFbWFpbDogbGVuY2lhQGF0dC5jb20KICAgVVJJOgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpNb3J0b24gJiBDaWF2YXR0b25lICAgICBFeHBpcmVzIERl Y2VtYmVyIDE3LCAyMDEwICAgICAgICAgICAgICBbUGFnZSAxOV0KDAoK --=====================_15247825==_-- From henk@ripe.net Wed Jun 23 00:18: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 3541A3A67B4 for ; Wed, 23 Jun 2010 00:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.039 X-Spam-Level: X-Spam-Status: No, score=-2.039 tagged_above=-999 required=5 tests=[AWL=0.560, BAYES_00=-2.599] 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 6br5ZQH7W9fK for ; Wed, 23 Jun 2010 00:18:17 -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 A94623A67B2 for ; Wed, 23 Jun 2010 00:18:16 -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 1ORKDw-0006rh-Ou for ippm@ietf.org; Wed, 23 Jun 2010 09:18:22 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=guest-81.ripe.net) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1ORKDw-0008M5-LI for ippm@ietf.org; Wed, 23 Jun 2010 09:18:16 +0200 Message-ID: <4C21A482.4050909@ripe.net> Date: Wed, 23 Jun 2010 08:06:58 +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.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 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: e0cdef1f45f89a40ad608d255b27e7d5f2726b4c423ab84dd855f6e35b7cf70f X-RIPE-Spam-Level: ---- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5f2726b4c423ab84dd855f6e35b7cf70f Subject: [ippm] Fwd: Fwd: Nomcom 2010-2011: Second Call for Volunteers 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, 23 Jun 2010 07:18:19 -0000 > From: NomCom Chair > Date: June 21, 2010 5:49:08 PM EDT > To: IETF Announcement list > Subject: Nomcom 2010-2011: Second Call for Volunteers > > Hi all, > > This is the Second call for Volunteers for the 2010-11 nomcom. We are > just about halfway through the volunteer period so if you are > considering > volunteering please do so very soon. > > I am pleased to report that we have 29 volunteers thus far whose > qualifications have been confirmed by the secretariat. I have notified > each of these volunteers by email. > > If you volunteered before 08:00 PDT (15:00 UTC) on June 21 to serve > as a > voting member and have not received a confirmation email from me, > please > re-submit and bring to my attention right away! > > However, we need many more volunteers. You have until 17:00 PDT > (24:00 > UTC) on July 8, 2010 to volunteer for nomcom but it is much better > if you > volunteer as early as possible. The more volunteers, the better > chance we > have of choosing a random yet representative cross section of the IETF > pouplation. > > As a reminder, volunteers must have attended 3 of the past 5 IETF > meetings - per RFC 3777, which means 3 of the following meetings: > IETF-73, > IETF-74, IETF-75, IETF-76 and IETF-77. If you qualify, and are > willing to > forgo appointment to any of the positions for which the nominating > committee is responsible, please volunteer. > > The 10 nominating committee members are selected randomly from a > pool of > volunteers. The details of the operation of nomcom may be found in > RFC > 3777. The process on how to volunteer for nomcom is in the initial > announcement: https://datatracker.ietf.org/ann/nomcom/2330/ > > The lists of open positions and people whose terms end in March 2011 > and > thus the positions for which the nominating committee is responsible > are > summarized in the initial announcement: > https://datatracker.ietf.org/ann/nomcom/2330/ > > The 29 volunteers who have thus far been qualified by the secretariat > are: > > Fred Baker, Cisco Systems > > Stephan Wenger, Vidyo, Inc. > > Marc Blanchet, Viagenie > > Lixia Zhang, UCLA > > John Drake, Juniper Networks > > Ole Troan, Cisco > > Jiankang Yao, CNNIC > > Wassim Haddad, Ericsson > > Yi Zhao, Huawei USA > > Teemu Savolainen, Nokia > > Jouni Korhonen, Nokia Siemens Networks > > Mehmet Ersue, Nokia Siemens Networks > > Christian Schmidt, Nokia Siemens Networks > > Stephen Hanna, Juniper Networks > > Suresh Krishnan, Ericsson > > Eric Gray, Ericsson > > David Sinicrope, Ericsson > > Jan Melen, Ericsson > > Richard Barnes, BBN Technologies > > Hugo Salgado Hernandez, NIC Chile > > Ning Zong, Huawei Technologies > > Qin Wu, Huawei Technologies > > Karen Seo, BBN Technologies > > Haibin Song, Huawei Technologies > > Susan Hares, Huawei Technologies > > Tony Hansen. AT&T Labs > > Fuqing Huang, Huawei Technologies Co., Ltd. > > Huub van Helvoort, Huawei Technologies > > Miya Kohno, Juniper Networks > > The primary activity for this nomcom will begin just prior to > IETF-78 in > Maastricht and should be completed in early January 2011. The > nomcom will > be collecting requirements from the community, as well as talking to > candidates and to community members about candidates. There will be > weekly > conference calls to ensure progress. Thus, being a nomcom member does > require some time commitment. > > While, there is no requirement in RFC 3777 that a participant attend > IETF > meetings while serving on nomcom, please consider that during the IETF > meetings, people that do not attend would be expected to remotely > participate during the day in the time zones of the meeting > locations - > Maastricht at the end of July and Beijing in November. > > If you are not yet sure you would like to volunteer, please consider > that > nomcom members play a very important role in shaping the leadership > of the > IETF. Ensuring the leadership of the IETF is fair and balanced and > comprised of those who can lead the IETF in the right direction is an > important responsibility that rests on the IETF participants at large. > Volunteering for the nomcom is a good way of contributing in that > direction. > > Please volunteer by sending an email before: > 17:00 PDT (24:00 UTC) July 8, 2010 as follows: > > To: nomcom-chair@ietf.org > Subject: Nomcom 2010-11 Volunteer > > Please include the following information in the body: > > // As you enter in the IETF Registration Form, > // First/Given name followed by Last/Family Name > > > // typically what goes in the Company field > // in the IETF Registration Form > > [] > // > > // For confirmation if selected > > Please expect an email response from me within 3 days stating > whether or > not you are qualified. If you don't receive a response, please re- > send > your email with the tag "Duplicate:" added to the subject line. > > Thank you and I hope to hear from you, > > Thomas Walsh > Chair, Nomcom 2010-11 > Email: nomcom-chair@ietf.org > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > From edgstl64@gmail.com Thu Jun 24 12:00:36 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 B574B3A6A4D for ; Thu, 24 Jun 2010 12:00:36 -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.778, 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 3qkQRsKvs48p for ; Thu, 24 Jun 2010 12:00:35 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 85C5028C19E for ; Thu, 24 Jun 2010 12:00:22 -0700 (PDT) Received: by vws2 with SMTP id 2so215118vws.31 for ; Thu, 24 Jun 2010 12:00:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=EFMcffPYOiubUDn7rBOJcTvVHqMj/z7JigYw32aR6vE=; b=FoO+WSoOqYKrQcC1u1z4FNTS+y3W4FiDKUIU5gpaUpCL3mFiG1OyNGARji49b+2SXp SowzN6F5RTGZIZfdHPe0Tfq2A0JZEleyQboweFxeJLx1Qy/9SecblSnDcfpCCP7hUqY2 GgU+STgu1gLHrH+zEOpNite+KWOKrBtwugdqs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=DucVWkkvh+IjWHSxCznUcYr34cpJrWdUOtCpjArsMlmpzDDzLi1LclApCJNyNPLelA nlkADoNn9madp4aBC9itNTeaDdKo6QRNOT2NMTzw8eQdHy9PVRgixTnOz3Tu9TFh1LFO KGXb7VsidNRzRKxbjN0GE6W6+QV3yTp4j+bOQ= MIME-Version: 1.0 Received: by 10.220.47.142 with SMTP id n14mr5372179vcf.87.1277406026373; Thu, 24 Jun 2010 12:00:26 -0700 (PDT) Received: by 10.220.192.202 with HTTP; Thu, 24 Jun 2010 12:00:26 -0700 (PDT) Date: Thu, 24 Jun 2010 15:00:26 -0400 Message-ID: From: Ed Gastle To: ippm@ietf.org Content-Type: multipart/alternative; boundary=001485f94cac6f99b50489cb4440 Subject: [ippm] TCP Throughput Testing Methodology draft 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, 24 Jun 2010 19:00:36 -0000 --001485f94cac6f99b50489cb4440 Content-Type: text/plain; charset=ISO-8859-1 Some comments on the TCP Throughput Testing Methodology draft: - The acronym MSS is referred to in the Introduction but not defined until 3.1 - suggest it be defined when the acronym is first used. - The Introduction seems to too narrowly focus the draft to the "network provider community". It seems this test methodology would also be useful in a LAN/Campus (private managed network) environment. - The Introduction (last paragraph) as well as section 3 recommends that RFC2544 tests be performed as a precursor to conducting TCP throughput tests. The stated purpose of this step is to "verify the integrity of the network before conducting TCP testing." What network integrity characteristics that affect TCP throughput tests should be clearly spelt out in the introduction. It seems the main parameter is frame loss and a stable delay (absence of jitter). But what level of frame loss and jitter that are acceptable are not defined. In addition there are many ways to test loss without performing RFC2544 tests. With this in mind it seems recommending RFC2544 is too restrictive a requirement. My main point here is the network performance parameters that must be in place to make performing TCP throughput testing accurate should be more clearly defined and explained. The method of measuring the network for these parameters should be left open. - The BDP calculation in section 3.2 should have the units of measure defined (BDP in Bits, RTT in ms, Bandwidth in bps) - Although there are many factors at play (TCP Window in particular) it seems counter-intuitive that maximum achievable TCP throughput in some cases INCREASES with delay. Referring to Table 3.2 a link with 100Mb of bandwidth and 2 ms of delay has greater TCP throughput than a link with 1 ms of delay. Are the calculations here correct? Ed Gastle --001485f94cac6f99b50489cb4440 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Some comments on the TCP Throughput Testing Methodology draft:=20
=A0=A0
  • The acronym MSS is referred to in the Introduction but not defined unti= l 3.1 - suggest it be defined when the acronym is first used.
  • The Introduction seems to too narrowly focus the draft to the "net= work provider community". It seems this test methodology would also be= useful in a LAN/Campus (private managed network) environment.
  • The Introduction (last paragraph)=A0 as well as section 3 recommends th= at RFC2544 tests be performed as a precursor to conducting TCP throughput t= ests. The stated purpose of this step is to "verify the integrity of t= he network before conducting TCP testing." What network integrity char= acteristics that affect TCP throughput tests should be clearly spelt out in= the introduction. It seems the main parameter is frame loss and a stable d= elay (absence of jitter). But what level of frame loss and jitter that are = acceptable are not defined. In addition there are many ways to test loss wi= thout performing RFC2544 tests. With this in mind it seems recommending RFC= 2544 is too restrictive a requirement. My main point here is the network pe= rformance parameters that must be in place to make performing TCP throughpu= t testing accurate should be more clearly defined and explained. The method= of measuring the network for these parameters should be left open.
  • The BDP calculation in section 3.2 should have the units of measure def= ined (BDP in Bits, RTT in ms, Bandwidth in bps)
  • Although there are many factors at play (TCP Window in particular) it s= eems counter-intuitive that maximum achievable TCP throughput in some cases= INCREASES with delay. Referring to Table 3.2 a link with 100Mb of bandwidt= h and 2 ms of delay has greater TCP throughput than a link with 1 ms of del= ay. Are the calculations here correct?
Ed Gastle
--001485f94cac6f99b50489cb4440-- From gilles.forget@sympatico.ca Thu Jun 24 21:28:29 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D1463A6835 for ; Thu, 24 Jun 2010 21:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.554 X-Spam-Level: * X-Spam-Status: No, score=1.554 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_60=1, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803] 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 xBIrQ1hEUvyX for ; Thu, 24 Jun 2010 21:28:23 -0700 (PDT) Received: from blu0-omc4-s13.blu0.hotmail.com (blu0-omc4-s13.blu0.hotmail.com [65.55.111.152]) by core3.amsl.com (Postfix) with ESMTP id 6614F3A67E2 for ; Thu, 24 Jun 2010 21:28:23 -0700 (PDT) Received: from BLU0-SMTP67 ([65.55.111.135]) by blu0-omc4-s13.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Jun 2010 21:28:31 -0700 X-Originating-IP: [64.228.82.34] X-Originating-Email: [gilles.forget@sympatico.ca] Message-ID: Received: from gforgetT400 ([64.228.82.34]) by BLU0-SMTP67.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Jun 2010 21:28:30 -0700 From: "Gilles Forget" To: "'Ed Gastle'" , References: In-Reply-To: Date: Fri, 25 Jun 2010 00:28:32 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01CB13FD.58B37280" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsTz8celxHsofiVTMylj+bD4H6ZqwATqwfg Content-Language: en-ca X-OriginalArrivalTime: 25 Jun 2010 04:28:30.0627 (UTC) FILETIME=[DD66D730:01CB141E] Subject: Re: [ippm] TCP Throughput Testing Methodology draft 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, 25 Jun 2010 04:28:29 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0020_01CB13FD.58B37280 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Bonjour Ed, Thank you very much for all of your very constructive comments. About RFC2544, I would just like to add that it was never meant for network testing. This RFC was written with lab testing in mind only, right at the beginning in section 3, it talks about DUTs (Devices Under Test). Plus the complete title is : Benchmarking Methodology for Network Interconnect Dev. However, it's a fact of life that it has been used for at least 10 years now, not only for lab testing but for complete end to end network tests and that is one of the reasons why we have decided to mention it in the draft. I know by field experience that it leads to finger pointing situations between business customers and network providers. On the other hand, it's hard for us to be very precise about how many frame loss or how much jitter is acceptable without entering the SLA (Service Level Agreement) area. SLAs are not only based on technical variables, they are also based on business and political variables that we can not define in the present document. Concerning your last comment, you are absolutely right, there is an error in Table 3.2. The error comes from versions 5 of Excel spreadsheets and I have corrected it in the calculation formula of version 6. At 100M, the theoretical TCP throughput should be 90.699 Mbps for all of the 3 calculated RTTs because we reach the maximum frame per seconds at all 3 delays. However, we have to be aware that it is still possible to achieve a better TCP throughput in some cases when delay increases because it permits more in flight bytes between sites. Thanks, Gilles Forget, CCNP. From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Ed Gastle Sent: June-24-10 3:00 PM To: ippm@ietf.org Subject: [ippm] TCP Throughput Testing Methodology draft Some comments on the TCP Throughput Testing Methodology draft: * The acronym MSS is referred to in the Introduction but not defined until 3.1 - suggest it be defined when the acronym is first used. * The Introduction seems to too narrowly focus the draft to the "network provider community". It seems this test methodology would also be useful in a LAN/Campus (private managed network) environment. * The Introduction (last paragraph) as well as section 3 recommends that RFC2544 tests be performed as a precursor to conducting TCP throughput tests. The stated purpose of this step is to "verify the integrity of the network before conducting TCP testing." What network integrity characteristics that affect TCP throughput tests should be clearly spelt out in the introduction. It seems the main parameter is frame loss and a stable delay (absence of jitter). But what level of frame loss and jitter that are acceptable are not defined. In addition there are many ways to test loss without performing RFC2544 tests. With this in mind it seems recommending RFC2544 is too restrictive a requirement. My main point here is the network performance parameters that must be in place to make performing TCP throughput testing accurate should be more clearly defined and explained. The method of measuring the network for these parameters should be left open. * The BDP calculation in section 3.2 should have the units of measure defined (BDP in Bits, RTT in ms, Bandwidth in bps) * Although there are many factors at play (TCP Window in particular) it seems counter-intuitive that maximum achievable TCP throughput in some cases INCREASES with delay. Referring to Table 3.2 a link with 100Mb of bandwidth and 2 ms of delay has greater TCP throughput than a link with 1 ms of delay. Are the calculations here correct? Ed Gastle ------=_NextPart_000_0020_01CB13FD.58B37280 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bonjour Ed,

 

Thank you very much for all of your very constructive = comments.

 

About RFC2544, I would just like to add that it was never = meant for network testing. This RFC was written with lab testing in mind only, = right at the beginning in section 3, it talks about DUTs (Devices Under = Test).

Plus the complete title is : Benchmarking Methodology for Network Interconnect Dev. However, it’s a fact of life that it has = been used for at least 10 years now, not only for lab testing but for complete end = to end network tests and that is one of the reasons why we have decided to = mention it in the draft. I know by field experience that it leads to finger = pointing situations between business customers and network providers. On the = other hand, it’s hard for us to be very precise about how many frame loss or = how much jitter is acceptable without entering the SLA (Service Level Agreement) = area. SLAs are not only based on technical variables, they are also based on = business and political variables that we can not define in the present = document.

 

Concerning your last comment, you are absolutely right, = there is an error in Table 3.2. The error comes from versions 5 of Excel = spreadsheets and I have corrected it in the calculation formula of version = 6.

At 100M, the theoretical TCP throughput should be 90.699 = Mbps for all of the 3 calculated RTTs because we reach the maximum frame per = seconds at all 3 delays.

However, we have to be aware that it is still possible to achieve a better TCP throughput in some cases when delay increases = because it permits more in flight bytes between sites.

 

Thanks,

Gilles Forget, CCNP.

 

 

 

From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Ed Gastle
Sent: June-24-10 3:00 PM
To: ippm@ietf.org
Subject: [ippm] TCP Throughput Testing Methodology = draft

 

Some comments on the TCP Throughput Testing = Methodology draft:

  

  • The acronym MSS is referred to in the Introduction but not defined until 3.1 - suggest it be defined when = the acronym is first used.
  • The Introduction seems to too narrowly = focus the draft to the "network provider community". It seems this = test methodology would also be useful in a LAN/Campus (private managed = network) environment.
  • The Introduction (last paragraph)  as = well as section 3 recommends that RFC2544 tests be performed as a = precursor to conducting TCP throughput tests. The stated purpose of this step is = to "verify the integrity of the network before conducting TCP testing." What network integrity characteristics that affect = TCP throughput tests should be clearly spelt out in the introduction. = It seems the main parameter is frame loss and a stable delay (absence of = jitter). But what level of frame loss and jitter that are acceptable are not defined. In addition there are many ways to test loss without = performing RFC2544 tests. With this in mind it seems recommending RFC2544 is = too restrictive a requirement. My main point here is the network = performance parameters that must be in place to make performing TCP throughput testing = accurate should be more clearly defined and explained. The method of = measuring the network for these parameters should be left open.
  • The BDP calculation in section 3.2 should = have the units of measure defined (BDP in Bits, RTT in ms, Bandwidth in = bps)
  • Although there are many factors at play = (TCP Window in particular) it seems counter-intuitive that maximum = achievable TCP throughput in some cases INCREASES with delay. Referring to = Table 3.2 a link with 100Mb of bandwidth and 2 ms of delay has greater TCP throughput than a link with 1 ms of delay. Are the calculations = here correct?

Ed Gastle

------=_NextPart_000_0020_01CB13FD.58B37280-- From henk@ripe.net Fri Jun 25 00:48: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 D6DA53A691D for ; Fri, 25 Jun 2010 00:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=0.517, BAYES_00=-2.599] 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 u+-mEfjn4mlx for ; Fri, 25 Jun 2010 00:48:08 -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 9B45B3A6960 for ; Fri, 25 Jun 2010 00:48:07 -0700 (PDT) Received: from dodo.ripe.net ([193.0.1.102]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OS3dw-0002Y0-SF for ippm@ietf.org; Fri, 25 Jun 2010 09:48:14 +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 1OS3dw-0003W5-Ny for ippm@ietf.org; Fri, 25 Jun 2010 09:48:08 +0200 Message-ID: <4C245F38.1070703@ripe.net> Date: Fri, 25 Jun 2010 09:48:08 +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.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: "ippm >> IETF IPPM WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d52cd8393aa4cb57a2360118b051f87f22 X-RIPE-Spam-Level: ---- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d52cd8393aa4cb57a2360118b051f87f22 Subject: [ippm] Fwd: WebEx and Remote Presentations 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, 25 Jun 2010 07:48:08 -0000 IPPM group, Please see below. Henk -------- Original Message -------- Subject: WebEx and Remote Presentations Date: Thu, 24 Jun 2010 14:50:21 -0400 From: The IESG Reply-To: iesg@ietf.org To: IETF WG Chairs CC: IAB Dear WG Chairs: WebEx has proven a very useful tool for interim virtual meetings, and we will continue to make WebEx available for this purpose. The IETF has tried a WebEx experiment for remote presentations at IETF meetings. For the most part, this experiment has been a failure. Too much time is spent getting WebEx and the room audio system to cooperate. And, when it does not, there can be loud obnoxious disruptive noises. As a result of this situation, the IESG has decided to limit the WebEx offering at IETF meetings to outbound audio and slides. If a presenter is unable to attend a meeting, they will have to arrange for someone else to make their presentation. They can listen on streaming audio or WebEx, and they can help answer questions in jabber. The IESG is willing to consider the remote presenter experiment again in the future if there is evidence that the outcome might be different. On behalf of the IESG, Russ Housley IETF Chair From henk@ripe.net Fri Jun 25 00:50:30 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 541093A6915 for ; Fri, 25 Jun 2010 00:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599] 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 vYYh+mL9YBMV for ; Fri, 25 Jun 2010 00:50:23 -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 A0B723A6876 for ; Fri, 25 Jun 2010 00:50:23 -0700 (PDT) Received: from dodo.ripe.net ([193.0.1.102]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OS3g4-0002cg-Of for ippm@ietf.org; Fri, 25 Jun 2010 09:50:31 +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 1OS3g4-0003aQ-KS for ippm@ietf.org; Fri, 25 Jun 2010 09:50:20 +0200 Message-ID: <4C245FBC.3080305@ripe.net> Date: Fri, 25 Jun 2010 09:50:20 +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.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: "ippm >> IETF IPPM WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d57307800bf222d0f0c921675a0c94d39c X-RIPE-Spam-Level: ---- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d57307800bf222d0f0c921675a0c94d39c Subject: [ippm] Meeting in Maastricht 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, 25 Jun 2010 07:50:30 -0000 IPPM group, We will meet in Maastricht. However, even though we requested a meeting slot, it is not on the agenda yet. This will be solved soon. You want to present, please drop us a note. Note that it will NOT be possible to do remote presentations. See the IESG mail for the background. Matt & Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ I confirm today what I denied yesterday. Anonymous Politician. From root@core3.amsl.com Fri Jun 25 11:45: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 65BDC3A6857; Fri, 25 Jun 2010 11:45: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: <20100625184502.65BDC3A6857@core3.amsl.com> Date: Fri, 25 Jun 2010 11:45:02 -0700 (PDT) Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-spatial-composition-13.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, 25 Jun 2010 18:45: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-13.txt Pages : 26 Date : 2010-06-25 This memo utilizes IP Performance 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-13.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-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-25113428.I-D@ietf.org> --NextPart-- From henk@ripe.net Sat Jun 26 01:08:17 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 0D5EF3A6876 for ; Sat, 26 Jun 2010 01:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[AWL=0.487, BAYES_00=-2.599] 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 XA4NQYwqmJGF for ; Sat, 26 Jun 2010 01:08:15 -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 98E3D3A684B for ; Sat, 26 Jun 2010 01:08:14 -0700 (PDT) Received: from dodo.ripe.net ([193.0.1.102]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OSQQy-0003Qa-GY for ippm@ietf.org; Sat, 26 Jun 2010 10:08:21 +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 1OSQQy-0002dx-Bc for ippm@ietf.org; Sat, 26 Jun 2010 10:08:16 +0200 Message-ID: <4C25B570.4000202@ripe.net> Date: Sat, 26 Jun 2010 10:08:16 +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.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: "ippm >> IETF IPPM WG" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d56f922227e1d5fe226f354411812f48f1 X-RIPE-Spam-Level: ---- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d56f922227e1d5fe226f354411812f48f1 Subject: [ippm] Fwd: IPPM - Requested session has been scheduled for IETF 78 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: Sat, 26 Jun 2010 08:08:17 -0000 FYI, we'll meet on Monday afternoon in Maastricht. Henk -------- Original Message -------- Subject: IPPM - Requested session has been scheduled for IETF 78 Date: Fri, 25 Jun 2010 08:33:52 -0700 (PDT) From: IETF Secretariat To: henk@ripe.net CC: matt@internet2.edu,ietfdbh@comcast.net,lars.eggert@nokia.com,session-request@ietf.org Dear Henk Uijterwaal, The sessions that you have requested have been scheduled. Below is the scheduled session information followed by the information of sessions that you have requested. IPPM Session 1 (2 hours) Monday, Afternoon Session II 1520-1720 Room Name: Auditorium 1 ---------------------------------------------- Requested Information: --------------------------------------------------------- Working Group Name: ippm Area Name: Transport Area Session Requester: Henk Uijterwaal Number of Sessions: 1 Length of Session(s): 2 hours Number of Attendees: 50 Conflicts to Avoid: First Priority: bmwg tsvwg tsvarea pmol sidr opsarea avt ledbat alto Second Priority: dccp ipfix Special Requests: Not on Wednesday morning due to conflict with IAOC meeting. --------------------------------------------------------- From Barry.Constantine@jdsu.com Sat Jun 26 04:00:34 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 C32313A6846 for ; Sat, 26 Jun 2010 04:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=-1.557, BAYES_80=2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiw8hPNrbYiR for ; Sat, 26 Jun 2010 04:00:26 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with SMTP id 1B3723A690C for ; Sat, 26 Jun 2010 04:00:25 -0700 (PDT) Received: from source ([209.36.247.244]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTCXd0auNhGqvoUQztAzaAY1hGVc6JT/s@postini.com; Sat, 26 Jun 2010 04:00:35 PDT Received: from milexhtca2.ds.jdsu.net ([10.75.2.122]) by Outbound1.jdsu.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 26 Jun 2010 03:51:32 -0700 Received: from MILEXCH1.ds.jdsu.net ([fe80::6444:f010:6d40:bdb]) by milexhtca2.ds.jdsu.net ([::1]) with mapi; Sat, 26 Jun 2010 03:51:31 -0700 From: Barry Constantine To: Gilles Forget , 'Ed Gastle' , "ippm@ietf.org" Date: Sat, 26 Jun 2010 03:51:29 -0700 Thread-Topic: [ippm] TCP Throughput Testing Methodology draft Thread-Index: AcsTz8celxHsofiVTMylj+bD4H6ZqwATqwfgAD+JyXA= Message-ID: <94DEE80C63F7D34F9DC9FE69E39436BE38B7E69AC8@MILEXCH1.ds.jdsu.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_94DEE80C63F7D34F9DC9FE69E39436BE38B7E69AC8MILEXCH1dsjds_" MIME-Version: 1.0 X-OriginalArrivalTime: 26 Jun 2010 10:51:32.0178 (UTC) FILETIME=[89E2FB20:01CB151D] Subject: Re: [ippm] TCP Throughput Testing Methodology draft 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: Sat, 26 Jun 2010 11:00:34 -0000 --_000_94DEE80C63F7D34F9DC9FE69E39436BE38B7E69AC8MILEXCH1dsjds_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ed, - Regarding the applicability to enterprise network groups and network prov= iders, this is a very good point. We have been focused upon network provid= ers since this methodology is envisioned as a qualification / turn-up test,= but agree it is equally applicable to enterprise groups. - Al and others made similar comments relating to other means besides RFC-2= 544 to pre-qualify the network; I added some text to broaden the scope of t= he functional network testing; obviously more clarification is required in = this area. - I received the updates from Gilles for the BDP calculations. These are all very good comments and will be incorporated into the next dra= ft version which will be published prior to Maastricht. Thanks, Barry Principal Member of Technical Staff JDSU Communication Test (formerly Acterna) Emerging Markets and Technology Research One Milestone Center Court Germantown, MD 20876 (W) 240-404-2227 (C) 301-325-7069 ________________________________ From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Gil= les Forget Sent: Friday, June 25, 2010 12:29 AM To: 'Ed Gastle'; ippm@ietf.org Subject: Re: [ippm] TCP Throughput Testing Methodology draft Bonjour Ed, Thank you very much for all of your very constructive comments. About RFC2544, I would just like to add that it was never meant for network= testing. This RFC was written with lab testing in mind only, right at the = beginning in section 3, it talks about DUTs (Devices Under Test). Plus the complete title is : Benchmarking Methodology for Network Interconn= ect Dev. However, it's a fact of life that it has been used for at least 10= years now, not only for lab testing but for complete end to end network te= sts and that is one of the reasons why we have decided to mention it in the= draft. I know by field experience that it leads to finger pointing situati= ons between business customers and network providers. On the other hand, it= 's hard for us to be very precise about how many frame loss or how much jit= ter is acceptable without entering the SLA (Service Level Agreement) area. = SLAs are not only based on technical variables, they are also based on busi= ness and political variables that we can not define in the present document= . Concerning your last comment, you are absolutely right, there is an error i= n Table 3.2. The error comes from versions 5 of Excel spreadsheets and I ha= ve corrected it in the calculation formula of version 6. At 100M, the theoretical TCP throughput should be 90.699 Mbps for all of th= e 3 calculated RTTs because we reach the maximum frame per seconds at all 3= delays. However, we have to be aware that it is still possible to achieve a better = TCP throughput in some cases when delay increases because it permits more i= n flight bytes between sites. Thanks, Gilles Forget, CCNP. From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Ed = Gastle Sent: June-24-10 3:00 PM To: ippm@ietf.org Subject: [ippm] TCP Throughput Testing Methodology draft Some comments on the TCP Throughput Testing Methodology draft: * The acronym MSS is referred to in the Introduction but not defined unt= il 3.1 - suggest it be defined when the acronym is first used. * The Introduction seems to too narrowly focus the draft to the "network= provider community". It seems this test methodology would also be useful i= n a LAN/Campus (private managed network) environment. * The Introduction (last paragraph) as well as section 3 recommends tha= t RFC2544 tests be performed as a precursor to conducting TCP throughput te= sts. The stated purpose of this step is to "verify the integrity of the net= work before conducting TCP testing." What network integrity characteristics= that affect TCP throughput tests should be clearly spelt out in the introd= uction. It seems the main parameter is frame loss and a stable delay (absen= ce of jitter). But what level of frame loss and jitter that are acceptable = are not defined. In addition there are many ways to test loss without perfo= rming RFC2544 tests. With this in mind it seems recommending RFC2544 is too= restrictive a requirement. My main point here is the network performance p= arameters that must be in place to make performing TCP throughput testing a= ccurate should be more clearly defined and explained. The method of measuri= ng the network for these parameters should be left open. * The BDP calculation in section 3.2 should have the units of measure de= fined (BDP in Bits, RTT in ms, Bandwidth in bps) * Although there are many factors at play (TCP Window in particular) it = seems counter-intuitive that maximum achievable TCP throughput in some case= s INCREASES with delay. Referring to Table 3.2 a link with 100Mb of bandwid= th and 2 ms of delay has greater TCP throughput than a link with 1 ms of de= lay. Are the calculations here correct? Ed Gastle --_000_94DEE80C63F7D34F9DC9FE69E39436BE38B7E69AC8MILEXCH1dsjds_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ed,

 

- Regarding the applicability to enterprise network groups and network providers, this is a very good point.=   We have been focused upon network providers since this methodology is envision= ed as a qualification / turn-up test, but agree it is equally applicable to en= terprise groups.

 

- Al and others made similar comments relating to other means besides RFC-2544 to pre-qualify the network; I adde= d some text to broaden the scope of the functional network testing; obviously more clarification is required in this area.

 

- I received the updates from Gilles f= or the BDP calculations.

 

These are all very good comments and w= ill be incorporated into the next draft version which will be published prior t= o Maastricht.

 

Thanks,

Barry=

<= span style=3D'font-size:12.0pt;color:navy'> 

Principal Member of Technical Staff

 

JDSU Communication Test (formerly Acte= rna)

Emerging Markets and Technology Research         =

One Mileston= e Center Court     &nb= sp;            =            

Germantown, MD 20876     &nbs= p;            &= nbsp;           &nbs= p;         

(W) 240-404-2227          &nb= sp;            =             &nb= sp;           

(C) 301-325-7069

From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Gilles Forget
Sent: Friday, June 25, 2010 = 12:29 AM
To: 'Ed Gastle'; ippm@ietf.o= rg
Subject: Re: [ippm] TCP Thro= ughput Testing Methodology draft

 

Bonjour Ed,

 

Thank you very= much for all of your very constructive comments.

 

About RFC2544,= I would just like to add that it was never meant for network testing. This RF= C was written with lab testing in mind only, right at the beginning in sectio= n 3, it talks about DUTs (Devices Under Test).

Plus the compl= ete title is : Benchmarking Methodology for Network Interconnect Dev. However, = it’s a fact of life that it has been used for at least 10 years now, not only fo= r lab testing but for complete end to end network tests and that is one of th= e reasons why we have decided to mention it in the draft. I know by field experience that it leads to finger pointing situations between business customers and network providers. On the other hand, it’s hard for us = to be very precise about how many frame loss or how much jitter is acceptable without entering the SLA (Service Level Agreement) area. SLAs are not only based on technical variables, they are also based on business and political variable= s that we can not define in the present document.

 

Concerning you= r last comment, you are absolutely right, there is an error in Table 3.2. The erro= r comes from versions 5 of Excel spreadsheets and I have corrected it in the calculation formula of version 6.

At 100M, the theoretical TCP throughput should be 90.699 Mbps for all of the 3 calculate= d RTTs because we reach the maximum frame per seconds at all 3 delays.

However, we ha= ve to be aware that it is still possible to achieve a better TCP throughput in so= me cases when delay increases because it permits more in flight bytes between sites.

 

Thanks,

Gilles Forget,= CCNP.

 

 

 

From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Ed Gastle
Sent: June-24-10 3:00 PM
To: ippm@ietf.org
Subject: [ippm] TCP Throughp= ut Testing Methodology draft

 

Some comments on the TCP Throughput Testing Methodology draft:

  

  • The acronym MSS is referred to= in the Introduction but not defined until 3.1 - suggest it be defined when th= e acronym is first used.
  • The Introduction seems to too = narrowly focus the draft to the "network provider community". It seem= s this test methodology would also be useful in a LAN/Campus (private managed network) environment.
  • The Introduction (last paragraph)  as well as section 3 recommends that RFC2544 tests be performed as a precursor to conducting TCP throughput tests. The state= d purpose of this step is to "verify the integrity of the network before conducting TCP testing." What network integrity characteristics that affect TCP throughput tests should be clearly spe= lt out in the introduction. It seems the main parameter is frame loss and= a stable delay (absence of jitter). But what level of frame loss and jit= ter that are acceptable are not defined. In addition there are many ways t= o test loss without performing RFC2544 tests. With this in mind it seems recommending RFC2544 is too restrictive a requirement. My main point h= ere is the network performance parameters that must be in place to make performing TCP throughput testing accurate should be more clearly defi= ned and explained. The method of measuring the network for these parameter= s should be left open.
  • The BDP calculation in section= 3.2 should have the units of measure defined (BDP in Bits, RTT in ms, Bandwidth in bps)
  • Although there are many factor= s at play (TCP Window in particular) it seems counter-intuitive that maximu= m achievable TCP throughput in some cases INCREASES with delay. Referrin= g to Table 3.2 a link with 100Mb of bandwidth and 2 ms of delay has greater= TCP throughput than a link with 1 ms of delay. Are the calculations here correct?

Ed Gastle

--_000_94DEE80C63F7D34F9DC9FE69E39436BE38B7E69AC8MILEXCH1dsjds_-- From brent.bowers@cox.com Sun Jun 27 12:12:32 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 4EDFF3A68DB for ; Sun, 27 Jun 2010 12:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1 X-Spam-Level: * X-Spam-Status: No, score=1 tagged_above=-999 required=5 tests=[BAYES_80=2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reeM6Qbfw2sb for ; Sun, 27 Jun 2010 12:12:31 -0700 (PDT) Received: from cox.com (post3.cox.com [24.248.72.35]) by core3.amsl.com (Postfix) with ESMTP id 119E93A69CC for ; Sun, 27 Jun 2010 12:12:30 -0700 (PDT) Received: from ([192.168.72.254]) by post3.cox.com with ESMTP with TLS id 5503596.24853924; Sun, 27 Jun 2010 15:12:34 -0400 Received: from CATL0MS100.corp.cox.com ([169.254.1.149]) by CATL0MS401.corp.cox.com ([10.62.236.87]) with mapi; Sun, 27 Jun 2010 15:12:33 -0400 From: To: Date: Sun, 27 Jun 2010 15:12:31 -0400 Thread-Topic: [ippm] TCP Throughput Testing Methodology draft Thread-Index: AcsWLLGp1WOCSW5HTz2jIUNQlwL3lw== Message-ID: References: <94DEE80C63F7D34F9DC9FE69E39436BE38B7E69AC8@MILEXCH1.ds.jdsu.net> In-Reply-To: <94DEE80C63F7D34F9DC9FE69E39436BE38B7E69AC8@MILEXCH1.ds.jdsu.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ippm@ietf.org Subject: Re: [ippm] TCP Throughput Testing Methodology draft 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, 27 Jun 2010 19:12:32 -0000 There is definitely a high applicability to large/national enterprise organ= izations for this type of testing. Cox is performing more TCP layer testin= g to qualify end-customer network service and a standard test methodology i= s a good idea. Our own IT group actually had an issue as well that wound up being a TCP RW= IN problem for an application served out of our Atlanta data center with cl= ients on the West coast. Brent Bowers Director, Commercial Engineering CCIE #13530 Cox Communications, Inc. 619.266.5436 (Office) 619.972.5436 (Mobile) On Jun 26, 2010, at 3:51 AM, Barry Constantine wrote: Ed, - Regarding the applicability to enterprise network groups and network prov= iders, this is a very good point. We have been focused upon network provid= ers since this methodology is envisioned as a qualification / turn-up test,= but agree it is equally applicable to enterprise groups. - Al and others made similar comments relating to other means besides RFC-2= 544 to pre-qualify the network; I added some text to broaden the scope of t= he functional network testing; obviously more clarification is required in = this area. - I received the updates from Gilles for the BDP calculations. These are all very good comments and will be incorporated into the next dra= ft version which will be published prior to Maastricht. Thanks, Barry Principal Member of Technical Staff JDSU Communication Test (formerly Acterna) Emerging Markets and Technology Research One Milestone Center Court Germantown, MD 20876 (W) 240-404-2227 (C) 301-325-7069 ________________________________ From: ippm-bounces@ietf.org [mailto:ippm-boun= ces@ietf.org] On Behalf Of Gilles Forget Sent: Friday, June 25, 2010 12:29 AM To: 'Ed Gastle'; ippm@ietf.org Subject: Re: [ippm] TCP Throughput Testing Methodology draft Bonjour Ed, Thank you very much for all of your very constructive comments. About RFC2544, I would just like to add that it was never meant for network= testing. This RFC was written with lab testing in mind only, right at the = beginning in section 3, it talks about DUTs (Devices Under Test). Plus the complete title is : Benchmarking Methodology for Network Interconn= ect Dev. However, it=92s a fact of life that it has been used for at least = 10 years now, not only for lab testing but for complete end to end network = tests and that is one of the reasons why we have decided to mention it in t= he draft. I know by field experience that it leads to finger pointing situa= tions between business customers and network providers. On the other hand, = it=92s hard for us to be very precise about how many frame loss or how much= jitter is acceptable without entering the SLA (Service Level Agreement) ar= ea. SLAs are not only based on technical variables, they are also based on = business and political variables that we can not define in the present docu= ment. Concerning your last comment, you are absolutely right, there is an error i= n Table 3.2. The error comes from versions 5 of Excel spreadsheets and I ha= ve corrected it in the calculation formula of version 6. At 100M, the theoretical TCP throughput should be 90.699 Mbps for all of th= e 3 calculated RTTs because we reach the maximum frame per seconds at all 3= delays. However, we have to be aware that it is still possible to achieve a better = TCP throughput in some cases when delay increases because it permits more i= n flight bytes between sites. Thanks, Gilles Forget, CCNP. From: ippm-bounces@ietf.org [mailto:ippm-boun= ces@ietf.org] On Behalf Of Ed Gastle Sent: June-24-10 3:00 PM To: ippm@ietf.org Subject: [ippm] TCP Throughput Testing Methodology draft Some comments on the TCP Throughput Testing Methodology draft: * The acronym MSS is referred to in the Introduction but not defined unt= il 3.1 - suggest it be defined when the acronym is first used. * The Introduction seems to too narrowly focus the draft to the "network= provider community". It seems this test methodology would also be useful i= n a LAN/Campus (private managed network) environment. * The Introduction (last paragraph) as well as section 3 recommends tha= t RFC2544 tests be performed as a precursor to conducting TCP throughput te= sts. The stated purpose of this step is to "verify the integrity of the net= work before conducting TCP testing." What network integrity characteristics= that affect TCP throughput tests should be clearly spelt out in the introd= uction. It seems the main parameter is frame loss and a stable delay (absen= ce of jitter). But what level of frame loss and jitter that are acceptable = are not defined. In addition there are many ways to test loss without perfo= rming RFC2544 tests. With this in mind it seems recommending RFC2544 is too= restrictive a requirement. My main point here is the network performance p= arameters that must be in place to make performing TCP throughput testing a= ccurate should be more clearly defined and explained. The method of measuri= ng the network for these parameters should be left open. * The BDP calculation in section 3.2 should have the units of measure de= fined (BDP in Bits, RTT in ms, Bandwidth in bps) * Although there are many factors at play (TCP Window in particular) it = seems counter-intuitive that maximum achievable TCP throughput in some case= s INCREASES with delay. Referring to Table 3.2 a link with 100Mb of bandwid= th and 2 ms of delay has greater TCP throughput than a link with 1 ms of de= lay. Are the calculations here correct? Ed Gastle From henk@ripe.net Mon Jun 28 04:20:27 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 C9C453A69A8 for ; Mon, 28 Jun 2010 04:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.125 X-Spam-Level: X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=0.474, BAYES_00=-2.599] 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 xEN7+8k4N4ya for ; Mon, 28 Jun 2010 04:20:25 -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 5487A3A68F5 for ; Mon, 28 Jun 2010 04:20:24 -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 1OTCNw-00023U-S6; Mon, 28 Jun 2010 13:20:29 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=guest-100.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OTCNw-0006lf-6m; Mon, 28 Jun 2010 13:20:20 +0200 Message-ID: <4C288573.9030400@ripe.net> Date: Mon, 28 Jun 2010 13:20:19 +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.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Al Morton References: <4C060DC6.1030306@ripe.net> <126BB105-7DE2-4888-B798-D6F0BAF9314D@nokia.com> <201006161556.o5GFu7Vr031032@alpd052.aldc.att.com> In-Reply-To: <201006161556.o5GFu7Vr031032@alpd052.aldc.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5e99ae2d5b38345e23395e0f09336f0e7 X-RIPE-Spam-Level: ---- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5e99ae2d5b38345e23395e0f09336f0e7 Cc: lencia@att.com, IETF IPPM WG Subject: Re: [ippm] AD review: draft-ietf-ippm-twamp-reflect-octets-06 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, 28 Jun 2010 11:20:27 -0000 Al, > In version 07 (not yet submitted), > we've implemented most of your comments below. When do you plan to submit? Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ I confirm today what I denied yesterday. Anonymous Politician. From acmorton@att.com Mon Jun 28 05:51:34 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 35B123A6A2F for ; Mon, 28 Jun 2010 05:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.313 X-Spam-Level: X-Spam-Status: No, score=-105.313 tagged_above=-999 required=5 tests=[AWL=0.483, 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 efH1jcx0O+q5 for ; Mon, 28 Jun 2010 05:51:29 -0700 (PDT) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id B8E753A68DF for ; Mon, 28 Jun 2010 05:51:29 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-7.tower-129.messagelabs.com!1277729498!28347984!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 20997 invoked from network); 28 Jun 2010 12:51:39 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-7.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Jun 2010 12:51:39 -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 o5SCprQ7025536 for ; Mon, 28 Jun 2010 08:51:53 -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 o5SCpkGQ025427 for ; Mon, 28 Jun 2010 08:51:46 -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 o5SCpVbD021513 for ; Mon, 28 Jun 2010 08:51:31 -0400 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id o5SCpQ1C021328 for ; Mon, 28 Jun 2010 08:51:26 -0400 Message-Id: <201006281251.o5SCpQ1C021328@alpd052.aldc.att.com> Received: from acmt.att.com (martym.mt.att.com[135.16.251.71](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100628125120gw100s4pp7e>; Mon, 28 Jun 2010 12:51:26 +0000 X-Originating-IP: [135.16.251.71] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 28 Jun 2010 08:51:39 -0400 To: Henk Uijterwaal From: Al Morton In-Reply-To: <4C288573.9030400@ripe.net> References: <4C060DC6.1030306@ripe.net> <126BB105-7DE2-4888-B798-D6F0BAF9314D@nokia.com> <201006161556.o5GFu7Vr031032@alpd052.aldc.att.com> <4C288573.9030400@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: lencia@att.com, IETF IPPM WG Subject: Re: [ippm] AD review: draft-ietf-ippm-twamp-reflect-octets-06 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, 28 Jun 2010 12:51:34 -0000 At 07:20 AM 6/28/2010, Henk Uijterwaal wrote: >Al, > >>In version 07 (not yet submitted), >>we've implemented most of your comments below. > >When do you plan to submit? We were waiting to hear a reply, since we didn't agree with a few comments, but as time is short for the deadline we will post 07 shortly... From henk@ripe.net Mon Jun 28 07:01:34 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 83B5E28C12D for ; Mon, 28 Jun 2010 07:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=0.455, BAYES_00=-2.599] 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 Vzo8V1e+FCUA for ; Mon, 28 Jun 2010 07:01:33 -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 7FA0428C112 for ; Mon, 28 Jun 2010 07:01:33 -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 1OTEtz-0002VB-Kj; Mon, 28 Jun 2010 16:01:41 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=guest-100.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OTEtz-00062n-GQ; Mon, 28 Jun 2010 16:01:35 +0200 Message-ID: <4C28AB3F.7010103@ripe.net> Date: Mon, 28 Jun 2010 16:01:35 +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.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Al Morton References: <4C060DC6.1030306@ripe.net> <126BB105-7DE2-4888-B798-D6F0BAF9314D@nokia.com> <201006161556.o5GFu7Vr031032@alpd052.aldc.att.com> <4C288573.9030400@ripe.net> <201006281251.o5SCpQuo021325@alpd052.aldc.att.com> In-Reply-To: <201006281251.o5SCpQuo021325@alpd052.aldc.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d59d51ad2efce99f8108eabe3ccc0c91de X-RIPE-Spam-Level: ---- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d59d51ad2efce99f8108eabe3ccc0c91de Cc: lencia@att.com, IETF IPPM WG Subject: Re: [ippm] AD review: draft-ietf-ippm-twamp-reflect-octets-06 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, 28 Jun 2010 14:01:34 -0000 On 28/06/2010 14:51, Al Morton wrote: > At 07:20 AM 6/28/2010, Henk Uijterwaal wrote: >> Al, >> >>> In version 07 (not yet submitted), >>> we've implemented most of your comments below. >> >> When do you plan to submit? > We were waiting to hear a reply, since we didn't agree with > a few comments, but as time is short for the deadline > we will post 07 shortly... Yes, please do post before the deadline for Maastricht. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ I confirm today what I denied yesterday. Anonymous Politician. From henk@ripe.net Mon Jun 28 07:29:37 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 F1F313A6895 for ; Mon, 28 Jun 2010 07:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599] 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 6x+uzFDP0sUY for ; Mon, 28 Jun 2010 07:29:36 -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 602383A67F4 for ; Mon, 28 Jun 2010 07:29:36 -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 1OTFL9-00007D-Hl for ippm@ietf.org; Mon, 28 Jun 2010 16:29:44 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=guest-100.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OTFL9-0007Yo-Dx for ippm@ietf.org; Mon, 28 Jun 2010 16:29:39 +0200 Message-ID: <4C28B1D3.7080106@ripe.net> Date: Mon, 28 Jun 2010 16:29:39 +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.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 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: e0cdef1f45f89a40ad608d255b27e7d5dcb2bb6e0a100468002b8e635f80c77e X-RIPE-Spam-Level: ---- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5dcb2bb6e0a100468002b8e635f80c77e Subject: [ippm] Deadlines for Maastricht 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, 28 Jun 2010 14:29:38 -0000 All, Please note the following dates: # 2010-07-05 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PDT (24:00 UTC), upload using IETF ID Submission Tool. # 2010-07-12 (Monday): Internet Draft final submission cut-off by 17:00 PDT (24:00 UTC), upload using IETF ID Submission Tool. That is next Monday and the Monday after that. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ I confirm today what I denied yesterday. Anonymous Politician. From root@core3.amsl.com Mon Jun 28 08:15:06 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 CDCAD3A690C; Mon, 28 Jun 2010 08:15: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: <20100628151505.CDCAD3A690C@core3.amsl.com> Date: Mon, 28 Jun 2010 08:15:02 -0700 (PDT) Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-twamp-reflect-octets-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: Mon, 28 Jun 2010 15:15:06 -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-07.txt Pages : 19 Date : 2010-06-28 This memo describes two closely-related features for the core specification of TWAMP - the Two-Way Active Measurement Protocol: an optional capability where the responding host returns some of the command octets or padding octets to the sender, and an optional sender packet format that ensures equal test packet sizes are used in both directions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-twamp-reflect-octets-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-reflect-octets-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-28081229.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jun 28 11:45: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 1A4BF3A693E; Mon, 28 Jun 2010 11:45: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: <20100628184504.1A4BF3A693E@core3.amsl.com> Date: Mon, 28 Jun 2010 11:45:01 -0700 (PDT) Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-reporting-metrics-03.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 18:45: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 : Reporting Metrics: Different Points of View Author(s) : A. Morton, et al. Filename : draft-ietf-ippm-reporting-metrics-03.txt Pages : 22 Date : 2010-06-28 Consumers of IP network performance metrics have many different uses in mind. The memo provides "long-term" reporting considerations (e.g, days, weeks or months, as opposed to 10 seconds), based on analysis of the two key audience points-of-view. It describes how the audience categories affect the selection of metric parameters and options when seeking info that serves their needs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-reporting-metrics-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ippm-reporting-metrics-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-28114440.I-D@ietf.org> --NextPart-- From acmorton@att.com Mon Jun 28 12:30:13 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9B693A694A for ; Mon, 28 Jun 2010 12:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.514 X-Spam-Level: X-Spam-Status: No, score=-103.514 tagged_above=-999 required=5 tests=[AWL=-1.557, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24, 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 whF2kpIGvF+m for ; Mon, 28 Jun 2010 12:30:06 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id C20EF3A6960 for ; Mon, 28 Jun 2010 12:30:03 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-2.tower-161.messagelabs.com!1277753412!25288331!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 25990 invoked from network); 28 Jun 2010 19:30:13 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-2.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Jun 2010 19:30:13 -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 o5SJTnSa001506 for ; Mon, 28 Jun 2010 15:29:49 -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 o5SJTiQa001407 for ; Mon, 28 Jun 2010 15:29:44 -0400 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id o5SJU73L008638 for ; Mon, 28 Jun 2010 14:30:07 -0500 Received: from mailgw1.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 o5SJU12V008322 for ; Mon, 28 Jun 2010 14:30:01 -0500 Message-Id: <201006281930.o5SJU12V008322@klpd017.kcdc.att.com> Received: from acmt.att.com (martym.mt.att.com[135.16.251.71](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100628193000gw100s4psae>; Mon, 28 Jun 2010 19:30:01 +0000 X-Originating-IP: [135.16.251.71] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 28 Jun 2010 15:30:18 -0400 To: ippm@ietf.org From: Al Morton Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ippm] Comments on Reordering Def. in draft-ietf-ippm-reporting-04.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 19:30:13 -0000 IPPM, At the last IPPM meeting, Matt Z. alerted us to a possible problem with the reordering metric definition in section 4.5 of http://tools.ietf.org/html/draft-ietf-ippm-reporting-04#section-4.5 >4.5. Reordering > > Reordering is the fraction of packets sent but not lost for which the > sequence number of the packet received immediately before the first > copy of the given packet is not the decrement of the sequence number > of the given packet. For the purposes of determining the sequence > number of the preceding packet in this definition, assuming sequence > numbers starting with 1, an extra packet at the start of the stream > of received packets, with a sequence number of 0, is considered to be > present (this extra packet, of course, is not counted for the > purposes of computing the fraction). > > For more information, refer to section 4.1.3 (Type-P-Reordered-Ratio- > Stream) of RFC 4737 [RFC4737] (Packet Reordering Metrics), and > supporting text. > > {Comment: As the non-normative sample code in Appendix A below shows, > this is also related to the amount of 1-reordering (Section 5.3 RFC > 4737 [RFC4737]). It is not, however, the degree of 1-reordering in > 5.3; because that divides by the number of all packets received, > instead of the number of non-duplicate packets received.} We reached consensus long ago that this reporting draft would not define any new metrics, it would simply re-use the existing metrics in a "short term" (10 second) repeated reporting scenario. Specifically, the definition above is a fairly strict enforcement of original sequence numbering, such that all packets not following the sequence reference (the previous packet) are declared reordered. Also, the definition above does not account for lost packets in it's brief specification of sequence number processing, while the Reordered packet definition in RFC 4737 easily avoids the problem and maintains orthogonality with the packet loss metric. In other words, prior packet loss alone cannot cause an arriving packet to be declared reordered. The RFC 4737 metric enforces a non-reversing order, and only packets that arrive "late" are declared reordered. Example: Sequence numbers arrive in the following order: 1 2 3 4 7 5 6 8 Designation by Def above: - - - - R R - R Designation by RFC 4737: - - - - - R R - Example: Sequence numbers arrive in the following order (with #6 Lost): 1 2 3 4 7 5 8 Designation by Def above: - - - - R R R Designation by RFC 4737: - - - - - R - I suggest, for replacement text (since the current text is not easily fixable for consistency with RFC 4737): 4.5. Reordering The definition of a reordered packet may be found in section 3 of RFC 4737. Reordering is expressed as the ratio "Type-P-Reordered-Ratio-Stream" as defined in section 4.1 of RFC 4737. Al From root@core3.amsl.com Tue Jun 29 06:45: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 7D5A93A6A33; Tue, 29 Jun 2010 06:45: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: <20100629134502.7D5A93A6A33@core3.amsl.com> Date: Tue, 29 Jun 2010 06:45:02 -0700 (PDT) Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-loss-episode-metrics-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: Tue, 29 Jun 2010 13:45: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 : Loss Episode Metrics for IPPM Author(s) : N. Duffield, et al. Filename : draft-ietf-ippm-loss-episode-metrics-00.txt Pages : 22 Date : 2010-06-29 The IETF has developed a one way packet loss metric that measures the loss rate on a Poisson probe stream between two hosts. However, the impact of packet loss on applications is in general sensitive not just to the average loss rate, but also to the way in which packet losses are distributed in loss episodes (i.e., maximal sets of consecutively lost probe packets). This draft defines one-way packet loss episode metrics, specifically the frequency and average duration of loss episodes, and a probing methodology under which the loss episode metrics are to be measured. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-loss-episode-metrics-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-loss-episode-metrics-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-29064024.I-D@ietf.org> --NextPart-- From lars.eggert@nokia.com Wed Jun 30 06:27:06 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 D310E28B23E for ; Wed, 30 Jun 2010 06:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.745 X-Spam-Level: X-Spam-Status: No, score=-4.745 tagged_above=-999 required=5 tests=[AWL=-1.346, BAYES_50=0.001, J_CHICKENPOX_31=0.6, 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 HuyE8VK2Oxls for ; Wed, 30 Jun 2010 06:27:05 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 17DC73A6AC4 for ; Wed, 30 Jun 2010 06:27:04 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o5UDQwQH028539 for ; Wed, 30 Jun 2010 16:27:12 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Jun 2010 16:27:06 +0300 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Jun 2010 16:27:06 +0300 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o5UDR2BJ007732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 30 Jun 2010 16:27:03 +0300 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.1 at fit.nokia.com Content-Type: multipart/signed; boundary=Apple-Mail-36--1050497423; protocol="application/pkcs7-signature"; micalg=sha1 Date: Wed, 30 Jun 2010 14:26:53 +0100 Message-Id: <9C708D19-C6FB-48A4-B5CC-2F20D09AA1E8@nokia.com> To: IETF IPPM WG Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.fit.nokia.com); Wed, 30 Jun 2010 16:26:55 +0300 (EEST) X-OriginalArrivalTime: 30 Jun 2010 13:27:06.0150 (UTC) FILETIME=[EF051460:01CB1857] X-Nokia-AV: Clean Subject: [ippm] AD review: draft-ietf-ippm-spatial-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: Wed, 30 Jun 2010 13:27:06 -0000 --Apple-Mail-36--1050497423 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Summary: ready to go, modulo a quick check regarding the IANA actions = (see below) Section 1., paragraph 0: > 1. Contributors Typically, this would be found in the Acknowledgement section. Also, the intro text needs to be changed ("thus far" doesn't make sense when this is being published.) Section 2., paragraph 1: > composition, spatial and temporal. The new composition framework Nit: s/new// Section 2.1., paragraph 1: > One-way metrics defined in other IPPM RFCs all assume that the Suggest to informally cite the relevant RFCs rather than referring to them with the unspecific "IPPM RFCs" term. Section 2.1., paragraph 2: > measurement can not be executed from the source to the destination. Nit: s/can not/cannot/ Section 3.1., paragraph 1: > For the primary IPPM metrics of Loss, Delay, and Delay Variation, Nit: add citations Section 4.1.1., paragraph 13: > o Type-P, as defined in [RFC2330], which includes any field that = may > affect a packet's treatment as it traverses network Nit: s/traverses network/traverses the network/ Section 4.1.10., paragraph 7: > REQUIRES assumption of sub-path independence w.r.t. the metric = being > defined/composed. REQUIRES is not an RFC2119 term. Section 5.2.9., paragraph 2: > The mean may not be sufficiently robust statistic to produce a Nit: s/sufficiently robust statistic/a sufficiently robust statistic/ Section 6.1.9., paragraph 3: > Or, when traffic volumes rise due to the rapid spread of an email- > born worm, loss due to queue overflow in one network may help = another Nit: s/born/borne/ Section 7.1.4., paragraph 0: > 7.1.4. Statistics: Mean, Variance, Skewness, Quanitle Nit: s/Quanitle/Quantile/ Section 8.1., paragraph 1: > method could be abused for denial of service attacks directed at > destination and/or the intervening network(s). Nit: s/destination/the destination/ Section 9., paragraph 0: > 9. IANA Considerations > > Metrics defined in IETF are typically registered in the IANA IPPM > METRICS REGISTRY as described in initial version of the registry > [RFC4148]. However, areas for improvement of this registry have = been > identified, and the registry structure has to be revisited when = there > is consensus to do so. > > Therefore, the metrics in this draft may be considered for > registration in the future, and no IANA Action is requested at this > time. Henk's writeup said: > There is one practical issues, see section 9. >=20 > The problem is that we defined a registry for our metrics but that it > has seen almost no use at all. This makes it hard to ask people to > continue to maintain it. >=20 > There are suggestions to improve the registry to something that is > useful, but these have to go through the entire WG process. I don't > think we should wait for that with this document, but rather just > publish it and fix things if/when there is consensus on a new > registry format. And if the group decides to abandon the regisitry, > then no time is wasted here either. This is the first I hear about there being a registry issue. In any = event, if there is, we will need to fix this, and I don;t want to hold = this draft up either. Unfortunately, we cannot publish this and simply = ignore the existing registry and its rules. The quickest way forward = would be to add the missing registry entries to this draft. Section 10., paragraph 0: > 10. Acknowlegements Nit: s/Acknowlegements/Acknowledgements/ Section 11.1., paragraph 2: > [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, > "Framework for IP Performance Metrics", RFC 2330, > May 1998. Downref: Normative reference to an Informational RFC: RFC 2330. I saw Henk's writeup comment and will call this out during the IETF last call. Section 11.1., paragraph 8: > [RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric > Composition", RFC 5835, April 2010. Downref: Normative reference to an Informational RFC: RFC 5835. Did not see this in Henk's writeup, do we want to ask the community to OK this downref? --Apple-Mail-36--1050497423 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQM/3DDmRp5mxHvrbX tRvSsDANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTA5MTAxNDAwMDAwMFoXDTEwMTAxNDIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC0xhcnMgRWdn ZXJ0MSQwIgYJKoZIhvcNAQkBFhVsYXJzLmVnZ2VydEBub2tpYS5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCrTp9sa04QO3gKan1sQGFAZ91BKjFdECaw29ZXHYOZSFW7JC/oyuAO x7pucJp9qDLYlv60I8zLJ1eocDn3bsjBWwAS65GGVT9NLiblzCd5DeWTkn9UD7OMvLL+Z1Z17sE0 jlmluQSCLjv0P7d6ZCpwVD2hWvuZu37fIQresIEYQLbZHXogwoCMhqwo8k8/WuwDbNcB9RiLq3JW FRjZILMmf5qFdExz1AZyG3OdFXe1F0vcxfHhbrGU5cVklV9XI3TfxVZciFNqnTuWsaHFxU0ZrwI0 njVtpLko1TW1vC5qS2ZIpWq7iDkIke+XL4IYTHlOdH7sM502qEE8JqadXjuTAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJraU8e1Ss8a Uj33lweT8ibOcmNLTNn2pnSi7p5BwNCFtrLNp9AdhcGYJfEQMOlanxc7dpQ7OWUbpub4jAYKyP47 hPQayKMJ73KcKmiN4Czj9g/uCTRwW3kiyhTo22Yl2MWGTM7WI39xTEQo4DOGs9EK6Ldb9zZU4oRl ZbaD1G/Lo33LYmuI8MfCLzTBtmT5MybyEnK17457+8bMLXoSFJfFGk5LPCn38SWdiAG/YH2A4had 3wvpd9Mpx38fxw/RZqlifRSTT8zlOwkq/u/+il9D4o2ruwMEMC1ZwPN3/w/u+QCw4o78wm24BOwU KyA6H4H1r9BoUZ1To1zXxwvuI+sxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9KwMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDYzMDEz MjY1M1owIwYJKoZIhvcNAQkEMRYEFL+VCUE8fEfa6qml73E58zIaH1QNMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEDP9ww5kaeZsR76217Ub0rAwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9Kw MA0GCSqGSIb3DQEBAQUABIIBAAXRrpC85prytQKKmhFUiLP3KwMlSLlubXbitnCGwShQlIWu0f9j PWp/eWqGcudS3Wty+9f2Um0j7/NIs6WIK0//um8d5RP9Bh1WoGZwodw7UeDObAlXbn9PTel4I1X/ hbj1RKGhP+pxyW8DiCa3YgziWAR8pkWZt+pWRWp48r2oApdNddAeUFeb4ywwNrNDLhWtn0UWBA1u Uj8H7ruveM4F0+NZk77KVeaMhnqA2V4Y0DohBxU0/kkVo++cZuuPrBObXZjthZfGuqLNDKPjmsq0 ziWUCfmUG+t9ROdVdMJPWSCxXdKWF95bpqK6GRQGvfD/tXkwOYDPCUOv4ZjvlQUAAAAAAAA= --Apple-Mail-36--1050497423-- From acmorton@att.com Wed Jun 30 07:06:39 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 1A5153A6A25 for ; Wed, 30 Jun 2010 07:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.11 X-Spam-Level: X-Spam-Status: No, score=-104.11 tagged_above=-999 required=5 tests=[AWL=-0.402, BAYES_05=-1.11, J_CHICKENPOX_31=0.6, 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 7cJj6yGIU89Y for ; Wed, 30 Jun 2010 07:06:38 -0700 (PDT) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id 1C44F3A676A for ; Wed, 30 Jun 2010 07:06:37 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-5.tower-129.messagelabs.com!1277906807!33070475!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 16364 invoked from network); 30 Jun 2010 14:06:48 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-5.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Jun 2010 14:06:48 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o5UE72oM010082 for ; Wed, 30 Jun 2010 10:07:02 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o5UE6xv8010016 for ; Wed, 30 Jun 2010 10:07:00 -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 o5UE6ids030786 for ; Wed, 30 Jun 2010 10:06:44 -0400 Received: from mailgw1.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id o5UE6d97030605 for ; Wed, 30 Jun 2010 10:06:39 -0400 Message-Id: <201006301406.o5UE6d97030605@alpd052.aldc.att.com> Received: from acmt.att.com (martym.mt.att.com[135.16.251.71](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100630140639gw100s4p2ve>; Wed, 30 Jun 2010 14:06:39 +0000 X-Originating-IP: [135.16.251.71] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 30 Jun 2010 10:06:57 -0400 To: Lars Eggert , IETF IPPM WG From: Al Morton In-Reply-To: <9C708D19-C6FB-48A4-B5CC-2F20D09AA1E8@nokia.com> References: <9C708D19-C6FB-48A4-B5CC-2F20D09AA1E8@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [ippm] AD review: draft-ietf-ippm-spatial-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: Wed, 30 Jun 2010 14:06:39 -0000 At 09:26 AM 6/30/2010, Lars Eggert wrote: >... >Henk's writeup said: > > > There is one practical issues, see section 9. > > > > The problem is that we defined a registry for our metrics but that it > > has seen almost no use at all. This makes it hard to ask people to > > continue to maintain it. > > > > There are suggestions to improve the registry to something that is > > useful, but these have to go through the entire WG process. I don't > > think we should wait for that with this document, but rather just > > publish it and fix things if/when there is consensus on a new > > registry format. And if the group decides to abandon the regisitry, > > then no time is wasted here either. > >This is the first I hear about there being a registry issue. In any >event, if there is, we will need to fix this, and I don;t want to >hold this draft up either. Unfortunately, we cannot publish this and >simply ignore the existing registry and its rules. The quickest way >forward would be to add the missing registry entries to this draft. We discussed this among chairs and authors as Henk was preparing the DocShep write-up. Emile was willing to supply the entries for the broken registry, but the rest felt that the quickest way forward was to simply make this section a place-holder. *If there is consensus to fix the registry*, all the work must be re-done and included in the initial registry contents. Another possible outcome is that the registry is withdrawn, based on IPPM consensus that what we have is not useful, and what we could create in the registry space with the capability to accommodate all our metric options does not seem practical or useful, in addition to the metric naming conventions we already use and options we already specify. It will certainly take several discussions over time to reach IPPM consensus, starting now and with the session at IETF-78. In any case, thanks for your comments Lars, and sorry about all the stray nits left at this point. Al From emile.stephan@orange-ftgroup.com Wed Jun 30 07:43: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 A88363A6AD6 for ; Wed, 30 Jun 2010 07:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.51 X-Spam-Level: * X-Spam-Status: No, score=1.51 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_FR=0.35, J_CHICKENPOX_31=0.6, MANGLED_DEALS=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ad7YwxIBffQL for ; Wed, 30 Jun 2010 07:42:57 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id B1AD13A6ACD for ; Wed, 30 Jun 2010 07:42:53 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 86BA293000B; Wed, 30 Jun 2010 16:36:58 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id F266B8B801A; Wed, 30 Jun 2010 16:36:57 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jun 2010 16:35:33 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Jun 2010 16:35:30 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462F8CC48@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <201006301406.o5UE6d97030605@alpd052.aldc.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ippm] AD review: draft-ietf-ippm-spatial-composition Thread-Index: AcsYXYCfh7JNfh0KSCeMrjhupAn09wAAqUsg References: <9C708D19-C6FB-48A4-B5CC-2F20D09AA1E8@nokia.com> <201006301406.o5UE6d97030605@alpd052.aldc.att.com> From: To: , , X-OriginalArrivalTime: 30 Jun 2010 14:35:33.0316 (UTC) FILETIME=[7F14E040:01CB1861] Cc: henk@ripe.net, matt@internet2.edu Subject: Re: [ippm] AD review: draft-ietf-ippm-spatial-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: Wed, 30 Jun 2010 14:43:03 -0000 Hi=20 I agree with Lars. This is what I suggested 3 weeks ago: add the metrics = of the draft in the existing registry and then work peacefully on a new = version of the registry.=20 Regards Emile > -----Message d'origine----- > De=A0: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] De la part = de Al > Morton > Envoy=E9=A0: mercredi 30 juin 2010 16:07 > =C0=A0: Lars Eggert; IETF IPPM WG > Objet=A0: Re: [ippm] AD review: draft-ietf-ippm-spatial-composition >=20 > At 09:26 AM 6/30/2010, Lars Eggert wrote: > >... > >Henk's writeup said: > > > > > There is one practical issues, see section 9. > > > > > > The problem is that we defined a registry for our metrics but that = it > > > has seen almost no use at all. This makes it hard to ask people = to > > > continue to maintain it. > > > > > > There are suggestions to improve the registry to something that is > > > useful, but these have to go through the entire WG process. I = don't > > > think we should wait for that with this document, but rather just > > > publish it and fix things if/when there is consensus on a new > > > registry format. And if the group decides to abandon the = regisitry, > > > then no time is wasted here either. > > > >This is the first I hear about there being a registry issue. In any > >event, if there is, we will need to fix this, and I don;t want to > >hold this draft up either. Unfortunately, we cannot publish this and > >simply ignore the existing registry and its rules. The quickest way > >forward would be to add the missing registry entries to this draft. >=20 > We discussed this among chairs and authors as Henk was preparing > the DocShep write-up. Emile was willing to supply the entries > for the broken registry, but the rest felt that the quickest way > forward was to simply make this section a place-holder. > *If there is consensus to fix the registry*, all the work must > be re-done and included in the initial registry contents. >=20 > Another possible outcome is that the registry is withdrawn, based > on IPPM consensus that what we have is not useful, and what we could > create in the registry space with the capability to accommodate all > our metric options does not seem practical or useful, in addition > to the metric naming conventions we already use and options we already > specify. >=20 > It will certainly take several discussions over time to reach IPPM > consensus, starting now and with the session at IETF-78. >=20 > In any case, thanks for your comments Lars, > and sorry about all the stray nits left at this point. >=20 > Al >=20 >=20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From henk@ripe.net Wed Jun 30 08:34: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 9AA8A3A69D4 for ; Wed, 30 Jun 2010 08:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599] 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 rAXxFBPLlytM for ; Wed, 30 Jun 2010 08:34:27 -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 765713A6A3B for ; Wed, 30 Jun 2010 08:34:25 -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 1OTzJ0-0005j9-5a; Wed, 30 Jun 2010 17:34:35 +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 1OTzIz-00064o-VP; Wed, 30 Jun 2010 17:34:30 +0200 Message-ID: <4C2B6405.9070404@ripe.net> Date: Wed, 30 Jun 2010 17:34:29 +0200 From: Henk Uijterwaal Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.4) Gecko/20100608 Lightning/1.0b2 Thunderbird/3.1 MIME-Version: 1.0 To: ippm@ietf.org, Lars Eggert References: <9C708D19-C6FB-48A4-B5CC-2F20D09AA1E8@nokia.com> In-Reply-To: <9C708D19-C6FB-48A4-B5CC-2F20D09AA1E8@nokia.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5cd245d66ad7c036896faec27ecf480a7 X-RIPE-Spam-Level: ---- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5cd245d66ad7c036896faec27ecf480a7 Subject: Re: [ippm] AD review: draft-ietf-ippm-spatial-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: Wed, 30 Jun 2010 15:34:36 -0000 Hi, > Section 11.1., paragraph 2: >> [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, >> "Framework for IP Performance Metrics", RFC 2330, >> May 1998. > > Downref: Normative reference to an Informational RFC: RFC 2330. I saw > Henk's writeup comment and will call this out during the IETF last > call. > > > Section 11.1., paragraph 8: >> [RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric >> Composition", RFC 5835, April 2010. > > Downref: Normative reference to an Informational RFC: RFC 5835. Did > not see this in Henk's writeup, do we want to ask the community to OK > this downref? That's an error in the write-up, the comment applied to both framework documents. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ I confirm today what I denied yesterday. Anonymous Politician. From dombrowh@sdsc.edu Wed Jun 30 08:42:58 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 A63E83A6848 for ; Wed, 30 Jun 2010 08:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.025 X-Spam-Level: * X-Spam-Status: No, score=1.025 tagged_above=-999 required=5 tests=[BAYES_50=0.001, EXTRA_MPART_TYPE=1, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_SPACE_RATIO=2.219] 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 rPRkPSHzY-Zb for ; Wed, 30 Jun 2010 08:42:57 -0700 (PDT) Received: from postal.sdsc.edu (postal.sdsc.edu [132.249.20.114]) by core3.amsl.com (Postfix) with ESMTP id DD1533A67D4 for ; Wed, 30 Jun 2010 08:42:55 -0700 (PDT) Received: from mta.ad.sdsc.edu (mta.ad.sdsc.edu [132.249.69.68]) by postal.sdsc.edu (8.11.7/8.11.7/server/80) with ESMTP id o5UFh7c14943 for ; Wed, 30 Jun 2010 08:43:07 -0700 (PDT) Received: from MBX.ad.sdsc.edu ([fe80::85f9:e068:7dc0:4fe0]) by mta.ad.sdsc.edu ([132.249.69.68]) with mapi; Wed, 30 Jun 2010 08:43:02 -0700 From: Jay Dombrowski To: "ippm@ietf.org" Date: Wed, 30 Jun 2010 08:43:04 -0700 Thread-Topic: unsubscribe Thread-Index: AcsYau24CSnkGtvaT9aYVcKGFlZwsg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_ACC6B628D8BA2A4D9917F78AF74843D04597C4A2FFMBXadsdscedu_"; type="multipart/alternative" MIME-Version: 1.0 Subject: [ippm] unsubscribe 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, 30 Jun 2010 15:42:59 -0000 --_004_ACC6B628D8BA2A4D9917F78AF74843D04597C4A2FFMBXadsdscedu_ Content-Type: multipart/alternative; boundary="_000_ACC6B628D8BA2A4D9917F78AF74843D04597C4A2FFMBXadsdscedu_" --_000_ACC6B628D8BA2A4D9917F78AF74843D04597C4A2FFMBXadsdscedu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks jd 858-534-5023 --_000_ACC6B628D8BA2A4D9917F78AF74843D04597C4A2FFMBXadsdscedu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

Thanks

jd

858-534-5023

 

--_000_ACC6B628D8BA2A4D9917F78AF74843D04597C4A2FFMBXadsdscedu_-- --_004_ACC6B628D8BA2A4D9917F78AF74843D04597C4A2FFMBXadsdscedu_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=92; creation-date="Wed, 30 Jun 2010 08:43:00 GMT"; modification-date="Wed, 30 Jun 2010 08:43:00 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhMgAyAIAAAP///wAAACH5BAAAAAAALAAAAAAyADIAAAIzhI+py+0Po5y02ouz3rz7D4bi SJbmiabqyrbuC8fyTNf2jef6zvf+DwwKh8Si8YhMKicFADs= --_004_ACC6B628D8BA2A4D9917F78AF74843D04597C4A2FFMBXadsdscedu_-- From wwwrun@core3.amsl.com Wed Jun 30 10:05:52 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 C13EA3A6893; Wed, 30 Jun 2010 10:05:52 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100630170552.C13EA3A6893@core3.amsl.com> Date: Wed, 30 Jun 2010 10:05:52 -0700 (PDT) Cc: ippm@ietf.org Subject: [ippm] Last Call: draft-ietf-ippm-twamp-reflect-octets (TWAMP Reflect Octets and Symmetrical Size Features) to Proposed Standard X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 17:05:52 -0000 The IESG has received a request from the IP Performance Metrics WG (ippm) to consider the following document: - 'TWAMP Reflect Octets and Symmetrical Size Features ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-07-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ippm-twamp-reflect-octets-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17857&rfc_flag=0