1

Insertion of ISP-owned Peer & Locality Awareness in BitTorrent

Ioanna Papafili, George D. Stamoulis, Sergios SoursosIoanna Papafili, George D. Stamoulis, Sergios SoursosAUEBAUEB

EuroNF workshop, AthensEuroNF workshop, AthensOctober 16-17, 2008October 16-17, 2008

2

Outline

• BitTorrent Optimization Potential

• Incentives for All Players

• Simulations

• Results

• Conclusions

• Open Issues

3

BitTorrent Optimization Potential

4

Problem & Objectives

• BitTorrent responsible for great amount of traffic– Implies great cost for ISPs in terms of interconnection agreements

• Choking algorithm: tit-for-tat principle for social fairness

• Exploit tit-for-tat to achieve performance improvements in terms of– Reduction of inter-domain traffic– Reduction of end-users completion times (if possible…)

5

Insertion of ISP-owned Peers (I)

• Idea: Insertion of ISP-owned peers (IoPs) – Controlled by the ISP– Equipped with high download / upload capacity – Equipped with large storage space– Participate actively in the swarm– Run the overlay protocol– More unchokes available than regular peers– Only licensed content due to legal issues

• Worst case: IoP initially has no content• Best case: Content is downloaded only once per ISP

• Clarification: “IoP insertion is not insertion of a cache combined with interception of peer’s messages”

6

Insertion of ISP-owned Peers (II)

• Motivation: “Reduce inter-domain traffic while maintain good peer performance or improve it if possible”

• Issue #1: IoP also selected from peers outside the ISP– Due to high upload rates & tit-for-tat mechanism– As a result extra egress inter-domain traffic generated

• Issue #2: Increase intra-domain traffic– In same cases means increase of costs for the ISP

7

Insertion of ISP-owned Peers (III)

• IoP preferred by local peers in1. Pure BT network: due to ‘tit-for-tat’ mechanism2. Locality-aware BT network: due to locality mechanism*

* R. Bindal, P. Cao, W. Chan, J. Medval, G. Suwala, T. Bates, A. Zhang, “Improving Traffic Locality in BitTorrent via Biased Neighbor Selection”, 26th IEEE International Conference on Distributed Computing Systems, p. 66, 2006

ISP 1

ISP 2

: inter-domain link: intra-domain link: overlay link

8

Incentives for All Players

9

Incentives

• ISP– Reduction of ingress inter-domain traffic– Reduction of interconnection costs– Improvement of customers’ QoE– What about intra-domain costs?

• Content Provider– Improvement of customers’ QoE– Possible interconnection agreement with ISP?

• End-Users– Transparent to the end-users

10

Simulations*

