This project aims to build a self-tuning multimedia streaming service that optimizes the user viewing experience by analyzing user behavior, inferring personalized quality of service (QoS) requirements, and tuning system and network resources to maximize utilities of all users. The advent of peer-to-peer (P2P) technology has provided the ideal playground for this research. Traces from operating P2P streaming systems provide rich datasets with which to study the influence of QoS factors on users' viewing experience. In addition, the affordability of a P2P streaming testbed provides both the sandbox to test research ideas and a general educational platform accessible to a large Internet user base.

This CAREER project has two complementary tracks: use-level QoS modeling and QoS-aware resource allocation. On the modeling track, the user utility function is formulated using statistical tools such as regression analysis to infer the influence of individual network- and system-level QoS factors on the user behaviors (e.g., skipping, changing channel, or premature leave), which reflect the subjective user viewing experience. On the resource allocation track, the problem is studied using a time-aware multi-dimensional optimization framework, which helps address the unique challenges posed by the semantics of a P2P system, e.g., how to inclusively optimize the resource allocation under heterogeneous user utility functions.

Broader Impact:

This research plan is expected to incubate the emergence of an extremely cost-effective and scalable P2P service platform as the innovation hotbed to significantly lower the entry barrier for new media-rich applications. The analytical outcome from user behavior study will also bring strategic insights and design guidelines applicable to all multimedia service paradigms beyond P2P.

Project Report

Background Towards the beginning of this project, we were searching for a P2P solution with minimum intrusion to the user experience. At the time, the mainstream P2P streaming solution were desktop rich applications such as PPStreaming, PPLive, etc. But users had already spending increasing amount of time on YouTube among other web portals. So we thought there should be some light-weight approaches that deal with transportation of the videos as plain data objects, and let those websites and their Flash players worry about the rest. Architecture Hence we created the architecture as above, the downloading stub sits on user's desktop machine and intercepts all HTTP GET requests destined to the port(s) it listens on. It then turns to the P2P world to download the requested data and wraps it in a HTTP response back to the requester, that's it. Also given the fact that BitTorrent was already the de facto standard for P2P content sharing, we decided to make our software interoperable with other programs of the BiTorrent family, hence the name BitTube. Our first version was adapted from the Python source code of the original BitTorrent client, then we quickly realized that this doesn't fit the video streaming scenario, where you must sequentially download the video and return any downloaded piece to your player ASAP. With this regard, the sophisticated "rarest first" and "tit-for-tat" policies of BitTorrent have little relevance in our context, so we replaced it with our own C++ implementation, now open sourced at https://github.com/yicui/BitTube. BitTube runs as a single-threaded event loop. In each cycle, it relies on the select() function (we choose non-blocking) to monitor all of its connections (tracker, other peers, its own listening port for requests from the browser, etc.) for any connect/read/write action. Also in case you are the only peer online or other peers cannot send you data fast enough to sustain your streaming, you have to fall back to the HTTP server of the original content provider. It's rather easier to consider the HTTP server as a super peer which never goes offline. But a peer behaves a lot different from a server: instead of retrieving the whole chunk of video file which is slow and wasteful, we only need get distinct pieces of the file from time to time. Here we achieve this by turning on the partial-get and keep-alive of the HTTP protocol. Looking back from now, it looks quite familar to the popular Node.js+Socket.io combination in today's realtime web applications. In today's standard, this design is still quite intrusive, First, you need to download and install our program, which required a great deal of trust and effort from users. We considered Firefox plugin but still couldn't get around the downloading part. Second, we required the content publisher to change URLs of their videos as depicted above. The localhost prefix is crucially important, otherwise our software is unable to catch the requests. The actual URL of the video and BitTorrent tracker follow this prefix. Again, this was the best we can achieve back then. We used to argue that this is the ONLY thing you have to do (in exchange for A LOT of bandwidth saving). Plus, if you don't like our tracker, feel free to use anyone's or host your own. Epilogue BitTube has been used to help broadcasting a few events for KTSF 26, and live broadasting of Chinese Spring Festival Gala on bigtvusa.com. Besides its C++ implementation, we also port it to the Flash player platform by utilizing Adobe's RTMFP protocol. It is also open souced to https://github.com/yicui/BitTube-on-Flash. What's next? One thing we do know is technology of this kind needs to head to the mobile space, and it doesn't have to be restrained to streaming. Games, chat, any scenario requiring distribution of digital content to vast number of users. As of now, proprietary apps rule the mobile braodcasting domain, e.g., Qik and UStream, but we think the entry barrier will be greatly lowered by open-source alternatives. Speaking of open source, one should also keep a close eye on WebRTC, whose peerconnection API is quite similar to early-stage RTMFP in Flash Player 10.0. Penetration rate being the most important metric for P2P technology, WebRTC is still no match to RTMFP as of now. When the time comes, BitTube should be ported (by anyone interested) to this new platform, which shall be truly exciting.

Agency
National Science Foundation (NSF)
Institute
Division of Computer and Network Systems (CNS)
Application #
0643488
Program Officer
Joseph Lyles
Project Start
Project End
Budget Start
2007-01-01
Budget End
2012-12-31
Support Year
Fiscal Year
2006
Total Cost
$400,000
Indirect Cost
Name
Vanderbilt University Medical Center
Department
Type
DUNS #
City
Nashville
State
TN
Country
United States
Zip Code
37240