[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Begin WG Last Call: draft-psamp-framework-05.txt
I finally managed to read the framework draft.
In general I agree to what Tom Petch said. For somebody not knowing psamp
it is probably hard to get the idea because of the presentation style and
missing pictures (especially section 2).
Some detailed comments:
1)
The second part seems to describe the relation of psamp to other groups
rather than the motivation.
2)
I am wondering if somebody not into psamp will get a clear picture from
this. The section looks like powerpoint slides were dumped into a document.
A picture would be nice explaining the relation of observation process,
packet stream, measurement process, selector process/state and reporting
process. Maybe also a picture for explaining the composition of selection
processes.
The whole cotent could be rearranged in one section terminology
(alphabetic order please) and one text section explaining the architecture
(i.e. intercation between components). The figure is split on two pages.
I don't understand the purpose of the numbers behind the Collectors. The
other components are not numbered.
3.1)
Parallel Measurement Processes: why is this listed unter "Selection
Process Requirements"? Especially as section 2 explains that the selection
process is part of the measurement process and not vice versa.
Encrypted packets: not clear what this means. Does it mean ignore fields
which are encrypted, when encryption is detected?
Typo: -> "Specific reporting processes ... , and _the_" (remove A)
4.1)
Why do we have another terminology section here which is duplicated
from the sample-tech draft? Can we order it alphabetically?
Content-dependent sampling: well for p=1 it would be a filter I guess :-)
Approximative Selection: "any of the above categories" Which above
categories? Hash range is obviously not one of them...
4.2)
Non-uniform probabilistic sampling: can the p also depend on packet
treatment?
Probabilistic n-out-of-N: typo "from each..."
What is ATOM?
hash-based selection can be used to approximate uniform sampling:
this does only depend on a good hash function but also on the hash
domain.
Typos:
"Since packet _encryption_ alters..."
"The hash domain is specified by a _bitmap_ ..."
"_Report_ packets also include a second hash..."
4.3)
"total bytes ... is estimated by B/R": depends on the selector.
Not necessarily true for non-uniform probabilistic sampling.
4.6)
pseurorandom independent, systematic sampling: either stick to the
terminology defined before or define those terms.
5.1)
(ii): what is considered to be payload? Above transport layer?
"These devices may exercise the option not to provide basic reports."
What does that mean? The content of 5.1 is not always a MUST?
5.2)
(v): is the timstamp always selection state even if it is not used
in the selection?
5.5)
"delay may be sensitive to processor load at the observation point."
The delay can also be sensitive to load at the collector (depending
on the collector).
7.5)
Is the first sentence different from the congestion avoidance
requirement in 3.3?
TCP does not exacerbate the network or collector overload problem.
Its designed to do the opposite. What you mean is that it may need
more bandwidth, may stall etc.
What exactly is the meaning of "dispatched export packets"?
I think the last sentence means to take the into account not only
the bandwidth of the interface but the available bandwidth on the
exporter collector path!?
7.7)
Does this belong into the framework draft? Seq number behaviour
and congestion control algorithm belong into the protocol draft IMO.
Assumes that the sequence number only captures the network loss.
This is not the case for the IPFIX header seq number (if I
understand Benoit correctly the idea of the IPFIX seq number is
to record loss in the network _and_ on the exporter).
7.7.2)
The bandwidth could also be controlled by mechanisms such as Diffserv.
In the second paragraph you are essentially saying that PSAMP
may be more aggressive than TCP which is somewhat contrary to
the congestion avoidance requirement.
10)
Major differences to IPFIX:
(ii): does this mean that IPFIX can not support new applications
(I don't hope so) or that IPFIX doesn't do this through packet
selectors?
Cheers,
Sebastian
Juergen Quittek wrote:
Benoit,
--On 24.02.2004 20:14 Uhr +0100 Benoit Claise wrote:
Juergen, Andy,
I wanted to review the framework draft before the deadline. I'm a
little bit late I know ;)
I am not willing to close WG last call without
indication that the document was thoroughly reviewed.
And except for the discussion on the targeted document
status there was no such indication, yet.
So yes, you miss the deadline set originally,
but the call is still open.
All others on the list:
If your time allows, PLEASE have a look at this document
and send us your comments!
Thanks,
Juergen
Then I'm facing the first issue discussed below: is the draft a
standard track document or not?
Because depending on the output, the review will be different!
Just an example: the terminology section. If a standard track
document, it must be the same as the PSAMP protocol draft (or almost),
which in turn will be the same as the IPFIX protocol draft (for which
we just agreed upon)
As I guess that we will be discussing this issue regarding standard
track versus informational document in Seoul, do I understand
correctly that the last-call deadline is postponed?
Regards, Benoit.
--On 02.02.2004 9:24 Uhr -0800 Andy Bierman wrote:
At 05:33 AM 2/2/2004, Romascanu, Dan (Dan) wrote:
Juergen,
I am wondering about the motivation of your decision to publish the
framework document as informational. The charter says nothing about
it. The document includes mandatory requirements (for example
section 5.1 - Mandatory Contents of Packet Reports).
What is the 'nature of the document' that leads you (as WG Chair) to
advice that this document falls under the definition of an
Informational document, as per Section 4.2.2 of RFC 2026?
I think we have an open issue here that the WG needs to discuss:
- should the framework contain normative text or not?
Agreed.
IMO, the answer is yes, but it depends on the details --
if one of the other existing drafts is a better place for
the text, then it should be moved there.
The mandatory contents of packet reports contents
is not an obvious call. The psamp-info draft is the only
possible candidate, but we should keep protocol conformance
details out of the info model. (Unlike MIBs, an info model
should not be coupled to a specific protocol.)
So the Framework is probably the best choice for this
particular normative detail.
So far, I understood that the framework document defines requirements
for the protocol, info model and MIB document. Concerning section 5,
the framework does not talk about bits and bytes and encodings, but
just about which information MUST be included in which case.
I think the protocol document will specify the required protocol
features in a more concrete way by naming the information elements
(defined in the info model) that MUST be used for providing the
required information. This should be (and usually is) done in a
way that the documents specifying the requirements do not need
to be part of the standard.
Juergen
Thanks and Regards,
Dan
Andy
-----Original Message-----
From: owner-psamp@ops.ietf.org
[mailto:owner-psamp@ops.ietf.org]On Behalf Of Juergen Quittek
Sent: 31 January, 2004 12:10 AM
To: psamp@ops.ietf.org
Subject: Re: Begin WG Last Call: draft-psamp-framework-05.txt
Dear all,
Inline please find a small correction of the WG last call.
--On 30.01.2004 19:39 Uhr +0100 Juergen Quittek wrote:
> Dear all,
>
> The PSAMP WG has completed work on
>
> A Framework for Packet Selection and Reporting.
>
> The WG proposes that the I-D 'draft-psamp-framework-05.txt'
> is the completed version of this document.
>
> The WG members are strongly urged to review this document as
> soon as possible, and express any concerns, or identify any errors,
> in an email to the PSAMP WG mailing list.
>
> Unless there are strong objections, published on the PSAMP
WG mailing
> list by Friday, February 20th, this document will be forwarded
> to the OPS Area Directors for standards track consideration by
> the IESG.
This is not correct. Considering the nature of the document
the target will be an informational RFC.
Juergen
> Please send all comments to the WG mailing list at
psamp@ops.ietf.org.
>
> Thanks,
>
> Juergen
> --
> Juergen Quittek quittek@netlab.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
--
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/>
--
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/>
--
Sebastian Zander E-mail: zander@fokus.fraunhofer.de
Fraunhofer FOKUS / METEOR Tel: +49-30-3463-7287
Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287
D-10589 Berlin, Germany www.fokus.fraunhofer.de/usr/sebastian.zander
--
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/>