While there are an endless number of Internet protocols, some of them are particularly suited for video networks. For real-time transmission of video over IP, let's look at the protocol stack used in the Pro-MPEG Forum's Code of Practice 3, which is currently undergoing standardization with the Society of Motion Picture and Television Engineers. (See Figure 1.)
IP over data link services, such as Ethernet for LANs or SONET for WAN, are ubiquitous for both data and video transmission. As we move up the protocol stack shown in Figure 1, we find UDP over IP, rather than the typical TCP over IP.
Note: Throughout this article, you will find references to Internet Engineering Task Force (IEFT) Request for Comment (RFC) documents. These are the defining documents for the protocols discussed in this article and can be found on many Web sites. (My favorite site iswww.rfcs.org.) In many cases, these documents are surprisingly readable and contain interesting information about the protocol.
User Datagram Protocol
UDP (RFC 768) sends datagrams from one place to another. UDP is a core video networking protocol because it allows the creation of large packets. It does not require acknowledgement from the receiver, and it has low overhead. Nothing in UDP guarantees that packets sent across the network will reach the other end. In fact, UDP explicitly does not check to see that packets have been received.
UDP packet size varies, and in some cases, UDP packets can be quite large. Video applications may use this capability to increase efficiency, encapsulating large blocks of video data in a single UDP packet. However, some system administrators may block UDP packets because they hog all the available bandwidth and are unfair to other traffic on the network.
Real-Time Transport Protocol
RTP (RFC 3550) transmits real-time information over IP networks. RTP packets contain sequence numbers and timing information that receiving applications can use to correct errors, such as jitter and wander, which may have occurred in transmission across the network.
Forward error correction
FEC is not a protocol, but rather a technique that recovers lost data in real time. FEC allows receiving applications to reconstruct lost data on the fly rather than waiting for retransmission of the lost data. But nothing in life is free. FEC reconstructs errored packets by using additional data contained in the transmission stream. This additional data raises the total bandwidth required for a particular link. In typical applications, the overhead is 15 percent to 20 percent. FEC also introduces delay, which is unacceptable in some applications.
Many FEC schemes have been developed over the years. These schemes represent varying compromises among different variables, such as complexity, robustness, delay and overhead. In the case of the Code of Practice 3 implementation, a constrained version of RFC 2733 is employed.
In Figure 1, two other layers are shown — a compression layer and a user application layer. In the future, compression may not always be employed. This is because prices for bandwidth continue to fall and because compression introduces delay — an undesirable characteristic in broadcast applications.
Video applications have migrated from purpose-built hardware, such as tape machines and special effects boxes, to multipurpose computing platforms. These platforms incorporate networking as an integrated part of their overall applications, making video networking an increasingly important part of any facility's infrastructure.
Quality of service frameworks
QoS frameworks are collections of protocols, policies and procedures that, together, establish a level of service across a network. As you can imagine, QoS is an important part of video networks.
Differentiated Services and Multi-Protocol Label Switching
Differentiated Services (DiffServ) and Multi-Protocol Label Switching (MPLS) operate on similar principles. The idea is to mark packets as they enter a network on a priority basis. When the marked packets reach a congestion point on the network, predetermined rules control which packets get priority and which packets may be dropped from the queue.
These frameworks have the potential to become an important part of video networks. The problem with them is that while they work conceptually, a particular session may not receive the desired high importance on the network. Figure 2 shows that voice traffic receives the highest classification, while e-commerce receives the lowest classification.
If you control your network from end to end, then you will not have any problem ensuring that your video traffic receives the priority it requires. However, if you are working with a public carrier, you may find that the carrier believes other traffic has priority. In Figure 2, there is not a classification for video, and it may be difficult convincing this public carrier that your video traffic is more important than telephone or other data traffic.
If you own dark fiber and you are trying to send both video and computer data across the fiber, you can successfully use these systems to mark the priority of the video traffic so that it gets through first when congestion occurs.
Second tier video networking protocols
Like UDP, Transaction Control Protocol (TCP) sends datagrams from one place to another over a network. One of the biggest differences between TCP and UDP is that TCP guarantees delivery of the data. TCP does this by stamping each datagram with a unique sequence number. It then looks for the receiver to acknowledge that it received the datagram. TCP also implements a number of rate control mechanisms to deal with rate limits imposed by the receiver and congestion issues on the network.
TCP is one of the most popular protocols on the Internet. However, it is not a core video networking protocol because in many video applications, it introduces unacceptable delay — especially in real-time applications.
TCP provides great functionality. For example, it requests the retransmission of lost packets and automatically puts packets in the order they were transmitted before handing the data to the next layer in the protocol stack. While recovery from lost packets and the ability to deal with packets that arrive out of order are important to video applications, many applications choose to handle these problems themselves. This is because video applications are especially sensitive to delay, and they frequently prefer to deal with these problems in specialized ways.
You would think File Transfer Protocol (FTP) would be a core video networking protocols, especially when moving video files. However, there are several reasons why FTP is not desirable for video applications.
As I said in my September 2005 column, “FTP has some characteristics which make it unsuitable for moving professional video files. First, many FTP applications have a file size limit of 2GB. Professional video files can be much larger than this, so this limitation can be a real problem. Second, FTP has rate control mechanisms that can interfere with transmission of large files.”
Given fairly common network parameters, FTP guarantees the transfer of large files will fail. FTP works well for smaller files. This being said, it is clear why FTP is not a core video network protocol.
Brad Gilmer is president of Gilmer & Associates, executive director of the AAF Association and executive director of the Video Services Forum.
Send questions and comments to:brad.gilmer@penton.com
