Re: [IPFIX] Export of long lived flow information

[John Court <[e-mail]>]

Yep I think everyone is starting to see the ambiguity that needs to be 
cleared up :-)

Paul,

Definitely. If it's a permanent flow and you're exporting totalCount 
fields - which are measured "since the Metering Process 
(re-)initialization for this Observation Point" - then the flowStartTime 
must surely be the time the first ever packet was observed.

If you take that literally shouldn't that be interpreted to mean that the 
totalCount continues into the next time a connection is up between the 
same flow key ?  Even if a flowEndReason of :

 0x03: end of Flow detected
The Flow was terminated because the Metering Process
detected signals indicating the end of the Flow, for
example, the TCP FIN flag.

That clearly wouldn't be of much use IMO and makes it difficult to see 
what the flowEndReason field semantics mean in that context.  Just 
pointing out that taking that definition literally doesn't give a useful 
answer on its own either :-).  Although maybe that does make sense in a 
router context ?  Can you clarify this some more, perhaps you never intend 
using the flowEndReason IE in your case ?

Thanks





From:   Paul Aitken <[e-mail]>
To:     Andrew Johnson <[e-mail]>, 
Cc:     Gerhard Muenz <[e-mail]>, John 
Court/Australia/IBM@IBMAU, [e-mail]
Date:   25/10/2012 08:07
Subject:        Re: [IPFIX] Export of long lived flow information



Andrew,

> I was thinking that a mechanism that allowed a non-permanent flow to be 
exported multiple time would be useful.  For example, security 
applications generally want to know about a new flow ASAP, so they can act 
on the information, but a short active timeout values lead to using more 
export bandwidth.  I was thinking we could do something like export a 
report of the flow after the first packet, and then export the final 
version of the flow once the normal timeouts had decided it was over.

I have in the past discussed the idea of exporting a "new flow alert" 
using zero-valued counters in order to make the collector aware that 
we've started monitoring it - so I'm claiming prior art on that.


> I had in mind something like using a delta count, followed by a total 
count.  Reading the below definition of Total counts though, I'm not sure 
that will work, but I think it depends on how we interpret the definition 
of "Flow".  If two records have matching key fields but different starting 
timestamps, are they the same Flow?

5101 defines:

       A Flow is defined as a set of IP packets passing an Observation
       Point in the network during a certain time interval.


- so it's all about the timestamps :-)


> I would argue that a single Flow can't have two flowStartTimes, so maybe 
not.

However, two flows with different flowStartTimes can be merged into one 
flow.


> This would mean that we shouldn't reset the flowStartTimes between 
sending reports for the same permanent Flow.

Definitely. If it's a permanent flow and you're exporting totalCount 
fields - which are measured "since the Metering Process 
(re-)initialization for this Observation Point" - then the flowStartTime 
must surely be the time the first ever packet was observed.

P.