From ippm-bounces@ietf.org Wed Jun 01 14:47:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdYFt-0006Hg-LI; Wed, 01 Jun 2005 14:47:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdYFr-0006Hb-Vv for ippm@megatron.ietf.org; Wed, 01 Jun 2005 14:47:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14794 for ; Wed, 1 Jun 2005 14:47:48 -0400 (EDT) Received: from alpha.dante.org.uk ([193.63.211.19] helo=mail.dante.org.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdYZe-0003YI-JE for ippm@ietf.org; Wed, 01 Jun 2005 15:08:24 -0400 Received: from [127.0.0.1] (helo=localhost) by mail.dante.org.uk with esmtp (Exim 4.43) id 1DdYFW-0005vf-5R for ippm@ietf.org; Wed, 01 Jun 2005 19:47:30 +0100 Received: from mail.dante.org.uk ([127.0.0.1]) by localhost (alpha [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22514-10 for ; Wed, 1 Jun 2005 19:47:21 +0100 (BST) Received: from [193.63.211.123] (helo=[193.63.211.123]) by mail.dante.org.uk with esmtp (Exim 4.43) id 1DdYFM-0005vb-Qy for ippm@ietf.org; Wed, 01 Jun 2005 19:47:20 +0100 Message-ID: <429E02BC.1050805@dante.org.uk> Date: Wed, 01 Jun 2005 19:47:24 +0100 From: Maurizio Molina User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ippm@ietf.org X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at dante.org.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: Subject: [ippm] Composition of Metrics X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Dear all, In RFC 2330 (Framework for IP Performance Metrics), the Spatial and temporal composition of metrics is defined (see extract below). However, in none of the RFCs defining the metrics the problem appears to be tackled. Could somebody clarify me if there is a reason why this piece of work has not been undertaken? Thanks, Maurizio 9.1. Spatial Composition of Metrics ..... When the definition of a metric includes a conjecture that the metric across the path is related to the metric across the subpaths of the path, that conjecture constitutes a claim that the metric exhibits spatial composition. The definition should then include: + the specific conjecture applied to the metric, + a justification of the practical utility of the composition in terms of making accurate measurements of the metric on the path, + a justification of the usefulness of the composition in terms of making analysis of the path using A-frame concepts more effective, and + an analysis of how the conjecture could be incorrect. 9.2. Temporal Composition of Formal Models and Empirical Metrics ...... When the definition of a metric includes a conjecture that the metric across the path at a given time T is related to the metric across the path for a set of other times, that conjecture constitutes a claim that the metric exhibits temporal composition. The definition should then include: + the specific conjecture applied to the metric, + a justification of the practical utility of the composition in terms of making accurate measurements of the metric on the path, and + a justification of the usefulness of the composition in terms of making analysis of the path using A-frame concepts more effective. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Jun 02 08:08:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdoVP-0007Q6-3M; Thu, 02 Jun 2005 08:08:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdoVN-0007Pw-Sl for ippm@megatron.ietf.org; Thu, 02 Jun 2005 08:08:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07616 for ; Thu, 2 Jun 2005 08:08:56 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdopO-00015j-89 for ippm@ietf.org; Thu, 02 Jun 2005 08:29:39 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Jun 2005 14:08:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ippm] Composition of Metrics Date: Thu, 2 Jun 2005 14:08:53 +0200 Message-ID: Thread-Topic: [ippm] Composition of Metrics Thread-Index: AcVm2quvVXIqoPX7TbulDfjqTwP4LAAjce7g From: "STEPHAN Emile RD-CORE-LAN" To: "Maurizio Molina" X-OriginalArrivalTime: 02 Jun 2005 12:08:54.0676 (UTC) FILETIME=[D8D27540:01C5676B] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable Cc: Lei Liang , ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Dear Maurizio 2 years ago I tried to introduce this point in the IPPM WG, see = http://www.watersprings.org/pub/id/draft-stephan-ippm-spatial-metrics-01.= txt. This ID defines metrics for spatial composition and spatial = decomposition. This point was presented and discussed in the IPPM WG.=20 My understanding of the IPPM WG conclusion is that it is quite tricky to = define composition metrics respectful of the RFC2330 because it is = possible to prove that such composition is not deterministic. Consequently Lei and I are focusing on the definition of spatial metrics = to decompose end-to-end measures and one-to-group metrics in = http://www.ietf.org/internet-drafts/draft-stephan-ippm-multimetrics-00.tx= t.=20 Regards Emile > -----Message d'origine----- > De=A0: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] De la part = de > Maurizio Molina > Envoy=E9=A0: mercredi 1 juin 2005 20:47 > =C0=A0: ippm@ietf.org > Objet=A0: [ippm] Composition of Metrics >=20 > Dear all, > In RFC 2330 (Framework for IP Performance Metrics), the Spatial and > temporal composition of metrics is defined (see extract below). > However, in none of the RFCs defining the metrics the problem appears = to > be tackled. Could somebody clarify me if there is a reason why this > piece of work has not been undertaken? > Thanks, > Maurizio >=20 >=20 > 9.1. Spatial Composition of Metrics > ..... > When the definition of a metric includes a conjecture that the = metric > across the path is related to the metric across the subpaths of the > path, that conjecture constitutes a claim that the metric exhibits > spatial composition. The definition should then include: > + the specific conjecture applied to the metric, > + a justification of the practical utility of the composition in > terms of making accurate measurements of the metric on the path, > + a justification of the usefulness of the composition in terms of > making analysis of the path using A-frame concepts more = effective, > and > + an analysis of how the conjecture could be incorrect. >=20 > 9.2. Temporal Composition of Formal Models and Empirical Metrics >=20 > ...... >=20 > When the definition of a metric includes a conjecture that the = metric > across the path at a given time T is related to the metric across = the > path for a set of other times, that conjecture constitutes a claim > that the metric exhibits temporal composition. The definition = should > then include: >=20 > + the specific conjecture applied to the metric, > + a justification of the practical utility of the composition in > terms of making accurate measurements of the metric on the path, > and > + a justification of the usefulness of the composition in terms of > making analysis of the path using A-frame concepts more = effective. >=20 >=20 >=20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Jun 09 12:22:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgPnA-0006iH-1N; Thu, 09 Jun 2005 12:22:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgPn8-0006i8-74 for ippm@megatron.ietf.org; Thu, 09 Jun 2005 12:22:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18300 for ; Thu, 9 Jun 2005 12:21:59 -0400 (EDT) Received: from alpha.dante.org.uk ([193.63.211.19] helo=mail.dante.org.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgQ8Y-00034N-7W for ippm@ietf.org; Thu, 09 Jun 2005 12:44:14 -0400 Received: from [127.0.0.1] (helo=localhost) by mail.dante.org.uk with esmtp (Exim 4.43) id 1DgPmX-0007SZ-TK; Thu, 09 Jun 2005 17:21:25 +0100 Received: from mail.dante.org.uk ([127.0.0.1]) by localhost (alpha [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28602-04; Thu, 9 Jun 2005 17:21:11 +0100 (BST) Received: from [193.63.211.123] (helo=[193.63.211.123]) by mail.dante.org.uk with esmtp (Exim 4.43) id 1DgPmJ-0007SU-Av; Thu, 09 Jun 2005 17:21:11 +0100 Message-ID: <42A86C7A.2080501@dante.org.uk> Date: Thu, 09 Jun 2005 17:21:14 +0100 From: Maurizio Molina User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: STEPHAN Emile RD-CORE-LAN , ippm@ietf.org Subject: Re: [ippm] Composition of Metrics References: In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=windows-1252 X-Virus-Scanned: amavisd-new at dante.org.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA18300 Cc: Lei Liang , GN-JRA1-list X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Hi Emile, I compared your two drafts, and summarizing I would say (correct me if I=92m wrong) that: 1) Type-P-METRIC-XX-trajectory in the old draft corresponds to the Type-P-METRIC-stream in the new one. 2) The new draft contains the one-to-group metrics 3) The asynchronous metrics were ruled out. Regarding the last point, I understand that if you have a set of hosts along a path and a set of delays obtai= ned by *different* probes (thus asynchronous...) is too na=EFve to say that the delay=92s sum is a good representation of the singleton one-way-delay on the path. The path delay and its partitioning in the different portions could of course be obtained if we had a trajectory metric, which is a good thing but is not given by any currently widely deployed measurement protocol. So, it looks like the IPPM WG preferred just to prepare the container for something that it is still to come and not to say anything about how to compose existing metric. What I think would be useful is giving guidelines about the composition of metric *statistics* (e.g. the mean -> trivial - the variance or the percentiles -> not trivial because the independence on the several path portions comes into play). I know that testing such an independence hypothesis is difficult or impossible, is it a reason for not saying anything about how to compose metric statistics (which is something that operators would like to do)?. Furthermore, in the fourth bullet point of RFC 2330 there was exactly the statement that the specification of the composition would come along with some reasoning about its correctness (see below). Apologies if I'm raising a point that has already been discussed and buried in te WG. In this case, I'd appreciate pointers to mail archives, etc. Regards, Maurizio STEPHAN Emile RD-CORE-LAN wrote: >Dear Maurizio > >2 years ago I tried to introduce this point in the IPPM WG, see http://w= ww.watersprings.org/pub/id/draft-stephan-ippm-spatial-metrics-01.txt. Thi= s ID defines metrics for spatial composition and spatial decomposition. T= his point was presented and discussed in the IPPM WG.=20 >My understanding of the IPPM WG conclusion is that it is quite tricky to= define composition metrics respectful of the RFC2330 because it is possi= ble to prove that such composition is not deterministic. > >Consequently Lei and I are focusing on the definition of spatial metrics= to decompose end-to-end measures and one-to-group metrics in http://www.= ietf.org/internet-drafts/draft-stephan-ippm-multimetrics-00.txt.=20 > > >Regards >Emile > > =20 > >>-----Message d'origine----- >>De : ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] De la part de >>Maurizio Molina >>Envoy=E9 : mercredi 1 juin 2005 20:47 >>=C0 : ippm@ietf.org >>Objet : [ippm] Composition of Metrics >> >>Dear all, >>In RFC 2330 (Framework for IP Performance Metrics), the Spatial and >>temporal composition of metrics is defined (see extract below). >>However, in none of the RFCs defining the metrics the problem appears t= o >>be tackled. Could somebody clarify me if there is a reason why this >>piece of work has not been undertaken? >>Thanks, >>Maurizio >> >> >>9.1. Spatial Composition of Metrics >>..... >> When the definition of a metric includes a conjecture that the metri= c >> across the path is related to the metric across the subpaths of the >> path, that conjecture constitutes a claim that the metric exhibits >> spatial composition. The definition should then include: >> + the specific conjecture applied to the metric, >> + a justification of the practical utility of the composition in >> terms of making accurate measurements of the metric on the path, >> + a justification of the usefulness of the composition in terms of >> making analysis of the path using A-frame concepts more effective= , >> and >> + an analysis of how the conjecture could be incorrect. >> >>9.2. Temporal Composition of Formal Models and Empirical Metrics >> >>...... >> >> When the definition of a metric includes a conjecture that the metri= c >> across the path at a given time T is related to the metric across th= e >> path for a set of other times, that conjecture constitutes a claim >> that the metric exhibits temporal composition. The definition shoul= d >> then include: >> >> + the specific conjecture applied to the metric, >> + a justification of the practical utility of the composition in >> terms of making accurate measurements of the metric on the path, >> and >> + a justification of the usefulness of the composition in terms of >> making analysis of the path using A-frame concepts more effective. >> >> >> >> >>_______________________________________________ >>ippm mailing list >>ippm@ietf.org >>https://www1.ietf.org/mailman/listinfo/ippm >> > > =20 > _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Jun 09 14:04:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgRO4-0002j6-BQ; Thu, 09 Jun 2005 14:04:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgRF1-0000cH-1G; Thu, 09 Jun 2005 13:54:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28891; Thu, 9 Jun 2005 13:54:53 -0400 (EDT) From: roman.krzanowski@verizon.com Received: from irvmail2.verizon.com ([192.76.80.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgRaS-0007Vb-39; Thu, 09 Jun 2005 14:17:08 -0400 Received: from smtpirv.verizon.com (smtpirv.verizon.com [138.83.34.67]) by irvmail2.verizon.com (8.13.3/8.13.3) with ESMTP id j59HsPe2008046; Thu, 9 Jun 2005 12:54:26 -0500 (EST) Received: from ustxirvhqwmms01.ent.verizon.com (IRVMMS01B.interwan.gte.com [138.83.34.107]) by smtpirv.verizon.com (8.13.3/8.13.3) with ESMTP id j59HsKk7006681; Thu, 9 Jun 2005 12:54:21 -0500 (CDT) Received: from 138.83.34.22 by ustxirvhqwmms01.ent.verizon.com with ESMTP (SMTP Relay); Thu, 09 Jun 2005 13:53:41 -0400 X-Server-Uuid: E1A60121-6F68-4E45-9692-B480AF34C963 Received: from dwsmtp01.core.verizon.com (dwmail21.interwan.gte.com [138.83.36.17]) by coregate1.verizon.com (8.13.3/8.13.3) with ESMTP id j59HsATm008740; Thu, 9 Jun 2005 12:54:12 -0500 (CDT) Subject: Re: [ippm] Composition of Metrics To: "Maurizio Molina" X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: Date: Thu, 9 Jun 2005 13:54:06 -0400 X-MIMETrack: Serialize by Router on DWSMTP01/HSVR/Verizon(Release 6.0.2CF2|July 23, 2003) at 06/09/2005 12:54:12 MIME-Version: 1.0 X-WSS-ID: 6EB65DAF2S81040445-01-01 X-Spam-Score: 0.3 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c X-Mailman-Approved-At: Thu, 09 Jun 2005 14:04:15 -0400 Cc: ippm-bounces@ietf.org, Lei Liang , ippm@ietf.org, STEPHAN Emile RD-CORE-LAN , GN-JRA1-list X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1689756869==" Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org --===============1689756869== Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQoNCg0KDQp0aGUgY29tcG9zaXRpb24gb2YgbWV0cmljcyBpcyBvbiBldmVyeWJvZHkncyBtaW5k ICggYSB0cml2aWFsIHN0YXRlbWVudCkNCmFuZCBJIGd1ZXNzIHRoZSBzb2x1dGlvbiBpcyBlbHVz aXZlLg0KSSBoYXZlIHNlZW4gdHdvIGJyb2FkIGFwcHJvYWNoZXMgIG9yIG1heWJlICB0aHJlZQ0K KDEpIENhbm5vdCBiZSBkb25lIGFuZCB2aW9sYXRlcyBhbGwga25vd24gcGh5c2ljYWwgYW5kIG1h dGhlbWF0aWNhbCBsYXdzLg0KKDIpIG11c3QgYmUgZG9uZSBhbmQgYW55IHJlYXNvbmFibGUgbWV0 aG9kIHdlIGFncmVlIG9uIHdpbGwgZG8NCigzKSBzb21lIGFwcHJveGltYXRpb24gdG8gdGhlIGVu ZCB0byBlbmQgcGVyZm9ybWFuY2UgZnJvbSBzdWItc2VnbWVudHMNCm1ldHJpY3MgIGZvciBwcmFj dGljYWwgcHVycG9zZXMgY2FuIGJlIGFjaGlldmVkIHVzaW5nDQphZGRpdGlvbiAoIGxhdGVuY3kp LCBwcm9iYWJpbGl0eSBiYXNlZCggcGFja2V0IGxvc3MpIGFnZ3JlZ2F0ZXMgdGhhdCwgd2hpbGUN CmluYWNjdXJhdGUsIGZyb20gdGhlIFNQICBwZXJzcGVjdGl2ZSB3aWxsIGRvLg0KDQpJIGFtIHNv bWVob3cgbGVhbmluZyB0b3dhcmRzIHRoZSBvcHRpb24gKDMpLiBUaGVyZSBpcyBpbiBteSB2aWV3 IGFuIGFic2VuY2UNCm9mIGhhcmQgZ3VpZGVsaW5lcyBob3cgdG8gZG8gdGhlIHJlY29tYmluYXRp b24NCmJ1dCBJIGd1ZXNzIHRoZXJlIGlzIHBsZW50eSBvZiBwcmFnbWF0aWMgYXBwcm9hY2hlcyBp bXBsZW1lbnRlZCBvciB1c2VkLg0KQW5kIGNvbnNpZGVyaW5nIHRoZSBuYXR1cmUgb2YgdGhlIHBy b2JsZW0NCnByYWdtYXRpYyBhcHBvYWNoIGlzIHRoZSBiZXN0IHdlIGNhbiBkby4gVG8gdGhpcyBw b2ludCwgbWF5YmUgdW5kZXIgIElQUE0NCldHIHdlIHNob3VsZCBkZXZlbG9wIHRoZSBkb2N1bWVu dA0Kd2l0aCByZXF1aXJlbWVudHMgYW5kIGEgc3VtbWFyeSBvZiBwcmFnbWF0aWMgc29sdXRpb25z IGZyb20gZGlmZmVyZW50IFNQcy4NCkluIG15IHZpZXcgc3VjaCBhIGRvY3VtZW50IHdvdWxkIGNl cnRhaW5seSBoZWxwIGFsbCBvZiB1cyBpbnZvbHZlZCB0byBmb2N1cw0Kb24gc29tZSBiZXN0IHBy YWN0aWNlcyBvciBtZXRob2RzDQpyb21hbiBrDQoNCg0KDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAg ICAgICAgICAgICAgICAgICAiTWF1cml6aW8gTW9saW5hIiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICA8bWF1cml6aW8ubW9saW5hQGRhICAgICAg ICBUbzogICAgICAgIlNURVBIQU4gRW1pbGUgUkQtQ09SRS1MQU4iIDxlbWlsZS5zdGVwaGFuQGZy YW5jZXRlbGVjb20uY29tPiwgICAgICANCiAgICAgICAgICAgICAgICAgICAgICBudGUub3JnLnVr PiAgICAgICAgICAgICAgICAgaXBwbUBpZXRmLm9yZyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAg ICAgICBTZW50IGJ5OiAgICAgICAgICAgICAgICAgICBjYzogICAgICAgIkxlaSBMaWFuZyIgPEwu TGlhbmdAc3VycmV5LmFjLnVrPiwgIkdOLUpSQTEtbGlzdCIgICAgICAgICAgICAgICAgICANCiAg ICAgICAgICAgICAgICAgICAgICBpcHBtLWJvdW5jZXNAaWV0Zi5vICAgICAgICAgPGduMi1qcmEx QGRhbnRlLm9yZy51az4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICByZyAgICAgICAgICAgICAgICAgICAg ICAgICBTdWJqZWN0OiAgUmU6IFtpcHBtXSBDb21wb3NpdGlvbiBvZiBNZXRyaWNzICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN CiAgICAgICAgICAgICAgICAgICAgICAwNi8wOS8yMDA1IDEyOjIxIFBNICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQoNCg0KSGkg RW1pbGUsDQoNCkkgY29tcGFyZWQgeW91ciB0d28gZHJhZnRzLCBhbmQgc3VtbWFyaXppbmcgSSB3 b3VsZCBzYXkgKGNvcnJlY3QgbWUgaWYNCknigJltIHdyb25nKSB0aGF0Og0KDQoxKSBUeXBlLVAt TUVUUklDLVhYLXRyYWplY3RvcnkgaW4gdGhlIG9sZCBkcmFmdCBjb3JyZXNwb25kcyB0byB0aGUN ClR5cGUtUC1NRVRSSUMtc3RyZWFtIGluIHRoZSBuZXcgb25lLg0KDQoyKSBUaGUgbmV3IGRyYWZ0 IGNvbnRhaW5zIHRoZSBvbmUtdG8tZ3JvdXAgbWV0cmljcw0KDQozKSBUaGUgYXN5bmNocm9ub3Vz IG1ldHJpY3Mgd2VyZSBydWxlZCBvdXQuDQoNClJlZ2FyZGluZyB0aGUgbGFzdCBwb2ludCwgSSB1 bmRlcnN0YW5kIHRoYXQgaWYgeW91IGhhdmUgYSBzZXQgb2YgaG9zdHMNCjxIMCwgSDEsIOKApkhu PiBhbG9uZyBhIHBhdGggYW5kIGEgc2V0IG9mIGRlbGF5cyA8ZFQxLCBkVDIsIOKApmRUbj4gb2J0 YWluZWQNCmJ5ICpkaWZmZXJlbnQqIHByb2JlcyAodGh1cyBhc3luY2hyb25vdXMuLi4pIGlzIHRv byBuYcOvdmUgdG8gc2F5IHRoYXQNCnRoZSBkZWxheeKAmXMgc3VtIGlzIGEgZ29vZCByZXByZXNl bnRhdGlvbiBvZiB0aGUgc2luZ2xldG9uIG9uZS13YXktZGVsYXkNCm9uIHRoZSBwYXRoLiBUaGUg cGF0aCBkZWxheSBhbmQgaXRzIHBhcnRpdGlvbmluZyBpbiB0aGUgZGlmZmVyZW50DQpwb3J0aW9u cyBjb3VsZCBvZiBjb3Vyc2UgYmUgb2J0YWluZWQgaWYgd2UgaGFkIGEgdHJhamVjdG9yeSBtZXRy aWMsDQp3aGljaCBpcyBhIGdvb2QgdGhpbmcgYnV0IGlzIG5vdCBnaXZlbiBieSBhbnkgY3VycmVu dGx5IHdpZGVseSBkZXBsb3llZA0KbWVhc3VyZW1lbnQgcHJvdG9jb2wuDQoNClNvLCBpdCBsb29r cyBsaWtlIHRoZSBJUFBNIFdHIHByZWZlcnJlZCBqdXN0IHRvIHByZXBhcmUgdGhlIGNvbnRhaW5l cg0KZm9yIHNvbWV0aGluZyB0aGF0IGl0IGlzIHN0aWxsIHRvIGNvbWUgYW5kIG5vdCB0byBzYXkg YW55dGhpbmcgYWJvdXQgaG93DQp0byBjb21wb3NlIGV4aXN0aW5nIG1ldHJpYy4gV2hhdCBJIHRo aW5rIHdvdWxkIGJlIHVzZWZ1bCBpcyBnaXZpbmcNCmd1aWRlbGluZXMgYWJvdXQgdGhlIGNvbXBv c2l0aW9uIG9mIG1ldHJpYyAqc3RhdGlzdGljcyogKGUuZy4gdGhlIG1lYW4NCi0+IHRyaXZpYWwg LSB0aGUgdmFyaWFuY2Ugb3IgdGhlIHBlcmNlbnRpbGVzIC0+IG5vdCB0cml2aWFsIGJlY2F1c2Ug dGhlDQppbmRlcGVuZGVuY2Ugb24gdGhlIHNldmVyYWwgcGF0aCBwb3J0aW9ucyBjb21lcyBpbnRv IHBsYXkpLiBJIGtub3cgdGhhdA0KdGVzdGluZyBzdWNoIGFuIGluZGVwZW5kZW5jZSBoeXBvdGhl c2lzIGlzIGRpZmZpY3VsdCBvciBpbXBvc3NpYmxlLCBpcw0KaXQgYSByZWFzb24gZm9yIG5vdCBz YXlpbmcgYW55dGhpbmcgYWJvdXQgaG93IHRvIGNvbXBvc2UgbWV0cmljDQpzdGF0aXN0aWNzICh3 aGljaCBpcyBzb21ldGhpbmcgdGhhdCBvcGVyYXRvcnMgd291bGQgbGlrZSB0byBkbyk/Lg0KRnVy dGhlcm1vcmUsIGluIHRoZSBmb3VydGggYnVsbGV0IHBvaW50IG9mIFJGQyAyMzMwIHRoZXJlIHdh cyBleGFjdGx5DQp0aGUgc3RhdGVtZW50IHRoYXQgdGhlIHNwZWNpZmljYXRpb24gb2YgdGhlIGNv bXBvc2l0aW9uIHdvdWxkIGNvbWUgYWxvbmcNCndpdGggc29tZSByZWFzb25pbmcgYWJvdXQgaXRz IGNvcnJlY3RuZXNzIChzZWUgYmVsb3cpLg0KQXBvbG9naWVzIGlmIEknbSByYWlzaW5nIGEgcG9p bnQgdGhhdCBoYXMgYWxyZWFkeSBiZWVuIGRpc2N1c3NlZCBhbmQNCmJ1cmllZCBpbiB0ZSBXRy4g SW4gdGhpcyBjYXNlLCBJJ2QgYXBwcmVjaWF0ZSBwb2ludGVycyB0byBtYWlsIGFyY2hpdmVzLA0K ZXRjLg0KUmVnYXJkcywNCk1hdXJpemlvDQoNClNURVBIQU4gRW1pbGUgUkQtQ09SRS1MQU4gd3Jv dGU6DQoNCj5EZWFyIE1hdXJpemlvDQo+DQo+MiB5ZWFycyBhZ28gSSB0cmllZCB0byBpbnRyb2R1 Y2UgdGhpcyBwb2ludCBpbiB0aGUgSVBQTSBXRywgc2VlDQpodHRwOi8vd3d3LndhdGVyc3ByaW5n cy5vcmcvcHViL2lkL2RyYWZ0LXN0ZXBoYW4taXBwbS1zcGF0aWFsLW1ldHJpY3MtMDEudHh0DQou IFRoaXMgSUQgZGVmaW5lcyBtZXRyaWNzIGZvciBzcGF0aWFsIGNvbXBvc2l0aW9uIGFuZCBzcGF0 aWFsDQpkZWNvbXBvc2l0aW9uLiBUaGlzIHBvaW50IHdhcyBwcmVzZW50ZWQgYW5kIGRpc2N1c3Nl ZCBpbiB0aGUgSVBQTSBXRy4NCj5NeSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBJUFBNIFdHIGNvbmNs dXNpb24gaXMgdGhhdCBpdCBpcyBxdWl0ZSB0cmlja3kgdG8NCmRlZmluZSBjb21wb3NpdGlvbiBt ZXRyaWNzIHJlc3BlY3RmdWwgb2YgdGhlIFJGQzIzMzAgYmVjYXVzZSBpdCBpcyBwb3NzaWJsZQ0K dG8gcHJvdmUgdGhhdCBzdWNoIGNvbXBvc2l0aW9uIGlzIG5vdCBkZXRlcm1pbmlzdGljLg0KPg0K PkNvbnNlcXVlbnRseSBMZWkgYW5kIEkgYXJlIGZvY3VzaW5nIG9uIHRoZSBkZWZpbml0aW9uIG9m IHNwYXRpYWwgbWV0cmljcw0KdG8gZGVjb21wb3NlIGVuZC10by1lbmQgbWVhc3VyZXMgYW5kIG9u ZS10by1ncm91cCBtZXRyaWNzIGluDQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1zdGVwaGFuLWlwcG0tbXVsdGltZXRyaWNzLTAwLnR4dC4NCg0KPg0KPg0KPlJlZ2Fy ZHMNCj5FbWlsZQ0KPg0KPg0KPg0KPj4tLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4+RGUg OiBpcHBtLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzppcHBtLWJvdW5jZXNAaWV0Zi5vcmddIERl IGxhIHBhcnQgZGUNCj4+TWF1cml6aW8gTW9saW5hDQo+PkVudm95w6kgOiBtZXJjcmVkaSAxIGp1 aW4gMjAwNSAyMDo0Nw0KPj7DgCA6IGlwcG1AaWV0Zi5vcmcNCj4+T2JqZXQgOiBbaXBwbV0gQ29t cG9zaXRpb24gb2YgTWV0cmljcw0KPj4NCj4+RGVhciBhbGwsDQo+PkluIFJGQyAyMzMwIChGcmFt ZXdvcmsgZm9yIElQIFBlcmZvcm1hbmNlIE1ldHJpY3MpLCB0aGUgU3BhdGlhbCBhbmQNCj4+dGVt cG9yYWwgY29tcG9zaXRpb24gb2YgbWV0cmljcyBpcyBkZWZpbmVkIChzZWUgZXh0cmFjdCBiZWxv dykuDQo+Pkhvd2V2ZXIsIGluIG5vbmUgb2YgdGhlIFJGQ3MgZGVmaW5pbmcgdGhlIG1ldHJpY3Mg dGhlIHByb2JsZW0gYXBwZWFycyB0bw0KPj5iZSB0YWNrbGVkLiBDb3VsZCBzb21lYm9keSBjbGFy aWZ5IG1lIGlmIHRoZXJlIGlzIGEgcmVhc29uIHdoeSB0aGlzDQo+PnBpZWNlIG9mIHdvcmsgaGFz IG5vdCBiZWVuIHVuZGVydGFrZW4/DQo+PlRoYW5rcywNCj4+TWF1cml6aW8NCj4+DQo+Pg0KPj45 LjEuIFNwYXRpYWwgQ29tcG9zaXRpb24gb2YgTWV0cmljcw0KPj4uLi4uLg0KPj4gICBXaGVuIHRo ZSBkZWZpbml0aW9uIG9mIGEgbWV0cmljIGluY2x1ZGVzIGEgY29uamVjdHVyZSB0aGF0IHRoZSBt ZXRyaWMNCj4+ICAgYWNyb3NzIHRoZSBwYXRoIGlzIHJlbGF0ZWQgdG8gdGhlIG1ldHJpYyBhY3Jv c3MgdGhlIHN1YnBhdGhzIG9mIHRoZQ0KPj4gICBwYXRoLCB0aGF0IGNvbmplY3R1cmUgY29uc3Rp dHV0ZXMgYSBjbGFpbSB0aGF0IHRoZSBtZXRyaWMgZXhoaWJpdHMNCj4+ICAgc3BhdGlhbCBjb21w b3NpdGlvbi4gIFRoZSBkZWZpbml0aW9uIHNob3VsZCB0aGVuIGluY2x1ZGU6DQo+PiArICAgIHRo ZSBzcGVjaWZpYyBjb25qZWN0dXJlIGFwcGxpZWQgdG8gdGhlIG1ldHJpYywNCj4+ICsgICAgYSBq dXN0aWZpY2F0aW9uIG9mIHRoZSBwcmFjdGljYWwgdXRpbGl0eSBvZiB0aGUgY29tcG9zaXRpb24g aW4NCj4+ICAgICAgdGVybXMgb2YgbWFraW5nIGFjY3VyYXRlIG1lYXN1cmVtZW50cyBvZiB0aGUg bWV0cmljIG9uIHRoZSBwYXRoLA0KPj4gKyAgICBhIGp1c3RpZmljYXRpb24gb2YgdGhlIHVzZWZ1 bG5lc3Mgb2YgdGhlIGNvbXBvc2l0aW9uIGluIHRlcm1zIG9mDQo+PiAgICAgIG1ha2luZyBhbmFs eXNpcyBvZiB0aGUgcGF0aCB1c2luZyBBLWZyYW1lIGNvbmNlcHRzIG1vcmUgZWZmZWN0aXZlLA0K Pj4gICAgICBhbmQNCj4+ICsgICAgYW4gYW5hbHlzaXMgb2YgaG93IHRoZSBjb25qZWN0dXJlIGNv dWxkIGJlIGluY29ycmVjdC4NCj4+DQo+PjkuMi4gVGVtcG9yYWwgQ29tcG9zaXRpb24gb2YgRm9y bWFsIE1vZGVscyBhbmQgRW1waXJpY2FsIE1ldHJpY3MNCj4+DQo+Pi4uLi4uLg0KPj4NCj4+ICAg V2hlbiB0aGUgZGVmaW5pdGlvbiBvZiBhIG1ldHJpYyBpbmNsdWRlcyBhIGNvbmplY3R1cmUgdGhh dCB0aGUgbWV0cmljDQo+PiAgIGFjcm9zcyB0aGUgcGF0aCBhdCBhIGdpdmVuIHRpbWUgVCBpcyBy ZWxhdGVkIHRvIHRoZSBtZXRyaWMgYWNyb3NzIHRoZQ0KPj4gICBwYXRoIGZvciBhIHNldCBvZiBv dGhlciB0aW1lcywgdGhhdCBjb25qZWN0dXJlIGNvbnN0aXR1dGVzIGEgY2xhaW0NCj4+ICAgdGhh dCB0aGUgbWV0cmljIGV4aGliaXRzIHRlbXBvcmFsIGNvbXBvc2l0aW9uLiAgVGhlIGRlZmluaXRp b24gc2hvdWxkDQo+PiAgIHRoZW4gaW5jbHVkZToNCj4+DQo+PiArICAgIHRoZSBzcGVjaWZpYyBj b25qZWN0dXJlIGFwcGxpZWQgdG8gdGhlIG1ldHJpYywNCj4+ICsgICAgYSBqdXN0aWZpY2F0aW9u IG9mIHRoZSBwcmFjdGljYWwgdXRpbGl0eSBvZiB0aGUgY29tcG9zaXRpb24gaW4NCj4+ICAgICAg dGVybXMgb2YgbWFraW5nIGFjY3VyYXRlIG1lYXN1cmVtZW50cyBvZiB0aGUgbWV0cmljIG9uIHRo ZSBwYXRoLA0KPj4gICAgICBhbmQNCj4+ICsgICAgYSBqdXN0aWZpY2F0aW9uIG9mIHRoZSB1c2Vm dWxuZXNzIG9mIHRoZSBjb21wb3NpdGlvbiBpbiB0ZXJtcyBvZg0KPj4gICAgICBtYWtpbmcgYW5h bHlzaXMgb2YgdGhlIHBhdGggdXNpbmcgQS1mcmFtZSBjb25jZXB0cyBtb3JlIGVmZmVjdGl2ZS4N Cj4+DQo+Pg0KPj4NCj4+DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+PmlwcG0gbWFpbGluZyBsaXN0DQo+PmlwcG1AaWV0Zi5vcmcNCj4+aHR0cHM6 Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBwbQ0KPj4NCj4NCj4NCj4NCg0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQppcHBtIG1h aWxpbmcgbGlzdA0KaXBwbUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaXBwbQ0KDQoNCg== --===============1689756869== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --===============1689756869==-- From ippm-bounces@ietf.org Thu Jun 09 14:25:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgRiQ-0006Fd-EA; Thu, 09 Jun 2005 14:25:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgRfV-0005xF-Cb; Thu, 09 Jun 2005 14:22:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00909; Thu, 9 Jun 2005 14:22:15 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgS10-00013x-Pt; Thu, 09 Jun 2005 14:44:31 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 09 Jun 2005 14:22:07 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j59ILZ5E007020; Thu, 9 Jun 2005 14:22:03 -0400 (EDT) Received: from xmb-rtp-201.amer.cisco.com ([64.102.31.13]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Jun 2005 14:22:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ippm] Composition of Metrics Date: Thu, 9 Jun 2005 14:21:58 -0400 Message-ID: <9EF3C46DC5D14D44B218FD5E93786CA24BA963@xmb-rtp-201.amer.cisco.com> Thread-Topic: [ippm] Composition of Metrics Thread-Index: AcVtHcRL12P2Sw5jRwWgNJtYpqOYKwAAbnEA From: "Robert Holley \(rholley\)" To: , "Maurizio Molina" X-OriginalArrivalTime: 09 Jun 2005 18:22:02.0783 (UTC) FILETIME=[2210BAF0:01C56D20] X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 09 Jun 2005 14:25:16 -0400 Cc: GN-JRA1-list , ippm@ietf.org, STEPHAN Emile RD-CORE-LAN , Lei Liang , ippm-bounces@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Roman, It seems like three (3) is a special case of two (2). But I agree that this work should be done. Regards Bob=20 > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On=20 > Behalf Of roman.krzanowski@verizon.com > Sent: Thursday, June 09, 2005 1:54 PM > To: Maurizio Molina > Cc: ippm-bounces@ietf.org; Lei Liang; ippm@ietf.org; STEPHAN=20 > Emile RD-CORE-LAN; GN-JRA1-list > Subject: Re: [ippm] Composition of Metrics >=20 >=20 >=20 >=20 >=20 > the composition of metrics is on everybody's mind ( a trivial=20 > statement) > and I guess the solution is elusive. > I have seen two broad approaches or maybe three > (1) Cannot be done and violates all known physical and=20 > mathematical laws. > (2) must be done and any reasonable method we agree on will do > (3) some approximation to the end to end performance from sub-segments > metrics for practical purposes can be achieved using > addition ( latency), probability based( packet loss)=20 > aggregates that, while > inaccurate, from the SP perspective will do. >=20 > I am somehow leaning towards the option (3). There is in my=20 > view an absence > of hard guidelines how to do the recombination > but I guess there is plenty of pragmatic approaches=20 > implemented or used. > And considering the nature of the problem > pragmatic appoach is the best we can do. To this point, maybe=20 > under IPPM > WG we should develop the document > with requirements and a summary of pragmatic solutions from=20 > different SPs. > In my view such a document would certainly help all of us=20 > involved to focus > on some best practices or methods > roman k >=20 >=20 >=20 >=20 > =20 > =20 > "Maurizio Molina" =20 > =20 > "STEPHAN Emile RD-CORE-LAN" , =20 > nte.org.uk> =20 > ippm@ietf.org =20 > =20 > Sent by: cc: =20 > "Lei Liang" , "GN-JRA1-list" =20 > ippm-bounces@ietf.o =20 > =20 > =20 > rg Subject: =20 > Re: [ippm] Composition of Metrics =20 > =20 > =20 > =20 > =20 > 06/09/2005 12:21 PM =20 > =20 > =20 > =20 > =20 > =20 >=20 >=20 >=20 >=20 > Hi Emile, >=20 > I compared your two drafts, and summarizing I would say (correct me if > I'm wrong) that: >=20 > 1) Type-P-METRIC-XX-trajectory in the old draft corresponds to the > Type-P-METRIC-stream in the new one. >=20 > 2) The new draft contains the one-to-group metrics >=20 > 3) The asynchronous metrics were ruled out. >=20 > Regarding the last point, I understand that if you have a set of hosts > along a path and a set of delays ...dTn> obtained > by *different* probes (thus asynchronous...) is too na=EFve to say = that > the delay's sum is a good representation of the singleton=20 > one-way-delay > on the path. The path delay and its partitioning in the different > portions could of course be obtained if we had a trajectory metric, > which is a good thing but is not given by any currently=20 > widely deployed > measurement protocol. >=20 > So, it looks like the IPPM WG preferred just to prepare the container > for something that it is still to come and not to say=20 > anything about how > to compose existing metric. What I think would be useful is giving > guidelines about the composition of metric *statistics* (e.g. the mean > -> trivial - the variance or the percentiles -> not trivial=20 > because the > independence on the several path portions comes into play). I=20 > know that > testing such an independence hypothesis is difficult or impossible, is > it a reason for not saying anything about how to compose metric > statistics (which is something that operators would like to do)?. > Furthermore, in the fourth bullet point of RFC 2330 there was exactly > the statement that the specification of the composition would=20 > come along > with some reasoning about its correctness (see below). > Apologies if I'm raising a point that has already been discussed and > buried in te WG. In this case, I'd appreciate pointers to=20 > mail archives, > etc. > Regards, > Maurizio >=20 > STEPHAN Emile RD-CORE-LAN wrote: >=20 > >Dear Maurizio > > > >2 years ago I tried to introduce this point in the IPPM WG, see > http://www.watersprings.org/pub/id/draft-stephan-ippm-spatial- > metrics-01.txt > . This ID defines metrics for spatial composition and spatial > decomposition. This point was presented and discussed in the IPPM WG. > >My understanding of the IPPM WG conclusion is that it is=20 > quite tricky to > define composition metrics respectful of the RFC2330 because=20 > it is possible > to prove that such composition is not deterministic. > > > >Consequently Lei and I are focusing on the definition of=20 > spatial metrics > to decompose end-to-end measures and one-to-group metrics in > http://www.ietf.org/internet-drafts/draft-stephan-ippm-multime > trics-00.txt. >=20 > > > > > >Regards > >Emile > > > > > > > >>-----Message d'origine----- > >>De : ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org]=20 > De la part de > >>Maurizio Molina > >>Envoy=E9 : mercredi 1 juin 2005 20:47 > >>=C0 : ippm@ietf.org > >>Objet : [ippm] Composition of Metrics > >> > >>Dear all, > >>In RFC 2330 (Framework for IP Performance Metrics), the Spatial and > >>temporal composition of metrics is defined (see extract below). > >>However, in none of the RFCs defining the metrics the=20 > problem appears to > >>be tackled. Could somebody clarify me if there is a reason why this > >>piece of work has not been undertaken? > >>Thanks, > >>Maurizio > >> > >> > >>9.1. Spatial Composition of Metrics > >>..... > >> When the definition of a metric includes a conjecture=20 > that the metric > >> across the path is related to the metric across the=20 > subpaths of the > >> path, that conjecture constitutes a claim that the=20 > metric exhibits > >> spatial composition. The definition should then include: > >> + the specific conjecture applied to the metric, > >> + a justification of the practical utility of the composition in > >> terms of making accurate measurements of the metric=20 > on the path, > >> + a justification of the usefulness of the composition=20 > in terms of > >> making analysis of the path using A-frame concepts=20 > more effective, > >> and > >> + an analysis of how the conjecture could be incorrect. > >> > >>9.2. Temporal Composition of Formal Models and Empirical Metrics > >> > >>...... > >> > >> When the definition of a metric includes a conjecture=20 > that the metric > >> across the path at a given time T is related to the=20 > metric across the > >> path for a set of other times, that conjecture=20 > constitutes a claim > >> that the metric exhibits temporal composition. The=20 > definition should > >> then include: > >> > >> + the specific conjecture applied to the metric, > >> + a justification of the practical utility of the composition in > >> terms of making accurate measurements of the metric=20 > on the path, > >> and > >> + a justification of the usefulness of the composition=20 > in terms of > >> making analysis of the path using A-frame concepts=20 > more effective. > >> > >> > >> > >> > >>_______________________________________________ > >>ippm mailing list > >>ippm@ietf.org > >>https://www1.ietf.org/mailman/listinfo/ippm > >> > > > > > > >=20 >=20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www1.ietf.org/mailman/listinfo/ippm >=20 >=20 >=20 _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Fri Jun 10 08:44:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgisF-00042z-BS; Fri, 10 Jun 2005 08:44:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgisA-00042R-20 for ippm@megatron.ietf.org; Fri, 10 Jun 2005 08:44:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16223 for ; Fri, 10 Jun 2005 08:44:27 -0400 (EDT) Received: from mail131.messagelabs.com ([216.82.242.99]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DgjDh-0002y2-0x for ippm@ietf.org; Fri, 10 Jun 2005 09:06:53 -0400 X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-15.tower-131.messagelabs.com!1118407449!2359982!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.166.71] Received: (qmail 9772 invoked from network); 10 Jun 2005 12:44:09 -0000 Received: from almso2.att.com (HELO almso2.proxy.att.com) (192.128.166.71) by server-15.tower-131.messagelabs.com with SMTP; 10 Jun 2005 12:44:09 -0000 Received: from attrh2i.attrh.att.com ([135.37.94.56]) by almso2.proxy.att.com (AT&T IPNS/MLO-6.0) with ESMTP id j5AChaoo008365 for ; Fri, 10 Jun 2005 08:44:09 -0400 Received: from custsla.mt.att.com (135.21.14.109) by attrh2i.attrh.att.com (7.2.052) id 4287736F005416DA; Fri, 10 Jun 2005 08:44:09 -0400 Received: from acmortonw.att.com ([135.25.189.16]) by custsla.mt.att.com (8.10.2+Sun/8.10.2) with ESMTP id j5ACi7Z21058; Fri, 10 Jun 2005 08:44:07 -0400 (EDT) Message-Id: <6.0.3.0.0.20050610081122.05c61a60@custsla.mt.att.com> X-Sender: acm@custsla.mt.att.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Fri, 10 Jun 2005 08:42:22 -0400 To: "Robert Holley \(rholley\)" , , "Maurizio Molina" From: Al Morton Subject: RE: [ippm] Composition of Metrics In-Reply-To: <9EF3C46DC5D14D44B218FD5E93786CA24BA963@xmb-rtp-201.amer.ci sco.com> References: <9EF3C46DC5D14D44B218FD5E93786CA24BA963@xmb-rtp-201.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org At 02:21 PM 06/09/2005, Robert Holley \(rholley\) wrote: >It seems like three (3) is a special case of two (2). > >But I agree that this work should be done. As Roman alluded, there is some work in progress. I mentioned ITU-T work in my talk at IETF-62, it's much along the lines of (2) and (3). One of the areas investigated there: what summary of the sample metrics collected on each path segment will produce a decent estimate of e2e path? I would encourage discussion of the topic here, because there will likely be benefit derived from IPPM's collective expertise. From the start, we should recognize the tension between accuracy and practicality (as always), and folks who need to combine metrics need to be clear about the degree of inaccuracy they can live with. In the spirit of contribution, I promise to summarize what I've added/seen so far, in ID or slide-ware form. (astonished that I've added another item to my ToDo list), Al _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Fri Jun 10 08:57:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgj4U-0006uM-HY; Fri, 10 Jun 2005 08:57:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgj4O-0006tw-3u for ippm@megatron.ietf.org; Fri, 10 Jun 2005 08:57:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17094 for ; Fri, 10 Jun 2005 08:57:06 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgjQ0-00051V-7b for ippm@ietf.org; Fri, 10 Jun 2005 09:19:31 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Jun 2005 14:56:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ippm] Composition of Metrics Date: Fri, 10 Jun 2005 14:56:44 +0200 Message-ID: Thread-Topic: [ippm] Composition of Metrics Thread-Index: AcVtHElGfpjdF5gWQW+uCxbxuFSbGAAeyzeA From: "STEPHAN Emile RD-CORE-LAN" To: X-OriginalArrivalTime: 10 Jun 2005 12:56:45.0257 (UTC) FILETIME=[DB205B90:01C56DBB] X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Content-Transfer-Encoding: quoted-printable Cc: Lei Liang , ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Dear Roman, In the draft = http://www.ietf.org/internet-drafts/draft-stephan-ippm-multimetrics-00.tx= t we define the decomposition of an end to end metrics. It satisfies the = point(3) because the result of a decomposition over one path give the = performance of a sub-segment and consequently may be used to compute an = approximation of the end to end performance of another path.=20 So I agree with your proposal. Nevertheless the main issue of = composition will be to define what is accurate enough to be usable. Regards Emile > -----Message d'origine----- > De=A0: roman.krzanowski@verizon.com = [mailto:roman.krzanowski@verizon.com] > Envoy=E9=A0: jeudi 9 juin 2005 19:54 > =C0=A0: Maurizio Molina > Cc=A0: STEPHAN Emile RD-CORE-LAN; GN-JRA1-list; ippm@ietf.org; ippm- > bounces@ietf.org; Lei Liang > Objet=A0: Re: [ippm] Composition of Metrics >=20 >=20 >=20 >=20 >=20 > the composition of metrics is on everybody's mind ( a trivial = statement) > and I guess the solution is elusive. > I have seen two broad approaches or maybe three > (1) Cannot be done and violates all known physical and mathematical = laws. > (2) must be done and any reasonable method we agree on will do > (3) some approximation to the end to end performance from sub-segments > metrics for practical purposes can be achieved using > addition ( latency), probability based( packet loss) aggregates that, > while > inaccurate, from the SP perspective will do. >=20 > I am somehow leaning towards the option (3). There is in my view an > absence > of hard guidelines how to do the recombination > but I guess there is plenty of pragmatic approaches implemented or = used. > And considering the nature of the problem > pragmatic appoach is the best we can do. To this point, maybe under = IPPM > WG we should develop the document > with requirements and a summary of pragmatic solutions from different = SPs. > In my view such a document would certainly help all of us involved to > focus > on some best practices or methods > roman k >=20 >=20 >=20 >=20 >=20 > "Maurizio Molina" > RD-CORE-LAN" , > nte.org.uk> ippm@ietf.org > Sent by: cc: "Lei Liang" > , "GN-JRA1-list" > ippm-bounces@ietf.o = > rg Subject: Re: [ippm] > Composition of Metrics >=20 >=20 > 06/09/2005 12:21 PM >=20 >=20 >=20 >=20 >=20 >=20 > Hi Emile, >=20 > I compared your two drafts, and summarizing I would say (correct me if > I'm wrong) that: >=20 > 1) Type-P-METRIC-XX-trajectory in the old draft corresponds to the > Type-P-METRIC-stream in the new one. >=20 > 2) The new draft contains the one-to-group metrics >=20 > 3) The asynchronous metrics were ruled out. >=20 > Regarding the last point, I understand that if you have a set of hosts > along a path and a set of delays = obtained > by *different* probes (thus asynchronous...) is too na=EFve to say = that > the delay's sum is a good representation of the singleton = one-way-delay > on the path. The path delay and its partitioning in the different > portions could of course be obtained if we had a trajectory metric, > which is a good thing but is not given by any currently widely = deployed > measurement protocol. >=20 > So, it looks like the IPPM WG preferred just to prepare the container > for something that it is still to come and not to say anything about = how > to compose existing metric. What I think would be useful is giving > guidelines about the composition of metric *statistics* (e.g. the mean > -> trivial - the variance or the percentiles -> not trivial because = the > independence on the several path portions comes into play). I know = that > testing such an independence hypothesis is difficult or impossible, is > it a reason for not saying anything about how to compose metric > statistics (which is something that operators would like to do)?. > Furthermore, in the fourth bullet point of RFC 2330 there was exactly > the statement that the specification of the composition would come = along > with some reasoning about its correctness (see below). > Apologies if I'm raising a point that has already been discussed and > buried in te WG. In this case, I'd appreciate pointers to mail = archives, > etc. > Regards, > Maurizio >=20 > STEPHAN Emile RD-CORE-LAN wrote: >=20 > >Dear Maurizio > > > >2 years ago I tried to introduce this point in the IPPM WG, see > http://www.watersprings.org/pub/id/draft-stephan-ippm-spatial-metrics- > 01.txt > . This ID defines metrics for spatial composition and spatial > decomposition. This point was presented and discussed in the IPPM WG. > >My understanding of the IPPM WG conclusion is that it is quite tricky = to > define composition metrics respectful of the RFC2330 because it is > possible > to prove that such composition is not deterministic. > > > >Consequently Lei and I are focusing on the definition of spatial = metrics > to decompose end-to-end measures and one-to-group metrics in > = http://www.ietf.org/internet-drafts/draft-stephan-ippm-multimetrics-00.tx= t. >=20 > > > > > >Regards > >Emile > > > > > > > >>-----Message d'origine----- > >>De : ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] De la part = de > >>Maurizio Molina > >>Envoy=E9 : mercredi 1 juin 2005 20:47 > >>=C0 : ippm@ietf.org > >>Objet : [ippm] Composition of Metrics > >> > >>Dear all, > >>In RFC 2330 (Framework for IP Performance Metrics), the Spatial and > >>temporal composition of metrics is defined (see extract below). > >>However, in none of the RFCs defining the metrics the problem = appears to > >>be tackled. Could somebody clarify me if there is a reason why this > >>piece of work has not been undertaken? > >>Thanks, > >>Maurizio > >> > >> > >>9.1. Spatial Composition of Metrics > >>..... > >> When the definition of a metric includes a conjecture that the = metric > >> across the path is related to the metric across the subpaths of = the > >> path, that conjecture constitutes a claim that the metric = exhibits > >> spatial composition. The definition should then include: > >> + the specific conjecture applied to the metric, > >> + a justification of the practical utility of the composition in > >> terms of making accurate measurements of the metric on the = path, > >> + a justification of the usefulness of the composition in terms = of > >> making analysis of the path using A-frame concepts more = effective, > >> and > >> + an analysis of how the conjecture could be incorrect. > >> > >>9.2. Temporal Composition of Formal Models and Empirical Metrics > >> > >>...... > >> > >> When the definition of a metric includes a conjecture that the = metric > >> across the path at a given time T is related to the metric across = the > >> path for a set of other times, that conjecture constitutes a = claim > >> that the metric exhibits temporal composition. The definition = should > >> then include: > >> > >> + the specific conjecture applied to the metric, > >> + a justification of the practical utility of the composition in > >> terms of making accurate measurements of the metric on the = path, > >> and > >> + a justification of the usefulness of the composition in terms = of > >> making analysis of the path using A-frame concepts more = effective. > >> > >> > >> > >> > >>_______________________________________________ > >>ippm mailing list > >>ippm@ietf.org > >>https://www1.ietf.org/mailman/listinfo/ippm > >> > > > > > > >=20 >=20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www1.ietf.org/mailman/listinfo/ippm >=20 _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Fri Jun 10 10:48:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgkns-0005or-Jh; Fri, 10 Jun 2005 10:48:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgknr-0005nk-1D for ippm@megatron.ietf.org; Fri, 10 Jun 2005 10:48:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26904 for ; Fri, 10 Jun 2005 10:48:08 -0400 (EDT) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgl9W-0001d8-3m for ippm@ietf.org; Fri, 10 Jun 2005 11:10:35 -0400 Received: by postman.ripe.net (Postfix, from userid 4008) id A1D5B24A18; Fri, 10 Jun 2005 16:47:51 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id B52F5249CF for ; Fri, 10 Jun 2005 16:47:50 +0200 (CEST) Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id j5AElnUV015495 for ; Fri, 10 Jun 2005 16:47:50 +0200 Message-Id: <6.2.1.2.2.20050610164734.02cca9b0@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 10 Jun 2005 16:47:47 +0200 To: ippm@ietf.org From: Henk Uijterwaal Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.003589 / -5.9 X-RIPE-Signature: 1c158c8b1f45a8fad8b77e2699c3e79c X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Subject: [ippm] Fwd: Internet Draft submission Cutoff Dates X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org > >FYI. > > >>Date: Fri, 10 Jun 2005 00:00:01 -0400 >>From: ietf-secretariat@ietf.org >>To: ietf-announce@ietf.org >>Subject: Internet-Drafts Submission Cutoff Dates for the 63rd IETF >>Meeting in P >> aris, France >> >> >>There are two (2) Internet-Draft cutoff dates for the 63rd >>IETF Meeting in Paris, France: >> >>July 11th: Cutoff Date for Initial (i.e., version -00) >>Internet-Draft Submissions >> >>All initial Internet-Drafts (version -00) must be submitted by Monday, >>July 11th at 9:00 AM ET. As always, all initial submissions with a >>filename beginning with "draft-ietf" must be approved by the >>appropriate WG Chair before they can be processed or announced. The >>Secretariat would appreciate receiving WG Chair approval by Tuesday, >>July 5th at 9:00 AM ET. >> >>July 18th: Cutoff Date for Revised (i.e., version -01 and higher) >>Internet-Draft Submissions >> >>All revised Internet-Drafts (version -01 and higher) must be submitted >>by Monday, July 18th at 9:00 AM ET. >> >>Initial and revised Internet-Drafts received after their respective >>cutoff dates will not be made available in the Internet-Drafts >>directory or announced until on or after Monday, August 1st at 9:00 >>AM ET, when Internet-Draft posting resumes. Please do not wait until >>the last minute to submit. >> >>PLEASE NOTE THE CHANGE OF PROCEDURE: If you submit an initial or >>revised Internet-Draft after their respective cutoff deadlines, then >>your document will be retained and posted when Internet-Draft >>processing resumes. You will no longer be required to resubmit the >>document. >> >>Thank you for your understanding and cooperation. If you have any >>questions or concerns, then please send a message to >>internet-drafts@ietf.org. >> >>The IETF Secretariat >> >>FYI: The Internet-Draft cutoff dates as well as other significant dates >>for the 63rd IETF Meeting can be found at >>http://www.ietf.org/meetings/cutoff_dates_63.html. > > > > >------------------------------------------------------------------------------ >Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net >RIPE Network Coordination Centre http://www.amsterdamned.org/~henk >P.O.Box 10096 Singel 258 Phone: +31.20.5354414 >1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 >The Netherlands The Netherlands Mobile: +31.6.55861746 >------------------------------------------------------------------------------ > >Look here junior, don't you be so happy. >And for Heaven's sake, don't you be so sad. (Tom Verlaine) ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Fri Jun 10 14:20:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgo6w-0001oG-Qz; Fri, 10 Jun 2005 14:20:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgo6o-0001mj-6x for ippm@megatron.ietf.org; Fri, 10 Jun 2005 14:20:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16864 for ; Fri, 10 Jun 2005 14:19:56 -0400 (EDT) Received: from panorama.covad.com ([66.134.72.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgoSW-0008Gl-1n for ippm@ietf.org; Fri, 10 Jun 2005 14:42:24 -0400 Received: from zanxmb00.cc-ntd1.covad.com (zanxmb00.corp.covad.com [172.16.2.119]) by panorama.Covad.COM (8.9.3/8.8.7) with ESMTP id LAA02661; Fri, 10 Jun 2005 11:19:33 -0700 (PDT) Received: from ZANEVS03.cc-ntd1.covad.com ([172.16.2.83]) by zanxmb00.cc-ntd1.covad.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 10 Jun 2005 11:19:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ippm] Composition of Metrics Date: Fri, 10 Jun 2005 11:19:33 -0700 Message-ID: Thread-Topic: [ippm] Composition of Metrics Thread-Index: AcVtHElGfpjdF5gWQW+uCxbxuFSbGAAeyzeAABOQjWA= From: "Fardid, Reza" To: "STEPHAN Emile RD-CORE-LAN" , X-OriginalArrivalTime: 10 Jun 2005 18:19:33.0593 (UTC) FILETIME=[F38DE490:01C56DE8] X-SPAM: 0.00% X-Spam-Score: 0.0 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Content-Transfer-Encoding: quoted-printable Cc: Lei Liang , ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Dear All, SPs already cope with measurement inaccuracies, in particular those = attributed to sampling and coverage.=20 This is useful work to undertake, even if it creates another source of = inaccuracy. Tolerance to inaccuracy depends on a number of interrelated = factors, from an SP perspective, which appear to be out of scope of = IPPM, if I am not mistaken: 1) Use of measurements in network design, SLA management, = troubleshooting; 2) Type of application; 3) Network administrative boundaries, when different segments in the = end-to-end path are controlled by different providers. It will be good to define the sources of (de)composition inaccuracies = for each measurement and leave it up to SPs to decide how best to cope = with them. Regards, Reza Fardid -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of = STEPHAN Emile RD-CORE-LAN Sent: Friday, June 10, 2005 5:57 AM To: roman.krzanowski@verizon.com Cc: Lei Liang; ippm@ietf.org Subject: RE: [ippm] Composition of Metrics Dear Roman, In the draft = http://www.ietf.org/internet-drafts/draft-stephan-ippm-multimetrics-00.tx= t we define the decomposition of an end to end metrics. It satisfies the = point(3) because the result of a decomposition over one path give the = performance of a sub-segment and consequently may be used to compute an = approximation of the end to end performance of another path.=20 So I agree with your proposal. Nevertheless the main issue of = composition will be to define what is accurate enough to be usable. Regards Emile > -----Message d'origine----- > De=A0: roman.krzanowski@verizon.com = [mailto:roman.krzanowski@verizon.com] > Envoy=E9=A0: jeudi 9 juin 2005 19:54 > =C0=A0: Maurizio Molina > Cc=A0: STEPHAN Emile RD-CORE-LAN; GN-JRA1-list; ippm@ietf.org; ippm- > bounces@ietf.org; Lei Liang > Objet=A0: Re: [ippm] Composition of Metrics >=20 >=20 >=20 >=20 >=20 > the composition of metrics is on everybody's mind ( a trivial = statement) > and I guess the solution is elusive. > I have seen two broad approaches or maybe three > (1) Cannot be done and violates all known physical and mathematical = laws. > (2) must be done and any reasonable method we agree on will do > (3) some approximation to the end to end performance from sub-segments > metrics for practical purposes can be achieved using > addition ( latency), probability based( packet loss) aggregates that, > while > inaccurate, from the SP perspective will do. >=20 > I am somehow leaning towards the option (3). There is in my view an > absence > of hard guidelines how to do the recombination > but I guess there is plenty of pragmatic approaches implemented or = used. > And considering the nature of the problem > pragmatic appoach is the best we can do. To this point, maybe under = IPPM > WG we should develop the document > with requirements and a summary of pragmatic solutions from different = SPs. > In my view such a document would certainly help all of us involved to > focus > on some best practices or methods > roman k >=20 >=20 >=20 >=20 >=20 > "Maurizio Molina" > RD-CORE-LAN" , > nte.org.uk> ippm@ietf.org > Sent by: cc: "Lei Liang" > , "GN-JRA1-list" > ippm-bounces@ietf.o = > rg Subject: Re: [ippm] > Composition of Metrics >=20 >=20 > 06/09/2005 12:21 PM >=20 >=20 >=20 >=20 >=20 >=20 > Hi Emile, >=20 > I compared your two drafts, and summarizing I would say (correct me if > I'm wrong) that: >=20 > 1) Type-P-METRIC-XX-trajectory in the old draft corresponds to the > Type-P-METRIC-stream in the new one. >=20 > 2) The new draft contains the one-to-group metrics >=20 > 3) The asynchronous metrics were ruled out. >=20 > Regarding the last point, I understand that if you have a set of hosts > along a path and a set of delays = obtained > by *different* probes (thus asynchronous...) is too na=EFve to say = that > the delay's sum is a good representation of the singleton = one-way-delay > on the path. The path delay and its partitioning in the different > portions could of course be obtained if we had a trajectory metric, > which is a good thing but is not given by any currently widely = deployed > measurement protocol. >=20 > So, it looks like the IPPM WG preferred just to prepare the container > for something that it is still to come and not to say anything about = how > to compose existing metric. What I think would be useful is giving > guidelines about the composition of metric *statistics* (e.g. the mean > -> trivial - the variance or the percentiles -> not trivial because = the > independence on the several path portions comes into play). I know = that > testing such an independence hypothesis is difficult or impossible, is > it a reason for not saying anything about how to compose metric > statistics (which is something that operators would like to do)?. > Furthermore, in the fourth bullet point of RFC 2330 there was exactly > the statement that the specification of the composition would come = along > with some reasoning about its correctness (see below). > Apologies if I'm raising a point that has already been discussed and > buried in te WG. In this case, I'd appreciate pointers to mail = archives, > etc. > Regards, > Maurizio >=20 > STEPHAN Emile RD-CORE-LAN wrote: >=20 > >Dear Maurizio > > > >2 years ago I tried to introduce this point in the IPPM WG, see > = http://www.watersprings.org/pub/id/draft-stephan-ippm-spatial-metrics-01.= txt > . This ID defines metrics for spatial composition and spatial > decomposition. This point was presented and discussed in the IPPM WG. > >My understanding of the IPPM WG conclusion is that it is quite tricky = to > define composition metrics respectful of the RFC2330 because it is > possible > to prove that such composition is not deterministic. > > > >Consequently Lei and I are focusing on the definition of spatial = metrics > to decompose end-to-end measures and one-to-group metrics in > = http://www.ietf.org/internet-drafts/draft-stephan-ippm-multimetrics-00.tx= t. >=20 > > > > > >Regards > >Emile > > > > > > > >>-----Message d'origine----- > >>De : ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] De la part = de > >>Maurizio Molina > >>Envoy=E9 : mercredi 1 juin 2005 20:47 > >>=C0 : ippm@ietf.org > >>Objet : [ippm] Composition of Metrics > >> > >>Dear all, > >>In RFC 2330 (Framework for IP Performance Metrics), the Spatial and > >>temporal composition of metrics is defined (see extract below). > >>However, in none of the RFCs defining the metrics the problem = appears to > >>be tackled. Could somebody clarify me if there is a reason why this > >>piece of work has not been undertaken? > >>Thanks, > >>Maurizio > >> > >> > >>9.1. Spatial Composition of Metrics > >>..... > >> When the definition of a metric includes a conjecture that the = metric > >> across the path is related to the metric across the subpaths of = the > >> path, that conjecture constitutes a claim that the metric = exhibits > >> spatial composition. The definition should then include: > >> + the specific conjecture applied to the metric, > >> + a justification of the practical utility of the composition in > >> terms of making accurate measurements of the metric on the = path, > >> + a justification of the usefulness of the composition in terms = of > >> making analysis of the path using A-frame concepts more = effective, > >> and > >> + an analysis of how the conjecture could be incorrect. > >> > >>9.2. Temporal Composition of Formal Models and Empirical Metrics > >> > >>...... > >> > >> When the definition of a metric includes a conjecture that the = metric > >> across the path at a given time T is related to the metric across = the > >> path for a set of other times, that conjecture constitutes a = claim > >> that the metric exhibits temporal composition. The definition = should > >> then include: > >> > >> + the specific conjecture applied to the metric, > >> + a justification of the practical utility of the composition in > >> terms of making accurate measurements of the metric on the = path, > >> and > >> + a justification of the usefulness of the composition in terms = of > >> making analysis of the path using A-frame concepts more = effective. > >> > >> > >> > >> > >>_______________________________________________ > >>ippm mailing list > >>ippm@ietf.org > >>https://www1.ietf.org/mailman/listinfo/ippm > >> > > > > > > >=20 >=20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www1.ietf.org/mailman/listinfo/ippm >=20 _______________________________________________ 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-bounces@ietf.org Sat Jun 11 12:22:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dh8kH-0001rK-3M; Sat, 11 Jun 2005 12:22:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dh8kG-0001rF-1S for ippm@megatron.ietf.org; Sat, 11 Jun 2005 12:22:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25353 for ; Sat, 11 Jun 2005 12:22:01 -0400 (EDT) From: vze275m9@verizon.net Received: from vms048pub.verizon.net ([206.46.252.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dh960-00008j-Pv for ippm@ietf.org; Sat, 11 Jun 2005 12:44:42 -0400 Received: from [192.168.1.3] ([151.200.121.194]) by vms048.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IHX00GRSHG8BORF@vms048.mailsrvcs.net> for ippm@ietf.org; Sat, 11 Jun 2005 11:21:49 -0500 (CDT) Date: Sat, 11 Jun 2005 12:21:44 -0400 Subject: Re: [ippm] Composition of Metrics In-reply-to: <9EF3C46DC5D14D44B218FD5E93786CA24BA963@xmb-rtp-201.amer.cisco.com> To: ippm@ietf.org Message-id: MIME-version: 1.0 (Apple Message framework v622) X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable References: <9EF3C46DC5D14D44B218FD5E93786CA24BA963@xmb-rtp-201.amer.cisco.com> X-Spam-Score: 0.7 (/) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org I guess my concern is that if you let expediency drive the definitions,=20= you can easily wind up with nonsense. A good example of this is the common "high water mark" metric that you=20= find often in MIBs. The information content that you get from this is=20 not worth the cycles spent on it. How often does it occur? Out of how=20 many samples? etc. etc. Metric composition is difficult because of a number of factors, not the=20= least of which is that often metrics on successive links or in=20 successive networks on an end to end path are not independent. If all=20 you are interested in are means and what you want to know is the mean=20 of a sum of random variables (e.g. end to end delay), then no problem;=20= add the means and that is perfectly valid. If you want to approximate=20= other compositions of metrics, though, you have to understand the best=20= and worst that you can do with your approximation and the limitations=20 (like when it is a reasonable approximation and when it is simply not=20 valid) and doing that is something like work. If the WG is willing to=20 do that work, then I say "wonderful" and let's get busy. If not, then I=20= think that you are not only wasting your time, but at worst producing=20 something seriously misleading. My 2 cents... Regards, Phil Chimento On Jun 9, 2005, at 14:21, Robert Holley (rholley) wrote: > > Roman, > > It seems like three (3) is a special case of two (2). > > But I agree that this work should be done. > > Regards > Bob > >> -----Original Message----- >> From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On >> Behalf Of roman.krzanowski@verizon.com >> Sent: Thursday, June 09, 2005 1:54 PM >> To: Maurizio Molina >> Cc: ippm-bounces@ietf.org; Lei Liang; ippm@ietf.org; STEPHAN >> Emile RD-CORE-LAN; GN-JRA1-list >> Subject: Re: [ippm] Composition of Metrics >> >> >> >> >> >> the composition of metrics is on everybody's mind ( a trivial >> statement) >> and I guess the solution is elusive. >> I have seen two broad approaches or maybe three >> (1) Cannot be done and violates all known physical and >> mathematical laws. >> (2) must be done and any reasonable method we agree on will do >> (3) some approximation to the end to end performance from = sub-segments >> metrics for practical purposes can be achieved using >> addition ( latency), probability based( packet loss) >> aggregates that, while >> inaccurate, from the SP perspective will do. >> >> I am somehow leaning towards the option (3). There is in my >> view an absence >> of hard guidelines how to do the recombination >> but I guess there is plenty of pragmatic approaches >> implemented or used. >> And considering the nature of the problem >> pragmatic appoach is the best we can do. To this point, maybe >> under IPPM >> WG we should develop the document >> with requirements and a summary of pragmatic solutions from >> different SPs. >> In my view such a document would certainly help all of us >> involved to focus >> on some best practices or methods >> roman k >> >> >> >> >> >> >> "Maurizio Molina" >> >> > "STEPHAN Emile RD-CORE-LAN" , >> nte.org.uk> >> ippm@ietf.org >> >> Sent by: cc: >> "Lei Liang" , "GN-JRA1-list" >> ippm-bounces@ietf.o >> >> >> rg Subject: >> Re: [ippm] Composition of Metrics >> >> >> >> >> 06/09/2005 12:21 PM >> >> >> >> >> >> >> >> >> >> Hi Emile, >> >> I compared your two drafts, and summarizing I would say (correct me = if >> I'm wrong) that: >> >> 1) Type-P-METRIC-XX-trajectory in the old draft corresponds to the >> Type-P-METRIC-stream in the new one. >> >> 2) The new draft contains the one-to-group metrics >> >> 3) The asynchronous metrics were ruled out. >> >> Regarding the last point, I understand that if you have a set of = hosts >> along a path and a set of delays > ...dTn> obtained >> by *different* probes (thus asynchronous...) is too na=EFve to say = that >> the delay's sum is a good representation of the singleton >> one-way-delay >> on the path. The path delay and its partitioning in the different >> portions could of course be obtained if we had a trajectory metric, >> which is a good thing but is not given by any currently >> widely deployed >> measurement protocol. >> >> So, it looks like the IPPM WG preferred just to prepare the container >> for something that it is still to come and not to say >> anything about how >> to compose existing metric. What I think would be useful is giving >> guidelines about the composition of metric *statistics* (e.g. the = mean >> -> trivial - the variance or the percentiles -> not trivial >> because the >> independence on the several path portions comes into play). I >> know that >> testing such an independence hypothesis is difficult or impossible, = is >> it a reason for not saying anything about how to compose metric >> statistics (which is something that operators would like to do)?. >> Furthermore, in the fourth bullet point of RFC 2330 there was exactly >> the statement that the specification of the composition would >> come along >> with some reasoning about its correctness (see below). >> Apologies if I'm raising a point that has already been discussed and >> buried in te WG. In this case, I'd appreciate pointers to >> mail archives, >> etc. >> Regards, >> Maurizio >> >> STEPHAN Emile RD-CORE-LAN wrote: >> >>> Dear Maurizio >>> >>> 2 years ago I tried to introduce this point in the IPPM WG, see >> http://www.watersprings.org/pub/id/draft-stephan-ippm-spatial- >> metrics-01.txt >> . This ID defines metrics for spatial composition and spatial >> decomposition. This point was presented and discussed in the IPPM WG. >>> My understanding of the IPPM WG conclusion is that it is >> quite tricky to >> define composition metrics respectful of the RFC2330 because >> it is possible >> to prove that such composition is not deterministic. >>> >>> Consequently Lei and I are focusing on the definition of >> spatial metrics >> to decompose end-to-end measures and one-to-group metrics in >> http://www.ietf.org/internet-drafts/draft-stephan-ippm-multime >> trics-00.txt. >> >>> >>> >>> Regards >>> Emile >>> >>> >>> >>>> -----Message d'origine----- >>>> De : ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] >> De la part de >>>> Maurizio Molina >>>> Envoy=E9 : mercredi 1 juin 2005 20:47 >>>> =C0 : ippm@ietf.org >>>> Objet : [ippm] Composition of Metrics >>>> >>>> Dear all, >>>> In RFC 2330 (Framework for IP Performance Metrics), the Spatial and >>>> temporal composition of metrics is defined (see extract below). >>>> However, in none of the RFCs defining the metrics the >> problem appears to >>>> be tackled. Could somebody clarify me if there is a reason why this >>>> piece of work has not been undertaken? >>>> Thanks, >>>> Maurizio >>>> >>>> >>>> 9.1. Spatial Composition of Metrics >>>> ..... >>>> When the definition of a metric includes a conjecture >> that the metric >>>> across the path is related to the metric across the >> subpaths of the >>>> path, that conjecture constitutes a claim that the >> metric exhibits >>>> spatial composition. The definition should then include: >>>> + the specific conjecture applied to the metric, >>>> + a justification of the practical utility of the composition in >>>> terms of making accurate measurements of the metric >> on the path, >>>> + a justification of the usefulness of the composition >> in terms of >>>> making analysis of the path using A-frame concepts >> more effective, >>>> and >>>> + an analysis of how the conjecture could be incorrect. >>>> >>>> 9.2. Temporal Composition of Formal Models and Empirical Metrics >>>> >>>> ...... >>>> >>>> When the definition of a metric includes a conjecture >> that the metric >>>> across the path at a given time T is related to the >> metric across the >>>> path for a set of other times, that conjecture >> constitutes a claim >>>> that the metric exhibits temporal composition. The >> definition should >>>> then include: >>>> >>>> + the specific conjecture applied to the metric, >>>> + a justification of the practical utility of the composition in >>>> terms of making accurate measurements of the metric >> on the path, >>>> and >>>> + a justification of the usefulness of the composition >> in terms of >>>> making analysis of the path using A-frame concepts >> more effective. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> ippm mailing list >>>> ippm@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ippm >>>> >>> >>> >>> >> >> >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www1.ietf.org/mailman/listinfo/ippm >> >> >> > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www1.ietf.org/mailman/listinfo/ippm > _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Sat Jun 11 17:47:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhDon-00073S-7Z; Sat, 11 Jun 2005 17:47:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhDom-00073N-CT for ippm@megatron.ietf.org; Sat, 11 Jun 2005 17:47:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18136 for ; Sat, 11 Jun 2005 17:47:02 -0400 (EDT) Received: from mail120.messagelabs.com ([216.82.255.211]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DhEAb-00048f-7d for ippm@ietf.org; Sat, 11 Jun 2005 18:09:45 -0400 X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-9.tower-120.messagelabs.com!1118526405!1611995!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [12.20.58.69] Received: (qmail 32682 invoked from network); 11 Jun 2005 21:46:45 -0000 Received: from ckmso1.att.com (HELO ckmso1.proxy.att.com) (12.20.58.69) by server-9.tower-120.messagelabs.com with SMTP; 11 Jun 2005 21:46:45 -0000 Received: from attrh2i.attrh.att.com ([135.37.94.56]) by ckmso1.proxy.att.com (AT&T IPNS/MLO-6.0) with ESMTP id j5BLkW2Y019886 for ; Sat, 11 Jun 2005 17:46:44 -0400 Received: from custsla.mt.att.com (135.21.14.109) by attrh2i.attrh.att.com (7.2.052) id 4287736F00575344; Sat, 11 Jun 2005 17:46:44 -0400 Received: from acmortonw.att.com ([135.210.128.36]) by custsla.mt.att.com (8.10.2+Sun/8.10.2) with ESMTP id j5BLkgZ21797; Sat, 11 Jun 2005 17:46:43 -0400 (EDT) Message-Id: <6.0.3.0.0.20050611172856.02f43bc0@custsla.mt.att.com> X-Sender: acm@custsla.mt.att.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Sat, 11 Jun 2005 17:45:27 -0400 To: vze275m9@verizon.net, ippm@ietf.org From: Al Morton Subject: Re: [ippm] Composition of Metrics In-Reply-To: References: <9EF3C46DC5D14D44B218FD5E93786CA24BA963@xmb-rtp-201.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org At 12:21 PM 06/11/2005, vze275m9@verizon.net wrote: >If all you are interested in are means and what you want to know is the >mean of a sum of random variables (e.g. end to end delay), then no >problem; add the means and that is perfectly valid. If you want to >approximate other compositions of metrics, though, you have to understand >the best and worst that you can do with your approximation and the >limitations (like when it is a reasonable approximation and when it is >simply not valid) and doing that is something like work. If the WG is >willing to do that work, then I say "wonderful" and let's get busy. If >not, then I think that you are not only wasting your time, but at worst >producing something seriously misleading. Well said, Phil. Almost everything we come-up with will be an approximation, and this group can bring considerable scrutiny to bear on the problem, assuming enough active contributors are interested. Each metric will have its own challenges, and any composition method should have a scope/application space. We've heard interest from several people so far... Anyone else? Al _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Jun 13 05:44:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhlUX-0002eL-G6; Mon, 13 Jun 2005 05:44:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhlUV-0002dc-Co for ippm@megatron.ietf.org; Mon, 13 Jun 2005 05:44:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24420 for ; Mon, 13 Jun 2005 05:44:21 -0400 (EDT) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dhlqi-0003qF-Pl for ippm@ietf.org; Mon, 13 Jun 2005 06:07:23 -0400 Received: by postman.ripe.net (Postfix, from userid 4008) id D318024810; Mon, 13 Jun 2005 11:44:05 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id DF52524175; Mon, 13 Jun 2005 11:44:04 +0200 (CEST) Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id j5D9i3UV023396; Mon, 13 Jun 2005 11:44:04 +0200 Message-Id: <6.2.1.2.2.20050613114128.02d1c018@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 13 Jun 2005 11:43:59 +0200 To: Al Morton , vze275m9@verizon.net, ippm@ietf.org From: Henk Uijterwaal Subject: Re: [ippm] Composition of Metrics In-Reply-To: <6.0.3.0.0.20050611172856.02f43bc0@custsla.mt.att.com> References: <9EF3C46DC5D14D44B218FD5E93786CA24BA963@xmb-rtp-201.amer.cisco.com> <6.0.3.0.0.20050611172856.02f43bc0@custsla.mt.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000000 / -5.9 X-RIPE-Signature: 829391acbb8578420827428c416b8d9a X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Matthew J Zekauskas X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Speaking as chair... >We've heard interest from several people so far... Yes, there seems to be interest, so I think we should see if there are sufficient volunteers to work on this. We should also define the scope of this work. So, if you are interested and can spend time on this, drop me a note. I'll also put it on the agenda for Paris, Henk (who has been extremely busy and is neglecting IPPM a bit). ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Jun 13 09:28:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhozO-0006Q9-B5; Mon, 13 Jun 2005 09:28:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhoeS-0002An-Ol; Mon, 13 Jun 2005 09:06:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08664; Mon, 13 Jun 2005 09:06:50 -0400 (EDT) From: roman.krzanowski@verizon.com Received: from irvmail2.verizon.com ([192.76.80.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dhp0g-000448-Uj; Mon, 13 Jun 2005 09:29:54 -0400 Received: from smtpftw.verizon.com (smtpftw.verizon.com [138.83.130.53]) by irvmail2.verizon.com (8.13.3/8.13.3) with ESMTP id j5DD6QR2026072; Mon, 13 Jun 2005 08:06:27 -0500 (EST) Received: from usinftwiccmms01.ent.verizon.com (ftwmms01b.interwan.gte.com [138.83.138.27]) by smtpftw.verizon.com (8.13.3/8.13.3) with ESMTP id j5DD6QHU000871; Mon, 13 Jun 2005 08:06:26 -0500 (EST) Received: from 138.83.34.22 by usinftwiccmms01.ent.verizon.com with ESMTP (SMTP Relay); Mon, 13 Jun 2005 09:05:38 -0400 X-Server-Uuid: 3A6621B7-3263-48CE-B234-243F618F6620 Received: from dwsmtp01.core.verizon.com (dwmail21.interwan.gte.com [138.83.36.17]) by coregate1.verizon.com (8.13.3/8.13.3) with ESMTP id j5DD6GfX009917; Mon, 13 Jun 2005 08:06:17 -0500 (CDT) Subject: Re: [ippm] Composition of Metrics To: "Henk Uijterwaal" X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: Date: Mon, 13 Jun 2005 09:05:42 -0400 X-MIMETrack: Serialize by Router on DWSMTP01/HSVR/Verizon(Release 6.0.2CF2|July 23, 2003) at 06/13/2005 08:06:16 MIME-Version: 1.0 X-WSS-ID: 6EB35B2823862478-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 13 Jun 2005 09:28:29 -0400 Cc: Matthew J Zekauskas , ippm-bounces@ietf.org, vze275m9@verizon.net, Al Morton , ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Henk I would be interested in working on the document... as a part of a team roman krzanowski "Henk Uijterwaal" To: "Al Morton" , vze275m9@verizon.net, ippm@ietf.org Sent by: cc: "Matthew J Zekauskas" ippm-bounces@ietf Subject: Re: [ippm] Composition of Metrics .org 06/13/2005 05:43 AM Speaking as chair... >We've heard interest from several people so far... Yes, there seems to be interest, so I think we should see if there are sufficient volunteers to work on this. We should also define the scope of this work. So, if you are interested and can spend time on this, drop me a note. I'll also put it on the agenda for Paris, Henk (who has been extremely busy and is neglecting IPPM a bit). ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Jun 14 05:34:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Di7ob-0001Qg-GA; Tue, 14 Jun 2005 05:34:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Di7oZ-0001Qb-TB for ippm@megatron.ietf.org; Tue, 14 Jun 2005 05:34:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26323 for ; Tue, 14 Jun 2005 05:34:33 -0400 (EDT) Received: from alpha.dante.org.uk ([193.63.211.19] helo=mail.dante.org.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Di8B2-0005jp-Ie for ippm@ietf.org; Tue, 14 Jun 2005 05:57:48 -0400 Received: from [127.0.0.1] (helo=localhost) by mail.dante.org.uk with esmtp (Exim 4.43) id 1Di7oQ-0002MU-Jg for ippm@ietf.org; Tue, 14 Jun 2005 10:34:26 +0100 Received: from mail.dante.org.uk ([127.0.0.1]) by localhost (alpha [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09010-04 for ; Tue, 14 Jun 2005 10:34:25 +0100 (BST) Received: from [193.63.211.123] (helo=[193.63.211.123]) by mail.dante.org.uk with esmtp (Exim 4.43) id 1Di7oP-0002MR-IW for ippm@ietf.org; Tue, 14 Jun 2005 10:34:25 +0100 Message-ID: <42AEA4A4.4070308@dante.org.uk> Date: Tue, 14 Jun 2005 10:34:28 +0100 From: Maurizio Molina User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ippm@ietf.org Subject: Re: [ippm] Composition of Metrics References: In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at dante.org.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org roman.krzanowski@verizon.com wrote: > > >Henk >I would be interested in working on the document... as a part of a team >roman krzanowski > > So would I... Maurizio Molina > > > "Henk Uijterwaal" > To: "Al Morton" , vze275m9@verizon.net, ippm@ietf.org > Sent by: cc: "Matthew J Zekauskas" > ippm-bounces@ietf Subject: Re: [ippm] Composition of Metrics > .org > > > 06/13/2005 05:43 > AM > > > > > > > >Speaking as chair... > > > >>We've heard interest from several people so far... >> >> > >Yes, there seems to be interest, so I think we should see if there are >sufficient volunteers to work on this. We should also define the scope >of this work. So, if you are interested and can spend time on this, >drop me a note. I'll also put it on the agenda for Paris, > >Henk > >(who has been extremely busy and is neglecting IPPM a bit). > > >------------------------------------------------------------------------------ > >Henk Uijterwaal Email: >henk.uijterwaal(at)ripe.net >RIPE Network Coordination Centre http://www.amsterdamned.org/~henk >P.O.Box 10096 Singel 258 Phone: +31.20.5354414 >1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 >The Netherlands The Netherlands Mobile: +31.6.55861746 >------------------------------------------------------------------------------ > > >Look here junior, don't you be so happy. >And for Heaven's sake, don't you be so sad. (Tom Verlaine) > > >_______________________________________________ >ippm mailing list >ippm@ietf.org >https://www1.ietf.org/mailman/listinfo/ippm > > > > > > >_______________________________________________ >ippm mailing list >ippm@ietf.org >https://www1.ietf.org/mailman/listinfo/ippm > > -- ______________________________________________________________________ Maurizio Molina Network Engineer DANTE - www.dante.net Tel: +44 (0)1223 371 300 Fax: +44 (0)1223 371 371 Email: maurizio.molina@dante.org.uk PGP Key ID: 3FF58D51 City House, 126-130 Hills Road Cambridge CB2 1PQ UK _____________________________________________________________________ _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Jun 14 08:02:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiA7p-0001Po-3P; Tue, 14 Jun 2005 08:02:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiA7n-0001Pf-Cf for ippm@megatron.ietf.org; Tue, 14 Jun 2005 08:02:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07205 for ; Tue, 14 Jun 2005 08:02:34 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiAUF-000426-37 for ippm@ietf.org; Tue, 14 Jun 2005 08:25:49 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Jun 2005 14:00:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ippm] Composition of Metrics Date: Tue, 14 Jun 2005 14:00:23 +0200 Message-ID: Thread-Topic: [ippm] Composition of Metrics Thread-Index: AcVwxNfJblNZzvBMTvuL0/2457rdpwAE7xyw From: "STEPHAN Emile RD-CORE-LAN" To: "Maurizio Molina" , X-OriginalArrivalTime: 14 Jun 2005 12:00:24.0814 (UTC) FILETIME=[A5E0B0E0:01C570D8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Hi all I will contribute too. Regards Emile > -----Message d'origine----- > De=A0: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] De la part = de > Maurizio Molina > Envoy=E9=A0: mardi 14 juin 2005 11:34 > =C0=A0: ippm@ietf.org > Objet=A0: Re: [ippm] Composition of Metrics >=20 > roman.krzanowski@verizon.com wrote: >=20 > > > > > >Henk > >I would be interested in working on the document... as a part of a = team > >roman krzanowski > > > > > So would I... > Maurizio Molina >=20 > > > > > > "Henk Uijterwaal" > > To: "Al Morton" > , vze275m9@verizon.net, ippm@ietf.org > > Sent by: cc: "Matthew J > Zekauskas" > > ippm-bounces@ietf Subject: Re: [ippm] > Composition of Metrics > > .org > > > > > > 06/13/2005 05:43 > > AM > > > > > > > > > > > > > > > >Speaking as chair... > > > > > > > >>We've heard interest from several people so far... > >> > >> > > > >Yes, there seems to be interest, so I think we should see if there = are > >sufficient volunteers to work on this. We should also define the = scope > >of this work. So, if you are interested and can spend time on this, > >drop me a note. I'll also put it on the agenda for Paris, > > > >Henk > > > >(who has been extremely busy and is neglecting IPPM a bit). > > > > > = >------------------------------------------------------------------------= - > ----- > > > >Henk Uijterwaal Email: > >henk.uijterwaal(at)ripe.net > >RIPE Network Coordination Centre > http://www.amsterdamned.org/~henk > >P.O.Box 10096 Singel 258 Phone: +31.20.5354414 > >1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 > >The Netherlands The Netherlands Mobile: +31.6.55861746 > = >------------------------------------------------------------------------= - > ----- > > > > > >Look here junior, don't you be so happy. > >And for Heaven's sake, don't you be so sad. (Tom = Verlaine) > > > > > >_______________________________________________ > >ippm mailing list > >ippm@ietf.org > >https://www1.ietf.org/mailman/listinfo/ippm > > > > > > > > > > > > > >_______________________________________________ > >ippm mailing list > >ippm@ietf.org > >https://www1.ietf.org/mailman/listinfo/ippm > > > > >=20 >=20 > -- > ______________________________________________________________________ >=20 > Maurizio Molina > Network Engineer >=20 > DANTE - www.dante.net >=20 > Tel: +44 (0)1223 371 300 > Fax: +44 (0)1223 371 371 > Email: maurizio.molina@dante.org.uk > PGP Key ID: 3FF58D51 >=20 > City House, 126-130 Hills Road > Cambridge CB2 1PQ > UK > _____________________________________________________________________ >=20 >=20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Jun 14 12:14:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiE2o-0004mV-Vj; Tue, 14 Jun 2005 12:13:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiE2n-0004mO-3U for ippm@megatron.ietf.org; Tue, 14 Jun 2005 12:13:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00936 for ; Tue, 14 Jun 2005 12:13:38 -0400 (EDT) Received: from panorama.covad.com ([66.134.72.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiEPI-0002hi-83 for ippm@ietf.org; Tue, 14 Jun 2005 12:36:57 -0400 Received: from zanxmb00.cc-ntd1.covad.com (zanxmb00.corp.covad.com [172.16.2.119]) by panorama.Covad.COM (8.9.3/8.8.7) with ESMTP id JAA25418; Tue, 14 Jun 2005 09:13:27 -0700 (PDT) Received: from ZANEVS03.cc-ntd1.covad.com ([172.16.2.83]) by zanxmb00.cc-ntd1.covad.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 14 Jun 2005 09:13:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ippm] Composition of Metrics Date: Tue, 14 Jun 2005 09:13:27 -0700 Message-ID: Thread-Topic: [ippm] Composition of Metrics Thread-Index: AcVv/Kf2dgkrkVO0RnufMi1cX06h1wA/upWA From: "Fardid, Reza" To: "Henk Uijterwaal" X-OriginalArrivalTime: 14 Jun 2005 16:13:27.0851 (UTC) FILETIME=[FFAC47B0:01C570FB] X-SPAM: 0.00% X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Cc: ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Henk, I will be interested in contributing, too. Regards, Reza Fardid -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Henk Uijterwaal Sent: Monday, June 13, 2005 2:44 AM To: Al Morton; vze275m9@verizon.net; ippm@ietf.org Cc: Matthew J Zekauskas Subject: Re: [ippm] Composition of Metrics Speaking as chair... >We've heard interest from several people so far... Yes, there seems to be interest, so I think we should see if there are sufficient volunteers to work on this. We should also define the scope of this work. So, if you are interested and can spend time on this, drop me a note. I'll also put it on the agenda for Paris, Henk (who has been extremely busy and is neglecting IPPM a bit). ------------------------------------------------------------------------ ------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------ ------ Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine)=20 _______________________________________________ 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-bounces@ietf.org Thu Jun 16 08:14:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DitG3-0006Gj-Cb; Thu, 16 Jun 2005 08:14:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DitG2-0006Ge-8c for ippm@megatron.ietf.org; Thu, 16 Jun 2005 08:14:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12159 for ; Thu, 16 Jun 2005 08:13:59 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Ditcq-0002DP-7y for ippm@ietf.org; Thu, 16 Jun 2005 08:37:43 -0400 Received: from ads33.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Thu, 16 Jun 2005 13:13:24 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads33.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 13:13:23 +0100 Received: from 131.227.89.181 ([131.227.89.181]) by EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.152]) with Microsoft Exchange Server HTTP-DAV ; Thu, 16 Jun 2005 12:13:21 +0000 Received: from ccsrlt31 by exchange.surrey.ac.uk; 16 Jun 2005 13:13:21 +0100 Subject: Re: [ippm] Composition of Metrics From: Lei Liang To: Henk Uijterwaal In-Reply-To: <6.2.1.2.2.20050613114128.02d1c018@localhost> References: <9EF3C46DC5D14D44B218FD5E93786CA24BA963@xmb-rtp-201.amer.cisco.com> <6.0.3.0.0.20050611172856.02f43bc0@custsla.mt.att.com> <6.2.1.2.2.20050613114128.02d1c018@localhost> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1118924001.2784.0.camel@ccsrlt31.ee.surrey.ac.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 16 Jun 2005 13:13:21 +0100 X-OriginalArrivalTime: 16 Jun 2005 12:13:23.0396 (UTC) FILETIME=[CAC66040:01C5726C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Hi, Henk, I would like to contribute in this topic as well. Best regards, Lei Liang On Mon, 2005-06-13 at 10:43, Henk Uijterwaal wrote: > Speaking as chair... > > >We've heard interest from several people so far... > > Yes, there seems to be interest, so I think we should see if there are > sufficient volunteers to work on this. We should also define the scope > of this work. So, if you are interested and can spend time on this, > drop me a note. I'll also put it on the agenda for Paris, > > Henk > > (who has been extremely busy and is neglecting IPPM a bit). > > > ------------------------------------------------------------------------------ > Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net > RIPE Network Coordination Centre http://www.amsterdamned.org/~henk > P.O.Box 10096 Singel 258 Phone: +31.20.5354414 > 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 > The Netherlands The Netherlands Mobile: +31.6.55861746 > ------------------------------------------------------------------------------ > > Look here junior, don't you be so happy. > And for Heaven's sake, don't you be so sad. (Tom Verlaine) > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Jun 20 00:45:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkE9p-0007XE-Ou; Mon, 20 Jun 2005 00:45:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkE9n-0007X9-2u for ippm@megatron.ietf.org; Mon, 20 Jun 2005 00:45:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01524 for ; Mon, 20 Jun 2005 00:45:07 -0400 (EDT) Received: from eagle.acns.colostate.edu ([129.82.100.90] helo=eagle.colostate.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkEXR-0006JM-6L for ippm@ietf.org; Mon, 20 Jun 2005 01:09:37 -0400 Received: from engr.colostate.edu (goku.engr.colostate.edu [129.82.224.16]) by eagle.colostate.edu (AIX5.1/8.11.6p2/8.11.0) with ESMTP id j5K4j6F1201582 for ; Sun, 19 Jun 2005 22:45:06 -0600 Received: from [129.82.228.219] (prolix.engr.colostate.edu [129.82.228.219]) by engr.colostate.edu (8.11.7p1+Sun/8.11.7) with ESMTP id j5K4j5f07928 for ; Sun, 19 Jun 2005 22:45:05 -0600 (MDT) Message-ID: <42B649D1.2050100@engr.colostate.edu> Date: Sun, 19 Jun 2005 22:45:05 -0600 From: "Nischal M. Piratla" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: ippm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: Subject: [ippm] Query about Reordering Byte Offset X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Al, I am running some simulations to come up with an unbiased outlook for all the metrics out there. Truly, I intend to observe what we can achieve with each metric, and not which one is better than the other. I have a doubt w.r.t Reorder Byte Offset, can you please respond to this query. During 62nd meeting, responding to my question and Mark's follow up remark, you said that the overestimate of buffer-size using Reorder Extent is possible, even in terms of packets. Is this also applicable to Reorder Byte Offset (talking in terms of bytes)? In other terms, can the Byte Offset metric fail (for certain cases) in prediction w.r.t whether reordered packets will be useful in general receiver buffer system with finite limits (sec. 4.4.4)? In addition, I am also trying to store the missing packets in a very large buffer to remove duplicates for IPPM metrics. I was wondering whether you have any other suggestions/scripts that can help me to control this buffer size, especially with huge bursts of losses? Thanks in advance for your responses. Regards, Nischal _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Jun 20 05:54:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkIzI-0001Ju-5K; Mon, 20 Jun 2005 05:54:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkIzG-0001Jo-Gb for ippm@megatron.ietf.org; Mon, 20 Jun 2005 05:54:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10283 for ; Mon, 20 Jun 2005 05:54:35 -0400 (EDT) Received: from cartero1.unavarra.es ([130.206.159.51]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkJMt-0004Fz-18 for ippm@ietf.org; Mon, 20 Jun 2005 06:19:07 -0400 Received: from cartero1.unavarra.es (localhost.localdomain [127.0.0.1]) by localhost.unavarra.es (Postfix) with ESMTP id 4412C19E636 for ; Mon, 20 Jun 2005 11:54:14 +0200 (CEST) Received: from unavarra.es (si.unavarra.es [130.206.166.108]) by cartero1.unavarra.es (Postfix) with ESMTP id 2ABB719E635 for ; Mon, 20 Jun 2005 11:54:14 +0200 (CEST) Received: from s163m108.unavarra.es (mail@s163m108.unavarra.es [130.206.163.108]) by unavarra.es (8.9.3/8.9.1) with ESMTP id LAA21274 for ; Mon, 20 Jun 2005 11:54:13 +0200 (MET DST) Received: from ulisses by s163m108.unavarra.es with local (Exim 3.36 #1 (Debian)) id 1DkIyg-0000wo-00 for ; Mon, 20 Jun 2005 11:54:02 +0200 Date: Mon, 20 Jun 2005 11:54:02 +0200 From: Ulisses To: ippm@ietf.org Message-ID: <20050620095402.GB3246@s163m108.unavarra.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [ippm] Packet Reordering Metric question X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Hello all I have read http://www.ietf.org/internet-drafts/draft-ietf-ippm-reordering-09.txt reading the examples of packet reordering, I'm curious about real-world examples of packet reordering when fifo queues are in use and no packet classification is in use. I have seen that some versions of Juniper do reordering, at least with some versions of the firmware/JunOS when using multiple processors. Currently I'm doing tests and I see reordering (and no loss) in the firsts packets in trains of packets. I would like to diagnose the symptom. comments/suggestions/references? Thanks in advance Ulisses Debian GNU/Linux: a dream come true ----------------------------------------------------------------------------- "Computers are useless. They can only give answers." Pablo Picasso "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Jun 20 23:49:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkZlW-0002KJ-V1; Mon, 20 Jun 2005 23:49:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkZlV-0002IF-C1 for ippm@megatron.ietf.org; Mon, 20 Jun 2005 23:49:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12025 for ; Mon, 20 Jun 2005 23:49:30 -0400 (EDT) Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dka9D-0007Kx-SX for ippm@ietf.org; Tue, 21 Jun 2005 00:14:11 -0400 X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-9.tower-121.messagelabs.com!1119325755!2182981!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.167.69] Received: (qmail 19257 invoked from network); 21 Jun 2005 03:49:15 -0000 Received: from almso1.att.com (HELO almso1.proxy.att.com) (192.128.167.69) by server-9.tower-121.messagelabs.com with SMTP; 21 Jun 2005 03:49:15 -0000 Received: from attrh3i.attrh.att.com ([135.38.62.9]) by almso1.proxy.att.com (AT&T IPNS/MLO-6.0) with ESMTP id j5L3n38P016199 for ; Mon, 20 Jun 2005 23:49:15 -0400 Received: from custsla.mt.att.com (135.21.14.109) by attrh3i.attrh.att.com (7.2.052) id 4290ADDF009FFE0D for ippm@ietf.org; Mon, 20 Jun 2005 23:49:15 -0400 Received: from acmortonw.att.com ([135.210.81.90]) by custsla.mt.att.com (8.10.2+Sun/8.10.2) with ESMTP id j5L3nDZ25934 for ; Mon, 20 Jun 2005 23:49:13 -0400 (EDT) Message-Id: <6.2.1.2.0.20050620134206.02260290@custsla.mt.att.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 20 Jun 2005 23:47:44 -0400 To: ippm@ietf.org From: Al Morton Subject: Re: [ippm] Query about Reordering Byte Offset In-Reply-To: <42B649D1.2050100@engr.colostate.edu> References: <42B649D1.2050100@engr.colostate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org At 12:45 AM 06/20/2005, Nischal M. Piratla wrote: >Al, >I am running some simulations to come up with an unbiased outlook for all >the metrics out there. Truly, I intend to observe what we can achieve with >each metric, and not which one is better than the other. How will you avoid bias in the type of simulations you select and run? >I have a doubt w.r.t Reorder Byte Offset, can you please respond to this >query. >During 62nd meeting, responding to my question and Mark's follow up >remark, you said that the overestimate of buffer-size using Reorder Extent >is possible, even in terms of packets. The draft says that Reordering Extent is a metric giving the distance (in units of arrival positions) between a reordered packet and the associated sequence discontinuity. There is also a comment that this simple distance may over-estimate the storage needed to restore some arrival orders, but more complexity may not be desirable. >Is this also applicable to Reorder Byte Offset (talking in terms of bytes)? >In other terms, can the Byte Offset metric fail (for certain cases) in >prediction w.r.t whether reordered packets will be useful in general >receiver buffer system with finite limits (sec. 4.4.4)? When you read the draft, you'll find that Reordering Byte Offset only sums packet payloads that are qualified by two criteria, and the metric will be successful as far as those criteria are a sufficient description of receiver buffer operation. >In addition, I am also trying to store the missing packets in a very large >buffer to remove duplicates for IPPM metrics. I was wondering whether you >have any other suggestions/scripts that can help me to control this buffer >size, especially with huge bursts of losses? One way is to restrict the size of each sample by collecting measurement results every 5 minutes + waiting time. Measurements on paths exhibiting some "huge bursts" would have only a portion of samples affected, but keep in mind that your scenario is a corner case. The first-order impairment seems to be connectivity. There's not much value in talking about spots on the leaves after someone has clear-cut the forest. Al _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Jun 21 01:04:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkawI-0005Zg-LG; Tue, 21 Jun 2005 01:04:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkawG-0005ZW-Lr for ippm@megatron.ietf.org; Tue, 21 Jun 2005 01:04:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17656 for ; Tue, 21 Jun 2005 01:04:44 -0400 (EDT) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkbK6-0000mm-NL for ippm@ietf.org; Tue, 21 Jun 2005 01:29:24 -0400 Received: by postman.ripe.net (Postfix, from userid 4008) id 510BD24A2B; Tue, 21 Jun 2005 07:04:30 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 6F49F24A24; Tue, 21 Jun 2005 07:04:29 +0200 (CEST) Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id j5L54Q38032656; Tue, 21 Jun 2005 07:04:29 +0200 Message-Id: <6.2.1.2.2.20050620173706.02c80870@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 20 Jun 2005 17:55:47 +0200 To: Ulisses , ippm@ietf.org From: Henk Uijterwaal Subject: Re: [ippm] Packet Reordering Metric question In-Reply-To: <20050620095402.GB3246@s163m108.unavarra.es> References: <20050620095402.GB3246@s163m108.unavarra.es> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00,DATE_IN_PAST_12_24 X-RIPE-Spam-Status: N 0.000001 / -5.2 X-RIPE-Signature: 67032cb68f392ecabe9501c8a41ecaa4 X-Spam-Score: 0.4 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Hi, >I have read >http://www.ietf.org/internet-drafts/draft-ietf-ippm-reordering-09.txt > >reading the examples of packet reordering, I'm curious about real-world >examples of packet reordering when fifo queues are in use and no packet >classification is in use. > >I have seen that some versions of Juniper do reordering, at least >with some versions of the firmware/JunOS when using multiple processors. > >Currently I'm doing tests and I see reordering (and no loss) in the firsts >packets in trains of packets. I would like to diagnose the symptom. > >comments/suggestions/references? I'm not quite sure what you want to do. You have a sample (train of packets) with reordering with some packets out of order w.r.t. the original sequence. The metric(s) described in the draft try to quantify the extend of the reordering. It is hard to intuitively quantify the extend of the reordering, but you can imagine that a sequence of 100 packets (1,2,3...100) that arrives as (2,1,3,4,5... 100) is considered less reordered than when it arrives as (100,99,98, .... 1). So, what you can do, is send trains of packets under various conditions, look at the arrival sequence, apply the metrics and compare their scores. The less reordering, the closer the result will be to 0 (or whatever the metric gives for an arrival sequence identical to the sending sequence). You can also try to relate reordering scores to other performance effects that you might see across your router. If you do, then I'd be very interested to hear about them. If you want to know what causes the reordering, you will have to look at the router hardware. The draft does not say anything about this. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Jun 21 01:04:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkawK-0005a5-5A; Tue, 21 Jun 2005 01:04:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkawG-0005ZX-MY for ippm@megatron.ietf.org; Tue, 21 Jun 2005 01:04:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17654 for ; Tue, 21 Jun 2005 01:04:44 -0400 (EDT) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkbK6-0000mn-MY for ippm@ietf.org; Tue, 21 Jun 2005 01:29:24 -0400 Received: by postman.ripe.net (Postfix, from userid 4008) id 4A38024A16; Tue, 21 Jun 2005 07:04:32 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 6950624A2A; Tue, 21 Jun 2005 07:04:31 +0200 (CEST) Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id j5L54Q3B032656; Tue, 21 Jun 2005 07:04:31 +0200 Message-Id: <6.2.1.2.2.20050620185324.02ca6bd0@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 20 Jun 2005 19:00:08 +0200 To: ippm@ietf.org From: Henk Uijterwaal In-Reply-To: <20050620095402.GB3246@s163m108.unavarra.es> References: <20050620095402.GB3246@s163m108.unavarra.es> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00,DATE_IN_PAST_12_24 X-RIPE-Spam-Status: N 0.000002 / -5.2 X-RIPE-Signature: 87fd5e753ba81501bbd4c28d7b607358 X-Spam-Score: 0.4 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Matthew J Zekauskas Subject: [ippm] IPPM Meeting in Paris X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org IPPM Group, The IPPM group will meet in Paris in August. So far we have these agenda topics: 1. Reordering draft 2. Bandwidth draft 3. New work items - TWAMP - Traceroutes - Composition of metrics - Multimetrics 4. Implementation document. If you want to say something about these topics, please tell us how much time you need. If you have any other topics for the agenda, just let us know. Henk will be completely offline between July 7 and 24. If you want a reply during that time, please make sure that both Matt and I are on the receipient list. Matt & Henk. ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Jun 21 01:35:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkbPo-0001nw-82; Tue, 21 Jun 2005 01:35:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkbK8-0000xe-5x for ippm@megatron.ietf.org; Tue, 21 Jun 2005 01:29:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19521 for ; Tue, 21 Jun 2005 01:29:23 -0400 (EDT) Received: from mail.halls.colostate.edu ([129.82.88.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dkbhy-0001Mt-I8 for ippm@ietf.org; Tue, 21 Jun 2005 01:54:03 -0400 Received: from [192.168.0.2] (sagg213246.halls.colostate.edu [129.82.213.246]) by mail.halls.colostate.edu (8.12.11/8.12.11) with ESMTP id j5L5TJWH007605 for ; Mon, 20 Jun 2005 23:29:19 -0600 Message-ID: <42B7A4A0.4010902@colostate.edu> Date: Mon, 20 Jun 2005 23:24:48 -0600 From: "Nischal M. Piratla" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ippm@ietf.org Subject: Re: [ippm] Query about Reordering Byte Offset References: <42B649D1.2050100@engr.colostate.edu> <6.2.1.2.0.20050620134206.02260290@custsla.mt.att.com> In-Reply-To: <6.2.1.2.0.20050620134206.02260290@custsla.mt.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/550/Mon Oct 25 09:39:01 2004, clamav-milter version 0.71 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 21 Jun 2005 01:35:14 -0400 Cc: X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Al, >> I am running some simulations to come up with an unbiased outlook for >> all the metrics out there. Truly, I intend to observe what we can >> achieve with each metric, and not which one is better than the other. > > How will you avoid bias in the type of simulations you select and run? Simulations analyze reordering based on load-splitting models with various probabilities and loss rates (burst losses) on multiple paths. So, I do not see anything going against ippm metrics or RD or RBD for that matter. Thank you for the non real-time measurement approach of 5 minute + wait. It really helps. (Also, I am considering all the scenarios not just the corner ones) Thank you, Nischal _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Jun 21 06:12:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkfiF-0003Jx-0P; Tue, 21 Jun 2005 06:10:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkfiC-0003IY-E9 for ippm@megatron.ietf.org; Tue, 21 Jun 2005 06:10:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00271 for ; Tue, 21 Jun 2005 06:10:29 -0400 (EDT) Received: from cartero1.unavarra.es ([130.206.159.51]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dkg65-0007zg-Sl for ippm@ietf.org; Tue, 21 Jun 2005 06:35:14 -0400 Received: from cartero1.unavarra.es (localhost.localdomain [127.0.0.1]) by localhost.unavarra.es (Postfix) with ESMTP id 9F72119E605; Tue, 21 Jun 2005 12:10:17 +0200 (CEST) Received: from unavarra.es (si.unavarra.es [130.206.166.108]) by cartero1.unavarra.es (Postfix) with ESMTP id 7B1A219E603; Tue, 21 Jun 2005 12:10:17 +0200 (CEST) Received: from s163m108.unavarra.es (mail@s163m108.unavarra.es [130.206.163.108]) by unavarra.es (8.9.3/8.9.1) with ESMTP id MAA23157; Tue, 21 Jun 2005 12:10:16 +0200 (MET DST) Received: from ulisses by s163m108.unavarra.es with local (Exim 3.36 #1 (Debian)) id 1Dkfhw-0003Wh-00; Tue, 21 Jun 2005 12:10:16 +0200 Date: Tue, 21 Jun 2005 12:10:16 +0200 From: Ulisses To: Michal Przybylski Subject: Re: [ippm] Packet Reordering Metric question Message-ID: <20050621101016.GA13543@s163m108.unavarra.es> References: <20050620095402.GB3246@s163m108.unavarra.es> <42B6CCEA.6050805@man.poznan.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42B6CCEA.6050805@man.poznan.pl> User-Agent: Mutt/1.3.28i X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Hi Michal On Mon, Jun 20, 2005 at 04:04:26PM +0200, Michal Przybylski wrote: > We have done something in this area, > > Please have a look at: > > http://ngn.man.poznan.pl/en/research/reordering/ > > and > > http://www.terena.nl/conferences/tnc2005/core/getfile.php?file_id=495 Thanks a lot for the links Taking into account that - route changes/flapping is not usual behaviour - QoS is not widely used because I believe over-provisioning is preferred I suposse that link-aggregation and router implementation is the cause of most reordering. isn't it? regards Ulisses > > All the best, > > Michal > > Ulisses napisa??(a): > >Hello all > > > >I have read > >http://www.ietf.org/internet-drafts/draft-ietf-ippm-reordering-09.txt > > > >reading the examples of packet reordering, I'm curious about real-world > >examples of packet reordering when fifo queues are in use and no packet > >classification is in use. > > > >I have seen that some versions of Juniper do reordering, at least > >with some versions of the firmware/JunOS when using multiple processors. > > > >Currently I'm doing tests and I see reordering (and no loss) in the firsts > >packets in trains of packets. I would like to diagnose the symptom. > > > >comments/suggestions/references? > > > >Thanks in advance > > > > Ulisses > > > > Debian GNU/Linux: a dream come true > >----------------------------------------------------------------------------- > >"Computers are useless. They can only give answers." Pablo > >Picasso > > > >"Debugging is twice as hard as writing the code in the first place. > >Therefore, if you write the code as cleverly as possible, you are, > >by definition, not smart enough to debug it." - Brian W. Kernighan > > > > > >_______________________________________________ > >ippm mailing list > >ippm@ietf.org > >https://www1.ietf.org/mailman/listinfo/ippm > > -- > ______________________________________________________________________ > Michal Przybylski Network Research and Development > michalp@man.poznan.pl Poznan Supercomputing and Networking Center > +48 61 858 20 27 http://www.man.poznan.pl > ______________________________________________________________________ -- Debian GNU/Linux: a dream come true ----------------------------------------------------------------------------- "Computers are useless. They can only give answers." Pablo Picasso "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Jun 21 06:46:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkgGv-0007zy-Fs; Tue, 21 Jun 2005 06:46:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkgGu-0007zp-CS for ippm@megatron.ietf.org; Tue, 21 Jun 2005 06:46:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03082 for ; Tue, 21 Jun 2005 06:46:21 -0400 (EDT) Received: from rose.man.poznan.pl ([150.254.173.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dkgem-0000P3-1v for ippm@ietf.org; Tue, 21 Jun 2005 07:11:06 -0400 Received: from [150.254.170.112] ([150.254.170.112]) (authenticated bits=0) by rose.man.poznan.pl (8.12.10/8.12.10/auth/ldap/milter/tls) with ESMTP id j5LAjmb1022902; Tue, 21 Jun 2005 12:45:50 +0200 (CEST) Message-ID: <42B7EFDE.4060907@man.poznan.pl> Date: Tue, 21 Jun 2005 12:45:50 +0200 From: Michal Przybylski User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: pl, en-us, en MIME-Version: 1.0 To: Ulisses Subject: Re: [ippm] Packet Reordering Metric question References: <20050620095402.GB3246@s163m108.unavarra.es> <42B6CCEA.6050805@man.poznan.pl> <20050621101016.GA13543@s163m108.unavarra.es> In-Reply-To: <20050621101016.GA13543@s163m108.unavarra.es> Content-Type: text/plain; charset=UTF-8; format=flowed X-Virus-Scanned: by PSNC antivirus scanner Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by rose.man.poznan.pl id j5LAjmb1022902 X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: quoted-printable Cc: ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Ulisses, Ulisses napisa=C5=82(a): >=20 > Hi Michal >=20 >=20 >=20 > Thanks a lot for the links >=20 > Taking into account that >=20 > - route changes/flapping is not usual behaviour > - QoS is not widely used because I believe over-provisioning is preferr= ed >=20 > I suposse that link-aggregation and router implementation is the cause > of most reordering. >=20 > isn't it? In our case yes - if you are from Spain, then you shall experience much=20 reordering from GEANT, caused by the M160 routers. However, GEANT is=20 also using Premium IP (EF) class to prioritize traffic and LBE (less=20 than best effort) traffic for e.g. disk backup traffic. Look for results=20 of LBE testing from Titziana Ferrari, and you will find some interesting=20 considersations of the influence on packet reordering by different QoS=20 schemes and weights applied. Also please speak to Miguel Angel Sotos or Esther Robles from RedIRIS,=20 who can help you wrt the situation in Spanish network. All the best, Michal >=20 > regards >=20 > Ulisses >=20 >=20 >>All the best, >> >>Michal >> >>Ulisses napisa??(a): >> >>>Hello all >>> >>>I have read=20 >>>http://www.ietf.org/internet-drafts/draft-ietf-ippm-reordering-09.txt >>> >>>reading the examples of packet reordering, I'm curious about real-worl= d >>>examples of packet reordering when fifo queues are in use and no packe= t >>>classification is in use. >>> >>>I have seen that some versions of Juniper do reordering, at least >>>with some versions of the firmware/JunOS when using multiple processor= s. >>> >>>Currently I'm doing tests and I see reordering (and no loss) in the fi= rsts=20 >>>packets in trains of packets. I would like to diagnose the symptom. >>> >>>comments/suggestions/references? >>> >>>Thanks in advance >>> >>> Ulisses >>> >>> Debian GNU/Linux: a dream come true >>>----------------------------------------------------------------------= ------- >>>"Computers are useless. They can only give answers." Pablo=20 >>>Picasso >>> >>>"Debugging is twice as hard as writing the code in the first place. >>>Therefore, if you write the code as cleverly as possible, you are, >>>by definition, not smart enough to debug it." - Brian W. Kernighan >>> >>> >>>_______________________________________________ >>>ippm mailing list >>>ippm@ietf.org=20 >>>https://www1.ietf.org/mailman/listinfo/ippm >> >>--=20 >>______________________________________________________________________ >>Michal Przybylski Network Research and Development >>michalp@man.poznan.pl Poznan Supercomputing and Networking Center >>+48 61 858 20 27 http://www.man.poznan.pl >>______________________________________________________________________ >=20 >=20 --=20 ______________________________________________________________________ Michal Przybylski Network Research and Development michalp@man.poznan.pl Poznan Supercomputing and Networking Center +48 61 858 20 27 http://www.man.poznan.pl ______________________________________________________________________ _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Jun 21 07:25:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkgsM-0004Z6-BB; Tue, 21 Jun 2005 07:25:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkgsL-0004Yz-Bg for ippm@megatron.ietf.org; Tue, 21 Jun 2005 07:25:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06270 for ; Tue, 21 Jun 2005 07:25:04 -0400 (EDT) Received: from cartero1.unavarra.es ([130.206.159.51]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkhGE-0001OA-KT for ippm@ietf.org; Tue, 21 Jun 2005 07:49:48 -0400 Received: from cartero1.unavarra.es (localhost.localdomain [127.0.0.1]) by localhost.unavarra.es (Postfix) with ESMTP id 5031119E609; Tue, 21 Jun 2005 13:24:54 +0200 (CEST) Received: from unavarra.es (si.unavarra.es [130.206.166.108]) by cartero1.unavarra.es (Postfix) with ESMTP id 44C1F19E603; Tue, 21 Jun 2005 13:24:54 +0200 (CEST) Received: from s163m108.unavarra.es (mail@s163m108.unavarra.es [130.206.163.108]) by unavarra.es (8.9.3/8.9.1) with ESMTP id NAA20251; Tue, 21 Jun 2005 13:24:53 +0200 (MET DST) Received: from ulisses by s163m108.unavarra.es with local (Exim 3.36 #1 (Debian)) id 1Dkgs9-0003fp-00; Tue, 21 Jun 2005 13:24:53 +0200 Date: Tue, 21 Jun 2005 13:24:53 +0200 From: Ulisses To: Henk Uijterwaal Subject: Re: [ippm] Packet Reordering Metric question Message-ID: <20050621112453.GB13941@s163m108.unavarra.es> References: <20050620095402.GB3246@s163m108.unavarra.es> <6.2.1.2.2.20050620173706.02c80870@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.1.2.2.20050620173706.02c80870@localhost> User-Agent: Mutt/1.3.28i X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Hello (again) Henk On Mon, Jun 20, 2005 at 05:55:47PM +0200, Henk Uijterwaal wrote: > Hi, > > >I have read > >http://www.ietf.org/internet-drafts/ > > > >reading the examples of packet reordering, I'm curious about real-world > >examples of packet reordering when fifo queues are in use and no packet > >classification is in use. > > > >I have seen that some versions of Juniper do reordering, at least > >with some versions of the firmware/JunOS when using multiple processors. > > > >Currently I'm doing tests and I see reordering (and no loss) in the firsts > >packets in trains of packets. I would like to diagnose the symptom. > > > >comments/suggestions/references? > > I'm not quite sure what you want to do. You have a sample (train of > packets) with reordering with some packets out of order w.r.t. the > original sequence. The metric(s) described in the draft try to quantify > the extend of the reordering. I already have implemented the metrics of draft-ietf-ippm-reordering-09.txt and tested within the Geant network. I found some extrange reordering, the problem is that I don't know if exists a way to infer where the reordering occurs other than doing mesh meassurements (all to all) and compare them with a graph taken from traceroute and infer the routers where it is happening. > You can also try to relate reordering scores to other performance > effects that you might see across your router. If you do, then > I'd be very interested to hear about them. Which related performance effects are you thinking about? I would greatly appreciate any suggestion > If you want to know what causes the reordering, you will have to > look at the router hardware. yes, that's _the_ problem. Thanks in advance Ulisses Debian GNU/Linux: a dream come true ----------------------------------------------------------------------------- "Computers are useless. They can only give answers." Pablo Picasso "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Jun 21 08:30:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkhtV-0005l6-80; Tue, 21 Jun 2005 08:30:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkhtU-0005kr-0i for ippm@megatron.ietf.org; Tue, 21 Jun 2005 08:30:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12516 for ; Tue, 21 Jun 2005 08:30:18 -0400 (EDT) Received: from mail131.messagelabs.com ([216.82.242.99]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DkiHH-0003Ga-Kd for ippm@ietf.org; Tue, 21 Jun 2005 08:55:03 -0400 X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-2.tower-131.messagelabs.com!1119356999!3085364!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.134.71] Received: (qmail 11702 invoked from network); 21 Jun 2005 12:29:59 -0000 Received: from kcmso2.att.com (HELO kcmso2.proxy.att.com) (192.128.134.71) by server-2.tower-131.messagelabs.com with SMTP; 21 Jun 2005 12:29:59 -0000 Received: from attrh3i.attrh.att.com ([135.38.62.9]) by kcmso2.proxy.att.com (AT&T IPNS/MLO-6.0) with ESMTP id j5LCT4Rd012594 for ; Tue, 21 Jun 2005 07:29:59 -0500 Received: from custsla.mt.att.com (135.21.14.109) by attrh3i.attrh.att.com (7.2.052) id 4290ADDF00A08B27 for ippm@ietf.org; Tue, 21 Jun 2005 08:29:59 -0400 Received: from acmortonw.att.com ([135.25.189.26]) by custsla.mt.att.com (8.10.2+Sun/8.10.2) with ESMTP id j5LCTwZ26033 for ; Tue, 21 Jun 2005 08:29:58 -0400 (EDT) Message-Id: <6.2.1.2.0.20050621081930.02248a10@custsla.mt.att.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 21 Jun 2005 08:28:29 -0400 To: ippm@ietf.org From: Al Morton Subject: Re: [ippm] Query about Reordering Byte Offset In-Reply-To: <42B7A4A0.4010902@colostate.edu> References: <42B649D1.2050100@engr.colostate.edu> <6.2.1.2.0.20050620134206.02260290@custsla.mt.att.com> <42B7A4A0.4010902@colostate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org At 01:24 AM 06/21/2005, Nischal M. Piratla wrote: >Thank you for the non real-time measurement approach of 5 minute + wait. >It really helps. I suggested a way to organize the samples; it has nothing to do with "non real-time" implementation. The waiting time is the value "Th" in the Loss RFC. Al _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Jun 21 08:59:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkiLV-00021n-Pp; Tue, 21 Jun 2005 08:59:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkiLO-00021f-Tv for ippm@megatron.ietf.org; Tue, 21 Jun 2005 08:59:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15038 for ; Tue, 21 Jun 2005 08:59:09 -0400 (EDT) Received: from mail131.messagelabs.com ([216.82.242.99]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DkijJ-000429-0W for ippm@ietf.org; Tue, 21 Jun 2005 09:23:54 -0400 X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-8.tower-131.messagelabs.com!1119340736!3095926!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.167.69] Received: (qmail 18517 invoked from network); 21 Jun 2005 07:58:56 -0000 Received: from almso1.att.com (HELO almso1.proxy.att.com) (192.128.167.69) by server-8.tower-131.messagelabs.com with SMTP; 21 Jun 2005 07:58:56 -0000 Received: from attrh3i.attrh.att.com ([135.38.62.9]) by almso1.proxy.att.com (AT&T IPNS/MLO-6.0) with ESMTP id j5LCub9G015818 for ; Tue, 21 Jun 2005 08:58:57 -0400 Received: from custsla.mt.att.com (135.21.14.109) by attrh3i.attrh.att.com (7.2.052) id 4290ADDF00A0A1EB for ippm@ietf.org; Tue, 21 Jun 2005 08:58:57 -0400 Received: from acmortonw.att.com ([135.25.189.26]) by custsla.mt.att.com (8.10.2+Sun/8.10.2) with ESMTP id j5LCwtZ26047 for ; Tue, 21 Jun 2005 08:58:56 -0400 (EDT) Message-Id: <6.2.1.2.0.20050621084848.02210030@custsla.mt.att.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 21 Jun 2005 08:57:26 -0400 To: ippm@ietf.org From: Al Morton Subject: Re: [ippm] Packet Reordering Metric question In-Reply-To: <20050621112453.GB13941@s163m108.unavarra.es> References: <20050620095402.GB3246@s163m108.unavarra.es> <6.2.1.2.2.20050620173706.02c80870@localhost> <20050621112453.GB13941@s163m108.unavarra.es> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org At 07:24 AM 06/21/2005, Ulisses wrote: >I already have implemented the metrics of >draft-ietf-ippm-reordering-09.txt and >tested within the Geant network. I found some extrange reordering, the problem >is that I don't know if exists a way to infer where the reordering occurs >other >than doing mesh meassurements (all to all) and compare them with a graph >taken from traceroute and infer the routers where it is happening. I assume this is steady-state reordering, as described in the draft. Perhaps you can narrow-down your search by dividing the network into sections, or has reordering appeared in all your measurements so far? Also, we should probably exclude specific manufacturer/model names from on-list discussions, IMO. Al _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Jun 21 13:57:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkmzg-0000Uo-Vo; Tue, 21 Jun 2005 13:57:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkmzf-0000Ud-3S for ippm@megatron.ietf.org; Tue, 21 Jun 2005 13:57:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12320 for ; Tue, 21 Jun 2005 13:57:01 -0400 (EDT) Received: from pop-cowbird.atl.sa.earthlink.net ([207.69.195.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DknNb-00045k-QE for ippm@ietf.org; Tue, 21 Jun 2005 14:21:49 -0400 Received: from h-68-166-188-8.snvacaid.dynamic.covad.net ([68.166.188.8] helo=oemcomputer) by pop-cowbird.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DkmzW-0001cN-00 for ippm@ietf.org; Tue, 21 Jun 2005 13:56:55 -0400 Message-ID: <003301c5768b$1e4383c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <20050620095402.GB3246@s163m108.unavarra.es><6.2.1.2.2.20050620173706.02c80870@localhost><20050621112453.GB13941@s163m108.unavarra.es> <6.2.1.2.0.20050621084848.02210030@custsla.mt.att.com> Subject: Re: [ippm] Packet Reordering Metric question Date: Tue, 21 Jun 2005 11:00:32 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Hi - > From: "Al Morton" > To: > Sent: Tuesday, June 21, 2005 5:57 AM > Subject: Re: [ippm] Packet Reordering Metric question ... > Also, we should probably exclude specific manufacturer/model names > from on-list discussions, IMO. ... As long as it's not advertising, why? Without a vendor / model, claims that some behaviour occurs in the wild are difficult to evaluate, and could achieve a kind of folklore status, persisting long after the interesting boxes have been unplugged. Randy _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Jun 21 14:18:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DknKG-0004w2-P0; Tue, 21 Jun 2005 14:18:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DknKF-0004vx-ME for ippm@megatron.ietf.org; Tue, 21 Jun 2005 14:18:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14283 for ; Tue, 21 Jun 2005 14:18:18 -0400 (EDT) Received: from cartero1.unavarra.es ([130.206.159.51]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkniC-0004eR-Qk for ippm@ietf.org; Tue, 21 Jun 2005 14:43:06 -0400 Received: from cartero1.unavarra.es (localhost.localdomain [127.0.0.1]) by localhost.unavarra.es (Postfix) with ESMTP id 1B72619E607; Tue, 21 Jun 2005 20:17:58 +0200 (CEST) Received: from unavarra.es (si.unavarra.es [130.206.166.108]) by cartero1.unavarra.es (Postfix) with ESMTP id 07E2D19E606; Tue, 21 Jun 2005 20:17:58 +0200 (CEST) Received: from s163m108.unavarra.es (mail@s163m108.unavarra.es [130.206.163.108]) by unavarra.es (8.9.3/8.9.1) with ESMTP id UAA26593; Tue, 21 Jun 2005 20:17:57 +0200 (MET DST) Received: from ulisses by s163m108.unavarra.es with local (Exim 3.36 #1 (Debian)) id 1DknJt-0004q7-00; Tue, 21 Jun 2005 20:17:57 +0200 Date: Tue, 21 Jun 2005 20:17:57 +0200 From: Ulisses To: Al Morton Subject: Re: [ippm] Packet Reordering Metric question Message-ID: <20050621181757.GA18561@s163m108.unavarra.es> References: <20050621112453.GB13941@s163m108.unavarra.es> <6.2.1.2.0.20050621084848.02210030@custsla.mt.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.1.2.0.20050621084848.02210030@custsla.mt.att.com> User-Agent: Mutt/1.3.28i X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Hello Al On Tue, Jun 21, 2005 at 08:57:26AM -0400, Al Morton wrote: [...] > I assume this is steady-state reordering, as described in the draft. Yes, it happens under normal operation of the network. > Perhaps you can narrow-down your search by dividing the network into > sections, or has reordering appeared in all your measurements so far? looking again at the results, It happend to be the same reordering issue I found some time ago... > Also, we should probably exclude specific manufacturer/model names > from on-list discussions, IMO. I understand that in general we must avoid it, and also that we don't do wrong if we mention them in well known issues. Thanks for your comments Ulisses Debian GNU/Linux: a dream come true ----------------------------------------------------------------------------- "Computers are useless. They can only give answers." Pablo Picasso "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Jun 21 15:50:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkolT-0005FV-Vp; Tue, 21 Jun 2005 15:50:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkol4-000592-ME; Tue, 21 Jun 2005 15:50:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24752; Tue, 21 Jun 2005 15:50:04 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dkp90-0007R7-AO; Tue, 21 Jun 2005 16:14:51 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Dkol0-0002ZK-1u; Tue, 21 Jun 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 21 Jun 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ippm@ietf.org Subject: [ippm] I-D ACTION:draft-ietf-ippm-bw-capacity-00.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : Defining Network Capacity Author(s) : P. Chimento, J. Ishac Filename : draft-ietf-ippm-bw-capacity-00.txt Pages : 14 Date : 2005-6-21 Measuring capacity is a task that sounds simple, but in reality can be quite complex. In addition, the lack of a unified nomenclature on this subject makes it increasingly difficult to properly build, test, and use techniques and tools built around these constructs. This document provides definitions for the terms 'Capacity' and 'Available Capacity' related to IP traffic traveling between a source and destination in an IP network. By doing so, we hope to build a common language that can be used when discussing and analyzing a diverse set of current and future estimation techniques. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-bw-capacity-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ippm-bw-capacity-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ippm-bw-capacity-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-6-21124405.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-bw-capacity-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-bw-capacity-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-21124405.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --NextPart-- From ippm-bounces@ietf.org Tue Jun 21 15:51:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkom0-0005Nb-OS; Tue, 21 Jun 2005 15:51:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkol7-0005Ac-Bt; Tue, 21 Jun 2005 15:50:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24786; Tue, 21 Jun 2005 15:50:07 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dkp90-0007RO-Ad; Tue, 21 Jun 2005 16:14:51 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Dkol0-0002au-E2; Tue, 21 Jun 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 21 Jun 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: ippm@ietf.org Subject: [ippm] I-D ACTION:draft-ietf-ippm-reordering-10.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : Packet Reordering Metric for IPPM Author(s) : A. Morton, et al. Filename : draft-ietf-ippm-reordering-10.txt Pages : 38 Date : 2005-6-21 This memo defines metrics to evaluate if a network has maintained packet order on a packet-by-packet basis. It provides motivations for the new metrics and discusses the measurement issues, including the context information required for all metrics. The memo first defines a reordered singleton, and then uses it as the basis for sample metrics to quantify the extent of reordering in several useful dimensions for network characterization or receiver design. Additional metrics quantify the frequency of reordering and the distance between separate occurrences. We then define a metric oriented toward reordering affects on TCP. Several examples of evaluation using the various sample metrics are included. An Appendix gives extended definitions for evaluating order with packet fragmentation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-reordering-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ippm-reordering-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ippm-reordering-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-6-21151727.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-reordering-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-reordering-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-21151727.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --NextPart-- From ippm-bounces@ietf.org Tue Jun 21 19:33:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DksFA-0003v9-D9; Tue, 21 Jun 2005 19:33:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DksF8-0003v4-S7 for ippm@megatron.ietf.org; Tue, 21 Jun 2005 19:33:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26432 for ; Tue, 21 Jun 2005 19:33:19 -0400 (EDT) Received: from panorama.covad.com ([66.134.72.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dksd9-0002kA-EH for ippm@ietf.org; Tue, 21 Jun 2005 19:58:11 -0400 Received: from zanxmb00.cc-ntd1.covad.com (zanxmb00.corp.covad.com [172.16.2.119]) by panorama.Covad.COM (8.9.3/8.8.7) with ESMTP id QAA16999 for ; Tue, 21 Jun 2005 16:33:12 -0700 (PDT) Received: from ZANEVS03.cc-ntd1.covad.com ([172.16.2.83]) by zanxmb00.cc-ntd1.covad.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 21 Jun 2005 16:33:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ippm] I-D ACTION:draft-ietf-ippm-bw-capacity-00.txt Date: Tue, 21 Jun 2005 16:33:11 -0700 Message-ID: Thread-Topic: [ippm] I-D ACTION:draft-ietf-ippm-bw-capacity-00.txt Thread-Index: AcV2nkA/VgrMM0wzS7GBFQXxaxsRyQAFQieg From: "Fardid, Reza" To: X-OriginalArrivalTime: 21 Jun 2005 23:33:12.0214 (UTC) FILETIME=[96DED360:01C576B9] X-SPAM: 0.00% X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Hi Phil, I have a couple of comments on this I-D on first glance: 1. Even though the goal is not to provide an exhaustive list of factors that can reduce link and/or path capacity, an important factor worth including is the impact of traffic policing and shaping on IP layer path capacity. SPs commonly use rate-limiting, e.g., in Metro Ethernet networks, to either restrict the nominal physical link capacity (e.g., Ethernet over SONET) for a single customer or enforce traffic contracts via sharing of link capacity among multiple customers (e.g., per VLAN). Verification of path capacity can be challenging in such networks; 2. Bulk transfer capacity (BTC) is also relevant in the context of end-to-end path capacity, even though its scope is limited as a TCP throughput metric. It might be useful to include it in the discussion section. A relevant reference is=20 R. S. Prasad, M. Murray, C. Dovrolis and K. Claffy, "Bandwidth estimation: metrics, measurement techniques and tools", IEEE Network, Nov/Dec 2003, Vol 17, No. 6, pages 27-35. Regards, Reza Fardid -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, June 21, 2005 12:50 PM To: i-d-announce@ietf.org Cc: ippm@ietf.org Subject: [ippm] I-D ACTION:draft-ietf-ippm-bw-capacity-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : Defining Network Capacity Author(s) : P. Chimento, J. Ishac Filename : draft-ietf-ippm-bw-capacity-00.txt Pages : 14 Date : 2005-6-21 =09 Measuring capacity is a task that sounds simple, but in reality can be quite complex. In addition, the lack of a unified nomenclature on this subject makes it increasingly difficult to properly build, test, and use techniques and tools built around these constructs. This document provides definitions for the terms 'Capacity' and 'Available Capacity' related to IP traffic traveling between a source and destination in an IP network. By doing so, we hope to build a common language that can be used when discussing and analyzing a diverse set of current and future estimation techniques. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-bw-capacity-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ippm-bw-capacity-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ippm-bw-capacity-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Jun 21 21:59:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkuWp-0006Pk-Cy; Tue, 21 Jun 2005 21:59:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkuWn-0006Pc-Nc for ippm@megatron.ietf.org; Tue, 21 Jun 2005 21:59:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07738 for ; Tue, 21 Jun 2005 21:59:43 -0400 (EDT) Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dkuuh-0006Jw-Be for ippm@ietf.org; Tue, 21 Jun 2005 22:24:36 -0400 X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-9.tower-121.messagelabs.com!1119405566!2245209!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.134.71] Received: (qmail 24610 invoked from network); 22 Jun 2005 01:59:26 -0000 Received: from kcmso2.att.com (HELO kcmso2.proxy.att.com) (192.128.134.71) by server-9.tower-121.messagelabs.com with SMTP; 22 Jun 2005 01:59:26 -0000 Received: from attrh2i.attrh.att.com ([135.37.94.56]) by kcmso2.proxy.att.com (AT&T IPNS/MLO-6.0) with ESMTP id j5M1vwRa017936 for ; Tue, 21 Jun 2005 20:59:26 -0500 Received: from custsla.mt.att.com (135.21.14.109) by attrh2i.attrh.att.com (7.2.052) id 42B597B0000E03B7 for ippm@ietf.org; Tue, 21 Jun 2005 21:59:26 -0400 Received: from acmortonw.att.com ([135.210.96.62]) by custsla.mt.att.com (8.10.2+Sun/8.10.2) with ESMTP id j5M1xPZ26485 for ; Tue, 21 Jun 2005 21:59:25 -0400 (EDT) Message-Id: <6.2.1.2.0.20050621144641.07211eb0@custsla.mt.att.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 21 Jun 2005 21:57:53 -0400 To: ippm@ietf.org From: Al Morton Subject: Re: [ippm] Packet Reordering Metric question In-Reply-To: <003301c5768b$1e4383c0$7f1afea9@oemcomputer> References: <20050620095402.GB3246@s163m108.unavarra.es> <6.2.1.2.2.20050620173706.02c80870@localhost> <20050621112453.GB13941@s163m108.unavarra.es> <6.2.1.2.0.20050621084848.02210030@custsla.mt.att.com> <003301c5768b$1e4383c0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org At 02:00 PM 06/21/2005, Randy Presuhn wrote: >As long as it's not advertising, why? Without a vendor / model, Publicity comes in two categories, positive and negative. This is the latter, and to be constructive even more details are needed, such as the OS version, interface card types, etc. We haven't even learned details about the packet stream used in the measurements, but we already have a vendor to beat-up? And I agree with you, that without all these details... >claims >that some behaviour occurs in the wild are difficult to evaluate, and could >achieve a kind of folklore status, persisting long after the interesting >boxes have been unplugged. I said this is my opinion. I typically expunge vendor names/models from standards contributions, emphasizing the impairment observed and the effect on the development instead. I wouldn't want to drag someone's name through the mud and find-out later that it wasn't their fault. The retraction never seems to flow as far, or as fast. Al _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Jun 22 09:18:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl57K-0001cF-Qe; Wed, 22 Jun 2005 09:18:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl57I-0001bR-Td for ippm@megatron.ietf.org; Wed, 22 Jun 2005 09:18:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07972 for ; Wed, 22 Jun 2005 09:18:06 -0400 (EDT) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl5VP-0007dO-Vt for ippm@ietf.org; Wed, 22 Jun 2005 09:43:05 -0400 Received: by postman.ripe.net (Postfix, from userid 4008) id 9504324B63; Wed, 22 Jun 2005 15:17:58 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 8A8FF246A9; Wed, 22 Jun 2005 15:17:57 +0200 (CEST) Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id j5MDHu38007403; Wed, 22 Jun 2005 15:17:57 +0200 Message-Id: <6.2.1.2.2.20050622150302.02d4de30@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 22 Jun 2005 15:17:54 +0200 To: Ulisses From: Henk Uijterwaal Subject: Re: [ippm] Packet Reordering Metric question In-Reply-To: <20050621112453.GB13941@s163m108.unavarra.es> References: <20050620095402.GB3246@s163m108.unavarra.es> <6.2.1.2.2.20050620173706.02c80870@localhost> <20050621112453.GB13941@s163m108.unavarra.es> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000000 / -5.9 X-RIPE-Signature: b901a0087f20d1ba73d1700217378101 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Hi, > > You can also try to relate reordering scores to other performance > > effects that you might see across your router. If you do, then > > I'd be very interested to hear about them. > >Which related performance effects are you thinking about? I would greatly >appreciate any suggestion Reordering usually means that the receiving device has to put the packets back into order. This requires it to run some sort of sort algorithm (which takes time) and store the packets while waiting for the ones that are late. If a packet is completely out of order, it will ask for a re-send. All this will affect things like throughput, used capacity, etc. It'd be interesting to see if there is a relation between the result for reordering and quantities like throughput. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Jun 22 10:05:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl5rH-0005aI-4A; Wed, 22 Jun 2005 10:05:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl5rE-0005Zz-Ur for ippm@megatron.ietf.org; Wed, 22 Jun 2005 10:05:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12957 for ; Wed, 22 Jun 2005 10:05:34 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dl6FL-0000v6-2p for ippm@ietf.org; Wed, 22 Jun 2005 10:30:33 -0400 Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Wed, 22 Jun 2005 15:01:10 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Jun 2005 15:01:03 +0100 Received: from 131.227.89.181 ([131.227.89.181]) by EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.152]) with Microsoft Exchange Server HTTP-DAV ; Wed, 22 Jun 2005 14:01:02 +0000 Received: from ccsrlt31 by exchange.surrey.ac.uk; 22 Jun 2005 15:01:02 +0100 Subject: Re: [ippm] Packet Reordering Metric question From: Lei Liang To: Henk Uijterwaal In-Reply-To: <6.2.1.2.2.20050622150302.02d4de30@localhost> References: <20050620095402.GB3246@s163m108.unavarra.es> <6.2.1.2.2.20050620173706.02c80870@localhost> <20050621112453.GB13941@s163m108.unavarra.es> <6.2.1.2.2.20050622150302.02d4de30@localhost> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1119448862.5113.6.camel@ccsrlt31.ee.surrey.ac.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 22 Jun 2005 15:01:02 +0100 X-OriginalArrivalTime: 22 Jun 2005 14:01:03.0554 (UTC) FILETIME=[D3CEC220:01C57732] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org On Wed, 2005-06-22 at 14:17, Henk Uijterwaal wrote: > Hi, > > > > You can also try to relate reordering scores to other performance > > > effects that you might see across your router. If you do, then > > > I'd be very interested to hear about them. > > > >Which related performance effects are you thinking about? I would greatly > >appreciate any suggestion > > Reordering usually means that the receiving device has to put the packets > back into order. This requires it to run some sort of sort algorithm > (which takes time) and store the packets while waiting for the ones that > are late. If a packet is completely out of order, it will ask for a re-send. > All this will affect things like throughput, used capacity, etc. It'd be > interesting to see if there is a relation between the result for reordering > and quantities like throughput. > It will be quite dependant on various network situation. I.e., the packet length, the throughput without reordering, transport protocols used and the sort algorithm used will all have impact on the relationship. That means the test to find out the relationship between reordering and quantities might have to consider all of these factors. cheers, Lei > Henk > > > ------------------------------------------------------------------------------ > Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net > RIPE Network Coordination Centre http://www.amsterdamned.org/~henk > P.O.Box 10096 Singel 258 Phone: +31.20.5354414 > 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 > The Netherlands The Netherlands Mobile: +31.6.55861746 > ------------------------------------------------------------------------------ > > Look here junior, don't you be so happy. > And for Heaven's sake, don't you be so sad. (Tom Verlaine) > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Jun 22 21:44:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlGly-0003da-DV; Wed, 22 Jun 2005 21:44:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlGlw-0003dO-Sy for ippm@megatron.ietf.org; Wed, 22 Jun 2005 21:44:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24941 for ; Wed, 22 Jun 2005 21:44:50 -0400 (EDT) From: vze275m9@verizon.net Received: from vms048pub.verizon.net ([206.46.252.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlHAA-00063I-MD for ippm@ietf.org; Wed, 22 Jun 2005 22:09:55 -0400 Received: from [192.168.1.4] ([68.239.109.238]) by vms048.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0III00L54KUB1WK6@vms048.mailsrvcs.net> for ippm@ietf.org; Wed, 22 Jun 2005 20:44:36 -0500 (CDT) Date: Wed, 22 Jun 2005 21:44:40 -0400 Subject: Re: [ippm] I-D ACTION:draft-ietf-ippm-bw-capacity-00.txt In-reply-to: To: "Fardid, Reza" Message-id: MIME-version: 1.0 (Apple Message framework v622) X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7bit References: X-Spam-Score: 0.7 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Hi Reza: Thanks for your comments. Responses inline. On Jun 21, 2005, at 19:33, Fardid, Reza wrote: > Hi Phil, > > I have a couple of comments on this I-D on first glance: > > 1. Even though the goal is not to provide an exhaustive list of factors > that can reduce link and/or path capacity, an important factor worth > including is the impact of traffic policing and shaping on IP layer > path > capacity. SPs commonly use rate-limiting, e.g., in Metro Ethernet > networks, to either restrict the nominal physical link capacity (e.g., > Ethernet over SONET) for a single customer or enforce traffic contracts > via sharing of link capacity among multiple customers (e.g., per VLAN). > Verification of path capacity can be challenging in such networks; Yes, you are right of course; a service provider can use shaping to limit apparent capacity of a logical link (like VLANs). However, the definition tries to capture capacity (but does not say how to measure it), no matter how the nominal capacity is reduced or impaired (i.e. whether deliberately or not). We can add shaping (policing is another matter) to the list, but it will still be incomplete. > 2. Bulk transfer capacity (BTC) is also relevant in the context of > end-to-end path capacity, even though its scope is limited as a TCP > throughput metric. It might be useful to include it in the discussion > section. > I am not sure how BTC is relevant here. We are not trying to do a survey of capacity-related metrics, but only trying to define what two quantities are (regardless of the transport layer protocol). > A relevant reference is > > R. S. Prasad, M. Murray, C. Dovrolis and K. Claffy, "Bandwidth > estimation: metrics, measurement techniques and tools", IEEE Network, > Nov/Dec 2003, Vol 17, No. 6, pages 27-35. > > Regards, > Reza Fardid > > Thanks for the reference. Regards, Phil Chimento _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Jun 23 05:23:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlNwF-0003cW-CC; Thu, 23 Jun 2005 05:23:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlMos-0001ql-NS for ippm@megatron.ietf.org; Thu, 23 Jun 2005 04:12:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14484 for ; Thu, 23 Jun 2005 04:12:17 -0400 (EDT) Received: from spinett.bth.se ([194.47.129.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlND9-0006Di-FD for ippm@ietf.org; Thu, 23 Jun 2005 04:37:24 -0400 Received: from Trantor (spinett.bth.se [194.47.129.13]) by spinett.bth.se (8.13.4/8.13.4/Debian-3) with ESMTP id j5N8C13c027382 for ; Thu, 23 Jun 2005 10:12:02 +0200 From: "Patrik Arlos" To: Subject: RE: [ippm] I-D ACTION:draft-ietf-ippm-bw-capacity-00.txt Date: Thu, 23 Jun 2005 10:11:59 +0200 Organization: Blekinge Institute of Technology Message-ID: <004801c577cb$3aba4700$05000100@Trantor> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Scanned-By: MIMEDefang 2.51 on 194.47.129.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 23 Jun 2005 05:23:57 -0400 Cc: X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Hi Phil, With IP Layer Link Capacity are you referring to the capacity seen on = the Network to Link-Layer and Link to Network-Layer interfaces? Or do you = mean the Transport-Network, Network-Transport interfaces? I would argue for = the later, since this will be the capacity seen by the higher layers and eventually the user/application. Using such a definition would simplify = the definition of capacity on other layers.=20 Regarding utilization, at least on Ethernet the utilization is also = based on the frame rate. Small frames fill the link, but only use ~75% of the bit-capacity. Will we not see the same from the higher layers, as the payload size varies compared the headers introduced? If so, the = utilization cannot be based only on the bit count.=20 /Patrik Patrik Arlos Tech. Lic Telecommunications systems PhD Candidate Telecommunications Blekinge Institute of Technology School of Engineering, Telecommunications Group 371 79 KARLSKRONA SWEDEN +46 (0)455 385654 Office +46 (0)733 800312 Mobile =20 _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Jun 23 12:43:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlUnm-0003PU-4W; Thu, 23 Jun 2005 12:43:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlUnk-0003PP-5p for ippm@megatron.ietf.org; Thu, 23 Jun 2005 12:43:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02607 for ; Thu, 23 Jun 2005 12:43:37 -0400 (EDT) Received: from mx2.grc.nasa.gov ([128.156.11.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlVC5-0005a9-Iu for ippm@ietf.org; Thu, 23 Jun 2005 13:08:50 -0400 Received: from lombok-fi.grc.nasa.gov (seraph1.grc.nasa.gov [128.156.10.10]) by mx2.grc.nasa.gov (Postfix) with ESMTP id 78534C342 for ; Thu, 23 Jun 2005 12:43:27 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id j5NGhRGT003053 for ; Thu, 23 Jun 2005 12:43:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id j5NGhQU6013495 for ; Thu, 23 Jun 2005 12:43:26 -0400 (EDT) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.n asa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id 11459-12 for ;Thu, 23 Jun 2005 12:43:26 -0400 (EDT) Received: from sunfire.grc.nasa.gov (IDENT:postfix@sunfire.grc.nasa.gov [139 .88.111.70])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMT P id j5NGhOWU013485for ; Thu, 23 Jun 2005 12:43:24 -0400 (ED T) Received: by sunfire.grc.nasa.gov (Postfix, from userid 500)id 29E62BC1C0; T hu, 23 Jun 2005 12:36:38 -0400 (EDT) Date: Thu, 23 Jun 2005 12:36:38 -0400 From: Joseph Ishac To: ippm@ietf.org Subject: Re: [ippm] I-D ACTION:draft-ietf-ippm-bw-capacity-00.txt Message-ID: <20050623163637.GA30369@sunfire.grc.nasa.gov> Mail-Followup-To: ippm@ietf.org References: <004801c577cb$3aba4700$05000100@Trantor> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004801c577cb$3aba4700$05000100@Trantor> User-Agent: Mutt/1.4.2.1i X-imss-version: 2.25 X-imss-result: Passed X-imss-approveListMatch: *@*.NASA.GOV X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joseph Ishac List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org On Thu, Jun 23, 2005 at 10:11:59AM +0200, Patrik Arlos wrote: > With IP Layer Link Capacity are you referring to the capacity seen on the > Network to Link-Layer and Link to Network-Layer interfaces? Or do you mean > the Transport-Network, Network-Transport interfaces? I would argue for the > later, since this will be the capacity seen by the higher layers and > eventually the user/application. Using such a definition would simplify the > definition of capacity on other layers. We mean IP Layer as in the definition of IP layer bits, which is the IP header plus payload (regardless of content). I'm not sure I understand your definition though. > Regarding utilization, at least on Ethernet the utilization is also based on > the frame rate. Small frames fill the link, but only use ~75% of the > bit-capacity. Will we not see the same from the higher layers, as the > payload size varies compared the headers introduced? If so, the utilization > cannot be based only on the bit count. The utilization is a fraction that is based on both the capacity (C()) and usage (Used()). It is not based of the nominal capacity of the link. So, the Ethernet framing overhead will affect the value of C(). We actually have a small bit talking to this in section 3. -Joseph _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Jun 29 15:29:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DniF8-00018U-Ix; Wed, 29 Jun 2005 15:29:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DniF7-00018P-5x for ippm@megatron.ietf.org; Wed, 29 Jun 2005 15:29:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28827 for ; Wed, 29 Jun 2005 15:29:03 -0400 (EDT) Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dnieh-0003t4-89 for ippm@ietf.org; Wed, 29 Jun 2005 15:55:33 -0400 Received: from lombok-fi.grc.nasa.gov (seraph4.grc.nasa.gov [128.156.10.13]) by mx1.grc.nasa.gov (Postfix) with ESMTP id 6D4E1C363 for ; Wed, 29 Jun 2005 15:28:47 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id j5TJSiGT026541; Wed, 29 Jun 2005 15:28:44 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id j5TJSiTn025710; Wed, 29 Jun 2005 15:28:44 -0400 (EDT) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.n asa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id 24294-09; Wed, 29 Jun 2005 15:28:44 -0400 (EDT) Received: from firebird1.grc.nasa.gov (gr000630429.grc.nasa.gov [139.88.111. 69])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id j5T JShwb025707;Wed, 29 Jun 2005 15:28:43 -0400 (EDT) Received: by firebird1.grc.nasa.gov (Postfix, from userid 501)id 222E9302C7; Wed, 29 Jun 2005 15:28:15 -0400 (EDT) Date: Wed, 29 Jun 2005 15:28:15 -0400 From: Joseph Ishac To: ippm@ietf.org Message-ID: <20050629192815.GA13218@firebird1.grc.nasa.gov> Mail-Followup-To: ippm@ietf.org, "Chimento, Philip F." References: <20050623163637.GA30369@sunfire.grc.nasa.gov> <001101c57973$c437 5e10$6700a8c0@Trantor> <20050625142520.GA3597@sunfire.grc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050625142520.GA3597@sunfire.grc.nasa.gov> User-Agent: Mutt/1.4.2.1i X-imss-version: 2.25 X-imss-result: Passed X-imss-approveListMatch: *@*.NASA.GOV X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: "Chimento, Philip F." Subject: [ippm] Capacity Issue 01: Meaning of "correctly received" bits X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joseph Ishac List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Thanks to all who have commented thus far on the capacity draft. In addition to the notes sent to the list, we have received some feedback directly. I am going to try and summarize some of the more major issues that resulted from those discussions. Recently, another WG experimented with breaking down the issues into individual threads. That seemed to work well, so I'm going to attempt and employ the same technique for this draft. 1. Correctly received bits The current draft states that only correctly received bits at the destination will be counted towards the IP Layer Link Capacity. Our intent was to exclude bits that could not be properly handled at the IP layer (and thus reduces the capacity seen at that layer). Thus errors at the lower layers and packets that fail validation of the IP header (RFC 1812 for version 4) would not be counted. We did not intend that to imply that all bits in the IP packet would need to be "correct" as we are not concerned with what happens at the higher layers. Currently we plan on making the above clearer in the draft, and I believe that would satisfy most who have commented on this issue. -Joseph _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Jun 29 15:29:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DniFB-000193-VF; Wed, 29 Jun 2005 15:29:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DniFA-00018y-DZ for ippm@megatron.ietf.org; Wed, 29 Jun 2005 15:29:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28835 for ; Wed, 29 Jun 2005 15:29:06 -0400 (EDT) Received: from mx2.grc.nasa.gov ([128.156.11.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dniek-0003tb-LX for ippm@ietf.org; Wed, 29 Jun 2005 15:55:36 -0400 Received: from lombok-fi.grc.nasa.gov (seraph1.grc.nasa.gov [128.156.10.10]) by mx2.grc.nasa.gov (Postfix) with ESMTP id 9FC82C354 for ; Wed, 29 Jun 2005 15:28:56 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id j5TJSuGT026630; Wed, 29 Jun 2005 15:28:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id j5TJSuvb025827; Wed, 29 Jun 2005 15:28:56 -0400 (EDT) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.n asa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id 25528-02; Wed, 29 Jun 2005 15:28:55 -0400 (EDT) Received: from firebird1.grc.nasa.gov (gr000630429.grc.nasa.gov [139.88.111. 69])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id j5T JSsuV025814;Wed, 29 Jun 2005 15:28:54 -0400 (EDT) Received: by firebird1.grc.nasa.gov (Postfix, from userid 501)id EC522302C7; Wed, 29 Jun 2005 15:28:25 -0400 (EDT) Date: Wed, 29 Jun 2005 15:28:25 -0400 From: Joseph Ishac To: ippm@ietf.org Message-ID: <20050629192825.GB13218@firebird1.grc.nasa.gov> Mail-Followup-To: ippm@ietf.org, "Chimento, Philip F." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-imss-version: 2.25 X-imss-result: Passed X-imss-approveListMatch: *@*.NASA.GOV X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: "Chimento, Philip F." Subject: [ippm] Capacity Issue 02: Interval Specification and Boundary X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joseph Ishac List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org 2. Interval Specification and Boundary Currently, specification of the interval in the draft is vague in regard to what exactly the times T and I refer to and where they are measured from. The intent was that they are both measured at the receiver, where T is the start of an interval that lasts I units of time. Measuring from the receiver alleviates the concern for packets in flight and propagation delay. Thus, T does not specify a time at the sender S (such as the start of a transmission). Another issue was bounding the interval such that it falls on a packet boundary. Currently, no such restriction is in place. My opinion is that such a concern is very implementation specific. One logical implementation choice would be to start and stop measuring at packet boundaries. Perhaps a little text should be added stating that doing that would be a good idea? Please send thoughts to the list, as we will use the discussion to sharpen up the definitions so that they are clearer. -Joseph _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm