Current Meeting Report
Slides
2.4.13 Packet Sampling (psamp)
NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.
Last Modifield: 06/28/2002
Chair(s):
Nick Duffield <duffield@research.att.com>
Operations and Management Area Director(s):
Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>
Operations and Management Area Advisor:
Randy Bush <randy@psg.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:
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 WG Meeting Minutes
IETF #54
July 16, 2002
110 people attending
Minutes by Andy Bierman and Nick Duffield
Minutes
-------
The meeting started with a note from the Area Director that the PSAMP WG has been chartered and new WG Chairs were appointed just before and after the meeting (Andy Bierman and Juergen Quittek). The meeting was chaired by Nick Duffield, who will step down as WG Chair in order to remain an author of WG documents.
Nick reviewed the goals of the WG. The major technical issues facing the WG are specifying packet selection operations, the choice of report format and protocol, and the choice of transport protocol. These issues were addressed in more detail, later in the meeting. Refer to the slides for more details on the goals of the PSAMP WG.
Matt Grossglauser presented slides on transport issues and multiple measurement banks for sample collection.
Multiple Measurement Banks: these enable multiple concurrent measurement tasks at different time and space scales. It is not envisaged that the WG would mandate a specific number of banks.
Transport Reliability: The transport does not have to be reliable because loss of sample reports is not deemed to be important. Furthermore, requirements on exporters to support reliable transport would prevent ubiquitous adoption of PSAMP. The collector applications must know if samples have been lost, but should not rely on every sample being reported.
Congestion Awareness: RFC 2914 specifies requirements for Internet protocols in order to prevent congestion collapse. The alternatives for PSAMP are to run over a congestion-aware transport or to control the sample report generator explicitly from a collector application, which would detect congestion (e.g. missing sample report packets) and send control messages to the appropriate sample report generator to reduce the sample rate and/or the export rate to that collector. Issues were raised in the meeting regarding the actual mechanism for this approach, the frequency and latency of the control messages, the protocol used, etc. These issues will have to be resolved by the WG over time.
Loss of Connectivity: This can be handled by a heartbeat protocol operation, in which the sample export packets to a particular collector will be terminated if heartbeat packets from that report collector stop reaching the sample generator for a specific time period. The details are still TBD.
Derek Chiou presented slides on hardware implementation of packet sampling technology. The purpose was to demonstrate that current hardware technology can support operations, including packet selection, currently under discussion in the WG, at a very high packet rate. An issue was raised that the PSAMP WG should specify functional requirements and not specify a particular implementation strategy. It was emphasized that these slides were intended to identify the general capabilities of current hardware technologies, not imply that a PSAMP implementation needed to be done using this approach. Refer to the slides for details on this issue.
Matt Grossglauser presented slides on some potential applications of packet sampling technology. These include performance monitoring and troubleshooting. The sampling mechanisms need to be simple enough to be widely implemented. The load on network devices (not just additional traffic on the network) needs to be considered. Packet filtering techniques are important, to allow an application to focus in on a particular problem (e.g. set of protocols or group of host addresses). Hash-based sampling enables measurement of packet paths through the network, which is useful for both engineering and diagnostic purposes. Refer to the slides for more details on this topics.
The potential relationship between PSAMP and RMON was brought up. The RMONMIB WG may choose to define a mechanism in the future to use PSAMP exported data as a data source for some RMON collection functions. No impact on the PSAMP WG is needed for this feature.
The interaction between the PSAMP and IPFIX WGs was discussed. There is potential overlap in several areas, and it is hoped to avoid duplication of effort. In his presentation, Nick Duffield differentiated three areas of potential interaction:
Packet Selection: a PSAMP device providing sampled packet input to IPFIX metering process; this motivates use of PSAMP sampling configuration and methods in the IPFIX information model. This has also been discussed in the IPFIX WG.
Report Formation: There is potential for PSAMP to reuse the IPFIX information model for reporting. The PSAMP WG needs to determine its requirements for reporting, and the extent to which they could be supported within IPFIX. Members of both WGs would need to work together if a compatible reporting framework were to be adopted.
Report Export: PSAMP's specific requirements for export, and the need for congestion awareness, can be supported by in the framework described by Matt Grossglauser. There may be different transport requirements for the two technologies, which need to be examined and resolved. The IPFIX WG has yet to select a congestion aware unreliable transport; when this choice is made it can be evaluated for PSAMP.
There appears to be a sufficient number of people interested in both the IPFIX and PSAMP WGs to insure that these issues will be addressed during the development of PSAMP documents.
Additional concerns about security, support for IPv6, and additional applications such as packet traceback were raised during the Q&A session. These issues (and others) will be addressed on the WG mailing list, during development of the WG documents.
Slides
Agenda
PSAMP: Transport & Multiple Banks
Some Hardware Implications of PSAMP
PSAMP and IPPT
Benefits of PSAMP for Network Operations