Subject: [IPFIX] Export of long lived flow information

From: John Court <[email-masked]>
Date: Tue, 23 Oct 2012 11:01:31 +1000

Hi,

I have been a subscriber to the list for a little over a year, and an 
implementer of IPFIX export for at least one product.  This WG has done 
great work overall !

One area that still has me a little confused even after researching as 
many of the RFCs as possible including RFC5472 is how to treat export of 
long lived flows.

At the moment I use "DeltaCount" information elements for everything and 
at specific intervals export long lived flows with the flowEndReason of 
"flowActiveTimeout".  This of course results in multiple flow records for 
long lived connections over time.  Since this situation doesn't seem to be 
covered explicitly I was hoping someone on the list would point me in the 
right direction or confirm my assumptions.  On thing that is particularly 
unclear is what to do about flowStart/flowEnd times when sending this type 
of record.

Thanks

John Court
Senior Software Engineer
IBM Security Systems Division
IBM Australia Development Laboratory
Office:  +61 7 5552 4014
Mobile: +61 430 841328

---

From: Brian Trammell <[email-masked]>
Date: Tue, 23 Oct 2012 09:43:12 +0200

Hi, John,

Your assumptions are basically correct. The IPFIX model of a Metering Process (MP) makes an implicit assumption that it will be configured or configurable to export information about long-lived flows every n minutes through active timeout. From the MP side, this allows periodic complete flushing of the flow cache. 

More importantly (IMO), on the Collecting Process (CP) side, it provides a guarantee that every packet observed and selected for export will be accounted for within Ta + Tde + Tdc, where Ta is the active timeout, Tde is the MP to EP delay (how long it takes for an exported flow to make it from the MP cache, through the Exporting Process (EP), into an IPFIX Message, which is implementation dependent but typically short) and Tde is the export delay (OWD from EP to CP). This is important for streaming process applications, as after this time, the CP and downstream processes can assume that no further information about the past will become available.

The tradeoff here is that shorter Ta causes more records to be exported about long flows, and a longer Ta causes a longer delay, which some streaming applications can't tolerate.

In any case, the assumption is that the flow is no longer in the cache after active timeout, so you don't know when the flow really started. Since the flowStartTime is the timestamp of the first observed packet within the record, and flowEndTime is the timestamp of the last observed packet within the record, the timestamps would then be record-local.... i.e. a flow less than twice the active timeout (with at least one packet per idle timeout) would result in two flow records. The first would have a timestamp range between the first packet of the flow and the last packet observed before the active timeout; the second between the first packet observed after the active timeout and the last packet of the flow.

This does, admittedly, make it rather difficult to stitch records for long flows together -- you can't match timestamps, and essentially need to simulate the flow cache with a longer active timeout. For applications requiring a single record per flow, active timeouts can be set to be practically infinite, with the tradeoff that you never know at the CP when you'll get a flow with a start time far in the past.

Best regards,

Brian

On Oct 23, 2012, at 3:01 AM, John Court wrote:

> Hi, 
> 
> I have been a subscriber to the list for a little over a year, and an implementer of IPFIX export for at least one product.  This WG has done great work overall ! 
> 
> One area that still has me a little confused even after researching as many of the RFCs as possible including RFC5472 is how to treat export of long lived flows. 
> 
> At the moment I use "DeltaCount" information elements for everything and at specific intervals export long lived flows with the flowEndReason of "flowActiveTimeout".  This of course results in multiple flow records for long lived connections over time.  Since this situation doesn't seem to be covered explicitly I was hoping someone on the list would point me in the right direction or confirm my assumptions.  On thing that is particularly unclear is what to do about flowStart/flowEnd times when sending this type of record. 
> 
> Thanks 
> 
> John Court
> Senior Software Engineer
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Andrew Johnson <[email-masked]>
Date: Tue, 23 Oct 2012 09:42:21 +0100

Hi folks

I've been thinking for a while now that we should be able to send a mixture of delta and update records for the same flow, but I haven't really figured out how to make the semantics obvious to the collector.

i.e.:    Delta (new record), update, update, update(ends the flow)

Perhaps we could use the flow end reason to make things more explicit.  For example, all but the last packet have a flowEndReason of 0 and then the last one updates the reason.

Would this sort of thing be useful?  Would collectors be able to work with it?

Cheers, Andrew

---

From: Andrew Feren <[email-masked]>
Date: Tue, 23 Oct 2012 09:19:19 -0400

Hi Andrew,

I'm not sure I understand your question.

How is a delta different than an update?

Specific to flowEndReason rather than sending 0 each update should 
include the reason (e.g. 0x02 active timeout).  Do you have some 
situation in mind where a flow is being exported for an unknown reason?  
Or is the reason known,  but it doesn't fit one of the 5 currently defined?

-Andrew

---

From: Andrew Johnson <[email-masked]>
Date: Tue, 23 Oct 2012 15:16:32 +0100

Hi Andrew

When using a permanent cache, the flows can be sent periodically using update (as opposed to delta) counters.  The idea is that the Collector can be kept up to date without actually ageing out the flow, so there is no flow end reason.  Updates send the latest state of the flow, which is preferable to deltas because the Exporting Device doesn't need to store the state of what was last sent (or reset it's internal counters) and if an update gets lost (e.g. with UDP) then the next update will ensure the Collector gets the full counts.

I am wondering if there is a use case for periodically sending the state of the flow (using update counters) for long lived flows that will be aged out at some point in the future.

Cheers, Andrew

On 23 Oct 2012, at 14:19, Andrew Feren wrote:

> Specific to flowEndReason rather than sending 0 each update should include the reason (e.g. 0x02 active timeout).  Do you have some situation in mind where a flow is being exported for an unknown reason?  Or is the reason known,  but it doesn't fit one of the 5 currently defined?
> 
> -Andrew
>

---

From: "Tarun Saxena (tasaxena)" <[email-masked]>
Date: Tue, 23 Oct 2012 21:35:06 +0000

Hello Andrew,

Are you proposing a new value for flowEndReason, say 0x6 which denotes that the flow has not ended (hence not flushed from the cache). The packet/byte counters are relative to the beginning of the flow and not delta from the last flow export.

What will be the value of flowStartTime and flowEndTime in this case?

How will these fields look like when a flow has to be exported due to wrapping around of counters? Forced end?

Thanks
Tarun

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Johnson (andrjohn)
Sent: Tuesday, October 23, 2012 7:47 PM
To: Andrew Feren
Cc: [email-masked]
Subject: Re: [IPFIX] Export of long lived flow information

Hi Andrew

Cheers, Andrew

---

From: Andrew Feren <[email-masked]>
Date: Wed, 24 Oct 2012 14:10:20 -0400

Hi Andrew,

So we aren't really talking about a mixture of deltas and updates, but 
totalCounters refreshed at regular intervals and shifting the 
responsibility of calculating deltas from the EP to the CP.

To answer your question though

"Would collectors be able to work with it?"
There isn't any reason I can see that this can't work, but I'm not sure 
how many current CPs will do anything useful with the extra totals.

A few thoughts in no particular order.

  * if you are worried about losing packets there are other transports
    available than UDP.
  * I'd rather get updates as deltas.
  * having no updates for a long time can cause data to be inaccurate
    when trying to diagnose a problem now as there may be many flows
    that are active, but haven't reported anything.
  * depending on how long it might be before a total is sent refreshing
    the totals periodically is probably a good thing

-Andrew