From ippm-bounces@ietf.org  Fri Apr  1 08:12:08 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22334
	for <ippm-archive@lists.ietf.org>; Fri, 1 Apr 2005 08:12:07 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DHLsy-0000Ft-4U; Fri, 01 Apr 2005 08:08:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DHLsx-0000Fo-0g
	for ippm@megatron.ietf.org; Fri, 01 Apr 2005 08:08:27 -0500
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 IAA22137
	for <ippm@ietf.org>; Fri, 1 Apr 2005 08:08:23 -0500 (EST)
Received: from p-mail2.rd.francetelecom.com ([195.101.245.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHM0G-0001DW-5c
	for ippm@ietf.org; Fri, 01 Apr 2005 08:16:01 -0500
Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by
	parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 1 Apr 2005 15:08:10 +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="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 1 Apr 2005 15:08:09 +0200
Message-ID: <DD8B8FEBBFAF9E488F63FF0F1A69EDD1F978C5@ftrdmel1.rd.francetelecom.fr>
Thread-Topic: middlebox metrics
Thread-Index: AcU13GVXouJJ5fywTHOtQyxxoY8/CAA0qBMQ
From: "STEPHAN Emile RD-CORE-LAN" <emile.stephan@francetelecom.com>
To: "Benoit Claise" <bclaise@cisco.com>,
        "Juergen Quittek" <quittek@netlab.nec.de>
X-OriginalArrivalTime: 01 Apr 2005 13:08:10.0205 (UTC)
	FILETIME=[DA78A0D0:01C536BB]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Content-Transfer-Encoding: quoted-printable
Cc: psamp@ops.ietf.org, ippm@ietf.org
Subject: [ippm] middlebox metrics
X-BeenThere: ippm@ietf.org 
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=subscribe>
Sender: ippm-bounces@ietf.org
Errors-To: ippm-bounces@ietf.org
Content-Transfer-Encoding: quoted-printable

Hi Benoit and Juergen,

<SNIP>
> >
> >It is clear that IPFIX is suitable to export binary data such as
> measurement results (either active or passive).
> >
> >Having common templates and clear metrics definitions is the only way
to
> increase the usability, interoperability and the scalability of the
> collecting part of measurement systems.
> >
> >
> Agreed on the clear metrics definitions, this is the IPPM WG job.

IPPM will probably be happy to do the job if PSAMP WG asks for it. What
is the position of PSAMP chairs?=20

Regards
Emile


_______________________________________________
ippm mailing list
ippm@ietf.org 
https://www1.ietf.org/mailman/listinfo/ippm


From ippm-bounces@ietf.org  Fri Apr  1 08:38:08 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25172
	for <ippm-archive@lists.ietf.org>; Fri, 1 Apr 2005 08:38:08 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DHMGW-0003YC-H4; Fri, 01 Apr 2005 08:32:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DHMGU-0003Y7-OT
	for ippm@megatron.ietf.org; Fri, 01 Apr 2005 08:32:47 -0500
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 IAA24583
	for <ippm@ietf.org>; Fri, 1 Apr 2005 08:32:43 -0500 (EST)
Received: from mailg.surrey.ac.uk ([131.227.102.21])
	by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DHMNo-0002C3-3B
	for ippm@ietf.org; Fri, 01 Apr 2005 08:40:21 -0500
Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP)
	with ESMTP; Fri, 1 Apr 2005 14:31:14 +0100
Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136])
	by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211);
	Fri, 1 Apr 2005 14:31:12 +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 ;
	Fri,  1 Apr 2005 13:31:11 +0000
Received: from ccsrlt31 by evs-ec1-node1.surrey.ac.uk;
	01 Apr 2005 14:31:11 +0100
Subject: Re: [ippm] question on the reordering draft 09
From: Lei Liang <L.Liang@surrey.ac.uk>
To: Al Morton <acmorton@att.com>
In-Reply-To: <6.0.3.0.0.20050331133807.06374eb0@custsla.mt.att.com>
References: <1112286509.8586.52.camel@ccsrlt31.ee.surrey.ac.uk>
	<6.0.3.0.0.20050331133807.06374eb0@custsla.mt.att.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1112362271.10500.7.camel@ccsrlt31.ee.surrey.ac.uk>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6
Date: Fri, 01 Apr 2005 14:31:11 +0100
X-OriginalArrivalTime: 01 Apr 2005 13:31:12.0103 (UTC)
	FILETIME=[12258770:01C536BF]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Content-Transfer-Encoding: 7bit
Cc: Lei Liang <L.Liang@eim.surrey.ac.uk>, ippm@ietf.org
X-BeenThere: ippm@ietf.org 
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=subscribe>
Sender: ippm-bounces@ietf.org
Errors-To: ippm-bounces@ietf.org
Content-Transfer-Encoding: 7bit

Hi, Al,
  Thanks for your quick explanation. the definition of the NextExp is
clear enough in the draft. the only thing I suggest is to clarify that S
and NextExp that are going to be compared are not associated to the same
packet but two subsequently received packets at destination.

cheers,
Lei

On Thu, 2005-03-31 at 20:03, Al Morton wrote:
> Lei,
> Thanks for your comment, see below:
> 
> At 11:28 AM 03/31/2005, Lei Liang wrote:
> >Dear all,
> >   I am confused when reading the definition of the Type-P-Reordered
> >(part 3.3) when it talks about the reordered and in-order. It says:
> >
> >   The value of Type-P-Reordered is defined as TRUE if s < NextExp (the
> >packet is reordered).
> >
> >    The value of Type-P-Reordered is defined as FALSE if s >= NextExp
> >    (the packet is in-order).
> 
> Both paragraphs above go on to say how to determine NextExp so that
> the next arriving packet can be evaluated.
> 
> >Then, as I understand it says a packet with sequence number S < the
> >expected sequence number of the following packet should be reordered.
> >the example can be given as a packet with sequence number of 3 and NextExp
> >of 4 is not in order???? it doesn't make sense.
> 
> Right, it doesn't make sense to calculate NextExp using the
> packet that you are trying to evaluate. Whether or not NextExp is
> re-calculated is conditioned on the outcome of the s to NextExp
> comparison. So the sentences you left out above are very important.
> 
> >or, it means that the sequence number s should be compared with the
> >NextExp number of the previous packet.
> 
> Yes, that's what we said when introducing the "next expected" concept in
> Section 3.0.
> 
> >then the example becomes as a packet
> >with sequence number of 3 is not in order because the previous packet has a
> >metric parameter NextExp=4. this make sense.
> >Seems to me, the two explanations can both fit the definition. And I suggest
> >to stress the NextExp in the definition to clarify that it's belong to the
> >previous packet rather than the current measured one.
> >cheers,
> >lei Liang
> 
> Will this help you (added second sentence)?
> 
> +  NextExp, the Next Expected Sequence number at the Destination,
>     in units of messages. This stored value in NextExp is determined
>     from a previously arriving packet.
> 
> Al
> 
> 
> _______________________________________________
> 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  Fri Apr  1 18:34:43 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03882
	for <ippm-archive@lists.ietf.org>; Fri, 1 Apr 2005 18:34:43 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DHVcL-0005xK-8l; Fri, 01 Apr 2005 18:31:57 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DHVcH-0005xC-QS
	for ippm@megatron.ietf.org; Fri, 01 Apr 2005 18:31:55 -0500
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 SAA03666
	for <ippm@ietf.org>; Fri, 1 Apr 2005 18:31:50 -0500 (EST)
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 1DHVjh-0004H0-Bg
	for ippm@ietf.org; Fri, 01 Apr 2005 18:39:33 -0500
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
	j31NVpS1293212 for <ippm@ietf.org>; Fri, 1 Apr 2005 16:31:51 -0700
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 j31NVof28102
	for <ippm@ietf.org>; Fri, 1 Apr 2005 16:31:51 -0700 (MST)
Message-ID: <424DD9E6.6050901@engr.colostate.edu>
Date: Fri, 01 Apr 2005 16:31:50 -0700
From: "Nischal M. Piratla" <nischal@engr.colostate.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.6) Gecko/20050319
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ippm@ietf.org
Subject: Re: [ippm] RD and TCP retransmit analysis
References: <4238BFF9@webmail.colostate.edu>
	<6.0.3.0.0.20050328093229.05e140b0@custsla.mt.att.com>
In-Reply-To: <6.0.3.0.0.20050328093229.05e140b0@custsla.mt.att.com>
X-Spam-Score: 1.0 (+)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6
X-BeenThere: ippm@ietf.org 
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1536534814=="
Sender: ippm-bounces@ietf.org
Errors-To: ippm-bounces@ietf.org

This is a multi-part message in MIME format.
--===============1536534814==
Content-Type: multipart/alternative;
	boundary="------------060307030006060109090004"

This is a multi-part message in MIME format.
--------------060307030006060109090004
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Al Morton wrote:

> Consider this example:
> Arrivals:            1   4   5   6   7   3   2
> ACKs:                   2   2  2   2  2   2
> Receive_index:       1   2   3   4   5   6   7
> Displacement:        0  -2  -2  -2  -2   3   5
>
> Is this an example of one of the circumstances you've excluded?
> (with the following sentence)
>
>> In addition, if a packet is reordered then the following packets
>> in the sequence are not reordered with same or higher displacement.
>
No, there is always a duplicate ACK per packet after an out-of-order 
arrival. So, 2 will be retransmitted after 3rd duplicate ACK arrives, 
i.e., retransmitted packet arrives after 6. Thus, there is no packet 
with displacement greater than 3 before packet with sequence number 2.

>
> In any case, how many arrivals must occur before Displacement
> can be evaluated again?
> IOW, the condition quoted above may also exclude this case:
> Arrivals:  1 3 4 5 6 2 7 9 10 11 12 8
> Displacement:        4              4
> but this seems to be a case where there may be two re-transmissions.
>
Again, per packet ACK after an out-of-order answers this concern.

> We have not placed strong requirements like this on the measured
> stream in the past, and this one appears to need some refinement.

Unless, I am mistaken there was no such explicit analysis for any of the 
metrics. So, I am not sure what it means when you say we have not placed 
strong requirements in the past. This analysis was made taking 
statements from RFC 2581 and RFC 1122 into consideration. However, we 
will  welcome your comments/suggestions on any refinements, if you feel 
are necessary.
- Nischal

--------------060307030006060109090004
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
Al Morton wrote:
<blockquote
 cite="mid6.0.3.0.0.20050328093229.05e140b0@custsla.mt.att.com"
 type="cite">Consider this example: <br>
Arrivals:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp; 4&nbsp;&nbsp; 5&nbsp;&nbsp; 6&nbsp;&nbsp; 7&nbsp;&nbsp; 3&nbsp;&nbsp; 2 <br>
ACKs:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2&nbsp;&nbsp; 2&nbsp; 2&nbsp;&nbsp; 2&nbsp; 2&nbsp;&nbsp; 2 <br>
Receive_index:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp; 2&nbsp;&nbsp; 3&nbsp;&nbsp; 4&nbsp;&nbsp; 5&nbsp;&nbsp; 6&nbsp;&nbsp; 7 <br>
Displacement:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp; -2&nbsp; -2&nbsp; -2&nbsp; -2&nbsp;&nbsp; 3&nbsp;&nbsp; 5 <br>
  <br>
