UNCORRECTED PROOF AUTHOR'S PROOF. Keywords Energy-efficiency. Proxy. Peer-to-peer. BitTorrent. Broadband router. Mobile.

Transcription

1 1 3 2 DOI /s Modeling resource constrained BitTorrent proxies for energy 5 efficient mobile content sharing 6 Imre Kelényi & Jukka K. Nurminen & Ákos Ludányi & 7 Tamás Lukovszki Q2 Q1 8 Received: 1 November 2010 / Accepted: 18 August # Springer Science+Business Media, LLC Abstract In this paper we present a solution that makes 12 BitTorrent content transfer for mobile device more energy 13 efficient. The main idea of the research is that instead of 14 downloading the content via BitTorrent directly to the 15 mobile phone, an intermediate proxy is used which sends 16 the data to the phone in high speed bursts. This results in 17 smaller energy footprint compared with regular BitTorrent 18 data transfer. Furthermore, we focus on how the proxy can 19 be hosted on memory limited broadband routers which are 20 available in almost every home. We define an analytical 21 model which can be used to analyze the memory allocation 22 strategies of the proxy peers and predict how proxy peers 23 influence the P2P community performance. We verify our 24 model via simulations. We also present measurement results 25 with real life torrents using our prototype system running 26 on home routers and Symbian based mobile phones. This work is supported by the New Hungary Development Plan (Project ID: TÁMOP-4.2.1/B-09/1/KMR and TAMOP 4.2.1/B-09/1/KMR ). I. Kelényi (*) : Á. Ludányi Budapest University of Technology, Budapest, Hungary imre.kelenyi@aut.bme.hu Á. Ludányi llutyo@gmail.com J. K. Nurminen Nokia Research Center, Helsinki, Finland jukka.k.nurminen@nokia.com T. Lukovszki Eötvös Loránd University, Budapest, Hungary lukovszki@inf.elte.hu Keywords Energy-efficiency. Proxy. Peer-to-peer. BitTorrent. Broadband router. Mobile 1 Introduction Running BitTorrent on mobile phones is clearly interesting for users as evidenced by close to downloads in year 2009 of SymTorrent, the native BitTorrent client for Symbian based mobile phones [1]. It shows that the resources of modern mobile phones are adequate to let them participate in P2P communities. At the same time, experience with SymTorrent highlights that energy consumption is one of the main difficulties for P2P usage on handheld devices. One approach to increase the energy-efficiency of content downloading is to improve the speed with which the mobile device receives the content. Earlier measurement studies show that higher bitrate improves the energyefficiency of file transfer [2, 3]. The speed of BitTorrent download can vary considerably and is often well below the capacity of the wireless interface. A recipe for energy saving is thus to increase the download speed to fill the whole capacity of the wireless channel. In our earlier work on energy-efficient BitTorrent, we have taken advantage of this phenomenon and shaped the traffic arriving to the mobile device to increase the bitrate it experiences. The essence of the work has been to alternate between idle time intervals when the mobile can enter power saving state and active intervals when the bitrate is as high as possible. In one case, the mobile peers negotiated a transfer schedule with regular peers [4]. The system guaranteed that during active periods the available peers would dedicate their upload capacity to the use of the energy-sensitive mobile peer. In this way the mobile peers

2 59 can save up to 50% energy. However, the drawback of this 60 approach is that it requires modifications to the BitTorrent 61 protocol and was thus not compatible with existing peers. 62 In another study, we used an intermediate server, a 63 BitTorrent proxy, hosted in the Internet to split content 64 download into two parts [5]. Regular BitTorrent was used 65 to download the content to the server, which was hosted on 66 Amazon EC2, and normal HTTP was used to transfer the 67 complete file from the server to the phone. Because 68 Amazon EC2 provides a high uplink speed the phone 69 received the content with high bitrate. In this way, the 70 energy-limited peers, in comparison to standard BitTorrent, 71 can achieve 50% energy savings without significantly 72 affecting the download speeds of regular peers. 73 As an alternative solution to hosting the proxies in the 74 Internet, we investigate in this paper the use of broadband 75 routers as platforms for running BitTorrent proxies. Broad- 76 band routers that connect the home to Internet via ADSL or 77 other technology are commonly available. Notice, that even 78 if the routers are located at homes they do not limit the 79 mobility of the users because they are accessible with 80 mobile devices from everywhere through Internet connec- 81 tions. If the mobile user happens to be at home he could use 82 the local WiFi connection but he can also connect to the 83 proxy remotely through cellular data connection or through 84 a public WiFi access point. 85 The router platform is attractive for a number of reasons. 86 Since most homes are equipped with broadband routers the 87 installed base is large and the routers are frequently idle 88 when their owners are on the move. Routers are typically 89 powered up all the time and the energy consumption of the 90 router is almost constant no matter how actively it is used. 91 There is thus plenty of spare capacity that could be taken 92 into use without additional costs for the users. From the 93 technical point of view, the firmware of many routers can 94 be changed, which allows extending the original function- 95 ality of the router. 96 However, a number of new problems arise because 97 broadband routers have limited resources. Although some 98 models allow hardware extensions with USB devices, and 99 some high-end router models even have built-in support for 100 torrent download, typically, the memory size is limited and 101 no mass memory is available. Future routers are likely to be 102 more capable but we think that targeting minimalistic 103 hardware is important both for utilization present router 104 base and for the generality of the idea. 105 The key contributions of this research are 106 & First, our explicit interest is how the system can deliver 107 a torrent to a battery powered, wirelessly connected 108 mobile device energy-efficiently. So far the key perfor- 109 mance metric of most BitTorrent research has been 110 download time. & Second, we analyze how the limited resources of the proxy peer influence BitTorrent performance. The ability to store and share pieces that a peer has already downloaded is one of the key concepts of BitTorrent. If the storage space of the proxy is limited, downloaded pieces have to be discarded after they have been transmitted to the mobile, and thus cannot be shared any longer. However, there is no method in the BitTorrent protocol to announce that a formerly shared piece has been discarded. Consequently, we investigate how this influences BitTorrent behavior and what policies and mechanisms are needed to manage the memory. Our goal is that these solutions are compatible with the existing BitTorrent clients and that they do not harm the downloading performance of regular peers. Even though our earlier papers on the topic [24, 25] briefly discuss some of these concepts, the research presented in this paper introduces a complete analytical model, adds further measurements and simulations, plus evaluates all the results together. The rest of the paper is organized as follows. In Section 2, we present related work and in greater detail explain how our work differs from it. In Section 3, we briefly summarize how the energy consumption is affected by wireless data transfer. Then in Section 4, we describe our proxy torrent concept and how it deals with the limited memory of the router platform. In Section 5, we derive a mathematical model of the BitTorrent swarm performance and proxy peer behavior including analysis of optimal memory allocation and energy consumption. In Section 6, we verify the model and investigate the behavior with large-scale simulations. We have also implemented a prototype which allows us to study how the solution works in live torrent networks. The prototype implementation and measurement results with it are presented in Section 7. Finally, in Section 8, we discuss and summarize our findings and present conclusions and ideas for further work. 2 Related work So far the energy-efficiency of BitTorrent, or peer-to-peer file downloading in general, has mainly been investigated from two different aspects: how to reduce the standby energy consumption of PC peers [7, 8] and how to perform active content download energy-efficiently with a mobile peer [2, 4, 5]. In another track, the use of helper nodes to speed up torrent downloads have shown promising results [6, 9]. The use of memory-limited devices to help torrent downloads seems to be absent in prior work. Outside of P2P field, the use of proxies to improve energyefficiency of mobile applications has been widely studied. For

3 161 instance, Flinn and Satyanarayanan [10] discuss how to 162 create energy-adaptive applications based on proxies and 163 Shenov and Radkov [11] use a proxy to improve the energy- 164 efficiency of streaming content to mobile devices. 165 The nano data center concept [12] provides services with 166 hardware distributed at homes. This operator-controlled 167 community solution is based on enhanced versions of 168 normal routers. While savings in the overall energy 169 consumption is a key target, the focus is on the infrastruc- 170 ture side, not on the energy-efficient operation of the 171 terminal devices. 172 Considering modeling BitTorrent, no prior research has 173 investigated the performance of a network with storage 174 limited peers. A number of studies have modeled heteroge- 175 neous networks. However, none of them is directly suitable 176 for our needs because the models only allow varying the 177 bandwidth capacity of the peers. Chow et al. [13] claims to be 178 the first paper modeling heterogeneous BitTorrent swarms 179 with arbitrary number of peer classes. Fan et al. [14], use 180 multiple peer classes and analyze different rate assignment 181 strategies. Liao et al. [15], investigate how the performance 182 of high bandwidth and low bandwidth peers compare and 183 introduces a novel token-based scheme to analyze perfor- 184 mance/fairness. The work of Chang et al. [16] quantifies the 185 performance impact of network address translation (NAT) on 186 BitTorrent by presenting a model using two peer classes 187 (NAT peers and public peers) Mobile energy consumption 189 An important observation in mobile phone power con- 190 sumption is that a higher bitrate increases the energy- 191 efficiency of a data transfer. Measurements in [2] showed 192 that especially for 3 G cellular the power consumption of 193 TCP data transfer is almost constant having only a weak 194 dependency on the bitrate. Only when bitrate drops to zero, 195 meaning that there is no communication, the device is able 196 to enter a sleep state with very low power consumption. An 197 extensive set of measurements for WiFi power consumption 198 [3] with three different mobile phone models shows very 199 similar results for g WLAN. 200 Figure 1, based on the measurements data of [2], 201 illustrates how the energy consumption per bit varies as a 202 function of communication speed. The shape of the curves 203 shows that the higher the bit rate, the more energy-efficient 204 the communication is. This suggests that in order to save 205 energy we should arrange the content download activity in 206 a way that the mobile device experiences as high bitrate as 207 possible. One way to achieve this is to alternate between 208 active transfer periods with high bitrates and idle periods 209 with no traffic. So instead of receiving data at a constant 210 low speed we prefer to communicate in high-speed bursts Fig. 1 Power consumption per bit as a function of communication speed separated by idle periods. The higher speed we are able to reach during the active periods the more energy-efficient the data transfer will be. Note that the average download speed does not change, only the shape of the traffic. Another important observation related to mobile communication is that activation of the wireless interface before data can be transferred and its deactivation after the data transfer, require time and energy. The amount of these head and tail energies varies with different communication technologies. Especially the tail energies are large in cellular data networks; in 3 G it takes over 12 s before the radio interface returns to idle state after the end of data transfer (6 s in GSM, and <1 s in WiFi) [17]. This suggests that we should send the data in fewer and larger bursts to minimize the burst specific overheads. 4 ProxyTorrent Prior research (e.g. [18] [19]) has shown that mobile phones are able to participate in peer-to-peer networks but at the same time revealed a set of issues, which reduce the download speed of mobile peers. Some of the most important issues are: & & & Because of their slow upload speeds, mobile devices get a low rank by BitTorrent s tit-for-tat mechanism. As a result, they get worse service from their peers. Mobile clients usually cannot accept incoming connections since they are behind routers or NATs. Therefore, they can reach fewer peers to serve them. BitTorrent is slow at the beginning of a new torrent download. It can take several minutes before it reaches a decent download speed. As discussed in Section 3, slower speed increases the energy consumption the download. Protocol overhead and

4 244 hash computation to validate the received data increase the 245 energy consumption further. 246 The key idea of ProxyTorrent is to use a proxy to shape 247 the traffic experienced by the phone. In this way torrent 248 download is divided into two activities. To the swarm the 249 proxy looks like a regular BitTorrent peer; it downloads and 250 uploads content with the normal BitTorrent mechanisms. 251 Then it forwards downloaded content to the mobile phone. 252 In a simple case the proxy would download the whole 253 torrent and after that push it to the phone in a single large 254 burst. This is the approach we have investigated in our 255 earlier research [5]. This, however, is only possible if the 256 proxy has enough memory to store the whole torrent. When 257 we are using the router hardware, or some other proxy 258 solution with small amount of resources, the limited 259 memory allows us to store only part of the content. This 260 raises interesting questions on what kind of memory 261 management policy to adopt that ensures both a fast and 262 fair torrent download and an energy-efficient transfer of 263 content pieces from the proxy to the phone. 264 A key assumption of BitTorrent operation is that when a 265 peer has completely downloaded a piece it announces the 266 availability of the piece to its peers. The peers can then 267 assume that the announced piece is available for down- 268 loading. This is, however, not the case if only part of the 269 content fits the router memory. To be able to download the 270 whole torrent, the router has to delete some pieces after 271 they have been sent to the mobile device, and then reuse the 272 memory to download additional pieces. The assumption 273 that a piece a peer has downloaded is available for others is 274 thus no longer valid. 275 The trivial solution to this problem is to ignore it. The 276 BitTorrent client in the router would announce the pieces 277 normally. Then, it would later receive requests for pieces 278 that have already been deleted from the memory, and which 279 cannot anymore be uploaded to peers. This would have a 280 negative effect on the download speed because the tit-for- 281 tat mechanism would rank the peer lower if it cannot serve 282 a requested piece. Moreover, most clients are likely to 283 disconnect the peer when the request times out. 284 Another trivial alternative is to announce no pieces at all 285 and miss the opportunity to serve other peers. However, this 286 free-rider behavior is bad for the proxy itself because 287 BitTorrent s tit-for-tat algorithm ranks it low resulting in 288 slow download speed. Furthermore, if the number of such 289 proxies in the BitTorrent swarm is high, it can also have a 290 negative effect on the download speed of other peers. 291 The solution we have adopted is illustrated in Fig. 2. In 292 order to both serve other peers and ensure that all 293 announcements the proxy peer makes are valid, our 294 solution divides the memory into two buffers. The 295 download buffer holds transient data on the way to the 296 mobile; the pieces are downloaded from peers, sent to the Fig. 2 ProxyTorrent architecture with an example of memory contents mobile device, and discarded. Then the same memory space is reused to download other pieces. The content of the download buffer is thus constantly changing as the download of the torrent progresses. The upload buffer, on the other hand, stores pieces that are served to the swarm. After a piece in the upload buffer has been downloaded and sent to the mobile device, it remains in the memory and is made available for other peers with the normal BitTorrent piece transfer mechanisms. Thus pieces stored in the upload buffer match the standard BitTorrent rules and are not deleted while the torrent transfer is active. The upload buffer is filled with the first pieces the client downloads. The system also has to decide when to communicate with the mobile device. We use a parameter, chunk size, to indicate how many pieces should be completely available in the download buffer before they are sent to the mobile. Sending a bigger set of data to the mobile phone in one pass would improve energy-efficiency by reducing the number of bursts and the overhead related to the bursts. On the other hand, a bigger chunk size would reduce BitTorrent download speed and waste memory because a number of completely downloaded pieces would wait for other pieces to complete before they can be transferred to the phone and their memory reused. 5 System model 5.1 Swarm performance analysis The aim of the model is to enable performance evaluation of proxy based BitTorrent setups and aid in configuring the system parameters, most importantly the upload/download buffer size

