On the Efficiency of Collaborative Caching in ISP-aware P2P Networks Jie Dai……Hai Jin et al. H.K.U.S.T. U.T. H.U.S.T. IEEE Infocom, Shanghai, China, April

On the Efficiency of Collaborative Caching inISP-aware P2P Networks

Jie Dai……Hai Jin et al. H.K.U.S.T. U.T. H.U.S.T.

IEEE Infocom, Shanghai, China, April 10-15, 2011

Presenter: Su Hu

Warm-up P2P: Overlay network

For the first 4 downloaded pieces,

the pieces are selected at random

Warm-up Challenges ISPs Tremendous data volume

Costly inter-ISP traffic

1) Not at the same layer

P2P Overlay

ISP Underlay

Internet access service

Application data

Warm-up Challenges ISPs 2) Users pay for bandwidth, why throttling ?

Shared bandwidth

bandwidth definition, local loop,

ADSL architecture ……

Profit

Outline1. Warm-up

2. Abstract

I. Introduction

II. Related Work

III. Inter-ISP Traffic Model & Cache Allocation

IV. Improving Cache with ISP Peering Agreement

V. Performance Evaluation

VI. Conclusion

VII. Summary

α, q, β, η, ISP index etc.

Abstract

Why Collaborative Cache 1) Reduce the inter-ISP traffic Existing design ignores: 1) Dynamic P2P traffic patterns, ISP peering, cache server

capacity ….

2) Analysis of resource allocation with awareness of Inter-ISP traffic and ISP policies

Abstract

Our work 1) Characterize inter-ISP traffic patterns

2) Develop cache allocation framework focus on minimizing inter-ISP traffic.

3) Incorporate both locality-aware/unaware & ISP peering agreements

The research help us understand1) Traffic characteristics of existing P2P

2) Design of collaborative ISP cache mechanisms

Outline1. Warm-up

2. Abstract

I. Introduction

II. Related Work




VI. Conclusion

VII. Summary

Introduction

Background 1: The Tussle 1) P2P: 70% of the Internet traffic

2) Can ISP throttle P2P packets?

3) ISP want to maintain customer bases

Background 2: How to resolve it1) Disparity

2) Locality-aware peer selection: P4P TopBT

3) vulnerable due to the dynamic of P2P

Proximity-driven biased neighbor select

Introduction

Our Solution- caching1) Web cache

2) Collaborative Caching lead to win-win:

Inter-ISP

Experiences of User

Cache for P2P

Redirect traffic to cache server at edges of ISP

Reduce the latency of P2P packet

Reduce access latencies to web page

Introduction

New Characteristics from web cache Mitigate the inter-ISP traffic

1) Inter-ISP traffic pattern, collaboration between P2P & ISP

2) Cache server resource allocation

3) ISP peering agreements

Both Storage (cache hit ratio) & bandwidth (server’s uploading capacity) constraints are important.

The collaboration between ISPs over the public Internet & corresponding cache server

Introduction

Propose a Optimization framework

1) Theoretical model of i-ISP traffic

2) Resource allocation scheme

3) The effects of ISP peering on our solution

4) Collaborative cache scheme tailored to ISP peering

Video distribution platform

ISP scales , channel popularity

Reduce i-ISP traffic both locality-aware/unaware peer selection

Positive on mitigation i-ISP traffic

Outline1. Warm-up

2. Abstract

I. Introduction

II. Related Work




VI. Conclusion

VII. Summary

Related Work

3 classes of ISP-friendly designPeer-driven

PPLive’s latency based mechanism, TCP ping ISP-drivenP4P: ISP advertise preferred paths to P2P app.

Why ISP caching?

Not impair the P2P robustness

Transparent to end user

Upon locality-aware system

Related Work

Existing P2P cache design Focus on independent server cache Improving the byte hit ratio Ignore ISP collaboration & cache server bandwidth

constraint Existing collaborative cache design

Dan’s work:

Rate allocation among cache servers

Ignore inter-ISP traffic model, practical constraints in real P2P

This paper: inter-ISP traffic model, server storage and bandwidth constraints,peer selection, ISP peering

Outline1. Warm-up

2. Abstract

I. Introduction

II. Related Work




VI. Conclusion

VII. Summary