Is this an example of one of the circumstances you've excluded? <br>
(with the following sentence) <br>
  <blockquote type="cite">In addition, if a packet is reordered then
the following packets <br>
in the sequence are not reordered with same or higher displacement. <br>
  </blockquote>
</blockquote>
No, there is always a duplicate ACK per packet after an out-of-order
arrival.
So, 2 will be retransmitted after 3rd duplicate ACK arrives, i.e.,
retransmitted packet arrives after 6. Thus, there is
no packet with displacement greater than 3 before packet with sequence
number 2.<br>
<blockquote
 cite="mid6.0.3.0.0.20050328093229.05e140b0@custsla.mt.att.com"
 type="cite"><br>
In any case, how many arrivals must occur before Displacement <br>
can be evaluated again? <br>
IOW, the condition quoted above may also exclude this case: <br>
Arrivals:&nbsp; 1 3 4 5 6 2 7 9 10 11 12 8 <br>
Displacement:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4 <br>
but this seems to be a case where there may be two re-transmissions. <br>
  <br>
</blockquote>
Again, per packet ACK after an out-of-order answers this concern.<br>
<blockquote
 cite="mid6.0.3.0.0.20050328093229.05e140b0@custsla.mt.att.com"
 type="cite">We have not placed strong requirements like this on the
measured <br>
stream in the past, and this one appears to need some refinement. <br>
</blockquote>
Unless, I am mistaken there was no such explicit analysis for any of
the metrics. So, I am not sure what it means when you say we have not
placed strong requirements in the past. This analysis was made taking
statements from RFC 2581 and RFC 1122 into consideration. However, we
will&nbsp; welcome your comments/suggestions on any refinements, if you feel
are necessary.<br>
- Nischal<br>
</body>
</html>

--------------060307030006060109090004--


--===============1536534814==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
ippm mailing list
ippm@ietf.org 
https://www1.ietf.org/mailman/listinfo/ippm

--===============1536534814==--



From ippm-bounces@ietf.org  Fri Apr  1 19:19:28 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06252
	for <ippm-archive@lists.ietf.org>; Fri, 1 Apr 2005 19:19:28 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DHWJ7-0005Wp-In; Fri, 01 Apr 2005 19:16:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DHWJ5-0005Wk-UU
	for ippm@megatron.ietf.org; Fri, 01 Apr 2005 19:16:08 -0500
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 TAA06066
	for <ippm@ietf.org>; Fri, 1 Apr 2005 19:16:04 -0500 (EST)
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 1DHWQW-0005fL-7W
	for ippm@ietf.org; Fri, 01 Apr 2005 19:23:48 -0500
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
	j320G6S1565378 for <ippm@ietf.org>; Fri, 1 Apr 2005 17:16:06 -0700
Received: from webmail.colostate.edu (csunts4.acns.colostate.edu
	[129.82.100.135])
	by engr.colostate.edu (8.11.7p1+Sun/8.11.7) with ESMTP id j320G5f08197
	for <ippm@ietf.org>; Fri, 1 Apr 2005 17:16:05 -0700 (MST)
X-WebMail-UserID: nischal@mail.engr.colostate.edu
Date: Fri, 1 Apr 2005 17:16:05 -0700
From: Nischal M Piratla <nischal@engr.colostate.edu>
To: ippm@ietf.org
X-EXP32-SerialNo: 00002247, 00002264
Subject: RE: [ippm] RD and TCP retransmit analysis
Message-ID: <42A92359@webmail.colostate.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: Infinite Mobile Delivery (Hydra) SMTP v3.62.01
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Content-Transfer-Encoding: 7bit
X-BeenThere: ippm@ietf.org 
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=subscribe>
Sender: ippm-bounces@ietf.org
Errors-To: ippm-bounces@ietf.org
Content-Transfer-Encoding: 7bit

I wanted to add this line in my response:
TCP retransmit analysis for any metric may not be useful as Mark Allman and 
others are working on this very interesting draft:
draft-ietf-tcpm-tcp-dcr-03.txt
- Nischal

>===== Original Message From "Nischal M. Piratla" <nischal@engr.colostate.edu> 
=====
>Al Morton wrote:
>
>> Consider this example:
>> Arrivals:            1   4   5   6   7   3   2
>> ACKs:                   2   2  2   2  2   2
>> Receive_index:       1   2   3   4   5   6   7
>> Displacement:        0  -2  -2  -2  -2   3   5
>>
>> Is this an example of one of the circumstances you've excluded?
>> (with the following sentence)
>>
>>> In addition, if a packet is reordered then the following packets
>>> in the sequence are not reordered with same or higher displacement.
>>
>No, there is always a duplicate ACK per packet after an out-of-order
>arrival. So, 2 will be retransmitted after 3rd duplicate ACK arrives,
>i.e., retransmitted packet arrives after 6. Thus, there is no packet
>with displacement greater than 3 before packet with sequence number 2.
>
>>
>> In any case, how many arrivals must occur before Displacement
>> can be evaluated again?
>> IOW, the condition quoted above may also exclude this case:
>> Arrivals:  1 3 4 5 6 2 7 9 10 11 12 8
>> Displacement:        4              4
>> but this seems to be a case where there may be two re-transmissions.
>>
>Again, per packet ACK after an out-of-order answers this concern.
>
>> We have not placed strong requirements like this on the measured
>> stream in the past, and this one appears to need some refinement.
>
>Unless, I am mistaken there was no such explicit analysis for any of the
>metrics. So, I am not sure what it means when you say we have not placed
>strong requirements in the past. This analysis was made taking
>statements from RFC 2581 and RFC 1122 into consideration. However, we
>will  welcome your comments/suggestions on any refinements, if you feel
>are necessary.
>- Nischal
>
>
>_______________________________________________
>ippm mailing list
>ippm@ietf.org
>https://www1.ietf.org/mailman/listinfo/ippm

****************************************************
Research Assistant
Computer Networking Research Laboratory (CNRL)
C203,Dept. of Electrical & Computer Eng.
Colorado State University,
Fort Collins, CO 80523
Voice: 970-491-7067/7794
Fax:   970-491-2249
http://www.cnrl.colostate.edu
http://lamar.colostate.edu/~nischal
****************************************************


_______________________________________________
ippm mailing list
ippm@ietf.org 
https://www1.ietf.org/mailman/listinfo/ippm


From ippm-bounces@ietf.org  Fri Apr  1 23:41:11 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25962
	for <ippm-archive@lists.ietf.org>; Fri, 1 Apr 2005 23:41:11 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DHaP3-0006tj-5d; Fri, 01 Apr 2005 23:38:33 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DHaP1-0006tb-AA
	for ippm@megatron.ietf.org; Fri, 01 Apr 2005 23:38:31 -0500
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 XAA25800
	for <ippm@ietf.org>; Fri, 1 Apr 2005 23:38:24 -0500 (EST)
