中 華 大 學 碩 士 論 文
BitTorrent環境下減少跨區域流量之 同儕合作策略
Reducing Cross-ISP traffic using an Adaptive Peer Collaboration Strategy in BitTorrent
系 所 別：資訊工程學系碩士班 學號姓名：M09602042 秦允求 指導教授：許慶賢 博士
中華民國 九十八 年 七 月
Reducing Cross-ISP traffic using an Adaptive Peer Collaboration Strategyin BitTorrent
By
Yun-Chiu Ching
Advisor: Prof. Ching-Hsien Hsu
Department of Computer Science and Information Engineering
Chung-Hua University Hsinchu, 30067, Taiwan
July 2009
中文摘要
Peer-to-Peer (P2P) 系統近年來在Internet-scale系統上面的發展應用越來越熱 門。BitTorrent 則是P2P系統中最多人使用的分享資源平台。由於BitTorrent環境 下的節點沒有區域感知的能力，無法區分自己的鄰居是屬於哪個Internet Service Provider (ISP)，導致開始分享檔案的時候就會帶來大量的cross-ISP流量(約佔 70%)，ISPs為了要控制成本就會調節BitTorrent流量來減少cross-ISP流量。在這篇 論文中，我們提出一個合適的同儕合作策略，並且不需要建置其他設備來仲裁節 點下載的動作或是備援機制，節點之間可以自行相互間接合作，避免設備當機時 造成系統無法正常運作與額外建置設備的成本。本論文所提出的同儕合作策略有 三個部份：一、區域鄰居挑選 (Biased Neighbor Selection)。二、唯一區塊挑選 (Unique Piece Selection)。三、動態優先配置 (Dynamic Priority Allocation)。採取 區域鄰居挑選的主要目的是，讓節點能夠得到大部份和自己相同ISP的鄰居，只 有少部份的鄰居是位於其他ISP，以減少cross-ISP傳輸的機會；在唯一區塊挑選 的部分，我們使用進階追蹤伺服器記錄每個ISP裡面目前所擁有的區塊，避免使 用者重複下載自己ISP裡面已經擁有的區塊；而動態優先配置主要是用來減少整 體的檔案下載時間。從模擬實驗結果可以得知我們提出的同儕合作策略優於傳統 的BitTorrent以及先前只使用區域鄰居挑選的方法，同儕合作策略不但減少 cross-ISP的流量，也有效地縮短了檔案下載的時間。
關鍵詞：點對點、跨區域流量、同儕合作策略、區域鄰居挑選、唯一區塊挑選、
廣域區塊表、動態優先配置
Abstract
The emerging Peer-to-Peer (P2P) model has become a very popular paradigm for developing Internet-scale systems. The BitTorrent is an example of P2P system for sharing resources, including files and documents. Owing to the peer does not have the capability of locality aware, it cannot differentiate its neighbors belong to which Internet Service Provider (ISP), file sharing results in a large amount of cross-ISP traffic (about 70%). ISPs often control BitTorrent traffic by bandwidth limiting for reducing cross-ISP traffic. In this thesis, we propose an adaptive Peer Collaboration Strategy to reduce cross-ISP traffic without additional equipment and backup mechanism, which means decreasing the cost of additional equipment. Internal peers can collaborate indirectly. In Peer Collaboration Strategy, first, each peer chooses most of its neighbors from internal ISP, and only a few from external ISPs for reducing transfer of cross-ISP by using Biased Neighbor Selection. Second, in order to avoid redundancy, we propose Unique Piece Selection, which employ Advanced Tracker (AT) to record the information of pieces that owned by each ISP. Finally, we adopt Dynamic Priority Allocation for decreasing the file download time.
Performance results show that our Peer Collaboration Strategy outperforms BitTorrent and previous approaches, reduces cross-ISP traffic and decreases the file download time remarkably.
Keywords: Peer-to-Peer, Cross-ISP traffic, Peer collaboration strategy, Biased neighbor selection, Unique piece selection, Global unique piece table, Dynamic priority allocation
Acknowledgements
First of all, I would like to thank my adviser Prof. Ching-Hsien Hsu. My adviser is a conscientious, enthusiastic and wisdom scholar. He gave me a lot of suggestions and guidance for the thesis and taught me how to research and solve the issue, and his ideas inspired me throughout the thesis. He also gave me some directions for my life in the future. Especially, he gave me a large amount of encouragement when I met problems on the thesis and went to presentation in foreign country, I deeply appreciated his kindness. I am very fortunate and glad to be one of Prof. Hsu’s graduate students.
And I would like to thank Prof. Kuan-Ching Li, Prof. Chao-Tung Yang, Prof. Wuu Yang and Prof. Kung-Ming Yu (The names are in alphabetical order) to be my oral exam committees.
Also, I would like to thank Shih-Chang Chen, Tai-Lung Chen, Patrick Chen and Chia-Wei Chu of Department of Computer Science and Information Engineering.
They always gave me support and incentive when I worked hard on the thesis.
Finally, I would like to thank my parents very much who have been there to give me great support, showing tolerance toward me and giving me the wherewithal to get through these two years in school. And I would like to thank my advisor again that let me finish my thesis successfully.
Table of Contents
中文摘要... I Abstract...II Acknowledgements ... III Table of Contents ... IV List of Figures... VI List of Tables...VII
CHAPTER 1 Introduction ...1
1.1. Motivation... 1
1.2. Contribution ... 3
1.3. Thesis Organization ... 5
CHAPTER 2 Related Work ...6
2.1. BitTorrent Overview ... 6
2.2. Existing Studies on Cross-ISP Traffic... 9
2.2.1. Cache... 10
2.2.2. Gateway Peer ... 10
2.2.3. Biased Neighbor Selection...11
2.2.4. Oracle ... 12
2.2.5. P4P ... 12
2.2.6. Content Distribution Network... 13
2.3. Summary of the Existing Studies... 13
CHAPTER 3 Preliminaries ...15
CHAPTER 4 Peer Collaboration Strategy ...18
4.1. Biased Neighbor Selection... 18
4.2. Unique Piece Selection ... 20
4.2.1. Communication Message... 20
4.2.2. Global Unique Piece Table ... 23
4.2.3. Issue and Solutions of ISP Lost Pieces ... 26
4.3. Dynamic Priority Allocation ... 28
CHAPTER 5 Performance Evaluation ...32
5.1. Methodology ... 32
5.2. Performance Analysis ... 35
5.2.1. Using bandwidth limiting in original BitTorrent ... 35
5.2.2. Only using strategies... 36
5.2.3. Using strategies plus bandwidth limiting... 40
CHAPTER 6 Conclusions and Future Work ...42
References ...44
List of Figures
Fig. 1-1. The analysis and statistics of internet traffic by IPOQUE [1] ...2
Fig. 1-2. The analysis and statistics of internet traffic by Cisco [12]...2
Fig. 2-1. The framework of BitTorrent ...7
Fig. 2-2. The framework of cache ...10
Fig. 2-3. The framework of gateway peer ... 11
Fig. 2-4. The framework of biased neighbor selection... 11
Fig. 2-5. The framework of oracle [7]...12
Fig. 2-6. The framework of P4P...13
Fig. 4-1. Random neighbor selection vs. biased neighbor selection...19
Fig. 4-2. Peer communications with <bitfield> message in BitTorrent...22
Fig. 4-3. Peer communications with <have> message in BitTorrent...22
Fig. 4-4. Flowchart of unique piece selection...25
Fig. 4-5. Using global unique piece table as receiving <bitfield> message ...26
Fig. 4-6. Using global unique piece table as receiving <have> message ...26
Fig. 4-7. Static quota allocation...29
Fig. 4-8. Dynamic quota allocation vs. dynamic priority allocation...31
Fig. 5-1. Redundancy of each approach in homogeneous networks...37
Fig. 5-2. Download time in homogeneous networks...38
Fig. 5-3. Download time with 50 extra peers in heterogeneous networks...39
Fig. 5-4. Redundancy of each approach in heterogeneous networks ...39
Fig. 5-5. Redundancy of combining bandwidth limiting with 50 extra peers ...40
Fig. 5-6. Download time of combining bandwidth limiting with 50 extra peers ...41
List of Tables
Table 2-1. Comparison of previous approaches ...14
Table 4-1. Structure and information of communication message ...21
Table 4-2. Information of global unique piece table ...24
Table 5-1. Evaluation methodology and criteria ...34
Table 5-2. Only using ISP bandwidth limiting in the homogeneous networks ...36
CHAPTER 1 Introduction
1.1. Motivation
BitTorrent [2, 13] file sharing system has become the most popular application in recent years. The early P2P file sharing systems are like Napster [6], Gnutella [5] and eMule [4]. Unlike the client-server model, BitTorrent divides a file into a number of equal-sized pieces, where each peer simultaneously downloads and uploads via its neighbors that usually located in different Autonomous System (AS) managed by different ISP, which means using random neighbor selection. BitTorrent has the special character, which the more users join BitTorrent, the faster download rate.
Hence, file sharing creates a lot of BitTorrent traffic. The research [20] showed that BitTorrent generated a large amount of cross-ISP traffic (about 70%). Each peer’s neighbors are selected randomly from the tracker, which indicates that each peer cannot decide its neighbors from the same ISP as itself. Additionally, each peer often gets a lot of pieces from external peer [20]. Therefore, BitTorrent traffic has become a large number of cross-ISP traffic. ISPs often control BitTorrent traffic by bandwidth limiting for reducing cross-ISP traffic. However, bandwidth limiting will increase the file download time and worsen the user download experience, the fundamental concern of the ISP, which is to improve the locality of BitTorrent traffic. Fig. 1-1 shows the Germany Company Ipoque has elaborated the following statistics between 2008 and 2009. And Fig. 1-2 presents the Company Cisco has evaluated the following
was larger than others. Therefore, controlling P2P traffic is a challenge for each ISP.
Fig. 1-1. The analysis and statistics of internet traffic by IPOQUE [1]
12000
10000
8000
6000
4000
2000
0
Internet Video to TV Internet Video to PC VoIP
Video Gaming P2P Web/E-mail 14000
2005 2006 2007 2008 2009 2010 2011
Fig. 1-2. The analysis and statistics of internet traffic by Cisco [12]
Consequently, we wish to reduce cross-ISP traffic without decreasing system performance, and decrease the file download time for user, and decrease the cost through our approach. This is a win-win situation.
1.2. Contribution
In this thesis, we propose Peer Collaboration Strategy, which includes three parts.
First, we allow a peer choose a lot of its neighbors from internal ISP as itself, and only a few from external ISPs by modifying trackers and clients [10]. This conception is doing a similar grouping BitTorrent peers into clusters [11], let most of pieces of exchange rely on internal ISP, and only a few of pieces rely on external ISP, improving traffic locality in BitTorrent and reducing the times of file crosses the ISP.
Besides, the approach of modifying trackers and clients comes to Biased Neighbor Selection [10] without additional equipment. It not only conform our spirit that as economic as possible but avoid the equipment had a breakdown and a lot of cost.
Moreover, the Biased Neighbor Selection is key to the success of reduces cross-ISP traffic and rely on BitTorrent adopts the Local Rarest First (LRF) algorithm [13, 21]
as the piece selection strategy, where each peer downloads piece which is least replicated pieces among its neighbors.
The purpose of BitTorrent peers into clusters is to solve redundancy problem [10]
and it is valid for reducing cross-ISP traffic. Owing to each peer’s neighbors are selected randomly from the tracker, the redundancy is very high as start sharing file.
The optimal redundancy is 1 [10], which means each piece will only be transferred once to each ISP. Even if there is no backup mechanism, our goal in this thesis is to let redundancy down as low as possible (close to 1). We present Peer Collaboration
Strategy, the lower redundancy, inspired by FPFR [19] and MOB [11]. They are both multicast approach and there redundancies are 1. The distribution of MOB in grid is similar to BitTorrent. Unlike the BitTorrent, MOB adds teamwork among the nodes of a cluster to improve collaboration. BitTorrent employs incentive mechanisms such Tit-For-Tat (TFT) [13, 21] to improve ratio of upload. However, BitTorrent is based on the personal benefit. Many users always leave as finishing their download and some of users are free-riding [14, 22]. In order to avoid redundancy after using Biased Neighbor Selection, each peer needs to collaborate. For example, each peer downloads different piece from external ISPs and does not download the piece if it is in internal ISP already. However, we knew BitTorrent has no teamwork among peers according to the above-mentioned statement. Thus, we propose Unique Piece Selection for letting each peer know whether the piece in internal ISP or not to avoid downloading the piece, which is exist in internal ISP. Thus, second part of Peer Collaboration Strategy is that decreasing redundancy is close to 1. In Unique Piece Selection, we employ Advanced Tracker (AT) to maintain a list, which records the information of pieces owned by each ISP presently. Each peer knows whether the piece in internal ISP or not in terms of a list. If there is no that piece in internal ISP, then each peer gets the piece from external peer.
Peer Collaboration Strategy may cause some peers are waiting for the internal piece rather than external piece so as to increase the file download time. On the other hand, all the download process of BitTorrent, especially in the first piece scenario and last piece scenario, because of BitTorrent’s choke algorithm has paradox of supply and demand [17], which causes increasing the file download time. Finally, we propose Dynamic Priority Allocation to decrease the file download time.
Performance results show that our Peer Collaboration Strategy outperforms BitTorrent and previous approaches, decreases cost and cross-ISP traffic without
decreasing the system performance, and decreases file download time remarkably.
1.3. Thesis Organization
The rest of this thesis is organized as follows. In chapter 2, we will introduce an overview of BitTorrent and the relate work of cross-ISP traffic. In chapter 3, we will present the preliminaries. Our approach Peer Collaboration Strategy will be shown in chapter 4 and we give the performance evaluation in chapter 5. We conclude this thesis and our future work in chapter 6.
CHAPTER 2 Related Work
2.1. BitTorrent Overview
The BitTorrent P2P system has become the most popular sharing resources and Bram Cohen had written its kernel source code in 2002 [13]. Unlike the HTTP/FTP model, BitTorrent via Internet shared a large number of files without increasing the loading of publisher’s server and bandwidth. The performance of BitTorrent outperforms the traditional approaches remarkably. The main idea of BitTorrent is that each peer can simultaneously download and upload. Therefore, the download rate does not restrain by publisher’s upload bandwidth, and much more users join the torrent can supply more upload bandwidth. BitTorrent is that a shared file is divided into a number of equal-sized pieces (typically 256 KB in size), and each piece is split in sub-pieces (typically 16 KB in size) to avoid a delay among pieces being sent, and always keeping some number (typically 5) requests pipelined at once. Sub-pieces are the transmission unit on the network, but the protocol only accounts for transferred pieces. Each peer simultaneously downloads and uploads after get first piece from its neighbors, and each peer is a serve as well as a client. Therefore, BitTorrent can distribute the pieces quickly and it has a higher transfer rate than the traditional approaches, and it also does not increase the loading of publisher’s server.
Fig. 2-1 shows that the file download process of BitTorrent is as follows. (1) A user downloads a metadata file (called the torrent file) was generated by publisher from a web server, which contains IP address of tracker and the SHA-1 hash values of each piece, and the piece size and so on. (2) A user starts the BitTorrent client
software to join and contacts the tracker as a new peer. Tracker is s central server, which keeps track of all peers downloading the file. The new peer requests a part of peers from the tracker, which responds to the new peer with a list of randomly chosen peers (typically 50), then the new peer attempts to establish connection with these peers as its neighbors. (3) The new peer starts to exchange pieces with its neighbors.
BitTorrent let tracker keep an up-to-date state, and every 30 min each peer reports to the tracker its state. As shown in Fig. 2-1, the Seed is initial seed, which means the file publisher, and there are two types of Peer, namely leechers and seeders. Leechers also called downloaders, are peers who only have a part (or none) of the pieces of the file, which seeders are peers who have all pieces of the file. Leechers simultaneously download and upload pieces, and seeders only upload piece. A leecher turns into a seeder when it obtains all the pieces. At this moment, a seeder can leave BitTorrent or stay online to upload pieces continually. When the number of its neighbors dips below the threshold (typically 20), the peer again contacts the tracker to obtain a list of additional neighbors.
Peer Seed
TCP HTTP
Peer Peer
Tracker
Peer Peer
Fig. 2-1. The framework of BitTorrent
BitTorrent does not the central sharing resources, so it needs a great algorithm to improve fairness and optimizing the whole performance. BitTorrent adopts choke algorithm includes TFT and Optimistic Unchoke (OU) as the peer selection strategy, where each peer can upload pieces to five peers, so each peer has five upload quotas, among which each peer allocates four quotas for the TFT and the fifth for the OU.
Process of Choke algorithm as follows, every 10 seconds, a peer employs the TFT to evaluate which of its interested neighbors have been giving pieces to it with the high rates and the four highest peers are preferred to unchoke. Every 30 seconds, a peer employs OU to randomly unchoke from the remaining set of peers. OU allows bootstrap new peers and explores other peers that potentially upload to it with the higher rates. Existing BitTorrent employs the Static Quota Allocation to fixedly allocate upload quotas for the TFT and OU. The peer starts to send <request> message to request pieces when the other side sends <unchoke> message to it. How to choose the piece is also very important. A poor piece selection may cause the last pieces problem [13, 21] and let peers obtain the incomplete file, and furthermore it may cause the low download rate or increase the loading of upload peer. BitTorrent employs four strategies as piece selection as follows.
(1) Strict Priority: In BitTorrent, a complete piece is the exchange unit for file sharing, but sub-pieces are the transmission unit on the network. Hence, once a single sub-piece has been requested, the remaining sub-pieces from that particular piece are requested before sub-pieces from any other piece.
(2) Rarest First: Under this strategy, a peer downloads the piece, which is least replicated among its neighbors is chosen first. Even if there are no seeds in BitTorrent, the peer may get piece from its neighbors to avoid the last pieces problem.
(3) Random First Piece: If a new peer has nothing to upload and exchange, it is
important to get one piece as quickly as possible, and the new peer starts to employ the rarest first policy until it gets first piece.
(4) Endgame Mode: When a user has most of pieces already, which means only a few of pieces does not obtain, the peer sends requests for all sub-pieces to its neighbors. Cancels are sent for sub-pieces as one of its neighbors starts to upload the sub-pieces, to avoid redundant sends and the end of the file can download quickly.
As shown in Fig. 2-1, BitTorrent has two types of protocol, one is the connection between peers and tracker, its protocol is based on HTTP, and the other is the connection among peers, its protocol is based on TCP.
2.2. Existing Studies on Cross-ISP Traffic
There are many previous approaches to solve issue about cross-ISP traffic, some of them need higher cost of equipment, and P2P systems and ISPs need collaboration closely [6, 7, 8, 20, 25, 26], others only spend low cost and P2P systems collaborate with ISPs indirectly [10, 12]. The purposes of these approaches are improving the system performance as well as decreasing redundancy. In this thesis, a peer inside the same ISP we called internal peer, conversely, we called external peer.
2.2.1. Cache
In [6], positional at the gateway of ISP to the Internet, a cache stores pieces sent by external peers to internal peers, and as internal peer wants to get the piece from external peer, the cache interrupts and sends the copy to internal peer. Fig. 2-2 shows that the framework of cache. The following steps are the operation of cache.
Step 1: One peer requests external peer to get the file A.
Step 2: External peer transmits the file A to interested peer.
Step 3: Cache stores the file A.
Step 4: Another peer requests external peer to get the file A.
Step 5: Cache interrupts and sends the copy to internal peer.
Fig. 2-2. The framework of cache
ISP
1 2 3
5 4
2.2.2. Gateway Peer
Another approach is to employ the gateway peer [20], and it is the only peer inside internal ISP that can connect to external peers. But gateway peer needs high upload bandwidth to avoid increasing download time [10], and gateway peer needs to keep stable performance. Fig. 2-3 shows that the framework of gateway peer. Only the peer to be circled can connect to external peers.
ISP
Fig. 2-3. The framework of gateway peer
2.2.3. Biased Neighbor Selection
P2P traffic shaping devices [10] can intercept and modify the responses from the tracker to the peer, and let peers drive to Biased Neighbor Selection .Modifying trackers and clients is another approach [10], allows each peer to get most of peers from internal ISP, only a few from external ISP, and it is a direct and efficient approach. Using bandwidth limiting to control BitTorrent traffic is the simple and direct approach, but it is not efficiency. Fig. 2-4 shows that the framework of Biased Neighbor Selection.
Random neighbor selection Biased neighbor selection Tracker
Fig. 2-4. The framework of biased neighbor selection
2.2.4. Oracle
In [7, 8], ISP supplies an oracle service to users. ISP employs the equipment to manage each peer to avoid a lot of BitTorrent traffic. Likewise, users can obtain a great download rate. However, they need the user supplies the oracle with a list of possible neighbors, and then oracle ranks them according to certain criteria such as distance and bandwidth. Fig. 2-5 shows that the framework of oracle [7].
Oracle
Fig. 2-5. The framework of oracle [7]
2.2.5. P4P
P4P [25, 26] supplies the interactive interface to P2P system and ISP, allows ISP to manage the underlying physical network and supplies the real- time network to P2P system. Furthermore, it can integrate network command into P2P system, improving the network utility ratio and performance of P2P system. Fig. 2-6 shows that the framework of P4P. The following steps are the operation of P4P.
Step 1: One user queries appTracker.
Step 2: appTracker asks iTracker for guidance.
Step 3: iTracker returns suggestions.
Step 4: appTracker selects and returns a list according to the suggestions.
Step 5: ISP can monitor the status of peers in the control plane.
User appTracker
iTracker Monitor P4P
5
4 2 1
3
ISP
Fig. 2-6. The framework of P4P
2.2.6. Content Distribution Network
The Content Distribution Network (CDN) [12, 23] was a network device, which be used to speed up the original web server and decrease loading, and to drive Biased Neighbor Selection without collaboration between users and ISPs [12]. A peer only needs to have the ability to perform local Domain Name Server (DNS) queries for CDN names, and then it can find its neighbors.
2.3. Summary of the Existing Studies
These approaches are the same principle, which let BitTorrent peers into clusters
file download time and ISP does not employ bandwidth limiting to reduce cross-ISP traffic. However, various approaches need to be raised the cost of hardware except modifying trackers and clients and CDN [12, 23]. For example, Cache, P2P traffic shaping devices, Oracle service and P4P portal, and it needs the particular peer to have highest bandwidth and stable performance, such as gateway peer. In this thesis, our Peer Collaboration Strategy can reduce cross-ISP traffic without sacrificing system performance and is based on the premise that as economic as possible. Besides, our Peer Collaboration Strategy only needs to modify original framework of BitTorrent, and it does not need additional equipment. Performance results show that our Peer Collaboration Strategy can decrease redundancy and decrease the file download time efficiently.
We made some comparison of previous approaches in Table 2-1. We decided to let our approach is based on BNS because it has low cost and small loading, CDN has low cost and small loading, but it need to depend on the number of edge server in CDN.
And using CDN to find neighbors has complex operation and maybe slow (latency is weakly correlated with path distance and each peer requires to measure). Thus, we only compared with BNS. And there are some issues will be explained in chapter 6.
Table 2-1. Comparison of previous approaches
Approach Collaboration with ISP
Reducing
Cross-ISP Cost Loading Finding
Peer Cache
Gateway peer BNS
Oracle P4P CDN
directly directly indirectly
directly directly indirectly
excellent excellent
good good good good
high high low high high low
large large small large large small
sample sample sample complex complex complex
CHAPTER 3 Preliminaries
Generally, BitTorrent goes through three stages in its life: flash crowd, steady state and winding down [9, 16, 18, 24]. Among the three stages, flash crowd stage creates a lot of traffic and is the most challenging for ISPs to control, so we focus on the flash crowd stage in this thesis. We assumed that each peer leaves as finishing its download, only initial seed always stays online until terminating the simulation, and initial seed does not employ the Biased Neighbor Selection. In this thesis, the main evaluation criteria are redundancy and download time. Improving traffic locality can reduce cross-ISP traffic, but the lower redundancy, the lower cross-ISP traffic.
In chapter 2, we can find three problems about BitTorrent. (1) Each peer’s neighbors are selected randomly from the tracker, and file sharing creates a lot of BitTorrent traffic. (2) BitTorrent adopts the LRF algorithm as the piece selection, and it cannot avoid redundancy is increasing even if we solve problem (1). (3) The whole download process of BitTorrent in the first piece scenario and last piece scenario are both increasing the file download time, because of the choke algorithm the paradox of supply and demand exists in BitTorrent [17]. We present the Peer Collaboration Strategy as follows, and it has three parts, which solve the above problems.
(1) Biased Neighbor Selection (BNS): According to the above-mentioned statement, each peer’s neighbors are selected randomly from the tracker. Hence, file sharing may create a lot of cross-ISP traffic. ISPs employ bandwidth limiting in order to reduce cross-ISP traffic to decrease cost. Therefore, we may not have a great performance even if we use the high bandwidth. Some factors affect the
Likewise, ISPs also need to control BitTorrent traffic. In order to create a win-win situation, using Biased Neighbor Selection is a direct and efficient approach, and ISPs do not worry about the cross-ISP traffic all the time but users have a better download experience. We adopt the approach of modifying trackers and clients to finish Biased Neighbor Selection [10]. Modifying tracker we called Advanced Tracker (AT). When a new peer join the torrent. According to the new peer’s ISP, AT let the new peer chooses M-N neighbors from internal ISP as itself, and only N neighbors from external ISPs, where M is the maximum connection of peer, and N is the number of external peers. We set N = 1, which means each peer has at most one external peer.
(2) Unique Piece Selection (UPS): BitTorrent adopts the LRF algorithm as the piece selection. Even if BitTorrent had been employed the Biased Neighbor Selection, each peer may get the redundant piece, which means the piece had downloaded by some internal peer. Because BitTorrent only employs the LRF algorithm as the piece selection and is affected by choke algorithm. Our method as follows, we let AT maintain a table, and we called Global Unique Piece Table (GUPT). It records the information of pieces that owned by each ISP and peers can observe the GUPT to avoid downloading the redundant piece. Therefore, each peer get the piece from external peer is unique inside internal ISP every time. Internal peers can collaborate indirectly, and decrease redundancy significantly. Also, we present the two approaches to solve the problem that the paradox of supply and demand in terms of GUPT. We detailed introduce it in section 4.2.2.
(3) Dynamic Priority Allocation (DPA): In Unique Piece Selection, GUPT will probably make some peers are waiting for the inside piece rather than outside piece, so increasing download time. On the other hand, the whole download process of BitTorrent in the first piece scenario and last piece scenario are both increasing the file download time, because of the choke algorithm the paradox of supply and demand exists in BitTorrent [17]. The advantages of Dynamic Quota Allocation (DQA) [17] are preserved in our Dynamic Priority Allocation, and we let OU to be allocated quota to external peer, decreasing the file download time via optimizing the upload quota utility ratio. It is noted that we do not make the backup mechanism, Dynamic Priority Allocation lets each peer to upload more some pieces in terms of it follows the DQA, and it just decreases the chance of ISP lost pieces (fast distribution). Dynamic Priority Allocation can let pieces spread to different ISP as quickly as possible because we give external peer has a higher priority.
CHAPTER 4 Peer Collaboration Strategy
In this chapter, we present our Peer Collaboration Strategy (PCS). We explain how internal peers collaborate to each other indirectly in terms of showing whole framework and flowchart in section 4.1 and section 4.2. We propose an approach to decrease the download time in section 4.3.
4.1. Biased Neighbor Selection
The basic approach to solve the problem of cross-ISP traffic is grouping BitTorrent peers into clusters so as to reduce the connection of external ISP. In BitTorrent, each peer’s neighbors are selected randomly from the tracker, and most of neighbors spread to different ISPs. Hence, file sharing creates a lot of cross-ISP traffic.
Internal peers can let a lot of exchange inside internal ISP, and only unique piece rely on external peer after BitTorrent peers into clusters.
In order to let BitTorrent peers into clusters, we choose the approach of modifying trackers and clients to drive Biased Neighbor Selection [10], and this is a direct and efficient approach. Modified tracker we called Advanced Tracker (AT). When a new peer join the torrent, According to the new peer’s ISP, AT let the new peer choose M-N neighbors from internal ISP as itself, and only N neighbors from external ISPs, where M is the maximum connection of peer, and N is the number of external peers, and we set N = 1, which means the maximum number of external peer is one. In random neighbor selection, the number of external peers that a peer has on average is
in formula (1), where Pisp and Ptotal denote the number of peers in the ISP and the number of peers in the BitTorrent separately.
N = M × (1 － Pisp / Ptotal) (1)
Fig. 4-1 shows that the Biased Neighbor Selection is different from random neighbor selection. As shown in Fig.4-1, Biased Neighbor Selection reduces a lot of external connection significantly. Oppositely, random neighbor selection has many external peers that we can expect result via formula (1). Thus, it does not need additional equipment to drive Biased Neighbor Selection and conform to the principle of economic. Also, the redundancy will decrease.
Fig. 4-1. Random neighbor selection vs. biased neighbor selection
However, BitTorrent adopts the LRF algorithm as the piece selection. The rarest piece cannot present the unique piece inside internal ISP. Therefore, each peer has many chances to get redundant piece in external ISP even if BitTorrent peers into clusters already. The choke algorithm also acts the important roles, and they are keys to reduce the redundancy. In section 4.2, we propose Unique Piece Selection to restrain the redundancy efficiently. Let each peer get the piece from external peer is almost unique inside internal ISP every time, besides an exception. For instance about
probably no seeds or particular pieces in internal ISP, which represents ISP lost pieces happened. At that time, the peer needs to send request to external peer if initial seed is not in internal ISP. This exception will increase redundancy. Otherwise, our Unique Piece Selection can avoid increase redundancy efficiently.
4.2. Unique Piece Selection 4.2.1. Communication Message
First of all, we show some communication message to understand the basic principle before showing the framework of Unique Piece Selection. As shown in section 2.1, a new peer get a list of randomly chosen peers from tracker, then the new peer attempts to establish connection with these peers as its neighbors after a successful handshake and both peers will start communicating by sending messages to one another. Table 4-1 denotes structure and information of communication message and messages are in the following format：
<message_length> <message_type> <message>
(1) Message_length: Length of <message_type> plus length of <message>. It has a length of 4 bytes.
(2) Message_type: A one byte value presenting the type of message sent.
(3) Message: Depending on <message_type>, each <message> has its own format.
Thus, <message_length> will have different values as well. The following gives the relation between the <message_length>, <message_type> and <message>.
Note that <choke>, <unchoke>, <interested> and <not interested> do not have this field.
Table 4-1. Structure and information of communication message
Message Structure / Addition Information
keep-alive <0000>
Keep connection.
choke <0001><0>
No data will be uploaded until unchoking occurs.
unchoke <0001><1>
Tell his peer that his requests will be answered.
interested <0001><2>
Tell his peer that he has something to download from him.
not interested <0001><3>
Tell his peer that he does not want to download from him.
have
<0005><4><index>
Announce that he has successfully downloaded a piece of that index.
bitfield
<0001 + bitfield length><5><bitfield>
Sent at the beginning of each successful handshake. The bitfield represents the pieces that the client has. Each field is set to ‘1’ if it has the piece, ‘0’ if not. Note that peers can send a partial bitfield, i.e. bitfield contains ‘0’s and ‘1’s.
request
<000d><6><[index][begin][length]>
Request for a portion of a piece of that particular index, at offset
“begin” and of that length. “index”, “begin” and “length” each has 4 bytes.
pieces
<0009+block length><7><[index][begin][block]>
Send a portion of a piece of that index at offset “begin”. This corresponds to a REQUEST message sent by the recipient earlier.
“index” and “begin” each has 4 bytes.
cancel
<000d><8><[index][begin][length]>
Cancel an earlier request of a piece of that particular index, at offset begin and of that length. “index”, “begin” and “length”
each has 4 bytes. This is only sent at endgame. This is because at endgame, a client will send requests for all its remaining sub-pieces to all of its peers. Once a sub-piece arrives, the client will send CANCEL messages to all of its peers so as not to receive duplicate data and waste bandwidth.
Figs. 4-2 and 4-3 denote an instance of how peers may communicate in a BitTorrent separately.
TCP
Connection established
<bitfield>
<bitfield>
<interested>
<unchoke>
<request>
<piece>
peer1 peer2
Fig. 4-2. Peer communications with <bitfield> message in BitTorrent
<have>
<interested>
<unchoke>
<request>
<piece>
peer1 peer2
Fig. 4-3. Peer communications with <have> message in BitTorrent
4.2.2. Global Unique Piece Table
In section 4.1, we use AT to drive Biased Neighbor Selection. However, we find some scenario would increase redundancy after using Biased Neighbor Selection.
(1) LRF algorithm: The definition of rarest piece is least replicated among its neighbors [21], which indicates rarest piece is not unique except the rarest piece first travels into internal ISP. Once the rarest piece travels into internal ISP, which it had downloaded by internal peer, the redundancy will increase gradually. The LRF algorithm does not use to solve the problem of choosing unique piece rather than it uses local or global.
(2) Choke algorithm: If some peer is interested in internal peer and external peer simultaneously, the redundancy may increase via choke algorithm. For example, internal peer sends <choke> message and external peer sends <unchoke> message in terms of TFT. The redundancy will increase as the particular piece had been downloaded before.
(3) ISP lost pieces: Internal peer needs external peer to get some rarest piece again when ISP lost pieces happened, which was due to several peers may simultaneously leave and peers include seed or initial seed is not here. ISP lost pieces cannot prevent, besides the system uses the backup mechanism [6] or network coding [15]. The redundancy will increase deservedly when ISP lost pieces.
(4) Synchronal request: When there are no records on GUPT (in internal ISP, a piece had not been downloaded yet), internal peers may download pieces via external peers simultaneously because no records on GUPT for references.
We present the second part of Peer Collaboration Strategy is that we let
redundancy close to 1. Internal peers cannot collaborate to decrease redundancy according to (1)(2)(3)(4). Our Unique Piece Selection can solve (1)(2). We organize (3)(4) into exception because it cannot avoid the redundancy is increased in our strategy. We do not discuss the matter and allow the redundancy is increased in (3)(4).
In Unique Piece Selection, our method is that we let AT maintain GUPT to record the information of pieces that owned by each ISP. For example, Table 4-2 describes the information of GUPT that maintained by AT and the file is split in 10 pieces. From the left side to the right side expresses the piece index of ascending sort order in Table 4-2. Each field set to 1 if it has the piece, 0 if not. As shown in Table 4-2, ISP A has pieces of index[1], index[2], index[3], index[5] and index[7] presently.
Table 4-2. Information of global unique piece table
ISP Piece information
A 0 1 1 1 0 1 0 1 0 0 B 1 1 0 0 0 1 1 1 1 0 C 1 0 1 1 1 1 1 1 0 1 D 1 0 1 1 0 0 0 1 1 0 E 0 1 1 1 1 0 1 0 1 1
Initially, the file was allocated by initial seed and spread it around. When a peer has received <bitfield> or <have> message from internal peer, it does not check the GUPT and it only uses the incentive mechanisms of BitTorrent. When a peer has received the <bitfield> or <have> message from external peer, it checks the record of the particular piece whether it had been recorded on GUPT. If there is no record about the particular piece on GUPT, the peer sends <interested> message and waiting to be unlocked according to <unchoke> message sent by opposite side. Conversely, sends
<not interested> message directly to inform the opposite side, which indicates
inhibiting the redundancy. Every 10 seconds, the peer periodical checks GUPT whether particular piece was recorded. After the peer to be unlocked by the opposite side, one peer informs AT to record the particular piece on GUPT as it has done to request the piece. Fig. 4-4 depicts the flowchart of Unique Piece Selection and this scheme can prevent the redundant pieces from external ISPs except ISP lost pieces happened and synchronal request. Fig. 4-5 depicts the process of using GUPT to work as receiving <bitfield> message and Fig. 4-6 depicts the process of using GUPT to work as receiving <have> message.
Fig. 4-4. Flowchart of unique piece selection
<interested> or <not interested>
peer1 peer2
External peer?
If T Check GUPT
<interested> If F
<not interested> If T TCP
Connection established
<bitfield>
<bitfield>
If F
Fig. 4-5. Using global unique piece table as receiving <bitfield> message
<interested> or <not interested>
peer1 peer2
External peer?
If T Check GUPT
<interested> If F
If T
<have>
If F
<not interested>
Fig. 4-6. Using global unique piece table as receiving <have> message
4.2.3. Issue and Solutions of ISP Lost Pieces
In our approach, we have no backup mechanism in order to decrease cost, when ISP lost pieces happened, some internal peers only rely on external peer to get
particular piece from external peer except initial seed inside the same ISP. The issue is some peers cannot get particular piece from external peer because maybe one peer had recorded particular piece on GUPT before, but some particular pieces were really not here (ISP lost pieces happened) and we don’t clean the record, and peers thought particular piece was still alive, actually was not. As a result, according to Unique Piece Selection, peers always send <not interested> message to external peer. Thus, peers will never complete their download except initial seed inside the same ISP.
Therefore, ISP lost pieces happened, we have the following solutions.
(1) Peer does not consult GUPT: Generally, ISP lost pieces is due to several peers may simultaneously leave, and this situation let ISP lost some rarest piece. In addition, BitTorrent has a strategy. When the number of its neighbors dips below the threshold (typically 20), the peer again contacts the tracker to obtain a list of additional neighbors. If one peer get piece at once after reconnection, which presents that only locality lost pieces rather than whole ISP. But, if the peer has no any action in the long time, which indicates ISP lost pieces happened and the peer only depend on external peer to get particular piece (maybe external peer is a seed or lecher who has lost piece, even initial seed). Our method as follows, the peer does not consult GUPT anymore as the peer does not send any <interested>
message after get a list from AT again in 30 seconds, which indicates ISP lost pieces .
(2) GUPT records the number of piece: GUPT also record the number of each piece.
Our method as follows, each peer inform AT to count the number of piece as get the piece from internal ISP, and subtract the one unit with all pieces as leaves, if the number of some piece is zero, which indicates a peer can request the loss piece from external peer again.
4.3. Dynamic Priority Allocation
It is not difficult to find the issues in Unique Piece Selection scenario, which is GUPT, will probably make some peers are waiting for the inside piece rather than outside piece, so as to increase download time or ISP lost pieces happened. On the other hand, the previous studies showed that the whole download process of BitTorrent in the first piece scenario and last piece scenario are both increasing the file download time, because of the choke algorithm the paradox of supply and demand exists in BitTorrent [17]. Each new peer can only rely on the upload peer uses the OU algorithm to randomly upload to one of these new peers, which causes many new peers to be starving. Unfortunately, BitTorrent adopts the Static Quota Allocation, TFT cannot allocate pending upload quota to OU.
For example, in Fig. 4-7, the upload peer 0 has the interested peer set Pint = {1, 2, 3, 4, 5, 6, 7, 8}, consisting of the high return interested peer set Phigh = {2, 4} and the low return interested peer set Plow = {1, 3, 5, 6, 7 ,8}, consisting of the normal interested peer set Pnorm = {5, 6, 8} and the urgent interested peer set Purg = {1, 3, 7}, which involves the external interested peer set Pex = {3} and the internal interested peer set Pin = {1, 7}. As shown in Fig. 4-7, we can find the Static Quota Allocation has lower upload quota utility ratio by about 60%. In DQA, OU can adopt more upload quotas which upload quotas are located at pendency, to optimize the upload quota utility ratio by 100% and solve the problem that the paradox of supply and demand.
Fig. 4-7. Static quota allocation
Although there are two approaches to solve ISP lost pieces in Unique Piece Selection. We prefer to adopt the zealous approach to prevent ISP lost pieces. First, Dynamic Priority Allocation (DPA) adopts the strategy of DQA, which let the system allocate the piece to neighbors more quickly. DQA let each peer has a smooth, average and steady download time. The new peer follows procession to download, it can avoid most of peers download very slowly, and only a few of peers download very quickly.
It is easy to cause ISP lost pieces via several peers simultaneously leave. Each peer has a smooth download time, which indicates it has smaller standard deviation that the interval of the download time among peers. Thus, a large amount of seeds can be produce in a short time. Moreover, we preserve advantages of DQA that adopt a weight allocation scheme to adaptively allocate upload quotas for TFT and OU in our Dynamic Priority Allocation, and we let external peer had a higher priority to be allocated the quota of OU in terms of letting the different piece would be allocated to different ISP as quickly as possible and letting the strategy was suited to the condition (cross-ISP traffic).
Formulas (2) to (9) are the deduction of DQA. Q denotes the total upload quotas
Furthermore, it set Qou divided into Qurg and Qnorm. Qurg and Qnorm denote the upload quota for urgent peer and normal peer separately. They are allocated by the following formula：
=
H Phigh ⋅α (2)
L= Plow ⋅(1−α) (3)
L Q H Qtft H ⋅
= + (4)
L Q H Qou L ⋅
= + (5)
U=|Purg ⋅|β (6)
N=Pnorm ⋅(1−β) (7)
ou
urg Q
N U
Q U ⋅
= + (8)
ou
norm Q
N U
Q N ⋅
= + (9)
Where |Phigh| denotes the number of the set Phigh and |Plow| denotes the number of the set Plow. Likewise, |Purg| denotes the number of the set Purg and |Pnorm| denotes the number of the set Pnorm. α denotes the weight of Phigh and β denotes the weight of Purg, and we set α = 0.7 and set β = 0.8 in terms of Dynamic Quota Allocation, which means Phigh has a higher priority than Plow and means Purg has a higher priority than Pnorm separately.
We use formula (8) to allocate the urgent upload quotas Qurg divided into Qex and Qin. In formula (10)~(13), Qex and Qin denote the upload quota for urgent external peer and urgent internal peer separately. |Pex| denotes the number of the set Pex and |Pin| denotes the number of the set Pin. γ denotes the weight of Pex, and we set γ = 0.7, which means Pex has a higher priority than Pin. Fig. 4-8 depicts the comparison
between the Dynamic Quota Allocation and Dynamic Priority Allocation with α = 0.7, set β = 0.8 and γ = 0.7 corresponding to Fig. 4-7. As shown in Fig. 4-8(a), the upload peer 0 uses formula (2)~(5) to dynamically allocate the upload quotas Qtft = 2 for TFT and Qou = 3 for OU and uses formula (6)~(9) to allocate the upload quotas Qurg = 2 for the Purg and Qnorm = 1 for the Pnorm. Similarly, Fig. 4-8(b) shows that the upload peer 0 uses formula (2)~(5) to dynamically allocate the upload quotas Qtft = 2 for TFT and Qou = 3 for OU and with formula (6)~(9) to allocate the upload quotas Qurg = 2 for the Purg and Qnorm = 1 for the Pnorm, and adopts formula (10)~(13) to allocate the upload quotas Qex = Qin = 1 for the Pex and Pin separately. Dynamic Priority Allocation mainly solved the file download time because it let pieces spread to different ISP as quickly as possible in early phase and decreased the chance of ISP lost pieces, and improved the upload quota utility ratio.
E= Pex⋅γ (10)
I= Pin ⋅(1−γ) (11)
urg
ex Q
I E
Q E ⋅
= + (12)
urg
in Q
I E
Q I ⋅
= + (13)
Fig. 4-8. Dynamic quota allocation vs. dynamic priority allocation
CHAPTER 5 Performance Evaluation
This chapter presents our performance evaluation. First, we introduce our simulation environments and methodology, and then analyze our performance results to prove PCS is effectiveness.
5.1. Methodology
ISP traffic redundancy and download time are the main evaluation criteria in our simulation experiments. The term ISP traffic redundancy means the average number of times each piece crosses the ISP, until all peers inside the ISP finish their download.
The lowest redundancy is 1. The highest redundancy is Pisp, where Pisp is the number of peers inside the ISP. We use formula (14) and (15) to calculate the ISP traffic redundancy as follow：
ISP(i, redundancy) =
∑
= 1 -
0 j
1 n Tj
n (14)
ISP(avg, redundancy) =
∑
= 1 -
0 i
) ,
(
1n
redundancy
ISPi
n (15)
Where ISP(i, redundancy) denotes redundancy of ISPi and ISP(avg, redundancy) denotes average redundancy of total ISP. Tj denotes the number of times of piece j crosses the ISP, and n denotes the number of piece. Measurement of the file download time uses the Cumulative Distribution Function (CDF). We design a discrete event driven simulator for BitTorrent, which primarily simulates the peer behavior such as (1) peer
joining/leaving, (2) peer obtains a list and connects its neighbors, (3) piece transfer, (4) peer reports the tracker periodically, and the main incentive mechanisms such (5)choke algorithm, (6)LRF algorithm in the flash crowd stage. The framework of network consists of 14 ISPs, they assumed to be connected completely and we combine bandwidth limiting with our simulation environments. It is noted that we ignore the simulation of the underlying physical network characteristics such as propagation delay, congestion control and flow control, etc. This approach also assumes idealized performance of TCP, and does not model the dynamics and traits of TCP implementations. Each ISP has 50 peers, and we simulate 700 peers including 1 initial seed and use one tracker, and the initial seed bandwidth is 400Kbps and does not use Biased Neighbor Selection.
Our simulation environments examine two network settings, the upload/download bandwidth for peers (100Kbps/1Mbps) in the homogeneous network and the heterogeneous contain a high-bandwidth peers (we called extra peers) with the homogeneous, the upload/download bandwidth for extra peers (1Mbps/1Mbps) in the heterogeneous. We assume all extra peers have point-to-point links with each ISP and also with each other. Each peer leaves as finishing its download, only initial seed always stays online until terminating the simulation. The shared file with size of 64 MB is divided into 2000 equal-size pieces with each piece size 32KB. Each peer has five upload quotas, four quotas for the TFT algorithm and the fifth quota for the OU algorithm. In DPA, we set α = 0.7, β = 0.8 and γ = 0.7. BNS plus UPS and DPA are called PCS and we refer to the BitTorrent using random neighbor selection as original BitTorrent. Our simulation environments and previous approach [10] are the same because we primarily compare with it and the simulation had been running many times with a different initial seed for the random number generator for each
In Table 5-1, we let the above-mentioned make arrangement.
Table 5-1. Evaluation methodology and criteria
Item Content Evaluation criteria (1) ISP traffic redundancy (average)
(2) Download time (Cumulative Distribution Function) Average ISP traffic
redundancy ISP(avg, redundancy) =
∑
= 1 -
0 i
) ,
(
1n
redundancy
ISPi
n
Event driven simulator
(1) Peer joining/leaving
(2) Peer obtains a list and connects its neighbors (3) Piece transfer
(4) Peer reports the tracker periodically (5) Choke algorithm
(6) LRF algorithm
(7) 5 quotas (TFT and OU) (8) α = 0.7, β = 0.8 and γ = 0.7 Initial seed
(1) Do not use BNS (2) Always online
(3) Random number generator for each experiment
File information
(1) File size is 64MB
(2) File is split in 2000 pieces (3) Piece size is 32KB
(4) Piece is not split in sub-pieces
Ideal network
(1) No propagation delay (2) No congestion delay (3) No flow control
(4) Ideal performance of TCP Homogeneous
(1) 14 ISPs
(2) 700 peers (upload / download :100Kbps / 1Mbps) (3) Initial seed (upload : 400Kbps)
Heterogeneous
(1) Homogeneous plus 10,20,30,40,50 extra peers (2) Upload / download :1Mbps / 1Mbps
(3) Extra peers have point-to-point with each ISP and with each other (do not use BNS)
5.2. Performance Analysis
Our performance analysis has three parts: (1) only using bandwidth limiting in homogeneous networks, (2) only using strategies in homogeneous and heterogeneous networks, (3) strategies plus bandwidth limiting in homogeneous and heterogeneous networks.
5.2.1. Using bandwidth limiting in original BitTorrent
PCS compared with previous approaches in terms of redundancy and the file download time. In [10], we knew only using bandwidth limiting cannot restrain the redundancy and decrease the file download time. Table 5-2 shows that only using ISP bandwidth limiting in original BitTorrent in the homogeneous networks. As seen in Table 5-2, we set ISP bandwidth from 2.5Mbps to 500Kbps, the redundancy was still higher (about 21), and the redundancy were decreased only slightly between 1.5Mbps and 500Kbps. It appears that ISP bandwidth limiting cannot reduce cross-ISP redundancy anymore because it is constrained by the random neighbor selection and the download time increase 2.6 times. This is a lose-lose situation that we cannot only using bandwidth limiting in original BitTorrent. The performance will be better as long as we use the BNS that will be shown in section 5.2.2. We can get an expectancy of redundancy of using ISP bandwidth limiting in original BitTorrent in the homogeneous networks via using formula (16), where notations were defined by formula (1)(14). Our simulations almost match this analysis with 50 peers in ISP i and total ISPs are i-1.
Table 5-2. Only using ISP bandwidth limiting in the homogeneous networks
ISP bandwidth limiting Time ISP traffic redundancy No limiting
2.5Mbps 1.5Mbps 500Kbps
7932s 8675s 10891s 18738s
47.13 31.47 25.23 21.95
5.2.2. Only using strategies
Fig. 5-1 depicts the ISP traffic redundancy of each approach without using ISP bandwidth limiting in the homogeneous networks, which means only using strategies.
As shown in Fig. 5-1, the redundancy of original BitTorrent is about 47 (Pisp is 50, so the highest Redundancy is 50). It is noted that each peer almost downloads piece from external peer, it is a poor traffic locality inside the ISP. The redundancy is decreasing down to 4 immediately after the original BitTorrent uses the BNS. Our PCS is based on BNS and it combines with UPS, which indicates that peers can collaborate indirectly, so the PCS can keep the redundancy under 3. Factors of increasing redundancy are only ISP lost pieces and synchronal request. Our PCS has UPS strategy, so the redundancy is lower than original BitTorrent that only uses the BNS in the homogeneous. Moreover, we combine BNS and UPS with DQA and DPA separately to examine. These strategy are used to decrease download time, there is no effect upon the redundancy in this state except do not use BNS. Also, Fig. 5-1 shows that the redundancy is almost the same as the strategy adds DQA and DPA. The average redundancy of DPA is lightly better than DQA, the key is DPA can let pieces spread to different ISP as quickly as possible because of external peer has a higher priority, which indicates that each peer has a smooth, average and steady download
time to avoid a few of peers leave as finishing their download and ISP lost pieces happened (a key factor of increasing redundancy).
0 5 10 15 20 25 30 35 40 45 50
Approach
ISP traffic redundancy
A1:
A2:
A3:
A4:
A5:
BT BNS BNS + UPS BNS + UPS + DQA BNS + UPS + DPA (PCS)
3.13 2.67 2.41 2.38
A1 A2 A3 A4 A5
Fig. 5-1. Redundancy of each approach in homogeneous networks
Fig. 5-2 depicts the file download time of each approach in the homogeneous. We can find our PCS outperforms BNS. For example, in 4000s, the PCS has about 95%
peers completing all pieces while the BNS has only 3% peers. DPA is based on DQA, so each peer maintains smooth download time among all pieces includes in the first piece scenario and last piece scenario. As shown in Fig. 5-2, also we find the DPA and DQA allocate pieces quickly in the early phase, and each peer keeps smooth download time. Several peers finish their download simultaneously in a short time. They have a great performance about the file download time, and they are faster than BNS and original BitTorrent. Besides, DPA can let pieces spread to different ISP as quickly as possible because of external peer has a higher priority, DPA is faster than DQA by about 1.1 times and faster than BNS by about 1.6 times, and faster than original
0 0.2 0.4 0.6 0.8 1
0 2000 4000 6000 8000 10000 12000
Time (seconds)
CDF
BT BNS BNS + UPS BNS + UPS + DQA BNS + UPS + DPA (PCS)
Fig. 5-2. Download time in homogeneous networks
Also, we find BNS plus UPS has common performance because GUPT of UPS let peers waiting to get pieces from internal peers not external peer. Thus, the file download time of BNS plus UPS is slow than BNS.
Next, we study performance in heterogeneous networks. Fig. 5-3 shows that we contrast the download time of all approaches in heterogeneous networks. As shown in Fig. 5-3, the performance of all approaches in the heterogeneous networks outperform in the homogeneous networks due to extra peers have the high upload bandwidth, and our PCS has the fastest download time. We can find our PCS not only restrain the redundancy as we add extra peers from 10 to 50 in Fig. 5-4, but the download time of PCS still outperforms others in Fig. 5-3.
