From ippm-bounces@ietf.org Mon May 02 07:49:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSZQI-0006PC-9c; Mon, 02 May 2005 07:49:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSWkW-0003lm-1G for ippm@megatron.ietf.org; Mon, 02 May 2005 04:57:56 -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 EAA15279 for ; Mon, 2 May 2005 04:57:54 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSWy9-0004tr-PL for ippm@ietf.org; Mon, 02 May 2005 05:12:02 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 2 May 2005 10:57:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 2 May 2005 10:57:52 +0200 Message-ID: Thread-Topic: traceroute metrics and traceroute storage issues Thread-Index: AcVL3rIRBUtHHkcVTneMKCgDxWlEiQDD5HAQ From: "STEPHAN Emile RD-CORE-LAN" To: "Henk Uijterwaal" , "Matthew J Zekauskas" X-OriginalArrivalTime: 02 May 2005 08:57:53.0537 (UTC) FILETIME=[06A52F10:01C54EF5] X-Spam-Score: 0.3 (/) X-Scan-Signature: 90f8d7cac99eccf384c4cdc57475e98c Cc: ippm@ietf.org Subject: [ippm] traceroute metrics and traceroute storage issues 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="===============0529528422==" Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org This is a multi-part message in MIME format. --===============0529528422== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C54EF5.067880A8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C54EF5.067880A8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Matt and Henk, =20 My opinion is that traceroute format and storage issues are not in the = scope of the IPPM WG. =20 I consider that traceroute metrics definitions issues are IPPM topics. = The draft (section 7) say that "Round-trip delay metrics, Connectivity = metrics, Loss metrics" are relevant metrics for traceroute. This section = should be enhanced and should detail the methodology.=20 =20 =20 Regards Emile =20 ________________________________ De : ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] De la part de = Carsten Schmoll Envoy=E9 : jeudi 28 avril 2005 12:36 =C0 : mallman@icir.org Cc : ippm@ietf.org Objet : Re: [ippm] traceroute as WG work item? =20 Dear Sandra, Mark, all, I think that it is a worthwhile attempt to focus traceroute output into = a=20 standards format. I further fully agree that it is vital to include more data into the information model than just the one that the traceroute command itself can deliver.=20 Allthough this topic cannot be seen as an urgent problem I think it is=20 worth contacting projects who already did work on putting traceroute=20 data into some (proprietary) database or other kind of storage. If these would join the work it could be really successful. Finally let me suggest that I'd vote for a human readable format, so there still would be the chance to work on results by using=20 scripts (even if it involves an XML paerser lib as well). If so then one importatnt step is also how to store multiple traceroute results together in one block of information in=20 a meaningful way. If this is achieved successfully, one can think about deriving a MIB or IPFIX template as well depending on the need of the community. At first though I agree that it is vital to find a critical mass of motivated people to put this action forward. Kind regards, Carsten. Mark Allman wrote: Hi Sandra- =20 =20 When you exchange measurements, you most probably want to have more precise information on how such measurements were carried out. Especially, I would like to know what options have been used to run the traceroute or what default values (e.g. Max-TTL value or Probe Data Size) are used by the specific traceroute. Such information would not be included with the three lines you = propose. =20 =20 Sure. Although, it easily could be. The lines were meant to convey the ease with which one can generate the right raw and meta data such that all this proposed effort boils down to is defining a format. =20 And, I agree with all of the above... that in some system for sharing folks have to define how the information is exchanged (at least how the meta-data is exchanged -- it is not clear to me that we need to re-encode actual measurements). I completely agree -- and have even published positions on such issues. I think it is vital work for the research community to share measurements. =20 So, let me try one more time to say that I don't think this work is harmful somehow. I just don't think it is a wonderfully compelling use of IETF resources either. And, I still very much worry about the energy level for this one (which seems to be basically nil within the WG). =20 Also note, that my strong argument for a detail of this scheme (e.g., XML vs. binary) should not be confused together with my high level feeling that this is not a hugely important IETF topic. =20 allman =20 =20 PS- I will also note that I am not the best judge of what is compelling IETF work. I think the IETF wastes a lot of effort on corners that either don't need to be worried about at all or can safely be worked out independent of the standards process. =20 =20 =20 =20 ________________________________ =20 _______________________________________________ ippm mailing list ippm@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ippm =20 --=20 "The difference between theory and practice is that in theory=20 theory and practice are the same but in practice they are not." =20 Dipl.Ing. Carsten Schmoll Fraunhofer Institute FOKUS carsten.schmoll@fokus.fraunhofer.de National Research Institute Fraunhofer FOKUS / dept. METEOR for Open Communication Systems Tel: +49-30-3463-7136 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8000 D-10589 Berlin, Germany ------_=_NextPart_001_01C54EF5.067880A8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Matt and Henk,

 

My opinion is that = traceroute format and storage issues are not in the scope of the IPPM = WG.

 

