[signa11]

rfc-4689 (iirc) defines jitter as the fluctuation in forwarding delay between 2 consecutive received packets in a stream.

not sure how this would work for tcp-ack's which can be cumulative. moreover, any approach that does this measurement must account for both delayed and lost/corrupt packets.

imho, only a true realtime jitter measurement would do, anything else would be a crude approximation, and might result in the same flaws as before...

[edit]: examples of '...anything else...' mentioned above might be inter-arrival histogram where receiver relies on packets being transmitted at a fixed cadence, in this case lost/corrupted packets would badly skew the computed numbers. another approach might be post-processing (after packet capture) where limited buffer space might prove to be the achilles heel etc.

[vadiml]

In VOIP applications the correct jitter estimation is very important and RTP/RTCP protocols are doing it pretty well. Of course each RTP packet has a timestamp which simplifies the task