Re: [IPFIX] Export of long lived flow information

Paul Aitken <paitken@cisco.com> Fri, 26 October 2012 20:21 UTC

Return-Path: <paitken@cisco.com>
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 E6F7A21F85EA for <ipfix@ietfa.amsl.com>; Fri, 26 Oct 2012 13:21:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 Hzg9rnttr90H for <ipfix@ietfa.amsl.com>; Fri, 26 Oct 2012 13:21:19 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2124121F85C1 for <ipfix@ietf.org>; Fri, 26 Oct 2012 13:21:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2054; q=dns/txt; s=iport; t=1351282879; x=1352492479; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=WQ+apyrLwPeOOrQfI4zDifTD+BDRKAdR2yYpvSCdg2Y=; b=b2PsJSj8iO10AM2J2Udplh0SiFrq566aE5+B21lQuY2smdmQMA0NbXUR +SGt8ArNH57nmNkJ5zx1qF6Y4jhkPjxGDaJePVCyBPAtsVW9NZaGEfC7L kMQtSLFWVJdPbEk6KDXtjwN8Tvk/dHcFymPNK4CdTR1nSR5ax3uAOf0Sm Y=;
X-IronPort-AV: E=Sophos;i="4.80,656,1344211200"; d="scan'208";a="135834460"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 26 Oct 2012 20:21:18 +0000
Received: from [10.55.82.156] (dhcp-10-55-82-156.cisco.com [10.55.82.156]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9QKLHKK024277; Fri, 26 Oct 2012 20:21:17 GMT
Message-ID: <508AF0BD.9070509@cisco.com>
Date: Fri, 26 Oct 2012 21:21:17 +0100
From: Paul Aitken <paitken@cisco.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: Andrew Johnson <andrjohn@cisco.com>
References: <OF96D061AA.F7F6CDD4-ONCA257AA0.00772818-4A257AA0.0078DF60@au1.ibm.com> <D50FAC55-C109-4A96-A471-538F27F9C2D9@tik.ee.ethz.ch> <OF30095AE1.689CF5C8-ONCA257AA1.001FB2C7-4A257AA1.00211D2B@au1.ibm.com> <5087B96B.7020500@cisco.com> <OFE375B6D9.49AD261E-ONCA257AA1.00703303-4A257AA1.00708F09@au1.ibm.com> <508850F7.2080801@net.in.tum.de> <50885B49.6050603@cisco.com> <DE1ABD89-26A9-485E-893A-3160C6F671A6@cisco.com> <5088666F.1090106@cisco.com> <OF4B5A9A3A.F88C734E-ONCA257AA2.0005120F-4A257AA2.0005F365@au1.ibm.com> <50898454.2000706@net.in.tum.de> <OF9FA62110.C222915A-ONCA257AA2.00764D83-4A257AA2.00772B6F@au1.ibm.com> <04A22782-E8DE-4FFB-A31C-8DC9FAC8FDDE@cisco.com>
In-Reply-To: <04A22782-E8DE-4FFB-A31C-8DC9FAC8FDDE@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: John Court <johnwcrt@au1.ibm.com>, 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: Fri, 26 Oct 2012 20:21:20 -0000

Andrew,

> A flow is defined as a set of packets which all have some common 
> properties, and the original idea of a flow was based on the common 
> 5-tuple of IP address, IP protocol and ports.  A Flow Record is formed 
> from any observation of packets belonging to a Flow (not all packets 
> within the flow are necessarily observed).
>
> If my PC opens an HTTP connection to some server and downloads a 
> simple web page, then we'd expect to see one traditional flows (per 
> direction, but ignore that for now).  If I open a new HTTP connection 
> to the same server, and coincidentally use the same source port, weeks 
> later, is that the same flow?

Per RFC 5101:

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


So if you define different time intervals (eg, "last week", "this week", 
and "next week") then yes, you've got two different flows there.

Whereas, if you define a interval which encompasses both of your 
connections, then you've only got one flow. And if your flow is going to 
last for weeks, then I hope you're reporting intermediate values.


> I had always thought of these as two flows, and the flowEndReason 
> implies it, but that would introduce some sort of time property as one 
> of the common property shared by the packets that make up a flow.  A 
> collector might aggregate the two reports, but removing the time 
> property is much like any other form of aggregation.

The time property is built in to the RFC 5101 definition.

P.


> It seems to me that we're using the timeout values of the cache as a 
> sort of ill-defined common property, but things get confusing when we 
> export total counts, or because the cache is low on resources, etc. 
>  Ideally, we'd want to be able to send more than one Flow Record for 
> the same Flow and provide enough information for the Collector to 
> reconstruct what the Monitoring Process is using to define a Flow.
>
>
> Cheers, Andrew