Learning about network protocols is one of the challenges facing any video professional moving into the realm of computer networks. Protocols are formalized agreements about how different vendors will communicate over networks. Applications frequently use more than one protocol at a time to transport data. Protocols can be layered on top of one another in combinations called protocol stacks. (See Figure 1.)
Internet Engineering Task Force documents, called requests for comments (RFCs), codify many, if not all, protocols. You can obtain all of the RFCs related to a particular protocol from www.ietf.org/rfc.html.
Almost every protocol is known by a three-letter acronym (TLA), and this month's column uses more TLAs than usual.
Internet Protocol (IP)
IP is the core of almost every LAN. It provides connectionless, unreliable delivery of datagrams. IP is connectionless, meaning that an application using IP can send packets immediately, without contacting the receiver ahead of time to establish a connection. This type of protocol doesn't require a two-way connection between sender and receiver. In this context, the term unreliable means there is no check in the protocol to be sure a specific datagram has been delivered.
IP knows nothing about the overlying application. It does not know the difference between streaming or file transfer; it supports either application. IP also doesn't guarantee that the network will deliver packets, or that, if it does deliver them, it will do so in the same order in which an application sent them. Packets may be destroyed or even duplicated while in transit across the network. IP places no restriction on delay across the network.
After all this, you may wonder what IP actually does. One of its most important jobs is to describe a methodology for getting datagrams from one place to another. It also describes routing and addressing schemes that are absolutely fundamental for moving data across the network. Because of this, it is a key enabler of almost everything done on the Internet.
Transmission Control Protocol (TCP)
TCP provides reliable transfer from one location to another. It also adds important functionality on top of IP. This includes guaranteeing delivery (although TCP will give up after a certain period of time if it fails to receive acknowledgement of packets), re-ordering packets so that the protocol presents them to the application in the same order that they were sent originally, and translating a stream of data generated by an application into IP datagrams that the network can transport. TCP provides a bridge between applications and the structure of data flowing on the network, so the application does not have to worry about how protocols encapsulate data for transmission or whether a particular data packet made it to the receiver.
TCP running over IP (TCP/IP) is extremely common. Nonetheless, it is important for production professionals to understand that these are two separate protocols specified by two different documents.
TCP has limitations that can cause problems in professional production applications. It guarantees delivery by requiring the receiver to acknowledge receipt of each packet. But heavy network traffic or congestion may delay these acknowledgements or lose them completely. TCP responds to congestion by cutting its transmission rate in half and then slowly increasing the rate over time as congestion decreases. With too severe a level of congestion or too large a network delay, the TCP transfer fails entirely. What is worse, even if the network has a large pipe, TCP's throttling behavior prevents data from filling the pipe. Another limitation is that the commonly available version of TCP limits file size to 2GB — an obvious problem when you are trying to move large video files. That said, TCP plays an important part in networked production.
Figure 2 on page 34 shows how an application might use TCP/IP to send data across an Ethernet network. As the application data works its way down the protocol stack, each of the protocols adds a header, and the subsequent protocol encapsulates both the data and the header from the protocol above it. This might seem like unnecessary overhead, but each of the protocols performs an important function. Without IP, for example, you would not be able to route the packets using IP addresses. (Note that the drawing is not to scale. An IP header is 20 bytes long, but the datagram can be up to 65,516 bytes long.)
Unreliable Datagram Protocol (UDP)
From its name, you would think that UDP would be totally unusable for video. Why would anyone want to use an unreliable protocol? UDP does not require a positive acknowledgment — it just sends the packets to the receiver without any feedback loop. This method might seem to be a problem but, in fact, it does not suffer from many of the issues related to TCP rate throttling. Many critical applications that use UDP handle the issue of guaranteed delivery themselves.
Because UDP does not require acknowledgement from the receiver, it is useful in cases where one sender wants to send the same information to multiple receivers and is not too worried if some pieces get lost along the way. Broadcasters can perform real-time streaming with UDP combined with other protocols, such as RTP.
ReSerVation Protocol (RSVP)
Network congestion can be a source of headaches for the production professional. When the Internet is congested, routers must drop packets if the next piece of equipment in the chain is not ready to accept them. This can be a problem for real-time applications such as streaming video, where the effects of packet loss are easy to hear and see.
A logical solution is to develop a protocol that reserves bandwidth along the way, so that the data you transmit is never dropped. This is the idea behind RSVP. Network devices that understand RSVP reserve a certain amount of bandwidth for you to use. While RSVP does provide some solutions, it presents two challenges. First, RSVP is not widely supported on the Internet so, beyond your ingress point, RSVP may fail to provide the needed bandwidth. Second, from a business perspective, there is some question as to whether all bandwidth providers on the public Internet support RSVP. Some providers may argue that guaranteeing one user bandwidth that they may or may not use is a waste of bandwidth. Others see the potential for a new class of service in offering that type of bandwidth and believe customers will pay more for it. Time will tell whether this protocol becomes as ubiquitous as UDP, TCP and IP.
MultiProtocol Label Switching (MPLS)
An alternative to reserving bandwidth along the way is to specify the route the traffic should take through the network. This is called route pinning. The assumption is that the network engineer will choose a route with enough capacity to handle the traffic. Or, perhaps, specifying the route will allow the traffic to travel over a path where all the equipment understands a particular protocol, such as RSVP. MPLS provides this functionality, as well as giving users the ability to describe what should happen if a specified path fails.
Real-time Transport Protocol (RTP)
RTP is used to move real-time streams including audio and video. It provides timing information that allows the receiver to reconstruct the original timing of the transmitted material in a way that identifes the content being sent, provides security, and notifies the overriding application of lost data. RTP frequently rides on top of a UDP/IP stack.
So many protocols are important to the industry that it was hard to choose just a few for this article. If I have omitted your favorite one, it is probably because of space limitations. The ones I list here are frequently discussed and relatively well-supported. Achieving interoperable support for lesser-used protocols is another challenge facing production professionals.
Brad Gilmer is executive director of the AAF Association and the Video Services Forum. He is also editor in chief of the “File Interchange Handbook.” Learning about network protocols is one of the challenges facing any video professional moving into the realm of computer networks.
Send questions and comments to:brad_gilmer@primediabusiness.com
To order Brad Gilmer's book, File Interchange Handbook for Images, Audio and Metadata, from Focal Press,visitwww.focalpress.comor call 800-545-2522. The book is also available from most major booksellers.
