From ippm-admin@advanced.org  Sat Feb  1 04:29:52 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02831
	for <ippm-archive@lists.ietf.org>; Sat, 1 Feb 2003 04:29:51 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h119V4BN001854;
	Sat, 1 Feb 2003 04:31:04 -0500
Received: from web13310.mail.yahoo.com (web13310.mail.yahoo.com [216.136.173.222])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with SMTP id h119ULBN001831
	for <ippm@advanced.org>; Sat, 1 Feb 2003 04:30:22 -0500
Message-ID: <20030201093021.35725.qmail@web13310.mail.yahoo.com>
Received: from [68.102.103.236] by web13310.mail.yahoo.com via HTTP; Sat, 01 Feb 2003 01:30:21 PST
From: Ameet Patil <ameet_patil2@yahoo.com>
To: ippm@advanced.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-432120486-1044091821=:34939"
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
Subject: [ippm] Need help with Video Over MPLS
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: Sat, 1 Feb 2003 01:30:21 -0800 (PST)

--0-432120486-1044091821=:34939
Content-Type: text/plain; charset=us-ascii


Hi there, I am a masters student at Wichita State University,USA. I was looking for a project topic in Video over Mpls, or just any topic in MPLS. I do have access to simulation softwares like Op-Net. I also have access to a routers lab. Please let me know at the earliest....

Thanks, Ameet



---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
--0-432120486-1044091821=:34939
Content-Type: text/html; charset=us-ascii

<P>Hi there, I am a masters student at Wichita State University,USA. I was looking for a project topic in Video over Mpls, or just any topic in MPLS. I do have access to simulation softwares like Op-Net. I also have access to a routers lab. Please let me know at the earliest....</P>
<P>Thanks, Ameet</P><p><br><hr size=1>Do you Yahoo!?<br>
<a href="http://rd.yahoo.com/mail/mailsig/*http://mailplus.yahoo.com">Yahoo! Mail Plus</a> - Powerful. Affordable. <a href="http://rd.yahoo.com/mail/mailsig/*http://mailplus.yahoo.com">Sign up now</a>
--0-432120486-1044091821=:34939--
_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From tq_live_ideas-admin@advanced.org  Sat Feb  1 06:49:52 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04655
	for <ippm-archive@lists.ietf.org>; Sat, 1 Feb 2003 06:49:51 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h11BrQBN006838
	for <ippm-archive@lists.ietf.org>; Sat, 1 Feb 2003 06:53:26 -0500
Date: Sat, 01 Feb 2003 06:53:26 -0500
Message-ID: <20030201115326.5751.38664.Mailman@mailhost.advanced.org>
Subject: advanced.org mailing list memberships reminder
From: mailman-owner@advanced.org
To: ippm-archive@ietf.org
X-No-Archive: yes
List-Id: Multiple lists at advanced.org
X-Ack: no
Sender: tq_live_ideas-admin@advanced.org
Errors-To: tq_live_ideas-admin@advanced.org
X-BeenThere: tq_live_ideas@thinkquest.org
X-Mailman-Version: 2.0.12
Precedence: bulk
X-Virus-Scanned: by AMaViS-ng (Milter interface)

This is a reminder, sent out once a month, about your advanced.org
mailing list memberships.  It includes your subscription info and how
to use it to change it or unsubscribe from a list.

You can visit the URLs to change your membership status or
configuration, including unsubscribing, setting digest-style delivery
or disabling delivery altogether (e.g., for a vacation), and so on.

In addition to the URL interfaces, you can also use email to make such
changes.  For more info, send a message to the '-request' address of
the list (for example, ippm-request@advanced.org) containing just the
word 'help' in the message body, and an email message will be sent to
you with instructions.

If you have questions, problems, comments, etc, send them to
mailman-owner@advanced.org.  Thanks!

Passwords for ippm-archive@lists.ietf.org:

List                                     Password // URL
----                                     --------  
ippm@advanced.org                        jTPE      
http://mailhost.advanced.org/mailman/options/ippm/ippm-archive%40lists.ietf.org


From ippm-admin@advanced.org  Mon Feb  3 06:44:51 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03536
	for <ippm-archive@lists.ietf.org>; Mon, 3 Feb 2003 06:44:51 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h13Bk4CN025466;
	Mon, 3 Feb 2003 06:46:04 -0500
Received: from hotmail.com (f57.sea2.hotmail.com [207.68.165.57])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h13BjACN025326
	for <ippm@advanced.org>; Mon, 3 Feb 2003 06:45:10 -0500
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 3 Feb 2003 03:45:09 -0800
Received: from 193.116.20.220 by sea2fd.sea2.hotmail.msn.com with HTTP;
	Mon, 03 Feb 2003 11:45:09 GMT
X-Originating-IP: [193.116.20.220]
From: "gab jones" <seun_ewulomi@hotmail.com>
To: ippm@advanced.org
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F57BAADouER8wVkpdax0001bc44@hotmail.com>
X-OriginalArrivalTime: 03 Feb 2003 11:45:09.0997 (UTC) FILETIME=[B48631D0:01C2CB79]
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
Subject: [ippm] netflow analyzer
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: Mon, 03 Feb 2003 11:45:09 +0000

Hi,

This are to people who have cisco netflow enabled on their router. Il like 
to know what netflow analyzers people are currently using.

I am currently looking into NetQos report analyzer. Is there anyone 
currently using this? If they are what do they think of the product?

Anyone please just list what product or open source tool they are currently 
using to analyze netflow data and why?

Suggestions on what netflow analyzer are good out there

is it better to use open source  e.g flow-tools, cflowd

I know with the open source they have powerful command line utilities to 
examine flows

thanks

regards,
gab

_________________________________________________________________
Surf together with new Shared Browsing 
http://join.msn.com/?page=features/browse&pgmarket=en-gb&XAPID=74&DI=1059

_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Mon Feb  3 12:03:44 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13295
	for <ippm-archive@lists.ietf.org>; Mon, 3 Feb 2003 12:03:44 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h13H44CN002290;
	Mon, 3 Feb 2003 12:04:04 -0500
Received: from web10203.mail.yahoo.com (web10203.mail.yahoo.com [216.136.130.67])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with SMTP id h118qFBN000999
	for <ippm@advanced.org>; Sat, 1 Feb 2003 03:52:16 -0500
Message-ID: <20030201085215.41152.qmail@web10203.mail.yahoo.com>
Received: from [203.197.138.177] by web10203.mail.yahoo.com via HTTP; Sat, 01 Feb 2003 00:52:15 PST
From: balajambunathan r <mailforbalu@yahoo.com>
To: ippm@advanced.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
Subject: [ippm] a doubt!!
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: Sat, 1 Feb 2003 00:52:15 -0800 (PST)

Respected sir,
	      I am doing a simulation of the existing tcp/ip
network and a full optical network for file transfer.
	I need a performance metric for comparing these two
networks.
	I will be thankful to you if you could kindly send me
a reply.

Yours sincerely,
R.Balajambunathan

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Mon Feb  3 12:03:57 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13310
	for <ippm-archive@lists.ietf.org>; Mon, 3 Feb 2003 12:03:57 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h13H4CCN002326;
	Mon, 3 Feb 2003 12:04:13 -0500
Received: from isis.lip6.fr (isis.lip6.fr [132.227.60.2])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h13EnQCO030369
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL)
	for <ippm@advanced.org>; Mon, 3 Feb 2003 09:49:27 -0500
Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2])
          by isis.lip6.fr (8.12.4/jtpda-5.4+victor) with ESMTP id h13EnPlE032205
          (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
          ; Mon, 3 Feb 2003 15:49:25 +0100
X-pt: isis.lip6.fr
Received: from LIP60MU1PINK59 (perse [132.227.61.88])
	by tibre.lip6.fr (8.11.6/8.11.3) with SMTP id h13EnP314501;
	Mon, 3 Feb 2003 15:49:25 +0100 (MET)
From: =?iso-8859-1?Q?Kav=E9_Salamatian?= <Kave.Salamatian@lip6.fr>
To: "gab jones" <seun_ewulomi@hotmail.com>, <ippm@advanced.org>
Subject: RE: [ippm] netflow analyzer
Message-ID: <EBELLEFJANFIHFPEMGPCAEFBCMAA.salamat@rp.lip6.fr>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <F57BAADouER8wVkpdax0001bc44@hotmail.com>
X-Scanned-By: isis.lip6.fr
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: Mon, 3 Feb 2003 15:48:45 +0100
Content-Transfer-Encoding: 8bit

Dear Gab,

you might have a look to the following paper NetFlow: Information loss or
win?, by Anja Feldman & al, that might be downloaded from IMW 2002 web pages
at http://www.icir.org/vern/imw-2002/program.html. It analyse what netflow
can do.

Bests

Kavé Salamatian

-----Message d'origine-----
De : ippm-admin@advanced.org [mailto:ippm-admin@advanced.org]De la part
de gab jones
Envoyé : lundi 3 février 2003 12:45
À : ippm@advanced.org
Objet : [ippm] netflow analyzer


Hi,

This are to people who have cisco netflow enabled on their router. Il like
to know what netflow analyzers people are currently using.

I am currently looking into NetQos report analyzer. Is there anyone
currently using this? If they are what do they think of the product?

Anyone please just list what product or open source tool they are currently
using to analyze netflow data and why?

Suggestions on what netflow analyzer are good out there

is it better to use open source  e.g flow-tools, cflowd

I know with the open source they have powerful command line utilities to
examine flows

thanks

regards,
gab

_________________________________________________________________
Surf together with new Shared Browsing
http://join.msn.com/?page=features/browse&pgmarket=en-gb&XAPID=74&DI=1059

_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm

_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Tue Feb  4 08:50:59 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22483
	for <ippm-archive@lists.ietf.org>; Tue, 4 Feb 2003 08:50:59 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h14Dr3CN003696;
	Tue, 4 Feb 2003 08:53:04 -0500
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h14DqCCN003676
	for <ippm@advanced.org>; Tue, 4 Feb 2003 08:52:13 -0500
Received: from RHOLLEYW2K1 (dhcp-64-102-43-113.cisco.com [64.102.43.113]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id IAA01245 for <ippm@advanced.org>; Tue, 4 Feb 2003 08:52:12 -0500 (EST)
From: "Robert Holley" <rholley@cisco.com>
To: <ippm@advanced.org>
Message-ID: <AOEEKIJDFDEJBIPPDENFAENIEAAA.rholley@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <87snb8awui.fsf@cain.internet2.edu>
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
Subject: [ippm] IPPM MIB
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: Tue, 4 Feb 2003 08:52:12 -0500
Content-Transfer-Encoding: 7bit

All,

Does anyone know of any implementations of the IPPM MIB?

I would be interested in finding any test agents etc.

thanks in advance
Bob
_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Tue Feb  4 14:36:04 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02502
	for <ippm-archive@lists.ietf.org>; Tue, 4 Feb 2003 14:36:04 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h14Jc3CN014700;
	Tue, 4 Feb 2003 14:38:03 -0500
Received: from u-mail.rd.francetelecom.com (u-mail.rd.francetelecom.com [208.25.178.63])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h14JbDCN014681
	for <ippm@advanced.org>; Tue, 4 Feb 2003 14:37:13 -0500
Received: by U-MAIL with Internet Mail Service (5.5.2653.19)
	id <C9J44Q5M>; Tue, 4 Feb 2003 11:37:12 -0800
Message-ID: <037E7050631FD611AAFD0002A509146A834A09@U-MAIL2>
From: JEWITT Jessie / FTR&D / US <jessie.jewitt@rd.francetelecom.com>
To: "'Robert Holley '" <rholley@cisco.com>
Cc: "'ippm@advanced.org'" <ippm@advanced.org>
Subject: RE: [ippm] IPPM MIB
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2CC85.72A2BE20"
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: Tue, 4 Feb 2003 11:41:44 -0800

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2CC85.72A2BE20
Content-Type: text/plain;
	charset="iso-8859-1"

 Robert-
   As co-author of the mib with Emile Stephan (France Telecom R&D), we are
currently completing an implementation of the mib in our labs in South San
Francisco. 
Jessie Jewitt

-----Original Message-----
From: Robert Holley
To: ippm@advanced.org
Sent: 2/4/03 5:59 AM
Subject: [ippm] IPPM MIB

All,

Does anyone know of any implementations of the IPPM MIB?

I would be interested in finding any test agents etc.

thanks in advance
Bob
_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm

------_=_NextPart_001_01C2CC85.72A2BE20
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [ippm] IPPM MIB</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>&nbsp;Robert-</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; As co-author of the mib with Emile =
Stephan (France Telecom R&amp;D), we are currently completing an =
implementation of the mib in our labs in South San Francisco. =
</FONT></P>

<P><FONT SIZE=3D2>Jessie Jewitt</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Robert Holley</FONT>
<BR><FONT SIZE=3D2>To: ippm@advanced.org</FONT>
<BR><FONT SIZE=3D2>Sent: 2/4/03 5:59 AM</FONT>
<BR><FONT SIZE=3D2>Subject: [ippm] IPPM MIB</FONT>
</P>

<P><FONT SIZE=3D2>All,</FONT>
</P>

<P><FONT SIZE=3D2>Does anyone know of any implementations of the IPPM =
MIB?</FONT>
</P>

<P><FONT SIZE=3D2>I would be interested in finding any test agents =
etc.</FONT>
</P>

<P><FONT SIZE=3D2>thanks in advance</FONT>
<BR><FONT SIZE=3D2>Bob</FONT>
<BR><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>ippm mailing list</FONT>
<BR><FONT SIZE=3D2>ippm@advanced.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://mailhost.advanced.org/mailman/listinfo/ippm" =
TARGET=3D"_blank">http://mailhost.advanced.org/mailman/listinfo/ippm</A>=
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2CC85.72A2BE20--
_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Thu Feb  6 13:32:21 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29488
	for <ippm-archive@lists.ietf.org>; Thu, 6 Feb 2003 13:32:21 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h16IW4CN027998;
	Thu, 6 Feb 2003 13:32:04 -0500
Received: from Modus.surfnetusa.com (modus.surfnetusa.com [208.201.152.19])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h16IVoCO027979
	for <ippm@advanced.org>; Thu, 6 Feb 2003 13:31:51 -0500
Received: from mainserver.surfnetusa.com (unverified [208.201.152.2]) by Modus.surfnetusa.com
 (Vircom SMTPRS 2.0.241) with ESMTP id <B0009240685@Modus.surfnetusa.com> for <ippm@advanced.org>;
 Thu, 6 Feb 2003 10:29:42 -0800
Received: from lsanca1-ar16-4-46-057-169.lsanca1.dsl-verizon.net (lsanca1-ar16-4-46-057-169.lsanca1.dsl-verizon.net [4.46.57.169]) by mainserver.bookholt.com (NTMail 5.06.0016/AX0201.00.06a07d84) with ESMTP id wmieqcaa for ippm@advanced.org; Thu, 6 Feb 2003 10:29:37 -0800
Message-Id: <5.1.0.14.2.20030206102633.024b96d8@mail.merike.com>
X-Sender: kaeo.merike@mail.merike.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
To: "'ippm@advanced.org'" <ippm@advanced.org>
From: Merike Kaeo <kaeo@merike.com>
Cc: matt@internet2.edu
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
Subject: [ippm] upcoming meeting
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: Thu, 06 Feb 2003 10:29:28 -0800

Hello.

In trying to ascertain how much time we would need for the upcoming 
meeting, please let Matt and I know if you would like to present any 
material and what the approximate time that you would need is.  Thanks.


- Merike



_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Sun Feb  9 10:23:25 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00282
	for <ippm-archive@lists.ietf.org>; Sun, 9 Feb 2003 10:23:25 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h19FP4CN014743;
	Sun, 9 Feb 2003 10:25:04 -0500
Received: from www.apara.com ([64.106.140.220])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h19FOvCN014724
	for <ippm@advanced.org>; Sun, 9 Feb 2003 10:24:58 -0500
Received: from www.apara.com (localhost.localdomain [127.0.0.1])
	by www.apara.com (8.11.6/8.11.6) with ESMTP id h19Fj2Q22217
	for <ippm@advanced.org>; Sun, 9 Feb 2003 21:15:02 +0530
Received: from alok (PPP-219-65-149-64.bng.vsnl.net.in [219.65.149.64])
	(authenticated)
	by www.apara.com (8.11.6/8.11.6) with ESMTP id h19Fixt22202
	for <ippm@advanced.org>; Sun, 9 Feb 2003 21:15:00 +0530
Message-ID: <031a01c2d04f$add4e680$81c802c0@alok>
From: "alok" <alok.dube@apara.com>
To: <ippm@advanced.org>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
Subject: [ippm] Congestion avoidance and Fair queueing algorithms
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: Sun, 9 Feb 2003 20:56:48 +0530

Hello,

I would like to know if there are people working on testing the following:
1. capping the Max TCP window size to 8192 bytes (or some such value)
2. using such TCP machines with such capabilities and "FQ" in the core,
where the queue size on the switching/routing nodes is based on window
size=8192 bytes, what is the pattern of congestion/packet loss, number of
retransmissions seen......
3. assuming TCP RENO is the default mechanism and SREJ/SACK methods are not
used, are there any published results with similar topologies?

thanks and rgds
Alok Dube


_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm




From ippm-admin@advanced.org  Fri Feb 14 12:00:41 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27220
	for <ippm-archive@lists.ietf.org>; Fri, 14 Feb 2003 12:00:41 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1EH05CN012025;
	Fri, 14 Feb 2003 12:00:05 -0500
Received: from mesa.acns.ColoState.EDU (mesa.acns.colostate.edu [129.82.100.130])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1EGxGCN011974
	for <ippm@advanced.org>; Fri, 14 Feb 2003 11:59:17 -0500
Received: from lamar.colostate.edu (lamar.acns.colostate.edu [129.82.100.75])
	by mesa.acns.ColoState.EDU (AIX4.3/8.9.3/8.9.3) with ESMTP id JAA77056
	for <ippm@advanced.org>; Fri, 14 Feb 2003 09:59:16 -0700
Received: from engr.colostate.edu (res096090.halls.colostate.edu [129.82.96.90] (may be forged)) by lamar.colostate.edu (AIX5.1/8.11.0/8.8.8) with ESMTP id h1EGxGI312790; Fri, 14 Feb 2003 09:59:16 -0700
Message-ID: <3E4D20C4.8070605@engr.colostate.edu>
From: Nischal M Piratla <nischal@engr.colostate.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ippm@advanced.org
CC: Anura Jayasumana <Anura.Jayasumana@Colostate.edu>,
        Abhijit A Bare
 <abhijit@CS.ColoState.EDU>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
Subject: [ippm] New metric for packet reordering.
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: Fri, 14 Feb 2003 10:00:52 -0700
Content-Transfer-Encoding: 7bit

Dear ippm Members,
We have come up with a new metric to measure packet reordering. We have 
posted a ID and here is the link:

http://www.ietf.org/internet-drafts/draft-jayasumana-reorder-density-00.txt

This draft may interest you all. Please feel free to send any 
comments/suggestions.
Thanks,
Nischal Piratla

_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Fri Feb 14 15:50:39 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04579
	for <ippm-archive@lists.ietf.org>; Fri, 14 Feb 2003 15:50:38 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1EKn4CN019175;
	Fri, 14 Feb 2003 15:49:04 -0500
Received: from basie.internet2.edu (basie.internet2.edu [207.75.164.22])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1EKn0CN019159
	for <ippm@advanced.org>; Fri, 14 Feb 2003 15:49:00 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by basie.internet2.edu (Postfix) with ESMTP
	id 4BA3D7B485; Fri, 14 Feb 2003 15:49:00 -0500 (EST)
Received: from localhost (localhost [127.0.0.1])
	by basie.internet2.edu (Postfix) with ESMTP
	id 5FFEB7B46C; Fri, 14 Feb 2003 15:48:59 -0500 (EST)
To: Jeff Brainard <jbrainard@mirapoint.com>
Cc: ippm@advanced.org
Subject: Re: [ippm] SMTP traffic metrics
References: <3E02050B.9010606@mirapoint.com>
From: stanislav shalunov <shalunov@internet2.edu>
In-Reply-To: <3E02050B.9010606@mirapoint.com>
Message-ID: <87bs1esi4l.fsf@cain.internet2.edu>
Lines: 26
X-Mailer: Gnus v5.7/Emacs 20.4
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS 0.3.12pre8
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: 14 Feb 2003 15:48:58 -0500

Jeff Brainard <jbrainard@mirapoint.com> writes:

> I'm looking for metrics on the % of Internet traffic that is email
> (Port 25 SMTP). This can either be presented as 'raw packets' or
> 'number of connections.'  Thanks for any info you might have to pass
> along...

Jeff,

Sorry about this incredibly late reply.

I can speak for Abilene, the Internet2 backbone (now moving from
2.5Gb/s to 10Gb/s).  Most university-to-university traffic in the
U.S. is likely to traverse it.

On Abilene, the percentage of `mail' traffic (which includes ports for
protocols like SMTP, POP3, IMAP, encrypted versions of these, etc.,
all combined) comprises about 0.4% of octets and 0.6% of packets.

See http://netflow.internet2.edu/weekly/ for more information.

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

Democracy is a form of government that substitutes election by the incompetent
many for appointment by the corrupt few.                         -- G. B. Shaw
_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Mon Feb 17 05:56:46 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19793
	for <ippm-archive@lists.ietf.org>; Mon, 17 Feb 2003 05:56:46 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1HAw4CN019894;
	Mon, 17 Feb 2003 05:58:04 -0500
Received: from birch.ripe.net (birch.ripe.net [193.0.1.96])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1HAv5CN019878
	for <ippm@advanced.org>; Mon, 17 Feb 2003 05:57:06 -0500
Received: from x49.ripe.net (x49.ripe.net [193.0.1.49])
	by birch.ripe.net (8.12.5/8.11.6) with ESMTP id h1HAv5Aq014348;
	Mon, 17 Feb 2003 11:57:05 +0100
Received: from localhost (henk@localhost)
	by x49.ripe.net (8.12.4/8.12.6) with ESMTP id h1HAv3Qg004791;
	Mon, 17 Feb 2003 11:57:04 +0100
X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs
From: "Henk Uijterwaal (RIPE-NCC)" <henk@ripe.net>
To: Nischal M Piratla <nischal@engr.colostate.edu>
cc: ippm@advanced.org, Anura Jayasumana <Anura.Jayasumana@Colostate.edu>,
        Abhijit A Bare <abhijit@CS.ColoState.EDU>
Subject: Re: [ippm] New metric for packet reordering.
In-Reply-To: <3E4D20C4.8070605@engr.colostate.edu>
Message-ID: <Pine.LNX.4.44.0302171151160.4222-100000@x49.ripe.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: Mon, 17 Feb 2003 11:57:03 +0100 (CET)

Nischal,

> We have come up with a new metric to measure packet reordering. We have
> posted a ID and here is the link:
>
> http://www.ietf.org/internet-drafts/draft-jayasumana-reorder-density-00.txt
>
> This draft may interest you all. Please feel free to send any
> comments/suggestions.

1. If I understand the algorithm correctly, then it needs an array
   in_buffer[N] with N the number of packets in a stream. This is not
   very practical, when I make a VoIP phonecall, then I never know how
   long it is going to last in advance and thus how I should dimension
   this array.

2. Can you include the same examples as in the other reordering metrics
   so one can compare the algorithms?

Henk


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

That problem that we weren't having yesterday, is it better? (Big ISP NOC)



_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Mon Feb 17 09:28:41 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22876
	for <ippm-archive@lists.ietf.org>; Mon, 17 Feb 2003 09:28:41 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1HES5CN025716;
	Mon, 17 Feb 2003 09:28:05 -0500
Received: from almso2.proxy.att.com (almso2.att.com [192.128.166.71])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1HERsCN025700
	for <ippm@advanced.org>; Mon, 17 Feb 2003 09:27:54 -0500
Received: from hogpa.mt.att.com ([135.16.74.2])
	by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with SMTP id h1HERqHS000899;
	Mon, 17 Feb 2003 09:27:52 -0500 (EST)
Received: from acmortonw.att.com by hogpa.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2)
	id JAA27457; Mon, 17 Feb 2003 09:27:50 -0500
Message-Id: <5.1.0.14.0.20030217091903.02c3eda0@135.16.74.2>
X-Sender: acm1@135.16.74.2
X-Mailer: QUALCOMM Windows Eudora Version 5.1
To: "Henk Uijterwaal (RIPE-NCC)" <henk@ripe.net>,
        Nischal M Piratla <nischal@engr.colostate.edu>
From: Al Morton <acmorton@att.com>
Subject: Re: [ippm] New metric for packet reordering.
Cc: ippm@advanced.org, Anura Jayasumana <Anura.Jayasumana@Colostate.edu>,
        Abhijit A Bare <abhijit@CS.ColoState.EDU>
In-Reply-To: <Pine.LNX.4.44.0302171151160.4222-100000@x49.ripe.net>
References: <3E4D20C4.8070605@engr.colostate.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: Mon, 17 Feb 2003 09:27:27 -0500

At 11:57 AM 02/17/2003 +0100, Henk Uijterwaal (RIPE-NCC) wrote:
>Nischal,
>
>...
>
>2. Can you include the same examples as in the other reordering metrics
>    so one can compare the algorithms?
>
>Henk

Case b, packet loss (1,2,4,5,6,7) is sufficient for comparison.
No reordered packets arrive, yet this metric reports reordering
density.  The existing metrics maintain orthogonality between
loss and reordering. Perhaps this algorithm would be better
characterized as a receiver buffer occupation function.

Al



_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Mon Feb 17 18:10:49 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03619
	for <ippm-archive@lists.ietf.org>; Mon, 17 Feb 2003 18:10:49 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1HNC4CN008032;
	Mon, 17 Feb 2003 18:12:04 -0500
Received: from goku.engr.colostate.edu (goku.engr.colostate.edu [129.82.224.16])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1HNB7CN008008
	for <ippm@advanced.org>; Mon, 17 Feb 2003 18:11:08 -0500
Received: from engr.colostate.edu (zurix.engr.colostate.edu [129.82.224.183])
	by goku.engr.colostate.edu (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h1HNAgKQ025664;
	Mon, 17 Feb 2003 16:10:43 -0700 (MST)
Message-ID: <3E516CC6.5010002@engr.colostate.edu>
From: Nischal M Piratla <nischal@engr.colostate.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Henk Uijterwaal (RIPE-NCC)" <henk@ripe.net>
CC: ippm@advanced.org, Anura Jayasumana <Anura.Jayasumana@Colostate.edu>,
        Abhijit A Bare <abhijit@CS.ColoState.EDU>
Subject: Re: [ippm] New metric for packet reordering.
References: <Pine.LNX.4.44.0302171151160.4222-100000@x49.ripe.net>
Content-Type: multipart/alternative;
 boundary="------------070501060607000802040106"
X-ECS-MailScanner: Found to be clean
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: Mon, 17 Feb 2003 16:14:14 -0700


--------------070501060607000802040106
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit

  Dear Henk Uijterwaal,

Please find the answers below:

1. If I understand the algorithm correctly, then it needs an array
   in_buffer[N] with N the number of packets in a stream. This is not
   very practical, when I make a VoIP phonecall, then I never know how
   long it is going to last in advance and thus how I should dimension
   this array

in_buffer (N): The dimension of this array is DT. DT is the threshold 
after which the packet is considered useless or lost. This array 
dimension can be chosen based on the application. . For example in VoIP, 
if a packet arrives after 150msec (in theory) it can be discarded. Based 
on the codec selection, we can determine the packet size, max delay and 
in turn the value of DT after which the packet is rendered useless. For 
a TCP connection this DT value would not exceed the number of packets in 
the TCP send queue. Thus, it is not necessary to know the number of 
packets before hand. Dt imposes a limit on when one should consider a 
packet to be lost.

2. Can you include the same examples as in the other reordering metrics
   so one can compare the algorithms?

I have picked one example from Al Morton's draft on reorder metric here. 
I hope it is ok to use the text from the draft 
<draft-ietf-ippm-reordering-01.txt>

"...Table 1 Example with Packet 4 Reordered,
   Sending order(SrcNum@Src): 1,2,3,4,5,6,7,8,9,10
   SrcNum       Src     Dst                     Dst     Posit.  Late
   @Dst NextExp Time    Time    Delay   IPDV    Order   Offset  Time	 
   1     1       0      68      68              1				
    2     2      20      88      68       0      2
    3     3      40     108      68       0      3
    5     4      80     148      68     -82      4
    6     6     100     168      68       0      5
    7     7     120     188      68       0      6
    8     8     140     208      68       0      7
    4     9      60     210     150      82      8      4       62
    9     9     160     228      68       0      9
   10    10     180     248      68       0     10

   Each column gives the following information:

   SrcNum   Packet sequence number at the Source.
   NextExp   The value of NextExp when the packet arrived(before
   update).
   SrcTime  Packet time stamp at the Source, ms.
   DstTime  Packet time stamp at the Destination, ms.
   Delay    1-way delay of the packet, ms.
   IPDV     IP Packet Delay Variation, ms
            IPDV = Delay(SrcNum)-Delay(SrcNum-1)..."
   

Reorder Density for the above example:

  SrcNum       
   @Dst NextExp  Displacement	 Frequency
   1     1          0              F[0] = 1				
    2     2          0              F[0]++
    3     3          0              F[0]++
    5     4          1              F[1] = 1
    6     4          2              F[2] = 1
    7     4          3              F[3] = 1
    8     4          4              F[4] = 1
    4     4          0              F[0]++  
    9     9          0              F[0]++
   10    10          0              F[0]++

Normalized F[i] for all i: F[0] = 0.6, F[1] = 0.1, F[2] = 0.1, F[3] = 0.1, F[4] = 0.1
we 
In this case, if we can set DT = 3, then the table will look like this:

  SrcNum       
   @Dst Expected  Displacement	 Frequency
   1     1          0              F[0] = 1				
    2     2          0              F[0]++
    3     3          0              F[0]++
    5     4          1              F[1] = 1
    6     4          2              F[2] = 1
    7     4          3              F[3] = 1
    8     4          0              F[0]++       { after the current packet's (8) arrival, packet '4' is rendered useless!}
    4     9          0              F[0]++       { should we count this as F[0] occurence?)
    9     9          0              F[0]++
   10    10          0              F[0]++

Normalized F[i] for all i: F[0] = 0.7, F[1] = 0.1, F[2] = 0.1, F[3] = 0.1


Other examples in current metrics are almost similar. However, there are 
no examples with packet duplication. Here is one for the metric 
proposed. (Note: Packet '5' is duplicated.)

  SrcNum       
   @Dst NextExp  Displacement	 Frequency
   1     1          0              F[0] = 1				
    2     2          0              F[0]++
    3     3          0              F[0]++
    5     4          1              F[1] = 1
    6     4          2              F[2] = 1
    7     4          3              F[3] = 1
    8     4          4              F[4] = 1
    4     4          0              F[0]++
    5    9          0              F[0]++    
    9     9          0              F[0]++
   

Normalized F[i] for all i: F[0] = 0.6, F[1] = 0.1, F[2] = 0.1, F[3] = 0.1, F[4] = 0.1. 


At the arrival of a duplicate packet the buffer occupancy is held the 
same as the duplicate packet will be discarded and the contents of the 
buffer remain.
If you need more examples or explanation, please feel free to send us an 
email.

Thanks,
Nischal Piratla

******************************************
Research Assistant
Computer Networking Research Laboratory
Department of Electrical and Computer Eng.
Colorado State University,
Fort Collins, CO 80523
Voice: +1 970-491-7974
Fax:   +1 970-491-2249
http://www.engr.colostate.edu/~nischal
*******************************************



Henk Uijterwaal (RIPE-NCC) wrote:

>Nischal,
>
>  
>
>>We have come up with a new metric to measure packet reordering. We have
>>posted a ID and here is the link:
>>
>>http://www.ietf.org/internet-drafts/draft-jayasumana-reorder-density-00.txt
>>
>>This draft may interest you all. Please feel free to send any
>>comments/suggestions.
>>    
>>
>
>1. If I understand the algorithm correctly, then it needs an array
>   in_buffer[N] with N the number of packets in a stream. This is not
>   very practical, when I make a VoIP phonecall, then I never know how
>   long it is going to last in advance and thus how I should dimension
>   this array.
>
>2. Can you include the same examples as in the other reordering metrics
>   so one can compare the algorithms?
>
>Henk
>
>
>------------------------------------------------------------------------------
>Henk Uijterwaal                             Email: henk.uijterwaal@ripe.net
>RIPE Network Coordination Centre            WWW: http://www.ripe.net/home/henk
>P.O.Box 10096          Singel 258           Phone: +31.20.5354414
>1001 EB Amsterdam      1016 AB Amsterdam    Fax: +31.20.5354445
>The Netherlands        The Netherlands      Mobile: +31.6.55861746
>------------------------------------------------------------------------------
>
>That problem that we weren't having yesterday, is it better? (Big ISP NOC)
>

--------------070501060607000802040106
Content-Type: text/html; charset=US-ASCII
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
 Dear Henk Uijterwaal,<br>
<br>
Please find the answers below:<br>
<pre wrap="">1. If I understand the algorithm correctly, then it needs an array
   in_buffer[N] with N the number of packets in a stream. This is not
   very practical, when I make a VoIP phonecall, then I never know how
   long it is going to last in advance and thus how I should dimension
   this array</pre>
in_buffer (N): The dimension of this array is DT. DT is the threshold after
which the packet is considered useless or lost. This array dimension can
be chosen based on the application. . For example in VoIP, if a packet arrives
after 150msec (in theory) it can be discarded. Based on the codec selection,
we can determine the packet size, max delay and in turn the value of DT after
which the packet is rendered useless. For a TCP connection this DT value
would not exceed the number of packets in the TCP send queue. Thus, it is
not necessary to know the number of packets before hand. Dt imposes a limit
on when one should consider a packet to be lost.<br>
 <br>
<pre wrap="">2. Can you include the same examples as in the other reordering metrics
   so one can compare the algorithms?</pre>
I have picked one example from Al Morton's draft on reorder metric here.
I hope it is ok to use the text from the draft &lt;draft-ietf-ippm-reordering-01.txt&gt;<br>
 <br>
 
<pre>"...Table 1 Example with Packet 4 Reordered,
   Sending order(SrcNum@Src): 1,2,3,4,5,6,7,8,9,10
   SrcNum       Src     Dst                     Dst     Posit.  Late
   @Dst NextExp Time    Time    Delay   IPDV    Order   Offset  Time	 
   &nbsp;1     1       0      68      68              1				
    2     2      20      88      68       0      2
    3     3      40     108      68       0      3
    5     4      80     148      68     -82      4
    6     6     100     168      68       0      5
    7     7     120     188      68       0      6
    8     8     140     208      68       0      7
    4     9      60     210     150      82      8      4       62
    9     9     160     228      68       0      9
   10    10     180     248      68       0     10

   Each column gives the following information:

   SrcNum   Packet sequence number at the Source.
   NextExp   The value of NextExp when the packet arrived(before
   update).
   SrcTime  Packet time stamp at the Source, ms.
   DstTime  Packet time stamp at the Destination, ms.
   Delay    1-way delay of the packet, ms.
   IPDV     IP Packet Delay Variation, ms
            IPDV = Delay(SrcNum)-Delay(SrcNum-1)..."
   </pre>
 Reorder Density for the above example:<br>
 
<pre>  SrcNum       
   @Dst NextExp  Displacement	 Frequency
   &nbsp;1     1          0              F[0] = 1				
    2     2          0              F[0]++
    3     3          0              F[0]++
    5     4          1              F[1] = 1
    6     4          2              F[2] = 1
    7     4          3              F[3] = 1
    8     4          4              F[4] = 1
    4     4          0              F[0]++  
    9     9          0              F[0]++
   10    10          0              F[0]++

Normalized F[i] for all i: F[0] = 0.6, F[1] = 0.1, F[2] = 0.1, F[3] = 0.1, F[4] = 0.1
we 
In this case, if we can set DT = 3, then the table will look like this:

  SrcNum       
   @Dst Expected  Displacement	 Frequency
   &nbsp;1     1          0              F[0] = 1				
    2     2          0              F[0]++
    3     3          0              F[0]++
    5     4          1              F[1] = 1
    6     4          2              F[2] = 1
    7     4          3              F[3] = 1
    8     4          0              F[0]++       { after the current packet's (8) arrival, packet '4' is rendered useless!}
    4     9          0              F[0]++       { should we count this as F[0] occurence?)
    9     9          0              F[0]++
   10    10          0              F[0]++

Normalized F[i] for all i: F[0] = 0.7, F[1] = 0.1, F[2] = 0.1, F[3] = 0.1

</pre>
 
<p>Other examples in current metrics are almost similar. However, there are
no examples with packet duplication. Here is one for the metric proposed.
(Note: Packet '5' is duplicated.)<br>
 </p>
 
<pre>  SrcNum       
   @Dst NextExp  Displacement	 Frequency
   &nbsp;1     1          0              F[0] = 1				
    2     2          0              F[0]++
    3     3          0              F[0]++
    5     4          1              F[1] = 1
    6     4          2              F[2] = 1
    7     4          3              F[3] = 1
    8     4          4              F[4] = 1
    4     4          0              F[0]++
    5&nbsp;    9          0              F[0]++    
    9     9          0              F[0]++
   </pre>
 
<pre>Normalized F[i] for all i: F[0] = 0.6, F[1] = 0.1, F[2] = 0.1, F[3] = 0.1, F[4] = 0.1. 

</pre>
  
<p>At the arrival of a duplicate packet the buffer occupancy is held the same
as the duplicate packet will be discarded and the contents of the buffer remain.<br>
 If you need more examples or explanation, please feel free to send us an
email.</p>
 Thanks,<br>
 Nischal Piratla
<pre class="moz-signature" cols="$mailwrapcol">******************************************
Research Assistant
Computer Networking Research Laboratory
Department of Electrical and Computer Eng.
Colorado State University,
Fort Collins, CO 80523
Voice: +1 970-491-7974
Fax:   +1 970-491-2249
<a class="moz-txt-link-freetext" href="http://www.engr.colostate.edu/~nischal">http://www.engr.colostate.edu/~nischal</a>
*******************************************</pre>
<br>
<br>
Henk Uijterwaal (RIPE-NCC) wrote:<br>
<blockquote type="cite"
 cite="midPine.LNX.4.44.0302171151160.4222-100000@x49.ripe.net">
  <pre wrap="">Nischal,

  </pre>
  <blockquote type="cite">
    <pre wrap="">We have come up with a new metric to measure packet reordering. We have
posted a ID and here is the link:

<a class="moz-txt-link-freetext" href="http://www.ietf.org/internet-drafts/draft-jayasumana-reorder-density-00.txt">http://www.ietf.org/internet-drafts/draft-jayasumana-reorder-density-00.txt</a>

This draft may interest you all. Please feel free to send any
comments/suggestions.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
1. If I understand the algorithm correctly, then it needs an array
   in_buffer[N] with N the number of packets in a stream. This is not
   very practical, when I make a VoIP phonecall, then I never know how
   long it is going to last in advance and thus how I should dimension
   this array.

2. Can you include the same examples as in the other reordering metrics
   so one can compare the algorithms?

Henk


------------------------------------------------------------------------------
Henk Uijterwaal                             Email: <a class="moz-txt-link-abbreviated" href="mailto:henk.uijterwaal@ripe.net">henk.uijterwaal@ripe.net</a>
RIPE Network Coordination Centre            WWW: <a class="moz-txt-link-freetext" href="http://www.ripe.net/home/henk">http://www.ripe.net/home/henk</a>
P.O.Box 10096          Singel 258           Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam    Fax: +31.20.5354445
The Netherlands        The Netherlands      Mobile: +31.6.55861746
------------------------------------------------------------------------------

That problem that we weren't having yesterday, is it better? (Big ISP NOC)</pre>
</blockquote>
</body>
</html>

--------------070501060607000802040106--

_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Tue Feb 18 01:05:18 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09892
	for <ippm-archive@lists.ietf.org>; Tue, 18 Feb 2003 01:05:18 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1I684CN018571;
	Tue, 18 Feb 2003 01:08:04 -0500
Received: from basie.internet2.edu (basie.internet2.edu [207.75.164.22])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1I67TCN018555
	for <ippm@advanced.org>; Tue, 18 Feb 2003 01:07:30 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by basie.internet2.edu (Postfix) with ESMTP
	id CF9517B493; Tue, 18 Feb 2003 01:07:29 -0500 (EST)
Received: from localhost (localhost [127.0.0.1])
	by basie.internet2.edu (Postfix) with ESMTP
	id CA51A7B484; Tue, 18 Feb 2003 01:07:28 -0500 (EST)
To: Nischal M Piratla <nischal@engr.colostate.edu>
Cc: ippm@advanced.org
Subject: Re: [ippm] New metric for packet reordering.
References: <3E4D20C4.8070605@engr.colostate.edu>
From: stanislav shalunov <shalunov@internet2.edu>
In-Reply-To: <3E4D20C4.8070605@engr.colostate.edu>
Message-ID: <87heb2ktpc.fsf@cain.internet2.edu>
Lines: 22
X-Mailer: Gnus v5.7/Emacs 20.4
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS 0.3.12pre8
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: 18 Feb 2003 01:07:27 -0500

Nischal,

I seem to be having a difficulty interpreting your algorithm as
presented in the internet-draft.

For example, I am looking at the following:

>             If (D < DT)
>             /*Store arrived packet in buffer.*/
>                D = D + 1;
>             Else
>                [...]

Is the comment an actual comment or a pseudocode statement?

Would it perhaps be convenient for you to provide some runnable C code
that we could play with to better understand your definition?

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

"Which one is worse?  Both are worse."		-- V. I. Lenin
_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Tue Feb 18 15:41:11 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07844
	for <ippm-archive@lists.ietf.org>; Tue, 18 Feb 2003 15:41:10 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1IKf5CN009643;
	Tue, 18 Feb 2003 15:41:05 -0500
Received: from hotmail.com (f100.sea2.hotmail.com [207.68.165.100])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1IKebCN009624
	for <ippm@advanced.org>; Tue, 18 Feb 2003 15:40:37 -0500
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 18 Feb 2003 12:40:36 -0800
Received: from 193.116.20.220 by sea2fd.sea2.hotmail.msn.com with HTTP;
	Tue, 18 Feb 2003 20:40:36 GMT
X-Originating-IP: [193.116.20.220]
From: "gab.seun jones.ewulomi" <seun_ewulomi@hotmail.com>
To: ippm@advanced.org
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F1005kOSIJC2dKvbahE000392d7@hotmail.com>
X-OriginalArrivalTime: 18 Feb 2003 20:40:36.0803 (UTC) FILETIME=[FDCA0130:01C2D78D]
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
Subject: [ippm] statistics techniques
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: Tue, 18 Feb 2003 20:40:36 +0000

Hi Guys,

My apologies on the somewhat easy question

Im doing a active test just using ping(via script). I have the script to 
ping a device(100 counts) then send it to a file.

My main question is what will give a more accurate rtt.

1)taking the mean of all 100 pings
2)median
3)mode

Just want techniques on what others would use and why

regards,
gab

_________________________________________________________________
Surf together with new Shared Browsing 
http://join.msn.com/?page=features/browse&pgmarket=en-gb&XAPID=74&DI=1059

_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Tue Feb 18 15:45:05 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08008
	for <ippm-archive@lists.ietf.org>; Tue, 18 Feb 2003 15:45:05 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1IKl4CN009871;
	Tue, 18 Feb 2003 15:47:04 -0500
Received: from basie.internet2.edu (basie.internet2.edu [207.75.164.22])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1IKl0CN009855
	for <ippm@advanced.org>; Tue, 18 Feb 2003 15:47:00 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by basie.internet2.edu (Postfix) with ESMTP
	id 37CCF7B4E1; Tue, 18 Feb 2003 15:47:00 -0500 (EST)
Received: from localhost (localhost [127.0.0.1])
	by basie.internet2.edu (Postfix) with ESMTP
	id 4FA647B4DA; Tue, 18 Feb 2003 15:46:59 -0500 (EST)
To: "gab.seun jones.ewulomi" <seun_ewulomi@hotmail.com>
Cc: ippm@advanced.org
Subject: Re: [ippm] statistics techniques
References: <F1005kOSIJC2dKvbahE000392d7@hotmail.com>
From: stanislav shalunov <shalunov@internet2.edu>
In-Reply-To: <F1005kOSIJC2dKvbahE000392d7@hotmail.com>
Message-ID: <87vfzhmi4d.fsf@cain.internet2.edu>
Lines: 21
X-Mailer: Gnus v5.7/Emacs 20.4
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS 0.3.12pre8
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: 18 Feb 2003 15:46:58 -0500

"gab.seun jones.ewulomi" <seun_ewulomi@hotmail.com> writes:

> Im doing a active test just using ping(via script). I have the script to 
> ping a device(100 counts) then send it to a file.
> 
> My main question is what will give a more accurate rtt.
> 
> 1)taking the mean of all 100 pings
> 2)median
> 3)mode

How can you compute the mean when some of the values are close to
infinity (losses)?

Median and minimum make a lot more sense.

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

A fanatic is one who can't change his mind and won't change the
subject.                                   -- Winston Churchill
_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Tue Feb 18 17:33:43 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10355
	for <ippm-archive@lists.ietf.org>; Tue, 18 Feb 2003 17:33:43 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1IMU4CN013782;
	Tue, 18 Feb 2003 17:30:04 -0500
Received: from smtp.noos.fr (nan-smtp-04.noos.net [212.198.2.73])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1IMTXCO013733
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL)
	for <ippm@advanced.org>; Tue, 18 Feb 2003 17:29:34 -0500
Received: (qmail 30384814 invoked by uid 0); 18 Feb 2003 22:29:32 -0000
Received: from unknown (HELO LIP60MU1PINK59) ([212.198.206.108])
          (envelope-sender <salamat@rp.lip6.fr>)
          by 212.198.2.73 (qmail-ldap-1.03) with SMTP
          for <shalunov@internet2.edu>; 18 Feb 2003 22:29:32 -0000
From: =?iso-8859-1?Q?Kav=E9_Salamatian?= <salamat@rp.lip6.fr>
To: "stanislav shalunov" <shalunov@internet2.edu>,
        "gab.seun jones.ewulomi" <seun_ewulomi@hotmail.com>
Cc: <ippm@advanced.org>
Subject: RE: [ippm] statistics techniques
Message-ID: <EBELLEFJANFIHFPEMGPCGEMNCMAA.salamat@rp.lip6.fr>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <87vfzhmi4d.fsf@cain.internet2.edu>
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: Tue, 18 Feb 2003 23:28:46 +0100
Content-Transfer-Encoding: 8bit

>> Im doing a active test just using ping(via script). I have the script to
>> ping a device(100 counts) then send it to a file.
>>
>> My main question is what will give a more accurate rtt.
>>
>> 1)taking the mean of all 100 pings
>> 2)median
>> 3)mode

>How can you compute the mean when some of the values are close to
>infinity (losses)?
This might not be a problem. There is a lot of methods for dealing with
missing values. However there is a more fundamental question. What do you
expect from the mean or the median or the mode ? Sometimes trivial questions
are the most difficult to answer. For example suppose that you have measure
the rtt for 100 counts, maybe you are searching for a formula f(.) that will
combine the results obtained in the past measurements to predict the rtt in
measurement 101. If this is your goal clearly the mean or mode or median is
not the best estimator. If your problem is to find a parametric
representation of the rtt distribution that have as parameter the mean,
please define initially what a prior parametric structure are you supposing.
If your problem is something else please define it.

Sometime, when I read some papers or draft in Internet measurement it remind
me of the following oriental story:
Somebody had lost his key in a dark yard but he was wandering about the key
in the room. A fellow ask him: you have lost the key in the yard but you are
searching it here. The guy answer: but there is light here and the yard is
dark....

Regards

Kavé Salamatian
Associate Professor, LIP6-UPMC

_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Tue Feb 18 18:04:22 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10854
	for <ippm-archive@lists.ietf.org>; Tue, 18 Feb 2003 18:04:22 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1IN75CN014985;
	Tue, 18 Feb 2003 18:07:05 -0500
Received: from basie.internet2.edu (basie.internet2.edu [207.75.164.22])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1IN6sCN014969
	for <ippm@advanced.org>; Tue, 18 Feb 2003 18:06:54 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by basie.internet2.edu (Postfix) with ESMTP
	id 2B4AB7B4E1; Tue, 18 Feb 2003 18:06:54 -0500 (EST)
Received: from localhost (localhost [127.0.0.1])
	by basie.internet2.edu (Postfix) with ESMTP
	id 144B27B4E3; Tue, 18 Feb 2003 18:06:53 -0500 (EST)
To: Kavé Salamatian <salamat@rp.lip6.fr>
Cc: ippm@advanced.org
Subject: Re: [ippm] statistics techniques
References: <EBELLEFJANFIHFPEMGPCGEMNCMAA.salamat@rp.lip6.fr>
From: stanislav shalunov <shalunov@internet2.edu>
In-Reply-To: <EBELLEFJANFIHFPEMGPCGEMNCMAA.salamat@rp.lip6.fr>
Message-ID: <87isvhmbn9.fsf@cain.internet2.edu>
Lines: 29
X-Mailer: Gnus v5.7/Emacs 20.4
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS 0.3.12pre8
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: 18 Feb 2003 18:06:50 -0500

I can not speak for the original poster, but since you appear to be
addressing me while (not?) answering his questions:

1. The values of delay for lost packets are not ``missing''.  They are
   potentially very large unknowable values.  That packet that I sent
   last year and that appeared to be lost might still be delivered one
   day.

2. The necessity for aggregation is more about human consumption of
   data than about using it to predict anything or to compute
   parameters of a distribution (there's no distribution).  Minimum
   (or something close to it) is meaningful in itself: given enough
   measurements, it's a reasonable guess of propagation delay.  Median
   is useful for several reasons:

   a. It reflects the whole sample.

   b. It is well-defined for samples where more than 50% of packets
      arrived during the measurement (thus making it widely usable).

   c. It is robust.

   d. It is easy to understand.

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

A fanatic is one who can't change his mind and won't change the
subject.                                   -- Winston Churchill
_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Wed Feb 19 07:26:54 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21636
	for <ippm-archive@lists.ietf.org>; Wed, 19 Feb 2003 07:26:53 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1JCS4CN002871;
	Wed, 19 Feb 2003 07:28:04 -0500
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1JCR3CN002725
	for <ippm@advanced.org>; Wed, 19 Feb 2003 07:27:04 -0500
Received: from antares.enst-bretagne.fr (antares.enst-bretagne.fr [192.44.75.8])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h1JCR6W10928;
	Wed, 19 Feb 2003 13:27:06 +0100
Received: from enst-bretagne.fr (taureau-tse.enst-bretagne.fr [192.44.75.100])
	by antares.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h1JCQwa21935;
	Wed, 19 Feb 2003 13:26:58 +0100 (MET)
Message-ID: <3E53775C.7B1F19B@enst-bretagne.fr>
From: Sandrine Vaton <Sandrine.Vaton@enst-bretagne.fr>
X-Mailer: Mozilla 4.75 [fr] (Windows NT 5.0; U)
X-Accept-Language: fr
MIME-Version: 1.0
To: stanislav shalunov <shalunov@internet2.edu>
CC: =?iso-8859-1?Q?Kav=E9?= Salamatian <salamat@rp.lip6.fr>, ippm@advanced.org
Subject: Re: [ippm] statistics techniques
References: <EBELLEFJANFIHFPEMGPCGEMNCMAA.salamat@rp.lip6.fr> <87isvhmbn9.fsf@cain.internet2.edu>
Content-Type: multipart/alternative;
 boundary="------------A219A405EB655A485166653D"
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: Wed, 19 Feb 2003 13:23:56 +0100


--------------A219A405EB655A485166653D
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit



stanislav shalunov a écrit :

> I can not speak for the original poster, but since you appear to be
> addressing me while (not?) answering his questions:
>
> 1. The values of delay for lost packets are not ``missing''.  They are
>    potentially very large unknowable values.  That packet that I sent
>    last year and that appeared to be lost might still be delivered one
>    day.

The word "missing" should be understood in the sense of "unobserved" but
in the sense of "censored". In statistics a model with "censored data" is
a model such that is X>xmax you do not observe X but you anyhow have the
information that X was superior to xmax. This is a classical problem in
the industry for example or in polling. In your case the actual value of
delay is not known when the delay is too big but you know that (delay >
delay_max): this is already some information on the value of the delay and
this should be taken into account in your estimation procedure.

For censored values problems a powerful algorithm is the Expectation
Maximization algorithm. You can also use Baysian techniques to simulate
the value of the delay on the information that the delay is superior to
delay_max. In both cases you suppose a statistical model for your series
of delays and you try to estimate the parameters of that model (mean,
variance, etc...) on the basis of a series of delays.

>
>
> 2. The necessity for aggregation is more about human consumption of
>    data than about using it to predict anything or to compute
>    parameters of a distribution (there's no distribution).  Minimum
>    (or something close to it) is meaningful in itself: given enough
>    measurements, it's a reasonable guess of propagation delay.  Median
>    is useful for several reasons:
>
>    a. It reflects the whole sample.
>
>    b. It is well-defined for samples where more than 50% of packets
>       arrived during the measurement (thus making it widely usable).
>

I do not agree with point b. If only 50% of the packets were delivered and
if you estimate the mean delay as the mean over the packets delivered then
you will strongly underestimate the average delay (you do not take into
account those packets that are not delivered yet but that could be
delivered one day).


>
>    c. It is robust.
>

In what sense?


>
>    d. It is easy to understand.
>
>

Sandrine Vaton
http://perso-info.enst-bretagne.fr/~vaton


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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<p>stanislav shalunov a &eacute;crit :
<blockquote TYPE=CITE>I can not speak for the original poster, but since
you appear to be
<br>addressing me while (not?) answering his questions:
<p>1. The values of delay for lost packets are not ``missing''.&nbsp; They
are
<br>&nbsp;&nbsp; potentially very large unknowable values.&nbsp; That packet
that I sent
<br>&nbsp;&nbsp; last year and that appeared to be lost might still be
delivered one
<br>&nbsp;&nbsp; day.</blockquote>

<p>The word "missing" should be understood in the sense of "unobserved"
but in the sense of "censored". In statistics a model with "censored data"
is a model such that is X>xmax you do not observe X but you anyhow have
the information that X was superior to xmax. This is a classical problem
in the industry for example or in polling. In your case the actual value
of delay is not known when the delay is too big but you know that (delay
> delay_max): this is already some information on the value of the delay
and this should be taken into account in your estimation procedure.
<p>For censored values problems a powerful algorithm is the Expectation
Maximization algorithm. You can also use Baysian techniques to simulate
the value of the delay on the information that the delay is superior to
delay_max. In both cases you suppose a statistical model for your series
of delays and you try to estimate the parameters of that model (mean, variance,
etc...) on the basis of a series of delays.
<blockquote TYPE=CITE>&nbsp;
<p>2. The necessity for aggregation is more about human consumption of
<br>&nbsp;&nbsp; data than about using it to predict anything or to compute
<br>&nbsp;&nbsp; parameters of a distribution (there's no distribution).&nbsp;
Minimum
<br>&nbsp;&nbsp; (or something close to it) is meaningful in itself: given
enough
<br>&nbsp;&nbsp; measurements, it's a reasonable guess of propagation delay.&nbsp;
Median
<br>&nbsp;&nbsp; is useful for several reasons:
<p>&nbsp;&nbsp; a. It reflects the whole sample.
<p>&nbsp;&nbsp; b. It is well-defined for samples where more than 50% of
packets
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; arrived during the measurement (thus
making it widely usable).
<br>&nbsp;</blockquote>

<p><br>I do not agree with point b. If only 50% of the packets were delivered
and if you estimate the mean delay as the mean over the packets delivered
then you will strongly underestimate the average delay (you do not take
into account those packets that are not delivered yet but that could be
delivered one day).
<br>&nbsp;
<blockquote TYPE=CITE>&nbsp;
<br>&nbsp;&nbsp; c. It is robust.
<br>&nbsp;</blockquote>
In what sense?
<br>&nbsp;
<blockquote TYPE=CITE>&nbsp;
<br>&nbsp;&nbsp; d. It is easy to understand.
<br>&nbsp;
<br><a href="http://mailhost.advanced.org/mailman/listinfo/ippm"></a>&nbsp;</blockquote>

<p>Sandrine Vaton
<br><A HREF="http://perso-info.enst-bretagne.fr/~vaton">http://perso-info.enst-bretagne.fr/~vaton</A>
<br>&nbsp;</html>

--------------A219A405EB655A485166653D--

_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Wed Feb 19 22:00:09 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16729
	for <ippm-archive@lists.ietf.org>; Wed, 19 Feb 2003 22:00:09 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1K324CN029293;
	Wed, 19 Feb 2003 22:02:04 -0500
Received: from basie.internet2.edu (basie.internet2.edu [207.75.164.22])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1K31rCN029277
	for <ippm@advanced.org>; Wed, 19 Feb 2003 22:01:53 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by basie.internet2.edu (Postfix) with ESMTP
	id 5D1537B4DD; Wed, 19 Feb 2003 22:01:53 -0500 (EST)
Received: from localhost (localhost [127.0.0.1])
	by basie.internet2.edu (Postfix) with ESMTP
	id 49F1D7B488; Wed, 19 Feb 2003 22:01:52 -0500 (EST)
To: Sandrine Vaton <Sandrine.Vaton@enst-bretagne.fr>
Cc: ippm@advanced.org
Subject: Re: [ippm] statistics techniques
References: <EBELLEFJANFIHFPEMGPCGEMNCMAA.salamat@rp.lip6.fr> <87isvhmbn9.fsf@cain.internet2.edu> <3E53775C.7B1F19B@enst-bretagne.fr>
From: stanislav shalunov <shalunov@internet2.edu>
In-Reply-To: <3E53775C.7B1F19B@enst-bretagne.fr>
Message-ID: <87of57lko2.fsf@cain.internet2.edu>
Lines: 30
X-Mailer: Gnus v5.7/Emacs 20.4
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS 0.3.12pre8
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: 19 Feb 2003 22:01:49 -0500

Sandrine Vaton <Sandrine.Vaton@enst-bretagne.fr> writes:

> The word "missing" should be understood in the sense of "unobserved" but
> in the sense of "censored".

And, if you know that the delay was greater than some value and have
no knowledge of the distribution, what do you do?

> >    Median is useful for several reasons:

> >    b. It is well-defined for samples where more than 50% of packets
> >       arrived during the measurement (thus making it widely usable).
> >
> 
> I do not agree with point b. If only 50% of the packets were
> delivered and if you estimate the mean delay as the mean over the
> packets delivered

Sure.  That's why I talk about _median_, not mean.

> >    c. It is robust.

> In what sense?

It is not significantly affected by small amounts of noise.

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

Sex is the mathematics urge sublimated.                 -- M. C. Reed.
_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Wed Feb 19 23:22:33 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18782
	for <ippm-archive@lists.ietf.org>; Wed, 19 Feb 2003 23:22:33 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1K4P5CN031644;
	Wed, 19 Feb 2003 23:25:05 -0500
Received: from mesa.acns.ColoState.EDU (mesa.acns.colostate.edu [129.82.100.130])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1K4ODCN031625
	for <ippm@advanced.org>; Wed, 19 Feb 2003 23:24:14 -0500
Received: from lamar.colostate.edu (lamar.acns.colostate.edu [129.82.100.75])
	by mesa.acns.ColoState.EDU (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA62394;
	Wed, 19 Feb 2003 21:24:11 -0700
Received: from engr.colostate.edu (res096090.halls.colostate.edu [129.82.96.90] (may be forged)) by lamar.colostate.edu (AIX5.1/8.11.0/8.8.8) with ESMTP id h1K4OAw05248; Wed, 19 Feb 2003 21:24:10 -0700
Message-ID: <3E5458CF.9040802@engr.colostate.edu>
From: Nischal M Piratla <nischal@engr.colostate.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Al Morton <acmorton@att.com>
CC: "Henk Uijterwaal (RIPE-NCC)" <henk@ripe.net>, ippm@advanced.org,
        Anura
 Jayasumana <Anura.Jayasumana@Colostate.edu>,
        Abhijit A Bare
 <abhijit@CS.ColoState.EDU>
Subject: Re: [ippm] New metric for packet reordering.
References: <3E4D20C4.8070605@engr.colostate.edu> <5.1.0.14.0.20030217091903.02c3eda0@135.16.74.2>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: Wed, 19 Feb 2003 21:25:51 -0700
Content-Transfer-Encoding: 7bit

Dear Al Morton,

Your question gives rise to a very interesting issue - the orthogonality
of reordering and other phenomena, including losses and duplication of
packets.

1) Loss: With the sequence (1,2,4,5,6,7) it is possible to conclude that
packet 3 is lost only if we are not expecting any more packets in the
sequence. The key question here is "When should a packet be considered
lost?" When it does not arrive during a certain time threshold, or when
the packet does not arrive till measurements are completed? Stated
differently, is a packet considered lost if it does not arrive within
some useful time period, or is it considered lost until it arrives? From 
the point of view of higher level protocols or applications, the former
is desirable. Also, in case of continuous monitoring of reorder in a
network, latter is not possible. Considering a packet to be lost if it
does not arrive during the measurement period does not necessarily make
loss and reordering measurements orthogonal. After debating along these
lines and considering the usefulness of the metric, we decided to move
ahead of any packet that did not arrive within a given time or threshold
(DT). [ In fact, considering packets that do not arrive within the
measurement periods equivalent to starting with DT= no of packets
arriving in measurement period, and decreasing DT by 1 with each
arriving packet. ]

Another interesting question is whether we should  consider (arrived
but) dropped packets as lost packets ?

2) Duplication: These are the packets that are duplicated due to
whatever reason. Should we have a reorder metric that is orthogonal to
it as well? It is possible to argue that reordering has nothing to do 
with duplication and these packets should not be taken into 
consideration. If we consider duplicate packet as a reordered packet, 
the reorder metric is not the same for sequences with duplication and 
sequences without duplication.
Consider the example: (1,2,3,2,4,5,6)
If we consider packet '2' second occurrence as reordering then the
orthogonality between duplicate packet and reorder is not maintained.


When we were thinking about these issues, we also considered Van Paxson 
& etal.'s RFC 2330. I am quoting the requirements that they stated for 
the performance metrics

"+ The metrics must be concrete and well-defined,
+ A methodology for a metric should have the property that it is
repeatable: if the methodology is used multiple times under
identical conditions, the same measurements should result in the
same measurements.
+ The metrics must exhibit no bias for IP clouds implemented with
identical technology,
+ The metrics must exhibit understood and fair bias for IP clouds
implemented with non-identical technology,
+ The metrics must be useful to users and providers in understanding
the performance they experience or provide,
+ The metrics must avoid inducing artificial performance goals."

We thought of the usefulness as one important criteria. Till recently,
we had only % reordering and as the example in the draft indicated the
definition was not concrete (and ambiguous) and hence the usefulness was 
very limited.

Lack of a concrete definition also makes it difficult to reproduce the
results. I hope this answers your query. Please feel free to send any
additional comments/suggestions.
Thank you,
Nischal Piratla


Al Morton wrote:
> At 11:57 AM 02/17/2003 +0100, Henk Uijterwaal (RIPE-NCC) wrote:
> 
>> Nischal,
>>
>> ...
>>
>> 2. Can you include the same examples as in the other reordering metrics
>>    so one can compare the algorithms?
>>
>> Henk
> 
> 
> Case b, packet loss (1,2,4,5,6,7) is sufficient for comparison.
> No reordered packets arrive, yet this metric reports reordering
> density.  The existing metrics maintain orthogonality between
> loss and reordering. Perhaps this algorithm would be better
> characterized as a receiver buffer occupation function.
> 
> Al
> 
> 


_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Wed Feb 19 23:30:19 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18866
	for <ippm-archive@lists.ietf.org>; Wed, 19 Feb 2003 23:30:18 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1K4X4CN032012;
	Wed, 19 Feb 2003 23:33:04 -0500
Received: from mesa.acns.ColoState.EDU (mesa.acns.colostate.edu [129.82.100.130])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1K4WGCN031980
	for <ippm@advanced.org>; Wed, 19 Feb 2003 23:32:17 -0500
Received: from lamar.colostate.edu (lamar.acns.colostate.edu [129.82.100.75])
	by mesa.acns.ColoState.EDU (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA87454;
	Wed, 19 Feb 2003 21:32:14 -0700
Received: from engr.colostate.edu (res096090.halls.colostate.edu [129.82.96.90] (may be forged)) by lamar.colostate.edu (AIX5.1/8.11.0/8.8.8) with ESMTP id h1K4WDw168992; Wed, 19 Feb 2003 21:32:13 -0700
Message-ID: <3E545AB2.1080108@engr.colostate.edu>
From: Nischal M Piratla <nischal@engr.colostate.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: stanislav shalunov <shalunov@internet2.edu>
CC: ippm@advanced.org, Anura Jayasumana <Anura.Jayasumana@Colostate.edu>,
        Abhijit A Bare <abhijit@CS.ColoState.EDU>
Subject: RE: [ippm] New metric for packet reordering
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: Wed, 19 Feb 2003 21:33:54 -0700
Content-Transfer-Encoding: 7bit

Stanislav,
Please find the link of C code for reorder density computation:

http://www.engr.colostate.edu/ece/Research/cnrl/code/RD.c

Feel free to send any more comments.
- Nischal

-------- Original Message --------
 >Subject: Re: [ippm] New metric for packet reordering.
 >Date: 18 Feb 2003 01:07:27 -0500
 >From: stanislav shalunov <shalunov@internet2.edu>
 >To: Nischal M Piratla <nischal@engr.colostate.edu>
 >CC: ippm@advanced.org
 >References: <3E4D20C4.8070605@engr.colostate.edu>
 >
 >Nischal,
 >
 >I seem to be having a difficulty interpreting your algorithm as
 >presented in the internet-draft.
 >
 >For example, I am looking at the following:
 >
 >
 >
 >            If (D < DT)
 >            /*Store arrived packet in buffer.*/
 >               D = D + 1;
 >            Else
 >               [...]
 >
 >
 >Is the comment an actual comment or a pseudocode statement?
 >
 >Would it perhaps be convenient for you to provide some runnable C code
 >that we could play with to better understand your definition?
 >
 >--
 >Stanislav Shalunov		http://www.internet2.edu/~shalunov/
 >
 >"Which one is worse?  Both are worse."		-- V. I. Lenin

_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Thu Feb 20 06:01:38 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07116
	for <ippm-archive@lists.ietf.org>; Thu, 20 Feb 2003 06:01:38 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1KB24CN008973;
	Thu, 20 Feb 2003 06:02:04 -0500
Received: from birch.ripe.net (birch.ripe.net [193.0.1.96])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1KB1lCN008956
	for <ippm@advanced.org>; Thu, 20 Feb 2003 06:01:48 -0500
Received: from x49.ripe.net (x49.ripe.net [193.0.1.49])
	by birch.ripe.net (8.12.5/8.11.6) with ESMTP id h1KB1lAq018228;
	Thu, 20 Feb 2003 12:01:47 +0100
Received: from localhost (henk@localhost)
	by x49.ripe.net (8.12.4/8.12.6) with ESMTP id h1KB1jdL022045;
	Thu, 20 Feb 2003 12:01:46 +0100
X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs
From: "Henk Uijterwaal (RIPE-NCC)" <henk@ripe.net>
To: Nischal M Piratla <nischal@engr.colostate.edu>
cc: Al Morton <acmorton@att.com>, <ippm@advanced.org>,
        Anura Jayasumana <Anura.Jayasumana@Colostate.edu>,
        Abhijit A Bare <abhijit@CS.ColoState.EDU>
Subject: Re: [ippm] New metric for packet reordering.
In-Reply-To: <3E5458CF.9040802@engr.colostate.edu>
Message-ID: <Pine.LNX.4.44.0302201153070.21091-100000@x49.ripe.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: Thu, 20 Feb 2003 12:01:45 +0100 (CET)

Nischal,

> 1) Loss: With the sequence (1,2,4,5,6,7) it is possible to conclude that
> packet 3 is lost only if we are not expecting any more packets in the
> sequence. The key question here is "When should a packet be considered
> lost?" When it does not arrive during a certain time threshold, or when
> the packet does not arrive till measurements are completed?

Time threshold, with the limit set by the application (and can be set to
infinite).  The problem is when an application asks for a resend, if this
happens after (say) 3 packets, then ( 1, 2, 4, 5, 6, 7, 3, 8) is as
interesting as (1, 2, 4, 5, 6, 7, 8).

> 2) Duplication: These are the packets that are duplicated due to
> whatever reason. Should we have a reorder metric that is orthogonal to
> it as well?

Yes, duplication is different from reordering.  If packets are duplicated,
then most applications will ignore the second copy, this doesn't take any
CPU cycles.  Reordering means that the packets have to be put back into
order, this does require effort by the application.

Henk


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

That problem that we weren't having yesterday, is it better? (Big ISP NOC)


_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Thu Feb 20 09:38:33 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15873
	for <ippm-archive@lists.ietf.org>; Thu, 20 Feb 2003 09:38:33 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1KEf4CN015262;
	Thu, 20 Feb 2003 09:41:05 -0500
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1KEeiCN015236
	for <ippm@advanced.org>; Thu, 20 Feb 2003 09:40:44 -0500
Received: from antares.enst-bretagne.fr (antares.enst-bretagne.fr [192.44.75.8])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h1KEeor09216
	for <ippm@advanced.org>; Thu, 20 Feb 2003 15:40:50 +0100
Received: from enst-bretagne.fr (taureau-tse.enst-bretagne.fr [192.44.75.100])
	by antares.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h1KEefa21215
	for <ippm@advanced.org>; Thu, 20 Feb 2003 15:40:41 +0100 (MET)
Message-ID: <3E54E832.5BA51C3B@enst-bretagne.fr>
From: Sandrine Vaton <Sandrine.Vaton@enst-bretagne.fr>
X-Mailer: Mozilla 4.75 [fr] (Windows NT 5.0; U)
X-Accept-Language: fr
MIME-Version: 1.0
To: ippm@advanced.org
Subject: [Fwd: [ippm] statistics techniques]
Content-Type: multipart/mixed;
 boundary="------------3A76D79B54EDA823D4F14E2F"
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: Thu, 20 Feb 2003 15:37:38 +0100

Il s'agit d'un message multivolet au format MIME.
--------------3A76D79B54EDA823D4F14E2F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



--------------3A76D79B54EDA823D4F14E2F
Content-Type: message/rfc822
Content-Disposition: inline

X-Mozilla-Status2: 00000000
Message-ID: <3E5379E6.DC1A251C@enst-bretagne.fr>
Date: Wed, 19 Feb 2003 13:34:47 +0100
From: Sandrine Vaton <Sandrine.Vaton@enst-bretagne.fr>
X-Mailer: Mozilla 4.75 [fr] (Windows NT 5.0; U)
X-Accept-Language: fr
MIME-Version: 1.0
To: stanislav shalunov <shalunov@internet2.edu>
Subject: Re: [ippm] statistics techniques
References: <F1005kOSIJC2dKvbahE000392d7@hotmail.com> <87vfzhmi4d.fsf@cain.internet2.edu>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

I suggest that you enrich your model as follows:

1/ the packet can be lost (with probability p) or delivered with probability
(1-p)
2/ if the packet is in the second class (the packets that have been delivered
or that will be delivered one day) then the rtt is a random variable whose
probability density function is f(x) (for example an exponential distribution
with mean 1/lambda). The domain of definition of f(x) being the real positive
line.

If you are in the second class then it is possible that the packet has not yet
arrived because the observation window is of finite size but you have the
information that rtt>rtt_max and this information should be taken into account
in your estimation procedure.

Sandrine Vaton
http://perso-info.enst-bretagne.fr/~vaton

stanislav shalunov a écrit :

> "gab.seun jones.ewulomi" <seun_ewulomi@hotmail.com> writes:
>
> > Im doing a active test just using ping(via script). I have the script to
> > ping a device(100 counts) then send it to a file.
> >
> > My main question is what will give a more accurate rtt.
> >
> > 1)taking the mean of all 100 pings
> > 2)median
> > 3)mode
>
> How can you compute the mean when some of the values are close to
> infinity (losses)?
>
> Median and minimum make a lot more sense.
>
> --
> Stanislav Shalunov              http://www.internet2.edu/~shalunov/
>
> A fanatic is one who can't change his mind and won't change the
> subject.                                   -- Winston Churchill
> _______________________________________________
> ippm mailing list
> ippm@advanced.org
> http://mailhost.advanced.org/mailman/listinfo/ippm


--------------3A76D79B54EDA823D4F14E2F--

_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Thu Feb 20 09:41:12 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15949
	for <ippm-archive@lists.ietf.org>; Thu, 20 Feb 2003 09:41:11 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1KEg4CN015346;
	Thu, 20 Feb 2003 09:42:05 -0500
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1KEexCN015243
	for <ippm@advanced.org>; Thu, 20 Feb 2003 09:41:00 -0500
Received: from antares.enst-bretagne.fr (antares.enst-bretagne.fr [192.44.75.8])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h1KEf7r09259
	for <ippm@advanced.org>; Thu, 20 Feb 2003 15:41:07 +0100
Received: from enst-bretagne.fr (taureau-tse.enst-bretagne.fr [192.44.75.100])
	by antares.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h1KEewa21227
	for <ippm@advanced.org>; Thu, 20 Feb 2003 15:40:58 +0100 (MET)
Message-ID: <3E54E843.ED59E183@enst-bretagne.fr>
From: Sandrine Vaton <Sandrine.Vaton@enst-bretagne.fr>
X-Mailer: Mozilla 4.75 [fr] (Windows NT 5.0; U)
X-Accept-Language: fr
MIME-Version: 1.0
To: ippm@advanced.org
Subject: [Fwd: [ippm] statistics techniques]
Content-Type: multipart/mixed;
 boundary="------------2CB19F7FAC2BC598045BED51"
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: Thu, 20 Feb 2003 15:37:55 +0100

Il s'agit d'un message multivolet au format MIME.
--------------2CB19F7FAC2BC598045BED51
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



--------------2CB19F7FAC2BC598045BED51
Content-Type: message/rfc822
Content-Disposition: inline

X-Mozilla-Status2: 00000000
Message-ID: <3E54DB0E.CA5C2D2E@enst-bretagne.fr>
Date: Thu, 20 Feb 2003 14:41:35 +0100
From: Sandrine Vaton <Sandrine.Vaton@enst-bretagne.fr>
X-Mailer: Mozilla 4.75 [fr] (Windows NT 5.0; U)
X-Accept-Language: fr
MIME-Version: 1.0
To: stanislav shalunov <shalunov@internet2.edu>
Subject: Re: [ippm] statistics techniques
References: <EBELLEFJANFIHFPEMGPCGEMNCMAA.salamat@rp.lip6.fr> <87isvhmbn9.fsf@cain.internet2.edu> <3E53775C.7B1F19B@enst-bretagne.fr> <87of57lko2.fsf@cain.internet2.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> And, if you know that the delay was greater than some value and have
> no knowledge of the distribution, what do you do?
>

SV -> Most of the time the Expectation Maximization algorithm is very useful
for dealing with censored data.


>
> > >    Median is useful for several reasons:
>
> > >    b. It is well-defined for samples where more than 50% of packets
> > >       arrived during the measurement (thus making it widely usable).
> > >
> >
> > I do not agree with point b. If only 50% of the packets were
> > delivered and if you estimate the mean delay as the mean over the
> > packets delivered
>
> Sure.  That's why I talk about _median_, not mean.
>

SV -> Hum hum I did not get that point. That looks tricky. But, unless you are
in a model with only one parameter (an exponential distribution for example)
the median will not be sufficient to fully determine the distribution.


>
> > >    c. It is robust.
>
> > In what sense?
>
> It is not significantly affected by small amounts of noise.
>

SV -> This is true when the noise is additive with a symetric distribution
around the origin.

>
> --
> Stanislav Shalunov              http://www.internet2.edu/~shalunov/
>
> Sex is the mathematics urge sublimated.                 -- M. C. Reed.


--------------2CB19F7FAC2BC598045BED51--

_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Thu Feb 20 11:09:15 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19414
	for <ippm-archive@lists.ietf.org>; Thu, 20 Feb 2003 11:09:15 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1KGC4CN018616;
	Thu, 20 Feb 2003 11:12:04 -0500
Received: from basie.internet2.edu (basie.internet2.edu [207.75.164.22])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1KGBxCN018600
	for <ippm@advanced.org>; Thu, 20 Feb 2003 11:12:00 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by basie.internet2.edu (Postfix) with ESMTP
	id 9153F7B4F0; Thu, 20 Feb 2003 11:11:59 -0500 (EST)
Received: from localhost (localhost [127.0.0.1])
	by basie.internet2.edu (Postfix) with ESMTP
	id 8A3227B4B6; Thu, 20 Feb 2003 11:11:58 -0500 (EST)
To: Nischal M Piratla <nischal@engr.colostate.edu>
Cc: ippm@advanced.org, Anura Jayasumana <Anura.Jayasumana@Colostate.edu>,
        Abhijit A Bare <abhijit@CS.ColoState.EDU>
Subject: Re: [ippm] New metric for packet reordering
References: <3E545AB2.1080108@engr.colostate.edu>
From: stanislav shalunov <shalunov@internet2.edu>
In-Reply-To: <3E545AB2.1080108@engr.colostate.edu>
Message-ID: <87r8a3j5it.fsf@cain.internet2.edu>
Lines: 25
X-Mailer: Gnus v5.7/Emacs 20.4
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS 0.3.12pre8
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: 20 Feb 2003 11:11:54 -0500

Nischal M Piratla <nischal@engr.colostate.edu> writes:

> http://www.engr.colostate.edu/ece/Research/cnrl/code/RD.c

Nischal,

It seems that:

* When `late' packets are encountered, your metric behaves like
  N-reordering;

* When `early' packets are encountered, your metric reports same
  degree of reordering as N-reordering, but larger number of packets
  are reported as reordered;

* When there are any missing packets, it reports high degrees of
  reordering for a whole bunch of packets.

This last is a show-stopper as far as I am concerned.

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

A fanatic is one who can't change his mind and won't change the
subject.                                   -- Winston Churchill
_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Thu Feb 20 12:09:29 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21632
	for <ippm-archive@lists.ietf.org>; Thu, 20 Feb 2003 12:09:29 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1KH83CN020529;
	Thu, 20 Feb 2003 12:08:04 -0500
Received: from basie.internet2.edu (basie.internet2.edu [207.75.164.22])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1KH7DCN020507
	for <ippm@advanced.org>; Thu, 20 Feb 2003 12:07:14 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by basie.internet2.edu (Postfix) with ESMTP
	id B9C247B4F0; Thu, 20 Feb 2003 12:07:13 -0500 (EST)
Received: from localhost (localhost [127.0.0.1])
	by basie.internet2.edu (Postfix) with ESMTP
	id 8C0C57B4B6; Thu, 20 Feb 2003 12:07:12 -0500 (EST)
To: Sandrine Vaton <Sandrine.Vaton@enst-bretagne.fr>
Cc: ippm@advanced.org
Subject: Re: [ippm] statistics techniques
References: <EBELLEFJANFIHFPEMGPCGEMNCMAA.salamat@rp.lip6.fr> <87isvhmbn9.fsf@cain.internet2.edu> <3E53775C.7B1F19B@enst-bretagne.fr> <87of57lko2.fsf@cain.internet2.edu> <3E54DB0E.CA5C2D2E@enst-bretagne.fr> <87of57j5ct.fsf@cain.internet2.edu> <3E550222.3633D4DB@enst-bretagne.fr>
From: stanislav shalunov <shalunov@internet2.edu>
In-Reply-To: <3E550222.3633D4DB@enst-bretagne.fr>
Message-ID: <8765rekhj4.fsf@cain.internet2.edu>
Lines: 63
X-Mailer: Gnus v5.7/Emacs 20.4
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS 0.3.12pre8
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: 20 Feb 2003 12:07:11 -0500

Sandrine Vaton <Sandrine.Vaton@enst-bretagne.fr> writes:

> stanislav shalunov a écrit :
> 
> > Sandrine Vaton <Sandrine.Vaton@enst-bretagne.fr> writes:
> >
> > > SV -> Hum hum I did not get that point. That looks tricky. But,
> > > unless you are in a model with only one parameter (an exponential
> > > distribution for example) the median will not be sufficient to fully
> > > determine the distribution.
> >
> > As would be the mean.
> >
> > But, I didn't even say I make any assumptions about the model.
> 
> The problem is that most of the time you need more than one parameter to
> characterize a distribution. For example for a Gaussian distribution you need
> the mean and the variance, unless you suppose that there is a relationship
> between mean and variance (for example variance=mean^c with c=...)

How does this make mean relevant?  I am saying that it is a better
practice to report median of delays than attempt to report mean of delays.

> > > SV -> This is true when the noise is additive with a symetric distribution
> > > around the origin.
> >
> > Suppose 1% of measurements is distorted (by a very large margin).
> > Median is unlikely to be affected.  Mean is.
> 
> The median will be affected if you have more than 50% of "censored"
> RTT. I agree with you for saying that with only 1% then the median
> is not affected.

If more than 50% of packets are lost, you ought to report median=infinity.
If any packets are lost, you ought to report mean=infinity.

Which one is better?

> But once again the median is maybe not the only parameter of
> interest. In particular, the distribution of the delays is clearly
> not exponential, is it?

It is unlikely that packet delay is a random quantity from a
statistical point of view.  (There's no probability space, there's a
feedback loop, etc.)  Certainly different measurements (taken close
enough) are not independent.

If one were to model delay as an i.i.d. random quantity, then shifted
exponentially distributed delay (two parameters) might be appropriate
for certain regimes, but polynomial distribution (perhaps
1/(a*(x-b)^3), two parameters again) seems better supported by
evidence.  Others suggested gamma-distribution and a host of
heavy-tail distributions.

There are certainly at least two independent quantities: the
propagation delay and some measure of the queuing delay.  I like
minimum and median to represent these two.

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

A fool's brain digests philosophy into folly, science into superstition,
and art into pedantry.  Hence University education.       -- G. B. Shaw
_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Thu Feb 20 15:24:48 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28384
	for <ippm-archive@lists.ietf.org>; Thu, 20 Feb 2003 15:24:48 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1KKR4CN027204;
	Thu, 20 Feb 2003 15:27:04 -0500
Received: from hotmail.com (f81.sea2.hotmail.com [207.68.165.81])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1KKQ7CN027179
	for <ippm@advanced.org>; Thu, 20 Feb 2003 15:26:07 -0500
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 20 Feb 2003 12:26:06 -0800
Received: from 193.116.20.220 by sea2fd.sea2.hotmail.msn.com with HTTP;
	Thu, 20 Feb 2003 20:26:06 GMT
X-Originating-IP: [193.116.20.220]
From: "gab.seun jones.ewulomi" <seun_ewulomi@hotmail.com>
To: shalunov@internet2.edu, Sandrine.Vaton@enst-bretagne.fr
Cc: ippm@advanced.org
Subject: Re: [ippm] statistics techniques
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F816kRfuCLqRN55aZj200047526@hotmail.com>
X-OriginalArrivalTime: 20 Feb 2003 20:26:06.0932 (UTC) FILETIME=[4C21B940:01C2D91E]
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: Thu, 20 Feb 2003 20:26:06 +0000



Hi Guys,

First of all my sincere apologies for any mis-understanding I could have 
caused. I didnt think it would matter to explain my goal because i thought 
it was a trivial question(thanks Kave for the wise words). I am by no means 
as clued up as you guys (just a beginner who isnt scared to do some 
mathematical crunching). Please bear with il just try and explain as my 
knowledg permits me.

This question was a cause of a little discussion/arguement with my boss and 
I in which I tried to explain that the median of the ping collection we took 
would make more sense than the mean.

first of all we have private network meaning we manage all our links and the 
isp's do all the switching at the exchange points. So in any case rtt should 
I say is fairly constant to nodes(sites - assuming taking into consideration 
transmission and propagation and also assuming no traffic) the only think 
that could probably bumps up the rtt are queueing or process delays at each 
hop.

What I expect from this test is to find out as Kave.S stated the rtt 
distribution within the 100 count. Although I definately welcome taking it 
further as Kave.S and Sandrine.V suggested by being able to predict rtt from 
past measurements e.g predict rtt in count 101. I will still greatly 
appreciate any pointers.

Taking this into consideration and as Stanislav stated you might get losses 
which will probably throw away trying to work out the average e.g loss could 
be > rtt_max.
Also I found out when I worked out both the mean and median and mode, they 
were always usually equal  which i think implies that the data are 
symmetrically distributed(im only assuming within this 100 count in which 
all the values are not far from the median. They aren't that dispersed). But 
taking the median took into consideration the skew which was very minimal.
Taking the Mean I found out doesnt tell you much about whether there is a 
fit within a particular range. Taking all this in I automatically assumed 
the median showed a more true picture.

I do agree that delay should be taken into consideration and if we know what 
delay_max is and if we get delay > delay_max as suggested will certainly be 
worthy information to know(I havent gone as using bayesian techniques yet to 
determine what the delay would be).

My goal was to find out the differences by comparing means or medians which 
I believe are both measures of the center of a distribution(please correct 
me if im wrong). If the data were totally symmetrical distributed(no skews), 
taking the mean would(i think) be a reliable measure of the center or 
average.

I wanted to graphically illustrate approximate location of the quartiles, 
including the median, and the extreme values. Basically have short term view 
of mean rtt as well as median rtt

I certainly need to enrich my model as Sandrine.V suggested because I havent 
taking into account packets that could be lost or delivered at a later time

This has gone well beyond me any more pointers will be greatly appreciated

regards,
seun





>From: stanislav shalunov <shalunov@internet2.edu>
>To: Sandrine Vaton <Sandrine.Vaton@enst-bretagne.fr>
>CC: ippm@advanced.org
>Subject: Re: [ippm] statistics techniques
>Date: 20 Feb 2003 12:07:11 -0500
>
>Sandrine Vaton <Sandrine.Vaton@enst-bretagne.fr> writes:
>
> > stanislav shalunov a écrit :
> >
> > > Sandrine Vaton <Sandrine.Vaton@enst-bretagne.fr> writes:
> > >
> > > > SV -> Hum hum I did not get that point. That looks tricky. But,
> > > > unless you are in a model with only one parameter (an exponential
> > > > distribution for example) the median will not be sufficient to fully
> > > > determine the distribution.
> > >
> > > As would be the mean.
> > >
> > > But, I didn't even say I make any assumptions about the model.
> >
> > The problem is that most of the time you need more than one parameter to
> > characterize a distribution. For example for a Gaussian distribution you 
>need
> > the mean and the variance, unless you suppose that there is a 
>relationship
> > between mean and variance (for example variance=mean^c with c=...)
>
>How does this make mean relevant?  I am saying that it is a better
>practice to report median of delays than attempt to report mean of delays.
>
> > > > SV -> This is true when the noise is additive with a symetric 
>distribution
> > > > around the origin.
> > >
> > > Suppose 1% of measurements is distorted (by a very large margin).
> > > Median is unlikely to be affected.  Mean is.
> >
> > The median will be affected if you have more than 50% of "censored"
> > RTT. I agree with you for saying that with only 1% then the median
> > is not affected.
>
>If more than 50% of packets are lost, you ought to report median=infinity.
>If any packets are lost, you ought to report mean=infinity.
>
>Which one is better?
>
> > But once again the median is maybe not the only parameter of
> > interest. In particular, the distribution of the delays is clearly
> > not exponential, is it?
>
>It is unlikely that packet delay is a random quantity from a
>statistical point of view.  (There's no probability space, there's a
>feedback loop, etc.)  Certainly different measurements (taken close
>enough) are not independent.
>
>If one were to model delay as an i.i.d. random quantity, then shifted
>exponentially distributed delay (two parameters) might be appropriate
>for certain regimes, but polynomial distribution (perhaps
>1/(a*(x-b)^3), two parameters again) seems better supported by
>evidence.  Others suggested gamma-distribution and a host of
>heavy-tail distributions.
>
>There are certainly at least two independent quantities: the
>propagation delay and some measure of the queuing delay.  I like
>minimum and median to represent these two.
>
>--
>Stanislav Shalunov		http://www.internet2.edu/~shalunov/
>
>A fool's brain digests philosophy into folly, science into superstition,
>and art into pedantry.  Hence University education.       -- G. B. Shaw
>_______________________________________________
>ippm mailing list
>ippm@advanced.org
>http://mailhost.advanced.org/mailman/listinfo/ippm


_________________________________________________________________
Chat online in real time with MSN Messenger http://messenger.msn.co.uk

_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Thu Feb 20 21:42:09 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07028
	for <ippm-archive@lists.ietf.org>; Thu, 20 Feb 2003 21:42:09 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1L2h5CN005841;
	Thu, 20 Feb 2003 21:43:05 -0500
Received: from mail.cad.zju.edu.cn (cad.zju.edu.cn [210.32.131.2])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with SMTP id h1L2gcCN005825
	for <ippm@advanced.org>; Thu, 20 Feb 2003 21:42:42 -0500
Received: (qmail 25751 invoked from network); 21 Feb 2003 02:49:28 -0000
Received: from unknown (HELO cad.zju.edu.cn) (210.32.131.97)
  by 210.32.131.2 with SMTP; 21 Feb 2003 02:49:28 -0000
Message-ID: <3E559261.246E1216@cad.zju.edu.cn>
From: Jing Shen <jshen@cad.zju.edu.cn>
Reply-To: jshen@cad.zju.edu.cn
Organization: State Key Lab of CAD&CG
X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: stanislav shalunov <shalunov@internet2.edu>
CC: Sandrine Vaton <Sandrine.Vaton@enst-bretagne.fr>, ippm@advanced.org
Subject: Re: [ippm] statistics techniques
References: <EBELLEFJANFIHFPEMGPCGEMNCMAA.salamat@rp.lip6.fr> <87isvhmbn9.fsf@cain.internet2.edu> <3E53775C.7B1F19B@enst-bretagne.fr> <87of57lko2.fsf@cain.internet2.edu> <3E54DB0E.CA5C2D2E@enst-bretagne.fr> <87of57j5ct.fsf@cain.internet2.edu> <3E550222.3633D4DB@enst-bretagne.fr> <8765rekhj4.fsf@cain.internet2.edu>
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: Fri, 21 Feb 2003 10:43:45 +0800
Content-Transfer-Encoding: 7bit

The RTT value is at least related to two factors: the time of
measurement 
and the status of network. To some of the measurement, RTT reaches
its bigest value at 9-10 o'clock and 15-16 o'clock, and the lowest value
is reached at 3-5 o'clock. So it's self-similar, and from viewpoint of
statics mathematical expectation should be value we need. 

In a 100 sample points measurement, it may be a better choice to 
take the median value if the measurement time is fixed.




>It is unlikely that packet delay is a random quantity from a
>statistical point of view.  (There's no probability space, there's a
>feedback loop, etc.)  Certainly different measurements (taken close
>enough) are not independent.

>If one were to model delay as an i.i.d. random quantity, then shifted
>exponentially distributed delay (two parameters) might be appropriate
>for certain regimes, but polynomial distribution (perhaps
>1/(a*(x-b)^3), two parameters again) seems better supported by
>evidence.  Others suggested gamma-distribution and a host of
>heavy-tail distributions.

>There are certainly at least two independent quantities: the
>propagation delay and some measure of the queuing delay.  I like
>minimum and median to represent these two.


-- 
Jing Shen




**********************************************************************
* The SunShine of life is made up of very little beams which is      *
*  bright all the time                                               *
**********************************************************************
_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Fri Feb 21 08:32:55 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28890
	for <ippm-archive@lists.ietf.org>; Fri, 21 Feb 2003 08:32:55 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1LDJ4CN021205;
	Fri, 21 Feb 2003 08:19:05 -0500
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1LDIACN021186
	for <ippm@advanced.org>; Fri, 21 Feb 2003 08:18:11 -0500
Received: from antares.enst-bretagne.fr (antares.enst-bretagne.fr [192.44.75.8])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h1LDIGr25753;
	Fri, 21 Feb 2003 14:18:16 +0100
Received: from enst-bretagne.fr (taureau-tse.enst-bretagne.fr [192.44.75.100])
	by antares.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h1LDI8a21053;
	Fri, 21 Feb 2003 14:18:08 +0100 (MET)
Message-ID: <3E562657.CC4C2DE3@enst-bretagne.fr>
From: Sandrine Vaton <Sandrine.Vaton@enst-bretagne.fr>
X-Mailer: Mozilla 4.75 [fr] (Windows NT 5.0; U)
X-Accept-Language: fr
MIME-Version: 1.0
To: stanislav shalunov <shalunov@internet2.edu>
CC: ippm@advanced.org
Subject: Re: [ippm] statistics techniques
References: <EBELLEFJANFIHFPEMGPCGEMNCMAA.salamat@rp.lip6.fr> <87isvhmbn9.fsf@cain.internet2.edu> <3E53775C.7B1F19B@enst-bretagne.fr> <87of57lko2.fsf@cain.internet2.edu> <3E54DB0E.CA5C2D2E@enst-bretagne.fr> <87of57j5ct.fsf@cain.internet2.edu> <3E550222.3633D4DB@enst-bretagne.fr> <8765rekhj4.fsf@cain.internet2.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: Fri, 21 Feb 2003 14:15:04 +0100
Content-Transfer-Encoding: 7bit



>
> >
> > The problem is that most of the time you need more than one parameter to
> > characterize a distribution. For example for a Gaussian distribution you need
> > the mean and the variance, unless you suppose that there is a relationship
> > between mean and variance (for example variance=mean^c with c=...)
>
> How does this make mean relevant?  I am saying that it is a better
> practice to report median of delays than attempt to report mean of delays.
>

SV -> I think that we do not understand each other. What I was saying is that only
*one* parameter is generally not enough to characterize the distribution of the
delays.

> If more than 50% of packets are lost, you ought to report median=infinity.
> If any packets are lost, you ought to report mean=infinity.
>
> Which one is better?
>

SV -> No. There ARE ways of estimating the finite mean (or median) even if a
majority of packets are lost. And the estimate will not be infinite
(fortunately...). For example the proportion of packets for which you do not have
the rtt gives you a lot of information on the parameters of the distribution of
delays (this proportion is a quartile of the distribution).


> It is unlikely that packet delay is a random quantity from a
> statistical point of view.  (There's no probability space, there's a
> feedback loop, etc.)  Certainly different measurements (taken close
> enough) are not independent.
>

SV -> Here we come to an agreement. The successive measurements should not be
considered as independent. I am completely in favor of tha point of view and I have
been defending that point of view for years!

From my simulations I even found out that most of the time a Hidden Markov Model
(HMM) was a valuable approach. Broadly speaking the channel can be considered as a
finite state random machine (a Markov chain) with 4 or 5 states and the distribution
of the delay depends on the state of the channel at present.

This enriched model should not prevent you from defining a distribution for the
delay. In the case of a HMM this distribution is a weighted mixture of the component
distributions (the weights being defined by the stationary regime of the
"underlying" Markov chain, that is to say the the channel).

See my Web page http://perso-info.enst-bretagne.fr/~vaton for a series of
publications in that sense. I also made available some software that I wrote for
training the parameters of a HMM on a series of packet loss as well as some MCMC
algorithms for various applications in network characterization.

>
> If one were to model delay as an i.i.d. random quantity, then shifted
> exponentially distributed delay (two parameters) might be appropriate
> for certain regimes, but polynomial distribution (perhaps
> 1/(a*(x-b)^3), two parameters again) seems better supported by
> evidence.  Others suggested gamma-distribution and a host of
> heavy-tail distributions.
>

You can choose any law you want! You can even define the distribution by an
analytical formula even if it does not correspond to a well known distribution   (
-x^2 cos(x) + 3 x sin (x)+3800 is not forbidden if you feel that it better fits your
empirical distribution...)

Kind regards,

Sandrine Vaton.

_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Fri Feb 21 12:40:31 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08377
	for <ippm-archive@lists.ietf.org>; Fri, 21 Feb 2003 12:40:31 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1LHh4CN029399;
	Fri, 21 Feb 2003 12:43:05 -0500
Received: from hotmail.com (f24.sea2.hotmail.com [207.68.165.24])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1LHgICN029372
	for <ippm@advanced.org>; Fri, 21 Feb 2003 12:42:18 -0500
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 21 Feb 2003 09:42:17 -0800
Received: from 193.116.20.220 by sea2fd.sea2.hotmail.msn.com with HTTP;
	Fri, 21 Feb 2003 17:42:15 GMT
X-Originating-IP: [193.116.20.220]
From: "gab.seun jones.ewulomi" <seun_ewulomi@hotmail.com>
To: jshen@cad.zju.edu.cn, shalunov@internet2.edu
Cc: Sandrine.Vaton@enst-bretagne.fr, ippm@advanced.org
Subject: Re: [ippm] statistics techniques
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F247fnp3eEHJtfob7bO00005ff5@hotmail.com>
X-OriginalArrivalTime: 21 Feb 2003 17:42:17.0978 (UTC) FILETIME=[94081DA0:01C2D9D0]
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: Fri, 21 Feb 2003 17:42:15 +0000

hi,

I presume thats why I chose to use the median because i was just using 100 
counts as by base measurement.

The time is a big factor because as you rightly stated even if the rtt 
reached a max at time t and reached a minimum at time t. I will certain like 
to know about the rtt at especially the max t time.
Assuming I will start doing counts=100 at 2hr intervals =1200 counts per 
day. So will taken the mean, median, max rtt, min rtt be a good starting 
point. Also will taking the variance for like chunks of the samples e.g for 
every daily sample of 1200 count take the variance sample size(count)<500 
daily(from the daily samples) give me the spread of a distribution about its 
average value within a set of sample data or is there a better way to 
approach this

regards,
gab

>From: Jing Shen Reply-To: jshen@cad.zju.edu.cn To: stanislav shalunov CC: 
>Sandrine Vaton , ippm@advanced.org Subject: Re: [ippm] statistics 
>techniques Date: Fri, 21 Feb 2003 10:43:45 +0800
>
>The RTT value is at least related to two factors: the time of measurement 
>and the status of network. To some of the measurement, RTT reaches its 
>bigest value at 9-10 o'clock and 15-16 o'clock, and the lowest value is 
>reached at 3-5 o'clock. So it's self-similar, and from viewpoint of statics 
>mathematical expectation should be value we need.
>
>In a 100 sample points measurement, it may be a better choice to take the 
>median value if the measurement time is fixed.
>
>
>
>
> >It is unlikely that packet delay is a random quantity from a >statistical 
>point of view. (There's no probability space, there's a >feedback loop, 
>etc.) Certainly different measurements (taken close >enough) are not 
>independent.
>
> >If one were to model delay as an i.i.d. random quantity, then shifted 
> >exponentially distributed delay (two parameters) might be appropriate 
> >for certain regimes, but polynomial distribution (perhaps >1/(a*(x-b)^3), 
>two parameters again) seems better supported by >evidence. Others suggested 
>gamma-distribution and a host of >heavy-tail distributions.
>
> >There are certainly at least two independent quantities: the >propagation 
>delay and some measure of the queuing delay. I like >minimum and median to 
>represent these two.
>
>
>--
>Jing Shen
>
>
>
>
>********************************************************************** * 
>The SunShine of life is made up of very little beams which is * * bright 
>all the time * 
>********************************************************************** 
>_______________________________________________ ippm mailing list 
>ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm

_________________________________________________________________
It's fast, it's easy and it's free. Get MSN Messenger today! 
http://messenger.msn.co.uk

_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Wed Feb 26 10:54:00 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13043
	for <ippm-archive@lists.ietf.org>; Wed, 26 Feb 2003 10:53:59 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1QFqXCN022585;
	Wed, 26 Feb 2003 10:52:35 -0500
Received: from isis.lip6.fr (isis.lip6.fr [132.227.60.2])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1JIfuCO014763
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL)
	for <ippm@advanced.org>; Wed, 19 Feb 2003 13:41:59 -0500
Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2])
          by isis.lip6.fr (8.12.4/jtpda-5.4+victor) with ESMTP id h1JIfsVR009806
          (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
          for <ippm@advanced.org>; Wed, 19 Feb 2003 19:41:54 +0100
X-pt: isis.lip6.fr
Received: from LIP60MU1PINK59 (rp-dhcp2 [132.227.61.202])
	by tibre.lip6.fr (8.11.6/8.11.3) with SMTP id h1JIfr309560
	for <ippm@advanced.org>; Wed, 19 Feb 2003 19:41:53 +0100 (MET)
From: =?iso-8859-1?Q?Kav=E9_Salamatian?= <Kave.Salamatian@lip6.fr>
To: <ippm@advanced.org>
Subject: RE: [ippm] statistics techniques
Message-ID: <EBELLEFJANFIHFPEMGPCEENECMAA.salamat@rp.lip6.fr>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
X-Scanned-By: isis.lip6.fr
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: Wed, 19 Feb 2003 19:41:09 +0100
Content-Transfer-Encoding: 7bit

>I can not speak for the original poster, but since you appear to be
>addressing me while (not?) answering his questions:
Not only, but the community. I think that the kind of trivial question I am
asking are not so trivial and they will shed some light on what we are doing
and on what is asked.

>1. The values of delay for lost packets are not ``missing''.  They are
>   potentially very large unknowable values.  That packet that I sent
>   last year and that appeared to be lost might still be delivered one
>   day.
Some of the inexisting values are indeed missing (relative to real packet
loss). Some of them are censored values. The two problems are well known and
well documented. It suffices to have a look to a good introductory level
statistical book.

>2. The necessity for aggregation is more about human consumption of
>   data than about using it to predict anything or to compute
>   parameters of a distribution (there's no distribution).
Correct. The Occam's razor, which is attributed to the mediaeval philosopher
William of Occam (living in 15th century in the oldish europe), underlies
that in all scientific modelling and theory building we should choose from a
set of otherwise equivalent models of a given phenomenon the simplest one.
However using this razor should be done with some cautions (as using any
razor). By aggregating are you not loosing something essential ?? Clearly
the statistical mean, mode, median, is not a universal aggregation tools. In
fact using the mean, mode or median as a aggregation tools pre suppose (even
if you are not aware of this, you are doing it) that you can describe the
compressed (aggregated observation) in only this value. Clearly there is
only one case that this is a valid assumption, the poisson pdf. Out of this
you need at least the variance, you will have a parametric a priori which is
the gaussian.

You are saying there is no distribution. But if you are in the real world
there is always distribution, and every computation is an estimation, and
for every estimation there is a statistical test. By using the mean, median
or mode as an aggregation parameter, what is the statistical test.... If you
think, you will see that the statistical test is "H0: The estimated mean,
median or mode is the parameter of a model describing the measurements". In
every test you have an associated risk. The risk is relative to the
application you are doing of the test results. Let's suppose that I
calculate the mean and I erase the measurement, now I use only the mean to
replace the erased values. Now if I use a quadratic risk function, my risk
is asymptotycally converging (under stationnarity and ergodicity conditions)
to the variance of the measured parameter. Is this risk acceptable?
Sometimes, yes, sometimes not. This is why the aggregation question has not
any universal answer (out of classical non lossy compression schemes as
Lempel Ziv and so).

If arbitrary answer is possible I would rather like and estimate the first
derivative of the Characteristic function calculated at s=0. It is a more
pedantic and funnier aggregation parameter :-)))

>   Minimum (or something close to it) is meaningful in itself: given enough
>   measurements, it's a reasonable guess of propagation delay.

Great. You have in mind a parametric model that the observed delay is the
summation of the propagation delay and a positive perturbation parameter
(let say it n). Your estimator is the minimal value oberved over N
observations and your associated risk with a quadratic risk function is
converging (under the same stationnarity and ergodicity constraints) to
E{Min{d_1, ..., D_N}}.

> Median is useful for several reasons:
>
>
>   a. It reflects the whole sample.
It reflects only the mean aspect of the sample, not the whole sample.

>   b. It is well-defined for samples where more than 50% of packets
>      arrived during the measurement (thus making it widely usable).
It is well defined whenever one measurment is avaiable, however the risk
induced by using this estimate of the mean can be large if a quadratic
criteria is used and less than 50% of packets arrived during the
measurements.

>   c. It is robust.
To what kind of problem. Let suppose that I have a network which have two
set of routing table. One for night and one for days. Routing  change every
night at 8 PM sharp and 8 AM Sharp. I have regularly measured the delay from
9 AM to 9 PM. Now is median robust to this? Clearly median, mode and mean
are not robust.


>   d. It is easy to understand.

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

A fanatic is one who can't change his mind and won't change the
subject.                                   -- Winston Churchill
_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm

_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Fri Feb 28 08:13:44 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26210
	for <ippm-archive@lists.ietf.org>; Fri, 28 Feb 2003 08:13:43 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1SDG4CN031205;
	Fri, 28 Feb 2003 08:16:04 -0500
Received: from basie.internet2.edu (basie.internet2.edu [207.75.164.22])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1SDFTCN031189
	for <ippm@advanced.org>; Fri, 28 Feb 2003 08:15:29 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by basie.internet2.edu (Postfix) with ESMTP
	id 506367B4B7; Fri, 28 Feb 2003 08:15:29 -0500 (EST)
Received: from localhost (localhost [127.0.0.1])
	by basie.internet2.edu (Postfix) with ESMTP
	id 66AA87B493; Fri, 28 Feb 2003 08:15:28 -0500 (EST)
To: Allison Mankin <mankin@psg.com>
Cc: ippm@advanced.org
Subject: Re: [ippm] IESG review of draft-ietf-ippm-owdp-reqs-04.txt
References: <E18INln-000Jog-00@psg.com>
From: stanislav shalunov <shalunov@internet2.edu>
In-Reply-To: <E18INln-000Jog-00@psg.com>
Message-ID: <874r6omtqo.fsf@cain.internet2.edu>
Lines: 32
X-Mailer: Gnus v5.7/Emacs 20.4
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS 0.3.12pre8
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: 28 Feb 2003 08:15:27 -0500

http://www.internet2.edu/~shalunov/ippm/draft-ietf-ippm-owdp-reqs-05.txt
has been submitted to the internet-drafts repository.

Its purpose is to address replay attack issues raised in Steve
Bellovin's security review.

To save you the trouble of digging it out and running diff, the
following substantially new text was included:

6.6. Replay Attacks

   OWAMP-Control must be resistant to any replay attacks.

   OWAMP-Test, on the other hand, is a protocol for network measurement.
   One of the attributes of networks is packet duplication.  OWAMP-Test
   has to be suitable for measurement of duplication.  This would make
   it vulnerable to attacks that involve replaying a recent packet.  For
   the recipient of such a packet it is impossible to determine whether
   the duplication is malicious or naturally occurring.

   OWAMP-Test should measure all duplication -- malicious or otherwise.
   Note that this is similar to delay attacks: an attacker can hold up a
   packet for some short period of time and then release it to continue
   on its way to the recipient.  There's no way such delay can be
   reliably distinguished from naturally occuring delay by the
   recipient.

   OWAMP-Test should measure the network as it was.  Note, however, that
   this does not prevent the data from being sanitized at a later stage
   of processing, analysis, or consumption.  Some sanity checks (those
   that are deemed reliable and erring on the side of inclusion) should
   be performed by OWAMP-Test recipient immediately.
_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Fri Feb 28 19:09:23 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17737
	for <ippm-archive@lists.ietf.org>; Fri, 28 Feb 2003 19:09:23 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h21095CN018421;
	Fri, 28 Feb 2003 19:09:05 -0500
Received: from mesa.acns.ColoState.EDU (mesa.acns.colostate.edu [129.82.100.130])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h2108FCN018405
	for <ippm@advanced.org>; Fri, 28 Feb 2003 19:08:16 -0500
Received: from lamar.colostate.edu (lamar.acns.colostate.edu [129.82.100.75])
	by mesa.acns.ColoState.EDU (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA23732;
	Fri, 28 Feb 2003 17:08:15 -0700
Received: from engr.colostate.edu (res097074.halls.colostate.edu [129.82.97.74] (may be forged)) by lamar.colostate.edu (AIX5.1/8.11.0/8.8.8) with ESMTP id h21087g566894; Fri, 28 Feb 2003 17:08:07 -0700
Message-ID: <3E5FFA02.3090600@engr.colostate.edu>
From: Nischal Piratla <nischal@engr.colostate.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: stanislav shalunov <shalunov@internet2.edu>
CC: ippm@advanced.org, Anura Jayasumana <Anura.Jayasumana@Colostate.edu>,
        Abhijit A Bare <abhijit@CS.ColoState.EDU>
Subject: Re: [ippm] New metric for packet reordering
References: <3E545AB2.1080108@engr.colostate.edu> <87r8a3j5it.fsf@cain.internet2.edu>
Content-Type: multipart/alternative;
 boundary="------------020603070408050403010202"
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: Fri, 28 Feb 2003 17:08:34 -0700


--------------020603070408050403010202
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Stanislav,
Thank you for the comments. Here are the clarifications.

> It seems that:
>
> * When `late' packets are encountered, your metric behaves like
>  N-reordering;
>
> * When `early' packets are encountered, your metric reports same
>  degree of reordering as N-reordering, but larger number of packets
>  are reported as reordered;
>
RD algorithm does not behave like N-reordering. Here are just  a couple 
of simple  examples:

Example 1:
For the sequence <1,4,5,2,3>
RD output:
displacement absolute normalized
0 2 0.400
1 1 0.200
2 2 0.400
3 0 0.000
4 0 0.000


N-reordering output:
1-reordering = 25.000000%
2-reordering = 33.333333%
no 3-reordering

1-reordering = 1
2-reordering = 1
no 3-reordering

In this sequence, RD shows that there are two packets with F[D=2] namely 
seq #s: 5 and 2. N-reordering treats only packet 2 as 1-reordered and 
2-reordered. According to RD, even after seq # 2 arrives the buffer 
requirement is '2' as seq #. 3 has not yet arrived. However, this 
conclusion cannot be derived from N-reordering.
   
    Example 2:
For the sequence <1,2,3,4,5,2,1>
RD output:
displacement absolute normalized
0 7 1.000
1 0 0.000
2 0 0.000
3 0 0.000

N-reordering output:
1-reordering = 33.333333%
2-reordering = 40.000000%
3-reordering = 50.000000%
4-reordering = 33.333333%
5-reordering = 50.000000%
no 6-reordering


1-reordering = 2
2-reordering = 2
3-reordering = 2
4-reordering = 1
5-reordering = 1
no 6-reordering

In this example, the N-reordering algo shows that there is 5-reordering. 
If you look at the sequence there are two duplicate packets namely, 
seq#s 2 & 1. In RD, the F[D] does not exist for D>0 i.e., there is no 
reordering. As one can see, the sequence has no reordering.

**************************************

> * When there are any missing packets, it reports high degrees of
>  reordering for a whole bunch of packets.
>
> This last is a show-stopper as far as I am concerned.
>
RD has a concept of DT i.e., threshold after which the packet is assumed 
lost. This  takes care of the above issue. Moreover, we compared it with 
existing N-reordering for a sequence where the seq #2 comes after 40 
packets, then N-reordering shows very high reordering. Here is the sequence

Sequence: 
<1,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,2> 


RD output with DT = 5:
displacement absolute normalized
0 36 0.878
1 1 0.024
2 1 0.024
3 1 0.024
4 1 0.024
5 1 0.024


N-reordering output:

1-reordering = 2.500000%
2-reordering = 2.564103%
3-reordering = 2.631579%
4-reordering = 2.702703%
5-reordering = 2.777778%
6-reordering = 2.857143%
7-reordering = 2.941176%
8-reordering = 3.030303%
9-reordering = 3.125000%
10-reordering = 3.225806%
11-reordering = 3.333333%
12-reordering = 3.448276%
13-reordering = 3.571429%
14-reordering = 3.703704%
15-reordering = 3.846154%
16-reordering = 4.000000%
17-reordering = 4.166667%
18-reordering = 4.347826%
19-reordering = 4.545455%
20-reordering = 4.761905%
21-reordering = 5.000000%
22-reordering = 5.263158%
23-reordering = 5.555556%
24-reordering = 5.882353%
25-reordering = 6.250000%
26-reordering = 6.666667%
27-reordering = 7.142857%
28-reordering = 7.692308%
29-reordering = 8.333333%
30-reordering = 9.090909%
31-reordering = 10.000000%
32-reordering = 11.111111%
33-reordering = 12.500000%
34-reordering = 14.285714%
35-reordering = 16.666667%
36-reordering = 20.000000%
37-reordering = 25.000000%
38-reordering = 33.333333%
39-reordering = 50.000000%
no 40-reordering

This example clearly shows that N-reordering is much more susceptible to 
delayed packets as it cannot treat them as lost when their useful life 
is over, whereas with RD this is taken care of.  So we have to disagree 
with the above statement That certainly eliminates RD metric from 
show-stopper's list.

Please feel free to send more comments so that we can make this metric 
more useful for everyone. 
Thank You,
Nischal

***********************************************
Research Assistant
Computer Networking Research Laboratory
Department of Electrical and Computer Eng.
Colorado State University,
Fort Collins, CO 80523
Voice: +1 970-491-7974
Fax:   +1 970-491-2249
http://www.engr.colostate.edu/ece/Research/cnrl
***********************************************

stanislav shalunov wrote:

>Nischal M Piratla <nischal@engr.colostate.edu> writes:
>
>  
>
>>http://www.engr.colostate.edu/ece/Research/cnrl/code/RD.c
>>    
>>
>
>Nischal,
>
>It seems that:
>
>* When `late' packets are encountered, your metric behaves like
>  N-reordering;
>
>* When `early' packets are encountered, your metric reports same
>  degree of reordering as N-reordering, but larger number of packets
>  are reported as reordered;
>
>* When there are any missing packets, it reports high degrees of
>  reordering for a whole bunch of packets.
>
>This last is a show-stopper as far as I am concerned.
>
>  
>



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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
Stanislav, <br>
 Thank you for the comments. Here are the clarifications.    
<blockquote type="cite">It seems that: <br>
  <br>
 * When `late' packets are encountered, your metric behaves like <br>
 &nbsp;N-reordering; <br>
  <br>
 * When `early' packets are encountered, your metric reports same <br>
 &nbsp;degree of reordering as N-reordering, but larger number of packets <br>
 &nbsp;are reported as reordered; <br>
  <br>
   </blockquote>
 RD algorithm does not behave like N-reordering. Here are just&nbsp; a couple
of simple&nbsp; examples: <br>
  <br>
 Example 1:<br>
 For the sequence &lt;1,4,5,2,3&gt; <br>
 RD output: <br>
 displacement absolute normalized <br>
 0 2 0.400 <br>
 1 1 0.200 <br>
 2 2 0.400 <br>
 3 0 0.000 <br>
 4 0 0.000 <br>
  <br>
  <br>
 N-reordering output: <br>
 1-reordering = 25.000000% <br>
 2-reordering = 33.333333% <br>
 no 3-reordering <br>
  <br>
 1-reordering = 1 <br>
 2-reordering = 1 <br>
 no 3-reordering <br>
  <br>
 In this sequence, RD shows that there are two packets with F[D=2] namely 
 seq #s: 5 and 2. N-reordering treats only packet 2 as 1-reordered and  2-reordered. 
According to RD, even after seq # 2 arrives the buffer  requirement is '2' 
as seq #. 3 has not yet arrived. However, this  conclusion cannot be derived 
from N-reordering. <br>
  &nbsp; &nbsp;<br>
 &nbsp; &nbsp; Example 2: <br>
 For the sequence &lt;1,2,3,4,5,2,1&gt; <br>
 RD output: <br>
 displacement absolute normalized <br>
 0 7 1.000 <br>
 1 0 0.000 <br>
 2 0 0.000 <br>
 3 0 0.000 <br>
  <br>
 N-reordering output: <br>
 1-reordering = 33.333333% <br>
 2-reordering = 40.000000% <br>
 3-reordering = 50.000000% <br>
 4-reordering = 33.333333% <br>
 5-reordering = 50.000000% <br>
 no 6-reordering <br>
  <br>
  <br>
 1-reordering = 2 <br>
 2-reordering = 2 <br>
 3-reordering = 2 <br>
 4-reordering = 1 <br>
 5-reordering = 1 <br>
 no 6-reordering <br>
  <br>
 In this example, the N-reordering algo shows that there is 5-reordering. 
 If you look at the sequence there are two duplicate packets namely,  seq#s 
2 &amp; 1. In RD, the F[D] does not exist for D&gt;0 i.e., there is no  reordering. 
As one can see, the sequence has no reordering. <br>
  <br>
 ************************************** <br>
  
<blockquote type="cite" cite="mid3E5FB697.2000203@engr.colostate.edu">* When
there are any missing packets, it reports high degrees of <br>
 &nbsp;reordering for a whole bunch of packets. <br>
  <br>
 This last is a show-stopper as far as I am concerned. <br>
   <br>
</blockquote>
RD has a concept of DT i.e., threshold after which the packet is assumed 
lost. This&nbsp; takes care of the above issue. Moreover, we compared it  with 
existing N-reordering for a sequence where the seq #2 comes after  40 packets, 
then N-reordering shows very high reordering. Here is the  sequence <br>
  <br>
  Sequence:  &lt;1,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,2&gt;
    <br>
  <br>
 RD output with DT = 5: <br>
 displacement absolute normalized <br>
 0 36 0.878 <br>
 1 1 0.024 <br>
 2 1 0.024 <br>
 3 1 0.024 <br>
 4 1 0.024 <br>
 5 1 0.024 <br>
  <br>
  <br>
 N-reordering output: <br>
  <br>
 1-reordering = 2.500000% <br>
 2-reordering = 2.564103% <br>
 3-reordering = 2.631579% <br>
 4-reordering = 2.702703% <br>
 5-reordering = 2.777778% <br>
 6-reordering = 2.857143% <br>
 7-reordering = 2.941176% <br>
 8-reordering = 3.030303% <br>
 9-reordering = 3.125000% <br>
 10-reordering = 3.225806% <br>
 11-reordering = 3.333333% <br>
 12-reordering = 3.448276% <br>
 13-reordering = 3.571429% <br>
 14-reordering = 3.703704% <br>
 15-reordering = 3.846154% <br>
 16-reordering = 4.000000% <br>
 17-reordering = 4.166667% <br>
 18-reordering = 4.347826% <br>
 19-reordering = 4.545455% <br>
 20-reordering = 4.761905% <br>
 21-reordering = 5.000000% <br>
 22-reordering = 5.263158% <br>
 23-reordering = 5.555556% <br>
 24-reordering = 5.882353% <br>
 25-reordering = 6.250000% <br>
 26-reordering = 6.666667% <br>
 27-reordering = 7.142857% <br>
 28-reordering = 7.692308% <br>
 29-reordering = 8.333333% <br>
 30-reordering = 9.090909% <br>
 31-reordering = 10.000000% <br>
 32-reordering = 11.111111% <br>
 33-reordering = 12.500000% <br>
 34-reordering = 14.285714% <br>
 35-reordering = 16.666667% <br>
 36-reordering = 20.000000% <br>
 37-reordering = 25.000000% <br>
 38-reordering = 33.333333% <br>
 39-reordering = 50.000000% <br>
 no 40-reordering <br>
  <br>
  This example clearly shows that N-reordering is much more susceptible to 
delayed packets as it cannot treat them as lost when their useful life is 
over, whereas with RD this is taken care of. &nbsp;So we have to disagree with 
the above statement&nbsp;That certainly eliminates RD metric from show-stopper's 
list.  <br>
<br>
 Please  feel free to send more comments so that we can make this metric
more  useful for everyone.&nbsp;   <br>
 Thank You, <br>
 Nischal <br>
  <br>
 *********************************************** <br>
 Research Assistant <br>
 Computer Networking Research Laboratory <br>
 Department of Electrical and Computer Eng. <br>
 Colorado State University, <br>
 Fort Collins, CO 80523 <br>
 Voice: +1 970-491-7974 <br>
 Fax:&nbsp;&nbsp; +1 970-491-2249 <br>
 <a class="moz-txt-link-freetext"
 href="http://www.engr.colostate.edu/ece/Research/cnrl">http://www.engr.colostate.edu/ece/Research/cnrl</a>
<br>
 *********************************************** <br>
<br>
stanislav shalunov wrote:<br>
<blockquote type="cite" cite="mid87r8a3j5it.fsf@cain.internet2.edu">
  <pre wrap="">Nischal M Piratla <a class="moz-txt-link-rfc2396E" href="mailto:nischal@engr.colostate.edu">&lt;nischal@engr.colostate.edu&gt;</a> writes:

  </pre>
  <blockquote type="cite">
    <pre wrap=""><a class="moz-txt-link-freetext" href="http://www.engr.colostate.edu/ece/Research/cnrl/code/RD.c">http://www.engr.colostate.edu/ece/Research/cnrl/code/RD.c</a>
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Nischal,

It seems that:

* When `late' packets are encountered, your metric behaves like
  N-reordering;

* When `early' packets are encountered, your metric reports same
  degree of reordering as N-reordering, but larger number of packets
  are reported as reordered;

* When there are any missing packets, it reports high degrees of
  reordering for a whole bunch of packets.

This last is a show-stopper as far as I am concerned.

  </pre>
</blockquote>
<br>
<br>
</body>
</html>

--------------020603070408050403010202--

_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Fri Feb 28 21:40:16 2003
Received: from mailhost.advanced.org (root@mailhost.advanced.org [12.29.241.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20632
	for <ippm-archive@lists.ietf.org>; Fri, 28 Feb 2003 21:40:16 -0500 (EST)
Received: from mailhost.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h212V4CN022159;
	Fri, 28 Feb 2003 21:31:04 -0500
Received: from jaguar.icir.org (jaguar.icir.org [192.150.187.74])
	by mailhost.advanced.org (8.12.6/8.12.6/Debian-8) with ESMTP id h1SLG8CO013381
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
	for <ippm@advanced.org>; Fri, 28 Feb 2003 16:16:09 -0500
Received: from jaguar.icir.org (localhost [127.0.0.1])
	by jaguar.icir.org (8.12.3/8.12.3) with ESMTP id h1SLG73I085982
	for <ippm@advanced.org>; Fri, 28 Feb 2003 13:16:07 -0800 (PST)
	(envelope-from vern@jaguar.icir.org)
Message-Id: <200302282116.h1SLG73I085982@jaguar.icir.org>
To: ippm@advanced.org
From: Vern Paxson <vern@icir.org>
X-Virus-Scanned: by AMaViS-ng (Milter interface)
X-Virus-Scanned: by AMaViS-ng (Milter interface)
Subject: [ippm] Internet Measurement Conference 2003 call for papers now available
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:ippm-request@advanced.org?subject=help>
List-Post: <mailto:ippm@advanced.org>
List-Subscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=subscribe>
List-Id: IETF IP Performance Metrics Working Group List <ippm.advanced.org>
List-Unsubscribe: <http://mailhost.advanced.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@advanced.org?subject=unsubscribe>
List-Archive: <http://mailhost.advanced.org/archives/ippm/>
Date: Fri, 28 Feb 2003 13:16:07 -0800

[apologies for multiple copies]

The Internet Measurement Conference 2003 will be held October 27-29, 2003
in Miami, USA.  This is the continuation of the 2001 and 2002 Internet
Measurement Workshops.  If potentially interested, please see the call for
papers at:

	http://www.icir.org/vern/imc-2003/

Key dates: submissions due May 16 (must be registered by May 9),
notification July 18, camera-ready due August 22.

For questions relating to the program, contact the program committee
chair, Mark Crovella <crovella@cs.bu.edu>.
_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm