From nobody Sat Dec 6 14:23:35 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDAC1A1AD9 for ; Sat, 6 Dec 2014 14:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTSshGvwxl3j; Sat, 6 Dec 2014 14:23:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1341A1A7E; Sat, 6 Dec 2014 14:23:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: ietf@wjcerveny.com, draft-ietf-ippm-rate-problem.all@tools.ietf.org, ippm-chairs@tools.ietf.org, ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141206222331.10096.61228.idtracker@ietfa.amsl.com> Date: Sat, 06 Dec 2014 14:23:31 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/4yDlY172ReBPTG1NzZIBwwlG7js Subject: [ippm] ID Tracker State Update Notice: X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2014 22:23:33 -0000 IESG state changed to AD Evaluation from Publication Requested ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem/ From nobody Sat Dec 6 14:23:55 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE7431A1AFE for ; Sat, 6 Dec 2014 14:23:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhP-1RHUkblP; Sat, 6 Dec 2014 14:23:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1091A1AEC; Sat, 6 Dec 2014 14:23:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: ietf@wjcerveny.com, draft-ietf-ippm-rate-problem.all@tools.ietf.org, ippm-chairs@tools.ietf.org, ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141206222351.3629.62977.idtracker@ietfa.amsl.com> Date: Sat, 06 Dec 2014 14:23:51 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/X8Glp7dayJR3f-mO6LqvykI0h40 Subject: [ippm] ID Tracker State Update Notice: X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2014 22:23:53 -0000 IESG state changed to Last Call Requested from AD Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem/ From nobody Mon Dec 8 06:43:33 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D131A9092; Mon, 8 Dec 2014 06:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fnve5heYGcNj; Mon, 8 Dec 2014 06:43:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 525F51A9094; Mon, 8 Dec 2014 06:43:19 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20141208144319.25925.72497.idtracker@ietfa.amsl.com> Date: Mon, 08 Dec 2014 06:43:19 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/kiW_o6JCWX6mI6kJtGhI0pxx1bQ Cc: ippm@ietf.org Subject: [ippm] Last Call: (Rate Measurement Test Protocol Problem Statement) to Informational RFC X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 08 Dec 2014 14:43:30 -0000 The IESG has received a request from the IP Performance Metrics WG (ippm) to consider the following document: - 'Rate Measurement Test Protocol Problem Statement' as Informational RFC 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 2014-12-22. 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. Abstract This memo presents an access rate-measurement problem statement for test protocols to measure IP Performance Metrics. The rate measurement scenario has wide-spread attention of Internet access subscribers and seemingly all industry players, including regulators. Key test protocol aspects require the ability to control packet size on the tested path and enable asymmetrical packet size testing in a controller-responder architecture. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Dec 8 06:43:39 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E3A1A90A0 for ; Mon, 8 Dec 2014 06:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_I143fThzTZ; Mon, 8 Dec 2014 06:43:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAB91A9099; Mon, 8 Dec 2014 06:43:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: ietf@wjcerveny.com, draft-ietf-ippm-rate-problem.all@tools.ietf.org, ippm-chairs@tools.ietf.org, ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141208144323.25925.65996.idtracker@ietfa.amsl.com> Date: Mon, 08 Dec 2014 06:43:23 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/-tJr5mGrpE1uwzJ9xqcLeetJezQ Subject: [ippm] ID Tracker State Update Notice: X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 14:43:35 -0000 Last call has been made for draft-ietf-ippm-rate-problem and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem/ From nobody Wed Dec 10 07:38:18 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4281A1E0F for ; Wed, 10 Dec 2014 07:38:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2dFmwDB2Lnb for ; Wed, 10 Dec 2014 07:38:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E22E1A6ED8 for ; Wed, 10 Dec 2014 07:38:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141210153811.5786.76187.idtracker@ietfa.amsl.com> Date: Wed, 10 Dec 2014 07:38:11 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/umrsB50b-7iaE0wL0Nf9YPnpEdM Subject: [ippm] Milestones changed for ippm WG X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 15:38:17 -0000 URL: http://datatracker.ietf.org/wg/ippm/charter/ From nobody Wed Dec 10 09:28:16 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189E71A8760 for ; Wed, 10 Dec 2014 09:28:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjmQHsU2ra7s for ; Wed, 10 Dec 2014 09:28:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB3B1A8770 for ; Wed, 10 Dec 2014 09:28:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141210172812.26420.5437.idtracker@ietfa.amsl.com> Date: Wed, 10 Dec 2014 09:28:12 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/gL3yEElMd5ST4jO0g-iB8cxpDGA Subject: [ippm] Milestones changed for ippm WG X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 17:28:15 -0000 Changed milestone "Submit draft on "A One-Way Delay Metric for IPPM" (RFC 2679 bis) as Internet Standard", set state to active from review, accepting new milestone. Changed milestone "Submit draft on "A One-Way Loss Metric for IPPM" (RFC 2680 bis) as Internet Standard", set state to active from review, accepting new milestone. Changed milestone "Submit draft on DSCP and ECN monitoring in TWAMP to IESG as Proposed Standard", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/ippm/charter/ From nobody Wed Dec 10 14:06:49 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F341A899B for ; Wed, 10 Dec 2014 14:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26o1FvM_ZLZR; Wed, 10 Dec 2014 14:06:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B7FD21A8A4D; Wed, 10 Dec 2014 14:06:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: ietf@wjcerveny.com, draft-ietf-ippm-rate-problem.all@tools.ietf.org, ippm-chairs@tools.ietf.org, ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141210220636.4316.67920.idtracker@ietfa.amsl.com> Date: Wed, 10 Dec 2014 14:06:36 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/dmJ8gLy9gx-YBWXTbk_KZU4H4Bo Subject: [ippm] ID Tracker State Update Notice: X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 22:06:46 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem/ From nobody Wed Dec 10 22:43:59 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0E71A8998; Wed, 10 Dec 2014 22:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qI6tsUTETUPi; Wed, 10 Dec 2014 22:43:49 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B75E1A8971; Wed, 10 Dec 2014 22:43:49 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-02-5488ecb3a0ae Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id CF.0F.03307.3BCE8845; Thu, 11 Dec 2014 02:00:36 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0195.001; Thu, 11 Dec 2014 01:43:42 -0500 From: Gregory Mirsky To: "ietf@ietf.org" , "ippm@ietf.org" Thread-Topic: IETF Last Call comments to draft-ietf-ippm-rate-problem Thread-Index: AdAVC33FycgR/mE2Q921Q9GeX2pmdA== Date: Thu, 11 Dec 2014 06:43:42 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8B260C@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B8B260Ceusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyuXRPgu6WNx0hBkducVg82zifxaLjwTt2 i54H75gtlk3Zw+zA4rFz1l12jyVLfjJ5fLn8mS2AOYrLJiU1J7MstUjfLoEr49Ohi0wF180q Drw9yNzA2KPfxcjBISFgIrFoelgXIyeQKSZx4d56ti5GLg4hgSOMEie+b2OEcJYzSsxoWsgE UsUmYCTxYmMPO4gtIuAi8eT0LLA4s8AURom769hAhgoLOEp8bFQAMUUE3CTenkmDqNaT6P94 AayaRUBVYuL05WA2r4CvxIHbm1hBbEagG76fWgM1UVzi1pP5TBC3CUgs2XOeGcIWlXj5+B8r hK0osa9/OjvIKmaBfInLL+0hRgpKnJz5hGUCo/AsJJNmIVTNQlIFUaIjsWD3JzYIW1ti2cLX zDD2mQOPmZDFFzCyr2LkKC1OLctNNzLYxAiMnWMSbLo7GPe8tDzEKMDBqMTDa7C9PUSINbGs uDL3EKM0B4uSOO+s2nnBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhjZFas37vMLu/PSz2y1 gvHa/VMLLhp0VextNJ58xIJpqqTjubJ7+3c9ePs8J7jV5fOnqQ+TvTeKqSck314o/ebQGk+G w32LVDW53rLYOS+vuy/tfTfvtOpSjWsl5XutTfkfrk77lcy+WCRuW6VBXOFb/depyvsiuWxP 9N6d/ndtf+G6Gh0ZieNKLMUZiYZazEXFiQDLoIxpfgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/gQFYURt4f3dbzpO0AzjNKBXet2M Cc: "ippm-chairs@tools.ietf.org" Subject: [ippm] IETF Last Call comments to draft-ietf-ippm-rate-problem X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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, 11 Dec 2014 06:43:53 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B8B260Ceusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, please kindly consider following comments as part of the IETF Last Call: * Abstract. Key test protocol aspects require the ability to control packet size on the= tested path and enable asymmetrical packet size testing in a controller-re= sponder architecture. I believe that in IPPM WG meeting in Toronto the WG agreed that support of = asymmetrical test packet rate is required and support of asymmetrical packe= t size is recommended. Thus I propose following text update: Key test protocol aspects require the ability to control test packet charac= teristics on the tested path and enable asymmetrical test flow rates in con= troller-responder architecture. * Section 5. Test Protocol Control & Generation Requirements As the IPPM WG agreed that asymmetric test packet flow may be created by va= riation of not just packet size but intra-pair spacing and/or inter-pair in= terval, requirement #4 is not generic but presents only one possible soluti= on. I propose change requirement #4 to change from "asymmetric packet size"= to "asymmetric packet flows in a two-way measurement architecture". The next to the last paragraph suggests: Implementations may support control and generation for only symmetric packe= t sizes when none of the above conditions hold. I believe that this requirement (if it is a requirement, then s/may/MAY/ se= ems in order here) contradicts earlier explanation that mentions variation = of intra-pair spacing and inter-pair interval as possible method to generat= e asymmetric flow of test packets. Thus a protocol that can control spacing= and/or intervals would be suitable to any combination of 1, 3, 4 and 6. Pr= oposed text: Implementations MAY support control and generation of variable inter-pair i= ntervals in each direction with symmetric packet sizes to support performan= ce measurements of asymmetric data flows in two-way architecture. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B8B260Ceusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear All,

please kindly consider following comments as part of= the IETF Last Call:

•       &nb= sp;     Abstract.

Key test protocol aspects= require the ability to control packet size on the tested path and enable a= symmetrical packet size testing in a controller-responder architecture.

I believe that in IPPM WG meeting in Toronto the WG = agreed that support of asymmetrical test packet rate is required and suppor= t of asymmetrical packet size is recommended. Thus I propose following text= update:

Key test protocol aspects= require the ability to control test packet characteristics on the tested p= ath and enable asymmetrical test flow rates in controller-responder archite= cture.

•       &nb= sp;     Section 5. Test Protocol Control & Generati= on Requirements

As the IPPM WG agreed that asymmetric test packet fl= ow may be created by variation of not just packet size but intra-pair spaci= ng and/or inter-pair interval, requirement #4 is not generic but presents o= nly one possible solution. I propose change requirement #4 to change from “asymmetric packet size” = to “asymmetric packet flows in a two-way measurement architectureR= 21;.

The next to the last paragraph suggests:<= /p>

Implementations may suppo= rt control and generation for only symmetric packet sizes when none of the = above conditions hold.

I believe that this requirement (if it is a requirem= ent, then s/may/MAY/ seems in order here) contradicts earlier explanation t= hat mentions variation of intra-pair spacing and inter-pair interval as pos= sible method to generate asymmetric flow of test packets. Thus a protocol that can control spacing and/or inte= rvals would be suitable to any combination of 1, 3, 4 and 6. Proposed text:=

Implementations MAY suppo= rt control and generation of variable inter-pair intervals in each directio= n with symmetric packet sizes to support performance measurements of asymme= tric data flows in two-way architecture.

 

Regards,

    &= nbsp;           Greg=

--_000_7347100B5761DC41A166AC17F22DF1121B8B260Ceusaamb103erics_-- From nobody Sun Dec 14 23:48:42 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9621A1A39; Sun, 14 Dec 2014 23:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwtYTfO-Tvmw; Sun, 14 Dec 2014 23:48:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA801A1A28; Sun, 14 Dec 2014 23:48:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141215074839.28181.32240.idtracker@ietfa.amsl.com> Date: Sun, 14 Dec 2014 23:48:39 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/eL_A2_Lg5oxb4w2r3VRQwgz0_XU Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-mizrahi-ippm-checksum-trailer-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 07:48:40 -0000 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 : UDP Checksum Trailer in OWAMP and TWAMP Author : Tal Mizrahi Filename : draft-mizrahi-ippm-checksum-trailer-02.txt Pages : 11 Date : 2014-12-14 Abstract: The One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) are used for performance monitoring in IP networks. Delay measurement is performed in these protocols by using timestamped test packets. Some implementations use hardware-based timestamping engines that integrate the accurate transmission timestamp into every outgoing OWAMP/TWAMP test packet during transmission. Since these packets are transported over UDP, the UDP checksum field is then updated to reflect this modification. This document proposes to use the last 2 octets of every test packet as a Checksum Trailer, allowing timestamping engines to reflect the checksum modification in the last 2 octets rather than in the UDP checksum field. The behavior defined in this document is completely interoperable with existing OWAMP/TWAMP implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-mizrahi-ippm-checksum-trailer/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-mizrahi-ippm-checksum-trailer-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-mizrahi-ippm-checksum-trailer-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 15 00:08:18 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BB01A1A3A for ; Mon, 15 Dec 2014 00:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lb41vhIz_wfu for ; Mon, 15 Dec 2014 00:08:12 -0800 (PST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C45E1A1A39 for ; Mon, 15 Dec 2014 00:08:11 -0800 (PST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id sBF85HYx006875 for ; Mon, 15 Dec 2014 00:08:09 -0800 Received: from sc-owa03.marvell.com ([199.233.58.149]) by mx0b-0016f401.pphosted.com with ESMTP id 1r8k9y3n4q-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 15 Dec 2014 00:08:09 -0800 Received: from IL-EXCH01.marvell.com (10.4.102.220) by SC-OWA03.marvell.com (10.93.76.24) with Microsoft SMTP Server (TLS) id 8.3.327.1; Mon, 15 Dec 2014 00:08:08 -0800 Received: from IL-EXCH01.marvell.com (10.4.102.220) by IL-EXCH01.marvell.com (10.4.102.220) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 15 Dec 2014 10:07:58 +0200 Received: from IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36]) by IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36%20]) with mapi id 15.00.0913.011; Mon, 15 Dec 2014 10:07:58 +0200 From: Tal Mizrahi To: "ippm@ietf.org" Thread-Topic: [ippm] I-D Action: draft-mizrahi-ippm-checksum-trailer-02.txt Thread-Index: AQHQGDupPlqeXfeYm0+GATWLOfzr7ZyQS+Fw Date: Mon, 15 Dec 2014 08:07:58 +0000 Message-ID: <3afcc99981874f88ab202c8b71f97d18@IL-EXCH01.marvell.com> References: <20141215074839.28181.32240.idtracker@ietfa.amsl.com> In-Reply-To: <20141215074839.28181.32240.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.102.232] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2014-12-15_01:2014-12-13,2014-12-14,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1412150087 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/ktEkowKcQv5IngfkP33Sc0JDdCU Subject: Re: [ippm] I-D Action: draft-mizrahi-ippm-checksum-trailer-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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, 15 Dec 2014 08:08:14 -0000 Hi, A minor update to avoid expiration. Thanks, Tal. -----Original Message----- From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Monday, December 15, 2014 9:49 AM To: i-d-announce@ietf.org Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-mizrahi-ippm-checksum-trailer-02.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 t= he IETF. Title : UDP Checksum Trailer in OWAMP and TWAMP Author : Tal Mizrahi Filename : draft-mizrahi-ippm-checksum-trailer-02.txt Pages : 11 Date : 2014-12-14 Abstract: The One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) are used for performance monitoring in IP networks. Delay measurement is performed in these protocols by using timestamped test packets. Some implementations use hardware-based timestamping engines that integrate the accurate transmission timestamp into every outgoing OWAMP/TWAMP test packet during transmission. Since these packets are transported over UDP, the UDP checksum field is then updated to reflect this modification. This document proposes to use the last 2 octets of every test packet as a Checksum Trailer, allowing timestamping engines to reflect the checksum modification in the last 2 octets rather than in the UDP checksum field. The behavior defined in this document is completely interoperable with existing OWAMP/TWAMP implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-mizrahi-ippm-checksum-trailer/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-mizrahi-ippm-checksum-trailer-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-mizrahi-ippm-checksum-trailer-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From nobody Mon Dec 15 07:27:36 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D931A6FE8; Mon, 15 Dec 2014 07:27:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v23P8UMYP8qW; Mon, 15 Dec 2014 07:27:20 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB8CB1A6FDE; Mon, 15 Dec 2014 07:27:19 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsFAKL8jlSHCzIm/2dsb2JhbABagkMhIlJcsxABAQEBAQEGmDACgRwWAQEBAQEBfIQOAQEDEhtMEgEVFVYmAQQBDQ0aiAoBsnCgYQEBAQEBBQEBAQEBAQEBGoYAiUExgx2BEwWJFYMXgVaOfosoIoNsgjN+AQEB X-IronPort-AV: E=Sophos; i="5.07,580,1413259200"; d="scan'208,217"; a="84702757" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 15 Dec 2014 10:27:16 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 15 Dec 2014 10:27:14 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Mon, 15 Dec 2014 16:27:14 +0100 From: "Romascanu, Dan (Dan)" To: "ops-dir@ietf.org" , "ippm@ietf.org" Thread-Topic: OPS-DIR review of draft-ietf-ippm-rate-problem-08 Thread-Index: AdAYe5l6zzPt7cY0Sz6o+JrRmzElOQ== Date: Mon, 15 Dec 2014 15:27:13 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C93075A@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C93075AAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/1HLz8sVX-pjqYCIdyxlcdiALIDE Cc: "draft-ietf-ippm-rate-problem.all@tools.ietf.org" Subject: [ippm] OPS-DIR review of draft-ietf-ippm-rate-problem-08 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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, 15 Dec 2014 15:27:30 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C93075AAZFFEXMB04globa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the Operational directorate's ongo= ing effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any ot= her last call comments. Ready with one issue This I-D is an informational document that does not define a new protocol o= r protocol extensions. It does however contain a problem statement for test= protocols conducting access rate measurement in productions networks. Thes= e protocols can be OWAMP (RFC 4656) or TWAMP (RFC 5357) but also non-IETF p= rotocols. The following operational considerations in Appendix A.1 of RFC 5= 706 apply, I believe, and do not receive appropriate answers in the documen= t: 5. Has the impact on network operation been discussed? See Section 2.5. * Will the new protocol significantly increase traffic load on existing networks? * Will the proposed management for the new protocol significantly increase traffic load on existing networks? * How will the new protocol impact the behavior of other protocols in the network? Will it impact performance (e.g., jitter) of certain types of applications running in the same network? I believe that at least a reference to these aspects need to be included, e= specially as the In-Service testing with injection of active traffic on pro= duction network is one of the methods discussed by the document. The following reference to the effects of the high level traffic is not suf= ficient IMO: =D8 Section 5 of [RFC2680] lists the problems with high measurement traffic rates, and the most relevant for rate measurement =D8 is the tendency for measurement traffic to skew the results, followed by the possibility of introducing congestion on the access link. In- Service testing MUST respect these traffic constraints. Obviously, categories of rate measurement methods that use less active test traffic than others with similar accuracy are preferred for In- Service testing. Section 5 of RFC2680 does not provide too many details as I was expecting. = It actually deals with traffic injection as with a security concern: =D8 There are two types of security concerns: potential harm caused by =D8 the measurements, and potential harm to the measurements. The =D8 measurements could cause harm because they are active, and inject =D8 packets into the network. The measurement parameters MUST be =D8 carefully selected so that the measurements inject trivial amounts of =D8 additional traffic into the networks they measure. If they inject =D8 "too much" traffic, they can skew the results of the measurement, and =D8 in extreme cases cause congestion and denial of service. =D8 'trivial amounts of additional traffic' is too vague - I believe that more = clear text that deals with the issue as with an operational issue, and make= s clear that degradation of service for users is not acceptable if In-Servi= ce testing policies are applied would be welcome. I hope this helps. Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C93075AAZFFEXMB04globa_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I have reviewed this document as part of the Operational directorate'= s ongoing

effort to review all IETF documents being processed by the IESG. = ; These comments

were written primarily for the benefit of the operational area direct= ors. 

Document editors and WG chairs should treat these comments just like = any other

last call comments.

 

Ready with one issue

 

This I-D is an informational document that does not = define a new protocol or protocol extensions. It does however contain a pro= blem statement for test protocols conducting access rate measurement in pro= ductions networks. These protocols can be OWAMP (RFC 4656) or TWAMP (RFC 5357) but also non-IETF protocols. T= he following operational considerations in Appendix A.1 of RFC 5706 apply, = I believe, and do not receive appropriate answers in the document:

 

5. Has the impact on network operation been discusse= d? See

Section 2.5.

* Will the new protocol significantly increase traff= ic load on

existing networks?

* Will the proposed management for the new protocol<= o:p>

significantly increase traffic load on existing netw= orks?

* How will the new protocol impact the behavior of o= ther

protocols in the network? Will it impact performance= (e.g.,

jitter) of certain types of applications running in = the same

network?

 

I believe that at least a reference to these aspects= need to be included, especially as the In-Service testing with injection o= f active traffic on production network is one of the methods discussed by t= he document.

 

The following reference to the effects of the high l= evel traffic is not sufficient IMO:

 

=D8&= nbsp; Section 5 of [RFC2680] lists the problems = with high
   measurement traffic rates, and the most relevant for rate meas= urement

=D8&= nbsp; is the tendency for measurement traffic to= skew the results, followed
   by the possibility of introducing congestion on the access lin= k.  In-
   Service testing MUST respect these traffic constraints.  = Obviously,
   categories of rate measurement methods that use less active te= st
   traffic than others with similar accuracy are preferred for In= -
   Service testing.

 

Section 5 of RFC2680 does not provide too many detai= ls as I was expecting. It actually deals with traffic injection as with a s= ecurity concern:

 

=D8  There are two types= of security concerns: potential harm caused by

=D8   the measureme= nts, and potential harm to the measurements. The

=D8   measurements = could cause harm because they are active, and inject

=D8   packets into = the network. The measurement parameters MUST be

=D8   carefully sel= ected so that the measurements inject trivial amounts of

=D8   additional tr= affic into the networks they measure. If they inject

=D8   "too muc= h" traffic, they can skew the results of the measurement, and

=D8   in extreme ca= ses cause congestion and denial of service.

=D8

‘trivial amounts of additional traffic’ = is too vague – I believe that more clear text that deals with the iss= ue as with an operational issue, and makes clear that degradation of servic= e for users is not acceptable if In-Service testing policies are applied would be welcome.

 

