[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Open issues on PSAMP framework


Thanks for compiling the list. Please find my comments inline

--On 24.06.2004 1:27 h -0400 duffield@research.att.com wrote:


Here is a list of the major open issues raised in the messages that you
referenced, plus proposals for their resolution. In some cases
alternative resolutions are proposed.

I encourage mailing list participant to send comments to the list so
that we can converge.

A number of smaller stylistic issues raised are not listed, but will be
taken into account in the revision.



FW-0: Document type. The AD and WG Chairs have agreed that the framework document will be informational. RESOLVED

FW-1: References to other PSAMP documents.
Proposal: Include a section describing the role of the other wg
documents. Use more informative labels for references:  [PSAMP-PROTO]
protocol document, [PSAMP-MIB] MIB document, [PSAMP-TECH] sampling
techniques, [PSAMP-INFO] information model document.

Question: can the other PSAMP drafts be included as normative references
while they are yet to be completed?

Yes, they can.

Giving an overview of the documents that are influenced by the
framework is a good idea.  But referencing them in any way will most
probably make the document stuck in the RFC editor queue until
all references also achieve RFC status. This might be a challenge
for the patience of the authors, but it is not bad in general.
Since the other documents will reference the framework in turn,
then all PSAMP documents would be published at once.

I would prefer referencing the other documents as RFCs with placeholders
for the so far unknown numbers.

FW-2: Terminology section.
Proposal: arrange items in alphabetic order. Use initial upper cases for

Fine with me. But I do not see strong reasons for one way or another. This should be decided by the editors.

FW-3: Requirements.
Proposal: emphasize high level generic requirements (current Section 3)
vs. detailed requirements (following sections). Because document is
informational, use lower cast must, should and may.

FW-4: Architecture.
Proposal: separate out a new architecture section. (The current section
2 attempts too much by describing architecture by means of the
terminology list). Arrange architecture diagram on a single page.
Include new diagrams of components of measurement process.

I support the proposal.

FW-5: Packet selection terminology (Sec 4.1).
The normative selection terminology reference for PSAMP will be
[PSAMP-TECH]. Some, but not all, terms from [PSAMP-TECH] are used in the
framework draft.

Alternative Proposals:
. FW-5a: Duplicate all terminology from [PSAMP-TECH]
. FW-5b: Duplicate only those terms used in the framework document
. FW-5c: Duplicate no terms and refer to [PSAMP-TECH] for definitions

I do not like alternative a. I am fine with b and c. b makes this document easier to read on its own. c avoids consistency checking. I have a weak preference for b.

FW-6: Packet Selection Operations (Sec 4.2)
The normative selection operation reference for PSAMP will be
[PSAMP-TECH]. Operations defined in [PSAMP-TECH] are also summarized in
the framework draft.
Proposal: retain current summary descriptions of selection operations.
Omit material from 4.2 on applications of hash based sampling; this now
occurs in [PSAMP-TECH].

Fine with me.

FW-7: Packet Report and Packet Interpretation.

While PSAMP will use IPFIX, the PSAMP terms (packet report and packet
interpretation) are not used in IPFIX. But the meaning appears
compatible with IPFIX (see Major Point 9 in
https://psg.com/lists/psamp/psamp.2004/msg00024.html )

Alternate Proposals:
FW-7a: retain psamp terminology, add section on correspondence with
FW-7b: omit psamp terminology and convert to IPFIX. This is probably
best long term. But would slow down convergence of the document since
(i) it would be a major change, and (ii) IPFIX is still in flux.

I have a clear preference for alternative a.

PSAMP uses the IPFIX protocol, but the IPFIX terminology is not useful
in some sections of the PSAMP documents.  I would rather like a clean
and consistent set of PSAMP documents than a terminology mix.

Maybe, we should request the IPFIX group to generalize their
terminology in a way that fits both groups?

FW-8: Transport Protocol.
Proposal: Section 7 to undergo major updates to reflect (i) choice of
IPFIX for PSAMP; (ii) apparent compatibility of IPFIX export protocol
choices (see
http://ipfix.doit.wisc.edu/archive/2377.html) with psamp requirements.
Section 7.7 on collector based rate reconfiguration will be omitted.

Question: is SCTP-PR a MUST in IPFIX?

Yes, it is.

FW-9: Proposal: Omit Section 4.6

FW-10: Packet reports. Proposal: definition in Section 2 to be modified
to include e.q. sequence numbers.

FW-11: Input sequence numbers.
Proposal: include input sequence numbers for each selector in a

FW-12: Selection State.
Proposal: selection state to be associated with a packet (e.g. for
reporting) is post-processing of the packet.

FW-13: Style.
Proposal: Streamline document to retain basic motivation while pruning
longer justifications (e.g. Section 10) .

FW-14: PSAMP device.
Proposal: define analogously to IPFIX.

Sounds like a good choice.



-----Original Message-----
From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
Sent: Thursday, May 13, 2004 3:54 AM
To: psamp@ops.ietf.org
Cc: dchiou@avici.com; bclaise@cisco.com; Duffield,Nicholas G (Nick);
Greenberg,Albert G (Albert); matthias.grossglauser@epfl.ch;
peram@cisco.com; Rexford,Jennifer L (Jennifer); gsadasiv@cisco.com
Subject: Open issues on PSAMP framework

Dear all,

I really would like to close WG last call on the PSAMP framework soon.

Still there is a non-trivial list of open issues that have not been
closed on the mailing list.  I am referring to issues raised in the
following messages:

    https://psg.com/lists/psamp/psamp.2004/msg00026.html  (and

Please have a look at these issues and help finishing the Document!

Nick, at least you as document editor (or one of your seven
should reply on the raised issues and suggest a solution for each one.


Juergen Quittek        quittek@ccrle.nec.de        Tel: +49 6221
NEC Europe Ltd., Network Laboratories Fax: +49 6221
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany

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