28
Performance Modeling and Engineering Issues of BT-Like File Sharing Systems M.H. Lin, John C.S. Lui, D.M. Chiu The Chinese University of Hong Kong

Performance Modeling and Engineering Issues of BT-Like File Sharing Systems M.H. Lin, John C.S. Lui, D.M. Chiu The Chinese University of Hong Kong

  • View
    217

  • Download
    3

Embed Size (px)

Citation preview

Performance Modeling and Engineering Issues of BT-Like File

Sharing Systems

M.H. Lin, John C.S. Lui, D.M. ChiuThe Chinese University of Hong Kong

P2P Systems

• Many interesting and important services:– File sharing (e.g., BT, Gnutella,..etc)– P2P live streaming (e.g., PPLive, PPStream,…etc)– P2P-VoD streaming

• A scalable and robust paradigm• ISPs call it a “distributive technology”

– Users have control about routing– Mess up the underlying traffic engineering

Qiu[Sigcomm’04], Bin[ICNP’06]Massoulie[Sigmetrics’05]Lin[Performance’07]

Huang[Sigcomm’08]

P2P Traffic Trends (by CacheLogic Inc.)

* Over 66% of P2P users traffic and …. growing

Reasons for growth: economics

Volume-basedCharging

Flat-ratecharging

Reasons for growth: economics

CPs reduce theiroperating cost

Users have goodservice & performance

Overview of BitTorrent Protocol

• Find the file you want to download• Contact tracker, which returns a subset of peers• The file is divided into chunks

– Exchange chunk with different peers– Chunk selection: rarest first– Incentive mechanism: tit-for-tat

• Since peers are selected randomly, it causes a lot of inter-ISP traffic

ISP’s problem• Increase in traffic implies increase in operating

cost– Need to increase their capacity– Need to pay for the cross-ISP traffic

• P2P traffic affects other applications• More traffic, but can’t get any profit.• ISPs don’t want to “kill” or “filter” P2P• What ISPs want:

– More money, of course – Reduce operating cost

Potential Solutions

• ISPs shape P2P traffic by blocking known port– But P2P uses dynamic port

• ISPs use high performance router to inspect packets– But P2P encrypts the payload

• ISPs use ``behavioral” to detect– Still under study, can it be counter by P2P?

• ISPs cache the traffic– Copyright and legal issues

Previous approach

• ISPs guide peers when choosing neighbors– Proposal by Bindal (ICDCS’06) and Aggrawal

(CCR’07)– P4P (Sigcomm 2008)– Use CDN (Sigcomm 2008)

• Peers and ISPs have to trust each other• It relies on the services of others, e.g., CDN• Security concerns.

To Exploit Locality …

“Exploit-the-Locality Principle” (ELP):Never download information from peers in other ISPs if there exist at least one copy of the information among peers in the same ISP.ELP aims to establish a happy/tolerant relationship between P2P users and ISPs. Users will be happy to use P2P applications and they do not cost too much to ISPs.

How Large is the Cross-ISP Traffic?It depends on the specific implementation.

Let us consider the bounds.

The remaining question is how to uncondition the number of peers and their downloading progress for a given ISP.

Scenario I: Regular Arrival

Assumptions Peers arrive according to a Poisson process. Peers are all persistent in the sense that they will not abort

before they finish the file download. Peers depart immediately when finish downloading. There exist some “seeders” to ensure file availability. Downloading rate for a given peer is independent of its

downloading progress. (ignoring the last piece problem)

Then we can use M/G/∞ model to uncondition the number of peers and their downloading progress.

Scenario I: Regular Arrival

Scenario I: Regular Arrival

Scenario II: Flash Crowd Based on the same assumptions in the regular arrival analysis,

except that peers arrival process is no longer Poisson. At time t = 0, n peers arrive and there is no more peer arrival

after t > 0. Let τmin (τmax) be the shortest (longest) downloading time of these peers.

Theorem 4: The average amount of incoming cross-ISP traffic caused by each peer under flash crowd, denoted by E(d), is bounded by

(Proof omitted, the basic idea is to classify peers based on downloading rate.)

Designing ISP-friendly Protocol One design requirement of our protocol is that it has

to be “compatible” with the current BitTorrent. This feature is important since ISPs may want to have an incremental deployment of this new service.

There are many details in our protocol, but the basic idea is quite simple: A peer will not download a chunk from external neighbors if he finds that this chunk is held by some internal neighbors.

Some Details of the Protocol

Some Details of the Protocol

Experiments on PlanetLab Clients:

Official BT: BitTorrent-4.4.0 ISP-friendly BT: Modified BitTorrent-4.4.0 Using default settings for bandwidth limits.

Each university as one “ISP”. We have six “ISPs”: Berkeley (16 nodes), Princeton (11 nodes), MIT (7 nodes),

Cornell (6 nodes), Columbia (3 nodes), OTHER (32 nodes) Four sets of experiments:

(official BT, ISP-friendly BT) × (regular arrival, flash crowd)

Official BT, Regular ArrivalF= 1-n/N

ISP-friendly BT, Regular Arrival

Official BT, Flash Crowd

ISP-friendly BT, Flash Crowd

Observations Cross-ISP traffic of the official BT is similar to that of

the completely random neighbor selection. ISP-friendly protocol can significantly reduce cross-

ISPs traffic. Download time of the ISP-friendly BT is slightly larger

than that of the official BT. Seeder may remain idle. Locality policy may reduce performance (e.g., download

time) the impact will be reduced if there are more peers within

an ISP. Experiment curves may exceed the upper bound:

Each peer may not be connected to all internal peers. The piece availability information cannot be updated

instantaneously.

Black Hole Security Attack Consider a free-rider who advertise it has a lot of

chunks but it refuses to provide any upload service to other peers.

This type of free-riders do exist in BitTorrent. They download slowly via the “optimistic unchoked”.

But to the ISP-friendly protocol, they prevent other internal peers to obtain information from external peers.

They may halt the whole file download process within the ISP.

We call this the “black hole attack”

Black Hole Security Attack We need to provide some mechanism to filter out

the attackers or peers with very low uploading rate. Our approach:

Each peer picks a subset of its internal peers and considers them as its “active co-agents”.

A peer will not download a chunk from external neighbors if it finds that this chunk is held by its “active co-agents”.

How to pick “active co-agents”?The internal peers who upload to you recently.

Random selection !!

Enhanced ISP-friendly Protocol under Regular Arrival

Summary We use a simple and effective idea: exploit the

content locality to reduce the traffic. We analytical show the significant cross-ISP traffic

reduction when one uses ELP. We design and implement such mechanism on a BT

software, carry out extensive experiments and measurements on the PlanetLab to demonstrate its effectiveness.

Lastly, we illustrate the black hole security attack and how one can modify the proposed protocol to address this problem.