Subject: charter goal #2a

From: Juergen Quittek <[email-masked]>
Date: Thu, 08 Feb 2001 08:36:31 +0100

Hi all,

with some delay, I'd like to continue commenting the
charter goals. Suggested goal 2 is:

>    Define a distributed metering architecture to support metrics
>    defined within the IPPM framework, e.g. one-way delay,
>    connectivity, one-way loss rate.  This architecture will
>    include remote packet capture, and will address privacy
>    concerns such as the inadvertant disclosure of user
>    information and the need to authenticate and authorise
>    access to captured data.

As Cornelia and Carter already stated, there are two issues
in here, remote packet capturing and a distributed metering
architecture. I discuss them separately starting with the
distributed metering architecture.

- What would be the resulting benefit?
  I observe a growing need for traffic metering in the Internet,
  mainly driven by two application areas: IP charging & accounting
  and monitoring service level agreements. Both are requirements
  of service providers.
  In charging and accounting, the requirement is to measure volume
  or session duration for specific users and for specific (value
  added) services.
  In SLA monitoring an ISP (or the customer) needs to check if a
  service (VPN, e-commerce server, access bandwidth & volume, etc)
  complies to some service level agreement.
  In both areas a non-proprietary (and available!) distribute
  metering architecture would be of high benefit.

- Is it or does it appear to be technically feasible?
  I believe so. Also I believe, it would be a lot of work.

- Is "now" the right time to work on this item?
  It seems to be a good time to start working on this issue, because
  the IPPM wg has made a lot of progress which can be used here.
  Also it is a good time to start before IPPM has completed their
  tasks, because a discussion with this group would certainly
  provide valuable input.

- Can we expect sufficient support by technical,
  experts, i.e. who is willing to contribute?
  Well, this goal is rather ambitious. We would need a lot of help
  to come up with a good architecture.

- What would be the expected output documents?
  At first a requirements document appears to be appropriate, and
  an architecture document. At this point in time it is hard to
  say what else would be required. Certainly, packet caturing
  standard would be required, but I believe, more than this is
  needed.

- What timeframe would be appropriate?
  As I said, I think this is an ambitious goal and two years might
  be a realistic minimum time frame.

- Is the IETF the right place for this item?
  Yes, of course.

    Juergen
-- 
Juergen Quittek     [email-masked]     Tel: +49 6221 90511-15
NEC Europe Ltd., C&C Research Laboratories   Fax: +49 6221 90511-55
Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de

---

From: Kappler Cornelia <[email-masked]>
Date: Fri, 16 Feb 2001 19:26:47 +0100

> -----Original Message-----
> From:	Juergen Quittek [SMTP:[email-masked]]
> Sent:	Thursday, February 08, 2001 8:37 AM
> To:	RTFM mailing list
> Subject:	charter goal #2a
> 
Juergen, 

>   metering architecture would be of high benefit.
I understood when Carter explained distributed metering is useful for specific metrics in which the same packet needs to be captured twice (correct?) as e.g. delay and reachabilty. 

The ones you cite however seem to be doable with the just a single meter or a collection of old-fashioned meters. 

E.g. for charging I might just count the number of packets as they leave the network, their QoS, and note their source/destination.

A number of *communicating* meters is needed for SLA monitoring. If the SLA specifies e.g. total bandwidth per traffic class for a specific customer, I need to count the average number of packets per traffic class of this customer coming out of the network and add the contribution of all egress points. This number needs to be compared to the average total bandwidth of this traffic class and customer trying to gain access to the network. So this is distributed. However, since I don't need to look at the individual packet, why don't I just compile information from several ordinary meters?

Cornelia