I-ISP Traffic Model & Cache Allocation

A. Inter-ISP traffic model P2P video streaming locality-aware locality-unaware

B. Optimization framework of allocation resource Inter-ISP traffic mitigation Two sets of server strategies Collaboration between P2P app. & cache server


NotationP2P video streaming

A. Inter-ISP traffic model

video channels

: number of concurrent users in P2P v system

: number of concurrent users in video channel i

: streaming rate of video channel i

: size of video channel I

Assume streaming length is same, only depend on streaming rate

: in-degree of individual peers

Assume peer out-degree equals in-degree


NotationExisting ISPs

ISP1 is most popular, ISPk is lest popular


: number of ISP in which peers view video ?

: Storage capacity by cache server in ISP k

: uploading bandwidth by cache server in ISP k

: percentage of channel i stored in c server in ISP k

: uploading bandwidth to channel i by c server in ISP k

: number of concurrent users of channel i in ISP k


Channel popularity distribution

q

i

ISP user distribution

β = 0, same user amount each ISP

higher the β, more unbalanced the ISP user


P2P object be accessed over long term: Zipf-Mandelbrot distribution

(1)

the probabilitythe probability

(2) β: different scenarios of ISP user populations

Probability that any user view channel i

Probability that any user is in ISP k


Inter-ISP traffic rate model (n-c)

1. Locality-unaware peer selection

m ： number of neighbor in same ISP

Hyper-geometric distribution


(3)

(4)

Evenly selected, Neighbors decides mainly by ISP user numbers


H(n , M , N)

p(x=k) = C(k , M) * C(n-k , N-M) / C(n , N)

k= max(0 , n-N+M) , …… , min(n , M)

N – xi M – xik n – din


(5)

M defectives in N, extract n samples, and the probability of k defectives

p2p streaming server is the external sources.


Inter-ISP generate by channel I in ISP k:

1) more popular channel more inter-ISP traffic

2) ISPs have similar scales,

3) ISPs have widely different scales,


(6)


Inter-ISP traffic rate model (n-c)

2. Locality-aware peer selection

： number of persistent external links

A. Inter-ISP traffic model Give priority to nearby peer (evaluate by the ISP peer in)

i-ISP traffic per peer


(7)


Locality-unaware Locality-awareA. Inter-ISP traffic model

: 30 : 5-10

1. = 80%, both have similar inter-ISP traffic 2. -> 0 , both coefficients values -> 13. the left coefficients is always larger than the right


Inter-ISP traffic rate for ISP k:

B. Cache resource allocation mechanisms

(8)

Peers in any channel are evenly distributed along the channel ?

Minimize Subject to:

Maximize

Subject to:

≤ (9)

(10)


Theorem 1

For max i-ISP mitigation, optimal resource allocation:


(12)

(11)

(13)


Theorem 1

Proof:

Maximize

Subject to:


(14)

Continuous knapsack, solution:Non-decreasing with index

Use greedy algorithm , give storage as needed for channel with higher priorities, (11)

Achieve upper of as min (, ) using (12) , (13)


Theorem 1 Remark:

Design guidelines of collaborative cache mechanism:

1. P2P system parameters:

number of users, channel popularity, file size, streaming rate of channel

2. ISP cache server needs to collaborate with P2P app.


Reduce end-to-end latencies,Mitigate i-ISP prevents throttling by ISP

Precisely indentify the content requests of P2P packets needs help of P2P app.


Algorithm 1:

Optimization-based Collaborative Cache framework for i-ISP mitigation

1. P2P app. actively transmits system states to ISP cache server.

2. Compute , , allocate ,, as ,

3. Cache server cut request to external, if average uploading rate to channel , satisfy the request

4. Monitor P2P states, adjust resource according to T1.


Population-based I, Concurrent users x.

Outline1. Warm-up

2. Abstract

I. Introduction

II. Related Work




VI. Conclusion

VII. Summary

Improve Cache with ISP Peering Agreement

Concept ISPs provide free connectivity to transit user Alleviate costly transit traffic

2 positive outcomes Large group of traffic-free candidate neighbor Strategically select P2P content to store and deliver

ISP peering relation is Reflexive & Symmetric

A. ISP Peering Agreements

