Re: RE : [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt

"Henk Uijterwaal (RIPE-NCC)" <henk@ripe.net> Sun, 07 December 2003 06:02 UTC

Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02267 for <ippm-archive@lists.ietf.org>; Sun, 7 Dec 2003 01:02:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASrzV-0003oc-FI; Sun, 07 Dec 2003 01:02:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASruD-0003eY-T9 for ippm@optimus.ietf.org; Sun, 07 Dec 2003 00:56:34 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02031 for <ippm@ietf.org>; Sun, 7 Dec 2003 00:56:17 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASruB-0004X6-00 for ippm@ietf.org; Sun, 07 Dec 2003 00:56:31 -0500
Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1ASruA-0004X2-00 for ippm@ietf.org; Sun, 07 Dec 2003 00:56:30 -0500
Received: by postman.ripe.net (Postfix, from userid 8) id 28E914EF6F; Sun, 7 Dec 2003 06:56:01 +0100 (CET)
Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 8E9DE4EE2A; Sun, 7 Dec 2003 06:56:00 +0100 (CET)
Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id hB75u0wp028728; Sun, 7 Dec 2003 06:56:00 +0100
Received: from localhost (henk@localhost) by cow.ripe.net (8.12.10/8.12.6) with ESMTP id hB75tx9U032235; Sun, 7 Dec 2003 06:56:00 +0100
X-Authentication-Warning: cow.ripe.net: henk owned process doing -bs
Date: Sun, 07 Dec 2003 06:55:59 +0100
From: "Henk Uijterwaal (RIPE-NCC)" <henk@ripe.net>
To: STEPHAN Emile FTRD/DAC/LAN <emile.stephan@rd.francetelecom.com>
Cc: Matthew J Zekauskas <matt@internet2.edu>, Andy Bierman <abierman@cisco.com>, "Romascanu, Dan (Dan)" <dromasca@avaya.com>, ippm@ietf.org
Subject: Re: RE : [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt
In-Reply-To: <E1A9FAD4F1DA924182BAA04350E4A1153481FD@lanmhs50.rd.francetelecom.fr>
Message-ID: <Pine.LNX.4.58.0312070644420.30342@cow.ripe.net>
References: <E1A9FAD4F1DA924182BAA04350E4A1153481FD@lanmhs50.rd.francetelecom.fr>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-RIPE-Spam-Status: N 0.084348
X-RIPE-Signature: 6e29845540676327623f4d923fa91836
Sender: ippm-admin@ietf.org
Errors-To: ippm-admin@ietf.org
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org ?subject=subscribe>

On Thu, 4 Dec 2003, STEPHAN Emile FTRD/DAC/LAN wrote:

> Dear All,
>
> The IPPM MIB is designed as the reporting interface for a set of points of measure colocated (an embedded SNMP agent) or distributed (an IPPM proxy).
>
> The workflow of the reporting is simple:
>
>     test packet arrival
>          |
>          V
>     network metrics computation ----> ippmHistoryTable
> 	owd,ploss,ipdv...
>          |
>          V
>    Aggregated metrics computation --> ippmHistoryTable
>  	min,max,avgt,%... of owd,ploss,ipdv...
>          |
>          V
>      filtering ---------------------> ippmReportTable
>
>
> The aggregation permits to produce results over well known period of
> time (e.g.: every 5 minutes, per hour...). Reporting raw singletons have
> a big limitation: If you increase the test packets rate you increase the
> volume of information to report too. The aggregation permits to solve
> this scalability issue: The volume of information to report does not
> increase with the test packets rate.

This is true.  However:

1. People prefer different aggregation intervals, different numbers
   (average, median), for different applications.  It is impossible to
   predict everything anybody is ever going to ask for, let alone
   standardize it.

2. For a single, one time, measurement, the ippmHistoryTable have a
   limited size.  For continous measurements, ippmHistoryTAble can
   be implemented as a round robin, with the application above it
   responsible to read the buffer before data expires (or accept that
   data is expired).

> The IPPM MIB stores only network measure results:
>
>     test packet arrival
>          |
>          V
>     network metrics computation --> ippmHistoryTable
> 	owd,ploss,ipdv...

I'd go for this.

Henk  (Chair hat off)

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