Subject: Re: charter goal #2a

From: Juergen Quittek <[email-masked]>
Date: Tue, 20 Mar 2001 03:57:32 +0100

Hi Cornelia,

Kappler Cornelia wrote:
> 
> > -----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,
> 
> > - 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.
> >
> 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.

Yes, for these applications you need to measure at more than one place.
> 
> The ones you cite however seem to be doable with the just a single
> meter or a collection of old-fashioned meters.

Well, if your clocks are sufficiently precise and synchronized also
for the measurements you mentioned above, a set of "old-fashioned"
meters could be fine. However, one of my motivations for developing
a distributed metering architecture is that it exploits the capabilities
of modern routers with little overhead required.

"Modern" routers, e.g. with DiffServ support, already have some
packet classifier built in hardware or software. I believe that this
existing functionality can be used for metering. 

One of the reasons why it is not being used so far might be that the
implementation effort is high. Implementing e.g. the Meter MIB is not
a trivial task. But if only a small, simple extension of the existing
device is required, it might be easier to convince manufacturers
to implement it. So basic packet capturing and very simple classification
should be suggested for distributed metering devices sending captured
packets or summaries of these to a central and more complex software
meter.

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

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