Re: Feedback -2

[Nick Duffield <duffield@research.att.com>]

Cristian, comments inline, Nick

Cristian Estan wrote:
> 
> In this email I address topic 2 - things that I think must be put in
> the draft.
> 
> The one biggest thing I found missing is how exactly do we get from
> the filtered/sampled/hashed packets to reports. The draft must say
> how. For example we keep a byte and a packet counter for each source -
> destination address pair or whatever granularity we want. If we report
> results this way, we need to specify what fields we use to distinguish
> between "flows" and what exactly we count for each flow (number of
> bytes and number of packets are obvious things, but I will come up
> with more exotic, nevertheless useful things in email 3).
> 
> Another option is to report a log of the sampled/hashed/filtered
> packet headers. This is what we would want if we do something like
> "Trajectory Sampling for Direct Traffic Observation". If we go this
> way, we want to specify what gets included in the log: timestamp,
> which header fields, hash on which header fields, etc.
> 
> The draft should clearly define what time interval the records refer
> to. I know I just opened a can of worms, but I feel we should clean
> this one up. Probably no one likes the undocumented heuristics Cisco
> uses to decide when to consider that a flow ended. I believe there is
> an important distinction they didn't make: between the time interval
> the record refers to and the time when it is reported. Therefore they
> do things like artificially "terminate" flow records for flows that
> have been active for say 30 minutes so that they can report the
> records. Why not just report say every 5 minutes on the flows that
> have been active in the last 5 minutes, no matter whether they
> terminated or not?
> 

These are detailed matters that should be addressed, but in a later
draft, 
once the framework has been agreed upon.

> And there's the gray area about what to do to let the management
> station interpolate what was in the records that got dropped. Sequence
> numbers are fine, but we can do more, especially in the case when the
> measurement device drops the records because it reached its data rate
> limit. I personally wouldn't mind borrowing some ideas from "Charging
> from Sampled Network Usage".

Robustness w.r.t. missing data is a must; see the last bullet in Section
1: 

	o Allow robust interpretation of measurements with respect to
   	reports missing due to loss in transport, or omission at the
   	measurement device.

As well as this, selective export to intelligently manage the impact of 
export rate limits is not precluded.

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