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