Small Is Not Always Beautiful

arXiv:0802.1015v1 [cs.NI] 7 Feb 2008 Small Is Not Always Beautiful∗ Paweł Marciniak† Poznan University of Technology, Poland pawel.marciniak@gmail.com Nikitas Liogkas UCLA Los Angeles, CA nikitas@cs.ucla.edu Arnaud Legout I.N.R.I.A. Sophia Antipolis, France arnaud.legout@sophia.inria.fr Eddie Kohler UCLA Los Angeles, CA kohler@cs.ucla.edu Abstract Peer-to-peer content distribution systems have been enjoying great popularity, and are now gain- ing momentum as a means of disseminating video streams over the Internet. In many of these proto- cols, including the popular BitTorrent, content is split into mostly fixed-size pieces, allowing a client to download data from many peers simultaneously. This makes piece size potentially critical for per- formance. However, previous research efforts have largely overlooked this parameter, opting to focus on others instead. This paper presents the results of real experi- ments with varying piece sizes on a controlled Bit- Torrent testbed. We demonstrate that this parame- ter is indeed critical, as it determines the degree of parallelism in the system, and we investigate op- timal piece sizes for distributing small and large content. We also pinpoint a related design trade- off, and explain how BitTorrent’s choice of dividing pieces into subpieces attempts to address it. 1 Introduction Implementation variations and parameter settings can severely affect the service observed by the clients of a peer-to-peer system. A better under- standing of protocol parameters is needed to im- prove and stabilize service, a particularly impor- tant goal for emerging peer-to-peer applications such as streaming video. BitTorrent is widely regarded as one of the most successful swarming protocols, which divide the content to be distributed into distinct pieces and enable peers to share these pieces efficiently. Pre- vious research efforts have focused on the algo- rithms believed to be the major factors behind Bit- Torrent’s good performance, such as the piece and peer selection strategies. However, to the best of our knowledge, no studies have looked into the op- ∗Appeared in IPTPS’2008, Tampa Bay, Florida, USA. †Work done while an intern at INRIA Sophia Antipolis. timal size of content pieces being exchanged among peers. This paper investigates this parameter by running real experiments with varying piece sizes on a controlled testbed, and demonstrates that piece size is critical for performance, as it deter- mines the degree of parallelism available in the sys- tem. Our results also show that, for small-sized con- tent, smaller pieces enable shorter download times, and as a result, BitTorrent’s design choice of fur- ther dividing content pieces into subpieces is un- necessary for such content. We evaluate the over- head that small pieces incur as content size grows and demonstrate a trade-offbetween piece size and available parallelism. We also explain how this trade-offmotivates the use of both pieces and sub- pieces for distributing large content, the common case in BitTorrent swarms. The rest of this paper is organized as follows. Section 2 provides a brief description of the Bit- Torrent protocol, and describes our experimental methodology. Section 3 then presents the results of our experiments with varying piece sizes, while Sec- tion 4 discusses potential reasons behind the poor performance of small pieces when distributing large content. Lastly, Section 5 describes related work and Section 6 concludes. 2 Background and Methodology BitTorrent Overview BitTorrent is a popular peer-to-peer content distribution protocol that has been shown to scale well with the number of par- ticipating clients. Prior to distribution, the content is divided into multiple pieces, while each piece is further divided into multiple subpieces. A metainfo file containing information necessary for initiat- ing the download process is then created by the content provider. This information includes each piece’s SHA-1 hash (used to verify received data) and the address of the tracker, a centralized com- ponent that facilitates peer discovery. In order to join a torrent—the collection of peers participating in the download of a particular content—a client retrieves the metainfo file out of band, usually from a Web site. It then contacts the tracker, which responds with a peer set of randomly selected peers. These might include both seeds, who already have the entire content and are sharing it with others, and leechers, who are still in the pro- cess of downloading. The new client can then start contacting peers in this set and request data. Most clients nowadays implement a rarest-first policy for piece requests: they first ask for the pieces that ex- ist at the smallest number of peers in their peer set. Although peers always exchange just subpieces with each other, they only make data available in the form of complete pieces: after downloading all subpieces of a piece, a peer notifies all peers in its peer set with a have

…(Full text truncated)…

This content is AI-processed based on ArXiv data.