280 likes | 425 Vues
Lava: A Reality Check of Network Coding in Peer-to-Peer Live Streaming. Mea Wang, Baochun Li Department of Electrical and Computer Engineering University of Toronto IEEE INFOCOM 2007. Outline. Introduction Lava Experimental results Conclusion. Question?.
E N D
Lava: A Reality Check of Network Coding in Peer-to-Peer Live Streaming Mea Wang, Baochun Li Department of Electrical and Computer Engineering University of Toronto IEEE INFOCOM 2007
Outline • Introduction • Lava • Experimental results • Conclusion
Question? • How helpful is networking coding in peer-to-peer streaming? • Network coding • Realistic testbed: Lava • With actual network traffic • P2P streaming protocol: Vanilla • Similar to CoolStreaming, PPLive… • A data-driven pull-based peer-to-peer live streaming protocol.
Network Coding Originally proposed in information theory Theoretically improve network throughput of multicast sessions in directed acyclic graphs, achieving their cut-set capacitybounds A promising information theoretic approaches to improve performance in peer-to-peer and wireless networks 左起:楊偉豪教授、李碩彥教授和蔡寧博士
Network Coding • Pioneering work: [1] R. Ahlswede, N. Cai, S.-Y. R. Li, and R.W. Yeung, “Network information flow,” IEEE Trans. on Information Theory, vol. 46, no. 4, July 2000. • [2] S. Y. R. Li, R. W. Yeung, and N. Cai, “Linear Network Coding,” IEEE Transactions on Information Theory, vol. 49, p. 371, 2003. • Improves the performance in data broadcasting • Most suitable setting: all to all communications DEFINITION Network coding is a particular in-network data processing technique that exploits the characteristics of the wireless medium (in particular, the broadcast communication channel) in order to increase the capacity or the throughput of the network.
Network Coding TERMINOLOGY • Communication network = finite directed graph • Acyclic communication network = network without any direct cyclic • Source node = node without any incoming edges (square) • Channel = noiseless communication link for the transmission of a data unit per unit time (edge) • W X has capacity equal to 2
The example (I) • Without network coding • Simple store and forward • Multicast rate of 1.5 bits per time unit
The example (II) • With network coding • XOR is one of the simplest form of data coding • Multicast rate of 2 bits per time unit • Disadvantages • Coding/decoding scheme has to be agreed upon beforehand
X1+X2 X1+X2 Figure 2: (Butterfly Network)S1 and S2 multicast to both R1 and R2. All links have capacity 1. With network coding (by xoring the data on link CD), the achievable rates are 2 for each source, the same as if every destination were using the network for its sole use. Without network coding, the achievable rates are less (for example if both rates are equal, the maximum rate is 1.5).
Lava • Experimental testbed of network coding in peer-to-peer live streaming • Lava: Architecture • Lava: Steaming with Vanilla • Lava: Progressive network coding
Lava: Architecture • A cluster of 44 high-performance servers • Interconnected by Gigabit Ethernet • Emulating upload bandwidth capacities on each peer at the application layer
Fig. 1. The architecture of a bandwidth-emulated peer in Lava.
Lava: Streaming with Vanilla Fig. 2. The playback buffer in Vanilla. • Vanilla: a standard peer-to-peer streaming protocol • Data-driven pull-based peer-to-peer protocol
Lava • 2 threads • network thread • (1) maintain all the incoming and outgoing TCP connections and UDP traffic • (2) generate data sources for a streaming session, and manage the session • (3) emulate the upload and download capacities on each peer • algorithm thread: implements the actual algorithms and protocols • (1) processes head-of-line messages from incoming connections, and send produced streaming segments from the algorithm to outgoing connections • (2) maintain a local buffer that store data segments that have been received so far, and emulate the playback of each segment • (3) Support multiple event-driven asynchronous timeout mechanisms with different timeout periods • (4) implement Vanilla Fig. 3. The architectural design of network coding in Lava.
Lava: Progressive Network Coding • Randomize network coding : • downstream peer p • coded blocks x=[x1, x2,…, xn] • n x n matrix A • a segment Is divided into n blocks • randomly chooses a set of coding coefficients
Lava: Progressive network coding • Progressive decoding • Using Gauss-Jordan eliminationinstead of Gaussian elimination • It can start to decode as soon as the first coded block is received • The decoding time overlaps with the time required to receive the original block • Reduced row-echelon form (RREF)
Experiment • Experiment setting • Each segment is 1 second of playback • The playback buffer to contain 30 segments • The low buffering watermarks are 10 seconds • The standard buffering watermarks 20 seconds • The initial buffering delay is set to 20 seconds • We test networkcoding with live streams with an average duration of 125seconds
Experimental Result Block Size / Block Number • Decoding BW decreases faster than the encoding BW as the number of blocks increases. • Make decoding process the bottleneck of network coding in the streaming process. • Support a wide range of streaming rates (100kB – 8MB per second)
Experimental Result • The computational overhead of Gauss-Jordan elimination. • Decoding times are almost completely concealed within the time required to receive the segment. • With / without network coding • Transmission time: the time required to completely receive a segment, and includes the encoding time on the source. • Recovery time: the time spent in the decoding process to recover the original blocks after all blocks have been received.
Experimental Result • Tuning density and aggressiveness : • Density: the ratio of none-zero entries in the set of coding coefficients d(0<d<1) • The lower coding density leads to a smaller number of blocks being coded, which reduces the coding complexity. • Aggressiveness: the peer starts producing and serving new coded blocks after a*n (0<a<1) coded blocks has been received. • A lower aggressiveness setting leads to more “supply “ of coded blocks.
Experimental Result • The best playback is achieved when both aggressiveness and density are 100%. • For typical streaming rates (e.g., 64 KB per second), the aggressiveness and density settings do not have significant effect on the playback quality and bandwidth redundancy. • playback quality • Playback skips: a segment is not successfully received in time, skip it. • Bandwidth redundancy: the percentage of discarded blocks (due to linear dependence or obsolescence)
Experimental Result • Better when a closes match between supply and demand. • Peers may be served by multiple randomly selected upstream peers that have coded blocks of the requested segment. • Network coding makes it possible to perform data streaming with finer granularity, so that the impact of a bandwidth supply shortage is significantly less severe. • 3 different streaming rate: • 64KBps : Supply > demand • 73KBps : Supply ~= demand • 78KBps : Supply < demand
Experimental Result The buffering levels with network coding increases slowly at the beginning of a session, due to processing overhead of coded blocks. (increasing initial peers) Balance between bandwidth supply and demand
Experimental Result Though network coding doesn’t improve the playback quality in static sessions, it reduces the amount of redundancy with respect to bandwidth usage. Scalability (Add one peer on each server at a time)
Peer Dynamic Without initial skips • Slow increase of buffering levels at the beginning of a session • Better performance with network coding, especially when peers depart at a faster rate. With initial skips • Interarrival times of peer join events and peer lifetimes are modeled as a Weibull distribution (k,λ), • with a PDF • Shape parameter k, scale parameter λ
Peer Dynamic • Although Vanilla enjoys a better overall playback, its buffering level fluctuates significantly. • More stable and better performance in higher churn rate. • Despite initial skips, network coding demonstrates its resilience to network dynamics, without incurring any additional bandwidth.
Conclusion • We have implemented a pull-based peer-to-peer live streaming protocol in our testbed, Lava. • Network coding makes it possible to perform streaming with a finer granularity, which reduces the redundancy of bandwidth usage, improves resilience to network dynamics.
References • [1] R. Ahlswede, N. Cai, S. R. Li, and R. W. Yeung, “Network Information Flow,” IEEE Transactions on Information Theory, vol. 46, no. 4, pp. 1204–1216, July 2000. • [2] S. Y. R. Li, R. W. Yeung, and N. Cai, “Linear Network Coding,” IEEE Transactions on Information Theory, vol. 49, p. 371, 2003. • [5] C. Gkantsidis and P. Rodriguez, “Network Coding for Large Scale Content Distribution,” Proc. of IEEE INFOCOM 2005. • [7] X. Zhang, J. Liu, B. Li, and T.-S. P. Yum, “Data-Driven Overlay Streaming: Design, Implementation, and Experience,” Proc. of IEEE INFOCOM 2005. • [13] Mea Wang and Baochun Li, “How Practical is Network Coding?” Proc. of the Fourteenth IEEE International Workshop on Quality of Service (IWQoS 2006), 2006, pp. 274–278. • Mea Wang, Baochun Li. “R2: Random Push with Random Network Coding in Live Peer-to-Peer Streaming,” IEEE Journal on Selected Areas in Communications, Special Issue on Advances in Peer-to-Peer Streaming Systems, vol. 25, no. 9, pp. 1655-1666, December 2007. • Mea Wang, Baochun Li. “Network Coding in Live Peer-to-Peer Streaming,” IEEE Transactions on Multimedia, Special Issue on Content Storage and Delivery in Peer-to-Peer Networks, vol. 9, no. 8, pp. 1554-1567, December 2007.