1 / 16

Overview

From Packet-level to Flow-level Simulations of P2P Networks Kolja Eger, Ulrich Killat Hamburg University of Technology ITG-Fachgruppentreffen, Aachen 4. Mai 2006. Overview. P2P Content Distribution Packet-level Simulation Flow-level Simulation Simulation complexity & accuracy Conclusion.

Download Presentation

Overview

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. From Packet-level to Flow-level Simulations of P2P Networks Kolja Eger, Ulrich KillatHamburg University of TechnologyITG-Fachgruppentreffen, Aachen4. Mai 2006

  2. Overview • P2P Content Distribution • Packet-level Simulation • Flow-level Simulation • Simulation complexity & accuracy • Conclusion

  3. P2P Content Distribution • Objective: Disseminate large files in minimal time to a large number of users • Swarming principle: • A file is fragmented into small pieces which can be shared before download of the whole file is completed • E.g.: BitTorrent protocol • Our research interests: • Efficiency: Peer has something of interest for at least one other peer at any point of time • Fairness: Peers which contribute much should also gain much ⇒ incentive to contribute

  4. Complexity of P2P Simulation • P2P networks are complex: • Large and varying peer populations • Peer behaviour is user-driven • Peers provide and consume different services, e.g. exchange different pieces of a file with each other • Services are offered with different quality, e.g. upload bandwidth • Each peer has only local information about the network • Only simple cases can be studied analytically, e.g. flash crowd of homogeneous peers • Simulations must be based on simplifications

  5. Packet-level Simulations • Assumptions: • Access line of the peers is the bottleneck in the network • No packet drops in the core network • Simplified topology: • Access link plus overlay link • Different RTTs between access routers • No. of links: Z = (NP -1)NP/2 + NP = NP/2 (NP+1) • Memory increases quadratically with NP • No. of events is decreased, because of small no. of hops

  6. Event x Timer x Timer x Peer contacts tracker Timer x Event 1 Timer x Timer x Timer x Timer x Timer x Connects to other peers Timer x Timer x Timer x Timer x Timer x Timer x Inform about pieces Timer x Timer x Timer x Timer x Timer x Timer x Check interest Timer x Timer x Timer x Timer x Timer x Timer x Timer x Timer x Timer x Timer x Timer x Timer x Peer selection (Unchoke) Timer x Event 2 Timer x Timer x Timer x Timer x Timer x Request pieces Timer x Timer x Timer x Timer x Timer x Timer x Upload Timer x Timer x Timer x Timer x Timer x Timer x Timer x Download Timer x Timer x Timer x Timer x Timer x Timer x Have Timer x Timer x Timer x Timer x Timer x Timer x Timer x Check interest Timer x BitTorrent Messages Packet-level Flow-level

  7. RTT RTT RTT RTT RTT Exponential increase TCP Behaviour • In BitTorrent each peer uploads to a number of other peers (default = 5) (called unchoking) • Every 10s peers are chosen based on the download rates from them TCP throughput / max. throughput • If uplink of a peer is the bottleneck, TCP reduces to exponential increase at the beginning Cup / (No. of uploads) * RTT Upload Capacity: 1*10 kbit/s to 30*10 kbit/s RTT 1*10ms to 25*10ms

  8. Flow-level Simulation • In peer selection algorithm download volume is computed beforehand • If remote peer needs less, it is redistributed over the remaining connections • Thus, peer allocates its upload bandwidth max-min fair Demand Demand Demand Volume = (Upload Capacity * unchoking interval) / (No. of uploads) Surplus / 3 Surplus / 2

  9. Simulation Setup • Flash crowd scenario where a single peer holds the complete file at the beginning • Time measured until all peers have finished their download • No peer leaves the network beforehand • File size: 10MB, piece size: 256KB • Homogeneous peers with upload capacity of 10KB/s and download capacity 8 times higher (asymmetric access line) • Packet-level simulation with ns-2 • Flow-level simulation uses timer functionality of ns-2 • Simulation are run on a Pentium 4: 3,2 GHz, 1 GB RAM

  10. Simulation Time • approx. 11hfor 60 peers with packet-level compared to 2 sec. with flow-level simulation • Calendar queue is used

  11. List insert: O(n) delete: O(1) Calendar insert: O(1) to O(n) delete: O(1) to O(n) Map insert: O(log(n)+) delete: O(log(n)+) Heap insert: O(log(n)) delete: O(log(n)) Event Scheduler Simulation Time [s] No. of peers

  12. Flow-level Simulation 170 000 peers in less than 30min.

  13. Simulation time for a flash crowd of 4000 peers with different upload capacities Higher capacities result in less events for the same download volume 640 B/s = 0,625 KiB/s = 5 Kib/s Standard-Upload-Kapazität 10.240 B/s = 10 KiB/s = 80 Kib/s ADSL 1000 16.384 B/s = 16 KiB/s = 128 Kib/s ADSL 2000 24.576 B/s = 24 KiB/s = 192 Kib/s ADSL 6000 76.800 B/s = 75 KiB/s = 600 Kib/s Flow-level Simulation (cont.)

  14. Simulation Accuracy • Both curves have the same shape • But results differ by around 10% • Reasons: • Packet headers • TCP behaviour • Load for BitTorrent messages

  15. Conclusion • Packet-level simulation does not scale for P2P networks • Flow-level simulation is inevitable to study networks of reasonable size • Results with flow-level simulator are qualitatively comparable but underestimate the true values due to the simplifications made • Flow-level simulation is a good compromise to study protocol design • But inadequate to take cross-layer interactions into account, e.g. unchoking is based on TCP throughput which depends on RTT

  16. Thank you for your attention!

More Related