Last Modified: 2003-10-28
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]
|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|
There is the general feeling that the export protocol for PSAMP is waiting on IPFIX.
Tanja Zseby on packet selection
Tanja presented progress on the packet selection document. Terminology is now almost consistent with the framework document. After recent discussions only small changes are required here. Packet selectors could be part of IPFIX or other metering process. A still open issues is the set of methods for flow state sampling. Further open issues of the document include: Should we include some examples for flow state sampling or just leave it open to vendor-specified parameters based on the info model? Is there a better term for hash-based sampling than "emulation" or "approximation"?
Benoit Claise on the PSAMP protocol
Benoit discussed the initial version of the PSAMP protocol document describing how the IPFIX protocol is used for exporting packet records. The IPFIX documents only speak about 'flow records'. These will be used as 'packet records' in PSAMP. The information model of IPFIX and PSAMP overlap. The PSAMP information model can be defined as extension of the IPFIX information model.
Benoit Claise on the PSAMP information model
Benoit presented the initial draft of the PSAMP information model. It is defined as extension of the IPFIX information model and adds a data type of a variable length byte array and it adds several information elements. It needs to be synchronized with the packet selection document.
Jürgen Quittek [on behalf of Thomas] on the PSAMP MIB
Very small changes were committed to the PSAMP MIB since the document depends on the packet selection document that was submitted just before the cut-off date leaving no time to reflect it in the PSAMP MIB. Committed changes concerned the support of multiple receivers of packet samples. We need to determine which portions are mandatory and which optional.
Maurizio Molina about hash functions
So far, the WG documents to not precisely describe hash functions. The presented individual I-D suggests to do so and defines some hash functions that have already been tested.
Emile Stephan about spacial metrics for IPPM
Emile suggests that one use of psamp is to determine the delay and loss of individual packets [and thus would perhaps benefit from IPPM defined spatial metrics for same].
Andy asked authors to post their open issues to the mailing list.