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

Hi Brian,

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

Thanks,
Ram

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

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. 

[ramki Krishnan] Thanks, will do.

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).

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

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? 

 [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.

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.

 [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

On Feb 18, 2013, at 7:41 AM, ramki Krishnan <[email protected]> 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: [email protected] [mailto:[email protected]] 
> Sent: Sunday, February 17, 2013 2:36 PM
> To: ramki Krishnan
> Cc: [email protected]
> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipfix

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