Subject: [ipfix-data] Re: [ipfix] draft-ietf-ipfix-data-01.txt

From: Ganesh Sadasivan <[email-masked]>
Date: Fri, 14 Jun 2002 10:17:57 -0700 (PDT)

> Paul,
> See my response in line starting with [G].
> Thanks
> Ganesh
> 
> > 5.1. Flow Classification
> > 
> >    The collector MUST be able to map the flow to
the
> corresponding 
> >    property types defined by the flow type. This
can
> be done only if 
> >    the collector has a mapping from flow type
> identifier (carried in 
> >    each flow record) to its actual structure. More
> details of how 
> >    this can be achieved are described in section
> 5.???
> > 
> > 
> >    In addition the collector, when it receives the
> flow records, MAY 
> >    need the following to interpret the flow
records
> further:
> > 
> >       A. Observation Point.
> >       B. Selection Criteria of Packets
> > 
> >    As mentioned in section 2.1, a flow record can
be
> better analyzed 
> 
> [G] Notice that it mentioned that the flow
> can be "better analysed" and it is not a
> MUST. Eg. If 2 observation 
> point A,B are measuring in flows in 2 different
> ways say A is sampling 1 in 5 and B is sampling
> 1 in 25. The collector can better analyse the 
> information, if along with the flow information,
> the observation point is also specified.This is
> not something mandatory but is useful for a 
> detailed analysis.
> 
> >    if the Observation Point from which it is
> measured is known. As 
> >    such it is recommended that the flow record
carry
> the Observation 
> >    Point information along with the flow records
> when exported. In 
> >    cases where there is a single observation point
> or where the 
> >    observation point information is not relevant,
> the exporter MAY 
> >    choose not to add this to the flow records.
> > 
> 
> 	I don't understand this section. What is flow
> classification?
> 
> 	Also, A flow should be able to be interpreted
> regardless of 
> 	knowing the observation point. A single observation
> point may
> 	map flows in 2 or more different ways. The fact
that
> different 
> 	observation points map flows based on different
> criteria 
> 	is irrelevant. All the information needed to
> interpret the flow
> 	must be passed up. 
> 
> 
> > 5.2.1. Function on properties that determines a
flow
> type (Fi)
> > 
> >    Packets that satisfy a function on the fields
> defined by the 
> >    packet header fields or fields obtained while
> doing the packet 
> >    processing or the properties of the packet
> itself.
> > 
> >    Example:
> > 
> >    Mask/Match of the fields that define a filter.
> The filter may be 
> >    defined as {Protocol == TCP, Destination Port
> between 80 and 120}. 
> > 
> > 
> >    could be used in any sequence to select 
> >    packets.
> > 
> 
> 	I think it would it be better to say "Multiple such
> functions" 
> 	instead of filters?
> 
> > 5.3. Selection Criteria for flows for export
> > 
> >    The measurement device MAY define additional
> rules so that only 
> >    certain flows records are picked up for export.
> This MAY be done 
> >    by either of the two types of methods defined
in
> 5.2.1 and 
> >    5.2.2 or a combination of them.
> > 
> >    Example:
> > 
> >    Only the flow records which meet the following
> selection criteria 
> >    are exported.
> > 
> >       1 All flow records whose destination IP
> address matches
> >         {20.3.1.5}.
> >       2 Every other (.i.e. sampling rate 1 in 2)
> flow record whose
> >         destination IP address matches
{160.0.1.30}.
> > 
> 
> 
> 	I'm not sure I agree with this. I think you have
> defined
> 	2 flows in #1 and #2. 
> 
> [G] That is true.
> 
> Given that, both flows are exported.
> 	I think maybe the "Selection Criteria" is really
part
> of
> 	the Flow Type.
> 
> [G] It could be a post-flow-measurement criteria 
> also. So need not be fixed to flow-type.
> 
> >       * Packet Counter 
> >       * Dropped Packet Counter 
> >       * Byte Counter 
> >       * Dropped Byte Counter
> >       * Timestamp of the First Packet Observed 
> >       * Timestamp of the Last Packet Observed 
> 
> 	Generally the last time stamp is the time at which
> he flow has expired (as described earlier). 
> 
> The last
> 	packet observed is not available unless each packet
> 	is processed in software. So either we need another
> 	field or a different definition.
> 
> [G] Just curious. Why do we need a last-packet
>  observed field?
> 
> 
> > 
> >       * Unique ID of the Observation Point 
> >       * Unique ID of the Measuring Device 
> 
> 	As stated above, I disagree that these are part of
> flow definition.
> 
> 

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: Simon Leinen <[email-masked]>
Date: 24 Jun 2002 18:03:34 +0200

>>>>> On Fri, 14 Jun 2002 10:17:57 -0700 (PDT), Ganesh Sadasivan <[email-masked]> said:
>> Paul,
[...]

>> The last packet observed is not available unless each packet is
>> processed in software.

Hm, that would imply that "only software" can update a per-flow
timestamp for every packet.  But even when all per-packet accounting
work is done "in hardware", it must be possible to update (increment)
byte/octet counters for every packet.  So it should also be possible
to copy a timestamp to the flow.  All that's needed is that the
("hardware") flow-updater needs access to a clock, and that memory
bandwidth to the per-flow table is sufficient to support that copy.

>> So either we need another field or a different definition.

>> [G] Just curious. Why do we need a last-packet observed field?

Because it makes it easier to compute approximate rates of flows.
It also nicely supports charging schemes with a usage time component.
-- 
Simon.