I hope this helps.

 

Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C93075AAZFFEXMB04globa_-- From nobody Mon Dec 15 09:34:16 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275831A86EF for ; Mon, 15 Dec 2014 09:34:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mstKrna5DHAt for ; Mon, 15 Dec 2014 09:34:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 394E51A8710 for ; Mon, 15 Dec 2014 09:33:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141215173355.18396.9603.idtracker@ietfa.amsl.com> Date: Mon, 15 Dec 2014 09:33:55 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/mDxtDnGRo99MJWIyZf7WWF7Xb9U Subject: [ippm] Milestones changed for ippm WG X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 17:34:12 -0000 URL: http://datatracker.ietf.org/wg/ippm/charter/ From nobody Tue Dec 16 05:18:01 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8081ACD88 for ; Tue, 16 Dec 2014 05:17:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q70EYrsarKQn for ; Tue, 16 Dec 2014 05:17:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 59E1A1ACD8C for ; Tue, 16 Dec 2014 05:17:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141216131752.31104.90219.idtracker@ietfa.amsl.com> Date: Tue, 16 Dec 2014 05:17:52 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/3Bi_sBcK8wlVbPEwVPtVGqymRac Subject: [ippm] Milestones changed for ippm WG X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 13:17:59 -0000 Changed milestone "Submit draft on the UDP Checksum Trailer in OWAMP and TWAMP to the IESG as Informational", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/ippm/charter/ From nobody Tue Dec 16 07:09:04 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4AF1A1B22; Tue, 16 Dec 2014 07:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOEfQio8oR_q; Tue, 16 Dec 2014 07:08:49 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 08D2F1A1B3A; Tue, 16 Dec 2014 07:08:48 -0800 (PST) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id 90738121944; Tue, 16 Dec 2014 10:21:02 -0500 (EST) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.240.40]) by mail-azure.research.att.com (Postfix) with ESMTP id 68602E080D; Tue, 16 Dec 2014 10:08:44 -0500 (EST) Received: from NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea]) by NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea%17]) with mapi; Tue, 16 Dec 2014 10:08:44 -0500 From: "MORTON, ALFRED C (AL)" To: "Romascanu, Dan (Dan)" , "ops-dir@ietf.org" , "ippm@ietf.org" Date: Tue, 16 Dec 2014 10:05:19 -0500 Thread-Topic: OPS-DIR review of draft-ietf-ippm-rate-problem-08 Thread-Index: AdAYe5l6zzPt7cY0Sz6o+JrRmzElOQAxhuiV Message-ID: <4AF73AA205019A4C8A1DDD32C034631D85493901@NJFPSRVEXG0.research.att.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C93075A@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C93075A@AZ-FFEXMB04.global.avaya.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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/Ew1mZ-nc-r-1BYwN_9tmEodQRe8 Cc: "draft-ietf-ippm-rate-problem.all@tools.ietf.org" Subject: Re: [ippm] OPS-DIR review of draft-ietf-ippm-rate-problem-08 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 15:08:56 -0000 Hi Dan, Thanks for your review. Perhaps we can close this quickly before we both disappear for the holidays (officially, I'm already gone and writing from Chicago, where it is unseasonably warm). We can certainly add details on the operational impact that test protocols conforming to this memo's problem statement might cause. This has been a point of issue since the earliest days of IPPM, so we should be able to cover the topic by introducing several references. If there is some additional point we can cover here, keeping in mind that measurement methods are a non-goal of this draft and the operational impact of specific methods are best dealt with when such methods are specified, please provide your thoughts. regards, Al The IPPM Framework RFC 2330, section 11.1, says + The act of measurement can perturb what is being measured (for example, injecting measurement traffic into a network alters the congestion level of the network), and repeated periodic perturbations can drive a network into a state of synchronization (cf. [FJ94]), greatly magnifying what might individually be minor effects. And also, RFC 2330 adopts the term "conservative" for measurement methodologies for which:, "... the act of measurement does not modify, or only slightly modifies, the value of the performance metric the methodology attempts to measure." However, the constraint that measurements strictly retain the=20 conservative property is updated in RFC 7312 https://tools.ietf.org/html/rfc7312#section-4.4 It should be noted that this definition of "conservative" in the sense of [RFC2330] depends to a large extent on the measurement path's technology and characteristics. In particular, when deployed on reactive paths, subpaths, links or hosts conforming to the definition in Section 1.1 of RFC 7312, measurement packets can originate capacity (re)allocations. In addition, small measurement flow variations can result in other users on the same path perceiving significant variations in measurement results. Therefore: It is not always possible for the method to be conservative. And, on modern networks with reactive components, any traffic level will have some impact on other users. Therefore, metrics and their measurement methods should be vetted by the industry SDOs. To make this point clear, we should cite=20 BMWG RFC (2455 considered harmful on production networks),=20 which covers the topic in Section 6 http://tools.ietf.org/html/rfc6815#section-6 and says: ...There are no specific methods proposed for activation of a packet transfer service in IPPM at this time. Thus, individuals who need to conduct capacity tests on production networks should actively participate in standards development to ensure their methods receive appropriate industry review and agreement, in the IETF or in alternate standards development organizations. =20 ________________________________________ From: OPS-DIR [ops-dir-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) = [dromasca@avaya.com] Sent: Monday, December 15, 2014 10:27 AM To: ops-dir@ietf.org; ippm@ietf.org Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org Subject: [OPS-DIR] OPS-DIR review of draft-ietf-ippm-rate-problem-08 I have reviewed this document as part of the Operational directorate's ongo= ing effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any ot= her last call comments. Ready with one issue This I-D is an informational document that does not define a new protocol o= r protocol extensions. It does however contain a problem statement for test= protocols conducting access rate measurement in productions networks. Thes= e protocols can be OWAMP (RFC 4656) or TWAMP (RFC 5357) but also non-IETF p= rotocols. The following operational considerations in Appendix A.1 of RFC 5= 706 apply, I believe, and do not receive appropriate answers in the documen= t: 5. Has the impact on network operation been discussed? See Section 2.5. * Will the new protocol significantly increase traffic load on existing networks? * Will the proposed management for the new protocol significantly increase traffic load on existing networks? * How will the new protocol impact the behavior of other protocols in the network? Will it impact performance (e.g., jitter) of certain types of applications running in the same network? I believe that at least a reference to these aspects need to be included, e= specially as the In-Service testing with injection of active traffic on pro= duction network is one of the methods discussed by the document. The following reference to the effects of the high level traffic is not suf= ficient IMO: =D8 Section 5 of [RFC2680] lists the problems with high measurement traffic rates, and the most relevant for rate measurement =D8 is the tendency for measurement traffic to skew the results, followed by the possibility of introducing congestion on the access link. In- Service testing MUST respect these traffic constraints. Obviously, categories of rate measurement methods that use less active test traffic than others with similar accuracy are preferred for In- Service testing. Section 5 of RFC2680 does not provide too many details as I was expecting. = It actually deals with traffic injection as with a security concern: =D8 There are two types of security concerns: potential harm caused by =D8 the measurements, and potential harm to the measurements. The =D8 measurements could cause harm because they are active, and inject =D8 packets into the network. The measurement parameters MUST be =D8 carefully selected so that the measurements inject trivial amounts of =D8 additional traffic into the networks they measure. If they inject =D8 "too much" traffic, they can skew the results of the measurement, and =D8 in extreme cases cause congestion and denial of service. =D8 =91trivial amounts of additional traffic=92 is too vague =96 I believe that= more clear text that deals with the issue as with an operational issue, an= d makes clear that degradation of service for users is not acceptable if In= -Service testing policies are applied would be welcome. I hope this helps. Regards, Dan From nobody Wed Dec 17 02:25:40 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D101A886B; Wed, 17 Dec 2014 02:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Td4qoFj00vj; Wed, 17 Dec 2014 02:25:32 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DB891A8862; Wed, 17 Dec 2014 02:25:32 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsEFAOFYkVTGmAcV/2dsb2JhbABagmQiUlgEszABAQEBAQEGkjWFcgKBHhYBAQEBAQF8hAwBAQEBAxJnDAQCAQgNBAQBAQsdBzIUCQgBAQQBCQQFCBqICgEMsyegZgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEhgCJQTEHBoMQgRMFiRqEboM+hj2CYYImh3aDOCKDbG8BgUR+AQEB X-IronPort-AV: E=Sophos;i="5.07,593,1413259200"; d="scan'208";a="99502422" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 17 Dec 2014 05:25:30 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 17 Dec 2014 05:25:29 -0500 Received: from AZ-FFEXMB03.global.avaya.com ([fe80::d008:af0c:fa66:47e3]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Wed, 17 Dec 2014 11:25:28 +0100 From: "Romascanu, Dan (Dan)" To: "MORTON, ALFRED C (AL)" , "ops-dir@ietf.org" , "ippm@ietf.org" Thread-Topic: OPS-DIR review of draft-ietf-ippm-rate-problem-08 Thread-Index: AdAYe5l6zzPt7cY0Sz6o+JrRmzElOQAxhuiVACgMtpA= Date: Wed, 17 Dec 2014 10:25:27 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C93A18C@AZ-FFEXMB03.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C93075A@AZ-FFEXMB04.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493901@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D85493901@NJFPSRVEXG0.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/SedzPKnzT0WOPAN44cCrfZKbCB0 Cc: "draft-ietf-ippm-rate-problem.all@tools.ietf.org" Subject: Re: [ippm] OPS-DIR review of draft-ietf-ippm-rate-problem-08 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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, 17 Dec 2014 10:25:38 -0000 Hi Al, I kind of disagree that dealing with the operational implications of applyi= ng active testing should not be mentioned in the problem statement, but onl= y when specific measurement methods are described. The problem statement do= cument explicitly describes active rate management and includes a section o= f requirements for test protocol control and generation. I believe that the= operational aspects of generating traffic in production networks should be= part of the problem statement, and explicitly mentioned, not only in the c= ontext of altering measurement results or security considerations.=20 Regards, Dan > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Tuesday, December 16, 2014 5:05 PM > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 >=20 > Hi Dan, >=20 > Thanks for your review. Perhaps we can close this quickly before we both > disappear for the holidays (officially, I'm already gone and writing from > Chicago, where it is unseasonably warm). >=20 > We can certainly add details on the operational impact that test protocol= s > conforming to this memo's problem statement might cause. This has been a > point of issue since the earliest days of IPPM, so we should be able to c= over > the topic by introducing several references. >=20 > If there is some additional point we can cover here, keeping in mind that > measurement methods are a non-goal of this draft and the operational > impact of specific methods are best dealt with when such methods are > specified, please provide your thoughts. >=20 > regards, > Al >=20 > The IPPM Framework RFC 2330, section 11.1, says >=20 > + The act of measurement can perturb what is being measured (for > example, injecting measurement traffic into a network alters the > congestion level of the network), and repeated periodic > perturbations can drive a network into a state of synchronization > (cf. [FJ94]), greatly magnifying what might individually be minor > effects. >=20 > And also, RFC 2330 adopts the term "conservative" for measurement > methodologies for which:, >=20 > "... the act of measurement does not modify, or only slightly > modifies, the value of the performance metric the methodology > attempts to measure." >=20 > However, the constraint that measurements strictly retain the conservativ= e > property is updated in RFC 7312 > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__tools.ietf.org_html_rfc7312-23section-2D4.4&d=3DAAIF- > g&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd > rphpBsFA&m=3DN8q- > hc4HbRszDQlImZQ_Tenl1mVdgb9ss1bTj9HzKew&s=3DpGbP1qC4qqZh21gJkoiKs > BmrE3lDnv8ulVOvmjOAlY0&e=3D >=20 > It should be noted that this definition of "conservative" in the > sense of [RFC2330] depends to a large extent on the measurement > path's technology and characteristics. In particular, when deployed > on reactive paths, subpaths, links or hosts conforming to the > definition in Section 1.1 of RFC 7312, measurement packets can > originate capacity (re)allocations. In addition, small measurement > flow variations can result in other users on the same path perceiving > significant variations in measurement results. Therefore: >=20 > It is not always possible for the method to be conservative. >=20 > And, on modern networks with reactive components, any traffic level will > have some impact on other users. Therefore, metrics and their > measurement methods should be vetted by the industry SDOs. To make this > point clear, we should cite BMWG RFC (2455 considered harmful on > production networks), which covers the topic in Section 6 > https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > 3A__tools.ietf.org_html_rfc6815-23section-2D6&d=3DAAIF- > g&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd > rphpBsFA&m=3DN8q- > hc4HbRszDQlImZQ_Tenl1mVdgb9ss1bTj9HzKew&s=3D5fEqW5JnBgSuJYNRNSJS > mwfu04Mp6cQTBkG_aQNT6qU&e=3D > and says: >=20 > ...There are no specific methods proposed for > activation of a packet transfer service in IPPM at this time. Thus, > individuals who need to conduct capacity tests on production networks > should actively participate in standards development to ensure their > methods receive appropriate industry review and agreement, in the > IETF or in alternate standards development organizations. >=20 >=20 >=20 > ________________________________________ > From: OPS-DIR [ops-dir-bounces@ietf.org] On Behalf Of Romascanu, Dan > (Dan) [dromasca@avaya.com] > Sent: Monday, December 15, 2014 10:27 AM > To: ops-dir@ietf.org; ippm@ietf.org > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > Subject: [OPS-DIR] OPS-DIR review of draft-ietf-ippm-rate-problem-08 >=20 > I have reviewed this document as part of the Operational directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the operational > area directors. > Document editors and WG chairs should treat these comments just like any > other last call comments. >=20 > Ready with one issue >=20 > This I-D is an informational document that does not define a new protocol= or > protocol extensions. It does however contain a problem statement for test > protocols conducting access rate measurement in productions networks. > These protocols can be OWAMP (RFC 4656) or TWAMP (RFC 5357) but also > non-IETF protocols. The following operational considerations in Appendix = A.1 > of RFC 5706 apply, I believe, and do not receive appropriate answers in t= he > document: >=20 > 5. Has the impact on network operation been discussed? See Section 2.5. > * Will the new protocol significantly increase traffic load on existing > networks? > * Will the proposed management for the new protocol significantly increas= e > traffic load on existing networks? > * How will the new protocol impact the behavior of other protocols in the > network? Will it impact performance (e.g., > jitter) of certain types of applications running in the same network? >=20 > I believe that at least a reference to these aspects need to be included, > especially as the In-Service testing with injection of active traffic on > production network is one of the methods discussed by the document. >=20 > The following reference to the effects of the high level traffic is not s= ufficient > IMO: >=20 >=20 > =D8 Section 5 of [RFC2680] lists the problems with high > measurement traffic rates, and the most relevant for rate measurement >=20 > =D8 is the tendency for measurement traffic to skew the results, followe= d > by the possibility of introducing congestion on the access link. In- > Service testing MUST respect these traffic constraints. Obviously, > categories of rate measurement methods that use less active test > traffic than others with similar accuracy are preferred for In- > Service testing. >=20 > Section 5 of RFC2680 does not provide too many details as I was expecting= . It > actually deals with traffic injection as with a security concern: >=20 >=20 > =D8 There are two types of security concerns: potential harm caused by >=20 > =D8 the measurements, and potential harm to the measurements. The >=20 > =D8 measurements could cause harm because they are active, and inject >=20 > =D8 packets into the network. The measurement parameters MUST be >=20 > =D8 carefully selected so that the measurements inject trivial amounts = of >=20 > =D8 additional traffic into the networks they measure. If they inject >=20 > =D8 "too much" traffic, they can skew the results of the measurement, a= nd >=20 > =D8 in extreme cases cause congestion and denial of service. >=20 > =D8 > 'trivial amounts of additional traffic' is too vague - I believe that mor= e clear > text that deals with the issue as with an operational issue, and makes cl= ear > that degradation of service for users is not acceptable if In-Service tes= ting > policies are applied would be welcome. >=20 > I hope this helps. >=20 > Regards, >=20 > Dan From nobody Wed Dec 17 05:38:59 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 332461A897C; Wed, 17 Dec 2014 05:38:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUhXq5vskUtY; Wed, 17 Dec 2014 05:38:47 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id C01E31A1ACE; Wed, 17 Dec 2014 05:38:46 -0800 (PST) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 4D53D121D27; Wed, 17 Dec 2014 08:51:04 -0500 (EST) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.240.40]) by mail-blue.research.att.com (Postfix) with ESMTP id 56460F0451; Wed, 17 Dec 2014 08:38:46 -0500 (EST) Received: from NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea]) by NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea%17]) with mapi; Wed, 17 Dec 2014 08:38:46 -0500 From: "MORTON, ALFRED C (AL)" To: "Romascanu, Dan (Dan)" , "ops-dir@ietf.org" , "ippm@ietf.org" Date: Wed, 17 Dec 2014 08:38:45 -0500 Thread-Topic: OPS-DIR review of draft-ietf-ippm-rate-problem-08 Thread-Index: AdAYe5l6zzPt7cY0Sz6o+JrRmzElOQAxhuiVACgMtpAABsHwBw== Message-ID: <4AF73AA205019A4C8A1DDD32C034631D85493905@NJFPSRVEXG0.research.att.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C93075A@AZ-FFEXMB04.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493901@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93A18C@AZ-FFEXMB03.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C93A18C@AZ-FFEXMB03.global.avaya.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/Dytns_WbAZEHClNgn8TNblgToKs Cc: "draft-ietf-ippm-rate-problem.all@tools.ietf.org" Subject: Re: [ippm] OPS-DIR review of draft-ietf-ippm-rate-problem-08 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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, 17 Dec 2014 13:38:52 -0000 Hi Dan, I did not say that the operational implications would not be dealt with her= e. I'm simply saying that IPPM drafts have done as you have asked many times a= lready, that is discuss the implications of active measurements, and that we would = not repeat that guidance (but include four references below). Also, that the m= easurement methods would each be vetted on their own, when proposed for standardizatio= n. You need both methods and control/test protocol, and the method solutions=20 for this problem are out of scope. For example, the model-based metrics draft in IPPM introduces the notion of= a target rate, which is a good thing, because it means that the test stream will have an u= pper bound. But that is an operational evaluation of a specific method, and OOS for the= problem=20 statement. Is this approach more clear? If not, please suggest some text. regards, Al ________________________________________ From: Romascanu, Dan (Dan) [dromasca@avaya.com] Sent: Wednesday, December 17, 2014 5:25 AM To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 Hi Al, I kind of disagree that dealing with the operational implications of applyi= ng active testing should not be mentioned in the problem statement, but onl= y when specific measurement methods are described. The problem statement do= cument explicitly describes active rate management and includes a section o= f requirements for test protocol control and generation. I believe that the= operational aspects of generating traffic in production networks should be= part of the problem statement, and explicitly mentioned, not only in the c= ontext of altering measurement results or security considerations. Regards, Dan > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Tuesday, December 16, 2014 5:05 PM > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > Hi Dan, > > Thanks for your review. Perhaps we can close this quickly before we both > disappear for the holidays (officially, I'm already gone and writing from > Chicago, where it is unseasonably warm). > > We can certainly add details on the operational impact that test protocol= s > conforming to this memo's problem statement might cause. This has been a > point of issue since the earliest days of IPPM, so we should be able to c= over > the topic by introducing several references. > > If there is some additional point we can cover here, keeping in mind that > measurement methods are a non-goal of this draft and the operational > impact of specific methods are best dealt with when such methods are > specified, please provide your thoughts. > > regards, > Al > > The IPPM Framework RFC 2330, section 11.1, says > > + The act of measurement can perturb what is being measured (for > example, injecting measurement traffic into a network alters the > congestion level of the network), and repeated periodic > perturbations can drive a network into a state of synchronization > (cf. [FJ94]), greatly magnifying what might individually be minor > effects. > > And also, RFC 2330 adopts the term "conservative" for measurement > methodologies for which:, > > "... the act of measurement does not modify, or only slightly > modifies, the value of the performance metric the methodology > attempts to measure." > > However, the constraint that measurements strictly retain the conservativ= e > property is updated in RFC 7312 > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__tools.ietf.org_html_rfc7312-23section-2D4.4&d=3DAAIF- > g&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd > rphpBsFA&m=3DN8q- > hc4HbRszDQlImZQ_Tenl1mVdgb9ss1bTj9HzKew&s=3DpGbP1qC4qqZh21gJkoiKs > BmrE3lDnv8ulVOvmjOAlY0&e=3D > > It should be noted that this definition of "conservative" in the > sense of [RFC2330] depends to a large extent on the measurement > path's technology and characteristics. In particular, when deployed > on reactive paths, subpaths, links or hosts conforming to the > definition in Section 1.1 of RFC 7312, measurement packets can > originate capacity (re)allocations. In addition, small measurement > flow variations can result in other users on the same path perceiving > significant variations in measurement results. Therefore: > > It is not always possible for the method to be conservative. > > And, on modern networks with reactive components, any traffic level will > have some impact on other users. Therefore, metrics and their > measurement methods should be vetted by the industry SDOs. To make this > point clear, we should cite BMWG RFC (2455 considered harmful on > production networks), which covers the topic in Section 6 > https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > 3A__tools.ietf.org_html_rfc6815-23section-2D6&d=3DAAIF- > g&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd > rphpBsFA&m=3DN8q- > hc4HbRszDQlImZQ_Tenl1mVdgb9ss1bTj9HzKew&s=3D5fEqW5JnBgSuJYNRNSJS > mwfu04Mp6cQTBkG_aQNT6qU&e=3D > and says: > > ...There are no specific methods proposed for > activation of a packet transfer service in IPPM at this time. Thus, > individuals who need to conduct capacity tests on production networks > should actively participate in standards development to ensure their > methods receive appropriate industry review and agreement, in the > IETF or in alternate standards development organizations. > > > > ________________________________________ > From: OPS-DIR [ops-dir-bounces@ietf.org] On Behalf Of Romascanu, Dan > (Dan) [dromasca@avaya.com] > Sent: Monday, December 15, 2014 10:27 AM > To: ops-dir@ietf.org; ippm@ietf.org > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > Subject: [OPS-DIR] OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > I have reviewed this document as part of the Operational directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the operational > area directors. > Document editors and WG chairs should treat these comments just like any > other last call comments. > > Ready with one issue > > This I-D is an informational document that does not define a new protocol= or > protocol extensions. It does however contain a problem statement for test > protocols conducting access rate measurement in productions networks. > These protocols can be OWAMP (RFC 4656) or TWAMP (RFC 5357) but also > non-IETF protocols. The following operational considerations in Appendix = A.1 > of RFC 5706 apply, I believe, and do not receive appropriate answers in t= he > document: > > 5. Has the impact on network operation been discussed? See Section 2.5. > * Will the new protocol significantly increase traffic load on existing > networks? > * Will the proposed management for the new protocol significantly increas= e > traffic load on existing networks? > * How will the new protocol impact the behavior of other protocols in the > network? Will it impact performance (e.g., > jitter) of certain types of applications running in the same network? > > I believe that at least a reference to these aspects need to be included, > especially as the In-Service testing with injection of active traffic on > production network is one of the methods discussed by the document. > > The following reference to the effects of the high level traffic is not s= ufficient > IMO: > > > =D8 Section 5 of [RFC2680] lists the problems with high > measurement traffic rates, and the most relevant for rate measurement > > =D8 is the tendency for measurement traffic to skew the results, followe= d > by the possibility of introducing congestion on the access link. In- > Service testing MUST respect these traffic constraints. Obviously, > categories of rate measurement methods that use less active test > traffic than others with similar accuracy are preferred for In- > Service testing. > > Section 5 of RFC2680 does not provide too many details as I was expecting= . It > actually deals with traffic injection as with a security concern: > > > =D8 There are two types of security concerns: potential harm caused by > > =D8 the measurements, and potential harm to the measurements. The > > =D8 measurements could cause harm because they are active, and inject > > =D8 packets into the network. The measurement parameters MUST be > > =D8 carefully selected so that the measurements inject trivial amounts = of > > =D8 additional traffic into the networks they measure. If they inject > > =D8 "too much" traffic, they can skew the results of the measurement, a= nd > > =D8 in extreme cases cause congestion and denial of service. > > =D8 > 'trivial amounts of additional traffic' is too vague - I believe that mor= e clear > text that deals with the issue as with an operational issue, and makes cl= ear > that degradation of service for users is not acceptable if In-Service tes= ting > policies are applied would be welcome. > > I hope this helps. > > Regards, > > Dan From nobody Wed Dec 17 06:34:17 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9009F1A8547; Wed, 17 Dec 2014 06:34:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ML9UH8GMP7US; Wed, 17 Dec 2014 06:34:07 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 561C31A8A89; Wed, 17 Dec 2014 06:34:07 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsEFAHeTkVTGmAcV/2dsb2JhbABagmQiUlgEszMBAQEBAQEGkjWFcgKBHxYBAQEBAQF8hAwBAQEBAxJnDAQCAQgNBAQBAQsdBzIUCQgBAQQBCQQFCBMHiAoBDLNqoG4BAQEBAQEBAQEBAQEBAQEBAQEBAQETBIYAiUExBwaDEIETBYkahG6DPoY9gmGCJod2gzgig2xvAYFEfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,594,1413259200"; d="scan'208";a="99532958" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 17 Dec 2014 09:34:05 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 17 Dec 2014 09:34:04 -0500 Received: from AZ-FFEXMB03.global.avaya.com ([fe80::d008:af0c:fa66:47e3]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Wed, 17 Dec 2014 15:34:02 +0100 From: "Romascanu, Dan (Dan)" To: "MORTON, ALFRED C (AL)" , "ops-dir@ietf.org" , "ippm@ietf.org" Thread-Topic: OPS-DIR review of draft-ietf-ippm-rate-problem-08 Thread-Index: AdAYe5l6zzPt7cY0Sz6o+JrRmzElOQAxhuiVACgMtpAABsHwBwACB4rA Date: Wed, 17 Dec 2014 14:34:02 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C93B6D0@AZ-FFEXMB03.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C93075A@AZ-FFEXMB04.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493901@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93A18C@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493905@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D85493905@NJFPSRVEXG0.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/wJS9id82PnZGqzNipQUX0fjomKY Cc: "draft-ietf-ippm-rate-problem.all@tools.ietf.org" Subject: Re: [ippm] OPS-DIR review of draft-ietf-ippm-rate-problem-08 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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, 17 Dec 2014 14:34:13 -0000 Suggested edit:=20 Insert section 7 after the Security considerations section with the followi= ng text, and renumber the other sections accordingly:=20 7. Operational Considerations The increase in traffic levels caused by applying any active measurement of= live networks is a concern and needs to be considered and controlled any t= ime active measurements are applied. It is RECOMMENDED that the increase lo= ad in the traffic levels in the live networks caused by the active measurem= ent protocols and by the management of the active measurement protocols doe= s not lead to a degradation of the quality of service of the applications r= unning in the networks or the quality of experience of the users of the app= lications.=20 Regards, Dan =20 > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Wednesday, December 17, 2014 3:39 PM > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 >=20 > Hi Dan, >=20 > I did not say that the operational implications would not be dealt with h= ere. >=20 > I'm simply saying that IPPM drafts have done as you have asked many times > already, that is discuss the implications of active measurements, and tha= t we > would not repeat that guidance (but include four references below). Also= , > that the measurement methods would each be vetted on their own, when > proposed for standardization. > You need both methods and control/test protocol, and the method solutions > for this problem are out of scope. >=20 > For example, the model-based metrics draft in IPPM introduces the notion = of > a target rate, which is a good thing, because it means that the test stre= am will > have an upper bound. > But that is an operational evaluation of a specific method, and OOS for t= he > problem statement. >=20 > Is this approach more clear? If not, please suggest some text. >=20 > regards, > Al > ________________________________________ > From: Romascanu, Dan (Dan) [dromasca@avaya.com] > Sent: Wednesday, December 17, 2014 5:25 AM > To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 >=20 > Hi Al, >=20 > I kind of disagree that dealing with the operational implications of appl= ying > active testing should not be mentioned in the problem statement, but only > when specific measurement methods are described. The problem statement > document explicitly describes active rate management and includes a secti= on > of requirements for test protocol control and generation. I believe that = the > operational aspects of generating traffic in production networks should b= e > part of the problem statement, and explicitly mentioned, not only in the > context of altering measurement results or security considerations. >=20 > Regards, >=20 > Dan >=20 >=20 > > -----Original Message----- > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > Sent: Tuesday, December 16, 2014 5:05 PM > > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > Hi Dan, > > > > Thanks for your review. Perhaps we can close this quickly before we > > both disappear for the holidays (officially, I'm already gone and > > writing from Chicago, where it is unseasonably warm). > > > > We can certainly add details on the operational impact that test > > protocols conforming to this memo's problem statement might cause. > > This has been a point of issue since the earliest days of IPPM, so we > > should be able to cover the topic by introducing several references. > > > > If there is some additional point we can cover here, keeping in mind > > that measurement methods are a non-goal of this draft and the > > operational impact of specific methods are best dealt with when such > > methods are specified, please provide your thoughts. > > > > regards, > > Al > > > > The IPPM Framework RFC 2330, section 11.1, says > > > > + The act of measurement can perturb what is being measured (for > > example, injecting measurement traffic into a network alters the > > congestion level of the network), and repeated periodic > > perturbations can drive a network into a state of synchronization > > (cf. [FJ94]), greatly magnifying what might individually be minor > > effects. > > > > And also, RFC 2330 adopts the term "conservative" for measurement > > methodologies for which:, > > > > "... the act of measurement does not modify, or only slightly > > modifies, the value of the performance metric the methodology > > attempts to measure." > > > > However, the constraint that measurements strictly retain the > > conservative property is updated in RFC 7312 > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > 3A__tools.ietf.org_html_rfc7312-23section-2D4.4&d=3DAAIF- > > > g&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd > > rphpBsFA&m=3DN8q- > > > hc4HbRszDQlImZQ_Tenl1mVdgb9ss1bTj9HzKew&s=3DpGbP1qC4qqZh21gJkoiKs > > BmrE3lDnv8ulVOvmjOAlY0&e=3D > > > > It should be noted that this definition of "conservative" in the > > sense of [RFC2330] depends to a large extent on the measurement > > path's technology and characteristics. In particular, when deployed > > on reactive paths, subpaths, links or hosts conforming to the > > definition in Section 1.1 of RFC 7312, measurement packets can > > originate capacity (re)allocations. In addition, small measurement > > flow variations can result in other users on the same path perceivin= g > > significant variations in measurement results. Therefore: > > > > It is not always possible for the method to be conservative. > > > > And, on modern networks with reactive components, any traffic level > > will have some impact on other users. Therefore, metrics and their > > measurement methods should be vetted by the industry SDOs. To make > > this point clear, we should cite BMWG RFC (2455 considered harmful on > > production networks), which covers the topic in Section 6 > > https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > > 3A__tools.ietf.org_html_rfc6815-23section-2D6&d=3DAAIF- > > > g&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd > > rphpBsFA&m=3DN8q- > > > hc4HbRszDQlImZQ_Tenl1mVdgb9ss1bTj9HzKew&s=3D5fEqW5JnBgSuJYNRNSJS > > mwfu04Mp6cQTBkG_aQNT6qU&e=3D > > and says: > > > > ...There are no specific methods proposed for > > activation of a packet transfer service in IPPM at this time. Thus, > > individuals who need to conduct capacity tests on production network= s > > should actively participate in standards development to ensure their > > methods receive appropriate industry review and agreement, in the > > IETF or in alternate standards development organizations. > > > > > > > > ________________________________________ > > From: OPS-DIR [ops-dir-bounces@ietf.org] On Behalf Of Romascanu, Dan > > (Dan) [dromasca@avaya.com] > > Sent: Monday, December 15, 2014 10:27 AM > > To: ops-dir@ietf.org; ippm@ietf.org > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > Subject: [OPS-DIR] OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > I have reviewed this document as part of the Operational directorate's > > ongoing effort to review all IETF documents being processed by the IESG= . > > These comments were written primarily for the benefit of the > > operational area directors. > > Document editors and WG chairs should treat these comments just like > > any other last call comments. > > > > Ready with one issue > > > > This I-D is an informational document that does not define a new > > protocol or protocol extensions. It does however contain a problem > > statement for test protocols conducting access rate measurement in > productions networks. > > These protocols can be OWAMP (RFC 4656) or TWAMP (RFC 5357) but also > > non-IETF protocols. The following operational considerations in > > Appendix A.1 of RFC 5706 apply, I believe, and do not receive > > appropriate answers in the > > document: > > > > 5. Has the impact on network operation been discussed? See Section 2.5. > > * Will the new protocol significantly increase traffic load on > > existing networks? > > * Will the proposed management for the new protocol significantly > > increase traffic load on existing networks? > > * How will the new protocol impact the behavior of other protocols in > > the network? Will it impact performance (e.g., > > jitter) of certain types of applications running in the same network? > > > > I believe that at least a reference to these aspects need to be > > included, especially as the In-Service testing with injection of > > active traffic on production network is one of the methods discussed by > the document. > > > > The following reference to the effects of the high level traffic is > > not sufficient > > IMO: > > > > > > =D8 Section 5 of [RFC2680] lists the problems with high > > measurement traffic rates, and the most relevant for rate > > measurement > > > > =D8 is the tendency for measurement traffic to skew the results, follo= wed > > by the possibility of introducing congestion on the access link. In= - > > Service testing MUST respect these traffic constraints. Obviously, > > categories of rate measurement methods that use less active test > > traffic than others with similar accuracy are preferred for In- > > Service testing. > > > > Section 5 of RFC2680 does not provide too many details as I was > > expecting. It actually deals with traffic injection as with a security = concern: > > > > > > =D8 There are two types of security concerns: potential harm caused by > > > > =D8 the measurements, and potential harm to the measurements. The > > > > =D8 measurements could cause harm because they are active, and inject > > > > =D8 packets into the network. The measurement parameters MUST be > > > > =D8 carefully selected so that the measurements inject trivial amount= s of > > > > =D8 additional traffic into the networks they measure. If they inject > > > > =D8 "too much" traffic, they can skew the results of the measurement,= and > > > > =D8 in extreme cases cause congestion and denial of service. > > > > =D8 > > 'trivial amounts of additional traffic' is too vague - I believe that > > more clear text that deals with the issue as with an operational > > issue, and makes clear that degradation of service for users is not > > acceptable if In-Service testing policies are applied would be welcome. > > > > I hope this helps. > > > > Regards, > > > > Dan From nobody Wed Dec 17 10:51:01 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E15D1A7016; Wed, 17 Dec 2014 10:50:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9i04T36t0CO; Wed, 17 Dec 2014 10:50:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F36481A1B9B; Wed, 17 Dec 2014 10:50:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141217185055.13818.74363.idtracker@ietfa.amsl.com> Date: Wed, 17 Dec 2014 10:50:55 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/VA8ZvzTyVpFFFUqvS8XKKp7eCxk Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-checksum-trailer-00.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 18:50:58 -0000 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 : UDP Checksum Trailer in OWAMP and TWAMP Author : Tal Mizrahi Filename : draft-ietf-ippm-checksum-trailer-00.txt Pages : 11 Date : 2014-12-17 Abstract: The One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) are used for performance monitoring in IP networks. Delay measurement is performed in these protocols by using timestamped test packets. Some implementations use hardware-based timestamping engines that integrate the accurate transmission timestamp into every outgoing OWAMP/TWAMP test packet during transmission. Since these packets are transported over UDP, the UDP checksum field is then updated to reflect this modification. This document proposes to use the last 2 octets of every test packet as a Checksum Trailer, allowing timestamping engines to reflect the checksum modification in the last 2 octets rather than in the UDP checksum field. The behavior defined in this document is completely interoperable with existing OWAMP/TWAMP implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-checksum-trailer/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ippm-checksum-trailer-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 18 05:07:48 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3EC41A8895; Thu, 18 Dec 2014 05:07:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ot99RJaQJ0DW; Thu, 18 Dec 2014 05:07:43 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id CC7AA1A8893; Thu, 18 Dec 2014 05:07:42 -0800 (PST) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 350DC1223F6; Thu, 18 Dec 2014 08:20:03 -0500 (EST) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.240.40]) by mail-blue.research.att.com (Postfix) with ESMTP id 502B3F0449; Thu, 18 Dec 2014 08:07:42 -0500 (EST) Received: from NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea]) by NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea%17]) with mapi; Thu, 18 Dec 2014 08:07:42 -0500 From: "MORTON, ALFRED C (AL)" To: "Romascanu, Dan (Dan)" , "ops-dir@ietf.org" , "ippm@ietf.org" Date: Thu, 18 Dec 2014 08:05:31 -0500 Thread-Topic: OPS-DIR review of draft-ietf-ippm-rate-problem-08 Thread-Index: AdAYe5l6zzPt7cY0Sz6o+JrRmzElOQAxhuiVACgMtpAABsHwBwACB4rAAC+P7po= Message-ID: <4AF73AA205019A4C8A1DDD32C034631D85493907@NJFPSRVEXG0.research.att.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C93075A@AZ-FFEXMB04.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493901@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93A18C@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493905@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93B6D0@AZ-FFEXMB03.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C93B6D0@AZ-FFEXMB03.global.avaya.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/ewwGuLAI0cxjPO909_VEOXu-EXc Cc: "draft-ietf-ippm-rate-problem.all@tools.ietf.org" Subject: Re: [ippm] OPS-DIR review of draft-ietf-ippm-rate-problem-08 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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, 18 Dec 2014 13:07:47 -0000 Hi Dan, I now see better where the disconnect is. You are looking for new explicit statements about operational impact. But you are assuming that the active measurement traffic is *excess* traffic, beyond some normal level resulting from all Subscriber traffic and an operator-chosen level of net management traffic. However, management traffic includes performance measurement traffic (when the traffic is originated by the operator), and Subscriber traffic includes active measurement traffic (when originated by the users). Test-related traffic needs to be engineered and limited along with all other traffic. Also, the requirement you wrote "does not lead to degradation" doesn't seem attainable, so we need to provide cautions through other means. Sending a single packet results in larger queue occupations all along its path =3D degradation. The packet could be for routing or other network management. The active measurement traffic is often launched by subscribers or their authorized users, and there may well be some degree of degradation to other subscriber's streams. Your proposed text recommends against this, yet it is no different from the degradation caused by a user who chooses to watch a video instead of testing (except that the video session may be longer). Further, Service providers may be temporarily replacing an idle user's traffic with active test traffic. Again there may be some degradation to other subscribers, but it would typically be no worse than from an additional user using their service. There is also the question of test frequency and overall performance: a user may experience instantaneous packet delay or loss while another subscriber tests their performance, but then the performance is at nominal levels for long periods between tests and the overall performance for a multi-hour session would be satisfactory. It is clear to me that the operational issues primarily addressed in previous IPPM work include the affects on other traffic, the accuracy of the measurements (including preferential treatment or spoofing of measured streams), and the real or perceived existence of DoS attacks. Although these are not identified as operations issues, they are certainly relevant in network operations where measurement has become a growing part of the management portfolio. So, we should continue to cite the existing IPPM (and BMWG) guidance on topics such as conservative measurement, and insert the references I provided earlier into Section 3 (where you cited the reference from RFC2680 - note the reference was to the sentence on high traffic rates, ("too much traffic") so the phrase "trivial amounts of additional traffic" may be an inadequate specification, but it was not the intended reference material. This is the new section I propose: 7. Operational Considerations All forms of testing originate traffic on the network, through their communications for control and results collection, or from dedicated measurement packet streams, or both. Testing traffic primarily falls in one of two categories, subscriber traffic or network management traffic. There is an on-going need to engineer networks so that various forms of traffic are adequately served, and publication of this memo does not change this need. Service subscribers and authorized users SHOULD obtain their network operator's or service provider's permission before conducting tests. Likewise, a service provider or third party SHOULD obtain the subscriber's permission to conduct tests, since they might temporarily reduce service quality. See section 4.1 of [RFC 3148]. Subscribers, their service providers and network operators, and sometimes third parties, all seek to measure network performance. Capacity testing with active traffic often affects the packet transfer performance of streams traversing shared components of the test path, to some degree. The degradation can be minimized by scheduling such tests infrequently, and restricting the amount of measurement traffic required to assess capacity metrics. As a result, occasional short-duration estimates are preferred to measurements based on frequent file transfers of many Megabytes. New measurement methodologies intended for standardization should be evaluated individually for potential operational issues. However, the scheduled frequency of testing is as important as the methods used (and schedules are not typically submitted for standardization). ________________________________________ From: Romascanu, Dan (Dan) [dromasca@avaya.com] Sent: Wednesday, December 17, 2014 9:34 AM To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 Suggested edit: Insert section 7 after the Security considerations section with the followi= ng text, and renumber the other sections accordingly: 7. Operational Considerations The increase in traffic levels caused by applying any active measurement of= live networks is a concern and needs to be considered and controlled any t= ime active measurements are applied. It is RECOMMENDED that the increase lo= ad in the traffic levels in the live networks caused by the active measurem= ent protocols and by the management of the active measurement protocols doe= s not lead to a degradation of the quality of service of the applications r= unning in the networks or the quality of experience of the users of the app= lications. Regards, Dan > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Wednesday, December 17, 2014 3:39 PM > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > Hi Dan, > > I did not say that the operational implications would not be dealt with h= ere. > > I'm simply saying that IPPM drafts have done as you have asked many times > already, that is discuss the implications of active measurements, and tha= t we > would not repeat that guidance (but include four references below). Also= , > that the measurement methods would each be vetted on their own, when > proposed for standardization. > You need both methods and control/test protocol, and the method solutions > for this problem are out of scope. > > For example, the model-based metrics draft in IPPM introduces the notion = of > a target rate, which is a good thing, because it means that the test stre= am will > have an upper bound. > But that is an operational evaluation of a specific method, and OOS for t= he > problem statement. > > Is this approach more clear? If not, please suggest some text. > > regards, > Al > ________________________________________ > From: Romascanu, Dan (Dan) [dromasca@avaya.com] > Sent: Wednesday, December 17, 2014 5:25 AM > To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > Hi Al, > > I kind of disagree that dealing with the operational implications of appl= ying > active testing should not be mentioned in the problem statement, but only > when specific measurement methods are described. The problem statement > document explicitly describes active rate management and includes a secti= on > of requirements for test protocol control and generation. I believe that = the > operational aspects of generating traffic in production networks should b= e > part of the problem statement, and explicitly mentioned, not only in the > context of altering measurement results or security considerations. > > Regards, > > Dan > > > > -----Original Message----- > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > Sent: Tuesday, December 16, 2014 5:05 PM > > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > Hi Dan, > > > > Thanks for your review. Perhaps we can close this quickly before we > > both disappear for the holidays (officially, I'm already gone and > > writing from Chicago, where it is unseasonably warm). > > > > We can certainly add details on the operational impact that test > > protocols conforming to this memo's problem statement might cause. > > This has been a point of issue since the earliest days of IPPM, so we > > should be able to cover the topic by introducing several references. > > > > If there is some additional point we can cover here, keeping in mind > > that measurement methods are a non-goal of this draft and the > > operational impact of specific methods are best dealt with when such > > methods are specified, please provide your thoughts. > > > > regards, > > Al > > > > The IPPM Framework RFC 2330, section 11.1, says > > > > + The act of measurement can perturb what is being measured (for > > example, injecting measurement traffic into a network alters the > > congestion level of the network), and repeated periodic > > perturbations can drive a network into a state of synchronization > > (cf. [FJ94]), greatly magnifying what might individually be minor > > effects. > > > > And also, RFC 2330 adopts the term "conservative" for measurement > > methodologies for which:, > > > > "... the act of measurement does not modify, or only slightly > > modifies, the value of the performance metric the methodology > > attempts to measure." > > > > However, the constraint that measurements strictly retain the > > conservative property is updated in RFC 7312 > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > 3A__tools.ietf.org_html_rfc7312-23section-2D4.4&d=3DAAIF- > > > g&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd > > rphpBsFA&m=3DN8q- > > > hc4HbRszDQlImZQ_Tenl1mVdgb9ss1bTj9HzKew&s=3DpGbP1qC4qqZh21gJkoiKs > > BmrE3lDnv8ulVOvmjOAlY0&e=3D > > > > It should be noted that this definition of "conservative" in the > > sense of [RFC2330] depends to a large extent on the measurement > > path's technology and characteristics. In particular, when deployed > > on reactive paths, subpaths, links or hosts conforming to the > > definition in Section 1.1 of RFC 7312, measurement packets can > > originate capacity (re)allocations. In addition, small measurement > > flow variations can result in other users on the same path perceivin= g > > significant variations in measurement results. Therefore: > > > > It is not always possible for the method to be conservative. > > > > And, on modern networks with reactive components, any traffic level > > will have some impact on other users. Therefore, metrics and their > > measurement methods should be vetted by the industry SDOs. To make > > this point clear, we should cite BMWG RFC (2455 considered harmful on > > production networks), which covers the topic in Section 6 > > https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > > 3A__tools.ietf.org_html_rfc6815-23section-2D6&d=3DAAIF- > > > g&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd > > rphpBsFA&m=3DN8q- > > > hc4HbRszDQlImZQ_Tenl1mVdgb9ss1bTj9HzKew&s=3D5fEqW5JnBgSuJYNRNSJS > > mwfu04Mp6cQTBkG_aQNT6qU&e=3D > > and says: > > > > ...There are no specific methods proposed for > > activation of a packet transfer service in IPPM at this time. Thus, > > individuals who need to conduct capacity tests on production network= s > > should actively participate in standards development to ensure their > > methods receive appropriate industry review and agreement, in the > > IETF or in alternate standards development organizations. > > > > > > > > ________________________________________ > > From: OPS-DIR [ops-dir-bounces@ietf.org] On Behalf Of Romascanu, Dan > > (Dan) [dromasca@avaya.com] > > Sent: Monday, December 15, 2014 10:27 AM > > To: ops-dir@ietf.org; ippm@ietf.org > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > Subject: [OPS-DIR] OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > I have reviewed this document as part of the Operational directorate's > > ongoing effort to review all IETF documents being processed by the IESG= . > > These comments were written primarily for the benefit of the > > operational area directors. > > Document editors and WG chairs should treat these comments just like > > any other last call comments. > > > > Ready with one issue > > > > This I-D is an informational document that does not define a new > > protocol or protocol extensions. It does however contain a problem > > statement for test protocols conducting access rate measurement in > productions networks. > > These protocols can be OWAMP (RFC 4656) or TWAMP (RFC 5357) but also > > non-IETF protocols. The following operational considerations in > > Appendix A.1 of RFC 5706 apply, I believe, and do not receive > > appropriate answers in the > > document: > > > > 5. Has the impact on network operation been discussed? See Section 2.5. > > * Will the new protocol significantly increase traffic load on > > existing networks? > > * Will the proposed management for the new protocol significantly > > increase traffic load on existing networks? > > * How will the new protocol impact the behavior of other protocols in > > the network? Will it impact performance (e.g., > > jitter) of certain types of applications running in the same network? > > > > I believe that at least a reference to these aspects need to be > > included, especially as the In-Service testing with injection of > > active traffic on production network is one of the methods discussed by > the document. > > > > The following reference to the effects of the high level traffic is > > not sufficient > > IMO: > > > > > > =D8 Section 5 of [RFC2680] lists the problems with high > > measurement traffic rates, and the most relevant for rate > > measurement > > > > =D8 is the tendency for measurement traffic to skew the results, follo= wed > > by the possibility of introducing congestion on the access link. In= - > > Service testing MUST respect these traffic constraints. Obviously, > > categories of rate measurement methods that use less active test > > traffic than others with similar accuracy are preferred for In- > > Service testing. > > > > Section 5 of RFC2680 does not provide too many details as I was > > expecting. It actually deals with traffic injection as with a security = concern: > > > > > > =D8 There are two types of security concerns: potential harm caused by > > > > =D8 the measurements, and potential harm to the measurements. The > > > > =D8 measurements could cause harm because they are active, and inject > > > > =D8 packets into the network. The measurement parameters MUST be > > > > =D8 carefully selected so that the measurements inject trivial amount= s of > > > > =D8 additional traffic into the networks they measure. If they inject > > > > =D8 "too much" traffic, they can skew the results of the measurement,= and > > > > =D8 in extreme cases cause congestion and denial of service. > > > > =D8 > > 'trivial amounts of additional traffic' is too vague - I believe that > > more clear text that deals with the issue as with an operational > > issue, and makes clear that degradation of service for users is not > > acceptable if In-Service testing policies are applied would be welcome. > > > > I hope this helps. > > > > Regards, > > > > Dan From nobody Thu Dec 18 06:09:03 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8411A89B5; Thu, 18 Dec 2014 06:09:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVilZ4Xl_fbB; Thu, 18 Dec 2014 06:08:53 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05DE51A899C; Thu, 18 Dec 2014 06:08:52 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMGABffklTGmAcV/2dsb2JhbABagmQiUlgEs1sBAQEBAQEGkjWFcgKBGxYBAQEBAQF8hAwBAQEBAgESCF8MBAIBCA0EBAEBCx0HMhQJCAIEAQkEBQgTB4gCCAEMs3egfgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEhgCECoUQJzEHBoMQgRMFiRqEcIM+hj+CYYImh3aDOCKDbG8BgQIkHn4BAQE X-IronPort-AV: E=Sophos;i="5.07,601,1413259200"; d="scan'208";a="99697956" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 18 Dec 2014 09:08:49 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 18 Dec 2014 09:08:49 -0500 Received: from AZ-FFEXMB03.global.avaya.com ([fe80::d008:af0c:fa66:47e3]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Thu, 18 Dec 2014 09:08:47 -0500 From: "Romascanu, Dan (Dan)" To: "MORTON, ALFRED C (AL)" , "ops-dir@ietf.org" , "ippm@ietf.org" Thread-Topic: OPS-DIR review of draft-ietf-ippm-rate-problem-08 Thread-Index: AdAYe5l6zzPt7cY0Sz6o+JrRmzElOQAxhuiVACgMtpAABsHwBwACB4rAAC+P7poAAbFTYA== Date: Thu, 18 Dec 2014 14:08:46 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C93CA1B@AZ-FFEXMB03.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C93075A@AZ-FFEXMB04.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493901@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93A18C@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493905@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93B6D0@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493907@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D85493907@NJFPSRVEXG0.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/rq1YrVAtmp2v_sm8e7P43cQjOdI Cc: "draft-ietf-ippm-rate-problem.all@tools.ietf.org" Subject: Re: [ippm] OPS-DIR review of draft-ietf-ippm-rate-problem-08 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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, 18 Dec 2014 14:09:00 -0000 Hi Al, We are getting close. Your suggested text seems almost appropriate, with tw= o observations:=20 - 'adequately served' is too vague and an explanation of what that means is= needed - I do not believe that we need a reference to RFC 3148. Again, the concern= is not about the potential of security attacks (like DoS attacks mentioned= in 3148). The intent is to warn well intentioned operators, SPs and end us= ers of the potential dangers of not taking into consideration the effects o= f active methods, and recommend that they design and deploy accordingly Suggested edit to your proposal:=20 OLD:=20 7. Operational Considerations All forms of testing originate traffic on the network, through their commun= ications for control and results collection, or from dedicated measurement = packet streams, or both. Testing traffic primarily falls in one of two categories, subscriber traffi= c or network management traffic. There is an on-going need to engineer networks so that various forms of tra= ffic are adequately served, and publication of this memo does not change th= is need. Service subscribers and authorized users SHOULD obtain their network operat= or's or service provider's permission before conducting tests. Likewise, a = service provider or third party SHOULD obtain the subscriber's permission t= o conduct tests, since they might temporarily reduce service quality. See section 4.1 of [RFC 3148]. Subscribers, their service providers and network operators, and sometimes t= hird parties, all seek to measure network performance. Capacity testing with active traffic often affects the packet transfer perf= ormance of streams traversing shared components of the test path, to some d= egree. The degradation can be minimized by scheduling such tests infrequent= ly, and restricting the amount of measurement traffic required to assess ca= pacity metrics. As a result, occasional short-duration estimates are prefer= red to measurements based on frequent file transfers of many Megabytes. New measurement methodologies intended for standardization should be evalua= ted individually for potential operational issues. However, the scheduled frequency of testing is as important as the methods = used (and schedules are not typically submitted for standardization). NEW:=20 7. Operational Considerations All forms of testing originate traffic on the network, through their commun= ications for control and results collection, or from dedicated measurement = packet streams, or both. Testing traffic primarily falls in one of two categories, subscriber traffi= c or network management traffic. There is an on-going need to engineer networks so that various forms of tra= ffic are adequately served, and publication of this memo does not change th= is need . It is desirable that the increase load in the traffic levels in t= he live networks caused by the active measurement protocols and by the mana= gement of the active measurement protocols does not lead to any significant= degradation of the quality of service of the applications running in the n= etworks or the quality of experience of the users of the applications. Service subscribers and authorized users SHOULD obtain their network operat= or's or service provider's permission before conducting tests. Likewise, a = service provider or third party SHOULD obtain the subscriber's permission t= o conduct tests, since they might temporarily reduce service quality. Subscribers, their service providers and network operators, and sometimes t= hird parties, all seek to measure network performance. Capacity testing with active traffic often affects the packet transfer perf= ormance of streams traversing shared components of the test path, to some d= egree. The degradation can be minimized by scheduling such tests infrequent= ly, and restricting the amount of measurement traffic required to assess ca= pacity metrics. As a result, occasional short-duration estimates are prefer= red to measurements based on frequent file transfers of many Megabytes. New measurement methodologies intended for standardization should be evalua= ted individually for potential operational issues. However, the scheduled frequency of testing is as important as the methods = used (and schedules are not typically submitted for standardization). Regards, Dan > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Thursday, December 18, 2014 3:06 PM > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 >=20 >=20 > Hi Dan, >=20 > I now see better where the disconnect is. You are looking for new explic= it > statements about operational impact. But you are assuming that the active > measurement traffic is *excess* traffic, beyond some normal level resulti= ng > from all Subscriber traffic and an operator-chosen level of net managemen= t > traffic. > However, management traffic includes performance measurement traffic > (when the traffic is originated by the operator), and Subscriber traffic > includes active measurement traffic (when originated by the users). Test- > related traffic needs to be engineered and limited along with all other t= raffic. >=20 > Also, the requirement you wrote "does not lead to degradation" > doesn't seem attainable, so we need to provide cautions through other > means. Sending a single packet results in larger queue occupations all al= ong > its path =3D degradation. > The packet could be for routing or other network management. >=20 > The active measurement traffic is often launched by subscribers or their > authorized users, and there may well be some degree of degradation to > other subscriber's streams. > Your proposed text recommends against this, yet it is no different from t= he > degradation caused by a user who chooses to watch a video instead of > testing (except that the video session may be longer). >=20 > Further, Service providers may be temporarily replacing an idle user's tr= affic > with active test traffic. Again there may be some degradation to other > subscribers, but it would typically be no worse than from an additional u= ser > using their service. >=20 > There is also the question of test frequency and overall performance: > a user may experience instantaneous packet delay or loss while another > subscriber tests their performance, but then the performance is at nomina= l > levels for long periods between tests and the overall performance for a > multi-hour session would be satisfactory. >=20 > It is clear to me that the operational issues primarily addressed in prev= ious > IPPM work include the affects on other traffic, the accuracy of the > measurements (including preferential treatment or spoofing of measured > streams), and the real or perceived existence of DoS attacks. Although th= ese > are not identified as operations issues, they are certainly relevant in n= etwork > operations where measurement has become a growing part of the > management portfolio. > So, we should continue to cite the existing IPPM (and BMWG) guidance on > topics such as conservative measurement, and insert the references I > provided earlier into Section 3 (where you cited the reference from RFC26= 80 > - note the reference was to the sentence on high traffic rates, ("too muc= h > traffic") so the phrase "trivial amounts of additional traffic" may be an > inadequate specification, but it was not the intended reference material. >=20 > This is the new section I propose: >=20 > 7. Operational Considerations >=20 > All forms of testing originate traffic on the network, through their > communications for control and results collection, or from dedicated > measurement packet streams, or both. > Testing traffic primarily falls in one of two categories, subscriber traf= fic or > network management traffic. > There is an on-going need to engineer networks so that various forms of > traffic are adequately served, and publication of this memo does not chan= ge > this need. > Service subscribers and authorized users SHOULD obtain their network > operator's or service provider's permission before conducting tests. Like= wise, > a service provider or third party SHOULD obtain the subscriber's permissi= on > to conduct tests, since they might temporarily reduce service quality. > See section 4.1 of [RFC 3148]. >=20 > Subscribers, their service providers and network operators, and sometimes > third parties, all seek to measure network performance. > Capacity testing with active traffic often affects the packet transfer > performance of streams traversing shared components of the test path, to > some degree. The degradation can be minimized by scheduling such tests > infrequently, and restricting the amount of measurement traffic required = to > assess capacity metrics. As a result, occasional short-duration estimates= are > preferred to measurements based on frequent file transfers of many > Megabytes. > New measurement methodologies intended for standardization should be > evaluated individually for potential operational issues. > However, the scheduled frequency of testing is as important as the method= s > used (and schedules are not typically submitted for standardization). >=20 >=20 > ________________________________________ > From: Romascanu, Dan (Dan) [dromasca@avaya.com] > Sent: Wednesday, December 17, 2014 9:34 AM > To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 >=20 > Suggested edit: >=20 > Insert section 7 after the Security considerations section with the follo= wing > text, and renumber the other sections accordingly: >=20 > 7. Operational Considerations >=20 > The increase in traffic levels caused by applying any active measurement = of > live networks is a concern and needs to be considered and controlled any > time active measurements are applied. It is RECOMMENDED that the > increase load in the traffic levels in the live networks caused by the ac= tive > measurement protocols and by the management of the active measurement > protocols does not lead to a degradation of the quality of service of the > applications running in the networks or the quality of experience of the = users > of the applications. >=20 > Regards, >=20 > Dan >=20 >=20 > > -----Original Message----- > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > Sent: Wednesday, December 17, 2014 3:39 PM > > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > Hi Dan, > > > > I did not say that the operational implications would not be dealt with= here. > > > > I'm simply saying that IPPM drafts have done as you have asked many > > times already, that is discuss the implications of active > > measurements, and that we would not repeat that guidance (but include > > four references below). Also, that the measurement methods would each > > be vetted on their own, when proposed for standardization. > > You need both methods and control/test protocol, and the method > > solutions for this problem are out of scope. > > > > For example, the model-based metrics draft in IPPM introduces the > > notion of a target rate, which is a good thing, because it means that > > the test stream will have an upper bound. > > But that is an operational evaluation of a specific method, and OOS > > for the problem statement. > > > > Is this approach more clear? If not, please suggest some text. > > > > regards, > > Al > > ________________________________________ > > From: Romascanu, Dan (Dan) [dromasca@avaya.com] > > Sent: Wednesday, December 17, 2014 5:25 AM > > To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > Hi Al, > > > > I kind of disagree that dealing with the operational implications of > > applying active testing should not be mentioned in the problem > > statement, but only when specific measurement methods are described. > > The problem statement document explicitly describes active rate > > management and includes a section of requirements for test protocol > > control and generation. I believe that the operational aspects of > > generating traffic in production networks should be part of the > > problem statement, and explicitly mentioned, not only in the context of > altering measurement results or security considerations. > > > > Regards, > > > > Dan > > > > > > > -----Original Message----- > > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > > Sent: Tuesday, December 16, 2014 5:05 PM > > > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > Hi Dan, > > > > > > Thanks for your review. Perhaps we can close this quickly before we > > > both disappear for the holidays (officially, I'm already gone and > > > writing from Chicago, where it is unseasonably warm). > > > > > > We can certainly add details on the operational impact that test > > > protocols conforming to this memo's problem statement might cause. > > > This has been a point of issue since the earliest days of IPPM, so > > > we should be able to cover the topic by introducing several reference= s. > > > > > > If there is some additional point we can cover here, keeping in mind > > > that measurement methods are a non-goal of this draft and the > > > operational impact of specific methods are best dealt with when such > > > methods are specified, please provide your thoughts. > > > > > > regards, > > > Al > > > > > > The IPPM Framework RFC 2330, section 11.1, says > > > > > > + The act of measurement can perturb what is being measured (for > > > example, injecting measurement traffic into a network alters th= e > > > congestion level of the network), and repeated periodic > > > perturbations can drive a network into a state of synchronizati= on > > > (cf. [FJ94]), greatly magnifying what might individually be min= or > > > effects. > > > > > > And also, RFC 2330 adopts the term "conservative" for measurement > > > methodologies for which:, > > > > > > "... the act of measurement does not modify, or only slightly > > > modifies, the value of the performance metric the methodology > > > attempts to measure." > > > > > > However, the constraint that measurements strictly retain the > > > conservative property is updated in RFC 7312 > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > > 3A__tools.ietf.org_html_rfc7312-23section-2D4.4&d=3DAAIF- > > > > > > g&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd > > > rphpBsFA&m=3DN8q- > > > > > > hc4HbRszDQlImZQ_Tenl1mVdgb9ss1bTj9HzKew&s=3DpGbP1qC4qqZh21gJkoiKs > > > BmrE3lDnv8ulVOvmjOAlY0&e=3D > > > > > > It should be noted that this definition of "conservative" in the > > > sense of [RFC2330] depends to a large extent on the measurement > > > path's technology and characteristics. In particular, when deploy= ed > > > on reactive paths, subpaths, links or hosts conforming to the > > > definition in Section 1.1 of RFC 7312, measurement packets can > > > originate capacity (re)allocations. In addition, small measuremen= t > > > flow variations can result in other users on the same path perceiv= ing > > > significant variations in measurement results. Therefore: > > > > > > It is not always possible for the method to be conservative. > > > > > > And, on modern networks with reactive components, any traffic level > > > will have some impact on other users. Therefore, metrics and their > > > measurement methods should be vetted by the industry SDOs. To make > > > this point clear, we should cite BMWG RFC (2455 considered harmful > > > on production networks), which covers the topic in Section 6 > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > > > 3A__tools.ietf.org_html_rfc6815-23section-2D6&d=3DAAIF- > > > > > > g&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd > > > rphpBsFA&m=3DN8q- > > > > > > hc4HbRszDQlImZQ_Tenl1mVdgb9ss1bTj9HzKew&s=3D5fEqW5JnBgSuJYNRNSJS > > > mwfu04Mp6cQTBkG_aQNT6qU&e=3D > > > and says: > > > > > > ...There are no specific methods proposed for > > > activation of a packet transfer service in IPPM at this time. Thu= s, > > > individuals who need to conduct capacity tests on production netwo= rks > > > should actively participate in standards development to ensure the= ir > > > methods receive appropriate industry review and agreement, in the > > > IETF or in alternate standards development organizations. > > > > > > > > > > > > ________________________________________ > > > From: OPS-DIR [ops-dir-bounces@ietf.org] On Behalf Of Romascanu, Dan > > > (Dan) [dromasca@avaya.com] > > > Sent: Monday, December 15, 2014 10:27 AM > > > To: ops-dir@ietf.org; ippm@ietf.org > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > Subject: [OPS-DIR] OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > I have reviewed this document as part of the Operational > > > directorate's ongoing effort to review all IETF documents being proce= ssed > by the IESG. > > > These comments were written primarily for the benefit of the > > > operational area directors. > > > Document editors and WG chairs should treat these comments just like > > > any other last call comments. > > > > > > Ready with one issue > > > > > > This I-D is an informational document that does not define a new > > > protocol or protocol extensions. It does however contain a problem > > > statement for test protocols conducting access rate measurement in > > productions networks. > > > These protocols can be OWAMP (RFC 4656) or TWAMP (RFC 5357) but > also > > > non-IETF protocols. The following operational considerations in > > > Appendix A.1 of RFC 5706 apply, I believe, and do not receive > > > appropriate answers in the > > > document: > > > > > > 5. Has the impact on network operation been discussed? See Section 2.= 5. > > > * Will the new protocol significantly increase traffic load on > > > existing networks? > > > * Will the proposed management for the new protocol significantly > > > increase traffic load on existing networks? > > > * How will the new protocol impact the behavior of other protocols > > > in the network? Will it impact performance (e.g., > > > jitter) of certain types of applications running in the same network? > > > > > > I believe that at least a reference to these aspects need to be > > > included, especially as the In-Service testing with injection of > > > active traffic on production network is one of the methods discussed > > > by > > the document. > > > > > > The following reference to the effects of the high level traffic is > > > not sufficient > > > IMO: > > > > > > > > > =D8 Section 5 of [RFC2680] lists the problems with high > > > measurement traffic rates, and the most relevant for rate > > > measurement > > > > > > =D8 is the tendency for measurement traffic to skew the results, fol= lowed > > > by the possibility of introducing congestion on the access link. = In- > > > Service testing MUST respect these traffic constraints. Obviously= , > > > categories of rate measurement methods that use less active test > > > traffic than others with similar accuracy are preferred for In- > > > Service testing. > > > > > > Section 5 of RFC2680 does not provide too many details as I was > > > expecting. It actually deals with traffic injection as with a securit= y concern: > > > > > > > > > =D8 There are two types of security concerns: potential harm caused > > > by > > > > > > =D8 the measurements, and potential harm to the measurements. The > > > > > > =D8 measurements could cause harm because they are active, and inje= ct > > > > > > =D8 packets into the network. The measurement parameters MUST be > > > > > > =D8 carefully selected so that the measurements inject trivial amou= nts of > > > > > > =D8 additional traffic into the networks they measure. If they inje= ct > > > > > > =D8 "too much" traffic, they can skew the results of the measuremen= t, > and > > > > > > =D8 in extreme cases cause congestion and denial of service. > > > > > > =D8 > > > 'trivial amounts of additional traffic' is too vague - I believe > > > that more clear text that deals with the issue as with an > > > operational issue, and makes clear that degradation of service for > > > users is not acceptable if In-Service testing policies are applied wo= uld be > welcome. > > > > > > I hope this helps. > > > > > > Regards, > > > > > > Dan From nobody Thu Dec 18 06:34:49 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0671A8983; Thu, 18 Dec 2014 06:34:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 822OzbtXjDNF; Thu, 18 Dec 2014 06:34:41 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA9D1A89C6; Thu, 18 Dec 2014 06:34:05 -0800 (PST) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id 060131226C0; Thu, 18 Dec 2014 09:46:26 -0500 (EST) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.240.40]) by mail-azure.research.att.com (Postfix) with ESMTP id E7C9EE03B3; Thu, 18 Dec 2014 09:34:01 -0500 (EST) Received: from NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea]) by NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea%17]) with mapi; Thu, 18 Dec 2014 09:34:01 -0500 From: "MORTON, ALFRED C (AL)" To: "Romascanu, Dan (Dan)" , "ops-dir@ietf.org" , "ippm@ietf.org" Date: Thu, 18 Dec 2014 09:34:01 -0500 Thread-Topic: OPS-DIR review of draft-ietf-ippm-rate-problem-08 Thread-Index: AdAYe5l6zzPt7cY0Sz6o+JrRmzElOQAxhuiVACgMtpAABsHwBwACB4rAAC+P7poAAbFTYAAA3/rr Message-ID: <4AF73AA205019A4C8A1DDD32C034631D85493909@NJFPSRVEXG0.research.att.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C93075A@AZ-FFEXMB04.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493901@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93A18C@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493905@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93B6D0@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493907@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93CA1B@AZ-FFEXMB03.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C93CA1B@AZ-FFEXMB03.global.avaya.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 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/FN57t4e3E4dktgbVtLbxMxLKlsw Cc: "draft-ietf-ippm-rate-problem.all@tools.ietf.org" Subject: Re: [ippm] OPS-DIR review of draft-ietf-ippm-rate-problem-08 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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, 18 Dec 2014 14:34:46 -0000 Hi Dan, When you added the sentence: It is desirable that the increase load in the traffic levels in the live = networks caused by the active measurement protocols and by the management of the active measurement protocols does not lead t= o any significant degradation of the quality of service of the applications running in the networks or the qua= lity of experience of the users of the applications. You have continued to assume that the measurement traffic is excess traffic= ("increased load") and it needs new requirements. As I said, one subscriber's traffic can degrade the traf= fic of another subscriber, whether the degradation is significant or not depends on too many factors t= o go into here, but one or both of the subscribers could be running tests related to this p= roblem statement. Operators engineer their management traffic load, including measurement-rel= ated traffic. There is simply traffic from many sources, all to be engineered. Operations= and Engineering as usual. The section has provided specific cautions and guidance for operators and u= sers. No need for new implementation rules, IMO. regards, Al ________________________________________ From: Romascanu, Dan (Dan) [dromasca@avaya.com] Sent: Thursday, December 18, 2014 9:08 AM To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 Hi Al, We are getting close. Your suggested text seems almost appropriate, with tw= o observations: - 'adequately served' is too vague and an explanation of what that means is= needed - I do not believe that we need a reference to RFC 3148. Again, the concern= is not about the potential of security attacks (like DoS attacks mentioned= in 3148). The intent is to warn well intentioned operators, SPs and end us= ers of the potential dangers of not taking into consideration the effects o= f active methods, and recommend that they design and deploy accordingly Suggested edit to your proposal: OLD: 7. Operational Considerations All forms of testing originate traffic on the network, through their commun= ications for control and results collection, or from dedicated measurement = packet streams, or both. Testing traffic primarily falls in one of two categories, subscriber traffi= c or network management traffic. There is an on-going need to engineer networks so that various forms of tra= ffic are adequately served, and publication of this memo does not change th= is need. Service subscribers and authorized users SHOULD obtain their network operat= or's or service provider's permission before conducting tests. Likewise, a = service provider or third party SHOULD obtain the subscriber's permission t= o conduct tests, since they might temporarily reduce service quality. See section 4.1 of [RFC 3148]. Subscribers, their service providers and network operators, and sometimes t= hird parties, all seek to measure network performance. Capacity testing with active traffic often affects the packet transfer perf= ormance of streams traversing shared components of the test path, to some d= egree. The degradation can be minimized by scheduling such tests infrequent= ly, and restricting the amount of measurement traffic required to assess ca= pacity metrics. As a result, occasional short-duration estimates are prefer= red to measurements based on frequent file transfers of many Megabytes. New measurement methodologies intended for standardization should be evalua= ted individually for potential operational issues. However, the scheduled frequency of testing is as important as the methods = used (and schedules are not typically submitted for standardization). NEW: 7. Operational Considerations All forms of testing originate traffic on the network, through their commun= ications for control and results collection, or from dedicated measurement = packet streams, or both. Testing traffic primarily falls in one of two categories, subscriber traffi= c or network management traffic. There is an on-going need to engineer networks so that various forms of tra= ffic are adequately served, and publication of this memo does not change th= is need . It is desirable that the increase load in the traffic levels in t= he live networks caused by the active measurement protocols and by the mana= gement of the active measurement protocols does not lead to any significant= degradation of the quality of service of the applications running in the n= etworks or the quality of experience of the users of the applications. Service subscribers and authorized users SHOULD obtain their network operat= or's or service provider's permission before conducting tests. Likewise, a = service provider or third party SHOULD obtain the subscriber's permission t= o conduct tests, since they might temporarily reduce service quality. Subscribers, their service providers and network operators, and sometimes t= hird parties, all seek to measure network performance. Capacity testing with active traffic often affects the packet transfer perf= ormance of streams traversing shared components of the test path, to some d= egree. The degradation can be minimized by scheduling such tests infrequent= ly, and restricting the amount of measurement traffic required to assess ca= pacity metrics. As a result, occasional short-duration estimates are prefer= red to measurements based on frequent file transfers of many Megabytes. New measurement methodologies intended for standardization should be evalua= ted individually for potential operational issues. However, the scheduled frequency of testing is as important as the methods = used (and schedules are not typically submitted for standardization). Regards, Dan > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Thursday, December 18, 2014 3:06 PM > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > Hi Dan, > > I now see better where the disconnect is. You are looking for new explic= it > statements about operational impact. But you are assuming that the active > measurement traffic is *excess* traffic, beyond some normal level resulti= ng > from all Subscriber traffic and an operator-chosen level of net managemen= t > traffic. > However, management traffic includes performance measurement traffic > (when the traffic is originated by the operator), and Subscriber traffic > includes active measurement traffic (when originated by the users). Test- > related traffic needs to be engineered and limited along with all other t= raffic. > > Also, the requirement you wrote "does not lead to degradation" > doesn't seem attainable, so we need to provide cautions through other > means. Sending a single packet results in larger queue occupations all al= ong > its path =3D degradation. > The packet could be for routing or other network management. > > The active measurement traffic is often launched by subscribers or their > authorized users, and there may well be some degree of degradation to > other subscriber's streams. > Your proposed text recommends against this, yet it is no different from t= he > degradation caused by a user who chooses to watch a video instead of > testing (except that the video session may be longer). > > Further, Service providers may be temporarily replacing an idle user's tr= affic > with active test traffic. Again there may be some degradation to other > subscribers, but it would typically be no worse than from an additional u= ser > using their service. > > There is also the question of test frequency and overall performance: > a user may experience instantaneous packet delay or loss while another > subscriber tests their performance, but then the performance is at nomina= l > levels for long periods between tests and the overall performance for a > multi-hour session would be satisfactory. > > It is clear to me that the operational issues primarily addressed in prev= ious > IPPM work include the affects on other traffic, the accuracy of the > measurements (including preferential treatment or spoofing of measured > streams), and the real or perceived existence of DoS attacks. Although th= ese > are not identified as operations issues, they are certainly relevant in n= etwork > operations where measurement has become a growing part of the > management portfolio. > So, we should continue to cite the existing IPPM (and BMWG) guidance on > topics such as conservative measurement, and insert the references I > provided earlier into Section 3 (where you cited the reference from RFC26= 80 > - note the reference was to the sentence on high traffic rates, ("too muc= h > traffic") so the phrase "trivial amounts of additional traffic" may be an > inadequate specification, but it was not the intended reference material. > > This is the new section I propose: > > 7. Operational Considerations > > All forms of testing originate traffic on the network, through their > communications for control and results collection, or from dedicated > measurement packet streams, or both. > Testing traffic primarily falls in one of two categories, subscriber traf= fic or > network management traffic. > There is an on-going need to engineer networks so that various forms of > traffic are adequately served, and publication of this memo does not chan= ge > this need. > Service subscribers and authorized users SHOULD obtain their network > operator's or service provider's permission before conducting tests. Like= wise, > a service provider or third party SHOULD obtain the subscriber's permissi= on > to conduct tests, since they might temporarily reduce service quality. > See section 4.1 of [RFC 3148]. > > Subscribers, their service providers and network operators, and sometimes > third parties, all seek to measure network performance. > Capacity testing with active traffic often affects the packet transfer > performance of streams traversing shared components of the test path, to > some degree. The degradation can be minimized by scheduling such tests > infrequently, and restricting the amount of measurement traffic required = to > assess capacity metrics. As a result, occasional short-duration estimates= are > preferred to measurements based on frequent file transfers of many > Megabytes. > New measurement methodologies intended for standardization should be > evaluated individually for potential operational issues. > However, the scheduled frequency of testing is as important as the method= s > used (and schedules are not typically submitted for standardization). > > > ________________________________________ > From: Romascanu, Dan (Dan) [dromasca@avaya.com] > Sent: Wednesday, December 17, 2014 9:34 AM > To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > Suggested edit: > > Insert section 7 after the Security considerations section with the follo= wing > text, and renumber the other sections accordingly: > > 7. Operational Considerations > > The increase in traffic levels caused by applying any active measurement = of > live networks is a concern and needs to be considered and controlled any > time active measurements are applied. It is RECOMMENDED that the > increase load in the traffic levels in the live networks caused by the ac= tive > measurement protocols and by the management of the active measurement > protocols does not lead to a degradation of the quality of service of the > applications running in the networks or the quality of experience of the = users > of the applications. > > Regards, > > Dan > > > > -----Original Message----- > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > Sent: Wednesday, December 17, 2014 3:39 PM > > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > Hi Dan, > > > > I did not say that the operational implications would not be dealt with= here. > > > > I'm simply saying that IPPM drafts have done as you have asked many > > times already, that is discuss the implications of active > > measurements, and that we would not repeat that guidance (but include > > four references below). Also, that the measurement methods would each > > be vetted on their own, when proposed for standardization. > > You need both methods and control/test protocol, and the method > > solutions for this problem are out of scope. > > > > For example, the model-based metrics draft in IPPM introduces the > > notion of a target rate, which is a good thing, because it means that > > the test stream will have an upper bound. > > But that is an operational evaluation of a specific method, and OOS > > for the problem statement. > > > > Is this approach more clear? If not, please suggest some text. > > > > regards, > > Al > > ________________________________________ > > From: Romascanu, Dan (Dan) [dromasca@avaya.com] > > Sent: Wednesday, December 17, 2014 5:25 AM > > To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > Hi Al, > > > > I kind of disagree that dealing with the operational implications of > > applying active testing should not be mentioned in the problem > > statement, but only when specific measurement methods are described. > > The problem statement document explicitly describes active rate > > management and includes a section of requirements for test protocol > > control and generation. I believe that the operational aspects of > > generating traffic in production networks should be part of the > > problem statement, and explicitly mentioned, not only in the context of > altering measurement results or security considerations. > > > > Regards, > > > > Dan > > > > > > > -----Original Message----- > > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > > Sent: Tuesday, December 16, 2014 5:05 PM > > > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > Hi Dan, > > > > > > Thanks for your review. Perhaps we can close this quickly before we > > > both disappear for the holidays (officially, I'm already gone and > > > writing from Chicago, where it is unseasonably warm). > > > > > > We can certainly add details on the operational impact that test > > > protocols conforming to this memo's problem statement might cause. > > > This has been a point of issue since the earliest days of IPPM, so > > > we should be able to cover the topic by introducing several reference= s. > > > > > > If there is some additional point we can cover here, keeping in mind > > > that measurement methods are a non-goal of this draft and the > > > operational impact of specific methods are best dealt with when such > > > methods are specified, please provide your thoughts. > > > > > > regards, > > > Al > > > > > > The IPPM Framework RFC 2330, section 11.1, says > > > > > > + The act of measurement can perturb what is being measured (for > > > example, injecting measurement traffic into a network alters th= e > > > congestion level of the network), and repeated periodic > > > perturbations can drive a network into a state of synchronizati= on > > > (cf. [FJ94]), greatly magnifying what might individually be min= or > > > effects. > > > > > > And also, RFC 2330 adopts the term "conservative" for measurement > > > methodologies for which:, > > > > > > "... the act of measurement does not modify, or only slightly > > > modifies, the value of the performance metric the methodology > > > attempts to measure." > > > > > > However, the constraint that measurements strictly retain the > > > conservative property is updated in RFC 7312 > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > > 3A__tools.ietf.org_html_rfc7312-23section-2D4.4&d=3DAAIF- > > > > > > g&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd > > > rphpBsFA&m=3DN8q- > > > > > > hc4HbRszDQlImZQ_Tenl1mVdgb9ss1bTj9HzKew&s=3DpGbP1qC4qqZh21gJkoiKs > > > BmrE3lDnv8ulVOvmjOAlY0&e=3D > > > > > > It should be noted that this definition of "conservative" in the > > > sense of [RFC2330] depends to a large extent on the measurement > > > path's technology and characteristics. In particular, when deploy= ed > > > on reactive paths, subpaths, links or hosts conforming to the > > > definition in Section 1.1 of RFC 7312, measurement packets can > > > originate capacity (re)allocations. In addition, small measuremen= t > > > flow variations can result in other users on the same path perceiv= ing > > > significant variations in measurement results. Therefore: > > > > > > It is not always possible for the method to be conservative. > > > > > > And, on modern networks with reactive components, any traffic level > > > will have some impact on other users. Therefore, metrics and their > > > measurement methods should be vetted by the industry SDOs. To make > > > this point clear, we should cite BMWG RFC (2455 considered harmful > > > on production networks), which covers the topic in Section 6 > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > > > 3A__tools.ietf.org_html_rfc6815-23section-2D6&d=3DAAIF- > > > > > > g&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd > > > rphpBsFA&m=3DN8q- > > > > > > hc4HbRszDQlImZQ_Tenl1mVdgb9ss1bTj9HzKew&s=3D5fEqW5JnBgSuJYNRNSJS > > > mwfu04Mp6cQTBkG_aQNT6qU&e=3D > > > and says: > > > > > > ...There are no specific methods proposed for > > > activation of a packet transfer service in IPPM at this time. Thu= s, > > > individuals who need to conduct capacity tests on production netwo= rks > > > should actively participate in standards development to ensure the= ir > > > methods receive appropriate industry review and agreement, in the > > > IETF or in alternate standards development organizations. > > > > > > > > > > > > ________________________________________ > > > From: OPS-DIR [ops-dir-bounces@ietf.org] On Behalf Of Romascanu, Dan > > > (Dan) [dromasca@avaya.com] > > > Sent: Monday, December 15, 2014 10:27 AM > > > To: ops-dir@ietf.org; ippm@ietf.org > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > Subject: [OPS-DIR] OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > I have reviewed this document as part of the Operational > > > directorate's ongoing effort to review all IETF documents being proce= ssed > by the IESG. > > > These comments were written primarily for the benefit of the > > > operational area directors. > > > Document editors and WG chairs should treat these comments just like > > > any other last call comments. > > > > > > Ready with one issue > > > > > > This I-D is an informational document that does not define a new > > > protocol or protocol extensions. It does however contain a problem > > > statement for test protocols conducting access rate measurement in > > productions networks. > > > These protocols can be OWAMP (RFC 4656) or TWAMP (RFC 5357) but > also > > > non-IETF protocols. The following operational considerations in > > > Appendix A.1 of RFC 5706 apply, I believe, and do not receive > > > appropriate answers in the > > > document: > > > > > > 5. Has the impact on network operation been discussed? See Section 2.= 5. > > > * Will the new protocol significantly increase traffic load on > > > existing networks? > > > * Will the proposed management for the new protocol significantly > > > increase traffic load on existing networks? > > > * How will the new protocol impact the behavior of other protocols > > > in the network? Will it impact performance (e.g., > > > jitter) of certain types of applications running in the same network? > > > > > > I believe that at least a reference to these aspects need to be > > > included, especially as the In-Service testing with injection of > > > active traffic on production network is one of the methods discussed > > > by > > the document. > > > > > > The following reference to the effects of the high level traffic is > > > not sufficient > > > IMO: > > > > > > > > > ? Section 5 of [RFC2680] lists the problems with high > > > measurement traffic rates, and the most relevant for rate > > > measurement > > > > > > ? is the tendency for measurement traffic to skew the results, follo= wed > > > by the possibility of introducing congestion on the access link. = In- > > > Service testing MUST respect these traffic constraints. Obviously= , > > > categories of rate measurement methods that use less active test > > > traffic than others with similar accuracy are preferred for In- > > > Service testing. > > > > > > Section 5 of RFC2680 does not provide too many details as I was > > > expecting. It actually deals with traffic injection as with a securit= y concern: > > > > > > > > > ? There are two types of security concerns: potential harm caused > > > by > > > > > > ? the measurements, and potential harm to the measurements. The > > > > > > ? measurements could cause harm because they are active, and inject > > > > > > ? packets into the network. The measurement parameters MUST be > > > > > > ? carefully selected so that the measurements inject trivial amount= s of > > > > > > ? additional traffic into the networks they measure. If they inject > > > > > > ? "too much" traffic, they can skew the results of the measurement, > and > > > > > > ? in extreme cases cause congestion and denial of service. > > > > > > ? > > > 'trivial amounts of additional traffic' is too vague - I believe > > > that more clear text that deals with the issue as with an > > > operational issue, and makes clear that degradation of service for > > > users is not acceptable if In-Service testing policies are applied wo= uld be > welcome. > > > > > > I hope this helps. > > > > > > Regards, > > > > > > Dan From nobody Thu Dec 18 07:00:34 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A071A8A39; Thu, 18 Dec 2014 07:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82QqkLTwKWfN; Thu, 18 Dec 2014 07:00:19 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07DAF1A8A59; Thu, 18 Dec 2014 07:00:18 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMGAJTqklSHCzIm/2dsb2JhbABagmQiUlgEs1sBAQEBAQEGkjWFcgKBHBYBAQEBAQF8hAwBAQEBAxIIID8MBAIBCA0EBAEBCxQJBzIUCQgCBAEJBAUIEweICgEMtAigYAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEhgCECoUFCycxBwaDEIETBYN7ig+DPoM+gwGCYYImh3aDOCKDbG8BgQIkHn4BAQE X-IronPort-AV: E=Sophos;i="5.07,601,1413259200"; d="scan'208";a="85153595" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 18 Dec 2014 10:00:14 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 18 Dec 2014 10:00:13 -0500 Received: from AZ-FFEXMB03.global.avaya.com ([fe80::d008:af0c:fa66:47e3]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Thu, 18 Dec 2014 16:00:12 +0100 From: "Romascanu, Dan (Dan)" To: "MORTON, ALFRED C (AL)" , "ops-dir@ietf.org" , "ippm@ietf.org" Thread-Topic: OPS-DIR review of draft-ietf-ippm-rate-problem-08 Thread-Index: AdAYe5l6zzPt7cY0Sz6o+JrRmzElOQAxhuiVACgMtpAABsHwBwACB4rAAC+P7poAAbFTYAAA3/rrAAE0nhA= Date: Thu, 18 Dec 2014 15:00:11 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C93CB00@AZ-FFEXMB03.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C93075A@AZ-FFEXMB04.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493901@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93A18C@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493905@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93B6D0@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493907@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93CA1B@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493909@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D85493909@NJFPSRVEXG0.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/x6FilUpCNqy4DABM8kcITrqk0tg Cc: "draft-ietf-ippm-rate-problem.all@tools.ietf.org" Subject: Re: [ippm] OPS-DIR review of draft-ietf-ippm-rate-problem-08 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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, 18 Dec 2014 15:00:29 -0000 Hi Al, But this IS increased traffic, as standardized rate measurements were not i= n practice until now, hence the need for new standards, including the ones = in IPPM. Yes, it's management traffic, but the very issue an operational co= nsiderations sections aims is to draw the attention that people that design= an deploy new protocols need to factor in the overall effects of new proto= cols traffic on the networks. New protocols and methods to measure rate gen= erate new traffic, active measurement causes more new traffic than passive = methods, all this needs to be considered. The goal of this text is exactly = to make sure and explicit that operators engineer their management traffic = load, including measurement-related traffic. Regards, Dan > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Thursday, December 18, 2014 4:34 PM > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 >=20 > Hi Dan, >=20 > When you added the sentence: > It is desirable that the increase load in the traffic levels in the liv= e networks > caused by the active measurement protocols > and by the management of the active measurement protocols does not > lead to any significant degradation of the > quality of service of the applications running in the networks or the q= uality > of experience of the users of the applications. >=20 > You have continued to assume that the measurement traffic is excess traff= ic > ("increased load") and it needs new requirements. As I said, one subscri= ber's > traffic can degrade the traffic of another subscriber, whether the > degradation is significant or not depends on too many factors to go into = here, > but one or both of the subscribers could be running tests related to this > problem statement. > Operators engineer their management traffic load, including measurement- > related traffic. >=20 > There is simply traffic from many sources, all to be engineered. Operatio= ns > and Engineering as usual. > The section has provided specific cautions and guidance for operators and > users. No need for new implementation rules, IMO. >=20 > regards, > Al > ________________________________________ > From: Romascanu, Dan (Dan) [dromasca@avaya.com] > Sent: Thursday, December 18, 2014 9:08 AM > To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 >=20 > Hi Al, >=20 > We are getting close. Your suggested text seems almost appropriate, with > two observations: >=20 > - 'adequately served' is too vague and an explanation of what that means = is > needed > - I do not believe that we need a reference to RFC 3148. Again, the conce= rn is > not about the potential of security attacks (like DoS attacks mentioned i= n > 3148). The intent is to warn well intentioned operators, SPs and end user= s of > the potential dangers of not taking into consideration the effects of act= ive > methods, and recommend that they design and deploy accordingly >=20 > Suggested edit to your proposal: >=20 > OLD: >=20 > 7. Operational Considerations >=20 > All forms of testing originate traffic on the network, through their > communications for control and results collection, or from dedicated > measurement packet streams, or both. > Testing traffic primarily falls in one of two categories, subscriber traf= fic or > network management traffic. > There is an on-going need to engineer networks so that various forms of > traffic are adequately served, and publication of this memo does not chan= ge > this need. > Service subscribers and authorized users SHOULD obtain their network > operator's or service provider's permission before conducting tests. Like= wise, > a service provider or third party SHOULD obtain the subscriber's permissi= on > to conduct tests, since they might temporarily reduce service quality. > See section 4.1 of [RFC 3148]. >=20 > Subscribers, their service providers and network operators, and sometimes > third parties, all seek to measure network performance. > Capacity testing with active traffic often affects the packet transfer > performance of streams traversing shared components of the test path, to > some degree. The degradation can be minimized by scheduling such tests > infrequently, and restricting the amount of measurement traffic required = to > assess capacity metrics. As a result, occasional short-duration estimates= are > preferred to measurements based on frequent file transfers of many > Megabytes. > New measurement methodologies intended for standardization should be > evaluated individually for potential operational issues. > However, the scheduled frequency of testing is as important as the method= s > used (and schedules are not typically submitted for standardization). >=20 > NEW: >=20 > 7. Operational Considerations >=20 > All forms of testing originate traffic on the network, through their > communications for control and results collection, or from dedicated > measurement packet streams, or both. > Testing traffic primarily falls in one of two categories, subscriber traf= fic or > network management traffic. > There is an on-going need to engineer networks so that various forms of > traffic are adequately served, and publication of this memo does not chan= ge > this need . It is desirable that the increase load in the traffic levels = in the live > networks caused by the active measurement protocols and by the > management of the active measurement protocols does not lead to any > significant degradation of the quality of service of the applications run= ning in > the networks or the quality of experience of the users of the application= s. > Service subscribers and authorized users SHOULD obtain their network > operator's or service provider's permission before conducting tests. Like= wise, > a service provider or third party SHOULD obtain the subscriber's permissi= on > to conduct tests, since they might temporarily reduce service quality. >=20 > Subscribers, their service providers and network operators, and sometimes > third parties, all seek to measure network performance. > Capacity testing with active traffic often affects the packet transfer > performance of streams traversing shared components of the test path, to > some degree. The degradation can be minimized by scheduling such tests > infrequently, and restricting the amount of measurement traffic required = to > assess capacity metrics. As a result, occasional short-duration estimates= are > preferred to measurements based on frequent file transfers of many > Megabytes. > New measurement methodologies intended for standardization should be > evaluated individually for potential operational issues. > However, the scheduled frequency of testing is as important as the method= s > used (and schedules are not typically submitted for standardization). >=20 > Regards, >=20 > Dan >=20 >=20 > > -----Original Message----- > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > Sent: Thursday, December 18, 2014 3:06 PM > > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > Hi Dan, > > > > I now see better where the disconnect is. You are looking for new > > explicit statements about operational impact. But you are assuming > > that the active measurement traffic is *excess* traffic, beyond some > > normal level resulting from all Subscriber traffic and an > > operator-chosen level of net management traffic. > > However, management traffic includes performance measurement traffic > > (when the traffic is originated by the operator), and Subscriber > > traffic includes active measurement traffic (when originated by the > > users). Test- related traffic needs to be engineered and limited along = with > all other traffic. > > > > Also, the requirement you wrote "does not lead to degradation" > > doesn't seem attainable, so we need to provide cautions through other > > means. Sending a single packet results in larger queue occupations all > > along its path =3D degradation. > > The packet could be for routing or other network management. > > > > The active measurement traffic is often launched by subscribers or > > their authorized users, and there may well be some degree of > > degradation to other subscriber's streams. > > Your proposed text recommends against this, yet it is no different > > from the degradation caused by a user who chooses to watch a video > > instead of testing (except that the video session may be longer). > > > > Further, Service providers may be temporarily replacing an idle user's > > traffic with active test traffic. Again there may be some degradation > > to other subscribers, but it would typically be no worse than from an > > additional user using their service. > > > > There is also the question of test frequency and overall performance: > > a user may experience instantaneous packet delay or loss while another > > subscriber tests their performance, but then the performance is at > > nominal levels for long periods between tests and the overall > > performance for a multi-hour session would be satisfactory. > > > > It is clear to me that the operational issues primarily addressed in > > previous IPPM work include the affects on other traffic, the accuracy > > of the measurements (including preferential treatment or spoofing of > > measured streams), and the real or perceived existence of DoS attacks. > > Although these are not identified as operations issues, they are > > certainly relevant in network operations where measurement has become > > a growing part of the management portfolio. > > So, we should continue to cite the existing IPPM (and BMWG) guidance > > on topics such as conservative measurement, and insert the references > > I provided earlier into Section 3 (where you cited the reference from > > RFC2680 > > - note the reference was to the sentence on high traffic rates, ("too > > much > > traffic") so the phrase "trivial amounts of additional traffic" may be > > an inadequate specification, but it was not the intended reference > material. > > > > This is the new section I propose: > > > > 7. Operational Considerations > > > > All forms of testing originate traffic on the network, through their > > communications for control and results collection, or from dedicated > > measurement packet streams, or both. > > Testing traffic primarily falls in one of two categories, subscriber > > traffic or network management traffic. > > There is an on-going need to engineer networks so that various forms > > of traffic are adequately served, and publication of this memo does > > not change this need. > > Service subscribers and authorized users SHOULD obtain their network > > operator's or service provider's permission before conducting tests. > > Likewise, a service provider or third party SHOULD obtain the > > subscriber's permission to conduct tests, since they might temporarily > reduce service quality. > > See section 4.1 of [RFC 3148]. > > > > Subscribers, their service providers and network operators, and > > sometimes third parties, all seek to measure network performance. > > Capacity testing with active traffic often affects the packet transfer > > performance of streams traversing shared components of the test path, > > to some degree. The degradation can be minimized by scheduling such > > tests infrequently, and restricting the amount of measurement traffic > > required to assess capacity metrics. As a result, occasional > > short-duration estimates are preferred to measurements based on > > frequent file transfers of many Megabytes. > > New measurement methodologies intended for standardization should be > > evaluated individually for potential operational issues. > > However, the scheduled frequency of testing is as important as the > > methods used (and schedules are not typically submitted for > standardization). > > > > > > ________________________________________ > > From: Romascanu, Dan (Dan) [dromasca@avaya.com] > > Sent: Wednesday, December 17, 2014 9:34 AM > > To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > Suggested edit: > > > > Insert section 7 after the Security considerations section with the > > following text, and renumber the other sections accordingly: > > > > 7. Operational Considerations > > > > The increase in traffic levels caused by applying any active > > measurement of live networks is a concern and needs to be considered > > and controlled any time active measurements are applied. It is > > RECOMMENDED that the increase load in the traffic levels in the live > > networks caused by the active measurement protocols and by the > > management of the active measurement protocols does not lead to a > > degradation of the quality of service of the applications running in > > the networks or the quality of experience of the users of the applicati= ons. > > > > Regards, > > > > Dan > > > > > > > -----Original Message----- > > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > > Sent: Wednesday, December 17, 2014 3:39 PM > > > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > Hi Dan, > > > > > > I did not say that the operational implications would not be dealt wi= th > here. > > > > > > I'm simply saying that IPPM drafts have done as you have asked many > > > times already, that is discuss the implications of active > > > measurements, and that we would not repeat that guidance (but > > > include four references below). Also, that the measurement methods > > > would each be vetted on their own, when proposed for standardization. > > > You need both methods and control/test protocol, and the method > > > solutions for this problem are out of scope. > > > > > > For example, the model-based metrics draft in IPPM introduces the > > > notion of a target rate, which is a good thing, because it means > > > that the test stream will have an upper bound. > > > But that is an operational evaluation of a specific method, and OOS > > > for the problem statement. > > > > > > Is this approach more clear? If not, please suggest some text. > > > > > > regards, > > > Al > > > ________________________________________ > > > From: Romascanu, Dan (Dan) [dromasca@avaya.com] > > > Sent: Wednesday, December 17, 2014 5:25 AM > > > To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > Hi Al, > > > > > > I kind of disagree that dealing with the operational implications of > > > applying active testing should not be mentioned in the problem > > > statement, but only when specific measurement methods are described. > > > The problem statement document explicitly describes active rate > > > management and includes a section of requirements for test protocol > > > control and generation. I believe that the operational aspects of > > > generating traffic in production networks should be part of the > > > problem statement, and explicitly mentioned, not only in the context > > > of > > altering measurement results or security considerations. > > > > > > Regards, > > > > > > Dan > > > > > > > > > > -----Original Message----- > > > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > > > Sent: Tuesday, December 16, 2014 5:05 PM > > > > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > > > Hi Dan, > > > > > > > > Thanks for your review. Perhaps we can close this quickly before > > > > we both disappear for the holidays (officially, I'm already gone > > > > and writing from Chicago, where it is unseasonably warm). > > > > > > > > We can certainly add details on the operational impact that test > > > > protocols conforming to this memo's problem statement might cause. > > > > This has been a point of issue since the earliest days of IPPM, so > > > > we should be able to cover the topic by introducing several referen= ces. > > > > > > > > If there is some additional point we can cover here, keeping in > > > > mind that measurement methods are a non-goal of this draft and the > > > > operational impact of specific methods are best dealt with when > > > > such methods are specified, please provide your thoughts. > > > > > > > > regards, > > > > Al > > > > > > > > The IPPM Framework RFC 2330, section 11.1, says > > > > > > > > + The act of measurement can perturb what is being measured > > > > + (for > > > > example, injecting measurement traffic into a network alters = the > > > > congestion level of the network), and repeated periodic > > > > perturbations can drive a network into a state of synchroniza= tion > > > > (cf. [FJ94]), greatly magnifying what might individually be m= inor > > > > effects. > > > > > > > > And also, RFC 2330 adopts the term "conservative" for measurement > > > > methodologies for which:, > > > > > > > > "... the act of measurement does not modify, or only slightly > > > > modifies, the value of the performance metric the methodology > > > > attempts to measure." > > > > > > > > However, the constraint that measurements strictly retain the > > > > conservative property is updated in RFC 7312 > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > > > 3A__tools.ietf.org_html_rfc7312-23section-2D4.4&d=3DAAIF- > > > > > > > > > > g&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd > > > > rphpBsFA&m=3DN8q- > > > > > > > > > > hc4HbRszDQlImZQ_Tenl1mVdgb9ss1bTj9HzKew&s=3DpGbP1qC4qqZh21gJkoiKs > > > > BmrE3lDnv8ulVOvmjOAlY0&e=3D > > > > > > > > It should be noted that this definition of "conservative" in the > > > > sense of [RFC2330] depends to a large extent on the measurement > > > > path's technology and characteristics. In particular, when depl= oyed > > > > on reactive paths, subpaths, links or hosts conforming to the > > > > definition in Section 1.1 of RFC 7312, measurement packets can > > > > originate capacity (re)allocations. In addition, small measurem= ent > > > > flow variations can result in other users on the same path perce= iving > > > > significant variations in measurement results. Therefore: > > > > > > > > It is not always possible for the method to be conservative. > > > > > > > > And, on modern networks with reactive components, any traffic > > > > level will have some impact on other users. Therefore, metrics > > > > and their measurement methods should be vetted by the industry > > > > SDOs. To make this point clear, we should cite BMWG RFC (2455 > > > > considered harmful on production networks), which covers the topic > > > > in Section 6 > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > > > > 3A__tools.ietf.org_html_rfc6815-23section-2D6&d=3DAAIF- > > > > > > > > > > g&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd > > > > rphpBsFA&m=3DN8q- > > > > > > > > > > hc4HbRszDQlImZQ_Tenl1mVdgb9ss1bTj9HzKew&s=3D5fEqW5JnBgSuJYNRNSJS > > > > mwfu04Mp6cQTBkG_aQNT6qU&e=3D > > > > and says: > > > > > > > > ...There are no specific methods proposed for > > > > activation of a packet transfer service in IPPM at this time. T= hus, > > > > individuals who need to conduct capacity tests on production > networks > > > > should actively participate in standards development to ensure t= heir > > > > methods receive appropriate industry review and agreement, in th= e > > > > IETF or in alternate standards development organizations. > > > > > > > > > > > > > > > > ________________________________________ > > > > From: OPS-DIR [ops-dir-bounces@ietf.org] On Behalf Of Romascanu, > > > > Dan > > > > (Dan) [dromasca@avaya.com] > > > > Sent: Monday, December 15, 2014 10:27 AM > > > > To: ops-dir@ietf.org; ippm@ietf.org > > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > > Subject: [OPS-DIR] OPS-DIR review of > > > > draft-ietf-ippm-rate-problem-08 > > > > > > > > I have reviewed this document as part of the Operational > > > > directorate's ongoing effort to review all IETF documents being > > > > processed > > by the IESG. > > > > These comments were written primarily for the benefit of the > > > > operational area directors. > > > > Document editors and WG chairs should treat these comments just > > > > like any other last call comments. > > > > > > > > Ready with one issue > > > > > > > > This I-D is an informational document that does not define a new > > > > protocol or protocol extensions. It does however contain a problem > > > > statement for test protocols conducting access rate measurement in > > > productions networks. > > > > These protocols can be OWAMP (RFC 4656) or TWAMP (RFC 5357) but > > also > > > > non-IETF protocols. The following operational considerations in > > > > Appendix A.1 of RFC 5706 apply, I believe, and do not receive > > > > appropriate answers in the > > > > document: > > > > > > > > 5. Has the impact on network operation been discussed? See Section > 2.5. > > > > * Will the new protocol significantly increase traffic load on > > > > existing networks? > > > > * Will the proposed management for the new protocol significantly > > > > increase traffic load on existing networks? > > > > * How will the new protocol impact the behavior of other protocols > > > > in the network? Will it impact performance (e.g., > > > > jitter) of certain types of applications running in the same networ= k? > > > > > > > > I believe that at least a reference to these aspects need to be > > > > included, especially as the In-Service testing with injection of > > > > active traffic on production network is one of the methods > > > > discussed by > > > the document. > > > > > > > > The following reference to the effects of the high level traffic > > > > is not sufficient > > > > IMO: > > > > > > > > > > > > ? Section 5 of [RFC2680] lists the problems with high > > > > measurement traffic rates, and the most relevant for rate > > > > measurement > > > > > > > > ? is the tendency for measurement traffic to skew the results, fol= lowed > > > > by the possibility of introducing congestion on the access link.= In- > > > > Service testing MUST respect these traffic constraints. Obvious= ly, > > > > categories of rate measurement methods that use less active test > > > > traffic than others with similar accuracy are preferred for In- > > > > Service testing. > > > > > > > > Section 5 of RFC2680 does not provide too many details as I was > > > > expecting. It actually deals with traffic injection as with a secur= ity > concern: > > > > > > > > > > > > ? There are two types of security concerns: potential harm caused > > > > by > > > > > > > > ? the measurements, and potential harm to the measurements. The > > > > > > > > ? measurements could cause harm because they are active, and inje= ct > > > > > > > > ? packets into the network. The measurement parameters MUST be > > > > > > > > ? carefully selected so that the measurements inject trivial amou= nts of > > > > > > > > ? additional traffic into the networks they measure. If they inje= ct > > > > > > > > ? "too much" traffic, they can skew the results of the measuremen= t, > > and > > > > > > > > ? in extreme cases cause congestion and denial of service. > > > > > > > > ? > > > > 'trivial amounts of additional traffic' is too vague - I believe > > > > that more clear text that deals with the issue as with an > > > > operational issue, and makes clear that degradation of service for > > > > users is not acceptable if In-Service testing policies are applied > > > > would be > > welcome. > > > > > > > > I hope this helps. > > > > > > > > Regards, > > > > > > > > Dan From nobody Thu Dec 18 07:20:13 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82FB31A8BB7; Thu, 18 Dec 2014 07:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dgq5FemLa1Ka; Thu, 18 Dec 2014 07:20:02 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3521A8A93; Thu, 18 Dec 2014 07:20:02 -0800 (PST) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id 507741227D9; Thu, 18 Dec 2014 10:32:23 -0500 (EST) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.240.40]) by mail-green.research.att.com (Postfix) with ESMTP id AFB89E03B0; Thu, 18 Dec 2014 10:16:45 -0500 (EST) Received: from NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea]) by NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea%17]) with mapi; Thu, 18 Dec 2014 10:19:59 -0500 From: "MORTON, ALFRED C (AL)" To: "Romascanu, Dan (Dan)" , "ops-dir@ietf.org" , "ippm@ietf.org" Date: Thu, 18 Dec 2014 10:19:58 -0500 Thread-Topic: OPS-DIR review of draft-ietf-ippm-rate-problem-08 Thread-Index: AdAYe5l6zzPt7cY0Sz6o+JrRmzElOQAxhuiVACgMtpAABsHwBwACB4rAAC+P7poAAbFTYAAA3/rrAAE0nhAAAIMPkg== Message-ID: <4AF73AA205019A4C8A1DDD32C034631D8549390D@NJFPSRVEXG0.research.att.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C93075A@AZ-FFEXMB04.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493901@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93A18C@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493905@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93B6D0@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493907@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93CA1B@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493909@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93CB00@AZ-FFEXMB03.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C93CB00@AZ-FFEXMB03.global.avaya.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 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/Y5eXJiNow31tMkB952BU0cR2M4Q Cc: "draft-ietf-ippm-rate-problem.all@tools.ietf.org" Subject: Re: [ippm] OPS-DIR review of draft-ietf-ippm-rate-problem-08 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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, 18 Dec 2014 15:20:08 -0000 Hi Dan, you wrote: The goal of this text is exactly to make sure and explicit that operator= s engineer their management traffic load, including measurement-related traffic. The text does that now, adding new considerations. The audience of this sec= tion are the operators. We now know the issue, potential for degradation. Do we need further implem= entation guidance? I don't think so. If the root of your concern is the comparison between active and passive, t= hen you have many more factors to consider than traffic. One is "What happens to forwarding c= apacity when I turn on NetFlow?" That's a question we helped operators try to answer in BMWG's RFC 6645. http://tools.ietf.org/html/rfc6645 regards, Al ________________________________________ From: Romascanu, Dan (Dan) [dromasca@avaya.com] Sent: Thursday, December 18, 2014 10:00 AM To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 Hi Al, But this IS increased traffic, as standardized rate measurements were not i= n practice until now, hence the need for new standards, including the ones = in IPPM. Yes, it's management traffic, but the very issue an operational co= nsiderations sections aims is to draw the attention that people that design= an deploy new protocols need to factor in the overall effects of new proto= cols traffic on the networks. New protocols and methods to measure rate gen= erate new traffic, active measurement causes more new traffic than passive = methods, all this needs to be considered. The goal of this text is exactly = to make sure and explicit that operators engineer their management traffic = load, including measurement-related traffic. Regards, Dan > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Thursday, December 18, 2014 4:34 PM > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > Hi Dan, > > When you added the sentence: > It is desirable that the increase load in the traffic levels in the liv= e networks > caused by the active measurement protocols > and by the management of the active measurement protocols does not > lead to any significant degradation of the > quality of service of the applications running in the networks or the q= uality > of experience of the users of the applications. > > You have continued to assume that the measurement traffic is excess traff= ic > ("increased load") and it needs new requirements. As I said, one subscri= ber's > traffic can degrade the traffic of another subscriber, whether the > degradation is significant or not depends on too many factors to go into = here, > but one or both of the subscribers could be running tests related to this > problem statement. > Operators engineer their management traffic load, including measurement- > related traffic. > > There is simply traffic from many sources, all to be engineered. Operatio= ns > and Engineering as usual. > The section has provided specific cautions and guidance for operators and > users. No need for new implementation rules, IMO. > > regards, > Al > ________________________________________ > From: Romascanu, Dan (Dan) [dromasca@avaya.com] > Sent: Thursday, December 18, 2014 9:08 AM > To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > Hi Al, > > We are getting close. Your suggested text seems almost appropriate, with > two observations: > > - 'adequately served' is too vague and an explanation of what that means = is > needed > - I do not believe that we need a reference to RFC 3148. Again, the conce= rn is > not about the potential of security attacks (like DoS attacks mentioned i= n > 3148). The intent is to warn well intentioned operators, SPs and end user= s of > the potential dangers of not taking into consideration the effects of act= ive > methods, and recommend that they design and deploy accordingly > > Suggested edit to your proposal: > > OLD: > > 7. Operational Considerations > > All forms of testing originate traffic on the network, through their > communications for control and results collection, or from dedicated > measurement packet streams, or both. > Testing traffic primarily falls in one of two categories, subscriber traf= fic or > network management traffic. > There is an on-going need to engineer networks so that various forms of > traffic are adequately served, and publication of this memo does not chan= ge > this need. > Service subscribers and authorized users SHOULD obtain their network > operator's or service provider's permission before conducting tests. Like= wise, > a service provider or third party SHOULD obtain the subscriber's permissi= on > to conduct tests, since they might temporarily reduce service quality. > See section 4.1 of [RFC 3148]. > > Subscribers, their service providers and network operators, and sometimes > third parties, all seek to measure network performance. > Capacity testing with active traffic often affects the packet transfer > performance of streams traversing shared components of the test path, to > some degree. The degradation can be minimized by scheduling such tests > infrequently, and restricting the amount of measurement traffic required = to > assess capacity metrics. As a result, occasional short-duration estimates= are > preferred to measurements based on frequent file transfers of many > Megabytes. > New measurement methodologies intended for standardization should be > evaluated individually for potential operational issues. > However, the scheduled frequency of testing is as important as the method= s > used (and schedules are not typically submitted for standardization). > > NEW: > > 7. Operational Considerations > > All forms of testing originate traffic on the network, through their > communications for control and results collection, or from dedicated > measurement packet streams, or both. > Testing traffic primarily falls in one of two categories, subscriber traf= fic or > network management traffic. > There is an on-going need to engineer networks so that various forms of > traffic are adequately served, and publication of this memo does not chan= ge > this need . It is desirable that the increase load in the traffic levels = in the live > networks caused by the active measurement protocols and by the > management of the active measurement protocols does not lead to any > significant degradation of the quality of service of the applications run= ning in > the networks or the quality of experience of the users of the application= s. > Service subscribers and authorized users SHOULD obtain their network > operator's or service provider's permission before conducting tests. Like= wise, > a service provider or third party SHOULD obtain the subscriber's permissi= on > to conduct tests, since they might temporarily reduce service quality. > > Subscribers, their service providers and network operators, and sometimes > third parties, all seek to measure network performance. > Capacity testing with active traffic often affects the packet transfer > performance of streams traversing shared components of the test path, to > some degree. The degradation can be minimized by scheduling such tests > infrequently, and restricting the amount of measurement traffic required = to > assess capacity metrics. As a result, occasional short-duration estimates= are > preferred to measurements based on frequent file transfers of many > Megabytes. > New measurement methodologies intended for standardization should be > evaluated individually for potential operational issues. > However, the scheduled frequency of testing is as important as the method= s > used (and schedules are not typically submitted for standardization). > > Regards, > > Dan > > > > -----Original Message----- > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > Sent: Thursday, December 18, 2014 3:06 PM > > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > Hi Dan, > > > > I now see better where the disconnect is. You are looking for new > > explicit statements about operational impact. But you are assuming > > that the active measurement traffic is *excess* traffic, beyond some > > normal level resulting from all Subscriber traffic and an > > operator-chosen level of net management traffic. > > However, management traffic includes performance measurement traffic > > (when the traffic is originated by the operator), and Subscriber > > traffic includes active measurement traffic (when originated by the > > users). Test- related traffic needs to be engineered and limited along = with > all other traffic. > > > > Also, the requirement you wrote "does not lead to degradation" > > doesn't seem attainable, so we need to provide cautions through other > > means. Sending a single packet results in larger queue occupations all > > along its path =3D degradation. > > The packet could be for routing or other network management. > > > > The active measurement traffic is often launched by subscribers or > > their authorized users, and there may well be some degree of > > degradation to other subscriber's streams. > > Your proposed text recommends against this, yet it is no different > > from the degradation caused by a user who chooses to watch a video > > instead of testing (except that the video session may be longer). > > > > Further, Service providers may be temporarily replacing an idle user's > > traffic with active test traffic. Again there may be some degradation > > to other subscribers, but it would typically be no worse than from an > > additional user using their service. > > > > There is also the question of test frequency and overall performance: > > a user may experience instantaneous packet delay or loss while another > > subscriber tests their performance, but then the performance is at > > nominal levels for long periods between tests and the overall > > performance for a multi-hour session would be satisfactory. > > > > It is clear to me that the operational issues primarily addressed in > > previous IPPM work include the affects on other traffic, the accuracy > > of the measurements (including preferential treatment or spoofing of > > measured streams), and the real or perceived existence of DoS attacks. > > Although these are not identified as operations issues, they are > > certainly relevant in network operations where measurement has become > > a growing part of the management portfolio. > > So, we should continue to cite the existing IPPM (and BMWG) guidance > > on topics such as conservative measurement, and insert the references > > I provided earlier into Section 3 (where you cited the reference from > > RFC2680 > > - note the reference was to the sentence on high traffic rates, ("too > > much > > traffic") so the phrase "trivial amounts of additional traffic" may be > > an inadequate specification, but it was not the intended reference > material. > > > > This is the new section I propose: > > > > 7. Operational Considerations > > > > All forms of testing originate traffic on the network, through their > > communications for control and results collection, or from dedicated > > measurement packet streams, or both. > > Testing traffic primarily falls in one of two categories, subscriber > > traffic or network management traffic. > > There is an on-going need to engineer networks so that various forms > > of traffic are adequately served, and publication of this memo does > > not change this need. > > Service subscribers and authorized users SHOULD obtain their network > > operator's or service provider's permission before conducting tests. > > Likewise, a service provider or third party SHOULD obtain the > > subscriber's permission to conduct tests, since they might temporarily > reduce service quality. > > See section 4.1 of [RFC 3148]. > > > > Subscribers, their service providers and network operators, and > > sometimes third parties, all seek to measure network performance. > > Capacity testing with active traffic often affects the packet transfer > > performance of streams traversing shared components of the test path, > > to some degree. The degradation can be minimized by scheduling such > > tests infrequently, and restricting the amount of measurement traffic > > required to assess capacity metrics. As a result, occasional > > short-duration estimates are preferred to measurements based on > > frequent file transfers of many Megabytes. > > New measurement methodologies intended for standardization should be > > evaluated individually for potential operational issues. > > However, the scheduled frequency of testing is as important as the > > methods used (and schedules are not typically submitted for > standardization). > > > > > > ________________________________________ > > From: Romascanu, Dan (Dan) [dromasca@avaya.com] > > Sent: Wednesday, December 17, 2014 9:34 AM > > To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > Suggested edit: > > > > Insert section 7 after the Security considerations section with the > > following text, and renumber the other sections accordingly: > > > > 7. Operational Considerations > > > > The increase in traffic levels caused by applying any active > > measurement of live networks is a concern and needs to be considered > > and controlled any time active measurements are applied. It is > > RECOMMENDED that the increase load in the traffic levels in the live > > networks caused by the active measurement protocols and by the > > management of the active measurement protocols does not lead to a > > degradation of the quality of service of the applications running in > > the networks or the quality of experience of the users of the applicati= ons. > > > > Regards, > > > > Dan > > > > > > > -----Original Message----- > > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > > Sent: Wednesday, December 17, 2014 3:39 PM > > > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > Hi Dan, > > > > > > I did not say that the operational implications would not be dealt wi= th > here. > > > > > > I'm simply saying that IPPM drafts have done as you have asked many > > > times already, that is discuss the implications of active > > > measurements, and that we would not repeat that guidance (but > > > include four references below). Also, that the measurement methods > > > would each be vetted on their own, when proposed for standardization. > > > You need both methods and control/test protocol, and the method > > > solutions for this problem are out of scope. > > > > > > For example, the model-based metrics draft in IPPM introduces the > > > notion of a target rate, which is a good thing, because it means > > > that the test stream will have an upper bound. > > > But that is an operational evaluation of a specific method, and OOS > > > for the problem statement. > > > > > > Is this approach more clear? If not, please suggest some text. > > > > > > regards, > > > Al > > > ________________________________________ > > > From: Romascanu, Dan (Dan) [dromasca@avaya.com] > > > Sent: Wednesday, December 17, 2014 5:25 AM > > > To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > Hi Al, > > > > > > I kind of disagree that dealing with the operational implications of > > > applying active testing should not be mentioned in the problem > > > statement, but only when specific measurement methods are described. > > > The problem statement document explicitly describes active rate > > > management and includes a section of requirements for test protocol > > > control and generation. I believe that the operational aspects of > > > generating traffic in production networks should be part of the > > > problem statement, and explicitly mentioned, not only in the context > > > of > > altering measurement results or security considerations. > > > > > > Regards, > > > > > > Dan > > > > > > > > > > -----Original Message----- > > > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > > > Sent: Tuesday, December 16, 2014 5:05 PM > > > > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > > > Hi Dan, > > > > > > > > Thanks for your review. Perhaps we can close this quickly before > > > > we both disappear for the holidays (officially, I'm already gone > > > > and writing from Chicago, where it is unseasonably warm). > > > > > > > > We can certainly add details on the operational impact that test > > > > protocols conforming to this memo's problem statement might cause. > > > > This has been a point of issue since the earliest days of IPPM, so > > > > we should be able to cover the topic by introducing several referen= ces. > > > > > > > > If there is some additional point we can cover here, keeping in > > > > mind that measurement methods are a non-goal of this draft and the > > > > operational impact of specific methods are best dealt with when > > > > such methods are specified, please provide your thoughts. > > > > > > > > regards, > > > > Al > > > > > > > > The IPPM Framework RFC 2330, section 11.1, says > > > > > > > > + The act of measurement can perturb what is being measured > > > > + (for > > > > example, injecting measurement traffic into a network alters = the > > > > congestion level of the network), and repeated periodic > > > > perturbations can drive a network into a state of synchroniza= tion > > > > (cf. [FJ94]), greatly magnifying what might individually be m= inor > > > > effects. > > > > > > > > And also, RFC 2330 adopts the term "conservative" for measurement > > > > methodologies for which:, > > > > > > > > "... the act of measurement does not modify, or only slightly > > > > modifies, the value of the performance metric the methodology > > > > attempts to measure." > > > > > > > > However, the constraint that measurements strictly retain the > > > > conservative property is updated in RFC 7312 > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > > > 3A__tools.ietf.org_html_rfc7312-23section-2D4.4&d=3DAAIF- > > > > > > > > > > g&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd > > > > rphpBsFA&m=3DN8q- > > > > > > > > > > hc4HbRszDQlImZQ_Tenl1mVdgb9ss1bTj9HzKew&s=3DpGbP1qC4qqZh21gJkoiKs > > > > BmrE3lDnv8ulVOvmjOAlY0&e=3D > > > > > > > > It should be noted that this definition of "conservative" in the > > > > sense of [RFC2330] depends to a large extent on the measurement > > > > path's technology and characteristics. In particular, when depl= oyed > > > > on reactive paths, subpaths, links or hosts conforming to the > > > > definition in Section 1.1 of RFC 7312, measurement packets can > > > > originate capacity (re)allocations. In addition, small measurem= ent > > > > flow variations can result in other users on the same path perce= iving > > > > significant variations in measurement results. Therefore: > > > > > > > > It is not always possible for the method to be conservative. > > > > > > > > And, on modern networks with reactive components, any traffic > > > > level will have some impact on other users. Therefore, metrics > > > > and their measurement methods should be vetted by the industry > > > > SDOs. To make this point clear, we should cite BMWG RFC (2455 > > > > considered harmful on production networks), which covers the topic > > > > in Section 6 > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > > > > 3A__tools.ietf.org_html_rfc6815-23section-2D6&d=3DAAIF- > > > > > > > > > > g&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd > > > > rphpBsFA&m=3DN8q- > > > > > > > > > > hc4HbRszDQlImZQ_Tenl1mVdgb9ss1bTj9HzKew&s=3D5fEqW5JnBgSuJYNRNSJS > > > > mwfu04Mp6cQTBkG_aQNT6qU&e=3D > > > > and says: > > > > > > > > ...There are no specific methods proposed for > > > > activation of a packet transfer service in IPPM at this time. T= hus, > > > > individuals who need to conduct capacity tests on production > networks > > > > should actively participate in standards development to ensure t= heir > > > > methods receive appropriate industry review and agreement, in th= e > > > > IETF or in alternate standards development organizations. > > > > > > > > > > > > > > > > ________________________________________ > > > > From: OPS-DIR [ops-dir-bounces@ietf.org] On Behalf Of Romascanu, > > > > Dan > > > > (Dan) [dromasca@avaya.com] > > > > Sent: Monday, December 15, 2014 10:27 AM > > > > To: ops-dir@ietf.org; ippm@ietf.org > > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > > Subject: [OPS-DIR] OPS-DIR review of > > > > draft-ietf-ippm-rate-problem-08 > > > > > > > > I have reviewed this document as part of the Operational > > > > directorate's ongoing effort to review all IETF documents being > > > > processed > > by the IESG. > > > > These comments were written primarily for the benefit of the > > > > operational area directors. > > > > Document editors and WG chairs should treat these comments just > > > > like any other last call comments. > > > > > > > > Ready with one issue > > > > > > > > This I-D is an informational document that does not define a new > > > > protocol or protocol extensions. It does however contain a problem > > > > statement for test protocols conducting access rate measurement in > > > productions networks. > > > > These protocols can be OWAMP (RFC 4656) or TWAMP (RFC 5357) but > > also > > > > non-IETF protocols. The following operational considerations in > > > > Appendix A.1 of RFC 5706 apply, I believe, and do not receive > > > > appropriate answers in the > > > > document: > > > > > > > > 5. Has the impact on network operation been discussed? See Section > 2.5. > > > > * Will the new protocol significantly increase traffic load on > > > > existing networks? > > > > * Will the proposed management for the new protocol significantly > > > > increase traffic load on existing networks? > > > > * How will the new protocol impact the behavior of other protocols > > > > in the network? Will it impact performance (e.g., > > > > jitter) of certain types of applications running in the same networ= k? > > > > > > > > I believe that at least a reference to these aspects need to be > > > > included, especially as the In-Service testing with injection of > > > > active traffic on production network is one of the methods > > > > discussed by > > > the document. > > > > > > > > The following reference to the effects of the high level traffic > > > > is not sufficient > > > > IMO: > > > > > > > > > > > > ? Section 5 of [RFC2680] lists the problems with high > > > > measurement traffic rates, and the most relevant for rate > > > > measurement > > > > > > > > ? is the tendency for measurement traffic to skew the results, fol= lowed > > > > by the possibility of introducing congestion on the access link.= In- > > > > Service testing MUST respect these traffic constraints. Obvious= ly, > > > > categories of rate measurement methods that use less active test > > > > traffic than others with similar accuracy are preferred for In- > > > > Service testing. > > > > > > > > Section 5 of RFC2680 does not provide too many details as I was > > > > expecting. It actually deals with traffic injection as with a secur= ity > concern: > > > > > > > > > > > > ? There are two types of security concerns: potential harm caused > > > > by > > > > > > > > ? the measurements, and potential harm to the measurements. The > > > > > > > > ? measurements could cause harm because they are active, and inje= ct > > > > > > > > ? packets into the network. The measurement parameters MUST be > > > > > > > > ? carefully selected so that the measurements inject trivial amou= nts of > > > > > > > > ? additional traffic into the networks they measure. If they inje= ct > > > > > > > > ? "too much" traffic, they can skew the results of the measuremen= t, > > and > > > > > > > > ? in extreme cases cause congestion and denial of service. > > > > > > > > ? > > > > 'trivial amounts of additional traffic' is too vague - I believe > > > > that more clear text that deals with the issue as with an > > > > operational issue, and makes clear that degradation of service for > > > > users is not acceptable if In-Service testing policies are applied > > > > would be > > welcome. > > > > > > > > I hope this helps. > > > > > > > > Regards, > > > > > > > > Dan From nobody Thu Dec 18 07:31:56 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F401A1B42; Thu, 18 Dec 2014 07:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0kaYwE45DEL; Thu, 18 Dec 2014 07:31:48 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ADD41A8A15; Thu, 18 Dec 2014 07:31:47 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMGABHzklSHCzIm/2dsb2JhbABagmQiUlgEs1oBAQEBAQEGkjWFcgKBHRYBAQEBAQF8hAwBAQEBAxIIID8MBAIBCA0EBAEBAQoUCQcyFAkIAgQBCQQFCBMHiAoBDLQAoGYBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIYAhAqFBQsnMQcGgxCBEwWDe4oPgz6DPoMBgmGCJod2gzgig2xvAYECJB5+AQEB X-IronPort-AV: E=Sophos;i="5.07,601,1413259200"; d="scan'208";a="85159678" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 18 Dec 2014 10:31:27 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 18 Dec 2014 10:31:26 -0500 Received: from AZ-FFEXMB03.global.avaya.com ([fe80::d008:af0c:fa66:47e3]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Thu, 18 Dec 2014 10:31:25 -0500 From: "Romascanu, Dan (Dan)" To: "MORTON, ALFRED C (AL)" , "ops-dir@ietf.org" , "ippm@ietf.org" Thread-Topic: OPS-DIR review of draft-ietf-ippm-rate-problem-08 Thread-Index: AdAYe5l6zzPt7cY0Sz6o+JrRmzElOQAxhuiVACgMtpAABsHwBwACB4rAAC+P7poAAbFTYAAA3/rrAAE0nhAAAIMPkgAAsoIg Date: Thu, 18 Dec 2014 15:31:24 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C93CB97@AZ-FFEXMB03.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C93075A@AZ-FFEXMB04.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493901@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93A18C@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493905@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93B6D0@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493907@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93CA1B@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493909@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93CB00@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D8549390D@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D8549390D@NJFPSRVEXG0.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/gCaIvMKDux7JZhpp_LVMJMXjhEc Cc: "draft-ietf-ippm-rate-problem.all@tools.ietf.org" Subject: Re: [ippm] OPS-DIR review of draft-ietf-ippm-rate-problem-08 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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, 18 Dec 2014 15:31:53 -0000 Hi Al, I will not further insist on fine tuning the text this I-D, as I do not lik= e keeping one document 'hostage' even for such important issues, when we ca= me that close.=20 I believe that making the text more clear would have been useful, but we al= most walked the extra mile with the inclusion of the new section, and that'= s fine by now.=20 Regards, Dan > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Thursday, December 18, 2014 5:20 PM > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 >=20 > Hi Dan, >=20 > you wrote: > The goal of this text is exactly to make sure and explicit that operat= ors > engineer their management traffic load, > including measurement-related traffic. >=20 > The text does that now, adding new considerations. The audience of this > section are the operators. > We now know the issue, potential for degradation. Do we need further > implementation guidance? > I don't think so. >=20 > If the root of your concern is the comparison between active and passive, > then you have many more factors to consider than traffic. One is "What > happens to forwarding capacity when I turn on NetFlow?" > That's a question we helped operators try to answer in BMWG's RFC 6645. > https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > 3A__tools.ietf.org_html_rfc6645&d=3DAwIFAg&c=3DBFpWQw8bsuKpl1SgiZH64Q > &r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DgidqHsa1uFlRnPsB > pwAmd1-VWq9YWDrVjyT2xjxFAm8&s=3D0UDbON- > YV4jGVyt8H9aBb1kTlyJmt3bJSwfW-5FZwrM&e=3D >=20 > regards, > Al >=20 > ________________________________________ > From: Romascanu, Dan (Dan) [dromasca@avaya.com] > Sent: Thursday, December 18, 2014 10:00 AM > To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 >=20 > Hi Al, >=20 > But this IS increased traffic, as standardized rate measurements were not= in > practice until now, hence the need for new standards, including the ones = in > IPPM. Yes, it's management traffic, but the very issue an operational > considerations sections aims is to draw the attention that people that de= sign > an deploy new protocols need to factor in the overall effects of new > protocols traffic on the networks. New protocols and methods to measure > rate generate new traffic, active measurement causes more new traffic tha= n > passive methods, all this needs to be considered. The goal of this text i= s > exactly to make sure and explicit that operators engineer their managemen= t > traffic load, including measurement-related traffic. >=20 > Regards, >=20 > Dan >=20 >=20 > > -----Original Message----- > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > Sent: Thursday, December 18, 2014 4:34 PM > > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > Hi Dan, > > > > When you added the sentence: > > It is desirable that the increase load in the traffic levels in the > > live networks caused by the active measurement protocols > > and by the management of the active measurement protocols does not > > lead to any significant degradation of the > > quality of service of the applications running in the networks or > > the quality of experience of the users of the applications. > > > > You have continued to assume that the measurement traffic is excess > > traffic ("increased load") and it needs new requirements. As I said, > > one subscriber's traffic can degrade the traffic of another > > subscriber, whether the degradation is significant or not depends on > > too many factors to go into here, but one or both of the subscribers > > could be running tests related to this problem statement. > > Operators engineer their management traffic load, including > > measurement- related traffic. > > > > There is simply traffic from many sources, all to be engineered. > > Operations and Engineering as usual. > > The section has provided specific cautions and guidance for operators > > and users. No need for new implementation rules, IMO. > > > > regards, > > Al > > ________________________________________ > > From: Romascanu, Dan (Dan) [dromasca@avaya.com] > > Sent: Thursday, December 18, 2014 9:08 AM > > To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > Hi Al, > > > > We are getting close. Your suggested text seems almost appropriate, > > with two observations: > > > > - 'adequately served' is too vague and an explanation of what that > > means is needed > > - I do not believe that we need a reference to RFC 3148. Again, the > > concern is not about the potential of security attacks (like DoS > > attacks mentioned in 3148). The intent is to warn well intentioned > > operators, SPs and end users of the potential dangers of not taking > > into consideration the effects of active methods, and recommend that > > they design and deploy accordingly > > > > Suggested edit to your proposal: > > > > OLD: > > > > 7. Operational Considerations > > > > All forms of testing originate traffic on the network, through their > > communications for control and results collection, or from dedicated > > measurement packet streams, or both. > > Testing traffic primarily falls in one of two categories, subscriber > > traffic or network management traffic. > > There is an on-going need to engineer networks so that various forms > > of traffic are adequately served, and publication of this memo does > > not change this need. > > Service subscribers and authorized users SHOULD obtain their network > > operator's or service provider's permission before conducting tests. > > Likewise, a service provider or third party SHOULD obtain the > > subscriber's permission to conduct tests, since they might temporarily > reduce service quality. > > See section 4.1 of [RFC 3148]. > > > > Subscribers, their service providers and network operators, and > > sometimes third parties, all seek to measure network performance. > > Capacity testing with active traffic often affects the packet transfer > > performance of streams traversing shared components of the test path, > > to some degree. The degradation can be minimized by scheduling such > > tests infrequently, and restricting the amount of measurement traffic > > required to assess capacity metrics. As a result, occasional > > short-duration estimates are preferred to measurements based on > > frequent file transfers of many Megabytes. > > New measurement methodologies intended for standardization should be > > evaluated individually for potential operational issues. > > However, the scheduled frequency of testing is as important as the > > methods used (and schedules are not typically submitted for > standardization). > > > > NEW: > > > > 7. Operational Considerations > > > > All forms of testing originate traffic on the network, through their > > communications for control and results collection, or from dedicated > > measurement packet streams, or both. > > Testing traffic primarily falls in one of two categories, subscriber > > traffic or network management traffic. > > There is an on-going need to engineer networks so that various forms > > of traffic are adequately served, and publication of this memo does > > not change this need . It is desirable that the increase load in the > > traffic levels in the live networks caused by the active measurement > > protocols and by the management of the active measurement protocols > > does not lead to any significant degradation of the quality of service > > of the applications running in the networks or the quality of experienc= e of > the users of the applications. > > Service subscribers and authorized users SHOULD obtain their network > > operator's or service provider's permission before conducting tests. > > Likewise, a service provider or third party SHOULD obtain the > > subscriber's permission to conduct tests, since they might temporarily > reduce service quality. > > > > Subscribers, their service providers and network operators, and > > sometimes third parties, all seek to measure network performance. > > Capacity testing with active traffic often affects the packet transfer > > performance of streams traversing shared components of the test path, > > to some degree. The degradation can be minimized by scheduling such > > tests infrequently, and restricting the amount of measurement traffic > > required to assess capacity metrics. As a result, occasional > > short-duration estimates are preferred to measurements based on > > frequent file transfers of many Megabytes. > > New measurement methodologies intended for standardization should be > > evaluated individually for potential operational issues. > > However, the scheduled frequency of testing is as important as the > > methods used (and schedules are not typically submitted for > standardization). > > > > Regards, > > > > Dan > > > > > > > -----Original Message----- > > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > > Sent: Thursday, December 18, 2014 3:06 PM > > > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > > > > Hi Dan, > > > > > > I now see better where the disconnect is. You are looking for new > > > explicit statements about operational impact. But you are assuming > > > that the active measurement traffic is *excess* traffic, beyond some > > > normal level resulting from all Subscriber traffic and an > > > operator-chosen level of net management traffic. > > > However, management traffic includes performance measurement > traffic > > > (when the traffic is originated by the operator), and Subscriber > > > traffic includes active measurement traffic (when originated by the > > > users). Test- related traffic needs to be engineered and limited > > > along with > > all other traffic. > > > > > > Also, the requirement you wrote "does not lead to degradation" > > > doesn't seem attainable, so we need to provide cautions through > > > other means. Sending a single packet results in larger queue > > > occupations all along its path =3D degradation. > > > The packet could be for routing or other network management. > > > > > > The active measurement traffic is often launched by subscribers or > > > their authorized users, and there may well be some degree of > > > degradation to other subscriber's streams. > > > Your proposed text recommends against this, yet it is no different > > > from the degradation caused by a user who chooses to watch a video > > > instead of testing (except that the video session may be longer). > > > > > > Further, Service providers may be temporarily replacing an idle > > > user's traffic with active test traffic. Again there may be some > > > degradation to other subscribers, but it would typically be no worse > > > than from an additional user using their service. > > > > > > There is also the question of test frequency and overall performance: > > > a user may experience instantaneous packet delay or loss while > > > another subscriber tests their performance, but then the performance > > > is at nominal levels for long periods between tests and the overall > > > performance for a multi-hour session would be satisfactory. > > > > > > It is clear to me that the operational issues primarily addressed in > > > previous IPPM work include the affects on other traffic, the > > > accuracy of the measurements (including preferential treatment or > > > spoofing of measured streams), and the real or perceived existence of > DoS attacks. > > > Although these are not identified as operations issues, they are > > > certainly relevant in network operations where measurement has > > > become a growing part of the management portfolio. > > > So, we should continue to cite the existing IPPM (and BMWG) guidance > > > on topics such as conservative measurement, and insert the > > > references I provided earlier into Section 3 (where you cited the > > > reference from > > > RFC2680 > > > - note the reference was to the sentence on high traffic rates, > > > ("too much > > > traffic") so the phrase "trivial amounts of additional traffic" may > > > be an inadequate specification, but it was not the intended > > > reference > > material. > > > > > > This is the new section I propose: > > > > > > 7. Operational Considerations > > > > > > All forms of testing originate traffic on the network, through their > > > communications for control and results collection, or from dedicated > > > measurement packet streams, or both. > > > Testing traffic primarily falls in one of two categories, subscriber > > > traffic or network management traffic. > > > There is an on-going need to engineer networks so that various forms > > > of traffic are adequately served, and publication of this memo does > > > not change this need. > > > Service subscribers and authorized users SHOULD obtain their network > > > operator's or service provider's permission before conducting tests. > > > Likewise, a service provider or third party SHOULD obtain the > > > subscriber's permission to conduct tests, since they might > > > temporarily > > reduce service quality. > > > See section 4.1 of [RFC 3148]. > > > > > > Subscribers, their service providers and network operators, and > > > sometimes third parties, all seek to measure network performance. > > > Capacity testing with active traffic often affects the packet > > > transfer performance of streams traversing shared components of the > > > test path, to some degree. The degradation can be minimized by > > > scheduling such tests infrequently, and restricting the amount of > > > measurement traffic required to assess capacity metrics. As a > > > result, occasional short-duration estimates are preferred to > > > measurements based on frequent file transfers of many Megabytes. > > > New measurement methodologies intended for standardization should > be > > > evaluated individually for potential operational issues. > > > However, the scheduled frequency of testing is as important as the > > > methods used (and schedules are not typically submitted for > > standardization). > > > > > > > > > ________________________________________ > > > From: Romascanu, Dan (Dan) [dromasca@avaya.com] > > > Sent: Wednesday, December 17, 2014 9:34 AM > > > To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > Suggested edit: > > > > > > Insert section 7 after the Security considerations section with the > > > following text, and renumber the other sections accordingly: > > > > > > 7. Operational Considerations > > > > > > The increase in traffic levels caused by applying any active > > > measurement of live networks is a concern and needs to be considered > > > and controlled any time active measurements are applied. It is > > > RECOMMENDED that the increase load in the traffic levels in the live > > > networks caused by the active measurement protocols and by the > > > management of the active measurement protocols does not lead to a > > > degradation of the quality of service of the applications running in > > > the networks or the quality of experience of the users of the > applications. > > > > > > Regards, > > > > > > Dan > > > > > > > > > > -----Original Message----- > > > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > > > Sent: Wednesday, December 17, 2014 3:39 PM > > > > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > > > Hi Dan, > > > > > > > > I did not say that the operational implications would not be dealt > > > > with > > here. > > > > > > > > I'm simply saying that IPPM drafts have done as you have asked > > > > many times already, that is discuss the implications of active > > > > measurements, and that we would not repeat that guidance (but > > > > include four references below). Also, that the measurement > > > > methods would each be vetted on their own, when proposed for > standardization. > > > > You need both methods and control/test protocol, and the method > > > > solutions for this problem are out of scope. > > > > > > > > For example, the model-based metrics draft in IPPM introduces the > > > > notion of a target rate, which is a good thing, because it means > > > > that the test stream will have an upper bound. > > > > But that is an operational evaluation of a specific method, and > > > > OOS for the problem statement. > > > > > > > > Is this approach more clear? If not, please suggest some text. > > > > > > > > regards, > > > > Al > > > > ________________________________________ > > > > From: Romascanu, Dan (Dan) [dromasca@avaya.com] > > > > Sent: Wednesday, December 17, 2014 5:25 AM > > > > To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org > > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > > > Hi Al, > > > > > > > > I kind of disagree that dealing with the operational implications > > > > of applying active testing should not be mentioned in the problem > > > > statement, but only when specific measurement methods are > described. > > > > The problem statement document explicitly describes active rate > > > > management and includes a section of requirements for test > > > > protocol control and generation. I believe that the operational > > > > aspects of generating traffic in production networks should be > > > > part of the problem statement, and explicitly mentioned, not only > > > > in the context of > > > altering measurement results or security considerations. > > > > > > > > Regards, > > > > > > > > Dan > > > > > > > > > > > > > -----Original Message----- > > > > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > > > > Sent: Tuesday, December 16, 2014 5:05 PM > > > > > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > > > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > > > > > Hi Dan, > > > > > > > > > > Thanks for your review. Perhaps we can close this quickly before > > > > > we both disappear for the holidays (officially, I'm already gone > > > > > and writing from Chicago, where it is unseasonably warm). > > > > > > > > > > We can certainly add details on the operational impact that test > > > > > protocols conforming to this memo's problem statement might cause= . > > > > > This has been a point of issue since the earliest days of IPPM, > > > > > so we should be able to cover the topic by introducing several > references. > > > > > > > > > > If there is some additional point we can cover here, keeping in > > > > > mind that measurement methods are a non-goal of this draft and > > > > > the operational impact of specific methods are best dealt with > > > > > when such methods are specified, please provide your thoughts. > > > > > > > > > > regards, > > > > > Al > > > > > > > > > > The IPPM Framework RFC 2330, section 11.1, says > > > > > > > > > > + The act of measurement can perturb what is being measured > > > > > + (for > > > > > example, injecting measurement traffic into a network alter= s the > > > > > congestion level of the network), and repeated periodic > > > > > perturbations can drive a network into a state of synchroni= zation > > > > > (cf. [FJ94]), greatly magnifying what might individually be= minor > > > > > effects. > > > > > > > > > > And also, RFC 2330 adopts the term "conservative" for measurement > > > > > methodologies for which:, > > > > > > > > > > "... the act of measurement does not modify, or only slightly > > > > > modifies, the value of the performance metric the methodology > > > > > attempts to measure." > > > > > > > > > > However, the constraint that measurements strictly retain the > > > > > conservative property is updated in RFC 7312 > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > > > > 3A__tools.ietf.org_html_rfc7312-23section-2D4.4&d=3DAAIF- > > > > > > > > > > > > > > > g&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd > > > > > rphpBsFA&m=3DN8q- > > > > > > > > > > > > > > > hc4HbRszDQlImZQ_Tenl1mVdgb9ss1bTj9HzKew&s=3DpGbP1qC4qqZh21gJkoiKs > > > > > BmrE3lDnv8ulVOvmjOAlY0&e=3D > > > > > > > > > > It should be noted that this definition of "conservative" in t= he > > > > > sense of [RFC2330] depends to a large extent on the measuremen= t > > > > > path's technology and characteristics. In particular, when de= ployed > > > > > on reactive paths, subpaths, links or hosts conforming to the > > > > > definition in Section 1.1 of RFC 7312, measurement packets can > > > > > originate capacity (re)allocations. In addition, small measur= ement > > > > > flow variations can result in other users on the same path per= ceiving > > > > > significant variations in measurement results. Therefore: > > > > > > > > > > It is not always possible for the method to be conservative= . > > > > > > > > > > And, on modern networks with reactive components, any traffic > > > > > level will have some impact on other users. Therefore, metrics > > > > > and their measurement methods should be vetted by the industry > > > > > SDOs. To make this point clear, we should cite BMWG RFC (2455 > > > > > considered harmful on production networks), which covers the > > > > > topic in Section 6 > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > > > > > 3A__tools.ietf.org_html_rfc6815-23section-2D6&d=3DAAIF- > > > > > > > > > > > > > > > g&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd > > > > > rphpBsFA&m=3DN8q- > > > > > > > > > > > > > > > hc4HbRszDQlImZQ_Tenl1mVdgb9ss1bTj9HzKew&s=3D5fEqW5JnBgSuJYNRNSJS > > > > > mwfu04Mp6cQTBkG_aQNT6qU&e=3D > > > > > and says: > > > > > > > > > > ...There are no specific methods proposed for > > > > > activation of a packet transfer service in IPPM at this time. = Thus, > > > > > individuals who need to conduct capacity tests on production > > networks > > > > > should actively participate in standards development to ensure= their > > > > > methods receive appropriate industry review and agreement, in = the > > > > > IETF or in alternate standards development organizations. > > > > > > > > > > > > > > > > > > > > ________________________________________ > > > > > From: OPS-DIR [ops-dir-bounces@ietf.org] On Behalf Of Romascanu, > > > > > Dan > > > > > (Dan) [dromasca@avaya.com] > > > > > Sent: Monday, December 15, 2014 10:27 AM > > > > > To: ops-dir@ietf.org; ippm@ietf.org > > > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > > > Subject: [OPS-DIR] OPS-DIR review of > > > > > draft-ietf-ippm-rate-problem-08 > > > > > > > > > > I have reviewed this document as part of the Operational > > > > > directorate's ongoing effort to review all IETF documents being > > > > > processed > > > by the IESG. > > > > > These comments were written primarily for the benefit of the > > > > > operational area directors. > > > > > Document editors and WG chairs should treat these comments just > > > > > like any other last call comments. > > > > > > > > > > Ready with one issue > > > > > > > > > > This I-D is an informational document that does not define a new > > > > > protocol or protocol extensions. It does however contain a > > > > > problem statement for test protocols conducting access rate > > > > > measurement in > > > > productions networks. > > > > > These protocols can be OWAMP (RFC 4656) or TWAMP (RFC 5357) but > > > also > > > > > non-IETF protocols. The following operational considerations in > > > > > Appendix A.1 of RFC 5706 apply, I believe, and do not receive > > > > > appropriate answers in the > > > > > document: > > > > > > > > > > 5. Has the impact on network operation been discussed? See > > > > > Section > > 2.5. > > > > > * Will the new protocol significantly increase traffic load on > > > > > existing networks? > > > > > * Will the proposed management for the new protocol > > > > > significantly increase traffic load on existing networks? > > > > > * How will the new protocol impact the behavior of other > > > > > protocols in the network? Will it impact performance (e.g., > > > > > jitter) of certain types of applications running in the same netw= ork? > > > > > > > > > > I believe that at least a reference to these aspects need to be > > > > > included, especially as the In-Service testing with injection of > > > > > active traffic on production network is one of the methods > > > > > discussed by > > > > the document. > > > > > > > > > > The following reference to the effects of the high level traffic > > > > > is not sufficient > > > > > IMO: > > > > > > > > > > > > > > > ? Section 5 of [RFC2680] lists the problems with high > > > > > measurement traffic rates, and the most relevant for rate > > > > > measurement > > > > > > > > > > ? is the tendency for measurement traffic to skew the results, > followed > > > > > by the possibility of introducing congestion on the access lin= k. In- > > > > > Service testing MUST respect these traffic constraints. Obvio= usly, > > > > > categories of rate measurement methods that use less active te= st > > > > > traffic than others with similar accuracy are preferred for In= - > > > > > Service testing. > > > > > > > > > > Section 5 of RFC2680 does not provide too many details as I was > > > > > expecting. It actually deals with traffic injection as with a > > > > > security > > concern: > > > > > > > > > > > > > > > ? There are two types of security concerns: potential harm > > > > > caused by > > > > > > > > > > ? the measurements, and potential harm to the measurements. The > > > > > > > > > > ? measurements could cause harm because they are active, and > inject > > > > > > > > > > ? packets into the network. The measurement parameters MUST be > > > > > > > > > > ? carefully selected so that the measurements inject trivial am= ounts > of > > > > > > > > > > ? additional traffic into the networks they measure. If they in= ject > > > > > > > > > > ? "too much" traffic, they can skew the results of the measurem= ent, > > > and > > > > > > > > > > ? in extreme cases cause congestion and denial of service. > > > > > > > > > > ? > > > > > 'trivial amounts of additional traffic' is too vague - I believe > > > > > that more clear text that deals with the issue as with an > > > > > operational issue, and makes clear that degradation of service > > > > > for users is not acceptable if In-Service testing policies are > > > > > applied would be > > > welcome. > > > > > > > > > > I hope this helps. > > > > > > > > > > Regards, > > > > > > > > > > Dan From nobody Thu Dec 18 07:44:58 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6E61A9098; Thu, 18 Dec 2014 07:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7bZAc_PGaYt; Thu, 18 Dec 2014 07:44:50 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF101A8A83; Thu, 18 Dec 2014 07:44:49 -0800 (PST) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id ED69A1228A6; Thu, 18 Dec 2014 10:57:09 -0500 (EST) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.240.40]) by mail-green.research.att.com (Postfix) with ESMTP id 48AFEE03B0; Thu, 18 Dec 2014 10:41:32 -0500 (EST) Received: from NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea]) by NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea%17]) with mapi; Thu, 18 Dec 2014 10:44:45 -0500 From: "MORTON, ALFRED C (AL)" To: "Romascanu, Dan (Dan)" , "ops-dir@ietf.org" , "ippm@ietf.org" Date: Thu, 18 Dec 2014 10:40:55 -0500 Thread-Topic: OPS-DIR review of draft-ietf-ippm-rate-problem-08 Thread-Index: AdAYe5l6zzPt7cY0Sz6o+JrRmzElOQAxhuiVACgMtpAABsHwBwACB4rAAC+P7poAAbFTYAAA3/rrAAE0nhAAAIMPkgAAsoIgAABx66s= Message-ID: <4AF73AA205019A4C8A1DDD32C034631D85493911@NJFPSRVEXG0.research.att.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C93075A@AZ-FFEXMB04.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493901@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93A18C@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493905@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93B6D0@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493907@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93CA1B@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493909@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93CB00@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D8549390D@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93CB97@AZ-FFEXMB03.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C93CB97@AZ-FFEXMB03.global.avaya.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 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/fl_4EPNCGN0wBGvtzTpz0DuHtFQ Cc: "draft-ietf-ippm-rate-problem.all@tools.ietf.org" Subject: Re: [ippm] OPS-DIR review of draft-ietf-ippm-rate-problem-08 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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, 18 Dec 2014 15:44:55 -0000 Hi Dan, Thanks for your compromise. On the topic of "increased" traffic: This document introduces a RECOMMENDATION for test protocols to add the capability generate asymmetrical packet sizes in different direc= tions, something that the current protocols cannot do (but they can certainly be used to make rate measurements now). In fact, this asymmetric size feature REDUCES the test traffic load. Perhaps you would like this mentioned as a desirable feature from an operations perspective? regards, Al ________________________________________ From: Romascanu, Dan (Dan) [dromasca@avaya.com] Sent: Thursday, December 18, 2014 10:31 AM To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 Hi Al, I will not further insist on fine tuning the text this I-D, as I do not lik= e keeping one document 'hostage' even for such important issues, when we ca= me that close. I believe that making the text more clear would have been useful, but we al= most walked the extra mile with the inclusion of the new section, and that'= s fine by now. Regards, Dan > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Thursday, December 18, 2014 5:20 PM > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > Hi Dan, > > you wrote: > The goal of this text is exactly to make sure and explicit that operat= ors > engineer their management traffic load, > including measurement-related traffic. > > The text does that now, adding new considerations. The audience of this > section are the operators. > We now know the issue, potential for degradation. Do we need further > implementation guidance? > I don't think so. > > If the root of your concern is the comparison between active and passive, > then you have many more factors to consider than traffic. One is "What > happens to forwarding capacity when I turn on NetFlow?" > That's a question we helped operators try to answer in BMWG's RFC 6645. > https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > 3A__tools.ietf.org_html_rfc6645&d=3DAwIFAg&c=3DBFpWQw8bsuKpl1SgiZH64Q > &r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DgidqHsa1uFlRnPsB > pwAmd1-VWq9YWDrVjyT2xjxFAm8&s=3D0UDbON- > YV4jGVyt8H9aBb1kTlyJmt3bJSwfW-5FZwrM&e=3D > > regards, > Al > > ________________________________________ > From: Romascanu, Dan (Dan) [dromasca@avaya.com] > Sent: Thursday, December 18, 2014 10:00 AM > To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > Hi Al, > > But this IS increased traffic, as standardized rate measurements were not= in > practice until now, hence the need for new standards, including the ones = in > IPPM. Yes, it's management traffic, but the very issue an operational > considerations sections aims is to draw the attention that people that de= sign > an deploy new protocols need to factor in the overall effects of new > protocols traffic on the networks. New protocols and methods to measure > rate generate new traffic, active measurement causes more new traffic tha= n > passive methods, all this needs to be considered. The goal of this text i= s > exactly to make sure and explicit that operators engineer their managemen= t > traffic load, including measurement-related traffic. > > Regards, > > Dan > > > > -----Original Message----- > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > Sent: Thursday, December 18, 2014 4:34 PM > > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > Hi Dan, > > > > When you added the sentence: > > It is desirable that the increase load in the traffic levels in the > > live networks caused by the active measurement protocols > > and by the management of the active measurement protocols does not > > lead to any significant degradation of the > > quality of service of the applications running in the networks or > > the quality of experience of the users of the applications. > > > > You have continued to assume that the measurement traffic is excess > > traffic ("increased load") and it needs new requirements. As I said, > > one subscriber's traffic can degrade the traffic of another > > subscriber, whether the degradation is significant or not depends on > > too many factors to go into here, but one or both of the subscribers > > could be running tests related to this problem statement. > > Operators engineer their management traffic load, including > > measurement- related traffic. > > > > There is simply traffic from many sources, all to be engineered. > > Operations and Engineering as usual. > > The section has provided specific cautions and guidance for operators > > and users. No need for new implementation rules, IMO. > > > > regards, > > Al > > ________________________________________ > > From: Romascanu, Dan (Dan) [dromasca@avaya.com] > > Sent: Thursday, December 18, 2014 9:08 AM > > To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > Hi Al, > > > > We are getting close. Your suggested text seems almost appropriate, > > with two observations: > > > > - 'adequately served' is too vague and an explanation of what that > > means is needed > > - I do not believe that we need a reference to RFC 3148. Again, the > > concern is not about the potential of security attacks (like DoS > > attacks mentioned in 3148). The intent is to warn well intentioned > > operators, SPs and end users of the potential dangers of not taking > > into consideration the effects of active methods, and recommend that > > they design and deploy accordingly > > > > Suggested edit to your proposal: > > > > OLD: > > > > 7. Operational Considerations > > > > All forms of testing originate traffic on the network, through their > > communications for control and results collection, or from dedicated > > measurement packet streams, or both. > > Testing traffic primarily falls in one of two categories, subscriber > > traffic or network management traffic. > > There is an on-going need to engineer networks so that various forms > > of traffic are adequately served, and publication of this memo does > > not change this need. > > Service subscribers and authorized users SHOULD obtain their network > > operator's or service provider's permission before conducting tests. > > Likewise, a service provider or third party SHOULD obtain the > > subscriber's permission to conduct tests, since they might temporarily > reduce service quality. > > See section 4.1 of [RFC 3148]. > > > > Subscribers, their service providers and network operators, and > > sometimes third parties, all seek to measure network performance. > > Capacity testing with active traffic often affects the packet transfer > > performance of streams traversing shared components of the test path, > > to some degree. The degradation can be minimized by scheduling such > > tests infrequently, and restricting the amount of measurement traffic > > required to assess capacity metrics. As a result, occasional > > short-duration estimates are preferred to measurements based on > > frequent file transfers of many Megabytes. > > New measurement methodologies intended for standardization should be > > evaluated individually for potential operational issues. > > However, the scheduled frequency of testing is as important as the > > methods used (and schedules are not typically submitted for > standardization). > > > > NEW: > > > > 7. Operational Considerations > > > > All forms of testing originate traffic on the network, through their > > communications for control and results collection, or from dedicated > > measurement packet streams, or both. > > Testing traffic primarily falls in one of two categories, subscriber > > traffic or network management traffic. > > There is an on-going need to engineer networks so that various forms > > of traffic are adequately served, and publication of this memo does > > not change this need . It is desirable that the increase load in the > > traffic levels in the live networks caused by the active measurement > > protocols and by the management of the active measurement protocols > > does not lead to any significant degradation of the quality of service > > of the applications running in the networks or the quality of experienc= e of > the users of the applications. > > Service subscribers and authorized users SHOULD obtain their network > > operator's or service provider's permission before conducting tests. > > Likewise, a service provider or third party SHOULD obtain the > > subscriber's permission to conduct tests, since they might temporarily > reduce service quality. > > > > Subscribers, their service providers and network operators, and > > sometimes third parties, all seek to measure network performance. > > Capacity testing with active traffic often affects the packet transfer > > performance of streams traversing shared components of the test path, > > to some degree. The degradation can be minimized by scheduling such > > tests infrequently, and restricting the amount of measurement traffic > > required to assess capacity metrics. As a result, occasional > > short-duration estimates are preferred to measurements based on > > frequent file transfers of many Megabytes. > > New measurement methodologies intended for standardization should be > > evaluated individually for potential operational issues. > > However, the scheduled frequency of testing is as important as the > > methods used (and schedules are not typically submitted for > standardization). > > > > Regards, > > > > Dan > > > > > > > -----Original Message----- > > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > > Sent: Thursday, December 18, 2014 3:06 PM > > > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > > > > Hi Dan, > > > > > > I now see better where the disconnect is. You are looking for new > > > explicit statements about operational impact. But you are assuming > > > that the active measurement traffic is *excess* traffic, beyond some > > > normal level resulting from all Subscriber traffic and an > > > operator-chosen level of net management traffic. > > > However, management traffic includes performance measurement > traffic > > > (when the traffic is originated by the operator), and Subscriber > > > traffic includes active measurement traffic (when originated by the > > > users). Test- related traffic needs to be engineered and limited > > > along with > > all other traffic. > > > > > > Also, the requirement you wrote "does not lead to degradation" > > > doesn't seem attainable, so we need to provide cautions through > > > other means. Sending a single packet results in larger queue > > > occupations all along its path =3D degradation. > > > The packet could be for routing or other network management. > > > > > > The active measurement traffic is often launched by subscribers or > > > their authorized users, and there may well be some degree of > > > degradation to other subscriber's streams. > > > Your proposed text recommends against this, yet it is no different > > > from the degradation caused by a user who chooses to watch a video > > > instead of testing (except that the video session may be longer). > > > > > > Further, Service providers may be temporarily replacing an idle > > > user's traffic with active test traffic. Again there may be some > > > degradation to other subscribers, but it would typically be no worse > > > than from an additional user using their service. > > > > > > There is also the question of test frequency and overall performance: > > > a user may experience instantaneous packet delay or loss while > > > another subscriber tests their performance, but then the performance > > > is at nominal levels for long periods between tests and the overall > > > performance for a multi-hour session would be satisfactory. > > > > > > It is clear to me that the operational issues primarily addressed in > > > previous IPPM work include the affects on other traffic, the > > > accuracy of the measurements (including preferential treatment or > > > spoofing of measured streams), and the real or perceived existence of > DoS attacks. > > > Although these are not identified as operations issues, they are > > > certainly relevant in network operations where measurement has > > > become a growing part of the management portfolio. > > > So, we should continue to cite the existing IPPM (and BMWG) guidance > > > on topics such as conservative measurement, and insert the > > > references I provided earlier into Section 3 (where you cited the > > > reference from > > > RFC2680 > > > - note the reference was to the sentence on high traffic rates, > > > ("too much > > > traffic") so the phrase "trivial amounts of additional traffic" may > > > be an inadequate specification, but it was not the intended > > > reference > > material. > > > > > > This is the new section I propose: > > > > > > 7. Operational Considerations > > > > > > All forms of testing originate traffic on the network, through their > > > communications for control and results collection, or from dedicated > > > measurement packet streams, or both. > > > Testing traffic primarily falls in one of two categories, subscriber > > > traffic or network management traffic. > > > There is an on-going need to engineer networks so that various forms > > > of traffic are adequately served, and publication of this memo does > > > not change this need. > > > Service subscribers and authorized users SHOULD obtain their network > > > operator's or service provider's permission before conducting tests. > > > Likewise, a service provider or third party SHOULD obtain the > > > subscriber's permission to conduct tests, since they might > > > temporarily > > reduce service quality. > > > See section 4.1 of [RFC 3148]. > > > > > > Subscribers, their service providers and network operators, and > > > sometimes third parties, all seek to measure network performance. > > > Capacity testing with active traffic often affects the packet > > > transfer performance of streams traversing shared components of the > > > test path, to some degree. The degradation can be minimized by > > > scheduling such tests infrequently, and restricting the amount of > > > measurement traffic required to assess capacity metrics. As a > > > result, occasional short-duration estimates are preferred to > > > measurements based on frequent file transfers of many Megabytes. > > > New measurement methodologies intended for standardization should > be > > > evaluated individually for potential operational issues. > > > However, the scheduled frequency of testing is as important as the > > > methods used (and schedules are not typically submitted for > > standardization). > > > > > > > > > ________________________________________ > > > From: Romascanu, Dan (Dan) [dromasca@avaya.com] > > > Sent: Wednesday, December 17, 2014 9:34 AM > > > To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > Suggested edit: > > > > > > Insert section 7 after the Security considerations section with the > > > following text, and renumber the other sections accordingly: > > > > > > 7. Operational Considerations > > > > > > The increase in traffic levels caused by applying any active > > > measurement of live networks is a concern and needs to be considered > > > and controlled any time active measurements are applied. It is > > > RECOMMENDED that the increase load in the traffic levels in the live > > > networks caused by the active measurement protocols and by the > > > management of the active measurement protocols does not lead to a > > > degradation of the quality of service of the applications running in > > > the networks or the quality of experience of the users of the > applications. > > > > > > Regards, > > > > > > Dan > > > > > > > > > > -----Original Message----- > > > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > > > Sent: Wednesday, December 17, 2014 3:39 PM > > > > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > > > Hi Dan, > > > > > > > > I did not say that the operational implications would not be dealt > > > > with > > here. > > > > > > > > I'm simply saying that IPPM drafts have done as you have asked > > > > many times already, that is discuss the implications of active > > > > measurements, and that we would not repeat that guidance (but > > > > include four references below). Also, that the measurement > > > > methods would each be vetted on their own, when proposed for > standardization. > > > > You need both methods and control/test protocol, and the method > > > > solutions for this problem are out of scope. > > > > > > > > For example, the model-based metrics draft in IPPM introduces the > > > > notion of a target rate, which is a good thing, because it means > > > > that the test stream will have an upper bound. > > > > But that is an operational evaluation of a specific method, and > > > > OOS for the problem statement. > > > > > > > > Is this approach more clear? If not, please suggest some text. > > > > > > > > regards, > > > > Al > > > > ________________________________________ > > > > From: Romascanu, Dan (Dan) [dromasca@avaya.com] > > > > Sent: Wednesday, December 17, 2014 5:25 AM > > > > To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org > > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > > > Hi Al, > > > > > > > > I kind of disagree that dealing with the operational implications > > > > of applying active testing should not be mentioned in the problem > > > > statement, but only when specific measurement methods are > described. > > > > The problem statement document explicitly describes active rate > > > > management and includes a section of requirements for test > > > > protocol control and generation. I believe that the operational > > > > aspects of generating traffic in production networks should be > > > > part of the problem statement, and explicitly mentioned, not only > > > > in the context of > > > altering measurement results or security considerations. > > > > > > > > Regards, > > > > > > > > Dan > > > > > > > > > > > > > -----Original Message----- > > > > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > > > > Sent: Tuesday, December 16, 2014 5:05 PM > > > > > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > > > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > > > > > Hi Dan, > > > > > > > > > > Thanks for your review. Perhaps we can close this quickly before > > > > > we both disappear for the holidays (officially, I'm already gone > > > > > and writing from Chicago, where it is unseasonably warm). > > > > > > > > > > We can certainly add details on the operational impact that test > > > > > protocols conforming to this memo's problem statement might cause= . > > > > > This has been a point of issue since the earliest days of IPPM, > > > > > so we should be able to cover the topic by introducing several > references. > > > > > > > > > > If there is some additional point we can cover here, keeping in > > > > > mind that measurement methods are a non-goal of this draft and > > > > > the operational impact of specific methods are best dealt with > > > > > when such methods are specified, please provide your thoughts. > > > > > > > > > > regards, > > > > > Al > > > > > > > > > > The IPPM Framework RFC 2330, section 11.1, says > > > > > > > > > > + The act of measurement can perturb what is being measured > > > > > + (for > > > > > example, injecting measurement traffic into a network alter= s the > > > > > congestion level of the network), and repeated periodic > > > > > perturbations can drive a network into a state of synchroni= zation > > > > > (cf. [FJ94]), greatly magnifying what might individually be= minor > > > > > effects. > > > > > > > > > > And also, RFC 2330 adopts the term "conservative" for measurement > > > > > methodologies for which:, > > > > > > > > > > "... the act of measurement does not modify, or only slightly > > > > > modifies, the value of the performance metric the methodology > > > > > attempts to measure." > > > > > > > > > > However, the constraint that measurements strictly retain the > > > > > conservative property is updated in RFC 7312 > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > > > > 3A__tools.ietf.org_html_rfc7312-23section-2D4.4&d=3DAAIF- > > > > > > > > > > > > > > > g&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd > > > > > rphpBsFA&m=3DN8q- > > > > > > > > > > > > > > > hc4HbRszDQlImZQ_Tenl1mVdgb9ss1bTj9HzKew&s=3DpGbP1qC4qqZh21gJkoiKs > > > > > BmrE3lDnv8ulVOvmjOAlY0&e=3D > > > > > > > > > > It should be noted that this definition of "conservative" in t= he > > > > > sense of [RFC2330] depends to a large extent on the measuremen= t > > > > > path's technology and characteristics. In particular, when de= ployed > > > > > on reactive paths, subpaths, links or hosts conforming to the > > > > > definition in Section 1.1 of RFC 7312, measurement packets can > > > > > originate capacity (re)allocations. In addition, small measur= ement > > > > > flow variations can result in other users on the same path per= ceiving > > > > > significant variations in measurement results. Therefore: > > > > > > > > > > It is not always possible for the method to be conservative= . > > > > > > > > > > And, on modern networks with reactive components, any traffic > > > > > level will have some impact on other users. Therefore, metrics > > > > > and their measurement methods should be vetted by the industry > > > > > SDOs. To make this point clear, we should cite BMWG RFC (2455 > > > > > considered harmful on production networks), which covers the > > > > > topic in Section 6 > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > > > > > 3A__tools.ietf.org_html_rfc6815-23section-2D6&d=3DAAIF- > > > > > > > > > > > > > > > g&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd > > > > > rphpBsFA&m=3DN8q- > > > > > > > > > > > > > > > hc4HbRszDQlImZQ_Tenl1mVdgb9ss1bTj9HzKew&s=3D5fEqW5JnBgSuJYNRNSJS > > > > > mwfu04Mp6cQTBkG_aQNT6qU&e=3D > > > > > and says: > > > > > > > > > > ...There are no specific methods proposed for > > > > > activation of a packet transfer service in IPPM at this time. = Thus, > > > > > individuals who need to conduct capacity tests on production > > networks > > > > > should actively participate in standards development to ensure= their > > > > > methods receive appropriate industry review and agreement, in = the > > > > > IETF or in alternate standards development organizations. > > > > > > > > > > > > > > > > > > > > ________________________________________ > > > > > From: OPS-DIR [ops-dir-bounces@ietf.org] On Behalf Of Romascanu, > > > > > Dan > > > > > (Dan) [dromasca@avaya.com] > > > > > Sent: Monday, December 15, 2014 10:27 AM > > > > > To: ops-dir@ietf.org; ippm@ietf.org > > > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > > > Subject: [OPS-DIR] OPS-DIR review of > > > > > draft-ietf-ippm-rate-problem-08 > > > > > > > > > > I have reviewed this document as part of the Operational > > > > > directorate's ongoing effort to review all IETF documents being > > > > > processed > > > by the IESG. > > > > > These comments were written primarily for the benefit of the > > > > > operational area directors. > > > > > Document editors and WG chairs should treat these comments just > > > > > like any other last call comments. > > > > > > > > > > Ready with one issue > > > > > > > > > > This I-D is an informational document that does not define a new > > > > > protocol or protocol extensions. It does however contain a > > > > > problem statement for test protocols conducting access rate > > > > > measurement in > > > > productions networks. > > > > > These protocols can be OWAMP (RFC 4656) or TWAMP (RFC 5357) but > > > also > > > > > non-IETF protocols. The following operational considerations in > > > > > Appendix A.1 of RFC 5706 apply, I believe, and do not receive > > > > > appropriate answers in the > > > > > document: > > > > > > > > > > 5. Has the impact on network operation been discussed? See > > > > > Section > > 2.5. > > > > > * Will the new protocol significantly increase traffic load on > > > > > existing networks? > > > > > * Will the proposed management for the new protocol > > > > > significantly increase traffic load on existing networks? > > > > > * How will the new protocol impact the behavior of other > > > > > protocols in the network? Will it impact performance (e.g., > > > > > jitter) of certain types of applications running in the same netw= ork? > > > > > > > > > > I believe that at least a reference to these aspects need to be > > > > > included, especially as the In-Service testing with injection of > > > > > active traffic on production network is one of the methods > > > > > discussed by > > > > the document. > > > > > > > > > > The following reference to the effects of the high level traffic > > > > > is not sufficient > > > > > IMO: > > > > > > > > > > > > > > > ? Section 5 of [RFC2680] lists the problems with high > > > > > measurement traffic rates, and the most relevant for rate > > > > > measurement > > > > > > > > > > ? is the tendency for measurement traffic to skew the results, > followed > > > > > by the possibility of introducing congestion on the access lin= k. In- > > > > > Service testing MUST respect these traffic constraints. Obvio= usly, > > > > > categories of rate measurement methods that use less active te= st > > > > > traffic than others with similar accuracy are preferred for In= - > > > > > Service testing. > > > > > > > > > > Section 5 of RFC2680 does not provide too many details as I was > > > > > expecting. It actually deals with traffic injection as with a > > > > > security > > concern: > > > > > > > > > > > > > > > ? There are two types of security concerns: potential harm > > > > > caused by > > > > > > > > > > ? the measurements, and potential harm to the measurements. The > > > > > > > > > > ? measurements could cause harm because they are active, and > inject > > > > > > > > > > ? packets into the network. The measurement parameters MUST be > > > > > > > > > > ? carefully selected so that the measurements inject trivial am= ounts > of > > > > > > > > > > ? additional traffic into the networks they measure. If they in= ject > > > > > > > > > > ? "too much" traffic, they can skew the results of the measurem= ent, > > > and > > > > > > > > > > ? in extreme cases cause congestion and denial of service. > > > > > > > > > > ? > > > > > 'trivial amounts of additional traffic' is too vague - I believe > > > > > that more clear text that deals with the issue as with an > > > > > operational issue, and makes clear that degradation of service > > > > > for users is not acceptable if In-Service testing policies are > > > > > applied would be > > > welcome. > > > > > > > > > > I hope this helps. > > > > > > > > > > Regards, > > > > > > > > > > Dan From nobody Thu Dec 18 07:51:13 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4700A1A90C2; Thu, 18 Dec 2014 07:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twVyaXC4w8WZ; Thu, 18 Dec 2014 07:51:07 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99CA21A1A68; Thu, 18 Dec 2014 07:51:06 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQGAJL2klTGmAcV/2dsb2JhbABagmQiUlgEs1oBAQEBAQEGkjWFcgKBHRYBAQEBAQF8hAwBAQEBAgESCCA/BQcEAgEIDQQEAQEBChQJBzIUCQgCBAEJBAUIEweIAggBDLQDoGQBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIYAhAqFBQsnMQcGgxCBEwWDe4oPgz6DPoMBgmGCJod2gzgig2xvAYECJB5+AQEB X-IronPort-AV: E=Sophos;i="5.07,601,1413259200"; d="scan'208";a="99721281" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 18 Dec 2014 10:51:03 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 18 Dec 2014 10:51:02 -0500 Received: from AZ-FFEXMB03.global.avaya.com ([fe80::d008:af0c:fa66:47e3]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Thu, 18 Dec 2014 16:50:11 +0100 From: "Romascanu, Dan (Dan)" To: "MORTON, ALFRED C (AL)" , "ops-dir@ietf.org" , "ippm@ietf.org" Thread-Topic: OPS-DIR review of draft-ietf-ippm-rate-problem-08 Thread-Index: AdAYe5l6zzPt7cY0Sz6o+JrRmzElOQAxhuiVACgMtpAABsHwBwACB4rAAC+P7poAAbFTYAAA3/rrAAE0nhAAAIMPkgAAsoIgAABx66sAAE9foA== Date: Thu, 18 Dec 2014 15:50:11 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C93CC13@AZ-FFEXMB03.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C93075A@AZ-FFEXMB04.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493901@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93A18C@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493905@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93B6D0@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493907@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93CA1B@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493909@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93CB00@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D8549390D@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93CB97@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493911@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D85493911@NJFPSRVEXG0.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/VYZHkBDq-Z3bkWzUR0jfyIbfWuM Cc: "draft-ietf-ippm-rate-problem.all@tools.ietf.org" Subject: Re: [ippm] OPS-DIR review of draft-ietf-ippm-rate-problem-08 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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, 18 Dec 2014 15:51:12 -0000 Indeed.=20 Thanks and Regards, Dan > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Thursday, December 18, 2014 5:41 PM > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 >=20 > Hi Dan, >=20 > Thanks for your compromise. >=20 > On the topic of "increased" traffic: >=20 > This document introduces a RECOMMENDATION for test protocols to add > the capability generate asymmetrical packet sizes in different directions= , > something that the current protocols cannot do (but they can certainly be > used to make rate measurements now). >=20 > In fact, this asymmetric size feature REDUCES the test traffic load. > Perhaps you would like this mentioned as a desirable feature from an > operations perspective? >=20 > regards, > Al >=20 > ________________________________________ > From: Romascanu, Dan (Dan) [dromasca@avaya.com] > Sent: Thursday, December 18, 2014 10:31 AM > To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 >=20 > Hi Al, >=20 > I will not further insist on fine tuning the text this I-D, as I do not l= ike keeping > one document 'hostage' even for such important issues, when we came that > close. >=20 > I believe that making the text more clear would have been useful, but we > almost walked the extra mile with the inclusion of the new section, and t= hat's > fine by now. >=20 > Regards, >=20 > Dan >=20 >=20 > > -----Original Message----- > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > Sent: Thursday, December 18, 2014 5:20 PM > > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > Hi Dan, > > > > you wrote: > > The goal of this text is exactly to make sure and explicit that > > operators engineer their management traffic load, > > including measurement-related traffic. > > > > The text does that now, adding new considerations. The audience of > > this section are the operators. > > We now know the issue, potential for degradation. Do we need further > > implementation guidance? > > I don't think so. > > > > If the root of your concern is the comparison between active and > > passive, then you have many more factors to consider than traffic. One > > is "What happens to forwarding capacity when I turn on NetFlow?" > > That's a question we helped operators try to answer in BMWG's RFC 6645= . > > https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > > > 3A__tools.ietf.org_html_rfc6645&d=3DAwIFAg&c=3DBFpWQw8bsuKpl1SgiZH64Q > > > &r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DgidqHsa1uFlRnPsB > > pwAmd1-VWq9YWDrVjyT2xjxFAm8&s=3D0UDbON- > > YV4jGVyt8H9aBb1kTlyJmt3bJSwfW-5FZwrM&e=3D > > > > regards, > > Al > > > > ________________________________________ > > From: Romascanu, Dan (Dan) [dromasca@avaya.com] > > Sent: Thursday, December 18, 2014 10:00 AM > > To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > Hi Al, > > > > But this IS increased traffic, as standardized rate measurements were > > not in practice until now, hence the need for new standards, including > > the ones in IPPM. Yes, it's management traffic, but the very issue an > > operational considerations sections aims is to draw the attention that > > people that design an deploy new protocols need to factor in the > > overall effects of new protocols traffic on the networks. New > > protocols and methods to measure rate generate new traffic, active > > measurement causes more new traffic than passive methods, all this > > needs to be considered. The goal of this text is exactly to make sure > > and explicit that operators engineer their management traffic load, > including measurement-related traffic. > > > > Regards, > > > > Dan > > > > > > > -----Original Message----- > > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > > Sent: Thursday, December 18, 2014 4:34 PM > > > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > Hi Dan, > > > > > > When you added the sentence: > > > It is desirable that the increase load in the traffic levels in > > > the live networks caused by the active measurement protocols > > > and by the management of the active measurement protocols does not > > > lead to any significant degradation of the > > > quality of service of the applications running in the networks or > > > the quality of experience of the users of the applications. > > > > > > You have continued to assume that the measurement traffic is excess > > > traffic ("increased load") and it needs new requirements. As I > > > said, one subscriber's traffic can degrade the traffic of another > > > subscriber, whether the degradation is significant or not depends on > > > too many factors to go into here, but one or both of the subscribers > > > could be running tests related to this problem statement. > > > Operators engineer their management traffic load, including > > > measurement- related traffic. > > > > > > There is simply traffic from many sources, all to be engineered. > > > Operations and Engineering as usual. > > > The section has provided specific cautions and guidance for > > > operators and users. No need for new implementation rules, IMO. > > > > > > regards, > > > Al > > > ________________________________________ > > > From: Romascanu, Dan (Dan) [dromasca@avaya.com] > > > Sent: Thursday, December 18, 2014 9:08 AM > > > To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > Hi Al, > > > > > > We are getting close. Your suggested text seems almost appropriate, > > > with two observations: > > > > > > - 'adequately served' is too vague and an explanation of what that > > > means is needed > > > - I do not believe that we need a reference to RFC 3148. Again, the > > > concern is not about the potential of security attacks (like DoS > > > attacks mentioned in 3148). The intent is to warn well intentioned > > > operators, SPs and end users of the potential dangers of not taking > > > into consideration the effects of active methods, and recommend that > > > they design and deploy accordingly > > > > > > Suggested edit to your proposal: > > > > > > OLD: > > > > > > 7. Operational Considerations > > > > > > All forms of testing originate traffic on the network, through their > > > communications for control and results collection, or from dedicated > > > measurement packet streams, or both. > > > Testing traffic primarily falls in one of two categories, subscriber > > > traffic or network management traffic. > > > There is an on-going need to engineer networks so that various forms > > > of traffic are adequately served, and publication of this memo does > > > not change this need. > > > Service subscribers and authorized users SHOULD obtain their network > > > operator's or service provider's permission before conducting tests. > > > Likewise, a service provider or third party SHOULD obtain the > > > subscriber's permission to conduct tests, since they might > > > temporarily > > reduce service quality. > > > See section 4.1 of [RFC 3148]. > > > > > > Subscribers, their service providers and network operators, and > > > sometimes third parties, all seek to measure network performance. > > > Capacity testing with active traffic often affects the packet > > > transfer performance of streams traversing shared components of the > > > test path, to some degree. The degradation can be minimized by > > > scheduling such tests infrequently, and restricting the amount of > > > measurement traffic required to assess capacity metrics. As a > > > result, occasional short-duration estimates are preferred to > > > measurements based on frequent file transfers of many Megabytes. > > > New measurement methodologies intended for standardization should > be > > > evaluated individually for potential operational issues. > > > However, the scheduled frequency of testing is as important as the > > > methods used (and schedules are not typically submitted for > > standardization). > > > > > > NEW: > > > > > > 7. Operational Considerations > > > > > > All forms of testing originate traffic on the network, through their > > > communications for control and results collection, or from dedicated > > > measurement packet streams, or both. > > > Testing traffic primarily falls in one of two categories, subscriber > > > traffic or network management traffic. > > > There is an on-going need to engineer networks so that various forms > > > of traffic are adequately served, and publication of this memo does > > > not change this need . It is desirable that the increase load in the > > > traffic levels in the live networks caused by the active measurement > > > protocols and by the management of the active measurement protocols > > > does not lead to any significant degradation of the quality of > > > service of the applications running in the networks or the quality > > > of experience of > > the users of the applications. > > > Service subscribers and authorized users SHOULD obtain their network > > > operator's or service provider's permission before conducting tests. > > > Likewise, a service provider or third party SHOULD obtain the > > > subscriber's permission to conduct tests, since they might > > > temporarily > > reduce service quality. > > > > > > Subscribers, their service providers and network operators, and > > > sometimes third parties, all seek to measure network performance. > > > Capacity testing with active traffic often affects the packet > > > transfer performance of streams traversing shared components of the > > > test path, to some degree. The degradation can be minimized by > > > scheduling such tests infrequently, and restricting the amount of > > > measurement traffic required to assess capacity metrics. As a > > > result, occasional short-duration estimates are preferred to > > > measurements based on frequent file transfers of many Megabytes. > > > New measurement methodologies intended for standardization should > be > > > evaluated individually for potential operational issues. > > > However, the scheduled frequency of testing is as important as the > > > methods used (and schedules are not typically submitted for > > standardization). > > > > > > Regards, > > > > > > Dan > > > > > > > > > > -----Original Message----- > > > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > > > Sent: Thursday, December 18, 2014 3:06 PM > > > > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > > > > > > > Hi Dan, > > > > > > > > I now see better where the disconnect is. You are looking for new > > > > explicit statements about operational impact. But you are assuming > > > > that the active measurement traffic is *excess* traffic, beyond > > > > some normal level resulting from all Subscriber traffic and an > > > > operator-chosen level of net management traffic. > > > > However, management traffic includes performance measurement > > traffic > > > > (when the traffic is originated by the operator), and Subscriber > > > > traffic includes active measurement traffic (when originated by > > > > the users). Test- related traffic needs to be engineered and > > > > limited along with > > > all other traffic. > > > > > > > > Also, the requirement you wrote "does not lead to degradation" > > > > doesn't seem attainable, so we need to provide cautions through > > > > other means. Sending a single packet results in larger queue > > > > occupations all along its path =3D degradation. > > > > The packet could be for routing or other network management. > > > > > > > > The active measurement traffic is often launched by subscribers or > > > > their authorized users, and there may well be some degree of > > > > degradation to other subscriber's streams. > > > > Your proposed text recommends against this, yet it is no different > > > > from the degradation caused by a user who chooses to watch a video > > > > instead of testing (except that the video session may be longer). > > > > > > > > Further, Service providers may be temporarily replacing an idle > > > > user's traffic with active test traffic. Again there may be some > > > > degradation to other subscribers, but it would typically be no > > > > worse than from an additional user using their service. > > > > > > > > There is also the question of test frequency and overall performanc= e: > > > > a user may experience instantaneous packet delay or loss while > > > > another subscriber tests their performance, but then the > > > > performance is at nominal levels for long periods between tests > > > > and the overall performance for a multi-hour session would be > satisfactory. > > > > > > > > It is clear to me that the operational issues primarily addressed > > > > in previous IPPM work include the affects on other traffic, the > > > > accuracy of the measurements (including preferential treatment or > > > > spoofing of measured streams), and the real or perceived existence > > > > of > > DoS attacks. > > > > Although these are not identified as operations issues, they are > > > > certainly relevant in network operations where measurement has > > > > become a growing part of the management portfolio. > > > > So, we should continue to cite the existing IPPM (and BMWG) > > > > guidance on topics such as conservative measurement, and insert > > > > the references I provided earlier into Section 3 (where you cited > > > > the reference from > > > > RFC2680 > > > > - note the reference was to the sentence on high traffic rates, > > > > ("too much > > > > traffic") so the phrase "trivial amounts of additional traffic" > > > > may be an inadequate specification, but it was not the intended > > > > reference > > > material. > > > > > > > > This is the new section I propose: > > > > > > > > 7. Operational Considerations > > > > > > > > All forms of testing originate traffic on the network, through > > > > their communications for control and results collection, or from > > > > dedicated measurement packet streams, or both. > > > > Testing traffic primarily falls in one of two categories, > > > > subscriber traffic or network management traffic. > > > > There is an on-going need to engineer networks so that various > > > > forms of traffic are adequately served, and publication of this > > > > memo does not change this need. > > > > Service subscribers and authorized users SHOULD obtain their > > > > network operator's or service provider's permission before conducti= ng > tests. > > > > Likewise, a service provider or third party SHOULD obtain the > > > > subscriber's permission to conduct tests, since they might > > > > temporarily > > > reduce service quality. > > > > See section 4.1 of [RFC 3148]. > > > > > > > > Subscribers, their service providers and network operators, and > > > > sometimes third parties, all seek to measure network performance. > > > > Capacity testing with active traffic often affects the packet > > > > transfer performance of streams traversing shared components of > > > > the test path, to some degree. The degradation can be minimized by > > > > scheduling such tests infrequently, and restricting the amount of > > > > measurement traffic required to assess capacity metrics. As a > > > > result, occasional short-duration estimates are preferred to > > > > measurements based on frequent file transfers of many Megabytes. > > > > New measurement methodologies intended for standardization should > > be > > > > evaluated individually for potential operational issues. > > > > However, the scheduled frequency of testing is as important as the > > > > methods used (and schedules are not typically submitted for > > > standardization). > > > > > > > > > > > > ________________________________________ > > > > From: Romascanu, Dan (Dan) [dromasca@avaya.com] > > > > Sent: Wednesday, December 17, 2014 9:34 AM > > > > To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org > > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > > > Suggested edit: > > > > > > > > Insert section 7 after the Security considerations section with > > > > the following text, and renumber the other sections accordingly: > > > > > > > > 7. Operational Considerations > > > > > > > > The increase in traffic levels caused by applying any active > > > > measurement of live networks is a concern and needs to be > > > > considered and controlled any time active measurements are > > > > applied. It is RECOMMENDED that the increase load in the traffic > > > > levels in the live networks caused by the active measurement > > > > protocols and by the management of the active measurement > > > > protocols does not lead to a degradation of the quality of service > > > > of the applications running in the networks or the quality of > > > > experience of the users of the > > applications. > > > > > > > > Regards, > > > > > > > > Dan > > > > > > > > > > > > > -----Original Message----- > > > > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > > > > Sent: Wednesday, December 17, 2014 3:39 PM > > > > > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > > > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > > > > > Hi Dan, > > > > > > > > > > I did not say that the operational implications would not be > > > > > dealt with > > > here. > > > > > > > > > > I'm simply saying that IPPM drafts have done as you have asked > > > > > many times already, that is discuss the implications of active > > > > > measurements, and that we would not repeat that guidance (but > > > > > include four references below). Also, that the measurement > > > > > methods would each be vetted on their own, when proposed for > > standardization. > > > > > You need both methods and control/test protocol, and the method > > > > > solutions for this problem are out of scope. > > > > > > > > > > For example, the model-based metrics draft in IPPM introduces > > > > > the notion of a target rate, which is a good thing, because it > > > > > means that the test stream will have an upper bound. > > > > > But that is an operational evaluation of a specific method, and > > > > > OOS for the problem statement. > > > > > > > > > > Is this approach more clear? If not, please suggest some text. > > > > > > > > > > regards, > > > > > Al > > > > > ________________________________________ > > > > > From: Romascanu, Dan (Dan) [dromasca@avaya.com] > > > > > Sent: Wednesday, December 17, 2014 5:25 AM > > > > > To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org > > > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > > > > > Hi Al, > > > > > > > > > > I kind of disagree that dealing with the operational > > > > > implications of applying active testing should not be mentioned > > > > > in the problem statement, but only when specific measurement > > > > > methods are > > described. > > > > > The problem statement document explicitly describes active rate > > > > > management and includes a section of requirements for test > > > > > protocol control and generation. I believe that the operational > > > > > aspects of generating traffic in production networks should be > > > > > part of the problem statement, and explicitly mentioned, not > > > > > only in the context of > > > > altering measurement results or security considerations. > > > > > > > > > > Regards, > > > > > > > > > > Dan > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > > > > > Sent: Tuesday, December 16, 2014 5:05 PM > > > > > > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > > > > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > > > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > > > > > > > Hi Dan, > > > > > > > > > > > > Thanks for your review. Perhaps we can close this quickly > > > > > > before we both disappear for the holidays (officially, I'm > > > > > > already gone and writing from Chicago, where it is unseasonably > warm). > > > > > > > > > > > > We can certainly add details on the operational impact that > > > > > > test protocols conforming to this memo's problem statement migh= t > cause. > > > > > > This has been a point of issue since the earliest days of > > > > > > IPPM, so we should be able to cover the topic by introducing > > > > > > several > > references. > > > > > > > > > > > > If there is some additional point we can cover here, keeping > > > > > > in mind that measurement methods are a non-goal of this draft > > > > > > and the operational impact of specific methods are best dealt > > > > > > with when such methods are specified, please provide your > thoughts. > > > > > > > > > > > > regards, > > > > > > Al > > > > > > > > > > > > The IPPM Framework RFC 2330, section 11.1, says > > > > > > > > > > > > + The act of measurement can perturb what is being measured > > > > > > + (for > > > > > > example, injecting measurement traffic into a network alt= ers the > > > > > > congestion level of the network), and repeated periodic > > > > > > perturbations can drive a network into a state of synchro= nization > > > > > > (cf. [FJ94]), greatly magnifying what might individually = be minor > > > > > > effects. > > > > > > > > > > > > And also, RFC 2330 adopts the term "conservative" for > measurement > > > > > > methodologies for which:, > > > > > > > > > > > > "... the act of measurement does not modify, or only slightl= y > > > > > > modifies, the value of the performance metric the methodolog= y > > > > > > attempts to measure." > > > > > > > > > > > > However, the constraint that measurements strictly retain the > > > > > > conservative property is updated in RFC 7312 > > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > > > > > 3A__tools.ietf.org_html_rfc7312-23section-2D4.4&d=3DAAIF- > > > > > > > > > > > > > > > > > > > > > g&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd > > > > > > rphpBsFA&m=3DN8q- > > > > > > > > > > > > > > > > > > > > > hc4HbRszDQlImZQ_Tenl1mVdgb9ss1bTj9HzKew&s=3DpGbP1qC4qqZh21gJkoiKs > > > > > > BmrE3lDnv8ulVOvmjOAlY0&e=3D > > > > > > > > > > > > It should be noted that this definition of "conservative" in= the > > > > > > sense of [RFC2330] depends to a large extent on the > measurement > > > > > > path's technology and characteristics. In particular, when > deployed > > > > > > on reactive paths, subpaths, links or hosts conforming to th= e > > > > > > definition in Section 1.1 of RFC 7312, measurement packets c= an > > > > > > originate capacity (re)allocations. In addition, small meas= urement > > > > > > flow variations can result in other users on the same path > perceiving > > > > > > significant variations in measurement results. Therefore: > > > > > > > > > > > > It is not always possible for the method to be conservati= ve. > > > > > > > > > > > > And, on modern networks with reactive components, any traffic > > > > > > level will have some impact on other users. Therefore, > > > > > > metrics and their measurement methods should be vetted by the > > > > > > industry SDOs. To make this point clear, we should cite BMWG > > > > > > RFC (2455 considered harmful on production networks), which > > > > > > covers the topic in Section 6 > > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > > > > > > 3A__tools.ietf.org_html_rfc6815-23section-2D6&d=3DAAIF- > > > > > > > > > > > > > > > > > > > > > g&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd > > > > > > rphpBsFA&m=3DN8q- > > > > > > > > > > > > > > > > > > > > > hc4HbRszDQlImZQ_Tenl1mVdgb9ss1bTj9HzKew&s=3D5fEqW5JnBgSuJYNRNSJS > > > > > > mwfu04Mp6cQTBkG_aQNT6qU&e=3D > > > > > > and says: > > > > > > > > > > > > ...There are no specific methods proposed for > > > > > > activation of a packet transfer service in IPPM at this time= . Thus, > > > > > > individuals who need to conduct capacity tests on > > > > > > production > > > networks > > > > > > should actively participate in standards development to ensu= re > their > > > > > > methods receive appropriate industry review and agreement, i= n > the > > > > > > IETF or in alternate standards development organizations. > > > > > > > > > > > > > > > > > > > > > > > > ________________________________________ > > > > > > From: OPS-DIR [ops-dir-bounces@ietf.org] On Behalf Of > > > > > > Romascanu, Dan > > > > > > (Dan) [dromasca@avaya.com] > > > > > > Sent: Monday, December 15, 2014 10:27 AM > > > > > > To: ops-dir@ietf.org; ippm@ietf.org > > > > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > > > > Subject: [OPS-DIR] OPS-DIR review of > > > > > > draft-ietf-ippm-rate-problem-08 > > > > > > > > > > > > I have reviewed this document as part of the Operational > > > > > > directorate's ongoing effort to review all IETF documents > > > > > > being processed > > > > by the IESG. > > > > > > These comments were written primarily for the benefit of the > > > > > > operational area directors. > > > > > > Document editors and WG chairs should treat these comments > > > > > > just like any other last call comments. > > > > > > > > > > > > Ready with one issue > > > > > > > > > > > > This I-D is an informational document that does not define a > > > > > > new protocol or protocol extensions. It does however contain a > > > > > > problem statement for test protocols conducting access rate > > > > > > measurement in > > > > > productions networks. > > > > > > These protocols can be OWAMP (RFC 4656) or TWAMP (RFC 5357) > > > > > > but > > > > also > > > > > > non-IETF protocols. The following operational considerations > > > > > > in Appendix A.1 of RFC 5706 apply, I believe, and do not > > > > > > receive appropriate answers in the > > > > > > document: > > > > > > > > > > > > 5. Has the impact on network operation been discussed? See > > > > > > Section > > > 2.5. > > > > > > * Will the new protocol significantly increase traffic load on > > > > > > existing networks? > > > > > > * Will the proposed management for the new protocol > > > > > > significantly increase traffic load on existing networks? > > > > > > * How will the new protocol impact the behavior of other > > > > > > protocols in the network? Will it impact performance (e.g., > > > > > > jitter) of certain types of applications running in the same ne= twork? > > > > > > > > > > > > I believe that at least a reference to these aspects need to > > > > > > be included, especially as the In-Service testing with > > > > > > injection of active traffic on production network is one of > > > > > > the methods discussed by > > > > > the document. > > > > > > > > > > > > The following reference to the effects of the high level > > > > > > traffic is not sufficient > > > > > > IMO: > > > > > > > > > > > > > > > > > > ? Section 5 of [RFC2680] lists the problems with high > > > > > > measurement traffic rates, and the most relevant for rate > > > > > > measurement > > > > > > > > > > > > ? is the tendency for measurement traffic to skew the > > > > > > results, > > followed > > > > > > by the possibility of introducing congestion on the access l= ink. In- > > > > > > Service testing MUST respect these traffic constraints. Obv= iously, > > > > > > categories of rate measurement methods that use less active = test > > > > > > traffic than others with similar accuracy are preferred for = In- > > > > > > Service testing. > > > > > > > > > > > > Section 5 of RFC2680 does not provide too many details as I > > > > > > was expecting. It actually deals with traffic injection as > > > > > > with a security > > > concern: > > > > > > > > > > > > > > > > > > ? There are two types of security concerns: potential harm > > > > > > caused by > > > > > > > > > > > > ? the measurements, and potential harm to the measurements. > The > > > > > > > > > > > > ? measurements could cause harm because they are active, and > > inject > > > > > > > > > > > > ? packets into the network. The measurement parameters MUST > be > > > > > > > > > > > > ? carefully selected so that the measurements inject trivial > amounts > > of > > > > > > > > > > > > ? additional traffic into the networks they measure. If they = inject > > > > > > > > > > > > ? "too much" traffic, they can skew the results of the > measurement, > > > > and > > > > > > > > > > > > ? in extreme cases cause congestion and denial of service. > > > > > > > > > > > > ? > > > > > > 'trivial amounts of additional traffic' is too vague - I > > > > > > believe that more clear text that deals with the issue as with > > > > > > an operational issue, and makes clear that degradation of > > > > > > service for users is not acceptable if In-Service testing > > > > > > policies are applied would be > > > > welcome. > > > > > > > > > > > > I hope this helps. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Dan From nobody Thu Dec 18 11:14:05 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8DE1A6FED; Thu, 18 Dec 2014 11:13:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RnlH_R9blgZ; Thu, 18 Dec 2014 11:13:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D371A6FDE; Thu, 18 Dec 2014 11:13:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.8.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141218191357.30656.43044.idtracker@ietfa.amsl.com> Date: Thu, 18 Dec 2014 11:13:57 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/T2_UK7B5AQIxQpu1iumEkGJmgMo Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-type-p-monitor-00.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 19:13:59 -0000 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 : Differentiated Service Code Point and Explicit Congestion Notification Monitoring in Two-Way Active Measurement Protocol (TWAMP) Authors : Jonas Hedin Greg Mirsky Steve Baillargeon Filename : draft-ietf-ippm-type-p-monitor-00.txt Pages : 10 Date : 2014-12-18 Abstract: This document describes an OPTIONAL feature for TWAMP [RFC5357] allowing the monitoring of the Differentiated Service Code Point and Explicit Congestion Notification fields with the TWAMP-Test protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-type-p-monitor/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ippm-type-p-monitor-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 18 11:18:47 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D5A1A9155; Thu, 18 Dec 2014 11:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2YXw0HzWZ2u; Thu, 18 Dec 2014 11:18:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A8C1A6EED; Thu, 18 Dec 2014 11:18:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.8.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141218191844.30626.92340.idtracker@ietfa.amsl.com> Date: Thu, 18 Dec 2014 11:18:44 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/AtCJ0kPc4Mr7JP5-GdkDXmkpASE Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-type-p-monitor-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 19:18:45 -0000 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 : Differentiated Service Code Point and Explicit Congestion Notification Monitoring in Two-Way Active Measurement Protocol (TWAMP) Authors : Jonas Hedin Greg Mirsky Steve Baillargeon Filename : draft-ietf-ippm-type-p-monitor-01.txt Pages : 9 Date : 2014-12-18 Abstract: This document describes an OPTIONAL extension for Two-Way Active Measurement Protocol (TWAMP) allowing the monitoring of the Differentiated Service Code Point and Explicit Congestion Notification fields with the TWAMP-Test protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-type-p-monitor/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ippm-type-p-monitor-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-type-p-monitor-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 18 11:24:59 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F971ABD3B for ; Thu, 18 Dec 2014 11:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4MTUYJB-kTZ for ; Thu, 18 Dec 2014 11:24:55 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AE9E1A923E for ; Thu, 18 Dec 2014 11:24:55 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-9b-5492d9330e53 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 05.2C.03307.339D2945; Thu, 18 Dec 2014 14:40:03 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0195.001; Thu, 18 Dec 2014 14:24:49 -0500 From: Gregory Mirsky To: "ippm@ietf.org" Thread-Topic: [ippm] I-D Action: draft-ietf-ippm-type-p-monitor-01.txt Thread-Index: AQHQGveKft9yMJTJx02P0j0WITSCx5yVuflQ Date: Thu, 18 Dec 2014 19:24:48 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8C4BCF@eusaamb103.ericsson.se> References: <20141218191844.30626.92340.idtracker@ietfa.amsl.com> In-Reply-To: <20141218191844.30626.92340.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUyuXRPoK7xzUkhBleWKFn0PHjH7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujFWzepgL7vNXHHl1lL2BcRdPFyMHh4SAicSXTuYuRk4gU0zi wr31bF2MXBxCAkcYJTbeWcsO4SxnlLgw7xobSBWbgJHEi4097CC2iICyRMu3P4wgg4QFXCXO T5UEMUUE3CTWT1KHqDCSWP3/Jdh8FgFViSW7joPZvAK+El8O3WIBKRcScJR4sTIbJMwp4CSx oq+XBcRmBDrn+6k1TCA2s4C4xK0n85kgzhSQWLLnPNTJohIvH/9jhbCVJCYtPccKUa8jsWD3 JzYIW1ti2cLXUGsFJU7OfMIygVF0FpKxs5C0zELSMgtJywJGllWMHKXFqWW56UYGmxiBIX9M gk13B+Oel5aHGAU4GJV4eD9wTQoRYk0sK67MPcQozcGiJM47q3ZesJBAemJJanZqakFqUXxR aU5q8SFGJg5OqQbGssbq76s/NiV7p59/uKbXxG7bz0Pvjf9XXjqfJBwmtZN5huVB2Xfbq5bG vgpvDHudyRT0/vbhSok+RfNPz/b7Mjh/mqRglbhY5EZ47+Yffy4mLb6xJ4T9a/mm1ObcspIQ 64p7zps8nyhwTFnuzb379OIP5Vff/VplG5C7ceopV/X0Ocst5l/5r8RSnJFoqMVcVJwIAGnY 8JxaAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/f7Y7sYjWbLCFzVK6nSsboNZhkCk Subject: [ippm] FW: I-D Action: draft-ietf-ippm-type-p-monitor-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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, 18 Dec 2014 19:24:57 -0000 Dear All, the document been submitted as the WG document and then editorial changes w= ere brought in. Authors welcome your comments, suggestions. Regards, Greg -----Original Message----- From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Thursday, December 18, 2014 11:19 AM To: i-d-announce@ietf.org Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-type-p-monitor-01.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 t= he IETF. Title : Differentiated Service Code Point and Explicit Co= ngestion Notification Monitoring in Two-Way Active Measurement Protocol (TW= AMP) Authors : Jonas Hedin Greg Mirsky Steve Baillargeon Filename : draft-ietf-ippm-type-p-monitor-01.txt Pages : 9 Date : 2014-12-18 Abstract: This document describes an OPTIONAL extension for Two-Way Active Measurement Protocol (TWAMP) allowing the monitoring of the Differentiated Service Code Point and Explicit Congestion Notification fields with the TWAMP-Test protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-type-p-monitor/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ippm-type-p-monitor-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-type-p-monitor-01 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From nobody Mon Dec 22 00:09:03 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEF51A8A0C; Mon, 22 Dec 2014 00:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upNEzkXoRL7k; Mon, 22 Dec 2014 00:08:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A001A8A0E; Mon, 22 Dec 2014 00:08:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: iesg@ietf.org, ietf@wjcerveny.com, draft-ietf-ippm-rate-problem.all@tools.ietf.org, ippm-chairs@tools.ietf.org, ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.9.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141222080848.22802.18919.idtracker@ietfa.amsl.com> Date: Mon, 22 Dec 2014 00:08:48 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/mXvVc8KwS7wVadICUutdWa2Z99U Cc: iesg-secretary@ietf.org Subject: [ippm] Last Call Expired: X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 08:08:57 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem/ IETF Last Call has ended, and the state has been changed to Waiting for Writeup. From nobody Sat Dec 27 11:31:02 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 565291A9145; Sat, 27 Dec 2014 11:30:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCK3IvRHe9cK; Sat, 27 Dec 2014 11:30:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3239C1A913D; Sat, 27 Dec 2014 11:30:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141227193058.8648.36042.idtracker@ietfa.amsl.com> Date: Sat, 27 Dec 2014 11:30:58 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/kT3wUioWEnQxVboKdyt5peOLeBQ Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-ipsec-07.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2014 19:30:59 -0000 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 : IKEv2-based Shared Secret Key for O/TWAMP Authors : Kostas Pentikousis Emma Zhang Yang Cui Filename : draft-ietf-ippm-ipsec-07.txt Pages : 13 Date : 2014-12-27 Abstract: The O/TWAMP security mechanism requires that both the client and server endpoints possess a shared secret. Since the currently- standardized O/TWAMP security mechanism only supports a pre-shared key mode, large scale deployment of O/TWAMP is hindered significantly. At the same time, recent trends point to wider IKEv2 deployment which, in turn, calls for mechanisms and methods that enable tunnel end-users, as well as operators, to measure one-way and two-way network performance in a standardized manner. This document discusses the use of keys derived from an IKEv2 SA as the shared key in O/TWAMP. If the shared key can be derived from the IKEv2 SA, O/ TWAMP can support certificate-based key exchange, which would allow for more operational flexibility and efficiency. The key derivation presented in this document can also facilitate automatic key management. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ippm-ipsec-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-ipsec-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Dec 27 12:12:30 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAEE31A9153; Sat, 27 Dec 2014 12:12:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrr0b-AoLUd1; Sat, 27 Dec 2014 12:12:26 -0800 (PST) Received: from mx2.eict.de (mx2.eict.de [212.91.241.168]) by ietfa.amsl.com (Postfix) with ESMTP id 7CEBA1A9152; Sat, 27 Dec 2014 12:12:26 -0800 (PST) Received: by mx2.eict.de (Postfix, from userid 481) id 380F71FF4F; Sat, 27 Dec 2014 21:12:25 +0100 (CET) Received: from mail.eict.de (mx1 [172.16.6.1]) by mx2.eict.de (Postfix) with ESMTP id 5479F1FF47; Sat, 27 Dec 2014 21:12:24 +0100 (CET) Received: from sbs2008.eict.local (sbs2008.intern.eict.de [192.168.2.11]) by mail.eict.de (Postfix) with ESMTP id D3F7D378238; Sat, 27 Dec 2014 21:12:23 +0100 (CET) Received: from SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298]) by SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298%13]) with mapi; Sat, 27 Dec 2014 21:12:23 +0100 From: Kostas Pentikousis To: "ippm@ietf.org" , "ipsec@ietf.org" Date: Sat, 27 Dec 2014 21:12:22 +0100 Thread-Topic: New Version Notification for draft-ietf-ippm-ipsec-07.txt Thread-Index: AdAiC6zxCbWVQLhEQ4a73n6+6VyUugAAFNfA Message-ID: <0C7EDCF89AB9E2478B5D010026CFF4AEB5AB607753@SBS2008.eict.local> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/m-SKi5GfCwjyvUwLyhREzLnRdRY Subject: [ippm] WG: New Version Notification for draft-ietf-ippm-ipsec-07.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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, 27 Dec 2014 20:12:29 -0000 RGVhciBhbGwgQElQUE0gYW5kIEBJUFNFQywNCg0KV2UgaGF2ZSB1cGRhdGVkIGRyYWZ0LWlldGYt aXBwbS1pcHNlYyB0byBhZGRyZXNzIHRoZSBpc3N1ZSB0aGF0IGFyb3NlIGR1cmluZyB0aGUgc2hl cGhlcmQgcmV2aWV3IChJQU5BIGNvbnNpZGVyYXRpb25zKS4NCg0KUGxlYXNlIGxldCB1cyBrbm93 IGlmIHlvdSBoYXZlIGFueSBmaW5hbCBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMuDQoNCkJlc3Qg cmVnYXJkcywNCg0KS29zdGFzDQoNCg0KLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0t LQ0KVm9uOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmddIA0KR2VzZW5kZXQ6IFNhbXN0YWcsIDI3LiBEZXplbWJlciAyMDE0IDIwOjMxDQpB bjogWWFuZyBDdWk7IEVtbWEgWmhhbmc7IEVtbWEgWmhhbmc7IFlhbmcgQ3VpOyBLb3N0YXMgUGVu dGlrb3VzaXM7IEtvc3RhcyBQZW50aWtvdXNpcw0KQmV0cmVmZjogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1pZXRmLWlwcG0taXBzZWMtMDcudHh0DQoNCg0KQSBuZXcgdmVyc2lv biBvZiBJLUQsIGRyYWZ0LWlldGYtaXBwbS1pcHNlYy0wNy50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1 bGx5IHN1Ym1pdHRlZCBieSBLb3N0YXMgUGVudGlrb3VzaXMgYW5kIHBvc3RlZCB0byB0aGUgSUVU RiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtaWV0Zi1pcHBtLWlwc2VjDQpSZXZpc2lvbjoJ MDcNClRpdGxlOgkJSUtFdjItYmFzZWQgU2hhcmVkIFNlY3JldCBLZXkgZm9yIE8vVFdBTVANCkRv Y3VtZW50IGRhdGU6CTIwMTQtMTItMjcNCkdyb3VwOgkJaXBwbQ0KUGFnZXM6CQkxMw0KVVJMOiAg ICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYt aXBwbS1pcHNlYy0wNy50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLWlwcG0taXBzZWMvDQpIdG1saXplZDogICAgICAgaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pcHBtLWlwc2VjLTA3DQpEaWZmOiAgICAg ICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1pcHBtLWlw c2VjLTA3DQoNCkFic3RyYWN0Og0KICAgVGhlIE8vVFdBTVAgc2VjdXJpdHkgbWVjaGFuaXNtIHJl cXVpcmVzIHRoYXQgYm90aCB0aGUgY2xpZW50IGFuZA0KICAgc2VydmVyIGVuZHBvaW50cyBwb3Nz ZXNzIGEgc2hhcmVkIHNlY3JldC4gIFNpbmNlIHRoZSBjdXJyZW50bHktDQogICBzdGFuZGFyZGl6 ZWQgTy9UV0FNUCBzZWN1cml0eSBtZWNoYW5pc20gb25seSBzdXBwb3J0cyBhIHByZS1zaGFyZWQN CiAgIGtleSBtb2RlLCBsYXJnZSBzY2FsZSBkZXBsb3ltZW50IG9mIE8vVFdBTVAgaXMgaGluZGVy ZWQNCiAgIHNpZ25pZmljYW50bHkuICBBdCB0aGUgc2FtZSB0aW1lLCByZWNlbnQgdHJlbmRzIHBv aW50IHRvIHdpZGVyIElLRXYyDQogICBkZXBsb3ltZW50IHdoaWNoLCBpbiB0dXJuLCBjYWxscyBm b3IgbWVjaGFuaXNtcyBhbmQgbWV0aG9kcyB0aGF0DQogICBlbmFibGUgdHVubmVsIGVuZC11c2Vy cywgYXMgd2VsbCBhcyBvcGVyYXRvcnMsIHRvIG1lYXN1cmUgb25lLXdheSBhbmQNCiAgIHR3by13 YXkgbmV0d29yayBwZXJmb3JtYW5jZSBpbiBhIHN0YW5kYXJkaXplZCBtYW5uZXIuICBUaGlzIGRv Y3VtZW50DQogICBkaXNjdXNzZXMgdGhlIHVzZSBvZiBrZXlzIGRlcml2ZWQgZnJvbSBhbiBJS0V2 MiBTQSBhcyB0aGUgc2hhcmVkIGtleQ0KICAgaW4gTy9UV0FNUC4gIElmIHRoZSBzaGFyZWQga2V5 IGNhbiBiZSBkZXJpdmVkIGZyb20gdGhlIElLRXYyIFNBLCBPLw0KICAgVFdBTVAgY2FuIHN1cHBv cnQgY2VydGlmaWNhdGUtYmFzZWQga2V5IGV4Y2hhbmdlLCB3aGljaCB3b3VsZCBhbGxvdw0KICAg Zm9yIG1vcmUgb3BlcmF0aW9uYWwgZmxleGliaWxpdHkgYW5kIGVmZmljaWVuY3kuICBUaGUga2V5 IGRlcml2YXRpb24NCiAgIHByZXNlbnRlZCBpbiB0aGlzIGRvY3VtZW50IGNhbiBhbHNvIGZhY2ls aXRhdGUgYXV0b21hdGljIGtleQ0KICAgbWFuYWdlbWVudC4NCg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNp b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYg U2VjcmV0YXJpYXQNCg0K