From: Derek Chiou [mailto:firstname.lastname@example.org]
Sent: Thursday, April 11, 2002 2:26 PM
To: Nick Duffield
Cc: email@example.com; Bert Wijnen; Randy Bush
Subject: Re: next step
Sorry for the late reply, this past week has been very busy.
Overall, I like the draft charter. I'm an IETF novice, but
after looking at a few other charters of extant working
groups, it seems like this one is reasonable in it's scope
and level of detail. This is the charter, after all, and not
I agree with Cristian that the semantics of some terms is a
bit vague. Let me try to summarize what we mean by packet
sampling and how it works to see if my understanding is correct.
A selector (of which there may be several), composed o
select classes of packets then sample at some rate from
each class of
packets, selects a set of packets to be sampled. Each
generates one instance of a _report structure_ or _packet report_.
That report structure contains fields copied from the packet
header/packet as well as some computed information. A contiguous
stream of report structures from a single selector forms a _report
stream_ that also contains a description of the report
selector configuration as well as additional information about the
stream. The report stream is sent over some
protocol/transport to the
collector. Several report streams may be in progress simultaneously
due to several selectors being active, potentially requiring support
from the protocol layer. Packet sampling is configured via a MIB.
Assuming my understanding is correct, let me propose these
(in caps) to the current draft charter
that emphasis the terms used and make their use consistant.
1. Selectors for packet sampling. Specify a set of primitive packet
sampling operations for network elements, and the ways in which
they can be combined. This set shall be sufficiently rich so as to
support some existing and emerging packet sampling schemes, and
some packet measurement requirements of some other IETF WG's.
2. Report Structure. Define a SAMPLED PACKET report (GENERALLY ONE
REPORT PER SAMPLED PACKET) that is sufficiently rich to include
fields from the packet, quantities computable from
packet content and router state, quantities computed during the
selection operation, and functions thereof, as needed to support
applications. NICK, DID YOU INTEND THESE ADDITIONAL STATE VARIABLES
TO BE PART OF THE PACKET REPORT? IF NOT, PERHAPS IT WOULD BE BEST
TO ELIMINATE THIS
Additional state variables are to
be supplied in a timely manner
3. Report Streams. Define a format for formation of a stream of packet
reports. The format should include: (i) description of THE PACKET
(ii) the packet reports THEMSELVES; (iii) sampling
parameters used to generate constituent reports (iv) sufficient
ADDITIONAL information, e.g. counters, to enable inference of
actual sampling rates, detection of and correction for
absent reports due to transmission loss, and detection of report
omission during operation of multiple packet selectors.
4. Presentation, Export, and Transport. Determine appropriate layer
for presentation of measurements to on-board applications. Select
transport for secure and timely export. Examine requirements for
dynamic configurability of export destination.
5. Multiple Report Streams. Determine requiremen
enabling multiple report streams, each with its own configurable
packet selector, report format, report stream format, and export.
6. Configuration Management. Specify a MIB for sampling parameters,
PACKET report FORMAT, report stream format AND export
parameters. Select communication protocol to
configure/read this MIB.
I think the issue of overlap with IPFIX still needs to be
resolved. From an initial reading, it seems that IPFIX's
charter is very close to the PSAMP draft charter. However,
IPFIX documents focus more on the protocols between the
various entities and less on the filtering/sampling
mechanisms. It seems that IPFIX is concentrating on defining
the protocol/transport we wish to select in point 4 of our
draft charter and
potentially some of the report stream self-description
ability discussed in 3. PSAMP is more focused on defining a
of packet sampling
Thus, it seems that there is a significant distinction
between IPFIX and
Nick Duffield wrote:
as I understand from our area directors, the next step is for us to
agree upon a charter. This will be taken to the IESG, and that body
will decide whether to charter PSAMP as an IETF Working Group.
This will involve reaching a consensus on the aims, scope,
arising out of the talks and discussions at the BOF. As a starting
point, I'll take the draft charter from the BOF agenda
and flesh out the thinner parts over the next few days.
Please send any comments on this draft charter to the list.
to unsubscribe send a message to firstname.lastname@example.org with the
word 'unsubscribe' in a single line as the message text body.
to unsubscribe send a message to email@example.com
with the word 'unsubscribe' in a single line as the message text body.