A29143A40AEAE3459FF829D1DD4331613C2434@KC-MAIL2.kc.umkc.edu">Packet filtering can be applied anywhere where packets can be observed. It should be done at a place where it is both convenient and from where all packets you are interested in are observable. Ideally, devices from which an aggregate report is generated should sample at the same place. For example, if one router samples on egress and the next router samples on ingress, you get very little additional information from the second sampler.Hi Dereck & all,Your explanation cleared my doubts.But,I am struck with another set of frivolous doubts...1.where exactly the packet filtering have to be applied ? Physical interface or the router loop back interface
A29143A40AEAE3459FF829D1DD4331613C2434@KC-MAIL2.kc.umkc.edu">PSAMP is generally useful for detection and observation of packet phenomenon. Policing functionality, however, requires not only (i) watching packets, but (ii) processing those packets in some way and (iii) actively changing traffic based on the results. Though PSAMP could potentially provide some or all of step (i), we are purposely avoiding steps (ii) and (iii).2.Another application oriented question..Can psamp be helpful in policing the traffic when it travels from the edge to core
A29143A40AEAE3459FF829D1DD4331613C2434@KC-MAIL2.kc.umkc.edu">As far as I know, this is not yet determined.3.Their may be times when the export rate may approach the router's packet forwarding rate.The framework draft saysthat a (configurable) limit of the no of measurment records per unit time will be imposed.So,what exactly be the processif it goes above the limit..just drop or some sort of recovering the sampled packets.
A29143A40AEAE3459FF829D1DD4331613C2434@KC-MAIL2.kc.umkc.edu">Or the collector may have to reside closer to the selector/exporter.4.The performance in packet forwarding could outwit the performance of measurement eqipments with advances inoptical switching,.what might be the solution at such times ?Is it like the packet sampling have to be done more closerto the collector.
A29143A40AEAE3459FF829D1DD4331613C2434@KC-MAIL2.kc.umkc.edu">Thanks in advance-Senthil-----Original Message-----Hi Senthil,
From: Derek Chiou [ mailto:dchiou@avici.com ]
Sent: Friday, April 12, 2002 5:31 PM
To: Ayyasamy, Senthilkumar (UMKC-Student)
Cc: Albert Greenberg; Nicholas_G_Duffield; psamp@ops.ietf.org ; 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.
Derek
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:dchiou@avici.com ]
Sent: Thursday, April 11, 2002 9:59 PM
To: Albert Greenberg
Cc: Nicholas_G_Duffield; psamp@ops.ietf.org ; 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.
Derek
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: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) , co mposed o
f 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 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 B EST
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
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 R eport Streams. Determine requiremen
ts
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. PSAM P is mo re 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 issuesarising 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/>