Re: [IPFIX] WG Last Call for draft-ietf-ipfix-information-model-rfc5102bis-05.txt

Brian Trammell <trammell@tik.ee.ethz.ch> Thu, 01 November 2012 06:35 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 4D28E21F851B for <ipfix@ietfa.amsl.com>; Wed, 31 Oct 2012 23:35:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.422
X-Spam-Level:
X-Spam-Status: No, score=-6.422 tagged_above=-999 required=5 tests=[AWL=0.177, 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 ja5H5+Ul-WYq for <ipfix@ietfa.amsl.com>; Wed, 31 Oct 2012 23:35:08 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id A554E21F84AE for <ipfix@ietf.org>; Wed, 31 Oct 2012 23:35:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 14A1CD930A; Thu, 1 Nov 2012 07:35:07 +0100 (MET)
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 hijp+zD38rQf; Thu, 1 Nov 2012 07:35:06 +0100 (MET)
Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (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 B8140D9305; Thu, 1 Nov 2012 07:35:06 +0100 (MET)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="iso-8859-1"
From: Brian Trammell <trammell@tik.ee.ethz.ch>
In-Reply-To: <5091422B.9070607@cisco.com>
Date: Thu, 01 Nov 2012 07:35:05 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <48C58B9E-EE52-415D-896F-AA15F8B7A6C4@tik.ee.ethz.ch>
References: <506CBFE3.10607@auckland.ac.nz> <5090547C.5020803@cisco.com> <F37F4EC6-E7AB-4975-93A7-82B7CDCD13EF@tik.ee.ethz.ch> <5091271E.3050206@cisco.com> <68907E1B-1D38-4F3A-B0E0-F47628F989F0@tik.ee.ethz.ch> <50913BF3.2080408@cisco.com> <8ED0D683-536C-46B6-8E5A-3CC3B7CB678F@tik.ee.ethz.ch> <5091422B.9070607@cisco.com>
To: Paul Aitken <paitken@cisco.com>
X-Mailer: Apple Mail (2.1283)
Cc: Nevil Brownlee <n.brownlee@auckland.ac.nz>, IPFIX Working Group <ipfix@ietf.org>
Subject: Re: [IPFIX] WG Last Call for draft-ietf-ipfix-information-model-rfc5102bis-05.txt
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: Thu, 01 Nov 2012 06:35:09 -0000

On Oct 31, 2012, at 4:22 PM, Paul Aitken wrote:

> Brian,
> 
>> What verb does the MP apply to a unit of information when it gives it to the EP?
>> 
>> A delta counter counts only observations made since the last Flow Record for a given Flow was measured.
>> 
>> Or maybe we can sidestep the action completely:
>> 
>> A delta counter counts only observations made since the previous Flow Record for a given Flow.
> 
> No, that's still involving export.
> 
> What should the MP do if the flow ends *but isn't exported* ?

In the idealized architecture, the MP can't know, so it just keeps exporting, clearly. If your implementation allows loss between the MP and the EP, there is nothing conceptually different between this situation and loss between the EP and the CP, except you can't use wireshark to debug it. :)

> Just the same as when the flow *is* exported. So the definition of deltaCount is independent of export, flow records, etc.
> 
> So the definitions have to be about the metering time, and particularly that we've started metering again. However, we can't write that, because some implementations may not hold state that tells them this. So all we know is that totalCounters meter from the start of the MP, while delta counters meter a potentially shorter interval, reporting the value metered since the start of that interval.

I've stared at this for a while and I can't come up with a way to express it that's unconvoluted enough for my taste. I still don't see why my last attempt at a definition above necessarily invokes export -- it's the MP sending on the information in a proto-Flow Record to the EP and deciding to start the counters over. So I suppose for the corner case that the MP sends something up to the EP and the EP drops it we could complicate the language a bit:

A delta counter counts only observations made since the previous Flow Record for a given Flow, as seen from the point of view of the Metering Process (i.e., discounting any failure or refusal to export the Flow Record on the part of the Exporting Process or failure to receive the Flow Record on the part of the Collecting Process).

although truth be told I think this overly complicated and unreadable for the magnitude of the corner case it addresses. Maybe without the i.e. phrase?

Cheers,

Brian