[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: next step

To: "Albert Greenberg" <albert@research.att.com>,"'Derek Chiou'" <dchiou@avici.com>,"Nicholas_G_Duffield" <duffield@research.att.com>
Subject: RE: next step
From: "Sonia Panchen" <sonia_panchen@inmon.com>
Date: Thu, 11 Apr 2002 16:28:29 -0700
Cc: <psamp@ops.ietf.org>,"Bert Wijnen" <bwijnen@lucent.com>,"Randy Bush" <randy@psg.com>
In-reply-to: <E02461E58097D511A56700805F65B5986D1F5A@exchangesrv2.research.att.com>
Albert,
Yes, you are correct. I was suggesting that the export of packet headers
looked like the simplest and most general approach.

Sonia

> -----Original Message-----
> From: owner-psamp@ops.ietf.org [mailto:owner-psamp@ops.ietf.org]On
> Behalf Of Albert Greenberg
> Sent: Thursday, April 11, 2002 12:10 PM
> To: 'Derek Chiou'; Nicholas_G_Duffield
> Cc: psamp@ops.ietf.org; Bert Wijnen; Randy Bush
> Subject: 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/>
>


--
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/>
References:
- RE: next step
  - From: Albert Greenberg <albert@research.att.com>
Prev by Date: Re: next step
Next by Date: RE: next step
Previous by thread: RE: next step
Next by thread: Re: next step
Index(es):
- Date
- Thread