By Beecher Tuttle
The explosive growth of streaming video traffic has elevated Transport Control Protocol (TCP) to the position of a ubiquitous technology.
Service providers can leverage TCP, along with HTTP adaptive streaming (HAS), to effectively transport non-real time video. These technologies have become increasingly popular because they provide a number of benefits, including familiarity and a widely deployed infrastructure.
That said, TCP is not an ideal solution for every environment. The technology carries with it certain inherent limitations that need to be understood for service providers to take full advantage of its benefits.
Two Alcatel-Lucent execs – Danny De Vleeschauwer and David Robinson – recently co-authored an article for TechZine, the telecom giant's online technology and research magazine, to reveal some of TCP's limitations and help service providers understand if it is the right solution for them.
As Vleeschauwer and Robinson explain, TCP was originally developed to offer reliable data transfer over unreliable networks, providing significant available capacity to all users. As a result, TCP has built-in congestion control mechanisms that can influence the streaming of video. This issue is compounding by the fact that HAS requires more capacity than the conventional method of transporting video, known as RTP/UDP.
Due to the presence of these issues, HAS over TCP is a strong fit in only certain circumstances, including “instantly consumed” non-real-time video, where a small amount of latency is understood. As one would imagine, the technology is not appropriate for platforms where real-time streaming is necessary, such as Skype and other video calling clients.
Vleeschauwer and Robinson stress that the most appropriate version of TCP is necessary to ensure the best video performance. They suggest that the technology should include Early Congestion Notification (ECN) and Selective Acknowledgements (SACK) to maximize efficiency in a wireless environment.
This is necessary because TCP will routinely minimize a window size by half when it should not, due to the fact that it is unable to differentiate between packet loss caused by congestion and packet loss that results from noisy channels, like wireless links. TCP senses network congestion based on packet loss.
ECN and SACK can help overcome these concerns and make TCP more robust. The former notifies TCP when a buffer is filling up, rather than waiting for packet loss to indicate congestion. It also enables TCP to partially differentiate between packet loss due to errors and packet loss resulting from congestion – a step that helps to further improve wireless and LTE efficiency.
SACK, on the other hand, enables the TCP receiver to do a more adequate job of distinguishing which packets were lost. This helps eliminate the practice of having to retransmit all packets.
The authors also note that wireless links can be further enhanced by link layer mechanisms – such as Forward Error Control (FEC) and Hybrid Automatic Repeat ReQuest (HARQ) – which help diminish packet loss between the endpoints of the link. It should be noted that these mechanisms are associated with a higher overhead bit rate and additional delay, so service providers should weigh the pros and cons before introducing them.
Furthermore, buffers need to be carefully sized for TCP to be advantageous, due to the fact that it relies on packet loss to indicate network congestion, according to the authors. If a buffer is too large, the feedback that TCP receives concerning network congestion is often delayed.
"Consequently, it becomes harder for TCP to adjust throughput to maintain its fair share," says Vleeschauwer and Robinson. "For this reason, TCP often does not work well with traffic shapers."
On the other hand, too small a buffer cannot absorb the bursts of traffic that TCP produces, resulting in lower throughput.
In addition, clients generally should not leave time gaps between the chunks of video they request, unless using the highest video bit rate that can be supported over the network. A large play-out buffer must be used in the video client to work effectively.
Finally, TCP does not handle high-definition video flow as well as standard-def. When transporting HD video, service providers should increase the number of TCP connections.
Vleeschauwer and Robinson conclude that HAS over TCP is an "excellent option" for transporting instantly consumed video when its limitations are understood and accounted for.
Check out the full article for illustrations of the effects of HTTP adaptive streaming and other supplementary information on TCP.