Free i-ISP traffic is not need to cache

(15) symmetric Matrix E


Not-full collaboration between peering ISPs Cache server not deliver to peers of peering ISP Locality-unaware peer selection

B. Impact of ISP Peering

(16)

Only peers in peering ISP help to mitigate i-ISP traffic, no collaboration between cache servers(5)

(17)


Not-full collaboration between peering ISPs Locality-unaware peer selection (cont.)

Locality-aware peer selection


(18)

Compared to (6), here need to also subtract the probability of being peering ISP



(19)

Multiply not


For both scenarios i-ISP traffic reduced due to expansion of free neighbor candidates.


(18)

(19)


Full collaboration between peering ISPs The bottleneck

One ISP’s cache server can’t store whole P2P object

-- Cache server bandwidth utilization insufficient Peering: combine of global cooperative cache Peering-based full collaboration

Upload rate for i rate of i-ISP can be intercept( )

C. Improving cache with ISP Peering

Cache server not only serve for peers in own ISP, but also to peering ISPs

: bandwidth assigned by to for channel i

<------


Full collaboration between peering ISPs

Maximize

Subject to:

C. Improving cache with ISP Peering

(20)

Any request to i can be served if sufficient bandwidth

(21)

Upper bound, Centralized solution, inappropriate for practice

Peering, resource, limit aik to serve max , propose a distributed collaborative cache scheme in algor 2

Improve Cache with ISP Peering Agreement Algorithm 2:

An ISP Collaboration-based Distributed Cache framework for i-ISP mitigation

1. Cache server announce surplus bandw and storage to peering ISPs.

2. After announce of , sorts channel in descending order of ,first channel , , bandw request to

3. Upon receive r from , allocates and confirm

4. After confirm of , evicts content confirm, reallocate to such , broadcast surplus info to peering ISP.

Outline1. Warm-up

2. Abstract

I. Introduction

II. Related Work




VI. Conclusion

VII. Summary

Performance EvaluationA. Trace-Driven Analyses

Statistical result of measurement on UUSee:

Number of channels: 993

(channel 100 has 100 users at peak time)

Number of concurrent users: 100000

To fit the cure of peak time users:

α = 0.78 q = 4 = 30 η = 5

B.Evaluation of Inter-ISP Traffic Pattern

Factors: P2P content popularity, ISP popularity

L-A(locality-aware) & L-U(locality-unaware)

Performance Evaluation

Fig.1.

B. Evaluation of Inter-ISP Traffic Pattern


Fig.2.

B. Evaluation of Inter-ISP Traffic Pattern

η


Fig.3.


Fig.4.

C. Evaluation of Collaborative Cache Mechanisms


Fig.5.



Fig.6.


Performance EvaluationD. Evaluation of ISP Peering Agreements

= 10 3 Peering Scenarios

1 ） Scenario 1:

1/2 3/4 … 9/10 extreme unbalanced

2 ） Scenario 2:

1/6 2/7 … 5/10 still has original property

3 ） Scenario 3:

1/10 2/9 … 5/6 extreme balanced


Fig.7.

D. Evaluation of ISP Peering Agreements


Fig.8.



Fig.9.


About percentage of 10 ISPs, so it can’t reach 1

Outline1. Warm-up

2. Abstract

I. Introduction

II. Related Work




VI. Conclusion

VII. Summary

Conclusion

Propose an inter-ISP traffic model Develop a cache resource framework under

resource constraint and peering agreement Put forward guidelines for cache storage and

bandwidth allocation design Strategy to improve collaborative cache under

ISP peering Future work: improving user experience

Summary

Review P2P overlay and challenge with ISP Review other existing ISP-friendly design Give the notation used in this slide Propose the inter-ISP traffic model Give the Cache resource allocation mechanisms Improve cache mechanisms with ISP peering Evaluation of our collaborative cache mechanism

Good Points

Propose the probability model, summarize the formulation of traffic under every strategy, formulate the optimization problem

Rational performance analysis based on experience data

Next : how to improve and implement it?

Documents

On the Efficiency of Collaborative Caching in ISP-aware P2P Networks Jie Dai……Hai Jin et al. H.K.U.S.T. U.T. H.U.S.T. IEEE Infocom, Shanghai, China, April