Re: [IPFIX] Export of long lived flow information

Paul Aitken <paitken@cisco.com> Fri, 26 October 2012 19:20 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 49EF521F863F for <ipfix@ietfa.amsl.com>; Fri, 26 Oct 2012 12:20:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.524
X-Spam-Level:
X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 UWQJpU0CpeTN for <ipfix@ietfa.amsl.com>; Fri, 26 Oct 2012 12:20:55 -0700 (PDT)
Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 1A64821F860A for <ipfix@ietf.org>; Fri, 26 Oct 2012 12:20:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2780; q=dns/txt; s=iport; t=1351279253; x=1352488853; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=wxR6xrUOClD/o/D3c1lzIAAeTcm3eQb8tl/T7alHWoA=; b=acQ45xinbdugSonxZG0bndAGrG2yaiyxOFA7T7DbTCM72Es61lE+iB2B iPE8Q2d0m9/+6FK28Dct1fX0TF4ldjAEsoGL8MqLcqqw4IzOIuJRp4piI DIOui9b9wnQ0VlD31rUpLWbdLcYw5Eg08H62jKFQGaXSgEoGmYKKKPIaP A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAPrhilCQ/khL/2dsb2JhbABEwlaBCIIeAQEBAwESASVAAQULCyEWDwkDAgECAUUGDQEHAQEeh14GnGugE5JfA5VzhWaIbYFrgnA
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="9135825"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 26 Oct 2012 19:20:51 +0000
Received: from [10.55.82.156] (dhcp-10-55-82-156.cisco.com [10.55.82.156]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9QJKppm004622; Fri, 26 Oct 2012 19:20:51 GMT
Message-ID: <508AE290.3020902@cisco.com>
Date: Fri, 26 Oct 2012 20:20:48 +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 Feren <andrewf@plixer.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> <508AB8FB.3060807@plixer.com>
In-Reply-To: <508AB8FB.3060807@plixer.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 19:20:56 -0000

Andrew, Gerhard,

>> My understanding is that both, deltaCounts and totalCounts contain 
>> the number of packets or octets observed in the indicated time 
>> interval. So, for identical flowStart* and flowEnd* timestamps, the 
>> values are the same.
> This is my understanding as well.

There has to be a difference between delta and total counts, else we 
wouldn't have both of them!

Suppose we have a permanent cache, so the cache entries never expire.

For a new flow starting at t0 with a first export at t1, the timestamps, 
delta, and total counts are the same.

However with the second export at t2, the total and delta counts are 
different although their timestamps match (they'll both say, "t0 to t2").

With the traditional (non-permanent) cache, the entry would probably 
have been removed at t1 and re-created on a subsequent packet, so at t2 
the delta and total counts would both be equal. However it'd be 
incorrect to report the total count, because that's defined as the total 
number of packets or bytes ..."since the Metering Process 
(re-)initialization for this Observation Point".


>> However, the description of totalCounts says that you report the 
>> number of packets or octets observed for this Flow since 
>> re-initialization. So, you must never reset the counter for this 
>> Flow, even after observing a FIN or RST.
>> If you reset flow counters, or if you remove Flows from your Cache, 
>> you cannot use totalCounts any more unless you re-initialize the 
>> Metering Process (e.g. after flushing the entire permanent Cache).
>
> I can try some tests later, but from what I have seen (and been told) 
> many totals being exported are in fact just a delta sent once at the 
> end of the flow.  If a later flow had the same IPs, protocol, and 
> ports as an earlier flow I'm pretty sure a new start time will be sent 
> rather than the the first time that flow was seen since reinitializing 
> the metering process.

So the MP uses a traditional (non-permanent) cache. In RFC 6728 terms, a 
TimeoutCache or NaturalCache rather than a PermanentCache.


> Or to put it an other way I think deltas are being sent, but called 
> totals by the implementation because it seemed like the right thing to 
> do for a value being sent once at the end of the flow.

The collector could be aggregating deltas to keep running totals.


> I suspect that totals reporting on the export process (eg 
> exportedOctetTotalCount, exportedMessageTotalCount) are, however, 
> reported with a start time that is only reset on reinitialization.

Definitely, because these are defined as "The total number of X that the 
Exporting Process has sent since the Exporting Process 
(re-)initialization ...".

P.