[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: next step
Hi Derek,
I like the wording. If I understood Sonia's response,
we are talking about export of selected header fields vs export
of an initial header segment or hash of an initial header segment.
The latter looks simplest and general. Got your point right, Sonia?
It would be helpful if you and other
linecard designers provide some insights on complexity.
-- Albert
> -----Original Message-----
> From: Derek Chiou [mailto:dchiou@avici.com]
> Sent: Thursday, April 11, 2002 2:26 PM
> To: Nick Duffield
> Cc: psamp@ops.ietf.org; 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
> the specification.
>
> 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 of filters that
> select classes of packets then sample at some rate from
> each class of
> packets, selects a set of packets to be sampled. Each
> sampled packet
> 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
> structures, the
> 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
> small modifications (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 NEXT SENTENCE. 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
> REPORT formatS;
> (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 requirements and consequences of
> 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
> uniform set of packet sampling selector mechanisms.
>
> Thus, it seems that there is a significant distinction
> between IPFIX and
> PSAMP.
>
>
>
>
> Nick Duffield wrote:
>
> >Folks,
> >
> >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,
> and issues
> >arising out of the talks and discussions at the BOF. As a starting
> >point, I'll take the draft charter from the BOF agenda
> >
> >http://www.ietf.org/ietf/02mar/psamp.txt
> >
> >and flesh out the thinner parts over the next few days.
> >Please send any comments on this draft charter to the list.
> >
> >Thanks,
> >
> >Nick
> >
> >--
> >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/>
> >
>
>
>
>
> --
> 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/>
>
--
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/>