[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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/>