From ippm-bounces@ietf.org Tue Nov 01 08:54:12 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EWwaY-0008Ka-PD; Tue, 01 Nov 2005 08:54:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EWwaW-0008Js-98
	for ippm@megatron.ietf.org; Tue, 01 Nov 2005 08:54:08 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21902
	for <ippm@ietf.org>; Tue, 1 Nov 2005 08:53:48 -0500 (EST)
Received: from vms044pub.verizon.net ([206.46.252.44])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWwon-0005nu-OS
	for ippm@ietf.org; Tue, 01 Nov 2005 09:09:01 -0500
Received: from [192.168.2.104] ([64.238.4.26])
	by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02
	(built Sep
	9 2005)) with ESMTPA id <0IPA00MOK3XZK8J3@vms044.mailsrvcs.net> for
	ippm@ietf.org; Tue, 01 Nov 2005 07:53:59 -0600 (CST)
Date: Tue, 01 Nov 2005 08:53:57 -0500
From: "Philip F. Chimento Jr." <vze275m9@verizon.net>
Subject: Re: [ippm] short preso for the jitter discussion
In-reply-to: <OF65F970B6.C4626491-ON852570AB.007837EC-852570AB.00792A9A@CORE.VERIZON.COM>
To: roman.krzanowski@verizon.com
Message-id: <9f45256a0253e31fd67578d7312b7bfd@verizon.net>
MIME-version: 1.0 (Apple Message framework v623)
X-Mailer: Apple Mail (2.623)
Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-transfer-encoding: 7bit
References: <OF65F970B6.C4626491-ON852570AB.007837EC-852570AB.00792A9A@CORE.VERIZON.COM>
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Content-Transfer-Encoding: 7bit
Cc: Henk Uijterwaal <henk@ripe.net>, 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 Roman:
I looked over your slides briefly. Keep in mind that the RFC 3393  
metric was written specifically to include the ITU definition (at the  
time) as a valid instantiation of the metric. I am at a bit of  a loss  
to understand how these are seen as being in opposition. If the Asian  
and Australian operators want to use a form of the ITU definition, they  
should be able to do it, and that should also be valid for RFC 3393.

Unfortunately I cannot be at Vancouver to discuss this. However, if you  
let me know exactly what the desired definition is, perhaps I can show  
you how you can instantiate this from the RFC metric. I don't have  
access to ITU documents, so if you can send me the definition I can  
work with it.

It is not clear to me that we need a work group to deal with this...

Regards,
Phil Chimento
pfc@ieee.org
301-580-6211

On Oct 31, 2005, at 17:03, roman.krzanowski@verizon.com wrote:

> I am attaching the short preso about the problem and issues I wanted to
> discuss during the IPPM WG meeting
> In vancouver.
> Please send ideas, suggestions or have them ready for the meeting
> thx
> roman
> (See attached file: Jitter  
> DefinitionsIPPM-DEC2005_Vancouver_2.ppt)<Jitter  
> DefinitionsIPPM- 
> DEC2005_Vancouver_2.ppt>_______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www1.ietf.org/mailman/listinfo/ippm


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



From ippm-bounces@ietf.org Tue Nov 01 09:50:16 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EWxSp-0001Ve-V0; Tue, 01 Nov 2005 09:50:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EWxSo-0001VU-9J
	for ippm@megatron.ietf.org; Tue, 01 Nov 2005 09:50:14 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24715
	for <ippm@ietf.org>; Tue, 1 Nov 2005 09:49:54 -0500 (EST)
Received: from mail121.messagelabs.com ([216.82.241.195])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EWxhA-0002Ne-Al
	for ippm@ietf.org; Tue, 01 Nov 2005 10:05:07 -0500
X-VirusChecked: Checked
X-Env-Sender: acmorton@att.com
X-Msg-Ref: server-8.tower-121.messagelabs.com!1130856601!7211966!1
X-StarScan-Version: 5.5.9.1; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 31593 invoked from network); 1 Nov 2005 14:50:01 -0000
Received: from unknown (HELO maillennium.att.com) (134.24.146.4)
	by server-8.tower-121.messagelabs.com with SMTP;
	1 Nov 2005 14:50:01 -0000
Received: from acmt.att.com (acmt.mt.att.com[135.16.251.49](misconfigured
	sender)) by maillennium.att.com (mailgw1) with SMTP
	id <20051101145001gw100lgghue>; Tue, 1 Nov 2005 14:50:01 +0000
Message-Id: <6.2.1.2.0.20051101092106.03f94ff0@postoffice.maillennium.att.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Tue, 01 Nov 2005 09:50:01 -0500
To: "Philip F. Chimento Jr." <vze275m9@verizon.net>,
	roman.krzanowski@verizon.com
From: Al Morton <acmorton@att.com>
Subject: Re: [ippm] short preso for the jitter discussion
In-Reply-To: <9f45256a0253e31fd67578d7312b7bfd@verizon.net>
References: <OF65F970B6.C4626491-ON852570AB.007837EC-852570AB.00792A9A@CORE.VERIZON.COM>
	<9f45256a0253e31fd67578d7312b7bfd@verizon.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: Henk Uijterwaal <henk@ripe.net>, 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 Phil,

After looking at Roman's slides, it seems that he would like
to achieve harmony between jitter definitions and usage, and allow
for some differences according to the intended goal of the
measurement or the circumstances (marginal clock sync, etc.).

I think we can agree that the ITU-T Y.1540 of IP Packet Delay Variation
is similar to the RFC 3393, in that both compare the OWD of a packet with the
OWD of another packet, and that the difference emerges in the
usual form of implementation. So for those who implement:

- Y.1540, the reference packet is usually the packet from the
population of interest with the *minimum delay*.

- RFC 3393, the reference packet is usually the previous packet,
although the definition of a selection function is flexible enough
to reproduce the ITU-T Y.1540 definition. This feature was included
by design; we were trying to harmonize work between ITU-T and IETF IPPM
and you succeeded from the standpoint of definitions.

So, I think the proposal here is to compare these two different
references for assessing variation (minimum OWD, previous packet),
and it will be a good start to look at the ippm-archive back in
the autumn of 2001, if memory serves. I remember that Rudiger Geib
and Mike Pierce posted some insightful messages on this topic.

regards,
Al

At 08:53 AM 11/1/2005, Philip F. Chimento Jr. wrote:
>Hi Roman:
>I looked over your slides briefly. Keep in mind that the RFC 3393
>metric was written specifically to include the ITU definition (at the
>time) as a valid instantiation of the metric. I am at a bit of  a loss
>to understand how these are seen as being in opposition. If the Asian
>and Australian operators want to use a form of the ITU definition, they
>should be able to do it, and that should also be valid for RFC 3393.
>
>Unfortunately I cannot be at Vancouver to discuss this. However, if you
>let me know exactly what the desired definition is, perhaps I can show
>you how you can instantiate this from the RFC metric. I don't have
>access to ITU documents, so if you can send me the definition I can
>work with it.
>
>It is not clear to me that we need a work group to deal with this...
>
>Regards,
>Phil Chimento
>pfc@ieee.org
>301-580-6211
>
>On Oct 31, 2005, at 17:03, roman.krzanowski@verizon.com wrote:
>
>>I am attaching the short preso about the problem and issues I wanted to
>>discuss during the IPPM WG meeting
>>In vancouver.
>>Please send ideas, suggestions or have them ready for the meeting
>>thx
>>roman
>>(See attached file: Jitter
>>DefinitionsIPPM-DEC2005_Vancouver_2.ppt)


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



From ippm-bounces@ietf.org Tue Nov 01 10:09:04 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EWxl1-0002bA-Ur; Tue, 01 Nov 2005 10:09:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EWxl0-0002b2-9R
	for ippm@megatron.ietf.org; Tue, 01 Nov 2005 10:09:02 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25751
	for <ippm@ietf.org>; Tue, 1 Nov 2005 10:08:42 -0500 (EST)
Received: from vms044pub.verizon.net ([206.46.252.44])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWxzM-0003xP-IC
	for ippm@ietf.org; Tue, 01 Nov 2005 10:23:55 -0500
Received: from [192.168.2.104] ([64.238.4.26])
	by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02
	(built Sep
	9 2005)) with ESMTPA id <0IPA005BP7EWTG40@vms044.mailsrvcs.net> for
	ippm@ietf.org; Tue, 01 Nov 2005 09:08:57 -0600 (CST)
Date: Tue, 01 Nov 2005 10:08:55 -0500
From: "Philip F. Chimento Jr." <vze275m9@verizon.net>
Subject: Re: [ippm] short preso for the jitter discussion
In-reply-to: <6.2.1.2.0.20051101092106.03f94ff0@postoffice.maillennium.att.com>
To: Al Morton <acmorton@att.com>
Message-id: <fdd43f0c1e87673c653b8e7c4ce137e4@verizon.net>
MIME-version: 1.0 (Apple Message framework v623)
X-Mailer: Apple Mail (2.623)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7bit
References: <OF65F970B6.C4626491-ON852570AB.007837EC-852570AB.00792A9A@CORE.VERIZON.COM>
	<9f45256a0253e31fd67578d7312b7bfd@verizon.net>
	<6.2.1.2.0.20051101092106.03f94ff0@postoffice.maillennium.att.com>
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a
Content-Transfer-Encoding: 7bit
Cc: roman.krzanowski@verizon.com, Henk Uijterwaal <henk@ripe.net>,
	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:

OK, but what you are saying implies a measurement project. Again, we 
went to a lot of trouble to make sure that the ITU definition could be 
an instantiation of the RFC 3393 metric, and it is. The issue is that 
if you want to report something meaningful, you have to say exactly 
what your selection function is, and always compare apples to apples. 
RFC 3393 allows you to do that. If you want to compare the relative 
merits of one selection function over another (with regard to fitness 
for a particular purpose) then you have to make an analytical argument 
or do an empirical study, in my opinion.

In a sense, that has nothing to do with the metric definition, and 
everything to do with what your measurement goals are. If the metric 
definition doesn't allow you to do something that you need to do, and 
which is legitimate from a statistical point of view, then we need to 
amend the definition; however, I don't see any evidence of that here...



Regards,
Phil Chimento
pfc@ieee.org
301-580-6211

On Nov 1, 2005, at 09:50, Al Morton wrote:

> Hi Phil,
>
> After looking at Roman's slides, it seems that he would like
> to achieve harmony between jitter definitions and usage, and allow
> for some differences according to the intended goal of the
> measurement or the circumstances (marginal clock sync, etc.).
>
> I think we can agree that the ITU-T Y.1540 of IP Packet Delay Variation
> is similar to the RFC 3393, in that both compare the OWD of a packet 
> with the
> OWD of another packet, and that the difference emerges in the
> usual form of implementation. So for those who implement:
>
> - Y.1540, the reference packet is usually the packet from the
> population of interest with the *minimum delay*.
>
> - RFC 3393, the reference packet is usually the previous packet,
> although the definition of a selection function is flexible enough
> to reproduce the ITU-T Y.1540 definition. This feature was included
> by design; we were trying to harmonize work between ITU-T and IETF IPPM
> and you succeeded from the standpoint of definitions.
>
> So, I think the proposal here is to compare these two different
> references for assessing variation (minimum OWD, previous packet),
> and it will be a good start to look at the ippm-archive back in
> the autumn of 2001, if memory serves. I remember that Rudiger Geib
> and Mike Pierce posted some insightful messages on this topic.
>
> regards,
> Al
>
> At 08:53 AM 11/1/2005, Philip F. Chimento Jr. wrote:
>> Hi Roman:
>> I looked over your slides briefly. Keep in mind that the RFC 3393
>> metric was written specifically to include the ITU definition (at the
>> time) as a valid instantiation of the metric. I am at a bit of  a loss
>> to understand how these are seen as being in opposition. If the Asian
>> and Australian operators want to use a form of the ITU definition, 
>> they
>> should be able to do it, and that should also be valid for RFC 3393.
>>
>> Unfortunately I cannot be at Vancouver to discuss this. However, if 
>> you
>> let me know exactly what the desired definition is, perhaps I can show
>> you how you can instantiate this from the RFC metric. I don't have
>> access to ITU documents, so if you can send me the definition I can
>> work with it.
>>
>> It is not clear to me that we need a work group to deal with this...
>>
>> Regards,
>> Phil Chimento
>> pfc@ieee.org
>> 301-580-6211
>>
>> On Oct 31, 2005, at 17:03, roman.krzanowski@verizon.com wrote:
>>
>>> I am attaching the short preso about the problem and issues I wanted 
>>> to
>>> discuss during the IPPM WG meeting
>>> In vancouver.
>>> Please send ideas, suggestions or have them ready for the meeting
>>> thx
>>> roman
>>> (See attached file: Jitter
>>> DefinitionsIPPM-DEC2005_Vancouver_2.ppt)
>


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



From ippm-bounces@ietf.org Tue Nov 01 10:36:02 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EWyB8-0000V0-Q0; Tue, 01 Nov 2005 10:36:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EWyB6-0000Ur-WE
	for ippm@megatron.ietf.org; Tue, 01 Nov 2005 10:36:01 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27021
	for <ippm@ietf.org>; Tue, 1 Nov 2005 10:35:40 -0500 (EST)
Received: from mail126.messagelabs.com ([216.82.254.83])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EWyPT-0006Up-PE
	for ippm@ietf.org; Tue, 01 Nov 2005 10:50:54 -0500
X-VirusChecked: Checked
X-Env-Sender: acmorton@att.com
X-Msg-Ref: server-2.tower-126.messagelabs.com!1130859344!9232996!1
X-StarScan-Version: 5.5.9.1; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 25749 invoked from network); 1 Nov 2005 15:35:44 -0000
Received: from unknown (HELO maillennium.att.com) (134.24.146.4)
	by server-2.tower-126.messagelabs.com with SMTP;
	1 Nov 2005 15:35:44 -0000
Received: from acmt.att.com (acmt.mt.att.com[135.16.251.49](misconfigured
	sender)) by maillennium.att.com (mailgw1) with SMTP
	id <20051101153159gw100lggige>; Tue, 1 Nov 2005 15:31:59 +0000
Message-Id: <6.2.1.2.0.20051101102729.03d2b670@postoffice.maillennium.att.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Tue, 01 Nov 2005 10:31:59 -0500
To: "Philip F. Chimento Jr." <vze275m9@verizon.net>
From: Al Morton <acmorton@att.com>
Subject: Re: [ippm] short preso for the jitter discussion
In-Reply-To: <fdd43f0c1e87673c653b8e7c4ce137e4@verizon.net>
References: <OF65F970B6.C4626491-ON852570AB.007837EC-852570AB.00792A9A@CORE.VERIZON.COM>
	<9f45256a0253e31fd67578d7312b7bfd@verizon.net>
	<6.2.1.2.0.20051101092106.03f94ff0@postoffice.maillennium.att.com>
	<fdd43f0c1e87673c653b8e7c4ce137e4@verizon.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Cc: roman.krzanowski@verizon.com, Henk Uijterwaal <henk@ripe.net>,
	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 10:08 AM 11/1/2005, Philip F. Chimento Jr. wrote:
>...If you want to compare the relative merits of one selection function 
>over another (with regard to fitness for a particular purpose) then you 
>have to make an analytical argument or do an empirical study, in my opinion.

Agreed, and that's my take on Roman's work proposal.  Perhaps
this work could result in an Application Statement on delay variation,
but I don't see a need to modify the definition(s), either.

Al



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



From ippm-bounces@ietf.org Tue Nov 01 10:37:26 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EWyCT-0000k1-V6; Tue, 01 Nov 2005 10:37:25 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EWlng-0006mV-SX; Mon, 31 Oct 2005 21:23:01 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03688;
	Mon, 31 Oct 2005 21:22:41 -0500 (EST)
