Download S11Hossfeld, Towards Efficient Simulation of Large

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Transcript
University of Würzburg
Informatik III (Distributed Systems)
Prof. Dr. P. Tran-Gia
Towards Efficient Simulation of
Large Scale P2P Networks
Tobias Hoßfeld
www3.informatik.uni-wuerzburg.de
ITG-Fachgruppe 5.2.1
“Cooperating and Scalable Networks”
Aachen, Ericsson, J. Sachs, 04.05.2006
 Resource mediation
where are files located
 Resource access control
who may download a file and
when

Mapping of P2P architectures into
architectural space
 pure P2P
 hybrid P2P
 classic client/server
X ChordPur
usere
oriented
P2P
X Gnutella
domain
P2P X eDonkey
Cartography
operatorcentric
domain
centralized
Two control functions in P2P systems
resource mediation

decentralized
Cartography of P2P Architectures
Client/
Server
centralized

Identification of control objectives
University of Würzburg
Distributed Systems
X BitTorrent
decentralized
resource access control
T. Hoßfeld
2
Peer-to-Peer Architectures
Information
Seeker
Information
Provider
Information
Mediator
Information
Provider
Information
Seeker
Unstructured P2P-Network (Gnutella)
Structured P2P-Network (Chord)
Web-Server
Index
Index
Information
Mediator
Information
Mediator
Hybrid P2P-Network (eDonkey)
University of Würzburg
Distributed Systems
Tracker
BitTorrent
T. Hoßfeld
3
Basic Functions of P2P Networks

join()
knows
one peer
new node
contacts
bootstrap
server
position in the P2P
network according
to the structure:
self-organization
University of Würzburg
Distributed Systems

leave()
peer informs its
“neighbors” and
bootstrap server
bootstrap
server
node failures detected
by periodical updates or
not answered requests:
resilience
T. Hoßfeld
4
Basic Functions of P2P Networks (contd.)

insert(key,data)
x
peer x wants to insert
(key,data); using DHTs:
key = hash(data)

retrieve(key)
x
key routes to peer y
which stores data
y
peer x searches for key
and asks its neighbors
which redirect requests
y sends data to x
y has (key,data)
y responsible
for (key,data)
structure assigns
responsibility for data
based on hash
function:
load balancing
University of Würzburg
Distributed Systems
performance improved
by using shortcuts
according to the known
structure for a given key:
scalability
T. Hoßfeld
5
Basic Function of P2P Content Distribution



Main feature is multiple source download.
Peers issue several download requests for the same file to
multiple providing peers in parallel.
Providing peers serve the requesting peers simultaneously.
providing
peer
downloading
downloading
peer
1
and
providing
peer 1
After successfully
downloading a whole
chunk, it is provided to
other peers.
downloading
peer 2
index server #2
index server #1
providing
peer
providing
peer
University of Würzburg
Distributed Systems
T. Hoßfeld
6
Features of P2P Systems and Their Implications






Usually a large number of participating peers
Large-scale: a lot of nodes and even higher number of resources
need to be simulated
Target of Workshop:
Focus on large-scale P2P
Peers may arbitrary
join or leave
networks
in order to consider
characteristics
Highly dynamic:key
a lot
of user created event (due to churn, i.e.
regarding
churn
peers joining and(e.g.
leaving
arbitrarily,
asfor
key100
feature of P2P systems)
peers reasonable?)
Cooperative working of peers and robust systems
Complexity:
 one event can cause a large number of events at other peers,
i.e. system events, due to cooperation among peers
 additionally periodic or provisional systems event to cope with
the self-organization of p2p systems
University of Würzburg
Distributed Systems
T. Hoßfeld
7
Approach For Simulating Large-Scale P2P Systems






System state has to be stored at simulation machine
requires efficient data structures (e.g. calendar queue)
How to model in order to reduce the number of events?
 Resource mediation might not require to model bandwidth,
only signalling delay
 Resource exchange might not require to model delay if large
contents are exchanged; requires modelling of bandwidth
 other performance influence factors: packet loss, moving
users, …
appropriate abstractions & models for investigated application
Clustering of peers to user groups...
might allow parallel simulation of clusters
University of Würzburg
Distributed Systems
T. Hoßfeld
8
Workshop in Würzburg

Efficient Data Structures
 Andreas Binzenhöfer, Calendar Queue and Event Design
Algorithms
 Jens Oberender, Modelling Resource Fragmentation

