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

From: ramki Krishnan <[email-masked]>
Date: Sun, 17 Feb 2013 22:41:35 -0800

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: [email-masked] [mailto:[email-masked]] 
Sent: Sunday, February 17, 2013 2:36 PM
To: ramki Krishnan
Cc: [email-masked]
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

---

From: Brian Trammell <[email-masked]>
Date: Mon, 18 Feb 2013 08:49:06 +0100

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 <[email-masked]> wrote:

> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: ramki Krishnan <[email-masked]>
Date: Mon, 18 Feb 2013 08:34:14 -0800

Hi Brian,

Thanks a lot for your comments. Please find responses inline.

Thanks,
Ram

-----Original Message-----
From: Brian Trammell [mailto:[email-masked]] 
Sent: Sunday, February 17, 2013 11:49 PM
To: ramki Krishnan
Cc: [email-masked]; David Meyer; [email-masked]
Subject: Re: [IPFIX] New Version Notification for draft-krishnan-ipfix-flow-aware-packet-sampling-01.txt

Hi, Ram,

[ramki Krishnan] Thanks, will do.

[ramki Krishnan] Thanks for the reference, will add the applicability statement also. By any chance, could you please share a copy of the paper ?

 [ramki Krishnan] The aim was to keep the flow information export formats generic -- since this draft is being pursued in the IPFIX working group, it is worth narrowing it down to IPFIX as you suggested.

 [ramki Krishnan] The aim is to identify gaps in standardization in dependent areas -- encaps for which IPFIX doesn't have IEs yet, would be a separate draft.

Best regards,

Brian