Received: from kcmso2.att.com ([192.128.134.71] helo=kcmso2.proxy.att.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHaWP-0008HX-A2
	for ippm@ietf.org; Fri, 01 Apr 2005 23:46:09 -0500
Received: from attrh2i.attrh.att.com ([135.37.94.56])
	by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id
	j324bVOl004181 for <ippm@ietf.org>; Fri, 1 Apr 2005 22:38:14 -0600
Received: from custsla.mt.att.com (135.21.14.109) by attrh2i.attrh.att.com
	(7.2.052)
	id 42477D25000D0325 for ippm@ietf.org; Fri, 1 Apr 2005 23:38:14 -0500
Received: from acmortonw.att.com ([135.210.8.87])
	by custsla.mt.att.com (8.10.2+Sun/8.10.2) with ESMTP id j324cDZ20302
	for <ippm@ietf.org>; Fri, 1 Apr 2005 23:38:13 -0500 (EST)
Message-Id: <6.0.3.0.0.20050401204039.05accab0@custsla.mt.att.com>
X-Sender: acm@custsla.mt.att.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0
Date: Fri, 01 Apr 2005 23:36:57 -0500
To: ippm@ietf.org
From: Al Morton <acmorton@att.com>
Subject: Re: [ippm] RD and TCP retransmit analysis
In-Reply-To: <424DD9E6.6050901@engr.colostate.edu>
References: <4238BFF9@webmail.colostate.edu>
	<6.0.3.0.0.20050328093229.05e140b0@custsla.mt.att.com>
	<424DD9E6.6050901@engr.colostate.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
X-BeenThere: ippm@ietf.org 
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=subscribe>
Sender: ippm-bounces@ietf.org
Errors-To: ippm-bounces@ietf.org

This last message talks about how TCP works,
but it doesn't really address the issue of an unclear
requirement on the packet stream.  Worse, you
now seem to be changing the definition used
to detect unnecessary re-transmissions using RD.

At 05:02 PM 03/11/2005, Nischal M Piratla wrote:
>Thus, the displacement (according to RD definitions) is greater than 2 for
>retransmitted packets.
>Therefore, "Sum of (all RD[k] for k >= 2) corresponds to fraction of packets
>that is unnecessarily retransmitted."

I created an example containing two closely spaced packets
with displacement > 2 (3 and 5). The metric above seems to
predict two re-transmissions where only one would occur,
unless some clarified version of the requirement on reordered
packets in the stream came into play.

But then,

>Thus, there is no packet with displacement greater than 3
>before packet with sequence number 2.

Ideally, there would be no requirements on the reordering of
the packet stream for the metric to be valid
(beyond "stream must be possible on a real network" of course).

There hasn't been much productive exchange in any of these
RD/RBD threads, IMO.  I invested time to re-read the
draft and offer what I thought were clear comments,
only to precipitate evasive stuff like this.
I'm not convinced there is value in pursuing this further.

Al

At 06:31 PM 04/01/2005, Nischal M. Piratla wrote:
>Al Morton wrote:
>>Consider this example:
>>Arrivals:            1   4   5   6   7   3   2
>>ACKs:                   2   2   2   2   2   2
>>Receive_index:       1   2   3   4   5   6   7
>>Displacement:        0  -2  -2  -2  -2   3   5
>>
>>Is this an example of one of the circumstances you've excluded?
>>(with the following sentence)
>>>In addition, if a packet is reordered then the following packets
>>>in the sequence are not reordered with same or higher displacement.
>No, there is always a duplicate ACK per packet after an out-of-order 
>arrival. So, 2 will be retransmitted after 3rd duplicate ACK arrives, 
>i.e., retransmitted packet arrives after 6. Thus, there is no packet with 
>displacement greater than 3 before packet with sequence number 2.
>>
>>In any case, how many arrivals must occur before Displacement
>>can be evaluated again?
>>IOW, the condition quoted above may also exclude this case:
>>Arrivals:  1 3 4 5 6 2 7 9 10 11 12 8
>>Displacement:        4              4
>>but this seems to be a case where there may be two re-transmissions.
>Again, per packet ACK after an out-of-order answers this concern.
>>We have not placed strong requirements like this on the measured
>>stream in the past, and this one appears to need some refinement.
>Unless, I am mistaken there was no such explicit analysis for any of the 
>metrics. So, I am not sure what it means when you say we have not placed 
>strong requirements in the past. This analysis was made taking statements 
>from RFC 2581 and RFC 1122 into consideration. However, we will  welcome 
>your comments/suggestions on any refinements, if you feel are necessary.
>- Nischal
>_______________________________________________
>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  Fri Apr  8 05:08:47 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20694
	for <ippm-archive@lists.ietf.org>; Fri, 8 Apr 2005 05:08:47 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJpSZ-0005MU-DN; Fri, 08 Apr 2005 05:07:28 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJpRV-0005IC-JS
	for ippm@megatron.ietf.org; Fri, 08 Apr 2005 05:06:21 -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 FAB20525
	for <ippm@ietf.org>; Fri, 8 Apr 2005 05:06:19 -0400 (EDT)
Received: from basie.internet2.edu ([207.75.164.22])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJpaD-0008M7-TU
	for ippm@ietf.org; Fri, 08 Apr 2005 05:15:23 -0400
Received: from localhost (unknown [127.0.0.1])
	by basie.internet2.edu (Postfix) with ESMTP
	id BBF011CD8A9; Fri,  8 Apr 2005 05:06:14 -0400 (EDT)
Received: from basie.internet2.edu ([127.0.0.1])
	by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 22723-06; Fri,  8 Apr 2005 05:06:14 -0400 (EDT)
Received: from BMW (unknown [127.0.0.1])
	by basie.internet2.edu (Postfix) with ESMTP
	id 5EBEE1CD85E; Fri,  8 Apr 2005 05:06:14 -0400 (EDT)
Date: Fri, 08 Apr 2005 05:06:13 -0400
From: Matthew J Zekauskas <matt@internet2.edu>
To: ippm@ietf.org
Message-ID: <742E933A19D457523CB875A2@DCFF15AFC1F6764BA3927E50>
X-Mailer: Mulberry/3.1.3 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by mail.internet2.edu virus scanner
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Content-Transfer-Encoding: 7bit
Cc: Henk Uijterwaal <henk@ripe.net>, Matt Zekauskas <matt@internet2.edu>
Subject: [ippm] minutes from the IPPM meeting at IETF62 in Minneapolis
X-BeenThere: ippm@ietf.org 
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=subscribe>
Sender: ippm-bounces@ietf.org
Errors-To: ippm-bounces@ietf.org
Content-Transfer-Encoding: 7bit

Draft minutes are now available along with a pointer to the audio
record and all presentations off of
<http://people.internet2.edu/~matt/IPPM/Meetings/ietf62/> .

Theoretically, they are due at 5pm ET 8-April-05.  If you have
any comments or changes, please send them to the chairs ASAP.

Thanks,

--Matt

_______________________________________________
ippm mailing list
ippm@ietf.org 
https://www1.ietf.org/mailman/listinfo/ippm


From ippm-bounces@ietf.org  Thu Apr 14 09:12:15 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09741
	for <ippm-archive@lists.ietf.org>; Thu, 14 Apr 2005 09:12:15 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DM42F-0003n1-Vi; Thu, 14 Apr 2005 09:05:31 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DM42F-0003gK-3N
	for ippm@megatron.ietf.org; Thu, 14 Apr 2005 09:05:31 -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 JAA09307
	for <ippm@ietf.org>; Thu, 14 Apr 2005 09:05:21 -0400 (EDT)
Received: from kcmso2.att.com ([192.128.134.71] helo=kcmso2.proxy.att.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM4C1-0006K5-Qg
	for ippm@ietf.org; Thu, 14 Apr 2005 09:15:42 -0400
Received: from attrh2i.attrh.att.com ([135.37.94.56])
	by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id
	j3ED51N6004460 for <ippm@ietf.org>; Thu, 14 Apr 2005 08:05:05 -0500
Received: from custsla.mt.att.com (135.21.14.109) by attrh2i.attrh.att.com
	(7.2.052) id 42477D25002A1184; Thu, 14 Apr 2005 09:05:03 -0400
Received: from acmortonw.att.com ([135.25.188.52])
	by custsla.mt.att.com (8.10.2+Sun/8.10.2) with ESMTP id j3ED51Z25588;
	Thu, 14 Apr 2005 09:05:01 -0400 (EDT)
Message-Id: <6.0.3.0.0.20050412093405.057f4820@custsla.mt.att.com>
X-Sender: acm@custsla.mt.att.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0
Date: Thu, 14 Apr 2005 09:04:59 -0400
To: ippm@ietf.org
From: Al Morton <acmorton@att.com>
Subject: Re: [ippm] Proposed new work items for the group
In-Reply-To: <6.2.0.14.2.20050308182609.02cc07b0@localhost>
References: <6.2.0.14.2.20050308182609.02cc07b0@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: Henk Uijterwaal <henk@ripe.net>, Matthew J Zekauskas <matt@internet2.edu>
X-BeenThere: ippm@ietf.org 
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=subscribe>
Sender: ippm-bounces@ietf.org
Errors-To: ippm-bounces@ietf.org

At 01:26 PM 03/08/2005, Henk Uijterwaal wrote:
>Following the discussion at our meeting yesterday, we would like to ask
>the group if
>  * draft-stefan-ippm-multimetrics-00.txt
>...
>should become working group items.

I looked at the draft on spatial and multicast metrics again,
and it seems to be worthwhile to take up as a work item.

I understand that these two metric categories were once in separate
drafts, but IMO they might be unified somewhat more
by using a general selection convention.
Something like a list of "measurement points-of-interest"
could serve both the spatial metrics and one-to-group metrics,
and facilitate collecting both types at once.
(I'll take this point up off-list with the authors).

A couple of comments so far:

On Type-P-Spatial-One-way-Delay-Stream (and the other Spatial
metrics), I think you could drop "Stream" for consistency with
earlier sample metrics (for example, where a Poisson Stream
of packets produced the sample).
Although this metric produces multiple values (see section 4.1.4),
I think this is really the -Spatial-One-way-Delay *Singleton*.
A packet traversing the Src-Dst path results in a set of delays
as defined here, including the Type-P-One-way-Delay singleton, dT.
This seems to be the "atomic" level of spatial metrics.

I understand that the spatial and multicast metrics have a
single Source packet in common.  However, there are
other widely used topologies, such as group-to-one and
group-to-group, and they require multiple Source packets
(potentially launched at different times). There would be
a set of "derived metrics" (as RFC 2330 defined) to address
the other topologies.

So, a different draft & proposal would be needed to address
other multi-point topologies, right?

Al


_______________________________________________
ippm mailing list
ippm@ietf.org 
https://www1.ietf.org/mailman/listinfo/ippm


From ippm-bounces@ietf.org  Thu Apr 14 10:30:18 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18848
	for <ippm-archive@lists.ietf.org>; Thu, 14 Apr 2005 10:30:18 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DM5Il-0002PT-7W; Thu, 14 Apr 2005 10:26:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DM5Ij-0002NK-Dt
	for ippm@megatron.ietf.org; Thu, 14 Apr 2005 10:26:37 -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 KAA18436
	for <ippm@ietf.org>; Thu, 14 Apr 2005 10:26:27 -0400 (EDT)
Received: from mailg.surrey.ac.uk ([131.227.102.21])
	by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DM5Sb-0001f0-L2
	for ippm@ietf.org; Thu, 14 Apr 2005 10:36:50 -0400
Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP)
	with ESMTP; Thu, 14 Apr 2005 15:11:04 +0100
Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136])
	by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 14 Apr 2005 15:11: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 ;
	Thu, 14 Apr 2005 14:11:02 +0000
Received: from ccsrlt31 by evs-ec1-node1.surrey.ac.uk;
	14 Apr 2005 15:11:02 +0100
Subject: Re: [ippm] Proposed new work items for the group
From: Lei Liang <L.Liang@surrey.ac.uk>
To: Al Morton <acmorton@att.com>
In-Reply-To: <6.0.3.0.0.20050412093405.057f4820@custsla.mt.att.com>
References: <6.2.0.14.2.20050308182609.02cc07b0@localhost>
	<6.0.3.0.0.20050412093405.057f4820@custsla.mt.att.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1113487862.2094.6.camel@ccsrlt31.ee.surrey.ac.uk>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6
Date: Thu, 14 Apr 2005 15:11:02 +0100
X-OriginalArrivalTime: 14 Apr 2005 14:11:03.0068 (UTC)
	FILETIME=[CAA495C0:01C540FB]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Content-Transfer-Encoding: 7bit
Cc: Henk Uijterwaal <henk@ripe.net>, Matthew J Zekauskas <matt@internet2.edu>,
        ippm@ietf.org
X-BeenThere: ippm@ietf.org 
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=subscribe>
Sender: ippm-bounces@ietf.org
Errors-To: ippm-bounces@ietf.org
Content-Transfer-Encoding: 7bit

Dear Al, 
  Thank you very much for your comments. The "measurement
points-of-interest" could be a good idea to summarize the comment parts
between the spatial and multicast metrics. We will be very happy to hear
your further comments on it. 
Regarding the comments on topologies, as you said, we might add a
section in the draft to indicate the possible solutoins with concern of
the multiparty communications. 

Best regards,
Lei Liang

On Thu, 2005-04-14 at 14:04, Al Morton wrote:
> At 01:26 PM 03/08/2005, Henk Uijterwaal wrote:
> >Following the discussion at our meeting yesterday, we would like to ask
> >the group if
> >  * draft-stefan-ippm-multimetrics-00.txt
> >...
> >should become working group items.
> 
> I looked at the draft on spatial and multicast metrics again,
> and it seems to be worthwhile to take up as a work item.
> 
> I understand that these two metric categories were once in separate
> drafts, but IMO they might be unified somewhat more
> by using a general selection convention.
> Something like a list of "measurement points-of-interest"
> could serve both the spatial metrics and one-to-group metrics,
> and facilitate collecting both types at once.
> (I'll take this point up off-list with the authors).
> 
> A couple of comments so far:
> 
> On Type-P-Spatial-One-way-Delay-Stream (and the other Spatial
> metrics), I think you could drop "Stream" for consistency with
> earlier sample metrics (for example, where a Poisson Stream
> of packets produced the sample).
> Although this metric produces multiple values (see section 4.1.4),
> I think this is really the -Spatial-One-way-Delay *Singleton*.
> A packet traversing the Src-Dst path results in a set of delays
> as defined here, including the Type-P-One-way-Delay singleton, dT.
> This seems to be the "atomic" level of spatial metrics.
> 
> I understand that the spatial and multicast metrics have a
> single Source packet in common.  However, there are
> other widely used topologies, such as group-to-one and
> group-to-group, and they require multiple Source packets
> (potentially launched at different times). There would be
> a set of "derived metrics" (as RFC 2330 defined) to address
> the other topologies.
> 
> So, a different draft & proposal would be needed to address
> other multi-point topologies, right?
> 
> Al
> 
> 
> _______________________________________________
> 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 Apr 16 15:16:58 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMsmn-0006wG-VI; Sat, 16 Apr 2005 15:16:57 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMsml-0006up-91
	for ippm@megatron.ietf.org; Sat, 16 Apr 2005 15:16:55 -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 PAA26737
	for <ippm@ietf.org>; Sat, 16 Apr 2005 15:16:50 -0400 (EDT)
Received: from wyvern.icir.org ([192.150.187.14])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMrin-0007NH-Dh
	for ippm@ietf.org; Sat, 16 Apr 2005 14:08:47 -0400
Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net
	[68.76.113.50])
	by wyvern.icir.org (8.12.11/8.12.8) with ESMTP id j3GHvmwv085650;
	Sat, 16 Apr 2005 10:57:49 -0700 (PDT)
	(envelope-from mallman@icir.org)
