UDP packets' jitter and delay

As @Jaap said: Currently Wireshark can only calculate jitter for RTP, as nothing else is implemented. However, it would be possible to calculate UDP jitter.

Explanation
In general you can calculate UDP jitter, however, to do it in the correct way, you would need two capture files. One in front of the client and one in front of the server to be able to calculate the transmission time (delay) and then the variation of delay (jitter). This is called Packet Delay Variation.

The following link describes it in a nice way

http://nms.lcs.mit.edu/~hari/papers/CS294/paper/node5.html

Cite: "Jitter: The jitter of a packet stream is defined as the mean deviation of the difference in packet spacing at the receiver compared to the sender, for a pair of packets...."

Basically, you could do it with one capture file as well, if you accept the time delta between two frame timestamps (in a capture file) to be the variation of network delay. However that's not really correct.

1. it does not take into account delays at the sender side (within the application)
2. a packet could take a different route and could arrive in front of another (earlier) packet.

This would void the calculation!

If you don't care about this, you can calculate (a kind of) jitter as the variation of the frame timestamp delta (frame.time_delta or frame.time_delta_displayed). See link to shell script below.

With RTP it's much easier to calculate jitter, as every RTP packet carries a timestamp value (rtp.timestamp).

Search for 'Timestamp' in the following page:

http://www.networksorcery.com/enp/protocol/rtp.htm

With that timestamp it is possible to calculate jitter with only one capture file, as you can calculate the time delta between two RTP packets and use the timestamp within those packets as a reference for "out of order packets" and "delay at the sender" (basically!).

See How jitter is calculated in the Wireshark RTP Wiki and the following link.

Search for "jitter estimator formula": http://toncar.cz/Tutorials/VoIP/VoIP_Basics_Jitter.html

There are tools for UDP jitter measurement.

• iperf (xjperf) does it's own measurement. It does not need a capture file..
• There is another approach that uses shell scripting and tshark.

So basically, one could implement "UDP jitter" calculation in Wireshark, if the problem described above (delay at sender, out of order packet arrival) is simply ignored or accepted. This could be done as a TAP, similar to the RTP statistics TAP. Volunteers are welcome ;-)

UPDATE: Thinking again about the possibility to calculate UDP jitter with just one capture file, I come to the conclusion, that it's NOT possible to get any usable values. So, you can't just ignore or accept the problem I mentioned above, as the error rate would be unknown, which makes the data useless.

Reason: If you measure only at one side, you are measuring a mix of delay at the sender and delay in the network.

      Sender                     Network           Receiver
p(1): ts(1)                       dn(1)            tr(1)
p(2): ts(2) = ts(1) + ds(2)       dn(2)            tr(2)
p(3): ts(3) = ts(2) + ds(3)       dn(3)            tr(3)
p = packet 1,2,3,…
ts = send time at sender
tr = receive time at receiver
dn = delay in the network
Delay:  tr(2) - tr(1) = [ts(2) + dn(2)] - [ts(1) + dn(1)]
= [ts(1) + ds(2) + dn(2)] - [ts(1) + dn(1)]
= ds(2) + [dn(2) - dn(1)]
= ds(2) + ["variation network delay"]

So, what you are measuring is actually the sum of delay at the sender (ds - delay in the stack, the application, etc.) and the variation in delay on the network (dn(2) - dn(1)). Actually you are just interested in the variation of network delay (jitter). The delay at the sender (ds) could well be much higher than the variation of delay in the network (d(n+1) - d(n)), so you can only use that value if the delay at the sender (ds) is zero. Hoewever, that is something you cannot assume.

Conclusion: To calculate UDP jitter, you need either two capture files (as I mentioned in the first place) or timestamps in the packet, which is not the case for standard UDP. The other option is to actively measure it with a tool like xjperf.

Sorry for my confusion about the “one capture file theory”. One should always do the math and not rely on the stomach ;-))

Regards
Kurt