5 327 The model uses two peer classes: limited (L), regular (R). 328 Limited peers use ProxyTorrent and have only limited storage 329 capacity, regular peers are standard BitTorrent peers with 330 enough storage capacity for sharing the whole torrent. In 331 addition, regular peers with the completecontentarecalled 332 seeds (S). To be able to focus on the effects of limited storage 333 capacity, the model and most of our further experiments assume 334 that all peers are homogeneous in terms of bandwidth capacity. 335 Table 1 summarizes all of the symbols used in the 336 formulas. The unit of data transfer is piece/second in all 337 applicable cases, e.g. u L =2 means that a limited peer 338 uploads two pieces each second. 339 The model is based on uplink sharing, which means that 340 the download throughput of the peers is calculated by 341 dividing the total available upload capacity among them. 342 This requires that the download capacity of peers is not 343 lower than their upload capacity: U D Since most internet access is asymmetric with much 347 higher download capacity than upload, this requirement is 348 met in nearly all practical cases. 349 Lemma 1. The number of regular and limited peers in 350 the swarm in the steady state is: n R ¼ lj R P d R t1.1 Table 1 Symbols and definitions t1.2 Symbol Definition t1.3 n R Number of regular peers in the system t1.4 n L Number of limited peers in the system t1.5 n S Number of seeds in the system t1.6 1 Global peer join rate t1.7 j L Limited peer join probability t1.8 j R Regular peer join probability t1.9 U Maximum upload capacity of the peers t1.10 D Maximum download capacity of the peers t1.11 u R Upload rate of regular peers t1.12 μ R Tit-for-tat rating of regular peers t1.13 u L Upload rate of limited peers t1.14 μ L Tit-for-tat rating of limited peers t1.15 d L Download rate of limited peers t1.16 d R Download rate of regular peers t1.17 P Number of pieces in the torrent (size of the torrent) t1.18 B u Size of the limited peers upload buffer t1.19 B d Size of the limited peers download buffer t1.20 α Number of parallel connections (neighbors) per peer t1.21 C Chunk size: number of pieces pushed to the mobile device in one turn t1.22 t deg Tit-for-tat degradation period ð1þ ð2þ n L ¼ lj L P d L ð3þ Proof. Peers arrive to the system with the arrival rate 1. The probability that a newly joined peer is a regular is j R, and limited peers join with j L probability. To determine the average number of peers in steady state, we use Little s law from queuing theory. The arrival rate of each peer class can be can be calculated by multiplying the global peer arrival rate with the peer class s probability, e.g. regular peers arrive with 1j R rate. The time spent in the system by a peer is equal to the download time. The average upload speed together with the tit-for-tat ratings are perhaps the most important components of the whole system since they are the key factors when the peers download speed is determined. Although both regular and limited peers have the same maximum upload capacity, their average upload speed during downloading the torrent is not equal. The average upload speeds are given by the following lemma: Lemma 2. Assume that the upload buffer of the limited peers is smaller than the shared file, i.e. B u /P<1 and the number of neighbors of each peer is α. Then the upload rate of the limited peers u L and of regular peers u R are u R ¼ U u L U 1 e Bua P 1 d L U ð4þ ð5þ Q Proof. Since regular peers are not limited in terms of storage capacity, they can gather enough pieces in a short 383 amount of time to be able to constantly serve the other 384 peers. This has been verified by both us and other research 385 through several measurements and simulations [13][15]. 386 Thus u R is equal to the maximum upload speed of the peer. 387 Moving to u L first we determine the probability that a 388 limited peer uploads to at least one other peer. This equals 389 to 1 P[a limited peer does not upload to any peers]. A 390 limited peer stores and shares B U pieces, and has α 391 neighbors. The probability that the peer has a particular 392 piece that a neighbor is looking for is B u P. Consequently, the 393 probability that it cannot serve any of its neighbors is B u a. P Thus the probability that it can serve at least one 395 of its neighbors is given by the following equation: 396 P½peer can serve a neighbourš ¼1 1 B a u P ¼ 1 1 B P Bu Bu P u P 1 e Bua P ð6þ

6 399 BitTorrent peers can download from an unlimited 400 number of neighbors simultaneously, thus it is enough that 401 the possible uploader has something that the others wants. 402 Furthermore, since the limited peer stores and uploads the 403 same B U pieces, it should be noted that this theorem 404 assumes that the neighbors of the peers are being replaced 405 relatively frequently. This condition is met with most real 406 world torrents where peers come and go dynamically and 407 there are also a lot of peers which discover each other only 408 after a long time. If we multiply this probability with the 409 maximum upload speed we get the average upload speed 410 provided by a limited peer. 411 This upload speed, however, does not yet take into 412 account that the proxy does not upload while it is 413 pushing pieces to the mobile device. Since transferring 414 to the mobile phone can take a large portion of the 415 torrent s completedownloadtime,thisfactorcannotbe 416 overlooked. 417 First, we calculate the peer s actual average upload 418 speed (u L ). Since limited peers can push pieces to the 419 mobile devices with U speed, the total time spent on 420 pushing pieces to the mobiles is P U. Since during this 421 uploads towards the BitTorrent swarm are stopped, the 422 total time a proxy peer is actively uploading is P d L P U. 423 Dividing this with the total download time gives us the 424 portion of the total download time during which the peer 425 was uploading: 1 d L U.Multiplyingthiswiththeprevi- 426 ously calculated upload speed gives us the average upload 427 speed. 428 Lemma 2 shows us that besides the upload buffer size, 429 the average number of peer neighbors α and the number of 430 pieces P can significantly affect the upload speed of limited 431 peers. More neighbors means more possible peers to serve. 432 More pieces increases the required upload buffer size (in 433 Section 5.2 we analyze this further and give a formula for 434 the minimal upload buffer size). From the second compo- 435 nent of the product in (5), we can also see that slower 436 download speed actually results in better upload utilization 437 for limited peers. This is because slower downloads mean 438 less frequent mobile push periods during which uploads are 439 stopped. 440 The tit-for-tat (TFT) rating (μ L and μ R ) is number in 441 [0,1], showing how much a peer contributes to the swarm. 442 Actual BitTorrent clients maintain a list of their neighbors 443 average upload speed in the last couple of minutes and 444 choose the fastest uploaders to be served next. Since our 445 model uses homogeneous peers, only the time they spend 446 with uploading matters. The TFT rating can be calculated 447 by normalizing the average upload speed. These values are 448 different from the average upload speed divided by the 449 upload capacity, because the TFT rating is calculated over a 450 time interval. Further explanation is provided in the proof 451 of the following lemma. Lemma 3. The tit-for-tat ratings (μ L and μ R ) are: m R ¼ 1 m L ¼ 1 e Bua P 1 C d L 2U 2 t deg ð7þ ð8þ Proof. Similarly as we reasoned in the proof of Lemma 2, the TFT rating for regular peers is 1: ¼ 1 of downloaded data to the mobile devices takes C U time. m R ¼ u R U Regular peers do not have storage limitations and thus they are assumed to be serving other peers all the time. One 463 could argue that when regular peers join the swarm they do 464 not have any pieces either. However gathering enough data 465 to full their upload buffer to utilize their complete upload 466 bandwidth (generally only 1-2% of the pieces are required 467 as we will see from our experiments) takes a relatively 468 small amount of time and thus the statement holds. 469 In the case of limited peers, the formula is similar to the 470 one we used for the average upload speed but without the 471 upload capacity multiplier. However, there is a key 472 difference, which is the result of how BitTorrent peers 473 calculate their neighbors average upload speed for the last 474 couple of minutes. Most clients use a sliding average which 475 means that even after a neighbor has stopped uploading, its 476 tit-for-tat rating still remains higher than zero for some 477 time, decreasing as time passes. The time, after a peer s 478 TFT rating becomes zero, is the TFT degradation time t deg. 479 Figure 3 illustrates how a peer s upload speed and tit-for-tat 480 rating relate to each other. 481 When a peer is actively uploading m L ¼ 1. When the 482 peer stops uploading, m L starts decreasing. Pushing a chunk Since during this period, the limited peer is not serving the 485 swarm, its TFT rating can be estimated as the mean of 486 m L during this period: 487 m Lðduring mobile pushþ ¼ 1 ð C Ut deg Þ Fig. 3 Upload speed versus tit-for-tat rating ð9þ

7 490 Downloading the complete torrent takes P d L time. This period 491 can be divided into two parts: while the peer is pushing 492 content to the mobile (and not serving the BitTorrent swarm) P U 493 and the remaining time, when the peer is not pushing 494 content to the mobile, but serving the swarm P d L P U.During 495 the latter m L ¼ 1, duringtheformeritisestimatedby(9): 1 P d L P U þ P U 1 C 2Ut deg m L ¼ P ¼ 1 C d L d L 2U 2 t deg ð10þ By comparing Lemma 2 and 3 we can see how the 499 upload speed and the TFT rating relate to each other. 500 Generally speaking, the TFT rating depicts a more positive 501 picture of the peer due to the degradation period. 502 Lemma 2 and 3 allows us to determine how much the 503 peers contribute to the swarm and how big percentage of 504 the available bandwidth they receive when applying 505 BitTorrent s TFT mechanism. The final step is to determine 506 the average download speed for both peer classes. The 507 average download speed directly maps to the download 508 time. Since peer classes are homogeneous, we only need to 509 determine how the upload capacity of the system is divided 510 between the classes. Each peer has three sources of 511 downloads: from seeds (d RS, d LS ), from its own class (d RR, 512 d LL ) and from the other class (d RL, d LR ). The equations 513 giving the download speed are defined as the sum of the 514 three download source components: d R ¼ d RS þ d RR þ d RL d L ¼ d LS þ d LL þ d LR Lemma 4. The download speeds from seeds are d RS ¼ d LS ¼ Un S n R þ n L ð11þ ð12þ ð13þ Proof. We have n S seeds, each with U upload capacity. 524 Seeds share their complete capacity among all down- 525 loaders. In earlier versions of BitTorrent, seeds favored 526 peers with higher download speed. However, since this 527 enabled several exploits and resulted in ineffective sharing 528 incentives, the current protocol serves peers based on the 529 time they were last served. Thus all peers are served an 530 equal amount of data over time. For example, the whole 531 n class of regular peers receives Un S R n R þn L download 532 capacity from seeds. If we divide it with the number of 533 regular peers (n R ), we get the download speed received by a 534 single peer. 535 Lemma 5. The download speeds from other actively 536 downloading peers depend on the class of the peer d RR ¼ Un R 4 1 þ 3Un R n R þ n L 4 1 n R þ n L m L ð14þ d LL ¼ u Ln L 4 1 þ 3u Ln L n R þ n L 4 d RL ¼ u Ln L 4 1 þ 3u Ln L n R þ n L 4 d LR ¼ Un R 4 1 þ 3Un R n R þ n L 4 m L n R þ n L m L 1 n R þ n L m L m L n R þ n L m L ð15þ ð16þ ð17þ Proof. The formulas sum all the available upload capacity of a given peer class and divide it between the peers according to BitTorrent choking and tit-for-tat rules. Each BitTorrent peer selects maximum four peers they serve at a time. One of the four peers is the optimistically unchoked peer. This peer is selected randomly, regardless its upload history, to give chance to newly joined peers to get some pieces and start uploading. Since all peers in the network are selected at the same rate, the fourth of the uploads provided by each peer ( U 4 for regular and u L 4 for 1 limited peers) are divided equally between all peers: n R þn L. The remaining three served peers are selected according to BitTorrent tit-for-tat mechanism, according to their TFT rating. Although in our model all peers have the same maximum upload speed, their TFT rating still differs since limited peers may not be able to upload all the time, which makes them slower uploaders from their partner s point of view. Since regular peers has 1 TFT rating and thus, their share is affected only by their number in the swarm n R m R ¼ n R. The TFT rating of limited peers can be less than one, so the final formula for the share of limited peers m from the tit-for-tat part is L n R þn L m L. We have a set of equations Eqs. 2, 3, 4, 5, 7, 8 and with an equal number of unknowns. We can reduce the system to only two equations with d R and d L as the unknowns by first substituting Eqs into Eqs. 11 and 12, then eliminating n R and n L with Eqs. 2 and 3. Finally, to eliminate the TFT ranking μ R and μ L and the upload speed u R and u L, we can use Eqs. 4, 5, 7 and Finding the optimal upload buffer size B u One of the main questions is how many pieces a proxy peer needs to share (store in its upload buffer) to get similar service as the regular peers which can store unlimited number of pieces. Generally speaking, if we do not consider the download buffer size, the larger the upload buffer is, the faster the download speed becomes. However, after a certain point increasing the buffer size becomes insignificant. Furthermore, according to our model the required upload slots largely depends on the average

8 587 number of connections and the number of pieces a torrent 588 contains. 589 We want to have the probability that the peer can upload 590 to others larger than a given threshold f [0,1], where means that there is always someone to which the peer can 592 upload, thus its complete upload capacity is always utilized. 593 Using the formula from Eq. 5 gives us the following 594 inequality: 1 e Bua P f ð18þ This can be reordered to form a the following formula 598 for B u P ln 1 f B u ð Þ a ð19þ If we assume f=0.9 to achieve 90% upload utilization for 602 limited peers, the formula gives 2:3 P a as the optimal upload 603 buffer size for a torrent with P pieces and an average α 604 neighbors per peer. For example, if we assume that the 605 peers have 50 neighbors, then we can achieve a 90% 606 utilization of the upload capacity by using an upload buffer 607 which must store even less than 5% of all pieces of the file. 608 However, this method can only be used if the average 609 number of neighbors per peer is known and is relatively 610 stable. If the BitTorrent swarm is in a dynamic state, e.g. 611 during the initial phase after the torrent has been published, 612 a static buffer allocation strategy is not appropriate (in 613 Section 6 we propose an adaptive buffer allocation strategy 614 that adapts to a dynamically changing swarm) Finding the optimal download buffer size B d 616 When choosing the right buffer allocation strategy the goal 617 is to be able to download from as many peers as possible 618 while using the remaining memory for storing pieces that 619 can be shared with others. Thus if on average we are Fig. 4 Power consumption of bursty traffic downloading from w peers, the minimal download buffer size we should have is B d w. This way we can download from all sources simultaneously. However, this does not take into account the chunk size C. Since C pieces are pushed to the mobile device in one chunk, at least C download slots are needed, and we get the following constraint B d C. Since during pushing the data to the phone, the download buffer cannot be freed up yet, doubling the number of download slots ensures that while a chunk is being transferred to the mobile, a new chunk can start downloading. This is true as long as the proxy s download speed is lower than its upload speed towards the mobile device, if the proxy can download several pieces while a push is being in progress, more download slots are needed: 8 C d L >< C w U B d w d ð20þ L >: C < w: U 6 Mobile energy consumption bursty traffic Figure 4 illustrates the phone s power consumption and transfer speed when data is being sent in a set of bursts. The energy consumption is a sum of the energy of the data sending bursts plus the overhead related to each burst: E ¼ nt b P b þ ne oh ð21þ where n is the number of bursts, t b is the duration of a burst, P b is the average power consumption during a burst (this may depend on the stream of a burst). The second term of the formula models the additional overhead energy E oh that each burst requires. This consists of the sum of E h, the head energy needed to ramp up the communication, and E t, the tail energy needed to return back to idle state after the communication has been

9 650 completed so that E oh ¼ E h þ E t. In this model we assume 651 that bursts are separated with long enough time intervals so 652 that their heads and tails do not overlap which means that 653 E oh is constant. 654 As discussed in Section 2, there is only a small increase 655 in power consumption when bitrate increases. Therefore, to 656 simplify our model, we assume that P b is constant. 657 The energy consumption of the mobile phone does not 658 depend on the download speed of the proxy as long as the 659 gaps between the bursts are long enough to let the phone 660 enter idle state. What matters is the number of bursts, which 661 can be directly influenced with the chunk size parameter. 662 The length of a burst is t b ¼ U C, while the total number of 663 bursts is n ¼ P C. Substituting these into Eq. 21 gives: E ¼ P U P b þ P C E oh ð22þ The model can only be used if the duration of the 667 overhead period t h +t t is shorter than the gap period t g, 668 which can be expressed as: t g ¼ C d L C U C ð23þ d L is the time the proxy peer needs to download a chunk 672 of data (C pieces) from the BitTorrent swarm. C U is the time 673 needed to push a chunk to the mobile device. The 674 difference between the two is the length of the time period 675 when the peer is downloading the next chunk but has 676 already finished the previous, thus the mobile device is idle. 677 Figure 5 shows the total energy consumption and burst 678 gap size as a function of the chunk size in swarms with 5%, % and 50% proxy peers, a 2000 piece torrent and using pieces upload buffer size. 681 It can be seen that the larger the chunk size, the smaller the 682 energy overhead becomes and thus the total energy consump- 683 tion decreases. However, we must be aware, that the energy 684 consumption plot depicts realistic values only if the gap size t g 685 is larger than the tail time t t. For example, if t t =15, which is a 686 typical value in 3 G networks [14], the smallest chunk size 687 that shows correct values in a swarm with 5% limited peers 688 is 14. More limited peers means worse overall performance 689 which also affects the length of the gaps between pushing 690 pieces to the mobile devices. If the network has 50% limited 691 peers, at least 9 piece chunks are needed Simulations and model verification Simulation setup 694 The goal of the simulations was to validate the analytical 695 model and investigate how the system would work on Fig. 5 Energy consumption and burst gap size as a function of chunk size larger scale. We used a modified version of a discrete-event BitTorrent simulator originally developed by Microsoft Research [20]. The simulator models most BitTorrent mechanisms, including tit-for-tat, choking, and rarest first piece selection. Support for end-game mode is missing, which increases the download time of the last pieces of the torrent; however, since all of the simulated peers suffer from this, their relative performance is not affected significantly. The network model is based on a fluid model of connections, which assumes that the flows traversing a link share the link bandwidth equally. The dynamics of TCP connections are not modeled. Thus, it is assumed that the bottleneck link is either the uplink of the sending node or the downlink of the receiving node. Where not stated otherwise, the following system parameters were used. The number of pieces was P=2000, the piece size was set to 256 kbyte, thus the size of the torrent was 500 Mbyte. The peers had around 120 active neighbors (α=120), the degradation period t deg was set to 40 s (4 unchoke rounds). The peers had 128 Kbyte/s upload capacity. The peer join rate was 1=1, meaning that a new peer joined every second. Peers left the network immediately as soon as they finished downloading. Only three

