sop

Small Is Not Always Beautiful : 

Small Is Not Always Beautiful Pawel Marciniak1, Nikitas Liogkas2, Arnaud Legout3, Eddie Kohler2 1 Poznan University of Technology, Poland 2 UCLA, Los Angeles, CA USA 3 INRIA, Projet Planète, Sophia Antipolis, France

BitTorrent Overview : 

2 BitTorrent Overview Web server Tracker coolContent.torrent random peer set coolContent.xvid 2

Pieces and Subpieces : 

Pieces and Subpieces Pieces are the unit of replication Subpieces are the atomic unit of transmission 3 coolContent.xvid pieces subpieces

What piece and subpiece size? : 

What piece and subpiece size? Subpiece size Usually hardcoded to 16kB In the following we consider 16kB subpieces Piece size Defined per torrent Usually ranges from 256kB to 2048kB Current practice is to select the smallest piece size so that the torrent file is small enough (100 kB) 4

What is the Impact of Piece Size? : 

What is the Impact of Piece Size? Smaller pieces (larger number of pieces) Faster piece propagation Fewer subpieces to complete and share a piece Better piece diversity Due to rarest first piece selection Faster reaction to data corruption Hashes available for pieces, not subpieces 5

What is the Impact of Piece Size? : 

What is the Impact of Piece Size? But, smaller pieces cause Larger torrent file Larger overhead Higher number of HAVE messages Sent to each neighbor for each received piece Larger BITFIELD messages Exchanged after the initial peer handshake Contain one bit per piece Less efficient pipelining Requesting several subpieces of a piece in parallel 6

Efficiency Trade-off : 

Efficiency Trade-off Smaller piece size Improves piece replication Reduces pipelining efficiency Increases overhead 7 What is the impact of piece size on BitTorrent performance?

Outline : 

8 Outline Background and Motivation Methodology Results Conclusion

Methodology: Experiments : 

9 Methodology: Experiments Using instrumented peers on PlanetLab 1 single initial seed connected for the duration of experiment 40 leechers join at the same time (flash crowd) and leave as soon as they complete the download All peers (seed + leechers) use an instrumented client Seed upload capacity 200 kB/s Leechers’ upload capacities distributed uniformly between 20 kB/s and 200 kB/s

Methodology: Experiments : 

10 Methodology: Experiments Subpiece size always 16kB Ran experiments for all possible combinations of the following content and piece sizes Content sizes 1, 5, 10, 20, 50, and 100 MB Piece sizes 16, 32, 64, 128, 256, 512, 1024, and 2048 kB

Outline : 

11 Outline Background and Motivation Methodology Results Small Content Large Content Conclusion

Small Content : 

Small Content Content size: 5 MB 5 independent runs 12

Small Content: Download Completion Time : 

Small Content: Download Completion Time 16 kB pieces 512 kB pieces 13 Small pieces let peers share pieces sooner

Small Content: Upload Utilization : 

Small Content: Upload Utilization 16 kB pieces 14 512 kB pieces Small pieces result in higher upload utilization

Outline : 

15 Outline Background and Motivation Methodology Results Small Content Large Content Conclusion

Large Content : 

Large Content Content size: 100MB 5 independent runs 16 Small pieces are no longer optimal

Large Content: Communication Overhead : 

Large Content: Communication Overhead HAVE and BITFIELD messages overhead for a 100MB content However same overhead observed for a 5 MB content 17 The increased overhead does not explain the observed trade-off for large contents

Possible Explanations : 

Possible Explanations Small pieces reduce opportunities for subpiece request pipelining (with more severe impact on larger contents) Need high sustained upload utilization Fast piece propagation due to small pieces has less impact at the scale of a large download The observed trade-off does not depends only on the piece size, but also on the content size TCP cannot use the available bandwidth as efficiently with small pieces 18

Outline : 

19 Outline Background and Motivation Methodology Results Conclusion

Conclusion : 

Conclusion For small contents Choose pieces as small as subpieces Piece propagation among peers is the bottleneck For large contents Small pieces are no longer optimal More complex trade-off than for small contents, to be further explored 20

Why Do We Care About Small Contents? : 

Why Do We Care About Small Contents? Web servers (with a client server architecture) do not scale Even the smallest web site may suffer from a dramatic increase in the number of requests Explored how BitTorrent can help Web servers to scale BitTorrent designed to scale Web needs to scale by design (which is not the case today) 21

Small Is Not Always Beautiful : 

Small Is Not Always Beautiful Thank you! Questions? Instrumented client available at: http://www-sop.inria.fr/planete/Arnaud.Legout/Projects/p2p_cd.html Pawel Marciniak, Nikitas Liogkas, Arnaud Legout, Eddie Kohler