Received: from lawyers.icir.org (guns.icir.org [68.76.113.50])
	by guns.icir.org (Postfix) with ESMTP
	id 4C47D77AC26; Sat, 16 Apr 2005 13:57:47 -0400 (EDT)
Received: from lawyers.icir.org (localhost [127.0.0.1])
	by lawyers.icir.org (Postfix) with ESMTP
	id AB16825ED2D; Sat, 16 Apr 2005 13:57:47 -0400 (EDT)
To: Juergen Quittek <quittek@netlab.nec.de>
From: Mark Allman <mallman@icir.org>
Subject: Re: [ippm] traceroute as WG work item? 
In-Reply-To: <977D8FE25543262C718BA2E3@[10.1.1.171]> 
Organization: ICSI Center for Internet Research (ICIR)
Song-of-the-Day: Money
MIME-Version: 1.0
Date: Sat, 16 Apr 2005 13:57:47 -0400
Message-Id: <20050416175747.AB16825ED2D@lawyers.icir.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Cc: ippm@ietf.org
X-BeenThere: ippm@ietf.org 
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: mallman@icir.org
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0512821993=="
Sender: ippm-bounces@ietf.org 
Errors-To: ippm-bounces@ietf.org 

--===============0512821993==
Content-Type: multipart/signed; boundary="=_bOundary";
	micalg=pgp-sha1; protocol="application/pgp-signature"

--=_bOundary
Content-Type: text/plain


I am late (as usual), sorry.

> Therefore I propose that this becomes an IPPM WG work item.
> Any comment, pro or con, is very welcome.

I don't see this as work that the IETF needs to be worried about.  It is
certainly important for your project (data warehouse) that everyone
understands the input and output formats for traceroute (etc.)
measurements.  And, so you need to write it down.  But, I don't see it
as necessitating an internet standard of some sort.  It's just a data
format.  We don't make an internet standard out of ppt even though lots
of us exchange that.  Or, of excel --- which we do use to store / share
data.  Or, libpcap.  Or, ...  It just seems to me like something that
the IETF doesn't need to get its fingers all over.  In any case ... it
would probably be much better done if a half-dozen people just did
something reasonable in an afternoon (and then wrote a few easy tools
that they could share) rather than an IETF WG taking a couple years to
haggle over it.

But, then again my sense of what the IETF should be doing isn't really
in alignment with the rest of the world's sense these days.  So, YMMV.

allman


-- 
Mark Allman -- ICIR -- http://www.icir.org/mallman/




--=_bOundary
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)

iD8DBQFCYVIbWyrrWs4yIs4RAqnIAJ94BG11d9Gs4Dc/8sodtAJYANzPDwCfT6yi
DR0IN5gtMANskUJeD2FqSLY=
=jzIp
-----END PGP SIGNATURE-----
--=_bOundary--


--===============0512821993==
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

--===============0512821993==--




From ippm-bounces@ietf.org Mon Apr 18 08:01:32 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNUwW-0003uq-QW; Mon, 18 Apr 2005 08:01:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNUwU-0003uE-SZ
	for ippm@megatron.ietf.org; Mon, 18 Apr 2005 08:01:31 -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 IAA11615
	for <ippm@ietf.org>; Mon, 18 Apr 2005 08:01:29 -0400 (EDT)
Received: from postman.ripe.net ([193.0.0.199])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNV7I-0001DV-Rs
	for ippm@ietf.org; Mon, 18 Apr 2005 08:12:41 -0400
Received: by postman.ripe.net (Postfix, from userid 8)
	id C952A24BB0; Mon, 18 Apr 2005 14:01:11 +0200 (CEST)
Received: from birch.ripe.net (birch.ripe.net [193.0.1.96])
	by postman.ripe.net (Postfix) with ESMTP id CC96725060;
	Mon, 18 Apr 2005 14:01:09 +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 j3IC18eu023774;
	Mon, 18 Apr 2005 14:01:09 +0200
Message-Id: <6.2.0.14.2.20050418131701.02c63590@localhost>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Mon, 18 Apr 2005 14:00:41 +0200
To: mallman@icir.org, Juergen Quittek <quittek@netlab.nec.de>
From: Henk Uijterwaal <henk@ripe.net>
Subject: Re: [ippm] traceroute as WG work item? 
In-Reply-To: <20050416175747.AB16825ED2D@lawyers.icir.org>
References: <977D8FE25543262C718BA2E3@[10.1.1.171]>
	<20050416175747.AB16825ED2D@lawyers.icir.org>
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: 10cb6e3b257997c08a622d5cdb558535
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=subscribe>
Sender: ippm-bounces@ietf.org 
Errors-To: ippm-bounces@ietf.org 

At 19:57 16/04/2005, Mark Allman wrote:
>I am late (as usual), sorry.

As the WG chair:  No, comments on this topic are still welcome,
until 29/4.

> > Therefore I propose that this becomes an IPPM WG work item.
> > Any comment, pro or con, is very welcome.
>
>I don't see this as work that the IETF needs to be worried about.  It is
>certainly important for your project (data warehouse) that everyone
>understands the input and output formats for traceroute (etc.)
>measurements.  And, so you need to write it down.  But, I don't see it
>as necessitating an internet standard of some sort.

Speaking as myself.  I've spend more time than I care to remember
writing scripts to convert the data from one set into the format used
by another, in order to merge results.  It often happened that the data
in one set was collected in a slightly different way than the other,
leading to interesting side effects.  So, I do think that writing down
what we should record from a traceroute measurement is a good idea.  I
do not think that it should be an internet standard, but OTOH, it
should be a document in a well known place.  An informational RFC might
just be the right thing.

>   It's just a data
>format.  We don't make an internet standard out of ppt even though lots
>of us exchange that.  Or, of excel --- which we do use to store / share
>data.  Or, libpcap.  Or, ...  It just seems to me like something that
>the IETF doesn't need to get its fingers all over.  In any case ... it
>would probably be much better done if a half-dozen people just did
>something reasonable in an afternoon (and then wrote a few easy tools
>that they could share) rather than an IETF WG taking a couple years to
>haggle over it.

I'd favor this approach: collect input for a few months, write it
down, publish by the summer.

If we cannot do this in a short timeframe, we've failed.

Henk



>But, then again my sense of what the IETF should be doing isn't really
>in alignment with the rest of the world's sense these days.  So, YMMV.
>

------------------------------------------------------------------------------
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 Thu Apr 21 21:42:45 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOnBt-0000fD-20; Thu, 21 Apr 2005 21:42:45 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOnBs-0000f8-Gl
	for ippm@megatron.ietf.org; Thu, 21 Apr 2005 21:42:44 -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 VAA08881
	for <ippm@ietf.org>; Thu, 21 Apr 2005 21:42:43 -0400 (EDT)