Received: from mx.cbeyond.net ([66.180.96.58] helo=mx.cbeyond.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EWm1y-00031d-Fh; Mon, 31 Oct 2005 21:37:47 -0500
Received: from [67.33.136.92] (port=4728 helo=[192.168.1.103])
	by mx.cbeyond.com with asmtp (Exim 4.34)
	id 1EWlna-0002l6-J7; Mon, 31 Oct 2005 21:22:54 -0500
Message-ID: <4366D17D.9070407@telchemy.com>
Date: Mon, 31 Oct 2005 21:22:53 -0500
From: Alan Clark <alan.d.clark@telchemy.com>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: roman.krzanowski@verizon.com
Subject: Re: [ippm] short preso for the jitter discussion
References: <OF65F970B6.C4626491-ON852570AB.007837EC-852570AB.00792A9A@CORE.VERIZON.COM>
In-Reply-To: <OF65F970B6.C4626491-ON852570AB.007837EC-852570AB.00792A9A@CORE.VERIZON.COM>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Tue, 01 Nov 2005 10:37:24 -0500
Cc: ippm@ietf.org, Henk Uijterwaal <henk@ripe.net>, ippm-bounces@ietf.org
X-BeenThere: ippm@ietf.org 
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <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 


Roman

Unfortunately I won't get to Vancouver until mid-day Tuesday however 
would welcome an offline discussion on jitter, and would appreciate the 
opportunity to get involved in any jitter modeling related activity 
resulting from the IPPM meeting.  You may be interested to know that the 
time series model described in our January 2003 contribution to ITU SG12 
was used as the basis for a new IP network emulation model, recently 
adopted by SG12. 

Regards

Alan Clark
Telchemy


roman.krzanowski@verizon.com wrote:

>I am attaching the short preso about the problem and issues I wanted to
>discuss during the IPPM WG meeting
>In vancouver.
>Please send ideas, suggestions or have them ready for the meeting
>thx
>roman
>(See attached file: Jitter DefinitionsIPPM-DEC2005_Vancouver_2.ppt)
>
>------------------------------------------------------------------------
>
>_______________________________________________
>ippm mailing list
>ippm@ietf.org 
>https://www1.ietf.org/mailman/listinfo/ippm
>  
>


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



From ippm-bounces@ietf.org Thu Nov 03 04:58:23 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EXbrT-00088G-6r; Thu, 03 Nov 2005 04:58:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EXbrR-00087C-9l
	for ippm@megatron.ietf.org; Thu, 03 Nov 2005 04:58:21 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18546
	for <ippm@ietf.org>; Thu, 3 Nov 2005 04:58:00 -0500 (EST)
Received: from alpha.dante.org.uk ([193.63.211.19] helo=mail.dante.org.uk)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXc6B-0000vW-Rc
	for ippm@ietf.org; Thu, 03 Nov 2005 05:13:37 -0500
Received: from [127.0.0.1] (helo=localhost)
	by mail.dante.org.uk with esmtp (Exim 4.51) id 1EXbqx-00064r-62
	for ippm@ietf.org; Thu, 03 Nov 2005 09:57:51 +0000
Received: from mail.dante.org.uk ([127.0.0.1])
	by localhost (alpha [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
	id 23280-05 for <ippm@ietf.org>; Thu,  3 Nov 2005 09:57:45 +0000 (GMT)
Received: from alpha.dante.org.uk ([193.63.211.19] helo=[127.0.0.1])
	by mail.dante.org.uk with esmtp (Exim 4.51) id 1EXbqr-00064n-9h
	for ippm@ietf.org; Thu, 03 Nov 2005 09:57:45 +0000
Message-ID: <4369DF1C.3020508@dante.org.uk>
Date: Thu, 03 Nov 2005 09:57:48 +0000
From: Maurizio Molina <maurizio.molina@dante.org.uk>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.7) Gecko/20050414
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ippm@ietf.org
Subject: Re: [ippm] short preso for the jitter discussion
References: <OF65F970B6.C4626491-ON852570AB.007837EC-852570AB.00792A9A@CORE.VERIZON.COM>	<9f45256a0253e31fd67578d7312b7bfd@verizon.net>
	<6.2.1.2.0.20051101092106.03f94ff0@postoffice.maillennium.att.com>
In-Reply-To: <6.2.1.2.0.20051101092106.03f94ff0@postoffice.maillennium.att.com>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: amavisd-new at dante.org.uk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Content-Transfer-Encoding: 7bit
Cc: 
X-BeenThere: ippm@ietf.org 
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <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 

Al Morton wrote:

> Hi Phil,
>
> After looking at Roman's slides, it seems that he would like
> to achieve harmony between jitter definitions and usage, and allow
> for some differences according to the intended goal of the
> measurement or the circumstances (marginal clock sync, etc.).
>
> I think we can agree that the ITU-T Y.1540 of IP Packet Delay Variation
> is similar to the RFC 3393, in that both compare the OWD of a packet
> with the
> OWD of another packet, and that the difference emerges in the
> usual form of implementation. So for those who implement:
>
> - Y.1540, the reference packet is usually the packet from the
> population of interest with the *minimum delay*.
>
> - RFC 3393, the reference packet is usually the previous packet,
> although the definition of a selection function is flexible enough
> to reproduce the ITU-T Y.1540 definition. This feature was included
> by design; we were trying to harmonize work between ITU-T and IETF IPPM
> and you succeeded from the standpoint of definitions.
>
> So, I think the proposal here is to compare these two different
> references for assessing variation (minimum OWD, previous packet),
> and it will be a good start to look at the ippm-archive back in
> the autumn of 2001, if memory serves. I remember that Rudiger Geib
> and Mike Pierce posted some insightful messages on this topic.

The IPPM archives seem to stop at 2003....
however, I remeber a paper from Demichelis-Chimento pointing out that
taking the previous packet as a reference, you can also understand the
dynamic of IPDV, i.e. how it grows and shrinks over time. This is not
easily visible taking a fixed reference as the minimum delay. I guess
that if you reset frequently enough the choice of the fixed reference,
you can also introduce a visibility of the dynamic with the Y.1540
definition. But still, besides the "formal" similarity, there is a
conceptual (and usage) difference between the two.
Maurizio

>
> regards,
> Al
>
> At 08:53 AM 11/1/2005, Philip F. Chimento Jr. wrote:
>
>> Hi Roman:
>> I looked over your slides briefly. Keep in mind that the RFC 3393
>> metric was written specifically to include the ITU definition (at the
>> time) as a valid instantiation of the metric. I am at a bit of  a loss
>> to understand how these are seen as being in opposition. If the Asian
>> and Australian operators want to use a form of the ITU definition, they
>> should be able to do it, and that should also be valid for RFC 3393.
>>
>> Unfortunately I cannot be at Vancouver to discuss this. However, if you
>> let me know exactly what the desired definition is, perhaps I can show
>> you how you can instantiate this from the RFC metric. I don't have
>> access to ITU documents, so if you can send me the definition I can
>> work with it.
>>
>> It is not clear to me that we need a work group to deal with this...
>>
>> Regards,
>> Phil Chimento
>> pfc@ieee.org
>> 301-580-6211
>>
>> On Oct 31, 2005, at 17:03, roman.krzanowski@verizon.com wrote:
>>
>>> I am attaching the short preso about the problem and issues I wanted to
>>> discuss during the IPPM WG meeting
>>> In vancouver.
>>> Please send ideas, suggestions or have them ready for the meeting
>>> thx
>>> roman
>>> (See attached file: Jitter
>>> DefinitionsIPPM-DEC2005_Vancouver_2.ppt)
>>
>
>
> _______________________________________________
> ippm mailing list
> ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm




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



From ippm-bounces@ietf.org Thu Nov 03 05:38:03 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EXcTr-0005Ch-F4; Thu, 03 Nov 2005 05:38:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EXcTo-0005Bp-RW
	for ippm@megatron.ietf.org; Thu, 03 Nov 2005 05:38:01 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21969
	for <ippm@ietf.org>; Thu, 3 Nov 2005 05:37:39 -0500 (EST)
Received: from mailserv.intranet.gr ([146.124.14.106])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXciY-0002m8-OA
	for ippm@ietf.org; Thu, 03 Nov 2005 05:53:17 -0500
Received: from mailserv.intranet.gr (localhost [127.0.0.1])
	by mailserv.intranet.gr (8.13.1/8.13.1) with ESMTP id jA3AjlN3024651
	for <ippm@ietf.org>; Thu, 3 Nov 2005 12:45:47 +0200 (EET)
Received: from iris.intranet.gr (iris.intranet.GR [146.124.80.178])
	by mailserv.intranet.gr (8.13.1/8.13.1) with ESMTP id jA3Ajl4Q024642
	for <ippm@ietf.org>; Thu, 3 Nov 2005 12:45:47 +0200 (EET)
Received: from [146.124.44.189] (HELO pcnt189)
	by iris.intranet.gr (CommuniGate Pro SMTP 4.3.8)
	with SMTP id 1784633 for ippm@ietf.org; Thu, 03 Nov 2005 12:48:15 +0200
Message-ID: <01f301c5e06b$541ee300$bd2c7c92@intranet.gr>
From: "Spiros Spirou" <spis@intracom.gr>
To: <ippm@ietf.org>
Date: Thu, 3 Nov 2005 12:40:02 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-7"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Content-Transfer-Encoding: 7bit
Cc: 
Subject: [ippm] RTP timestamp as SrcTime in draft-ietf-ippm-reordering-10
X-BeenThere: ippm@ietf.org 
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Spiros Spirou <spiros.spirou@ieee.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>
Sender: ippm-bounces@ietf.org 
Errors-To: ippm-bounces@ietf.org 

Hi folks,

Is it terribly wrong to use the RTP timestamp as the SrcTime parameter of
the Type-P-Reordered metric?

TIA,

Spiros


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



From ippm-bounces@ietf.org Thu Nov 03 07:55:46 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EXed7-00075B-Sf; Thu, 03 Nov 2005 07:55:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EXed6-00074h-CU
	for ippm@megatron.ietf.org; Thu, 03 Nov 2005 07:55:44 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28992
	for <ippm@ietf.org>; Thu, 3 Nov 2005 07:55:22 -0500 (EST)
Received: from vms048pub.verizon.net ([206.46.252.48])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXerr-0000x4-NU
	for ippm@ietf.org; Thu, 03 Nov 2005 08:11:02 -0500
Received: from [192.168.2.104] ([64.238.4.26])
	by vms048.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02
	(built Sep
	9 2005)) with ESMTPA id <0IPD00AN2QKEKYQ3@vms048.mailsrvcs.net> for
	ippm@ietf.org; Thu, 03 Nov 2005 06:55:27 -0600 (CST)
Date: Thu, 03 Nov 2005 07:55:26 -0500
From: "Philip F. Chimento Jr." <vze275m9@verizon.net>
Subject: Re: [ippm] short preso for the jitter discussion
In-reply-to: <4369DF1C.3020508@dante.org.uk>
To: Maurizio Molina <maurizio.molina@dante.org.uk>
Message-id: <7b82999fed66cda2bf910c5b81712905@verizon.net>
MIME-version: 1.0 (Apple Message framework v623)
X-Mailer: Apple Mail (2.623)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7bit
References: <OF65F970B6.C4626491-ON852570AB.007837EC-852570AB.00792A9A@CORE.VERIZON.COM>
	<9f45256a0253e31fd67578d7312b7bfd@verizon.net>
	<6.2.1.2.0.20051101092106.03f94ff0@postoffice.maillennium.att.com>
	<4369DF1C.3020508@dante.org.uk>
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 2086112c730e13d5955355df27e3074b
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 Maurizio:

I agree that the ITU definition, and the common usage of inter-packet 
delay variation are different. The point is that RFC 3393 was written 
to allow the person/organization using the metric to define the 
selection function, which in effect defines the semantic of the metric. 
If you choose two different selection functions, you have two different 
semantics and the results of using those metrics cannot be compared 
directly, unless you establish (mathematically) a relationship between 
the two.

If you want to compare metrics, you need to argue that one or another 
is better for a particular purpose. If you want to establish one 
semantic that is optimal for ALL uses, I would be very interested to 
read the results of that research.



Regards,
Phil Chimento

On Nov 3, 2005, at 04:57, Maurizio Molina wrote:

> Al Morton wrote:
>
>> Hi Phil,
>>
>> After looking at Roman's slides, it seems that he would like
>> to achieve harmony between jitter definitions and usage, and allow
>> for some differences according to the intended goal of the
>> measurement or the circumstances (marginal clock sync, etc.).
>>
>> I think we can agree that the ITU-T Y.1540 of IP Packet Delay 
>> Variation
>> is similar to the RFC 3393, in that both compare the OWD of a packet
>> with the
>> OWD of another packet, and that the difference emerges in the
>> usual form of implementation. So for those who implement:
>>
>> - Y.1540, the reference packet is usually the packet from the
>> population of interest with the *minimum delay*.
>>
>> - RFC 3393, the reference packet is usually the previous packet,
>> although the definition of a selection function is flexible enough
>> to reproduce the ITU-T Y.1540 definition. This feature was included
>> by design; we were trying to harmonize work between ITU-T and IETF 
>> IPPM
>> and you succeeded from the standpoint of definitions.
>>
>> So, I think the proposal here is to compare these two different
>> references for assessing variation (minimum OWD, previous packet),
>> and it will be a good start to look at the ippm-archive back in
>> the autumn of 2001, if memory serves. I remember that Rudiger Geib
>> and Mike Pierce posted some insightful messages on this topic.
>
> The IPPM archives seem to stop at 2003....
> however, I remeber a paper from Demichelis-Chimento pointing out that
> taking the previous packet as a reference, you can also understand the
> dynamic of IPDV, i.e. how it grows and shrinks over time. This is not
> easily visible taking a fixed reference as the minimum delay. I guess
> that if you reset frequently enough the choice of the fixed reference,
> you can also introduce a visibility of the dynamic with the Y.1540
> definition. But still, besides the "formal" similarity, there is a
> conceptual (and usage) difference between the two.
> Maurizio
>
>>
>> regards,
>> Al
>>
>> At 08:53 AM 11/1/2005, Philip F. Chimento Jr. wrote:
>>
>>> Hi Roman:
>>> I looked over your slides briefly. Keep in mind that the RFC 3393
>>> metric was written specifically to include the ITU definition (at the
>>> time) as a valid instantiation of the metric. I am at a bit of  a 
>>> loss
>>> to understand how these are seen as being in opposition. If the Asian
>>> and Australian operators want to use a form of the ITU definition, 
>>> they
>>> should be able to do it, and that should also be valid for RFC 3393.
>>>
>>> Unfortunately I cannot be at Vancouver to discuss this. However, if 
>>> you
>>> let me know exactly what the desired definition is, perhaps I can 
>>> show
>>> you how you can instantiate this from the RFC metric. I don't have
>>> access to ITU documents, so if you can send me the definition I can
>>> work with it.
>>>
>>> It is not clear to me that we need a work group to deal with this...
>>>
>>> Regards,
>>> Phil Chimento
>>> pfc@ieee.org
>>> 301-580-6211
>>>
>>> On Oct 31, 2005, at 17:03, roman.krzanowski@verizon.com wrote:
>>>
>>>> I am attaching the short preso about the problem and issues I 
>>>> wanted to
>>>> discuss during the IPPM WG meeting
>>>> In vancouver.
>>>> Please send ideas, suggestions or have them ready for the meeting
>>>> thx
>>>> roman
>>>> (See attached file: Jitter
>>>> DefinitionsIPPM-DEC2005_Vancouver_2.ppt)
>>>
>>
>>
>> _______________________________________________
>> ippm mailing list
>> ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm
>
>
>
>
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www1.ietf.org/mailman/listinfo/ippm
>


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



From ippm-bounces@ietf.org Thu Nov 03 10:10:12 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EXgjE-0000GZ-FQ; Thu, 03 Nov 2005 10:10:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EXgjD-0000GP-9Z
	for ippm@megatron.ietf.org; Thu, 03 Nov 2005 10:10:11 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05794
	for <ippm@ietf.org>; Thu, 3 Nov 2005 10:09:48 -0500 (EST)
Received: from cod.ripe.net ([193.0.1.202])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXgy0-0005rp-Sr
	for ippm@ietf.org; Thu, 03 Nov 2005 10:25:29 -0500
Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239])
	by cod.ripe.net (Postfix) with ESMTP id 571B072762;
	Thu,  3 Nov 2005 16:09:50 +0100 (CET)
Message-Id: <6.2.3.4.2.20051103160840.02d0d3b0@localhost>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Thu, 03 Nov 2005 16:09:45 +0100
To: Maurizio Molina <maurizio.molina@dante.org.uk>, ippm@ietf.org
From: Henk Uijterwaal <henk@ripe.net>
Subject: Re: [ippm] short preso for the jitter discussion
In-Reply-To: <4369DF1C.3020508@dante.org.uk>
References: <OF65F970B6.C4626491-ON852570AB.007837EC-852570AB.00792A9A@CORE.VERIZON.COM>
	<9f45256a0253e31fd67578d7312b7bfd@verizon.net>
	<6.2.1.2.0.20051101092106.03f94ff0@postoffice.maillennium.att.com>
	<4369DF1C.3020508@dante.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: 
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 10:57 03/11/2005, Maurizio Molina wrote:

>The IPPM archives seem to stop at 2003....

Where are you looking,

http://www.ietf.org/mail-archive/web/ippp/current

has everything up to this morning.

Henk



------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

Look here junior, don't you be so happy.
And for Heaven's sake, don't you be so sad.                 (Tom Verlaine) 


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



From ippm-bounces@ietf.org Thu Nov 03 10:36:14 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EXh8Q-0007R3-Ls; Thu, 03 Nov 2005 10:36:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EXh8P-0007Qy-DS
	for ippm@megatron.ietf.org; Thu, 03 Nov 2005 10:36:13 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06945
	for <ippm@ietf.org>; Thu, 3 Nov 2005 10:35:50 -0500 (EST)
Received: from tiere.net.avaya.com ([198.152.12.100])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXhND-0006ue-2A
	for ippm@ietf.org; Thu, 03 Nov 2005 10:51:32 -0500
Received: from tiere.net.avaya.com (localhost [127.0.0.1])
	by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id
	jA3FXH4P001990
	for <ippm@ietf.org>; Thu, 3 Nov 2005 10:33:17 -0500 (EST)
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com
	[135.64.105.51])
	by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id
	jA3FVh4P029948
	for <ippm@ietf.org>; Thu, 3 Nov 2005 10:32:28 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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] short preso for the jitter discussion
Date: Thu, 3 Nov 2005 17:32:12 +0200
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F096CE004@is0004avexu1.global.avaya.com>
Thread-Topic: [ippm] short preso for the jitter discussion
Thread-Index: AcXgijJijAtO4GWaRM+55w9w3qPNAAAAVccA
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: "Henk Uijterwaal" <henk@ripe.net>,
	"Maurizio Molina" <maurizio.molina@dante.org.uk>, <ippm@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Content-Transfer-Encoding: quoted-printable
Cc: 
X-BeenThere: ippm@ietf.org 
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <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 

The correct URL should be
http://www.ietf.org/mail-archive/web/ippm/current.

I believe Maurizio is looking for something BEFORE 2003.

Regards,

Dan


=20
=20

> -----Original Message-----
> From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On=20
> Behalf Of Henk Uijterwaal
> Sent: Thursday, November 03, 2005 5:10 PM
> To: Maurizio Molina; ippm@ietf.org
> Subject: Re: [ippm] short preso for the jitter discussion
>=20
> At 10:57 03/11/2005, Maurizio Molina wrote:
>=20
> >The IPPM archives seem to stop at 2003....
>=20
> Where are you looking,
>=20
> http://www.ietf.org/mail-archive/web/ippp/current
>=20
> has everything up to this morning.
>=20
> Henk
>=20
>=20
>=20
> --------------------------------------------------------------
> ----------------
> Henk Uijterwaal                           Email:=20
> henk.uijterwaal(at)ripe.net
> RIPE Network Coordination Centre         =20
> 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
> --------------------------------------------------------------
> ----------------
>=20
> Look here junior, don't you be so happy.
> And for Heaven's sake, don't you be so sad.                =20
> (Tom Verlaine)=20
>=20
>=20
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www1.ietf.org/mailman/listinfo/ippm
>=20

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



From ippm-bounces@ietf.org Thu Nov 03 11:00:16 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EXhVg-0007CG-68; Thu, 03 Nov 2005 11:00:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EXhVe-0007Bj-Tt
	for ippm@megatron.ietf.org; Thu, 03 Nov 2005 11:00:15 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08046
	for <ippm@ietf.org>; Thu, 3 Nov 2005 10:59:51 -0500 (EST)
