The other methods outlined in section 7.5 do not provide this detail. I think
it is incumbent on your draft to state that implementations, regardless of
approach, document where the metrics are calculated so that meaningful action
can be taken.
Exactly. This must be described in the RFC8911 IP performance metrics registry
See section 3.1.2 in our draft
OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Mean: This
metric assesses the mean of one-way delays of all successfully
forwarded IP packets constituting a single Flow. We consider the
measurement of one-way delay based on a single Observation Point
(OP) [RFC7011] somewhere in the network.
This implies that it depends on how you create your Flow Records in the IPFIX
Metering Process.
To take you 3 examples
1) the time at which the packet was received by the node,
=> this would be the case if the IPFIX Metering Process is enabled on the
input interface, in the ingress direction
2) the time at which the packet was transmitted by the node, or
=> this would be the case if the IPFIX Metering Process is enabled on the
output interface, in the egress direction
Note: in such as case, there is always the issue of having precise
timestamps or not
3) when a tunnel encapsulation is used, the point at which the packet is
encapsulated into the tunnel.
=> this would be the case if the IPFIX Metering Process is enabled on the
tunnel interface, in the egress direction
[JMC] My point was that “ingress” may mean different things in different
implementations. It may be the first thing that is recorded in the feature
path. It may be after copy from the input interface to a buffer, it may be
after packet filtering is performed, etc. The IOAM draft states that this must
be documented, and I am asking for your work to include similar text such that
all implementations, regardless of telemetry approach used, document where in
the feature path the measurement is taken.
We tried to make the performance metric generic, based on the IPFIX Observation
Point definition
Another question on Section 1. When you say, “The advantage of this solution
is that the delay metrics (min, max, and mean) can be computed on the router,
and aggregated directly within the Flow Record, saving export bandwidth and
computation on the Collector”, wouldn’t the collector typically have the
resources for such computation whereas the router may be more constrained?
Meaning, pushing this to the router might be the wrong approach, especially in
this day and age of huge central data processing facilities.
Let's keep in mind that we want to export the min, the max, and the mean delays.
This implies that we have to look at every single packet, deduce the delay, and
evaluate whether we face the min and the max... trivial.
Now, for the mean, we need to re-calculate it with every single new packet of
this flow.
If we want to do on the collector, this requires the export of every single
packet of that flow (basically, a series of Flow Records of one packet), to be
able to compute the delays on the collector.
Once it's done, we need the aggregate all these one packet Flow Records into a
single one with: the right number of packets, and the delays
So to save computing on the router, we are going to increase the IPFIX export
bandwidth (multiply it by average number of monitored packets in the Flows)
[JMC] This makes sense, but I don’t think that saving compute power on the
collector is really something to call out. The bandwidth on the network is the
bigger cost.
Re-reading section 7.5, I found a mistake
OLD:
The alternative, with any delay monitoring on the
router, requires the export of every single packet as a separate Flow
Record, including the timestamps information, for the Collector to
compute delay metrics (min, max, and mean) and to recompute the
aggregated Flow Record.
NEW:
The alternative, without any delay monitoring on the
router, requires the export of every single packet as a separate Flow
Record, including the timestamps information, for the Collector to
compute delay metrics (min, max, and mean), before recomputing the
aggregated Flow Record.
ALTERNATIVE NEW:
The alternative, with no delay monitoring on the
router, requires the export of every single packet as a separate Flow
Record, including the timestamps information, for the Collector to
compute delay metrics (min, max, and mean), before recomputing the
aggregated Flow Record.
[JMC] I like NEW better than ALTERNATIVE NEW.
Joe
_______________________________________________
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