10 719 seeds were used, so that the effect of leechers (active peers) 720 is more significant. To reach the steady state quicker, the 721 simulations were started with 1000 leechers with 50% of 722 the torrent already downloaded (random pieces were 723 selected). The simulation time was 100,000 s so the active 724 set of peers were completely replaced several times Simulation results 726 We analyzed four scenarios with different limited/regular 727 peer join ratios. For example, in the 5% limited peers 728 scenario, 5% of the joining peers were limited. The 5% case 729 can be considered as the most realistic case, since it is 730 unlikely that in real BitTorrent networks more than 5% of 731 the peers were running on routers, at least in the near future. 732 In the other three cases, higher percentage of the peers was 733 limited. In all cases we varied the upload buffer size of the 734 peers and analyzed how it influenced the download time. 735 The results are depicted in Fig. 6. The figure shows the 736 results of both the analytical model (MOD) and the simulator (SIM). Both approaches give rather consistent results with the exception of very large buffer sizes. Starting with 5% limited peers scenario depicted in Fig. 6, we can see that the download speed of regular peers is almost constant regardless of the buffer size of limited peers. This is not surprising because a small number of limited peers cannot have a major influence on the whole community. When we look at the download speed of the limited peers, we see that there is always a significant difference between the limited and regular peers, even if the limited peers share a relatively large number of pieces. This is because the limited peers must also send the pieces to the mobile client during which they pause uploads to their peers, which hurts their TFT ranking and download speed. Nevertheless, increasing the upload buffer size improves the download speed (until some point). The optimal upload buffer size criteria from Eq. 15, gives us B u =38 for the number of pieces that should be shared to reach 90% of the performance of the regular peers. This Fig. 6 Average download rate for networks with 5% limited peers, 25% limited peers, 50% limited peers and 75% limited peers. SIM is for simulation, MOD is for the analytical model s results

11 757 value is supported by these results: both the analytical 758 model s and the simulations rate of change is quite low at 759 around 40 pieces. 760 However, the simulation results show a turning point at 761 around 45 pieces, after which increasing the upload buffer 762 size actually hurts the performance of the peer. This is the 763 result of failing to meet the download buffer constraint B d 764 in Eq. 16. The results show that the download speed is 765 around 0.3 at B u =45, and since we used chunk size C=20, 766 then B d C d L U ¼ 6, which is the minimal number of 767 download slots we should have to be able to utilize all 768 download possibilities. Thus when the upload buffer size is , only 5 pieces are available for the download buffer 770 which is not enough. Increasing the upload buffer further 771 and decreasing the download buffer correspondingly results 772 into declining performance. Although this effect is not 773 modeled by our main equations, it can be checked by using 774 Eq. 16. As a rule of thumb we can say that increasing B u is 775 good for the swarm as long as the constraint for B d defined 776 in Eq. 16 is satisfied. 777 Looking at the remaining three simulated scenario 778 (Fig. 6), we can see that networks with more limited peers 779 behave similarly as the 5% network. Since there is a larger 780 number of lower quality peers, which do not upload 781 continuously and which serve only some pieces, the 782 average download time is lower for all peers. It can be 783 seen that when only a small number of pieces are shared, 784 the limited peers get much worse service in the 75% than in 785 the 5% scenario since using fewer upload slots potentially 786 lowers the number of available download sources in the 787 entire network. Regular peers are still only slightly affected, 788 but interestingly, the larger upload buffer at limited peers 789 actually resulted in a somewhat worse performance for the 790 regular peers. This can be traced back to tit-for-tat: limited 791 peers can contribute more frequently if they have more 792 uploadable pieces, but unfortunately they are not as good 793 uploaders as BitTorrent s TFT mechanism calculates. 794 Limited peers periodically stop uploading completely, and 795 as we could see in the proof of Lemma 3 in Section 5.1, 796 these stops are not reflected in the TFT rating to a full 797 degree. Anyhow, the difference between the regular peers 798 download time at upload buffer size 5 and 50 is no more 799 than 4%. The main idea is to try to start downloading from as many peers as possible, then dynamically reallocate the unused part of the download buffer to the upload buffer. Thus, after joining the swarm and establishing the connections, we set the number of download pieces to be equal to the number of accessible peers with pieces we like to download. Then we periodically check the utilization of the download buffer. If it is underutilized, we reallocate some space from the download buffer to the upload buffer. In this way, the download buffer size can only shrink during the download process. This is in line with the fact that the number of peers we are interested in is also likely to decrease as the download progresses because when the peer is getting more pieces the number of peers in possession of still missing pieces gets smaller. Figure 7 shows how the adaptive algorithm controls the download buffer size as a function of time (the charts show average values over all proxy peers). The buffer allocation gradually settles to around B u =42 and B d =8, which is close to the optimal values given by the analytical model. A slight difference between the 5% and 50% cases is also visible: in the swarm with the larger number of standard peers, the proxy peers are also served a bit more frequently, thus their download buffer size remains at a higher level for a longer period. Simulation results with 25% and 75% limited peer ratio also showed similar results in the same range, but these are omitted from the chart to improve readability. 9 Measurements and experiments 9.1 ProxyTorrent prototype and measurement setup We developed our prototype with Linux and off-the-shelf router hardware. The Linux distribution that we installed Adaptive buffer allocation 801 In Sections 5.3 and 5.2 we have introduced formulas that 802 can be used to configure the proxy s upload and download 803 buffer size optimally. However, these methods require 804 relatively stable swarm characteristics. An alternative 805 method is to use an adaptive algorithm that gradually 806 updates the slot allocation. Fig. 7 Simulated effect of the adaptive buffer allocation algorithm. The average share of download buffer of proxy peers as a function of the time spent since joining the network