Received: from herring.ripe.net ([193.0.1.203])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXhZW-0007gk-24
	for ippm@ietf.org; Thu, 03 Nov 2005 11:04:15 -0500
Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239])
	by herring.ripe.net (Postfix) with ESMTP id 672C82F5A1;
	Thu,  3 Nov 2005 16:48:26 +0100 (CET)
Message-Id: <6.2.3.4.2.20051103164623.02d8bc38@localhost>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Thu, 03 Nov 2005 16:48:21 +0100
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>,
	"Maurizio Molina" <maurizio.molina@dante.org.uk>, <ippm@ietf.org>
From: Henk Uijterwaal <henk@ripe.net>
Subject: RE: [ippm] short preso for the jitter discussion
In-Reply-To: <AAB4B3D3CF0F454F98272CBE187FDE2F096CE004@is0004avexu1.glob
	al.avaya.com>
References: <AAB4B3D3CF0F454F98272CBE187FDE2F096CE004@is0004avexu1.global.avaya.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
Cc: 
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 16:32 03/11/2005, Romascanu, Dan (Dan) wrote:
>The correct URL should be
>http://www.ietf.org/mail-archive/web/ippm/current.
>
>I believe Maurizio is looking for something BEFORE 2003.

Aha,

ftp://ftp.ietf.org/ietf-mail-archive/ippm/

which goes back to 1998 (as flat files though).  There is also
some stuff at http://www.advanced.org/ippm/mail.html, but the
mailman archive is unreachable.  I also cannot reach Matt, who
might be able to fix it.

Henk



>Regards,
>
>Dan
>
>
>
>
>
> > -----Original Message-----
> > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On
> > Behalf Of Henk Uijterwaal
> > Sent: Thursday, November 03, 2005 5:10 PM
> > To: Maurizio Molina; ippm@ietf.org
> > Subject: Re: [ippm] short preso for the jitter discussion
> >
> > At 10:57 03/11/2005, Maurizio Molina wrote:
> >
> > >The IPPM archives seem to stop at 2003....
> >
> > Where are you looking,
> >
> > http://www.ietf.org/mail-archive/web/ippp/current
> >
> > has everything up to this morning.
> >
> > Henk
> >
> >
> >
> > --------------------------------------------------------------
> > ----------------
> > Henk Uijterwaal                           Email:
> > henk.uijterwaal(at)ripe.net
> > RIPE Network Coordination Centre
> > http://www.amsterdamned.org/~henk
> > P.O.Box 10096          Singel 258         Phone: +31.20.5354414
> > 1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
> > The Netherlands        The Netherlands    Mobile: +31.6.55861746
> > --------------------------------------------------------------
> > ----------------
> >
> > Look here junior, don't you be so happy.
> > And for Heaven's sake, don't you be so sad.
> > (Tom Verlaine)
> >
> >
> > _______________________________________________
> > ippm mailing list
> > ippm@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ippm
> >

------------------------------------------------------------------------------
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 Nov 03 12:15:18 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EXidi-0001m4-2a; Thu, 03 Nov 2005 12:12:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EXidg-0001lr-4s
	for ippm@megatron.ietf.org; Thu, 03 Nov 2005 12:12:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13618
	for <ippm@ietf.org>; Thu, 3 Nov 2005 12:12:14 -0500 (EST)
Received: from mail126.messagelabs.com ([216.82.254.83])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EXisR-0003kr-Eb
	for ippm@ietf.org; Thu, 03 Nov 2005 12:27:55 -0500
X-VirusChecked: Checked
X-Env-Sender: acmorton@att.com
X-Msg-Ref: server-13.tower-126.messagelabs.com!1131037927!9530662!1
X-StarScan-Version: 5.5.9.1; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 26798 invoked from network); 3 Nov 2005 17:12:07 -0000
Received: from unknown (HELO maillennium.att.com) (134.24.146.4)
	by server-13.tower-126.messagelabs.com with SMTP;
	3 Nov 2005 17:12:07 -0000
Received: from acmt.att.com (acmt.mt.att.com[135.16.251.49](misconfigured
	sender)) by maillennium.att.com (mailgw1) with SMTP
	id <20051103170822gw100lgh67e>; Thu, 3 Nov 2005 17:08:22 +0000
Message-Id: <6.2.1.2.0.20051103114221.03e51410@postoffice.maillennium.att.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Thu, 03 Nov 2005 12:08:22 -0500
To: Spiros Spirou <spiros.spirou@ieee.org>, <ippm@ietf.org>
From: Al Morton <acmorton@att.com>
Subject: Re: [ippm] RTP timestamp as SrcTime in draft-ietf-ippm-reordering-10
In-Reply-To: <01f301c5e06b$541ee300$bd2c7c92@intranet.gr>
References: <01f301c5e06b$541ee300$bd2c7c92@intranet.gr>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: 
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 06:40 AM 11/3/2005, Spiros Spirou wrote:
>Is it terribly wrong to use the RTP timestamp as the SrcTime parameter of
>the Type-P-Reordered metric?
>
>TIA,
>
>Spiros

Thanks for your interest in reordering and for posting your question.

Clearly, we were thinking of "wire time" when defining SrcTime,
as below (from ippm-reordering-10) :

>3.2 Metric Parameters:
>
>    +  Src, the IP address of a host
>
>    +  Dst, the IP address of a host
>
>    +  SrcTime, the time of packet emission from the Source (or wire
>       time)

And from RFC 3550:

>    timestamp: 32 bits
>       The timestamp reflects the sampling instant of the first octet in
>       the RTP data packet.  The sampling instant MUST be derived from a
>       clock that increments monotonically and linearly in time to allow
>       synchronization and jitter calculations (see Section 6.4.1).  The
>       resolution of the clock MUST be sufficient for the desired
>       synchronization accuracy and for measuring packet arrival jitter
>       (one tick per video frame is typically not sufficient). ...

So, whether it is terribly wrong to use the RTP timestamp in place of
wire time depends on what happens between the instant of the
time stamp and the instant of actual packet emission.

If there is a constant delay between time stamping and emission,
then it's a source of error that's easy to characterize and remove.

If there is considerable "source jitter" (the time between timestamp and
emission is variable and significant w.r.t. delay variation in the
test path), then you would be headed toward "terribly wrong" if the error
due to source jitter was ignored.

So, it's best to characterize any source of error, and source jitter
is exactly that in this scenario.

hope this helps,
(the framework RFC 2330 probably treats this topic in general, too)
Al



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



From ippm-bounces@ietf.org Sun Nov 06 20:24:30 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EYvkM-00067z-JY; Sun, 06 Nov 2005 20:24:30 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EYvkK-00067u-RJ
	for ippm@megatron.ietf.org; Sun, 06 Nov 2005 20:24:28 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02862
	for <ippm@ietf.org>; Sun, 6 Nov 2005 20:24:02 -0500 (EST)
Received: from web15407.mail.cnb.yahoo.com ([202.43.216.210])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EYvzf-0002WF-GJ
	for ippm@ietf.org; Sun, 06 Nov 2005 20:40:30 -0500
Received: (qmail 20957 invoked by uid 60001); 7 Nov 2005 01:23:56 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.cn;
	h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=GKj+Qcj9P4PClBCoRbKr9QuW902nZ6USTF9hcHRQ/Y/+1GpU2Hu+MIvqoPtuOZx4954iqlmsabAN9VIY2z7G7TyGW+/jIdWwhvNqRx2KymeeV8Xg2Ne/8/lgAWuP43eDY59UOapzLNjlFfpK4UTqDndiiLcwi1C3enx4+761hJM=
	; 
Message-ID: <20051107012356.20955.qmail@web15407.mail.cnb.yahoo.com>
Received: from [202.96.103.151] by web15407.mail.cnb.yahoo.com via HTTP;
	Mon, 07 Nov 2005 09:23:56 CST
Date: Mon, 7 Nov 2005 09:23:56 +0800 (CST)
From: Jing Shen <jshen_cad@yahoo.com.cn>
Subject: Re: [ippm] short preso for the jitter discussion
To: ippm@ietf.org
In-Reply-To: <7b82999fed66cda2bf910c5b81712905@verizon.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=gb2312
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id UAA02862
Cc: 
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 

>=20
> If you want to compare metrics, you need to argue
> that one or another=20
> is better for a particular purpose. If you want to
> establish one=20
> semantic that is optimal for ALL uses, I would be
> very interested to=20
> read the results of that research.
>=20

The ppt he attached seems to be focusing on that.

Jing



=09

=09
	=09
___________________________________________________________=20
=D1=C5=BB=A2=C3=E2=B7=D1G=D3=CA=CF=E4=A3=AD=D6=D0=B9=FA=B5=DA=D2=BB=BE=F8=
=CE=DE=C0=AC=BB=F8=D3=CA=BC=FE=C9=A7=C8=C5=B3=AC=B4=F3=D3=CA=CF=E4=20
http://cn.mail.yahoo.com


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



From ippm-bounces@ietf.org Sun Nov 06 20:33:25 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EYvsz-0007r8-Mn; Sun, 06 Nov 2005 20:33:25 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EYvsy-0007qt-4D
	for ippm@megatron.ietf.org; Sun, 06 Nov 2005 20:33:24 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03287
	for <ippm@ietf.org>; Sun, 6 Nov 2005 20:32:57 -0500 (EST)
Received: from postman.ripe.net ([193.0.0.199])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYw8S-0002j0-Rj
	for ippm@ietf.org; Sun, 06 Nov 2005 20:49:26 -0500
Received: by postman.ripe.net (Postfix, from userid 4008)
	id E0FE92453B; Mon,  7 Nov 2005 02:33:13 +0100 (CET)
Received: from cod.ripe.net (cod.ripe.net [193.0.1.202])
	by postman.ripe.net (Postfix) with ESMTP id 1EBCE24529
	for <ippm@ietf.org>; Mon,  7 Nov 2005 02:33:12 +0100 (CET)
Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239])
	by cod.ripe.net (Postfix) with ESMTP id BB9E1726B3
	for <ippm@ietf.org>; Mon,  7 Nov 2005 02:33:11 +0100 (CET)
Message-Id: <6.2.3.4.2.20051107023200.02cd7d10@localhost>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Mon, 07 Nov 2005 02:33:04 +0100
To: ippm@ietf.org
From: Henk Uijterwaal <henk@ripe.net>
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.000074 / -5.9
X-RIPE-Signature: 48d3b75f7e047b66787d7348c5ce6868
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: 
Subject: [ippm] Updated agenda for Vancouver
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 

Dear All,

Here's the updated agenda for Vancouver:

Draft agenda IPPM meeting @ IETF64
==================================
1. Administrativia:
    Agenda Bashing, Scribe, Minutes, Blue Sheets
    Full agenda: 10 minutes/speaker + 5 mins of discussion
2. Status of Drafts and Milestones
3. Draft-svdberg-ippm-temporal-00.txt
    Steven van de Berghe
4. Decomposition of metrics
    Al Morton, draft-morton-ippm-composition-01
5. Draft-stephan-ippm-multimetrics-01.txt
    Emile Stephan
6. ITU on IP performance models (Y1541)
    Loki Jorgenson
7. Differences between Interpacket jitter metric and 99-0 percentile
    ITU measure
    Roman Krasnowski
8. Draft-niccolini-ippm-storetraceroutes-01
    Juergen Quittek,
9. TWAMP draft
    Kaynam Hedayat
A. ITU liaison on NSIS
    Al Morton
B. AOB

Henk


------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

Look here junior, don't you be so happy.
And for Heaven's sake, don't you be so sad.                 (Tom Verlaine) 


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



From ippm-bounces@ietf.org Tue Nov 08 00:02:35 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EZLcx-00019M-C9; Tue, 08 Nov 2005 00:02:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EZLcv-00019H-7J
	for ippm@megatron.ietf.org; Tue, 08 Nov 2005 00:02:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10560
	for <ippm@ietf.org>; Tue, 8 Nov 2005 00:02:07 -0500 (EST)
Received: from basie.internet2.edu ([207.75.164.22])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZLsf-0007F2-HP
	for ippm@ietf.org; Tue, 08 Nov 2005 00:18:49 -0500
Received: from localhost (unknown [127.0.0.1])
	by basie.internet2.edu (Postfix) with ESMTP
	id D66E61CDAB5; Tue,  8 Nov 2005 00:02:31 -0500 (EST)
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 07262-10; Tue,  8 Nov 2005 00:02:31 -0500 (EST)
Received: from localhost (unknown [127.0.0.1])
	by basie.internet2.edu (Postfix) with ESMTP
	id 3F9F31CDAB9; Tue,  8 Nov 2005 00:02:31 -0500 (EST)
To: "sharee mcnab" <sharee.mcnab@alliedtelesyn.co.nz>
Subject: Re: [ippm] OWAMP draft - draft*ietf-ippm-owdp-14.txt
References: <s35e0aff.047@aslan.alliedtelesyn.co.nz>
From: stanislav shalunov <shalunov@internet2.edu>
Date: 08 Nov 2005 00:02:37 -0500
In-Reply-To: <s35e0aff.047@aslan.alliedtelesyn.co.nz>
Message-ID: <86hdanvij6.fsf@abel.internet2.edu>
Lines: 65
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: by mail.internet2.edu virus scanner
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
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 

"sharee mcnab" <sharee.mcnab@alliedtelesyn.co.nz> writes:

> At ATR, we've been looking into OWAMP (as well as TWAMP) and had the
> following questions.  Perhaps the authors or others could answer
> these questions?

I can't speak about TWAMP, of which I only have limited knowledge.
It seems that your questions apply to OWAMP, though.

> A.  Page 5.  Section 2, paragraph 2.  States OWAMP-control messages
> use a "Well-known port number" (ie 0-1023).  Is it planned to
> designate & register a defined OWAMP port number for OWAMP-control
> messages?

IANA will only designate the port number after the IESG approves the
draft.  The IESG is currently still in the process of considering it.

> B.  Page 14. Section 3.5 Generally Server-> Sender/Receiver
> interactions for setting up tests and retrieving test data are
> undefined for the more general architecture where the various
> modules are on separate hosts.  This obviously impacts
> interoperability in the more general architecture.  Is it be worth
> extending the standard to include these interactions or
> alternatively defining the standard to limited architectures, maybe
> with an extension for the more general case?

The undefined interactions are meant to support OWAMP-Control access
to devices that speak some other control protocol (perhaps SNMP or
some proprietary protocol such as command names over SSH or whatever),
but do not speak OWAMP-Control, yet are capable of being taught to
speak the simpler OWAMP-Test.  If you have no such devices to support,
there's no need to separate the roles---simply talk OWAMP-Control
directly to the device you want to talk OWAMP-Test to.

> C.  Section 3.5, second to last paragraph.  Setting the Conf-Sender
> and Conf-Receiver seems inconsequential when it is the
> Control-Client speaking to the Server.  Surely this is only of
> importance when the Server is speaking to the Sender/Receiver.

The two fields Conf-Sender and Conf-Receiver being set mean that the
client is asking the server to configure the sender and the receiver,
respectively.

> Also, what is to stop the sender & receiver checking the sender/
> receiver address field to determine if they are the receiver or
> sender?

They should indeed do so to understand if they need to configure
themselves or some third host.  Many OWAMP servers will only be
administratively able to configure themselves.  Others might have some
hosts that they might also be able to configure.

> D.  The OWAMP draft has a strong emphasis on security and
> encryption.  It is not clear to me though that there are enough
> implementation details in the draft to enable interoperability with
> regards to security keys?  Is this the intention or is it planned to
> have limited interoperability in authenticated and encrypted modes?

The protocol's use of cryptography is fully specified and different
implementations should interoperate in all modes.

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

Just my 0.086g of Ag.

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



From ippm-bounces@ietf.org Tue Nov 08 04:15:58 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EZPUa-0004Hr-PO; Tue, 08 Nov 2005 04:10:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EZPUW-0004HX-Ra
	for ippm@megatron.ietf.org; Tue, 08 Nov 2005 04:10:09 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22959
	for <ippm@ietf.org>; Tue, 8 Nov 2005 04:09:41 -0500 (EST)
Received: from mailserv.intranet.gr ([146.124.14.106])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZPkH-0005Em-9f
	for ippm@ietf.org; Tue, 08 Nov 2005 04:26:27 -0500
Received: from mailserv.intranet.gr (localhost [127.0.0.1])
	by mailserv.intranet.gr (8.13.1/8.13.1) with ESMTP id jA89HtOq025782
	for <ippm@ietf.org>; Tue, 8 Nov 2005 11:17:56 +0200 (EET)
Received: from iris.intranet.gr (iris.intranet.GR [146.124.80.178])
	by mailserv.intranet.gr (8.13.1/8.13.1) with ESMTP id jA89HqHr025752;
	Tue, 8 Nov 2005 11:17:54 +0200 (EET)
Received: from [146.124.44.189] (HELO pcnt189)
	by iris.intranet.gr (CommuniGate Pro SMTP 4.3.8)
	with SMTP id 1814895; Tue, 08 Nov 2005 11:20:21 +0200
Message-ID: <000601c5e44c$e3179c70$bd2c7c92@intranet.gr>
From: "Spiros Spirou" <spis@intracom.gr>
To: "Al Morton" <acmorton@att.com>
References: <01f301c5e06b$541ee300$bd2c7c92@intranet.gr>
	<6.2.1.2.0.20051103114221.03e51410@postoffice.maillennium.att.com>
Subject: Re: [ippm] RTP timestamp as SrcTime in draft-ietf-ippm-reordering-10
Date: Tue, 8 Nov 2005 11:12:12 +0100
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.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Content-Transfer-Encoding: 7bit
Cc: ippm@ietf.org
X-BeenThere: ippm@ietf.org 
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Spiros Spirou <spiros.spirou@ieee.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>
Sender: ippm-bounces@ietf.org 
Errors-To: ippm-bounces@ietf.org 

Hi Al,

Thanks for the reply.

I may be trying to misuse the draft: What I have in mind is a self-contained
measuring device (receiver) that reports the Type-P-Reordered metric and
associated parameters (including SrcTime for completeness).

