Re: [IPFIX] Export of long lived flow information
Gerhard Muenz <muenz@net.in.tum.de> Wed, 31 October 2012 07:52 UTC
Return-Path: <muenz@net.in.tum.de>
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 442F321F86F3 for <ipfix@ietfa.amsl.com>; Wed, 31 Oct 2012 00:52:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.019
X-Spam-Level:
X-Spam-Status: No, score=-5.019 tagged_above=-999 required=5 tests=[AWL=0.630, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_54=0.6, 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 Q1Bnj7y6ev2D for <ipfix@ietfa.amsl.com>; Wed, 31 Oct 2012 00:52:19 -0700 (PDT)
Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by ietfa.amsl.com (Postfix) with ESMTP id 003F621F86F1 for <ipfix@ietf.org>; Wed, 31 Oct 2012 00:52:14 -0700 (PDT)
Received: by mail.net.in.tum.de (Postfix, from userid 81) id 8965119A5899; Wed, 31 Oct 2012 08:52:11 +0100 (CET)
To: Brian Trammell <trammell@tik.ee.ethz.ch>
X-PHP-Originating-Script: 0:main.inc
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Wed, 31 Oct 2012 08:52:11 +0100
From: Gerhard Muenz <muenz@net.in.tum.de>
In-Reply-To: <03BF5948-51D3-417B-AD8A-5F6B678A9F46@tik.ee.ethz.ch>
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> <508AE290.3020902@cisco.com> <5b06f4caa55ce88df0f606fb59e19785@net.in.tum.de> <508FC64D.3000006@cisco.com> <03BF5948-51D3-417B-AD8A-5F6B678A9F46@tik.ee.ethz.ch>
Message-ID: <fc2afcef270e9c2916461e2021bb7bae@net.in.tum.de>
X-Sender: muenz@net.in.tum.de
User-Agent: Roundcube Webmail/0.6
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: Wed, 31 Oct 2012 07:52:20 -0000
Hi all, I scanned through the IANA registry and briefly checked occurrences of "this Flow". I do not think that we need change them in general, except for those IEs which define a measurement interval. So, we have: - flowStart* (including flowStartDeltaMicroseconds) - flowEnd* (including flowEndDeltaMicroseconds) - flowDuration* My first shot was the following change for absolute flowStart*/flowEnd* timestamps: OLD: The absolute timestamp of the first|last packet of this Flow. NEW: The absolute timestamp of the first|last packet accounted in this Flow Record. We could add a sentence clarifying that the Flow properties reported in this Flow Record refer to the given measurement interval. At the moment, I only find a good "negative" way to describe this: "If this Information Element is present in a Flow Record, Flow properties in this Flow Record do not refer to packets preceding|succeeding this timestamp." Do you have better suggestions? Or do you think that this clarification is not necessary? Regards, Gerhard On 30.10.2012 13:38, Brian Trammell wrote: > Hi, Paul, all, > > If someone throws together a quick summary of the position for me I'd > be happy make a couple of slides and do the presentation in person in > Atlanta. > > From where I sit, it looks like we just go ask IANA to make the > registry change. Wearing my IE-Doctors-author hat (I can't wear an IE > Doctor hat, there aren't any yet. :) ), I'd say this revision would > be > covered (and permissible) under point 2 in section 5.2 of ie-doctors. > > Best regards, > > Brian > > > On 30 Oct 2012, at 13:21 , Paul Aitken wrote: > >> Gerhard, >> >> I agree with your definitions. Thanks for clarifying. >> >> So what's the next step? >> >> * Update the IANA definitions? >> * Add clarifications to the WG documents? >> >> >> Do we need a short presentation at the upcoming WG meeting? >> >> P. >> >> >> On 30/10/12 11:51, Gerhard Muenz wrote: >>> Paul, >>> >>> On 26.10.2012 20:20, Paul Aitken wrote: >>>> 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"). >>> >>> No, this would contradict the new definition of flowStart* we are >>> just discussing. >>> If delta counts are exported for the interval (t1,t2), then >>> flowStart* is t1. >>> If delta counts are exported for the interval (t0,t2), then >>> flowStart* is t0. >>> If total counts are exported, flowStart is always t0. >>> These statements hold regardless of which type of cache is used by >>> the Metering Process. In general, the information model does not care >>> about how the cache is implemented. The exported information just >>> must follow the IE definition. >>> >>>> >>>> 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". >>> >>> You must not export total counters in this case because you reset >>> counters before re-initialization of the Metering Process. >>> >>> Thanks, >>> Gerhard >>> >>>> >>>> >>>>>> 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. >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix
- [IPFIX] Export of long lived flow information John Court
- Re: [IPFIX] Export of long lived flow information Brian Trammell
- Re: [IPFIX] Export of long lived flow information Andrew Johnson
- Re: [IPFIX] Export of long lived flow information Andrew Feren
- Re: [IPFIX] Export of long lived flow information Andrew Johnson
- Re: [IPFIX] Export of long lived flow information Tarun Saxena (tasaxena)
- Re: [IPFIX] Export of long lived flow information John Court
- Re: [IPFIX] Export of long lived flow information John Court
- Re: [IPFIX] Export of long lived flow information Brian Trammell
- Re: [IPFIX] Export of long lived flow information John Court
- Re: [IPFIX] Export of long lived flow information Brian Trammell
- Re: [IPFIX] Export of long lived flow information Paul Aitken
- Re: [IPFIX] Export of long lived flow information Paul Aitken
- Re: [IPFIX] Export of long lived flow information Andrew Feren
- Re: [IPFIX] Export of long lived flow information John Court
- Re: [IPFIX] Export of long lived flow information Gerhard Muenz
- Re: [IPFIX] Export of long lived flow information Paul Aitken
- Re: [IPFIX] Export of long lived flow information Andrew Johnson
- Re: [IPFIX] Export of long lived flow information Paul Aitken
- Re: [IPFIX] Export of long lived flow information John Court
- Re: [IPFIX] Export of long lived flow information Gerhard Muenz
- Re: [IPFIX] Export of long lived flow information John Court
- Re: [IPFIX] Export of long lived flow information Paul Aitken
- Re: [IPFIX] Export of long lived flow information Andrew Feren
- Re: [IPFIX] Export of long lived flow information Brian Trammell
- Re: [IPFIX] Export of long lived flow information Andrew Johnson
- Re: [IPFIX] Export of long lived flow information Andrew Feren
- Re: [IPFIX] Export of long lived flow information Paul Aitken
- Re: [IPFIX] Export of long lived flow information Paul Aitken
- Re: [IPFIX] Export of long lived flow information Paul Aitken
- Re: [IPFIX] Export of long lived flow information Paul Aitken
- Re: [IPFIX] [QUAR] Re: Export of long lived flow … Andrew Feren
- Re: [IPFIX] Export of long lived flow information Gerhard Muenz
- Re: [IPFIX] Export of long lived flow information Paul Aitken
- Re: [IPFIX] Export of long lived flow information Brian Trammell
- Re: [IPFIX] Export of long lived flow information Gerhard Muenz
- Re: [IPFIX] Export of long lived flow information Brian Trammell
- Re: [IPFIX] Export of long lived flow information John Court
- [IPFIX] Fw: Export of long lived flow information John Court
- Re: [IPFIX] Export of long lived flow information Brian Trammell