RE: Comments on "draft-duffield-framework-papame-00"

["Sonia Panchen" <sonia_panchen@inmon.com>]

Albert,
I think you have emphasized a good point:
1 in N sampling on a continuous basis works very effectively for baselining.
It is quite possible to run other techniques (eg filtering) in parallel if
necessary for other applications. For example:
* ACL based counters for billing (i/f counters being a degenerate case).
* IPFIX-like aggregations giving accurate summary counts while filtering out
the detail.

Sonia Panchen

> -----Original Message-----
> From: owner-psamp@ops.ietf.org [mailto:owner-psamp@ops.ietf.org]On
> Behalf Of Albert Greenberg
> Sent: Friday, February 22, 2002 11:46 AM
> To: Sonia Panchen
> Cc: psamp@ops.ietf.org
> Subject: Re: Comments on "draft-duffield-framework-papame-00"
>
>
> Hi Sonia,
>
> On filtering vs 1 in N sampling:  I agree that 1 in N sampling
> is needed.  It is especially helpful for tasks that involve
> "learning;" e.g., top ten traffic volumes.  Filtering is helpful
> when you know what you are looking for and can then install an
> appropriate filter; e.g., source addresses from a given netblock
> for billing purposes.   It can track the associated volume then
> with higher fidelity than the sampling.   Ideally, one would run
> sampling and some filtering in parallel.
>
> -- Albert Greenberg
> On Fri,
> 22
> Feb 2002, Sonia Panchen
> wrote:
>
> > As I understand it "A Framework for Passive Packet Measurement" is a
> > starting point for network equipment vendors, software developers, and
> > xSPs
> > to agree on a a set of capabilities that would be useful for providing
> > the
> > network traffic monitoring and analysis required for operational network
> > management tasks.
> >
> > As such it describes a number of interesting goals, philosophies,
> > specifically:
> >
> > Provision of reliable, detailed, timely traffic measurements
> > Promotion of widespread embedded traffic measurement mechanisms by
> > defining
> > simple and cost effective monitoring techniques.
> > Pervasive measurement technology with consistent and well defined
> > interfaces
> > will encourage development of a broad spectrum of applications that make
> > use
> > of this data.
> >
> > As a network traffic monitoring and analysis software vendor, InMon
> > Corp. is
> > very interested in promoting standard measurement functionality in
> > switching
> > ASICs so that network hardware is capable of providing basic information
> > in
> > a consistent format. Some of the techniques mentioned are consistent
> > with a
> > technology (sFlow RFC 3176) that we have developed and successfully
> > deployed
> > in large scale enterprise and xSP environments, specifically:
> >
> > Selection of packets for measurement: random 1 in N count-based sampling
> > Measurement export mechanism: unreliable, stateless - each exported
> > packet
> > is self contained
> > Content and format of exported data: eg Data export packet specification
> > which includes packet header, router state parameters, and sampling
> > process
> > information for scaling.
> >
> > For the applications that we have been interested in (operational
> > control:
> > congestion contol, troubleshooting, security threat characterization,
> > accounting for capacity planning and billing etc., routing policy
> > optimization) we have not found a need for filtering and hashing for
> > packet
> > selection and so cannot comment on these techniques. We have also found
> > that, for our applications, with a measurement and analysis system
> > design
> > based on 1 in N random sampling with immediate forwarding of the data,
> > an
> > unreliable data export mechanism is ideal. Such a system has many
> > benefits.
> > For example it provides detailed, reliable, and timely information, is
> > cost
> > effective for embedded implementation, and has low network overhead.
> >
> > It seems that PSAMP could make a significant contribution by building
> > concensus on basic mechanisms that should be incorporated in ASICs (eg
> > sampling, filtering and hashing algorithms) and how they are specified
> > and
> > parameterised.
> >
> > The filtering, sampling and hashing functions are somewhat orthogonal to
> > the
> > data export functions. You could export sampled, filtered, and hashed
> > data
> > using any of the existing flow export protocols (e.g. IPFIX, NetFlow,
> > LFAP,
> > RTFM, sFlow etc). There are many applications for sampled data and the
> > variety of export protocols reflects these different objectives.
> >
> > Sonia Panchen
> > InMon Corp
> > sonia_panchen@inmon.com
> >
> >
> >
> >
> > --
> > to unsubscribe send a message to psamp-request@ops.ietf.org with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://ops.ietf.org/lists/psamp/>
> >
>
>
> Albert Greenberg; AT&T Labs-Research; Florham Park, NJ 07932-0971
>
>
> --
> to unsubscribe send a message to psamp-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/psamp/>
>


--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>