[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on "draft-duffield-framework-papame-00"
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
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
> to agree on a a set of capabilities that would be useful for providing
> network traffic monitoring and analysis required for operational network
> management tasks.
> As such it describes a number of interesting goals, philosophies,
> Provision of reliable, detailed, timely traffic measurements
> Promotion of widespread embedded traffic measurement mechanisms by
> simple and cost effective monitoring techniques.
> Pervasive measurement technology with consistent and well defined
> will encourage development of a broad spectrum of applications that make
> of this data.
> As a network traffic monitoring and analysis software vendor, InMon
> Corp. is
> very interested in promoting standard measurement functionality in
> ASICs so that network hardware is capable of providing basic information
> a consistent format. Some of the techniques mentioned are consistent
> with a
> technology (sFlow RFC 3176) that we have developed and successfully
> 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
> is self contained
> Content and format of exported data: eg Data export packet specification
> which includes packet header, router state parameters, and sampling
> information for scaling.
> For the applications that we have been interested in (operational
> 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
> selection and so cannot comment on these techniques. We have also found
> that, for our applications, with a measurement and analysis system
> based on 1 in N random sampling with immediate forwarding of the data,
> unreliable data export mechanism is ideal. Such a system has many
> For example it provides detailed, reliable, and timely information, is
> 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
> The filtering, sampling and hashing functions are somewhat orthogonal to
> data export functions. You could export sampled, filtered, and hashed
> 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
> to unsubscribe send a message to firstname.lastname@example.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 email@example.com with
the word 'unsubscribe' in a single line as the message text body.