From ippm-admin@ietf.org Thu Dec 4 13:33:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07408 for ; Thu, 4 Dec 2003 13:33:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARyGe-0000qp-L8; Thu, 04 Dec 2003 13:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARvfu-0006St-Dp for ippm@optimus.ietf.org; Thu, 04 Dec 2003 10:45:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01585 for ; Thu, 4 Dec 2003 10:45:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARvfr-0003Sj-00 for ippm@ietf.org; Thu, 04 Dec 2003 10:45:51 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 1ARvfq-0003S4-00 for ippm@ietf.org; Thu, 04 Dec 2003 10:45:51 -0500 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 4 Dec 2003 16:45:34 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE : [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt Date: Thu, 4 Dec 2003 16:45:33 +0100 Message-ID: Thread-Topic: [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt Thread-Index: AcOunWAwyd4JYoJ7RGq7YH9RzMApVQL15YHQ From: "STEPHAN Emile FTRD/DAC/LAN" To: "Henk Uijterwaal (RIPE-NCC)" , "Matthew J Zekauskas" , "Andy Bierman" , "Romascanu, Dan (Dan)" Cc: X-OriginalArrivalTime: 04 Dec 2003 15:45:34.0140 (UTC) FILETIME=[A78FBFC0:01C3BA7D] Content-Transfer-Encoding: quoted-printable Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Dear All, The IPPM MIB is designed as the reporting interface for a set of points = of measure colocated (an embedded SNMP agent) or distributed (an IPPM = proxy). The workflow of the reporting is simple: test packet arrival =20 | V network metrics computation ----> ippmHistoryTable owd,ploss,ipdv... | V Aggregated metrics computation --> ippmHistoryTable min,max,avgt,%... of owd,ploss,ipdv... | V filtering ---------------------> ippmReportTable=20 =20 The aggregation permits to produce results over well known period of = time (e.g.: every 5 minutes, per hour...). Reporting raw singletons have = a big limitation: If you increase the test packets rate you increase the = volume of information to report too. The aggregation permits to solve = this scalability issue: The volume of information to report does not = increase with the test packets rate. 3 main implementations are possible: Implementation A: The IPPM MIB stores only network measure results: test packet arrival =20 | V network metrics computation --> ippmHistoryTable=20 owd,ploss,ipdv... Implementation B: The IPPM MIB does not store network measure results but store a first = level of aggregation compatible with both measurement needs and = management plane bottlenecks: test packet arrival =20 | V network metrics computation owd,ploss,ipdv... | V Aggregated metrics computation --> ippmHistoryTable=20 min,max,avgt,%... of owd,ploss,ipdv... Implementation C: The IPPM MIB computes different level of aggregation and filters the = imformation to report: test packet arrival =20 | V network metrics computation owd,ploss,ipdv... | V Aggregated metrics computation --> ippmHistoryTable min,max,avgt,%... of owd,ploss,ipdv... | V filtering ---------------------> ippmReportTable To sum up, A) and B) are suitable for embedded agent, and B) and C) are = compatible with proxy mode: An IPPM Proxy is an separate application. = Regarding the B) in proxy mode, the first level of aggregation is = performed by the probe. Hope that helps, Regards Emile -----Message d'origine----- De : Henk Uijterwaal (RIPE-NCC) [mailto:henk@ripe.net]=20 Envoy=E9 : mercredi 19 novembre 2003 14:01 =C0 : Matthew J Zekauskas Cc : ippm@ietf.org Objet : Re: [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt On Thu, 13 Nov 2003, Matthew J Zekauskas wrote: > As chair, I'd like to say that Andy's comment below is what I've heard = > informally, but no one has to-date posted to the list. I'd like to=20 > ask others to read the draft, and comment on the complexity (or any=20 > other area) -- do you agree, or do you think that the current draft=20 > is on the right track. > > With my chair hat off, I concur with Andy's assessment below. What I=20 > always intended to implement with Surveyor was a simple scheme to=20 > export the basic data types; if there was any complex manipulation, it = > would be done by the software playing the role as a network management = > system. Also with my chair hat off. The way I currently see this (and the way that we've implemented this) = is something like: +------+ /-------- | User |----------------\ Control +------+ Control | | V V +--------+ +----------+ | Sender | | Receiver | +--------+ +----------+ | | ^ | | | | | | \--------Measurement ---------/ | | | V V +--------------------------------------------+ | Results | +--------------------------------------------+ | V +------------+ | Processing | +------------+ | V User The user requests up a measurement session by sending a control message = to both sender and receiver. Sender and receiver set up the measurement = using a home-grown mechanism now, perhaps OWAMP-control in the future. = The measurement is done, currently with our own protocol, perhaps = OWAMP-test in the future. Both sender and receiver record data = regarding the measurement in a file. After the measurement is over, = these files are pulled to a central point at regular intervals. Here = data is processed: combine what sender and receiver know about a = measurement, aggregate, filter, plot and print on web pages or so, = depending on what the user wants. The last steps are often done more than once, people tend to aggregate = over short intervals as well as long intervals, make 2 or more plots of = the same data etc. When talking to users, the biggest issue is that the data is not = available until the file has been written. A buffer with the data from the last X minutes would solve that. An = application can then query the buffer and do whatever it wants to do = with the data. This is where I see a standard format (MIB) and protocol (SNMP) come in. What people are not interested in, is a standard way to aggregate and = filter data. Requirements vary a lot here: time interval, loops over = the data, format (numbers vs a plot), etc, and the one size-fits all = approach doesn't seem right. Henk > > --Matt > > --On Thursday, November 13, 2003 8:02 AM -0800 Andy Bierman=20 > wrote: > > > Although a good job has been done documenting this MIB, > > IMO it is too complex to be deployable. The resource requirements=20 > > in the agent are very large. Some of the tables can get extremely=20 > > large, which would lead to poor SNMP performance. The resource=20 > > limitation mechanisms do not align well with actual SNMP agent=20 > > implementation constraints. > > > > This MIB is way too complicated and contains too many features that=20 > > should be provided by an EMS or NMS. There are likely to be many=20 > > implementation difficulties due to undocumented (and unforeseen)=20 > > interactions between features. The MIB should be simplified to=20 > > collect metric values and provide aggregation reports which can be=20 > > retrieved via SNMP. Analysis of the reports, threshold based > > exception handling, sending email and pages to administrators, > > etc. should be left to the application. > > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www1.ietf.org/mailman/listinfo/ippm > -------------------------------------------------------------------------= ----- Henk Uijterwaal Email: = henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: = http://www.ripe.net/home/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 -------------------------------------------------------------------------= ----- That problem that we weren't having yesterday, is it better? (Big ISP = NOC) _______________________________________________ ippm mailing list ippm@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Thu Dec 4 13:33:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07423 for ; Thu, 4 Dec 2003 13:33:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARyHu-0000tf-GV for ippm-archive@odin.ietf.org; Thu, 04 Dec 2003 13:33:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4IXI6g003444 for ippm-archive@odin.ietf.org; Thu, 4 Dec 2003 13:33:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARyHs-0000tP-7D for ippm-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 13:33:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07400 for ; Thu, 4 Dec 2003 13:33:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARyHq-00060W-00 for ippm-web-archive@ietf.org; Thu, 04 Dec 2003 13:33:14 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARyHp-00060S-00 for ippm-web-archive@ietf.org; Thu, 04 Dec 2003 13:33:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARyGe-0000qp-L8; Thu, 04 Dec 2003 13:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARvfu-0006St-Dp for ippm@optimus.ietf.org; Thu, 04 Dec 2003 10:45:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01585 for ; Thu, 4 Dec 2003 10:45:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARvfr-0003Sj-00 for ippm@ietf.org; Thu, 04 Dec 2003 10:45:51 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 1ARvfq-0003S4-00 for ippm@ietf.org; Thu, 04 Dec 2003 10:45:51 -0500 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 4 Dec 2003 16:45:34 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE : [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt Date: Thu, 4 Dec 2003 16:45:33 +0100 Message-ID: Thread-Topic: [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt Thread-Index: AcOunWAwyd4JYoJ7RGq7YH9RzMApVQL15YHQ From: "STEPHAN Emile FTRD/DAC/LAN" To: "Henk Uijterwaal (RIPE-NCC)" , "Matthew J Zekauskas" , "Andy Bierman" , "Romascanu, Dan (Dan)" Cc: X-OriginalArrivalTime: 04 Dec 2003 15:45:34.0140 (UTC) FILETIME=[A78FBFC0:01C3BA7D] Content-Transfer-Encoding: quoted-printable Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Dear All, The IPPM MIB is designed as the reporting interface for a set of points = of measure colocated (an embedded SNMP agent) or distributed (an IPPM = proxy). The workflow of the reporting is simple: test packet arrival =20 | V network metrics computation ----> ippmHistoryTable owd,ploss,ipdv... | V Aggregated metrics computation --> ippmHistoryTable min,max,avgt,%... of owd,ploss,ipdv... | V filtering ---------------------> ippmReportTable=20 =20 The aggregation permits to produce results over well known period of = time (e.g.: every 5 minutes, per hour...). Reporting raw singletons have = a big limitation: If you increase the test packets rate you increase the = volume of information to report too. The aggregation permits to solve = this scalability issue: The volume of information to report does not = increase with the test packets rate. 3 main implementations are possible: Implementation A: The IPPM MIB stores only network measure results: test packet arrival =20 | V network metrics computation --> ippmHistoryTable=20 owd,ploss,ipdv... Implementation B: The IPPM MIB does not store network measure results but store a first = level of aggregation compatible with both measurement needs and = management plane bottlenecks: test packet arrival =20 | V network metrics computation owd,ploss,ipdv... | V Aggregated metrics computation --> ippmHistoryTable=20 min,max,avgt,%... of owd,ploss,ipdv... Implementation C: The IPPM MIB computes different level of aggregation and filters the = imformation to report: test packet arrival =20 | V network metrics computation owd,ploss,ipdv... | V Aggregated metrics computation --> ippmHistoryTable min,max,avgt,%... of owd,ploss,ipdv... | V filtering ---------------------> ippmReportTable To sum up, A) and B) are suitable for embedded agent, and B) and C) are = compatible with proxy mode: An IPPM Proxy is an separate application. = Regarding the B) in proxy mode, the first level of aggregation is = performed by the probe. Hope that helps, Regards Emile -----Message d'origine----- De : Henk Uijterwaal (RIPE-NCC) [mailto:henk@ripe.net]=20 Envoy=E9 : mercredi 19 novembre 2003 14:01 =C0 : Matthew J Zekauskas Cc : ippm@ietf.org Objet : Re: [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt On Thu, 13 Nov 2003, Matthew J Zekauskas wrote: > As chair, I'd like to say that Andy's comment below is what I've heard = > informally, but no one has to-date posted to the list. I'd like to=20 > ask others to read the draft, and comment on the complexity (or any=20 > other area) -- do you agree, or do you think that the current draft=20 > is on the right track. > > With my chair hat off, I concur with Andy's assessment below. What I=20 > always intended to implement with Surveyor was a simple scheme to=20 > export the basic data types; if there was any complex manipulation, it = > would be done by the software playing the role as a network management = > system. Also with my chair hat off. The way I currently see this (and the way that we've implemented this) = is something like: +------+ /-------- | User |----------------\ Control +------+ Control | | V V +--------+ +----------+ | Sender | | Receiver | +--------+ +----------+ | | ^ | | | | | | \--------Measurement ---------/ | | | V V +--------------------------------------------+ | Results | +--------------------------------------------+ | V +------------+ | Processing | +------------+ | V User The user requests up a measurement session by sending a control message = to both sender and receiver. Sender and receiver set up the measurement = using a home-grown mechanism now, perhaps OWAMP-control in the future. = The measurement is done, currently with our own protocol, perhaps = OWAMP-test in the future. Both sender and receiver record data = regarding the measurement in a file. After the measurement is over, = these files are pulled to a central point at regular intervals. Here = data is processed: combine what sender and receiver know about a = measurement, aggregate, filter, plot and print on web pages or so, = depending on what the user wants. The last steps are often done more than once, people tend to aggregate = over short intervals as well as long intervals, make 2 or more plots of = the same data etc. When talking to users, the biggest issue is that the data is not = available until the file has been written. A buffer with the data from the last X minutes would solve that. An = application can then query the buffer and do whatever it wants to do = with the data. This is where I see a standard format (MIB) and protocol (SNMP) come in. What people are not interested in, is a standard way to aggregate and = filter data. Requirements vary a lot here: time interval, loops over = the data, format (numbers vs a plot), etc, and the one size-fits all = approach doesn't seem right. Henk > > --Matt > > --On Thursday, November 13, 2003 8:02 AM -0800 Andy Bierman=20 > wrote: > > > Although a good job has been done documenting this MIB, > > IMO it is too complex to be deployable. The resource requirements=20 > > in the agent are very large. Some of the tables can get extremely=20 > > large, which would lead to poor SNMP performance. The resource=20 > > limitation mechanisms do not align well with actual SNMP agent=20 > > implementation constraints. > > > > This MIB is way too complicated and contains too many features that=20 > > should be provided by an EMS or NMS. There are likely to be many=20 > > implementation difficulties due to undocumented (and unforeseen)=20 > > interactions between features. The MIB should be simplified to=20 > > collect metric values and provide aggregation reports which can be=20 > > retrieved via SNMP. Analysis of the reports, threshold based > > exception handling, sending email and pages to administrators, > > etc. should be left to the application. > > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www1.ietf.org/mailman/listinfo/ippm > -------------------------------------------------------------------------= ----- Henk Uijterwaal Email: = henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: = http://www.ripe.net/home/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 -------------------------------------------------------------------------= ----- That problem that we weren't having yesterday, is it better? (Big ISP = NOC) _______________________________________________ ippm mailing list ippm@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Thu Dec 4 19:28:41 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28159 for ; Thu, 4 Dec 2003 19:28:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS3pB-0000za-Ko; Thu, 04 Dec 2003 19:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS3Cc-0008Cs-3c for ippm@optimus.ietf.org; Thu, 04 Dec 2003 18:48:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26148 for ; Thu, 4 Dec 2003 18:47:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS3CY-0004oA-00 for ippm@ietf.org; Thu, 04 Dec 2003 18:48:06 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AS3CX-0004nU-00 for ippm@ietf.org; Thu, 04 Dec 2003 18:48:05 -0500 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hB4NlWjq015491; Thu, 4 Dec 2003 15:47:32 -0800 (PST) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn2-174.cisco.com [10.21.112.174]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AOU87107; Thu, 4 Dec 2003 15:47:31 -0800 (PST) Message-Id: <4.3.2.7.2.20031204153931.02a38da0@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 04 Dec 2003 15:45:20 -0800 To: "STEPHAN Emile FTRD/DAC/LAN" From: Andy Bierman Subject: RE : [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt Cc: "Henk Uijterwaal (RIPE-NCC)" , "Matthew J Zekauskas" , "Romascanu, Dan (Dan)" , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable At 07:45 AM 12/4/2003, STEPHAN Emile FTRD/DAC/LAN wrote: >Dear All, I think Implementation A and B make sense for this MIB. Filtering and notification can be done with a different MIB, such as the ALARM-MIB under development in the DISMAN WG. High level (EMS) features such as email or SMS notification can be left for future work or not standardized. It seems to me that the WG wants this MIB to be drastically simplified before it will be considered further. To me, that means remove all objects that are not needed for Implementation=20 A and B described below. Andy >The IPPM MIB is designed as the reporting interface for a set of points of= measure colocated (an embedded SNMP agent) or distributed (an IPPM proxy). > >The workflow of the reporting is simple: > > test packet arrival =20 > | > V > network metrics computation ----> ippmHistoryTable > owd,ploss,ipdv... > | > V > Aggregated metrics computation --> ippmHistoryTable > min,max,avgt,%... of owd,ploss,ipdv... > | > V > filtering ---------------------> ippmReportTable=20 >=20 > >The aggregation permits to produce results over well known period of time= (e.g.: every 5 minutes, per hour...). Reporting raw singletons have a big= limitation: If you increase the test packets rate you increase the volume= of information to report too. The aggregation permits to solve this= scalability issue: The volume of information to report does not increase= with the test packets rate. > >3 main implementations are possible: > >Implementation A: > >The IPPM MIB stores only network measure results: > > test packet arrival =20 > | > V > network metrics computation --> ippmHistoryTable=20 > owd,ploss,ipdv... > >Implementation B: >The IPPM MIB does not store network measure results but store a first level= of aggregation compatible with both measurement needs and management plane= bottlenecks: > > test packet arrival =20 > | > V > network metrics computation > owd,ploss,ipdv... > | > V > Aggregated metrics computation --> ippmHistoryTable=20 > min,max,avgt,%... of owd,ploss,ipdv... > >Implementation C: >The IPPM MIB computes different level of aggregation and filters the= imformation to report: > > test packet arrival =20 > | > V > network metrics computation > owd,ploss,ipdv... > | > V > Aggregated metrics computation --> ippmHistoryTable > min,max,avgt,%... of owd,ploss,ipdv... > | > V > filtering ---------------------> ippmReportTable > >To sum up, A) and B) are suitable for embedded agent, and B) and C) are= compatible with proxy mode: An IPPM Proxy is an separate application.= Regarding the B) in proxy mode, the first level of aggregation is performed= by the probe. > >Hope that helps, > >Regards >Emile > >-----Message d'origine----- >De : Henk Uijterwaal (RIPE-NCC) [mailto:henk@ripe.net]=20 >Envoy=E9 : mercredi 19 novembre 2003 14:01 >=C0 : Matthew J Zekauskas >Cc : ippm@ietf.org >Objet : Re: [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt > > >On Thu, 13 Nov 2003, Matthew J Zekauskas wrote: > >> As chair, I'd like to say that Andy's comment below is what I've heard=20 >> informally, but no one has to-date posted to the list. I'd like to=20 >> ask others to read the draft, and comment on the complexity (or any=20 >> other area) -- do you agree, or do you think that the current draft=20 >> is on the right track. >> >> With my chair hat off, I concur with Andy's assessment below. What I=20 >> always intended to implement with Surveyor was a simple scheme to=20 >> export the basic data types; if there was any complex manipulation, it=20 >> would be done by the software playing the role as a network management=20 >> system. > >Also with my chair hat off. > >The way I currently see this (and the way that we've implemented this) is= something like: > > +------+ > /-------- | User |----------------\ > Control +------+ Control > | | > V V > +--------+ +----------+ > | Sender | | Receiver | > +--------+ +----------+ > | | ^ | > | | | | > | \--------Measurement ---------/ | > | | > V V > +--------------------------------------------+ > | Results | > +--------------------------------------------+ > | > V > +------------+ > | Processing | > +------------+ > | > V > User > > >The user requests up a measurement session by sending a control message to= both sender and receiver. Sender and receiver set up the measurement using= a home-grown mechanism now, perhaps OWAMP-control in the future. The= measurement is done, currently with our own protocol, perhaps OWAMP-test in= the future. Both sender and receiver record data regarding the measurement= in a file. After the measurement is over, these files are pulled to a= central point at regular intervals. Here data is processed: combine what= sender and receiver know about a measurement, aggregate, filter, plot and= print on web pages or so, depending on what the user wants. > >The last steps are often done more than once, people tend to aggregate over= short intervals as well as long intervals, make 2 or more plots of the same= data etc. > >When talking to users, the biggest issue is that the data is not available= until the file has been written. > >A buffer with the data from the last X minutes would solve that. An= application can then query the buffer and do whatever it wants to do with= the data. This is where I see a standard format (MIB) and protocol >(SNMP) come in. > >What people are not interested in, is a standard way to aggregate and= filter data. Requirements vary a lot here: time interval, loops over the= data, format (numbers vs a plot), etc, and the one size-fits all approach= doesn't seem right. > > >Henk > > > > > > > > > > >> >> --Matt >> >> --On Thursday, November 13, 2003 8:02 AM -0800 Andy Bierman=20 >> wrote: >> >> > Although a good job has been done documenting this MIB, >> > IMO it is too complex to be deployable. The resource requirements=20 >> > in the agent are very large. Some of the tables can get extremely=20 >> > large, which would lead to poor SNMP performance. The resource=20 >> > limitation mechanisms do not align well with actual SNMP agent=20 >> > implementation constraints. >> > >> > This MIB is way too complicated and contains too many features that=20 >> > should be provided by an EMS or NMS. There are likely to be many=20 >> > implementation difficulties due to undocumented (and unforeseen)=20 >> > interactions between features. The MIB should be simplified to=20 >> > collect metric values and provide aggregation reports which can be=20 >> > retrieved via SNMP. Analysis of the reports, threshold based >> > exception handling, sending email and pages to administrators, >> > etc. should be left to the application. >> >> >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www1.ietf.org/mailman/listinfo/ippm >> > >---------------------------------------------------------------------------= --- >Henk Uijterwaal Email: henk.uijterwaal@ripe.net >RIPE Network Coordination Centre WWW:= http://www.ripe.net/home/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 >---------------------------------------------------------------------------= --- > >That problem that we weren't having yesterday, is it better? (Big ISP NOC) > >_______________________________________________ >ippm mailing list >ippm@ietf.org=20 >https://www1.ietf.org/mailman/listinfo/ippm=20 _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Thu Dec 4 19:28:44 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28177 for ; Thu, 4 Dec 2003 19:28:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS3pd-00011i-5E for ippm-archive@odin.ietf.org; Thu, 04 Dec 2003 19:28:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB50STpG003942 for ippm-archive@odin.ietf.org; Thu, 4 Dec 2003 19:28:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS3pc-00011V-O8 for ippm-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 19:28:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28151 for ; Thu, 4 Dec 2003 19:28:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS3pb-0005dS-00 for ippm-web-archive@ietf.org; Thu, 04 Dec 2003 19:28:27 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AS3pa-0005dP-00 for ippm-web-archive@ietf.org; Thu, 04 Dec 2003 19:28:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS3pB-0000za-Ko; Thu, 04 Dec 2003 19:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS3Cc-0008Cs-3c for ippm@optimus.ietf.org; Thu, 04 Dec 2003 18:48:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26148 for ; Thu, 4 Dec 2003 18:47:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS3CY-0004oA-00 for ippm@ietf.org; Thu, 04 Dec 2003 18:48:06 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AS3CX-0004nU-00 for ippm@ietf.org; Thu, 04 Dec 2003 18:48:05 -0500 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hB4NlWjq015491; Thu, 4 Dec 2003 15:47:32 -0800 (PST) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn2-174.cisco.com [10.21.112.174]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AOU87107; Thu, 4 Dec 2003 15:47:31 -0800 (PST) Message-Id: <4.3.2.7.2.20031204153931.02a38da0@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 04 Dec 2003 15:45:20 -0800 To: "STEPHAN Emile FTRD/DAC/LAN" From: Andy Bierman Subject: RE : [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt Cc: "Henk Uijterwaal (RIPE-NCC)" , "Matthew J Zekauskas" , "Romascanu, Dan (Dan)" , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable At 07:45 AM 12/4/2003, STEPHAN Emile FTRD/DAC/LAN wrote: >Dear All, I think Implementation A and B make sense for this MIB. Filtering and notification can be done with a different MIB, such as the ALARM-MIB under development in the DISMAN WG. High level (EMS) features such as email or SMS notification can be left for future work or not standardized. It seems to me that the WG wants this MIB to be drastically simplified before it will be considered further. To me, that means remove all objects that are not needed for Implementation=20 A and B described below. Andy >The IPPM MIB is designed as the reporting interface for a set of points of= measure colocated (an embedded SNMP agent) or distributed (an IPPM proxy). > >The workflow of the reporting is simple: > > test packet arrival =20 > | > V > network metrics computation ----> ippmHistoryTable > owd,ploss,ipdv... > | > V > Aggregated metrics computation --> ippmHistoryTable > min,max,avgt,%... of owd,ploss,ipdv... > | > V > filtering ---------------------> ippmReportTable=20 >=20 > >The aggregation permits to produce results over well known period of time= (e.g.: every 5 minutes, per hour...). Reporting raw singletons have a big= limitation: If you increase the test packets rate you increase the volume= of information to report too. The aggregation permits to solve this= scalability issue: The volume of information to report does not increase= with the test packets rate. > >3 main implementations are possible: > >Implementation A: > >The IPPM MIB stores only network measure results: > > test packet arrival =20 > | > V > network metrics computation --> ippmHistoryTable=20 > owd,ploss,ipdv... > >Implementation B: >The IPPM MIB does not store network measure results but store a first level= of aggregation compatible with both measurement needs and management plane= bottlenecks: > > test packet arrival =20 > | > V > network metrics computation > owd,ploss,ipdv... > | > V > Aggregated metrics computation --> ippmHistoryTable=20 > min,max,avgt,%... of owd,ploss,ipdv... > >Implementation C: >The IPPM MIB computes different level of aggregation and filters the= imformation to report: > > test packet arrival =20 > | > V > network metrics computation > owd,ploss,ipdv... > | > V > Aggregated metrics computation --> ippmHistoryTable > min,max,avgt,%... of owd,ploss,ipdv... > | > V > filtering ---------------------> ippmReportTable > >To sum up, A) and B) are suitable for embedded agent, and B) and C) are= compatible with proxy mode: An IPPM Proxy is an separate application.= Regarding the B) in proxy mode, the first level of aggregation is performed= by the probe. > >Hope that helps, > >Regards >Emile > >-----Message d'origine----- >De : Henk Uijterwaal (RIPE-NCC) [mailto:henk@ripe.net]=20 >Envoy=E9 : mercredi 19 novembre 2003 14:01 >=C0 : Matthew J Zekauskas >Cc : ippm@ietf.org >Objet : Re: [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt > > >On Thu, 13 Nov 2003, Matthew J Zekauskas wrote: > >> As chair, I'd like to say that Andy's comment below is what I've heard=20 >> informally, but no one has to-date posted to the list. I'd like to=20 >> ask others to read the draft, and comment on the complexity (or any=20 >> other area) -- do you agree, or do you think that the current draft=20 >> is on the right track. >> >> With my chair hat off, I concur with Andy's assessment below. What I=20 >> always intended to implement with Surveyor was a simple scheme to=20 >> export the basic data types; if there was any complex manipulation, it=20 >> would be done by the software playing the role as a network management=20 >> system. > >Also with my chair hat off. > >The way I currently see this (and the way that we've implemented this) is= something like: > > +------+ > /-------- | User |----------------\ > Control +------+ Control > | | > V V > +--------+ +----------+ > | Sender | | Receiver | > +--------+ +----------+ > | | ^ | > | | | | > | \--------Measurement ---------/ | > | | > V V > +--------------------------------------------+ > | Results | > +--------------------------------------------+ > | > V > +------------+ > | Processing | > +------------+ > | > V > User > > >The user requests up a measurement session by sending a control message to= both sender and receiver. Sender and receiver set up the measurement using= a home-grown mechanism now, perhaps OWAMP-control in the future. The= measurement is done, currently with our own protocol, perhaps OWAMP-test in= the future. Both sender and receiver record data regarding the measurement= in a file. After the measurement is over, these files are pulled to a= central point at regular intervals. Here data is processed: combine what= sender and receiver know about a measurement, aggregate, filter, plot and= print on web pages or so, depending on what the user wants. > >The last steps are often done more than once, people tend to aggregate over= short intervals as well as long intervals, make 2 or more plots of the same= data etc. > >When talking to users, the biggest issue is that the data is not available= until the file has been written. > >A buffer with the data from the last X minutes would solve that. An= application can then query the buffer and do whatever it wants to do with= the data. This is where I see a standard format (MIB) and protocol >(SNMP) come in. > >What people are not interested in, is a standard way to aggregate and= filter data. Requirements vary a lot here: time interval, loops over the= data, format (numbers vs a plot), etc, and the one size-fits all approach= doesn't seem right. > > >Henk > > > > > > > > > > >> >> --Matt >> >> --On Thursday, November 13, 2003 8:02 AM -0800 Andy Bierman=20 >> wrote: >> >> > Although a good job has been done documenting this MIB, >> > IMO it is too complex to be deployable. The resource requirements=20 >> > in the agent are very large. Some of the tables can get extremely=20 >> > large, which would lead to poor SNMP performance. The resource=20 >> > limitation mechanisms do not align well with actual SNMP agent=20 >> > implementation constraints. >> > >> > This MIB is way too complicated and contains too many features that=20 >> > should be provided by an EMS or NMS. There are likely to be many=20 >> > implementation difficulties due to undocumented (and unforeseen)=20 >> > interactions between features. The MIB should be simplified to=20 >> > collect metric values and provide aggregation reports which can be=20 >> > retrieved via SNMP. Analysis of the reports, threshold based >> > exception handling, sending email and pages to administrators, >> > etc. should be left to the application. >> >> >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www1.ietf.org/mailman/listinfo/ippm >> > >---------------------------------------------------------------------------= --- >Henk Uijterwaal Email: henk.uijterwaal@ripe.net >RIPE Network Coordination Centre WWW:= http://www.ripe.net/home/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 >---------------------------------------------------------------------------= --- > >That problem that we weren't having yesterday, is it better? (Big ISP NOC) > >_______________________________________________ >ippm mailing list >ippm@ietf.org=20 >https://www1.ietf.org/mailman/listinfo/ippm=20 _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Sun Dec 7 01:02:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02267 for ; Sun, 7 Dec 2003 01:02:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASrzV-0003oc-FI; Sun, 07 Dec 2003 01:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASruD-0003eY-T9 for ippm@optimus.ietf.org; Sun, 07 Dec 2003 00:56:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02031 for ; Sun, 7 Dec 2003 00:56:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASruB-0004X6-00 for ippm@ietf.org; Sun, 07 Dec 2003 00:56:31 -0500 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1ASruA-0004X2-00 for ippm@ietf.org; Sun, 07 Dec 2003 00:56:30 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id 28E914EF6F; Sun, 7 Dec 2003 06:56:01 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 8E9DE4EE2A; Sun, 7 Dec 2003 06:56:00 +0100 (CET) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id hB75u0wp028728; Sun, 7 Dec 2003 06:56:00 +0100 Received: from localhost (henk@localhost) by cow.ripe.net (8.12.10/8.12.6) with ESMTP id hB75tx9U032235; Sun, 7 Dec 2003 06:56:00 +0100 X-Authentication-Warning: cow.ripe.net: henk owned process doing -bs Date: Sun, 7 Dec 2003 06:55:59 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: STEPHAN Emile FTRD/DAC/LAN Cc: Matthew J Zekauskas , Andy Bierman , "Romascanu, Dan (Dan)" , ippm@ietf.org Subject: Re: RE : [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: N 0.084348 X-RIPE-Signature: 6e29845540676327623f4d923fa91836 Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , On Thu, 4 Dec 2003, STEPHAN Emile FTRD/DAC/LAN wrote: > Dear All, > > The IPPM MIB is designed as the reporting interface for a set of points of measure colocated (an embedded SNMP agent) or distributed (an IPPM proxy). > > The workflow of the reporting is simple: > > test packet arrival > | > V > network metrics computation ----> ippmHistoryTable > owd,ploss,ipdv... > | > V > Aggregated metrics computation --> ippmHistoryTable > min,max,avgt,%... of owd,ploss,ipdv... > | > V > filtering ---------------------> ippmReportTable > > > The aggregation permits to produce results over well known period of > time (e.g.: every 5 minutes, per hour...). Reporting raw singletons have > a big limitation: If you increase the test packets rate you increase the > volume of information to report too. The aggregation permits to solve > this scalability issue: The volume of information to report does not > increase with the test packets rate. This is true. However: 1. People prefer different aggregation intervals, different numbers (average, median), for different applications. It is impossible to predict everything anybody is ever going to ask for, let alone standardize it. 2. For a single, one time, measurement, the ippmHistoryTable have a limited size. For continous measurements, ippmHistoryTAble can be implemented as a round robin, with the application above it responsible to read the buffer before data expires (or accept that data is expired). > The IPPM MIB stores only network measure results: > > test packet arrival > | > V > network metrics computation --> ippmHistoryTable > owd,ploss,ipdv... I'd go for this. Henk (Chair hat off) ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/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 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Sun Dec 7 01:02:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02282 for ; Sun, 7 Dec 2003 01:02:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASrzk-0003r6-0B for ippm-archive@odin.ietf.org; Sun, 07 Dec 2003 01:02:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB762Fvm014820 for ippm-archive@odin.ietf.org; Sun, 7 Dec 2003 01:02:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASrzj-0003qx-Rg for ippm-web-archive@optimus.ietf.org; Sun, 07 Dec 2003 01:02:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02264 for ; Sun, 7 Dec 2003 01:02:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASrzh-0004cF-00 for ippm-web-archive@ietf.org; Sun, 07 Dec 2003 01:02:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASrzg-0004cB-00 for ippm-web-archive@ietf.org; Sun, 07 Dec 2003 01:02:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASrzV-0003oc-FI; Sun, 07 Dec 2003 01:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASruD-0003eY-T9 for ippm@optimus.ietf.org; Sun, 07 Dec 2003 00:56:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02031 for ; Sun, 7 Dec 2003 00:56:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASruB-0004X6-00 for ippm@ietf.org; Sun, 07 Dec 2003 00:56:31 -0500 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1ASruA-0004X2-00 for ippm@ietf.org; Sun, 07 Dec 2003 00:56:30 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id 28E914EF6F; Sun, 7 Dec 2003 06:56:01 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 8E9DE4EE2A; Sun, 7 Dec 2003 06:56:00 +0100 (CET) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id hB75u0wp028728; Sun, 7 Dec 2003 06:56:00 +0100 Received: from localhost (henk@localhost) by cow.ripe.net (8.12.10/8.12.6) with ESMTP id hB75tx9U032235; Sun, 7 Dec 2003 06:56:00 +0100 X-Authentication-Warning: cow.ripe.net: henk owned process doing -bs Date: Sun, 7 Dec 2003 06:55:59 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: STEPHAN Emile FTRD/DAC/LAN Cc: Matthew J Zekauskas , Andy Bierman , "Romascanu, Dan (Dan)" , ippm@ietf.org Subject: Re: RE : [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: N 0.084348 X-RIPE-Signature: 6e29845540676327623f4d923fa91836 Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , On Thu, 4 Dec 2003, STEPHAN Emile FTRD/DAC/LAN wrote: > Dear All, > > The IPPM MIB is designed as the reporting interface for a set of points of measure colocated (an embedded SNMP agent) or distributed (an IPPM proxy). > > The workflow of the reporting is simple: > > test packet arrival > | > V > network metrics computation ----> ippmHistoryTable > owd,ploss,ipdv... > | > V > Aggregated metrics computation --> ippmHistoryTable > min,max,avgt,%... of owd,ploss,ipdv... > | > V > filtering ---------------------> ippmReportTable > > > The aggregation permits to produce results over well known period of > time (e.g.: every 5 minutes, per hour...). Reporting raw singletons have > a big limitation: If you increase the test packets rate you increase the > volume of information to report too. The aggregation permits to solve > this scalability issue: The volume of information to report does not > increase with the test packets rate. This is true. However: 1. People prefer different aggregation intervals, different numbers (average, median), for different applications. It is impossible to predict everything anybody is ever going to ask for, let alone standardize it. 2. For a single, one time, measurement, the ippmHistoryTable have a limited size. For continous measurements, ippmHistoryTAble can be implemented as a round robin, with the application above it responsible to read the buffer before data expires (or accept that data is expired). > The IPPM MIB stores only network measure results: > > test packet arrival > | > V > network metrics computation --> ippmHistoryTable > owd,ploss,ipdv... I'd go for this. Henk (Chair hat off) ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/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 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Mon Dec 8 18:37:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12771 for ; Mon, 8 Dec 2003 18:37:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATUw1-0003Ik-FZ; Mon, 08 Dec 2003 18:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATMOS-0008Bj-O1 for ippm@optimus.ietf.org; Mon, 08 Dec 2003 09:29:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10507 for ; Mon, 8 Dec 2003 09:29:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATMOQ-0004nu-00 for ippm@ietf.org; Mon, 08 Dec 2003 09:29:46 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx with esmtp (Exim 4.12) id 1ATMOO-0004nr-00 for ippm@ietf.org; Mon, 08 Dec 2003 09:29:44 -0500 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 8 Dec 2003 15:29:29 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3BD97.AFFEA5BE" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 8 Dec 2003 15:29:28 +0100 Message-ID: Thread-Topic: IPPM MIB proxy trace Thread-Index: AcO9l4zjbmDi4a88RHuCWBTk2r3aAw== From: "STEPHAN Emile FTRD/DAC/LAN" To: "Henk Uijterwaal (RIPE-NCC)" , "Matthew J Zekauskas" Cc: "Romascanu, Dan (Dan)" , , "Andy Bierman" , "Al Morton" X-OriginalArrivalTime: 08 Dec 2003 14:29:29.0571 (UTC) FILETIME=[B084CB30:01C3BD97] Subject: [ippm] IPPM MIB proxy trace Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3BD97.AFFEA5BE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Following is a quick tour of the IPPM REPORTING MIB in proxy mode. It corresponds to the demo made to the WG chairs at the end of the WG session in Minneapolis. The intend is to provide real MIB and IPPM material to help IPPM fellows to make they mind on the IPPM MIB without reading the MIB spec in detail:-) Regards Emile 1. abstract=20 France Telecom R&D and Qosmetrix had recently integrated the implementation of IPPM MIB developed by FranceTelecom lab in the measurement system of Qosmetrix, Netadvisor. The IPPM MIB is implemented as a SNMPv2 proxy on the top of this measurement system.=20 Information is extracted directly from snmpwalks performed on the proxy. The prefix 'IPPM-REPORTING-MIB::' is removed from all the statements. 2. Configuration The first probe is located in Qosmetrix lab in Camarillo (Ca) the second one is located in Qosmetrix office in Massy (Paris, France). The Netadvisor and the IPPM Proxy are located in Qosmetrix lab in Camarillo; The test consists of 2 types of measures: + One network measure is running between Camarillo and Paris. It performs Type-P-One-way-Delay(6). Its configuration is described in section 8; + A first level of aggregation is performed by the recipient probe. It computes Type-P-One-way-Delay-Median(9) and Type-P-One-way-Delay-Minimums(10) results and uploads them. Network measure singletons are not uploaded.Their configurations are described in section 9; 3. ippmSystem group=20 ippmSystemTime.0 =3D Hex-STRING: 07 58 12 AF 34 DB 6A F8=20 ippmSystemSynchronizationType.0 =3D INTEGER: other(0) ippmSystemSynchronizationDesc.0 =3D STRING: NO SYNCHRONIZATION AVAILABLE ON THIS SYSTEM ippmSystemClockResolution.0 =3D Gauge32: 10000000 Nanoseconds ippmSystemOperationalStatus.0 =3D INTEGER: up(1) 4. ippmOwners Table=20 ippmOwnersOwner.1 =3D STRING: "ippmAdmin" ippmOwnersGrantedMetrics.1 =3D STRING: "0111111111111111111111111111111111" ippmOwnersQuota.1 =3D Gauge32: 4294967295 ippmOwnersIpAddressType.1 =3D INTEGER: ipv6(2) ippmOwnersIpAddress.1 =3D STRING: "fe80::209:5bff:fe08:d420" ippmOwnersEmail.1 =3D STRING: ippmAdmin@qosmetrix.com ippmOwnersSMS.1 =3D STRING: 1-805-445-8504 ippmOwnersStatus.1 =3D INTEGER: active(1) ippmOwnersOwner.2 =3D STRING: "root" ippmOwnersGrantedMetrics.2 =3D STRING: "0000001011110000000000000001011000" ippmOwnersQuota.2 =3D Gauge32: 2147483647 ippmOwnersIpAddressType.2 =3D INTEGER: ipv4(1) ippmOwnersIpAddress.2 =3D STRING: "192.168.1.175" ippmOwnersEmail.2 =3D STRING: owner@qosmetrix.com ippmOwnersSMS.2 =3D STRING: 1-805-445-8504 ippmOwnersStatus.2 =3D INTEGER: active(1) 5. ippmSynchronization Table=20 Following are the description of the synchronization of the 2 probes: ippmSynchronizationTime.1.1 =3D Hex-STRING: 00 00 00 00 00 00 00 = 00 ippmSynchronizationStratum.1.1 =3D Gauge32: 1 =20 ippmSynchronizationResolution.1.1 =3D Gauge32: 40 Nanoseconds =20 ippmSynchronizationTime.2.1 =3D Hex-STRING: 00 00 00 00 00 00 00 = 00 ippmSynchronizationStratum.2.1 =3D Gauge32: 1 =20 ippmSynchronizationResolution.2.1 =3D Gauge32: 40 Nanoseconds =20 6. ippmPointOfMeasure Table=20 ippmPointOfMeasureMgmtAddrType.1 =3D INTEGER: ipv4(1) =20 ippmPointOfMeasureMgmtAddress.1 =3D STRING: "66.14.75.68" =20 ippmPointOfMeasureTestAddrTypeP.1 =3D STRING: "ip" =20 ippmPointOfMeasureTestAddr.1 =3D STRING: 66.14.75.68 =20 ippmPointOfMeasureMetrics.1 =3D STRING: "0000001011110000000000000001011000" =20 ippmPointOfMeasureMgmtAddrType.2 =3D INTEGER: ipv4(1) =20 ippmPointOfMeasureMgmtAddress.2 =3D STRING: "62.161.75.221" =20 ippmPointOfMeasureTestAddrTypeP.2 =3D STRING: "ip" =20 ippmPointOfMeasureTestAddr.2 =3D STRING: 62.161.75.221 =20 ippmPointOfMeasureMetrics.2 =3D STRING: "0000001011110000000000000001011000" =20 =20 7. Metrics Table=20 # Note: Only the entries of interest are displayed. ... ippmMetricCapabilities.6 =3D INTEGER: implemented(1) =20 ippmMetricType.6 =3D INTEGER: network(0) =20 ippmMetricUnit.6 =3D INTEGER: nanosecond(8) =20 ippmMetricDescription.6 =3D STRING: Type-P-One-way-Delay =20 ... ippmMetricCapabilities.9 =3D INTEGER: implemented(1) =20 ippmMetricType.9 =3D INTEGER: aggregated(1) =20 ippmMetricUnit.9 =3D INTEGER: nanosecond(8) =20 ippmMetricDescription.9 =3D STRING: Type-P-One-way-Delay-Median =20 ... ippmMetricCapabilities.10 =3D INTEGER: implemented(1) =20 ippmMetricType.10 =3D INTEGER: aggregated(1) =20 ippmMetricUnit.10 =3D INTEGER: nanosecond(8) =20 ippmMetricDescription.10 =3D STRING: Type-P-One-way-Delay-Minimum =20 ... ippmMetricCapabilities.27 =3D INTEGER: implemented(1) =20 ippmMetricType.27 =3D INTEGER: network(0) =20 ippmMetricUnit.27 =3D INTEGER: nanosecond(9) =20 ippmMetricDescription.27 =3D STRING: Type-P-One-way-ipdv =20 ... 8. Network Measure Table Once the scenario is started, Netadvisor creates the new network measures in the IPPM Proxy. # network measure root.1 Type-P-One-way-Delay(6) and Type-P-One-way-ipdv(27) # Note: aggregation derivated from Type-P-One-way-ipdv(27) are not displayed in the document # ippmNetMeasureName."root".1 =3D STRING: -New Test Config ippmNetMeasureMetrics."root".1 =3D STRING: "0000001000000000000000000001000000" # ^ ^ # 6 27 # metric ID ----------------------------------------------+--------------------+---- -- # ippmNetMeasureBeginTime."root".1 =3D Hex-STRING: 07 58 08 9C 00 = 00 00 00=20 ippmNetMeasureCollectionRateUnit."root".1=3D INTEGER: minute(4) ippmNetMeasureCollectionRate."root".1 =3D Gauge32: 1 ippmNetMeasureDurationUnit."root".1 =3D INTEGER: second(3) ippmNetMeasureDuration."root".1 =3D Gauge32: 1800 ippmNetMeasureHistorySize."root".1 =3D Gauge32: 0 ippmNetMeasureFailureMgmtMode."root".1 =3D INTEGER: auto(1) ippmNetMeasureResultsMgmt."root".1 =3D INTEGER: suspend(2) ippmNetMeasureSrcTypeP."root".1 =3D STRING: "ip.tcp" ippmNetMeasureSrc."root".1 =3D STRING: "66.14.75.68 12634" ippmNetMeasureDstTypeP."root".1 =3D STRING: "ip.tcp" ippmNetMeasureDst."root".1 =3D STRING: "62.161.75.221 = 9000" ippmNetMeasureTxMode."root".1 =3D INTEGER: periodic(1) ippmNetMeasureTxPacketRateUnit."root".1 =3D INTEGER: second(5) ippmNetMeasureTxPacketRate."root".1 =3D Gauge32: 10 Packets ippmNetMeasureMedOrBurstSize."root".1 =3D Gauge32: 0 Packets ippmNetMeasureDevOrIntBurstSize."root".1 =3D Gauge32: 0 Packets ippmNetMeasureLossTimeout."root".1 =3D Gauge32: 800 Milliseconds ippmNetMeasureL3PacketSize."root".1 =3D Gauge32: 156 Bytes ippmNetMeasureDataPattern."root".1 =3D STRING: "7" ippmNetMeasureMap."root".1 =3D STRING: "Net Measure for = One Way Delay" ippmNetMeasureTotalPktsRecv."root".1 =3D Counter64: 12674 Packets ippmNetMeasureLastUpdate."root".1 =3D Hex-STRING: 07 58 0D 88 00 = 00 00 00=20 ippmNetMeasureOperState."root".1 =3D INTEGER: stopped(2) The duration of the measure is 1260 seconds (07580D88 - 0758089C). The rate is 10 pkts/s. So the total packets received is closed to 12600 9. Aggregated Measure Table Once the scenario is started, Netadvisor creates the new aggregated measures in the IPPM Proxy. # measure root.2 Type-P-One-way-Delay-Median(9) of the measure "root".1 # ippmAggrMeasureName."root".2 =3D STRING: New Test Config ippmAggrMeasureMetrics."root".2 =3D STRING: "0000000001000000000000000000000000" ippmAggrMeasureBeginTime."root".2 =3D Hex-STRING: 07 58 08 9C 00 00 = 00 00 ippmAggrMeasureAggrPeriodUnit."root".2=3D INTEGER: second(6) ippmAggrMeasureAggrPeriod."root".2 =3D INTEGER: 10 ippmAggrMeasureDurationUnit."root".2 =3D INTEGER: second(6) ippmAggrMeasureDuration."root".2 =3D INTEGER: 1800 ippmAggrMeasureHistorySize."root".2 =3D INTEGER: 190 ippmAggrMeasureStorageType."root".2 =3D INTEGER: nonVolatile(3) ippmAggrMeasureResultsMgmt."root".2 =3D INTEGER: suspend(2) ippmAggrMeasureHistoryOwner."root".2 =3D STRING: "root" ippmAggrMeasureHistoryMetric."root".2 =3D INTEGER: 6 ippmAggrMeasureHistoryOwnerIndex."root".2 =3D INTEGER: 1 ippmAggrMeasureAdminState."root".2 =3D INTEGER: start(0) ippmAggrMeasureFastReport."root".2 =3D OID: SNMPv2-SMI::zeroDotZero ippmAggrMeasureMap."root".2 =3D STRING: Net Measure for One = Way Delay ippmAggrMeasureLastUpdate."root".2 =3D Hex-STRING: 07 58 0D 88 00 00 = 00 00 ippmAggrMeasureOperState."root".2 =3D INTEGER: running(1) ippmAggrMeasureNbPktsTreated."root".2 =3D INTEGER: 126 ippmAggrMeasureStatus."root".2 =3D INTEGER: active(1) # measure root.3 Type-P-One-way-Delay-Minimum(10) of the measure "root".1 # ippmAggrMeasureName."root".3 =3D STRING: New Test Config ippmAggrMeasureMetrics."root".3 =3D STRING: "0000000000100000000000000000000000" ippmAggrMeasureBeginTime."root".3 =3D Hex-STRING: 07 58 08 9C 00 00 = 00 00 ippmAggrMeasureAggrPeriodUnit."root".3=3D INTEGER: second(6) ippmAggrMeasureAggrPeriod."root".3 =3D INTEGER: 10 ippmAggrMeasureDurationUnit."root".3 =3D INTEGER: second(6) ippmAggrMeasureDuration."root".3 =3D INTEGER: 1800 ippmAggrMeasureHistorySize."root".3 =3D INTEGER: 190 ippmAggrMeasureStorageType."root".3 =3D INTEGER: nonVolatile(3) ippmAggrMeasureResultsMgmt."root".3 =3D INTEGER: suspend(2) ippmAggrMeasureHistoryOwner."root".3 =3D STRING: "root" ippmAggrMeasureHistoryOwnerIndex."root".3 =3D INTEGER: 1 ippmAggrMeasureHistoryMetric."root".3 =3D INTEGER: 6 ippmAggrMeasureAdminState."root".3 =3D INTEGER: start(0) ippmAggrMeasureFastReport."root".3 =3D OID: SNMPv2-SMI::zeroDotZero ippmAggrMeasureMap."root".3 =3D STRING: Net Measure for One = Way Delay ippmAggrMeasureLastUpdate."root".3 =3D Hex-STRING: 07 58 0D 88 00 00 = 00 00 ippmAggrMeasureOperState."root".3 =3D INTEGER: running(1) ippmAggrMeasureNbPktsTreated."root".3 =3D INTEGER: 126 ippmAggrMeasureStatus."root".3 =3D INTEGER: active(1) 10. History Table # Results for the aggregated measure named 'root.2': owd median # # The average delay from California to France is close to 101 ms # ippmHistoryTimestamp."root".2.9.1 =3D Hex-STRING: 07 58 08 A6 00 00 = 00 00=20 ippmHistoryValue."root".1.9.1 =3D INTEGER: 101167304 ippmHistoryTimestamp."root".2.9.2 =3D Hex-STRING: 07 58 08 B0 00 00 = 00 00=20 ippmHistoryValue."root".2.9.2 =3D INTEGER: 101306811 ippmHistoryTimestamp."root".2.9.3 =3D Hex-STRING: 07 58 08 BA 00 00 = 00 00=20 ippmHistoryValue."root".2.9.3 =3D INTEGER: 101211175 ippmHistoryTimestamp."root".2.9.4 =3D Hex-STRING: 07 58 08 C4 00 00 = 00 00=20 ippmHistoryValue."root".2.9.4 =3D INTEGER: 101080395 ippmHistoryTimestamp."root".2.9.5 =3D Hex-STRING: 07 58 08 CE 00 00 = 00 00=20 ippmHistoryValue."root".2.9.5 =3D INTEGER: 100703053 ippmHistoryTimestamp."root".2.9.6 =3D Hex-STRING: 07 58 08 D8 00 00 = 00 00=20 ippmHistoryValue."root".2.9.6 =3D INTEGER: 100790354 ippmHistoryTimestamp."root".2.9.7 =3D Hex-STRING: 07 58 08 E2 00 00 = 00 00=20 ippmHistoryValue."root".2.9.7 =3D INTEGER: 100831317 ippmHistoryTimestamp."root".2.9.8 =3D Hex-STRING: 07 58 08 EC 00 00 = 00 00=20 ippmHistoryValue."root".2.9.8 =3D INTEGER: 101174398 ippmHistoryTimestamp."root".2.9.9 =3D Hex-STRING: 07 58 08 F6 00 00 = 00 00 ippmHistoryValue."root".2.9.9 =3D INTEGER: 100669560 ... # Results for the aggregated measure named 'root.3': owd minimum # # The minimum delay from California to France is 98 ms # ippmHistoryTimestamp."root".3.10.1 =3D Hex-STRING: 07 58 08 A6 00 00 = 00 00=20 ippmHistoryValue."root".3.10.1 =3D INTEGER: 98592163 ippmHistoryTimestamp."root".3.10.2 =3D Hex-STRING: 07 58 08 B0 00 00 = 00 00=20 ippmHistoryValue."root".3.10.2 =3D INTEGER: 98607014 ippmHistoryTimestamp."root".3.10.3 =3D Hex-STRING: 07 58 08 BA 00 00 = 00 00=20 ippmHistoryValue."root".3.10.3 =3D INTEGER: 98937947 ippmHistoryTimestamp."root".3.10.4 =3D Hex-STRING: 07 58 08 C4 00 00 = 00 00=20 ippmHistoryValue."root".3.10.4 =3D INTEGER: 98689982 ippmHistoryTimestamp."root".3.10.5 =3D Hex-STRING: 07 58 08 CE 00 00 = 00 00=20 ippmHistoryValue."root".3.10.5 =3D INTEGER: 98512898 ippmHistoryTimestamp."root".3.10.6 =3D Hex-STRING: 07 58 08 D8 00 00 = 00 00=20 ippmHistoryValue."root".3.10.6 =3D INTEGER: 98537068 ippmHistoryTimestamp."root".3.10.7 =3D Hex-STRING: 07 58 08 E2 00 00 = 00 00=20 ippmHistoryValue."root".3.10.7 =3D INTEGER: 98901570 ippmHistoryTimestamp."root".3.10.8 =3D Hex-STRING: 07 58 08 EC 00 00 = 00 00=20 ippmHistoryValue."root".3.10.8 =3D INTEGER: 99173706 ippmHistoryTimestamp."root".3.10.9 =3D Hex-STRING: 07 58 08 F6 00 00 = 00 00 ippmHistoryValue."root".3.10.9 =3D INTEGER: 98840372 ... ------_=_NextPart_001_01C3BD97.AFFEA5BE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IPPM MIB proxy trace

Dear all,

Following is a quick tour of the IPPM = REPORTING MIB in proxy mode. It corresponds to the demo made to the WG = chairs at the end of the WG session in Minneapolis.

The intend is to provide real MIB and = IPPM material to help IPPM fellows to make they mind on the IPPM MIB = without reading the MIB spec in detail:-)


Regards
Emile

1. abstract

France Telecom R&D and Qosmetrix = had recently integrated the implementation of IPPM MIB developed by = FranceTelecom lab in the measurement system of Qosmetrix, Netadvisor. = The IPPM MIB is implemented as a SNMPv2 proxy on the top of this = measurement system.

Information is extracted directly = from snmpwalks performed on the proxy. The prefix 'IPPM-REPORTING-MIB::' = is removed from all the statements.

2. Configuration

The first probe is located in = Qosmetrix lab in Camarillo (Ca) the second one is located in Qosmetrix = office in Massy (Paris, France).

The  Netadvisor and the IPPM = Proxy are located in Qosmetrix lab in Camarillo;

The test consists of 2 types of = measures:

   + One network measure is = running between Camarillo and Paris. It performs = Type-P-One-way-Delay(6). Its configuration is described in section = 8;

   + A first level of = aggregation is performed by the recipient probe. It computes = Type-P-One-way-Delay-Median(9) and Type-P-One-way-Delay-Minimums(10) = results and uploads them. Network measure singletons are not = uploaded.Their configurations are described in section 9;


3. ippmSystem group

ippmSystemTime.0 =3D Hex-STRING: 07 = 58 12 AF 34 DB 6A F8
ippmSystemSynchronizationType.0 =3D = INTEGER: other(0)
ippmSystemSynchronizationDesc.0 =3D = STRING: NO SYNCHRONIZATION AVAILABLE ON THIS SYSTEM
ippmSystemClockResolution.0 =3D = Gauge32: 10000000 Nanoseconds
ippmSystemOperationalStatus.0 =3D = INTEGER: up(1)


