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

Re: next step

Hi Albert,

I think that Sonia was saying that she would like to see an entire header, rather than selected fields; if so, I agree with Sonia.  Passing raw information rather than selected or aggregated information, gives the collector all available information and thus provides some level of future protection (who knows when another currently unassigned or obsolete field suddenly has new semantics?)  Perhaps what is exported is the first n bytes of the packet, where n is configurable to some degree.

There are some obvious privacy issues, but those may not be important and we can probably save until later.

From an equipment complexity issue, the less processing within the exporter, the better.  Even selecting certain fields rather than passing the whole header adds some effort, though correspondingly, the extra bandwidth can be a problem as well.  

Modulo bandwidth issues, I think exporting the whole header or even selected header fields is reasonable to do; routers can do port mirroring after all.  

One area of  significant potential complexity in the selectors.  We have to make sure the selectors are as simple as possible while giving the most flexibility.  I think a common set of selectors across a wide range of equipment would be a huge boon for customers, but we have to ensure they are simple enough for everyone to easily implement.

Derek



Albert Greenberg wrote:
E02461E58097D511A56700805F65B5986D1F5A@exchangesrv2.research.att.com"> 
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 fi
lters 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/>