Скачать презентацию Lava A Reality Check of Network Coding in Скачать презентацию Lava A Reality Check of Network Coding in

675e35d88fa8c1577eb6b6de27010cd3.ppt

  • Количество слайдов: 28

Lava: A Reality Check of Network Coding in Peer-to-Peer Live Streaming Mea Wang, Baochun 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 1

Outline n n Introduction Lava Experimental results Conclusion 2 Outline n n Introduction Lava Experimental results Conclusion 2

Question? n How helpful is networking coding in peer-topeer streaming? q q Network coding Question? n How helpful is networking coding in peer-topeer streaming? q q Network coding Realistic testbed: Lava n q With actual network traffic P 2 P streaming protocol: Vanilla n n Similar to Cool. Streaming, PPLive… A data-driven pull-based peer-to-peer live streaming protocol. 3

Network Coding n n n Originally proposed in information theory Theoretically improve network throughput Network Coding n n n Originally proposed in information theory Theoretically improve network throughput of multicast sessions in directed acyclic graphs, achieving their cut-set capacity bounds A promising information theoretic approaches to improve performance in peer-to-peer and wireless networks 左起:楊偉豪教授、李碩彥教授和蔡寧博士 4

Network Coding DEFINITION Network coding is a particular in-network data processing technique that exploits Network Coding 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. n 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. n [2] S. Y. R. Li, R. W. Yeung, and N. Cai, “Linear Network Coding, ” IEEE Transactions on Information Theory, vol. 49, p. 371, 2003. n Improves the performance in data broadcasting Most suitable setting: all to all communications n 5

Network Coding TERMINOLOGY n n Communication network = finite directed graph Acyclic communication network Network Coding TERMINOLOGY n n 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) q W X has capacity equal to 2 6

The example (I) n Without network coding q q Simple store and forward Multicast The example (I) n Without network coding q q Simple store and forward Multicast rate of 1. 5 bits per time unit 7

The example (II) n With network coding q q q XOR is one of The example (II) n With network coding q q q XOR is one of the simplest form of data coding Multicast rate of 2 bits per time unit Disadvantages n Coding/decoding scheme has to be agreed upon beforehand 8

X 1+X 2 Figure 2: (Butterfly Network) S 1 and S 2 multicast to X 1+X 2 Figure 2: (Butterfly Network) S 1 and S 2 multicast to both R 1 and R 2. 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). 9

Lava n Experimental testbed of network coding in peer-topeer live streaming q q q Lava n Experimental testbed of network coding in peer-topeer live streaming q q q Lava: Architecture Lava: Steaming with Vanilla Lava: Progressive network coding Lava 10

Lava: Architecture n A cluster of 44 high-performance servers q Interconnected by Gigabit Ethernet Lava: Architecture n A cluster of 44 high-performance servers q Interconnected by Gigabit Ethernet q Emulating upload bandwidth capacities on each peer at the application layer 11

Fig. 1. The architecture of a bandwidth-emulated peer in Lava. 12 Fig. 1. The architecture of a bandwidth-emulated peer in Lava. 12

Lava: Streaming with Vanilla n Vanilla: a standard peer-to-peer streaming protocol q Data-driven pull-based Lava: Streaming with Vanilla n Vanilla: a standard peer-to-peer streaming protocol q Data-driven pull-based peer-to-peer protocol Fig. 2. The playback buffer in Vanilla. 13

Lava n 2 threads q network thread n n n q (1) maintain all Lava n 2 threads q network thread n n n q (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 n n (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. 14

Lava: Progressive Network Coding • Randomize network coding : • downstream peer p • Lava: Progressive Network Coding • Randomize network coding : • downstream peer p • coded blocks x=[x 1, x 2, …, xn] • n x n matrix A • a segment Is divided into n blocks • randomly chooses a set of coding coefficients 15

Lava: Progressive network coding n Progressive decoding q q Using Gauss-Jordan elimination instead of Lava: Progressive network coding n Progressive decoding q q Using Gauss-Jordan elimination instead 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) 16

Experiment n Experiment setting q q q Each segment is 1 second of playback Experiment n Experiment setting q q q 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 network coding with live streams with an average duration of 125 seconds 17

Experimental Result Block Size / Block Number • Decoding BW decreases faster than the 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 (100 k. B – 8 MB per second) 18

Experimental Result n With / without network coding q Transmission time: the time required Experimental Result n With / without network coding q Transmission time: the time required to completely receive a segment, and includes the encoding time on the source. q Recovery time: the time spent in the decoding process to recover the original blocks after all blocks have been received. • The computational overhead of Gauss. Jordan elimination. • Decoding times are almost completely concealed within the time required to receive the segment. 19

Experimental Result n Tuning density and aggressiveness : q Density: the ratio of none-zero Experimental Result n Tuning density and aggressiveness : q Density: the ratio of none-zero entries in the set of coding coefficients d(0

Experimental Result n playback quality q q Playback skips: a segment is not successfully Experimental Result n playback quality q q 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) • 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. 21

Experimental Result n 3 different streaming rate: q q q 64 KBps : Supply Experimental Result n 3 different streaming rate: q q q 64 KBps : Supply > demand 73 KBps : Supply ~= demand 78 KBps : Supply < demand • 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. 22

Experimental Result n Balance between bandwidth supply and demand The buffering levels with network Experimental Result n Balance between bandwidth supply and demand The buffering levels with network coding increases slowly at the beginning of a session, 23 due to processing overhead of coded blocks. (increasing initial peers)

Experimental Result n Scalability (Add one peer on each server at a time) Though Experimental Result n Scalability (Add one peer on each server at a time) Though network coding doesn’t improve the playback quality in static sessions, it reduces 24 the amount of redundancy with respect to bandwidth usage.

Peer Dynamic n Interarrival times of peer join events and peer lifetimes are modeled Peer Dynamic n Interarrival times of peer join events and peer lifetimes are modeled as a Weibull distribution (k, λ), q q with a PDF Shape parameter k, scale parameter λ Without initial skips With 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. 25

Peer Dynamic • Although Vanilla enjoys a better overall playback, its buffering level fluctuates 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. 26

Conclusion n n We have implemented a pull-based peer-topeer live streaming protocol in our Conclusion n n We have implemented a pull-based peer-topeer 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. 27

References n n n n [1] R. Ahlswede, N. Cai, S. R. Li, and References n n n n [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 (IWQo. S 2006), 2006, pp. 274– 278. Mea Wang, Baochun Li. “R 2: 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. 28