Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwfTu-00035i-3U; Mon, 26 Nov 2007 10:02:42 -0500 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1IvD38-0000Wi-R4 for pmol-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 09:29:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvD38-0000UX-Fc for pmol@ietf.org; Thu, 22 Nov 2007 09:29:02 -0500 Received: from newdev.eecs.harvard.edu ([140.247.60.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvD35-00029h-7P for pmol@ietf.org; Thu, 22 Nov 2007 09:29:02 -0500 Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id 97FB96518A6; Thu, 22 Nov 2007 09:28:13 -0500 (EST) To: henk@ripe.net, lars.eggert@nokia.com Subject: Re: [PMOL] Draft Agenda for PMOL at IETF-70 In-Reply-To: <47458A79.9070504@ripe.net> Message-Id: <20071122142813.97FB96518A6@newdev.eecs.harvard.edu> Date: Thu, 22 Nov 2007 09:28:13 -0500 (EST) From: sob@harvard.edu (Scott O. Bradner) X-Spam-Score: 1.8 (+) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db X-Mailman-Approved-At: Mon, 26 Nov 2007 10:02:40 -0500 Cc: zin@jaist.ac.jp, ted.a.seely@sprint.com, ogashiwa@noware.co.jp, rbonica@juniper.net, satoru@ft.solteria.net, sob@harvard.edu, nagami@inetcore.com, pmol@ietf.org X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pmol-bounces@ietf.org > This draft deals with passive measurements at a higher layer not all that passive Scott _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwRFK-0005j5-K3; Sun, 25 Nov 2007 18:50:42 -0500 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1IwRFJ-0005iy-TW for pmol-confirm+ok@megatron.ietf.org; Sun, 25 Nov 2007 18:50:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwRFJ-0005io-IN for pmol@ietf.org; Sun, 25 Nov 2007 18:50:41 -0500 Received: from umi.kikuken.org ([202.126.16.27] helo=ari.kikuken.org) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IwRFI-0005pT-6n for pmol@ietf.org; Sun, 25 Nov 2007 18:50:40 -0500 Received: (qmail 11893 invoked from network); 26 Nov 2007 08:50:37 +0900 Received: from unknown (HELO localhost) (218.100.15.124) by umi.kikuken.org with SMTP; 26 Nov 2007 08:50:37 +0900 Date: Mon, 26 Nov 2007 08:50:50 +0900 (JST) Message-Id: <20071126.085050.166543582.yu@kikuken.org> To: lars.eggert@nokia.com Subject: Re: [PMOL] Draft Agenda for PMOL at IETF-70 From: KIKUCHI Yutaka In-Reply-To: <7C27ED83-0B18-4E5C-B314-CF7895101232@nokia.com> References: <20071122.125514.34369847.yu@kikuken.org> <7C27ED83-0B18-4E5C-B314-CF7895101232@nokia.com> Organization: Kochi Univ. of Tech. X-Mailer: Mew version 4.2.53 on Emacs 22.0.50 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: zin@jaist.ac.jp, ted.a.seely@sprint.com, ogashiwa@noware.co.jp, rbonica@juniper.net, satoru@ft.solteria.net, pmol@ietf.org, nagami@inetcore.com, sob@harvard.edu X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pmol-bounces@ietf.org Lars-san, good morning from Japn. > > I think our approach is very different from IPPMs'. > > Our intention is to maintain all of tunnel flows in operation > > to check continuously the SLAs of the flows. > > > > The measurment method should be very light-weight and scalable. > > This is the top priority to deploy. > > The metrics depend on less resource situation. > > It is not much argurable how the metrics should be. > > > > Also, the method must be passive. > > IPPM seems not to deal with passive measurement. > > This is all well and good, but IPPM is *the* working group that > defines metrics for IP paths. Starting work in the same space in > another WG is not going to be productive. I do agree with the last sentence, but I do not agree with the second last sentence because our proposals should be discussed in the operational sense. A typical use case of the drafts is... 0. operators in an xSP or an iDC... 1. after setting up for watching every one of flows to servers, 2. while working with other tasks and listening music with iPod, 3. getting an alarm on a failure of some tunnels, and 4. checking the reason whether equipment fault, route changed or the other. 5. The xSP will refund money according as the SLA and the measured quality. I think such the scenario is much different from the IPPM color. > If IPPM isn't currently chartered to work on the kinds of solutions > that you require, there is an established process for proposing to > recharter working groups. If your proposal fails to see traction in > IPPM for other reasons, you'd do well to review the comments you > receive in order to improve your proposal. > > In addition, we already asked the IPPM mailing list about the draft, > > according to a suggestion from Dan in 68th Czech IETF, > > and we got a following answer from the IPPM chairs after 69th IETF. > > http://www1.ietf.org/mail-archive/web/ippm/current/msg01196.html > > That message was sent at a time when the exact scope of PMOL was yet > to be defined. Now it has been defined, and focuses on > > (... the) development of performance metrics for IP-based > protocols and > applications that operate over UDP, TCP, SCTP, DCCP, Forward Error > Correction (FEC) and other robust transport protocols, and that > can be > used to characterize traffic on live networks. > > A metric to quantify packet sequentiality for tunneled flows doesn't > fall into this charter, IMO. Does "... development of PM for IP-based protolcols ..." include? I think our draft is in the target range. Anyway I knew PMOL does not handle new proposals in the current charter. -- Yu. _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvDtC-0008Ih-1G; Thu, 22 Nov 2007 10:22:50 -0500 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1IvDtA-0008IP-Tw for pmol-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 10:22:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvDtA-0008IE-Jy for pmol@ietf.org; Thu, 22 Nov 2007 10:22:48 -0500 Received: from umi.kikuken.org ([202.126.16.27] helo=ari.kikuken.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IvDt6-000433-LK for pmol@ietf.org; Thu, 22 Nov 2007 10:22:48 -0500 Received: (qmail 29137 invoked from network); 23 Nov 2007 00:22:42 +0900 Received: from unknown (HELO localhost) (218.100.15.124) by umi.kikuken.org with SMTP; 23 Nov 2007 00:22:42 +0900 Date: Fri, 23 Nov 2007 00:22:47 +0900 (JST) Message-Id: <20071123.002247.03156804.yu@kikuken.org> To: sob@harvard.edu Subject: Re: [PMOL] Draft Agenda for PMOL at IETF-70 From: KIKUCHI Yutaka In-Reply-To: <20071122142813.97FB96518A6@newdev.eecs.harvard.edu> References: <47458A79.9070504@ripe.net> <20071122142813.97FB96518A6@newdev.eecs.harvard.edu> Organization: Kochi Univ. of Tech. X-Mailer: Mew version 4.2.53 on Emacs 22.0.50 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: zin@jaist.ac.jp, ted.a.seely@sprint.com, ogashiwa@noware.co.jp, rbonica@juniper.net, pmol@ietf.org, nagami@inetcore.com, satoru@ft.solteria.net X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pmol-bounces@ietf.org > > This draft deals with passive measurements at a higher layer > > not all that passive > > Scott It is completely passive. Folks, see also the OPSAWG mailing list now discussing about the issue. -- Yu. _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCXU-0005J8-I0; Thu, 22 Nov 2007 08:56:20 -0500 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1IvCXT-0005Ag-An for pmol-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 08:56:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCXS-00055V-QC for pmol@ietf.org; Thu, 22 Nov 2007 08:56:18 -0500 Received: from postboy.ripe.net ([193.0.19.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvCXP-00018N-22 for pmol@ietf.org; Thu, 22 Nov 2007 08:56:18 -0500 Received: by postboy.ripe.net (Postfix, from userid 4008) id 621F36A13C; Thu, 22 Nov 2007 14:56:14 +0100 (CET) Received: from herring.ripe.net (herring.ripe.net [193.0.1.203]) by postboy.ripe.net (Postfix) with ESMTP id EF1766A288; Thu, 22 Nov 2007 14:56:12 +0100 (CET) Received: from RIPE-NCC-101045.local (gw.office.nsrp.ripe.net [193.0.1.126]) by herring.ripe.net (Postfix) with ESMTP id BBBA22F583; Thu, 22 Nov 2007 14:56:12 +0100 (CET) Message-ID: <47458A79.9070504@ripe.net> Date: Thu, 22 Nov 2007 14:56:09 +0100 From: Henk Uijterwaal User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Lars Eggert Subject: Re: [PMOL] Draft Agenda for PMOL at IETF-70 References: <20071121.052648.15829104.yu@kikuken.org> <2AFC89C9-C28D-4430-AB2C-D79490AA3CD6@nokia.com> <20071122.125514.34369847.yu@kikuken.org> <7C27ED83-0B18-4E5C-B314-CF7895101232@nokia.com> In-Reply-To: <7C27ED83-0B18-4E5C-B314-CF7895101232@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000000 / -4.4 X-RIPE-Signature: c42c19269dd32c8ebc7e3da5a3db9fd8 X-Spam-Score: -8.0 (--------) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: zin@jaist.ac.jp, ted.a.seely@sprint.com, ogashiwa@noware.co.jp, rbonica@juniper.net, satoru@ft.solteria.net, pmol@ietf.org, nagami@inetcore.com, sob@harvard.edu X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pmol-bounces@ietf.org Hi, > That message was sent at a time when the exact scope of PMOL was yet to > be defined. Now it has been defined, [...] > A metric to quantify packet sequentiality for tunneled flows doesn't > fall into this charter, IMO. So it looks like we have a problem. Right now, IPPM focusses on active measurements at the IP layer. This draft deals with passive measurements at a higher layer and thus doesn't fit into IPPM. It also doesn't fit into PMOL. I do think that it is a good draft though, so I think we have to find a place for it. \ Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Is one of the choices leaving the office open? Alan Greenspan on the next elections _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv8bZ-0005mW-Rq; Thu, 22 Nov 2007 04:44:17 -0500 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1Iv8bY-0005mG-QE for pmol-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 04:44:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv8bT-0005fy-CU for pmol@ietf.org; Thu, 22 Nov 2007 04:44:11 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iv8bQ-0001B3-Ld for pmol@ietf.org; Thu, 22 Nov 2007 04:44:11 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lAM9hiaP010560; Thu, 22 Nov 2007 11:43:53 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Nov 2007 11:43:33 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Nov 2007 11:43:33 +0200 Received: from esdhcp036138.research.nokia.com (esdhcp036138.research.nokia.com [172.21.36.138]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lAM9hNUq004165; Thu, 22 Nov 2007 11:43:24 +0200 Message-Id: <7C27ED83-0B18-4E5C-B314-CF7895101232@nokia.com> From: Lars Eggert To: ext KIKUCHI Yutaka In-Reply-To: <20071122.125514.34369847.yu@kikuken.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [PMOL] Draft Agenda for PMOL at IETF-70 Date: Thu, 22 Nov 2007 11:43:22 +0200 References: <20071121.052648.15829104.yu@kikuken.org> <2AFC89C9-C28D-4430-AB2C-D79490AA3CD6@nokia.com> <20071122.125514.34369847.yu@kikuken.org> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 22 Nov 2007 09:43:33.0670 (UTC) FILETIME=[25B6CC60:01C82CEC] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: zin@jaist.ac.jp, ted.a.seely@sprint.com, ogashiwa@noware.co.jp, rbonica@juniper.net, satoru@ft.solteria.net, pmol@ietf.org, nagami@inetcore.com, sob@harvard.edu X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pmol-bounces@ietf.org Hi, On 2007-11-22, at 5:55, ext KIKUCHI Yutaka wrote: > I think our approach is very different from IPPMs'. > Our intention is to maintain all of tunnel flows in operation > to check continuously the SLAs of the flows. > > The measurment method should be very light-weight and scalable. > This is the top priority to deploy. > The metrics depend on less resource situation. > It is not much argurable how the metrics should be. > > Also, the method must be passive. > IPPM seems not to deal with passive measurement. This is all well and good, but IPPM is *the* working group that defines metrics for IP paths. Starting work in the same space in another WG is not going to be productive. If IPPM isn't currently chartered to work on the kinds of solutions that you require, there is an established process for proposing to recharter working groups. If your proposal fails to see traction in IPPM for other reasons, you'd do well to review the comments you receive in order to improve your proposal. > In addition, we already asked the IPPM mailing list about the draft, > according to a suggestion from Dan in 68th Czech IETF, > and we got a following answer from the IPPM chairs after 69th IETF. > http://www1.ietf.org/mail-archive/web/ippm/current/msg01196.html That message was sent at a time when the exact scope of PMOL was yet to be defined. Now it has been defined, and focuses on (... the) development of performance metrics for IP-based protocols and applications that operate over UDP, TCP, SCTP, DCCP, Forward Error Correction (FEC) and other robust transport protocols, and that can be used to characterize traffic on live networks. A metric to quantify packet sequentiality for tunneled flows doesn't fall into this charter, IMO. Lars _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv39s-0006Ex-Hc; Wed, 21 Nov 2007 22:55:20 -0500 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1Iv39r-00066m-2h for pmol-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 22:55:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv39q-00063W-M1 for pmol@ietf.org; Wed, 21 Nov 2007 22:55:18 -0500 Received: from umi.kikuken.org ([202.126.16.27] helo=ari.kikuken.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Iv39m-00067e-7T for pmol@ietf.org; Wed, 21 Nov 2007 22:55:18 -0500 Received: (qmail 24552 invoked from network); 22 Nov 2007 12:55:12 +0900 Received: from unknown (HELO localhost) (218.100.15.124) by umi.kikuken.org with SMTP; 22 Nov 2007 12:55:12 +0900 Date: Thu, 22 Nov 2007 12:55:14 +0900 (JST) Message-Id: <20071122.125514.34369847.yu@kikuken.org> To: dromasca@avaya.com Subject: Re: [PMOL] Draft Agenda for PMOL at IETF-70 From: KIKUCHI Yutaka In-Reply-To: References: <20071121.052648.15829104.yu@kikuken.org> <2AFC89C9-C28D-4430-AB2C-D79490AA3CD6@nokia.com> Organization: Kochi Univ. of Tech. X-Mailer: Mew version 4.2.53 on Emacs 22.0.50 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: zin@jaist.ac.jp, ted.a.seely@sprint.com, ogashiwa@noware.co.jp, rbonica@juniper.net, satoru@ft.solteria.net, pmol@ietf.org, nagami@inetcore.com, sob@harvard.edu X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pmol-bounces@ietf.org Lars-san, Dan-san, Thank you very much for the help to find suitable place. I think our approach is very different from IPPMs'. Our intention is to maintain all of tunnel flows in operation to check continuously the SLAs of the flows. The measurment method should be very light-weight and scalable. This is the top priority to deploy. The metrics depend on less resource situation. It is not much argurable how the metrics should be. Also, the method must be passive. IPPM seems not to deal with passive measurement. In addition, we already asked the IPPM mailing list about the draft, according to a suggestion from Dan in 68th Czech IETF, and we got a following answer from the IPPM chairs after 69th IETF. http://www1.ietf.org/mail-archive/web/ippm/current/msg01196.html -- still in a floating boat (*_*), Yu. > > > I would agree that IPPM may be a better place to discuss this draft, as > IPPM metrics apply to a large extend already to what is being proposed. > The question of using IPPM metrics at the ends of the tunnel was already > raised I believe in the OPSAWG when this was presented first. > > Dan > > > > > -----Original Message----- > > From: Lars Eggert [mailto:lars.eggert@nokia.com] > > Sent: Wednesday, November 21, 2007 11:39 AM > > To: ext KIKUCHI Yutaka > > Cc: zin@jaist.ac.jp; ogashiwa@noware.co.jp; > > rbonica@juniper.net; satoru@ft.solteria.net; pmol@ietf.org; > > nagami@inetcore.com > > Subject: Re: [PMOL] Draft Agenda for PMOL at IETF-70 > > > > On 2007-11-20, at 22:26, ext KIKUCHI Yutaka wrote: > > > May I have a slot to discuss an I-D for tunnel measurement? > > > > > > 4. One-way Passive Measurement of End-to-End Quality (Yutaka) > > > > > http://www.ietf.org/internet-drafts/draft-kikuchi-passive-measure-01.t > > > xt > > > > > > I had presented the -00 version in OPSAWG at the last IETF, > > but it is > > > more adapted to discuss in PMOL than in OPSAWG. > > > > Given that tunnels can be a part of an IP path, I'd think > > that this draft would be in scope of IPPM, rather than PMOL > > or OPSAWG. Even more so, because some of the metrics you > > define for a tunnel seem to overlap with metrics IPPM has > > already defined for IP paths. > > > > Lars > > > > > > _______________________________________________ > > PMOL mailing list > > PMOL@ietf.org > > https://www1.ietf.org/mailman/listinfo/pmol > > > _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iumm5-0000Dm-4T; Wed, 21 Nov 2007 05:25:41 -0500 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1Iumm4-0000Cy-6q for pmol-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 05:25:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iumm3-0000Ck-PA for pmol@ietf.org; Wed, 21 Nov 2007 05:25:39 -0500 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iumlz-0007o0-Be for pmol@ietf.org; Wed, 21 Nov 2007 05:25:39 -0500 X-IronPort-AV: E=Sophos;i="4.21,445,1188792000"; d="scan'208";a="85563713" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 21 Nov 2007 05:25:34 -0500 X-IronPort-AV: E=Sophos;i="4.21,445,1188792000"; d="scan'208";a="126988629" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 21 Nov 2007 05:24:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PMOL] Draft Agenda for PMOL at IETF-70 Date: Wed, 21 Nov 2007 11:24:44 +0100 Message-ID: In-Reply-To: <2AFC89C9-C28D-4430-AB2C-D79490AA3CD6@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PMOL] Draft Agenda for PMOL at IETF-70 Thread-Index: AcgsInlZAd08196ZR3mz8ptEfL7BlQABRdCQ References: <200711201738.lAKHcPVF000715@flph023.ffdc.sbc.com><20071121.052648.15829104.yu@kikuken.org> <2AFC89C9-C28D-4430-AB2C-D79490AA3CD6@nokia.com> From: "Romascanu, Dan (Dan)" To: "Lars Eggert" , "ext KIKUCHI Yutaka" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: zin@jaist.ac.jp, ted.a.seely@sprint.com, ogashiwa@noware.co.jp, rbonica@juniper.net, satoru@ft.solteria.net, pmol@ietf.org, nagami@inetcore.com, "Scott O. Bradner" X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pmol-bounces@ietf.org I would agree that IPPM may be a better place to discuss this draft, as IPPM metrics apply to a large extend already to what is being proposed. The question of using IPPM metrics at the ends of the tunnel was already raised I believe in the OPSAWG when this was presented first.=20 Dan =20 > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 > Sent: Wednesday, November 21, 2007 11:39 AM > To: ext KIKUCHI Yutaka > Cc: zin@jaist.ac.jp; ogashiwa@noware.co.jp;=20 > rbonica@juniper.net; satoru@ft.solteria.net; pmol@ietf.org;=20 > nagami@inetcore.com > Subject: Re: [PMOL] Draft Agenda for PMOL at IETF-70 >=20 > On 2007-11-20, at 22:26, ext KIKUCHI Yutaka wrote: > > May I have a slot to discuss an I-D for tunnel measurement? > > > > 4. One-way Passive Measurement of End-to-End Quality (Yutaka)=20 > >=20 > http://www.ietf.org/internet-drafts/draft-kikuchi-passive-measure-01.t > > xt > > > > I had presented the -00 version in OPSAWG at the last IETF,=20 > but it is=20 > > more adapted to discuss in PMOL than in OPSAWG. >=20 > Given that tunnels can be a part of an IP path, I'd think=20 > that this draft would be in scope of IPPM, rather than PMOL=20 > or OPSAWG. Even more so, because some of the metrics you=20 > define for a tunnel seem to overlap with metrics IPPM has=20 > already defined for IP paths. >=20 > Lars >=20 >=20 > _______________________________________________ > PMOL mailing list > PMOL@ietf.org > https://www1.ietf.org/mailman/listinfo/pmol >=20 _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ium3g-00025h-MG; Wed, 21 Nov 2007 04:39:48 -0500 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1Ium3f-00025c-F0 for pmol-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 04:39:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ium3a-00021R-2Z for pmol@ietf.org; Wed, 21 Nov 2007 04:39:42 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ium3U-0006Rd-GG for pmol@ietf.org; Wed, 21 Nov 2007 04:39:42 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lAL9dHUu007347; Wed, 21 Nov 2007 11:39:20 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 11:39:16 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 11:39:15 +0200 Received: from esdhcp03514.research.nokia.com (esdhcp03514.research.nokia.com [172.21.35.14]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lAL9d10l021789; Wed, 21 Nov 2007 11:39:04 +0200 Message-Id: <2AFC89C9-C28D-4430-AB2C-D79490AA3CD6@nokia.com> From: Lars Eggert To: ext KIKUCHI Yutaka In-Reply-To: <20071121.052648.15829104.yu@kikuken.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [PMOL] Draft Agenda for PMOL at IETF-70 Date: Wed, 21 Nov 2007 11:39:02 +0200 References: <200711201738.lAKHcPVF000715@flph023.ffdc.sbc.com> <20071121.052648.15829104.yu@kikuken.org> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 21 Nov 2007 09:39:15.0873 (UTC) FILETIME=[61A45910:01C82C22] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: zin@jaist.ac.jp, ogashiwa@noware.co.jp, rbonica@juniper.net, satoru@ft.solteria.net, pmol@ietf.org, nagami@inetcore.com X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pmol-bounces@ietf.org On 2007-11-20, at 22:26, ext KIKUCHI Yutaka wrote: > May I have a slot to discuss an I-D for tunnel measurement? > > 4. One-way Passive Measurement of End-to-End Quality (Yutaka) > http://www.ietf.org/internet-drafts/draft-kikuchi-passive-measure-01.txt > > I had presented the -00 version in OPSAWG at the last IETF, > but it is more adapted to discuss in PMOL than in OPSAWG. Given that tunnels can be a part of an IP path, I'd think that this draft would be in scope of IPPM, rather than PMOL or OPSAWG. Even more so, because some of the metrics you define for a tunnel seem to overlap with metrics IPPM has already defined for IP paths. Lars _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iub1D-0005iD-0S; Tue, 20 Nov 2007 16:52:31 -0500 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1Iub1B-0005i1-4K for pmol-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 16:52:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iub1A-0005hs-Qp for pmol@ietf.org; Tue, 20 Nov 2007 16:52:28 -0500 Received: from umi.kikuken.org ([202.126.16.27] helo=ari.kikuken.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Iub16-00046u-Lc for pmol@ietf.org; Tue, 20 Nov 2007 16:52:28 -0500 Received: (qmail 16579 invoked from network); 21 Nov 2007 06:52:22 +0900 Received: from unknown (HELO localhost) (218.100.15.124) by umi.kikuken.org with SMTP; 21 Nov 2007 06:52:22 +0900 Date: Wed, 21 Nov 2007 06:51:56 +0900 (JST) Message-Id: <20071121.065156.91285733.yu@kikuken.org> To: acmorton@att.com Subject: Re: [PMOL] Draft Agenda for PMOL at IETF-70 From: KIKUCHI Yutaka In-Reply-To: <200711202044.lAKKih0P022960@mlph070.sfdc.sbc.com> References: <200711201738.lAKHcPVF000715@flph023.ffdc.sbc.com> <20071121.052648.15829104.yu@kikuken.org> <200711202044.lAKKih0P022960@mlph070.sfdc.sbc.com> Organization: Kochi Univ. of Tech. X-Mailer: Mew version 4.2.53 on Emacs 22.0.50 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: zin@jaist.ac.jp, ogashiwa@noware.co.jp, rbonica@juniper.net, satoru@ft.solteria.net, pmol@ietf.org, nagami@inetcore.com X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pmol-bounces@ietf.org Al, Thanks for the reply. How about preparing some slides to discuss the framework according to our experience, not for intending to discuss the metrics? -- Yu. > Yu, > > Sorry, but our charter says: > > >Discussion of new work proposals is strongly discouraged under the > >initial charter of the PMOL WG, except to advise a protocol > >development WG when they are evaluating a new work proposal for > >related performance metrics. > > However, if your experience working with the framework memo > has generated any constructive comments, please send them > to the list and/or bring them up during discussion at the meeting. > > Al > pmol co-chair > > At 03:26 PM 11/20/2007, KIKUCHI Yutaka wrote: > >Al, Alan, and Everyone, > > > >May I have a slot to discuss an I-D for tunnel measurement? > > > >4. One-way Passive Measurement of End-to-End Quality (Yutaka) > >http://www.ietf.org/internet-drafts/draft-kikuchi-passive-measure-01.txt > > > >I had presented the -00 version in OPSAWG at the last IETF, > >but it is more adapted to discuss in PMOL than in OPSAWG. > >The I-D includes a trial of metrics evaluation with > >draft-morton-perf-metrics-framework-00.txt (sorry for not 01.txt). > > > >Please see also the following I-D describing the requirements > >to measure tunnels. > > > >"Quality Measurement Requirements for Tunneling Protocols" > >http://www.ietf.org/internet-drafts/draft-kikuchi-tunnel-measure-req-02.txt > > > >-- Regards, Yu. > > > > > Folks, > > > > > > The draft agenda for our session in Vancouver is below. > > > > > > Future updates may be found here: > > > http://www3.ietf.org/proceedings/07dec/agenda/pmol.txt > > > > > > Al and Alan > > > co-chairs > > > > > > > > > Performance Metrics for Other Layers WG (pmol) > > > > > > THURSDAY, December 6, 2007 > > > 1300-1500 Afternoon Session I > > > Salon F OPS > > > > > > Co-Chairs: > > > Al Morton > > > Alan Clark > > > > > > Please help contribute to a successful meeting by reading the drafts > > > and references *before* we meet. > > > > > > AGENDA: Draft as of 11/20/2007 > > > > > > 0. Agenda Bashing > > > > > > 1. Brief overview of the PMOL charter (Chairs - Al) > > > http://www.ietf.org/html.charters/pmol-charter.html > > > > > > 2. Metrics Framework Draft (Alan) > > > > > http://www.ietf.org/internet-drafts/draft-morton-perf-metrics-framework-01.txt > > > > > > 3. SIP Performance Metrics Draft (Daryl) > > > http://www.ietf.org/internet-drafts/draft-malas-performance-metrics-07.txt > > > > > > 4. AOB > > > > > > > > > To offer comments on PMOL work in progress or the agenda itself, > > > please send email to: > > > > > > > > > > > > > > > > > > _______________________________________________ > > > PMOL mailing list > > > PMOL@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pmol > > > > > _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuZxq-0005yZ-38; Tue, 20 Nov 2007 15:44:58 -0500 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1IuZxo-0005wg-RD for pmol-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 15:44:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuZxo-0005wY-G5 for pmol@ietf.org; Tue, 20 Nov 2007 15:44:56 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuZxo-0003MU-16 for pmol@ietf.org; Tue, 20 Nov 2007 15:44:56 -0500 X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-13.tower-121.messagelabs.com!1195591492!24827079!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.128.149] Received: (qmail 25468 invoked from network); 20 Nov 2007 20:44:53 -0000 Received: from sbcsmtp9.sbc.com (HELO flph024.enaf.ffdc.sbc.com) (144.160.128.149) by server-13.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 20 Nov 2007 20:44:53 -0000 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph024.enaf.ffdc.sbc.com (8.14.0/8.14.0) with ESMTP id lAKKiqUp027465 for ; Tue, 20 Nov 2007 12:44:52 -0800 Received: from flph023.ffdc.sbc.com (flph023.ffdc.sbc.com [150.234.117.36]) by flph024.enaf.ffdc.sbc.com (8.14.0/8.14.0) with ESMTP id lAKKinoC027441 for ; Tue, 20 Nov 2007 12:44:49 -0800 Received: from ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph023.ffdc.sbc.com (8.14.0/8.14.0) with ESMTP id lAKKinK2013365 for ; Tue, 20 Nov 2007 12:44:49 -0800 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by flph023.ffdc.sbc.com (8.14.0/8.14.0) with ESMTP id lAKKihT9013320 for ; Tue, 20 Nov 2007 12:44:48 -0800 Message-Id: <200711202044.lAKKihT9013320@flph023.ffdc.sbc.com> Received: from acmt.att.com (acmt.mt.att.com[135.16.251.73](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20071120204443gw10010g89e>; Tue, 20 Nov 2007 20:44:43 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 20 Nov 2007 15:42:02 -0500 To: KIKUCHI Yutaka From: Al Morton Subject: Re: [PMOL] Draft Agenda for PMOL at IETF-70 In-Reply-To: <20071121.052648.15829104.yu@kikuken.org> References: <200711201738.lAKHcPVF000715@flph023.ffdc.sbc.com> <20071121.052648.15829104.yu@kikuken.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.5 (+) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: zin@jaist.ac.jp, ogashiwa@noware.co.jp, rbonica@juniper.net, satoru@ft.solteria.net, pmol@ietf.org, nagami@inetcore.com X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pmol-bounces@ietf.org Yu, Sorry, but our charter says: >Discussion of new work proposals is strongly discouraged under the >initial charter of the PMOL WG, except to advise a protocol >development WG when they are evaluating a new work proposal for >related performance metrics. However, if your experience working with the framework memo has generated any constructive comments, please send them to the list and/or bring them up during discussion at the meeting. Al pmol co-chair At 03:26 PM 11/20/2007, KIKUCHI Yutaka wrote: >Al, Alan, and Everyone, > >May I have a slot to discuss an I-D for tunnel measurement? > >4. One-way Passive Measurement of End-to-End Quality (Yutaka) >http://www.ietf.org/internet-drafts/draft-kikuchi-passive-measure-01.txt > >I had presented the -00 version in OPSAWG at the last IETF, >but it is more adapted to discuss in PMOL than in OPSAWG. >The I-D includes a trial of metrics evaluation with >draft-morton-perf-metrics-framework-00.txt (sorry for not 01.txt). > >Please see also the following I-D describing the requirements >to measure tunnels. > >"Quality Measurement Requirements for Tunneling Protocols" >http://www.ietf.org/internet-drafts/draft-kikuchi-tunnel-measure-req-02.txt > >-- Regards, Yu. > > > Folks, > > > > The draft agenda for our session in Vancouver is below. > > > > Future updates may be found here: > > http://www3.ietf.org/proceedings/07dec/agenda/pmol.txt > > > > Al and Alan > > co-chairs > > > > > > Performance Metrics for Other Layers WG (pmol) > > > > THURSDAY, December 6, 2007 > > 1300-1500 Afternoon Session I > > Salon F OPS > > > > Co-Chairs: > > Al Morton > > Alan Clark > > > > Please help contribute to a successful meeting by reading the drafts > > and references *before* we meet. > > > > AGENDA: Draft as of 11/20/2007 > > > > 0. Agenda Bashing > > > > 1. Brief overview of the PMOL charter (Chairs - Al) > > http://www.ietf.org/html.charters/pmol-charter.html > > > > 2. Metrics Framework Draft (Alan) > > > http://www.ietf.org/internet-drafts/draft-morton-perf-metrics-framework-01.txt > > > > 3. SIP Performance Metrics Draft (Daryl) > > http://www.ietf.org/internet-drafts/draft-malas-performance-metrics-07.txt > > > > 4. AOB > > > > > > To offer comments on PMOL work in progress or the agenda itself, > > please send email to: > > > > > > > > > > > > _______________________________________________ > > PMOL mailing list > > PMOL@ietf.org > > https://www1.ietf.org/mailman/listinfo/pmol > > _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuZgM-0004Z8-6t; Tue, 20 Nov 2007 15:26:54 -0500 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1IuZgL-0004Z3-Ki for pmol-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 15:26:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuZgK-0004Yo-QY for pmol@ietf.org; Tue, 20 Nov 2007 15:26:52 -0500 Received: from umi.kikuken.org ([202.126.16.27] helo=ari.kikuken.org) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IuZgJ-0002Ul-ID for pmol@ietf.org; Tue, 20 Nov 2007 15:26:52 -0500 Received: (qmail 4034 invoked from network); 21 Nov 2007 05:26:48 +0900 Received: from unknown (HELO localhost) (218.100.15.124) by umi.kikuken.org with SMTP; 21 Nov 2007 05:26:48 +0900 Date: Wed, 21 Nov 2007 05:26:48 +0900 (JST) Message-Id: <20071121.052648.15829104.yu@kikuken.org> To: acmorton@att.com Subject: Re: [PMOL] Draft Agenda for PMOL at IETF-70 From: KIKUCHI Yutaka In-Reply-To: <200711201738.lAKHcPVF000715@flph023.ffdc.sbc.com> References: <200711201738.lAKHcPVF000715@flph023.ffdc.sbc.com> Organization: Kochi Univ. of Tech. X-Mailer: Mew version 4.2.53 on Emacs 22.0.50 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: zin@jaist.ac.jp, ogashiwa@noware.co.jp, rbonica@juniper.net, satoru@ft.solteria.net, pmol@ietf.org, nagami@inetcore.com X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pmol-bounces@ietf.org Al, Alan, and Everyone, May I have a slot to discuss an I-D for tunnel measurement? 4. One-way Passive Measurement of End-to-End Quality (Yutaka) http://www.ietf.org/internet-drafts/draft-kikuchi-passive-measure-01.txt I had presented the -00 version in OPSAWG at the last IETF, but it is more adapted to discuss in PMOL than in OPSAWG. The I-D includes a trial of metrics evaluation with draft-morton-perf-metrics-framework-00.txt (sorry for not 01.txt). Please see also the following I-D describing the requirements to measure tunnels. "Quality Measurement Requirements for Tunneling Protocols" http://www.ietf.org/internet-drafts/draft-kikuchi-tunnel-measure-req-02.txt -- Regards, Yu. > Folks, > > The draft agenda for our session in Vancouver is below. > > Future updates may be found here: > http://www3.ietf.org/proceedings/07dec/agenda/pmol.txt > > Al and Alan > co-chairs > > > Performance Metrics for Other Layers WG (pmol) > > THURSDAY, December 6, 2007 > 1300-1500 Afternoon Session I > Salon F OPS > > Co-Chairs: > Al Morton > Alan Clark > > Please help contribute to a successful meeting by reading the drafts > and references *before* we meet. > > AGENDA: Draft as of 11/20/2007 > > 0. Agenda Bashing > > 1. Brief overview of the PMOL charter (Chairs - Al) > http://www.ietf.org/html.charters/pmol-charter.html > > 2. Metrics Framework Draft (Alan) > http://www.ietf.org/internet-drafts/draft-morton-perf-metrics-framework-01.txt > > 3. SIP Performance Metrics Draft (Daryl) > http://www.ietf.org/internet-drafts/draft-malas-performance-metrics-07.txt > > 4. AOB > > > To offer comments on PMOL work in progress or the agenda itself, > please send email to: > > > > > > _______________________________________________ > PMOL mailing list > PMOL@ietf.org > https://www1.ietf.org/mailman/listinfo/pmol > _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuX4a-00086J-Cj; Tue, 20 Nov 2007 12:39:44 -0500 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1IuX4Z-00082Z-9O for pmol-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 12:39:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuX4T-0007qg-4D for pmol@ietf.org; Tue, 20 Nov 2007 12:39:37 -0500 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuX4O-0001KN-WE for pmol@ietf.org; Tue, 20 Nov 2007 12:39:37 -0500 X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-9.tower-120.messagelabs.com!1195580322!26810951!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.128.149] Received: (qmail 11532 invoked from network); 20 Nov 2007 17:38:42 -0000 Received: from sbcsmtp9.sbc.com (HELO flph024.enaf.ffdc.sbc.com) (144.160.128.149) by server-9.tower-120.messagelabs.com with AES256-SHA encrypted SMTP; 20 Nov 2007 17:38:42 -0000 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph024.enaf.ffdc.sbc.com (8.14.0/8.14.0) with ESMTP id lAKHcfBk011928 for ; Tue, 20 Nov 2007 09:38:41 -0800 Received: from flph023.ffdc.sbc.com (flph023.ffdc.sbc.com [150.234.117.36]) by flph024.enaf.ffdc.sbc.com (8.14.0/8.14.0) with ESMTP id lAKHcadU011848 for ; Tue, 20 Nov 2007 09:38:36 -0800 Received: from ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph023.ffdc.sbc.com (8.14.0/8.14.0) with ESMTP id lAKHcaDt000848 for ; Tue, 20 Nov 2007 09:38:36 -0800 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by flph023.ffdc.sbc.com (8.14.0/8.14.0) with ESMTP id lAKHcPVF000715 for ; Tue, 20 Nov 2007 09:38:30 -0800 Message-Id: <200711201738.lAKHcPVF000715@flph023.ffdc.sbc.com> Received: from acmt.att.com (acmt.mt.att.com[135.16.251.73](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20071120173824gw10010g5pe>; Tue, 20 Nov 2007 17:38:24 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 20 Nov 2007 12:35:47 -0500 To: pmol@ietf.org From: Al Morton Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.5 (--) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Ron Bonica Subject: [PMOL] Draft Agenda for PMOL at IETF-70 X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pmol-bounces@ietf.org Folks, The draft agenda for our session in Vancouver is below. Future updates may be found here: http://www3.ietf.org/proceedings/07dec/agenda/pmol.txt Al and Alan co-chairs Performance Metrics for Other Layers WG (pmol) THURSDAY, December 6, 2007 1300-1500 Afternoon Session I Salon F OPS Co-Chairs: Al Morton Alan Clark Please help contribute to a successful meeting by reading the drafts and references *before* we meet. AGENDA: Draft as of 11/20/2007 0. Agenda Bashing 1. Brief overview of the PMOL charter (Chairs - Al) http://www.ietf.org/html.charters/pmol-charter.html 2. Metrics Framework Draft (Alan) http://www.ietf.org/internet-drafts/draft-morton-perf-metrics-framework-01.txt 3. SIP Performance Metrics Draft (Daryl) http://www.ietf.org/internet-drafts/draft-malas-performance-metrics-07.txt 4. AOB To offer comments on PMOL work in progress or the agenda itself, please send email to: _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IslNO-0004mY-8l; Thu, 15 Nov 2007 15:31:50 -0500 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1IskLP-0006df-Jr for pmol-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 14:25:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IskLP-0006dC-8K; Thu, 15 Nov 2007 14:25:43 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IskLO-0004dH-P9; Thu, 15 Nov 2007 14:25:43 -0500 Received: from [128.9.160.144] (nib.isi.edu [128.9.160.144]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lAFJNLp6024643; Thu, 15 Nov 2007 11:23:21 -0800 (PST) Message-ID: <473C9CA8.3090403@isi.edu> Date: Thu, 15 Nov 2007 11:23:20 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Stephen Kent Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)] References: <47263CC1.8000104@thinkingcat.com> <473B0B7E.1030803@isi.edu> <20071114223258.30bb5f35@cs.columbia.edu> <473B9213.3090805@isi.edu> <473BEA75.7080505@isi.edu> <20071115135323.1b437d77@berkshire.machshav.com> <473C5935.2020409@isi.edu> In-Reply-To: X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 X-Mailman-Approved-At: Thu, 15 Nov 2007 15:31:49 -0500 Cc: Leslie Daigle , ietf@ietf.org, pmol@ietf.org, "Steven M. Bellovin" , IESG , Sam Hartman X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1747443889==" Errors-To: pmol-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1747443889== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0202F822B24C50C02C204C9F" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0202F822B24C50C02C204C9F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Stephen Kent wrote: > Joe, >=20 > This discussion seems to have moved from a discussion of crypto use on= > home/office computers, to use in routers. There is no good motivation > for other than edge (CPE?) routers to make use of IPsec for subscriber > traffic. BGP... > use of IPsec to > protect BGP is a non-starter, because of where in the router the > processing would be done (given current router designs). Yes - and that was the punchline that performance does matter. > In any case, > use of IPsec by routers is a very different topic that use in > home/office computers and ought not be brought into this discussion. They are two different things, agreed. > As for the original topic, yes, performance hits come in various flavor= s > when we discuss crypto protocol use. For example, there was a good pape= r > at NDSS a few years ago that showed how "marshalling" of data in SSL > implementations was a very big partFrom pmol-bounces@ietf.org Thu Nov 15 15:31:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IslNO-0004mY-8l; Thu, 15 Nov 2007 15:31:50 -0500 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1IskLP-0006df-Jr for pmol-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 14:25:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IskLP-0006dC-8K; Thu, 15 Nov 2007 14:25:43 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IskLO-0004dH-P9; Thu, 15 Nov 2007 14:25:43 -0500 Received: from [128.9.160.144] (nib.isi.edu [128.9.160.144]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lAFJNLp6024643; Thu, 15 Nov 2007 11:23:21 -0800 (PST) Message-ID: <473C9CA8.3090403@isi.edu> Date: Thu, 15 Nov 2007 11:23:20 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Stephen Kent Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)] References: <47263CC1.8000104@thinkingcat.com> <473B0B7E.1030803@isi.edu> <20071114223258.30bb5f35@cs.columbia.edu> <473B9213.3090805@isi.edu> <473BEA75.7080505@isi.edu> <20071115135323.1b437d77@berkshire.machshav.com> <473C5935.2020409@isi.edu> In-Reply-To: X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 X-Mailman-Approved-At: Thu, 15 Nov 2007 15:31:49 -0500 Cc: Leslie Daigle , ietf@ietf.org, pmol@ietf.org, "Steven M. Bellovin" , IESG , Sam Hartman X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1747443889==" Errors-To: pmol-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1747443889== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0202F822B24C50C02C204C9F" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0202F822B24C50C02C204C9F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Stephen Kent wrote: > Joe, >=20 > This discussion seems to have moved from a discussion of crypto use on= > home/office computers, to use in routers. There is no good motivation > for other than edge (CPE?) routers to make use of IPsec for subscriber > traffic. BGP... > use of IPsec to > protect BGP is a non-starter, because of where in the router the > processing would be done (given current router designs). Yes - and that was the punchline that performance does matter. > In any case, > use of IPsec by routers is a very different topic that use in > home/office computers and ought not be brought into this discussion. They are two different things, agreed. > As for the original topic, yes, performance hits come in various flavor= s > when we discuss crypto protocol use. For example, there was a good pape= r > at NDSS a few years ago that showed how "marshalling" of data in SSL > implementations was a very big part of the performance hit. Nonetheless= , > the bottom line is that for mainstream users, most of us are not > convinced that performance is the primary reason for not using crypto. If "us" means crypto folk, I agree. If "us" means the rest of us - who don't use crypto - I am not at all convinced. There are a variety of other communities who want to use security - high performance (grid, optiputer), enterprise (huge numbers of short connections), etc. They all have different reasons for not using crypto more, but writing off performance would be to continue a mistake. I've made that point clear; whether it's actually heard or not isn't something I have much control over, though. Joe --------------enig0202F822B24C50C02C204C9F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHPJyoE5f5cImnZrsRAircAKDYHndeC5vTZ5+7pCK0T8DWOpagPwCgkOqI 85WGck6wX0L6wxWKg1rETd8= =lZne -----END PGP SIGNATURE----- --------------enig0202F822B24C50C02C204C9F-- --===============1747443889== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol --===============1747443889==-- Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IslNO-0004mR-4y; Thu, 15 Nov 2007 15:31:50 -0500 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1Isjyc-0001oP-GS for pmol-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 14:02:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isjyb-0001n9-S4; Thu, 15 Nov 2007 14:02:09 -0500 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsjyY-0002jG-JJ; Thu, 15 Nov 2007 14:02:09 -0500 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IsjyV-0003yq-5r; Thu, 15 Nov 2007 14:02:04 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <473C5935.2020409@isi.edu> References: <47263CC1.8000104@thinkingcat.com> <473B0B7E.1030803@isi.edu> <20071114223258.30bb5f35@cs.columbia.edu> <473B9213.3090805@isi.edu> <473BEA75.7080505@isi.edu> <20071115135323.1b437d77@berkshire.machshav.com> <473C5935.2020409@isi.edu> Date: Thu, 15 Nov 2007 10:35:18 -0500 To: Joe Touch From: Stephen Kent Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)] Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 1.4 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-Mailman-Approved-At: Thu, 15 Nov 2007 15:31:49 -0500 Cc: Leslie Daigle , ietf@ietf.org, pmol@ietf.org, "Steven M. Bellovin" , IESG , Sam Hartman X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pmol-bounces@ietf.org Joe, This discussion seems to have of the performance hit. Nonetheless= , > the bottom line is that for mainstream users, most of us are not > convinced that performance is the primary reason for not using crypto. If "us" means crypto folk, I agree. If "us" means the rest of us - who don't use crypto - I am not at all convinced. There are a variety of other communities who want to use security - high performance (grid, optiputer), enterprise (huge numbers of short connections), etc. They all have different reasons for not using crypto more, but writing off performance would be to continue a mistake. I've made that point clear; whether it's actually heard or not isn't something I have much control over, though. Joe --------------enig0202F822B24C50C02C204C9F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHPJyoE5f5cImnZrsRAircAKDYHndeC5vTZ5+7pCK0T8DWOpagPwCgkOqI 85WGck6wX0L6wxWKg1rETd8= =lZne -----END PGP SIGNATURE----- --------------enig0202F822B24C50C02C204C9F-- --===============1747443889== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol --===============1747443889==-- Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IslNO-0004mR-4y; Thu, 15 Nov 2007 15:31:50 -0500 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1Isjyc-0001oP-GS for pmol-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 14:02:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isjyb-0001n9-S4; Thu, 15 Nov 2007 14:02:09 -0500 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsjyY-0002jG-JJ; Thu, 15 Nov 2007 14:02:09 -0500 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IsjyV-0003yq-5r; Thu, 15 Nov 2007 14:02:04 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <473C5935.2020409@isi.edu> References: <47263CC1.8000104@thinkingcat.com> <473B0B7E.1030803@isi.edu> <20071114223258.30bb5f35@cs.columbia.edu> <473B9213.3090805@isi.edu> <473BEA75.7080505@isi.edu> <20071115135323.1b437d77@berkshire.machshav.com> <473C5935.2020409@isi.edu> Date: Thu, 15 Nov 2007 10:35:18 -0500 To: Joe Touch From: Stephen Kent Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)] Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 1.4 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-Mailman-Approved-At: Thu, 15 Nov 2007 15:31:49 -0500 Cc: Leslie Daigle , ietf@ietf.org, pmol@ietf.org, "Steven M. Bellovin" , IESG , Sam Hartman X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pmol-bounces@ietf.org Joe, This discussion seems to have moved from a discussion of crypto use on home/office computers, to use in routers. There is no good motivation for other than edge (CPE?) routers to make use of IPsec for subscriber traffic. We know, from discussions with operators, that use of IPsec to protect BGP is a non-starter, because of where in the router the processing would be done (given current router designs). In any case, use of IPsec by routers is a very different topic that use in home/office computers and ought not be brought into this discussion. As for the original topic, yes, performance hits come in various flavors when we discuss crypto protocol use. For example, there was a good paper at NDSS a few years ago that showed how "marshalling" of data in SSL implementations was a very big part of the performance hit. Nonetheless, the bottom line is that for mainstream users, most of us are not convinced that performance is the primary reason for not using crypto. Steve _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol moved from a discussion of crypto use on home/office computers, to use in routers. There is no good motivation for other than edge (CPE?) routers to make use of IPsec for subscriber traffic. We know, from discussions with operators, that use of IPsec to protect BGP is a non-starter, because of where in the router the processing would be done (given current router designs). In any case, use of IPsec by routers is a very different topic that use in home/office computers and ought not be brought into this discussion. As for the original topic, yes, performance hits come in various flavors when we discuss crypto protocol use. For example, there was a good paper at NDSS a few years ago that showed how "marshalling" of data in SSL implementations was a very big part of the performance hit. Nonetheless, the bottom line is that for mainstream users, most of us are not convinced that performance is the primary reason for not using crypto. Steve _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsfyY-00076i-1H; Thu, 15 Nov 2007 09:45:50 -0500 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1IsfqL-0001er-96 for pmol-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 09:37:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsfqK-0001cY-QL; Thu, 15 Nov 2007 09:37:20 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsfqK-0006ug-9k; Thu, 15 Nov 2007 09:37:20 -0500 Received: from [192.168.1.46] (pool-71-106-88-149.lsanca.dsl-w.verizon.net [71.106.88.149]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lAFEZf3k029528; Thu, 15 Nov 2007 06:35:41 -0800 (PST) Message-ID: <473C5935.2020409@isi.edu> Date: Thu, 15 Nov 2007 06:35:33 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Steven M. Bellovin" Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)] References: <47263CC1.8000104@thinkingcat.com> <473B0B7E.1030803@isi.edu> <20071114223258.30bb5f35@cs.columbia.edu> <473B9213.3090805@isi.edu> <473BEA75.7080505@isi.edu> <20071115135323.1b437d77@berkshire.machshav.com> In-Reply-To: <20071115135323.1b437d77@berkshire.machshav.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 X-Mailman-Approved-At: Thu, 15 Nov 2007 09:45:49 -0500 Cc: Leslie Daigle , Stephen Kent , pmol@ietf.org, IESG , Sam Hartman , ietf@ietf.org X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0437301914==" Errors-To: pmol-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0437301914== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB68AF3FF37E87CBD2FA97F1E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB68AF3FF37E87CBD2FA97F1E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Steven M. Bellovin wrote: > On Wed, 14 Nov 2007 22:43:01 -0800 > Joe Touch wrote: >=20 >> Sam Hartman wrote: >> ... >>> Yes, Steve almost certanily did slow down any heavy CPU use during >>> the time when he was doing the backup. >>> >>> Our point--Steve, Steve and I--is that for a lot of uses and a lot >>> of users, no one cares. >> Perhaps that's why everyone is using security. We don't have a >> problem then. >> > I didn't say that; I said that performance generally isn't the issue. > Often, there's a *perception* of a performance issue, because once > there was. The bigger problem, in my opinion, is usability. *Lots* of > people use SSL, because they don't have to do anything. SSL as used in= > https has lots of problems I won't go into here, but it is excellent > protection against passive eavesdroppers. While I'm sure your anecdotal laptop measurements are valid, there are plenty of others who: - transfer large files over disks with more than 70Mbps of BW e.g., photos are now over 15MB/file, and videos larger - do enough with their CPU in the meantime that they would notice when the OS was sharing it - e.g., photoshop Why don't users turn on security on DSL lines? They do - VPNs, SSL, etc. Sure, various protocols still have problems, as you note, but security over low-speed links is largely a success story. Why don't core Internet routers have security? Note that some router vendors sell "IPv6" routers even though they don't come with IPsec HW, and don't put IPsec in SW -- even though it begs the question of what IPv6-IPsec should be called (IPv5.5?). Why? They do more than ASCII email when they're trying to send packets, have a SATA disk (even on laptops), and don't have - or want - CPU power to burn (or even to share 50/50) to hide a very real performance problem.= Performance problems come in many flavors: - per packet overhead - algorithmic overhead - keying overhead - policy lookup overhead All of these are real problems, and can cause performance to drop to a small fraction of what's capable without security. Hiding the problem with other debilitations hasn't made it go away. Joe --------------enigB68AF3FF37E87CBD2FA97F1E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHPFk7E5f5cImnZrsRAqRdAKDcvQpkDFejLkA1rBDDIcsZ1iv7sACeJhXe z9eN65K4k+un/yzuVrc96YU= =ExpY -----END PGP SIGNATURE----- --------------enigB68AF3FF37E87CBD2FA97F1E-- --===============0437301914== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol --===============0437301914==-- Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isfjb-0006dI-13; Thu, 15 Nov 2007 09:30:23 -0500 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1Isfil-0005pZ-7c for pmol-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 09:29:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isfik-0005pO-UE; Thu, 15 Nov 2007 09:29:30 -0500 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Isfih-0006MN-RS; Thu, 15 Nov 2007 09:29:30 -0500 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id lAFENNWV010432; Thu, 15 Nov 2007 06:23:25 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Nov 2007 14:26:51 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)] Date: Thu, 15 Nov 2007 06:26:50 -0800 Message-ID: <2788466ED3E31C418E9ACC5C316615570462D1@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)] Thread-Index: Acgnjti4SxnRF1hQQqmgRiOOZr45ggABLeQA From: "Hallam-Baker, Phillip" To: "Steven M. Bellovin" , "Joe Touch" X-OriginalArrivalTime: 15 Nov 2007 14:26:51.0334 (UTC) FILETIME=[90383E60:01C82793] X-Spam-Score: -4.0 (----) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e X-Mailman-Approved-At: Thu, 15 Nov 2007 09:30:22 -0500 Cc: Leslie Daigle , Stephen Kent , pmol@ietf.org, IESG , Sam Hartman , ietf@ietf.org X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1474084090==" Errors-To: pmol-bounces@ietf.org This is a multi-part message in MIME format. --===============1474084090== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C82793.8FC3454B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C82793.8FC3454B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am mostly in agreement with Steve but I find the premise somewhat odd. Crypto overhead is an issue for some applications but not so much at the = bulk end as the large number of small transactions end. Think web server = doing a thousand hits a second. Even that is manageable with crypto = accelerators and restart and such.=20 At the bulk end I would not see ssl as the ideal protocol for securing = distribution of online movies. Why would this be suprising? Why would we = expect one protocol to be optimal for every application? For a start I would probaby want to have a message layer encryption = scheme so that I only need to encrypt my file once, I would probably = want the crypto to support fast index lookup for chapter search and I = would probably want DRM features. The reason we use ssl for everything is because it is deployed and it is = easier to adapt a deployed protocol than build from scratch. I don't see the backup scenario as relevant either. Batch mode backup is = a legacy of the tape drive era. With tape drives and tapes costing an = order of magnitude more per gig than disk that era is over. If the = backup medium is disk volume shaddowing makes much more sense. Given that consumer targetted backup systems offering volume shaddowing = are available for just over $500 for a 500Gb system the batch mode = backup scenario is obsolete. Now if only the providers of that technology had thought about how I am = to protect my data against the house burning down... Sent from my GoodLink Wireless Handheld (www.good.com) -----Original Message----- From: Steven M. Bellovin [mailto:smb@cs.columbia.edu] Sent: Thursday, November 15, 2007 05:53 AM Pacific Standard Time To: Joe Touch Cc: Leslie Daigle; Stephen Kent; pmol@ietf.org; Romascanu, Dan (Dan); = IESG; Sam Hartman; ietf@ietf.org Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance = Metrics atOther Layers (pmol)] On Wed, 14 Nov 2007 22:43:01 -0800 Joe Touch wrote: > Sam Hartman wrote: > ... > > Yes, Steve almost certanily did slow down any heavy CPU use during > > the time when he was doing the backup. > >=20 > > Our point--Steve, Steve and I--is that for a lot of uses and a lot > > of users, no one cares. >=20 > Perhaps that's why everyone is using security. We don't have a > problem then. >=20 I didn't say that; I said that performance generally isn't the issue. Often, there's a *perception* of a performance issue, because once there was. The bigger problem, in my opinion, is usability. *Lots* of people use SSL, because they don't have to do anything. SSL as used in https has lots of problems I won't go into here, but it is excellent protection against passive eavesdroppers. --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ------_=_NextPart_001_01C82793.8FC3454B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [PMOL] Re: A question about [Fwd: WG Review: Performance = Metrics atOther Layers (pmol)]

I am mostly in agreement with Steve but I find the = premise somewhat odd.

Crypto overhead is an issue for some applications but not so much at the = bulk end as the large number of small transactions end. Think web server = doing a thousand hits a second. Even that is manageable with crypto = accelerators and restart and such.

At the bulk end I would not see ssl as the ideal protocol for securing = distribution of online movies. Why would this be suprising? Why would we = expect one protocol to be optimal for every application?

For a start I would probaby want to have a message layer encryption = scheme so that I only need to encrypt my file once, I would probably = want the crypto to support fast index lookup for chapter search and I = would probably want DRM features.

The reason we use ssl for everything is because it is deployed and it is = easier to adapt a deployed protocol than build from scratch.

I don't see the backup scenario as relevant either. Batch mode backup is = a legacy of the tape drive era. With tape drives and tapes costing an = order of magnitude more per gig than disk that era is over. If the = backup medium is disk volume shaddowing makes much more sense.

Given  that consumer targetted backup systems offering volume = shaddowing are available for just over $500 for a 500Gb system the batch = mode backup scenario is obsolete.

Now if only the providers of that technology had thought about how I am = to protect my data against the house burning down...


Sent from my GoodLink Wireless Handheld (www.good.com)

 -----Original Message-----
From:   Steven M. Bellovin [mailto:smb@cs.columbia.edu]
Sent:   Thursday, November 15, 2007 05:53 AM Pacific Standard = Time
To:     Joe Touch
Cc:     Leslie Daigle; Stephen Kent; pmol@ietf.org; = Romascanu, Dan (Dan); IESG; Sam Hartman; ietf@ietf.org
Subject:        Re: [PMOL] Re: A = question about [Fwd: WG Review: Performance Metrics  atOther Layers = (pmol)]

On Wed, 14 Nov 2007 22:43:01 -0800
Joe Touch <touch@ISI.EDU> wrote:

> Sam Hartman wrote:
> ...
> > Yes, Steve almost certanily did slow down any heavy CPU use = during
> > the time when he was doing the backup.
> >
> > Our point--Steve, Steve and I--is that for a lot of uses and a = lot
> > of users, no one cares.
>
> Perhaps that's why everyone is using security. We don't have a
> problem then.
>
I didn't say that; I said that performance generally isn't the = issue.
Often, there's a *perception* of a performance issue, because once
there was. The bigger problem, in my opinion, is usability.  *Lots* = of
people use SSL, because they don't have to do anything.  SSL as = used in
https has lots of problems I won't go into here, but it is excellent
protection against passive eavesdroppers.


        =         --Steve Bellovin, http://www.cs.columbia.edu/~smb<= /A>

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.or= g/mailman/listinfo/ietf

------_=_NextPart_001_01C82793.8FC3454B-- --===============1474084090== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol --===============1474084090==-- Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsfM2-00080B-Px; Thu, 15 Nov 2007 09:06:02 -0500 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1IsfA1-0000YQ-PM for pmol-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 08:53:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isf9v-0000FE-EX; Thu, 15 Nov 2007 08:53:31 -0500 Received: from machshav.com ([198.180.150.44]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Isf9v-0004dN-4p; Thu, 15 Nov 2007 08:53:31 -0500 Received: by machshav.com (Postfix, from userid 512) id B97A65A1; Thu, 15 Nov 2007 13:53:30 +0000 (GMT) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6EACC183; Thu, 15 Nov 2007 13:53:28 +0000 (GMT) Received: by berkshire.machshav.com (Postfix, from userid 54047) id BED36766186; Thu, 15 Nov 2007 08:53:23 -0500 (EST) Date: Thu, 15 Nov 2007 13:53:23 +0000 From: "Steven M. Bellovin" To: Joe Touch Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)] Message-ID: <20071115135323.1b437d77@berkshire.machshav.com> In-Reply-To: <473BEA75.7080505@isi.edu> References: <47263CC1.8000104@thinkingcat.com> <473B0B7E.1030803@isi.edu> <20071114223258.30bb5f35@cs.columbia.edu> <473B9213.3090805@isi.edu> <473BEA75.7080505@isi.edu> Organization: Columbia University X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.0; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Thu, 15 Nov 2007 09:06:01 -0500 Cc: Leslie Daigle , Stephen Kent , pmol@ietf.org, IESG , Sam Hartman , ietf@ietf.org X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pmol-bounces@ietf.org On Wed, 14 Nov 2007 22:43:01 -0800 Joe Touch wrote: > Sam Hartman wrote: > ... > > Yes, Steve almost certanily did slow down any heavy CPU use during > > the time when he was doing the backup. > > > > Our point--Steve, Steve and I--is that for a lot of uses and a lot > > of users, no one cares. > > Perhaps that's why everyone is using security. We don't have a > problem then. > I didn't say that; I said that performance generally isn't the issue. Often, there's a *perception* of a performance issue, because once there was. The bigger problem, in my opinion, is usability. *Lots* of people use SSL, because they don't have to do anything. SSL as used in https has lots of problems I won't go into here, but it is excellent protection against passive eavesdroppers. --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IscI5-0007pJ-Cv; Thu, 15 Nov 2007 05:49:45 -0500 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1IsYSA-0005WE-8Y for pmol-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 01:43:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsYS9-0005TJ-KE; Thu, 15 Nov 2007 01:43:53 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsYS9-0004Oa-8D; Thu, 15 Nov 2007 01:43:53 -0500 Received: from [192.168.1.46] (pool-71-106-88-149.lsanca.dsl-w.verizon.net [71.106.88.149]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lAF6h2EZ006707; Wed, 14 Nov 2007 22:43:02 -0800 (PST) Message-ID: <473BEA75.7080505@isi.edu> Date: Wed, 14 Nov 2007 22:43:01 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sam Hartman Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)] References: <47263CC1.8000104@thinkingcat.com> <473B0B7E.1030803@isi.edu> <20071114223258.30bb5f35@cs.columbia.edu> <473B9213.3090805@isi.edu> In-Reply-To: X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-Mailman-Approved-At: Thu, 15 Nov 2007 05:49:44 -0500 Cc: Leslie Daigle , Stephen Kent , pmol@ietf.org, "Steven M. Bellovin" , IESG , ietf@ietf.org X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0189919871==" Errors-To: pmol-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0189919871== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD0F53F625FE6C7F36FADD001" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD0F53F625FE6C7F36FADD001 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sam Hartman wrote: =2E.. > Yes, Steve almost certanily did slow down any heavy CPU use during the = time when he was doing the backup. >=20 > Our point--Steve, Steve and I--is that for a lot of uses and a lot of > users, no one cares. Perhaps that's why everyone is using security. We don't have a problem th= en. Joe --------------enigD0F53F625FE6C7F36FADD001 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHO+p1E5f5cImnZrsRAvptAKCTEM8iEM/e2qcsD9ycFUs3io8HYwCg9i6q jDcXZXHSQOSaQM1ST2T+H34= =xa8/ -----END PGP SIGNATURE----- --------------enigD0F53F625FE6C7F36FADD001-- --===============0189919871== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol --===============0189919871==-- Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IscI4-0007o4-TG; Thu, 15 Nov 2007 05:49:44 -0500 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1IsSZP-0000oJ-20 for pmol-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 19:26:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsSZO-0000o7-Mw; Wed, 14 Nov 2007 19:26:58 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsSZN-0001Si-PG; Wed, 14 Nov 2007 19:26:58 -0500 Received: from [75.214.48.228] (228.sub-75-214-48.myvzw.com [75.214.48.228]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lAF0PurB009414; Wed, 14 Nov 2007 16:25:57 -0800 (PST) Message-ID: <473B9213.3090805@isi.edu> Date: Wed, 14 Nov 2007 16:25:55 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Steven M. Bellovin" Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)] References: <47263CC1.8000104@thinkingcat.com> <473B0B7E.1030803@isi.edu> <20071114223258.30bb5f35@cs.columbia.edu> In-Reply-To: <20071114223258.30bb5f35@cs.columbia.edu> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.9 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 X-Mailman-Approved-At: Thu, 15 Nov 2007 05:49:44 -0500 Cc: Leslie Daigle , Stephen Kent , pmol@ietf.org, IESG , Sam Hartman , ietf@ietf.org X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1273663859==" Errors-To: pmol-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1273663859== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig09E0B0730573A9B5F5BDBEE1" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig09E0B0730573A9B5F5BDBEE1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Steve, Steven M. Bellovin wrote: > On Wed, 14 Nov 2007 15:39:50 -0500 > Stephen Kent wrote: >=20 >> Joe, >> >> I disagree with your suggestion "The software performance of security >> protocols has been the more substantial issue, and is likely to >> continue to be for the forseeable future." >> >> I suspect that most desktop users do not need hardware crypto for >> performance. Irarely if ever drive my GiGE interface at its line >> rate. With fast processors, especially multi-core processors, we have >> enough cycles to do symmetric crypto at data rates consistent with >> most application demands for individual users. Public key operations >> for key management are usually low duty cycle, so they too can be >> accommodated. >> > Thanks -- I was going to say something similar. I regularly back up my= > laptop's disk over a software-encrypted GigE link. The dump file > occupies about 35G of disk space; it takes about 70 minutes. Exclusive= > of protocol overhead, that comes to ~71M bps; given IP, TCP, and ssh, > I'd guess it's more like 75-80M bps. I also know that I can run ttcp > between that pair of machines at about 500M bps. Am I really suffering= > from a 7:1 performance hit from the crypto? Nope. By essentially shutting your machine down for over an hour. > I can't do controlled experiments right now, since the laptop and > server in question are currently about 350 km apart at the moment. >=20 > Dumping the disk to /dev/null took about 30 minutes. The maximum hit > I'm taking from the crypto, then, is about 2.3:1. The numbers I get are 3:1 for some protocols, worse for others, but the CPU hit is also substantial, vs. just taking time but not CPU to do the transfer. > Using the > performance numbers from 'openssl speed' for 1024-byte blocks for > AES-128 and SHA-1, the crypto is 23 minutes of CPU time. (This is a > 1.8Ghz, single-core laptop.) The other 17 minutes probably go to data > copies -- I'm doing 'dump | ssh cat >file' -- so a kernel implementatio= n > (say, IPsec) would be better -- and overhead, plus (of course) > calculation error). The point, though, is that the crypto isn't the > limiting factor. It's not stopping me from doing anything. It's not > even the biggest bottleneck in my application. And *that's* what's > important -- not *network* speed, but *application* speed. Your application shut your machine down for over an hour - just dumping alone wouldn't). That's substantial - sure, not for you, but you run crypto. For those who don't, this is a large part of why (the other part is key management, but that doesn't come into play for things like backups since it's a single key and two known parties). --- The point is that you have a GigE interface you don't use. Why? It's cheap, and when you do use it - to dump at work - it's a lot faster than 100Mbps. Crypto puts a huge dent into that capability the way it's done right now, and nobody is selling me 1Gbps crypto chips for a price that makes it cost-effective to put it into a laptop. And I don't exactly want to burn 100% of my CPU capacity to saturate my 802.11 link, let alone such a small fraction of my GigE. Joe --------------enig09E0B0730573A9B5F5BDBEE1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHO5ITE5f5cImnZrsRAjA4AKCAJfE1wWMy5LQjd4YkxstnMysU3gCeIr2E 2onWX2xxJ8T0NAL2mNBBhos= =36nJ -----END PGP SIGNATURE----- --------------enig09E0B0730573A9B5F5BDBEE1-- --===============1273663859== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol --===============1273663859==-- Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IscHv-0007cn-HV; Thu, 15 Nov 2007 05:49:35 -0500 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1IsUlA-0004vw-El for pmol-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 21:47:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsUlA-0004vl-4x; Wed, 14 Nov 2007 21:47:16 -0500 Received: from machshav.com ([198.180.150.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsUl7-0001TQ-JL; Wed, 14 Nov 2007 21:47:16 -0500 Received: by machshav.com (Postfix, from userid 512) id 1BAC95AA; Thu, 15 Nov 2007 02:47:13 +0000 (GMT) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 4EA17180; Thu, 15 Nov 2007 02:47:12 +0000 (GMT) Received: by berkshire.machshav.com (Postfix, from userid 54047) id 25688766172; Wed, 14 Nov 2007 21:47:20 -0500 (EST) Date: Thu, 15 Nov 2007 02:47:18 +0000 From: "Steven M. Bellovin" To: Sam Hartman Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)] Message-ID: <20071115024718.31c11a00@berkshire.machshav.com> In-Reply-To: References: <47263CC1.8000104@thinkingcat.com> <473B0B7E.1030803@isi.edu> <20071114223258.30bb5f35@cs.columbia.edu> <473B9213.3090805@isi.edu> Organization: Columbia University X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.0; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-Mailman-Approved-At: Thu, 15 Nov 2007 05:49:34 -0500 Cc: Leslie Daigle , Stephen Kent , Joe Touch , pmol@ietf.org, IESG , ietf@ietf.org X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pmol-bounces@ietf.org On Wed, 14 Nov 2007 21:22:48 -0500 Sam Hartman wrote: > > Joe> By essentially shutting your machine down for over an hour. No, not at all; not even close. > > I'm only going to send this one message, but then I'll drop out of the > thread. We've drifted far from Leslie's original query. > > Steve did not say his machine was CPU bound. Also, even if it was CPU > bound, he's probably running an operating system with reasonable > multiprogramming characteristics. So, if he wanted to use the > machine, his backup would take longer, but he'd get to do whatever he > wanted. > > Yes, Steve almost certanily did slow down any heavy CPU use during > the time when he was doing the backup. > Right. Operating systems are really good at sharing the CPU between processes. As long as you're talking about pure CPU load, the scheduler works *very* well, and has for O(45 years). Right now, as I'm typing this, I'm running that dump again in the background, this type piped to 'cat >/dev/null' to better simulate the pipe overhead, and I'm running 'openssl speed' in another window. I do not perceive any slowdown whatsoever. I would notice it I tried to view a movie, or if I tried to do serious picture or video editing, or if I tried running another command -- say, firing up firefox if it were not already running -- that did a lot of disk I/O. I don't know of any OS -- and that includes every version of Unix I've ever used, going back more than 30 years, and every version of Windows I've used, going back about a dozen years, that shares disk bandwidth particularly well. But sharing CPU is very easy. I don't dispute Joe's numbers about how crypto can limit bandwidth. Again, though, what matters to me is system and application performance, and there I generally don't feel the hit. Why do I use GigE? Well, in one sense it's because that's what came with my computer, but I did spend the money to convert my house network to GigE. There's some unencrypted traffic to the file server. Just as important, even with the crypto I'm approaching the limits of what I can do with 100BaseT. As I noted, my actual, over the wire, dump operations are running at 75-80M bps. There's not a lot of headroom between that and the 91M bps that is the fastest I've managed with ttcp. I just got a new, faster laptop; I'm curious what it will do, with and without the crypto. --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IscHe-00075z-7k; Thu, 15 Nov 2007 05:49:18 -0500 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1IsUNZ-00069S-6V for pmol-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 21:22:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsUNY-00068f-5u; Wed, 14 Nov 2007 21:22:52 -0500 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsUNV-0000u6-JB; Wed, 14 Nov 2007 21:22:52 -0500 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C299D4A45; Wed, 14 Nov 2007 21:22:48 -0500 (EST) From: Sam Hartman To: Joe Touch Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)] References: <47263CC1.8000104@thinkingcat.com> <473B0B7E.1030803@isi.edu> <20071114223258.30bb5f35@cs.columbia.edu> <473B9213.3090805@isi.edu> Date: Wed, 14 Nov 2007 21:22:48 -0500 In-Reply-To: <473B9213.3090805@isi.edu> (Joe Touch's message of "Wed, 14 Nov 2007 16:25:55 -0800") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-Mailman-Approved-At: Thu, 15 Nov 2007 05:49:16 -0500 Cc: Leslie Daigle , Stephen Kent , pmol@ietf.org, "Steven M. Bellovin" , IESG , ietf@ietf.org X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pmol-bounces@ietf.org >>>>> "Joe" == Joe Touch writes: Joe> Hi, Steve, Joe> Steven M. Bellovin wrote: >> On Wed, 14 Nov 2007 15:39:50 -0500 >> Stephen Kent wrote: >> >>> Joe, >>> >>> I disagree with your suggestion "The software performance of >>> security protocols has been the more substantial issue, and is >>> likely to continue to be for the forseeable future." >>> >>> I suspect that most desktop users do not need hardware crypto >>> for performance. Irarely if ever drive my GiGE interface at >>> its line rate. With fast processors, especially multi-core >>> processors, we have enough cycles to do symmetric crypto at >>> data rates consistent with most application demands for >>> individual users. Public key operations for key management >>> are usually low duty cycle, so they too can be accommodated. >>> >> Thanks -- I was going to say something similar. I regularly >> back up my laptop's disk over a software-encrypted GigE >> link. The dump file occupies about 35G of disk space; it takes >> about 70 minutes. Exclusive of protocol overhead, that comes >> to ~71M bps; given IP, TCP, and ssh, I'd guess it's more like >> 75-80M bps. I also know that I can run ttcp between that pair >> of machines at about 500M bps. Am I really suffering from a >> 7:1 performance hit from the crypto? Nope. Joe> By essentially shutting your machine down for over an hour. I'm only going to send this one message, but then I'll drop out of the thread. We've drifted far from Leslie's original query. Steve did not say his machine was CPU bound. Also, even if it was CPU bound, he's probably running an operating system with reasonable multiprogramming characteristics. So, if he wanted to use the machine, his backup would take longer, but he'd get to do whatever he wanted. Yes, Steve almost certanily did slow down any heavy CPU use during the time when he was doing the backup. Our point--Steve, Steve and I--is that for a lot of uses and a lot of users, no one cares. _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsQo8-0004po-K6; Wed, 14 Nov 2007 17:34:04 -0500 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1IsQnC-0003M4-FA for pmol-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 17:33:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsQnC-0003Kh-3C; Wed, 14 Nov 2007 17:33:06 -0500 Received: from machshav.com ([198.180.150.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsQn9-0003Bl-Nn; Wed, 14 Nov 2007 17:33:06 -0500 Received: by machshav.com (Postfix, from userid 512) id 7316F55B; Wed, 14 Nov 2007 22:33:03 +0000 (GMT) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2CE9515E; Wed, 14 Nov 2007 22:33:01 +0000 (GMT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 7B32876605E; Wed, 14 Nov 2007 17:32:58 -0500 (EST) Date: Wed, 14 Nov 2007 22:32:58 +0000 From: "Steven M. Bellovin" To: Stephen Kent Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)] Message-ID: <20071114223258.30bb5f35@cs.columbia.edu> In-Reply-To: References: <47263CC1.8000104@thinkingcat.com> <473B0B7E.1030803@isi.edu> Organization: Columbia University X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.0; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-Mailman-Approved-At: Wed, 14 Nov 2007 17:34:02 -0500 Cc: Leslie Daigle , ietf@ietf.org, Joe Touch , pmol@ietf.org, IESG , Sam Hartman X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pmol-bounces@ietf.org On Wed, 14 Nov 2007 15:39:50 -0500 Stephen Kent wrote: > Joe, > > I disagree with your suggestion "The software performance of security > protocols has been the more substantial issue, and is likely to > continue to be for the forseeable future." > > I suspect that most desktop users do not need hardware crypto for > performance. Irarely if ever drive my GiGE interface at its line > rate. With fast processors, especially multi-core processors, we have > enough cycles to do symmetric crypto at data rates consistent with > most application demands for individual users. Public key operations > for key management are usually low duty cycle, so they too can be > accommodated. > Thanks -- I was going to say something similar. I regularly back up my laptop's disk over a software-encrypted GigE link. The dump file occupies about 35G of disk space; it takes about 70 minutes. Exclusive of protocol overhead, that comes to ~71M bps; given IP, TCP, and ssh, I'd guess it's more like 75-80M bps. I also know that I can run ttcp between that pair of machines at about 500M bps. Am I really suffering from a 7:1 performance hit from the crypto? Nope. I can't do controlled experiments right now, since the laptop and server in question are currently about 350 km apart at the moment. Dumping the disk to /dev/null took about 30 minutes. The maximum hit I'm taking from the crypto, then, is about 2.3:1. Using the performance numbers from 'openssl speed' for 1024-byte blocks for AES-128 and SHA-1, the crypto is 23 minutes of CPU time. (This is a 1.8Ghz, single-core laptop.) The other 17 minutes probably go to data copies -- I'm doing 'dump | ssh cat >file' -- so a kernel implementation (say, IPsec) would be better -- and overhead, plus (of course) calculation error). The point, though, is that the crypto isn't the limiting factor. It's not stopping me from doing anything. It's not even the biggest bottleneck in my application. And *that's* what's important -- not *network* speed, but *application* speed. --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsPwK-0003N0-0Z; Wed, 14 Nov 2007 16:38:28 -0500 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1IsPvC-0001KG-HA for pmol-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 16:37:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsPvB-0001H0-Pt; Wed, 14 Nov 2007 16:37:17 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsPv7-0001LL-A8; Wed, 14 Nov 2007 16:37:17 -0500 Received: from [128.9.176.75] (c3-vpn4.isi.edu [128.9.176.75] (may be forged)) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lAELZsBx020178; Wed, 14 Nov 2007 13:35:56 -0800 (PST) Message-ID: <473B6A39.80405@isi.edu> Date: Wed, 14 Nov 2007 13:35:53 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Stephen Kent Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)] References: <47263CC1.8000104@thinkingcat.com> <473B0B7E.1030803@isi.edu> In-Reply-To: X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-Mailman-Approved-At: Wed, 14 Nov 2007 16:38:26 -0500 Cc: Leslie Daigle , ietf@ietf.org, pmol@ietf.org, IESG , Sam Hartman X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0220158455==" Errors-To: pmol-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0220158455== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2C4D0D160F14A8B13AE0A0FB" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2C4D0D160F14A8B13AE0A0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Steve, Stephen Kent wrote: > Joe, >=20 > I disagree with your suggestion "The software performance of security > protocols has been the more substantial issue, and is likely to continu= e > to be for the forseeable future." >=20 > I suspect that most desktop users do not need hardware crypto for > performance. Irarely if ever drive my GiGE interface at its line rate.= It's not hard to drive it high enough to see a substantial impact (300+Mbps); when I turn on S/W crypto, that drops to less than 1/3 at best. See the paper below. > With fast processors, especially multi-core processors, we have enough > cycles to do symmetric crypto at data rates consistent with most > application demands for individual users. Public key operations for ke= y > management are usually low duty cycle, so they too can be accommodated.= Public key is less the issue. See the following for recent measurements using multicore processors - FWIW, this will peg the processing of a modern CPU just to reach over 100Mbps: J. Touch, Y. Yang, "Reducing the Impact of DoS Attacks on Endpoint IP Security,"Proc. NPSec 2006, in conjunction with ICNP 2006, Nov. 2006. http://www.isi.edu/touch/pubs/npsec2006 Joe --------------enig2C4D0D160F14A8B13AE0A0FB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHO2o5E5f5cImnZrsRApTYAJ41nNN+5QUqvPz64e1zCwGAxHk4YQCg1O4F KpgMv3GbJoewTV6nuRtti7o= =W1iu -----END PGP SIGNATURE----- --------------enig2C4D0D160F14A8B13AE0A0FB-- --===============0220158455== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol --===============0220158455==-- Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsP3i-0000Cn-GW; Wed, 14 Nov 2007 15:42:02 -0500 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1IsP1w-0005yP-BK for pmol-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 15:40:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsP1v-0005x2-WB; Wed, 14 Nov 2007 15:40:12 -0500 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsP1s-0006zE-S6; Wed, 14 Nov 2007 15:40:11 -0500 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IsP1m-0006Nx-3V; Wed, 14 Nov 2007 15:40:02 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <473B0B7E.1030803@isi.edu> References: <47263CC1.8000104@thinkingcat.com> <473B0B7E.1030803@isi.edu> Date: Wed, 14 Nov 2007 15:39:50 -0500 To: Joe Touch From: Stephen Kent Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)] Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-Mailman-Approved-At: Wed, 14 Nov 2007 15:42:00 -0500 Cc: Leslie Daigle , ietf@ietf.org, pmol@ietf.org, IESG , Sam Hartman X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pmol-bounces@ietf.org Joe, I disagree with your suggestion "The software performance of security protocols has been the more substantial issue, and is likely to continue to be for the forseeable future." I suspect that most desktop users do not need hardware crypto for performance. Irarely if ever drive my GiGE interface at its line rate. With fast processors, especially multi-core processors, we have enough cycles to do symmetric crypto at data rates consistent with most application demands for individual users. Public key operations for key management are usually low duty cycle, so they too can be accommodated. Steve _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsMuz-0007C8-KN; Wed, 14 Nov 2007 13:24:53 -0500 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1IsLpP-00004u-Tv for pmol-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 12:15:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsLpP-0008WD-GF; Wed, 14 Nov 2007 12:15:03 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsLpO-0002ms-VS; Wed, 14 Nov 2007 12:15:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 82E4F175DF; Wed, 14 Nov 2007 17:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IsLpO-00041E-2G; Wed, 14 Nov 2007 12:15:02 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: ietf-announce@ietf.org From: IESG Secretary Message-Id: Date: Wed, 14 Nov 2007 12:15:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a X-Mailman-Approved-At: Wed, 14 Nov 2007 13:24:52 -0500 Cc: pmol@ietf.org Subject: [PMOL] WG Action: Performance Metrics at Other Layers (pmol) X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pmol-bounces@ietf.org A new IETF working group has been formed in the Operations and Management Area. For additional information, please contact the Area Directors or the WG Chairs. +++ Performance Metrics at Other Layers (pmol) =========================================== Current Status: Active Working Group WG Chairs: Al Morton Alan Clark Operations and Management Area: Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion: pmol@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/pmol Archive: http://www.ietf.org/mail-archive/web/pmol/index.html Description of Working Group: The successful implementation and operation of IP based applications often depends on some underlying performance measurement infrastructure that helps service operators or network managers to recognize when performance is unsatisfactory and identify problems affecting service quality. Standardized performance metrics add the desirable features of consistent implementation, interpretation, no comparison. The IETF has two Working Groups dedicated to the development of performance metrics however each has strict limitations in their charters: - The Benchmarking Methodology WG has addressed a range of networking technologies and protocols in their long history (such as IEEE 802.3, ATM, Frame Relay, and Routing Protocols), but the charter strictly limits their Performance characterizations to the laboratory environment. - The IP Performance Metrics WG has the mandate to develop metrics applicable to the performance of Internet data delivery, but it is specifically prohibited from developing metrics that characterize traffic (such as a VoIP stream). The IETF also has current and completed activities related to the reporting of application performance metrics (e.g. RAQMON and RTCP XR) and is also actively involved in the development of reliable transport protocols which would affect the relationship between IP performance and application performance. Thus there is a gap in the currently chartered coverage of IETF WGs: development of performance metrics for IP-based protocols and applications that operate over UDP, TCP, SCTP, DCCP, Forward Error Correction (FEC) and other robust transport protocols, and that can be used to characterize traffic on live networks. The working group will focus on the completion of two RFCs: 1. A PMOL framework and guidelines memo that will describe the necessary elements of performance metrics of protocols and applications transported over IETF-specified protocols (such as the formal definition, purpose, and units of measure) and the various types of metrics that characterize traffic on live networks (such as metrics derived from other metrics, possibly on lower layers). The framework will also address the need to specify the intended audience and the motivation for the performance metrics. There will also be guidelines for a performance metric development process that includes entry criteria for new proposals (how a proposal might be evaluated for possible endorsement by a protocol development working group), and how an successful proposal will be developed. Also, it is recognized that there are applications and protocols that do not need to use this framework and can make use of simpler specific methods for determining performance. 2. A proof-of-concept RFC defining performance metrics for SIP, based on draft-malas-performance-metrics. This memo would serve as an example of the framework and the PMOL development process in the IETF. Discussion of new work proposals is strongly discouraged under the initial charter of the PMOL WG, except to advise a protocol development WG when they are evaluating a new work proposal for related performance metrics. The Working Group will work closely with the RAI and APPS areas, performing early review of the documents with the two areas and inviting their particpation in the WGLC. The PMOL WG will also be guided by a document describing how memos defining performance metrics are intended to advance along the IETF Standards track (draft-bradner-metricstest). PMOL WG will take advantage of expertise and seek to avoid overlap with other standards development organizations, such as ETSI STQ, ITU-T SG 12, ATIS IIF, ATIS PRQC, and others. Milestones June 08 SIP Performance Metrics Draft to IESG Review for consideration as Proposed Standard Sept 08 PMOL Framework and Guidelines Draft to IESG Review for consideration as BCP Nov 08 - Discuss rechartering of the WG for new PMOL metrics work or shut down _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJcB-00010N-Kw; Wed, 14 Nov 2007 09:53:15 -0500 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1IsJb1-0006oa-NO for pmol-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 09:52:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJav-0006Up-A9; Wed, 14 Nov 2007 09:51:57 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsJar-000101-OW; Wed, 14 Nov 2007 09:51:57 -0500 Received: from [192.168.1.46] (pool-71-106-88-149.lsanca.dsl-w.verizon.net [71.106.88.149]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lAEEpghJ021063; Wed, 14 Nov 2007 06:51:42 -0800 (PST) Message-ID: <473B0B7E.1030803@isi.edu> Date: Wed, 14 Nov 2007 06:51:42 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sam Hartman Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)] References: <47263CC1.8000104@thinkingcat.com> In-Reply-To: X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab X-Mailman-Approved-At: Wed, 14 Nov 2007 09:53:13 -0500 Cc: IESG , ietf@ietf.org, pmol@ietf.org, Leslie Daigle X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1357077894==" Errors-To: pmol-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1357077894== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9387D3286DFF979632C54BAB" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9387D3286DFF979632C54BAB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sam Hartman wrote: >>>>>> "Romascanu," =3D=3D Romascanu, Dan (Dan) writ= es: >=20 > >> -----Original Message----- From: Sam Hartman > >> [mailto:hartmans@mit.edu] Sent: Monday, October 29, 2007 10:24 > >> PM To: Leslie Daigle Cc: IESG; ietf@ietf.org; pmol@ietf.org > >> Subject: [PMOL] Re: A question about [Fwd: WG Review: > >> Performance Metrics atOther Layers (pmol)] > >>=20 > >> >>>>> "Leslie" =3D=3D Leslie Daigle > >> writes: > >>=20 > >> I doubt I'll use the output in security protocols. > >>=20 >=20 > Romascanu,> Isn't it true that best security protocol designs > Romascanu,> always take performance aspects into account, because > Romascanu,> users will turn off the security features if they deem > Romascanu,> their performance reduction too great?=20 >=20 > In many cases the performance of security protocols is not a huge issue= at all with modern hardware. > There are a few important exceptions. A significant one is the lack of hardware to support security protocols. GigE interfaces have been common on both desktops and laptops for 5 years, but no corresponding security hardware has been similarly deployed= =2E The software performance of security protocols has been the more substantial issue, and is likely to continue to be for the forseeable future. Joe --------------enig9387D3286DFF979632C54BAB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHOwt+E5f5cImnZrsRAkfHAKCoFUTQemHmiRgnaZ9j/C3JpSbtbwCdFW02 H1GmsFcvhdhr72KKQG062MQ= =dSNL -----END PGP SIGNATURE----- --------------enig9387D3286DFF979632C54BAB-- --===============1357077894== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol --===============1357077894==-- Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io0wJ-000582-2t; Fri, 02 Nov 2007 14:08:15 -0400 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1Io0gI-0002Yp-C0 for pmol-confirm+ok@megatron.ietf.org; Fri, 02 Nov 2007 13:51:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io0gI-0002Ww-2G; Fri, 02 Nov 2007 13:51:42 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Io0g8-0007JP-Ks; Fri, 02 Nov 2007 13:51:38 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ZPUsejRT8o2bLRoNMPe+M0jfvJI5Up7BTWazDrNJCW+iB6x1wmg9+15WQAZE7cyB; h=Received:Message-ID:From:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MIMEOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.189.246] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Io0fq-0002eT-TV; Fri, 02 Nov 2007 13:51:15 -0400 Message-ID: <002d01c81d81$74bba3a0$6801a8c0@oemcomputer> From: "Randy Presuhn" References: <47263CC1.8000104@thinkingcat.com> <1194021043.2713.47.camel@localhost> Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: PerformanceMetrics atOther Layers (pmol)] Date: Fri, 2 Nov 2007 10:52:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a4beb055f130b31aead16dff6464144dfcce1a89a3d976bb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.189.246 X-Spam-Score: 1.6 (+) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-Mailman-Approved-At: Fri, 02 Nov 2007 14:08:13 -0400 Cc: ietf@ietf.org, pmol@ietf.org X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pmol-bounces@ietf.org Hi - > From: "Bill Sommerfeld" > To: "Sam Hartman" > Cc: "IESG" ; "Romascanu, Dan (Dan)" ; ; ; "Leslie Daigle" > Sent: Friday, November 02, 2007 8:30 AM > Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: PerformanceMetrics atOther Layers (pmol)] ... > Depending on the scope of this effort I see a bunch of things that might > be worth modelling: ... What's the relationship of all this to RFC 2564 and RFC 3729? (For the phone case, the question would extend to RFC 4711.) Randy _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InzuA-0006dF-Ll; Fri, 02 Nov 2007 13:01:58 -0400 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1InzgL-0005lj-RW for pmol-confirm+ok@megatron.ietf.org; Fri, 02 Nov 2007 12:47:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InzgG-0005hc-Ee; Fri, 02 Nov 2007 12:47:36 -0400 Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InzgA-0004v5-IA; Fri, 02 Nov 2007 12:47:36 -0400 Received: from dm-east-02.east.sun.com ([129.148.13.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA2GkpRS029429; Fri, 2 Nov 2007 16:46:51 GMT Received: from localhost.east.sun.com (vroom.East.Sun.COM [129.148.19.3]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lA2GkpK4059230; Fri, 2 Nov 2007 12:46:51 -0400 (EDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lA2GUmrl002753; Fri, 2 Nov 2007 12:30:48 -0400 (EDT) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.14.1+Sun/8.14.1/Submit) id lA2GUhmA002752; Fri, 2 Nov 2007 12:30:43 -0400 (EDT) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)] From: Bill Sommerfeld To: Sam Hartman In-Reply-To: References: <47263CC1.8000104@thinkingcat.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 02 Nov 2007 12:30:43 -0400 Message-Id: <1194021043.2713.47.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 X-Spam-Score: -1.0 (-) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-Mailman-Approved-At: Fri, 02 Nov 2007 13:01:57 -0400 Cc: IESG , ietf@ietf.org, pmol@ietf.org, Leslie Daigle X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pmol-bounces@ietf.org On Thu, 2007-11-01 at 11:09 -0400, Sam Hartman wrote: > In many cases the performance of security protocols is not a huge > issue at all with modern hardware. Depending on the scope of this effort I see a bunch of things that might be worth modelling: - additional compute resources (cpu, memory, crypto hardware, battery energy, etc.) - additional round trips (that pesky speed of light thing) - increases in message sizes/reduced effective MTU - availability (if your security protocol depends on a KDC/OCSP server/CRL distribution point/other service, if it's not available, you're not available) The first is not a factor on typical client computers, but the same is not necessarily true for the mobile phone/pda class of widget or even for servers -- in the latter case customers say they want high enough utilization that the overhead of security protocols is going to be significant for server sizing. > It has not been my experience that it is important to a level where > metrics are requested or used. it's very common for customers to ask "how big a server/server farm do we need to support this expected workload?". The impact of security protocols on that workload can be significant. - Bill _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InhXu-0003tW-NV; Thu, 01 Nov 2007 17:25:46 -0400 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1InhXt-0003sg-KW for pmol-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 17:25:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InhXs-0003s2-GW; Thu, 01 Nov 2007 17:25:44 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InhXs-0007b7-1H; Thu, 01 Nov 2007 17:25:44 -0400 X-IronPort-AV: E=Sophos;i="4.21,359,1188802800"; d="scan'208";a="184290740" Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-5.cisco.com with ESMTP; 01 Nov 2007 14:25:43 -0700 Received: from stealth-10-32-245-154.cisco.com ([10.32.245.154]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id lA1Jxupo009203; Thu, 1 Nov 2007 11:59:56 -0800 Message-Id: From: David R Oran To: Brian E Carpenter In-Reply-To: <472A39C6.9080301@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)] Date: Thu, 1 Nov 2007 17:25:41 -0400 References: <47263CC1.8000104@thinkingcat.com> <472A39C6.9080301@gmail.com> X-Mailer: Apple Mail (2.912) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2491; t=1193947197; x=1194811197; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[PMOL]=20Re=3A=20A=20question=20about=20[Fwd=3A=20WG= 20Review=3A=20Performance=09Metrics=20atOther=20Layers=20(pmol)] |Sender:=20 |To:=20Brian=20E=20Carpenter=20; bh=bb8rsWIf/Ake+ExNQ1K8gDtOzEjEu/GPC1ZNBapAw8o=; b=Iu6c880sLR9sc00VeQA6KmGhDnBSX9JiVigjUnlLAMvyxpU6jAgOnxJUkAmR/Zj0qRV/0v8/ U40hrMlTzMR0OJSccAxlUcPz9S/B6zb2g6alz4o9mRMCguuvuesVanRO; Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: pmol@ietf.org, Sam Hartman , IESG , Leslie Daigle , ietf@ietf.org X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pmol-bounces@ietf.org On Nov 1, 2007, at 4:40 PM, Brian E Carpenter wrote: > >> Leslie asked for comments from uninvolved parties and I'm giving my >> personal opinion that I would not find this work useful. If others >> do, we should go charter it. > > I think it will be useful, if it succeeds in rigorously defining > metrics for upper layer protocols, given their dependencies on > the metrics for lower layer protocols. The context is how to > write meaningful service level agreements for application level > services, which require well-defined and reproducible metrics. > For the services I work on in my day job (e.g. multicast/unicast real- time video streaming) the metrics I am concerned with are either: a) RTP/RTCP transport metrics, for which AVT has done a very good job with and hence PMOL is redundant, or b) session protocol setup metrics (e.g. RTSP), which are mostly useful for debugging as opposed to service measurement c) application-level SLA metrics, which are pretty abstract and not amenable to direct computation (e.g. visible artifacts per hour), or d) encoding/perceptual metrics, such as PSNR, R-factor, etc. which are in generally defined on bodies other than the IETF and which have been the subject of much controversy both in the industry and in the IETF when people have tried to get them blessed. As such, PMOL would be valuable to me if: 1. it succeeded in developing useful algorithms/methods for correlating these metrics to lower level metrics like route convergence time or congestive loss rates, or 2. it succeeded in developing application metrics which are less susceptible to industry controversy, vendor wars, service-provider "count everything that moves" behavior, and found wide adoption. My personal assessment is: a) the likelihood of PMOL succeeding at either of these is quite low, but I'm willing to be pleasantly surprised, and b) if PMOL starts encroaching on the work in AVT I will be unhappy as I think AVT does a very good job without needing a new venue for developing useful transport level metrics, at least for real time flows In summary, my general level of interest in PMOL is low, but that's a moot point since the WG has been chartered and I wish the group the best of luck! Dave Oran (IAB hat off). > Brian > > > _______________________________________________ > PMOL mailing list > PMOL@ietf.org > https://www1.ietf.org/mailman/listinfo/pmol _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InhD8-0006kH-4R; Thu, 01 Nov 2007 17:04:18 -0400 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1Ingr7-0005tE-0L for pmol-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 16:41:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ingr6-0005so-Mj for pmol@ietf.org; Thu, 01 Nov 2007 16:41:32 -0400 Received: from wa-out-1112.google.com ([209.85.146.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ingr0-0001Of-O4 for pmol@ietf.org; Thu, 01 Nov 2007 16:41:32 -0400 Received: by wa-out-1112.google.com with SMTP id k40so1107969wah for ; Thu, 01 Nov 2007 13:40:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=VgpW5ALquwkVQauMIRi+AieQCbBGinYIcNpzH4+BBoE=; b=LAPMBzDZ5m6EFYTIkDvn20owoXGXteS9JcXUddAFiY/APDI0NLhJifdQG5cIKFzeFAcqMzC8dTSKwzyeNQ0MGMijJS7oeiNNG+wJ+tTF9rYlnD7jwFZ2/IAVUmTCNInpBmFoYwjLP3a66qtaTKZ5eXxDeA0KOXZktyCZfx/95z8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Xa6nYrpMGjAmffVJpaCrkTwHG0hFB2/O0Qy5UVTqMOYaZmZR/lALK4ZG5eqJZeBHm5wkf2W04MQ23b1cJUEU7UqoMynfzouGVThRGtovz/Ok35U8JTQhCXY0rKEuiL94pwkO8f3q/7m9O8T8XKvOb6uRfUqIrZZAdXzP0TGVTMo= Received: by 10.114.89.1 with SMTP id m1mr1048376wab.1193949647692; Thu, 01 Nov 2007 13:40:47 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id d20sm2926663waa.2007.11.01.13.40.45 (version=SSLv3 cipher=RC4-MD5); Thu, 01 Nov 2007 13:40:47 -0700 (PDT) Message-ID: <472A39C6.9080301@gmail.com> Date: Fri, 02 Nov 2007 09:40:38 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sam Hartman Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)] References: <47263CC1.8000104@thinkingcat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-Mailman-Approved-At: Thu, 01 Nov 2007 17:04:17 -0400 Cc: IESG , ietf@ietf.org, pmol@ietf.org, Leslie Daigle X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pmol-bounces@ietf.org > Leslie asked for comments from uninvolved parties and I'm giving my > personal opinion that I would not find this work useful. If others > do, we should go charter it. I think it will be useful, if it succeeds in rigorously defining metrics for upper layer protocols, given their dependencies on the metrics for lower layer protocols. The context is how to write meaningful service level agreements for application level services, which require well-defined and reproducible metrics. Brian _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inf54-0000fp-UQ; Thu, 01 Nov 2007 14:47:50 -0400 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1Inf53-0000en-Er for pmol-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 14:47:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inf53-0000eT-3z for pmol@ietf.org; Thu, 01 Nov 2007 14:47:49 -0400 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Inf52-0002Fv-HT for pmol@ietf.org; Thu, 01 Nov 2007 14:47:49 -0400 X-IronPort-AV: E=Sophos;i="4.21,359,1188792000"; d="scan'208";a="80132974" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-outbound.avaya.com with ESMTP; 01 Nov 2007 14:47:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Nov 2007 19:47:05 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PMOL Working Group was approved! Thread-Index: Acgct5jOVDTZzY2zT7SYRTtMFMKCRw== From: "Romascanu, Dan (Dan)" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Subject: [PMOL] PMOL Working Group was approved! X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pmol-bounces@ietf.org The IESG approved in the telechat today the formation of the PMOL Working Group. Congratulations and good luck! Please see below the charter that was approved by the IESG. Regards, Dan Performance Metrics at Other Layers (pmol) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Last Modified: 2007-10-22 Current Status: Proposed Working Group WG Chairs: TBD Operations and Management Area: Dan Romascanu Ronald Bonica Description: The successful implementation and operation of IP based applications often depends on some underlying performance measurement infrastructure that helps service operators or network managers to recognize when performance is unsatisfactory and identify problems affecting service quality. Standardized performance metrics add the desirable features of consistent implementation, interpretation, no comparison. The IETF has two Working Groups dedicated to the development of performance metrics however each has strict limitations in their charters: - The Benchmarking Methodology WG has addressed a range of networking technologies and protocols in their long history (such as IEEE 802.3, ATM, Frame Relay, and Routing Protocols), but the charter strictly limits their Performance characterizations to the laboratory environment. - The IP Performance Metrics WG has the mandate to develop metrics applicable to the performance of Internet data delivery, but it is specifically prohibited from developing metrics that characterize traffic (such as a VoIP stream). The IETF also has current and completed activities related to the reporting of application performance metrics (e.g. RAQMON and RTCP XR) and is also actively involved in the development of reliable transport protocols which would affect the relationship between IP performance and application performance. Thus there is a gap in the currently chartered coverage of IETF WGs: development of performance metrics for IP-based protocols and applications that operate over UDP, TCP, SCTP, DCCP, Forward Error Correction (FEC) and other robust transport protocols, and that can be used to characterize traffic on live networks. The working group will focus on the completion of two RFCs: 1. A PMOL framework and guidelines memo that will describe the necessary elements of performance metrics of protocols and applications transported over IETF-specified protocols (such as the formal definition, purpose, and units of measure) and the various types of metrics that characterize traffic on live networks (such as metrics derived from other metrics, possibly on lower layers). The framework will also address the need to specify the intended audience and the motivation for the performance metrics. There will also be guidelines for a performance metric development process that includes entry criteria for new proposals (how a proposal might be evaluated for possible endorsement by a protocol development working group), and how an successful proposal will be developed. Also, it is recognized that there are applications and protocols that do not need to use this framework and can make use of simpler specific methods for determining performance.=20 2. A proof-of-concept RFC defining performance metrics for SIP, based on draft-malas-performance-metrics. This memo would serve as an example of the framework and the PMOL development process in the IETF. Discussion of new work proposals is strongly discouraged under the initial charter of the PMOL WG, except to advise a protocol development WG when they are evaluating a new work proposal for related performance metrics. The Working Group will work closely with the RAI and APPS areas, performing early review of the documents with the two areas and inviting their particpation in the WGLC.=20 The PMOL WG will also be guided by a document describing how memos defining performance metrics are intended to advance along the IETF Standards track (draft-bradner-metricstest). PMOL WG will take advantage of expertise and seek to avoid overlap with other standards development organizations, such as ETSI STQ, ITU-T SG 12, ATIS IIF, ATIS PRQC, and others. Milestones June 08 SIP Performance Metrics Draft to IESG Review for consideration as Proposed Standard Sept 08 PMOL Framework and Guidelines Draft to IESG Review for consideration as BCP Nov 08 - Discuss rechartering of the WG for new PMOL metrics work or shut down =20 _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inbgk-0005BJ-TE; Thu, 01 Nov 2007 11:10:30 -0400 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1Inbgj-0005Am-L9 for pmol-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 11:10:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inbgj-000552-BM; Thu, 01 Nov 2007 11:10:29 -0400 Received: from c-24-128-97-133.hsd1.ma.comcast.net ([24.128.97.133] helo=carter-zimmerman.suchdamage.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InbgZ-0004tA-7C; Thu, 01 Nov 2007 11:10:25 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 53DE54A45; Thu, 1 Nov 2007 11:09:58 -0400 (EDT) From: Sam Hartman To: "Romascanu, Dan (Dan)" Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)] References: <47263CC1.8000104@thinkingcat.com> Date: Thu, 01 Nov 2007 11:09:58 -0400 In-Reply-To: (Dan Romascanu's message of "Thu, 1 Nov 2007 13:48:22 +0100") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: pmol@ietf.org, Leslie Daigle , IESG , ietf@ietf.org X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pmol-bounces@ietf.org >>>>> "Romascanu," == Romascanu, Dan (Dan) writes: >> -----Original Message----- From: Sam Hartman >> [mailto:hartmans@mit.edu] Sent: Monday, October 29, 2007 10:24 >> PM To: Leslie Daigle Cc: IESG; ietf@ietf.org; pmol@ietf.org >> Subject: [PMOL] Re: A question about [Fwd: WG Review: >> Performance Metrics atOther Layers (pmol)] >> >> >>>>> "Leslie" == Leslie Daigle >> writes: >> >> I doubt I'll use the output in security protocols. >> Romascanu,> Isn't it true that best security protocol designs Romascanu,> always take performance aspects into account, because Romascanu,> users will turn off the security features if they deem Romascanu,> their performance reduction too great? In many cases the performance of security protocols is not a huge issue at all with modern hardware. There are a few important exceptions. So measuring Romascanu,> the performance of security protocols and the impact Romascanu,> of activating security on other protocols and Romascanu,> applications seems to be important. It has not been my experience that it is important to a level where metrics are requested or used. Certainly performance is something we think about, and it is something that does get measured from time to time and there are certain people who care about security performance a lot. Leslie asked for comments from uninvolved parties and I'm giving my personal opinion that I would not find this work useful. If others do, we should go charter it. _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ina38-00025A-Rf; Thu, 01 Nov 2007 09:25:30 -0400 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1Ina18-0000YR-G9 for pmol-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 09:23:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ina17-0000YA-If for pmol@ietf.org; Thu, 01 Nov 2007 09:23:25 -0400 Received: from [69.64.64.72] (helo=mail.fstc.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ina12-0001Nd-4h for pmol@ietf.org; Thu, 01 Nov 2007 09:23:25 -0400 Received: (qmail 44687 invoked from network); 1 Nov 2007 06:21:03 -0700 Received: from unknown (HELO dschutzer) (71.167.122.244) by mail.fstc.org with (RC4-MD5 encrypted) SMTP; 1 Nov 2007 06:21:03 -0700 From: "Dan Schutzer" To: "'Romascanu, Dan \(Dan\)'" , "'Sam Hartman'" , "'Leslie Daigle'" References: <47263CC1.8000104@thinkingcat.com> Subject: RE: [PMOL] Re: A question about [Fwd: WG Review: PerformanceMetrics atOther Layers (pmol)] Date: Thu, 1 Nov 2007 09:22:54 -0400 Message-ID: <032401c81c8a$536d0f60$6500a8c0@dschutzer> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgaeZQYmYxG9gL3SB6kLK97DiK2MgCC0DJAAAFeAdA= X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-Mailman-Approved-At: Thu, 01 Nov 2007 09:25:29 -0400 Cc: ietf@ietf.org, pmol@ietf.org, 'IESG' X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pmol-bounces@ietf.org agreed -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Thursday, November 01, 2007 8:48 AM To: Sam Hartman; Leslie Daigle Cc: pmol@ietf.org; IESG; ietf@ietf.org Subject: RE: [PMOL] Re: A question about [Fwd: WG Review: PerformanceMetrics atOther Layers (pmol)] > -----Original Message----- > From: Sam Hartman [mailto:hartmans@mit.edu] > Sent: Monday, October 29, 2007 10:24 PM > To: Leslie Daigle > Cc: IESG; ietf@ietf.org; pmol@ietf.org > Subject: [PMOL] Re: A question about [Fwd: WG Review: > Performance Metrics atOther Layers (pmol)] > > >>>>> "Leslie" == Leslie Daigle writes: > > I doubt I'll use the output in security protocols. > Isn't it true that best security protocol designs always take performance aspects into account, because users will turn off the security features if they deem their performance reduction too great? So measuring the performance of security protocols and the impact of activating security on other protocols and applications seems to be important. Dan _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InZU6-0007H3-5u; Thu, 01 Nov 2007 08:49:18 -0400 Received: from pmol by megatron.ietf.org with local (Exim 4.43) id 1InZU5-0007GY-F5 for pmol-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 08:49:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InZTz-0007C2-VL; Thu, 01 Nov 2007 08:49:11 -0400 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InZTt-00006l-37; Thu, 01 Nov 2007 08:49:11 -0400 X-IronPort-AV: E=Sophos;i="4.21,358,1188792000"; d="scan'208";a="80035034" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-outbound.avaya.com with ESMTP; 01 Nov 2007 08:48:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)] Date: Thu, 1 Nov 2007 13:48:22 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)] Thread-Index: AcgaeZQYmYxG9gL3SB6kLK97DiK2MgCC0DJA References: <47263CC1.8000104@thinkingcat.com> From: "Romascanu, Dan (Dan)" To: "Sam Hartman" , "Leslie Daigle" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: pmol@ietf.org, IESG , ietf@ietf.org X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pmol-bounces@ietf.org =20 =20 > -----Original Message----- > From: Sam Hartman [mailto:hartmans@mit.edu]=20 > Sent: Monday, October 29, 2007 10:24 PM > To: Leslie Daigle > Cc: IESG; ietf@ietf.org; pmol@ietf.org > Subject: [PMOL] Re: A question about [Fwd: WG Review:=20 > Performance Metrics atOther Layers (pmol)] >=20 > >>>>> "Leslie" =3D=3D Leslie Daigle writes: >=20 > I doubt I'll use the output in security protocols. >=20 Isn't it true that best security protocol designs always take performance aspects into account, because users will turn off the security features if they deem their performance reduction too great? So measuring the performance of security protocols and the impact of activating security on other protocols and applications seems to be important.=20 Dan _______________________________________________ PMOL mailing list PMOL@ietf.org https://www1.ietf.org/mailman/listinfo/pmol