The resource allocation problem reguesting maximum through- Put in BitTorrent networks is investigated. It is known from the iterature that the total throughput of BitTorrent is far from the the- oretical maximum. However, direct implementation of the uncon- strained maximum flow model into BitTorrent is not desirable, due to the necessity of further social considerations. This paper aims to produce more realistic upper bound for maximum throughput in BitTorrent networks by suggesting new model variants to move the maximum flow model closer to the rules of a typical BitTorrent community. Numerical experiments are done on those modified models, introducing lower bounds and balancing constraints on the amount of downloading and uploading, to verify their impact. Additionally, computational results are presented for comparing the network linear program model and the standard algebraic model of the maximum flow problem in AMPL

Dobjánné Antal, Elvira

Vinkó, Tamás

English

Repository of the Academy's Library

Gradus Vol 3, No 2 (2016) 67-72ISSN 2064-8014On maximum throughput in BitTorrentElvira Dobjánné Antal1∗, and Tamás Vinkó21Department of Natural Sciences and Engineering, Faculty of Mechanical Engineering and Automation,Pallasz Athéné University, Hungary2Institute of Informatics, University of Szeged, HungaryKeywords:resource allocation, flow network,BitTorrent, linear programmingArticle history:Received 07 Sept 2016Revised 10 Nov 2016Accepted 11 Nov 2016AbstractThe resource allocation problem requesting maximum through-put in BitTorrent networks is investigated. It is known from theliterature that the total throughput of BitTorrent is far from the the-oretical maximum. However, direct implementation of the uncon-strained maximum flow model into BitTorrent is not desirable, dueto the necessity of further social considerations. This paper aimsto produce more realistic upper bound for maximum throughputin BitTorrent networks by suggesting new model variants to movethe maximum flow model closer to the rules of a typical BitTorrentcommunity. Numerical experiments are done on those modifiedmodels, introducing lower bounds and balancing constraints onthe amount of downloading and uploading, to verify their impact.Additionally, computational results are presented for comparingthe network linear program model and the standard algebraicmodel of the maximum flow problem in AMPL.1 IntroductionBitTorrent is a computer network protocol for content sharing based on peer-to-peer technology[3]. Those users, who want to download a file F , and hence called as leechers, get pieces of Ffrom those users, named as seeders, who entirely have F . Since the file is divided into pieces, theleechers can also exchange them between each other without the contribution of a predeterminedcentral unit – that is the peer-to-peer aspect of BitTorrent. A set of leechers, seeders and files iscalled BitTorrent community. These communities can be modeled by graphs, which allows to analyzedifferent optimization problems related to resource allocation. A simple and natural model is theusers–files bipartite network. However, if we need to investigate optimization problems involvingbandwidth, then the usage of the tripartite flow network model introduced by Capota et al. [4] isadvised. One possible problem is maximizing throughput. In that case we would like to maximize theoverall happiness in the whole community, while not necessarily take into account the happiness ofthe participating individuals. Using the tripartite flow network, this problem reduces to the classicalgraph-theoretical problem of finding the maximum flow. Once it is calculated, maximum flow gives atheoretical upper bound of throughput in the community at the given time instance represented by thegraph. Although, this particular problem was investigated up to some degree in earlier papers [4, 8],it is still not fully understood how far is the BitTorrent performance from realistic upper bounds.2 DatasetsWe used two datasets which are traces of BitTorrent communities. The same datasets were usedin [4, 8]. They contain the tripartite graph representation of the two communities, where each graph∗Corresponding author. Tel.: +36 76 516 438E-mail address: antal.elvira@gamf.kefo.hu67E. D. Antal et al.corresponds to an actual status of the online seeders and leechers and shared files. The BitSoupdataset contains ten graphs; it was originally collected in [1]. The FileList dataset contains eightgraphs; it was originally collected in [2]. The number of nodes and edges in the BitSoup and FileListgraphs are shown in Table 1 and 2, respectively. We can notice that the densities of the graphsare different within a community. Moreover, comparing FileList to BitSoup, we have less number ofnodes, but more edges in the former. Hence, we can expect different results for the two datasets.3 Network flow modelOne of the most straightforward and easy way to deal with network flow problems is the usage ofAMPL [5]. This language enables to model flow networks as network linear programs. In this sec-tion we demonstrate the difference of the computational running times between standard (algebraic)model and network model using the node and arc keywords in AMPL [6].For testing the two models we used two state-of-the-art LP solvers: Gurobi and MOSEK. Althoughboth solvers accept the two models, only MOSEK is capable to fully utilize the network model as it hasa specific LP method to solve network linear programs. The stand-out performance of this specializedmethod can be clearly noticed in the numerical results below. All the computations were done on a24-core Intel Xeon 2.27 GHz computer with 24 GB memory.3.1 BitSoup graphsTable 1 shows the running times in seconds of the two tested solvers. It is interesting to see thatwhile Gurobi is 4.54 times faster on average in case of solving the algebraic model, MOSEK solvesthe network model even 3.22 times faster on average. It is also beneficial to use the network modelfor Gurobi, but the increase in the running time is not that much. The clear winner is MOSEK with thenetwork solver.Table 1. Running times (in seconds) for BitSoup graphsgraph Gurobi MOSEKname nodes edges algebraic network algebraic networkb1 37 266 1 254 129 26.20 20.26 100.33 6.22b2 41 243 1 526 799 32.50 21.55 133.40 8.28b3 33 651 934 852 16.00 13.61 74.90 4.49b4 33 261 739 941 13.73 12.12 62.04 3.50b5 34 075 1 184 615 21.21 16.04 105.92 5.52b6 36 849 775 404 14.27 12.28 76.03 3.29b7 33 493 611 714 9.72 6.99 52.91 2.41b8 29 426 682 401 12.30 8.89 48.14 2.48b9 30 242 508 129 8.60 6.95 33.11 1.87b10 37 504 927 018 17.49 13.83 83.34 4.583.2 FileList graphsThe results are shown in Table 2. First of all, we can see that the overall running times are longerthan those for BitSoup graphs. Similar trend can be noticed as before, MOSEK is the fastest one if itis running on the network model.68On maximum throughput in BitTorrentTable 2. Running times (in seconds) for FileList graphsgraph Gurobi MOSEKname nodes edges algebraic network algebraic networkf1 23 705 1 963 645 42.58 30.92 120.96 19.34f2 25 516 5 673 353 141.24 89.81 668.28 41.20f3 27 715 4 341 702 101.62 86.36 293.90 54.84f4 26 178 3 331 577 66.19 47.60 188.50 22.87f5 26 731 2 997 262 58.60 43.98 178.28 19.45f6 26 215 6 168 009 135.78 101.17 601.97 68.39f7 24 719 3 562 633 74.86 39.66 234.56 28.93f8 27 796 4 671 512 86.96 97.43 382.22 42.10Since MOSEK with its network LP solver (called NETWORK_PRIMAL_SIMPLEX) performs way muchquicker than the others, in the rest of the paper we will use this configuration for the experiments.4 Flows at individualsWe seek the answer to the question: what is the quality of the result of the maximum flow problemat the level of the individuals on these investigated BitTorrent graphs? The paper of Vinkó andBotyánszki [8] gives partial answers, focusing on the seeders. Using the function maxflow from theigraph package in R, which implements the Goldberg–Tarjan algorithm [7], it turned out that mostof the uploading edges have zero flow in the optimum. Moreover, if we require to have positive flowvalues on the uploading edges, which moves the optimization model closer to BitTorrent, then weget lower value in the total flow compared to the unconstrained maxflow problem. In this paper weinvestigate the flow values at the leechers’ side.4.1 Zero downloadFirst, we have a look on the download edges in the graphs. In case of the BitSoup graphs weobtain zero flow values on the 0.1%–0.3% of the download edges. This means that the correspondingleechers got no data according to the configuration found for the maximum throughput. The FileListgraphs give different results: 1.5% – 15% of the download edges get zero flow.It seems to be a good idea to modify the model in such a way that we require some little amountof flow to be put on each and every download edge. We investigated two constraints: requiring (1)to have flow at least 1% of the capacity of the actual leecher, and (2) to have flow at least 5% ofthe capacity of the actual leecher. The results we obtained are somewhat interesting: the problemsturned out to be unsolvable under the 5% condition. If we require 1%, then two networks was solvedin BitSoup and six networks in FileList. In these cases the values of the maximum flow were thesame as in the unconstrained version.4.2 Zero download per sessionsIn the BitTorrent networks we studied it is usual that leechers are participating in multiple files,i.e. downloading different contents at the same time. These downloads are treated as different edgesin the graph representations. Moreover, these edges give more fine-grained picture about the down-load at a leecher node. Hence, it is worth have a look on the flow values on these edges too. Theresults are shown in Table 3. We can see that in the network model we obtained larger number ofedges with zero flow, which is a disadvantage of that model.69E. D. Antal et al.Table 3. Average percentage of leeching edges with zero flowBitSoup FileListconstraint algebraic network algebraic networkw/o 37% 40% 23% 32%1% – 38% (2 cases) – 26% (6 cases)On the other hand, when the 1% constraint from Section 4.1 is added to the model (second rowin Table 3), then, in the cases when the problems were feasible we got slightly better results.4.3 Balancing at downloadIn these experiments we introduced another kind of constraints which force balanced flows on theleeching edges of the individual leechers. More specifically, for a given downloading node assumingthat it is leeching in k different torrents and gets F amount of total flow in the optimal configuration itis required that each and every leeching edge must have F/k amount of flow. Is it a solvable model?For the BitSoup graphs we obtained feasible solutions for all the ten cases. On average thevalue of the maximum flow got decreased to 90% of the unconstrained case’s value. Moreover, lessthan 1% of the downloading edges got zero flow value. Regarding the leeching edges we also haveless than 1% of them with zero flow. Note that if we additionally require to have flow value on thedownloading edges at least 1% of downloading capacities, then we get feasible solution only for onegraph.For the FileList graphs we again obtained feasible solutions for all the eight cases. On the onehand, on average, the value of the maximum flow got decreased only to 97% of the value of theunconstrained case, which is much better than BitSoup. On the other hand, we got up to 6% of thedownloading edges with zero flow, and up to 5% of the leeching edges with zero flow. If we add the1% constraint on the downloading edges then we obtained feasible solutions on six graphs.Summarizing the results of these experiments we conclude that it is possible to give equal down-loading service per leecher by having a slightly lower overall throughput and by not serving at allsome tiny amount of leechers.4.4 Positive flow on leechers uploadingIn the last model we get even closer to BitTorrent. It is done by combining the balancing con-straints together with trying to put positive flow values to the uploading edges corresponding to theleechers. Note that this experiment was already done in [8] without the balancing constraints. In thismodel we essentially try to capture the tit-for-tat mechanism of BitTorrent which requests leechers toupload to other leechers (hence they are exchanging pieces of content).The results we got for the BitSoup graphs are the following. As in Section 4.3 we got 90% ofthe total flow of the unconditioned model. In most of the cases only less than 10% of the leecheruploading edges got positive flow values. This means that more than 90% of the leechers do notcontribute as uploader, which is against the rules of BitTorrent.In case of FileList, similar to the result of Section 4.3, we have 97% of the total flow value of theoriginal maxflow problem. However, less than 1% of the leecher uploading edges got positive flow,which is even worse than in BitSoup.An interesting fact to report is that the sum of the flow values on the leecher uploading edgesin these experiments are usually rather high. In other words, only a few leechers play role in theuploading process, but they carry a heavy load. In the model examined here we do not aim formaximizing the number of leecher uploading edges with positive flow. That would lead to a mixed-integer linear programming problem which might be causing difficulties to solve. Instead, we did asimple modification of the model: the maximum amount of flow on the leecher uploading edges mustbe less than 1.70On maximum throughput in BitTorrentThis modification resulted in a big difference, as in BitSoup the ratio of zero flow went below 57%(in one of the cases it is as low as 21%). In FileList we could notice also a massive improvement,as at least 25% of the leecher downloading edges got positive flow in every case. Nevertheless, thethroughput of the network was decreased only by a maximum of 0.4% for each test case because ofthis newly introduced constraint.Finally, we need to mention here that in case we enforce positive flow values on all leecher up-loading edges then the problem becomes unfeasible, assuming that the balance constraints are used.This is, however, not that surprising, as in the tripartite graph model this means that a leecher ` mustupload to all other leechers participating in the sharing of files which are being downloaded by `. Thisis a very restrictive constraint.5 ConclusionsIn this paper we did some numerical investigations of the maximum throughput problem in BitTor-rent networks, which aims at maximizing the happiness of the community, to see what do we obtainat the individual levels in the optimal configuration. It is known from the literature that the resourceallocation algorithm of BitTorrent gives around 60–80% of the theoretical maximum throughput [4].However, that allocation corresponding to the upper bound does not take into account the individuals.It is clear that the direct implementation of the unconstrained maximum flow model into BitTorrent isnot desirable. This is due to the fact that it might end up in an allocation where great percentage ofthe users obtain no service from the system.We created and investigated three new model variants to move the maximum flow model closerto the rules of a typical BitTorrent community. According to the obtained results, introducing the newconstraints leads to decrease of the total throughput compared to the unconstrained case’s value.However, our experiments did never show more than 11% decrease, assuming equally good servicelevel for individual leechers in their parallel downloads, but not necessarily requiring leechers to up-load. Furthermore, a new linear programming constraint was introduced to involve more leechers tothe uploading process without significant downgrade of the total throughput of the network.To sum up, our results presented in this paper help to understand better BitTorrent in regard to themaximum throughput aspect. It would be worth developing and studying distributed algorithms basedon the proposed model variants to verify their advantageous properties compared to the existingBitTorrent protocol. We confirmed with numerical tests that network linear program representation formaxflow problem in AMPL results in significantly shorter running times than running times achievedfor the standard algebraic model. Further work could verify whether application of the network LPmodel for other practical problems is beneficial too.AcknowledgementT. Vinkó was supported by the Bolyai Scholarship of the Hungarian Academy of Sciences.References[1] N. Andrade, E. Santos-Neto, F. Brasileiro, M. Ripeanu, “Resource demand and supply in BitTor-rent content-sharing communities,” Computer Networks, vol. 53, no. 4, pp. 515–527, 2009.[2] J. Roozenburg, “Secure decentralized swarm discovery in Tribler,” Master’s thesis, Delft Univer-sity of Technology, 2006.[3] B. Cohen, “Incentives build robustness in BitTorrent,” in: Workshop on Economics of Peer-to-Peer systems, vol. 6, 2003, pp. 68–72.71E. D. Antal et al.[4] M. Capota, N. Andrade, T. Vinkó, F. Santos, J. Pouwelse, D. Epema, “Inter-swarm resource allo-cation in BitTorrent communities,” in: IEEE International Conference on Peer-to-Peer Computing(P2P), 2011, pp. 300–309.[5] R. Fourer, D.M. Gay, B.W. Kernighan, “AMPL,” Boyd & Fraser, Danvers, 1993.[6] R. Fourer, D.M. Gay., “Expressing special structures in an algebraic modeling language for math-ematical programming,” ORSA Journal on computing, vol. 7, no. 2, pp. 166–190, 1995.[7] A. V. Goldberg, R. E. Tarjan, “A new approach to the maximum-flow problem,” J. ACM, vol. 35,no. 4, pp. 921–940, 1988.[8] T. Vinkó and B. Botyánszki, “Empirical investigation of BitTorrent community graphs,” Computing,vol. 98, pp. 567–582, 2016.72

On maximum throughput in BitTorrent

http://real.mtak.hu/110230/1/2016_2_CSC_009_Dobjanne.pdf

On maximum throughput in BitTorrent

Abstract

Similar works

Full text

Available Versions

Repository of the Academy's Library