Understanding the Power of Pull Based P2P Live Streaming and Doing Even Better

Meng Zhang,Qian Zhang,Lifenng Sun,Shiqiang Yang
2007-01-01
Abstract:The Internet has been witnessing the success of Peer-toPeer (P2P) live streaming during the past three years. A number of commercial P2P streaming software has emerged on Internet (such as PPLive to name a few). Almost all these P2P streaming systems are based on pull-based (or called “data-driven”/“swarming”) protocol [4, 2]. In this type of protocol, the live media content is divided into segments and every node periodically notifies its neighbors of what packets it has. Then each node explicitly requests the segments of interest from its neighbors according to their notification. This protocol is very similar to that of BitTorrent, and the major difference from BitTorrent is that each node only requests the latest generated segments in a much smaller window (called request window). The well-acknowledged advantages of pullbased protocol are its robustness and simplicity. However, we would like to report a graceful characteristic of pull-based protocol that has not been paid enough attention: with appropriate protocol design and parameter settings, the simplest pull-based protocol without any intelligent scheduling and bandwidth measurement is nearly optimal in bandwidth utilization and system throughput, that is, as long as the total upload capacity supply is a little higher than the minimum bandwidth demand, all the peers can obtain nearly 100% playback quality. On the other hand, the most outstanding drawback of pull-based streaming is its tradeoff between control overhead and delay [3]: to minimize the delay, each node notifies its neighbors of packet arrivals as soon as it receives the packet and the neighbor should request the packet immediately after receiving the notification, resulting in a remarkable control overhead; while, to diminish the overhead, a node can wait until dozens of packets arrived and inform these packets to its neighbors once in a packet meanwhile the neighbors can also request a bunch of packets once, which obviously leads to a considerable delay. An interesting question is whether there exists any protocol that can not only hold the near optimality in upload capacity utilization but also achieve both much lower delay and smaller overhead. Fortunately, a simple protocol called hybrid pull-push protocol we proposed has all these features.
What problem does this paper attempt to address?