Subject: Re: [IPFIX] Any last comments on draft-ietf-ipfix-flow-selection-tech-07 ???

From: Paul Aitken <[email-masked]>
Date: Mon, 05 Sep 2011 20:35:11 +0100

Nevil, All,

> There hasn't been any comment on the selection draft for nearly a
> month - as long as I don't hear any by next Monday, I'll declare
> its WG Last Call finished and send its write-up to Dan.

Sorry for the late response.

Please find many comments inline. I'd like to see a new version of this 
draft.

Thanks,
P.

>
> Internet Engineering Task Force                             S. D'Antonio
> Internet-Draft                                     University of Napoli
> Intended status: Standards Track                            "Parthenope"
> Expires: January 12, 2012                                       T. Zseby
>                                                Fraunhofer Institute FOKUS
>                                                                  C. Henke
>                                             Technische Universitat Berlin
>                                                                 L. Peluso
>                                                      University of Napoli
>                                                             July 11, 2011
>
>
>                         Flow Selection Techniques
>                draft-ietf-ipfix-flow-selection-tech-07.txt
>
> Abstract
>
>     Flow selection is the process of selecting a subset of flows from all
>     flows observed at an observation point.  Flow selection reduces the

Is just one OP allowed, or can they be observed at multiple observation 
points?
eg, consider flow selection in a mediation device.

>     effort of post-processing flow data and transferring Flow Records.
>     This document describes motivations for flow selection and presents
>     flow selection techniques.  It provides an information model for
>     configuring flow selection techniques and discusses what information
>     about a flow selection process should be exported.
>
> Requirements Language
>
>     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>     document are to be interpreted as described in RFC 2119 [RFC2119].
>
> Status of this Memo
>
>     This Internet-Draft is submitted in full conformance with the
>     provisions of BCP 78 and BCP 79.
>
>     Internet-Drafts are working documents of the Internet Engineering
>     Task Force (IETF).  Note that other groups may also distribute
>     working documents as Internet-Drafts.  The list of current Internet-
>     Drafts is at http://datatracker.ietf.org/drafts/current/.
>
>     Internet-Drafts are draft documents valid for a maximum of six months
>     and may be updated, replaced, or obsoleted by other documents at any
>     time.  It is inappropriate to use Internet-Drafts as reference
>     material or to cite them other than as "work in progress."
>
>     This Internet-Draft will expire on January 12, 2012.
>
>
>
>
> D'Antonio, et al.       Expires January 12, 2012                [Page 1]
> 
> Internet-Draft          Flow Selection Techniques              July 2011
>
>
> Copyright Notice
>
>     Copyright (c) 2011 IETF Trust and the persons identified as the
>     document authors.  All rights reserved.
>
>     This document is subject to BCP 78 and the IETF Trust's Legal
>     Provisions Relating to IETF Documents
>     (http://trustee.ietf.org/license-info) in effect on the date of
>     publication of this document.  Please review these documents
>     carefully, as they describe your rights and restrictions with respect
>     to this document.  Code Components extracted from this document must
>     include Simplified BSD License text as described in Section 4.e of
>     the Trust Legal Provisions and are provided without warranty as
>     described in the Simplified BSD License.
>
>     This document may contain material from IETF Documents or IETF
>     Contributions published or made publicly available before November
>     10, 2008.  The person(s) controlling the copyright in some of this
>     material may not have granted the IETF Trust the right to allow
>     modifications of such material outside the IETF Standards Process.
>     Without obtaining an adequate license from the person(s) controlling
>     the copyright in such materials, this document may not be modified
>     outside the IETF Standards Process, and derivative works of it may
>     not be created outside the IETF Standards Process, except to format
>     it for publication as an RFC or to translate it into languages other
>     than English.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> D'Antonio, et al.       Expires January 12, 2012                [Page 2]
> 
> Internet-Draft          Flow Selection Techniques              July 2011
>
>
> Table of Contents
>
>     1.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
>     2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
>     3.  Difference between Flow Selection and Packet Selection . . . .  7
>     4.  Flow selection as a Function in the IPFIX Architecture . . . .  8
>       4.1.  Flow selection during the Metering Process . . . . . . . . 10
>       4.2.  Flow selection during the Exporting Process  . . . . . . . 10
>       4.3.  Flow selection as a function of the IPFIX Mediator . . . . 10
>     5.  Flow Selection Techniques  . . . . . . . . . . . . . . . . . . 11
>       5.1.  Flow Filtering . . . . . . . . . . . . . . . . . . . . . . 11
>         5.1.1.  Property Match Filtering . . . . . . . . . . . . . . . 11
>         5.1.2.  Hash-based Flow Filtering  . . . . . . . . . . . . . . 11
>       5.2.  Flow Sampling  . . . . . . . . . . . . . . . . . . . . . . 12
>         5.2.1.  Systematic sampling  . . . . . . . . . . . . . . . . . 12
>         5.2.2.  Random sampling  . . . . . . . . . . . . . . . . . . . 12
>       5.3.  Flow-state Dependent Flow Selection  . . . . . . . . . . . 13
>       5.4.  Flow-state Dependent Packet Selection  . . . . . . . . . . 13
>     6.  Configuration of Flow Selection Techniques . . . . . . . . . . 14
>       6.1.  Description of Flow Selection Techniques . . . . . . . . . 15
>       6.2.  Description of Flow-state Dependent Packet Selection . . . 17
>     7.  Information Model for Flow Selection Reporting . . . . . . . . 17
>       7.1.  fsFlowRecordTotalCount . . . . . . . . . . . . . . . . . . 18
>       7.2.  fsFlowRecordSelectedCount  . . . . . . . . . . . . . . . . 19
>       7.3.  fsPacketTotalCount . . . . . . . . . . . . . . . . . . . . 19
>       7.4.  fsPacketSelectedCount  . . . . . . . . . . . . . . . . . . 19
>       7.5.  fsOctetTotalCount  . . . . . . . . . . . . . . . . . . . . 19
>       7.6.  fsOctetSelectedCount . . . . . . . . . . . . . . . . . . . 20
>     8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
>     9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
>     10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
>       10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
>       10.2. Informative References . . . . . . . . . . . . . . . . . . 21
>     Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> D'Antonio, et al.       Expires January 12, 2012                [Page 3]
> 
> Internet-Draft          Flow Selection Techniques              July 2011
>
>
> 1.  Scope
>
>     This document describes flow selection techniques for network traffic
>     measurements.  A flow is defined as a set of packets with common
>     properties as described in [RFC5101].  Flow selection can be done to
>     limit the resource demands for capturing, storing, exporting and
>     post-processing of Flow Records.  It also can be used to select a
>     particular set of flows that are of interest to a specific
>     application.  This document provides a categorization of flow
>     selection techniques and describes configuration and reporting
>     parameters for them.  In order to be compliant with this document, at
>     least one of the flow selection schemes MUST be implemented.  That
>     means that the configuration parameters as well as the reporting
>     Information Elements for this particular scheme MUST be supported.
>
>     This document also addresses configuration and reporting parameters
>     for flow-state dependent packet selection as described in [RFC5475],
>     although this technique is categorized as packet selection.  The
>     reason is, that flow-state dependent packet selection techniques
>     often aim at the reduction of resources for flow capturing and flow
>     processing.  Furthermore, they were only briefly discussed in
>     [RFC5475].  Therefore we included configuration and reporting
>     considerations for such techniques in this document.
>
>
> 2.  Terminology
>
>     This document is consistent with the terminology introduced in
>     [RFC5101], [RFC5470], [RFC5475] and [RFC3917].  As in [RFC5101] and
>     [RFC5476], the first letter of each IPFIX-specific and PSAMP-specific
>     term is capitalized along with the flow selection specific terms
>     defined here.
>
>     * Packet Classification
>
>        Packet Classification is a process by which packets are mapped to
>        specific Flow Records based on packet properties or external
>        properties (e.g. interface).  The properties make up the Flow Key
>        (e.g. header information, packet content, AS number).  In case a

"The properties (e.g. header information, packet content, AS number) 
make up the Flow Key."

>        Flow Record for a specific Flow Key already exists the Flow Record
>        is updated, otherwise a new Flow Record is created.
>
>     * Packet Aggregation Process
>
>        In the IPFIX Metering Process the Packet Aggregation Process
>        aggregates packet data into flow data and forms the Flow Records.
>        After the aggregation step only the aggregated flow information is
>        available.  Information about individual packets is lost.
>
>
>
> D'Antonio, et al.       Expires January 12, 2012                [Page 4]
> 
> Internet-Draft          Flow Selection Techniques              July 2011
>
>
>     * Flow Selection Process
>
>        A Flow Selection Process takes Flow Records as its input and
>        selects a subset of this set as its output.  A Flow Selection
>        Process MAY run on several instances within the IPFIX

s/on several instances/in several places/

>        architecture.  A Flow Selection Process MAY be part of an IPFIX
>        Metering Process, Exporting Process or as an Intermediate
>        Selection Process as defined for the IPFIX Mediator [RFC6183].
>
>     * Flow Selection State
>
>        A Flow Selection Process SHOULD maintain state information for use
>        by the Flow Selector.  At a given time, the Flow Selection State
>        may depend on flows and packets observed at and before that time,
>        as well as other variables.  Examples include:
>
>          (i)   sequence number of packets and accounted Flow Records;
>
>          (ii)  number of selected flows;
>
>          (iii) number of observed flows;
>
>          (iv)  current flow cache occupancy;
>
>          (v)   flow specific counters, lower und upper bounds

s/und/and/

>          (vi)  flow selection timeout intervals

Some of the list items end with ";" while others do not.

>     * Flow Selector
>
>        A Flow Selector defines the action of a Flow Selection Process on
>        a single flow of its input.  The Flow Selector can make use of the
>        following information in order to establish whether a flow has to
>        be selected or not:
>
>          (i)   the content of the Flow Record;
>
>          (ii)  any state information related to the Metering Process or
>                Exporting Process;
>
>          (iii) any Flow Selection State that may be maintained by the
>                Flow Selection Process.
>
>     * Complete Flow
>
>        A Complete Flow consists of all packets within the flow time-out
>        interval that enter the Flow Selection Process and belong to the

"A Complete Flow consists of all the packets that enter the
  Flow Selection Process within the flow time-out interval, and which 
belong to the ..."

>        same flow as defined by the flow definition in [RFC5470].  For
>
>
>
> D'Antonio, et al.       Expires January 12, 2012                [Page 5]
> 
> Internet-Draft          Flow Selection Techniques              July 2011
>
>
>        this definition only packets that arrive at the Flow Selection
>        Process are considered.  That means, packets that are not observed
>        at the Flow Selection Process because of prior packet selection or
>        packet loss are not considered as belonging to the Complete Flow.
>
>     * Flow Filtering
>
>        Flow Filtering selects flows based on a deterministic function on
>        the Flow Record content, flow state, external properties (e.g.

Does "flow state" mean "flow selection state"?
ie referring to the list just above, is it (ii), (iii), or both?

>        ingress interface) or external events (e.g violated Access Control
>        List).  If the relevant parts of the Flow Record content can be
>        already observed at packet level (e.g.  Flow Keys from packet

s/can be already/can already be/

>        header fields) Flow Filtering can be performed at packet level by
>        Property Match Filtering as described in [RFC5475].
>
>     * Hash-based Flow Filtering
>
>        Hash-based Flow Filtering is a deterministic flow filter function
>        that selects flows based on a Hash Function which is calculated
>        over parts of the Flow Record content or external properties.  If
>        the hash value falls into a predefined Hash Selection Range the
>        flow is selected.

Is there a way to control which fields from the Flow Record go in to the 
hash?

Else, if two devices implement the same hash, are fed the same packets, 
and implement the same flow records - except that the fields are in a 
different order - then they may produce different output.

>     * Flow-state Dependent Flow Selection
>
>        Flow-state Dependent Flow Selection is a selection function that
>        selects or drops flows based on the current flow state.  The
>        selection can be either deterministic, random or non-uniform
>        random.

Again, please clarify exactly what the flow state is. It seems worth 
defining the "Flow-state" term.

eg, one could assume flow state = active, expired, exported...

>     * Flow-state Dependent Packet Selection
>
>        Flow-state Dependent Packet Selection is a selection function that
>        selects or drops packets based on the current flow state.  The
>        selection can be either deterministic, random or non-uniform
>        random.  Flow-state Dependent Packet Selection can be used to
>        prefer the selection of packets belonging to specific flows (e.g.
>        large or small flows).

Are those real examples? Surely preferring packets for small flows gives 
lots of details without giving the big picture and may quickly fill the 
cache (not withstanding that everything starts as a small flow 
anyway...), while preferring packets for large flows may grow whatever 
flows are initially observed into "large" flows while discarding 
individual packets which would eventually make a truely "large" flow.

Unless this is something you want to develop, I'd just remove the "(e.g. 
...)" section.

[Later] I see that you mention "large" flows several times. Does this 
require foreknowledge of what may constitute a large flow? Else, how can 
you correctly select packets which pertain to the "large" flows?

>     * Flow Sampling
>
>        Flow Sampling selects flows based on Flow Record sequence or
>        arrival times (e.g. entry in flow cache, arrival time at Exporter
>        or Mediator).  The selection can be systematic (e.g. every n-th
>        flow) or based on a random function (e.g. select each Flow Record
>        with probability p, or randomly select n out of N Flow Records).

I'm hoping that  a discussion of the pros and cons of each method and 
recommendations as to when to use each method will follow.

[Later] It may be worth saying "Discussion of these methods appears in 
section 5 below".

>
>
>
>
> D'Antonio, et al.       Expires January 12, 2012                [Page 6]
> 
> Internet-Draft          Flow Selection Techniques              July 2011
>
>
> 3.  Difference between Flow Selection and Packet Selection
>
>     Flow selection differs from packet selection described in [RFC5475].

This seems obvious.

>     Packet selection techniques consider packets as basic element and the

"as *the" basic element" ?

>     parent population consists of all packets observed at an observation
>     point.  In contrast to this the basic elements in flow selection are

Just one observation point? Therefore the techniques can't be used when 
traffic has been aggregated from multiple OPs?

>     the flows.  The parent population consists of all observed flows and
>     the selection process operates on the flows.  The major
>     characteristics of flow selection are the following:
>
>     -       Flow selection takes flows as basic elements.  For packet
>             selection, packets are considered as basic elements.
>
>     -       Flow selection can only take place after Packet
>             Classification, because the classification rules determine to
>             which flow a packet belongs.  Packet selection can be applied
>             before and after Packet Classification.
>
>     -       Flow selection operates on Complete Flows.  That means that
>             after the Flow Selection Process either all packets of the
>             flow are kept or all packets of the flow are discarded.  All

When you say "flow" here, I think you mean "Complete Flow".
So consider, "either the complete flow is kept or the complete flow is 
discarded".

>             packets of the flow here means all packets that enter the
>             Flow Selection Process.  That means that if the flow

Packets don't enter the flow selection process, since the flow selection 
process operates on complete flows (per the definition above).

>             selection is preceded by a packet selection process the
>             Complete Flow consists only of the packets that were not
>             discarded during the packet selection.
>
>     There are some techniques that are difficult to unambiguously
>     categorize into one of the categories.  Here we give some guidance
>     how to categorize such techniques:
>
>     -       Techniques that can be considered as both packet and flow
>             selection: some packet selection techniques result in the
>             selection of Complete Flows and therefore can be considered
>             as packet or as flow selection at the same time.  An example
>             is Property Match Filtering of all packets to a specific
>             destination address.  If flows are defined based on
>             destination addresses, such a packet selection also results
>             in a flow selection and can be considered as packet or flow
>             selection.
>
>     -       Flow-state Dependent Packet Selection (as described in
>             [RFC5475]): there exist techniques that select packets based

s/there exist technique/techniques exist/

>             on the flow state, e.g. based on the number of already
>             observed packets belonging to the flow.  Examples of these
>             techniques from the literature are "Sample and Hold" [EsVa01]
>             "Fast Filtered Sampling" [MSZC10] or the "Sticky Sampling"
>             algorithm presented in [MaMo02].  Such techniques can be used
>
>
>
> D'Antonio, et al.       Expires January 12, 2012                [Page 7]
> 
> Internet-Draft          Flow Selection Techniques              July 2011
>
>
>             to influence which flows are captured (e.g. increase the
>             selection of packets belonging to large flows) and reduce the
>             number of flows that need to be stored in the flow cache.
>             Nevertheless, such techniques do not necessarily select
>             Complete Flows, because they do not ensure that all packets
>             of a selected flow are captured.  Therefore Flow-state
>             Dependent Packet Selection methods that do not ensure that
>             either all or no packets of a flow are selected strictly
>             speaking have to be considered as packet selection techniques
>             and not as flow selection techniques.
>
>
> 4.  Flow selection as a Function in the IPFIX Architecture
>
>     Figure 1 shows the IPFIX reference model as defined in [RFC5470] and
>     shows the Packet Classification and Packet Aggregation Process in the
>     Metering Process.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> D'Antonio, et al.       Expires January 12, 2012                [Page 8]
> 
> Internet-Draft          Flow Selection Techniques              July 2011
>
>
>                       Packet(s) coming in to Observation Point(s)
>                         |                                     |
>                         v                                     v
>        +----------------+---------------------------+   +-----+-------+
>        |          Metering Process                  |   |             |
>        |                                            |   |             |
>        |   packet header capturing                  |   |             |
>        |        |                                   |...| Metering    |
>        |   timestamping                             |   | Process N   |
>        |        |                                   |   |             |
>        |   packet sampling                          |   |             |
>        |        |                                   |   |             |
>        |   (packet classification)                    |   |             |

The bounding boxes need to be fixed.

>        |        |                                   |   |             |
>        |   packet filtering*                        |   |             |
>        |        |                                   |   |             |
>        |   (packet aggregation)*                    |   |             |
>        |        |                                   |   |             |
>        +--------|-----------------------------------+   +-----|-------+
>            Flow Records                                   Flow Records
>                 |                                             |
>                 +----------------------+----------------------+
>                                        |
>                 +----------------------|-----------------+
>                 | Exporting Process*                     |
>                 +----------------------+-----------------+
>                                        |  IPFIX (Flow Records)
>                                        v
>              +-------------------------|-----------------------+
>              |  IPFIX Mediator         |                       |
>              |                         v                       |
>              |               Collecting Process(es)            |
>              |                         |                       |
>              |      Intermediate Flow Selection Process (*)    |
>              |                         |                       |
>              |               Exporting Process(es)             |

Flow selection is possible in this EP too.
eg, after the IFSP, the EP may need to perform selection to throttle the 
export bandwith.

>              +-------------------------|-----------------------+
>                                        v
>                                      IPFIX
>
>         (*) indicates where flow selection can take place.
>
>              Figure 1: Flow selection in the IPFIX Architecture
>
>     In contrast to packet selection, flow selection is always applied
>     after the packets are classified into flows.  Flows can be selected
>     at different stages of the measurement chain:
>
>
>
>
> D'Antonio, et al.       Expires January 12, 2012                [Page 9]
> 
> Internet-Draft          Flow Selection Techniques              July 2011
>
>
>     1.  during the Metering Process
>
>     2.  during Exporting Process
>
>     3.  during an Intermediate Selection Process on a Mediator
>
> 4.1.  Flow selection during the Metering Process
>
>     In the Packet Aggregation Process the packet information is used to
>     update the Flow Records in the flow cache.  Flow selection that is
>     applied before aggregation equals a packet selection process.  The
>     flow still consists of individual packets.  Those are then selected
>     based on the classification information, i.e. based on the flow they
>     belong to.  Flow selection before aggregation can be based on the
>     fields of the Flow Key (also on a hash value over these fields), but

So the hash cannot be on non-key fields? I didn't see that specified 
anywhere.

>     not based on characteristics that are only available after packet
>     aggregation (e.g. flow size, flow duration).  Flow selection during
>     the Metering Process is applied to reduce resources for all
>     succeeding processes or to select specific flows of interest in case
>     such flow characteristics are already observable at packet level
>     (e.g. flows to specific IP addresses).  In contrast, Flow-state
>     Dependent Packet Selection is a packet selection method, because it
>     does not necessarily select Complete Flows.
>
> 4.2.  Flow selection during the Exporting Process
>
>     The Flow Selection Process at the Exporter is similar to an
>     Intermediate Selection Process as described in [RFC6183] and works on
>     Flow records.  Flow selection during the Exporting Process can
>     therefore also depend on flow characteristics that are only visible
>     after the aggregation of packets, such as flow size and flow
>     duration.  The Exporting Process may implement policies for exporting
>     only a subset of the Flow Records which have been stored in the
>     system memory in order to unload flow export and flow postprocessing.

Consider "post-processing".

>     Flow selection during the Exporting Process may select only the
>     subset of Flow Records which are of interest to the users
>     application, or select only as many Flow Records as can be handled by
>     the available resources (e.g. limited flow cache size and export link
>     capacity).

Surely flow cache size would be of interest at the metering process 
rather than at the exporting process?

> 4.3.  Flow selection as a function of the IPFIX Mediator
>
>     As shown in Figure 1, flow selection can be performed as an
>     Intermediate Process within an IPFIX Mediator [RFC6183].  The
>     Intermediate Selection Process takes Flow Record stream as its input
>     and selects a flow record stream.  The Intermediate Selection Process
>     can again apply a flow selection technique to obtain flows of
>     interest to the application.  Further the Intermediate Selection

"Further,"

>
>
> D'Antonio, et al.       Expires January 12, 2012               [Page 10]
> 
> Internet-Draft          Flow Selection Techniques              July 2011
>
>
>     Process can base its selection decision on the correlation of data
>     from different observation points, e.g. by only selecting flows that
>     were at least recorded on two observation points.

So earlier discussion of "an Observation Point" wasn't exclusive? Good.

>
> 5.  Flow Selection Techniques
>
>     A flow selection technique selects either all or none of the packets
>     of a flow, otherwise the technique has to be considered as packet
>     selection.  We distinguish between Flow Filtering and Flow Sampling.

This is such a simple definition, I wish it had been said earlier!

> 5.1.  Flow Filtering
>
>     Flow Filtering is a deterministic function on the IPFIX Flow Record
>     content.  In case that the relevant flow characteristics are already

s/In case that/If/

>     observable at packet level (e.g.  Flow Keys) Flow Filtering can be

Add a comma after the ")".

>     applied before aggregation at packet level.
>
> 5.1.1.  Property Match Filtering
>
>     Flow Filtering can be done similarly to Property Match Filtering for

s/done/performed/ ?

>     packet selection described in [RFC5475].  The difference is that,
>     instead of packet fields, Flow Record fields are here used to derive
>     the selection decision.  Property Match Filtering is typically used
>     to select a specific subset of the flows that are of interest to a
>     particular application (e.g. all flows to a specific destination, all
>     large flows, etc.).  Properties on which the filtering is based can
>     be for example Flow Keys, the flow size in bytes, the number of
>     packets in the flow, the observation time of the first or last
>     packet, or the maximum packet length.  The selection criteria can be
>     a specific value or an interval.  Property Match Filtering can be
>     applied during the Metering Process if the properties are already
>     observable at the packet level (e.g.  Flow Key fields).
>
>     There are content-based Property Match Filtering techniques that
>     require a computation on the current flow cache.  An example is the
>     selection of the k largest flows or a percentage of flows with the

Although I'm sure you intend 'k' as a variable, it looks like a typo.

Can't it just be "N" - or just not named at all since it's not used below?

>     longest lifetime.  This type of Property Match Filtering is also used
>     in flow selection techniques that react to external events (e.g.
>     resource constraint).  For example in case the flow cache is full,

s/in case/when/

>     the Flow Record with the lowest flow volume per current flow life
>     time is deleted.

s/is/may be/

