Sampling and Filtering Techniques for IP Packet Selection
RFC 5475

Cullen Jennings cleared his DISCUSS. The AD is waiting for the edits that would reflect the consensus of the WG regarding the mandatory hash algorithm before sending the final approval announcement

[Ballot comment]
Review by Christian Vogt:

Draft-ietf-psamp-sample-tech-10 identifies and defines packet selection
techniques that are needed for input reduction in network measurements.

The document is very elaborative and certainly very valuable to the
PSAMP community.  For non-experts, however, it would be beneficial if
the document could be clarified according to the following comments:


(1)  Section 1, 2nd paragraph, claims that there are 3 types of packet
selection techniques:  sampling, filtering, and aggregation.  I would
argue that only sampling and filtering are *selection* techniques.
Aggregation is not a selection technique, although it does reduce the
input for network measurement like sampling and filtering do.

I would therefore remove aggregation from the list of packet selection
techniques.  This would not only be more precise, it would also
accommodate the fact that this document is about packet selection, but
does not get into aggregation.


(2)  I was missing a statement of objectives at the beginning of the
document:  What is it that the document is trying to achieve?  Is it to
provide guidance to network administrators when deploying network
measurement equipment?  Is it requirements for network measurement
implementations?  Is it an informational document proposing a set of
definitions for the standardization community to use?


(3)  The document explains that hashing well-defined packet bits is a
technique that can be used for both filtering and emulated sampling.
IMO, it would be good to explain in the document when it is appropriate
to emulate sampling through hashing, and when proper sampling should be
applied instead.  The document currently provides an only very limited
explanation:  In section 4, 4th paragraph, it states that hashing-based
sampling is useful where a consistent set of packets is to be selected
by different devices (although even here it remains unclear why/whether
proper sampling would be inappropriate in such a situation).


(4)  The table starting on page 27 summarizes packet selection
techniques.  The 3rd column is defined as functions that a particular
packet selection technique must execute in order to select a packet.
However, some of the fields in the 3rd column render this definition
circular because they include "selection function" or "filter function"
(i.e., a class of selection function).

[Ballot comment]
Review by Christian Vogt:

Draft-ietf-psamp-sample-tech-10 identifies and defines packet selection
techniques that are needed for input reduction in network measurements.

The document is very elaborative and certainly very valuable to the
PSAMP community.  For non-experts, however, it would be beneficial if
the document could be clarified according to the following comments:


(1)  Section 1, 2nd paragraph, claims that there are 3 types of packet
selection techniques:  sampling, filtering, and aggregation.  I would
argue that only sampling and filtering are *selection* techniques.
Aggregation is not a selection technique, although it does reduce the
input for network measurement like sampling and filtering do.

I would therefore remove aggregation from the list of packet selection
techniques.  This would not only be more precise, it would also
accommodate the fact that this document is about packet selection, but
does not get into aggregation.


(2)  I was missing a statement of objectives at the beginning of the
document:  What is it that the document is trying to achieve?  Is it to
provide guidance to network administrators when deploying network
measurement equipment?  Is it requirements for network measurement
implementations?  Is it an informational document proposing a set of
definitions for the standardization community to use?


(3)  The document explains that hashing well-defined packet bits is a
technique that can be used for both filtering and emulated sampling.
IMO, it would be good to explain in the document when it is appropriate
to emulate sampling through hashing, and when proper sampling should be
applied instead.  The document currently provides an only very limited
explanation:  In section 4, 4th paragraph, it states that hashing-based
sampling is useful where a consistent set of packets is to be selected
by different devices (although even here it remains unclear why/whether
proper sampling would be inappropriate in such a situation).


(4)  The table starting on page 27 summarizes packet selection
techniques.  The 3rd column is defined as functions that a particular
packet selection technique must execute in order to select a packet.
However, some of the fields in the 3rd column render this definition
circular because they include "selection function" or "filter function"
(i.e., a class of selection function).

[Ballot discuss]
Most of this was very clear but I don't understand the hash function recommendations here.

Section 6.2.2 explains the security considerations for hash function
selection, including algorithm complexity attacks.  But the hashes
that are recommended don't seem to match these requirements. Actually,
one of them, CRC-32 is identified as not meeting these requirements,
which is puzzling.

Why does Section 6.2.3.1 have any hashes at SHOULD? How will interop work? What hashes can one side assume the other side implements?

I have a hard time deciding the meaning of "X SHOULD be used. Y and Z MAY be used." Does this mean Y and Z SHOULD NOT be used?

This particular function, BOB, seems pretty ad hoc. I'm also
fairly uncomfortable with it being defined in (non-portable) C
code in an appendix. This seems like something that should be defined in
some more formal fashion.

[Ballot discuss]
First of all, I don't think that this is appropriate as standards track. This document talks generally about what one could do for packet sampling, and describes a number of options, but doesn't give explicit details regarding what actually needs to be implemented. A wide range of implementations might be said to compy with this document, and thus I don't understand what it means for this to be a standard. Informational makes more sense to me.

On re-reading the protocol document, the framework, and this document, I think that I now am satisfied wrt the relationship between this document as compared to draft-ietf-opsec-filter-caps-09. The opsec document could be referenced as providing examples of selecter criteria for filters, but since this would presumably only be an informational reference this can be considered a COMMENT and I won't hold my discuss on it.

[Ballot discuss]
First of all, I don't think that this is appropriate as standards track. This document talks generally about what one could do for packet sampling, and describes a number of options, but doesn't give explicit details regarding what actually needs to be implemented. A wide range of implementations might be said to compy with this document, and thus I don't understand what it means for this to be a standard. Informational makes more sense to me.

On re-reading the protocol document, the framework, and this document, I think that I now am satisfied wrt the relationship between this document as compared to draft-ietf-opsec-filter-caps-09. The opsec document could be referenced as providing examples of selecter criteria for filters, but since this would presumably only be an informational reference this can be considered a COMMENT and I won't hold my discuss on it.

[Ballot comment]
I reviewed this document  to make sure it was in line with:
  the IPFIX protocol draft, so that one could use IPFIX to export the information
  the PSAMP protocol draft, so that one could PSAMP (which is based on IPFIX) to export the information
  the PSAMP architecture draft
  the PSAMP information model (which is based on the IPFIX information model)

and all that appears "ok."

Regarding the document itself, I would say that it contains
  - the common sampling mechanisms used routers
  - some more complex sampling mechanisms, based on the consensus
  - a very basic filtering mechanism (logical AND)
  - some hashing mechanisms, for trajectory sampling
Even if we had some requests to add some extra mechanisms, I would say that this draft is complete. Anyway, there is an IANA procedure for new mechanisms.

Why make it PS? Only because there is the inclusion of the basic filtering mechanism and the hashing for trajectory sampling. Although as other mention, it is laden w/ IPR.

[Ballot comment]
I reviewed this document  to make sure it was in line with:
  the IPFIX protocol draft, so that we could use IPFIX to export the information
  the PSAMP protocol draft, so that we could PSAMP (which is based on IPFIX) to export the information
  the PSAMP architecture draft
  the PSAMP information model (which is based on the IPFIX information model)

and all that appears "ok."

Regarding the document itself, I would say that it contains
  - the common sampling mechanisms used routers
  - some more complex sampling mechanisms, based on the consensus
  - a very basic filtering mechanism (logical AND)
  - some hashing mechanisms, for trajectory sampling
Even if we had some requests to add some extra mechanisms, I would say that this draft is complete. Anyway, there is an IANA procedure for new mechanisms.

Why make it PS? Only because there is the inclusion of the basic filtering mechanism and the hashing for trajectory sampling. Although as other mention, it is laden w/ IPR.

[Ballot discuss]
First of all, I don't think that this is appropriate as standards track. This document talks generally about what one could do for packet sampling, but doesn't give explicit details regarding what actually needs to be implemented. A wide range of implementations might be said to compy with this document, and thus I don't understand what it means for this to be a standard. Informational makes more sense to me.

Also, I don't understand the relationship between this document as compared to draft-ietf-opsec-filter-caps-09. The latter gives quite specific recommendations on what a router might choose to filter on, and what one might do with packets that match a particular filter (count, discard, copy, etc..).

Also, given this last question, it might make sense to last call draft-ietf-psamp-sample-tech in the opsec working group.

[Ballot discuss]
This is a very well written document but I have one question. "What is the rationale for publishing this document on the standards track?" Doesn't it seem more appropriate as INFORMATIONAL?

Also, this comment from Fred Baker on the OPS-DIRECTORATE:

The one "fix" I would recommend is to get a definition of the term  "transport". The term is used three times without definition. I have  heard the term used for the framing protocol on a DS1 interface  (physical layer), ATM and similar services in the intranet sublayer  of the Network layer, IP itself (also a sublayer of the Network  layer), TCP/SCTP/etc, SSH, and the BitTorrent file fragmentation/ assembly module. As such, I think the word "Transport" should always  be defined in any context in which it is used unless the definition  is implicit (a protocol whose name contains the word "Transport" is  probably the transport, at least from its perspective).

[Ballot comment]
This from Fred Baker of the OPS-DIRECTORATE:

My principal comment has to do with the IPR. AT&T among others have  IPR that affects this technology and have filed a RAND statement with  no comment on terms. While much of this document is presently  implemented in vendor equipment and used in operational networks,  trajectory sampling is not. Since the apparent objective of the  document is to make trajectory sampling based on interesting filters  commonly available for operational use, the IPR statement reduces the  document's utility. Since this is a non-technical issue, I would not  ask the working group for a change in the document; this is a comment  to the working group and the authors.

A second comment has to do with the use of sampling in the first  place. It isn't clear that sampled analysis meets the needs of the  European Union's Data Retention mandates. As such, either the Data  Retention mandate is creating a requirement for additional technology  beyond the needs of the service providers (something they have stated  they don't intend), or sampled data fails to meet some operational  requirement that I don't know about. In any event, vendors and ISPs  have to somehow come to terms with the disparate requirements, and  can't simply use sampling to replace full-scale accounting. This  comment is out of scope for psamp, but is relevant to ops-dir.

[Ballot discuss]
This is a very well written document but I have one question. "What is the rationale for publishing this document on the standards track?" Doesn't it seem more appropriate as INFORMATIONAL?

Also, this comment from Fred Baker on the OPS-DIRECTORATE:

The one "fix" I would recommend is to get a definition of the term  "transport". The term is used three times without definition. I have  heard the term used for the framing protocol on a DS1 interface  (physical layer), ATM and similar services in the intranet sublayer  of the Network layer, IP itself (also a sublayer of the Network  layer), TCP/SCTP/etc, SSH, and the BitTorrent file fragmentation/ assembly module. As such, I think the word "Transport" should always  be defined in any context in which it is used unless the definition  is implicit (a protocol whose name contains the word "Transport" is  probably the transport, at least from its perspective).

[Ballot discuss]
This is a very well written document but I have one question. "What is the rationale for publishing this document on the standards track?" Doesn't it seem more appropriate as INFORMATIONAL?

IANA Last Call comments:

IANA has questions.

IESG NOTE: Expert required.

Upon approval of this document, the IANA will in the following
registry "IP Flow Information Export (IPFIX) Parameters" located at
http://www.iana.org/assignments/ipfix-parameters
create a new sub-registry "PSAMP selectorAlgorithm Information Element"

Assignment by First Come First Served, subject to Expert Review
Initial contents of this sub-registry will be:

[ NOTE: It looks like you define Selector Algorithms in the document
(sections 6.5.2.x) but nowhere do you have a table of them. Please
create a table of selectorAlgorithms. In addition, what information
is required in the registry? ]

We understand the above to be the only IANA Action for this document.

PROTO write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Juergen Quittek is the document shepherd.
He has personally reviewed this version of the document and believes
it is ready for forwarding to the IESG for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

An adequate review by key WG members was performed.
The document shepherd has no concerns about depth and breadth of the reviews.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

There are no such concerns.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is a solid WG consensus on the content of the draft.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Yes.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

Yes, references are split into two sections.
There are no normative references that are not already published as RFC.
There are no downward references.


(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

There is a section on IANA considerations and it correctly states that
this document has no actions for IANA.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

There are no such sections.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

Technical Summary

This document describes Sampling and Filtering techniques for IP
packet selection. It provides a categorization of schemes and
defines what parameters are needed to describe the most common
selection schemes. Furthermore it shows how techniques can be
combined to build more elaborate packet Selectors. The document
provides the basis for the definition of information models for
configuring selection techniques in Measurement Processes and
for reporting the technique in use to a Collector.

Working Group Summary

This document has been a regular WG document. There is strong
consensus in the working group that this document describes an
appropriate sampling and filtering techniques for IP packet selection.

Document Quality

There are no known implementations yet, but two vendors
and academic research institutes announced implementations.
The document is fully supported by the WG and there has no
concerns been raised that there are better alternatives or
that the document is not useful.