Received: from kyoto.netlab.nec.de ([195.37.70.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOnNO-0003l0-Qe
	for ippm@ietf.org; Thu, 21 Apr 2005 21:54:40 -0400
Received: from [192.168.0.128] (HSI-KBW-082-212-048-130.hsi.kabelbw.de
	[82.212.48.130])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id 8F1ED1BAC4D;
	Fri, 22 Apr 2005 03:42:30 +0200 (CEST)
Date: Fri, 22 Apr 2005 03:42:25 +0200
From: Juergen Quittek <quittek@netlab.nec.de>
To: mallman@icir.org
Subject: Re: [ippm] traceroute as WG work item? 
Message-ID: <2428E13F13E38B74596176BF@[192.168.0.128]>
In-Reply-To: <20050416175747.AB16825ED2D@lawyers.icir.org>
References: <20050416175747.AB16825ED2D@lawyers.icir.org>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=subscribe>
Sender: ippm-bounces@ietf.org 
Errors-To: ippm-bounces@ietf.org 

Hi Mark,

--On 4/16/2005 7:57 PM +0200 Mark Allman wrote:

>
> I am late (as usual), sorry.
>
>> Therefore I propose that this becomes an IPPM WG work item.
>> Any comment, pro or con, is very welcome.
>
> I don't see this as work that the IETF needs to be worried about.

In March (http://www.ietf.org/mail-archive/web/ippm/current/msg00553.html)
you stated that you would not be against such work. You just wondered
about why doing it right now.  Can you tell what made you change your
mind since then?

> It is
> certainly important for your project (data warehouse) that everyone
> understands the input and output formats for traceroute (etc.)
> measurements.  And, so you need to write it down.  But, I don't see it
> as necessitating an internet standard of some sort.  It's just a data
> format.

No, it is also an information model.  A draft of it is already
contained in the current version while the data format is still
a rather open issue.

> We don't make an internet standard out of ppt even though lots
> of us exchange that.  Or, of excel --- which we do use to store / share
> data.

Please consider that it is not just about data formats.
Yes, you can easily write tools for converting measurement results
stored in on data format to another one, say, excel sheet to a PPT.
But as soon as you want to interpret numbers or compare them,
you need to have a clear and shared semantics for the numbers you
are dealing with.  This would be provided by the information model.

> Or, libpcap.  Or, ...  It just seems to me like something that
> the IETF doesn't need to get its fingers all over.  In any case ... it
> would probably be much better done if a half-dozen people just did
> something reasonable in an afternoon (and then wrote a few easy tools
> that they could share) rather than an IETF WG taking a couple years to
> haggle over it.
>
> But, then again my sense of what the IETF should be doing isn't really
> in alignment with the rest of the world's sense these days.  So, YMMV.

Thanks,

    Juergen
-- 
Juergen Quittek        quittek@netlab.nec.de       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de

>
> allman
>
>
> --
> Mark Allman -- ICIR -- http://www.icir.org/mallman/
>
>
>



_______________________________________________
ippm mailing list
ippm@ietf.org 
https://www1.ietf.org/mailman/listinfo/ippm



From ippm-bounces@ietf.org Thu Apr 21 22:41:41 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOo6v-0008Fg-0q; Thu, 21 Apr 2005 22:41:41 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOo6t-0008Fb-6c
	for ippm@megatron.ietf.org; Thu, 21 Apr 2005 22:41:39 -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 WAA11780
	for <ippm@ietf.org>; Thu, 21 Apr 2005 22:41:37 -0400 (EDT)
Received: from wyvern.icir.org ([192.150.187.14])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOoIQ-0004tY-4P
	for ippm@ietf.org; Thu, 21 Apr 2005 22:53:35 -0400
Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net
	[68.76.113.50])
	by wyvern.icir.org (8.12.11/8.12.8) with ESMTP id j3M2fa0g070621;
	Thu, 21 Apr 2005 19:41:36 -0700 (PDT)
	(envelope-from mallman@icir.org)
Received: from lawyers.icir.org (guns.icir.org [68.76.113.50])
	by guns.icir.org (Postfix) with ESMTP
	id AFB3777AA54; Thu, 21 Apr 2005 22:41:33 -0400 (EDT)
Received: from lawyers.icir.org (localhost [127.0.0.1])
	by lawyers.icir.org (Postfix) with ESMTP
	id 7D6EB2607F6; Thu, 21 Apr 2005 22:41:34 -0400 (EDT)
To: Juergen Quittek <quittek@netlab.nec.de>
From: Mark Allman <mallman@icir.org>
Subject: Re: [ippm] traceroute as WG work item? 
In-Reply-To: <2428E13F13E38B74596176BF@[192.168.0.128]> 
Organization: ICSI Center for Internet Research (ICIR)
Song-of-the-Day: Peaches
MIME-Version: 1.0
Date: Thu, 21 Apr 2005 22:41:34 -0400
Message-Id: <20050422024134.7D6EB2607F6@lawyers.icir.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Cc: ippm@ietf.org
X-BeenThere: ippm@ietf.org 
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: mallman@icir.org
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1925459254=="
Sender: ippm-bounces@ietf.org 
Errors-To: ippm-bounces@ietf.org 

--===============1925459254==
Content-Type: multipart/signed; boundary="=_bOundary";
	micalg=pgp-sha1; protocol="application/pgp-signature"

--=_bOundary
Content-Type: text/plain


> In March
> (http://www.ietf.org/mail-archive/web/ippm/current/msg00553.html) you
> stated that you would not be against such work. You just wondered
> about why doing it right now.  Can you tell what made you change your
> mind since then?

Well, I was never really compelled.  I looked over the draft and thought
about it more I just don't think we need to do it.  At the end of the
day it wouldn't be harmful to do this draft - but I don't find it really
needed or even hugely desireable.  (A further hesitation I'd have is
that not many folks seem to have indicated interested and so I'd wonder
about energy.)

> Please consider that it is not just about data formats.  Yes, you can
> easily write tools for converting measurement results stored in on
> data format to another one, say, excel sheet to a PPT.  But as soon as
> you want to interpret numbers or compare them, you need to have a
> clear and shared semantics for the numbers you are dealing with.  This
> would be provided by the information model.

Three line internet-draft:
 
    date > traceroute-data 2>&1
    uname -a >> traceroute-data 2>&1
    traceroute somehost >> traceroute-data 2>&1

What are you suggesting beyond that, except specifying a stock format?
Maybe I just don't follow.

Thanks,
allman




--=_bOundary
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)

iD8DBQFCaGReWyrrWs4yIs4RAmnPAJwNjibeVSXNPYcT9vOxvDf3k9L5fgCfUWMH
Fn9RwYMpoaA5FJJ2P7FTvLA=
=OCNB
-----END PGP SIGNATURE-----
--=_bOundary--


--===============1925459254==
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

--===============1925459254==--




From ippm-bounces@ietf.org Tue Apr 26 08:00:02 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQOjS-0004ZC-Ph; Tue, 26 Apr 2005 08:00:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQOjS-0004Ym-20
	for ippm@megatron.ietf.org; Tue, 26 Apr 2005 08:00:02 -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 IAA00852
	for <ippm@ietf.org>; Tue, 26 Apr 2005 08:00:00 -0400 (EDT)
Received: from host114-228.pool82187.interbusiness.it ([82.187.228.114]
	helo=localhost.localdomain)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQOvs-0001q2-1Y
	for ippm@ietf.org; Tue, 26 Apr 2005 08:12:53 -0400
Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1])
	by localhost.localdomain (8.13.1/8.13.1) with ESMTP id j3QBxmcV009853; 
	Tue, 26 Apr 2005 13:59:49 +0200
Message-ID: <426E2D34.1030003@ntop.org>
Date: Tue, 26 Apr 2005 13:59:48 +0200
From: Luca Deri <deri@ntop.org>
Organization: ntop.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041217
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ippm@ietf.org
X-Enigmail-Version: 0.90.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Content-Transfer-Encoding: 7bit
Cc: 
Subject: [ippm] Comments on draft-niccolini-ippm-storetraceroutes-00
X-BeenThere: ippm@ietf.org 
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=subscribe>
Sender: ippm-bounces@ietf.org 
Errors-To: ippm-bounces@ietf.org 

Hi all,
I would like to share with you my comments to the above draft.

First of all I think that this work is useful and that it similar 
efforts are welcome. However I see a couple of issues that I would like 
to be addressed in future version of this draft:

- The authors start with a survey of the available traceroute tools on 
some popular platforms. Although this could be a good idea, it has the 
problem that this work is platform dependent nad that it will likely be 
obsoleted soon. Some years ago RIPE wrote a tool to be used as reference 
tool for DNS query. I think that it should be discussed whether it makes 
sense to develop such a cross-platform tool (or base it on some open 
source tools) and use it as reference for the draft.

- Many modern networks are based on MPLS. I don't see how the MPLS 
labels fit into the draft. For instance the Linux traceroute tool shows 
MPLS labels as you can see below.
 1 gw-vlan759.nexicom.net (216.168.111.185) 4 msec 0 msec 4 msec
 2 gw-7513.nexicom.net (216.168.96.1) 160 msec 8 msec 0 msec
 3 dis1-toronto63-fe1-5-14.in.bellnexxia.net (206.108.110.221) 8 msec 4 
msec 4 msec
 4 core2-toronto63-pos1-2.in.bellnexxia.net (206.108.98.125) 8 msec 4 
msec 8 msec
 5 64.230.242.105 [MPLS: Label 12903 Exp 0] 176 msec 64 msec 8 msec
 6 64.230.242.181 [MPLS: Label 12905 Exp 0] 4 msec 44 msec 200 msec
 7 64.230.242.198 [MPLS: Label 12473 Exp 0] 8 msec 4 msec 4 msec
 8 dis1-toronto12-pos6-0.in.bellnexxia.net (206.108.97.70) 8 msec 4 msec 
4 msec
 9 206.108.111.106 8 msec 4 msec 8 msec
10 10.78.254.125 8 msec 8 msec 4 msec
11 10.78.254.8 12 msec 8 msec 4 msec
12 129.33.183.72 8 msec 4 msec 8 msec
13  *  *  *
14  *  *  *

Cheers, Luca

-- 
Luca Deri <deri@ntop.org>	http://luca.ntop.org/
Hacker: someone who loves to program and enjoys being
clever about it - Richard Stallman


_______________________________________________
ippm mailing list
ippm@ietf.org 
https://www1.ietf.org/mailman/listinfo/ippm



From ippm-bounces@ietf.org Tue Apr 26 18:08:19 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQYE7-0000Yc-KB; Tue, 26 Apr 2005 18:08:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQYE6-0000YW-7F
	for ippm@megatron.ietf.org; Tue, 26 Apr 2005 18:08:18 -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 SAA23131
	for <ippm@ietf.org>; Tue, 26 Apr 2005 18:08:15 -0400 (EDT)
Received: from kyoto.netlab.nec.de ([195.37.70.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQYQb-0000OW-1f
	for ippm@ietf.org; Tue, 26 Apr 2005 18:21:15 -0400
Received: from [192.168.0.128] (HSI-KBW-082-212-048-130.hsi.kabelbw.de
	[82.212.48.130])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id 37A531BAC9E;
	Wed, 27 Apr 2005 00:08:06 +0200 (CEST)
Date: Wed, 27 Apr 2005 00:08:08 +0200
From: Juergen Quittek <quittek@netlab.nec.de>
To: mallman@icir.org
Subject: Re: [ippm] traceroute as WG work item? 
Message-ID: <730D8E764C3921D83B5DFB26@[192.168.0.128]>
In-Reply-To: <20050422024134.7D6EB2607F6@lawyers.icir.org>
References: <20050422024134.7D6EB2607F6@lawyers.icir.org>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=subscribe>
Sender: ippm-bounces@ietf.org 
Errors-To: ippm-bounces@ietf.org 

Hi Mark,

--On 4/22/2005 4:41 AM +0200 Mark Allman wrote:

>
>> In March
>> (http://www.ietf.org/mail-archive/web/ippm/current/msg00553.html) you
>> stated that you would not be against such work. You just wondered
>> about why doing it right now.  Can you tell what made you change your
>> mind since then?
>
> Well, I was never really compelled.  I looked over the draft and thought
> about it more I just don't think we need to do it.  At the end of the
> day it wouldn't be harmful to do this draft - but I don't find it really
> needed or even hugely desireable.  (A further hesitation I'd have is
> that not many folks seem to have indicated interested and so I'd wonder
> about energy.)

I share this concern.  Is there nobody else interested?

>> Please consider that it is not just about data formats.  Yes, you can
>> easily write tools for converting measurement results stored in on
>> data format to another one, say, excel sheet to a PPT.  But as soon as
>> you want to interpret numbers or compare them, you need to have a
>> clear and shared semantics for the numbers you are dealing with.  This
>> would be provided by the information model.
>
> Three line internet-draft:
>
>     date > traceroute-data 2>&1
>     uname -a >> traceroute-data 2>&1
>     traceroute somehost >> traceroute-data 2>&1
>
> What are you suggesting beyond that, except specifying a stock format?
> Maybe I just don't follow.

In <http://www1.ietf.org/mail-archive/web/ippm/current/msg00548.html>
you argured strongly for using XML, so you should extend your I-D:

    echo "<traceroute-data>" > traceroute-data
    date > traceroute-data 2>&1
    uname -a >> traceroute-data 2>&1
    traceroute somehost >> traceroute-data 2>&1
    echo "</tracerouter-data>" > traceroute-data

When you start parsing it, you might think about structuring the content
some more and might finally end up with a schema that comes close to what
is the information model in the current draft.

Thanks,

    Juergen
-- 
Juergen Quittek        quittek@netlab.nec.de       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de


> Thanks,
> allman



_______________________________________________
ippm mailing list
ippm@ietf.org 
https://www1.ietf.org/mailman/listinfo/ippm



From ippm-bounces@ietf.org Wed Apr 27 03:59:35 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQhSH-0006QD-Re; Wed, 27 Apr 2005 03:59:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQhSF-0006Q8-24
	for ippm@megatron.ietf.org; Wed, 27 Apr 2005 03:59:31 -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 DAA11543
	for <ippm@ietf.org>; Wed, 27 Apr 2005 03:59:29 -0400 (EDT)
Received: from smtp0.netlab.nec.de ([195.37.70.40])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQheo-0004YF-B1
	for ippm@ietf.org; Wed, 27 Apr 2005 04:12:33 -0400
Received: from europa.office (europa.office [10.1.1.2])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id 2C500D96D;
	Wed, 27 Apr 2005 10:02:41 +0200 (CEST)
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] traceroute as WG work item? 
Date: Wed, 27 Apr 2005 09:59:18 +0200
Message-ID: <88F766D04E6AF3409B39E60D7D933EB20A505C@europa.office>
Thread-Topic: [ippm] traceroute as WG work item? 
Thread-Index: AcVG5Rl9x9ymgtL0TzukTJLvAXP4dwEFzq5A
From: "Sandra Tartarelli" <Sandra.Tartarelli@netlab.nec.de>
To: <mallman@icir.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=subscribe>
Sender: ippm-bounces@ietf.org 
Errors-To: ippm-bounces@ietf.org 

Hi Mark,=20

> -----Original Message-----
> From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On=20
> Behalf Of Mark Allman
> Sent: Friday, April 22, 2005 4:42 AM
> To: Juergen Quittek
> Cc: ippm@ietf.org
> Subject: Re: [ippm] traceroute as WG work item?=20
>=20

> > Please consider that it is not just about data formats. =20
> Yes, you can=20
> > easily write tools for converting measurement results stored in on=20
> > data format to another one, say, excel sheet to a PPT.  But=20
> as soon as=20
> > you want to interpret numbers or compare them, you need to have a=20
> > clear and shared semantics for the numbers you are dealing=20
> with.  This=20
> > would be provided by the information model.
>=20
> Three line internet-draft:
> =20
>     date > traceroute-data 2>&1
>     uname -a >> traceroute-data 2>&1
>     traceroute somehost >> traceroute-data 2>&1
>=20
> What are you suggesting beyond that, except specifying a stock format?
> Maybe I just don't follow.
>=20
> Thanks,
> allman

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.

In addition, the draft was intended to define traceroute specific
metrics, provided that the IPPM is interested in this...=20

Regards,
Sandra Tartarelli

_______________________________________________
ippm mailing list
ippm@ietf.org 
https://www1.ietf.org/mailman/listinfo/ippm



From ippm-bounces@ietf.org Wed Apr 27 08:43:14 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQlso-0006s9-Lw; Wed, 27 Apr 2005 08:43:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQlsn-0006s4-4v
	for ippm@megatron.ietf.org; Wed, 27 Apr 2005 08:43:13 -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 IAA05879
	for <ippm@ietf.org>; Wed, 27 Apr 2005 08:43:11 -0400 (EDT)
Received: from wyvern.icir.org ([192.150.187.14])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQm5O-0002By-O2
	for ippm@ietf.org; Wed, 27 Apr 2005 08:56:18 -0400
Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net
	[68.76.113.50])
	by wyvern.icir.org (8.12.11/8.12.8) with ESMTP id j3RCh7Rj062356;
	Wed, 27 Apr 2005 05:43:07 -0700 (PDT)
	(envelope-from mallman@guns.icir.org)
Received: from guns.icir.org (localhost [127.0.0.1])
	by guns.icir.org (Postfix) with ESMTP
	id 7F0FE77A6E3; Wed, 27 Apr 2005 08:43:06 -0400 (EDT)
To: "Sandra Tartarelli" <Sandra.Tartarelli@netlab.nec.de>
From: Mark Allman <mallman@icir.org>
Subject: Re: [ippm] traceroute as WG work item? 
In-Reply-To: <88F766D04E6AF3409B39E60D7D933EB20A505C@europa.office> 
Organization: ICSI Center for Internet Research (ICIR)
Song-of-the-Day: Lady Picture Show
MIME-Version: 1.0
Date: Wed, 27 Apr 2005 08:43:06 -0400
Message-Id: <20050427124306.7F0FE77A6E3@guns.icir.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: ippm@ietf.org
X-BeenThere: ippm@ietf.org 
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: mallman@icir.org
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0005489691=="
Sender: ippm-bounces@ietf.org 
Errors-To: ippm-bounces@ietf.org 

--===============0005489691==
Content-Type: multipart/signed; boundary="=_bOundary";
	micalg=pgp-sha1; protocol="application/pgp-signature"

--=_bOundary
Content-Type: text/plain


Hi Sandra-

> 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.

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.

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.

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).

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
    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.


-- 
Mark Allman -- ICIR -- http://www.icir.org/mallman/




--=_bOundary
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (FreeBSD)

iD4DBQFCb4jaWyrrWs4yIs4RArSnAJiyidi6uxkqWQPqC4M2g2CfKksOAKCE/YnG
Krjy0Ysg6+ku9f6gvfwVCA==
=cLcx
-----END PGP SIGNATURE-----
--=_bOundary--


--===============0005489691==
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

--===============0005489691==--




From ippm-bounces@ietf.org Wed Apr 27 12:18:44 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQpFM-0005Eu-B2; Wed, 27 Apr 2005 12:18:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQpFL-0005DE-6g
	for ippm@megatron.ietf.org; Wed, 27 Apr 2005 12:18:43 -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 MAA29446
	for <ippm@ietf.org>; Wed, 27 Apr 2005 12:18:40 -0400 (EDT)
Received: from mailg.surrey.ac.uk ([131.227.102.21])
	by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DQpRz-00006z-9P
	for ippm@ietf.org; Wed, 27 Apr 2005 12:31:50 -0400
Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP)
	with ESMTP; Wed, 27 Apr 2005 17:04:23 +0100
Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136])
	by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211);
	Wed, 27 Apr 2005 17:04:21 +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, 27 Apr 2005 16:04:21 +0000
Received: from ccsrlt31 by evs-ec1-node1.surrey.ac.uk;
	27 Apr 2005 17:04:21 +0100
Subject: Re: [ippm] Proposed new work items for the group
From: Lei Liang <L.Liang@surrey.ac.uk>
To: Al Morton <acmorton@att.com>
In-Reply-To: <6.0.3.0.0.20050414112737.05bc5130@custsla.mt.att.com>
References: <6.2.0.14.2.20050308182609.02cc07b0@localhost>
	<6.0.3.0.0.20050412093405.057f4820@custsla.mt.att.com>
	<1113487862.2094.6.camel@ccsrlt31.ee.surrey.ac.uk>
	<6.0.3.0.0.20050414112737.05bc5130@custsla.mt.att.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1114617860.3207.0.camel@ccsrlt31.ee.surrey.ac.uk>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6
Date: Wed, 27 Apr 2005 17:04:21 +0100
X-OriginalArrivalTime: 27 Apr 2005 16:04:21.0891 (UTC)
	FILETIME=[C66D6530:01C54B42]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632
Content-Transfer-Encoding: 7bit
Cc: STEPHAN Emile RD-CORE-LAN <emile.stephan@francetelecom.com>, ippm@ietf.org
X-BeenThere: ippm@ietf.org 
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=subscribe>
Sender: ippm-bounces@ietf.org 
Errors-To: ippm-bounces@ietf.org 

Hi, Al,
  Thank you very much for your email. I was actually out of office in
last week. So it is very in time.
  Regarding the measurement point, it is a very interesting topic.
Considering both the measurement and calculation aspect, the measurement
point could be critical w.r.t the fact that not all users can be
practical measurement point in the implementation. So when we talk about
one-to-group, we imply that the topology of the communication group is
centre-distributed or server-client topology. the centre or the server
that is controlled by network operators can be the very good reference
point while calculation will be carried out although the actual
measurements have to be carried out at all clients. This reference point
will make the measurement points definition more clear, i.e., the
measurement points will be all clients/receivers while the reference
point acts as source for the one-to-group metric. Or, the reference
point is the measurement point when all clients/receivers act as sources
for group-to-one metric. So we can define the reference point as the
host while the statistic calculation will be done.

some comments in line.


On Fri, 2005-04-22 at 22:29, Al Morton wrote: 
> At 10:11 AM 04/14/2005, you wrote:
> >Dear Al,
> >   Thank you very much for your comments. The "measurement
> >points-of-interest" could be a good idea to summarize the comment parts
> >between the spatial and multicast metrics. We will be very happy to hear
> >your further comments on it.
> 
> Sorry for the delay, I had to service a priority interrupt,
> and it took me some time to get back to this...
> 
> Briefly, here's the concept:
> 
> The measurement points of all multi-point metrics can be
> defined as a list of points-of-interest.
> So, MP1, MP2, MP3, ... MPn  may be along a single path,
> or they may be at the endpoints of a multicast tree.
> 
> One question is, what's the best way to indicate measurement
> points without ambiguity, using the RFC 2330 Framework?
> A path is composed of hosts and links:
> < h0, l1, h1, l2, h2, ... ln, hn >
> The path definition notes that hosts h1 through hn-1 are routers.
> 
> A multicast tree has many similar paths, and in the
> one to group direction, the measurements terminate in many different hosts.
> 
> So, if we equate measurement points to hosts, then we might have
> something like this:
> 
> (Just a suggestion, not the final text!)
> 
> 2.  Terminology
> 
> 2.1  Multiparty metric
> 
>     A metric is said to be multiparty if it defines more than two hosts
>     as measurement points. All multiparty measurements define a set of hosts
>     called "points of interest", where one host is the source and other hosts
>     are the measurement collection points.  For example, if the set of
>     points of interest is < ha, hb, hc, ... hn >, where ha is the source,
>     then measurements may be conducted between <ha, hb>, <ha, hc>, etc.
> 
a metric is said to be multiparty if it defines more than two sources or
destinations in the measurements. (we don't use measurement point in
order to avoid ambiguity)

> 2.2  Spatial metric points of interest
> 
>     The points of interest can be selected to define a spatial metric.
>     A metric is said to be spatial if one of the hosts involved is
>     neither the source nor the destination of the metered packet.
>     In this case, the useful points of interest are the routers in the
>     path between source and destination (in addition to the source itself).
> 
> 2.3  One-to-group metric points of interest
> 
>     Points of interest can also be selected to define a One-to-group metric.
>     A metric is said to be one-to-group if the measured packet is sent by
>     one source and received by several destinations.
>     In this case, the points of interest are the set of host destinations
>     receiving packets from the source (in addition to the source itself).
> 
> 2.4  Other measurement topologies defined by points of interest
> 
>     We note that points of interest can also be selected to define
>     Group-to-one and Group-to-group topologies. These topologies are
>     currently beyond the scope of this memo, because they would involve
>     multiple packets launched from different sources, and therefore they
>     are simply collections of many point-to-point metrics.
> 
the measurement for group-to-one scenario can be easily derived from the
one-to-group measurement. The measurement point is the same host with
reference point. 
For the group-to-group topology, I think there is a big problem to
define measurement point and reference point. however, no matter how the
users are connected, we can always treat them as one-to-many
connections.


> 
> 

_______________________________________________
ippm mailing list
ippm@ietf.org 
https://www1.ietf.org/mailman/listinfo/ippm



From ippm-bounces@ietf.org Thu Apr 28 06:25:58 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DR6DW-0007mF-O6; Thu, 28 Apr 2005 06:25:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DR6DV-0007mA-8e
	for ippm@megatron.ietf.org; Thu, 28 Apr 2005 06:25: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 GAA00096
	for <ippm@ietf.org>; Thu, 28 Apr 2005 06:25:54 -0400 (EDT)
Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DR6QL-0003Jt-60
	for ippm@ietf.org; Thu, 28 Apr 2005 06:39:13 -0400