However, it seems that the requirement to report SrcTime as wire time
prohibits a self-contained Type-P-Reordered measurement, because it
necessitates a simultaneous measurement of the transmission wire time at the
source. Following from your correct observations, this complication may also
hold when earlier times (such as the RTP timestamp) are used in reporting
the SrcTime, because one still needs to detect, estimate, and remove the
"source jitter" component, and I don't see how these can be done at the
receiver without measurements at the server as well.

So, am I going up a dead-end? Is there a way to report the SrcTime as (the
elusive) wire time without access to the server?

Regards,

Spiros

----- Original Message ----- 
From: "Al Morton" <acmorton@att.com>
To: "Spiros Spirou" <spiros.spirou@ieee.org>; <ippm@ietf.org>
Sent: Thursday, November 03, 2005 6:08 PM
Subject: Re: [ippm] RTP timestamp as SrcTime in
draft-ietf-ippm-reordering-10


> At 06:40 AM 11/3/2005, Spiros Spirou wrote:
> >Is it terribly wrong to use the RTP timestamp as the SrcTime parameter of
> >the Type-P-Reordered metric?
> >
> >TIA,
> >
> >Spiros
>
> Thanks for your interest in reordering and for posting your question.
>
> Clearly, we were thinking of "wire time" when defining SrcTime,
> as below (from ippm-reordering-10) :
>
> >3.2 Metric Parameters:
> >
> >    +  Src, the IP address of a host
> >
> >    +  Dst, the IP address of a host
> >
> >    +  SrcTime, the time of packet emission from the Source (or wire
> >       time)
>
> And from RFC 3550:
>
> >    timestamp: 32 bits
> >       The timestamp reflects the sampling instant of the first octet in
> >       the RTP data packet.  The sampling instant MUST be derived from a
> >       clock that increments monotonically and linearly in time to allow
> >       synchronization and jitter calculations (see Section 6.4.1).  The
> >       resolution of the clock MUST be sufficient for the desired
> >       synchronization accuracy and for measuring packet arrival jitter
> >       (one tick per video frame is typically not sufficient). ...
>
> So, whether it is terribly wrong to use the RTP timestamp in place of
> wire time depends on what happens between the instant of the
> time stamp and the instant of actual packet emission.
>
> If there is a constant delay between time stamping and emission,
> then it's a source of error that's easy to characterize and remove.
>
> If there is considerable "source jitter" (the time between timestamp and
> emission is variable and significant w.r.t. delay variation in the
> test path), then you would be headed toward "terribly wrong" if the error
> due to source jitter was ignored.
>
> So, it's best to characterize any source of error, and source jitter
> is exactly that in this scenario.
>
> hope this helps,
> (the framework RFC 2330 probably treats this topic in general, too)
> Al
>
>
>


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



From ippm-bounces@ietf.org Tue Nov 08 15:24:08 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EZa0m-0000AW-KJ; Tue, 08 Nov 2005 15:24:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EZa0l-00009t-KX
	for ippm@megatron.ietf.org; Tue, 08 Nov 2005 15:24:07 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01285
	for <ippm@ietf.org>; Tue, 8 Nov 2005 15:23:39 -0500 (EST)
Received: from relay.jaalam.net ([209.139.228.35])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EZaGY-0007Hl-Mj
	for ippm@ietf.org; Tue, 08 Nov 2005 15:40:28 -0500
Received: from jsrvr8.jaalam.net ([172.16.128.105])
	by relay.jaalam.net (SMSSMTP 4.1.0.19) with SMTP id
	M2005110812233530119
	for <ippm@ietf.org>; Tue, 08 Nov 2005 12:23:35 -0800
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: Tue, 8 Nov 2005 12:23:34 -0800
Message-ID: <F09324DCDD2F5D488EAC603D6B299DC7012EF0FC@jsrvr8.jaalam.net>
Thread-Topic: apologies for missing IPPM meeting
Thread-Index: AcXjvoENjkjB+ByASz+0ijfAQyZujQA44lGg
From: "Loki Jorgenson" <ljorgenson@apparentnetworks.com>
To: <ippm@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Content-Transfer-Encoding: quoted-printable
Cc: 
Subject: [ippm] apologies for missing IPPM meeting
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 

=20
Apologies to the group for missing the morning meeting - I was to attend
only for the IPPM meeting and I had it down as 13:00 (not 09:00) on
Monday.  So simply missed it.

Loki Jorgenson
Chief Scientist
Apparent Networks
The Hudson House
Suite 400 - 321 Water Street
Vancouver, BC, Canada, V6B 1B8

e   ljorgenson@ApparentNetworks.com
t   604 433 2333 ext 105
f   604 433 2311
m   604 250-4642
w   www.ApparentNetworks.com


Message: 2
Date: Mon, 07 Nov 2005 02:33:04 +0100
From: Henk Uijterwaal <henk@ripe.net>
Subject: [ippm] Updated agenda for Vancouver
To: ippm@ietf.org
Message-ID: <6.2.3.4.2.20051107023200.02cd7d10@localhost>
Content-Type: text/plain; charset=3D"us-ascii"; format=3Dflowed

Dear All,

Here's the updated agenda for Vancouver:

Draft agenda IPPM meeting @ IETF64
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
1. Administrativia:
    Agenda Bashing, Scribe, Minutes, Blue Sheets
    Full agenda: 10 minutes/speaker + 5 mins of discussion
2. Status of Drafts and Milestones
3. Draft-svdberg-ippm-temporal-00.txt
    Steven van de Berghe
4. Decomposition of metrics
    Al Morton, draft-morton-ippm-composition-01
5. Draft-stephan-ippm-multimetrics-01.txt
    Emile Stephan
6. ITU on IP performance models (Y1541)
    Loki Jorgenson
7. Differences between Interpacket jitter metric and 99-0 percentile
    ITU measure
    Roman Krasnowski
8. Draft-niccolini-ippm-storetraceroutes-01
    Juergen Quittek,
9. TWAMP draft
    Kaynam Hedayat
A. ITU liaison on NSIS
    Al Morton
B. AOB

Henk


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



From ippm-bounces@ietf.org Tue Nov 08 18:50:38 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EZdEc-0007Jh-C4; Tue, 08 Nov 2005 18:50:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EZdE7-0007Bd-Pg; Tue, 08 Nov 2005 18:50:08 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14242;
	Tue, 8 Nov 2005 18:49:41 -0500 (EST)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EZdTz-0004xB-Pl; Tue, 08 Nov 2005 19:06:32 -0500
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1EZdE1-0005E5-Ti; Tue, 08 Nov 2005 18:50:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1EZdE1-0005E5-Ti@newodin.ietf.org>
Date: Tue, 08 Nov 2005 18:50:01 -0500
X-Spam-Score: 0.4 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: ippm@ietf.org
Subject: [ippm] I-D ACTION:draft-ietf-ippm-owdp-15.txt 
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 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Performance Metrics Working Group of the IETF.

	Title		: A One-way Active Measurement Protocol (OWAMP)
	Author(s)	: S. Shalunov, et al.
	Filename	: draft-ietf-ippm-owdp-15.txt
	Pages		: 55
	Date		: 2005-11-8
	
With growing availability of good time sources to network nodes, it
   becomes increasingly possible to measure one-way IP performance
   metrics with high precision.  To do so in an interoperable manner, a
   common protocol for such measurements is required.  The One-Way
   Active Measurement Protocol (OWAMP) can measure one-way delay, as
   well as other unidirectional characteristics, such as one-way loss.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ippm-owdp-15.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ippm-owdp-15.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ippm-owdp-15.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2005-11-8161331.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ippm-owdp-15.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-ippm-owdp-15.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2005-11-8161331.I-D@ietf.org>


--OtherAccess--

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

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

--NextPart--




From ippm-bounces@ietf.org Wed Nov 09 14:12:07 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EZvMd-0007us-8Y; Wed, 09 Nov 2005 14:12:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EZvMb-0007uZ-Uf
	for ippm@megatron.ietf.org; Wed, 09 Nov 2005 14:12:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01493
	for <ippm@ietf.org>; Wed, 9 Nov 2005 14:11:36 -0500 (EST)
Received: from postman.ripe.net ([193.0.0.199])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZvcc-0006Ri-V9
	for ippm@ietf.org; Wed, 09 Nov 2005 14:28:40 -0500
Received: by postman.ripe.net (Postfix, from userid 4008)
	id 91B1F2445A; Wed,  9 Nov 2005 20:11:53 +0100 (CET)
Received: from cod.ripe.net (cod.ripe.net [193.0.1.202])
	by postman.ripe.net (Postfix) with ESMTP id BB252248F3
	for <ippm@ietf.org>; Wed,  9 Nov 2005 20:11:52 +0100 (CET)
Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239])
	by cod.ripe.net (Postfix) with ESMTP id 1C1D0726A3
	for <ippm@ietf.org>; Wed,  9 Nov 2005 20:11:51 +0100 (CET)
Message-Id: <6.2.3.4.2.20051109200624.02d56e70@localhost>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Wed, 09 Nov 2005 20:10:56 +0100
To: ippm@ietf.org
From: Henk Uijterwaal <henk@ripe.net>
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.000480 / -5.9
X-RIPE-Signature: a5e3152a716affcd77c7b55be3aa8295
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Cc: 
Subject: [ippm] Updated milestones
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 

Dear all,

I've gone through the list of milestones that we had for the group,
added all the actions that I think we took up last Monday, and put
in a guess for a completion date.  The names are the names of the
people who I think are primarily working on a draft.

If your name is listed, can you please check if this is reasonable.

If you think you took up an action and you cannot find it here, please
let me know.

I'll send this list to Allison for approval on Wednesday Nov 16.

Henk

- - - - --

Dec 05  Submit draft on the One-Way Active Measurement Protocol to the IESG
         for consideration as a PS.
         (Stanislav Shalunov)

Dec 05  Collect implementation reports for RFCs 2678-2681
         (Henk Uijterwaal)

Jan 06  Submit initial applicability statement for the IPPM and ITU
         Jitter Measurements
         (Roman Krasnowski)

Jan 06  Submit draft on a packet reordering metric to the IESG for Proposed
         Standard.
         (Al Morton)

Jun 06  Submit draft on Two-way active measurements protocol (TWAMP) to the
         IESG for consideration as proposed standard.
         (Kaynam Heyadat)

Jun 06  Submit link bandwidth capacity definitions draft to the IESG, for
         consideration as an Informational RFC.
         (Phil Chimento, Joe Ishac)

XXX 06  Submit draft on spatial composition of metrics
         (Al Morton)

XXX 06  Submit draft on Temporal Aggregation of Metrics
         (Steven van de Berghe)

XXX 06  Submit draft on IPPM Multiparty metrics
         (Emile Stephan)

XXX 06  Submit draft on storing results of traceroute measurements
         (Saverio Nicolini)

Aug 06  Develop new charter text



------------------------------------------------------------------------------
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 Nov 10 19:27:23 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EaMlH-0004vZ-Bk; Thu, 10 Nov 2005 19:27:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EaMlF-0004vQ-Ub
	for ippm@megatron.ietf.org; Thu, 10 Nov 2005 19:27:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27689
	for <ippm@ietf.org>; Thu, 10 Nov 2005 19:26:52 -0500 (EST)
Received: from gate.alliedtelesyn.co.nz ([202.49.72.33] ident=proxyuser)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EaN1Y-0001ND-4p
	for ippm@ietf.org; Thu, 10 Nov 2005 19:44:13 -0500
Received: (qmail 22169 invoked from network); 11 Nov 2005 00:27:04 -0000
Received: from mailmarshall.alliedtelesyn.co.nz (10.32.18.40)
	by gate-int.alliedtelesyn.co.nz with SMTP; 11 Nov 2005 00:27:04 -0000
Received: from aslan.alliedtelesyn.co.nz (Not Verified[10.32.18.53]) by
	mailmarshall.alliedtelesyn.co.nz with NetIQ MailMarshal (v5.5.6.7)
	id <B00045947d>; Fri, 11 Nov 2005 13:26:20 +1300
Received: from CHCDOM1-MTA by aslan.alliedtelesyn.co.nz
	with Novell_GroupWise; Fri, 11 Nov 2005 13:27:04 +1300
Message-Id: <s3749c28.007@aslan.alliedtelesyn.co.nz>
X-Mailer: Novell GroupWise Internet Agent 6.5.4 
Date: Fri, 11 Nov 2005 13:26:32 +1300
From: "nick kinraid" <nick.kinraid@alliedtelesyn.co.nz>
To: <ippm@ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Content-Transfer-Encoding: quoted-printable
Cc: 
Subject: [ippm] Comment on draft-ietf-ippm-owdp-14
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,=20
Just a small comment,

In section 3.5, page 16, 2nd to last paragraph:
"Otherwise, SID is a unique server-generated session identifier." ,
referring to the case when conf-receiver was set.

However on page 17, top paragraph:
"Note that SID is always chosen by the reciever."

Previous statments in the document refer to the receiving side generating=
=20the SID, so maybe the first sentence is incorrect and can be changed t=
o read 'session-receiver generated...".

Regards
Nick Kinraid
NOTICE: This message contains privileged and confidential
information intended only for the use of the addressee
named above. If you are not the intended recipient of
this message you are hereby notified that you must not
disseminate, copy or take any action in reliance on it.
If you have received this message in error please
notify Allied Telesyn Research Ltd immediately.
Any views expressed in this message are those of the
individual sender, except where the sender has the
authority to issue and specifically states them to
be the views of Allied Telesyn Research.

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



From ippm-bounces@ietf.org Fri Nov 11 00:53:59 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EaRrL-0007VP-4g; Fri, 11 Nov 2005 00:53:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EaRrJ-0007UF-3V
	for ippm@megatron.ietf.org; Fri, 11 Nov 2005 00:53:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15323
	for <ippm@ietf.org>; Fri, 11 Nov 2005 00:53:27 -0500 (EST)
Received: from basie.internet2.edu ([207.75.164.22])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaS7e-0001Fe-LD
	for ippm@ietf.org; Fri, 11 Nov 2005 01:10:51 -0500
Received: from localhost (unknown [127.0.0.1])
	by basie.internet2.edu (Postfix) with ESMTP
	id 475011CD975; Fri, 11 Nov 2005 00:53:52 -0500 (EST)
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 09596-04; Fri, 11 Nov 2005 00:53:52 -0500 (EST)
Received: from localhost (unknown [127.0.0.1])
	by basie.internet2.edu (Postfix) with ESMTP
	id EA3F61CD970; Fri, 11 Nov 2005 00:53:51 -0500 (EST)
To: "nick kinraid" <nick.kinraid@alliedtelesyn.co.nz>,
	sharee.mcnab@alliedtelesyn.co.nz
Subject: Re: [ippm] Comment on draft-ietf-ippm-owdp-14
References: <s3749c28.007@aslan.alliedtelesyn.co.nz>
From: stanislav shalunov <shalunov@internet2.edu>
Date: 11 Nov 2005 00:53:55 -0500
In-Reply-To: <s3749c28.007@aslan.alliedtelesyn.co.nz>
Message-ID: <86iruzpw5o.fsf@abel.internet2.edu>
Lines: 41
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: by mail.internet2.edu virus scanner
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
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 

"nick kinraid" <nick.kinraid@alliedtelesyn.co.nz> writes:

> In section 3.5, page 16, 2nd to last paragraph:
> "Otherwise, SID is a unique server-generated session identifier." ,
> referring to the case when conf-receiver was set.
> 
> However on page 17, top paragraph:
> "Note that SID is always chosen by the reciever."

Nick,