I consider that = traceroute metrics definitions issues are IPPM topics. The draft (section 7) say = that "Round-trip delay metrics, Connectivity metrics, Loss metrics" are relevant = metrics for traceroute. This section should be enhanced and should detail the = methodology.

 

 

Regards

Emile

 

De : ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] = De la part de Carsten Schmoll
Envoy=E9 : jeudi 28 = avril 2005 12:36
=C0 : = mallman@icir.org
Cc : = ippm@ietf.org
Objet : Re: [ippm] = traceroute as WG work item?

 


Dear Sandra, Mark, all,

I think that it is a worthwhile attempt to focus traceroute output into = a
standards format. I further fully agree that it is vital to include = more
data into the information model than just the one that the = traceroute
command itself can deliver.

Allthough this topic cannot be seen as an urgent problem I think it is =
worth contacting projects who already did work on putting traceroute =
data into some (proprietary) database or other kind of storage.

If these would join the work it could be really successful.

Finally let me suggest that I'd vote for a human readable format,
so there still would be the chance to work on results by using
scripts (even if it involves an XML paerser lib as well).

If so then one importatnt step is also how to store multiple
traceroute results together in one block of information in
a meaningful way. If this is achieved successfully, one can think
about deriving a MIB or IPFIX template as well depending on
the need of the community.

At first though I agree that it is vital to find a critical mass of
motivated people to put this action forward.

Kind regards,
Carsten.


Mark Allman wrote:

Hi Sandra-
 
=A0 
When you exchange measurements, you most =
probably want to have more
precise information on how such measurements =
were carried out.
Especially, I would like to know what options =
have been used to run the
traceroute or what default values (e.g. =
Max-TTL value or Probe Data
Size) are used by the specific =
traceroute.
Such information would not be included with =
the three lines you propose.
=A0=A0=A0 
 
Sure.=A0 Although, it easily could be.=A0 The =
lines were meant to convey the
ease with which one can generate the right =
raw and meta data such that
all this proposed effort boils down to is =
defining a format.
 
And, I agree with all of the above... that in =
some system for sharing
folks have to define how the information is =
exchanged (at least how the
meta-data is exchanged -- it is not clear to =
me that we need to
re-encode actual measurements).=A0 I =
completely agree -- and have even
published positions on such issues.=A0 I =
think it is vital work for the
research community to share =
measurements.
 
So, let me try one more time to say that I =
don't think this work is
harmful somehow.=A0 I just don't think it is =
a wonderfully compelling use
of IETF resources either.=A0 And, I still =
very much worry about the energy
level for this one (which seems to be =
basically nil within the WG).
 
Also note, that my strong argument for a =
detail of this scheme (e.g.,
XML vs. binary) should not be confused =
together with my high level
feeling that this is not a hugely important =
IETF topic.
 
allman
 
 
PS- I will also note that I am not the best =
judge of what is compelling
=A0=A0=A0 IETF work.=A0 I think the IETF =
wastes a lot of effort on corners that
=A0=A0=A0 either don't need to be worried =
about at all or can safely be worked
=A0=A0=A0 out independent of the standards =
process.
 
 
=A0 
 






 
______________________________________________=
_
ippm mailing =
list
ippm@ietf.org =

https://www1.ietf.or=
g/mailman/listinfo/ippm
=A0 



-- 
"The difference between theory and =
practice is that in theory 
=A0theory and practice are the same but in =
practice they are not."
 
Dipl.Ing. Carsten =
Schmoll=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Fraunhofer =
Institute FOKUS
carsten.schmoll@fokus=
.fraunhofer.de=A0=A0=A0=A0=A0 National Research =
Institute
Fraunhofer FOKUS / dept. =
METEOR=A0=A0=A0=A0=A0=A0=A0=A0=A0 for Open Communication =
Systems
Tel: =
+49-30-3463-7136=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
 Kaiserin-Augusta-Allee 31
Fax: =
+49-30-3463-8000=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
 D-10589 Berlin, Germany
------_=_NextPart_001_01C54EF5.067880A8-- --===============0529528422== 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 --===============0529528422==-- From ippm-bounces@ietf.org Wed May 18 17:21:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYVya-0003lm-CE; Wed, 18 May 2005 17:21:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYVyV-0003j2-Db; Wed, 18 May 2005 17:21:07 -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 RAA21858; Wed, 18 May 2005 17:21:04 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYWFX-0000cs-DA; Wed, 18 May 2005 17:38:43 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DYVyR-0001Dk-Lg; Wed, 18 May 2005 17:21:03 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 18 May 2005 17:21:03 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ippm@ietf.org Subject: [ippm] Last Call: 'A One-way Active Measurement Protocol (OWAMP)' to Proposed Standard X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org 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 The IESG has received a request from the IP Performance Metrics WG to consider the following document: - 'A One-way Active Measurement Protocol (OWAMP) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-06-01. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ippm-owdp-14.txt _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm