Current Meeting Report
Jabber Logs

2.4.10 Packet Sampling (psamp)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 07/23/2002

Andy Bierman <>
Juergen Quittek <>
Operations and Management Area Director(s):
Randy Bush <>
Bert Wijnen <>
Operations and Management Area Advisor:
Randy Bush <>
Mailing Lists:
General Discussion:
To Subscribe:
In Body: subscribe
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:
AUG 02  Submit Framework document
NOV 02  Submit Packet selector and packet information document
FEB 03  Submit Report format and report stream format document
MAY 03  Submit Export and requirements for collectors document
AUG 03  Submit MIB document
No Current Internet-Drafts
No Request For Comments

Current Meeting Report

PSAMP meeting on Nov 18, 2002
reported by Juergen Quittek

Mark Allman on IRTF IMRG

Mark Allman announced the new IRTF Internet Measurement Research Group 
(IMRG) It is just starting and Mark briefly explained the goals.

Andy Bierman on WG status

Andy Bierman reported on the WG status. He asked whether or not the 
current list of documents to be produced represent the correct grouping of 
content. There was no objection to the current grouping.  Then the 
schedule of the WG documents was discussed and Andy asked for 
volunteers for documents on which work had not started. The current 
charter is not clear about the document schedule: it does not clearly 
distinguish initial submission and completion of documents. Nick 
Duffield explained that initial submission was intended.

The following schedules were suggested:
   Schedule for doc 3 (report formats):    Feb03 / Jun03
   Schedule for doc 4 (export):            Feb03 / Jun03
   Schedule for doc 5 (MIB):               Mar03 / Aug03

Nick Duffield volunteered to submit the initial version of doc 3, Benoit 
Claise volunteered for doc 4, and Dan Romascanu volunteered for doc 5.

Andy will update the agenda accordingly.

Nick Duffield on the framework document

Nick discussed the following framework components
    - configurability
    - - per device 
    - - per measurement process
    - - per collector?
    - collector driven rate control
    - selection operations
    - - framework should discuss but not solve issues
    - do we want to support iTrace (ICMP traceback) type of 
    - issue on specifying sampling algorithms
    - - should specify functional requirements and not constrain 
    - sampling types: what can the application expect if 2 sample probes 
with the same algorithm 
There was very little discussion on this. 

Unknown speaker: co-operation with ITRACE WG?
Randy Presuhn: Support of IP tracing applications
The issue was delegated to the mailing list

Juergen: Can sampling be specified precisely enough that 
interoperability is given?
Tanja: Confidentce intervals can be given. 

Tanja Zseby on packet selection document


Tanja gave an overview on her terminology which is not yet consistent with 
the framework document. It was agreed to move her terminology section to the 
framework document.

Emile: Is time synchronization considered? It might be desirable for 
example for path discovery.
Tanja: yes, but not explicitly
Andy: Time synchronization is not in our scope

Then Tanja discussed the information model for packet selection.
The model was discussed concerning its completeness and openness.

Dan: Concern about openness of information model: might be too complex, 
better not do it
Nick: Concern about openness of information model: might be too 
restricted. There might come up future sampling techniques that cannot be 
expressed with this model.

Juergen on Relationship to IPFIX

Juergen suggested to use common terminology for both groups.
Further suggestions:
  - use PSAMP packet selection model in IPFIX
  - use IPFIX export protocol for PSAMP packet export there might be 
problems with different reliability requirements. The higher IPFIX 
requirements might be too much for PSAMP
  - use PSAMP packet selection configuration for IPFIX meter 



PSAMP Framework Document
IRTF Internet Measurement RG
On the Relationship between PSAMP and IPFIX
Sampling and Filtering Techniques for IP Packet Selection