12 838 onto the routers is DD-WRT [21], which is an open source 839 embedded operating system especially tailored for routers. 840 In addition to giving us the ability to fully control the 841 router s network configuration setup, DD-WRT allows us to 842 build and execute custom applications on a wide range of 843 commercially available routers. As hardware we used Asus 844 WL-500gP, which has a 266 MHz CPU, 8 MB flash 845 storage, and 32 MB RAM. 846 The BitTorrent downloads to the proxy were handled 847 with the Enhanced CTorrent BitTorrent client [22],which is 848 a standard BitTorrent client designed to be fast and 849 lightweight. We extended CTorrent with the proxy func- 850 tionality. The modified version allows us to experiment 851 with different parameters, in particular, to specify the size 852 of the upload and download buffers plus the chunk size. 853 We used Nokia N82 phones to perform the measure- 854 ments. The energy consumption was measured using Nokia 855 Energy Profiler [23]. We used Java ME to implement the 856 phone client, which can start torrent downloads and receive 857 the downloaded pieces from the proxy. 858 The mobile client communicates with the proxy with TCP. 859 We observed that by using multiple TCP connections in 860 parallel we were able to increase the bitrate of the data transfer 861 from proxy to phone and, in this way, improve the energy- 862 efficiency. The fundamental reason for this phenomenon 863 would require further research although we suspect it depends 864 on the TCP stack implementation in our test phone model. We 865 experimented with different number of connections and it 866 turned out that increasing the number of connections beyond did not improve the speed anymore. Therefore, we used parallel connections for the measurements. 869 We allocated roughly 13 MB of the router s RAM memory 870 for ProxyTorrent to have capacity for 100 BitTorrent pieces 871 (of 128 kbyte in size); the remaining memory was used by the 872 operating system and services running on the router. Fig. 8 Measured energy consumption and download time of a 105 MB torrent with different systems and access technologies. Different chunk sizes (CS) were used in the three ProxyTorrent measurements We performed a set of tests with different memory buffer allocations, which showed that, matching the modeling and simulation results, the majority of memory should be allocated for the upload buffer. Consequently, we used a fixed allocation of 75% upload buffer and 25% download buffer in the subsequent measurements. We performed our measurements with live BitTorrent networks. We repeated each measurement at least three times and calculated the average download time and energy consumption. The scenario was to download a popular, heavily seeded 105 MByte torrent with 128 kbyte piece size to the phone. During the tests the swarm had around 500 peers and around 1:5 leecher/ seeder ratio. For comparison, we also downloaded the same torrent with SymTorrent, the phone based standard BitTorrent client. 9.2 Download speed and energy consumption The 3 G and WLAN based measurement results are shown in Fig. 8. The router based proxy results are labeled ProxyTorrent plus the chunk size used for the transfer (e.g. CS 5 means 5 pieces are sent to the phone in one chunk). In comparison with SymTorrent, using the router-based proxy consumes 40% less energy with 3 G and 55% less with WLAN. As expected doing transfers at higher speeds significantly improves the energy efficiency. In addition to better bandwidth utilization, shorter download times and lower protocol overhead contribute to energy savings. Figure 8 also shows that chunk size has only a small influence on the performance. With WLAN the energy overhead related to each burst (for activation and deactivation of the connections) is very small. Therefore, the number of burst, which chunk size influences, is of little importance for WLAN

13 906 The results also show that for 3 G the chunk size has 907 only a minor effect; the energy difference between using and 10 chunk cases is only 9%. At first glance this is 909 surprising because for 3 G the energy overhead related to 910 each burst is high and minimizing the number of burst 911 should save energy. A detailed examination shows that in 912 these tests the torrent download time was so fast that the G radio interface did not have time to enter the idle state 914 at all. The energy savings of the 3 G case then mainly come 915 from the shorter overall torrent download time that the 916 proxy enables rather than from the traffic shaping Chunk size and bursts 918 Next we artificially limited the download speed of the 919 proxy to analyze the case where proxy can download the 920 torrent much slower than it can push it to the mobile phone. 921 Thus we limited the proxy download speed to 64 kbyte/s 922 and measured the power consumption and download speed 923 while the proxy downloaded and pushed 50 Mbytes of data 924 to the mobile with different chunk sizes. The results are 925 depicted in Figs. 9 and This time increasing the chunk size resulted in smaller 927 energy consumption. Difference between energy consump- 928 tion with chunk size 4 and 20 is 12%; however, the 929 download time also increased with 8%. The right part of 930 Fig. 9 shows the phone s power and download speed in a s interval. It is nicely visible as both the bursts and the 932 gaps between them get longer as the chunk size increases. 933 The power graphs show that with chunk size 4, the phone 934 can hardly ever enter the low power state, but as the chunk 935 size increases, the gaps become longer than the tail time 936 and thus the phone can enter the low power mode. We can 937 also observer the tail time, as the power still remains at the 938 same level for several seconds after the last bit of the 939 previous chunk was sent. Fig. 10 Measurement results of varying the chunk size Download speed versus power 9.4 Proxy performance with various upload buffer sizes In order to analyze the effect of memory allocation we used two simultaneously running proxy peers. In this way we tried to limit the effect of random variation arising from the constantly changing conditions of live networks. The first proxy was the reference, always set to use 75 pieces of its buffer for uploading. This value is close to the optimal allocation ratio determined by the model. For the second proxy we tested different upload buffer sizes (0, 25, 50). We performed 10 measurements with different popular music and video torrents whose size was in the MB range. Figure 11 summarizes the results of the measurements. The boxes show the minimum, maximum and the mean of the results for the different cases. For example, the box at 0 means that the reference proxy with B u =75 downloaded the torrent 9% 300% faster than having not uploading at all (B u =0), the mean of the difference was 151%. We chose to depict the relative difference, since the actual transfer speed was very different in thethe results reflect how transient a real-life network can be: performing two measurements with Fig. 9 Measurement results of varying the chunk size Total download time and energy consumption Fig. 11 Measurements results with two proxies. The graph shows the relative performance of a proxy compared to a reference proxy

14 960 the same parameters after each other often showed signifi- 961 cantly different results. The negative differences in the 25% 962 and 50% cases actually indicate that the proxy with higher 963 upload buffer performed worse than the reference unit in 964 some measurement. Nevertheless, considering the mean of 965 the difference, it is clearly visible, that increasing the upload 966 buffer size also boosted the download speed of the proxy. It 967 is also in line with the model and simulations Discussion and conclusions 969 In this paper we have investigated the use of broadband routers 970 to improve the energy-efficiency of BitTorrent downloads to 971 mobile phones. The results show that using an auxiliary 972 computing device as a proxy can speed up the download time 973 and at the same time save energy at the mobile phone. 974 The particular interest of this paper has been the use of 975 widely available broadband routers to assist in BitTorrent 976 downloading. We consider the router to act as a proxy 977 splitting the content download into normal BitTorrent parts 978 (between proxy and peers) and regular TCP communication 979 (between proxy and mobile phone). 980 This work has both a practical side and a more theoretical 981 side. On the practical side, it shows that using broadband 982 routers as proxies for BitTorrent downloads is feasible and 983 results in energy savings and user experience improvements via 984 shorter download times. The concept could thus be deployed 985 and it would be rather easy to take into practical use because it 986 is compatible with existing BitTorrent clients and does not 987 harm the efficient operation of BitTorrent communities. 988 On the theoretical side, we have investigated how 989 BitTorrent works on memory-limited devices. Only a 990 relatively small number of pieces are required to achieve 991 full upload utilization and reach good download speeds. 992 Most of the available memory should be allocated to 993 serving other peers. This memory allocation can be done 994 statically using our analytical formulas or with an adaptive 995 algorithm. The amount of data that is sent to the mobile 996 device in one pass is another important parameter influenc- 997 ing the performance. In general a bigger chunk size can 998 save energy but it may increase the download time. 999 As always plenty of work still needs to be done. There are 1000 many parameters that control the operation of the system and 1001 understanding better how each of them influences the 1002 operation would still need further experimentation. It is 1003 possible that the optimal values for the parameters vary as a 1004 function of torrent properties and as a function of the phone 1005 context. Developing adaptive algorithms that tune the 1006 parameters into different settings is one interesting topic for 1007 further work. On the practical side additional work would still 1008 be needed to package the solution to a form which would 1009 allow easy deployment of the solution to users. References SymTorrent, URL: 2. Nurminen JK (2010) Parallel connections and their effect on the battery consumption of a mobile phone. In Proc. of 7th IEEE CCNC, Las Vegas, USA 3. Xiao Y, Savolainen P, Karppanen A, Siekkinen M, Ylä-Jääski A (2010) Practical power modeling of data transmission over g for Wireless Applications. 1st International ICST Conference on E-Energy October 2010, Athens, Greece 4. Kelényi I, Nurminen JK (2009) Bursty content sharing mechanism for energy-limited mobile devices. In Proc. of the 4th ACM PM2HW2N, Tenerife, Spain 5. Kelényi I, Nurminen JK (2010) CloudTorrent energy-efficient BitTorrent content sharing for mobile devices via cloud services. In Proc. of 7th IEEE CCNC, Las Vegas, USA 6. Garbacki P, Iosup A, Epema D, van Steen M (2006) 2Fast: Collaborative downloads in P2P networks. In Proceedings of the 6th IEEE P2P, Los Alamitos, CA, USA 7. Blackburn J, Christensen K (2009) A simulation study of a new green BitTorrent. In Proc. of the First International Workshop on Green Communications 8. Jimeno M, Christensen K (2007) A prototype power management proxy for gnutella peer-to-peer file sharing. In Proc. of 32nd IEEE Conference on Local Computer Networks 9. Wong J (2004) Enhancing collaborative content delivery with helpers. In Master s Thesis, The University of British Columbia 10. Flinn J, Satyanarayanan M (1999) Energy-aware adaptation for mobile applications. In Proc. of the 17th ACM Symposium on Operating Systems Principles, Charleston, USA 11. Shenoy PJ, Radkov P (2003) Proxy-assisted power-friendly streaming to mobile devices. In Proc. of SPIE 12. Valancius V, Laoutaris N Massoulie L Diot C Rodriguez P (2009) Greening the internet with nano data centers. In Proc. of CoNEXT ' Chow ALH, Golubchik L, Misra V (2009) BitTorrent: An Extensible Heterogeneous Model, IEEE 14. Fan B, Lui JC, Chiu D (2009) The design trade-offs of BitTorrentlike file sharing protocols. IEEE/ACM Transactions on Networking 17: Liao W, Papadopoulos F, Psounis K (2007) Performance analysis of BitTorrent-like systems with heterogeneous users. Perform Eval 64: Chang L, Liu Y, Wei Z, Pan J (2010) Optimizing BitTorrent-like peer-to-peer systems in the presence of network address translation devices. Peer-to-Peer Networking and Applications, Springer 17. Balasubramanian N, Balasubramanian A, Venkataramani A (2009) Energy consumption in mobile phones: a measurement study and implications for network applications. Proc. of the 9th ACM SIGCOMM conference on Internet measurement conference 18. Nurminen JK, Nöyränen J (2008) Energy-consumption in mobile peer-to-peer quantitative results from file sharing. In Proc. of 5th IEEE CCNC, Las Vegas, USA 19. Kelényi I, Nurminen JK (2008) Energy aspects of peer cooperation measurements with a mobile DHT system. 43th IEEE International Conference on Communications (ICC 2008), Beijing 20. Bharambe A, Herley C, Padmanabhan VN (2006) Analyzing and improving a BitTorrent network s performance mechanisms. In Proc. of 25th IEEE INFOCOM 21. DD-WRT, URL: Enhanced CTorrent, URL: Bosch Creus G, Kuulusa M (2007) Optimizing mobile software with built-in power profiling. In F Fitzek, F Reichert ed, Mobile Phone Programming and its Application to Wireless Networking. Springer 24. Kelényi I, Ludányi Á, Nurminen JK (2011) Energy-efficient BitTorrent downloads to mobile phones through memory-limited

15 1075 proxies. 8th Annual IEEE Consumer Communications & Net working Conference (CCNC 2011), Las Vegas, USA Kelényi I, Ludányi Á, Nurminen JK (2010) Ismo Puustinen: 1078 energy-efficient mobile BitTorrent with broadband router hosted 1079 proxies. 3rd Joint IFIP Wireless Mobile Networking Conference 1080 (WMNC'2010), 2010, Budapest, Hungary 1083 Imre Kelényi is currently an 1084 assistant lecturer in the Depart ment of Automation and Applied 1086 Informatics, Budapest University 1087 of Technology and Economics 1088 (BME), Hungary. He received 1089 his Master s degrees in technical 1090 informatics from BME in He completed BME s PhD course 1092 in Currently he is preparing 1093 his PhD dissertation on energy 1094 efficient mobile peer-to-peer sys tems, which is also his primary 1096 research interest. He is the creator 1097 of the world s first ever mobile BitTorrent and Gnutella clients: SymTorrent and Symella. He has worked as a contract software engineer for various companies including Nokia, 1100 Nokia Siemens Networks and T-Mobile Jukka K. Nurminen received 1106 the M.Sc, Tech.Lic., and Ph.D degrees from the Helsinki Uni versity of Technology. In he joined Nokia where he is 1110 currently working as a Principal 1111 Researcher at Nokia Research 1112 Center in Helsinki, Finland. He 1113 is also an Adjunct Professor at 1114 the Helsinki University of Tech nology. His current interests are 1116 mobile computing and peer-to peer applications, and especially 1118 their energy-efficiency Ákos Ludányi received an outstanding BSc degree in Computer Engineering from Budapest University of Technology and Economics (BME) in Now he is attending an MSc course on applied informatics at BME. He s research interest is mobile P2P applications. Ákos worked at NavNGo (developing car navigation systems). Currently he is working as a software engineer for BME s AppliedMobile Research Group and Nokia. Tamás Lukovszki is associate professor at the Eötvös Loránd University, Faculty of Informatics in Budapest, Hungary. He received his Bachelor s degree in informatics from the Eötvös Loránd University, Budapest, Hungary, Master s degree and PhD in computer science from the University of Paderborn, Germany. He worked as researcher in the Heinz Nixdorf Institute, Paderborn, Germany and as senior researcher in the Discrete Optimization Lab of the Siemens AG, Corporate Technology, Munich, Germany. His area of specialization is computer networks and network algorithms. His current research interest includes analysis of networked systems and P2P networks