Network Jitter

Content

What’s Network Jitter

How to Estimate Jitter

Few of Experimental Data

 

 

Network connection is influenced by a number factors: network delay, queuing delay in middle boxes,  network jitter, packet loss, packet re-ordering and even packet duplication. In this post we speak about the network jitter.

 

 

What’s Network Jitter

Network jitter is a measure of variation of arrivals times of packets to Receiver, it’s desirable that Sender sends packets uniformly, equally spaced time intervals, otherwise the network jitter is noised. In other words the network jitter of a packet is the difference between the actual arrival time and the expected one.  If the difference is greater 0 then the packet has arrived Receiver lately (and can be discarded if it arrived too lately).  If the difference is negative then the packet arrived early and Receiver should have sufficiently large playout buffer to amortize the jitter.

 

 

Large network jitter requires large amortization buffer at Receiver and consequently additional latency added. Cloud gaming and video conferencing applications are very sensitive to the latency. If the network jitter is smaller than the frame duration (1/fps) then an input buffer is sufficient to accumulate a single frame, otherwise the amortization buffer is needed.

Instantaneous changes in arrival times of packets that exceed the jitter amortization buffer result in overruns (Receiver discards input packets since there is no room to absorb them) or underruns (Receiver should decode and display a frame, but the frame has not completely arrived or the buffer is empty. In such case Receiver can wait until the frame completed but it might produce visible stuttering and even lip-syncs). 

The amortization buffer at Receiver can be adaptive according to measured network jitter: larger jitter larger buffer and vice versa.

 

 

the figure is taken from the book “End-to-End QoS Network Design Quality of Service for Rich-Media & Cloud Networks”, Tim Szigeti et al. , 2014

 

How to Estimate Jitter

Let’s assume that Sender sends RTP-packets, each RTP packet carries its own delivery timestamp (usually in units of ms). RTP packetization is popular in media streaming.

Protocol stack of delivered media (MPEG2 System or Transport Stream is optional and not recommended, this layer adds ~2% of overhead):

 

 

Timestamps are conveyed in RTP layer, we show below that the timestamps are necessary to estimate the network jitter.

 

 

 

Denote the deviation D(i)  of inter-arrival times of successive packets i-th and (i+1)-th:

 

D(i)  =    (R(i+1) – R(i))  – (S(i+1)-S(i))             (1)

 

Where R(i) is the timestamp in RTP header of i-th packet (at Sender’s clock), S(i) is arrival time of i-th packet to Receiver (at Receiver’s clock).

It’s obvious from the formula (1) that if the network jitter is zero then D(i) = 0.

The network jitter J can be progressively updated as follows:

for the very first packet   J = |D(0)|

for non-first packet ‘i’:

J  =   J  +  1/16( | D(i) | – J )

 The 1/16 is the reactive factor, you can take 1/32 or 1/8.

 

Conclusion: The larger jitter the larger playout buffer at Receiver’s side. 

Mismatches between the network jitter and the playout buffer can cause annoying effects like jerkiness in playback due to the failure of some frames to meet their presentation deadlines (the frame arrives too late or the frame arrives too early and the playout buffer is full).

 

Few of Experimental Data

According to the work “RTP: Audio and Video for the Internet” by Colin Perkins  the network jitter is not distributed normally, the distribution is right-tailed:

In such case STD makes few sense, for example we can’t use the rule of 3-sigmas (only in the normal distribution the probability of deviation from 3-sigmas is less 1%). In the case of skewed asymmetrical distribution the STD is replaced with other parameter called ‘skewness’:

 

Another definition of the skewness: 

                        3(mean – median)/σ

 

or even

(mean – median)/σ