* K. Eger, T. Hoßfeld, A. Binzenhöfer, G. Kunzmann, "Efficient Simulation of Large-Scale P2P Networks: Packet-level vs. Flow-level Simulations", 2nd Workshop on the Use of P2P, GRID and Agents for the Development of Content Networks (UPGRADE-CN'07) in conjunction with IEEE HPDC, Monterey Bay, USA, June 2007

11

Scenarios (I)

1. Pure BT 2. Locality-aware BT3. BT with Insertion of ISP-owned peer4. LA BT with Insertion of ISP-owned peer

• Symmetric or Asymmetric– Symmetric: 25 peer per AS, e.g. 2 Tier-4 ISPs– Asymmetric: 35 and 15 peers in each AS, e.g. Tier-3 and Tier-4 ISPs respectively

• All-together or Split– All-together: Joining time of all peers ~U(0,10)– Split: Joining time of 5 peers in each AS ~U(150,300), whereas joining time of the

rest of the peers in each AS and the ISP-owned peer ~U(0,10)

12

Scenarios (II)

Insertion of IoP in BitTorrent without locality awareness

Insertion of IoP in BitTorrent combined with locality awareness

13

Simulation parametersDescription Value

Number of peers 50

Number of seeds 1

Number of ASes 2

Number of peers per AS (25,25), (35,15)

Upload capacity of regular peers 512K

Download capacity of regular peers 4096K

File size 20M

Number of peers requested from tracker (Size

of tracker’s list)

25

Number of local peers replied by tracker 20

Number of connections 20

Choking interval 10

Number of unchoked connections permitted

per peer

4, 10 (in case of IoP)

Number of ISP-owned peers 1

Upload/download capacity of ISP-owned peers 40960K

@ AS 0

@ AS 1

14

Results

15

Insertion of IoP without LA (Symmetric, All-together) – Ingress inter-domain traffic

• Important reduction – up to 30% - of ingress inter-domain traffic to AS 1• Similar results apply for symmetric and asymmetric, and all-together and

split cases

16

Ingress inter-domain traffic (Symmetric, All-together)

• Up to 30% reduction for both Ases when only LA is employed• Up to 60% reduction for AS1 when IoP is also inserted in the LA BT• As expected ingress inter-domain traffic of AS 0 is increased, however it is

still less than the pure BT case

17

Ingress inter-domain traffic (Asymmetric, All-together)

• Up to 15% reduction when only LA is employed• Up to 45% reduction for AS1 when IoP is also inserted in the LA BT• However, the ingress inter-domain traffic for AS 0 (no IoP) is increased up

to 30% compared to pure BitTorrent!

18

Completion Times – Symmetric case

• Up to 10-15% improvement of all peers’ completion times by IoP• Up to 35-40% improvement especially for peers that join the swarm later

than the IoP (peaks)

19

Completion Times – Asymmetric case

• Similar results as in previous case

20

Conclusions

21

Conclusions

• ISP deploying only locality awareness risk to lose customers because of completion time deterioration

• The insertion of IoP improves both ingress inter-domain traffic and peers’ completion times for the AS that deploys the extra peer

• Consequently:– Interconnection agreement may be modified in favor of the AS that

deploys the extra peer – The AS does not risk losing customers, on the contrary it may attract

new ones

22

Open Issues

23

Possible Issues for Future Research

• Asymmetric case & IoP increased ingress inter-domain traffic for AS 0 – Is there an incentive for AS 0 to introduce an IoP as well?– Study how the results will be affected

• So far: One swarm & one IoP– Variations: One swarm and multiple IoPs / Multiple swarms and multiple

IoPs– Tradeoff: extra performance improvement vs. extra resources– How many IoPs?– How do their total resources scale?

• So far: Fixed peer population & only 1 file per simulation– New assumptions: peers leave/enter the swarm, more files exchanged

• Study how interconnections agreements are affected!– E.g. under the 95th percentile charging scheme

24

Legal issues

• Copyrighted content in ISP’s premises

• Interconnection agreements with content providers?

• Other idea: Enhance regular peers’ upload capacity– Choose highly active peers and increase their upload (and/or download)

capacity instead of inserting ISP-owned peers

• Incentives for All Players:– Highly active peers: Get better service at no extra cost– Other peers: Experience better QoE– ISP: Achieves reduction of inter-domain traffic without facing legal issues

since the content is not stored in its premises!

25

Thank you!

Questions?

26

Back up

27

Related Work

28

Topology Awareness

• Issue: Tracker replies a random list of peers to each peer’s request!– Inefficient use of the underlay– Affects also the performance of the overlay

• Idea: Alternative peer selection at the tracker– Apply a proximity criterion

• Potential proximity criteria: Autonomous System, number of hops, Round-Trip-Time, congestion, price

• Topology information must be available to the tracker– Information provided by the underlay– Or by the peers themselves – Incentives to be truthful?

29

Locality Awareness

• Proximity criterion: Autonomous System• Tracker’s reply list comprises of (Bindal et al.*):

– K out of N peers selected within the same AS with the requesting peer– N-K selected from other ASes

• Important reduction of ingress inter-domain traffic is achieved• No improvements on peer’s completion times are observed

– For some peers the completion time is increased!

* R. Bindal, P. Cao, W. Chan, J. Medval, G. Suwala, T. Bates, A. Zhang, “Improving Traffic Locality in BitTorrent via Biased Neighbor Selection”, 26th IEEE International Conference on Distributed Computing Systems, p. 66, 2006

30

Simulator

31

bittorrent.patch* for the ns-2 simulator

• BitTorrent-like protocol, functions simplified• Four classes implemented: Application, Tracker, Connection,

Message• BitTorrent implementation is modular; e.g. peer and piece

selection algorithms can be replaced by alternatives• Network model:

– FullTCP: bidirectional data transfers– Uplink is assumed to be the bottleneck in the whole network– Downlink is neglected

* K. Eger, T. Hoßfeld, A. Binzenhöfer, G. Kunzmann, "Efficient Simulation of Large-Scale P2P Networks: Packet-level vs. Flow-level Simulations", 2nd Workshop on the Use of P2P, GRID and Agents for the Development of Content Networks (UPGRADE-CN'07) in conjunction with IEEE HPDC, Monterey Bay, USA, June 2007