Re: [IPFIX] latency reporting

Hi, Andrew, all,

I think all of these are useful (indeed, many must think so if you're seeing them from shipping exporters). However, just as with jitter, to some extent, you'll see different Information Elements out there because there are different ways to calculate things, and each of these measurement methods actually is producing a different type of data. RTT derived from synack measurement near the initiator gives you totally different results than synack measurement near the responder (the latter being essentially useless). RTT derived via TWAMP is something different entirely, as you're not measuring application latency along with network latency, and you know you have the whole path.

So we have to be careful about precise definitions if we're going to end up with data we can properly interpret. On that point, I'm not sure I support the idea of having a single overarching "jitter" or "latency" or "rtt" Information Element then selecting an algorithm externally, unless that external selection was flexible enough to handle all the algorithm, OP-placement, passive/active measurement, and other attributes/issues. This seems like it could be a job for extended field specifiers, but we'd have to think about where to draw the line between "IE attribute" and "new IE" very, very carefully here.

Jitter's another beast entirely, because there's such a variety of definitions and algorithms that you can end up with broadly incomparable numbers; at least with RTT everyone's kind of trying to get at the same number.

Indeed, this is a problem we'll most probably be addressing the semantic side of, in part, in the IPPM working group. 

One further point, inline:

On Dec 7, 2012, at 11:10 PM, Andrew Feren wrote:

> Hi all,
> 
> I've been doing some review and clean up of my local IE database and I see around a dozen IEs related to latency and RTT from various exporters/vendors.  This seems like a measurement that could use a standard IE for reporting.  Here are my thoughts so far...
> 
> Name: latencyMilliseconds 
> Type: unsigned32 
> Semantic: quantity 
> Description: latency measured in milliseconds. 
> Units: milliseconds 
> 
> Name: roundTripTimeMilliseconds 
> Type: unsigned32 
> Semantic: quantity 
> Description: Round trip time measured in milliseconds. 
> Units: milliseconds 
> 
> Perhaps the above needs to be fleshed out with some Extended Field Specifiers as has been discussed recently for jitter.
> 
> On a related note an IE that I am not seeing from most of the exporters sending latency information, but which can be useful when diagnosing problems is out of order packet information.
> 
> Name: outOfOrderPacketDeltaCount
> Type: unsigned64
> Semantic: deltaCounter 
> Description: The number of out of order packets since the previous report (if any) for this Flow at the Observation Point. 
> Units: packets

This doesn't suffer _as much_ from OP-sensitivity (reordering generally/often happens due to retransmission as opposed to routers behaving badly) but there is a problem of definition: what is an out of order packet? As with timing issues, there are a lot of little details you have to work out in order to get comparable numbers; those details should be explicitly explained in the definition.

Cheers,

Brian

> Name: outOfOrderPacketTotalCount
> Type: unsigned64
> Semantic: totalCounter 
> Description: The total number of out of order packets for this Flow at the Observation Point since the Metering Process (re-)initialization for this Observation Point.
> Units: packets
> 
> -Andrew
> _______________________________________________
> IPFIX mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipfix

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix