[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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,
Feb 2002, Sonia Panchen

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