1 / 19

SIMULATING A MOBILE PEER-TO-PEER NETWORK

SIMULATING A MOBILE PEER-TO-PEER NETWORK. Simo Sibakov Department of Communications and Networking (Comnet) Helsinki University of Technology Supervisor: Prof. Raimo Kantola. Contents. Background Protocol introductions SIP, P2PSIP, RELOAD Overlay Concept DHT concept

tanuja
Download Presentation

SIMULATING A MOBILE PEER-TO-PEER NETWORK

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. SIMULATING A MOBILE PEER-TO-PEER NETWORK Simo Sibakov Department of Communications and Networking (Comnet) Helsinki University of Technology Supervisor: Prof. Raimo Kantola

  2. Contents • Background • Protocol introductions • SIP, P2PSIP, RELOAD • Overlay Concept • DHT • concept • DHT algorithms Chord and Kademlia • Routing modes • OverSim simulator • Input parameters • Output parameters • Results • Conclusions

  3. Background of the study • The task was to: • simulate a P2PSIP network using RELOAD as its peer protocol • evaluate P2PSIP’s applicability for mobile telephone networks • The study included: • Writing a C++ class for the simulation program to model the RELOAD messages • Making other necessary additions to the simulation program code. • Collecting and analyzing the results

  4. SIP (Session Initiation Protocol) • SIP is a signaling protocol used for setting up multimedia sessions • SIP supports user mobility and localization • SIP is a traditional client/server protocol dependent on server elements

  5. Alice@work UA SIP MESSAGE OTHER PROTOCOL 3 INVITE john.smith@domain.com (public URI) domain.com Registrar Proxy 4 Query 2 Store sip.domain.com Location Service 5 Response 1 REGISTER 6 INVITE johns@cafeteria.com johns@cafeteria.com (SIP URI) UA John@cafeteria

  6. P2PSIP (Peer-to-Peer SIP) • An alternative solution to the session establishment • Provides the same localization service as SIP but without server elements • Every node (peer) has equal functions and responsibilities for data storage and message routing RELOAD (Resource LOcation And Delivery) • The peer protocol of P2PSIP • RELOAD is used for inter-peer communications in the P2PSIP overlay

  7. DHT (Distributed Hash Table) • Distributes the data and query load evenly to all nodes in the overlay • Divides the keyspace between the participating nodes • Each node has an identifier (node ID) • Stored data elements also have identifiers (resource ID) • Two DHT algorithms, Chord and Kademlia, are used in this study • DHT algorithms define the logical location of the nodes in the overlay

  8. Overlay concept OVERLAY NETWORK Logical links UNDERLAYING NETWORK Physical links

  9. Chord • Nodes are logically arranged in the identifier circle • Keys are assigned to the node whose ID succeeds the ID of the key • Chord has two independent routing tables: successor list and finger table

  10. Kademlia • Nodes are treated as leaves of a binary tree where nodes are located according to the shortest unique prefix of the node ID. • Every node sees the network as a group of subtrees • For every subtree a node has a k-bucket in which there is information about k nodes. SUBTREE MODEL K-BUCKETS (k=2)

  11. Routing modes SYMMETRIC RECURSIVE ITERATIVE

  12. OverSim - Overlay Network Simulator • Based on OMNeT++ discrete event network simulator • Consists of modules that are implemented in C++ • In this study RELOAD was modeled in the DHT TestApp module.

  13. Input parameters • In the simulations 4 input parameters were observed • Other parameters were kept fixed • Altogether 57 simulation scenarios were run • Simulation time for each simulation run was 14 days

  14. Output parameters • Overall bandwidth usage • Message overhead for maintenance • Only when using Chord. Kademlia does not use separate maintenance messages • Number of lookup hops • Length of the lookup path • Lookup message overhead • Amount of data transferred in the lookup processes in bytes • Lookup delay • Delay between sending a lookup and receiving an answer • Key distribution • Mean number of keys stored per node • Lookup success rate

  15. Results • Input paremeters affecting the mean total traffic are number of nodes and key update interval • Kademlia uses more than twice as much bandwidth than Chord • Iterative routing uses more bandwidth than recursive routing when Chord is used • Mean total traffic is generally low (maximum bw for GPRS is ~14kB)

  16. Results • Kademlia needs less time to complete lookups than Chord does • Kademlia uses more bandwidth for lookup traffic than Chord does

  17. Results • Kademlia gives higher lookup success rates than chord • Recursive routing gives higher lookup success rates than iterative routing when Chord is used • The shorter the key update interval the higher the lookup success rate • The longer the mean node lifetime the higher the lookup success rate

  18. Conclusions • 2G mobile telephone networks can handle the bandwidht usage of a P2PSIP network using RELOAD peer protocol • With the input parameters used in this study, lookup success rates are in general too low for session establishment to work satisfyingly. • Kademlia outperforms Chord when lookup delay and success rates are compared • Kademlia uses more than twice the bandwidth that chord does. • FUTURE RESEARCH: • This study could be developed by using more exact input parameters • The reasons for the low lookup success rate could be investigated

  19. Questions?

More Related