Nick,
13.
* Timeliness: reports on selected packets MUST be made available
to the collector quickly enough to support near real time
applications. Specifically, any report on a packet MUST be
dispatched within 1 second of the time of receipt of the packet
by the measurement process.
Where does the 1 second requirement come from?
Should just say: with a configurable time ...
Proposed new material for later Section (much lifted from WG discussion)
Low measurement latency allows the traffic monitoring system to be
more responsive to real-time network events, quickly identifying
sources of congestion. Timeliness is generally a good thing for the
switches/routers performing the sampling since it minimizes the
amount of memory needed to buffer samples.
Keeping the packet dispatching delay to under 1 second has other
benefits besides limiting buffer requirements. For many
applications a 1 second time resolution is sufficient. Applications
in this category would include: identifying sources associated with
congestion; tracing denial of service attacks through the network
and constructing traffic matrices.
The 1 second rule in these situations eliminates the need for
timestamping by clocks synchronized clocks in measurement devices,
or for the measurement devices and collector to maintain
bi-directional communication in order to track clock offsets. The
collector can simply process packet reports in the order that they
are received---using its own clock as a "global" time
base---avoiding the complexity of buffering and reordering samples.
See [DuGeGr02] for an example.
I would put 1 second as a guideline, and not as a fix value:
- "1 second has other benefits besides limiting buffer requirements"
-> it depends on the bandwidth
- I would clearly write: configurable timeout. As a side consequence,
that would be in line with IPFIX
"The 1 second rule in these situations eliminates the need for
timestamping by clocks synchronized clocks in
measurement devices"
29.
4.6 Criteria for Choice of Selection Operations
In current practice, sampling has been performed using particular
algorithms, including:
- pseudorandom independent sampling with probability 1/N;
- systematic sampling of every Nth packet.
The question arises as to whether both of these should be
standardized as distinct selection operations, or whether they can
be regarded as different implementations of a single selection
operation.
To determine the answer to this question, we need to consider
...
I would not sure about the goal of this chapter?
Is the goal to say that we could have the same results (the same accuracy)
by having different selection operation?
If yes, how is it important from a PSAMP device point of view?
Don't we deal here with the interpration of the data, that should be done
on the collector?
Please shed some light!
This section raises the issue that we need some rational way to decide which selection operations are needed, and what variations should just be regarded as implementation details.
32.
When an entity that hosts a reporting process and, in its usual
capacity other than performing PSAMP functions, identifies or
process one or more of the above fields, then the contents of each
such field(s) SHOULD be made available for optional reporting. For
example, when a device routes based on destination IP address, that
field should be made available. Conversely, an entity that does
not route is not expected to be able to locate an IP address within
a packet, or make it available for reporting, although it MAY do
so.
This is a very broad statement, which means: any header field from any
protocol known to a router.
Sure you want to say that?
This goes well beyond to the few limited fields that the IPFIX information
model contains!
We should be prepared to go beyond the ipfix information model, since ipfix if ip flow centric; there other traffic out there (e.g. AToM). If we need to limit to some protocols of interest, that would be fine, but we need the list to be extensible as new protocols come along
I fully agree with the extensibility.
But I have a problem with the statement above which is under the
section " 5.2 Recommended Contents for Packet Reports (SHOULD)"
There is a big difference between "SHOULD be extensible to export field
of the following protocols" and:
(iii) fields relating to the following protocols
used in the packet, specifically: IPv4, IPV6, transport
protocols, MPLS, ATOM.
...
... then the contents of each
such field(s) SHOULD be made available for optional reporting
Because, explain like this: to be PSAMP compliant, an implementation SHOULD report any field of the listed protocols.
BTW, IPFIX has got an extensibility requirement! So this is somehow already covered. But now I agree that repeating it in this draft is usefull!
Note: a MAY instead of a SHOULD seem more appropriate, and that would solve all the issue
33.
5.3 Report Interpretation
Information for use in report interpretation MUST include (i)
configuration parameters of the selectors of the packets reported
on; (ii) format of the packet reports (iii) configuration
parameters and state information of the network element; (iv)
indication of the inherent accuracy of the reported quantities,
e.g., of timestamps; (v) identifiers for observation point,
measurement process, and export process.
state information of the network element ->
state information of the network element (if relevant to the selection
process)
Because not all state information are interesting.
Not sure what you mean by "relevant". You might want to report state (e.g. routing state) even though it is not used for selection.
My point is that I read: Information for use in report interpretation
MUST include ... state information of the network element.
And most of the time, this info (e.g. routing state) is not needed.
Actually this remark is valid for most of the points (i) (ii) (iii)
(iv) (v) in the sentences. There are some cases where we don't need ALL
of them.
Example: I don't report the input interface, why should I send the
observation point?
Example: why report the configuration parameters of the network element
(for example, something like the equivalent of OPERATING_TIME in the
MIB) if I don't need it.
etc...
I would propose.
MUST (i) configuration parameters of the selectors of the packets
reported on; (ii) format of the packet reports
SHOULD (iii) configuration parameters and state information of the
network element; (iv) indication of the inherent accuracy of the
reported quantities, e.g., of timestamps; (v) identifiers for
observation point, measurement process, and export process.
Now, whether you need the SHOULD or not depends on the final
application using the data reports
And why do we need the identifiers for the measurement and export
processes if we have the selector info?
Here's a case where its useful to have process ids: you want to reconfig selectors because information is getting lost (from congestion in observation point, or at transmission).
I agree this could make usefull!
Regards, Benoit.
|