(From an implementation point of view, I wouldn't do this since "per" 
involves division which I don't have time for when the cache is full...)

> 5.1.2.  Hash-based Flow Filtering
>
>     Hash-based Flow Filtering uses a Hash Function h to map the Flow Key
>     c onto a Hash Range R. A flow is selected if the hash value h(c) is
>     within the Hash Selection Range S, which is a subset of R. Hash-based

Do it like 'h', 'c', 'R' and 'S' so it doesn't look like typos.

>
>
> D'Antonio, et al.       Expires January 12, 2012               [Page 11]
> 
> Internet-Draft          Flow Selection Techniques              July 2011
>
>
>     Flow Filtering can be used to emulate a random sampling process but
>     still enable the correlation between selected flow subset at

"subsets"?

>     different observation points.  Hash-based Flow Filtering is similar
>     to Hash-based Packet Selection, and in fact is identical when Hash-
>     based Packet Selection uses the Flow Key that defines the flow as the
>     hash input.  Nevertheless there MAY be the incentive to apply Hash-
>     based Flow Filtering not on the packet level during the Metering
>     Process, for example when the size of the selection range and
>     therefore the sampling probability is dependent on the number of
>     observed flows.
>
> 5.2.  Flow Sampling
>
>     Flow Sampling operates on Flow Record sequence or arrival times.  It
>     can use either a systematic or a random function for the selection
>     process.  Flow Sampling usually aims at the selection of a
>     representative subset of all flows in order to estimate
>     characteristics of the whole set (e.g. mean flow size in the
>     network).
>
> 5.2.1.  Systematic sampling
>
>     Systematic sampling is a deterministic selection function.
>     Systematic sampling may be a periodic selection of the k-th Flow

Why k-th? In my experience, most engineers understand "Nth".

>     Record which arrives at the Exporting or Intermediate Selection
>     Process.  Systematic sampling can also be applied during the Metering
>     Process.  An example would be to use an additional data structure
>     that saves the Flow Keys of the non-selected flows.

I don't follow the example, because a regular MP doesn't meter flows; it 
meters packets - so this would be systematic *packet* sampling rather 
than systematic *flow* sampling.

Also, the example sounds like a filter: flows f were sampled, while 
flows f' were not.

>     Systematic sampling can also be time-based.  Systematic sampling is

s/Systematic sampling/Time based systematic sampling/

>     applied by only creating flows that are observed between time-based
>     start and stop triggers.  The time interval may be applied at packet
>     level during the Metering Process or after aggregation on flow level,
>     e.g. by selecting a flow arriving at the Exporting Process every k
>     seconds.
>
> 5.2.2.  Random sampling
>
>     Random flow sampling is based on a random process which requires the
>     calculation of random numbers.  One can differentiate between n-out-N

Random numbers are required for random sampling? This seems... obvious.

>     and probabilistic flow sampling.  The sampling probability of

It would bee good to explain the difference between n-out-N and 
probabilistic flow sampling.

>     individual Flows Records MAY be adjusted according to the Flow Record

s/Flows/Flow/

>     content or external events like the available export resources.  Non-

If the sampling rate is adjusted per individual flow record, how do you 
propose to report the sampling rate(s) correctly to allow normalisation 
and the correct interpretation of the data?

>     uniform random sampling approaches can be applied similar to the ones
>     defined in [RFC5475].  An example would be to increase the selection
>     probability of large volume flows over small volume flows as
>     described in the Smart Sampling technique [DuLT01].  Random flow
>     sampling can also be applied before the Packet Aggregation Process
>
>
>
> D'Antonio, et al.       Expires January 12, 2012               [Page 12]
> 
> Internet-Draft          Flow Selection Techniques              July 2011
>
>
>     when additional flow state about non selected flows is kept.

Why keep info about non-selected flows? What will be done with it? If 
the point of selection is to get rid of uninteresting flows, keeping the 
stuff that wasn't selected is just wasteful.

> 5.3.  Flow-state Dependent Flow Selection
>
>     Flow-state Dependent Flow Selection can be a deterministic or random
>     flow selection process based on the Flow Record content and the flow
>     state which may be kept additionally for each of the flows.  External
>     processes may update counters, bounds and timers for each of the Flow
>     Records and the Flow Selection Process utilises this information for
>     the selection decision.  A review of Flow-state Dependent Flow
>     Selection techniques that aim at the selection of the most frequent
>     items by keeping additional flow state information can be found in
>     [CoHa08].  Flow-state Dependent Flow Selection can only be applied
>     after packet aggregation, when a packet has been assigned to a flow.
>     The selection process then decides based upon the flow state for each
>     flow if it is kept in the flow cache or not.  Two Flow State
>     Dependent Flow Selection are here described:

s/Selection are/Selection algorithms are/

>     The frequent algorithm [KaPS03] is a technique that aims at the
>     selection of all flows that at least exceed a 1/k fraction of the
>     observed packet stream.  The algorithm has only a flow cache of size

OPS should be capitalised per RFC5476.

>     k-1 and each flow in the cache has an additional counter.  The
>     counter is incremented each time a packet belonging to the flow in
>     the flow cache is observed.  In case the observed packet does not
>     belong to any flow all counters are decremented and if any of the
>     flow counters has a value of zero the flow is replaced with a flow
>     formed from the new packet.
>
>     Lossy counting is a selection technique that identifies all flows
>     whose packet count exceeds a certain percentage of the whole observed
>     packet stream (e.g. 5% of all packets) with a certain estimation
>     error e.  Lossy counting separates the observed packet stream in

'e'

>     windows of size N=1/e, where N is an amount of consecutive packets.
>     For each observed flow an additional counter will be held in the flow
>     state.  The counter is incremented each time a packet belonging to
>     the flow is observed and all counters are decremented at the end of
>     each window and all flows with a counter of zero will be removed from
>     the flow cache.

s/will be/are/

> 5.4.  Flow-state Dependent Packet Selection
>
>     Flow-state Dependent Packet Selection is not a flow selection
>     technique but a packet selection technique.  Nevertheless we will
>     describe configuration and reporting parameters for this technique in
>     this document.  An example is the "Sample and Hold" algorithm
>     [EsVa01] that tries to prefer large volume flows in the selection.
>     When a packet arrives it is selected when a Flow Record for this
>     packet already exists.  In case there is no Flow Record, the packet
>
>
>
> D'Antonio, et al.       Expires January 12, 2012               [Page 13]
> 
> Internet-Draft          Flow Selection Techniques              July 2011
>
>
>     is selected by a certain probability that is dependent on the packet
>     size.
>
>
> 6.  Configuration of Flow Selection Techniques
>
>     This section describes the configuration parameters of the flow
>     selection techniques presented above.  It provides the basis of an
>     information model to be adopted in order to configure the Flow
>     Selection Process within an IPFIX Device.  The following table gives
>     an overview of the defined selection techniques, where they can be
>     applied and what their input parameters are.  Dependent on where the
>     flow selection techniques are applied different input parameters can
>     be configured.
>
>     Overview of Flow Selection Techniques:
>
>     +------------------+-----------------+------------------------------+
>     | Location         | Selection       | Selection Input              |
>     |                  | Method          |                              |
>     +------------------+-----------------+------------------------------+
>     | During the       | Flow-state      | packet sampling              |
>     | Metering Process | Dependent       | probabilities, flow state,   |
>     | based on Packets | Packet          | packet properties            |
>     |                  | Selection       |                              |
>     +------------------+-----------------+------------------------------+
>     |                  | Property Match  | Flow Key fields, filter      |
>     |                  | Flow Filtering  | function                     |
>     +------------------+-----------------+------------------------------+
>     |                  | Hash-based Flow | selection range, Hash        |
>     |                  | Filtering       | Function, Flow Key           |
>     +------------------+-----------------+------------------------------+
>     |                  | Time-based      | flow position (derived from  |
>     |                  | Systematic Flow | arrival time of packets),    |
>     |                  | Sampling        | flow state                   |
>     +------------------+-----------------+------------------------------+
>     |                  | Sequence-based  | flow position (derived from  |
>     |                  | Systematic Flow | packet position), flow state |
>     |                  | Sampling        |                              |
>     +------------------+-----------------+------------------------------+
>     |                  | Random Flow     | random number generator or   |
>     |                  | Sampling        | list and packet position,    |
>     |                  |                 | flow state                   |
>     +------------------+-----------------+------------------------------+
>     | Exporting /      | Property Match  | Flow Record content, filter  |
>     | Intermediate     | Flow Filtering  | function                     |
>     | Selection        |                 |                              |
>     | Process          |                 |                              |
>
>
>
> D'Antonio, et al.       Expires January 12, 2012               [Page 14]
> 
> Internet-Draft          Flow Selection Techniques              July 2011
>
>
>     |                  | Hash-based Flow | selection range, Hash        |
>     |                  | Filtering       | Function, hash input (Flow   |
>     |                  |                 | Keys and other flow          |
>     |                  |                 | properties)                  |
>     +------------------+-----------------+------------------------------+
>     |                  | Flow-state      | flow state parameters,       |
>     |                  | Dependent Flow  | random number generator or   |
>     |                  | Selection       | list                         |
>     +------------------+-----------------+------------------------------+
>     |                  | Time-based      | flow arrival time, flow      |
>     |                  | Systematic Flow | state                        |
>     |                  | Sampling        |                              |
>     +------------------+-----------------+------------------------------+
>     |                  | Sequence-based  | flow position, flow state    |
>     |                  | Systematic Flow |                              |
>     |                  | Sampling        |                              |
>     +------------------+-----------------+------------------------------+
>     |                  | Random Flow     | random number generator or   |
>     |                  | Sampling        | list and flow position, flow |
>     |                  |                 | state                        |
>     +------------------+-----------------+------------------------------+
>
> 6.1.  Description of Flow Selection Techniques
>
>     In this section, we define what parameters are required to describe
>     the most common Flow Selection techniques.

Consider moving this paragraph to the top of section 6.

>     Flow Selection Parameters:
>

Flow state dependent packet selection is missing here.

[Later] OK, it's below. See below.

>     For Property Match Filtering:
>
>     -   Information Element (from [RFC5102]):
>         Specifies the Information Element which is used as the property
>         in the filter expression.

Can there be more than one IE?

Don't use RFC5102 as the reference, use IANA - since there are now many 
more IEs in IANA than in 5102, you're adding an unintentional limitation.

>     -   Selection Value or Value Interval:
>         Specifies the value or interval of the filter expression.
>         Packets and Flow Record that have a value equal to the Selection
>         Value or within the Interval will be selected.

Are there other possibilities, eg not-equal, less-than, greater-than, 
regexp?

The table above says "Flow Key fields, filter function" (for the 
relevant "Selection Input"). Is the text here supposed to align with or 
relate to the table in any way?

>     For Hash-based Flow Filtering:
>
>     -   Hash Domain:
>         Specifies the bits from packet (IPv4 or IPv6) which are taken as

Why say "IPv4 or IPv6" ?

>         the hash input to the Hash Function.
>
>
>
>
>
>
> D'Antonio, et al.       Expires January 12, 2012               [Page 15]
> 
> Internet-Draft          Flow Selection Techniques              July 2011
>
>
>     -   Hash Function:
>         Specifies the name of the Hash Function that is used to calculate
>         the hash value.  Possible Hash Functions are BOB, IPSX, CRC-32
>
>     -   Hash Selection Range:
>         Flows that have a hash value within the Hash Selection Range are
>         selected.  The Hash Selection Range can be a value interval or
>         arbitrary hash values within the Hash Range of the Hash Function.
>
>     -   Random Seed or Initializer Value:
>         Some Hash Functions require an initializing value.  In order to
>         make the selection decision more secure one can choose a random
>         seed that configures the hash function.

Again, the table above says, "selection range, Hash Function, Flow Key" 
- so there's some similarity between the text and the table, but they 
don't align.

>     For Flow-state Dependent Flow Selection:

It'd be good to maintain a consistent order of selection methods.

>     -   frequency threshold:
>         Specifies the frequency threshold s for flow state dependent flow

Is 's' the name of the threshold? It's not an obvious choice and looks 
like a typo.

Consider:

	Specifies the frequency threshold 's' for flow state

	Specifies the frequency threshold, 's', for flow state

>         selection techniques that try to find the most frequent items
>         within a dataset.  All flows which exceed the defined threshold
>         will be selected.
>
>     -   accuracy parameter:
>         specifies the accuracy parameter e for techniques that deal with

Is 'e' a variable? Again, it looks like a typo.

>         the frequent items problems.  The accuracy paramter defines the

s/paramter/parameter/

>         maximum error, i.e. no flows that have a true frequency less than
>         (s- e) N is selected, where s is the frequency threshold and N is

"(s - e) N", with equal spacing.

>         the total number of packets.
>
>     The above list of parameters for Flow-state Dependent Flow Selection
>     techniques is suitable for the presented frequent item and lossy
>     counting algorithm.  Nevertheless there exist a variety of techniques

s/there exist a variety of techniques/a variety of techniques exist/

>     with very specific parameters which are not defined here.
>
>     For Systematic time-based Flow Sampling:
>
>     -   Interval length (in usec)
>         Defines the length of the sampling interval during which flows
>         are selected.
>
>     -   Spacing (in usec)
>         The spacing parameter defines the spacing in usec between the end
>         of one sampling interval and the start of the next succeeding
>         interval.
>
>     For Systematic count-based Flow Sampling:
>
>
>
>
>
> D'Antonio, et al.       Expires January 12, 2012               [Page 16]
> 
> Internet-Draft          Flow Selection Techniques              July 2011
>
>
>     -   Interval length
>         Defines the number of flows that are selected within the sampling
>         interval.
>
>     -   Spacing
>         The spacing parameter defines the spacing in number of observed
>         flows between the end of one sampling interval and the start of
>         the next succeeding interval.

Can these methods be used together? eg, observe 10 flows, then wait 10 
seconds?

>     For random n-out-of-N Flow Sampling:
>
>     -   Population Size N
>         The Population Size N is the number of all flows in the
>         Population from which the sample is drawn.
>
>     -   Sample size n
>         The sample size n is the number of flows that are randomly drawn
>         from the population N.
>
>     For probabilistic Flow Sampling:
>
>     -   Sampling probability p
>         The sampling probability p defines the probability by which each
>         of the observed flows is selected.

Again, the same point about N, n and p - it's not immediately clear that 
these are variables rather than typos.
However, since they're not used anywhere, why name them at all?

> 6.2.  Description of Flow-state Dependent Packet Selection
>
>     The configuration of Flow-state Dependent Packet Selection has not
>     been described in [RFC5475] therefore the parameters are defined
>     here:
>
>     For Flow-state Dependent Packet Selection:
>
>     -   packet selection probability per possible flow state interval
>         Defines multiple [flow interval, packet selection probability]

It'd be better to use { } for this, since [ ] usually delineate citations.

>         value pairs that configure the sampling probability dependent on
>         the current flow state.
>
>     -   additional parameters
>         For the configuration of flow state dependent packet selection
>         additional parameters or packet properties may be required for
>         the configuration, e.g. the packet size ([EsVa01])
>
>
> 7.  Information Model for Flow Selection Reporting
>
>     In this section we describe Information Elements (IEs) that SHOULD be
>     exported by a flow selection process in order to support the
>
>
>
> D'Antonio, et al.       Expires January 12, 2012               [Page 17]
> 
> Internet-Draft          Flow Selection Techniques              July 2011
>
>
>     interpretation of measurement results from flow measurements where
>     only some flows are selected.  The information is mainly used to
>     report how many packets and flows have been observed in total and how
>     many of them were selected.  This helps for instance to calculate the
>     Attained Selection Fraction, which is an important parameter to

Insert xref for ASF [RFC5476].

>     provide an accuracy statement.  The IEs can provide reporting
>     information about Flow Records, packets or bytes.  The reported
>     metrics are number of total and the number of selected elements.

s/number of total/total number of elements,/

>      From this the number of dropped elements can be derived.  All

- provided appropriate total and selected pairs are exported.

>     counters SHOULD be exported and reset when a new measurement interval
>     starts.  Additional IEs may be useful for future flow selection
>     techniques.  Those can be defined additionally if needed.
>
>     List of additional Flow Selection Information Elements:
>
>                     +------+---------------------------+
>                     | ID   | Name                      |
>                     +------+---------------------------+
>                     | TBD1 | fsFlowRecordTotalCount    |
>                     +------+---------------------------+
>                     | TBD2 | fsFlowRecordSelectedCount |
>                     +------+---------------------------+
>                     | TBD3 | fsPacketTotalCount        |
>                     +------+---------------------------+
>                     | TBD4 | fsPacketSelectedCount     |
>                     +------+---------------------------+
>                     | TBD5 | fsOctetTotalCount         |
>                     +------+---------------------------+
>                     | TBD6 | fsOctetSelectedCount      |
>                     +------+---------------------------+
>

Curiously, TBD1, TBD2, TBD7, TBD8, TBD9 and TBD10 are used below.
Did none of the other reviewers notice this? :-(

> 7.1.  fsFlowRecordTotalCount
>
>     Description:
>
>        This Information Element specifies the current number of all Flow
>        Records that form the parent population as input to the Flow
>        Selection Process.
>
>     Abstract Data Type: unsigned64
>
>     ElementId: TBD1
>
>     Units: Flows
>
>
>
>
>
>
>
> D'Antonio, et al.       Expires January 12, 2012               [Page 18]
> 
> Internet-Draft          Flow Selection Techniques              July 2011
>
>
> 7.2.  fsFlowRecordSelectedCount
>
>     Description:
>
>        This Information Element specifies the current number of Flow
>        Records that were selected during the Flow Selection Process.
>
>     Abstract Data Type: unsigned64
>
>     ElementId: TBD2
>
>     Units: Flows
>
> 7.3.  fsPacketTotalCount
>
>     Description:
>
>        This Information Element specifies the current number of packets
>        in all flows that form the parent population as input to the Flow
>        Selection Process.
>
>     Abstract Data Type: unsigned64

NB u64 might not be sufficient for this. See below.

>     ElementId: TBD7

This is TBD3 in the list above.

>     Units: Packets
>
> 7.4.  fsPacketSelectedCount
>
>     Description:
>
>        This Information Element specifies the current number packets in
>        all flows that were selected during the Flow Selection Process.
>
>     Abstract Data Type: unsigned64
>
>     ElementId: TBD8

This is TBD4. You get the idea.

>     Units: Packets
>
> 7.5.  fsOctetTotalCount
>
>     Description:
>
>        This Information Element specifies the current number of all bytes
>        in all flows that form the parent population as input to the Flow
>        Selection Process.
>
>
>
>
> D'Antonio, et al.       Expires January 12, 2012               [Page 19]
> 
> Internet-Draft          Flow Selection Techniques              July 2011
>
>
>     Abstract Data Type: unsigned64

NB u64 may be insufficient for this since all bytes in all flows = all 
traffic entering the selection process.

eg, monitoring 1000 x 10g interfaces, this allows for < 2^24 seconds of 
traffic, which is about 170 days. Perhaps this is enough today... though 
perhaps not so next year.

>     ElementId: TBD9
>
>     Units: Octets
>
> 7.6.  fsOctetSelectedCount
>
>     Description:
>
>        This Information Element specifies the current number of bytes in
>        all flows that were selected during the Flow Selection Process.
>
>     Abstract Data Type: unsigned64
>
>     ElementId: TBD10
>
>     Units: Octets
>
>
> 8.  IANA Considerations
>
>     This document introduces several new Information Elements as an
>     extension to the IPFIX information model.  Values TBD1-TBD10 in
>     section 7 of this document should be replaced with the assigned
>     numbers by IANA.
>
>
> 9.  Security Considerations
>
>     In this section security issues concerning an IPFIX Device performing
>     flow selection are pointed out.  In case the flow selection function
>     is activated an IPFIX Device might be exposed to security threats.

"activated,"

>     Since flow selection implies analysing flow packets, associating them
>     to a specific traffic flow and selecting Flow Records, a malicious

"associate ... with" -  so s/to/with/

>     user who was able to gain control of an IPFIX Device might access
>     both packet and flow data, thus violating their confidentiality.
>
>     Furthermore, the intruder might be attracted by the possibility of
>     altering the Flow Selection Process by modifying the criteria used to
>     select Flow Records.  In this case, the IPFIX Device would export
>     flow data which are different from the ones that the Collector
>     expects to receive.
>
>     It is apparent that these security threats can be mitigated by
>     authenticating entities that interact with the IPFIX Device and
>     keeping information for flow selection configuration confidential.

In short, if you can gain control of the box then you can do bad things. 
This is well known.

Does this document expose any new security considerations for the reader 
/ implementer?
If not, then consider stating that explicitly (copy the "no new security 
implications" text from other IPFIX RFCs) in order to avoid creating a 
negative impression (ie, that implementing this draft exposes security 
risks).

>
>
>
> D'Antonio, et al.       Expires January 12, 2012               [Page 20]
> 
> Internet-Draft          Flow Selection Techniques              July 2011
>
>
> 10.  References
>
> 10.1.  Normative References
>
>     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>                Requirement Levels", BCP 14, RFC 2119, March 1997.
>
> 10.2.  Informative References
>
>     [CoHa08]   Cormode, G. and M. Hadjieleftheriou, "Finding frequent
>                items in data streams", Journal, Proceedings of the Very
>                Large DataBase Endowment VLDB Endowment, Volume 1 Issue 2,
>                August 2008, August 2008.
>
>     [DuLT01]   Duffield, N., Lund, C., and M. Thorup, "Charging from
>                Sampled Network Usage", ACM Internet Measurement Workshop
>                IMW 2001, San Francisco, USA, November 2001.
>
>     [EsVa01]   Estan, C. and G,. Varghese, "New Directions in Traffic
>                Measurement and Accounting: Focusing on the Elephants,
>                Ignoring the Mice", ACM SIGCOMM Internet Measurement
>                Workshop 2001, San Francisco (CA), November 2001.
>
>     [KaPS03]   Karp, R., Papadimitriou, C., and S. S. Shenker, "A simple
>                algorithm for finding frequent elements in sets and
>                bags.", ACM Transactions on Database Systems, Volume 28,
>                51-55, 2003, March 2003.
>
>     [MSZC10]   Mai, J., Sridharan, A., Zang, H., and C. Chuah, "Fast
>                Filtered Sampling", Computer Networks Volume 54, Issue 11,
>                Pages 1885-1898, ISSN 1389-1286, January 2010.
>
>     [MaMo02]   Manku, G. and R. Motwani, "Approximate Frequency Counts
>                over Data Streams", Proceedings of the Internation

s/Internation/International/

>                Conference on Very large DataBases (VLDB) pages 346--357,
>                2002, Hong Kong, China, 2002.
>
>     [RFC3917]  Quittek, J., Zseby, T., Claise, B., and S. Zander,
>                "Requirements for IP Flow Information Export (IPFIX)",
>                RFC 3917, October 2004.
>
>     [RFC5101]  Claise, B., "Specification of the IP Flow Information
>                Export (IPFIX) Protocol for the Exchange of IP Traffic
>                Flow Information", RFC 5101, January 2008.
>
>     [RFC5102]  Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
>                Meyer, "Information Model for IP Flow Information Export",
>                RFC 5102, January 2008.
>
>
>
> D'Antonio, et al.       Expires January 12, 2012               [Page 21]
> 
> Internet-Draft          Flow Selection Techniques              July 2011
>
>
>     [RFC5470]  Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
>                "Architecture for IP Flow Information Export", RFC 5470,
>                March 2009.
>
>     [RFC5475]  Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F.
>                Raspall, "Sampling and Filtering Techniques for IP Packet
>                Selection", RFC 5475, March 2009.
>
>     [RFC5476]  Claise, B., Johnson, A., and J. Quittek, "Packet Sampling
>                (PSAMP) Protocol Specifications", RFC 5476, March 2009.
>
>     [RFC6183]  Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi,
>                "IP Flow Information Export (IPFIX) Mediation: Framework",
>                RFC 6183, April 2011.
>
>
> Authors' Addresses
>
>     Salvatore D'Antonio
>     University of Napoli "Parthenope"
>     Centro Direzionale di Napoli Is. C4
>     Naples  80143
>     Italy
>
>     Phone: +39 081 5476766
>     Email: [email-masked]
>
>
>     Tanja Zseby
>     Fraunhofer Institute FOKUS
>     Kaiserin-Augusta-Allee 31
>     Berlin  10589
>     Germany
>
>     Phone: +49 30 3463 7153
>     Email: [email-masked]
>
>
>     Christian Henke
>     Technische Universitat Berlin
>     Strasse des 17. Juni 135
>     Berlin  10623
>     Germany
>
>     Phone: +49 30 3463 7366
>     Email: [email-masked]
>
>
>
>
>
> D'Antonio, et al.       Expires January 12, 2012               [Page 22]
> 
> Internet-Draft          Flow Selection Techniques              July 2011
>
>
>     Lorenzo Peluso
>     University of Napoli
>     Via Claudio 21
>     Napoli  80125
>     Italy
>
>     Phone: +39 081 7683821
>     Email: [email-masked]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> D'Antonio, et al.       Expires January 12, 2012               [Page 23]
>

---

From: Paul Aitken <[email-masked]>
Date: Tue, 06 Sep 2011 12:08:32 +0100

Dear all,

Considering the draft some more...

A standards track document should specify and contain everything that 
needs to be known and understood in order to implement the specified 
methods.

However, this draft reads more as an overview of the methods, rather 
than a specification of them. While reading it gave an idea of the 
available methods, what actually needs done to correctly implement each 
method is not spelled out. eg, there are only two MUSTs in the document, 
both in the first paragraph of section 1. The average over all the IPFIX 
drafts is over 15 MUSTs.

In short, it seems more Informational than Standards track.

P.

---

From: Benoit Claise <[email-masked]>
Date: Tue, 06 Sep 2011 15:38:33 +0200

Dear all,

After speaking with Paul, I reviewed this draft.
Next to Paul's comments below, I have some more. See in line.

I have a couple of important concerns:
- the lack of integration with the other mediation related RFC & drafts
     * for the terminology (example: Flow Selection Process is used 
instead of the Intermediate Flow Selection Process)
     * for the figure
- I just took one example "Random Flow Sampling" and looked at what I 
should implement to be compliant. And I don't know the answer, and there 
is not a single example.
If I compare with the PSAMP protocol specification for Random (packet) 
sampling, http://tools.ietf.org/html/rfc5476#section-6.5.2.3, this is clear.

Therefore, I haven't read the entire draft, as there were blocking 
factors already.

Regards, Benoit.

> Please find many comments inline. I'd like to see a new version of 
> this draft.
>
> Thanks,
> P.
>
>
>>
>>                                                                  C. 
>> Henke
>>                                                                 L. 
>> Peluso
>>                                                      University of 
>> Napoli
>>                                                             July 11, 
>> 2011
> Is just one OP allowed, or can they be observed at multiple 
> observation points?
Right.
"a subset from all flows observed at an observation point, into a cache, 
or in mediatior"
>>     effort of post-processing flow data and transferring Flow Records.
Capitalization in the abstract?
>>     application. 
This is where you should expand on the different cases:
     1. selected flows observed at an observation point,
     2. selected flow from a cache,
     3 .selected flow in a mediator
>> This document provides a categorization of flow
Please add section such as 
http://tools.ietf.org/html/rfc6235#section-1.2, to be consistent between 
all the different mediation drafts.
Note: this should be done as for 
http://tools.ietf.org/html/draft-trammell-ipfix-a9n-03
>>     [RFC5101], [RFC5470], [RFC5475] and [RFC3917]. 
Please mention which terms are used in this draft.
For example, when I read the definition of Packet Aggregation Process or 
Flow Selection Process, I was wondering they were not similar to terms 
defined in other RFCs
>> As in [RFC5101] and
I hope the terminology is also in line with 
http://tools.ietf.org/html/rfc6183 and http://tools.ietf.org/html/rfc5982
If this is the case, please mention it.
>>        is updated, otherwise a new Flow Record is created.
How is this different from the IPFIX Metering Process?

* Metering Process

       The Metering Process generates Flow Records.  Inputs to the
       process are packet headers and characteristics observed at an
       Observation Point, and packet treatment at the Observation Point
       (for example, the selected output interface).

       The Metering Process consists of a set of functions that includes
       packet header capturing, timestamping, sampling, classifying, and
       maintaining Flow Records.

       The maintenance of Flow Records may include creating new records,
       updating existing ones, computing Flow statistics, deriving
       further Flow properties, detecting Flow expiration, passing Flow
       Records to the Exporting Process, and deleting Flow Records.

>>        available.  Information about individual packets is lost.
What is packet data?
Again, how is this different from the Metering Process?

>>        Selection Process as defined for the IPFIX Mediator [RFC6183].
I really confused by "A Flow Selection Process MAY be part of ... an 
Intermediate
        Selection Process as defined for the IPFIX Mediator [RFC6183]."
Why don't you reuse the

    Intermediate Selection Process

       An Intermediate Selection Process is an Intermediate Process that
       selects records from a sequence based upon criteria-evaluated
       record values and passes only those records that match the
       criteria (e.g., filtering only records from a given network to a
       given Collector).

Your Flow Selection Process term should be replaced by the Intermediate 
Selection Process.
>>        A Flow Selection Process SHOULD maintain state information for 
It's the second time that I see RFC 2119 keywords in definition.
If I recall correctly, this is not welcome.
>>        following information in order to establish whether a flow has to
I'm confused by the "on a single flow".
If I do flow based random sampling, do I use a Flow Selector? I mean, I 
will look at all the flows in the caches, not individual flows
> Is there a way to control which fields from the Flow Record go in to 
> the hash?
>
> Else, if two devices implement the same hash, are fed the same 
> packets, and implement the same flow records - except that the fields 
> are in a different order - then they may produce different output.
>
>
> Are those real examples? Surely preferring packets for small flows 
> gives lots of details without giving the big picture and may quickly 
> fill the cache (not withstanding that everything starts as a small 
> flow anyway...), while preferring packets for large flows may grow 
> whatever flows are initially observed into "large" flows while 
> discarding individual packets which would eventually make a truely 
> "large" flow.
>
> Unless this is something you want to develop, I'd just remove the 
> "(e.g. ...)" section.
>
> require foreknowledge of what may constitute a large flow? Else, how 
> can you correctly select packets which pertain to the "large" flows?
>
>
>>     * Flow Sampling
>>
> Just one observation point? Therefore the techniques can't be used 
> when traffic has been aggregated from multiple OPs?
>
>
> Packets don't enter the flow selection process, since the flow 
> selection process operates on complete flows (per the definition above).
>
>
> eg, after the IFSP, the EP may need to perform selection to throttle 
> the export bandwith.
In other words, we could have a IPFIX Mediation on the Original Exporter.
Using a * to "indicate where flow selection can take place." is confusing
There is a big confusion between packet and flow.
A flow selection happens where there are flows, and you mention that 
flow selection can take place in "packet filtering", "packet 
aggregation". It doesn't make sense.
This figure should be redrawn according to the figure A at 
http://tools.ietf.org/html/rfc6183#section-4, with Intermediate Flow 
Selection Process

>>     after the packets are classified into flows. 
Exactly. See my previous remark
>> Flows can be selected
> I don't follow the example, because a regular MP doesn't meter flows; 
> it meters packets - so this would be systematic *packet* sampling 
> rather than systematic *flow* sampling.
>
> If the sampling rate is adjusted per individual flow record, how do 
> you propose to report the sampling rate(s) correctly to allow 
> normalisation and the correct interpretation of the data?
>
>
> the point of selection is to get rid of uninteresting flows, keeping 
> the stuff that wasn't selected is just wasteful.
>
>
>>     |                  | Method          
>>     |                  | Selection       
>>     |                  | Sampling        
>>     |                  |                 | flow 
>> state                   |
>>     | Selection        |                 
>>     | Process          |                 
>> properties)                  |
>>     |                  | Selection       | 
>> list                         |
>>     |                  | Sampling        
>>     |                  | Systematic Flow 
>>     |                  | Sampling        
>> state                        |
> Don't use RFC5102 as the reference, use IANA - since there are now 
> many more IEs in IANA than in 5102, you're adding an unintentional 
> limitation.
>
>
> relevant "Selection Input"). Is the text here supposed to align with 
> or relate to the table in any way?
>
>
> Again, the table above says, "selection range, Hash Function, Flow 
> Key" - so there's some similarity between the text and the table, but 
> they don't align.
>
>
> Again, the same point about N, n and p - it's not immediately clear 
> that these are variables rather than typos.
> eg, monitoring 1000 x 10g interfaces, this allows for < 2^24 seconds 
> of traffic, which is about 170 days. Perhaps this is enough today... 
> though perhaps not so next year.
>
>
>>     ElementId: TBD9
>>
>>     Units: Octets
>>
> In short, if you can gain control of the box then you can do bad 
> things. This is well known.
>
> Does this document expose any new security considerations for the 
> reader / implementer?
> If not, then consider stating that explicitly (copy the "no new 
> security implications" text from other IPFIX RFCs) in order to avoid 
> creating a negative impression (ie, that implementing this draft 
> exposes security risks).
>
>
>>
>>
>>
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Brian Trammell <[email-masked]>
Date: Wed, 7 Sep 2011 13:25:13 +0200

Greetings, all,

On review of Benoit's and Paul's comments, I would like to reiterate that my review primarily concerned the diffs between -06 and -07, and whether those addressed the pending last call comments, and was not an extensive review. On reading the comments of Paul and Benoit, I find myself in agreement.

Therefore, I agree with that the editorial changes suggested by Paul should be folded into a revised -08. The questions posed by Benoit and Paul with respect to content should also be answered with the -08 revision.

That said, I refer back to my first LC review of this document of 1 March 2011 (http://www.ietf.org/mail-archive/web/ipfix/current/msg05775.html) -- and I have to say that the draft still falls a bit short of the scope as I understood it to be at the time it was added to the working group charter. Specifically (note that these comments are quoted from that message and refer to the -04 revision of the document):

> Third, the selection of flow keys for key-based selection in the subsections of section 7 seems arbitrary. Specifically, why can't I select flows based on protocolIdentifier? It is also unclear how to apply this flow selection system for selecting the set of flows for any but a very simplistic set of keys. A good example: all flows involving a given set of networks: "All flows which belong to Organization Foo", where Foo controls the netblocks 130.229.0.0/16, 199.38.128.0/17, and 199.57.198.0/23. Also, keep in mind that _any_ IE, basically, may be a Flow Key field. What if I only want to select 3-packet TCP flows (i.e., zero content complete handshakes)?
> 
> I would submit that this case -- arbitrary key space subsets -- must be handled by any flow selection draft that comes out of the WG; it's fairly common especially at the mediator level. If, instead, the scope of this document really is intended only to handle flow sampling use cases for resource constraint avoidance, that is certainly useful, but I would suggest in that case that it should be made Informational, and that an updated working group charter reflect a need to handle generalized flow selection in a separate document.

The state of the document today does acknowledge all these potential corner cases (mainly through "flow property match filtering"), but as noted by Paul provides no specification of a method for configuring this property match filtering, or reporting anything about it other than flow counts. I don't really blame the authors of the document for this: it is a very hard problem, and somewhat out of scope from the original work they intended to bring into the working group. But we do seem to be far from WG consensus on whether this document fits the charter.

I think, given this, that we may want to consider Paul's suggestion and, in the upcoming recharter, change the intended status of this document to Informational, and reduce its scope to more or less the present scope of the document.

Best regards,

Brian

On Sep 6, 2011, at 3:38 PM, Benoit Claise wrote:

>    * for the terminology (example: Flow Selection Process is used instead of the Intermediate Flow Selection Process)
>    * for the figure
> - I just took one example "Random Flow Sampling" and looked at what I should implement to be compliant. And I don't know the answer, and there is not a single example.
> If I compare with the PSAMP protocol specification for Random (packet) sampling, http://tools.ietf.org/html/rfc5476#section-6.5.2.3, this is clear.
> 
> Therefore, I haven't read the entire draft, as there were blocking factors already.
> 
> Regards, Benoit.
> 
>> Nevil, All,
>> 
>> Please find many comments inline. I'd like to see a new version of this draft.
>> 
>> Thanks,
>> P.
>> 
>> 
>>> 
>> Is just one OP allowed, or can they be observed at multiple observation points?
> "a subset from all flows observed at an observation point, into a cache, or in mediatior"
>> 
>> 
> Please add section such as http://tools.ietf.org/html/rfc6235#section-1.2, to be consistent between all the different mediation drafts.
> Note: this should be done as for http://tools.ietf.org/html/draft-trammell-ipfix-a9n-03
>>> 
>>> 2.  Terminology
>>> 
> For example, when I read the definition of Packet Aggregation Process or Flow Selection Process, I was wondering they were not similar to terms defined in other RFCs
>>> As in [RFC5101] and
> I hope the terminology is also in line with http://tools.ietf.org/html/rfc6183 and http://tools.ietf.org/html/rfc5982
>> "The properties (e.g. header information, packet content, AS number) make up the Flow Key."
>> 
>> 
> I really confused by "A Flow Selection Process MAY be part of ... an Intermediate
> Your Flow Selection Process term should be replaced by the Intermediate Selection Process.
>>> 
>>>    * Flow Selection State
>>> 
> If I do flow based random sampling, do I use a Flow Selector? I mean, I will look at all the flows in the caches, not individual flows
>>> 
>> Flow Selection Process within the flow time-out interval, and which belong to the ..."
>> 
>> 
>> Is there a way to control which fields from the Flow Record go in to the hash?
>> 
>> Else, if two devices implement the same hash, are fed the same packets, and implement the same flow records - except that the fields are in a different order - then they may produce different output.
>> 
>> 
>> Again, please clarify exactly what the flow state is. It seems worth defining the "Flow-state" term.
>> 
>> Are those real examples? Surely preferring packets for small flows gives lots of details without giving the big picture and may quickly fill the cache (not withstanding that everything starts as a small flow anyway...), while preferring packets for large flows may grow whatever flows are initially observed into "large" flows while discarding individual packets which would eventually make a truely "large" flow.
>> 
>> Unless this is something you want to develop, I'd just remove the "(e.g. ...)" section.
>> 
>> [Later] I see that you mention "large" flows several times. Does this require foreknowledge of what may constitute a large flow? Else, how can you correctly select packets which pertain to the "large" flows?
>> 
>> 
>>>    * Flow Sampling
>>> 
>> I'm hoping that  a discussion of the pros and cons of each method and recommendations as to when to use each method will follow.
>> 
>> [Later] It may be worth saying "Discussion of these methods appears in section 5 below".
>> 
>> 
>>> 
>>> 
>>> 
>>> 
>> Just one observation point? Therefore the techniques can't be used when traffic has been aggregated from multiple OPs?
>> 
>> 
>> So consider, "either the complete flow is kept or the complete flow is discarded".
>> 
>> 
>> Packets don't enter the flow selection process, since the flow selection process operates on complete flows (per the definition above).
>> 
>> 
>> eg, after the IFSP, the EP may need to perform selection to throttle the export bandwith.
> A flow selection happens where there are flows, and you mention that flow selection can take place in "packet filtering", "packet aggregation". It doesn't make sense.
> This figure should be redrawn according to the figure A at http://tools.ietf.org/html/rfc6183#section-4, with Intermediate Flow Selection Process
>>> 
>> So the hash cannot be on non-key fields? I didn't see that specified anywhere.
>> 
>> 
>> Surely flow cache size would be of interest at the metering process rather than at the exporting process?
>> 
>> 
>> (From an implementation point of view, I wouldn't do this since "per" involves division which I don't have time for when the cache is full...)
>> 
>> 
>> I don't follow the example, because a regular MP doesn't meter flows; it meters packets - so this would be systematic *packet* sampling rather than systematic *flow* sampling.
>> 
>> Also, the example sounds like a filter: flows f were sampled, while flows f' were not.
>> 
>> 
>> It would bee good to explain the difference between n-out-N and probabilistic flow sampling.
>> 
>> 
>> If the sampling rate is adjusted per individual flow record, how do you propose to report the sampling rate(s) correctly to allow normalisation and the correct interpretation of the data?
>> 
>> 
>> Why keep info about non-selected flows? What will be done with it? If the point of selection is to get rid of uninteresting flows, keeping the stuff that wasn't selected is just wasteful.
>> 
>> 
>> Don't use RFC5102 as the reference, use IANA - since there are now many more IEs in IANA than in 5102, you're adding an unintentional limitation.
>> 
>> 
>> Are there other possibilities, eg not-equal, less-than, greater-than, regexp?
>> 
>> The table above says "Flow Key fields, filter function" (for the relevant "Selection Input"). Is the text here supposed to align with or relate to the table in any way?
>> 
>> 
>> Again, the table above says, "selection range, Hash Function, Flow Key" - so there's some similarity between the text and the table, but they don't align.
>> 
>> 
>> Is 's' the name of the threshold? It's not an obvious choice and looks like a typo.
>> 
>> Consider:
>> 
>> Can these methods be used together? eg, observe 10 flows, then wait 10 seconds?
>> 
>> 
>> Again, the same point about N, n and p - it's not immediately clear that these are variables rather than typos.
>> NB u64 may be insufficient for this since all bytes in all flows = all traffic entering the selection process.
>> 
>> eg, monitoring 1000 x 10g interfaces, this allows for < 2^24 seconds of traffic, which is about 170 days. Perhaps this is enough today... though perhaps not so next year.
>> 
>> 
>>>    ElementId: TBD9
>>> 
>>>    Units: Octets
>>> 
>> In short, if you can gain control of the box then you can do bad things. This is well known.
>> 
>> Does this document expose any new security considerations for the reader / implementer?
>> If not, then consider stating that explicitly (copy the "no new security implications" text from other IPFIX RFCs) in order to avoid creating a negative impression (ie, that implementing this draft exposes security risks).
>> 
>> 
>>> 
>>> 
>>>

---

From: Nevil Brownlee <[email-masked]>
Date: Wed, 21 Sep 2011 10:48:41 +1200

Hi again flow-selection authors:

Reading Paul's comment again (below), do you agree with his suggestion
about 'Informational?'  If not, the draft really does need to specify
at least some of the sampling methods ...

Cheers again, Nevil

-- 
---------------------------------------------------------------------
  Nevil Brownlee                    Computer Science Department | ITS
  Phone: +64 9 373 7599 x88941             The University of Auckland
  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand