Re: [IPFIX] New Version Notification for draft-krishnan-ipfix-flow-aware-packet-sampling-01.txt

Brian Trammell <trammell@tik.ee.ethz.ch> Mon, 18 February 2013 07:49 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 C0BDE21F8BAF for <ipfix@ietfa.amsl.com>; Sun, 17 Feb 2013 23:49:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.123
X-Spam-Level:
X-Spam-Status: No, score=-6.123 tagged_above=-999 required=5 tests=[AWL=0.476, 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 Lu8OL9OD4uW9 for <ipfix@ietfa.amsl.com>; Sun, 17 Feb 2013 23:49:11 -0800 (PST)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 8DFDF21F8B60 for <ipfix@ietf.org>; Sun, 17 Feb 2013 23:49:10 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 946FFD9304; Mon, 18 Feb 2013 08:49:08 +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 btoGdOnfJqf9; Mon, 18 Feb 2013 08:49:08 +0100 (MET)
Received: from [10.0.27.102] (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 31647D9305; Mon, 18 Feb 2013 08:49:08 +0100 (MET)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Brian Trammell <trammell@tik.ee.ethz.ch>
In-Reply-To: <C7634EB63EFD984A978DFB46EA5174F2BF4FF7E093@HQ1-EXCH01.corp.brocade.com>
Date: Mon, 18 Feb 2013 08:49:06 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <4CA8A9E3-4E44-473D-B7A6-88A55FEDD060@tik.ee.ethz.ch>
References: <20130217223618.23473.71237.idtracker@ietfa.amsl.com> <C7634EB63EFD984A978DFB46EA5174F2BF4FF7E093@HQ1-EXCH01.corp.brocade.com>
To: ramki Krishnan <ramk@Brocade.com>
X-Mailer: Apple Mail (2.1499)
Cc: David Meyer <dmm@1-4-5.net>, "ning.so@tatacommunications.com" <ning.so@tatacommunications.com>, "ipfix@ietf.org" <ipfix@ietf.org>
Subject: Re: [IPFIX] New Version Notification for draft-krishnan-ipfix-flow-aware-packet-sampling-01.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: Mon, 18 Feb 2013 07:49:12 -0000

Hi, Ram,

Thanks for the interesting draft. I have a couple of comments and questions thereon...

Section 2.1.3 appears to describe a counting Bloom filter using thresholding and periodic reset; it would be nice to point this out explicitly. 

The algorithm presented would seem to have the problem that effective filtered flow size is phase-dependent: that is, relatively smaller constant-rate flows beginning early within a counting Bloom filter reset interval would be detected with the same probability as relatively larger flows beginning toward the interval. This is not a problem for long big flows, but flows shorter than the reset interval and crossing a reset interval will be variably detected based on when they begin. 30 seconds (the interval in the example) is therefore probably toward the long end of what you can get away with for an interval.

You may want to have a look at Bianchi et al "Measurement Data Reduction through Variation Rate Metering", proc. INFOCOM 2010, which addresses this problem (with respect to key variation counting for scan detection flow prefiltering) using rotating conservative counting Bloom filters with periodic decay. If you're not concerned with borderline-big flows, and the phase dependence is acceptable, the technique presented there may not apply.

(On that, a clear applicability statement -- why would I want to do this, and in which application areas -- would be nice to see, too).

In section 6:

>    for exporting the identified large flows to an external
>    entity, it is recommended to use one of the protocols recommended in
>    evaluation of candidate protocols for IPFIX [RFC 3955]

Why recommend an RFC 3955 candidate protocol for large flow export, as opposed to IPFIX itself? 

Also in section 6:

>    For any
>    packet formats (for e.g. VXLAN, NVGRE) which are not covered by the
>    above RFCs, a flow export data model needs to be defined 

As I understand it, in isolating large flows, the various encapsulations are really more a problem for the MP's packet decode logic. How a packet is encapsulated is actually a separate problem from what information you want to export about each flow. Of course, if you're dealing with encaps that IPFIX doesn't have IEs for yet, you may want to define them so you can export information about them, but that seems to orthogonal to the aim of the draft.

Best regards,

Brian

On Feb 18, 2013, at 7:41 AM, ramki Krishnan <ramk@Brocade.com> wrote:

> Dear All,
> 
> The content of the draft has been substantially enhanced with simulation results for the suggested techniques. Looking forward to your comments. 
> 
> Thanks,
> Ram
> 
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
> Sent: Sunday, February 17, 2013 2:36 PM
> To: ramki Krishnan
> Cc: ning.so@tatacommunications.com
> Subject: New Version Notification for draft-krishnan-ipfix-flow-aware-packet-sampling-01.txt
> 
> 
> A new version of I-D, draft-krishnan-ipfix-flow-aware-packet-sampling-01.txt
> has been successfully submitted by ram krishnan and posted to the IETF repository.
> 
> Filename:	 draft-krishnan-ipfix-flow-aware-packet-sampling
> Revision:	 01
> Title:		 Flow Aware Packet Sampling Techniques
> Creation date:	 2013-02-17
> Group:		 Individual Submission
> Number of pages: 11
> URL:             http://www.ietf.org/internet-drafts/draft-krishnan-ipfix-flow-aware-packet-sampling-01.txt
> Status:          http://datatracker.ietf.org/doc/draft-krishnan-ipfix-flow-aware-packet-sampling
> Htmlized:        http://tools.ietf.org/html/draft-krishnan-ipfix-flow-aware-packet-sampling-01
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-krishnan-ipfix-flow-aware-packet-sampling-01
> 
> Abstract:
>   The demands on the networking infrastructure and thus the
>   switch/router bandwidths are growing exponentially; the drivers are
>   bandwidth hungry rich media applications, inter data center
>   communications etc. Using sampling techniques, for a given sampling
>   rate, the amount of samples that need to be processed is increasing
>   exponentially. This draft suggests flow aware sampling techniques for
>   handling various scenarios with minimal sampling overhead.
> 
> 
> 
> 
> The IETF Secretariat
> 
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix