Modeling resource constrained BitTorrent proxies for energy efficient mobile content sharing

Modeling resource constrained BitTorrent proxies for energyefficient mobile content sharing

Imre Kelényi & Jukka K. Nurminen & Ákos Ludányi &Tamás Lukovszki

Received: 1 November 2010 /Accepted: 18 August 2011 /Published online: 16 September 2011# Springer Science+Business Media, LLC 2011

Abstract In this paper we present a solution that makesBitTorrent content transfer for mobile device more energyefficient. The main idea of the research is that instead ofdownloading the content via BitTorrent directly to themobile phone, an intermediate proxy is used which sendsthe data to the phone in high speed bursts. This results insmaller energy footprint compared with regular BitTorrentdata transfer. Furthermore, we focus on how the proxy canbe hosted on memory limited broadband routers which areavailable in almost every home. We define an analyticalmodel which can be used to analyze the memory allocationstrategies of the proxy peers and predict how proxy peersinfluence the P2P community performance. We verify ourmodel via simulations. We also present measurement resultswith real life torrents using our prototype system runningon home routers and Symbian based mobile phones.

Keywords Energy-efficiency . Proxy . Peer-to-peer .

BitTorrent . Broadband router . Mobile

1 Introduction

Running BitTorrent on mobile phones is clearly interestingfor users as evidenced by close to 50.000 downloads in year2009 of SymTorrent, the native BitTorrent client forSymbian based mobile phones [1]. It shows that theresources of modern mobile phones are adequate to letthem participate in P2P communities. At the same time,experience with SymTorrent highlights that energy con-sumption is one of the main difficulties for P2P usage onhandheld devices.

One approach to increase the energy-efficiency ofcontent downloading is to improve the speed with whichthe mobile device receives the content. Earlier measurementstudies show that higher bitrate improves the energy-efficiency of file transfer [2, 3]. The speed of BitTorrentdownload can vary considerably and is often well below thecapacity of the wireless interface. A recipe for energysaving is thus to increase the download speed to fill thewhole capacity of the wireless channel.

In our earlier work on energy-efficient BitTorrent, wehave taken advantage of this phenomenon and shaped thetraffic arriving to the mobile device to increase the bitrate itexperiences. The essence of the work has been to alternatebetween idle time intervals when the mobile can enterpower saving state and active intervals when the bitrate isas high as possible. In one case, the mobile peers negotiateda transfer schedule with regular peers [4]. The systemguaranteed that during active periods the available peerswould dedicate their upload capacity to the use of theenergy-sensitive mobile peer. In this way the mobile peers

This work is supported by Nokia Research Center and the New HungaryDevelopment Plan (Project ID: TÁMOP-4.2.1/B-09/1/KMR-2010-0002and TÁMOP 4.2.1/B-09/1/KMR-2010-0003). Most of this research wasdone when Jukka K. Nurminen was at Nokia Research Center.

I. Kelényi (*) :Á. LudányiBudapest University of Technology,Budapest, Hungarye-mail: [email protected]

Á. Ludányie-mail: [email protected]

J. K. NurminenDepartment of Computer Science and Engineering,Aalto University,Espoo, Finlande-mail: [email protected]

T. LukovszkiEötvös Loránd University,Budapest, Hungarye-mail: [email protected]

Peer-to-Peer Netw. Appl. (2012) 5:163–177DOI 10.1007/s12083-011-0107-5

can save up to 50% energy. However, the drawback of thisapproach is that it requires modifications to the BitTorrentprotocol and was thus not compatible with existing peers.

In another study, we used an intermediate server, aBitTorrent proxy, hosted in the Internet to split contentdownload into two parts [5]. Regular BitTorrent was usedto download the content to the server, which was hosted onAmazon EC2, and normal HTTP was used to transfer thecomplete file from the server to the phone. Because AmazonEC2 provides a high-speed uplink channel, the phonereceives the content with high bitrate. In this way, theenergy-limited peers, in comparison to standard BitTorrent,can achieve 50% energy savings without significantlyaffecting the download speeds of regular peers.

As an alternative solution to hosting the proxies in theInternet, we investigate in this paper the use of broadbandrouters as platforms for running BitTorrent proxies. Broad-band routers that connect the home to Internet via ADSL orother technology are commonly available. Notice, that evenif the routers are located at homes they do not limit themobility of the users because they are accessible withmobile devices from everywhere through Internet connec-tions. If the mobile user happens to be at home he could usethe local WiFi connection but he can also connect to theproxy remotely through cellular data connection or througha public WiFi access point.

The router platform is attractive for a number of reasons.Since most homes are equipped with broadband routers theinstalled base is large and the routers are frequently idlewhen their owners are on the move. Routers are typicallypowered up all the time and the energy consumption of therouter is almost constant no matter how actively it is used.There is thus plenty of spare capacity that could be takeninto use without additional costs for the users. From thetechnical point of view, the firmware of many routers canbe changed, which allows extending the original function-ality of the router.

However, a number of new problems arise becausebroadband routers have limited resources. Although somemodels allow hardware extensions with USB devices, andsome high-end router models even have built-in support fortorrent download, typically, the memory size is limited andno mass memory is available. Future routers are likely to bemore capable but we think that targeting minimalistichardware is important both for utilization present routerbase and for the generality of the idea.

The key contributions of this research are

& First, our explicit interest is how the system can delivera torrent to a battery powered, wirelessly connectedmobile device energy-efficiently. So far the key perfor-mance metric of most BitTorrent research has beendownload time.

& Second, we analyze how the limited resources of theproxy peer influence BitTorrent performance. Theability to store and share pieces that a peer has alreadydownloaded is one of the key concepts of BitTorrent. Ifthe storage space of the proxy is limited, downloadedpieces have to be discarded after they have beentransmitted to the mobile, and thus cannot be sharedany longer. However, there is no method in theBitTorrent protocol to announce that a formerly sharedpiece has been discarded. Consequently, we investigatehow this influences BitTorrent behavior and whatpolicies and mechanisms are needed to manage thememory. Our goal is to keep compatibility with existingBitTorrent clients and not harm the downloading per-formance of regular peers.

Even though our earlier papers on the topic [24, 25]briefly discuss some of these concepts, the researchpresented in this paper introduces a complete analyticalmodel, adds further measurements and simulations, plusevaluates all the results together.

The rest of the paper is organized as follows. InSection 2, we present related work and in greater detailexplain how our work differs from it. In Section 3, webriefly summarize how the energy consumption is affectedby wireless data transfer. Then in Section 4, we describeour proxy torrent concept and how it deals with the limitedmemory of the router platform. In Section 5, we derive amathematical model of the BitTorrent swarm performanceand proxy peer behavior including analysis of optimalmemory allocation and energy consumption. In Section 6,we verify the model and investigate the behavior withlarge-scale simulations. We have also implemented aprototype which allows us to study how the solution worksin live torrent networks. The prototype implementation andmeasurement results with it are presented in Section 7.Finally, in Section 8, we discuss and summarize ourfindings and present conclusions and ideas for further work.

2 Related work

So far the energy-efficiency of BitTorrent, or peer-to-peerfile downloading in general, has mainly been investigatedfrom two different aspects: how to reduce the standbyenergy consumption of PC peers [7, 8] and how to performactive content download energy-efficiently with a mobilepeer [2, 4, 5]. In another track, the use of helper nodes tospeed up torrent downloads have shown promising results[6, 9]. The use of memory-limited devices to help torrentdownloads seems to be absent in prior work.

Outside of P2P field, the use of proxies to improve energy-efficiency of mobile applications has been widely studied. For

164 Peer-to-Peer Netw. Appl. (2012) 5:163–177

instance, Flinn and Satyanarayanan [10] discuss how tocreate energy-adaptive applications based on proxies andShenov and Radkov [11] use a proxy to improve the energy-efficiency of streaming content to mobile devices.

The nano data center concept [12] provides services withhardware distributed at homes. This operator-controlledcommunity solution is based on enhanced versions ofnormal routers. While savings in the overall energyconsumption is a key target, the focus is on the infrastruc-ture side, not on the energy-efficient operation of theterminal devices.

Considering modeling BitTorrent, no prior research hasinvestigated the performance of a network with storagelimited peers. A number of studies have modeled heteroge-neous networks. However, none of them is directly suitablefor our needs because the models only allow varying thebandwidth capacity of the peers. Chow et al. [13] claims to bethe first paper modeling heterogeneous BitTorrent swarmswith arbitrary number of peer classes. Fan et al. [14], usemultiple peer classes and analyze different rate assignmentstrategies. Liao et al. [15], investigate how the performanceof high bandwidth and low bandwidth peers compare andintroduces a novel token-based scheme to analyze perfor-mance/fairness. The work of Chang et al. [16] quantifies theperformance impact of network address translation (NAT) onBitTorrent by presenting a model using two peer classes(NAT peers and public peers).

3 Mobile energy consumption

An important observation in mobile phone power con-sumption is that a higher bitrate increases the energy-efficiency of a data transfer. Measurements in [2] showedthat especially for 3G cellular the power consumption ofTCP data transfer is almost constant having only a weakdependency on the bitrate. Only when bitrate drops to zero,meaning that there is no communication, the device is ableto enter a sleep state with very low power consumption. Anextensive set of measurements for WiFi power consumption[3] with three different mobile phone models shows verysimilar results for 802.11 g WLAN.

Figure 1, based on the measurements data of [2],illustrates how the energy consumption per bit varies as afunction of communication speed. The shape of the curvesshows that the higher the bit rate, the more energy-efficientthe communication is. This suggests that in order to saveenergy we should arrange the content download activity ina way that the mobile device experiences as high bitrate aspossible. One way to achieve this is to alternate betweenactive transfer periods with high bitrates and idle periodswith no traffic. So instead of receiving data at a constantlow speed we prefer to communicate in high-speed bursts

separated by idle periods. The higher speed we are able toreach during the active periods the more energy-efficientthe data transfer will be. Note that the average downloadspeed does not change, only the shape of the traffic.

Another important observation related to mobile com-munication is that activation of the wireless interface beforedata can be transferred and its deactivation after the datatransfer, require time and energy. The amount of these headand tail energies varies with different communicationtechnologies. Especially the tail energies are large incellular data networks; in 3G it takes over 12 s before theradio interface returns to idle state after the end of datatransfer (6 s in GSM, and <1 s in WiFi) [17]. This suggeststhat we should send the data in fewer and larger bursts tominimize the burst specific overhead.

4 ProxyTorrent

Prior research (e.g. [18] [19]) has shown that mobile phonesare able to participate in peer-to-peer networks but at thesame time revealed a set of issues, which reduce thedownload speed of mobile peers. Some of the mostimportant issues are:

& Because of their slow upload speeds, mobile devices geta low rank by BitTorrent’s tit-for-tat mechanism. As aresult, they get worse service from their peers.

& Mobile clients usually cannot accept incoming con-nections 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 torrentdownload. It can take several minutes before it reachesa decent download speed.

As discussed in Section 3, slower speed increases theenergy consumption the download. Protocol overhead and

Fig. 1 Power consumption per bit as a function of communicationspeed

Peer-to-Peer Netw. Appl. (2012) 5:163–177 165

hash computation to validate the received data increase theenergy consumption further.

The key idea of ProxyTorrent is to use a proxy to shapethe traffic experienced by the phone. In this way torrentdownload is divided into two activities. To the swarm theproxy looks like a regular BitTorrent peer; it downloads anduploads content with the normal BitTorrent mechanisms.Then it forwards downloaded content to the mobile phone.In a simple case the proxy would download the wholetorrent and after that push it to the phone in a single largeburst. This is the approach we have investigated in ourearlier research [5]. This, however, is only possible if theproxy has enough memory to store the whole torrent. Whenwe are using the router hardware, or some other proxysolution with small amount of resources, the limitedmemory allows us to store only part of the content. Thisraises interesting questions on what kind of memorymanagement policy to adopt that ensures both a fast andfair torrent download and an energy-efficient transfer ofcontent pieces from the proxy to the phone.

A key assumption of BitTorrent operation is that when apeer has completely downloaded a piece it announces theavailability of the piece to its peers. The peers can thenassume that the announced piece is available for down-loading. This is, however, not the case if only part of thecontent fits the router memory. To be able to download thewhole torrent, the router has to delete some pieces afterthey have been sent to the mobile device, and then reuse thememory to download additional pieces. The assumptionthat a piece a peer has downloaded is available for others isthus no longer valid.

The trivial solution to this problem is to ignore it. TheBitTorrent client in the router would announce the piecesnormally. Then, it would later receive requests for piecesthat have already been deleted from the memory, and whichcannot anymore be uploaded to peers. This would have anegative effect on the download speed because the tit-for-tat mechanism would rank the peer lower if it cannot servea requested piece. Moreover, most clients are likely todisconnect the peer when the request times out.

Another trivial alternative is to announce no pieces at alland miss the opportunity to serve other peers. However, thisfree-rider behavior is bad for the proxy itself becauseBitTorrent’s tit-for-tat algorithm ranks it low resulting inslow download speed. Furthermore, if the number of suchproxies in the BitTorrent swarm is high, it can also have anegative effect on the download speed of other peers.

The solution we have adopted is illustrated in Fig. 2. Inorder to both serve other peers and ensure that allannouncements the proxy peer makes are valid, oursolution divides the memory into two buffers. Thedownload buffer holds transient data on the way to themobile; the pieces are downloaded from peers, sent to the

mobile device, and discarded. Then the same memory spaceis reused to download other pieces. The content of thedownload buffer is thus constantly changing as thedownload of the torrent progresses. The upload buffer, onthe other hand, stores pieces that are served to the swarm.After a piece in the upload buffer has been downloaded andsent to the mobile device, it remains in the memory and ismade available for other peers with the normal BitTorrentpiece transfer mechanisms. Thus pieces stored in the uploadbuffer match the standard BitTorrent rules and are notdeleted while the torrent transfer is active. The uploadbuffer is filled with the first pieces the client downloads.

The system also has to decide when to communicatewith the mobile device. We use a parameter, chunk size, toindicate how many pieces should be completely available inthe download buffer before they are sent to the mobile.Sending a bigger set of data to the mobile phone in onepass would improve energy-efficiency by reducing thenumber of bursts and the overhead related to the bursts. On theother hand, a bigger chunk size would reduce BitTorrentdownload speed and waste memory because a number ofcompletely downloaded pieces would wait for other piecesto complete before they can be transferred to the phone andtheir memory reused.

5 System model

5.1 Swarm performance analysis

The aim of the model is to enable performance evaluationof proxy based BitTorrent setups and aid in configuring thesystem parameters, most importantly the upload/downloadbuffer size.

Fig. 2 ProxyTorrent architecture with an example of memorycontents


The model uses two peer classes: limited (L), regular (R).Limited peers use ProxyTorrent and have only limited storagecapacity, regular peers are standard BitTorrent peers withenough storage capacity for sharing the whole torrent. Inaddition, regular peers with the complete content are calledseeds (S). To be able to focus on the effects of limited storagecapacity, themodel andmost of our further experiments assumethat all peers are homogeneous in terms of bandwidth capacity.

Table 1 summarizes all of the symbols used in theformulas. The unit of data transfer is piece/second in allapplicable cases, e.g. uL=2 means that a limited peeruploads two pieces each second.

The model is based on uplink sharing, which means thatthe download throughput of the peers is calculated bydividing the total available upload capacity among them.This requires that the download capacity of peers is notlower than their upload capacity:

U � D ð1ÞSince most internet access is asymmetric with much

higher download capacity than upload, this requirement ismet in nearly all practical cases.

Lemma 1. The number of regular and limited peers inthe swarm in the steady state is:

nR ¼ ljRP

dRð2Þ

nL ¼ ljLP

dLð3Þ

Proof. Peers arrive to the system with the arrival rate 1.The probability that a newly joined peer is a regular is jR,and limited peers join with jL probability. To determine theaverage number of peers in steady state, we use Little’s lawfrom queuing theory. The arrival rate of each peer class canbe can be calculated by multiplying the global peer arrivalrate with the peer class’s probability, e.g. regular peersarrive with 1jR rate. The time spent in the system by a peeris equal to the download time.

The average upload speed together with the tit-for-tatratings are perhaps the most important components of thewhole system since they are the key factors when the peers’download speed is determined. Although both regular andlimited peers have the same maximum upload capacity,their average upload speed during downloading the torrentis not equal. The average upload speeds are given by thefollowing lemma:

Lemma 2. Assume that the upload buffer of the limitedpeers is smaller than the shared file, i.e. Bu/P<1 and thenumber of neighbors of each peer is α. Then the upload rateof the limited peers uL and of regular peers uR are

uR ¼ U ð4Þ

uL � U � 1� e�Bu �a

P

� �� 1� dL

U

� �ð5Þ

Proof. Since regular peers are not limited in terms ofstorage capacity, they can gather enough pieces in a shortamount of time to be able to constantly serve the otherpeers. This has been verified by both us and other researchthrough several measurements and simulations [13][15].Thus uR is equal to the maximum upload speed of the peer.

Moving to uL first we determine the probability that alimited peer uploads to at least one other peer. This equalsto 1−P[a limited peer does not upload to any peers]. Alimited peer stores and shares BU pieces, and has αneighbors. The probability that the peer has a particular

piece that a neighbor is looking for is BuP . Consequently, the

probability that it cannot serve any of its neighbors is

1� BuP

� �a. Thus the probability that it can serve at least one

of its neighbors is given by the following equation:

P½peer can serve a neighbour� ¼ 1� 1� Bu

P

� �a

¼ 1� 1� Bu

P

� � PBu�BuP a

� 1� e�Bu �aP

ð6Þ

Table 1 Symbols and definitions

Symbol Definition

nR Number of regular peers in the system

nL Number of limited peers in the system

nS Number of seeds in the system

1 Global peer join rate

jL Limited peer join probability

jR Regular peer join probability

U Maximum upload capacity of the peers

D Maximum download capacity of the peers

uR Upload rate of regular peers

μR Tit-for-tat rating of regular peers

uL Upload rate of limited peers

μL Tit-for-tat rating of limited peers

dL Download rate of limited peers

dR Download rate of regular peers

P Number of pieces in the torrent (size of the torrent)

Bu Size of the limited peers’ upload buffer

Bd Size of the limited peers’ download buffer

α Number of parallel connections (neighbors) per peer

C Chunk size: number of pieces pushed to the mobiledevice in one turn

tdeg Tit-for-tat degradation period


BitTorrent peers can download from an unlimitednumber of neighbors simultaneously, thus it is enough thatthe possible uploader has something that the others wants.Furthermore, since the limited peer stores and uploads thesame BU pieces, it should be noted that this theoremassumes that the neighbors of the peers are being replacedrelatively frequently. This condition is met with most realworld torrents where peers come and go dynamically andthere are also a lot of peers which discover each other onlyafter a long time. If we multiply this probability with themaximum upload speed we get the average upload speedprovided by a limited peer.

This upload speed, however, does not yet take intoaccount that the proxy does not upload while it ispushing pieces to the mobile device. Since transferringto the mobile phone can take a large portion of thetorrent’s complete download time, this factor cannot beoverlooked.

First, we calculate the peer’s actual average uploadspeed (uL). Since limited peers can push pieces to themobile devices with U speed, the total time spent onpushing pieces to the mobiles is P

U. Since during thisuploads towards the BitTorrent swarm are stopped, thetotal time a proxy peer is actively uploading is P

dL� P

U.

Dividing this with the total download time gives us the portionof the total download time during which the peer wasuploading: 1� dL

U

� �. Multiplying this with the previously

calculated upload speed gives us the average upload speed.

Lemma 2 shows us that besides the upload buffer size,the average number of peer neighbors α and the number ofpieces P can significantly affect the upload speed of limitedpeers. More neighbors means more possible peers to serve.More pieces increases the required upload buffer size (inSection 5.2 we analyze this further and give a formula forthe minimal upload buffer size). From the second compo-nent of the product in (5), we can also see that slowerdownload speed actually results in better upload utilizationfor limited peers. This is because slower downloads meanless frequent mobile push periods during which uploads arestopped.

The tit-for-tat (TFT) rating (μL and μR) is number in[0,1], showing how much a peer contributes to the swarm.Actual BitTorrent clients maintain a list of their neighbors’average upload speed in the last couple of minutes andchoose the fastest uploaders to be served next. Since ourmodel uses homogeneous peers, only the time they spendwith uploading matters. The TFT rating can be calculatedby normalizing the average upload speed. These values aredifferent from the average upload speed divided by theupload capacity, because the TFT rating is calculated over atime interval. Further explanation is provided in the proofof the following lemma.

Lemma 3. The tit-for-tat ratings (μL and μR) are:

mR ¼ 1 ð7Þ

mL ¼ 1� e�Bu �a

P

� �1� C � dL

2U 2 � tdeg

� �ð8Þ

Proof. Similarly as we reasoned in the proof of Lemma2, the TFT rating for regular peers is 1:

mR ¼ uRU

¼ 1

Regular peers do not have storage limitations and thusthey are assumed to be serving other peers all the time. Onecould argue that when regular peers join the swarm they donot have any pieces either. However gathering enough datato full their upload buffer to utilize their complete uploadbandwidth (generally only 1-2% of the pieces are requiredas we will see from our experiments) takes a relativelysmall amount of time and thus the statement holds.

In the case of limited peers, the formula is similar to theone we used for the average upload speed but without theupload capacity multiplier. However, there is a keydifference, which is the result of how BitTorrent peerscalculate their neighbors average upload speed for the lastcouple of minutes. Most clients use a sliding average whichmeans that even after a neighbor has stopped uploading, itstit-for-tat rating still remains higher than zero for sometime, decreasing as time passes. The time, after a peer’sTFT rating becomes zero, is the TFT degradation time tdeg.Figure 3 illustrates how a peer’s upload speed and tit-for-tatrating relate to each other.

When a peer is actively uploading mL ¼ 1. When thepeer stops uploading, mLstarts decreasing. Pushing a chunkof downloaded data to the mobile devices takes C

U time.Since during this period, the limited peer is not serving theswarm, its TFT rating can be estimated as the mean ofmLduring this period:

mLðduring mobile pushÞ ¼ 1� ð C

UtdegÞ ð9Þ

Fig. 3 Upload speed versus tit-for-tat rating


Downloading the complete torrent takes PdLtime. This period

can be divided into two parts: while the peer is pushingcontent to the mobile (and not serving the BitTorrent swarm)PU and the remaining time, when the peer is not pushing

content to the mobile, but serving the swarm PdL� P

U. During

the latter mL ¼ 1, during the former it is estimated by (9):

mL ¼1 P

dL� P

U

� �þ P

U 1� C2Utdeg

� �PdL

¼ 1� C � dL2U2 � tdeg ð10Þ

By comparing Lemma 2 and 3 we can see how theupload speed and the TFT rating relate to each other.Generally speaking, the TFT rating depicts a more positivepicture of the peer due to the degradation period.

Lemma 2 and 3 allows us to determine how much thepeers contribute to the swarm and how big percentage ofthe available bandwidth they receive when applyingBitTorrent’s TFT mechanism. The final step is to determinethe average download speed for both peer classes. Theaverage download speed directly maps to the downloadtime. Since peer classes are homogeneous, we only need todetermine how the upload capacity of the system is dividedbetween the classes. Each peer has three sources ofdownloads: from seeds (dRS, dLS), from its own class (dRR,dLL) and from the other class (dRL, dLR). The equationsgiving the download speed are defined as the sum of thethree download source components:

dR ¼ dRS þ dRR þ dRL ð11ÞdL ¼ dLS þ dLL þ dLR ð12Þ

Lemma 4. The download speeds from seeds are

dRS ¼ dLS ¼ UnSnR þ nL

ð13Þ

Proof. We have nS seeds, each with U upload capacity.Seeds share their complete capacity among all down-loaders. In earlier versions of BitTorrent, seeds favoredpeers with higher download speed. However, since thisenabled several exploits and resulted in ineffective sharingincentives, the current protocol serves peers based on thetime they were last served. Thus all peers are served an equalamount of data over time. For example, the whole class ofregular peers receives UnS � nR

nRþnLdownload capacity from

seeds. If we divide it with the number of regular peers (nR),we get the download speed received by a single peer.

Lemma 5. The download speeds from other activelydownloading peers depend on the class of the peer

dRR ¼ UnR4

� 1

nR þ nLþ 3UnR

4� 1

nR þ nL � mLð14Þ

dLL ¼ uLnL4

� 1

nR þ nLþ 3uLnL

4� mL


dRL ¼ uLnL4

� 1

nR þ nLþ 3uLnL

4� 1


dLR ¼ UnR4

� 1

nR þ nLþ 3UnR

4� mL


Proof. The formulas sum all the available uploadcapacity of a given peer class and divide it between thepeers according to BitTorrent choking and tit-for-tat rules.Each BitTorrent peer selects maximum four peers theyserve at a time. One of the four peers is the optimisticallyunchoked peer. This peer is selected randomly, regardlessits upload history, to give chance to newly joined peers toget some pieces and start uploading. Since all peers in thenetwork are selected at the same rate, the fourth of theuploads provided by each peer (U4 for regular and uL

4 for

limited peers) are divided equally between all peers: 1nRþnL

.

The remaining three served peers are selected accordingto BitTorrent tit-for-tat mechanism, according to their TFTrating. Although in our model all peers have the samemaximum upload speed, their TFT rating still differs sincelimited peers may not be able to upload all the time, whichmakes them slower uploaders from their partner’s point ofview. Since regular peers has 1 TFT rating and thus, theirshare is affected only by their number in the swarmnR � mR ¼ nR. The TFT rating of limited peers can be lessthan one, so the final formula for the share of limited peersfrom the tit-for-tat part is mL

nRþnL�mL.

We have a set of equations Eqs. 2, 3, 4, 5, 7, 8 and 11–17 with an equal number of unknowns. We can reduce thesystem to only two equations with dR and dL as theunknowns by first substituting Eqs. 14–17 into Eqs. 11 and12, then eliminating nR and nL with Eqs. 2 and 3. Finally, toeliminate the TFT ranking μR and μL and the upload speeduR and uL, we can use Eqs. 4, 5, 7 and 8.

5.2 Finding the optimal upload buffer size Bu

One of the main questions is how many pieces a proxy peerneeds to share (store in its upload buffer) to get similarservice as the regular peers which can store unlimitednumber of pieces. Generally speaking, if we do notconsider the download buffer size, the larger the uploadbuffer is, the faster the download speed becomes. However,after a certain point increasing the buffer size becomes in-significant. Furthermore, according to our model the required


upload slots largely depends on the average number ofconnections and the number of pieces a torrent contains.

We want to have the probability that the peer can uploadto others larger than a given threshold f ∈ [0,1], where 1means that there is always someone to which the peer canupload, thus its complete upload capacity is always utilized.Using the formula from Eq. 5 gives us the followinginequality:

1� e�Bu �aP

� �� f ð18Þ

This can be reordered to form a the following formulafor Bu

Bu � �P ln 1� fð Þa

ð19Þ

If we assume f=0.9 to achieve 90% upload utilization forlimited peers, the formula gives 2:3 P

a as the optimal uploadbuffer size for a torrent with P pieces and an average αneighbors per peer. For example, if we assume that thepeers have 50 neighbors, then we can achieve a 90%utilization of the upload capacity by using an upload bufferwhich must store even less than 5% of all pieces of the file.However, this method can only be used if the averagenumber of neighbors per peer is known and is relativelystable. If the BitTorrent swarm is in a dynamic state, e.g.during the initial phase after the torrent has been published,a static buffer allocation strategy is not appropriate (inSection 6 we propose an adaptive buffer allocation strategythat adapts to a dynamically changing swarm).

5.3 Finding the optimal download buffer size Bd

When choosing the right buffer allocation strategy the goalis to be able to download from as many peers as possiblewhile using the remaining memory for storing pieces thatcan be shared with others. Thus if on average we are

downloading from w peers, the minimal download buffersize we should have is Bd � w. This way we can downloadfrom all sources simultaneously. However, this does nottake into account the chunk size C. Since C pieces arepushed to the mobile device in one chunk, at least Cdownload slots are needed, and we get the followingconstraint Bd � C. Since during pushing the data to thephone, the download buffer cannot be freed up yet, doublingthe number of download slots ensures that while a chunk isbeing transferred to the mobile, a new chunk can startdownloading. This is true as long as the proxy’s downloadspeed is lower than its upload speed towards the mobiledevice, if the proxy can download several pieces while apush is being in progress, more download slots are needed:

Bd �C

dLU

� if C � w

wdLU

� if C < w:

8>>><>>>:

ð20Þ

6 Mobile energy consumption—bursty traffic

Figure 4 illustrates the phone’s power consumption andtransfer speed when data is being sent in a set of bursts.

The energy consumption is a sum of the energy of thedata sending bursts plus the overhead related to each burst:

E ¼ ntbPb þ nEoh ð21Þwhere n is the number of bursts, tb is the duration of a burst,Pb is the average power consumption during a burst (thismay depend on the stream of a burst).

The second term of the formula models the additionaloverhead energy Eoh that each burst requires. This consistsof the sum of Eh, the head energy needed to ramp up thecommunication, and Et, the tail energy needed to returnback to idle state after the communication has been

Fig. 4 Power consumption ofbursty traffic


completed so that Eoh ¼ Eh þ Et. In this model we assumethat bursts are separated with long enough time intervals sothat their heads and tails do not overlap which means thatEoh is constant.

As discussed in Section 2, there is only a small increasein power consumption when bitrate increases. Therefore, tosimplify our model, we assume that Pb is constant.

The energy consumption of the mobile phone does notdepend on the download speed of the proxy as long as thegaps between the bursts are long enough to let the phoneenter idle state. What matters is the number of bursts, whichcan be directly influenced with the chunk size parameter.

The length of a burst is tb ¼ CU, while the total number of

bursts is n ¼ PC. Substituting these into Eq. 21 gives:

E ¼ P

UPb þ P

CEoh ð22Þ

The model can only be used if the duration of theoverhead period th+tt is shorter than the gap period tg,which can be expressed as:

tg ¼ C

dL� C

Uð23Þ

CdLis the time the proxy peer needs to download a chunk

of data (C pieces) from the BitTorrent swarm. CU is the time

needed to push a chunk to the mobile device. Thedifference between the two is the length of the time periodwhen the peer is downloading the next chunk but hasalready finished the previous, thus the mobile device is idle.

Figure 5 shows the total energy consumption and burstgap size as a function of the chunk size in swarms with 5%,30% and 50% proxy peers, a 2000 piece torrent and using20 pieces upload buffer size.

It can be seen that the larger the chunk size, the smaller theenergy overhead becomes and thus the total energy consump-tion decreases. However, we must be aware, that the energyconsumption plot depicts realistic values only if the gap size tgis larger than the tail time tt. For example, if tt=15, which is atypical value in 3G networks [14], the smallest chunk sizethat shows correct values in a swarm with 5% limited peersis 14. More limited peers means worse overall performancewhich also affects the length of the gaps between pushingpieces to the mobile devices. If the network has 50% limitedpeers, at least 9 piece chunks are needed.

7 Simulations and model verification

7.1 Simulation setup

The goal of the simulations was to validate the analyticalmodel and investigate how the system would work on

larger scale. We used a modified version of a discrete-eventBitTorrent simulator originally developed by MicrosoftResearch [20]. The simulator models most BitTorrentmechanisms, including tit-for-tat, choking, and rarest firstpiece selection. Support for end-game mode is missing,which increases the download time of the last pieces of thetorrent; however, since all of the simulated peers sufferfrom this, their relative performance is not affectedsignificantly. The network model is based on a fluid modelof connections, which assumes that the flows traversing alink share the link bandwidth equally. The dynamics ofTCP connections are not modeled. Thus, it is assumed thatthe bottleneck link is either the uplink of the sending nodeor the downlink of the receiving node.

Where not stated otherwise, the following systemparameters were used. The number of pieces was P=2000,the piece size was set to 256 kbyte, thus the size of thetorrent was 500 Mbyte. The peers had around 120 activeneighbors (α=120), the degradation period tdeg was set to40 s (4 unchoke rounds). The peers had 128 Kbyte/s uploadcapacity. The peer join rate was 1=1, meaning that a newpeer joined every second. Peers left the network immedi-ately as soon as they finished downloading. Only three

Fig. 5 Energy consumption and burst gap size as a function of chunksize


seeds were used, so that the effect of leechers (active peers)is more significant. To reach the steady state quicker, thesimulations were started with 1000 leechers with 50% ofthe torrent already downloaded (random pieces wereselected). The simulation time was 100,000 s so the activeset of peers were completely replaced several times.

7.2 Simulation results

We analyzed four scenarios with different limited/regularpeer join ratios. For example, in the “5% limited peers”scenario, 5% of the joining peers were limited. The 5% casecan be considered as the most realistic case, since it isunlikely that in real BitTorrent networks more than 5% ofthe peers were running on routers, at least in the near future.In the other three cases, higher percentage of the peers waslimited. In all cases we varied the upload buffer size of thepeers and analyzed how it influenced the download time.The results are depicted in Fig. 6. The figure shows theresults of both the analytical model (MOD) and the

simulator (SIM). Both approaches give rather consistentresults with the exception of very large buffer sizes.

Starting with 5% limited peers scenario depicted inFig. 6, we can see that the download speed of regular peersis almost constant regardless of the buffer size of limitedpeers. This is not surprising because a small number oflimited peers cannot have a major influence on the wholecommunity. When we look at the download speed of thelimited peers, we see that there is always a significantdifference between the limited and regular peers, even ifthe limited peers share a relatively large number ofpieces. This is because the limited peers must also sendthe pieces to the mobile client during which they pauseuploads to their peers, which hurts their TFT ranking anddownload speed.

Nevertheless, increasing the upload buffer sizeimproves the download speed (until some point). Theoptimal upload buffer size criteria from Eq. 15, gives usBu=38 for the number of pieces that should be shared toreach 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 forsimulation, MOD is for the analytical model’s results


value is supported by these results: both the analyticalmodel’s and the simulations’ rate of change is quite low ataround 40 pieces.

However, the simulation results show a turning point ataround 45 pieces, after which increasing the upload buffersize actually hurts the performance of the peer. This is theresult of failing to meet the download buffer constraint Bd

in Eq. 20. The results show that the download speed isaround 0.3 at Bu=45, and since we used chunk size C=20,then C dL

U

� ¼ 6, which is the minimal number of downloadslots we should have to be able to utilize all downloadpossibilities. Thus when the upload buffer size is 45, only5 pieces are available for the download buffer which is notenough. Increasing the upload buffer further and decreasingthe download buffer correspondingly results into decliningperformance. Although this effect is not modeled by ourmain equations, it can be checked by using Eq. 20. As arule of thumb we can say that increasing Bu is good forthe swarm as long as the constraint for Bd defined in Eq. 20is satisfied.

Looking at the remaining three simulated scenario(Fig. 6), we can see that networks with more limited peersbehave similarly as the 5% network. Since there is a largernumber of “lower quality” peers, which do not uploadcontinuously and which serve only some pieces, theaverage download time is lower for all peers. It can beseen that when only a small number of pieces are shared,the limited peers get much worse service in the 75% than inthe 5% scenario since using fewer upload slots potentiallylowers the number of available download sources in theentire network. Regular peers are still only slightly affected,but interestingly, the larger upload buffer at limited peersactually resulted in a somewhat worse performance for theregular peers. This can be traced back to tit-for-tat: limitedpeers can contribute more frequently if they have moreuploadable pieces, but unfortunately they are not as gooduploaders as BitTorrent’s TFT mechanism calculates.Limited peers periodically stop uploading completely, andas we could see in the proof of Lemma 3 in Section 5.1,these stops are not reflected in the TFT rating to a fulldegree. Anyhow, the difference between the regular peers’download time at upload buffer size 5 and 50 is no morethan 4%.

8 Adaptive buffer allocation

In Sections 5.3 and 5.2 we have introduced formulas thatcan be used to configure the proxy’s upload and downloadbuffer size optimally. However, these methods requirerelatively stable swarm characteristics. An alternativemethod is to use an adaptive algorithm that graduallyupdates the slot allocation.

The main idea is to try to start downloading from asmany peers as possible, then dynamically reallocate theunused part of the download buffer to the upload buffer.Thus, after joining the swarm and establishing the con-nections, we set the number of download pieces to be equalto the number of accessible peers with pieces we like todownload. Then we periodically check the utilization of thedownload buffer. If it is underutilized, we reallocate somespace from the download buffer to the upload buffer. In thisway, the download buffer size can only shrink during thedownload process. This is in line with the fact that thenumber of peers we are interested in is also likely todecrease as the download progresses because when the peeris getting more pieces the number of peers in possession ofstill missing pieces gets smaller.

Figure 7 shows how the adaptive algorithm controls thedownload buffer size as a function of time (the charts showaverage values over all proxy peers). The buffer allocationgradually settles to around Bu=42 and Bd=8, which is closeto the optimal values given by the analytical model. A slightdifference between the 5% and 50% cases is also visible: inthe swarm with the larger number of standard peers, theproxy peers are also served a bit more frequently, thus theirdownload buffer size remains at a higher level for a longerperiod. Simulation results with 25% and 75% limited peerratio also showed similar results in the same range, but theseare 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-shelfrouter hardware. The Linux distribution that we installed

Fig. 7 Simulated effect of the adaptive buffer allocation algorithm.The average share of download buffer of proxy peers as a function ofthe time spent since joining the network


onto the routers is DD-WRT [21], which is an open sourceembedded operating system especially tailored for routers.In addition to giving us the ability to fully control therouter’s network configuration setup, DD-WRT allows us tobuild and execute custom applications on a wide range ofcommercially available routers. As hardware we used AsusWL-500gP, which has a 266 MHz CPU, 8 MB flashstorage, and 32 MB RAM.

The BitTorrent downloads to the proxy were handledwith the Enhanced CTorrent BitTorrent client [22],which isa standard BitTorrent client designed to be fast andlightweight. We extended CTorrent with the proxy func-tionality. The modified version allows us to experimentwith different parameters, in particular, to specify the sizeof the upload and download buffers plus the chunk size.

We used Nokia N82 phones to perform the measure-ments. The energy consumption was measured using NokiaEnergy Profiler [23]. We used Java ME to implement thephone client, which can start torrent downloads and receivethe downloaded pieces from the proxy.

The mobile client communicates with the proxy with TCP.We observed that by using multiple TCP connections inparallel we were able to increase the bitrate of the data transferfrom proxy to phone and, in this way, improve the energy-efficiency. The fundamental reason for this phenomenonwould require further research although we suspect it dependson the TCP stack implementation in our test phone model. Weexperimented with different number of connections and itturned out that increasing the number of connections beyond 5did not improve the speed anymore. Therefore, we used 5parallel connections for the measurements.

We allocated roughly 13MB of the router’s RAMmemoryfor ProxyTorrent to have capacity for 100 BitTorrent pieces(of 128 kByte in size); the remaining memory was used by theoperating system and services running on the router.

We performed a set of tests with different memory bufferallocations, which showed that, matching the modeling andsimulation results, the majority of memory should beallocated for the upload buffer. Consequently, we used afixed allocation of 75% upload buffer and 25% downloadbuffer in the subsequent measurements.

We performed our measurements with live BitTorrentnetworks. We repeated each measurement at least threetimes and calculated the average download time andenergy consumption. The scenario was to download apopular, heavily seeded 105 MByte torrent with 128kByte piece size to the phone. During the tests theswarm had around 500 peers and around 1:5 leecher/seeder ratio. For comparison, we also downloaded thesame torrent with SymTorrent, the phone based standardBitTorrent client.

9.2 Download speed and energy consumption

The 3G and WLAN based measurement results are shownin 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-basedproxy consumes 40% less energy with 3G and 55% lesswith WLAN. As expected doing transfers at higher speedssignificantly improves the energy efficiency. In addition tobetter bandwidth utilization, shorter download times andlower protocol overhead contribute to energy savings.

Figure 8 also shows that chunk size has only a smallinfluence on the performance. With WLAN the energyoverhead related to each burst (for activation and deactiva-tion of the connections) is very small. Therefore, thenumber of burst, which chunk size influences, is of littleimportance for WLAN.

Fig. 8 Measured energyconsumption and download timeof a 105 MB torrent withdifferent systems and accesstechnologies. Different chunksizes (CS) were used in the threeProxyTorrent measurements


The results also show that for 3G the chunk size has onlya minor effect; the energy difference between using 1 and10 chunk cases is only 9%. At first glance this is surprisingbecause for 3G the energy overhead related to each burstis high and minimizing the number of burst should saveenergy. A detailed examination shows that in these tests thetorrent download time was so fast that the 3G radiointerface did not have time to enter the idle state at all.The energy savings of the 3G case then mainly come fromthe shorter overall torrent download time that the proxyenables rather than from the traffic shaping.

9.3 Chunk size and bursts

Next we artificially limited the download speed of theproxy to analyze the case where proxy can download thetorrent much slower than it can push it to the mobile phone.Thus we limited the proxy download speed to 64 kbyte/sand measured the power consumption and download speedwhile the proxy downloaded and pushed 50 Mbytes of datato the mobile with different chunk sizes. The results aredepicted in Figs. 9 and 10.

This time increasing the chunk size resulted in smallerenergy consumption. Difference between energy consump-tion with chunk size 4 and 20 is 12%; however, thedownload time also increased with 8%. The right part ofFig. 9 shows the phone’s power and download speed in a200 s interval. It is nicely visible as both the bursts and thegaps between them get longer as the chunk size increases.The power graphs show that with chunk size 4, the phonecan hardly ever enter the low power state, but as the chunksize increases, the gaps become longer than the tail timeand thus the phone can enter the low power mode. We canalso observer the tail time, as the power still remains at thesame level for several seconds after the last bit of theprevious chunk was sent.

9.4 Proxy performance with various upload buffer sizes

In order to analyze the effect of memory allocation we usedtwo simultaneously running proxy peers. In this way we triedto limit the effect of random variation arising from theconstantly changing conditions of live networks. The firstproxy was the reference, always set to use 75 pieces of itsbuffer for uploading. This value is close to the optimalallocation ratio determined by the model. For the secondproxy we tested different upload buffer sizes (0, 25, 50). Weperformed 10 measurements with different popular music andvideo torrents whose size was in the 100–350 MB range.

Figure 11 summarizes the results of the measurements.The boxes show the minimum, maximum and the mean ofthe results for the different cases. For example, the box at 0means that the reference proxy with Bu=75 downloaded thetorrent 9%–300% faster than having not uploading at all(Bu =0), the mean of the difference was 151%. We chose todepict the relative difference, since the actual transfer speedwas very different in theThe results reflect how transient areal-life network can be: performing two measurements with

Fig. 10 Measurement results of varying the chunk size—Downloadspeed versus power

Fig. 9 Measurement results of varying the chunk size—Totaldownload time and energy consumption

Fig. 11 Measurements results with two proxies. The graph shows therelative performance of a proxy compared to a reference proxy


the same parameters after each other often showed signifi-cantly different results. The negative differences in the 25%and 50% cases actually indicate that the proxy with higherupload buffer performed worse than the reference unit insome measurement. Nevertheless, considering the mean ofthe difference, it is clearly visible, that increasing the uploadbuffer size also boosted the download speed of the proxy. Itis also in line with the model and simulations.

10 Discussion and conclusions

In this paper we have investigated the use of broadband routersto improve the energy-efficiency of BitTorrent downloads tomobile phones. The results show that using an auxiliarycomputing device as a proxy can speed up the download timeand at the same time save energy at the mobile phone.

The particular interest of this paper has been the use ofwidely available broadband routers to assist in BitTorrentdownloading. We consider the router to act as a proxysplitting the content download into normal BitTorrent parts(between proxy and peers) and regular TCP communication(between proxy and mobile phone).

This work has both a practical side and a more theoreticalside. On the practical side, it shows that using broadbandrouters as proxies for BitTorrent downloads is feasible andresults in energy savings and user experience improvements viashorter download times. The concept could thus be deployedand it would be rather easy to take into practical use because itis compatible with existing BitTorrent clients and does notharm the efficient operation of BitTorrent communities.

On the theoretical side, we have investigated howBitTorrent works on memory-limited devices. Only arelatively small number of pieces are required to achievefull upload utilization and reach good download speeds.Most of the available memory should be allocated toserving other peers. This memory allocation can be donestatically using our analytical formulas or with an adaptivealgorithm. The amount of data that is sent to the mobiledevice in one pass is another important parameter influenc-ing the performance. In general a bigger chunk size cansave energy but it may increase the download time.

As always plenty of work still needs to be done. There aremany parameters that control the operation of the system andunderstanding better how each of them influences theoperation would still need further experimentation. It ispossible that the optimal values for the parameters vary as afunction of torrent properties and as a function of the phonecontext. Developing adaptive algorithms that tune theparameters into different settings is one interesting topic forfurther work. On the practical side additional work would stillbe needed to package the solution to a form which wouldallow easy deployment of the solution to users.

References

1. SymTorrent, URL: http://symtorrent.aut.bme.hu2. Nurminen JK (2010) Parallel connections and their effect on the

battery consumption of a mobile phone. In Proc. of 7th IEEECCNC, Las Vegas, USA

3. Xiao Y, Savolainen P, Karppanen A, Siekkinen M, Ylä-Jääski A(2010) Practical power modeling of data transmission over802.11 g for Wireless Applications. 1st International ICSTConference on E-Energy. 14–15 October 2010, Athens, Greece

4. Kelényi I, Nurminen JK (2009) Bursty content sharing mecha-nism for energy-limited mobile devices. In Proc. of the 4th ACMPM2HW2N, Tenerife, Spain

5. Kelényi I, Nurminen JK (2010) CloudTorrent—energy-efficientBitTorrent 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 the6th IEEE P2P, Los Alamitos, CA, USA

7. Blackburn J, Christensen K (2009) A simulation study of a newgreen BitTorrent. In Proc. of the First International Workshop onGreen Communications

8. Jimeno M, Christensen K (2007) A prototype power managementproxy for gnutella peer-to-peer file sharing. In Proc. of 32nd IEEEConference on Local Computer Networks

9. Wong J (2004) Enhancing collaborative content delivery withhelpers. In Master’s Thesis, The University of British Columbia

10. Flinn J, Satyanarayanan M (1999) Energy-aware adaptation formobile applications. In Proc. of the 17th ACM Symposium onOperating Systems Principles, Charleston, USA

11. Shenoy PJ, Radkov P (2003) Proxy-assisted power-friendlystreaming 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 '09

13. Chow ALH, Golubchik L, Misra V (2009) BitTorrent: AnExtensible Heterogeneous Model, IEEE

14. Fan B, Lui JC, Chiu D (2009) The design trade-offs of BitTorrent-like file sharing protocols. IEEE/ACM Transactions on Network-ing 17:365–376

15. Liao W, Papadopoulos F, Psounis K (2007) Performance analysisof BitTorrent-like systems with heterogeneous users. Perform Eval64:876–891

16. Chang L, Liu Y, Wei Z, Pan J (2010) Optimizing BitTorrent-likepeer-to-peer systems in the presence of network address transla-tion devices. Peer-to-Peer Networking and Applications, Springer

17. Balasubramanian N, Balasubramanian A, Venkataramani A (2009)Energy consumption in mobile phones: a measurement study andimplications for network applications. Proc. of the 9th ACMSIGCOMM conference on Internet measurement conference

18. Nurminen JK, Nöyränen J (2008) Energy-consumption in mobilepeer-to-peer—quantitative results from file sharing. In Proc. of 5thIEEE CCNC, Las Vegas, USA

19. Kelényi I, Nurminen JK (2008) Energy aspects of peer cooper-ation—measurements with a mobile DHT system. 43th IEEEInternational Conference on Communications (ICC 2008), Beijing

20. Bharambe A, Herley C, Padmanabhan VN (2006) Analyzing andimproving a BitTorrent network’s performance mechanisms. InProc. of 25th IEEE INFOCOM

21. DD-WRT, URL: http://www.dd-wrt.com/22. Enhanced CTorrent, URL: http://www.rahul.net/dholmes/ctorrent/23. Bosch Creus G, Kuulusa M (2007) Optimizing mobile software with

built-in power profiling. In F Fitzek, F Reichert ed, Mobile PhoneProgramming and its Application to Wireless Networking. Springer

24. Kelényi I, Ludányi Á, Nurminen JK (2011) Energy-efficientBitTorrent downloads to mobile phones through memory-limited


http://symtorrent.aut.bme.hu

http://www.dd-wrt.com/

http://www.rahul.net/dholmes/ctorrent/

proxies. 8th Annual IEEE Consumer Communications & Net-working Conference (CCNC 2011), Las Vegas, USA

25. Kelényi I, Ludányi Á, Nurminen JK (2010) Ismo Puustinen:energy-efficient mobile BitTorrent with broadband router hostedproxies. 3rd Joint IFIP Wireless Mobile Networking Conference(WMNC'2010), 2010, Budapest, Hungary

Imre Kelényi is assistant lecturerin the Department of Automa-tion and Applied Informatics,Budapest University of Technol-ogy and Economics (BME),Hungary. He received his Mas-ter’s degree in technical infor-matics from BME in 2007. Hecompleted BME’s PhD course in2010. Currently he is preparinghis PhD dissertation on energyefficient mobile peer-to-peer sys-tems, which is also his primaryresearch interest. He is the creatorof the world’s first ever mobile

BitTorrent and Gnutella clients: SymTorrent and Symella. He has workedas a contract software engineer for various companies including Nokia,Nokia Siemens Networks and T-Mobile.

Jukka K. Nurminen is professorof data communication softwareat Aalto University in Finland.Before returning to academia hespent almost 25 years at NokiaResearch Center working on avariety of topics related to mobileapplications and services. His cur-rent interests are mobile comput-ing, peer-to-peer applications, andthe energy efficiency of distributedsolutions. He received his M.Sc.degree in 1986 and Ph.D. degreein 2003 from Helsinki Universityof Technology.

Ákos Ludányi received an out-standing BSc degree in ComputerEngineering from BudapestUniversity of Technology andEconomics (BME) in 2010.Now he is attending an MSccourse on applied informatics atBME. He’s research interest ismobile P2P applications. Ákosworked at NavNGo (developingcar navigation systems). Currentlyhe is working as a software engi-neer for BME’s Applied MobileResearch Group and Nokia.

Tamás Lukovszki is associateprofessor at the Eötvös LorándUniversity, Faculty of Informat-ics in Budapest, Hungary.

He received his Bachelor’sdegree in informatics from theEötvös Loránd University, Buda-pest, Hungary, Master’s degreeand PhD in computer sciencefrom the University of Paderborn,Germany.

He worked as researcher inthe Heinz Nixdorf Institute,Paderborn, Germany and as se-nior researcher in the Discrete

Optimization Lab of the Siemens AG, Corporate Technology, Munich,Germany.

His area of specialization is computer networks and networkalgorithms.

His current research interest includes analysis of networked systemsand P2P networks.


Documents

Modeling resource constrained BitTorrent proxies for energy efficient mobile content sharing