Thanks for writing this down.  Is this the same problem that Sharee
mentioned during the physical meeting or should I pursue her bug
report separately?  (I'm not in Vancouver.)

> Previous statments in the document refer to the receiving side
> generating the SID, so maybe the first sentence is incorrect and can
> be changed to read 'session-receiver generated...".

The key is the sentence preceding the first quote.  Here's the context:

#   If only Conf-Sender was set, the SID field in the response is unused.
#   Otherwise, SID is a unique server-generated session identifier.  It
#   can be used later as handle to fetch the results of a session.

I believe the text is correct.  It is also more clear than it would be
if it were changed---because the change would remove useful
information.  More importantly, the change would make the sentence
wrong (in a minor way): the SID is not generated by the receiver,
which might have no clue about OWAMP-Control or SIDs, but, indeed, by
a party participating in the OWAMP-Control exchange---the server in
this case.

SID is always generated by the side of OWAMP-Control responsible for
the receiver.  This formalizes the condition and tells the implementor
when this side is the server.

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

This message is designed to be viewed with 0.06479891g of NaCl.

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



From ippm-bounces@ietf.org Fri Nov 11 15:50:10 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eafqc-000178-8i; Fri, 11 Nov 2005 15:50:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EafqV-00014C-SJ; Fri, 11 Nov 2005 15:50:03 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04997;
	Fri, 11 Nov 2005 15:49:35 -0500 (EST)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Eag6z-0005oz-Be; Fri, 11 Nov 2005 16:07:06 -0500
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1EafqT-000803-Vu; Fri, 11 Nov 2005 15:50:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1EafqT-000803-Vu@newodin.ietf.org>
Date: Fri, 11 Nov 2005 15:50:01 -0500
X-Spam-Score: 0.4 (/)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Cc: ippm@ietf.org
Subject: [ippm] I-D ACTION:draft-ietf-ippm-bw-capacity-01.txt 
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 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Performance Metrics Working Group of the IETF.

	Title		: Defining Network Capacity
	Author(s)	: P. Chimento, J. Ishac
	Filename	: draft-ietf-ippm-bw-capacity-01.txt
	Pages		: 16
	Date		: 2005-11-11
	
Measuring capacity is a task that sounds simple, but in reality can
   be quite complex.  In addition, the lack of a unified nomenclature on
   this subject makes it increasingly difficult to properly build, test,
   and use techniques and tools built around these constructs.  This
   document provides definitions for the terms 'Capacity' and 'Available
   Capacity' related to IP traffic traveling between a source and
   destination in an IP network.  By doing so, we hope to build a common
   language that can be used when discussing and analyzing a diverse set
   of current and future estimation techniques.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ippm-bw-capacity-01.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ippm-bw-capacity-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ippm-bw-capacity-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2005-11-11125518.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ippm-bw-capacity-01.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-ippm-bw-capacity-01.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2005-11-11125518.I-D@ietf.org>


--OtherAccess--

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

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

--NextPart--





From ippm-bounces@ietf.org Fri Nov 11 15:50:51 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EafrH-0001PN-8C; Fri, 11 Nov 2005 15:50:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EafqY-00015E-DJ; Fri, 11 Nov 2005 15:50:06 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05026;
	Fri, 11 Nov 2005 15:49:37 -0500 (EST)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Eag6z-0005oy-53; Fri, 11 Nov 2005 16:07:06 -0500
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1EafqT-0007zz-Uy; Fri, 11 Nov 2005 15:50:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1EafqT-0007zz-Uy@newodin.ietf.org>
Date: Fri, 11 Nov 2005 15:50:01 -0500
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
Cc: ippm@ietf.org
Subject: [ippm] I-D ACTION:draft-ietf-ippm-twamp-00.txt 
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 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Performance Metrics Working Group of the IETF.

	Title		: A Two-way Active Measurement Protocol (TWAMP) 
	Author(s)	: J. Babiarz, et al.
	Filename	: draft-ietf-ippm-twamp-00.txt
	Pages		: 16
	Date		: 2005-11-11
	
    The IPPM One-way Active Measurement Protocol [OWAMP] provides a 
    common protocol for measuring one-way metrics between network 
    devices.  OWAMP [OWAMP] can be used in both directions 
    independently to measure one-way metrics in both directions between 
    two network elements.  However, it does not accommodate round-trip 
    or two-way measurements.  This draft proposes a Two-way Active 
    Measurement Protocol, based on the One-way Active Measurement 
    Protocol [OWAMP], that will accommodate two-way or round-trip 
    measurements.  

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ippm-twamp-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ippm-twamp-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ippm-twamp-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2005-11-11125241.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ippm-twamp-00.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-ippm-twamp-00.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2005-11-11125241.I-D@ietf.org>


--OtherAccess--

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

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

--NextPart--




From ippm-bounces@ietf.org Fri Nov 11 20:01:20 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eajlg-0008Dl-6U; Fri, 11 Nov 2005 20:01:20 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Eajlf-0008DZ-6z
	for ippm@megatron.ietf.org; Fri, 11 Nov 2005 20:01:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00274
	for <ippm@ietf.org>; Fri, 11 Nov 2005 20:00:48 -0500 (EST)
Received: from mx1.grc.nasa.gov ([128.156.11.68])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eak2A-00038v-Ks
	for ippm@ietf.org; Fri, 11 Nov 2005 20:18:23 -0500
Received: from lombok-fi.grc.nasa.gov (seraph1.grc.nasa.gov [128.156.10.10])
	by mx1.grc.nasa.gov (Postfix) with ESMTP id 93C3FC3A1
	for <ippm@ietf.org>; Fri, 11 Nov 2005 20:01:06 -0500 (EST)
Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35])
	by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id
	jAC116GT010299
	for <ippm@ietf.org>; Fri, 11 Nov 2005 20:01:06 -0500 (EST)
Received: from apataki.grc.nasa.gov (localhost [127.0.0.1])
	by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id
	jAC115Km022617
	for <ippm@ietf.org>; Fri, 11 Nov 2005 20:01:05 -0500 (EST)
Received: from firebird1.grc.nasa.gov (gr000630429.grc.nasa.gov 
	[139.88.111.69])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1)
	with ESMTP id jAC111D6022604for <ippm@ietf.org>;
	Fri, 11 Nov 2005 20:01:01 -0500 (EST)
Received: by firebird1.grc.nasa.gov (Postfix, from userid 501)id 35C1930322;
	Fri, 11 Nov 2005 20:01:01 -0500 (EST)
Date: Fri, 11 Nov 2005 20:01:01 -0500
From: Joseph Ishac <jishac@grc.nasa.gov>
To: ippm@ietf.org
Subject: Re: [ippm] I-D ACTION:draft-ietf-ippm-bw-capacity-01.txt
Message-ID: <20051112010101.GA531@firebird1.grc.nasa.gov>
Mail-Followup-To: ippm@ietf.org
References: <E1EafqT-000803-Vu@newodin.ietf.org>
Mime-Version: 1.0
Content-Type: text/plain;
	charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1EafqT-000803-Vu@newodin.ietf.org>
User-Agent: Mutt/1.4.2.1i
X-imss-version: 2.034
X-imss-result: Passed
X-imss-scores: Clean:55.68622 C:2 M:3 S:5 R:5
X-imss-settings: Baseline:1 C:1 M:1 S:2 R:2 (0.0000 0.0000)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: 
X-BeenThere: ippm@ietf.org 
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Joseph Ishac <jishac@grc.nasa.gov>
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 

A new version of the capacity draft is available.

 	Title		: Defining Network Capacity
 	Author(s)	: P. Chimento, J. Ishac
 	Filename	: draft-ietf-ippm-bw-capacity-01.txt
 	Pages		: 16
 	Date		: 2005-11-11
  http://www.ietf.org/internet-drafts/draft-ietf-ippm-bw-capacity-01.txt

With this revision we have hopefully addressed all of the comments and
outstanding issues that were raised.  So, please take a moment to read
the draft and comment.

For those who were familiar with the previous version(s) a changelog follows:

Major changes from draft-ietf-ippm-bw-capacity-00

* The paragraphs surrounding the definition of IP layer bits were
  cleaned up.
* Better explanation of the interval times
* Made the interval a little clearer in the definitions.
* Added a section to specify a correctly formed packet
* Section added for BTC

Thanks!

-Joseph

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



From ippm-bounces@ietf.org Wed Nov 16 08:18:20 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EcN4J-0006im-Fs; Wed, 16 Nov 2005 08:11:19 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EcN4H-0006ih-LM
	for ippm@megatron.ietf.org; Wed, 16 Nov 2005 08:11:17 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24086
	for <ippm@ietf.org>; Wed, 16 Nov 2005 08:10:43 -0500 (EST)
Received: from mailserv.intranet.gr ([146.124.14.106])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcNLh-0007Wr-5K
	for ippm@ietf.org; Wed, 16 Nov 2005 08:29:19 -0500
Received: from mailserv.intranet.gr (localhost [127.0.0.1])
	by mailserv.intranet.gr (8.13.1/8.13.1) with ESMTP id jAGDJF3Z019689
	for <ippm@ietf.org>; Wed, 16 Nov 2005 15:19:15 +0200 (EET)
Received: from iris.intranet.gr (iris.intranet.GR [146.124.80.178])
	by mailserv.intranet.gr (8.13.1/8.13.1) with ESMTP id jAGDJDQI019674
	for <ippm@ietf.org>; Wed, 16 Nov 2005 15:19:13 +0200 (EET)
Received: from [146.124.44.189] (HELO pcnt189)
	by iris.intranet.gr (CommuniGate Pro SMTP 4.3.8)
	with SMTP id 1880023 for ippm@ietf.org; Wed, 16 Nov 2005 15:21:42 +0200
Message-ID: <004b01c5eab7$eb485cb0$bd2c7c92@intranet.gr>
From: "Spiros Spirou" <spis@intracom.gr>
To: <ippm@ietf.org>
Date: Wed, 16 Nov 2005 15:13:29 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-7"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Content-Transfer-Encoding: 7bit
Cc: 
Subject: [ippm] Type-P-Reordered Dst param
X-BeenThere: ippm@ietf.org 
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Spiros Spirou <spiros.spirou@ieee.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>
Sender: ippm-bounces@ietf.org 
Errors-To: ippm-bounces@ietf.org 

Hi,

In section 3.2 of draft-ietf-ippm-reordering-10 the Dst parameters of the
Type-P-Reordered is defined as "the IP address of a host". I assume that
this is not the destination IP field of the packet's IP header because
multicast and broadcast IPs don't qualify as "host IPs". So, is it correct
to report the unicast IP address of the interface that the packet was
received on (think about multihomed receivers)? Which IP should be reported
in case of multiple unicast IPs on the receiving interface?

Thanks,

Spiros


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



From ippm-bounces@ietf.org Wed Nov 16 09:19:22 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EcO8A-0007B4-JL; Wed, 16 Nov 2005 09:19:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EcO89-0007Az-Kg
	for ippm@megatron.ietf.org; Wed, 16 Nov 2005 09:19:21 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29049
	for <ippm@ietf.org>; Wed, 16 Nov 2005 09:18:49 -0500 (EST)
Received: from postman.ripe.net ([193.0.0.199])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcOPa-0001Si-Ib
	for ippm@ietf.org; Wed, 16 Nov 2005 09:37:24 -0500
Received: by postman.ripe.net (Postfix, from userid 4008)
	id 6E89E2551A; Wed, 16 Nov 2005 15:19:11 +0100 (CET)
Received: from herring.ripe.net (herring.ripe.net [193.0.1.203])
	by postman.ripe.net (Postfix) with ESMTP id 95F742550B;
	Wed, 16 Nov 2005 15:19:10 +0100 (CET)
Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239])
	by herring.ripe.net (Postfix) with ESMTP id 53F532F583;
	Wed, 16 Nov 2005 15:19:10 +0100 (CET)
Message-Id: <6.2.3.4.2.20051116150915.02c404c0@localhost>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Wed, 16 Nov 2005 15:19:07 +0100
To: Spiros Spirou <spiros.spirou@ieee.org>, <ippm@ietf.org>
From: Henk Uijterwaal <henk@ripe.net>
Subject: Re: [ippm] Type-P-Reordered Dst param
In-Reply-To: <004b01c5eab7$eb485cb0$bd2c7c92@intranet.gr>
References: <004b01c5eab7$eb485cb0$bd2c7c92@intranet.gr>
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.000013 / -5.9
X-RIPE-Signature: d90fb1d6763993f66dfc308d335c4fbe
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: 
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 15:13 16/11/2005, Spiros Spirou wrote:
>Hi,
>
>In section 3.2 of draft-ietf-ippm-reordering-10 the Dst parameters of the
>Type-P-Reordered is defined as "the IP address of a host". I assume that
>this is not the destination IP field of the packet's IP header because
>multicast and broadcast IPs don't qualify as "host IPs". So, is it correct
>to report the unicast IP address of the interface that the packet was
>received on (think about multihomed receivers)? Which IP should be reported
>in case of multiple unicast IPs on the receiving interface?

This comes from the framework and (AFAIK) multiple interfaces or interfaces
with multiple addresses were not discussed when the framework was built.

However, Src and Dst are there to identify the host that sent or received
the packet(s) in the test.  If a host has multiple interfaces or multiple
addresses on an interface, I'd report the address that was actually used.
This uniquely defines the host and also allows one to select traffic
based on the path it took.   Packets sent from/to eth0 may be treated
differently than to eth1, packets sent from/to 192.168.0.0/24 may be
treated differently than packets sent from/to 192.168.1.0/24.

Henk


------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

Look here junior, don't you be so happy.
And for Heaven's sake, don't you be so sad.                 (Tom Verlaine) 


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



From ippm-bounces@ietf.org Wed Nov 16 14:32:12 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EcT0u-0000eO-DR; Wed, 16 Nov 2005 14:32:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EcT0s-0000bj-JU
	for ippm@megatron.ietf.org; Wed, 16 Nov 2005 14:32:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19088
	for <ippm@ietf.org>; Wed, 16 Nov 2005 14:31:35 -0500 (EST)
Received: from mail121.messagelabs.com ([216.82.241.195])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EcTIM-0005gN-8w
	for ippm@ietf.org; Wed, 16 Nov 2005 14:50:15 -0500
X-VirusChecked: Checked
X-Env-Sender: acmorton@att.com
X-Msg-Ref: server-3.tower-121.messagelabs.com!1132169517!7996530!1
X-StarScan-Version: 5.5.9.1; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 20395 invoked from network); 16 Nov 2005 19:31:57 -0000
Received: from unknown (HELO maillennium.att.com) (134.24.146.4)
	by server-3.tower-121.messagelabs.com with SMTP;
	16 Nov 2005 19:31:57 -0000
Received: from acmt.att.com (unknown[135.70.124.138](misconfigured sender))
	by maillennium.att.com (mailgw1) with SMTP
	id <20051116193156gw100lggd9e>; Wed, 16 Nov 2005 19:31:56 +0000
Message-Id: <6.2.1.2.0.20051116135531.03f019a0@postoffice.maillennium.att.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Wed, 16 Nov 2005 14:31:55 -0500
To: Henk Uijterwaal <henk@ripe.net>, Spiros Spirou <spiros.spirou@ieee.org>,
	<ippm@ietf.org>
From: Al Morton <acmorton@att.com>
Subject: Re: [ippm] Type-P-Reordered Dst param
In-Reply-To: <6.2.3.4.2.20051116150915.02c404c0@localhost>
References: <004b01c5eab7$eb485cb0$bd2c7c92@intranet.gr>
	<6.2.3.4.2.20051116150915.02c404c0@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: 
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 Spiros,
adding to Henk's reply, below:

At 09:19 AM 11/16/2005, Henk Uijterwaal wrote:
>At 15:13 16/11/2005, Spiros Spirou wrote:
>>Hi,
>>
>>In section 3.2 of draft-ietf-ippm-reordering-10 the Dst parameters of the
>>Type-P-Reordered is defined as "the IP address of a host". I assume that
>>this is not the destination IP field of the packet's IP header because
>>multicast and broadcast IPs don't qualify as "host IPs". So, is it correct
>>to report the unicast IP address of the interface that the packet was
>>received on (think about multihomed receivers)? Which IP should be reported
>>in case of multiple unicast IPs on the receiving interface?
>
>This comes from the framework and (AFAIK) multiple interfaces or interfaces
>with multiple addresses were not discussed when the framework was built.

The framework is Unicast-oriented (there are no instances of "multicast"
or "broadcast" in the text of RFC 2330), and Dst is consistently defined
as above in all current IPPM RFCs.  Unicast was the right place to
start, and IPPM's first foray into the world of one-to-many is the
multi-metrics draft: draft-stephan-ippm-multimetrics-01.txt

In the Reordering draft, section 2.3
"Required Context for All Reordering Metrics" gives the opportunity
to report any and all relevant information under the
"Packet of Type-P" category (including transport addresses).

Al



>However, Src and Dst are there to identify the host that sent or received
>the packet(s) in the test.  If a host has multiple interfaces or multiple
>addresses on an interface, I'd report the address that was actually used.
>This uniquely defines the host and also allows one to select traffic
>based on the path it took.   Packets sent from/to eth0 may be treated
>differently than to eth1, packets sent from/to 192.168.0.0/24 may be
>treated differently than packets sent from/to 192.168.1.0/24.
>
>Henk


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



From ippm-bounces@ietf.org Thu Nov 17 15:33:56 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EcqSC-0005B1-QD; Thu, 17 Nov 2005 15:33:56 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EcqIe-0002wu-7p
	for ippm@megatron.ietf.org; Thu, 17 Nov 2005 15:24:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18000
	for <ippm@ietf.org>; Thu, 17 Nov 2005 15:23:28 -0500 (EST)
Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcqZE-0007Tn-GM
	for ippm@ietf.org; Thu, 17 Nov 2005 15:41:19 -0500
Received: from mail121.messagelabs.com ([216.82.241.195])
	by mx2.foretec.com with smtp (Exim 4.24) id 1Ecpy9-0006oQ-Mm
	for ippm@ietf.org; Thu, 17 Nov 2005 15:02:53 -0500
X-VirusChecked: Checked
X-Env-Sender: acmorton@att.com
X-Msg-Ref: server-5.tower-121.messagelabs.com!1132247509!7423437!1
X-StarScan-Version: 5.5.9.1; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 20034 invoked from network); 17 Nov 2005 17:11:49 -0000
Received: from unknown (HELO maillennium.att.com) (134.24.146.4)
	by server-5.tower-121.messagelabs.com with SMTP;
	17 Nov 2005 17:11:49 -0000
Received: from acmt.att.com (acmt.mt.att.com[135.16.251.35](misconfigured
	sender)) by maillennium.att.com (mailgw1) with SMTP
	id <20051117171149gw100lggl6e>; Thu, 17 Nov 2005 17:11:49 +0000
Message-Id: <6.2.1.2.0.20051117121105.021c6c38@postoffice.maillennium.att.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Thu, 17 Nov 2005 12:11:49 -0500
To: Spiros Spirou <spiros.spirou@ieee.org>
From: Al Morton <acmorton@att.com>
Subject: Re: [ippm] RTP timestamp as SrcTime in draft-ietf-ippm-reordering-10
In-Reply-To: <000601c5e44c$e3179c70$bd2c7c92@intranet.gr>
References: <01f301c5e06b$541ee300$bd2c7c92@intranet.gr>
	<6.2.1.2.0.20051103114221.03e51410@postoffice.maillennium.att.com>
	<000601c5e44c$e3179c70$bd2c7c92@intranet.gr>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Cc: ippm@ietf.org
X-BeenThere: ippm@ietf.org 
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <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 

Sorry - mail tool problem, here's the complete reply:

Hi Spiros,

I don't think that you are misusing the draft,
you are simply applying the definitions under circumstances
that are somewhat different from the usual IPPM active
measurement set-up, with instruments present only at the
receivers.  Perhaps you can make measurements
more ubiquitously as a single-point measure, and the
information you derive may out-weigh the errors between
the true wire time and the RTP time stamp, as long as you
are clear about *what* was measured (both network and source
effects on transmission time).

 From RFC 2330, section 10.2:
    When appropriate, metrics should be defined in terms of wire times
    rather than host endpoint times, so that the metric's definition
    highlights the issue of separating delays due to the host from those
    due to the network.

You might attack the problem of characterizing source error by making
measurements as "close to the source" as possible.

It's usually better to light a candle than to curse the darkness.

Al



At 05:12 AM 11/8/2005, Spiros Spirou wrote:
>Hi Al,
>
>Thanks for the reply.
>
>I may be trying to misuse the draft: What I have in mind is a self-contained
>measuring device (receiver) that reports the Type-P-Reordered metric and
>associated parameters (including SrcTime for completeness).
>
>However, it seems that the requirement to report SrcTime as wire time
>prohibits a self-contained Type-P-Reordered measurement, because it
>necessitates a simultaneous measurement of the transmission wire time at the
>source. Following from your correct observations, this complication may also
>hold when earlier times (such as the RTP timestamp) are used in reporting
>the SrcTime, because one still needs to detect, estimate, and remove the
>"source jitter" component, and I don't see how these can be done at the
>receiver without measurements at the server as well.
>
>So, am I going up a dead-end? Is there a way to report the SrcTime as (the
>elusive) wire time without access to the server?
>
>Regards,
>
>Spiros


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



