[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft minutes of Minneapolis session
Thanks for posting these. Pls realize that the dealine for
submitting final minutes for inclusion ion the proceedings
is Dec 19th!
Thanks,
Bert
> -----Original Message-----
> From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
> Sent: maandag 8 december 2003 9:32
> To: psamp@ops.ietf.org
> Subject: draft minutes of Minneapolis session
>
>
> Dear all,
>
> Below please find a draft of the minutes of the Minneapolis session.
> Thanks to Dave Plonka for taking them.
>
> Please check them an send comments if you disagree or if you miss
> something.
>
> Thanks,
>
> Juergen
>
>
> =======================================
> Minutes of the PSAMP session at IETF 58
> Tuesday November 11, 9:00 h - 11:30 h
> =======================================
>
> Minutes taken by Dave Plonka and Juergen Quittek
>
>
> ===============
> Session summary
> ===============
> The WG documents on the PSAMP framework and on packet selection
> are now consistent with respect to each other and both are
> quite mature. For both documents the editors will send the
> list of remaining open issue to the mailing list soon. After
> the next update (planned for mid of December) both documents
> can enter WG last call together. The protocol and information
> model documents are available as first versions. They describe
> how the (upcoming) IPFIX protocol is used for exporting packet
> samples. They depend on the corresponding IPFIX documents that
> are expected to be completed by May 2004. The PSAMP MIB
> definition progressed slowly, because it depends on the packet
> selection document. The WG discussed how to integrate an
> individual I-D describing hash functions for packet selection
> in detail. the WG hesitated to have this as an additional WG
> document. It rather should be integrated into the packet
> selection document.
>
>
> =============================
> Presentations and discussions
> =============================
>
> Andy Bierman on the WG Status
> =============================
> Andy reported on the status of the WG documents.
> The sampling framework document and the packet selection
> document are quite mature and should enter WG last call soon.
> The report format and report stream format document
> (PSAMP protocol) is waiting for progress of the IPFIX protocol.
> The export protocol and requirements for collectors document
> (PSAMP information model) is waiting for progress of the IPFIX
> info model.
>
>
> Nick Duffield on the PSAMP framework
> ====================================
> Nick discussed open issues on the framework document.
> The term 'sampling' was misunderstood by several reader.
> Therefore it was replaced by 'packet selection'.
> The framework description was extended to better cover
> encrypted packets. The description of exporting packet
> reports now discusses compliancy to and coexistence with IPFIX.
>
> The term 'emulated selection' will be replaced by
> 'approximative selection'. The term 'measurement packets'
> will be replaced by 'export packet'.
>
> An issue of discussion is the reporting of the sequence counter.
> Suggestion is to report it regularly, but not with every
> packet report. The issue will be put on the mailing list.
> Support of encryption of packet reports will be changed to
> be REQUIRED.
>
> Reporting sequence numbers is considered to enable
> re-normalization of measured bytes.
>
> He discussed export requirements including confidentiality
> and timeliness. Is there a need to request that a delay
> SHOULD not exceed 1 second?
> Q: [Andy] why not make it configurable?
> Q: [Nick] why would an implementation not want to export ASAP?
> A: [Andy] there may be resource issues
> A: [Maurizio Molina] implementer may wish to group packets for
> export
>
> There is the general feeling that the export protocol for
> PSAMP is waiting on IPFIX.
> A: [Andy] coupling with IPFIX is not just to reuse documents,
> but also implementation code
> A: [?] reminder that SCTP is already RFC defined, PR-SCTP is
> in IEST queue packet selection
>
>
> Tanja Zseby on packet selection
> ===============================
> Tanja presented progress on the packet selection document.
> Terminology is now almost consistent with the framework
> document. After recent discussions only small changes are
> required here. Packet selectors could be part of IPFIX or
> other metering process. A still open issues is the set of
> methods for flow state sampling. Further open issues of the
> document include: Should we include some examples for flow
> state sampling or just leave it open to vendor-specified
> parameters based on the info model? Is there a better term
> for hash-based sampling than "emulation" or "approximation"?
> A: [Juergen] re: the flow state sampling, since the known
> current methods are experimental, perhaps we should just
> say they are vendor-specified (ie. w/o examples)
> A: [Maurizio] perhaps it would help to have one
> example (such as sample and hold)
>
>
> Benoit Claise on the PSAMP protocol
> ===================================
> Benoit discussed the initial version of the PSAMP protocol
> document describing how the IPFIX protocol is used for
> exporting packet records. The IPFIX documents only speak
> about 'flow records'. These will be used as 'packet records'
> in PSAMP. The information model of IPFIX and PSAMP overlap.
> The PSAMP information model can be defined as extension of
> the IPFIX information model.
> A: [Plonka] timeliness of export needs to be mentioned in
> PSAMP protocol and the other drafts (such as requirements)
> need to take into consideration that if you choose an
> existing transport like IPFIX, that it might impose limits
> on the timeliness
> A: [Andy] doubts that its reasonable to demand some explicit
> export time, especially as little as one second, perhaps
> it should just be user configurable [presumably within
> the implementation limits]
> A: [Benoit] IPFIX does have a timeout, to get timely reporting
> A: [Dave Plonka] in IPFIX, there is currently no explicit bound
> on the time from flow timeout until export
> A: [Nick] motivation for 1 second "time limit", we want to
> specify a maximum, so that its not uncontrolled
> A: [Benoit] you can piggyback this on IPFIX
>
>
> Benoit Claise on the PSAMP information model
> ============================================
> Benoit presented the initial draft of the PSAMP information
> model. It is defined as extension of the IPFIX information
> model and adds a data type of a variable length byte array
> and it adds several information elements. It needs to be
> synchronized with the packet selection document.
> Q: [Nick] Do you have fields defined for all the sampling
> types, such as hash-based?
> A: [Benoit/Juergen] not yet, yes - that needs to be added.
> This document is still in a premature state.
>
>
> Juergen Quittek [on behalf of Thomas] on the PSAMP MIB
> ======================================================
> Very small changes were committed to the PSAMP MIB since
> the document depends on the packet selection document that
> was submitted just before the cut-off date leaving no time
> to reflect it in the PSAMP MIB. Committed changes concerned
> the support of multiple receivers of packet samples. We need
> to determine which portions are mandatory and which optional.
> A: [Andy/Juergen] regarding the existing drafts, suggest
> perhaps 4 weeks time to deal with existing open issues,
> and take them to last call
> A: [Juergen] document editors should take the open issues to
> mailing list, try to get them addressed in 4 weeks, to
> enter last call in december, perhaps to wrap-up in January.
>
>
> Maurizio Molina about hash functions
> ====================================
> So far, the WG documents to not precisely describe hash
> functions. The presented individual I-D suggests to do so
> and defines some hash functions that have already been tested.
> A: [Andy] re: specification of hash function, I'm relunctant
> to add more RFCs to the initial PSAMP effort. If this
> document were an informational RFC (resulting from an
> individual draft) that would be sufficient.
> A: [Nevil Brownlee] re: hash functions - they're hard to get
> right, it would be better for PSAMP to settle on a short
> list (of no more than 3), and concurs with Andy's suggestion
> for new hash algorithms to be individual drafts specified
> outside PSAMP.
> A: [Nick] there is a benefit from PSAMP implementations
> using the same hash functions, for consistency there is
> a trade-off between strength and complexity when trying
> to identify the "best" hash functions for PSAMP.
> A: [Andy] if hash functions need to be in their own draft
> so that they can be easily edited, that probably means
> that they're not mature enought to be part of PSAMP yet.
> He suggest taking the discussion to the mailing list.
> A: [Andy] PSAMP could publish detailed functional requirements
> of a candidate hash function, rather than specifying a
> specific one with pseudo-code.
> A: [Nick] trying to avoid different vendors using different
> hash functions - because that's not that useful.
> A: [Andy] OK, well then there needs to be some agreement
> [on standard hash functions]
>
> Emile Stephan about spacial metrics for IPPM
> ============================================
> Emile suggests that one use of psamp is to determine the delay
> and loss of individual packets [and thus would perhaps benefit
> from IPPM defined spatial metrics for same].
> Q: [Henk Uijterwaal] why can't you apply the existing IPPM
> metrics (to points H1 to H2 in slide #3)?
> A: [Emile] [something about it not being end-to-end]
> Q: [Andy] Nick, do we have any requirement on time
> syncronization?
> A: [Nick] there is no such PSAMP requirement specified, but
> we do say that when timestamps are supplied that the
> accuracy is indicated.
> Q: [Andy] [to Emile] are you suggestion some change to PSAMP
> [to accomodate this potential application of PSAMP data]?
> Q: [Nick] Does IPFIX address timestamp issues?
> A: [Nevil] Yes, microsecond resolution is possible in export
> data type, but the accuracy and resolution are not have to
> be specified.
> A: [Tanja] QoS monitoring is one of IPFIX' target applications,
> and that would somewhat depend on timestamps.
>
>
> ==================
> Session conclusion
> ==================
>
> Andy asked authors to post their open issues to the mailing list.
> Q: [Randy Bush] how are we doing on progress?
> A: [Andy] plan for Jan. 10 for two main drafts to go to last call.
>
>
>
>
> --
> 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/>