|Authors||H. Espeland, C. H. Lunde, H. K. Stensland, C. Griwodz and P. Halvorsen|
|Editors||C. Griwodz and L. Wolf|
|Title||Transparent Protocol Translation and Load Balancing on a Network Processor in a Media Streaming Scenario|
|Afilliation||Communication Systems, Communication Systems|
|Publication Type||Proceedings, refereed|
|Year of Publication||2008|
|Conference Name||Network and Operating System Support for Digital Audio and Video (NOSSDAV 2008)|
Today, major newspapers and TV stations make live and on-demand audio/video content available, video-on-demand services are becoming common and even personal media are frequently uploaded to streaming sites. The discussion about the best transport protocol for streaming has been going on for years. Currently, HTTP-streaming is usual although the transport of streaming media data over TCP is hindered by TCP's probing behavior, which results in the rapid reduction and slow recovery of the packet rates. On the other hand, UDP has been criticized for being unfair against TCP, and it is therefore often blocked by access network providers. To exploit benefits of both TCP and UDP, we have implemented a proxy that performs transparent protocol translation in such a way that the video stream is delivered to clients in a TCP-compatible and TCP-friendly way, but with UDP-like smoothness. The translation is related to multicast-to-unicast translation and to voice-over-IP proxies that translate between UDP and TCP. Furthermore, it is also similar to the use of proxy caching that ISPs employ to reduce bandwidth demands. The unique advantage of our approach is that we avoid full-featured TCP handling on the proxy server but still achieve live protocol translation at line-speed in a TCP-compliant, TCP-friendly manner. Although we discard packets just like a sender of non-adaptive video over TCP, we achieve higher user-perceived quality because our proxy can avoid receive queue underflows in the proxy, while also achieving the same average bandwidth as a TCP connection between proxy and client. In this demo, we present our prototype implemented on an Intel IXP2400 network processor. The prototype proxy does not buffer outgoing packets, yielding data loss in case of a congested TCP side. Comparing HTTP-streaming from a web-server and RTP/UDP-streaming from a video server shows that, in case of some loss, our solution using UDP from the server and a proxy that translates to TCP delivers a smoother stream at playout rate while the end-to-end TCP stream oscillates heavily.