From ippm-bounces@ietf.org Thu Nov 17 16:20:07 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ecr1L-0005if-NG; Thu, 17 Nov 2005 16:10:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecr1J-0005iK-VR
	for ippm@megatron.ietf.org; Thu, 17 Nov 2005 16:10:14 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24119
	for <ippm@ietf.org>; Thu, 17 Nov 2005 16:09:40 -0500 (EST)
Received: from mail121.messagelabs.com ([216.82.241.195])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EcrIy-0001yO-Hu
	for ippm@ietf.org; Thu, 17 Nov 2005 16:28:32 -0500
X-VirusChecked: Checked
X-Env-Sender: acmorton@att.com
X-Msg-Ref: server-9.tower-121.messagelabs.com!1132247390!7930431!1
X-StarScan-Version: 5.5.9.1; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 15211 invoked from network); 17 Nov 2005 17:09:50 -0000
Received: from unknown (HELO maillennium.att.com) (134.24.146.4)
	by server-9.tower-121.messagelabs.com with SMTP;
	17 Nov 2005 17:09:50 -0000
Received: from acmt.att.com (acmt.mt.att.com[135.16.251.35](misconfigured
	sender)) by maillennium.att.com (mailgw1) with SMTP
	id <20051117170950gw100lggl4e>; Thu, 17 Nov 2005 17:09:50 +0000
Message-Id: <6.2.1.2.0.20051117115220.05719e58@postoffice.maillennium.att.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Thu, 17 Nov 2005 12:02:59 -0500
To: Spiros Spirou <spiros.spirou@ieee.org>
From: Al Morton <acmorton@att.com>
Subject: Re: [ippm] RTP timestamp as SrcTime in draft-ietf-ippm-reordering-10
In-Reply-To: <000601c5e44c$e3179c70$bd2c7c92@intranet.gr>
References: <01f301c5e06b$541ee300$bd2c7c92@intranet.gr>
	<6.2.1.2.0.20051103114221.03e51410@postoffice.maillennium.att.com>
	<000601c5e44c$e3179c70$bd2c7c92@intranet.gr>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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
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 Spiros,

I don't think that you are miss-using the draft,
you are simply applying the definitions under circumstances
that are somewhat different from the usual IPPM active
measurement set-up, with instruments only present at the
receivers.  Perhaps you can make measurements
more ubiquitously as a single-point measure, and the
information you derive may out-weigh the errors between
the true wire time and the RTP time stamp, as long as you
are clear about *what* was measured (both network and source
effects on transmission time).

 From RFC 2330, section 10.2:
    When appropriate, metrics should be defined in terms of wire times
    rather than host endpoint times, so that the metric's definition
    highlights the issue of separating delays due to the host from those
    due to the network.



At 05:12 AM 11/8/2005, Spiros Spirou wrote:
>Hi Al,
>
>Thanks for the reply.
>
>I may be trying to misuse the draft: What I have in mind is a self-contained
>measuring device (receiver) that reports the Type-P-Reordered metric and
>associated parameters (including SrcTime for completeness).
>
>However, it seems that the requirement to report SrcTime as wire time
>prohibits a self-contained Type-P-Reordered measurement, because it
>necessitates a simultaneous measurement of the transmission wire time at the
>source. Following from your correct observations, this complication may also
>hold when earlier times (such as the RTP timestamp) are used in reporting
>the SrcTime, because one still needs to detect, estimate, and remove the
>"source jitter" component, and I don't see how these can be done at the
>receiver without measurements at the server as well.
>
>So, am I going up a dead-end? Is there a way to report the SrcTime as (the
>elusive) wire time without access to the server?
>
>Regards,
>
>Spiros


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



From ippm-bounces@ietf.org Fri Nov 18 03:00:51 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ed1Ax-0007sh-Hv; Fri, 18 Nov 2005 03:00:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed1Aw-0007sM-5C
	for ippm@megatron.ietf.org; Fri, 18 Nov 2005 03:00:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29192
	for <ippm@ietf.org>; Fri, 18 Nov 2005 03:00:14 -0500 (EST)
Received: from mailserv.intranet.gr ([146.124.14.106])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed1Sj-0005ac-Cb
	for ippm@ietf.org; Fri, 18 Nov 2005 03:19:14 -0500
Received: from mailserv.intranet.gr (localhost [127.0.0.1])
	by mailserv.intranet.gr (8.13.1/8.13.1) with ESMTP id jAI88r84016544
	for <ippm@ietf.org>; Fri, 18 Nov 2005 10:08:53 +0200 (EET)
Received: from iris.intranet.gr (iris.intranet.GR [146.124.80.178])
	by mailserv.intranet.gr (8.13.1/8.13.1) with ESMTP id jAI88qYn016536;
	Fri, 18 Nov 2005 10:08:52 +0200 (EET)
Received: from [146.124.44.189] (HELO pcnt189)
	by iris.intranet.gr (CommuniGate Pro SMTP 4.3.8)
	with SMTP id 1894450; Fri, 18 Nov 2005 10:11:20 +0200
Message-ID: <00db01c5ec1e$e10851c0$bd2c7c92@intranet.gr>
From: "Spiros Spirou" <spis@intracom.gr>
To: <ippm@ietf.org>, "Henk Uijterwaal" <henk@ripe.net>
References: <004b01c5eab7$eb485cb0$bd2c7c92@intranet.gr>
	<6.2.3.4.2.20051116150915.02c404c0@localhost>
Subject: Re: [ippm] Type-P-Reordered Dst param
Date: Fri, 18 Nov 2005 10:03:01 +0100
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.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Content-Transfer-Encoding: 7bit
Cc: 
X-BeenThere: ippm@ietf.org 
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Spiros Spirou <spiros.spirou@ieee.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>
Sender: ippm-bounces@ietf.org 
Errors-To: ippm-bounces@ietf.org 

Hi Henk,

Thanks for the answer. Please see comments below.

> However, Src and Dst are there to identify the host that sent or received
> the packet(s) in the test.  If a host has multiple interfaces or multiple
> addresses on an interface, I'd report the address that was actually used.

This works when the address that was actually used is unicast. If you
consider reception of multicast (or broadcast) flows on an interface
configured with multiple (unicast) IPs then it's not clear which one you
should report.

> This uniquely defines the host and also allows one to select traffic
> based on the path it took.   Packets sent from/to eth0 may be treated
> differently than to eth1, packets sent from/to 192.168.0.0/24 may be
> treated differently than packets sent from/to 192.168.1.0/24.
>
> Henk
>

Spiros


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



From ippm-bounces@ietf.org Fri Nov 18 05:00:12 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ed32S-0007Me-K8; Fri, 18 Nov 2005 05:00:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed32P-0007MZ-Sp
	for ippm@megatron.ietf.org; Fri, 18 Nov 2005 05:00:11 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05496
	for <ippm@ietf.org>; Fri, 18 Nov 2005 04:59:35 -0500 (EST)
Received: from postman.ripe.net ([193.0.0.199])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed3KB-0001Bm-M3
	for ippm@ietf.org; Fri, 18 Nov 2005 05:18:34 -0500
Received: by postman.ripe.net (Postfix, from userid 4008)
	id 818C82464C; Fri, 18 Nov 2005 10:59:52 +0100 (CET)
Received: from herring.ripe.net (herring.ripe.net [193.0.1.203])
	by postman.ripe.net (Postfix) with ESMTP id AD40924436;
	Fri, 18 Nov 2005 10:59:50 +0100 (CET)
Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239])
	by herring.ripe.net (Postfix) with ESMTP id 19F112F583;
	Fri, 18 Nov 2005 10:59:50 +0100 (CET)
Message-Id: <6.2.3.4.2.20051118105754.02d96120@localhost>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Fri, 18 Nov 2005 10:59:47 +0100
To: "Spiros Spirou" <spiros.spirou@ieee.org>, <ippm@ietf.org>
From: Henk Uijterwaal <henk@ripe.net>
Subject: Re: [ippm] Type-P-Reordered Dst param
In-Reply-To: <00db01c5ec1e$e10851c0$bd2c7c92@intranet.gr>
References: <004b01c5eab7$eb485cb0$bd2c7c92@intranet.gr>
	<6.2.3.4.2.20051116150915.02c404c0@localhost>
	<00db01c5ec1e$e10851c0$bd2c7c92@intranet.gr>
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: 40267a24d569b4b9b66b404bab793a14
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Cc: 
X-BeenThere: ippm@ietf.org 
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <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 10:03 18/11/2005, Spiros Spirou wrote:
>Hi Henk,
>
>Thanks for the answer. Please see comments below.
>
> > However, Src and Dst are there to identify the host that sent or received
> > the packet(s) in the test.  If a host has multiple interfaces or multiple
> > addresses on an interface, I'd report the address that was actually used.
>
>This works when the address that was actually used is unicast. If you
>consider reception of multicast (or broadcast) flows on an interface
>configured with multiple (unicast) IPs then it's not clear which one you
>should report.

I don't think the standard says which one you should report.  However, if
there are 2 addresses on an interface, then I'd report the address that
the packet was sent to.  (I.e. eth0 has address 1 and 2, a packet is sent
to 2, report 2).

Henk





> > This uniquely defines the host and also allows one to select traffic
> > based on the path it took.   Packets sent from/to eth0 may be treated
> > differently than to eth1, packets sent from/to 192.168.0.0/24 may be
> > treated differently than packets sent from/to 192.168.1.0/24.
> >
> > Henk
> >
>
>Spiros

------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

Look here junior, don't you be so happy.
And for Heaven's sake, don't you be so sad.                 (Tom Verlaine) 


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



From ippm-bounces@ietf.org Fri Nov 18 05:42:40 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ed3hY-00062e-Gw; Fri, 18 Nov 2005 05:42:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed3hW-00062W-Km
	for ippm@megatron.ietf.org; Fri, 18 Nov 2005 05:42:38 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08124
	for <ippm@ietf.org>; Fri, 18 Nov 2005 05:42:04 -0500 (EST)
Received: from smtp11.clb.oleane.net ([213.56.31.48])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed3zK-0002ej-AK
	for ippm@ietf.org; Fri, 18 Nov 2005 06:01:04 -0500
Received: from Pavillonquatre ([194.3.133.88]) (authenticated)
	by smtp11.clb.oleane.net with ESMTP id jAIAgMbT024963
	for <ippm@ietf.org>; Fri, 18 Nov 2005 11:42:22 +0100
Message-Id: <200511181042.jAIAgMbT024963@smtp11.clb.oleane.net>
From: "Chantal Ladouce" <chantal.ladouce@upperside.fr>
To: <ippm@ietf.org>
Date: Fri, 18 Nov 2005 11:41:58 +0100
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcXsLLMa+R0yGRZjQd+C2w66UTHD+A==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c
Cc: 
Subject: [ippm] IMS at the International SIP 2006 - Paris - France
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="===============0275539535=="
Sender: ippm-bounces@ietf.org 
Errors-To: ippm-bounces@ietf.org 

This is a multi-part message in MIME format.

--===============0275539535==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_006B_01C5EC35.158A8AB0"

This is a multi-part message in MIME format.

------=_NextPart_000_006B_01C5EC35.158A8AB0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Carriers Experience on SIP based IMS Real Size Experiments

. Extending SIP IMS Architecture from Wireless to Wireline Networks

. Challenges in IMS Testing

 

Everything you need to know on IMS and SIP will be delivered at the
International SIP conference to be held in Paris next 21-24 February 2006.

 

Get all details at:

 

http://www.upperside.fr/sip2006/sip2006program.htm#day2

 

 


------=_NextPart_000_006B_01C5EC35.158A8AB0
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City" =
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place" downloadurl=3D"http://www.5iantlavalamp.com/"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Batang;
	panose-1:2 3 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:"\@Batang";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DFR link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span class=3Dtitrerangdeux><font size=3D1 =
face=3DArial><span
lang=3DEN-GB style=3D'font-size:9.0pt;font-family:Arial'>Carriers =
Experience on SIP
based </span></font></span><strong><b><font size=3D1 face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:9.0pt;font-family:Arial'>IMS Real Size =
Experiments</span></font></b></strong><font
size=3D1 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:9.0pt;font-family:Arial'><o:p></o:p></span></font></p>=


<p class=3DMsoNormal><span class=3Dtitrerangdeux><font size=3D1 =
face=3DArial><span
lang=3DEN-GB style=3D'font-size:9.0pt;font-family:Arial'>. Extending =
</span></font></span><strong><b><font
size=3D1 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:9.0pt;font-family:Arial'>SIP
IMS Architecture</span></font></b></strong><span =
class=3Dtitrerangdeux><font
size=3D1 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:9.0pt;font-family:Arial'>
from Wireless to Wireline Networks</span></font></span><font size=3D1 =
face=3DArial><span
lang=3DEN-GB =
style=3D'font-size:9.0pt;font-family:Arial'><o:p></o:p></span></font></p>=


<p class=3DMsoNormal><span class=3Dtitrerangdeux><font size=3D1 =
face=3DArial><span
lang=3DEN-GB style=3D'font-size:9.0pt;font-family:Arial'>. Challenges in =
</span></font></span><strong><b><font
size=3D1 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:9.0pt;font-family:Arial'>IMS
Testing</span></font></b></strong><font size=3D1 face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:9.0pt;font-family:Arial'><o:p></o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D1 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
9.0pt;font-family:Arial'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><span class=3Dtitrerangdeux><font size=3D1 =
face=3DArial><span
lang=3DEN-GB style=3D'font-size:9.0pt;font-family:Arial'>Everything you =
need to
know on IMS and SIP will be delivered at the International SIP =
conference to be
held in <st1:place w:st=3D"on"><st1:City =
w:st=3D"on">Paris</st1:City></st1:place>
next 21-24 February 2006.</span></font></span><font size=3D1 =
face=3DArial><span
lang=3DEN-GB =
style=3D'font-size:9.0pt;font-family:Arial'><o:p></o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D1 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
9.0pt;font-family:Arial'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><span class=3Dtitrerangdeux><font size=3D1 =
face=3DArial><span
lang=3DEN-GB style=3D'font-size:9.0pt;font-family:Arial'>Get all details =
at:</span></font></span><font
size=3D1 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:9.0pt;font-family:Arial'><o:p></o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D1 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
9.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D1 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
9.0pt;font-family:Arial'><a
href=3D"http://www.upperside.fr/sip2006/sip2006program.htm#day2">http://w=
ww.upperside.fr/sip2006/sip2006program.htm#day2</a><o:p></o:p></span></fo=
nt></p>

<p class=3DMsoNormal><font size=3D1 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
9.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_006B_01C5EC35.158A8AB0--



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

--===============0275539535==--





From ippm-bounces@ietf.org Fri Nov 18 05:52:30 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ed3r4-0007hz-9P; Fri, 18 Nov 2005 05:52:30 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed3r2-0007hr-Sk
	for ippm@megatron.ietf.org; Fri, 18 Nov 2005 05:52:28 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08691
	for <ippm@ietf.org>; Fri, 18 Nov 2005 05:51:54 -0500 (EST)
Received: from mailserv.intranet.gr ([146.124.14.106])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed48p-0002zv-MH
	for ippm@ietf.org; Fri, 18 Nov 2005 06:10:54 -0500
Received: from mailserv.intranet.gr (localhost [127.0.0.1])
	by mailserv.intranet.gr (8.13.1/8.13.1) with ESMTP id jAIB0WjU009920
	for <ippm@ietf.org>; Fri, 18 Nov 2005 13:00:32 +0200 (EET)
Received: from iris.intranet.gr (iris.intranet.GR [146.124.80.178])
	by mailserv.intranet.gr (8.13.1/8.13.1) with ESMTP id jAIB0W3r009914;
	Fri, 18 Nov 2005 13:00:32 +0200 (EET)
Received: from [146.124.44.189] (HELO pcnt189)
	by iris.intranet.gr (CommuniGate Pro SMTP 4.3.8)
	with SMTP id 1896647; Fri, 18 Nov 2005 13:03:00 +0200
Message-ID: <010c01c5ec36$dbd6e550$bd2c7c92@intranet.gr>
From: "Spiros Spirou" <spis@intracom.gr>
To: "Henk Uijterwaal" <henk@ripe.net>
References: <004b01c5eab7$eb485cb0$bd2c7c92@intranet.gr>
	<6.2.3.4.2.20051116150915.02c404c0@localhost>
	<00db01c5ec1e$e10851c0$bd2c7c92@intranet.gr>
	<6.2.3.4.2.20051118105754.02d96120@localhost>
Subject: Re: [ippm] Type-P-Reordered Dst param
Date: Fri, 18 Nov 2005 12:54:41 +0100
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.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Content-Transfer-Encoding: 7bit
Cc: ippm@ietf.org
X-BeenThere: ippm@ietf.org 
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Spiros Spirou <spiros.spirou@ieee.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>
Sender: ippm-bounces@ietf.org 
Errors-To: ippm-bounces@ietf.org 

Hi Henk,

> I don't think the standard says which one you should report.  However, if
> there are 2 addresses on an interface, then I'd report the address that
> the packet was sent to.  (I.e. eth0 has address 1 and 2, a packet is sent
> to 2, report 2).
>

When the packets have been sent to a multicast group (i.e. the Destination
IP field of the IP header is a valid Class D address), I think that one
cannot do what you're suggesting, because the standard requires reporting a
"host IP" and multicast IPs do not qualify as such.

Spiros


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



From ippm-bounces@ietf.org Fri Nov 18 06:47:37 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ed4iP-00008m-ME; Fri, 18 Nov 2005 06:47:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed4iN-00008W-TU
	for ippm@megatron.ietf.org; Fri, 18 Nov 2005 06:47:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11537
	for <ippm@ietf.org>; Fri, 18 Nov 2005 06:47:01 -0500 (EST)
Received: from mailserv.intranet.gr ([146.124.14.106])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed509-0004iD-Uo
	for ippm@ietf.org; Fri, 18 Nov 2005 07:06:02 -0500
