TCP vs UDP for Video Streaming

Prerequisite : TCP/IP Model, User Datagram Protocol (UDP)

In this era of the modern internet with entertainment, education, gaming and all kinds of necessities streaming live everyday, the demand of an uninterrupted video stream is highly adamant. To dive into the topic of which protocol is better for video streaming, one must be familiar with the TCP and UDP protocols.

TCP in transmitting packets :

• TCP is a protocol that negotiates a formal session with its partner. TCP sends data and accepts acknowledgement. 
• TCP guarantees delivery. 
• It also adjusts its send rate according to its estimate of the network’s ability to send the data. It estimates bandwidth, loss and latency and if those have deteriorated, it will decrease the flow rate and if they have improved, it will increase the flow rate.  
• If a data pack is lost during transmission, it is retransmitted, eventually.

TCP’s normal transmission :
TCP gradually increases the amount of data it sends until the link becomes saturated. First it starts slow and sends more and more data at an increasing rate. At congestion avoidance phase, in order to avoid congestion it gradually increases the data. At the end stage it adjusts the data to a rate that the receiver can comfortably process, known as the steady state.

TCP’s reaction to lost packets :
When a packet is lost, either due to the network buffer being overfilled or the receiver getting more data than it can buffer, the lost packet won’t be acknowledged, so TCP assumes that it sent the data too quickly and so it starts the slow start all over again. When a second packet is dropped, the flow is cut again. If the drops are successive, then the rate will drop so much that at a time only a single packet is being sent.

We can look at a scenario that depicts TCP’s reaction to lost packets below – 

In this scenario source A sends 10 data packets D1 to D10 to recipient B and while transmission, a data packet D6 is lost. 

• Source A establishes a TCP connection with Source B.
• A sends D1  data packet and D2 data packet to Source B.
• B asks for data packet D3.
• A sends D3 along with data packets D4, D5 and D6.
• But D6 gets lost during the transmission, lets say due to B’s buffer getting overfilled.
• B then asks for data packet D6.
• A this time sends only one packet, a slow start again.
• B asks for D6 again.
• A continues to send packets D8 and D9 individually, while B keeps asking for D6.
• The receiver has not sent 4 acknowledgements asking for D6, the TCP now assumes that the packet is lost, otherwise the assumption was that it was misrouted in the network. So, A finally re-transmits D6.
• B now asks for data packet D10.
• A sends D10, and then the connection closing process is performed.

We observe that a single dropped packet caused a slow start process and a congestion avoidance process to not allow the increase in traffic flow. It dropped back to a single packet at a time. Thus, one single packet loss, cut our throughput by as high as 50%.
We come to certain conclusions that –

• TCP is sensitive to packet loss, latency (delay), and available bandwidth.
• TCP adjusts to it using slow start, congestion avoidance and estimating latency of round trip time (RTT).

Hence, if your client is demanding bandwidth more than the sender could provide and there is a data loss, then latency is unavoidable. Now if we think of a live video streaming and due to some of the above mentioned causes, a packet loss occurs then the performance of the live streaming will be heavily deteriorated because the protocol will be busy re-transmitting the lost packets. This will result in the viewer lagging behind than what is actually being streamed on the video live. 

UDP :
UDP is also a transport layer protocol. It has no idea whether or not the data arrives successfully. It sends as soon as the application provides data and a soon as the OS says OK. It essentially has no knowledge of receipt or failure. UDP does three things –

• It identifies the sending and receiving process using port numbers.
• It runs an error check on the UDP header.
• It records a check on the UDP header.

Thus, we see that UDP provides no means whatsoever to retrieve the lost packets. It does not care whether every packet has reached its destination or not. If you think of the live video streaming again, a loss in a data packet will not lag the video in order to retrieve the lost packet. The quality of the video will deteriorate depending on how much the loss was, ranging from a small square on the corner of the screen being distorted or the whole screen, but the pace of the video will remain aligned with the actual live stream.

Real Time Protocol :

• UDP in itself does not provide many features that TCP does. But layering it with another protocol, we can achieve some features same as TCP.
• In voice or video conferencing, some of the TCP features are added by inserting a protocol called Real Time Protocol (RTP). If we put the RTP header in with UDP, RTP will add sequence numbers, some time stamps and an identifier of the audio or video source and it will also allow for the protocol called RTCP to report loss.
• While using RTP with UDP, voice packets are sent with uniform spacing based on the codec output.
  For example, in voice they are sent every 20ms (1/50 sec). And in video, they are sent when an IP packet is filled.

So UDP can be very sensitive to loss in voice if several successive packets are lost, audio drops momentarily and we notice it. But if you lose a single packet, its a 50th of a second of a sound and your ear are not sensitive to detect that. But in case of video, because so many video packets are necessary to paint a single frame, the quality may be reduced and it becomes apparent in form of little squares or little slices on the screen that turn to a different color because the data didn’t come in order to paint it properly. In a real time audio or video transmission, networks should normally not exhibit loss > 0.25%.

Therefore, UDP coupled with other protocols like RTP, WebRTC and RTSP can provide a better video streaming experience than TCP.