-----Original Message-----Hi Senthil,
From: Derek Chiou [mailto:firstname.lastname@example.org]
Sent: Friday, April 12, 2002 5:31 PM
To: Ayyasamy, Senthilkumar (UMKC-Student)
Cc: Albert Greenberg; Nicholas_G_Duffield; email@example.com; Bert Wijnen; Randy Bush
Subject: Re: next step
The selector/exporter/collector together implement the task of selecting some packets based on some criteria and summarizing those packets in some fashion into a format that a human can use.
I think "complexity" is perhaps the wrong word to describe the functionality of the selector, extractor and collector. Instead, we want the appropriate entity do each task. Clearly, a workstation sitting outside of the router cannot do packet selection, since it can't even see the packets. In a similar way, the router probably does not have enough state/horsepower to do an arbitrary summarization of packets.
Thus, there is a logical separation of tasks between the selector and the collector. The remaining partitioning issue is what the exporter does, as the boundary between the exporter and collector is still vague. Since it clearly lives on the router and exports to the collector, one would expect that less processing is better. Should the exporter be simply a mechanism to package up the packet report into an IP packet and send it on its way? In most if not all instances, the exporter will be running on a processor since the communication between the two will probably be TCP or at least something like TCP. Thus, there is potential for the exporter to run some of the summarization code.
I think, however, the intention of PSAMP is to provide a set of mechanisms that virtually all networking equipment can easily support. The equipment at the two ends, both the very low-end equipment and the ultra high-end equipment, tend to be pushing their limits with regards to implementation. They often don't have sufficient resources to do a lot extra work. Thus, a very simple selector/exporter is important to keep the bar low enough that we get universal adoption of the standard.
Obviously, if the selector/exporter are doing very little work, the collector must do more work. Having the selector/exporter perform collector work is very seductive, as it reduces the bandwidth to the collector and thus reduces its requirements. The requirement for a congestion-aware protcol between the exporter and collector already almost dictates a processor implementing the exporter. Requiring that processor to be powerful enough to run a substantial amount of collector functionality is probably not a good idea.
It would be nice to make be able to layer collector functionality such that, if the exporter is powerful enough, it can do some convenient collector work, but there should always be a way to export raw packet reports to the collector.
That's my opinion at least.
Senthil, I'm not sure if I've answered your questions, let me know if I haven't.
Ayyasamy, Senthilkumar (UMKC-Student) wrote:
A29143A40AEAE3459FF829D1DD4331613C2431@KC-MAIL2.kc.umkc.edu type="cite">Hi Dereck,I presume from your message that complexity should be less at the exporter & selector when compared with the collector .It would be more helpful if you point out the complexities associated with exporter,selector& collector from a management &technical point of view .Is flxibility with regard to implementation is the only criteria for analysing complexity .-senthil-----Original Message-----Hi Albert,
From: Derek Chiou [ mailto:firstname.lastname@example.org ]
Sent: Thursday, April 11, 2002 9:59 PM
To: Albert Greenberg
Cc: Nicholas_G_Duffield; email@example.com ; Bert Wijnen; Randy Bush
Subject: Re: next step
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.
Albert Greenberg wrote:
E02461E58097D511A56700805F65B5986D1F5A@exchangesrv2.research.att.com type="cite">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:firstname.lastname@example.org]
Sent: Thursday, April 11, 2002 2:26 PM
To: Nick Duffield
Cc: email@example.com; 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
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 o f fi
select classes of packets then sample at some rate from
each class of
packets, selects a set of packets to be sampled. Each
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
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 modi f ications
(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 NE XT 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
(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 requiremen ts and consequences
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
Thus, it seems that there is a significant distinction
between IPFIX and
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 issuesarising out of the talks and discussions at the BOF. As a starting
point, I'll take the draft charter from the BOF agenda
and flesh out the thinner parts over the next few days.
Please send any comments on this draft charter to the list.
to unsubscribe send a message to firstname.lastname@example.org with the
word 'unsubscribe' in a single line as the message text body.
to unsubscribe send a message to email@example.com
with the word 'unsubscribe' in a single line as the message text body.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.