Received: from mailserv.intranet.gr (localhost [127.0.0.1])
	by mailserv.intranet.gr (8.13.1/8.13.1) with ESMTP id jAIBtckb005115
	for <ippm@ietf.org>; Fri, 18 Nov 2005 13:55:39 +0200 (EET)
Received: from iris.intranet.gr (iris.intranet.GR [146.124.80.178])
	by mailserv.intranet.gr (8.13.1/8.13.1) with ESMTP id jAIBtahd005092;
	Fri, 18 Nov 2005 13:55:36 +0200 (EET)
Received: from [146.124.44.189] (HELO pcnt189)
	by iris.intranet.gr (CommuniGate Pro SMTP 4.3.8)
	with SMTP id 1897318; Fri, 18 Nov 2005 13:58:04 +0200
Message-ID: <010d01c5ec3e$8d168d00$bd2c7c92@intranet.gr>
From: "Spiros Spirou" <spis@intracom.gr>
To: <ippm@ietf.org>, "Al Morton" <acmorton@att.com>
References: <004b01c5eab7$eb485cb0$bd2c7c92@intranet.gr>
	<6.2.3.4.2.20051116150915.02c404c0@localhost>
	<6.2.1.2.0.20051116135531.03f019a0@postoffice.maillennium.att.com>
Subject: Re: [ippm] Type-P-Reordered Dst param
Date: Fri, 18 Nov 2005 13:49:44 +0100
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.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Content-Transfer-Encoding: 7bit
Cc: Henk Uijterwaal <henk@ripe.net>
X-BeenThere: ippm@ietf.org 
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Spiros Spirou <spiros.spirou@ieee.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>
Sender: ippm-bounces@ietf.org 
Errors-To: ippm-bounces@ietf.org 

Hi Al,

> The framework is Unicast-oriented (there are no instances of "multicast"
> or "broadcast" in the text of RFC 2330), and Dst is consistently defined
> as above in all current IPPM RFCs.  Unicast was the right place to
> start, and IPPM's first foray into the world of one-to-many is the
> multi-metrics draft: draft-stephan-ippm-multimetrics-01.txt

For one-to-group metrics the multimetrics draft uses a list (Recv1,...,
RecvN) of "the IP addresses of the N hosts acting as receivers" instead of
the Dst parameter. Still, in the case that receiver j is multihomed should
Recvj be the unicast IP of the interface that received the packet(s)?.
Furthermore, as I already commented to Henk's reply, for an interface
configured with multiple IP that receives the multicast (or broadcast) flow
what should Recvj be?

> In the Reordering draft, section 2.3
> "Required Context for All Reordering Metrics" gives the opportunity
> to report any and all relevant information under the
> "Packet of Type-P" category (including transport addresses).

I would prefer not to abuse the elasticity provided by section 2.3 because
it might undermine the draft's intention, which, in my mind at least, is to
define a common "language" for reporting reordering. IMHO, multicast traffic
is not that uncommon to be handled by the "extension mechanism" of the
draft.

Spiros


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



From ippm-bounces@ietf.org Fri Nov 18 07:29:01 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ed5MS-0007P1-Vk; Fri, 18 Nov 2005 07:29:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed5MR-0007Op-OP
	for ippm@megatron.ietf.org; Fri, 18 Nov 2005 07:28:59 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13961
	for <ippm@ietf.org>; Fri, 18 Nov 2005 07:28:24 -0500 (EST)
Received: from mailserv.intranet.gr ([146.124.14.106])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed5eG-00069Y-PN
	for ippm@ietf.org; Fri, 18 Nov 2005 07:47:26 -0500
Received: from mailserv.intranet.gr (localhost [127.0.0.1])
	by mailserv.intranet.gr (8.13.1/8.13.1) with ESMTP id jAICb4Rv028758
	for <ippm@ietf.org>; Fri, 18 Nov 2005 14:37:04 +0200 (EET)
Received: from iris.intranet.gr (iris.intranet.GR [146.124.80.178])
	by mailserv.intranet.gr (8.13.1/8.13.1) with ESMTP id jAICb17S028745;
	Fri, 18 Nov 2005 14:37:02 +0200 (EET)
Received: from [146.124.44.189] (HELO pcnt189)
	by iris.intranet.gr (CommuniGate Pro SMTP 4.3.8)
	with SMTP id 1897880; Fri, 18 Nov 2005 14:39:29 +0200
Message-ID: <011801c5ec44$564a0530$bd2c7c92@intranet.gr>
From: "Spiros Spirou" <spis@intracom.gr>
To: "Al Morton" <acmorton@att.com>
References: <01f301c5e06b$541ee300$bd2c7c92@intranet.gr>
	<6.2.1.2.0.20051103114221.03e51410@postoffice.maillennium.att.com>
	<000601c5e44c$e3179c70$bd2c7c92@intranet.gr>
	<6.2.1.2.0.20051117121105.021c6c38@postoffice.maillennium.att.com>
Subject: Re: [ippm] RTP timestamp as SrcTime in draft-ietf-ippm-reordering-10
Date: Fri, 18 Nov 2005 14:31:09 +0100
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.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Content-Transfer-Encoding: 7bit
Cc: ippm@ietf.org
X-BeenThere: ippm@ietf.org 
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Spiros Spirou <spiros.spirou@ieee.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>
Sender: ippm-bounces@ietf.org 
Errors-To: ippm-bounces@ietf.org 

Hi Al,

Thanks for making the time to reply. Please see my comments below.

> Sorry - mail tool problem, here's the complete reply:
>
> Hi Spiros,
>
> I don't think that you are misusing the draft,
> you are simply applying the definitions under circumstances
> that are somewhat different from the usual IPPM active
> measurement set-up, with instruments present only at the
> receivers.  Perhaps you can make measurements
> more ubiquitously as a single-point measure, and the
> information you derive may out-weigh the errors between
> the true wire time and the RTP time stamp, as long as you
> are clear about *what* was measured (both network and source
> effects on transmission time).

However, I suspect that then I will not be able to claim adherence to the
soon-to-be-RFC draft, because without the "out-of-band" clarification that
you suggest, SrcTime would be falsely interpreted as wire time by a third
party. I am not sure whether the problem lies at the inherited requirement
to use the "ideal" wire time to report SrcTime, the lack of a defined
mechanism to further clarify the reporting of SrcTime for more practical
cases, or just my intention to use the draft in "circumstances that are
somewhat different from the usual IPPM active measurement set-up" as you
have correctly observed.

>
>  From RFC 2330, section 10.2:
>     When appropriate, metrics should be defined in terms of wire times
>     rather than host endpoint times, so that the metric's definition
>     highlights the issue of separating delays due to the host from those
>     due to the network.
>
> You might attack the problem of characterizing source error by making
> measurements as "close to the source" as possible.

This might not be always easy when one tries to measure deployed systems.
Furthermore, it might also be impossible when reordering measurements are
done internally to a receiver with the intent of dynamicaly modifiying its
real-time behaviour to achive better Quality of Experience.

>
> It's usually better to light a candle than to curse the darkness.
>
> Al
>

Spiros


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



From ippm-bounces@ietf.org Fri Nov 18 07:49:59 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ed5gl-00079y-2d; Fri, 18 Nov 2005 07:49:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed5gh-00079f-M0
	for ippm@megatron.ietf.org; Fri, 18 Nov 2005 07:49:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15041
	for <ippm@ietf.org>; Fri, 18 Nov 2005 07:49:20 -0500 (EST)
Received: from mailg.surrey.ac.uk ([131.227.102.21])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ed5yW-0006y3-Oe
	for ippm@ietf.org; Fri, 18 Nov 2005 08:08:22 -0500
Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP)
	with ESMTP; Fri, 18 Nov 2005 12:45:28 +0000
Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136])
	by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.1830);
	Fri, 18 Nov 2005 12:45:26 +0000
Received: from 131.227.89.115 ([131.227.89.115])
	by EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.152])
	with Microsoft Exchange Server HTTP-DAV ;
	Fri, 18 Nov 2005 12:45:26    UT
Received: from ccsrlt115.ee.surrey.ac.uk by exchange.surrey.ac.uk;
	18 Nov 2005 12:45:26 +0000
Subject: Re: [ippm] Type-P-Reordered Dst param
From: Lei Liang <L.Liang@surrey.ac.uk>
To: Spiros Spirou <spiros.spirou@ieee.org>
In-Reply-To: <010d01c5ec3e$8d168d00$bd2c7c92@intranet.gr>
References: <004b01c5eab7$eb485cb0$bd2c7c92@intranet.gr>
	<6.2.3.4.2.20051116150915.02c404c0@localhost>
	<6.2.1.2.0.20051116135531.03f019a0@postoffice.maillennium.att.com>
	<010d01c5ec3e$8d168d00$bd2c7c92@intranet.gr>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Fri, 18 Nov 2005 12:45:26 +0000
Message-Id: <1132317926.15191.41.camel@ccsrlt115.ee.surrey.ac.uk>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-7)
X-OriginalArrivalTime: 18 Nov 2005 12:45:26.0906 (UTC)
	FILETIME=[F34DF5A0:01C5EC3D]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Content-Transfer-Encoding: 7bit
Cc: Henk Uijterwaal <henk@ripe.net>, Al Morton <acmorton@att.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, falks,
  It does make sense now. Actually, in all previous IPPM RFCs, they have
the similar descriptions regarding "host IP". this is because there were
no so much efforts on the multicast/broadcast or one-to-many
communications when they were written. This also includes the framework
RFC. The solution is actually simple as we put in the multimetrics draft
by specifying both multicast group address and the address of the
measurement point. In that case, please see the comments in line.


On Fri, 2005-11-18 at 13:49 +0100, Spiros Spirou wrote:
> Hi Al,
> 
> > The framework is Unicast-oriented (there are no instances of "multicast"
> > or "broadcast" in the text of RFC 2330), and Dst is consistently defined
> > as above in all current IPPM RFCs.  Unicast was the right place to
> > start, and IPPM's first foray into the world of one-to-many is the
> > multi-metrics draft: draft-stephan-ippm-multimetrics-01.txt
> 
> For one-to-group metrics the multimetrics draft uses a list (Recv1,...,
> RecvN) of "the IP addresses of the N hosts acting as receivers" instead of
> the Dst parameter. Still, in the case that receiver j is multihomed should
> Recvj be the unicast IP of the interface that received the packet(s)?.
yes. The "HOST IP" is trying to identify the measurement point itself
physically in the metric and distinct metrics collected on each
measurement point. In the multimetrics draft, these measurement points
are called points of interest.


> Furthermore, as I already commented to Henk's reply, for an interface
> configured with multiple IP that receives the multicast (or broadcast) flow
> what should Recvj be?
Personally, I think the IP address Recvj should report in the metrics
could be anyone of its IPs as long as all metrics use the same IP. As
said above, this is only to identify Recvj from other receivers.


> 
> > In the Reordering draft, section 2.3
> > "Required Context for All Reordering Metrics" gives the opportunity
> > to report any and all relevant information under the
> > "Packet of Type-P" category (including transport addresses).
> 
> I would prefer not to abuse the elasticity provided by section 2.3 because
> it might undermine the draft's intention, which, in my mind at least, is to
> define a common "language" for reporting reordering. IMHO, multicast traffic
> is not that uncommon to be handled by the "extension mechanism" of the
> draft.
> 
I don't know that the metrics of reordering should actually report
whether unicast of multicast coz the operation will not be affected by
any transport mechanism. But I'd leave this question to Al. 

> Spiros
> 
> 
> _______________________________________________
> 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 Nov 18 08:20:42 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ed6AU-0005EK-M3; Fri, 18 Nov 2005 08:20:42 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed6AT-0005EF-JC
	for ippm@megatron.ietf.org; Fri, 18 Nov 2005 08:20:41 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17463
	for <ippm@ietf.org>; Fri, 18 Nov 2005 08:20:06 -0500 (EST)
Received: from mailg.surrey.ac.uk ([131.227.102.21])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ed6SJ-0008Ay-1m
	for ippm@ietf.org; Fri, 18 Nov 2005 08:39:08 -0500
Received: from ads33.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP)
	with ESMTP; Fri, 18 Nov 2005 13:20:15 +0000
Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136])
	by ads33.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.1830);
	Fri, 18 Nov 2005 13:20:14 +0000
Received: from 131.227.89.115 ([131.227.89.115])
	by EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.152])
	with Microsoft Exchange Server HTTP-DAV ;
	Fri, 18 Nov 2005 13:20:13    UT
Received: from ccsrlt115.ee.surrey.ac.uk by exchange.surrey.ac.uk;
	18 Nov 2005 13:20:14 +0000
From: Lei Liang <L.Liang@surrey.ac.uk>
To: ippm@ietf.org
In-Reply-To: <010d01c5ec3e$8d168d00$bd2c7c92@intranet.gr>
References: <004b01c5eab7$eb485cb0$bd2c7c92@intranet.gr>
	<6.2.3.4.2.20051116150915.02c404c0@localhost>
	<6.2.1.2.0.20051116135531.03f019a0@postoffice.maillennium.att.com>
	<010d01c5ec3e$8d168d00$bd2c7c92@intranet.gr>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Fri, 18 Nov 2005 13:20:13 +0000
Message-Id: <1132320014.15191.63.camel@ccsrlt115.ee.surrey.ac.uk>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-7)
X-OriginalArrivalTime: 18 Nov 2005 13:20:14.0555 (UTC)
	FILETIME=[CFA3EAB0:01C5EC42]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Content-Transfer-Encoding: 7bit
Cc: 
Subject: [ippm] Unicast2multicast
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 

Dear all,
  With respect to the fact that more and more concern have been raised
in the mailing list about multicast/broadcast and the fact that most of
the IPPM RFCs were written oriented to unicast, I think we might need
put more efforts into the Unicast2Multicast or one-to-one2one-to-many
extension or even transition. 
  Personally I think unicast can be viewed as a special case of
multicast/broadcast from the routing point of view. the
multicast/broadcast builds up a routing tree in the networks and unicast
can be viewed as a special simplified tree without branches but only the
"Trunk". This concept can actually be applied to the de/composition
framework that we are trying to achieve in the WG, I think. I.e. we can
try to de/compose the routing(path) tree rather than only mention the
single "trunk"-- unicast path.
  Another concern is, I think, we can make our WG IDs more collaborated
with each other by add words talking about this unicast2multicast
extension/transition. e.g. specify any concern regarding to
multicast/broadcast when necessary in IDs. I will add something to the
multimetric ID with concern of collaboration to the 1 and 2 way active
measurement RFC and ID. 


Regards,

Lei Liang

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



From ippm-bounces@ietf.org Mon Nov 21 07:12:19 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EeAWx-0006AX-Gz; Mon, 21 Nov 2005 07:12:19 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EeAWv-0006AP-49; Mon, 21 Nov 2005 07:12:17 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24094;
	Mon, 21 Nov 2005 07:11:38 -0500 (EST)
Received: from smtp3.adl2.internode.on.net ([203.16.214.203])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EeApJ-0000Mx-Bu; Mon, 21 Nov 2005 07:31:21 -0500
Received: from [10.10.1.20] (ppp58-174.lns1.cbr1.internode.on.net
	[59.167.58.174])
	by smtp3.adl2.internode.on.net (8.12.9/8.12.6) with ESMTP id
	jALCC1vl015829; Mon, 21 Nov 2005 22:42:03 +1030 (CST)
	(envelope-from kewin@acm.org)
Message-ID: <4381B98E.2090804@acm.org>
Date: Mon, 21 Nov 2005 23:11:58 +1100
From: Kewin Stoeckigt <kewin@acm.org>
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: roman.krzanowski@verizon.com
Subject: Re: [ippm] short preso for the jitter discussion
References: <OF65F970B6.C4626491-ON852570AB.007837EC-852570AB.00792A9A@CORE.VERIZON.COM>
In-Reply-To: <OF65F970B6.C4626491-ON852570AB.007837EC-852570AB.00792A9A@CORE.VERIZON.COM>
Content-Type: text/plain; charset=windows-1251
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Content-Transfer-Encoding: 7bit
Cc: ippm@ietf.org, Henk Uijterwaal <henk@ripe.net>, ippm-bounces@ietf.org
X-BeenThere: ippm@ietf.org 
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <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 was wondering if there was a jitter discussion in Vancouver?
Unfortunately I wasn't in Vancouver, but I would be interested in the
outcome of such a discussion.

Kewin

roman.krzanowski@verizon.com wrote:
> I am attaching the short preso about the problem and issues I wanted to
> discuss during the IPPM WG meeting
> In vancouver.
> Please send ideas, suggestions or have them ready for the meeting
> thx
> roman
> (See attached file: Jitter DefinitionsIPPM-DEC2005_Vancouver_2.ppt)
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> ippm mailing list
> ippm@ietf.org 
> https://www1.ietf.org/mailman/listinfo/ippm


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



From ippm-bounces@ietf.org Tue Nov 22 12:31:41 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EebzZ-00079c-82; Tue, 22 Nov 2005 12:31:41 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EeB9r-00043e-Ba
	for ippm@megatron.ietf.org; Mon, 21 Nov 2005 07:52:32 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26831
	for <ippm@ietf.org>; Mon, 21 Nov 2005 07:51:52 -0500 (EST)
Received: from spinett.bth.se ([194.47.129.13])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeBSG-0001iN-Ui
	for ippm@ietf.org; Mon, 21 Nov 2005 08:11:35 -0500
Received: from Trantor (spinett.bth.se [194.47.129.13])
	by spinett.bth.se (8.13.4/8.13.4/Debian-3) with ESMTP id jALCqAEY003044
	for <ippm@ietf.org>; Mon, 21 Nov 2005 13:52:10 +0100
From: "Patrik Arlos" <Patrik.Arlos@bth.se>
To: <ippm@ietf.org>
Subject: RE: [ippm] I-D ACTION:draft-ietf-ippm-bw-capacity-01.txt
Date: Mon, 21 Nov 2005 13:52:09 +0100
Organization: Blekinge Institute of Technology
Message-ID: <004401c5ee9a$62b1f050$6700a8c0@Trantor>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
In-Reply-To: <20051112010101.GA531@firebird1.grc.nasa.gov>
Importance: Normal
X-Scanned-By: MIMEDefang 2.51 on 194.47.129.13
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 210770d71723b650f9c8e3db4e95b596
X-Mailman-Approved-At: Tue, 22 Nov 2005 12:31:39 -0500
Cc: 
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="===============0767926667=="
Sender: ippm-bounces@ietf.org 
Errors-To: ippm-bounces@ietf.org 

