[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
DRAFT PSAMP BOF minutes, IETF 53
PSAMP folks,
please review the DRAFT minutes of the BOF at IETF 53, below.
Please send any comments/suggestions/corrections to the list.
Thanks,
Nick
--
DRAFT 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: [to be finalized: roughly 100]
Agenda:
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:
. PSAMP and RMON
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.
. PSAMP and IPFIX
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.
--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>