Feedback -2

[Cristian Estan <cestan@cs.ucsd.edu>]

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?

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".



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