Abstractions and Models
 Kolja Eger, Packet-based Simulation
 Gerald Kunzmann, Signaling in Voice/Video over IP Systems
 Daniel Schlosser, Tobias Hoßfeld, Periodic and Market-Based
Bandwidth Allocation

Parallel Simulation
 Ivan Dedinski, Parallel Discrete Event Simulation
University of Würzburg
Distributed Systems
T. Hoßfeld
9
Talks Today
Kolja
Eger
Compact
Data Structures
adapted
Andreas
Binzenhöfer
unoptimized
detailed
Hier könnte Ihr
Name stehen !
Gerald
Kunzmann
Tobias
Hoßfeld
Modeling
Resource Mediation
abstract
University of Würzburg
Distributed Systems
abstract
detailed
Modeling
Resource Access Control
T. Hoßfeld
10
University of Würzburg
Informatik III (Distributed Systems)
Prof. Dr. P. Tran-Gia
Periodic and Market-Based
Bandwidth Allocation in
eDonkey Networks
Tobias Hoßfeld, Daniel Schlosser
www3.informatik.uni-wuerzburg.de
Measurements of eDonkey Traffic

Case-by-case measurements of eDonkey file-sharing application
in public GPRS/UMTS network
Multiple source download via GPRS
45
downloading peer (mobile)
sharing peer #1 (mobile)
sharing peer #2 (fixed)
40
35
throughput [kbps]

30
25
20
15
10
5
0
0
5
University of Würzburg
Distributed Systems
10
15
time [min]
20
25
30
T. Hoßfeld
12
eDonkey Data Exchange via UMTS
5
5
4
fixed downloading peer
fixed sharing peer #1
mobile sharing peer #2
3
data [MB]
data [MB]
4
2
1
mobile downloading peer
fixed sharing peer #1
mobile sharing peer #2
3
2
1
0
0

2
4
6
time [min]
UMTS upload restricts
throughput
8
0
0
10

5
10
15
20
time [min]
25
30
UMTS download restricts
throughput

Max-min-fair share of available bandwidth is observed
 How to model the bandwidth allocation of fair-share P2P file-sharing
applications?
University of Würzburg
Distributed Systems
T. Hoßfeld
13
Simulation of Fair-Share Bandwidth Allocation
Events which influence the bandwidth allocation are that a peer…
 starts the download of a file
 finishs a download
 goes offline while downloading
 continues downloading a file after joining the network again
 We consider eDonkey-like file-sharing networks

Events
t
Dt
Dt
Dt
Dt
Dt
Dt
Dt
Dt
Dt
Dt
Dt
Computation of
allocated bandwidth

t
Aim: Modeling of bandwidth allocation in fair-share networks
University of Würzburg
Distributed Systems
T. Hoßfeld
14
Stream-based or packet-based approach?

TCP can be neglected if conditions are fulfilled (540 kB blocks)
Signaling vs. data exchange: RTT vs. bandwidth
400
350
RTT = 100ms
RTT = 200ms
RTT = 300ms
300
goodput [kbps]

250
200
150
100
50
0
0
50
University of Würzburg
Distributed Systems
100
150
200
250
downlink bandwidth [kbps]
300
350
400
T. Hoßfeld
15
What means fair-share?


All peers get the same bandwidth
If a peer cannot consume completely the allocated bandwidth, the
surplus is distributed among the remaining peers
Peer 3
11 kbps
11 kbps
3 kbps
Peer 2
3 kbps
uploading
Peer 1
40 kbps
Peer 4
20 kbps
University of Würzburg
Distributed Systems
13 kbps
13 kbps
Peer 5
40 kbps
T. Hoßfeld
16
Periodic Bandwidth Allocation

For each Dt, for each peer: compute bandwidth allocation
Peer 3
Peer 2
Peer 1
Peer 4
University of Würzburg
Distributed Systems
Peer 5
Allocated bandwidth
can be overbooked
or underbooked
T. Hoßfeld
17
Market-Based Bandwidth Allocation

For each event, consider affected, i.e. connected, peers

All affected peers make a bid

Strategy
 If there are no other bids, propose
x = not allocated bandwidth / #peers
 If minimal bid y of all affected peers is smaller than x, then
keep bid y and compute x‘
 If all bids are larger than x, then bid x on these connections
 Finish: If lower bid of a connection is the minimal bid of a peer