This is a multi-part message in MIME format.

--===============0767926667==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0045_01C5EEA2.C4765850"

This is a multi-part message in MIME format.

------=_NextPart_000_0045_01C5EEA2.C4765850
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Joseph, Philip:=20

=20

In your definition of Nominal Physical Link Capacity (NPLC), you state =
that
it 'does not vary with time'. I do not think that it holds for wireless
channels. The argument being that the signal interference can change =
quite
rapidly, and at some point the sending speed has to be altered to =
compensate
for the interference. Cf. the different speeds of 802.11 or UMTS. =
However,
from the following discussion, the time varying behaviour of the NPLC is =
not
interesting. Since it only acts as the upper limit of the capacity, =
i.e.,
C(t,t+I)<NomCap (t,t+I). Furthermore, if the desire is to define =
capacity at
the IP layer the behaviour of the underlying technologies should not =
matter.


=20

How about using 'hop' instead of 'link' in the IP layer terminology? A =
hop
involves a sender, a receiver and a set of link layer links. I do think =
that
is would resolve some other problems as well, for instance when virtual =
LAN
(VLAN) is used a 'hop' might cover multiple physical links, without any =
IP
layer treatment. I.e., from the IP layer's viewpoint there is a direct
connection to the destination.

=20

For instance, let S and D denote the IP address of the sending and =
receiving
entities, respectively. The path between S and D is described as =
sequence of
hops. A hop covers all communication entities involved in the transfer =
of an
IP packet between two logically adjacent entities. Via the number of =
hops
(hop count) we can identify the number of networks that has to be =
traversed
in order to reach D from S. The number of hops is only dependent on the =
IP
layer configuration, not the underlying configurations. For example, if =
S
and D are located on the same IP network, then hop count is zero. A hop
count of one would mean that the IP traffic passes one router to reach =
the
destination.=20

=20

=20

=20

/Patrik

=20

=20

=20

Patrik Arlos

SE/BTH/Sweden

+46 (0)455-385654

=20

> -----Original Message-----

> From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf =
Of

> Joseph Ishac

> Sent: den 12 november 2005 02:01

> To: ippm@ietf.org

> Subject: Re: [ippm] I-D ACTION:draft-ietf-ippm-bw-capacity-01.txt

>=20

> A new version of the capacity draft is available.

>=20

>     Title       : Defining Network Capacity

>     Author(s)   : P. Chimento, J. Ishac

>     Filename    : draft-ietf-ippm-bw-capacity-01.txt

>     Pages       : 16

>     Date        : 2005-11-11

>   =
http://www.ietf.org/internet-drafts/draft-ietf-ippm-bw-capacity-01.txt

>=20

> With this revision we have hopefully addressed all of the comments and

> outstanding issues that were raised.  So, please take a moment to read

> the draft and comment.

>=20

> For those who were familiar with the previous version(s) a changelog

> follows:

>=20

> Major changes from draft-ietf-ippm-bw-capacity-00

>=20

> * The paragraphs surrounding the definition of IP layer bits were

>   cleaned up.

> * Better explanation of the interval times

> * Made the interval a little clearer in the definitions.

> * Added a section to specify a correctly formed packet

> * Section added for BTC

>=20

> Thanks!

>=20

> -Joseph

>=20

> _______________________________________________

> ippm mailing list

> ippm@ietf.org

> https://www1.ietf.org/mailman/listinfo/ippm


------=_NextPart_000_0045_01C5EEA2.C4765850
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0pt;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 77.95pt 72.0pt 77.95pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-GB link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Hi Joseph, Philip: </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>In your definition of Nominal Physical Link Capacity (NPLC), you =
state
that it 'does not vary with time'. I do not think that it holds for =
wireless
channels. The argument being that the signal interference can change =
quite
rapidly, and at some point the sending speed has to be altered to =
compensate
for the interference. Cf. the different speeds of 802.11 or UMTS. =
However, from
the following discussion, the time varying behaviour of the NPLC is not
interesting. Since it only acts as the upper limit of the capacity, =
i.e., C(t,t+I)&lt;NomCap
(t,t+I). Furthermore, if the desire is to define capacity at the IP =
layer the
behaviour of the underlying technologies should not matter. =
</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>How about using 'hop' instead of &#8216;link&#8217; in the IP =
layer
terminology? A hop involves a sender, a receiver and a set of link layer =
links.
I do think that is would resolve some other problems as well, for =
instance when
virtual LAN (VLAN) is used a 'hop' might cover multiple physical links, =
without
any IP layer treatment. I.e., from the IP layer's viewpoint there is a =
direct
connection to the destination.</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>For instance, let S and D denote the IP address of the sending =
and
receiving entities, respectively. The path between S and D is described =
as
sequence of hops. A hop covers all communication entities involved in =
the
transfer of an IP packet between two logically adjacent entities. Via =
the number
of hops (hop count) we can identify the number of networks that has to =
be
traversed in order to reach D from S. The number of hops is only =
dependent on
the IP layer configuration, not the underlying configurations. For =
example, if
S and D are located on the same IP network, then hop count is zero. A =
hop count
of one would mean that the IP traffic passes one router to reach the
destination. </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>/Patrik</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DPT-BR
style=3D'font-size:10.0pt'>Patrik Arlos</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DPT-BR
style=3D'font-size:10.0pt'>SE/BTH/Sweden</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DPT-BR
style=3D'font-size:10.0pt'>+46 (0)455-385654</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DPT-BR
style=3D'font-size:10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font><span lang=3DEN-US>-----Original =
Message-----</span></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font><span lang=3DEN-US>From: =
ippm-bounces@ietf.org
[mailto:ippm-bounces@ietf.org] On Behalf Of</span></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font><span lang=3DEN-US>Joseph Ishac</span></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font><span lang=3DEN-US>Sent: den </span><span =
lang=3DEN-US>12 november 2005</span><span lang=3DEN-US> </span><span
 lang=3DEN-US>02:01</span></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font><span lang=3DEN-US>To: =
ippm@ietf.org</span></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font><span lang=3DEN-US>Subject: Re: [ippm] I-D
ACTION:draft-ietf-ippm-bw-capacity-01.txt</span></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; A new version of the capacity draft is =
available.</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; &nbsp;&nbsp;&nbsp; =
Title&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :
Defining Network Capacity</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; &nbsp;&nbsp;&nbsp; Author(s)&nbsp;&nbsp; : P. Chimento, J. =
Ishac</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; &nbsp;&nbsp;&nbsp; Filename&nbsp;&nbsp;&nbsp; :
draft-ietf-ippm-bw-capacity-01.txt</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; &nbsp;&nbsp;&nbsp; =
Pages&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 16</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; &nbsp;&nbsp;&nbsp; =
Date&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :
2005-11-11</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; =
&nbsp;&nbsp;http://www.ietf.org/internet-drafts/draft-ietf-ippm-bw-capaci=
ty-01.txt</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; With this revision we have hopefully addressed all of the =
comments
and</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; outstanding issues that were raised.&nbsp; So, please take =
a
moment to read</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; the draft and comment.</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; For those who were familiar with the previous version(s) a
changelog</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; follows:</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; Major changes from =
draft-ietf-ippm-bw-capacity-00</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; * The paragraphs surrounding the definition of IP layer =
bits were</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; &nbsp;&nbsp;cleaned up.</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; * Better explanation of the interval =
times</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; * Made the interval a little clearer in the =
definitions.</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; * Added a section to specify a correctly formed =
packet</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; * Section added for BTC</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; Thanks!</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; -Joseph</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; =
_______________________________________________</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; ippm mailing list</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; ippm@ietf.org</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; =
https://www1.ietf.org/mailman/listinfo/ippm</span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0045_01C5EEA2.C4765850--



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

--===============0767926667==--





From ippm-bounces@ietf.org Tue Nov 22 12:31:42 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EebzZ-0007Ag-Uu; Tue, 22 Nov 2005 12:31:41 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EeH3o-0001pV-EH
	for ippm@megatron.ietf.org; Mon, 21 Nov 2005 14:10:44 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24755
	for <ippm@ietf.org>; Mon, 21 Nov 2005 14:10:01 -0500 (EST)
Received: from mail.av.it.pt ([193.136.92.53] helo=av.it.pt)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeHMH-0004rD-0T
	for ippm@ietf.org; Mon, 21 Nov 2005 14:29:48 -0500
X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.av.it.pt
X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,HTML_80_90,
	HTML_MESSAGE,MSGID_FROM_MTA_ID autolearn=no version=3.0.4
X-TFF-CGPSA-Version: 1.4
X-TFF-CGPSA-Filter: Scanned
Received: from [193.136.93.103] (HELO acer3f05b2af82)
	by av.it.pt (CommuniGate Pro SMTP 4.3.7)
	with ESMTP id 3598092; Mon, 21 Nov 2005 19:08:47 +0000
From: =?iso-8859-1?Q?H=E9lder_Veiga?= <hveiga@av.it.pt>
To: <ippm@ietf.org>, <shalunov@internet2.edu>,
	"'Henk Uijterwaal \(RIPE NCC\)'" <henk@ripe.net>, <ben@internet2.edu>, 
	<ankarp@yahoo.com>, <boote@internet2.edu>, <matt@internet2.edu>
Date: Mon, 21 Nov 2005 19:09:59 -0000
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcXsYdTseoXGvfuUTHGuXXI9r2M2xgCKxF2wAA+pBMA=
Message-ID: <auto-000003598092@av.it.pt>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9
X-Mailman-Approved-At: Tue, 22 Nov 2005 12:31:39 -0500
Cc: =?iso-8859-1?Q?'Ant=F3nio_Nogueira'?= <nogueira@av.it.pt>,
	'Paulo Salvador Ferreira' <salvador@av.it.pt>,
	owamp-users@internet2.edu, jsmartins@inf.ufrgs.br,
	'Dario Rossi' <rossi@tlc.polito.it>, "'Martin,
	Cynthia'" <Cynthia.Martin@si-intl.com>, jlo@det.ua.pt,
	=?iso-8859-1?Q?'Jo=E3o_Silva'?= <a28123@alunos.det.ua.pt>, rv@det.ua.pt,
	'Geraldine Texier' <geraldine.texier@enst-bretagne.fr>,
	'Patrik Arlos' <Patrik.Arlos@bth.se>, 'Pin Hu' <pin.hu@plymouth.ac.uk>,
	'Marco Mellia' <mellia@prezzemolo.polito.it>,
	'Thomas Pfeiffenberger' <tpfeiff@salzburgresearch.at>,
	'Zhan Xiaoying' <xyzhan@dcs.gla.ac.uk>,
	'Felix Strohmeier' <fstrohmeier@salzburgresearch.at>, jolival@av.it.pt
Subject: [ippm] J-OWAMP, new version and site
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="===============1369013012=="
Sender: ippm-bounces@ietf.org 
Errors-To: ippm-bounces@ietf.org 

This is a multi-part message in MIME format.

--===============1369013012==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000D_01C5EECF.2B140360"

This is a multi-part message in MIME format.

------=_NextPart_000_000D_01C5EECF.2B140360
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Please accept our apologies if you receive multiple copies of this
announcement.

-------------------------------------------------------------------------=
---
----------------------------------------

=20

Dear all,

=20

This is to announce that we have completed the second phase of =
development
of a Java implementation of OWAMP. We added two new versions (1.1 and =
2.0)
of our implementation to the J-OWAMP web site. The current version of
J-OWAMP (version 2.0) implements the December 2004 draft proposal of =
OWAMP
(http://www.internet2.edu/~shalunov/ippm/draft-ietf-ippm-owdp-14.txt). =
The
previous versions of J-OWAMP (versions 1.0 and 1.1) implement the May =
2004
draft proposal of OWAMP
(http://www.internet2.edu/~shalunov/ippm/draft-ietf-ippm-owdp-08.txt). =
You
can find more information on this platform in =
http://www.av.it.pt/jowamp.

=20

Any comments are welcome.

=20

Best regards.

=20

H=E9lder Veiga

Rui Valadas

Jos=E9 Lu=EDs Oliveira

Paulo Salvador

Ant=F3nio Nogueira

Jo=E3o Silva


------=_NextPart_000_000D_01C5EECF.2B140360
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Please accept our =
apologies
if you receive multiple copies of this =
announcement.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>-------------------------------------------------------------------=
-------------------------------------------------<o:p></o:p></span></font=
></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dnavy
face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Dear all,<font =
color=3Dnavy><span
style=3D'color:navy'><o:p></o:p></span></font></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>This is to announce =
that we
have completed the second phase of development of a Java implementation =
of
OWAMP. We added two new versions (1.1 and 2.0) of our implementation to =
the
J-OWAMP web site. The current version of J-OWAMP (version 2.0) =
implements the
December 2004 draft proposal of OWAMP<font color=3Dnavy><span =
style=3D'color:navy'>
</span></font>(<a
href=3D"http://www.internet2.edu/~shalunov/ippm/draft-ietf-ippm-owdp-14.t=
xt">http://www.internet2.edu/~shalunov/ippm/draft-ietf-ippm-owdp-14.txt</=
a><font
color=3Dnavy><span style=3D'color:navy'>)</span></font>. The previous =
versions of
J-OWAMP (versions 1.0 and 1.1) implement the May 2004 draft proposal of =
OWAMP (<a
href=3D"http://www.internet2.edu/~shalunov/ippm/draft-ietf-ippm-owdp-08.t=
xt">http://www.internet2.edu/~shalunov/ippm/draft-ietf-ippm-owdp-08.txt</=
a>).
You can find more information on this platform in <a
href=3D"http://www.av.it.pt/jowamp">http://www.av.it.pt/jowamp</a>.<font
color=3Dnavy><span =
style=3D'color:navy'><o:p></o:p></span></font></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Any comments are =
welcome.<font
color=3Dnavy><span =
style=3D'color:navy'><o:p></o:p></span></font></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dnavy
face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Best regards.<font
color=3Dnavy><span =
style=3D'color:navy'><o:p></o:p></span></font></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
lang=3DPT style=3D'font-size:10.0pt;font-family:"Courier New"'>H=E9lder =
Veiga<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
lang=3DPT style=3D'font-size:10.0pt;font-family:"Courier New"'>Rui =
Valadas<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
lang=3DPT style=3D'font-size:10.0pt;font-family:"Courier New"'>Jos=E9 =
Lu=EDs Oliveira<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Paulo =
Salvador<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Ant=F3nio =
Nogueira<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Jo=E3o Silva<font =
color=3Dnavy><span
style=3D'color:navy'><o:p></o:p></span></font></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_000D_01C5EECF.2B140360--




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

--===============1369013012==--






From ippm-bounces@ietf.org Wed Nov 30 21:51:36 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EheXo-0003r0-OL; Wed, 30 Nov 2005 21:51:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EheXn-0003qL-Ci
	for ippm@megatron.ietf.org; Wed, 30 Nov 2005 21:51:35 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08182
	for <ippm@ietf.org>; Wed, 30 Nov 2005 21:50:49 -0500 (EST)
Received: from gate.alliedtelesyn.co.nz ([202.49.72.33] ident=proxyuser)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EhesA-0002i5-Hn
	for ippm@ietf.org; Wed, 30 Nov 2005 22:12:40 -0500
Received: (qmail 11126 invoked from network); 1 Dec 2005 02:51:18 -0000
Received: from mailmarshall.alliedtelesyn.co.nz (10.32.18.40)
	by gate-int.alliedtelesyn.co.nz with SMTP; 1 Dec 2005 02:51:18 -0000
Received: from aslan.alliedtelesyn.co.nz (Not Verified[10.32.18.53]) by
	mailmarshall.alliedtelesyn.co.nz with NetIQ MailMarshal (v5.5.6.7)
	id <B0004723e2>; Thu, 01 Dec 2005 15:49:41 +1300
Received: from CHCDOM1-MTA by aslan.alliedtelesyn.co.nz
	with Novell_GroupWise; Thu, 01 Dec 2005 15:51:17 +1300
Message-Id: <s38f1bf5.013@aslan.alliedtelesyn.co.nz>
X-Mailer: Novell GroupWise Internet Agent 6.5.4 
Date: Thu, 01 Dec 2005 15:50:50 +1300
From: "sharee mcnab" <sharee.mcnab@alliedtelesyn.co.nz>
To: <khedayat@brixnet.com>, <ippm@ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Content-Transfer-Encoding: quoted-printable
Cc: nick kinraid <nick.kinraid@alliedtelesyn.co.nz>
Subject: [ippm] draft-hedayat-two-way-active-measurement protocol-01.txt
	TWAMP Light
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 


Further comments/questions on the TWAMP draft -

1.  In the TWAMP draft the format of the send packet is not explictly sta=
ted.  Should we assume
a) the send packet is the same as the OWAMP send packet (ie 14 octets una=
uthenticated, 32 authenticated/encrypted) which then leaves the send and =
reflected packets with a different size (undesirable) unless the payload =
is adjusted by the reflector.
OR
b) the send packet is the same format as that of the reflected packet (ie=
=2040 octets unauthenticated, 80 authenticated/encrypted), here both pack=
ets are the same size (desirable) with a larger bandwidth requirement.

I assume b) but think clarification should be in the draft.

2.  An explicit packet record is not defined for TWAMP.  Is this consider=
ed within the scope of the TWAMP draft to provide a packet record for thi=
s protocol?
Given the excessive number of time stamps for a two-way measurement I wou=
ld propose that a single time reference be used and then offsets to reduc=
e the size of the packet record.

Cheers
Sharee


NOTICE: This message contains privileged and confidential
information intended only for the use of the addressee
named above. If you are not the intended recipient of
this message you are hereby notified that you must not
disseminate, copy or take any action in reliance on it.
If you have received this message in error please
notify Allied Telesyn Research Ltd immediately.
Any views expressed in this message are those of the
individual sender, except where the sender has the
authority to issue and specifically states them to
be the views of Allied Telesyn Research.

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