Jitter

Jitter is the variation in the delay packets experience crossing a network path. It is not the size of that delay. A stream whose average latency is a healthy 20 ms can still be unplayable. That happens when consecutive packets land 5 ms, 50 ms, 10 ms and 40 ms apart. The average looks right, but the irregular spacing breaks real-time delivery. Jitter is not packet loss. It is not throughput either. It measures the regularity of arrivals, not how many arrive or how fast.

The standards prefer a different name. RFC 3393 section 1.1 declares that the document will avoid the term jitter wherever possible. It will "stick to delay variation which is more precise". That is because jitter also names unrelated phenomena. RFC 5481 notes the term "has been used to describe frequency or phase variations, such as data stream rate variations or carrier signal phase noise". Trust a metric labelled "jitter" only once you know which formulation produced it. The industry implements two formulations that are not interchangeable, and RTP reports a smoothed version of one of them.

What a receiver does about it never changes. A jitter buffer (RFC 5481 calls these de-jitter buffers) holds arriving packets briefly. It releases them on a steady cadence, converting variable delay into a constant, larger delay. That trade, variation for latency, is the whole of jitter engineering. Interactive calls and low-latency live streams cannot spend the added delay, so they are the workloads jitter hurts first. For a CDN the lever is the queues on the path, because jitter is mostly queueing time. The variation left after that mostly sits on the viewer's own access link.

How it works

One-way delay splits in two. The deterministic part is transmission and propagation. It "does not change when all the transmitted packets have the same format and size and use same physical link". The remainder is jitter. Jitter "is mainly associated with the queueing delay and varies from packet to packet, even when the packets have the same size and format" (Penco et al., 2022). That is why jitter is a congestion signal. It samples the queue depth ahead of each packet. RFC 5481 section 3.1 makes the inference explicit. If one packet in a stream meets virtually empty queues on a stable path, "the additional delay observed on other packets can be attributed to the time spent in one or more queues".

Every delay variation metric is derived from one-way delay. Each takes the difference between two measurements, and one of them acts as the reference. RFC 5481 records the two formulations the industry actually implements:

• IPDV is inter-packet delay variation. Here "the reference is the previous packet in the stream (according to sending sequence)", so IPDV(i) = D(i) - D(i-1). It is signed. Its mean over a stream is usually zero. It measures the change in inter-packet spacing between sending and receiving.
• PDV is packet delay variation. Its reference is the packet with the minimum one-way delay in the interval, so PDV(i) = D(i) - D(min). It is never negative. It is "a version of the one-way-delay distribution, shifted to the origin by normalizing to the minimum delay".

RFC 3393 section 1.2 defines the singleton metric both forms comply with. It calls the metric IP packet delay variation (ipdv). RFC 3393 defines it for "a selected pair of packets in the stream going from measurement point MP1 to measurement point MP2". It "is the difference between the one-way-delay of the selected packets". Section 4.5 derives the familiar one-sided statistic. Consecutive packets are selected, and "they then take the absolute value of the ipdv values in the sample".

RTP reports a smoothed version of the same idea. For RTP over UDP, a receiver computes a per-packet difference D from timestamps at both ends, where "the relative transit time is the difference between a packet's RTP timestamp and the receiver's clock at the time of arrival, measured in the same units". The receiver runs this difference through a first-order filter with gain 1/16: J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16. RFC 3550 section 6.4.1 describes the resulting RTCP field as "an estimate of the statistical variance of the RTP data packet interarrival time". It requires that "the jitter calculation MUST conform to the formula specified here", so figures from different implementations are comparable.

The jitter buffer absorbs what is left. It "re-orders packets if they are delayed by less than the length of the buffer and drops packets that are too late". That makes its length simultaneously the variation it tolerates and the delay it adds: "if it is too small, then the video is jittery, but if it is too large, delays are added, which is detrimental to the user". RFC 3393 section 1.3 names this as delay variation's first use. RFC 3393 calls it "the sizing of play-out buffers for applications requiring the regular delivery of packets". It adds that what normally matters for sizing is the maximum delay variation, not the average.

Why it matters for a CDN

Jitter matters more than the number users quote. Cloudflare's own position is that "video conferencing, streaming, web browsing, and even gaming all require minimal bandwidth and are much more sensitive to latency, jitter, and packet loss". Cloudflare also states that "a remote worker may benefit more from lower jitter (smoother video conferencing)". A delivery network tuned only for bandwidth has optimised the metric that stopped being the constraint.

Jitter bites at a different layer depending on the delivery model. CDNs carry both models:

• Packet level applies to RTP and WebRTC voice and video. The jitter buffer is measured in tens of milliseconds. Path variation shows up directly as buffer growth, added delay, or dropped frames.
• Segment level applies to HTTP adaptive bitrate delivery such as HLS and DASH. TCP and QUIC hide per-packet variation by retransmitting and reordering. What surfaces instead is variance in segment completion time against a playback buffer measured in seconds. LL-HLS and LL-DASH shrink that buffer deliberately. This removes the slack that used to hide the variation.

The CDN's lever is the queues. Jitter is mostly queueing time, so an edge server near the viewer traverses fewer and less loaded queues than a distant origin. This removes most of the variation a CDN can reach. What remains sits largely on the last mile. RFC 5481 section 3.1 is direct about the reason: "delay variation can occur beyond IP router queues, in other communication components. Examples include media contention: DOCSIS, IEEE 802.11, and some mobile radio technologies". Wi-Fi and mobile radio are not yours to fix. Plan for them in the player rather than in the network.

What CDNs do

• Cloudflare scores it. Its Aggregated Internet Measurement (AIM) rubric turns six metrics into a network quality score for streaming, gaming and real-time communication. Those metrics are latency, packet loss, download, upload, loaded latency and jitter. The speed test behind it derives jitter from round-trip time samples. It reports "loaded and idle jitter, the average variation between consecutive RTT measurements". It also publishes results to Measurement Lab and the Radar API.
• Akamai reroutes around transient congestion mid-object. Quick Retry "detects slow forward throughput while fetching a streaming media object and attempts a different forward connection path to try to avoid congestion". Read the limit with the feature. The default target forward throughput is 5 Mbps. Akamai documents that "quick retry isn't enabled for high bit rate streams above the 5 Mbps default". This excludes 4K and 8K streams until an account rep sets a higher target. That target is settable between 2 and 50 Mbps.
• Amazon CloudFront makes low-latency delivery explicit configuration rather than a default. For LL-HLS you must "specify _HLS_msn and _HLS_part as additional query string parameters for the cache policy that you use with the cache behavior for manifest requests (*.m3u8)". AWS documents the step for an Elemental MediaPackage origin. Without it, the distribution does not forward the blocking playlist parameters that low-latency mode requires.

Watch out for

• Jitter and loss answer different questions. RFC 3550 section 6.4.4 states: "Packet loss tracks persistent congestion while the jitter measure tracks transient congestion. The jitter measure may indicate congestion before it leads to packet loss." Rising jitter is the early warning. Rising loss is the confirmation.
• An RTCP jitter figure is not an SLA number. The same section is explicit: "The interarrival jitter field is only a snapshot of the jitter at the time of a report and is not intended to be taken quantitatively." It exists for comparison across reports from one receiver over time, or across receivers at one time.
• RTP jitter includes the sender. The calculation keys off the RTP timestamp, so "any variation in the delay between that sampling instant and the time the packet is transmitted will affect the resulting jitter that is calculated". Video is the common case: all packets of a frame carry one timestamp but are not all transmitted at once. RFC 3550 keeps that contribution deliberately, "considering that the receiver buffer must accommodate it". So an RTP jitter value is not a pure measurement of the network.
• IPDV and PDV do not convert. RFC 5481 section 6.6 finds no clear relationship between PDV and the RFC 3550 interarrival jitter. It also finds no way to turn PDV singletons into IPDV singletons without returning to the raw delay samples. A jitter number without its formulation cannot be compared with another one.
• Loss corrupts IPDV faster than PDV. With every other packet lost, "the IPDV metric doesn't produce any results, while the PDV produces results for all arriving packets". IPDV results are affected by both the loss ratio and the loss distribution. PDV results are affected only by the ratio.
• A packet that arrives too late is a lost packet. "Lost and delayed packets are separated by a waiting time threshold". A de-jitter buffer's length is exactly that threshold for the application. Severe reordering is the same phenomenon at its limit. RFC 5481 calls reordering "essentially an extreme form of delay variation".

Best practice

• Report a spread over a stated window, never a single sample. RFC 5481 section 8.3 says it is "sufficient to specify the upper percentile (e.g., 99.9%)" for PDV. For IPDV, it recommends an inter-quantile range such as 5% to 95%, because that distribution is two-sided. Percentiles read off an IPDV distribution mislead: one late packet fails two singleton pairs, once positive and once negative.
• Size the play-out buffer from the PDV distribution. The range (max-min) or the 99.9th percentile of PDV "are closely related to the buffer size needed to accommodate the observed network delay variation". The minimum delay is the alignment point a de-jitter buffer smooths against. RFC 5481 notes that ITU-T Y.1541 sets its objective on the 99.9th percentile of PDV.
• Measure idle and loaded jitter. Loaded jitter is what the connection does while it is busy. That is the state a viewer is actually in. A large idle-to-loaded gap over a wired link points at the access network rather than the player.
• Quote the formulation, the statistic and the window with every number. "PDV 99.9th percentile 18 ms over 5 minutes" is actionable, but "jitter 18 ms" is not.