and is repeated
University of Würzburg
Distributed Systems
T. Hoßfeld
18
Market-Based Bandwidth Allocation
Downloading
network links
Uploading
network links
3.333
20
NL3: 40kbps
15
NL4: 30kbps
NL0: 10kbps
NL1: 10kbps
5
10
NL5: 10kbps
5
NL2: 80kbps
NL6: 10kbps
20
10
NL7: 10kbps
Initial bid: x = BW / #peers
University of Würzburg
Distributed Systems
40
NL8: 40kbps
T. Hoßfeld
19
MBBA Example
Downloading
network links
Uploading
network links
3.333
NL0: 10kbps
20
15
3.333
NL3: 40kbps
NL4: 30kbps
26.667
NL1: 10kbps
NL2: 80kbps
5
25 5
25
20 25
10
5
3.333
6.667
NL5: 10kbps
NL6: 10kbps
10
NL7: 10kbps
If minimal bid y of all connected peers
holds y<x, then set bid y and compute
x‘ x = BW / #peers.
40
NL8: 40kbps
If all y<x, keep x.
University of Würzburg
Distributed Systems
T. Hoßfeld
20
MBBA Example
Downloading
network links
Uploading
network links
3.333
NL0: 10kbps
20
3.333
NL3: 40kbps
NL4: 30kbps
26.667
NL1: 10kbps
5
NL2: 80kbps
25 5
25
25
10
3.333
6.667
NL5: 10kbps
NL6: 10kbps
10
NL7: 10kbps
Finish: If lower bid of a connection is
the minimal of a peer and is repeated
University of Würzburg
Distributed Systems
40
NL8: 40kbps
T. Hoßfeld
21
MBBA Example
Downloading
network links
Uploading
network links
NL3: 40kbps
3.333
NL4: 30kbps
NL0: 10kbps
5
26.667
NL1: 10kbps
NL2: 80kbps
NL5: 10kbps
24.444
25 5
256.667
2524.444
24.444
6.667
NL6: 10kbps
10
NL7: 10kbps
Finish: If lower bid of a connection is
the minimal of a peer and is repeated
40
NL8: 40kbps
Minimal bid y<x, set y and compute x‘
University of Würzburg
Distributed Systems
T. Hoßfeld
22
MBBA Example
Downloading
network links
Uploading
network links
NL3: 40kbps
3.333
NL4: 30kbps
NL0: 10kbps
5
26.667
NL1: 10kbps
NL2: 80kbps
NL5: 10kbps
24.444
31.667
6.667
NL6: 10kbps
10
24.444
24.444
31.667
10
Finish: If lower bid of a connection is
the minimal of a peer and is repeated
If all y<x, keep x.
University of Würzburg
Distributed Systems
NL7: 10kbps
40
NL8: 40kbps
T. Hoßfeld
23
MBBA Example
Downloading
network links
Uploading
network links
NL3: 40kbps
3.333
NL4: 30kbps
NL0: 10kbps
5
26.667
NL1: 10kbps
NL5: 10kbps
6.667
NL2: 80kbps
31.667
36.666
Finish: If lower bid of a connection is
the minimal of a peer and is repeated
University of Würzburg
Distributed Systems
NL6: 10kbps
10
NL7: 10kbps
40
NL8: 40kbps
T. Hoßfeld
24
MBBA Example
Downloading
network links
Uploading
network links
NL0: 10kbps
NL3: 40kbps
3.333
NL4: 30kbps
5
26.667
NL1: 10kbps
NL2: 80kbps
NL5: 10kbps
6.667
NL6: 10kbps
10
NL7: 10kbps
36.666
NL8: 40kbps
University of Würzburg
Distributed Systems
T. Hoßfeld
25
Comparison PBA vs. MBBA

Exchange of small files
University of Würzburg
Distributed Systems
T. Hoßfeld
26
Comparison PBA vs. MBBA

Exchange of large files
MBBA: computes and allocates
immediately fair-share bandwidth -> in
real
systems this requires some time
PBA:
bandwidth overbooked or
underbooked for Δt -> in next step
bandwidth is adapted
University of Würzburg
Distributed Systems
T. Hoßfeld
27
Conclusion

For P2P content distribution networks, like eDonkey, resource
access control is crucial point

Fair-share bandwidth allocation has to be modeled

We have proposed two stream-based approaches which are valid
in the considered scenarios
 Periodic bandwidth allocation PBA
 Market-based bandwidth allocation MBBA

Depending on the number of events influencing the resource
access control PBA or MBBA has to be preferred
University of Würzburg
Distributed Systems
T. Hoßfeld
28