2.4.12 Packet Sampling (psamp)

NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-02-12

Andy Bierman <abierman@cisco.com>
Juergen Quittek <quittek@ccrle.nec.de>
Operations and Management Area Director(s):
Bert Wijnen <bwijnen@lucent.com>
David Kessens <david.kessens@nokia.com>
Operations and Management Area Advisor:
David Kessens <david.kessens@nokia.com>
Mailing Lists:
General Discussion: psamp@ops.ietf.org
To Subscribe: psamp-request@ops.ietf.org
In Body: subscribe
Archive: https://ops.ietf.org/lists/psamp/
Description of Working Group:
The Packet Sampling working group is chartered to define a standard set of capabilities for network elements to sample subsets of packets by statistical and other methods. The capabilities should be simple enough that they can be implemented ubiquitously at maximal line rate. They should be rich enough to support a range of existing and emerging measurement-based applications, and other IETF working groups where appropriate.

The focus of the WG will be to (i) specify a set of selection operations by which packets are sampled (ii) specify the information that is to be made available for reporting on sampled packets; (iii) describe protocols by which information on sampled packets is reported to applications; (iv) describe protocols by which packet selection and reporting configured.

Packet reports must be communicable in a timely manner, to applications either on-board of off-board the sampling network element. The streams of packet reports produced by a packet sampling must (i) allow consistent interpretation, independent of the particular network element that produced them; (ii) be self-defining, in that their interpretation does not require additional information to be supplied by the network element; (iii) allow robustness of interpretation with respect to missing reports or part of reports;

Network elements shall support multiple parallel packet samplers, each with independently configurable packet selectors, reports, report streams, and export. Network elements must allow easy and secure reconfiguration of these packet samplers by on-board or external applications.

Export of a report stream across a network must be congestion avoiding in compliance with RFC 2914. Unreliable transport is permitted because the requirements at the exporter for reliable transport (state maintenance, addressibilty, acknowledgment processing, buffering unacknowledged data) would prevent ubiquitous deployment. Congestion avoidance with unreliable export is to be accomplished by the following measures, which shall be mandatory to implement and use. The maximum export rate of a report stream must be configurable at the exporter. A report stream must contain sufficient information for transmission loss to be detected a collector. Then the collector must run a congestion control algorithm to compute a new sending rate, and reconfigure the exporter with this rate. In order to maintain report collection during periods of congestion, PSAMP report streams may claim more than a fair share of link bandwidth, provided the number of report streams in competition with fair sharing traffic is limited. Selection of the content of packet reports will be cognizant of privacy and anonymity issues while being responsive to the needs of measurement applications, and in accordance with RFC 2804.

Re-use of existing protocols will be encouraged provided the protocol capabilities are compatible with PSAMP requirements.

Specifically, the PSAMP WG will perform the following tasks, in accordance with the principles stated above:

1. Selectors for packet sampling. Define the set of primitive packet selection operations for network elements, the parameters by which they may be configured, and the ways in which they can be combined.

2. Packet Information. Specify extent of packet that is to be made available for reporting. Target for inclusion the packet's IP header, some subsequent bytes of the packet, and encapsulating headers if present. Full packet capture of arbitrary packet streams is explicitly out of scope. Specify variants for IPv4 and IPv6, extent of IP packet available under encapsulation methods, and under packet encryption.

3. Sampled packet reports. Define the format of the report that is constructed by the network element for each sampled packet for communication to applications. The format shall be sufficiently rich as to allow inclusion in the packet report of (i) IP packet information as specified in paragraph 2 above; (ii) encapsulating packet headers as specified in paragraph 2 above; (iii) interface or channel identifiers associated with transit of the packet across the network element; (iv) quantities computable from packet content and router state, (v) quantities computed during the selection operation. All reported quantities must reflect the router state and configuration encountered by the packet in the network element.

4. Report Streams. Define a format for a stream of packet reports, to include: (i) the format of packet reports in the stream; (ii) the packet reports themselves; (iii) configuration parameters of the selectors of the packets reported on; (iv) configuration parameters and state information of the network element; (v) quantities that enable collectors and applications to infer of attained packet sampling rates, detect loss during samping, report loss in transmission, and correct for information missing from the packet report stream; (vi) indication of the inherent accuracy of the reported quantities, e.g., of timestamps.

5. Multiple Report Streams. Define requirements for multiple parallel packet samplers in one network element, including the allowed degradation of packet reporting when packets are selected by multiple packet samplers.

6. Configuration and Management. Define a packet sampler MIB to reside at the network element, including parameters for packet selection, packet report and stream format, and export. Select or define a communication protocol to configure/read this MIB.

7. Presentation, Export, and Transport of Packet Reports. Define interface for presentation of reports to on-board applications. Select unreliable transport protocol for remote export. Determine rate control algorithms for export.

Initial Internet-Draft: A Framework for Passive Packet Measurement [draft-duffield-framework-papame]

Goals and Milestones:
Done  Submit initial Framework document
Done  Submit initial Packet selector and packet information document
Done  Submit initial Report format and report stream format document
Done  Submit initial Export and requirements for collectors document
Done  Submit initial MIB document
May 03  Submit final Framework document
May 03  Submit final Packet selector and packet information document
Sep 03  Submit final Report format and report stream format document
Oct 03  Submit final Export and requirements for collectors document
Nov 03  Submit final MIB document
  • - draft-ietf-psamp-framework-05.txt
  • - draft-ietf-psamp-sample-tech-04.txt
  • - draft-ietf-psamp-mib-02.txt
  • - draft-ietf-psamp-protocol-01.txt
  • - draft-ietf-psamp-info-01.txt
  • No Request For Comments

    Current Meeting Report

    Minutes of the PSAMP session at IETF 59
    Tuesday March 2, 09:30 h - 11:30 h

    Session summary

    The PSAMP WG discussed the first two documents that are close to completion (expected in April). The framework document is in last call and just needs some serious detailed review. The packet selection document is close to be ready for last call. The only major open issue is the selection of a mandatory hash function. The existing suggestions were technically evaluated, but IPR issues are still unclear.

    The remaining documents (protocol, information model, and MIB module) are progressing slowly. All of them depend on documents of the IPFIX WG. The editors were advised to use the time until the IPFIX documents are stable for solving all independent issues.

    1. WG Status (Juergen Quittek)

    Juergen presented the list of WG documents and summarized their respective states. The PSAMP Framework document is in WG last call and still waiting for further review. The document on Packet Selector and Packet Information is almost ready for WG last call. The remaining three documents (Report Format and Report Stream Format, Export Protocol and Requirements for Collectors, PSAMP MIB) all depend on the IPFIX protocol and information model, which are still under development. Therefore progress there is slow, just IPFIX-independent issues are progressing.

    2. PSAMP Framework, draft-ietf-psamp-framework-05.txt (Nick Duffield)

    Nick first reported on changes in the framework since the last session. Confidentiality protection available for exported packet records was required for IPFIX by the IESG. Since PSAMP uses the IPFIX protocol, this also applies to PSAMP. In PSAMP confidentiality is even more important because laso payload of packets may be exported. Timestamps SHOULD have microseconds resolution. Accuracy of timestamps MUST be reported.
    [Benoit Claise] IPFIX already requests microseconds precision
    [Randy Presuhn] Use the finest precision considered in order to be future-proof.
    [Andy Bierman] Is applied resolution fine to be reported in the MIB.
    [Nick] It would be desirable to have the PSMAP data stream self-contained.
    [Juergen] to be done by option record. A discussion of packet selection of encrypted packet was added to the framework.
    [Nick] MUST be configurable to ignore encrypted packets.
    [Andy] This is an issue for the MIB module. The section discussing sequence numbers was extended as well as the section on expoert timelyness.
    [Nick] include sequence number in every report.
    [Juergen] Could this be a matter of configuration.
    [Andy] This puts a lot of additional effort. Let's investigate it first.

    Nick asked about recent developments in IPFIX. For IPFIX, SCTP is a MUST. Does this mean SCTP-PR is required? Is it sufficient to just support SCTP-PR? These questions were forwarded to the IPFIX WG session.
    [Nick] Is it OK with IPFIX if a PSAMP probe just reports packet slices?
    [Juergen] Yes, IPFIX supports that. This should be explicitly mentioned by the protocol document.
    [Nick] PSAMP proble SHOULD be able to also filter non-IP packets.
    [Juergen] IPFIX does not cover non-IP packets.
    [Andy] We should use MAY instead of SHOULD.
    [Nick] MAY is probably OK.
    [Emile] It is not clear how the configuration for sampling non-IP packets is done and how to do hash-based trajectory sampling with non-IP packets.
    [Andy] Better avoid it because of its complexity that was discovered by the RMON WG.

    There is no obvious need to delay this document until work in the IPFIX WG has progressed further. Therefore, this document can be passed to the AD as soon as WG last call is closed. Yet, to be discussed is the targeted RFC status. SHOULD it be informational or standards track?
    [Juergen] It's OK if requirements are implemented by standard docs
    [Randy] For a framework document the statement of compliance becomes nebulous.
    [David Kessens] Let's discuss it later and come back to the issue on the mailing list.

    3. Packet Selection, draft-ietf-psamp-sample-tech-04.txt (Tanja Zseby)

    Tanja presented changes to the Packet Selection I-D since the last meeting. Two mandatory hash functions were included, one for random sampling and one for packet identifier genration.

    An evalaution performed by Maurizio Molina and Nick led to the selection of the IP Shift-XOR algorithm for random sampling and the CRC32 for packet ID generation.

    The I-D is almost ready for WG last call, it just needs one more revision.

    4. Hash Function Comparison (Nick)

    Nick presented slides on the comparison of hash functions prepared by Maurizio. They comparison covered the technical differences.
    [Andy] IPR need to be included in the evaluation.
    [Nick] IPSX may be protected by IPR.
    [Juergen] We need to evaluate the IPR issue for all four candidates.
    [Stewart Bryant] Hash function selection should also cover the IP version IPSX does not cover IPv6.

    5. PSAMP Protocol Specification, draft-ietf-psamp-protocol-01.txt (Benoit)

    Benoit reported on recent changes of the protocol specification. Most important is the fact that now the decision about SCTP as mandatory transport protocol was made.

    There were two major open issues. First, do we want to distinguish export with one packet from a PSAMP export?
    [Juergen] We must be able to distinguish IPFIX flow records containing a single packet from a PSAMP report on a sampled packet
    [Benoit] the content is not different
    [Andy] There is a difference between reporting flows and reporting packets

    The seond open issue is concerned with reporting the sequential order of sampling and filtering.
    [Tanja] The packet selection draft gives directions.
    [Andy] We need to make sure that option records and MIB content are consistent.

    6. PSAMP Inforamtion Model, draft-ietf-psamp-info-01.txt (Juergen)

    Juergen presented slides prepared by Thomas Dietz. The major change was the alignent with the new structure of the IPFIX information model: The XML prepresentation of the information model was changed. The information model is now better aligned with the packet selection I-D. Still open is the info model for packet filtering, for the sequence of sampling and filtering and for the observation point. Also, the numbering scheme of the PSAMP fields to be registered by IANA is not clear.

    7. PSAMP MIB, draft-ietf-psamp-mib-02.txt (Juergen)

    Juergen presented slides prepared by Thomas Dietz. Thomas updated the sampling methods according to the new version of the packet selection I-D. He added a simple structure for representing templates. This needs to be further elaborated. Most still open issues depend on progress in the information model.

    8. WG Schedule

    The WG is far behind its planned schedule. One reason for this is the dependency on progress in the IPFIX working group. The framework and packet selection documents are expected to be completed soon, the other three documents are expected to be completed one IETF meeting after the IPFIX protocol and information model documents are complete.


    PSAMP Framework Document Sampling and Filtering Techniques for IP Packet Selection - Update -
    Hash Function comparison for PSAMP purposes: results and suggestions
    PSAMP Protocol Specifications
    PSAMP Information Model Status
    PSAMP MIB Status