4. ippmOwners Table

ippmOwnersOwner.1 =3D STRING: = "ippmAdmin"
ippmOwnersGrantedMetrics.1 =3D = STRING: "0111111111111111111111111111111111"
ippmOwnersQuota.1 =3D Gauge32: = 4294967295
ippmOwnersIpAddressType.1 =3D = INTEGER: ipv6(2)
ippmOwnersIpAddress.1 =3D STRING: = "fe80::209:5bff:fe08:d420"
ippmOwnersEmail.1 =3D STRING: = ippmAdmin@qosmetrix.com
ippmOwnersSMS.1 =3D STRING: = 1-805-445-8504
ippmOwnersStatus.1 =3D INTEGER: = active(1)

ippmOwnersOwner.2 =3D STRING: = "root"
ippmOwnersGrantedMetrics.2 =3D = STRING: "0000001011110000000000000001011000"
ippmOwnersQuota.2 =3D Gauge32: = 2147483647
ippmOwnersIpAddressType.2 =3D = INTEGER: ipv4(1)
ippmOwnersIpAddress.2 =3D STRING: = "192.168.1.175"
ippmOwnersEmail.2 =3D STRING: = owner@qosmetrix.com
ippmOwnersSMS.2 =3D STRING: = 1-805-445-8504
ippmOwnersStatus.2 =3D INTEGER: = active(1)

5. ippmSynchronization Table

Following are the description of the = synchronization of the 2 probes:

ippmSynchronizationTime.1.1     = ;  =3D Hex-STRING: 00 00 00 00 00 00 00 00  
ippmSynchronizationStratum.1.1    =3D = Gauge32: 1 
ippmSynchronizationResolution.1.1 = =3D Gauge32: 40 Nanoseconds 

ippmSynchronizationTime.2.1     = ;  =3D Hex-STRING: 00 00 00 00 00 00 00 00  
ippmSynchronizationStratum.2.1    =3D = Gauge32: 1 
ippmSynchronizationResolution.2.1 = =3D Gauge32: 40 Nanoseconds 

6. ippmPointOfMeasure  Table =

ippmPointOfMeasureMgmtAddrType.1  =3D INTEGER: = ipv4(1)  
ippmPointOfMeasureMgmtAddress.1   =3D STRING: = "66.14.75.68"  
ippmPointOfMeasureTestAddrTypeP.1 = =3D STRING: "ip"  
ippmPointOfMeasureTestAddr.1    &nbs= p; =3D STRING: 66.14.75.68  
ippmPointOfMeasureMetrics.1     = ;  =3D STRING: = "0000001011110000000000000001011000"  

ippmPointOfMeasureMgmtAddrType.2  =3D INTEGER: = ipv4(1)  
ippmPointOfMeasureMgmtAddress.2   =3D STRING: = "62.161.75.221"  
ippmPointOfMeasureTestAddrTypeP.2 = =3D STRING: "ip"  
ippmPointOfMeasureTestAddr.2    &nbs= p; =3D STRING: 62.161.75.221  
ippmPointOfMeasureMetrics.2     = ;  =3D STRING: = "0000001011110000000000000001011000"  
 
7. Metrics Table

# Note: Only the entries of interest = are displayed.

...
ippmMetricCapabilities.6  =3D = INTEGER: implemented(1)   
ippmMetricType.6      &nbs= p;   =3D INTEGER: network(0)   
ippmMetricUnit.6      &nbs= p;   =3D INTEGER: nanosecond(8)   
ippmMetricDescription.6   = =3D STRING: Type-P-One-way-Delay   
...
ippmMetricCapabilities.9  =3D = INTEGER: implemented(1)   
ippmMetricType.9      &nbs= p;   =3D INTEGER: aggregated(1)   
ippmMetricUnit.9      &nbs= p;   =3D INTEGER: nanosecond(8)   
ippmMetricDescription.9   = =3D STRING: Type-P-One-way-Delay-Median   
...
ippmMetricCapabilities.10 =3D = INTEGER: implemented(1)   
ippmMetricType.10      &nb= sp;  =3D INTEGER: aggregated(1)   
ippmMetricUnit.10      &nb= sp;  =3D INTEGER: nanosecond(8)   
ippmMetricDescription.10  =3D = STRING: Type-P-One-way-Delay-Minimum   
...
ippmMetricCapabilities.27 =3D = INTEGER: implemented(1)   
ippmMetricType.27      &nb= sp;  =3D INTEGER: network(0)   
ippmMetricUnit.27      &nb= sp;  =3D INTEGER: nanosecond(9)   
ippmMetricDescription.27  =3D = STRING: Type-P-One-way-ipdv   
...

8. Network Measure Table

Once the scenario is started, = Netadvisor creates the new network measures in the IPPM Proxy.

# network measure root.1 = Type-P-One-way-Delay(6) and Type-P-One-way-ipdv(27)
# Note: aggregation derivated from = Type-P-One-way-ipdv(27) are not displayed in the document
#
ippmNetMeasureName."root".1   &= nbsp;          =3D STRING: = -New Test Config
ippmNetMeasureMetrics."root".1  &nbs= p;        =3D STRING: = "0000001000000000000000000001000000"
#         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;           = ^            =         ^
#         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;           = 6            =         27
# metric ID = ----------------------------------------------+--------------------+-----= -
#
ippmNetMeasureBeginTime."root".1  &n= bsp;      =3D Hex-STRING: 07 58 08 9C 00 00 00 = 00
ippmNetMeasureCollectionRateUnit."root".1=3D = INTEGER: minute(4)
ippmNetMeasureCollectionRate."root".1 &nb= sp;  =3D Gauge32: 1
ippmNetMeasureDurationUnit."root".1  = ;    =3D INTEGER: second(3)
ippmNetMeasureDuration."root".1  &nb= sp;       =3D Gauge32: 1800
ippmNetMeasureHistorySize."root".1  =      =3D Gauge32: 0
ippmNetMeasureFailureMgmtMode."root".1 &n= bsp; =3D INTEGER: auto(1)
ippmNetMeasureResultsMgmt."root".1  =      =3D INTEGER: suspend(2)
ippmNetMeasureSrcTypeP."root".1  &nb= sp;       =3D STRING: = "ip.tcp"
ippmNetMeasureSrc."root".1   &n= bsp;           =3D = STRING: "66.14.75.68 12634"
ippmNetMeasureDstTypeP."root".1  &nb= sp;       =3D STRING: = "ip.tcp"
ippmNetMeasureDst."root".1   &n= bsp;           =3D = STRING: "62.161.75.221 9000"
ippmNetMeasureTxMode."root".1   = ;         =3D INTEGER: = periodic(1)
ippmNetMeasureTxPacketRateUnit."root".1  = =3D INTEGER: second(5)
ippmNetMeasureTxPacketRate."root".1  = ;    =3D Gauge32: 10 Packets
ippmNetMeasureMedOrBurstSize."root".1 &nb= sp;  =3D Gauge32: 0 Packets
ippmNetMeasureDevOrIntBurstSize."root".1 =3D = Gauge32: 0 Packets
ippmNetMeasureLossTimeout."root".1  =      =3D Gauge32: 800 Milliseconds
ippmNetMeasureL3PacketSize."root".1  = ;    =3D Gauge32: 156 Bytes
ippmNetMeasureDataPattern."root".1  =      =3D STRING: "7"
ippmNetMeasureMap."root".1   &n= bsp;           =3D = STRING: "Net Measure for One Way Delay"
ippmNetMeasureTotalPktsRecv."root".1 &nbs= p;   =3D Counter64: 12674 Packets
ippmNetMeasureLastUpdate."root".1  &= nbsp;     =3D Hex-STRING: 07 58 0D 88 00 00 00 00 =
ippmNetMeasureOperState."root".1  &n= bsp;      =3D INTEGER: stopped(2)

The duration of the measure is 1260 = seconds (07580D88 - 0758089C). The rate is 10 pkts/s. So the total = packets received is closed to 12600

9. Aggregated Measure Table

Once the scenario is started, = Netadvisor creates the new aggregated measures in the IPPM Proxy.

# measure root.2  = Type-P-One-way-Delay-Median(9) of the measure "root".1
#
ippmAggrMeasureName."root".2   =        =3D STRING: New Test Config
ippmAggrMeasureMetrics."root".2  &nb= sp;    =3D STRING: = "0000000001000000000000000000000000"
ippmAggrMeasureBeginTime."root".2  &= nbsp;  =3D Hex-STRING: 07 58 08 9C 00 00 00 00
ippmAggrMeasureAggrPeriodUnit."root".2=3D = INTEGER: second(6)
ippmAggrMeasureAggrPeriod."root".2  =   =3D INTEGER: 10
ippmAggrMeasureDurationUnit."root".2  = =3D INTEGER: second(6)
ippmAggrMeasureDuration."root".2  &n= bsp;   =3D INTEGER: 1800
ippmAggrMeasureHistorySize."root".2  = ; =3D INTEGER: 190
ippmAggrMeasureStorageType."root".2  = ; =3D INTEGER: nonVolatile(3)
ippmAggrMeasureResultsMgmt."root".2  = ; =3D INTEGER: suspend(2)
ippmAggrMeasureHistoryOwner."root".2  = =3D STRING: "root"
ippmAggrMeasureHistoryMetric."root".2 =3D = INTEGER: 6
ippmAggrMeasureHistoryOwnerIndex."root".2 =3D = INTEGER: 1
ippmAggrMeasureAdminState."root".2  =   =3D INTEGER: start(0)
ippmAggrMeasureFastReport."root".2  =   =3D OID: SNMPv2-SMI::zeroDotZero
ippmAggrMeasureMap."root".2   &= nbsp;       =3D STRING: Net Measure for = One Way Delay
ippmAggrMeasureLastUpdate."root".2  =   =3D Hex-STRING: 07 58 0D 88 00 00 00 00
ippmAggrMeasureOperState."root".2  &= nbsp;  =3D INTEGER: running(1)
ippmAggrMeasureNbPktsTreated."root".2 =3D = INTEGER: 126
ippmAggrMeasureStatus."root".2  &nbs= p;     =3D INTEGER: active(1)

# measure root.3  = Type-P-One-way-Delay-Minimum(10) of the measure = "root".1
#
ippmAggrMeasureName."root".3   =        =3D STRING: New Test Config
ippmAggrMeasureMetrics."root".3  &nb= sp;    =3D STRING: = "0000000000100000000000000000000000"
ippmAggrMeasureBeginTime."root".3  &= nbsp;  =3D Hex-STRING: 07 58 08 9C 00 00 00 00
ippmAggrMeasureAggrPeriodUnit."root".3=3D = INTEGER: second(6)
ippmAggrMeasureAggrPeriod."root".3  =   =3D INTEGER: 10
ippmAggrMeasureDurationUnit."root".3  = =3D INTEGER: second(6)
ippmAggrMeasureDuration."root".3  &n= bsp;   =3D INTEGER: 1800
ippmAggrMeasureHistorySize."root".3  = ; =3D INTEGER: 190
ippmAggrMeasureStorageType."root".3  = ; =3D INTEGER: nonVolatile(3)
ippmAggrMeasureResultsMgmt."root".3  = ; =3D INTEGER: suspend(2)
ippmAggrMeasureHistoryOwner."root".3  = =3D STRING: "root"
ippmAggrMeasureHistoryOwnerIndex."root".3 =3D = INTEGER: 1
ippmAggrMeasureHistoryMetric."root".3 =3D = INTEGER: 6
ippmAggrMeasureAdminState."root".3  =   =3D INTEGER: start(0)
ippmAggrMeasureFastReport."root".3  =   =3D OID: SNMPv2-SMI::zeroDotZero
ippmAggrMeasureMap."root".3   &= nbsp;       =3D STRING: Net Measure for = One Way Delay
ippmAggrMeasureLastUpdate."root".3  =   =3D Hex-STRING: 07 58 0D 88 00 00 00 00
ippmAggrMeasureOperState."root".3  &= nbsp;  =3D INTEGER: running(1)
ippmAggrMeasureNbPktsTreated."root".3 =3D = INTEGER: 126
ippmAggrMeasureStatus."root".3  &nbs= p;     =3D INTEGER: active(1)


10. History Table

# Results for the aggregated measure = named 'root.2': owd median
#
# The average delay from California = to France is close  to 101 ms
#

ippmHistoryTimestamp."root".2.9.1  &= nbsp;  =3D Hex-STRING: 07 58 08 A6 00 00 00 00
ippmHistoryValue."root".1.9.1   = ;      =3D INTEGER: 101167304
ippmHistoryTimestamp."root".2.9.2  &= nbsp;  =3D Hex-STRING: 07 58 08 B0 00 00 00 00
ippmHistoryValue."root".2.9.2   = ;      =3D INTEGER: 101306811
ippmHistoryTimestamp."root".2.9.3  &= nbsp;  =3D Hex-STRING: 07 58 08 BA 00 00 00 00
ippmHistoryValue."root".2.9.3   = ;      =3D INTEGER: 101211175
ippmHistoryTimestamp."root".2.9.4  &= nbsp;  =3D Hex-STRING: 07 58 08 C4 00 00 00 00
ippmHistoryValue."root".2.9.4   = ;      =3D INTEGER: 101080395
ippmHistoryTimestamp."root".2.9.5  &= nbsp;  =3D Hex-STRING: 07 58 08 CE 00 00 00 00
ippmHistoryValue."root".2.9.5   = ;      =3D INTEGER: 100703053
ippmHistoryTimestamp."root".2.9.6  &= nbsp;  =3D Hex-STRING: 07 58 08 D8 00 00 00 00
ippmHistoryValue."root".2.9.6   = ;      =3D INTEGER: 100790354
ippmHistoryTimestamp."root".2.9.7  &= nbsp;  =3D Hex-STRING: 07 58 08 E2 00 00 00 00
ippmHistoryValue."root".2.9.7   = ;      =3D INTEGER: 100831317
ippmHistoryTimestamp."root".2.9.8  &= nbsp;  =3D Hex-STRING: 07 58 08 EC 00 00 00 00
ippmHistoryValue."root".2.9.8   = ;      =3D INTEGER: 101174398
ippmHistoryTimestamp."root".2.9.9  &= nbsp;  =3D Hex-STRING: 07 58 08 F6 00 00 00 00
ippmHistoryValue."root".2.9.9   = ;      =3D INTEGER: 100669560
...

# Results for the aggregated measure = named 'root.3': owd minimum
#
# The minimum delay from California = to France is 98 ms
#
ippmHistoryTimestamp."root".3.10.1  =   =3D Hex-STRING: 07 58 08 A6 00 00 00 00
ippmHistoryValue."root".3.10.1  &nbs= p;     =3D INTEGER: 98592163
ippmHistoryTimestamp."root".3.10.2  =   =3D Hex-STRING: 07 58 08 B0 00 00 00 00
ippmHistoryValue."root".3.10.2  &nbs= p;     =3D INTEGER: 98607014
ippmHistoryTimestamp."root".3.10.3  =   =3D Hex-STRING: 07 58 08 BA 00 00 00 00
ippmHistoryValue."root".3.10.3  &nbs= p;     =3D INTEGER: 98937947
ippmHistoryTimestamp."root".3.10.4  =   =3D Hex-STRING: 07 58 08 C4 00 00 00 00
ippmHistoryValue."root".3.10.4  &nbs= p;     =3D INTEGER: 98689982
ippmHistoryTimestamp."root".3.10.5  =   =3D Hex-STRING: 07 58 08 CE 00 00 00 00
ippmHistoryValue."root".3.10.5  &nbs= p;     =3D INTEGER: 98512898
ippmHistoryTimestamp."root".3.10.6  =   =3D Hex-STRING: 07 58 08 D8 00 00 00 00
ippmHistoryValue."root".3.10.6  &nbs= p;     =3D INTEGER: 98537068
ippmHistoryTimestamp."root".3.10.7  =   =3D Hex-STRING: 07 58 08 E2 00 00 00 00
ippmHistoryValue."root".3.10.7  &nbs= p;     =3D INTEGER: 98901570
ippmHistoryTimestamp."root".3.10.8  =   =3D Hex-STRING: 07 58 08 EC 00 00 00 00
ippmHistoryValue."root".3.10.8  &nbs= p;     =3D INTEGER: 99173706
ippmHistoryTimestamp."root".3.10.9  =   =3D Hex-STRING: 07 58 08 F6 00 00 00 00
ippmHistoryValue."root".3.10.9  &nbs= p;     =3D INTEGER: 98840372
...


------_=_NextPart_001_01C3BD97.AFFEA5BE-- _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Mon Dec 8 18:37:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12786 for ; Mon, 8 Dec 2003 18:37:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATUwJ-0003Qu-Ho for ippm-archive@odin.ietf.org; Mon, 08 Dec 2003 18:37:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8NbJXw013188 for ippm-archive@odin.ietf.org; Mon, 8 Dec 2003 18:37:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATUwG-0003Pb-O7 for ippm-web-archive@optimus.ietf.org; Mon, 08 Dec 2003 18:37:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12756 for ; Mon, 8 Dec 2003 18:36:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATUwD-0001mN-00 for ippm-web-archive@ietf.org; Mon, 08 Dec 2003 18:37:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATUwD-0001mJ-00 for ippm-web-archive@ietf.org; Mon, 08 Dec 2003 18:37:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATUw1-0003Ik-FZ; Mon, 08 Dec 2003 18:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATMOS-0008Bj-O1 for ippm@optimus.ietf.org; Mon, 08 Dec 2003 09:29:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10507 for ; Mon, 8 Dec 2003 09:29:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATMOQ-0004nu-00 for ippm@ietf.org; Mon, 08 Dec 2003 09:29:46 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx with esmtp (Exim 4.12) id 1ATMOO-0004nr-00 for ippm@ietf.org; Mon, 08 Dec 2003 09:29:44 -0500 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 8 Dec 2003 15:29:29 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3BD97.AFFEA5BE" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 8 Dec 2003 15:29:28 +0100 Message-ID: Thread-Topic: IPPM MIB proxy trace Thread-Index: AcO9l4zjbmDi4a88RHuCWBTk2r3aAw== From: "STEPHAN Emile FTRD/DAC/LAN" To: "Henk Uijterwaal (RIPE-NCC)" , "Matthew J Zekauskas" Cc: "Romascanu, Dan (Dan)" , , "Andy Bierman" , "Al Morton" X-OriginalArrivalTime: 08 Dec 2003 14:29:29.0571 (UTC) FILETIME=[B084CB30:01C3BD97] Subject: [ippm] IPPM MIB proxy trace Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3BD97.AFFEA5BE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Following is a quick tour of the IPPM REPORTING MIB in proxy mode. It corresponds to the demo made to the WG chairs at the end of the WG session in Minneapolis. The intend is to provide real MIB and IPPM material to help IPPM fellows to make they mind on the IPPM MIB without reading the MIB spec in detail:-) Regards Emile 1. abstract=20 France Telecom R&D and Qosmetrix had recently integrated the implementation of IPPM MIB developed by FranceTelecom lab in the measurement system of Qosmetrix, Netadvisor. The IPPM MIB is implemented as a SNMPv2 proxy on the top of this measurement system.=20 Information is extracted directly from snmpwalks performed on the proxy. The prefix 'IPPM-REPORTING-MIB::' is removed from all the statements. 2. Configuration The first probe is located in Qosmetrix lab in Camarillo (Ca) the second one is located in Qosmetrix office in Massy (Paris, France). The Netadvisor and the IPPM Proxy are located in Qosmetrix lab in Camarillo; The test consists of 2 types of measures: + One network measure is running between Camarillo and Paris. It performs Type-P-One-way-Delay(6). Its configuration is described in section 8; + A first level of aggregation is performed by the recipient probe. It computes Type-P-One-way-Delay-Median(9) and Type-P-One-way-Delay-Minimums(10) results and uploads them. Network measure singletons are not uploaded.Their configurations are described in section 9; 3. ippmSystem group=20 ippmSystemTime.0 =3D Hex-STRING: 07 58 12 AF 34 DB 6A F8=20 ippmSystemSynchronizationType.0 =3D INTEGER: other(0) ippmSystemSynchronizationDesc.0 =3D STRING: NO SYNCHRONIZATION AVAILABLE ON THIS SYSTEM ippmSystemClockResolution.0 =3D Gauge32: 10000000 Nanoseconds ippmSystemOperationalStatus.0 =3D INTEGER: up(1) 4. ippmOwners Table=20 ippmOwnersOwner.1 =3D STRING: "ippmAdmin" ippmOwnersGrantedMetrics.1 =3D STRING: "0111111111111111111111111111111111" ippmOwnersQuota.1 =3D Gauge32: 4294967295 ippmOwnersIpAddressType.1 =3D INTEGER: ipv6(2) ippmOwnersIpAddress.1 =3D STRING: "fe80::209:5bff:fe08:d420" ippmOwnersEmail.1 =3D STRING: ippmAdmin@qosmetrix.com ippmOwnersSMS.1 =3D STRING: 1-805-445-8504 ippmOwnersStatus.1 =3D INTEGER: active(1) ippmOwnersOwner.2 =3D STRING: "root" ippmOwnersGrantedMetrics.2 =3D STRING: "0000001011110000000000000001011000" ippmOwnersQuota.2 =3D Gauge32: 2147483647 ippmOwnersIpAddressType.2 =3D INTEGER: ipv4(1) ippmOwnersIpAddress.2 =3D STRING: "192.168.1.175" ippmOwnersEmail.2 =3D STRING: owner@qosmetrix.com ippmOwnersSMS.2 =3D STRING: 1-805-445-8504 ippmOwnersStatus.2 =3D INTEGER: active(1) 5. ippmSynchronization Table=20 Following are the description of the synchronization of the 2 probes: ippmSynchronizationTime.1.1 =3D Hex-STRING: 00 00 00 00 00 00 00 = 00 ippmSynchronizationStratum.1.1 =3D Gauge32: 1 =20 ippmSynchronizationResolution.1.1 =3D Gauge32: 40 Nanoseconds =20 ippmSynchronizationTime.2.1 =3D Hex-STRING: 00 00 00 00 00 00 00 = 00 ippmSynchronizationStratum.2.1 =3D Gauge32: 1 =20 ippmSynchronizationResolution.2.1 =3D Gauge32: 40 Nanoseconds =20 6. ippmPointOfMeasure Table=20 ippmPointOfMeasureMgmtAddrType.1 =3D INTEGER: ipv4(1) =20 ippmPointOfMeasureMgmtAddress.1 =3D STRING: "66.14.75.68" =20 ippmPointOfMeasureTestAddrTypeP.1 =3D STRING: "ip" =20 ippmPointOfMeasureTestAddr.1 =3D STRING: 66.14.75.68 =20 ippmPointOfMeasureMetrics.1 =3D STRING: "0000001011110000000000000001011000" =20 ippmPointOfMeasureMgmtAddrType.2 =3D INTEGER: ipv4(1) =20 ippmPointOfMeasureMgmtAddress.2 =3D STRING: "62.161.75.221" =20 ippmPointOfMeasureTestAddrTypeP.2 =3D STRING: "ip" =20 ippmPointOfMeasureTestAddr.2 =3D STRING: 62.161.75.221 =20 ippmPointOfMeasureMetrics.2 =3D STRING: "0000001011110000000000000001011000" =20 =20 7. Metrics Table=20 # Note: Only the entries of interest are displayed. ... ippmMetricCapabilities.6 =3D INTEGER: implemented(1) =20 ippmMetricType.6 =3D INTEGER: network(0) =20 ippmMetricUnit.6 =3D INTEGER: nanosecond(8) =20 ippmMetricDescription.6 =3D STRING: Type-P-One-way-Delay =20 ... ippmMetricCapabilities.9 =3D INTEGER: implemented(1) =20 ippmMetricType.9 =3D INTEGER: aggregated(1) =20 ippmMetricUnit.9 =3D INTEGER: nanosecond(8) =20 ippmMetricDescription.9 =3D STRING: Type-P-One-way-Delay-Median =20 ... ippmMetricCapabilities.10 =3D INTEGER: implemented(1) =20 ippmMetricType.10 =3D INTEGER: aggregated(1) =20 ippmMetricUnit.10 =3D INTEGER: nanosecond(8) =20 ippmMetricDescription.10 =3D STRING: Type-P-One-way-Delay-Minimum =20 ... ippmMetricCapabilities.27 =3D INTEGER: implemented(1) =20 ippmMetricType.27 =3D INTEGER: network(0) =20 ippmMetricUnit.27 =3D INTEGER: nanosecond(9) =20 ippmMetricDescription.27 =3D STRING: Type-P-One-way-ipdv =20 ... 8. Network Measure Table Once the scenario is started, Netadvisor creates the new network measures in the IPPM Proxy. # network measure root.1 Type-P-One-way-Delay(6) and Type-P-One-way-ipdv(27) # Note: aggregation derivated from Type-P-One-way-ipdv(27) are not displayed in the document # ippmNetMeasureName."root".1 =3D STRING: -New Test Config ippmNetMeasureMetrics."root".1 =3D STRING: "0000001000000000000000000001000000" # ^ ^ # 6 27 # metric ID ----------------------------------------------+--------------------+---- -- # ippmNetMeasureBeginTime."root".1 =3D Hex-STRING: 07 58 08 9C 00 = 00 00 00=20 ippmNetMeasureCollectionRateUnit."root".1=3D INTEGER: minute(4) ippmNetMeasureCollectionRate."root".1 =3D Gauge32: 1 ippmNetMeasureDurationUnit."root".1 =3D INTEGER: second(3) ippmNetMeasureDuration."root".1 =3D Gauge32: 1800 ippmNetMeasureHistorySize."root".1 =3D Gauge32: 0 ippmNetMeasureFailureMgmtMode."root".1 =3D INTEGER: auto(1) ippmNetMeasureResultsMgmt."root".1 =3D INTEGER: suspend(2) ippmNetMeasureSrcTypeP."root".1 =3D STRING: "ip.tcp" ippmNetMeasureSrc."root".1 =3D STRING: "66.14.75.68 12634" ippmNetMeasureDstTypeP."root".1 =3D STRING: "ip.tcp" ippmNetMeasureDst."root".1 =3D STRING: "62.161.75.221 = 9000" ippmNetMeasureTxMode."root".1 =3D INTEGER: periodic(1) ippmNetMeasureTxPacketRateUnit."root".1 =3D INTEGER: second(5) ippmNetMeasureTxPacketRate."root".1 =3D Gauge32: 10 Packets ippmNetMeasureMedOrBurstSize."root".1 =3D Gauge32: 0 Packets ippmNetMeasureDevOrIntBurstSize."root".1 =3D Gauge32: 0 Packets ippmNetMeasureLossTimeout."root".1 =3D Gauge32: 800 Milliseconds ippmNetMeasureL3PacketSize."root".1 =3D Gauge32: 156 Bytes ippmNetMeasureDataPattern."root".1 =3D STRING: "7" ippmNetMeasureMap."root".1 =3D STRING: "Net Measure for = One Way Delay" ippmNetMeasureTotalPktsRecv."root".1 =3D Counter64: 12674 Packets ippmNetMeasureLastUpdate."root".1 =3D Hex-STRING: 07 58 0D 88 00 = 00 00 00=20 ippmNetMeasureOperState."root".1 =3D INTEGER: stopped(2) The duration of the measure is 1260 seconds (07580D88 - 0758089C). The rate is 10 pkts/s. So the total packets received is closed to 12600 9. Aggregated Measure Table Once the scenario is started, Netadvisor creates the new aggregated measures in the IPPM Proxy. # measure root.2 Type-P-One-way-Delay-Median(9) of the measure "root".1 # ippmAggrMeasureName."root".2 =3D STRING: New Test Config ippmAggrMeasureMetrics."root".2 =3D STRING: "0000000001000000000000000000000000" ippmAggrMeasureBeginTime."root".2 =3D Hex-STRING: 07 58 08 9C 00 00 = 00 00 ippmAggrMeasureAggrPeriodUnit."root".2=3D INTEGER: second(6) ippmAggrMeasureAggrPeriod."root".2 =3D INTEGER: 10 ippmAggrMeasureDurationUnit."root".2 =3D INTEGER: second(6) ippmAggrMeasureDuration."root".2 =3D INTEGER: 1800 ippmAggrMeasureHistorySize."root".2 =3D INTEGER: 190 ippmAggrMeasureStorageType."root".2 =3D INTEGER: nonVolatile(3) ippmAggrMeasureResultsMgmt."root".2 =3D INTEGER: suspend(2) ippmAggrMeasureHistoryOwner."root".2 =3D STRING: "root" ippmAggrMeasureHistoryMetric."root".2 =3D INTEGER: 6 ippmAggrMeasureHistoryOwnerIndex."root".2 =3D INTEGER: 1 ippmAggrMeasureAdminState."root".2 =3D INTEGER: start(0) ippmAggrMeasureFastReport."root".2 =3D OID: SNMPv2-SMI::zeroDotZero ippmAggrMeasureMap."root".2 =3D STRING: Net Measure for One = Way Delay ippmAggrMeasureLastUpdate."root".2 =3D Hex-STRING: 07 58 0D 88 00 00 = 00 00 ippmAggrMeasureOperState."root".2 =3D INTEGER: running(1) ippmAggrMeasureNbPktsTreated."root".2 =3D INTEGER: 126 ippmAggrMeasureStatus."root".2 =3D INTEGER: active(1) # measure root.3 Type-P-One-way-Delay-Minimum(10) of the measure "root".1 # ippmAggrMeasureName."root".3 =3D STRING: New Test Config ippmAggrMeasureMetrics."root".3 =3D STRING: "0000000000100000000000000000000000" ippmAggrMeasureBeginTime."root".3 =3D Hex-STRING: 07 58 08 9C 00 00 = 00 00 ippmAggrMeasureAggrPeriodUnit."root".3=3D INTEGER: second(6) ippmAggrMeasureAggrPeriod."root".3 =3D INTEGER: 10 ippmAggrMeasureDurationUnit."root".3 =3D INTEGER: second(6) ippmAggrMeasureDuration."root".3 =3D INTEGER: 1800 ippmAggrMeasureHistorySize."root".3 =3D INTEGER: 190 ippmAggrMeasureStorageType."root".3 =3D INTEGER: nonVolatile(3) ippmAggrMeasureResultsMgmt."root".3 =3D INTEGER: suspend(2) ippmAggrMeasureHistoryOwner."root".3 =3D STRING: "root" ippmAggrMeasureHistoryOwnerIndex."root".3 =3D INTEGER: 1 ippmAggrMeasureHistoryMetric."root".3 =3D INTEGER: 6 ippmAggrMeasureAdminState."root".3 =3D INTEGER: start(0) ippmAggrMeasureFastReport."root".3 =3D OID: SNMPv2-SMI::zeroDotZero ippmAggrMeasureMap."root".3 =3D STRING: Net Measure for One = Way Delay ippmAggrMeasureLastUpdate."root".3 =3D Hex-STRING: 07 58 0D 88 00 00 = 00 00 ippmAggrMeasureOperState."root".3 =3D INTEGER: running(1) ippmAggrMeasureNbPktsTreated."root".3 =3D INTEGER: 126 ippmAggrMeasureStatus."root".3 =3D INTEGER: active(1) 10. History Table # Results for the aggregated measure named 'root.2': owd median # # The average delay from California to France is close to 101 ms # ippmHistoryTimestamp."root".2.9.1 =3D Hex-STRING: 07 58 08 A6 00 00 = 00 00=20 ippmHistoryValue."root".1.9.1 =3D INTEGER: 101167304 ippmHistoryTimestamp."root".2.9.2 =3D Hex-STRING: 07 58 08 B0 00 00 = 00 00=20 ippmHistoryValue."root".2.9.2 =3D INTEGER: 101306811 ippmHistoryTimestamp."root".2.9.3 =3D Hex-STRING: 07 58 08 BA 00 00 = 00 00=20 ippmHistoryValue."root".2.9.3 =3D INTEGER: 101211175 ippmHistoryTimestamp."root".2.9.4 =3D Hex-STRING: 07 58 08 C4 00 00 = 00 00=20 ippmHistoryValue."root".2.9.4 =3D INTEGER: 101080395 ippmHistoryTimestamp."root".2.9.5 =3D Hex-STRING: 07 58 08 CE 00 00 = 00 00=20 ippmHistoryValue."root".2.9.5 =3D INTEGER: 100703053 ippmHistoryTimestamp."root".2.9.6 =3D Hex-STRING: 07 58 08 D8 00 00 = 00 00=20 ippmHistoryValue."root".2.9.6 =3D INTEGER: 100790354 ippmHistoryTimestamp."root".2.9.7 =3D Hex-STRING: 07 58 08 E2 00 00 = 00 00=20 ippmHistoryValue."root".2.9.7 =3D INTEGER: 100831317 ippmHistoryTimestamp."root".2.9.8 =3D Hex-STRING: 07 58 08 EC 00 00 = 00 00=20 ippmHistoryValue."root".2.9.8 =3D INTEGER: 101174398 ippmHistoryTimestamp."root".2.9.9 =3D Hex-STRING: 07 58 08 F6 00 00 = 00 00 ippmHistoryValue."root".2.9.9 =3D INTEGER: 100669560 ... # Results for the aggregated measure named 'root.3': owd minimum # # The minimum delay from California to France is 98 ms # ippmHistoryTimestamp."root".3.10.1 =3D Hex-STRING: 07 58 08 A6 00 00 = 00 00=20 ippmHistoryValue."root".3.10.1 =3D INTEGER: 98592163 ippmHistoryTimestamp."root".3.10.2 =3D Hex-STRING: 07 58 08 B0 00 00 = 00 00=20 ippmHistoryValue."root".3.10.2 =3D INTEGER: 98607014 ippmHistoryTimestamp."root".3.10.3 =3D Hex-STRING: 07 58 08 BA 00 00 = 00 00=20 ippmHistoryValue."root".3.10.3 =3D INTEGER: 98937947 ippmHistoryTimestamp."root".3.10.4 =3D Hex-STRING: 07 58 08 C4 00 00 = 00 00=20 ippmHistoryValue."root".3.10.4 =3D INTEGER: 98689982 ippmHistoryTimestamp."root".3.10.5 =3D Hex-STRING: 07 58 08 CE 00 00 = 00 00=20 ippmHistoryValue."root".3.10.5 =3D INTEGER: 98512898 ippmHistoryTimestamp."root".3.10.6 =3D Hex-STRING: 07 58 08 D8 00 00 = 00 00=20 ippmHistoryValue."root".3.10.6 =3D INTEGER: 98537068 ippmHistoryTimestamp."root".3.10.7 =3D Hex-STRING: 07 58 08 E2 00 00 = 00 00=20 ippmHistoryValue."root".3.10.7 =3D INTEGER: 98901570 ippmHistoryTimestamp."root".3.10.8 =3D Hex-STRING: 07 58 08 EC 00 00 = 00 00=20 ippmHistoryValue."root".3.10.8 =3D INTEGER: 99173706 ippmHistoryTimestamp."root".3.10.9 =3D Hex-STRING: 07 58 08 F6 00 00 = 00 00 ippmHistoryValue."root".3.10.9 =3D INTEGER: 98840372 ... ------_=_NextPart_001_01C3BD97.AFFEA5BE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IPPM MIB proxy trace

Dear all,

Following is a quick tour of the IPPM = REPORTING MIB in proxy mode. It corresponds to the demo made to the WG = chairs at the end of the WG session in Minneapolis.

The intend is to provide real MIB and = IPPM material to help IPPM fellows to make they mind on the IPPM MIB = without reading the MIB spec in detail:-)


Regards
Emile

1. abstract

France Telecom R&D and Qosmetrix = had recently integrated the implementation of IPPM MIB developed by = FranceTelecom lab in the measurement system of Qosmetrix, Netadvisor. = The IPPM MIB is implemented as a SNMPv2 proxy on the top of this = measurement system.

Information is extracted directly = from snmpwalks performed on the proxy. The prefix 'IPPM-REPORTING-MIB::' = is removed from all the statements.

2. Configuration

The first probe is located in = Qosmetrix lab in Camarillo (Ca) the second one is located in Qosmetrix = office in Massy (Paris, France).

The  Netadvisor and the IPPM = Proxy are located in Qosmetrix lab in Camarillo;

The test consists of 2 types of = measures:

   + One network measure is = running between Camarillo and Paris. It performs = Type-P-One-way-Delay(6). Its configuration is described in section = 8;

   + A first level of = aggregation is performed by the recipient probe. It computes = Type-P-One-way-Delay-Median(9) and Type-P-One-way-Delay-Minimums(10) = results and uploads them. Network measure singletons are not = uploaded.Their configurations are described in section 9;


3. ippmSystem group

ippmSystemTime.0 =3D Hex-STRING: 07 = 58 12 AF 34 DB 6A F8
ippmSystemSynchronizationType.0 =3D = INTEGER: other(0)
ippmSystemSynchronizationDesc.0 =3D = STRING: NO SYNCHRONIZATION AVAILABLE ON THIS SYSTEM
ippmSystemClockResolution.0 =3D = Gauge32: 10000000 Nanoseconds
ippmSystemOperationalStatus.0 =3D = INTEGER: up(1)


4. ippmOwners Table

ippmOwnersOwner.1 =3D STRING: = "ippmAdmin"
ippmOwnersGrantedMetrics.1 =3D = STRING: "0111111111111111111111111111111111"
ippmOwnersQuota.1 =3D Gauge32: = 4294967295
ippmOwnersIpAddressType.1 =3D = INTEGER: ipv6(2)
ippmOwnersIpAddress.1 =3D STRING: = "fe80::209:5bff:fe08:d420"
ippmOwnersEmail.1 =3D STRING: = ippmAdmin@qosmetrix.com
ippmOwnersSMS.1 =3D STRING: = 1-805-445-8504
ippmOwnersStatus.1 =3D INTEGER: = active(1)

ippmOwnersOwner.2 =3D STRING: = "root"
ippmOwnersGrantedMetrics.2 =3D = STRING: "0000001011110000000000000001011000"
ippmOwnersQuota.2 =3D Gauge32: = 2147483647
ippmOwnersIpAddressType.2 =3D = INTEGER: ipv4(1)
ippmOwnersIpAddress.2 =3D STRING: = "192.168.1.175"
ippmOwnersEmail.2 =3D STRING: = owner@qosmetrix.com
ippmOwnersSMS.2 =3D STRING: = 1-805-445-8504
ippmOwnersStatus.2 =3D INTEGER: = active(1)

5. ippmSynchronization Table

Following are the description of the = synchronization of the 2 probes:

ippmSynchronizationTime.1.1     = ;  =3D Hex-STRING: 00 00 00 00 00 00 00 00  
ippmSynchronizationStratum.1.1    =3D = Gauge32: 1 
ippmSynchronizationResolution.1.1 = =3D Gauge32: 40 Nanoseconds 

ippmSynchronizationTime.2.1     = ;  =3D Hex-STRING: 00 00 00 00 00 00 00 00  
ippmSynchronizationStratum.2.1    =3D = Gauge32: 1 
ippmSynchronizationResolution.2.1 = =3D Gauge32: 40 Nanoseconds 

6. ippmPointOfMeasure  Table =

ippmPointOfMeasureMgmtAddrType.1  =3D INTEGER: = ipv4(1)  
ippmPointOfMeasureMgmtAddress.1   =3D STRING: = "66.14.75.68"  
ippmPointOfMeasureTestAddrTypeP.1 = =3D STRING: "ip"  
ippmPointOfMeasureTestAddr.1    &nbs= p; =3D STRING: 66.14.75.68  
ippmPointOfMeasureMetrics.1     = ;  =3D STRING: = "0000001011110000000000000001011000"  

ippmPointOfMeasureMgmtAddrType.2  =3D INTEGER: = ipv4(1)  
ippmPointOfMeasureMgmtAddress.2   =3D STRING: = "62.161.75.221"  
ippmPointOfMeasureTestAddrTypeP.2 = =3D STRING: "ip"  
ippmPointOfMeasureTestAddr.2    &nbs= p; =3D STRING: 62.161.75.221  
ippmPointOfMeasureMetrics.2     = ;  =3D STRING: = "0000001011110000000000000001011000"  
 
7. Metrics Table

# Note: Only the entries of interest = are displayed.

...
ippmMetricCapabilities.6  =3D = INTEGER: implemented(1)   
ippmMetricType.6      &nbs= p;   =3D INTEGER: network(0)   
ippmMetricUnit.6      &nbs= p;   =3D INTEGER: nanosecond(8)   
ippmMetricDescription.6   = =3D STRING: Type-P-One-way-Delay   
...
ippmMetricCapabilities.9  =3D = INTEGER: implemented(1)   
ippmMetricType.9      &nbs= p;   =3D INTEGER: aggregated(1)   
ippmMetricUnit.9      &nbs= p;   =3D INTEGER: nanosecond(8)   
ippmMetricDescription.9   = =3D STRING: Type-P-One-way-Delay-Median   
...
ippmMetricCapabilities.10 =3D = INTEGER: implemented(1)   
ippmMetricType.10      &nb= sp;  =3D INTEGER: aggregated(1)   
ippmMetricUnit.10      &nb= sp;  =3D INTEGER: nanosecond(8)   
ippmMetricDescription.10  =3D = STRING: Type-P-One-way-Delay-Minimum   
...
ippmMetricCapabilities.27 =3D = INTEGER: implemented(1)   
ippmMetricType.27      &nb= sp;  =3D INTEGER: network(0)   
ippmMetricUnit.27      &nb= sp;  =3D INTEGER: nanosecond(9)   
ippmMetricDescription.27  =3D = STRING: Type-P-One-way-ipdv   
...

8. Network Measure Table

Once the scenario is started, = Netadvisor creates the new network measures in the IPPM Proxy.

# network measure root.1 = Type-P-One-way-Delay(6) and Type-P-One-way-ipdv(27)
# Note: aggregation derivated from = Type-P-One-way-ipdv(27) are not displayed in the document
#
ippmNetMeasureName."root".1   &= nbsp;          =3D STRING: = -New Test Config
ippmNetMeasureMetrics."root".1  &nbs= p;        =3D STRING: = "0000001000000000000000000001000000"
#         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;           = ^            =         ^
#         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;           = 6            =         27
# metric ID = ----------------------------------------------+--------------------+-----= -
#
ippmNetMeasureBeginTime."root".1  &n= bsp;      =3D Hex-STRING: 07 58 08 9C 00 00 00 = 00
ippmNetMeasureCollectionRateUnit."root".1=3D = INTEGER: minute(4)
ippmNetMeasureCollectionRate."root".1 &nb= sp;  =3D Gauge32: 1
ippmNetMeasureDurationUnit."root".1  = ;    =3D INTEGER: second(3)
ippmNetMeasureDuration."root".1  &nb= sp;       =3D Gauge32: 1800
ippmNetMeasureHistorySize."root".1  =      =3D Gauge32: 0
ippmNetMeasureFailureMgmtMode."root".1 &n= bsp; =3D INTEGER: auto(1)
ippmNetMeasureResultsMgmt."root".1  =      =3D INTEGER: suspend(2)
ippmNetMeasureSrcTypeP."root".1  &nb= sp;       =3D STRING: = "ip.tcp"
ippmNetMeasureSrc."root".1   &n= bsp;           =3D = STRING: "66.14.75.68 12634"
ippmNetMeasureDstTypeP."root".1  &nb= sp;       =3D STRING: = "ip.tcp"
ippmNetMeasureDst."root".1   &n= bsp;           =3D = STRING: "62.161.75.221 9000"
ippmNetMeasureTxMode."root".1   = ;         =3D INTEGER: = periodic(1)
ippmNetMeasureTxPacketRateUnit."root".1  = =3D INTEGER: second(5)
ippmNetMeasureTxPacketRate."root".1  = ;    =3D Gauge32: 10 Packets
ippmNetMeasureMedOrBurstSize."root".1 &nb= sp;  =3D Gauge32: 0 Packets
ippmNetMeasureDevOrIntBurstSize."root".1 =3D = Gauge32: 0 Packets
ippmNetMeasureLossTimeout."root".1  =      =3D Gauge32: 800 Milliseconds
ippmNetMeasureL3PacketSize."root".1  = ;    =3D Gauge32: 156 Bytes
ippmNetMeasureDataPattern."root".1  =      =3D STRING: "7"
ippmNetMeasureMap."root".1   &n= bsp;           =3D = STRING: "Net Measure for One Way Delay"
ippmNetMeasureTotalPktsRecv."root".1 &nbs= p;   =3D Counter64: 12674 Packets
ippmNetMeasureLastUpdate."root".1  &= nbsp;     =3D Hex-STRING: 07 58 0D 88 00 00 00 00 =
ippmNetMeasureOperState."root".1  &n= bsp;      =3D INTEGER: stopped(2)

The duration of the measure is 1260 = seconds (07580D88 - 0758089C). The rate is 10 pkts/s. So the total = packets received is closed to 12600

9. Aggregated Measure Table

Once the scenario is started, = Netadvisor creates the new aggregated measures in the IPPM Proxy.

# measure root.2  = Type-P-One-way-Delay-Median(9) of the measure "root".1
#
ippmAggrMeasureName."root".2   =        =3D STRING: New Test Config
ippmAggrMeasureMetrics."root".2  &nb= sp;    =3D STRING: = "0000000001000000000000000000000000"
ippmAggrMeasureBeginTime."root".2  &= nbsp;  =3D Hex-STRING: 07 58 08 9C 00 00 00 00
ippmAggrMeasureAggrPeriodUnit."root".2=3D = INTEGER: second(6)
ippmAggrMeasureAggrPeriod."root".2  =   =3D INTEGER: 10
ippmAggrMeasureDurationUnit."root".2  = =3D INTEGER: second(6)
ippmAggrMeasureDuration."root".2  &n= bsp;   =3D INTEGER: 1800
ippmAggrMeasureHistorySize."root".2  = ; =3D INTEGER: 190
ippmAggrMeasureStorageType."root".2  = ; =3D INTEGER: nonVolatile(3)
ippmAggrMeasureResultsMgmt."root".2  = ; =3D INTEGER: suspend(2)
ippmAggrMeasureHistoryOwner."root".2  = =3D STRING: "root"
ippmAggrMeasureHistoryMetric."root".2 =3D = INTEGER: 6
ippmAggrMeasureHistoryOwnerIndex."root".2 =3D = INTEGER: 1
ippmAggrMeasureAdminState."root".2  =   =3D INTEGER: start(0)
ippmAggrMeasureFastReport."root".2  =   =3D OID: SNMPv2-SMI::zeroDotZero
ippmAggrMeasureMap."root".2   &= nbsp;       =3D STRING: Net Measure for = One Way Delay
ippmAggrMeasureLastUpdate."root".2  =   =3D Hex-STRING: 07 58 0D 88 00 00 00 00
ippmAggrMeasureOperState."root".2  &= nbsp;  =3D INTEGER: running(1)
ippmAggrMeasureNbPktsTreated."root".2 =3D = INTEGER: 126
ippmAggrMeasureStatus."root".2  &nbs= p;     =3D INTEGER: active(1)

# measure root.3  = Type-P-One-way-Delay-Minimum(10) of the measure = "root".1
#
ippmAggrMeasureName."root".3   =        =3D STRING: New Test Config
ippmAggrMeasureMetrics."root".3  &nb= sp;    =3D STRING: = "0000000000100000000000000000000000"
ippmAggrMeasureBeginTime."root".3  &= nbsp;  =3D Hex-STRING: 07 58 08 9C 00 00 00 00
ippmAggrMeasureAggrPeriodUnit."root".3=3D = INTEGER: second(6)
ippmAggrMeasureAggrPeriod."root".3  =   =3D INTEGER: 10
ippmAggrMeasureDurationUnit."root".3  = =3D INTEGER: second(6)
ippmAggrMeasureDuration."root".3  &n= bsp;   =3D INTEGER: 1800
ippmAggrMeasureHistorySize."root".3  = ; =3D INTEGER: 190
ippmAggrMeasureStorageType."root".3  = ; =3D INTEGER: nonVolatile(3)
ippmAggrMeasureResultsMgmt."root".3  = ; =3D INTEGER: suspend(2)
ippmAggrMeasureHistoryOwner."root".3  = =3D STRING: "root"
ippmAggrMeasureHistoryOwnerIndex."root".3 =3D = INTEGER: 1
ippmAggrMeasureHistoryMetric."root".3 =3D = INTEGER: 6
ippmAggrMeasureAdminState."root".3  =   =3D INTEGER: start(0)
ippmAggrMeasureFastReport."root".3  =   =3D OID: SNMPv2-SMI::zeroDotZero
ippmAggrMeasureMap."root".3   &= nbsp;       =3D STRING: Net Measure for = One Way Delay
ippmAggrMeasureLastUpdate."root".3  =   =3D Hex-STRING: 07 58 0D 88 00 00 00 00
ippmAggrMeasureOperState."root".3  &= nbsp;  =3D INTEGER: running(1)
ippmAggrMeasureNbPktsTreated."root".3 =3D = INTEGER: 126
ippmAggrMeasureStatus."root".3  &nbs= p;     =3D INTEGER: active(1)


10. History Table

# Results for the aggregated measure = named 'root.2': owd median
#
# The average delay from California = to France is close  to 101 ms
#

ippmHistoryTimestamp."root".2.9.1  &= nbsp;  =3D Hex-STRING: 07 58 08 A6 00 00 00 00
ippmHistoryValue."root".1.9.1   = ;      =3D INTEGER: 101167304
ippmHistoryTimestamp."root".2.9.2  &= nbsp;  =3D Hex-STRING: 07 58 08 B0 00 00 00 00
ippmHistoryValue."root".2.9.2   = ;      =3D INTEGER: 101306811
ippmHistoryTimestamp."root".2.9.3  &= nbsp;  =3D Hex-STRING: 07 58 08 BA 00 00 00 00
ippmHistoryValue."root".2.9.3   = ;      =3D INTEGER: 101211175
ippmHistoryTimestamp."root".2.9.4  &= nbsp;  =3D Hex-STRING: 07 58 08 C4 00 00 00 00
ippmHistoryValue."root".2.9.4   = ;      =3D INTEGER: 101080395
ippmHistoryTimestamp."root".2.9.5  &= nbsp;  =3D Hex-STRING: 07 58 08 CE 00 00 00 00
ippmHistoryValue."root".2.9.5   = ;      =3D INTEGER: 100703053
ippmHistoryTimestamp."root".2.9.6  &= nbsp;  =3D Hex-STRING: 07 58 08 D8 00 00 00 00
ippmHistoryValue."root".2.9.6   = ;      =3D INTEGER: 100790354
ippmHistoryTimestamp."root".2.9.7  &= nbsp;  =3D Hex-STRING: 07 58 08 E2 00 00 00 00
ippmHistoryValue."root".2.9.7   = ;      =3D INTEGER: 100831317
ippmHistoryTimestamp."root".2.9.8  &= nbsp;  =3D Hex-STRING: 07 58 08 EC 00 00 00 00
ippmHistoryValue."root".2.9.8   = ;      =3D INTEGER: 101174398
ippmHistoryTimestamp."root".2.9.9  &= nbsp;  =3D Hex-STRING: 07 58 08 F6 00 00 00 00
ippmHistoryValue."root".2.9.9   = ;      =3D INTEGER: 100669560
...

# Results for the aggregated measure = named 'root.3': owd minimum
#
# The minimum delay from California = to France is 98 ms
#
ippmHistoryTimestamp."root".3.10.1  =   =3D Hex-STRING: 07 58 08 A6 00 00 00 00
ippmHistoryValue."root".3.10.1  &nbs= p;     =3D INTEGER: 98592163
ippmHistoryTimestamp."root".3.10.2  =   =3D Hex-STRING: 07 58 08 B0 00 00 00 00
ippmHistoryValue."root".3.10.2  &nbs= p;     =3D INTEGER: 98607014
ippmHistoryTimestamp."root".3.10.3  =   =3D Hex-STRING: 07 58 08 BA 00 00 00 00
ippmHistoryValue."root".3.10.3  &nbs= p;     =3D INTEGER: 98937947
ippmHistoryTimestamp."root".3.10.4  =   =3D Hex-STRING: 07 58 08 C4 00 00 00 00
ippmHistoryValue."root".3.10.4  &nbs= p;     =3D INTEGER: 98689982
ippmHistoryTimestamp."root".3.10.5  =   =3D Hex-STRING: 07 58 08 CE 00 00 00 00
ippmHistoryValue."root".3.10.5  &nbs= p;     =3D INTEGER: 98512898
ippmHistoryTimestamp."root".3.10.6  =   =3D Hex-STRING: 07 58 08 D8 00 00 00 00
ippmHistoryValue."root".3.10.6  &nbs= p;     =3D INTEGER: 98537068
ippmHistoryTimestamp."root".3.10.7  =   =3D Hex-STRING: 07 58 08 E2 00 00 00 00
ippmHistoryValue."root".3.10.7  &nbs= p;     =3D INTEGER: 98901570
ippmHistoryTimestamp."root".3.10.8  =   =3D Hex-STRING: 07 58 08 EC 00 00 00 00
ippmHistoryValue."root".3.10.8  &nbs= p;     =3D INTEGER: 99173706
ippmHistoryTimestamp."root".3.10.9  =   =3D Hex-STRING: 07 58 08 F6 00 00 00 00
ippmHistoryValue."root".3.10.9  &nbs= p;     =3D INTEGER: 98840372
...


------_=_NextPart_001_01C3BD97.AFFEA5BE-- _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Thu Dec 11 17:27:41 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29109 for ; Thu, 11 Dec 2003 17:27:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUZGv-0004YS-7r; Thu, 11 Dec 2003 17:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUZGm-0004Xt-E6 for ippm@optimus.ietf.org; Thu, 11 Dec 2003 17:26:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29052 for ; Thu, 11 Dec 2003 17:26:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUZGi-0003Vv-00 for ippm@ietf.org; Thu, 11 Dec 2003 17:26:48 -0500 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 1AUZGi-0003Vp-00 for ippm@ietf.org; Thu, 11 Dec 2003 17:26:48 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 985502152; Thu, 11 Dec 2003 17:06:05 -0500 (EST) Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 94928214E; Thu, 11 Dec 2003 17:06:04 -0500 (EST) To: =?iso-8859-5?b?UmVu6SBTZXJyYWw=?= Cc: owamp-users@internet2.edu, ippm@ietf.org References: <200312110909.20344.rserral@ac.upc.es> From: stanislav shalunov Date: 11 Dec 2003 17:05:58 -0500 In-Reply-To: <200312110909.20344.rserral@ac.upc.es> Message-ID: <86ekvbm2m1.fsf@abel.internet2.edu> Lines: 31 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Virus-Scanned: by mail.internet2.edu virus scanner Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id RAA29053 Subject: [ippm] Re: Fetch client doubt Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Ren=E9 Serral writes: > Hi, I'm a PhD student at UPC (Spain), we are starting an > implementation of OWAMP. Great! Keep us posted on your progress and let's test interoperability when you have running code. > I don't know if this is the correct list for sending my question, anywa= y: I am copying ippm@ietf.org in my reply. Since this is a specification issue rather than something that's specific to our particular implementation of OWAMP, the IPPM list is probably the right place to discuss it -- or it should at least be copied. > I have a doubt about the point 5.3 (creation of test sessions) in > the draft. My problem is that I don't know if the Schedule slots > have to be sent with the same message than the Request-Session > message. Or it can be sent in different messages. Maybe it doesn't > matters? The Request-Session command described in section 5.3 completely describes the session that's being requested, providing the server with all the information it needs to decide whether to grant the request. I'm not sure what would be the purpose of splitting the request into separate messages? The downsides would include: (i) an extra RTT before anything useful happens and (ii) slightly more complexity. What would be the upsides? --=20 Stanislav Shalunov http://www.internet2.edu/~shalunov/ _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Thu Dec 11 17:27:43 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29124 for ; Thu, 11 Dec 2003 17:27:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUZHA-0004aY-Fm for ippm-archive@odin.ietf.org; Thu, 11 Dec 2003 17:27:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBMRGod017637 for ippm-archive@odin.ietf.org; Thu, 11 Dec 2003 17:27:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUZHA-0004aO-Bi for ippm-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 17:27:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29074 for ; Thu, 11 Dec 2003 17:27:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUZH8-0003WR-00 for ippm-web-archive@ietf.org; Thu, 11 Dec 2003 17:27:14 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUZH7-0003WM-00 for ippm-web-archive@ietf.org; Thu, 11 Dec 2003 17:27:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUZGv-0004YS-7r; Thu, 11 Dec 2003 17:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUZGm-0004Xt-E6 for ippm@optimus.ietf.org; Thu, 11 Dec 2003 17:26:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29052 for ; Thu, 11 Dec 2003 17:26:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUZGi-0003Vv-00 for ippm@ietf.org; Thu, 11 Dec 2003 17:26:48 -0500 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 1AUZGi-0003Vp-00 for ippm@ietf.org; Thu, 11 Dec 2003 17:26:48 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 985502152; Thu, 11 Dec 2003 17:06:05 -0500 (EST) Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 94928214E; Thu, 11 Dec 2003 17:06:04 -0500 (EST) To: =?iso-8859-5?b?UmVu6SBTZXJyYWw=?= Cc: owamp-users@internet2.edu, ippm@ietf.org References: <200312110909.20344.rserral@ac.upc.es> From: stanislav shalunov Date: 11 Dec 2003 17:05:58 -0500 In-Reply-To: <200312110909.20344.rserral@ac.upc.es> Message-ID: <86ekvbm2m1.fsf@abel.internet2.edu> Lines: 31 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Virus-Scanned: by mail.internet2.edu virus scanner Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id RAA29053 Subject: [ippm] Re: Fetch client doubt Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Ren=E9 Serral writes: > Hi, I'm a PhD student at UPC (Spain), we are starting an > implementation of OWAMP. Great! Keep us posted on your progress and let's test interoperability when you have running code. > I don't know if this is the correct list for sending my question, anywa= y: I am copying ippm@ietf.org in my reply. Since this is a specification issue rather than something that's specific to our particular implementation of OWAMP, the IPPM list is probably the right place to discuss it -- or it should at least be copied. > I have a doubt about the point 5.3 (creation of test sessions) in > the draft. My problem is that I don't know if the Schedule slots > have to be sent with the same message than the Request-Session > message. Or it can be sent in different messages. Maybe it doesn't > matters? The Request-Session command described in section 5.3 completely describes the session that's being requested, providing the server with all the information it needs to decide whether to grant the request. I'm not sure what would be the purpose of splitting the request into separate messages? The downsides would include: (i) an extra RTT before anything useful happens and (ii) slightly more complexity. What would be the upsides? --=20 Stanislav Shalunov http://www.internet2.edu/~shalunov/ _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Fri Dec 12 09:58:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09802 for ; Fri, 12 Dec 2003 09:58:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUojx-0005ZK-EI; Fri, 12 Dec 2003 09:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUojp-0005Z6-Th for ippm@optimus.ietf.org; Fri, 12 Dec 2003 09:57:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09783 for ; Fri, 12 Dec 2003 09:57:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUojn-0006M4-00 for ippm@ietf.org; Fri, 12 Dec 2003 09:57:51 -0500 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 1AUojn-0006M1-00 for ippm@ietf.org; Fri, 12 Dec 2003 09:57:51 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 9B26B13DC; Fri, 12 Dec 2003 09:57:50 -0500 (EST) Received: from internet2.edu (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 250E4177A; Fri, 12 Dec 2003 09:57:49 -0500 (EST) Message-ID: <3FD9D76C.8B9FCA8@internet2.edu> Date: Fri, 12 Dec 2003 07:57:48 -0700 From: "Jeff W. Boote" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: =?iso-8859-1?Q?Ren=E9?= Serral Cc: stanislav shalunov , owamp-users@internet2.edu, ippm@ietf.org References: <200312110909.20344.rserral@ac.upc.es> <86ekvbm2m1.fsf@abel.internet2.edu> <200312121010.37042.rserral@ac.upc.es> Content-Type: text/plain; charset=iso-8859-1 X-Virus-Scanned: by mail.internet2.edu virus scanner Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA09784 Subject: [ippm] Re: Fetch client doubt Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Ren=E9 Serral wrote: > The point was that when the number of slots is very big you'll need var= ious > phisical packets. Its only a matter of implementation only, we are tryi= ng to > program the code as much compatible as we can. Since this is a tcp connection, the number of physical packets should be hidden from most implementations by the tcp layer. So, I don't think it should matter to an OWAMP implementation. jeff _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Fri Dec 12 09:58:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09816 for ; Fri, 12 Dec 2003 09:58:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUok5-0005bh-CD for ippm-archive@odin.ietf.org; Fri, 12 Dec 2003 09:58:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCEw9n4021547 for ippm-archive@odin.ietf.org; Fri, 12 Dec 2003 09:58:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUok5-0005bS-4l for ippm-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 09:58:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09793 for ; Fri, 12 Dec 2003 09:58:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUok2-0006Mf-00 for ippm-web-archive@ietf.org; Fri, 12 Dec 2003 09:58:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUok2-0006Mb-00 for ippm-web-archive@ietf.org; Fri, 12 Dec 2003 09:58:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUojx-0005ZK-EI; Fri, 12 Dec 2003 09:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUojp-0005Z6-Th for ippm@optimus.ietf.org; Fri, 12 Dec 2003 09:57:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09783 for ; Fri, 12 Dec 2003 09:57:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUojn-0006M4-00 for ippm@ietf.org; Fri, 12 Dec 2003 09:57:51 -0500 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 1AUojn-0006M1-00 for ippm@ietf.org; Fri, 12 Dec 2003 09:57:51 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 9B26B13DC; Fri, 12 Dec 2003 09:57:50 -0500 (EST) Received: from internet2.edu (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 250E4177A; Fri, 12 Dec 2003 09:57:49 -0500 (EST) Message-ID: <3FD9D76C.8B9FCA8@internet2.edu> Date: Fri, 12 Dec 2003 07:57:48 -0700 From: "Jeff W. Boote" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: =?iso-8859-1?Q?Ren=E9?= Serral Cc: stanislav shalunov , owamp-users@internet2.edu, ippm@ietf.org References: <200312110909.20344.rserral@ac.upc.es> <86ekvbm2m1.fsf@abel.internet2.edu> <200312121010.37042.rserral@ac.upc.es> Content-Type: text/plain; charset=iso-8859-1 X-Virus-Scanned: by mail.internet2.edu virus scanner Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA09784 Subject: [ippm] Re: Fetch client doubt Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Ren=E9 Serral wrote: > The point was that when the number of slots is very big you'll need var= ious > phisical packets. Its only a matter of implementation only, we are tryi= ng to > program the code as much compatible as we can. Since this is a tcp connection, the number of physical packets should be hidden from most implementations by the tcp layer. So, I don't think it should matter to an OWAMP implementation. jeff _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Fri Dec 12 10:02:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09912 for ; Fri, 12 Dec 2003 10:02:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUonp-0005k1-8X; Fri, 12 Dec 2003 10:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUjLA-0000tL-7T for ippm@optimus.ietf.org; Fri, 12 Dec 2003 04:12:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01979 for ; Fri, 12 Dec 2003 04:12:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUjL7-0000Ma-00 for ippm@ietf.org; Fri, 12 Dec 2003 04:12:01 -0500 Received: from roura.ac.upc.es ([147.83.33.10]) by ietf-mx with esmtp (Exim 4.12) id 1AUjL6-0000M3-00 for ippm@ietf.org; Fri, 12 Dec 2003 04:12:00 -0500 Received: from pcrafols.ac.upc.es (rserral@pcrafols.ac.upc.es [147.83.35.119]) by roura.ac.upc.es (8.12.8/8.12.8) with ESMTP id hBC9BRJA010753; Fri, 12 Dec 2003 10:11:28 +0100 (MET) From: =?iso-8859-1?q?Ren=E9=20Serral?= Organization: CCABA To: stanislav shalunov Date: Fri, 12 Dec 2003 10:10:37 +0100 User-Agent: KMail/1.5.4 Cc: owamp-users@internet2.edu, ippm@ietf.org References: <200312110909.20344.rserral@ac.upc.es> <86ekvbm2m1.fsf@abel.internet2.edu> In-Reply-To: <86ekvbm2m1.fsf@abel.internet2.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200312121010.37042.rserral@ac.upc.es> Content-Transfer-Encoding: quoted-printable Subject: [ippm] Re: Fetch client doubt Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Comments below On Thursday 11 December 2003 23:05, stanislav shalunov wrote: > Ren=E9 Serral writes: > > Hi, I'm a PhD student at UPC (Spain), we are starting an > > implementation of OWAMP. > > Great! Keep us posted on your progress and let's test > interoperability when you have running code. > > > I don't know if this is the correct list for sending my question, anywa= y: > > I am copying ippm@ietf.org in my reply. Since this is a specification > issue rather than something that's specific to our particular > implementation of OWAMP, the IPPM list is probably the right place to > discuss it -- or it should at least be copied. > Oh! good I didn't know where to send my request. > > I have a doubt about the point 5.3 (creation of test sessions) in > > the draft. My problem is that I don't know if the Schedule slots > > have to be sent with the same message than the Request-Session > > message. Or it can be sent in different messages. Maybe it doesn't > > matters? > > The Request-Session command described in section 5.3 completely > describes the session that's being requested, providing the server > with all the information it needs to decide whether to grant the > request. I'm not sure what would be the purpose of splitting the > request into separate messages? The downsides would include: (i) an > extra RTT before anything useful happens and (ii) slightly more > complexity. What would be the upsides? The point was that when the number of slots is very big you'll need various= =20 phisical packets. Its only a matter of implementation only, we are trying t= o=20 program the code as much compatible as we can. Thanks for the answer. Best regards, =2D-=20 =2D-------------------------------------------------------------- Ren=E9 Serral Universitat Polit=E8cnica de Catalunya rserral@ac.upc.es UPC Campus Nord, Ed. D4 Tel: +34 934 017 432 Barcelona 08034 --------------------------------------------------------------- =20 _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Fri Dec 12 10:02:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09930 for ; Fri, 12 Dec 2003 10:02:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUonr-0005mG-D5 for ippm-archive@odin.ietf.org; Fri, 12 Dec 2003 10:02:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCF23m4022202 for ippm-archive@odin.ietf.org; Fri, 12 Dec 2003 10:02:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUonr-0005m1-83 for ippm-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 10:02:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09905 for ; Fri, 12 Dec 2003 10:01:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUonp-0006OT-00 for ippm-web-archive@ietf.org; Fri, 12 Dec 2003 10:02:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUono-0006OQ-00 for ippm-web-archive@ietf.org; Fri, 12 Dec 2003 10:02:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUonp-0005k1-8X; Fri, 12 Dec 2003 10:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUjLA-0000tL-7T for ippm@optimus.ietf.org; Fri, 12 Dec 2003 04:12:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01979 for ; Fri, 12 Dec 2003 04:12:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUjL7-0000Ma-00 for ippm@ietf.org; Fri, 12 Dec 2003 04:12:01 -0500 Received: from roura.ac.upc.es ([147.83.33.10]) by ietf-mx with esmtp (Exim 4.12) id 1AUjL6-0000M3-00 for ippm@ietf.org; Fri, 12 Dec 2003 04:12:00 -0500 Received: from pcrafols.ac.upc.es (rserral@pcrafols.ac.upc.es [147.83.35.119]) by roura.ac.upc.es (8.12.8/8.12.8) with ESMTP id hBC9BRJA010753; Fri, 12 Dec 2003 10:11:28 +0100 (MET) From: =?iso-8859-1?q?Ren=E9=20Serral?= Organization: CCABA To: stanislav shalunov Date: Fri, 12 Dec 2003 10:10:37 +0100 User-Agent: KMail/1.5.4 Cc: owamp-users@internet2.edu, ippm@ietf.org References: <200312110909.20344.rserral@ac.upc.es> <86ekvbm2m1.fsf@abel.internet2.edu> In-Reply-To: <86ekvbm2m1.fsf@abel.internet2.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200312121010.37042.rserral@ac.upc.es> Content-Transfer-Encoding: quoted-printable Subject: [ippm] Re: Fetch client doubt Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Comments below On Thursday 11 December 2003 23:05, stanislav shalunov wrote: > Ren=E9 Serral writes: > > Hi, I'm a PhD student at UPC (Spain), we are starting an > > implementation of OWAMP. > > Great! Keep us posted on your progress and let's test > interoperability when you have running code. > > > I don't know if this is the correct list for sending my question, anywa= y: > > I am copying ippm@ietf.org in my reply. Since this is a specification > issue rather than something that's specific to our particular > implementation of OWAMP, the IPPM list is probably the right place to > discuss it -- or it should at least be copied. > Oh! good I didn't know where to send my request. > > I have a doubt about the point 5.3 (creation of test sessions) in > > the draft. My problem is that I don't know if the Schedule slots > > have to be sent with the same message than the Request-Session > > message. Or it can be sent in different messages. Maybe it doesn't > > matters? > > The Request-Session command described in section 5.3 completely > describes the session that's being requested, providing the server > with all the information it needs to decide whether to grant the > request. I'm not sure what would be the purpose of splitting the > request into separate messages? The downsides would include: (i) an > extra RTT before anything useful happens and (ii) slightly more > complexity. What would be the upsides? The point was that when the number of slots is very big you'll need various= =20 phisical packets. Its only a matter of implementation only, we are trying t= o=20 program the code as much compatible as we can. Thanks for the answer. Best regards, =2D-=20 =2D-------------------------------------------------------------- Ren=E9 Serral Universitat Polit=E8cnica de Catalunya rserral@ac.upc.es UPC Campus Nord, Ed. D4 Tel: +34 934 017 432 Barcelona 08034 --------------------------------------------------------------- =20 _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Tue Dec 16 14:50:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29278 for ; Tue, 16 Dec 2003 14:50:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWLCk-0001s6-D3; Tue, 16 Dec 2003 14:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWLC7-0001rR-75 for ippm@optimus.ietf.org; Tue, 16 Dec 2003 14:49:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29257 for ; Tue, 16 Dec 2003 14:49:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWLC4-00000l-00 for ippm@ietf.org; Tue, 16 Dec 2003 14:49:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWLC3-00000e-00 for ippm@ietf.org; Tue, 16 Dec 2003 14:49:19 -0500 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 1AWLC3-00000b-00 for ippm@ietf.org; Tue, 16 Dec 2003 14:49:19 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 5C74EAC0; Tue, 16 Dec 2003 14:49:19 -0500 (EST) Received: from internet2.edu (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id E5307B01; Tue, 16 Dec 2003 14:49:17 -0500 (EST) Message-ID: <3FDF61BD.820EED67@internet2.edu> Date: Tue, 16 Dec 2003 12:49:17 -0700 From: "Jeff W. Boote" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: l.pena@uol.com.br Cc: owamp-users@internet2.edu, ippm@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [ippm] Re: Owamp precision Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit l.pena@uol.com.br wrote: > > I'm working in a research project that use owamp infrasctruct and I have some doubts about this protocol. I am CC'ing the ippm@ietf.org list due to the "protocol" question. > First I'd like to know how owamp calculate this precision, it gets from ntp estimated error? > > I was reading the owamp draft and saw in section 6.1 that estimated error is result from two variables scale and multiplier. Why this function (estimated error = multiplier * 2^(-32) * 2^scale) this is used?!?! What are the meaning of these two values?! Our owamp "implementation" does get this value from the ntp estimated error. Other implementations might compute this number in other ways. (In fact, I could change the way this number is computed in the future for this implementation. It is not entirely clear to me that the estimated error reported by the FreeBSD ntp kernel call is computed properly based on the NTP error budget. This is something I want to look closer at in the future.) The reason these values are represented with two "variables" (mult, scale) is to allow the error value to be represented with as much precision as possible at many different levels of scale. (It is simply a floating point number.) jeff _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Tue Dec 16 14:50:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29299 for ; Tue, 16 Dec 2003 14:50:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWLCt-0001uM-MD for ippm-archive@odin.ietf.org; Tue, 16 Dec 2003 14:50:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGJoBJ1007328 for ippm-archive@odin.ietf.org; Tue, 16 Dec 2003 14:50:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWLCt-0001u7-IH for ippm-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 14:50:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29271 for ; Tue, 16 Dec 2003 14:50:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWLCq-00001s-00 for ippm-web-archive@ietf.org; Tue, 16 Dec 2003 14:50:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWLCp-00001k-00 for ippm-web-archive@ietf.org; Tue, 16 Dec 2003 14:50:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWLCp-00001h-00 for ippm-web-archive@ietf.org; Tue, 16 Dec 2003 14:50:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWLCk-0001s6-D3; Tue, 16 Dec 2003 14:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWLC7-0001rR-75 for ippm@optimus.ietf.org; Tue, 16 Dec 2003 14:49:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29257 for ; Tue, 16 Dec 2003 14:49:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWLC4-00000l-00 for ippm@ietf.org; Tue, 16 Dec 2003 14:49:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWLC3-00000e-00 for ippm@ietf.org; Tue, 16 Dec 2003 14:49:19 -0500 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 1AWLC3-00000b-00 for ippm@ietf.org; Tue, 16 Dec 2003 14:49:19 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 5C74EAC0; Tue, 16 Dec 2003 14:49:19 -0500 (EST) Received: from internet2.edu (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id E5307B01; Tue, 16 Dec 2003 14:49:17 -0500 (EST) Message-ID: <3FDF61BD.820EED67@internet2.edu> Date: Tue, 16 Dec 2003 12:49:17 -0700 From: "Jeff W. Boote" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: l.pena@uol.com.br Cc: owamp-users@internet2.edu, ippm@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by mail.internet2.edu virus scanner Content-Transfer-Encoding: 7bit Subject: [ippm] Re: Owamp precision Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit l.pena@uol.com.br wrote: > > I'm working in a research project that use owamp infrasctruct and I have some doubts about this protocol. I am CC'ing the ippm@ietf.org list due to the "protocol" question. > First I'd like to know how owamp calculate this precision, it gets from ntp estimated error? > > I was reading the owamp draft and saw in section 6.1 that estimated error is result from two variables scale and multiplier. Why this function (estimated error = multiplier * 2^(-32) * 2^scale) this is used?!?! What are the meaning of these two values?! Our owamp "implementation" does get this value from the ntp estimated error. Other implementations might compute this number in other ways. (In fact, I could change the way this number is computed in the future for this implementation. It is not entirely clear to me that the estimated error reported by the FreeBSD ntp kernel call is computed properly based on the NTP error budget. This is something I want to look closer at in the future.) The reason these values are represented with two "variables" (mult, scale) is to allow the error value to be represented with as much precision as possible at many different levels of scale. (It is simply a floating point number.) jeff _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Tue Dec 16 15:27:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01964 for ; Tue, 16 Dec 2003 15:27:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWLmX-0003ZC-L1; Tue, 16 Dec 2003 15:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWLlh-0003Ya-Rt for ippm@optimus.ietf.org; Tue, 16 Dec 2003 15:26:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01909 for ; Tue, 16 Dec 2003 15:26:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWLlb-000131-00 for ippm@ietf.org; Tue, 16 Dec 2003 15:26:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWLlB-00012s-00 for ippm@ietf.org; Tue, 16 Dec 2003 15:25:38 -0500 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 1AWLlB-00012m-00 for ippm@ietf.org; Tue, 16 Dec 2003 15:25:37 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id D6E6CA53; Tue, 16 Dec 2003 15:25:27 -0500 (EST) Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id D06C8A51; Tue, 16 Dec 2003 15:25:26 -0500 (EST) To: owamp-users@internet2.edu, ippm@ietf.org Cc: l.pena@uol.com.br References: <3FDF61BD.820EED67@internet2.edu> From: stanislav shalunov Date: 16 Dec 2003 15:25:25 -0500 In-Reply-To: <3FDF61BD.820EED67@internet2.edu> Message-ID: <86u140eci2.fsf@abel.internet2.edu> Lines: 14 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [ippm] Re: Owamp precision Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , "Jeff W. Boote" writes: > The reason these values are represented with two "variables" (mult, > scale) is to allow the error value to be represented with as much > precision as possible at many different levels of scale. ...in as few bits as possible. We could have used another timestamp value to represent precision; it's a tradeoff between space (expensive space in OWAMP-Test, not cheap space in OWAMP-Control) and precision. Given that errors can't be known with the same precision as the actual timestamps, the resolution of error estimate (1.5%) spec seems sufficient. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Tue Dec 16 15:28:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02039 for ; Tue, 16 Dec 2003 15:28:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWLnR-0003gU-2C for ippm-archive@odin.ietf.org; Tue, 16 Dec 2003 15:27:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGKRv5W014162 for ippm-archive@odin.ietf.org; Tue, 16 Dec 2003 15:27:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWLnQ-0003gL-TJ for ippm-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 15:27:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02007 for ; Tue, 16 Dec 2003 15:27:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWLnK-00015R-00 for ippm-web-archive@ietf.org; Tue, 16 Dec 2003 15:27:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWLmu-00014m-00 for ippm-web-archive@ietf.org; Tue, 16 Dec 2003 15:27:25 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWLmu-00014P-00 for ippm-web-archive@ietf.org; Tue, 16 Dec 2003 15:27:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWLmX-0003ZC-L1; Tue, 16 Dec 2003 15:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWLlh-0003Ya-Rt for ippm@optimus.ietf.org; Tue, 16 Dec 2003 15:26:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01909 for ; Tue, 16 Dec 2003 15:26:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWLlb-000131-00 for ippm@ietf.org; Tue, 16 Dec 2003 15:26:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWLlB-00012s-00 for ippm@ietf.org; Tue, 16 Dec 2003 15:25:38 -0500 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 1AWLlB-00012m-00 for ippm@ietf.org; Tue, 16 Dec 2003 15:25:37 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id D6E6CA53; Tue, 16 Dec 2003 15:25:27 -0500 (EST) Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id D06C8A51; Tue, 16 Dec 2003 15:25:26 -0500 (EST) To: owamp-users@internet2.edu, ippm@ietf.org Cc: l.pena@uol.com.br References: <3FDF61BD.820EED67@internet2.edu> From: stanislav shalunov Date: 16 Dec 2003 15:25:25 -0500 In-Reply-To: <3FDF61BD.820EED67@internet2.edu> Message-ID: <86u140eci2.fsf@abel.internet2.edu> Lines: 14 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by mail.internet2.edu virus scanner Subject: [ippm] Re: Owamp precision Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 "Jeff W. Boote" writes: > The reason these values are represented with two "variables" (mult, > scale) is to allow the error value to be represented with as much > precision as possible at many different levels of scale. ...in as few bits as possible. We could have used another timestamp value to represent precision; it's a tradeoff between space (expensive space in OWAMP-Test, not cheap space in OWAMP-Control) and precision. Given that errors can't be known with the same precision as the actual timestamps, the resolution of error estimate (1.5%) spec seems sufficient. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Thu Dec 18 05:52:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15055 for ; Thu, 18 Dec 2003 05:52:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWvlA-00038m-Kg; Thu, 18 Dec 2003 05:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWvkt-00038O-78 for ippm@optimus.ietf.org; Thu, 18 Dec 2003 05:51:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15038 for ; Thu, 18 Dec 2003 05:51:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWvkp-0001ml-00 for ippm@ietf.org; Thu, 18 Dec 2003 05:51:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWvkn-0001me-00 for ippm@ietf.org; Thu, 18 Dec 2003 05:51:39 -0500 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1AWvkn-0001lV-00 for ippm@ietf.org; Thu, 18 Dec 2003 05:51:37 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id 0D4F14E085; Thu, 18 Dec 2003 11:51:08 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 6AE164E07C for ; Thu, 18 Dec 2003 11:51:07 +0100 (CET) Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id hBIAp7dH012073 for ; Thu, 18 Dec 2003 11:51:07 +0100 Received: from localhost (henk@localhost) by x49.ripe.net (8.12.10/8.12.6) with ESMTP id hBIAp7N8006280 for ; Thu, 18 Dec 2003 11:51:07 +0100 X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Thu, 18 Dec 2003 11:51:07 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: ippm@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: N 0.500000 X-RIPE-Signature: f6cc7ab5c9eba6fdb341d367063898e9 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [ippm] draft ietf58 ippm minutes Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Comments to Matt before Friday 19, 17:00h GMT please. Henk -=-=- IETF IP Performance Metrics WG (ippm) Thursday, November 13, 2003 at 13:00 to 15:00 ============================================= The meeting was moderated by the working group chairs, Matt Zekauskas and Henk Uijterwaal. Al Morton and Ruediger Geib took notes, which were edited into these minutes by the chairs. AGENDA 1. Agenda Bashing 2. Packet Reordering 3. Reordering Density 4. IPPM-MIB 5. OWAMP 6. Status, Milestones & Futures 1. Agenda Bashing -- The chairs There was no bashing, but Matt welcomed Henk Uijterwaal as the new co-chair, replacing Merike Kaeo who is now focusing on security work. 2. Packet Reordering -- Al Morton Al Morton presented the changes since the last meeting to the reordering draft (see slides). The major changes are (1) continued clarifications started in the last version, including changing the sense of the base metric so it reports "true" when a packet has been reordered, moving alternate methods of detecting reordering (time or bytes instead of sequence number) to a separate section, (2) adding the concept of steady-state versus transient reordering, and (3) adding text to cover packet fragmentation. The fragmentation text needs work, and will likely have the details moved to a separate section. The draft is still missing an appendix on applicability promised by Greg Wright. Matt asked which appendices, if any, were going to be normative (and we should so state). Jerry Perser asked if we could drop IPPM from the title, since in his view it was more general (that is, there was some applicability to BMWG as well). There was no objection from the assembled group. Matt (chair hat off) asked if adding fragmentation added too much complexity; none of the other metrics look at individual fragments. Jerry felt that either we should specify the metric so fragmentation does not occur, or we should check whether fragments are reordered. Al Morton noted that he has seen systems "in the wild" that don't handle reordered fragments well. Stanislav Shalunov noted that some versions of Linux actually send fragments in the reverse order because they get a slight performance improvement during reassembly; a note should be added. 3. Reordering Density -- Anura Jayasumana The next presentation was by Anura Jayasumana on reordering density (an individual submission). This is the second presentation we had on this topic, but the first by an author; there was a presentation at the last IETF meeting by Jerry McCollum from Agilent, who is familiar with the work. One can think of the reorder density function like a normalized histogram of buffer occupancy. The major problem that the group has with this work is that lost packets show up in the reorder density, so you cannot completely separate losses from reordering events using this technique. An example showing a lost packet was given. Stanislav Shalunov noted that it appears that loss is counted as reordering. Anura stated that it was correct. Stanislav asked if a sequence had no reordering but just loss would the result be non-zero? Anura said that was correct, that there is a problem with packet loss, the current definition was a compromise, and ensured the computation could be done in order n time and constant space. One interesting claim made by the author is that they have been able to characterize the nature of loss based on distributions of reorder density. It could also be a basis for TCP adjusting it's sensitivity to reordering on the fly, and the distribution could be used when modeling a network. (See also the "Properties" slides.) One major change from the previous proposal was the addition of "late" and "early" reordering density. Together with the original definition, Anura felt that this characterization might also be useful in solving concatenation of partial path reordering metrics to give a reordering metric for the full path. This led back to a discussion of packet loss. Jerry Perser asked if lost packets were early or late? Anura said that was recognized with the help of a place label. Al Morton again brought up that this was the biggest issue in this draft; the current working group draft makes reordering orthogonal with loss, and there is a clear definition of "early" and "late". The definitions of in and out of order and early and late need to merge to add this to the draft. Anura said that it depends on what you are trying to achieve with reordering measurements: perform TCP or network diagnosis? Predict network behavior? The use of density would add value; a simple number describing reordering doesn't provide enough information. The definition of loss would have to be agreed. Stanislav asserted that n-reordering makes the definition of loss orthogonal to reordering. n-reordering metric doesn't change in the presence of loss. Not every router sends a stream of numbers with monotonically increasing sequence numbers. Anura thought there was a problem with n-reordering and fast routers. Stanislav said that a linear buffer would be sufficient. Anura said that n squared would hit. Stanislav said not for n-reordering. Anura said that then duplicates are an issue. Al said that you either save information on packets which have arrived or those missing, usually the latter. Anura thought that a moving window is better than keeping information on packets. Jerry Perser noted that test instruments can't track millions of duplicate packets. Anura said that with reordering density you only need to keep track for a fixed window. Stanislav wanted to get back to loss. Anura said they recognize loss within window. Jerry wondered why it isn't called loss and reordering density. Anura said it isn't a loss density. Jerry said that he had a problem claiming reordered packets when only one is lost. For example, look at slide 6; Jerry said packet 4 is in sequence. Anura said that according to his definition packet 4 is reordered [3 was lost]. Anura wanted to know about packets arriving much later; suddenly "2" comes in and your whole view changes. Is this appropriate? Applications would presumably treat them as lost. Are they lost or reordered? Stanislav said the definition of reordering is only based on a sequence of arrivals. Jerry wanted to know if the authors checked the resources you require to implement reordering density (say for an oc192 link) -- what was the fastest speed tested? Anura said that results are forthcoming; they have software on Linux for testing, and the fastest speed tested so far was fast Ethernet. The authors would like this draft used as an alternative characterization metric in the current draft or published as a separate informational draft. Henk asked if we should merge drafts or proceed separately? Matt said that his sense was that the current authors seem to be disinclined to merge with loss mixed with reordering. Al Morton said that was true, and there were no other comments. 4. IPPM-MIB -- Emile Stephan Next, Emile Stephan presented the latest version of the MIB. He wanted to know the status of the registry -- it will be presented to the ADs as soon as the (apparently now expired) version is refreshed by the I-D editor after the meeting. RMON would like the OIDs for the metrics. Bob Cole asked what happens for new metrics? Matt said OIDs should be included in those drafts. As far as the MIB goes, Emile presented some recent (minor) changes, and then tried to walk the room through a sample setup showing how all the tables were organized and how views of the data are consumed (see slides). He tried to do a demo showing the MIB presenting results from a commercial measurement system, but the demo hiccupped in the middle. (He later showed it to the chairs.) He noted that Andy Bierman had sent a comment to the list today, and that he hasn't had time to consider it in detail, but he will respond. Matt tried to start a discussion based on Andy's initial paragraph to the list, which Matt summarized as that the MIB was "too complex". Henk asked who had read the draft and if anyone was interested in implementing it or had an alternative. Only the chairs and Andy admitted to reading it. There was therefore no point in an extended discussion, but Andy noted that there was a higher-level question: what should be in an SNMP agent. There are roles for an SNMP agent, and roles for the management station. In his mind, there are too many features, and a lot in this draft is out of scope. The draft ideas are basically two years old, and there are no other implementations. If no one is going to implement this (or even read it) then there must be some action at the WG-level... Emile noted that an operator would not like to get flooded by "unsolicited" measurement results; filters are required close to the controller of the measurement system, not in the back office. The feedback from Henk's customers is that the MIB should be simple, light-weight, and give users the freedom to do their own aggregation and statistics computation. The draft seems to be too France Telecom specific. Emile noted that this desire was in contradiction with a previous concern that the buffer for all results might be too big and therefore some aggregation might be required. There is a contradiction between a desire to report only raw data and a need for aggregation. Henk wondered if perhaps the draft could be limited to just the two tables it needs to provide raw data and remove everything else? Emile noted that the report tables are optional. Bob Cole wondered if the compliance section was clear that only two tables were required. Al said that he would read a document limited to core functionality. Andy felt the document itself was too complex? Does it want to specify a MIB for a single aggregation box or 1000 agents doing measurements? Matt said that he would like to see comments on this issue on the mailing list. 5. OWAMP -- Stanislav Shalunov Finally Stanislav Shalunov presented the updates to OWAMP. The approval of the requirements document was announced to the group. Updates to the protocol document are based on a sample open source implementation, and include test vectors for the random number generator used in the generation of packet sending schedules, so that the receiver knows accurately when the sender was supposed to send packets (which allows losses to be detected at the receiver without having to correlate sent packets with the sender). Matt asked how close Stanislav felt this document was to be forwarded to the IESG. One big issue is that the security has not been reviewed by experts. That needs to be done. Matt: What about a comparison with IPMP? Stanislav said that there are two differences: OWAMP includes control, and OWAMP tries to be "sneaky" and be not recognizable by routers. Matt noted that there was an ongoing discussion on IPMP on the IRTF/IMRG mailing list if any working group members were interested in following IPMP. 6. Milestones and Futures -- The Chairs Matt Zekauskas closed the meeting noting the milestones that have been met, those that are in process, and those that will be dropped if no one steps up to work on them. (see slides) These were largely a re-iteration of the conclusions from the Vienna meeting; they need to be run through the mailing list. Matt and Henk will send email to the list to solicit input. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Thu Dec 18 05:52:43 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15073 for ; Thu, 18 Dec 2003 05:52:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWvlQ-0003Aq-1r for ippm-archive@odin.ietf.org; Thu, 18 Dec 2003 05:52:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIAqGUi012198 for ippm-archive@odin.ietf.org; Thu, 18 Dec 2003 05:52:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWvlP-0003Af-RU for ippm-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 05:52:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15048 for ; Thu, 18 Dec 2003 05:52:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWvlM-0001n3-00 for ippm-web-archive@ietf.org; Thu, 18 Dec 2003 05:52:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWvlK-0001mv-00 for ippm-web-archive@ietf.org; Thu, 18 Dec 2003 05:52:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWvlK-0001ms-00 for ippm-web-archive@ietf.org; Thu, 18 Dec 2003 05:52:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWvlA-00038m-Kg; Thu, 18 Dec 2003 05:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWvkt-00038O-78 for ippm@optimus.ietf.org; Thu, 18 Dec 2003 05:51:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15038 for ; Thu, 18 Dec 2003 05:51:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWvkp-0001ml-00 for ippm@ietf.org; Thu, 18 Dec 2003 05:51:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWvkn-0001me-00 for ippm@ietf.org; Thu, 18 Dec 2003 05:51:39 -0500 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1AWvkn-0001lV-00 for ippm@ietf.org; Thu, 18 Dec 2003 05:51:37 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id 0D4F14E085; Thu, 18 Dec 2003 11:51:08 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 6AE164E07C for ; Thu, 18 Dec 2003 11:51:07 +0100 (CET) Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id hBIAp7dH012073 for ; Thu, 18 Dec 2003 11:51:07 +0100 Received: from localhost (henk@localhost) by x49.ripe.net (8.12.10/8.12.6) with ESMTP id hBIAp7N8006280 for ; Thu, 18 Dec 2003 11:51:07 +0100 X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Thu, 18 Dec 2003 11:51:07 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: ippm@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: N 0.500000 X-RIPE-Signature: f6cc7ab5c9eba6fdb341d367063898e9 Subject: [ippm] draft ietf58 ippm minutes Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Comments to Matt before Friday 19, 17:00h GMT please. Henk -=-=- IETF IP Performance Metrics WG (ippm) Thursday, November 13, 2003 at 13:00 to 15:00 ============================================= The meeting was moderated by the working group chairs, Matt Zekauskas and Henk Uijterwaal. Al Morton and Ruediger Geib took notes, which were edited into these minutes by the chairs. AGENDA 1. Agenda Bashing 2. Packet Reordering 3. Reordering Density 4. IPPM-MIB 5. OWAMP 6. Status, Milestones & Futures 1. Agenda Bashing -- The chairs There was no bashing, but Matt welcomed Henk Uijterwaal as the new co-chair, replacing Merike Kaeo who is now focusing on security work. 2. Packet Reordering -- Al Morton Al Morton presented the changes since the last meeting to the reordering draft (see slides). The major changes are (1) continued clarifications started in the last version, including changing the sense of the base metric so it reports "true" when a packet has been reordered, moving alternate methods of detecting reordering (time or bytes instead of sequence number) to a separate section, (2) adding the concept of steady-state versus transient reordering, and (3) adding text to cover packet fragmentation. The fragmentation text needs work, and will likely have the details moved to a separate section. The draft is still missing an appendix on applicability promised by Greg Wright. Matt asked which appendices, if any, were going to be normative (and we should so state). Jerry Perser asked if we could drop IPPM from the title, since in his view it was more general (that is, there was some applicability to BMWG as well). There was no objection from the assembled group. Matt (chair hat off) asked if adding fragmentation added too much complexity; none of the other metrics look at individual fragments. Jerry felt that either we should specify the metric so fragmentation does not occur, or we should check whether fragments are reordered. Al Morton noted that he has seen systems "in the wild" that don't handle reordered fragments well. Stanislav Shalunov noted that some versions of Linux actually send fragments in the reverse order because they get a slight performance improvement during reassembly; a note should be added. 3. Reordering Density -- Anura Jayasumana The next presentation was by Anura Jayasumana on reordering density (an individual submission). This is the second presentation we had on this topic, but the first by an author; there was a presentation at the last IETF meeting by Jerry McCollum from Agilent, who is familiar with the work. One can think of the reorder density function like a normalized histogram of buffer occupancy. The major problem that the group has with this work is that lost packets show up in the reorder density, so you cannot completely separate losses from reordering events using this technique. An example showing a lost packet was given. Stanislav Shalunov noted that it appears that loss is counted as reordering. Anura stated that it was correct. Stanislav asked if a sequence had no reordering but just loss would the result be non-zero? Anura said that was correct, that there is a problem with packet loss, the current definition was a compromise, and ensured the computation could be done in order n time and constant space. One interesting claim made by the author is that they have been able to characterize the nature of loss based on distributions of reorder density. It could also be a basis for TCP adjusting it's sensitivity to reordering on the fly, and the distribution could be used when modeling a network. (See also the "Properties" slides.) One major change from the previous proposal was the addition of "late" and "early" reordering density. Together with the original definition, Anura felt that this characterization might also be useful in solving concatenation of partial path reordering metrics to give a reordering metric for the full path. This led back to a discussion of packet loss. Jerry Perser asked if lost packets were early or late? Anura said that was recognized with the help of a place label. Al Morton again brought up that this was the biggest issue in this draft; the current working group draft makes reordering orthogonal with loss, and there is a clear definition of "early" and "late". The definitions of in and out of order and early and late need to merge to add this to the draft. Anura said that it depends on what you are trying to achieve with reordering measurements: perform TCP or network diagnosis? Predict network behavior? The use of density would add value; a simple number describing reordering doesn't provide enough information. The definition of loss would have to be agreed. Stanislav asserted that n-reordering makes the definition of loss orthogonal to reordering. n-reordering metric doesn't change in the presence of loss. Not every router sends a stream of numbers with monotonically increasing sequence numbers. Anura thought there was a problem with n-reordering and fast routers. Stanislav said that a linear buffer would be sufficient. Anura said that n squared would hit. Stanislav said not for n-reordering. Anura said that then duplicates are an issue. Al said that you either save information on packets which have arrived or those missing, usually the latter. Anura thought that a moving window is better than keeping information on packets. Jerry Perser noted that test instruments can't track millions of duplicate packets. Anura said that with reordering density you only need to keep track for a fixed window. Stanislav wanted to get back to loss. Anura said they recognize loss within window. Jerry wondered why it isn't called loss and reordering density. Anura said it isn't a loss density. Jerry said that he had a problem claiming reordered packets when only one is lost. For example, look at slide 6; Jerry said packet 4 is in sequence. Anura said that according to his definition packet 4 is reordered [3 was lost]. Anura wanted to know about packets arriving much later; suddenly "2" comes in and your whole view changes. Is this appropriate? Applications would presumably treat them as lost. Are they lost or reordered? Stanislav said the definition of reordering is only based on a sequence of arrivals. Jerry wanted to know if the authors checked the resources you require to implement reordering density (say for an oc192 link) -- what was the fastest speed tested? Anura said that results are forthcoming; they have software on Linux for testing, and the fastest speed tested so far was fast Ethernet. The authors would like this draft used as an alternative characterization metric in the current draft or published as a separate informational draft. Henk asked if we should merge drafts or proceed separately? Matt said that his sense was that the current authors seem to be disinclined to merge with loss mixed with reordering. Al Morton said that was true, and there were no other comments. 4. IPPM-MIB -- Emile Stephan Next, Emile Stephan presented the latest version of the MIB. He wanted to know the status of the registry -- it will be presented to the ADs as soon as the (apparently now expired) version is refreshed by the I-D editor after the meeting. RMON would like the OIDs for the metrics. Bob Cole asked what happens for new metrics? Matt said OIDs should be included in those drafts. As far as the MIB goes, Emile presented some recent (minor) changes, and then tried to walk the room through a sample setup showing how all the tables were organized and how views of the data are consumed (see slides). He tried to do a demo showing the MIB presenting results from a commercial measurement system, but the demo hiccupped in the middle. (He later showed it to the chairs.) He noted that Andy Bierman had sent a comment to the list today, and that he hasn't had time to consider it in detail, but he will respond. Matt tried to start a discussion based on Andy's initial paragraph to the list, which Matt summarized as that the MIB was "too complex". Henk asked who had read the draft and if anyone was interested in implementing it or had an alternative. Only the chairs and Andy admitted to reading it. There was therefore no point in an extended discussion, but Andy noted that there was a higher-level question: what should be in an SNMP agent. There are roles for an SNMP agent, and roles for the management station. In his mind, there are too many features, and a lot in this draft is out of scope. The draft ideas are basically two years old, and there are no other implementations. If no one is going to implement this (or even read it) then there must be some action at the WG-level... Emile noted that an operator would not like to get flooded by "unsolicited" measurement results; filters are required close to the controller of the measurement system, not in the back office. The feedback from Henk's customers is that the MIB should be simple, light-weight, and give users the freedom to do their own aggregation and statistics computation. The draft seems to be too France Telecom specific. Emile noted that this desire was in contradiction with a previous concern that the buffer for all results might be too big and therefore some aggregation might be required. There is a contradiction between a desire to report only raw data and a need for aggregation. Henk wondered if perhaps the draft could be limited to just the two tables it needs to provide raw data and remove everything else? Emile noted that the report tables are optional. Bob Cole wondered if the compliance section was clear that only two tables were required. Al said that he would read a document limited to core functionality. Andy felt the document itself was too complex? Does it want to specify a MIB for a single aggregation box or 1000 agents doing measurements? Matt said that he would like to see comments on this issue on the mailing list. 5. OWAMP -- Stanislav Shalunov Finally Stanislav Shalunov presented the updates to OWAMP. The approval of the requirements document was announced to the group. Updates to the protocol document are based on a sample open source implementation, and include test vectors for the random number generator used in the generation of packet sending schedules, so that the receiver knows accurately when the sender was supposed to send packets (which allows losses to be detected at the receiver without having to correlate sent packets with the sender). Matt asked how close Stanislav felt this document was to be forwarded to the IESG. One big issue is that the security has not been reviewed by experts. That needs to be done. Matt: What about a comparison with IPMP? Stanislav said that there are two differences: OWAMP includes control, and OWAMP tries to be "sneaky" and be not recognizable by routers. Matt noted that there was an ongoing discussion on IPMP on the IRTF/IMRG mailing list if any working group members were interested in following IPMP. 6. Milestones and Futures -- The Chairs Matt Zekauskas closed the meeting noting the milestones that have been met, those that are in process, and those that will be dropped if no one steps up to work on them. (see slides) These were largely a re-iteration of the conclusions from the Vienna meeting; they need to be run through the mailing list. Matt and Henk will send email to the list to solicit input. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Thu Dec 18 11:10:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01093 for ; Thu, 18 Dec 2003 11:10:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX0iv-0001nZ-FW; Thu, 18 Dec 2003 11:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX0iP-0001mW-EZ for ippm@optimus.ietf.org; Thu, 18 Dec 2003 11:09:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01059 for ; Thu, 18 Dec 2003 11:09:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX0iK-0003CZ-00 for ippm@ietf.org; Thu, 18 Dec 2003 11:09:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX0iJ-0003CS-00 for ippm@ietf.org; Thu, 18 Dec 2003 11:09:24 -0500 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 1AX0iJ-0003CP-00 for ippm@ietf.org; Thu, 18 Dec 2003 11:09:23 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 7917AE4A for ; Thu, 18 Dec 2003 11:09:22 -0500 (EST) Received: from BMW (unknown [207.75.164.22]) by basie.internet2.edu (Postfix) with ESMTP id 6F013CF3 for ; Thu, 18 Dec 2003 11:09:21 -0500 (EST) Date: Thu, 18 Dec 2003 11:09:21 -0500 From: Matthew J Zekauskas To: ippm@ietf.org Subject: Re: [ippm] draft ietf58 ippm minutes Message-ID: <146466848.1071745761@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The slides are also available currently at http://people.internet2.edu/~matt/IPPM/Meetings/ietf58/ --Matt _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Thu Dec 18 11:10:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01108 for ; Thu, 18 Dec 2003 11:10:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX0j4-0001pN-HL for ippm-archive@odin.ietf.org; Thu, 18 Dec 2003 11:10:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIGAA8i007019 for ippm-archive@odin.ietf.org; Thu, 18 Dec 2003 11:10:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX0j4-0001p8-Cg for ippm-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 11:10:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01076 for ; Thu, 18 Dec 2003 11:10:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX0j1-0003Dc-00 for ippm-web-archive@ietf.org; Thu, 18 Dec 2003 11:10:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX0j0-0003DV-00 for ippm-web-archive@ietf.org; Thu, 18 Dec 2003 11:10:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX0j0-0003DS-00 for ippm-web-archive@ietf.org; Thu, 18 Dec 2003 11:10:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX0iv-0001nZ-FW; Thu, 18 Dec 2003 11:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX0iP-0001mW-EZ for ippm@optimus.ietf.org; Thu, 18 Dec 2003 11:09:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01059 for ; Thu, 18 Dec 2003 11:09:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX0iK-0003CZ-00 for ippm@ietf.org; Thu, 18 Dec 2003 11:09:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX0iJ-0003CS-00 for ippm@ietf.org; Thu, 18 Dec 2003 11:09:24 -0500 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 1AX0iJ-0003CP-00 for ippm@ietf.org; Thu, 18 Dec 2003 11:09:23 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 7917AE4A for ; Thu, 18 Dec 2003 11:09:22 -0500 (EST) Received: from BMW (unknown [207.75.164.22]) by basie.internet2.edu (Postfix) with ESMTP id 6F013CF3 for ; Thu, 18 Dec 2003 11:09:21 -0500 (EST) Date: Thu, 18 Dec 2003 11:09:21 -0500 From: Matthew J Zekauskas To: ippm@ietf.org Subject: Re: [ippm] draft ietf58 ippm minutes Message-ID: <146466848.1071745761@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by mail.internet2.edu virus scanner Content-Transfer-Encoding: 7bit Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The slides are also available currently at http://people.internet2.edu/~matt/IPPM/Meetings/ietf58/ --Matt _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Fri Dec 19 12:20:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16462 for ; Fri, 19 Dec 2003 12:20:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXOHG-0002QI-1W; Fri, 19 Dec 2003 12:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXO7N-0002B4-CT for ippm@optimus.ietf.org; Fri, 19 Dec 2003 12:08:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16172 for ; Fri, 19 Dec 2003 12:08:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXO7M-0001DZ-00 for ippm@ietf.org; Fri, 19 Dec 2003 12:08:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXO7L-0001DS-00 for ippm@ietf.org; Fri, 19 Dec 2003 12:08:47 -0500 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 1AXO7L-0001DP-00; Fri, 19 Dec 2003 12:08:47 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id CEAFE150A; Fri, 19 Dec 2003 12:08:46 -0500 (EST) Received: from BMW (unknown [207.75.164.22]) by basie.internet2.edu (Postfix) with ESMTP id BCAE1144F; Fri, 19 Dec 2003 12:08:45 -0500 (EST) Date: Fri, 19 Dec 2003 12:08:45 -0500 From: Matthew J Zekauskas To: proceedings@ietf.org Cc: Matthew J Zekauskas , ippm@ietf.org, Henk Uijterwaal , Allison Mankin , Jon Peterson Message-ID: <236428886.1071835725@localhost> In-Reply-To: <236132350.1071835428@localhost> References: <236132350.1071835428@localhost> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [ippm] Re: Minutes from IPPM meeting at IETF58 in Minneapolis Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Grr. looked at the attachment, and for some reason, it looks like lines were wrapped as part of the attachment process. Please pull the version from the website as a better starting point. --Matt --On Friday, December 19, 2003 12:03 PM -0500 Matthew J Zekauskas wrote: > The minutes for the ippm meeting are attached. A copy > is also available off of > http://people.internet2.edu/~matt/IPPM/Meetings/ietf58/ > along with all presentations. > > --Matt _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Fri Dec 19 12:20:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16497 for ; Fri, 19 Dec 2003 12:20:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXOI7-0002VF-P0 for ippm-archive@odin.ietf.org; Fri, 19 Dec 2003 12:19:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJHJttc009617 for ippm-archive@odin.ietf.org; Fri, 19 Dec 2003 12:19:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXOI7-0002V2-K8 for ippm-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 12:19:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16449 for ; Fri, 19 Dec 2003 12:19:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXOI6-0001WQ-00 for ippm-web-archive@ietf.org; Fri, 19 Dec 2003 12:19:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXOI4-0001WI-00 for ippm-web-archive@ietf.org; Fri, 19 Dec 2003 12:19:53 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXOI4-0001W7-00 for ippm-web-archive@ietf.org; Fri, 19 Dec 2003 12:19:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXOHG-0002QI-1W; Fri, 19 Dec 2003 12:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXO7N-0002B4-CT for ippm@optimus.ietf.org; Fri, 19 Dec 2003 12:08:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16172 for ; Fri, 19 Dec 2003 12:08:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXO7M-0001DZ-00 for ippm@ietf.org; Fri, 19 Dec 2003 12:08:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXO7L-0001DS-00 for ippm@ietf.org; Fri, 19 Dec 2003 12:08:47 -0500 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 1AXO7L-0001DP-00; Fri, 19 Dec 2003 12:08:47 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id CEAFE150A; Fri, 19 Dec 2003 12:08:46 -0500 (EST) Received: from BMW (unknown [207.75.164.22]) by basie.internet2.edu (Postfix) with ESMTP id BCAE1144F; Fri, 19 Dec 2003 12:08:45 -0500 (EST) Date: Fri, 19 Dec 2003 12:08:45 -0500 From: Matthew J Zekauskas To: proceedings@ietf.org Cc: Matthew J Zekauskas , ippm@ietf.org, Henk Uijterwaal , Allison Mankin , Jon Peterson Message-ID: <236428886.1071835725@localhost> In-Reply-To: <236132350.1071835428@localhost> References: <236132350.1071835428@localhost> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by mail.internet2.edu virus scanner Content-Transfer-Encoding: 7bit Subject: [ippm] Re: Minutes from IPPM meeting at IETF58 in Minneapolis Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Grr. looked at the attachment, and for some reason, it looks like lines were wrapped as part of the attachment process. Please pull the version from the website as a better starting point. --Matt --On Friday, December 19, 2003 12:03 PM -0500 Matthew J Zekauskas wrote: > The minutes for the ippm meeting are attached. A copy > is also available off of > http://people.internet2.edu/~matt/IPPM/Meetings/ietf58/ > along with all presentations. > > --Matt _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Fri Dec 19 13:08:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16463 for ; Fri, 19 Dec 2003 12:20:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXOHF-0002Q2-Bt; Fri, 19 Dec 2003 12:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXO2i-0001fA-JS for ippm@optimus.ietf.org; Fri, 19 Dec 2003 12:04:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15965 for ; Fri, 19 Dec 2003 12:03:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXO2h-00013G-00 for ippm@ietf.org; Fri, 19 Dec 2003 12:03:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXO2f-000139-00 for ippm@ietf.org; Fri, 19 Dec 2003 12:03:58 -0500 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 1AXO2e-00012x-00; Fri, 19 Dec 2003 12:03:56 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id DBF501CA0; Fri, 19 Dec 2003 12:03:50 -0500 (EST) Received: from BMW (unknown [207.75.164.22]) by basie.internet2.edu (Postfix) with ESMTP id ABAB81C94; Fri, 19 Dec 2003 12:03:49 -0500 (EST) Date: Fri, 19 Dec 2003 12:03:48 -0500 From: Matthew J Zekauskas To: proceedings@ietf.org Cc: ippm@ietf.org, Matt Zekauskas , Henk Uijterwaal , Allison Mankin , Jon Peterson Message-ID: <236132350.1071835428@localhost> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========236137978==========" X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [ippm] Minutes from IPPM meeting at IETF58 in Minneapolis Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , --==========236137978========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 7bit The minutes for the ippm meeting are attached. A copy is also available off of http://people.internet2.edu/~matt/IPPM/Meetings/ietf58/ along with all presentations. --Matt --==========236137978========== Content-Type: text/plain; charset=us-ascii; name="ippm-2003-11-13-minutes-01.txt" Content-Disposition: attachment; filename="ippm-2003-11-13-minutes-01.txt"; size=11491 Content-Transfer-Encoding: 7bit IETF IP Performance Metrics WG (ippm) Thursday, November 13, 2003 at 13:00 to 15:00 ============================================= The meeting was moderated by the working group chairs, Matt Zekauskas and Henk Uijterwaal. Al Morton and Ruediger Geib took notes, which were edited into these minutes by the chairs. AGENDA 1. Agenda Bashing 2. Packet Reordering 3. Reordering Density 4. IPPM-MIB 5. OWAMP 6. Status, Milestones & Futures 1. Agenda Bashing -- The chairs There was no bashing, but Matt welcomed Henk Uijterwaal as the new co-chair, replacing Merike Kaeo who is now focusing on security work. 2. Packet Reordering -- Al Morton Al Morton presented the changes since the last meeting to the reordering draft (see slides). The major changes are (1) continued clarifications started in the last version, including changing the sense of the base metric so it reports "true" when a packet has been reordered, moving alternate methods of detecting reordering (time or bytes instead of sequence number) to a separate section, (2) adding the concept of steady-state versus transient reordering, and (3) adding text to cover packet fragmentation. The fragmentation text needs work, and will likely have the details moved to a separate section. The draft is still missing an appendix on applicability promised by Greg Wright. Matt asked which appendices, if any, were going to be normative (and we should so state). Jerry Perser asked if we could drop IPPM from the title, since in his view it was more general (that is, there was some applicability to BMWG as well). There was no objection from the assembled group. Matt (chair hat off) asked if adding fragmentation added too much complexity; none of the other metrics look at individual fragments. Jerry felt that either we should specify the metric so fragmentation does not occur, or we should check whether fragments are reordered. Al Morton noted that he has seen systems "in the wild" that don't handle reordered fragments well. Stanislav Shalunov noted that some versions of Linux actually send fragments in the reverse order because they get a slight performance improvement during reassembly; a note should be added. 3. Reordering Density -- Anura Jayasumana The next presentation was by Anura Jayasumana on reordering density (an individual submission). This is the second presentation we had on this topic, but the first by an author; there was a presentation at the last IETF meeting by Jerry McCollum from Agilent, who is familiar with the work. One can think of the reorder density function like a normalized histogram of buffer occupancy. The major problem that the group has with this work is that lost packets show up in the reorder density, so you cannot completely separate losses from reordering events using this technique. An example showing a lost packet was given. Stanislav Shalunov noted that it appears that loss is counted as reordering. Anura stated that it was correct. Stanislav asked if a sequence had no reordering but just loss would the result be non-zero? Anura said that was correct, that there is a problem with packet loss, the current definition was a compromise, and ensured the computation could be done in order n time and constant space. One interesting claim made by the author is that they have been able to characterize the nature of loss based on distributions of reorder density. It could also be a basis for TCP adjusting it's sensitivity to reordering on the fly, and the distribution could be used when modeling a network. (See also the "Properties" slides.) One major change from the previous proposal was the addition of "late" and "early" reordering density. Together with the original definition, Anura felt that this characterization might also be useful in solving concatenation of partial path reordering metrics to give a reordering metric for the full path. This led back to a discussion of packet loss. Jerry Perser asked if lost packets were early or late? Anura said that was recognized with the help of a place label. Al Morton again brought up that this was the biggest issue in this draft; the current working group draft makes reordering orthogonal with loss, and there is a clear definition of "early" and "late". The definitions of in and out of order and early and late need to merge to add this to the draft. Anura said that it depends on what you are trying to achieve with reordering measurements: perform TCP or network diagnosis? Predict network behavior? The use of density would add value; a simple number describing reordering doesn't provide enough information. The definition of loss would have to be agreed. Stanislav asserted that n-reordering makes the definition of loss orthogonal to reordering. n-reordering metric doesn't change in the presence of loss. Not every router sends a stream of numbers with monotonically increasing sequence numbers. Anura thought there was a problem with n-reordering and fast routers. Stanislav said that a linear buffer would be sufficient. Anura said that n squared would hit. Stanislav said not for n-reordering. Anura said that then duplicates are an issue. Al said that you either save information on packets which have arrived or those missing, usually the latter. Anura thought that a moving window is better than keeping information on packets. Jerry Perser noted that test instruments can't track millions of duplicate packets. Anura said that with reordering density you only need to keep track for a fixed window. Stanislav wanted to get back to loss. Anura said they recognize loss within window. Jerry wondered why it isn't called loss and reordering density. Anura said it isn't a loss density. Jerry said that he had a problem claiming reordered packets when only one is lost. For example, look at slide 6; Jerry said packet 4 is in sequence. Anura said that according to his definition packet 4 is reordered [3 was lost]. Anura wanted to know about packets arriving much later; suddenly "2" comes in and your whole view changes. Is this appropriate? Applications would presumably treat them as lost. Are they lost or reordered? Stanislav said the definition of reordering is only based on a sequence of arrivals. Jerry wanted to know if the authors checked the resources you require to implement reordering density (say for an oc192 link) -- what was the fastest speed tested? Anura said that results are forthcoming; they have software on Linux for testing, and the fastest speed tested so far was fast Ethernet. The authors would like this draft used as an alternative characterization metric in the current draft or published as a separate informational draft; publishing elsewhere was mentioned as another possibility. Henk asked if we should merge drafts or proceed separately? Matt said that his sense was that the current authors seem to be disinclined to merge with loss mixed with reordering. Al Morton said that was true, and there were no other comments. 4. IPPM-MIB -- Emile Stephan Next, Emile Stephan presented the latest version of the MIB. He wanted to know the status of the registry -- it will be presented to the ADs as soon as the (apparently now expired) version is refreshed by the I-D editor after the meeting. RMON would like the OIDs for the metrics. Bob Cole asked what happens for new metrics? Matt said OIDs should be included in those drafts. As far as the MIB goes, Emile presented some recent (minor) changes, and then tried to walk the room through a sample setup showing how all the tables were organized and how views of the data are consumed (see slides). He tried to do a demo showing the MIB presenting results from a commercial measurement system, but the demo hiccupped in the middle. (He later showed it to the chairs.) He noted that Andy Bierman had sent a comment to the list today, and that he hasn't had time to consider it in detail, but he will respond. Matt tried to start a discussion based on Andy's initial paragraph to the list, which Matt summarized as that the MIB was "too complex". Henk asked who had read the draft and if anyone was interested in implementing it or had an alternative. Only the chairs and Andy admitted to reading it. There was therefore no point in an extended discussion, but Andy noted that there was a higher-level question: what should be in an SNMP agent. There are roles for an SNMP agent, and roles for the management station. In his mind, there are too many features, and a lot in this draft is out of scope. The draft ideas are basically two years old, and there are no other implementations. If no one is going to implement this (or even read it) then there must be some action at the WG-level... Emile noted that an operator would not like to get flooded by "unsolicited" measurement results; filters are required close to the controller of the measurement system, not in the back office. The feedback from Henk's customers is that the MIB should be simple, light-weight, and give users the freedom to do their own aggregation and statistics computation. The draft seems to be too France Telecom specific. Emile noted that this desire was in contradiction with a previous concern that the buffer for all results might be too big and therefore some aggregation might be required. There is a contradiction between a desire to report only raw data and a need for aggregation. Henk wondered if perhaps the draft could be limited to just the two tables it needs to provide raw data and remove everything else? Emile noted that the report tables are optional. Bob Cole wondered if the compliance section was clear that only two tables were required. Al said that he would read a document limited to core functionality. Andy felt the document itself was too complex? Does it want to specify a MIB for a single aggregation box or 1000 agents doing measurements? Matt said that he would like to see comments on this issue on the mailing list. 5. OWAMP -- Stanislav Shalunov Finally Stanislav Shalunov presented the updates to OWAMP. The approval of the requirements document was announced to the group. Updates to the protocol document are based on a sample open source implementation, and include test vectors for the random number generator used in the generation of packet sending schedules, so that the receiver knows accurately when the sender was supposed to send packets (which allows losses to be detected at the receiver without having to correlate sent packets with the sender). Matt asked how close Stanislav felt this document was to be forwarded to the IESG. One big issue is that the security has not been reviewed by experts. That needs to be done. Matt: What about a comparison with IPMP? Stanislav said that there are two differences: OWAMP includes control, and OWAMP tries to be "sneaky" and be not recognizable by routers. Matt noted that there was an ongoing discussion on IPMP on the IRTF/IMRG mailing list if any working group members were interested in following IPMP. 6. Milestones and Futures -- The Chairs Matt Zekauskas closed the meeting noting the milestones that have been met, those that are in process, and those that will be dropped if no one steps up to work on them. (see slides) These were largely a re-iteration of the conclusions from the Vienna meeting; they need to be run through the mailing list. Matt and Henk will send email to the list to solicit input. --==========236137978==========-- _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Fri Dec 19 13:08:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16499 for ; Fri, 19 Dec 2003 12:20:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXOI8-0002VX-R5 for ippm-archive@odin.ietf.org; Fri, 19 Dec 2003 12:19:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJHJu5H009633 for ippm-archive@odin.ietf.org; Fri, 19 Dec 2003 12:19:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXOI8-0002VI-Ld for ippm-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 12:19:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16452 for ; Fri, 19 Dec 2003 12:19:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXOI7-0001WV-00 for ippm-web-archive@ietf.org; Fri, 19 Dec 2003 12:19:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXOI4-0001WA-00 for ippm-web-archive@ietf.org; Fri, 19 Dec 2003 12:19:54 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXOI4-0001W6-00 for ippm-web-archive@ietf.org; Fri, 19 Dec 2003 12:19:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXOHF-0002Q2-Bt; Fri, 19 Dec 2003 12:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXO2i-0001fA-JS for ippm@optimus.ietf.org; Fri, 19 Dec 2003 12:04:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15965 for ; Fri, 19 Dec 2003 12:03:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXO2h-00013G-00 for ippm@ietf.org; Fri, 19 Dec 2003 12:03:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXO2f-000139-00 for ippm@ietf.org; Fri, 19 Dec 2003 12:03:58 -0500 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 1AXO2e-00012x-00; Fri, 19 Dec 2003 12:03:56 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id DBF501CA0; Fri, 19 Dec 2003 12:03:50 -0500 (EST) Received: from BMW (unknown [207.75.164.22]) by basie.internet2.edu (Postfix) with ESMTP id ABAB81C94; Fri, 19 Dec 2003 12:03:49 -0500 (EST) Date: Fri, 19 Dec 2003 12:03:48 -0500 From: Matthew J Zekauskas To: proceedings@ietf.org Cc: ippm@ietf.org, Matt Zekauskas , Henk Uijterwaal , Allison Mankin , Jon Peterson Message-ID: <236132350.1071835428@localhost> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========236137978==========" X-Virus-Scanned: by mail.internet2.edu virus scanner Subject: [ippm] Minutes from IPPM meeting at IETF58 in Minneapolis Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --==========236137978========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 7bit The minutes for the ippm meeting are attached. A copy is also available off of http://people.internet2.edu/~matt/IPPM/Meetings/ietf58/ along with all presentations. --Matt --==========236137978========== Content-Type: text/plain; charset=us-ascii; name="ippm-2003-11-13-minutes-01.txt" Content-Disposition: attachment; filename="ippm-2003-11-13-minutes-01.txt"; size=11491 Content-Transfer-Encoding: 7bit IETF IP Performance Metrics WG (ippm) Thursday, November 13, 2003 at 13:00 to 15:00 ============================================= The meeting was moderated by the working group chairs, Matt Zekauskas and Henk Uijterwaal. Al Morton and Ruediger Geib took notes, which were edited into these minutes by the chairs. AGENDA 1. Agenda Bashing 2. Packet Reordering 3. Reordering Density 4. IPPM-MIB 5. OWAMP 6. Status, Milestones & Futures 1. Agenda Bashing -- The chairs There was no bashing, but Matt welcomed Henk Uijterwaal as the new co-chair, replacing Merike Kaeo who is now focusing on security work. 2. Packet Reordering -- Al Morton Al Morton presented the changes since the last meeting to the reordering draft (see slides). The major changes are (1) continued clarifications started in the last version, including changing the sense of the base metric so it reports "true" when a packet has been reordered, moving alternate methods of detecting reordering (time or bytes instead of sequence number) to a separate section, (2) adding the concept of steady-state versus transient reordering, and (3) adding text to cover packet fragmentation. The fragmentation text needs work, and will likely have the details moved to a separate section. The draft is still missing an appendix on applicability promised by Greg Wright. Matt asked which appendices, if any, were going to be normative (and we should so state). Jerry Perser asked if we could drop IPPM from the title, since in his view it was more general (that is, there was some applicability to BMWG as well). There was no objection from the assembled group. Matt (chair hat off) asked if adding fragmentation added too much complexity; none of the other metrics look at individual fragments. Jerry felt that either we should specify the metric so fragmentation does not occur, or we should check whether fragments are reordered. Al Morton noted that he has seen systems "in the wild" that don't handle reordered fragments well. Stanislav Shalunov noted that some versions of Linux actually send fragments in the reverse order because they get a slight performance improvement during reassembly; a note should be added. 3. Reordering Density -- Anura Jayasumana The next presentation was by Anura Jayasumana on reordering density (an individual submission). This is the second presentation we had on this topic, but the first by an author; there was a presentation at the last IETF meeting by Jerry McCollum from Agilent, who is familiar with the work. One can think of the reorder density function like a normalized histogram of buffer occupancy. The major problem that the group has with this work is that lost packets show up in the reorder density, so you cannot completely separate losses from reordering events using this technique. An example showing a lost packet was given. Stanislav Shalunov noted that it appears that loss is counted as reordering. Anura stated that it was correct. Stanislav asked if a sequence had no reordering but just loss would the result be non-zero? Anura said that was correct, that there is a problem with packet loss, the current definition was a compromise, and ensured the computation could be done in order n time and constant space. One interesting claim made by the author is that they have been able to characterize the nature of loss based on distributions of reorder density. It could also be a basis for TCP adjusting it's sensitivity to reordering on the fly, and the distribution could be used when modeling a network. (See also the "Properties" slides.) One major change from the previous proposal was the addition of "late" and "early" reordering density. Together with the original definition, Anura felt that this characterization might also be useful in solving concatenation of partial path reordering metrics to give a reordering metric for the full path. This led back to a discussion of packet loss. Jerry Perser asked if lost packets were early or late? Anura said that was recognized with the help of a place label. Al Morton again brought up that this was the biggest issue in this draft; the current working group draft makes reordering orthogonal with loss, and there is a clear definition of "early" and "late". The definitions of in and out of order and early and late need to merge to add this to the draft. Anura said that it depends on what you are trying to achieve with reordering measurements: perform TCP or network diagnosis? Predict network behavior? The use of density would add value; a simple number describing reordering doesn't provide enough information. The definition of loss would have to be agreed. Stanislav asserted that n-reordering makes the definition of loss orthogonal to reordering. n-reordering metric doesn't change in the presence of loss. Not every router sends a stream of numbers with monotonically increasing sequence numbers. Anura thought there was a problem with n-reordering and fast routers. Stanislav said that a linear buffer would be sufficient. Anura said that n squared would hit. Stanislav said not for n-reordering. Anura said that then duplicates are an issue. Al said that you either save information on packets which have arrived or those missing, usually the latter. Anura thought that a moving window is better than keeping information on packets. Jerry Perser noted that test instruments can't track millions of duplicate packets. Anura said that with reordering density you only need to keep track for a fixed window. Stanislav wanted to get back to loss. Anura said they recognize loss within window. Jerry wondered why it isn't called loss and reordering density. Anura said it isn't a loss density. Jerry said that he had a problem claiming reordered packets when only one is lost. For example, look at slide 6; Jerry said packet 4 is in sequence. Anura said that according to his definition packet 4 is reordered [3 was lost]. Anura wanted to know about packets arriving much later; suddenly "2" comes in and your whole view changes. Is this appropriate? Applications would presumably treat them as lost. Are they lost or reordered? Stanislav said the definition of reordering is only based on a sequence of arrivals. Jerry wanted to know if the authors checked the resources you require to implement reordering density (say for an oc192 link) -- what was the fastest speed tested? Anura said that results are forthcoming; they have software on Linux for testing, and the fastest speed tested so far was fast Ethernet. The authors would like this draft used as an alternative characterization metric in the current draft or published as a separate informational draft; publishing elsewhere was mentioned as another possibility. Henk asked if we should merge drafts or proceed separately? Matt said that his sense was that the current authors seem to be disinclined to merge with loss mixed with reordering. Al Morton said that was true, and there were no other comments. 4. IPPM-MIB -- Emile Stephan Next, Emile Stephan presented the latest version of the MIB. He wanted to know the status of the registry -- it will be presented to the ADs as soon as the (apparently now expired) version is refreshed by the I-D editor after the meeting. RMON would like the OIDs for the metrics. Bob Cole asked what happens for new metrics? Matt said OIDs should be included in those drafts. As far as the MIB goes, Emile presented some recent (minor) changes, and then tried to walk the room through a sample setup showing how all the tables were organized and how views of the data are consumed (see slides). He tried to do a demo showing the MIB presenting results from a commercial measurement system, but the demo hiccupped in the middle. (He later showed it to the chairs.) He noted that Andy Bierman had sent a comment to the list today, and that he hasn't had time to consider it in detail, but he will respond. Matt tried to start a discussion based on Andy's initial paragraph to the list, which Matt summarized as that the MIB was "too complex". Henk asked who had read the draft and if anyone was interested in implementing it or had an alternative. Only the chairs and Andy admitted to reading it. There was therefore no point in an extended discussion, but Andy noted that there was a higher-level question: what should be in an SNMP agent. There are roles for an SNMP agent, and roles for the management station. In his mind, there are too many features, and a lot in this draft is out of scope. The draft ideas are basically two years old, and there are no other implementations. If no one is going to implement this (or even read it) then there must be some action at the WG-level... Emile noted that an operator would not like to get flooded by "unsolicited" measurement results; filters are required close to the controller of the measurement system, not in the back office. The feedback from Henk's customers is that the MIB should be simple, light-weight, and give users the freedom to do their own aggregation and statistics computation. The draft seems to be too France Telecom specific. Emile noted that this desire was in contradiction with a previous concern that the buffer for all results might be too big and therefore some aggregation might be required. There is a contradiction between a desire to report only raw data and a need for aggregation. Henk wondered if perhaps the draft could be limited to just the two tables it needs to provide raw data and remove everything else? Emile noted that the report tables are optional. Bob Cole wondered if the compliance section was clear that only two tables were required. Al said that he would read a document limited to core functionality. Andy felt the document itself was too complex? Does it want to specify a MIB for a single aggregation box or 1000 agents doing measurements? Matt said that he would like to see comments on this issue on the mailing list. 5. OWAMP -- Stanislav Shalunov Finally Stanislav Shalunov presented the updates to OWAMP. The approval of the requirements document was announced to the group. Updates to the protocol document are based on a sample open source implementation, and include test vectors for the random number generator used in the generation of packet sending schedules, so that the receiver knows accurately when the sender was supposed to send packets (which allows losses to be detected at the receiver without having to correlate sent packets with the sender). Matt asked how close Stanislav felt this document was to be forwarded to the IESG. One big issue is that the security has not been reviewed by experts. That needs to be done. Matt: What about a comparison with IPMP? Stanislav said that there are two differences: OWAMP includes control, and OWAMP tries to be "sneaky" and be not recognizable by routers. Matt noted that there was an ongoing discussion on IPMP on the IRTF/IMRG mailing list if any working group members were interested in following IPMP. 6. Milestones and Futures -- The Chairs Matt Zekauskas closed the meeting noting the milestones that have been met, those that are in process, and those that will be dropped if no one steps up to work on them. (see slides) These were largely a re-iteration of the conclusions from the Vienna meeting; they need to be run through the mailing list. Matt and Henk will send email to the list to solicit input. --==========236137978==========-- _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm