1 Executive Summary

 

This MQP began with the simple intention of developing an improved method for transporting real-time, multimedia data over an internet. To this end, a research effort was spawned to investigate the suitability of the existing TCP/IP Internet Protocol suite for the task of delivering potentially high-bandwidth, real-time multimedia data. This research led to two important early conclusions regarding both transport layer protocols in the TCP/IP protocol suite, the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP):

1. TCP, the fully-reliable, stream-based data transport protocol used in such applications as telnet and FTP where reliability is an important consideration, has a number of parameters accessible at both the application layer and inside the actual kernel implementation that can be tuned to yield optimum performance. Quite often, implementations of TCP are left in an unoptimized state to allow for successful operation over nearly any type of networking medium; given specific information about the underlying network architecture that a particular TCP implementation is to operate over, a programmer could tune it to meet these requirements.
2. UDP, the best-effort, datagram delivery service in the transport layer of the Internet Protocol suite, is primarily an interface to the internet-layer Internet Protocol, and as such, has very few parameters that would require tuning. Recently, UDP has become the protocol of choice for many multimedia application developers due to its lack of a flow control mechanism, placing the burden of flow control back at the application. Network testing performed by myself and graduate student Brian Hazzard while supported by a grant from Lockheed Martin Government Electronic Systems indicated that a UDP-based application left to run without flow control will soon overload local buffers and drop packets before they even reach the physical network. Multimedia applications that utilize UDP must necessarily lack the robustness of TCP's carefully implemented flow control algorithm, and suffer from less-than-desirable performance.

Clearly, the method by which improved transfer of multimedia data can be reached must lie at a point somewhere near the middle of the spectrum formed by the nearly diametrically opposed implementations of TCP and UDP.

In the fall of 1997, a second MQP was started to develop an internet video-phone that would make use of a unique set of simple, but effective compression algorithms. During that project's preliminary talks, a common-sense idea was presented: The most important factor in real-time, multimedia data is the linear progression of the time-sensitive data and this should be preserved at all costs. If an application using TCP to transmit a video stream encounters network congestion, the video stream that, in a linear world, is five minutes long could take six or seven minutes to view with variations in the time-wise stretching of the play back, a very nonlinear experience! In contrast, a protocol that made every effort to preserve sequential time linearity in the face of network congestion, if given a five minute video stream would provide a video stream that lasted exactly five minutes, but with, at times, a lowered quality than that of the original. In the nonlinear case, an audience member could close her eyes, and the video would pick up where she left off; in the linear case, the video appears to keep running while her eyes are closed and she simply misses some data.

Our proposed solution to the successful transport of real-time multimedia data was then formulated. The phrase timed-obsolescence was coined to indicate that multimedia data should have a window of usefulness associated with it, a sort of expiration date for video and audio. Once a set of data has exceeded that window, it should be discarded without further attempts at delivery.

This MQP's newly defined end product would be a robust, fully functional internetworking transport layer protocol that implemented the above concept of timed-obsolescence as its main objective.

The protocol needed to have a fully-functional flow control mechanism, similar on many levels to that employed by TCP. With good flow control, the protocol would be able to dynamically adjust to network congestion and retransmit lost packets in a timely manner. This necessitated that, at the very least, the protocol under development would use a sliding window scheme to control the amount of data in the network at any given time. In fact, it was discovered that many of the well documented optimizations to TCP in the 1980's and early 90's would be absolutely necessary for this multimedia-specific endeavor, including: slow start, round trip time variance estimation, exponential retransmit timer back-off, dynamic congestion window sizing and per-packet time-stamping. It also became obvious that the timed-obsolescence feature demanded selective acknowledgment and retransmit, a subject that TCP developers have been avoiding for some time now.

Months of development went in to the resulting 4,000 lines of C source code that now comprise the unique transport protocol developed to satisfy the goal of timely and semi-reliable transmission of real-time multimedia data. The protocol's name, the eXtended User Datagram Protocol (XUDP) is intended to convey that it is actually built on top of the services of UDP, that it utilizes a UDP datagram-like entity for its fundamental unit of data transfer and that it is an extension to these services in that it behaves much more like TCP than like UDP. As evidenced by the results (chapter 8) and conclusions (chapter 9) sections, XUDP met the goal of preserving the linear progression of timed sequential data in every case.

Although some work remains to be done to optimize critical algorithms in XUDP, it is, at the completion of this project, a viable communications protocol with great promise for use in future real-time multimedia applications.