Received: from [10.147.67.235] (i4dhcp235 [10.147.67.235])
	by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id
	j3SAPmT29819; Thu, 28 Apr 2005 12:25:48 +0200 (MEST)
Message-ID: <4270BA2C.5060803@fokus.fraunhofer.de>
Date: Thu, 28 Apr 2005 12:25:48 +0200
From: Tanja Zseby <zseby@fokus.fraunhofer.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Henk Uijterwaal <henk@ripe.net>
Subject: Re: [ippm] traceroute as WG work item?
References: <977D8FE25543262C718BA2E3@[10.1.1.171]>	<20050416175747.AB16825ED2D@lawyers.icir.org>
	<6.2.0.14.2.20050418131701.02c63590@localhost>
In-Reply-To: <6.2.0.14.2.20050418131701.02c63590@localhost>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f
Content-Transfer-Encoding: 7bit
Cc: ippm@ietf.org, mallman@icir.org
X-BeenThere: ippm@ietf.org 
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=subscribe>
Sender: ippm-bounces@ietf.org 
Errors-To: ippm-bounces@ietf.org 

Hi all,

we also spend some time on converting traces from one format to another 
or design tools in a way that they are able to read different formats. 
Fortunately for packet traces often libpcap format is used, but there 
are still many traces in different formats. I assume if the libpcap 
format would be the standard for storing packet traces even more people 
would use this.
For traceroute data it seems that there is nothing like a commonly used 
format (as libpcap for packet traces) so I think it is even more of 
benefit if people agree on a format. In my opinion this is what 
standardization is for. If it is simple to write it down, even better. 
 From the mails on the list it seems that there are at least a few 
things that need to be discussed . There exists a first draft and 
authors that commited themself to do work on this. So there is interest 
and there are people who will work on this. Why not giving them a home 
within the IPPM group to make their work more valuable for all of us ?
So I think the IETF is the right place to discuss this and for me it 
would be of benefit to have such a standard format.

Regards
Tanja


Henk Uijterwaal wrote:

> At 19:57 16/04/2005, Mark Allman wrote:
>
>> I am late (as usual), sorry.
>
>
> As the WG chair:  No, comments on this topic are still welcome,
> until 29/4.
>
>> > Therefore I propose that this becomes an IPPM WG work item.
>> > Any comment, pro or con, is very welcome.
>>
>> I don't see this as work that the IETF needs to be worried about.  It is
>> certainly important for your project (data warehouse) that everyone
>> understands the input and output formats for traceroute (etc.)
>> measurements.  And, so you need to write it down.  But, I don't see it
>> as necessitating an internet standard of some sort.
>
>
> Speaking as myself.  I've spend more time than I care to remember
> writing scripts to convert the data from one set into the format used
> by another, in order to merge results.  It often happened that the data
> in one set was collected in a slightly different way than the other,
> leading to interesting side effects.  So, I do think that writing down
> what we should record from a traceroute measurement is a good idea.  I
> do not think that it should be an internet standard, but OTOH, it
> should be a document in a well known place.  An informational RFC might
> just be the right thing.
>
>>   It's just a data
>> format.  We don't make an internet standard out of ppt even though lots
>> of us exchange that.  Or, of excel --- which we do use to store / share
>> data.  Or, libpcap.  Or, ...  It just seems to me like something that
>> the IETF doesn't need to get its fingers all over.  In any case ... it
>> would probably be much better done if a half-dozen people just did
>> something reasonable in an afternoon (and then wrote a few easy tools
>> that they could share) rather than an IETF WG taking a couple years to
>> haggle over it.
>
>
> I'd favor this approach: collect input for a few months, write it
> down, publish by the summer.
>
> If we cannot do this in a short timeframe, we've failed.
>
> Henk
>
>
>
>> But, then again my sense of what the IETF should be doing isn't really
>> in alignment with the rest of the world's sense these days.  So, YMMV.
>>
>
> ------------------------------------------------------------------------------ 
>
> 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


-- 
Dipl.-Ing. Tanja Zseby			    	      	
Fraunhofer Institute FOKUS			Email: zseby@fokus.fraunhofer.de	
Kaiserin-Augusta-Allee 31			Phone: +49-30-3463-7153
D-10589 Berlin, Germany				Fax:   +49-30-3463-8153
-------------------------------------------------------------------------------------- 
"Living on earth is expensive but it includes a free trip around the sun." (Anonymous)
--------------------------------------------------------------------------------------


_______________________________________________
ippm mailing list
ippm@ietf.org 
https://www1.ietf.org/mailman/listinfo/ippm



From ippm-bounces@ietf.org Thu Apr 28 06:36:21 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DR6NZ-0001cp-Mt; Thu, 28 Apr 2005 06:36:21 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DR6NX-0001cS-TC
	for ippm@megatron.ietf.org; Thu, 28 Apr 2005 06:36:20 -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 GAA01037
	for <ippm@ietf.org>; Thu, 28 Apr 2005 06:36:17 -0400 (EDT)
Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DR6aN-0003mK-Hc
	for ippm@ietf.org; Thu, 28 Apr 2005 06:49:36 -0400
Received: from [10.147.66.159] (i3dhcp159 [10.147.66.159])
	by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id
	j3SAaFT01790; Thu, 28 Apr 2005 12:36:15 +0200 (MEST)
Message-ID: <4270BC96.7020302@fokus.fraunhofer.de>
Date: Thu, 28 Apr 2005 12:36:06 +0200
From: Carsten Schmoll <carsten.schmoll@fokus.fraunhofer.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: mallman@icir.org
Subject: Re: [ippm] traceroute as WG work item?
References: <20050427124306.7F0FE77A6E3@guns.icir.org>
In-Reply-To: <20050427124306.7F0FE77A6E3@guns.icir.org>
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0249046757=="
Sender: ippm-bounces@ietf.org 
Errors-To: ippm-bounces@ietf.org 

This is a cryptographically signed message in MIME format.

--===============0249046757==
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=sha1; boundary="------------ms040508000303040803060406"

This is a cryptographically signed message in MIME format.

--------------ms040508000303040803060406
Content-Type: multipart/alternative;
	boundary="------------080407090806030906030700"

This is a multi-part message in MIME format.
--------------080407090806030906030700
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


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-
>
>  
>
>>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.
>>    
>>
>
>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.
>
>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.
>
>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).
>
>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
>    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.
>
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>ippm mailing list
>ippm@ietf.org 
>https://www1.ietf.org/mailman/listinfo/ippm
>  
>

-- 
"The difference between theory and practice is that in theory 
 theory and practice are the same but in practice they are not."

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


--------------080407090806030906030700
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
Dear Sandra, Mark, all,<br>
<br>
I think that it is a worthwhile attempt to focus traceroute output into
a <br>
standards format. I further fully agree that it is vital to include more<br>
data into the information model than just the one that the traceroute<br>
command itself can deliver. <br>
<br>
Allthough this topic cannot be seen as an urgent problem I think it is <br>
worth contacting projects who already did work on putting traceroute <br>
data into some (proprietary) database or other kind of storage.<br>
<br>
If these would join the work it could be really successful.<br>
<br>
Finally let me suggest that I'd vote for a human readable format,<br>
so there still would be the chance to work on results by using <br>
scripts (even if it involves an XML paerser lib as well).<br>
<br>
If so then one importatnt step is also how to store multiple<br>
traceroute results together in one block of information in <br>
a meaningful way. If this is achieved successfully, one can think<br>
about deriving a MIB or IPFIX template as well depending on<br>
the need of the community.<br>
<br>
At first though I agree that it is vital to find a critical mass of<br>
motivated people to put this action forward.<br>
<br>
Kind regards,<br>
Carsten.<br>
<br>
<br>
Mark Allman wrote:<br>
<blockquote cite="mid20050427124306.7F0FE77A6E3@guns.icir.org"
 type="cite">
  <pre wrap="">Hi Sandra-

  </pre>
  <blockquote type="cite">
    <pre wrap="">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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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.

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.

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).

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
    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.


  </pre>
  <pre wrap="">
<hr size="4" width="90%">
_______________________________________________
ippm mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ippm@ietf.org">ippm@ietf.org</a> 
<a class="moz-txt-link-freetext" href="https://www1.ietf.org/mailman/listinfo/ippm">https://www1.ietf.org/mailman/listinfo/ippm</a>
  </pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 
"The difference between theory and practice is that in theory 
 theory and practice are the same but in practice they are not."

Dipl.Ing. Carsten Schmoll                Fraunhofer Institute FOKUS
<a class="moz-txt-link-abbreviated" href="mailto:carsten.schmoll@fokus.fraunhofer.de">carsten.schmoll@fokus.fraunhofer.de</a>      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
</pre>
</body>
</html>

--------------080407090806030906030700--

