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

["Will Eatherton" <will@cisco.com>]

Nick and group,

Here is our initial review of the psamp draft with questions and comments.
If a BOF gets set up for March IETF we would definitely be interested in
attending.

---------------

Comments on "draft-duffield-framework-papame-00"
	Michelle Ma (mma@cisco.com)
	Will Eatherton (will@cisco.com)
	Ganesh Sadasivan (gsadasiv@cisco.com)
	cisco systems - members of Core Routing Group

1.0 Motivation
	-- Example 1 :  For low speed links, is it true that non-sampled raw
netflow (cisco v5) would, if not eliminate, greatly reduce the flaws
mentioned for MIB type statistics averaged over several minute time periods
?  So should this example be qualified as a high speed link in which
non-sampled raw netflow  is not applicable ?  So this draft mainly targeted
at high speed links ?
	-- Example 1 : you mention MPLS FEC, is it the explicit target of this
proposal to encompass MPLS as part of this framework ?

	-- Example 2 : For this example, what are the issues with using an
aggregation method on the router (e.g. cisco v8 netflow ?)

	-- Example 3 : are there any published studies that present an empirical
study of how much in "error" off-line processing is for spatial flow of
traffic ?  There seem to be some in the community saying this works just
fine, and
others questioning the procedure.

2.0 Goals
	-- Does it make sense to have as a goal the use of IPFIX to transport the
data for this framework ?
	-- As a discussion topic, it seems there is going to be some levels of
overlap between the goals as stated for psamp and IPFIX.  Within IPFIX we
seem to be reaching conclusion that some level of specification of data
gathering options is needed in order to properly encode state about how data
was gathered (like sampling rate).


3.1 Measurement information flow

This terminology is a bit confusing. It's basically the control stream
between the measuring device and the collector. The description of the
"information flow" is a bit too abstract. Maybe it's meant to lay out less
details here?

3.2 Packet selection

The exact sensible combinations of hash/filtering/sampling and the kind of
applications for each combination would be interesting to enumerate.

-- Hashing

It may be helpful to briefly explain the rationale or application scenario
of hashing. If there is no need to uniquely identify a packet across
multiple devices, then hash may not be necessary?

My understanding is that within context of this effort you expect that an
exact hash function will need to be specified.  If so that goal needs be
explicitly communicated.  This will be an interesting (possibly difficult)
thing to do since the relative difficulty of the hash function will vary
platform to platform depending on the underlying architecture the vendor is
using for packet processing.

-- Filtering

Would there be a dynamic filtering scenario, where each filter installation
is triggered by packets dynamically rather than by configuration?

Within context of this framework do you expect to have explicit guidelines
on how many filtering functions makes sense ?  Large numbers of filters will
increase complexity, and has affect on the stated goal for "including in the
minimal set of primitives functions that can be implemented at maximal line
rate with minimal additional state".

-- Sampling

I guess it's fine to broadly categorize sampling schemes into deterministic
and probabilistic, but perhaps we should not confine deterministic to 1/N
and probabilistic to p(x)=1/N. There may be some sampling scheme requiring
more than one parameters, for example, the sampling probability can be
based on both N and packet length.

I think within each category, there could be yet another two modes:
stationary and adaptive, depending on whether the sampling parameters are
configured or dynamically adjusted based on traffic condition.

3.3 Report generation and export

I'm a bit confused about the "packet count" as part of the subsidiary
information. I thought this draft is about packet based measurement, not
flow based...

The collector device should be identified by both IP address and L4 port
number.

   3.4 Measurement Record Format

This is the section that mostly obviously has to to be considered/reviewed
in context of IPFIX.



to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.