Re: [IPFIX] Export of long lived flow information

Brian Trammell <trammell@tik.ee.ethz.ch> Tue, 23 October 2012 07:43 UTC

Return-Path: <trammell@tik.ee.ethz.ch>
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E3121F863F for <ipfix@ietfa.amsl.com>; Tue, 23 Oct 2012 00:43:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.71
X-Spam-Level:
X-Spam-Status: No, score=-6.71 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcRTeJTmm03o for <ipfix@ietfa.amsl.com>; Tue, 23 Oct 2012 00:43:18 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 6874B21F863A for <ipfix@ietf.org>; Tue, 23 Oct 2012 00:43:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 6D8C4D9312; Tue, 23 Oct 2012 09:43:17 +0200 (MEST)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3C7VHoNng7QK; Tue, 23 Oct 2012 09:43:17 +0200 (MEST)
Received: from [10.0.27.100] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 2D1F9D930B; Tue, 23 Oct 2012 09:43:17 +0200 (MEST)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="us-ascii"
From: Brian Trammell <trammell@tik.ee.ethz.ch>
In-Reply-To: <OFBEE7B680.CE11B7E3-ONCA257AA0.0001FAB7-4A257AA0.0005B27D@au1.ibm.com>
Date: Tue, 23 Oct 2012 09:43:12 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <C9BF46B8-129C-4D96-8A35-F5F5DE2390F0@tik.ee.ethz.ch>
References: <OFBEE7B680.CE11B7E3-ONCA257AA0.0001FAB7-4A257AA0.0005B27D@au1.ibm.com>
To: John Court <johnwcrt@au1.ibm.com>
X-Mailer: Apple Mail (2.1283)
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] Export of long lived flow information
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipfix>
List-Post: <mailto:ipfix@ietf.org>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Oct 2012 07:43:19 -0000

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
> IBM Security Systems Division
> IBM Australia Development Laboratory
> Office:  +61 7 5552 4014
> Mobile: +61 430 841328
> 
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix