With respect to playback quality, if media segments do not arrive in a timely fashion, they have to be skipped at playback, which degrades the playback quality. How do we consistently maintain high playback quality at all participating peers? With respect to the initial buffering delay, which is experienced by a peer when it first joins or switches to a new channel, how do we improve user experience with the shortest initial buffering delay? With respect to server bandwidth costs, how do we minimize such costs by maximizing bandwidth contribution from participating peers? Last but not the least important, how do we design a system that scales well to accommodate a large flash crowd and a high degree of peer dynamics?

We believe that these performance metrics should be given priority when evaluating a protocol that is designed specifically for peer-to-peer live streaming. The playback quality and the initial buffering delay matter most to the user experience, which determines the level of user satisfaction. The server bandwidth costs, however, matter most to the companies in operation, as they directly determine most of the ongoing operational costs.

While it may be possible to implement a protocol design in real-world systems without “paper and pencil” analytical studies, we believe in the values of such analytical studies of large-scale P2P streaming systems. Analytical studies help us to understand the fundamentals with mathematical rigor, rather than by resorting to intuition or trial-and-error. Analytical studies also help us to understand properties that are hard to evaluate with real-world studies without risks, such as the ability to scale well to a large number of peers with good performance.

At first glance, developing a theoretical framework that helps protocol designers to understand all of these performance metrics may appear too good to be true. Most existing analytical studies therefore focused on only one or two performance metrics instead. For instance, Y. Liu [ACM Multimedia 2007] provided a centralized streaming algorithm that achieves minimum delay. Massoulie et al. [INFOCOM 2007] proposed a streaming algorithm that approaches maximum streaming rate. Bonald et al. [SIGMETRICS 2008] identified several streaming algorithms that achieve near-optimal streaming rate and delay.

In contrast, in our recent research paper to appear in ACM Multimedia 2008, we seek to mathematically analyze and understand a new family of streaming protocols, simultaneously considering all these performance metrics. Our rescue comes from the use of network coding, which not only eliminates some of the mathematical difficulties associated with previous theoretical models, but also leads to simple and practical streaming protocols. This simplification allows us to take into account all of the important performance metrics, even under a more realistic system model.

We identify several design principles for streaming systems with network coding and show that any protocol following our design principles is sufficient to achieve provably good overall performance in realistic settings. In particular, we have provided sufficient conditions on the required server bandwidth costs to ensure smooth playback under peer dynamics, and with short initial buffering delays. A closer look at these conditions further suggests that our design principles are able to achieve near-optimal bandwidth utilization during flash crowds and to handle severe peer dynamics with ease.

Our design principles can be readily implemented in practice with low overhead. In fact, our previous work on R² is a particular example of such implementations. Through such an example of a practical protocol design, combined with our theoretical framework of fundamental properties, we have provided a striking demonstration of an effective streaming protocol design with network coding. We expect to see real-world implementations of our design principles in the near future. Clearly, the design principles identified in our work might not be unique, and our analytical studies are concerned with a family of such protocols, focusing on important elements, rather than protocol details. We believe our theoretical framework will shed considerable light into the journey towards the best possible protocols in P2P streaming systems.

A slide presentation on this project is available for further reading, in both Adobe Flash and Adobe PDF formats.

Previous research in the literature has focused on constructing high-quality peer-level topologies. Tree-based per-slice push, such as Chunkyspread [ICNP 2006], may shorten the delays between live events and their playback time, but they suffer overhead of maintaining trees and unavoidable implementation complexity. Mesh-based per-segment pull, such as CoolStreaming [INFOCOM 2005], may be simple to implement and offer better resilience to frequent peer departures, but the overhead of requests and buffer availability exchanges is quite significant, and the delays between live events and their playback time may be much longer.

With the recent surge of interest in practical network coding, it is interesting to see if network coding would be helpful in delivering performance gains in P2P streaming, with respect to three important performance metrics: (1) resilience to peer dynamics; (2) the utilization of scarce server bandwidth; and (3) the time required for initial buffering delays when switching to new channels.

In the R² project, our objective is to design, analyze, and implement a new peer-to-peer live streaming protocol, that hopefully combines the benefits of tree-based per-slice push and mesh-based per-segment pull, but without much complexity in its implementation. In the first phase, we are interested in weather network coding can offer any tangible benefits in P2P streaming, without revising the traditional mesh-based per-segment pull protocol. We have performed an experimental evaluation of the benefits of network coding over a vanilla pull-based streaming protocol, with the conclusion that there exist some benefits offered by network coding, but they are nothing to write home about. Our papers summarizing results in this step have been published in IEEE Transactions on Multimedia (PDF), and IEEE INFOCOM 2007 (PDF).

In the second phase, we are naturally curious about the possibility of designing a much improved protocol that is tailored to take full advantage of network coding. Towards this objective, we have designed R² (Random push with Random network coding), and believed that R² enjoys the advantages of both push-based and pull-based streaming protocols. To show its practicality and effectiveness, our experimental results are based on a complete implementation of R² with emulated peers on a server cluster, coupled with an optimized library of random network coding tuned for performance. Our paper on R² is to appear in the December 2007 issue of the IEEE Journal on Selected Areas in Communications, Special Issue on Advances in P2P Streaming.

If you are still reading, you may also be interested in our presentation slides dedicated to the R² project, available as an Adobe PDF document.

The objective of our second milestone in the Magellan project was precisely to see if it is possible to select “good” active peers with a satisfactory level of available bandwidth. In our recent paper to appear in IEEE Journal on Selected Areas in Communications (JSAC), Special Issue on Advances in Peer-to-Peer Streaming Systems, it is our hope that some kind of imprecise and approximate knowledge of available TCP bandwidth between two peers can be derived with minimum active probing, or better yet, no probing at all.

To hopefully achieve this objective, we have taken the time to conduct an exhaustive investigation with respect to statistical properties of TCP throughput values of streaming flows among peers, using more than 230 GB of UUSee traces and 370 million live streaming flows over a four-month period of time (November 2006 to February 2007). In particular, we have investigated TCP throughput distributions in various peer ISP/area/type categories, statistically tested the correlation between TCP throughput and its application-layer factors by modeling them into regression models, and studied the evolutionary properties of TCP throughput values over the trace period.

We have made quite a number of interesting observations. First, we have discovered that the ISPs that peers belong to are highly significant in determining inter-peer bandwidth, even more important than their geographic locations. Second, we have also found excellent linear correlations between the availability of peer last-mile bandwidth and inter-peer bandwidth within the same ISP and between a subset of ISPs, with different linear regression coefficients for different pairs of ISPs. Finally, we have observed daily evolutionary patterns of inter-peer bandwidth.

Based on these insights, we have designed a “throughput expectation index” that makes it possible to select high-bandwidth peers without performing any measurements. This index is computed based on the ISPs that peers belong to, a table of linear regression coefficients for different pairs of ISPs, and the time of the day. All linear regression coefficients are derived off-line using historical measurement traces. We have cross-checked the set of peers selected using such an index against the set of real-world top-ranked peers in the traces from a different time period, and discovered a surprisingly good match between the two.

Interested readers are referred to the web site of the first author, Chuan Wu, for more details.

We expect many more papers in the near-term future taking the same research metholodogy: treating commercial applications as a “blackbox,” and perform extensive measurements by monitoring their traffic characteristics. In fact, Skype has already received a similar level of scrutiny with such a research approach, and if we were allowed a crystal ball (as of early July 2007), we would predict papers on Youtube, Joost, Zattoo, and perhaps even the iPhone when it uses EDGE (or, later, 3G HSDPA) — if we were allowed sufficient resources in addition to that crystal ball before it’s too late, perhaps we would launch a few projects on these ourselves!

As a commonly adopted design for most of the recent successful P2P live streaming applications, blocks of live media contents are being delivered over a mesh overlay topology, featuring a BitTorrent-like reciprocal exchanges of useful content blocks among multiple peers. It is also interesting to observe that most current-generation P2P streaming applications employ relatively simple peer selection and mesh construction protocol designs. They typically use central tracking servers to gain initial knowledge of existing peers in the channels, and periodically exchange peer lists among peers themselves. As mesh-based streaming topologies play an important role towards the commercial success of P2P streaming, it is critical to acquire a thorough and in-depth understanding of the topological characteristics of these large-scale P2P meshes. It would be an intriguing research challenge to investigate how the constructed topologies actually behave in practice, dynamically evolve over time, and react to extreme scenarios such as huge flash crowds.

There has been quite a number of existing papers on exploring P2P topologies of P2P decentralized search (such as Gnutella and its variants). The problem is that such P2P decentralized search applications are quite different from modern P2P streaming applications based on block exchanges and long-lived meshes, leading to possibly different topological properties. As a matter of fact, topological characteristics in block-exchanging P2P streaming applications may well be different from their file-sharing predecessors (such as BitTorrent), due to its biased peer selection protocol design towards the timely delivery of media content.

The bad news is, there are only so much one can do with a measurement-based study treating the application as a “blackbox.” If we wish to gain in-depth insights and a complete understanding of P2P streaming characteristics, we need to collaborate with commercial solution providers and add instrumentation facilities into the product itself! With the Magellan project, we wish to achieve exactly that, by collaborating with UUSee Inc., one of the leading P2P live streaming solution providers in mainland China, supported by reputable venture capital firms in North America.

Our ICDCS 2007 paper, that we just presented in Toronto, Canada, represents the first milestone of Magellan, with our observations from exploring graph theoretical properties in actually formed live streaming topologies. All of our observations are based on over 120 GB of traces and 10 million unique IP addresses that we have collected over a two-month period (September to October 2006) using dedicated trace servers, and instrumented client code to proactively submit reports to trace servers. With emphasis on their evolutionary nature over a long period of time, we have utilized and extended classical graph measurement metrics — such as the degree, clustering coefficient, and reciprocity — to investigate various aspects of the streaming topologies at different times of the day, in different days in a week, and in flash crowd scenarios. We also compare our discoveries with existing results related to file sharing applications, with further insights unique to P2P streaming.

We have brought several insights to the spotlight in this paper. First, we show that the current-generation P2P streaming platform scales very well, even in large flash crowd scenarios. Second, we observe that the degree distribution towards active neighbors in a peer-to-peer mesh does not follow the power-law distribution. Third, we argue that ISP-based clusters are formed from the dynamic peer selection process, carried out during live streaming sessions, even with exceedingly simple algorithms of peer selection. Finally, we believe that mesh P2P topologies do not resemble a tree in reality, and that the level of reciprocity among peers is high, which plays a key role towards the effectiveness of utilizing peer upload bandwidth.

If you are still reading, you may also be interested in our presentation slides dedicated to this work, available as either an Adobe PDF document or an Flash slide show.

Update on September 12, 2007: I just noticed three papers on YouTube trace analysis in IMC 2007 (Internet Measurement Conference). I guess my “crystal ball” works quite accurately when I wrote this short essay back in July: would Joost be the next one to analyze?

The lack of commercial use of network coding in any P2P applications may be due to the high coding complexity of random linear codes, as the number of blocks to code scales up. As random linear nodes are used, or implicitly assumed, in almost all practical proposals of using network coding in recent papers, we thought it would be a good idea to see how much coding — what may be the typical block length — that modern desktop processors are able to handle, by carefully designing a performanced-tuned implementation of random network coding. Ideally, such an implementation would use the best development tools available today, and take advantage of all available hardware support from modern processors. We thought it would be an important and challenging step towards commercial use of network coding, especially in P2P applications that use modern processors.

Our recent paper titled “Parallelized Progressive Network Coding With Hardware Acceleration,” to appear in the Proceedings of IEEE IWQoS 2007 (held in Chicago, from June 21-22, 2007), has presented results from such an implementation that we have completed. In this implementation, we have used a combination of three tricks: progressive decoding using Gauss-Jordan elimination so that blocks can be decoded on-the-fly as they are received, a loop-based implementation of GF(256) multiplication that takes advantage of SIMD vector instructions in modern processors, and a threaded implementation that aggressively utilizes multi-core CPUs and their L2 caches. The result has been a network coding implementation written in C++, with a strong focus on multi-core performance, optimized for Intel, AMD, and PowerPC processor families (AltiVec on PowerPC and SSE2 on x86). In addition, our code takes care of platform-specific details (e.g., byte-aligned memory allocation for SIMD) and readily compiles and runs on Microsoft Windows, Mac OS X, and Linux.

This graph shows the decoding performance of our implementation (where n is the number of blocks to code):

This table shows the performance of both encoding and decoding on various processors and operating systems:

A slide presentation of this work is available as an Adobe PDF document or a Flash slide show.

This work has brought us some good news. We show that for practical block sizes and block lengths (such as 128 blocks of 4 KB each), it is practical to perform network coding on-the-fly in P2P applications, with little computational overhead (since most of the time required for coding overlaps with the time for transmitting or receiving coded data). If the network is the bottleneck, the load on processors should be light, as the coding performance we have shown is far better than typical DSL bandwidth (at most 500 KB per second).

As almost everyone else in academia, I tend to do three things on conference trips: checking emails, browsing the web, and doing presentations. Checking emails and browsing the web seem to be as intuitive as it can get with the new multi-touch UI on the iPhone, not to mention the nice-to-have features of making regular phone calls and taking random snapshot travel pictures. Most conferences these days have WiFi available on-site, and the iPhone can take advantage of that as well as any laptops.

Though not mentioned in its set of core features, I can see that, possibly with a few accessories, the iPhone is readily capable of doing conference presentations. Though the current iPods can be used to power presentations, they involve tweaks such as saving the slides as JPEG or Quicktime movies. In contrast, the OS X core running in the iPhone should have no problems running a lightweight Keynote or PowerPoint, and the MacWorld keynote address was already using its 30-pin iPod connector to send digital video out of the device, making it a natural choice of connecting to a digital projector with some kind of a video-out accessory. The iPhone supports Bluetooth, making it easy to find a Bluetooth clicker to control the presentation.

But how about the tons of emails that need replies in a hurry? I can imagine a foldable keyboard (like the stowaway ones available from iGo for Palm) produced as an accessory and connected to the iPhone via Bluetooth, making it a time saver to type longer emails on the device. Needs more storage space? iPod already has a iPod dock connector to firewire cable available, and it would not be a pipe dream to connect the iPhone to a portable firewire hard drive, again via the 30-pin iPod connector. At this point, if the iPhone would takeoff and evolve into an ecosystem as the Apple stock price suggested, in a year or two, the iPhone may be the only electronic device that I carry when traveling.

But that may not be the most exciting time saver — when I think of the possibility of using this device to handle all pending emails of the day while offline on the subway, on my commute to and from downtown, and then use WiFi to send them out when I am out of the subway. Though existing devices can be used for all these, the experience may not be as trouble-free and seamless as I liked. All considered, the iPhone may make it more productive to work, rather than just yet another gadget one plays with.

Update on October 2, 2007: With the recently released firmware 1.1.1, iPhone supports TV out to send video signals to external displays, using an Apple composite AV cable or an Apple component AV cable. I guess the day of traveling light and delivering presentations with an iPhone is not too far away.

In a nutshell, the research objective of the Agilos project was to assist complex applications to make informed decisions regarding the timing and scale of QoS adaptations. The project implementation was performed in Windows NT 4.0, compiled with Visual C++ 4.2 (and later 6.0), and supported by ORBacus 2.1 (and later 3.0) as its CORBA framework. In its final revision around early 2000, it involved approximately 60,000 lines of code (LOC), developed across a distributed Windows-based platform. This work has led to the IEEE Communications Society Leonard G. Abraham Prize Paper Award in the Field of Communications Systems in 2000.

We have just launched a dedicated web page for the Agilos project, as a special way to celebrate the ten year anniversary of its launch in late 1996, in a mailroom converted office facing the north of DCL, 1304 W. Springfield Avenue, Urbana, Illinois. The initial code development was performed in the summer of 1996, using a (then brand-new) Gateway PC powered by Pentium 200MHz MMX, 64MB of memory, as well as 1GB of disk space. At the time, it had one of the first host names in the MONET research group: cairo.cs.uiuc.edu.

The Gateway PC has been actively used to serve the official web site of the MONET research group till 2004. Unfortunately, the original project web page for the Agilos project has not been linked from the current MONET web site (and perhaps due to be phased out soon), making our ten-year anniversary web site more important.

I wholeheartedly agree that travel diminishes productivity. I felt that when I travel, I could not concentrate on one thing at a time. For example, rather than just tuning into the talks, I switch contexts more often, especially if the talks are not very engaging (a topic of its own). I was trying to learn from and enjoy the conference, at the same time of keeping an usual day-to-day workload — and this is hard to achieve. Most people around in conferences seem to be doing the same thing: juggling between emails and the conference itself. So much so that the provisioning of wireless Internet access at a technical session could be treated as a bug, rather than a feature. Keshav was also precise in pointing out that work does not go away after the trip, it just needs more time to catch up with.

On the other hand, it just turns out that — unlike teenagers — academics are not too keen on communicating over the Internet using more recent technologies than email messages. Very few frequently log into instant messaging systems (such as MSN, google talk, iChat AV, or Skype), or engage in a serious research discussion when they do. It is unlikely that a conference TPC meeting allows TPC members to tune in over Skype or iChat. Very few have research wikis or blogs. I cannot think of a web-based discussion forum to carry out academic discussions, or simply to publish CFPs. Well, it is probably because most are busy traveling — and working on the actual research.

If we progress beyond emails for research interactions, then at the very least TPC meetings can be held over the Internet, saving a trip or two every year! Is immature technology the root of the problem, when video conferencing has to go through insufficient bandwidth, NATs and firewalls? Or should we be more adventurous and use networks to do research in networking, distributed systems to do research in distributed systems, and multimedia to do research in multimedia?

During the years of research since I was a graduate student at UIUC, I have always had questions on the impact of academic papers in the real world, which seems to be dominated by Microsoft (with its proprietary Windows Media Video), RealNetworks, and Apple Quicktime. The myriad of protocols (e.g., RTP, RTSP, RTCP, SIP, H.323) and codecs (e.g., MPEG2, MPEG4, H.264) seems to be dazzling, but I have not seen many promising academic proposals been deployed to real-world use, such as layered coding and multiple description coding. For example, papers as recent as SIGCOMM 2006 (titled Enabling Contribution Awareness in an Overlay Broadcasting System) still propose to use layered MDC to provide differentiated qualities to different peers in overlay broadcasting, while successful codecs of layered coding and MDC — or at least open source ones — are nowhere in sight.

No all academic proposals are shelved or archived, of course. I have had the deepest respect for at least two pieces of work from academia. First, Professor Henning Schulzrinne’s work on RTP, RTSP and SIP. They have not only become industry standards, adopted by the Apple Darwin Streaming Server (which is open source), but also embraced the design principles of simplicity, which I cherish.

Second, Professor Larry Rowe’s recent work on lecture webcasting has captured my interests about a year ago. Professor Rowe has had a technical report documenting his experiences webcasting NOSSDAV 2005 presentations, with both positive and negative lessons learned. Since then, he has had even more engaging stories (in the form similar to modern blogs but presented as static web pages) about ongoing challenges with Quicktime upgrades and video qualities at a high bit rate (1200 Kbps).

Professor Rowe preferred the Darwin Quicktime streaming server since it is open source and uses open standards such as RTP and RTSP, but then believed that even the Quicktime streaming technology was still immature to be used for a large digital library. I enjoyed reading the paper since I think it was impartial and involved a large amount of work towards bridging academia and practice (at least bringing conference talks to the web!), but unfortunately the paper was not published at any prestigious conferences or journals.

I am very curious to see if, in the next five years, I could stream a large number of archived webcasts of lectures and talks to my office desktop. Youtube’s success has made a point that even poor-quality ones with out-of-sync audio may be better than nothing. And if lecture webcasts do become a reality, would that be the result of the industrial push of trendy technologies — such as the iTunes U or video podcasts, or the outcome of papers in leading conferences and transactions?

Though that may be the official line, I somehow feel that the weblog section may eventually just become my personal blog dedicated to research, while the static web pages would include the list of publications for download. We will see how it works out, but at least I realized one thing a long time ago: there is no way a web site can be perfect. I would rather be in pursuit of perfection one post (or one paper) at a time.