--------------ms040508000303040803060406
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILbjCC
BbMwggSboAMCAQICAgEdMA0GCSqGSIb3DQEBBQUAME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQK
EwpGcmF1bmhvZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNB
IHYyMB4XDTA0MDYyNDEwMDk1NVoXDTA1MTIzMTIzMDAwMFowXTELMAkGA1UEBhMCREUxEzAR
BgNVBAoTCkZyYXVuaG9mZXIxDjAMBgNVBAsTBUZPS1VTMQ8wDQYDVQQLEwZQZW9wbGUxGDAW
BgNVBAMTD0NhcnN0ZW4gU2NobW9sbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AOLS+MB7FZNRzI7FMsOIgc/Ej3787GLIjCAqesjRedn7YYf6/wSKn7G0NVoiMcw/NdPpTbko
bgPDAOIkpYCKkWWOpaH2NYKaTox04DRVB92lxLc5Ug6YU+3PUjJv7diwfq8JrkvzO4/QDK3H
u/X1bPAVTIZvYGtYdoYkRonSOcDMbOnNZ8fAvx6MR1XK79zp5fGkxc2y+totRd45eKJvWxeZ
S2EfSJHnCI3HGArXg1+6gTCZB3iCHa0P7IaQpqcB+qrLFMszVoIpb8n6rXm9Caf/7vrqr0g6
mJsrzcFb7SRhlX1GivGvY1Lnw2kYlAHoYcOnzwqPW9PEl7M3Xu0eFFECAwEAAaOCAokwggKF
MIGeBglghkgBhvhCAQ0EgZAWgY1Tb2Z0d2FyZSBaZXJ0aWZpa2F0IGRlciBaZXJ0aWZpemll
cnVuZ2luc3RhbnogKENBKSBkZXIgRnJhdW5ob2Zlci1HZXNlbGxzY2hhZnQgZS5WLiwgTXVl
bmNoZW47IFd1cnplbHplcnRpZmlrYXQgdmlhIGh0dHA6Ly9wa2kuZnJhdW5ob2Zlci5kZS8w
TQYIKwYBBQUHAQEEQTA/MD0GCCsGAQUFBzABhjFodHRwOi8vcGtpLmZyYXVuaG9mZXIuZGUv
RmhHLUNBX3YyX09DU1AtUmVzcG9uZGVyMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9wa2ku
ZnJhdW5ob2Zlci5kZS9GaEctQ0EtQ2VydHMvRmhHLUNBX3YyX0NSTC5jcmwwCQYDVR0TBAIw
ADBKBgNVHRIEQzBBgSR6ZXJ0aWZpemllcnVuZ3NpbnN0YW56QGZyYXVuaG9mZXIuZGWGGWh0
dHA6Ly9wa2kuZnJhdW5ob2Zlci5kZS8wLgYDVR0RBCcwJYEjY2Fyc3Rlbi5zY2htb2xsQGZv
a3VzLmZyYXVuaG9mZXIuZGUwTAYDVR0gBEUwQzBBBgsrBgEEAYYKUAIBATAyMDAGCCsGAQUF
BwIBFiRodHRwOi8vcGtpLmZyYXVuaG9mZXIuZGUvcG9saWN5Lmh0bWwwJwYDVR0lBCAwHgYI
KwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBDALBgNVHQ8EBAMCA/gwHQYDVR0OBBYEFN+v
LP4JH3Wal1v9UzQRsqMtwCseMB8GA1UdIwQYMBaAFADD/O9jwlYoL1ELdVb/ewXpHMnxMA0G
CSqGSIb3DQEBBQUAA4IBAQAheQ1WRa1zrxv6ZpKlVgfd5J3q/9mk+DAEdGWlMqBPVLj6aHYT
Tx+gNZLq4icJt6OpfTgYwuGW3cFivg2+GS0F7iTR0OqrDtNBcS5njvrYQ84FJw8vpbfQMNAk
IHBtUBJiXVLx1eyYXgFnzav6X8hnZFKm0Res6HRg/VHwqV78kfoz+Znd3QBpQCH2u+m6WDrC
wrDfD15KbHeUs5qzdJiUiouxZRXTOzRmQA2luh0TQJz+1h+D9mhzpgGwZ/3KE0KXp2IfsrQQ
c5yGnyA/Mde8Uh4m4fzKAuAJI1Gh31ssq1u2VR9e2xHtnii8xWFe5y0ezBtAWYgyQr3SKNiv
kGQDMIIFszCCBJugAwIBAgICAR0wDQYJKoZIhvcNAQEFBQAwTzELMAkGA1UEBhMCREUxEzAR
BgNVBAoTCkZyYXVuaG9mZXIxKzApBgNVBAMTIkZyYXVuaG9mZXItR2VzZWxsc2NoYWZ0IFJv
b3QtQ0EgdjIwHhcNMDQwNjI0MTAwOTU1WhcNMDUxMjMxMjMwMDAwWjBdMQswCQYDVQQGEwJE
RTETMBEGA1UEChMKRnJhdW5ob2ZlcjEOMAwGA1UECxMFRk9LVVMxDzANBgNVBAsTBlBlb3Bs
ZTEYMBYGA1UEAxMPQ2Fyc3RlbiBTY2htb2xsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEA4tL4wHsVk1HMjsUyw4iBz8SPfvzsYsiMICp6yNF52fthh/r/BIqfsbQ1WiIxzD81
0+lNuShuA8MA4iSlgIqRZY6lofY1gppOjHTgNFUH3aXEtzlSDphT7c9SMm/t2LB+rwmuS/M7
j9AMrce79fVs8BVMhm9ga1h2hiRGidI5wMxs6c1nx8C/HoxHVcrv3Onl8aTFzbL62i1F3jl4
om9bF5lLYR9IkecIjccYCteDX7qBMJkHeIIdrQ/shpCmpwH6qssUyzNWgilvyfqteb0Jp//u
+uqvSDqYmyvNwVvtJGGVfUaK8a9jUufDaRiUAehhw6fPCo9b08SXszde7R4UUQIDAQABo4IC
iTCCAoUwgZ4GCWCGSAGG+EIBDQSBkBaBjVNvZnR3YXJlIFplcnRpZmlrYXQgZGVyIFplcnRp
Zml6aWVydW5naW5zdGFueiAoQ0EpIGRlciBGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBlLlYu
LCBNdWVuY2hlbjsgV3VyemVsemVydGlmaWthdCB2aWEgaHR0cDovL3BraS5mcmF1bmhvZmVy
LmRlLzBNBggrBgEFBQcBAQRBMD8wPQYIKwYBBQUHMAGGMWh0dHA6Ly9wa2kuZnJhdW5ob2Zl
ci5kZS9GaEctQ0FfdjJfT0NTUC1SZXNwb25kZXIwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDov
L3BraS5mcmF1bmhvZmVyLmRlL0ZoRy1DQS1DZXJ0cy9GaEctQ0FfdjJfQ1JMLmNybDAJBgNV
HRMEAjAAMEoGA1UdEgRDMEGBJHplcnRpZml6aWVydW5nc2luc3RhbnpAZnJhdW5ob2Zlci5k
ZYYZaHR0cDovL3BraS5mcmF1bmhvZmVyLmRlLzAuBgNVHREEJzAlgSNjYXJzdGVuLnNjaG1v
bGxAZm9rdXMuZnJhdW5ob2Zlci5kZTBMBgNVHSAERTBDMEEGCysGAQQBhgpQAgEBMDIwMAYI
KwYBBQUHAgEWJGh0dHA6Ly9wa2kuZnJhdW5ob2Zlci5kZS9wb2xpY3kuaHRtbDAnBgNVHSUE
IDAeBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMAsGA1UdDwQEAwID+DAdBgNVHQ4E
FgQU368s/gkfdZqXW/1TNBGyoy3AKx4wHwYDVR0jBBgwFoAUAMP872PCVigvUQt1Vv97Bekc
yfEwDQYJKoZIhvcNAQEFBQADggEBACF5DVZFrXOvG/pmkqVWB93kner/2aT4MAR0ZaUyoE9U
uPpodhNPH6A1kuriJwm3o6l9OBjC4ZbdwWK+Db4ZLQXuJNHQ6qsO00FxLmeO+thDzgUnDy+l
t9Aw0CQgcG1QEmJdUvHV7JheAWfNq/pfyGdkUqbRF6zodGD9UfCpXvyR+jP5md3dAGlAIfa7
6bpYOsLCsN8PXkpsd5SzmrN0mJSKi7FlFdM7NGZADaW6HRNAnP7WH4P2aHOmAbBn/coTQpen
Yh+ytBBznIafID8x17xSHibh/MoC4AkjUaHfWyyrW7ZVH17bEe2eKLzFYV7nLR7MG0BZiDJC
vdIo2K+QZAMxggL/MIIC+wIBATBVME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhv
ZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNBIHYyAgIBHTAJ
BgUrDgMCGgUAoIIBfzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wNTA0MjgxMDM2MDZaMCMGCSqGSIb3DQEJBDEWBBQo861nuXETgbLQD6xGUG2rvw9QWTBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDBkBgkrBgEEAYI3EAQxVzBVME8xCzAJBgNV
BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2Vs
bHNjaGFmdCBSb290LUNBIHYyAgIBHTBmBgsqhkiG9w0BCRACCzFXoFUwTzELMAkGA1UEBhMC
REUxEzARBgNVBAoTCkZyYXVuaG9mZXIxKzApBgNVBAMTIkZyYXVuaG9mZXItR2VzZWxsc2No
YWZ0IFJvb3QtQ0EgdjICAgEdMA0GCSqGSIb3DQEBAQUABIIBAJ05PkfDp7iFJJOfd+IdXATE
F+yzg38lweDcrmsytAdR3gYrV+RnmGafcxJMowTPxc9zL9hvrqTsHd2kujaCR7ZGxr+TyIuJ
kBUPENknD9BACL792RsCOMaLBOZQJ3AVH/Ufzuf0ot0joA6ZlfgiRZoXweJ/PADvtiARG8Ej
A352JvN+bmKmh4mQfvQUWdidtOnSqh174c12mdxF5SldSTO/hVePXAjdEbo45USmV4V1rUog
gIqY3S47ZHIn2eN5k+gAp7C9OuIQBOY9/7HvbcQRcPPUtTF3y9ip7XIEdzj0crnDy5iFLOEJ
pqG6omv+COQyJUjraVJWIrcxmFQxk4UAAAAAAAA=
--------------ms040508000303040803060406--


--===============0249046757==
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

--===============0249046757==--




From ippm-bounces@ietf.org Thu Apr 28 11:50:09 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DRBHF-0001sn-1o; Thu, 28 Apr 2005 11:50:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DRBHD-0001sT-Tm
	for ippm@megatron.ietf.org; Thu, 28 Apr 2005 11:50: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 LAA28207
	for <ippm@ietf.org>; Thu, 28 Apr 2005 11:50:05 -0400 (EDT)
Received: from ranger.systems.pipex.net ([62.241.162.32])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRBU7-00005W-1f
	for ippm@ietf.org; Thu, 28 Apr 2005 12:03:27 -0400
Received: from pc6 (1Cust184.tnt103.lnd4.gbr.da.uu.net [213.116.54.184])
	by ranger.systems.pipex.net (Postfix) with SMTP id 1C8A6E000244;
	Thu, 28 Apr 2005 16:49:56 +0100 (BST)
Message-ID: <050601c54c01$054ae5c0$0601a8c0@pc6>
From: "Tom Petch" <nwnetworks@dial.pipex.com>
To: "Juergen Quittek" <quittek@netlab.nec.de>, <mallman@icir.org>
References: <20050422024134.7D6EB2607F6@lawyers.icir.org>
	<730D8E764C3921D83B5DFB26@[192.168.0.128]>
Subject: Re: [ippm] traceroute as WG work item? 
Date: Thu, 28 Apr 2005 16:05:24 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 2.9 (++)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Content-Transfer-Encoding: 7bit
Cc: ippm@ietf.org
X-BeenThere: ippm@ietf.org 
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Tom Petch <nwnetworks@dial.pipex.com>
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=subscribe>
Sender: ippm-bounces@ietf.org 
Errors-To: ippm-bounces@ietf.org 

----- Original Message -----
From: "Juergen Quittek" <quittek@netlab.nec.de>
To: <mallman@icir.org>
Cc: <ippm@ietf.org>
Sent: Wednesday, April 27, 2005 12:08 AM
Subject: Re: [ippm] traceroute as WG work item?


> Hi Mark,
>
> --On 4/22/2005 4:41 AM +0200 Mark Allman wrote:
>
> >
> >> In March
> >> (http://www.ietf.org/mail-archive/web/ippm/current/msg00553.html) you
> >> stated that you would not be against such work. You just wondered
> >> about why doing it right now.  Can you tell what made you change your
> >> mind since then?
> >
> > Well, I was never really compelled.  I looked over the draft and thought
> > about it more I just don't think we need to do it.  At the end of the
> > day it wouldn't be harmful to do this draft - but I don't find it really
> > needed or even hugely desireable.  (A further hesitation I'd have is
> > that not many folks seem to have indicated interested and so I'd wonder
> > about energy.)
>
> I share this concern.  Is there nobody else interested?
>

My concern too; a technically valid topic but not one that I can generate much
energy for at present.  It does not solve any issues that are bugging me.

Tom Petch


_______________________________________________
ippm mailing list
ippm@ietf.org 
https://www1.ietf.org/mailman/listinfo/ippm