From matt@advanced.org Wed Mar 15 04:30:47 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19655 for ; Wed, 15 Mar 2000 04:30:47 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id EAA27905 for ippm-l@advanced.org; Wed, 15 Mar 2000 04:11:47 -0500 (EST) Received: from hermes.noc.teithe.gr (hermes.noc.teithe.gr [193.92.235.38]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id EAA14293 for ; Wed, 15 Mar 2000 04:11:33 -0500 (EST) From: tzevgit@hermes.noc.teithe.gr Received: from localhost (tzevgit@localhost) by hermes.noc.teithe.gr (8.9.3/8.9.3) with ESMTP id MAA04920 for ; Wed, 15 Mar 2000 12:12:59 +0200 Date: Wed, 15 Mar 2000 12:12:58 +0200 (EET) To: ippm@advanced.org Subject: a little problem with TReno Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi...I am trying to compile TReno on a linux(slackware 7.0) but it finds a lot of problems! Itcan't find some structure members or redefines some others!! If you know something please help :) Thank you...Thodoris! From matt@advanced.org Wed Mar 15 06:30:08 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01763 for ; Wed, 15 Mar 2000 06:30:08 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id GAA07714 for ippm-l@advanced.org; Wed, 15 Mar 2000 06:22:00 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id GAA27158 for ; Wed, 15 Mar 2000 06:21:59 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28158; Wed, 15 Mar 2000 06:21:56 -0500 (EST) Message-Id: <200003151121.GAA28158@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ippm@advanced.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ippm-npmps-00.txt Date: Wed, 15 Mar 2000 06:21:55 -0500 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : Network performance measurement for periodic streams Author(s) : G. Grotefeld, V. Raisanen Filename : draft-ietf-ippm-npmps-00.txt Pages : 17 Date : 14-Mar-00 This document describes some of the issues associated with application-level measurements of network performance for periodic streams. An example application would be the testing of Dst-Src routes for use as bearer for multimedia streams. In this document, the reader is assumed to be familiar with the terminology of the Framework for IP Performance Metrics RFC 2330 [1]. This document is parallel to A One-way Delay Metric for IPPM RFC 2679[2]. A sample metric is described that is suitable for application-level measurement for streaming multimedia over IP. Using such a measurement, transmission service of a network is probed with a traffic stream similar to that of the application of interest, which is likely to be very dissimilar to the Poisson inter-arrival interval described in [2]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-npmps-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ippm-npmps-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ippm-npmps-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000314132419.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-npmps-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-npmps-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000314132419.I-D@ietf.org> --OtherAccess-- --NextPart-- From matt@advanced.org Thu Mar 16 04:57:34 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19776 for ; Thu, 16 Mar 2000 04:57:21 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id EAA01906 for ippm-l@advanced.org; Thu, 16 Mar 2000 04:43:25 -0500 (EST) Received: from aetos.it.teithe.gr (tzevgit@aetos.it.teithe.gr [193.92.235.39]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id EAA09360 for ; Thu, 16 Mar 2000 04:43:22 -0500 (EST) Received: from localhost (tzevgit@localhost) by aetos.it.teithe.gr (8.9.3/8.9.3) with ESMTP id LAA23066 for ; Thu, 16 Mar 2000 11:43:16 +0200 (EET) Date: Thu, 16 Mar 2000 11:43:16 +0200 From: Zevgitis Theodoros To: ippm@advanced.org Subject: a little problem with TReno (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I send an e-mail yesterday but i the server hermes hass a problem with receiving e-mail so please answer to tzevgit@it.teithe.gr My mail was: Hi...I am trying to compile TReno on a linux(slackware 7.0) but it finds a lot of problems! Itcan't find some structure members or redefines some others!! If you know something please help :) Thank you...Thodoris! From matt@advanced.org Fri Mar 17 10:14:25 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05273 for ; Fri, 17 Mar 2000 10:14:23 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id JAA15740 for ippm-l@advanced.org; Fri, 17 Mar 2000 09:59:41 -0500 (EST) Received: from galatea (localhost [127.0.0.1]) by betelgeuse.advanced.org (8.9.3/8.9.1) with SMTP id JAA07487; Fri, 17 Mar 2000 09:59:35 -0500 (EST) From: "Matthew J Zekauskas" To: Cc: Subject: Agenda for IPPM in Adelaide Date: Fri, 17 Mar 2000 10:03:33 -0500 Message-ID: <003401bf9021$f69147e0$4467dec7@advanced.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Transfer-Encoding: 7bit Proposed agenda: IP Performance Metrics WG (ippm) Monday, 27 March 2000, 19:30 - 22:00 (note that we expect 60-90 minutes) Status update & agenda bashing (5 minutes) -- The Chairs Loss patterns (10 minutes) -- Rayadurgam Ravikanth Final comments before last call Delay variation (15 minutes) -- Matt Zekauskas for Phil Chimento Latest changes. Experience applying the metrics to Surveyor data for European QoS tests Proposed metric for periodic traffic (30 minutes) -- Chuck Powers Presentation & Discussion Bulk Transport Metric (15 minutes) -- The Chairs The State of the World Current Work Discussion of the future -- alternatives? IPPM Milestones and Future Plans (30 minutes) -- The Chairs 10 minutes to outline our optins and directions, 20 minutes for discussion From matt@advanced.org Fri Mar 17 14:04:10 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10852 for ; Fri, 17 Mar 2000 14:04:09 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id NAA00978 for ippm-l@advanced.org; Fri, 17 Mar 2000 13:56:36 -0500 (EST) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id NAA28028 for ; Fri, 17 Mar 2000 13:56:34 -0500 (EST) Received: from wind.research.telcordia.com (wind-7 [192.4.7.17]) by thumper.research.telcordia.com (8.9.3/8.9.3) with ESMTP id NAA17230 for ; Fri, 17 Mar 2000 13:55:58 -0500 (EST) Received: (from wel@localhost) by wind.research.telcordia.com (8.8.8/8.8.8) id NAA08073 for ippm@advanced.org; Fri, 17 Mar 2000 13:55:57 -0500 (EST) Date: Fri, 17 Mar 2000 13:55:57 -0500 (EST) From: "Will E. Leland" Message-Id: <200003171855.NAA08073@wind.research.telcordia.com> To: ippm@advanced.org Subject: WG input needed on "Periodic Streams" As Chairs, we need discussion and insight from the IPPM list on the new I-D on periodic streams. We do not want to encourage a wide range of specific (and not widely useful) metrics, but rather a small set of generally useful metrics. We think the current draft represents a class of traffic not well captured by the existing metrics. However, we seek your input. The key questions for the working group are: 1) Is this an area in which a metric would be useful? This draft represents the convergence of two independent proposals, which leads us to believe there's a good chance the metric would be used. While the previous metrics have stressed Poisson traffic to avoid synchronizing with network activity, this draft seems to present a well-motivated reason to use periodic streams that is potentially important to a significant class of applications. 2) Is the proposed metric itself well-defined and useful? Does it give the right information to be useful for these streams? Are there better alternatives? 3) If the class of stream is important and the proposed metric useful, how should the draft be improved? One specific concern we have already forwarded to the authors is that the metric can be better mapped to the IPPM metric framework. In particular, the progression between singleton to sample is muddied here. If we do not see some interest from the Working Group, we'll view that as a clear statement that this metric is not needed. -- Will & Matt From matt@advanced.org Mon Mar 20 02:27:02 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13776 for ; Mon, 20 Mar 2000 02:27:01 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id CAA20767 for ippm-l@advanced.org; Mon, 20 Mar 2000 02:10:52 -0500 (EST) Received: from imo-d10.mx.aol.com (imo-d10.mx.aol.com [205.188.157.42]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id CAA13024 for ; Mon, 20 Mar 2000 02:10:50 -0500 (EST) From: HSCOMMS@aol.com Received: from HSCOMMS@aol.com by imo-d10.mx.aol.com (mail_out_v25.3.) id w.da.230c8f6 (3889); Mon, 20 Mar 2000 02:10:11 -0500 (EST) Message-ID: Date: Mon, 20 Mar 2000 02:10:11 EST Subject: Re: WG input needed on "Periodic Streams" To: wel@research.telcordia.com, ippm@advanced.org, g.grotefeld@motorola.com, Vilho.Raisanen@nokia.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 61 Content-Transfer-Encoding: 7bit In a message dated 3/17/00 3:30:15 PM Eastern Standard Time, wel@research.telcordia.com writes: > 1) ...While the previous metrics have stressed Poisson traffic > to avoid synchronizing with network activity, this draft seems to > present a well-motivated reason to use periodic streams that is > potentially important to a significant class of applications. > Although the packets in the streams are periodic to simulate those sent by the application(s) of interest, and such periods are likely to be very dissimilar to Poisson inter-arrival intervals, there is no reason why the streams themselves could not be sent at Poisson intervals to gain the advantages of Poisson sampling. To converge to an estimate of the network's performance over various useful time periods, it will be necessary to send more than a single stream anyway, (unless the test stream is sent continuously). > 2) Is the proposed metric itself well-defined and useful? > Does it give the right information to be useful for these streams? > Are there better alternatives? > The periodic packet interval, incT, should be better defined i.e., is it from the first bit of packet 1 to first bit of packet 2, or from the last bit of packet 1 to first bit of packet 2? The threshold for delay equivalent to loss, dTloss, is listed as an "optional" parameter of the metric. Although it may not be included in an application, how can it be excluded from the metric? Without some value of dTloss, how will a lost packet be counted or a delay value of "infinity" returned? Sect. 4.8 first mentions the "threshold for delay equivalent to loss *(if any)*" - again optional - but Sect. 4.8.2 says it MUST be reported. I think further clarification of this parameter is required. Also, it could be stated that if this parameter is present in a given application, the same value can be used in the metric. It should be stated that unlike Delay, DJit(i) can be either zero, positive or negative or alternately, expressed as: |Tstamp(Dst)[i]-Tstamp(Dst)[i-1] - (Tstamp(Src)[i]-Tstamp(Src)[i-1]|. > 3) If the class of stream is important and the proposed metric useful, > how should the draft be improved? One specific concern we have already > forwarded to the authors is that the metric can be better mapped > to the IPPM metric framework. In particular, the progression between > singleton to sample is muddied here. > The metric is currently defined as a sample metric. Since this is an application level metric and the streams are used to simulate application traffic, perhaps it would be useful to consider the measurement results for each instance of a packet stream (as opposed to each instance of a packet) as a singleton metric (based on measurements of the delays of the individual packets in the stream). I believe this is supported by RFC 2330 Sect. 11. The sample metric would be composed of measurement data from several streams, separated in time by Poisson intervals as suggested above. Application level statistics could then be generated from the sample. These would complement the statistics proposed in Sect. 4.9 of the draft. E.g., if the application is a VoIP call and each stream represents one call, or the packets sent in one direction of a call, one could generate a statistic stating that n% of the *calls* made via the network meet or exceed some performance criteria such as those shown in Sect. 4.9. Another statistic might say that 90% of the calls actually meet some other measured criteria. Either way, it is the performance of the application via the network (the calls) - not just the packets - that is being reported in these statistics. Regards, Howard Stanislevic HSComms Network Engineering and Consulting From matt@advanced.org Tue Mar 21 07:40:03 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23500 for ; Tue, 21 Mar 2000 07:40:03 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id HAA15265 for ippm-l@advanced.org; Tue, 21 Mar 2000 07:24:25 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id HAA24807 for ; Tue, 21 Mar 2000 07:24:23 -0500 (EST) From: vilho.raisanen@nokia.com Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id OAA09831; Tue, 21 Mar 2000 14:24:17 +0200 (EET) Received: from esebh03nok.ntc.nokia.com (esebh03nok.ntc.nokia.com [131.228.118.244]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id OAA21580; Tue, 21 Mar 2000 14:24:15 +0200 (EET) Received: by esebh03nok with Internet Mail Service (5.5.2650.10) id ; Tue, 21 Mar 2000 14:24:15 +0200 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE101F534E6@eseis04nok> To: HSCOMMS@aol.com, wel@research.telcordia.com, ippm@advanced.org, g.grotefeld@motorola.com, vilho.raisanen@nokia.com Subject: RE: WG input needed on "Periodic Streams" Date: Tue, 21 Mar 2000 14:24:10 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Hello Howard, thanks for the comments. Your point about tests performed at Poisson distributed intervals vs. network time scales is a good one. The present draft was formulated in a hurry and more effort should be invested in clarifying issues such as this one. As to singleton/sample metrics, the proposed metric was originally called "sample metric" to be consistent with the parlance of one-way and RT metrics. This way, it is possible to refer to "singleton metrics" in previous IPPM docs for related caveats &c. My original idea was that definition of statistics based on sample metrics might define Poisson distributed intervals between sample tests. I'm open to suggestions and comments, however. List, comments? In summary, I think that you raised important points and I hope that the sample vs. singleton issue and definition of statistics (or sample metric in the alternative parlance) will be discussed in Adelaide. Moreover, the utility of using a percentage of "acceptable" calls vs. network behaviour time scales would probably need further attention. Unfortunately, I can't attend the meeting but will read the minutes with interest :). BR, Vilho > -----Original Message----- > From: EXT HSCOMMS@aol.com [mailto:HSCOMMS@aol.com] > Sent: 20. March 2000 9:10 > To: wel@research.telcordia.com; ippm@advanced.org; > g.grotefeld@motorola.com; Vilho.Raisanen@nokia.com > Subject: Re: WG input needed on "Periodic Streams" > > > In a message dated 3/17/00 3:30:15 PM Eastern Standard Time, > wel@research.telcordia.com writes: > > > 1) ...While the previous metrics have stressed Poisson traffic > > to avoid synchronizing with network activity, this > draft seems to > > present a well-motivated reason to use periodic streams that is > > potentially important to a significant class of applications. > > > Although the packets in the streams are periodic to simulate > those sent by > the application(s) of interest, and such periods are likely > to be very > dissimilar to Poisson inter-arrival intervals, there is no > reason why the > streams themselves could not be sent at Poisson intervals to gain the > advantages of Poisson sampling. To converge to an estimate of > the network's > performance over various useful time periods, it will be > necessary to send > more than a single stream anyway, (unless the test stream is sent > continuously). > > > 2) Is the proposed metric itself well-defined and useful? > > Does it give the right information to be useful for > these streams? > > Are there better alternatives? > > > The periodic packet interval, incT, should be better defined > i.e., is it from > the first bit of packet 1 to first bit of packet 2, or from > the last bit of > packet 1 to first bit of packet 2? > > The threshold for delay equivalent to loss, dTloss, is listed as an > "optional" parameter of the metric. Although it may not be > included in an > application, how can it be excluded from the metric? Without > some value of > dTloss, how will a lost packet be counted or a delay value of > "infinity" > returned? Sect. 4.8 first mentions the "threshold for delay > equivalent to > loss *(if any)*" - again optional - but Sect. 4.8.2 says it > MUST be reported. > I think further clarification of this parameter is required. > Also, it could > be stated that if this parameter is present in a given > application, the same > value can be used in the metric. > > It should be stated that unlike Delay, DJit(i) can be either > zero, positive > or negative or alternately, expressed as: > |Tstamp(Dst)[i]-Tstamp(Dst)[i-1] - > (Tstamp(Src)[i]-Tstamp(Src)[i-1]|. > > > 3) If the class of stream is important and the proposed > metric useful, > > how should the draft be improved? One specific > concern we have already > > forwarded to the authors is that the metric can be > better mapped > > to the IPPM metric framework. In particular, the > progression between > > singleton to sample is muddied here. > > > The metric is currently defined as a sample metric. Since this is an > application level metric and the streams are used to simulate > application > traffic, perhaps it would be useful to consider the > measurement results for > each instance of a packet stream (as opposed to each instance > of a packet) as > a singleton metric (based on measurements of the delays of > the individual > packets in the stream). I believe this is supported by RFC > 2330 Sect. 11. > > The sample metric would be composed of measurement data from > several streams, > separated in time by Poisson intervals as suggested above. > > Application level statistics could then be generated from the > sample. These > would complement the statistics proposed in Sect. 4.9 of the draft. > > E.g., if the application is a VoIP call and each stream > represents one call, > or the packets sent in one direction of a call, one could generate a > statistic stating that n% of the *calls* made via the network > meet or exceed > some performance criteria such as those shown in Sect. 4.9. > Another statistic > might say that 90% of the calls actually meet some other > measured criteria. > Either way, it is the performance of the application via the > network (the > calls) - not just the packets - that is being reported in > these statistics. > > Regards, > Howard Stanislevic > HSComms Network Engineering and Consulting > From matt@advanced.org Tue Mar 21 14:28:16 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24346 for ; Tue, 21 Mar 2000 14:28:16 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id OAA14421 for ippm-l@advanced.org; Tue, 21 Mar 2000 14:20:38 -0500 (EST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id OAA03173 for ; Tue, 21 Mar 2000 14:20:37 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id MAA12269 for ; Tue, 21 Mar 2000 12:20:36 -0700 (MST)] Received: [from s-il06al.corp.mot.com (s-il06al.corp.mot.com [199.2.152.60]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id MAA00520 for ; Tue, 21 Mar 2000 12:20:35 -0700 (MST)] Received: by s-il06al.corp.mot.com with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Mar 2000 13:20:35 -0600 Message-ID: <23DBE2EFD4D5D3119616009027E32671133D6F@il06exm23.corp.mot.com> From: Grotefeld Glenn-cecl03 To: "'HSCOMMS@aol.com'" , wel@research.telcordia.com, ippm@advanced.org, Vilho.Raisanen@nokia.com Subject: RE: WG input needed on "Periodic Streams" Date: Tue, 21 Mar 2000 13:20:34 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Vilho and I appreciate Howard's comments (and certainly Will's!) and I make specific responses within (noted as GG) Glenn Grotefeld Motorola, Inc. g.grotefeld@motorola.com US 847 576-5992 847 538-7455 FAX In a message dated 3/17/00 3:30:15 PM Eastern Standard Time, wel@research.telcordia.com writes: > 1) ...While the previous metrics have stressed Poisson traffic > to avoid synchronizing with network activity, this draft seems to > present a well-motivated reason to use periodic streams that is > potentially important to a significant class of applications. > Although the packets in the streams are periodic to simulate those sent by the application(s) of interest, and such periods are likely to be very dissimilar to Poisson inter-arrival intervals, there is no reason why the streams themselves could not be sent at Poisson intervals to gain the advantages of Poisson sampling. To converge to an estimate of the network's performance over various useful time periods, it will be necessary to send more than a single stream anyway, (unless the test stream is sent continuously). GG: I agree that BETWEEN samples could be modeled as Poisson inter-arrival interval. In the context of ippm, more than one sample would represent a "sample of samples". Contributions on text to describe this would be appreciated. > 2) Is the proposed metric itself well-defined and useful? > Does it give the right information to be useful for these streams? > Are there better alternatives? > The periodic packet interval, incT, should be better defined i.e., is it from the first bit of packet 1 to first bit of packet 2, or from the last bit of packet 1 to first bit of packet 2? GG: I agree that more text is needed. I bogged down over the question of how to describe the potential variability of incT. The threshold for delay equivalent to loss, dTloss, is listed as an "optional" parameter of the metric. Although it may not be included in an application, how can it be excluded from the metric? Without some value of dTloss, how will a lost packet be counted or a delay value of "infinity" returned? Sect. 4.8 first mentions the "threshold for delay equivalent to loss *(if any)*" - again optional - but Sect. 4.8.2 says it MUST be reported. I think further clarification of this parameter is required. Also, it could be stated that if this parameter is present in a given application, the same value can be used in the metric. GG: I left this open-ended, thinking that there may be an application that does not care about the delay that a packet experiences. Now that I think more, what application could stand waiting for 24 hours for a packet? It should be stated that unlike Delay, DJit(i) can be either zero, positive or negative or alternately, expressed as: |Tstamp(Dst)[i]-Tstamp(Dst)[i-1] - (Tstamp(Src)[i]-Tstamp(Src)[i-1]|. GG: The authors have different views on whether jitter should be defined at all. > 3) If the class of stream is important and the proposed metric useful, > how should the draft be improved? One specific concern we have already > forwarded to the authors is that the metric can be better mapped > to the IPPM metric framework. In particular, the progression between > singleton to sample is muddied here. > The metric is currently defined as a sample metric. Since this is an application level metric and the streams are used to simulate application traffic, perhaps it would be useful to consider the measurement results for each instance of a packet stream (as opposed to each instance of a packet) as a singleton metric (based on measurements of the delays of the individual packets in the stream). I believe this is supported by RFC 2330 Sect. 11. The sample metric would be composed of measurement data from several streams, separated in time by Poisson intervals as suggested above. Application level statistics could then be generated from the sample. These would complement the statistics proposed in Sect. 4.9 of the draft. E.g., if the application is a VoIP call and each stream represents one call, or the packets sent in one direction of a call, one could generate a statistic stating that n% of the *calls* made via the network meet or exceed some performance criteria such as those shown in Sect. 4.9. Another statistic might say that 90% of the calls actually meet some other measured criteria. Either way, it is the performance of the application via the network (the calls) - not just the packets - that is being reported in these statistics. <> Regards, Howard Stanislevic HSComms Network Engineering and Consulting From matt@advanced.org Tue Mar 21 17:55:00 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10059 for ; Tue, 21 Mar 2000 17:55:00 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id RAA09185 for ippm-l@advanced.org; Tue, 21 Mar 2000 17:48:30 -0500 (EST) Received: from galatea (localhost [127.0.0.1]) by betelgeuse.advanced.org (8.9.3/8.9.1) with SMTP id RAA10543; Tue, 21 Mar 2000 17:48:29 -0500 (EST) From: "Matthew J Zekauskas" To: Cc: "Matthew J Zekauskas" Subject: Draft pointers for IPPM Agenda Date: Tue, 21 Mar 2000 17:52:50 -0500 Message-ID: <003801bf9388$2edf88a0$6d0294cc@advanced.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <003401bf9021$f69147e0$4467dec7@advanced.org> Content-Transfer-Encoding: 7bit I've been asked to post the drafts corresponding to the agenda items. Included are pointers to the drafts on www.ietf.org. --Matt > > Proposed agenda: IP Performance Metrics WG (ippm) > > Monday, 27 March 2000, 19:30 - 22:00 (note that we expect 60-90 minutes) > > Status update & agenda bashing (5 minutes) -- The Chairs > > Loss patterns (10 minutes) -- Rayadurgam Ravikanth > Final comments before last call One-way Loss Pattern Sample Metrics http://www.ietf.org/internet-drafts/draft-ietf-ippm-loss-pattern-02.txt > > Delay variation (15 minutes) -- Matt Zekauskas for Phil Chimento > Latest changes. > Experience applying the metrics to Surveyor data for European QoS tests Instantaneous Packet Delay Variation Metric for IPPM http://www.ietf.org/internet-drafts/draft-ietf-ippm-ipdv-04.txt > > Proposed metric for periodic traffic (30 minutes) -- Chuck Powers > Presentation & Discussion Network performance measurement for periodic streams http://www.ietf.org/internet-drafts/draft-ietf-ippm-npmps-00.txt > > Bulk Transport Metric (15 minutes) -- The Chairs > The State of the World > Current Work > Discussion of the future -- alternatives? Current draft on the table: Empirical Bulk Transfer Capacity (The framework document; I think this one is ready to go, but personally would like to see at least one metric.) http://www.ietf.org/internet-drafts/draft-ietf-ippm-btc-framework-02.txt For background only, a version of the Treno BTC document. **THIS HAS EXPIRED, AND IS NOT CURRENTLY A WORKING GROUP DOCUMENT.** http://www.advanced.org/IPPM/docs/draft-ietf-ippm-treno-btc-03.txt > > IPPM Milestones and Future Plans (30 minutes) -- The Chairs > 10 minutes to outline our optins and directions, > 20 minutes for discussion > From matt@advanced.org Tue Mar 21 20:50:14 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14583 for ; Tue, 21 Mar 2000 20:50:13 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id UAA24610 for ippm-l@advanced.org; Tue, 21 Mar 2000 20:43:10 -0500 (EST) Received: from galatea (localhost [127.0.0.1]) by betelgeuse.advanced.org (8.9.3/8.9.1) with SMTP id UAA16927; Tue, 21 Mar 2000 20:43:09 -0500 (EST) From: "Matthew J Zekauskas" To: Cc: "Bill Cerveny" Subject: ADMIN: No mailling list changes from 31-March-2000 to 17-April-2000 Date: Tue, 21 Mar 2000 20:47:29 -0500 Message-ID: <003b01becef1$72a049a0$4467dec7@galatea.advanced.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-UIDL: 04101edd38cda7dc5518a2035194fffc X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Transfer-Encoding: 7bit I will (mostly) be off the net between the end of the IETF and the 17th of April, so there will be no IPPM mailing list changes processed. If there is something you consider an emergency, please contact Bill Cerveny, cerveny@advanced.org. Remember, please send all IPPM mailing list change/add/drop requests to ippm-request@advanced.org. --Matt From matt@advanced.org Wed Mar 22 16:27:34 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09554 for ; Wed, 22 Mar 2000 16:27:34 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id QAA06166 for ippm-l@advanced.org; Wed, 22 Mar 2000 16:12:08 -0500 (EST) Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id QAA07565 for ; Wed, 22 Mar 2000 16:12:06 -0500 (EST) Received: from hogpa.mt.att.com ([135.16.74.2]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with SMTP id QAA07921 for ; Wed, 22 Mar 2000 16:11:34 -0500 (EST) Received: from acmortonw by hogpa.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id QAA02955; Wed, 22 Mar 2000 16:11:30 -0500 Message-Id: <3.0.32.20000322161128.0073e788@hogpa.mt.att.com> X-Sender: acm1@hogpa.mt.att.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 22 Mar 2000 16:11:28 -0500 To: ippm@advanced.org From: Al Morton Subject: Re: WG input needed on "Periodic Streams" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" After reading the Draft and responses from Howard and the authors, let me add the following to Will's questions for the WG: At 01:55 PM 3/17/00 -0500, Will E. Leland wrote: >The key questions for the working group are: > >1) Is this an area in which a metric would be useful? Yes. A small group here has been defining measurement methods for this application class, and agree with the author's reasoning. > >2) Is the proposed metric itself well-defined and useful? > Does it give the right information to be useful for these streams? > Are there better alternatives? I'd like to know if the WG will take up this work before typing up several suggestions. But let me add to the discussion on incT, since Howard Stanislevic pointed out a potential source of ambiguity and Glenn agreed to address it. IMO, the logical boundaries of the periodic packet interval are first bit of packet n to first bit of packet n+1. Now incT corresponds to the duration of real-time media contained in the packets, and avoids the variability of last bit-first bit or last bit-last bit intervals when using non-uniform packet lengths. Also, measuring delay variation has been an important part of our small group's deliberations, so I found Glenn's comment intriguing >GG: The authors have different views on whether jitter should be defined at >all. I'd like to hear the view on why jitter is unnecessary. > >3) If the class of stream is important and the proposed metric useful, > how should the draft be improved? One specific concern we have already > forwarded to the authors is that the metric can be better mapped > to the IPPM metric framework. In particular, the progression between > singleton to sample is muddied here. One suggestion would be to specify several alternatives for the Statistics reporting section. The alternatives correspond to typical application receivers (e.g., one where delay variation is critical, another where substantial delay variation and even out-of-sequence packets can be tolerated). These alternative "receivers" would ideally be few in number, but cover the majority of applications with periodic packet streams. > >If we do not see some interest from the Working Group, we'll view that >as a clear statement that this metric is not needed. > We're willing to review, comment, and contribute as necessary to the development of this metric. If for some reason ippm chooses not to take up this work, we'll follow the authors to a different venue and help with development there. Enjoy Adelaide, Al Morton From matt@advanced.org Sun Mar 26 22:01:20 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11017 for ; Sun, 26 Mar 2000 22:01:15 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id VAA00779 for ippm-l@advanced.org; Sun, 26 Mar 2000 21:46:28 -0500 (EST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id VAA14939 for ; Sun, 26 Mar 2000 21:46:26 -0500 (EST) Received: from kantoor.ripe.net (kantoor.ripe.net [193.0.1.98]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id EAA19019; Mon, 27 Mar 2000 04:45:51 +0200 (CEST) Received: from localhost (henk@localhost) by kantoor.ripe.net (8.8.8/8.8.5) with ESMTP id EAA25477; Mon, 27 Mar 2000 04:45:46 +0200 (CEST) X-Authentication-Warning: kantoor.ripe.net: henk owned process doing -bs Date: Mon, 27 Mar 2000 04:45:46 +0200 (CEST) From: "Henk Uijterwaal (RIPE-NCC)" To: "Will E. Leland" cc: ippm@advanced.org Subject: Re: WG input needed on "Periodic Streams" In-Reply-To: <200003171855.NAA08073@wind.research.telcordia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 17 Mar 2000, Will E. Leland wrote: > > As Chairs, we need discussion and insight from the IPPM list on the > new I-D on periodic streams. We do not want to encourage a wide range > of specific (and not widely useful) metrics, but rather a small set > of generally useful metrics. We think the current draft represents > a class of traffic not well captured by the existing metrics. However, > we seek your input. > > The key questions for the working group are: > > 1) Is this an area in which a metric would be useful? > This draft represents the convergence of two independent proposals, > which leads us to believe there's a good chance the metric would > be used. While the previous metrics have stressed Poisson traffic > to avoid synchronizing with network activity, this draft seems to > present a well-motivated reason to use periodic streams that is > potentially important to a significant class of applications. > > 2) Is the proposed metric itself well-defined and useful? > Does it give the right information to be useful for these streams? > Are there better alternatives? I find these questions hard, if not impossible to answer from just the current draft. Before finalizing the draft, I think that there should be at least a preliminary implementation plus some practical experience to show that this actually measures something useful. Then, paragraphs 4.2.1 to 4.2.4 confuse me: If I understand it correctly, the metric itself consists of global definitions (4.2.1) and (4.2.4). To extract the data one has to do measurements at SRC and DST (4.2.2 and 4.2.3). Wouldn't it make more sense to define the submetrics first, then merge 4.2.1 and 4.2.4 into 1, with some discussion on how to get there from the indivisual measurements? Finally, there is no paragrpaph 4.3 in the draft, is this correct? 2 minor comments: 4.5 5th + sign ("Depending on..") I think the choice of GPS or NTP is an implementation detail. The metric should be reported with an experimental error, and this will be larger for a setup with just NTP. It's up to the user to determine if the error is still acceptable. 4.7.3. Shouldn't the + signs be +/- ? (in reported value is true value +/- random error). If one can deterimen the random error, it's not random anymore. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.535-4414, Fax -4445 1016 AB Amsterdam Home: +31.20.4195305 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ The Committee (...) was unable to reach a consensus that substantial merit was lacking. Thus, the appeal was deemed meritorious. (Orlando NABC #19). From matt@advanced.org Mon Mar 27 04:56:28 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07659 for ; Mon, 27 Mar 2000 04:56:28 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id EAA23461 for ippm-l@advanced.org; Mon, 27 Mar 2000 04:45:07 -0500 (EST) Received: from galatea (localhost [127.0.0.1]) by betelgeuse.advanced.org (8.9.3/8.9.1) with SMTP id EAA10984; Mon, 27 Mar 2000 04:45:04 -0500 (EST) From: "Matthew J Zekauskas" To: "Henk Uijterwaal (RIPE-NCC)" Cc: Subject: RE: WG input needed on "Periodic Streams" Date: Mon, 27 Mar 2000 04:50:04 -0500 Message-ID: <000201bf97d1$d3f26360$cec0d0a9@advanced.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: Content-Transfer-Encoding: 7bit I'll tackle the nits, because they derive from the delay & loss RFCs. > 2 minor comments: > > 4.5 5th + sign ("Depending on..") > I think the choice of GPS or NTP is an implementation detail. The > metric should be reported with an experimental error, and this will > be larger for a setup with just NTP. It's up to the user to determine > if the error is still acceptable. You are correct, in that the metric should be reported with the experimental error, and if NTP yeilds satisfactory results, that's fine. This bullet just warns that NTP may not be what you want to use if delay values are small. It also states that no one has yet tried this out. That is still true, at least for any documented cases, to my knowledge (if someone has tried it and documented the results, speak up!). I personally have played with NTP in a setting, but there were other problems (the particular path had lots of guaranteed jitter) so I couldn't disambiguate the contribution due to NTP; and so I can't say how useful it is. I also know of another group that was testing NTP (unfortunately, I don't believe anything was published), but decided that they needed the improved accuracy of GPS for their application. I believe this text is taken directly from the other RFCs; I have no objection to modifying it. > > 4.7.3. Shouldn't the + signs be +/- ? (in reported value is true value > +/- random error). If one can deterimen the random error, it's not > random anymore. This too was taken from the other RFCs. The + signs just indicate that the components are additive. The "random error" might be positive or negative for any given singleton in the sample. --Matt From matt@advanced.org Mon Mar 27 10:32:52 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20766 for ; Mon, 27 Mar 2000 10:32:50 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id KAA21148 for ippm-l@advanced.org; Mon, 27 Mar 2000 10:22:44 -0500 (EST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id KAA27465 for ; Mon, 27 Mar 2000 10:22:43 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id IAA18339 for ; Mon, 27 Mar 2000 08:22:41 -0700 (MST)] Received: [from il06exi01.CORP.MOT.COM (il06exi01.corp.mot.com [199.5.78.78]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id IAA10986 for ; Mon, 27 Mar 2000 08:22:39 -0700 (MST)] Received: by il06exi01.corp.mot.com with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Mar 2000 09:06:10 -0600 Message-ID: <23DBE2EFD4D5D3119616009027E32671133D94@il06exm23.corp.mot.com> From: Grotefeld Glenn-cecl03 To: "'Henk Uijterwaal (RIPE-NCC)'" , "Will E. Leland" Cc: ippm@advanced.org Subject: RE: WG input needed on "Periodic Streams" Date: Mon, 27 Mar 2000 09:06:00 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" ~GG: Responses supplied within the section. Glenn Grotefeld Motorola, Inc. g.grotefeld@motorola.com US 847 576-5992 847 538-7455 FAX On Fri, 17 Mar 2000, Will E. Leland wrote: > > As Chairs, we need discussion and insight from the IPPM list on the > new I-D on periodic streams. We do not want to encourage a wide range > of specific (and not widely useful) metrics, but rather a small set > of generally useful metrics. We think the current draft represents > a class of traffic not well captured by the existing metrics. However, > we seek your input. > > The key questions for the working group are: > > 1) Is this an area in which a metric would be useful? > This draft represents the convergence of two independent proposals, > which leads us to believe there's a good chance the metric would > be used. While the previous metrics have stressed Poisson traffic > to avoid synchronizing with network activity, this draft seems to > present a well-motivated reason to use periodic streams that is > potentially important to a significant class of applications. > > 2) Is the proposed metric itself well-defined and useful? > Does it give the right information to be useful for these streams? > Are there better alternatives? I find these questions hard, if not impossible to answer from just the current draft. Before finalizing the draft, I think that there should be at least a preliminary implementation plus some practical experience to show that this actually measures something useful. Then, paragraphs 4.2.1 to 4.2.4 confuse me: If I understand it correctly, the metric itself consists of global definitions (4.2.1) and (4.2.4). To extract the data one has to do measurements at SRC and DST (4.2.2 and 4.2.3). Wouldn't it make more sense to define the submetrics first, then merge 4.2.1 and 4.2.4 into 1, with some discussion on how to get there from the indivisual measurements? -----START GG------- GG: The titling of the subparagraphs could be sharpened up to eliminate the potential for confusion (hint: alternate text welcome). + 4.2.1 relates to items that apply to all three following sections. + 4.2.1 also applies to parameters that are known prior to (deep breath, follow the protocol) the collection of singletons* that form the sample*. The other sections (especially 4.2.4) are only known AFTER the sample. + 4.2.2 and 4.2.3 are items collected at a local level (Src and Dest). + "4.2.4 Metrics resulting when metrics collected at MP(Src) and MP(Dst)are merged": I'm sorry, that looks pretty clear to me. -----END GG/ START GG------------ Finally, there is no paragrpaph 4.3 in the draft, is this correct? GG: Yes, paragraph renumbering was missed as we were pushing around sections. -----START GG------ 2 minor comments: ----START GG------ GG: See Matt's separate message ----END GG -------- 4.5 5th + sign ("Depending on..") I think the choice of GPS or NTP is an implementation detail. The metric should be reported with an experimental error, and this will be larger for a setup with just NTP. It's up to the user to determine if the error is still acceptable. 4.7.3. Shouldn't the + signs be +/- ? (in reported value is true value +/- random error). If one can deterimen the random error, it's not random anymore. Henk ---------------------------------------------------------------------------- -- Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.535-4414, Fax -4445 1016 AB Amsterdam Home: +31.20.4195305 The Netherlands Mobile: +31.6.55861746 ---------------------------------------------------------------------------- -- The Committee (...) was unable to reach a consensus that substantial merit was lacking. Thus, the appeal was deemed meritorious. (Orlando NABC #19). ~ From matt@advanced.org Thu Mar 30 04:24:22 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14593 for ; Thu, 30 Mar 2000 04:24:22 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id EAA00991 for ippm-l@advanced.org; Thu, 30 Mar 2000 04:09:04 -0500 (EST) Received: from galatea (localhost [127.0.0.1]) by betelgeuse.advanced.org (8.9.3/8.9.1) with SMTP id EAA18918; Thu, 30 Mar 2000 04:08:56 -0500 (EST) From: "Matthew J Zekauskas" To: Cc: "Matt Zekauskas" , "Will Leland" , "Vern Paxson" , "Scott Bradner" , Subject: Presentations and draft minutes from the IPPM session at the Adelaide IETF Date: Thu, 30 Mar 2000 04:14:16 -0500 Message-ID: <000001bf9a28$530ea020$cec0d0a9@advanced.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit The presentations and draft minutes from the IPPM session at the Adelaide IETF are available at http://www.advanced.org/IPPM/Meetings/ietf47/ If anyone that attended the session has any comments on the minutes, please let me know. [Note that I will be reading email only infrequently from 4-April until 17-April.] --Matt, for Matt & Will