Current Meeting Report

2.3.11 Packet Sampling (psamp) Bof

Current Meeting Report

Minutes of the Packet Sampling (PSAMP) BOF
IETF 53, Minneapolis, Tuesday March 19, 2002; 9:00-11:30

Reported by Nick Duffield (chair), Albert Greenberg, Sonia Panchen and Dave Plonka.

Attendance: 123

BOF agenda, scope, status (Nick Duffield)
Motivation for packet sampling (Albert Greenberg)
Experiences using widespread packet sampling (Sonia Panchen)
Initial comments on PSAMP (Will Eatherton/Benoit Claise)
Comments on PSAMP (Derek Chiou)
Packet hashing and sampling applications (Nick Duffield)
Elements of a framework for PSAMP (Nick Duffield)
Draft Charter (Nick Duffield; omitted for lack of time)

Agenda Discussion

No changes were proposed.

Motivation for Packet Sampling (Albert Greenberg)

Albert motivated PSAMP as a working group to standardize ubiquitous passive packet sampled measurement capabilities. These would support existing and new measurement-based applications with reliable, detailed, direct and timely measurements, available at line rate on all line cards, measurement ASICs, monitors, etc. A PSAMP working group would reach agreement among router and monitor vendors, software developers, xSPs, and others, on a set of simple packet selection mechanisms with well-defined and consistent interfaces, in a specification that vendors can build to. PSAMP primitives would aim to (1) offer packet-level measurements to higher level "on-board" or "off-board" applications, (2) allow for low-latency between measurement and reporting, and (3) allow for parallelism in measurement (i.e., more than one logically independent packet sampling operation, operating on the same packet stream). PSAMP aims to explore the potential to use IPFIX (working group focusing on export of information on aggregations providing summaries of packet trains) solutions for data export and information modeling, where requirements line up. However, there would be a danger of mutual slowdown if the two efforts were coupled too strongly.

PSAMP primitives address which packets to select and which information to export. Albert remarked that aiming for simplicity is critical: (1) realistically, the goal of pervasive passive packet sampling support suggests simple, stateless primitives, and (2) simple primitives suffice for a wide range of measurement applications (e.g., traffic engineering, DoS attack detection, data for capacity planning and billing, guidance for "what-if's" in network and service planning).

Albert discussed example applications (troubleshooting congestion, traffic engineering, capacity planning, and managing peering relationships), where it makes sense to use wide-open, low rate sampling to identify large traffic volumes, and more narrow selection of which packets to sample to drill down and analyze things further. Trajectory Sampling* is a hash-based form of packet sampling that provides immediate and direct observation of network behavior, without need for complex joins with potentially stale routing and forwarding table data. Albert noted that it is very important to control measurement overhead, and a mechanism to cap the rate that packet samples are provided for export is needed. As exported packet sample measurements may get lost inside the network or inside the router, it is important that the PSAMP export format support sequence numbers. In addition, information on the configuration state of sampling should be available in the reporting stream.

*Intellectual Property: AT&T Corp. may own intellectual property applicable to this contribution. AT&T is currently reviewing its licensing intent relative to the Intellectual Property and will notify the IETF when AT&T has made a determination of that intent.

Experiences using widespread packet sampling (Sonia Panchen)

Sonia outlined the history of sampling for network traffic monitoring; sampling is an ideal response to the underlying growth of traffic. She describe the sFlow (RFC 3176) packet sampling system and gave examples of use of the data in the large scale deployments of this system in the Enterprise and Service Provider spaces. 1 in N random sampling provides reliable, detailed and timely data in a scalable way. PSAMP could play a valuable role in promoting the use of sampling for traffic measurements by developing a body of experience, models, and literature that demonstrates the validity of sampling. This could result in a standard set of measurement primitives that are cost effective and simple enough to be implemented (in ASIC) and deployed widely. The measurement techniques are somewhat orthogonal to the data export functions. Sampled, filtered, and hashed data could be exported using any of the existing flow export protocols.

Initial comments on PSAMP (Will Eatherton/Benoit Claise)

Benoit observed need for sampling for measurement in high-end routers. Service providers are requesting standardization of this, and packet pre-processing by filtering and sampling is already becoming commonplace is Cisco routers. He sees a possible goal of PSAMP to specify a "metering process" (in the IPFIX sense) in terms of sampling, filtering and hashing. The use of IPFIX as the PSAMP export should also be explored. There would be a need to address performance issues in the router.

Comments on PSAMP (Derek Chiou)

Derek observed that packet sampling is useful, tractable, and required by vendor customers. Avici is actively supporting customers with their packet sampling requirements. He would like a single, simple standard to implement, and plans to support such a standard.

Packet hashing and sampling applications (Nick Duffield)

Nick described trajectory sampling**, a technique for direct measurement of packet paths through the network that employs hash-based sampling in routers. He described some new measurement applications that are enabled by hash-based sampling, and explained how a packet-hashing capability in PSAMP could be used to support higher-level on-board applications, such as IP Packet Traceback.

**See statement above on intellectual property.

Elements of a framework for PSAMP (Nick Duffield)

PSAMP is positioned as a supplier of packet level measurements to higher level protocols or applications. Nick described key elements for PSAMP: (i) specification of a set of packet selection primitives, and their allowed combinations; (ii) availability of multiple parallel packet selectors, with independently configurable selection parameters, reporting and export; (iii) the resulting report streams should be self-describing, including selection and configuration parameters; (iv) the information in report stream should be robust with respect to loss; (v) configuration information should be contained in a MIB to facilitate out-of-band reconfiguration by external applications; (vi) export to local (on-board) and remote applications.

Discussion of the talks:

There was discussion of how PSAMP goals differ from those of RMON. Albert Greenberg summarized RMON as stateful, with sophisticated means to define triggering events, and use SNMP for export. In distinction, PSAMP has a push model for continuous export, is stateless and is to lightweight enough for ubiquitous implementation.

. Security Applications
People would like to see standardized packet sampling abilities in order to support security applications. There was discussion of whether sampling can capture network attacks. Attacks tend to focus large amounts of traffic; sampling will catch them. For scalable solutions, sampling is needed to prevent overloading the monitoring system.

Can hash based sampling be eluded by malicious parties? Not if the selection range is kept private, even if the hash function is made public. The PSAMP requirement for ease of configuration would facilitate a global change of selection range if necessary.

. Anonymity
People expressed the need for anonymity in measurements. As AD, Randy Bush said that he will work with the group on balancing the opposing requirements of privacy and knowing how a network is used.

. Accuracy
Can sampling can provide sufficient accuracy, especially for bursty events? Statistical models provide accuracy measures that are essential for applications. Only time-based sampling gives rise to problems capturing bursty events. Accuracy for hash-based sampling is managed in the same way as for 1 in N or statistical sampling.

. Dropped Packets
Somebody said that there would be benefit in sampling packets where they were dropped or marked. This is something PSAMP can explore. If packet sampling were applied on ingress interfaces or early in the packet processing pipeline, this would enable reporting on packets dropped or marked. Indeed, on ingress interfaces the necessary logic is likely more readily available.

. Timestamps
Reporting timestamps is essential for some applications.

. Measurement Depth
Several people said that measurement needs to go beyond the 48 byte header. 128 bytes of IP4 packet have been found to serve applications well. Practice currently differs between vendors. Looking deeper can have an impact on performance; customers can trade-off.

. Baselining and Exploration vs. Aggregation
Packet sampling was seen as a useful technique for establishing a baseline, especially in higher speed links. Sampling enables exploration of network usage. PSAMP is an opportunity to get alignment with current practice. Some people wondered whether it is better to aggregate at the router if you know in advance what you want to aggregate; there are already standard aggregations, and this reduces the export volume. However, experience from measurements, e.g. in RIPE, show that the detail necessary to understand emerging trends is not available in aggregated data.

. Counters and SNMP
Could one just use SNMP to retrieve counters kept for PSAMP? Counter values play an essential supporting role to the packet samples; they allow for interpretation of the data and provide robustness. They are easier to correlate with the samples if included in the measurement stream. Also, that polling interface counters may not be scalable.

. Transport
sFlow uses UDP because of low overhead and data resilience to loss. Somebody commented that this can lead to congestion. Sonia Panchen emphasizes that data is usually sent to a collector on the local site, not across the Internet, therefore congestion awareness is less of an issue. Data can be extracted from remote collectors across the Internet using a congestion aware protocol.

How does PSAMP differ from IPFIX, since a packet can be viewed as a degenerate (i.e. 1 packet) case of a flow? PSAMP is primarily about a packet selection mechanisms, whereas IPFIX assumes a (flow) measurement is available and then defines the aggregation configuration and format and export of the data. IPFIX could supply the PSAMP information model and export if IPFIX capabilities align with PSAMP requirements.

Albert Greenberg observed that there may not be complete overlap between measurement requirements for PSAMP and IPFIX. PSAMP does not perform aggregation, while it has some requirements (e.g. graceful degradation under resource scarcity) that may be quite different than for IPFIX. PSAMP has a timeliness requirement. There would be a danger of mutual slowdown by coupling the efforts too strongly.

It was pointed out that IPFIX doesn't want to get into detailed dynamic configuration, whereas PSAMP wants to allow easy out-of-band dynamic changes.

As AD, Randy Bush says that IPFIX will nail-down existing practice, while PSAMP could include new proposals such as hash-based sampling, etc.

Support for chartering PSAMP as a WG

A vote of hums found more in favor than against. There was substantial interest in going forward to charter a PSAMP WG, with attendees signing up for participation as authors (8 people), reviewers (8) and potential implementors (1).

It was agreed to continue discussion of PSAMP scope and draft charter to the mailing list.


Experiences with Widespread Packet Sampling
Motivation for Passive Packet Sampling
Initial Comments on PSAMP
Avici and Packet Sampling
Packet Hashing and Sampling Applications
Elements of a Framework for PSAMP