[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
final PSAMP minutes
Dear all,
Below please find the final version of the minutes of the PSAMP session
in San Francisco.
Thanks to all who send comments and corrections.
Cheers,
Juergen
--
Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15
NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de
==========================================================================
PSAMP meeting on March 21, 2003
reported by Juergen Quittek
The meeting had about 45 attendees.
=====================================
Any Bierman on WG and document status
=====================================
Andy gave an overview of the session: three documents are to be
discussed covering framework, packet selection and harmonization
with the IPFIX WG. For the first two documents he hopes they can
be delivered in May as planned. Between these two documents,
minor issues need to be clarified including terminology.
Working group last call is planned for end of April.
The PSAMP MIB document was not on the agenda. Work on it will
start in April. Volunteers for writing the PSAMP MIB are still
welcome. Please contact the chairs.
Conformance issues for PSAMP systems are to be discussed today.
Minimum requirements include a single observation point, a single
standard sampling algorithm and export using PSAMP format and
protocol.
====================================
Nich Duffield on the PSAMP framework
====================================
Nick reported on the changes in the PSAMP framework document
<draft-ietf-psamp-framework-02.txt> since the last meeting.
The selection operation was just a binary decision, now it is
the selected packet. This simplifies expressing ordered composite
selection operations.
Now, each selector keeps the number of input packets and reports
it as sequence number.
Basic packet selection can be count-based or timer-based. Past
studies showed that count-based selection is more accurate.
Still both will be supported by PSAMP. Further supported selection
methods include random sampling, 1 in N sampling and hash based
sampling. There are more candidates, but it is an open question,
how much of them can be specified.
Filtering is the selection based on packet fields and packet
treatment. Filtering will not be a mandatory feature of PSAMP
devices. Routers already do filtering with ACLs, but filtering
for PSAMP can be easier than filtering with ACLs.
Composite selection operations are nice to have, but it is not yet
clear if we need complex composition capabilities. The current
proposal is to just offer either (1) first sampling, then
filtering or (2) first filtering, then sampling.
Having at least two parallel measurement processes is nice, because one
can drill down on detail with a second measurement process, while not
disturbing baseline measurements by the first.
It was under discussion whether there shall be a set of mandatory
packet selection methods or whether just a single arbitrary one
MUST be supported by a PSAMP device. But according to the
discussion during Andy's presentation the group agreed on a
single arbitrary one. This position needs to be agreed on the
mailing list.
Reporting MUST support the following reports:
- first N bytes of packet
- sequence numbers
- device interface serving as observation point
- attributes calculated during sampling: hash, timestamp, ...
There were no changes in the export process, but there are some
expected depending on our evaluation of DCCP and PR-SCTP, and on
the IPFIX protocol choice.
Question by unknown person: How will the observation point be
specified? By logical or physical interface ID?
Juergen, Andy: the physical seems to be always required, the
logical one can be optional. Anyway, the observation point need
to be clearly identified.
===============================
Tanja Szeby on Packet Selection
===============================
Tanja reported on progress with the document on packet selection
<draft-ietf-psamp-sample-tech-01.txt>.
In conformance with Andy and Tanja stated that there are no
MANDATORY sampling schemes but if one is supported, than this
scheme need to be precisely defined by the standard and the
implementation MUST comply to this.
Nick: we need to distinguish between content-based sampling
(in which the packet content parametrizes a selection probability)
and methods such as hash-based sampling, in which the content is used
to calculate a pseudorandom variate which is then compared with a
selection probability to determine whether the packet is selected.
Is content-based sampling other than hash-based required at all?
Andy: Does anyone have a strong feeling on whether to have no particular
scheme mandatory, but just the support of at least one of them? Please
send comments to the list.
==================================
Benoit Claise on relation to IPFIX
==================================
Benoit explained the similarities and differences in
architecture and terminology of IPFIX and PSAMP. Terminology
should be consistent between the two groups.
Also mutual re-use of technologies is possible. The IPFIX WG
has chosen NetFlow version 9 as starting point for protocol
development. NetFlow v9 is template-based.
Andy: at least one reporting template per observation point need
to be available in order to differentiate observation point.
Juergen: There should be one report configuration per
observation point.
Peter Phaal: There might be a problem with using templates
for PSAMP.
Benoit: There should be no problem with templates.
Andy: There is a problem with template-based reporting, because
variable length fields are not yet supported.
Benoit: This was also discussed in IPFIX the day before and it
is identified as a shortcoming to be fixed.
Fulvio Risso: It looks like the group focuses on routers
and switches. Are workstations also in the scope?
Andy: Yes.
Fulvio Risso: Why would the readable MIB be a MUST
After a short discussion, read-only support of the
PSAMP MIB was not considered as mandatory. For small sampling
devices, supporting the MIB could be a too strong requirement.
Nick pointed out some terms that need alignment between
PSAMP and IPFIX: field <-> attribute,
PSAMP device interface <-> observation point
Nick: We should use SNMP for configuration
Andy: How does the WG feel about using the IPFIX protocol for exporting?
Dinesh Dutt: we have a measurement application that does remote
capture which is already running and that uses TCP-based communication.
The application is the WinPcap 3.0 packet capture library
(http://winpcap.polito.it), which has been released recently.
The WG has agreed to use the IPFIX reporting protocol if is
suitable for PSAMP. Therefore, a detailed analysis on the IPFIX
protocol needs to be done and if its not suitable, then the reason
should be stated exactly. One issue was already stated: the lack
of support for variable field length. However, according to Benoit,
this problem will be fixed in the IPFIX wg.
It was agreed to continue this discussion on the mailing list.
--
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/>