Peer to Peer Applications in Ad hoc Networks Author: Jesús Hijas [email protected] Networking Laboratory Helsinki University of Technology Supervisor:

Peer to Peer Applications in Ad hoc Networks

Author: Jesús Hijas

[email protected] LaboratoryHelsinki University of Technology

Supervisor: Professor Raimo Kantola

Instructor: LSc. José Costa-Requena

HELSINKI UNIVERSITY OF TECHNOLOGYPeer to Peer Applications in Ad Hoc NetworksJesús Hijas

Outline

• Problem overview– Ad Hoc Networks– Peer to Peer applications

• P2P architectures

• Study of the problem – Limitations when using P2P applications in Ad Hoc networks.

• Solution– P2P application proposal for Ad Hoc networks

• Verification– Tests and results

• Conclusions


Problem

• The problem to be solved in this Thesis is how to discover and use Peer to Peer applications in Ad Hoc networks.

• We also study their performance and scalability problems when running in nodes that are part of an Ad Hoc network.


Problem (II)

• Ad Hoc networks are wireless, self-organizing systems that provide functionality without infrastructure support.

• Peer to Peer (P2P) applications are those that do not rely on elements as servers or clients

• Inherent symbiosis:– P2P applications: distributed, running in the nodes of

the network, not in central servers– Ad hoc networks: all nodes are peers (equals) that

have to act both as clients and servers (P2P paradigm).


Problem (III)

• P2P architectures: Centralized (e.g. Napster)


Problem (IV)

• P2P architectures: Distributed and unstructured (e.g. Gnutella)


Problem (V)

• P2P architectures: Distributed but structured (e.g. Kazaa)


Study of the problem

• Problem description: to achieve the goal of this Thesis, we need to study which problems appear when integrating P2P applications and Ad Hoc networks:– Service Discovery: P2P architecture is fully distributed, which

means that applications are available in concrete nodes of the network and not centralized in servers. In Ad Hoc networks, one node does not know the others beforehand. Thus, applications have to be discovered before they can be used.

– P2P architecture: should not rely on central nodes, since in Ad Hoc networks one node can be down at anytime.

– P2P applications: may act both as client and server with high reliability.


Solution

• We need to implement a Service Discovery mechanism so that peers can find each other and the services they provide. It will be implemented over UPnP.– Chosen among others such as JINI, Salutation, SLP,

etc.

• P2P architecture must be distributed and unstructured.

• P2P application must include both client and server entities in a single piece of software that will run in every node in the Ad Hoc network.


Solution (II)

• P2P application proposal for Ad Hoc networks:– P2P application: Presence Service.

• Chosen among others such as Instant Messaging, Voice over IP, file sharing, etc. due to its simplicity.

• Will run over SIP.

– Service Discovery module: in charge of solving the problem of service discovery in Ad Hoc networks.

• Will run over UPnP.


Solution (III)

• P2P application proposal for Ad Hoc networks: design of the system.


HTTP, TCP, IP, SSDP, UDP, XML…SIP

Solution (IV)

• Presence Service functionality:– Service that allows the user to know about the

reachability, availability and willingness of communication of another user (i.e. his status).

– Users subscribe to others’ presence information.

– When the presence status of one user changes, it has to notify all the subscribers this user has.


Solution (V)

• UPnP functionality:– We use UPnP discovery step, in which control points and

devices multicast SSDP discovery messages (to address 239.255.255.250).


Verification

• Tests scope: estimate the performance of the P2P application developed in a real Ad Hoc Network.• Test method: prepare test cases with different number of nodes in the network and measure the total traffic generated by

the application in one node.• Test conclusions: consider scalability problems based on the results obtained in the tests and the previous analytic study.


Verification (II)

• The Ad Hoc network is formed by iPAQ PDAs with with one wireless adapter

• Linux OS• Wireless link

bandwidth: 2Mbps• 1 iPAQ 3900 and 2

iPAQ 3800


Verification (III)

• Analytic study:– Excluding unavoidable traffic, such as IGMP, TCP or ARP, the total

traffic of the application is:

– SIP traffic, TSIP, is the number of SIP messages sent by one node.– UPnP traffic, TUPnP, varies with the expression:

– With:• CC = Value of control-cache header• N = number of nodes in the network• Ntx = number of transmissions of one packet


UPnPSIP TTT

txUPnP NNCC

packsT 1

sec)/(

Verification (IV)

• Tests case 1: one node in the network– Scope: measure the UPnP traffic in one iPAQ when it

does not interact with other devices and estimate the value of CC to complete the analytic formula.

– Results:

– CC: time between UPnP announcements (expiration time)

Test case 1 UPnP Total

Time between first and last packet (sec) 6,719 7,348

Packets 29 33

Avg. Traffic (Kbit/s)Avg. Traffic (Kbit/s) 99 1010


spacks

s

packets

timeCC 232,0

29

719,6

Verification (V)

• Analytic study:– We will assume no UPnP retransmissions, i.e.

– With these data the general analytic model for the traffic of the application is:

– The capacity consumed by the application is:

– Considering the average UPnP packet size measured in the test cases (309 bytes):

1txN


NNNNCC

TspacksT txSIP 31,41232,0

10

1)/(

)/(8)(.)/()/( bytebitsbytespacksizeAvgsbytesTrafficsbitsBW

NNsbitsBW 32,10654830931,4)/(

Verification (VI)

• Test case 2: two nodes in the network. Scenario.


Verification (VII)

• Test case 2: capture.


Verification (VIII)

• Test case 2: Traffic.


Verification (IX)

• Test case 2: Result analysis.– Initial IGMP and ARP traffic.– SIP traffic (red) is very low compared to UPnP traffic (green).– Data and comparison:

– Analytic results for test case 2:


Test case 2 SIP UPnP Total

Avg. Traffic (Kbit/s)Avg. Traffic (Kbit/s) 11 2222 2424

sKbitTUPnP /308,21232,10654

Verification (X)

• Test case 3: three nodes in the network. Scenario.


Verification (XI)

• Test case 3: Traffic.


Verification (XII)

• Test case 3: Result analysis.– IGMP and ARP traffic peaks in the initialization.– UPnP traffic: predomines during all the test.– SIP traffic (red) is very low.– Total traffic increases softly compared to test case 1.– Data:

– Analytic results for test case 3:


Test case 3 SIP UPnP Total

Avg. Traffic Avg. Traffic (Kbit/s)(Kbit/s)

11 3535 3636

sKbitTUPnP /926,31332,10654

Verification (XIII)

• Result analysis:


Bandwith of the Presence Service Application

050

100150200250300350400450

1 4 7 10 13 16 19 22 25 28 31 34 37 40

Number of nodes (N)

Ba

nd

wid

th (

Kb

it/s

)

Analytic function

Measured values

Verification (XIV)

• Result analysis:– If we consider the total capacity of the channel

provided by the wireless card in the iPAQ devices (2Mbit/s), we could accept that the Presence application would consume the 20% of this capacity. Therefore, the maximum acceptable capacity of the application in one device would be:

– This maximum is reached with 37 nodes in the network. This number can be taken as the maximum acceptable number of nodes in the Ad Hoc network so that the application is efficient.


sKBitsMBitsKBitBWMAX /400/2%20)/(

Conclusions

• In this Thesis we have developed a Peer to Peer application that will run in an Ad Hoc network.

• Attending to the results got, we can conclude that Peer to Peer applications are suitable for Ad Hoc networks, providing a fully-distributed service and automatic service discovery in every node, without relying in central servers and with a reasonable scalability.

• Possible future work:– Reducing the UPnP traffic to improve the scalability of the

application.– Integrating the Presence Service with any other P2P application

such as VoIP or IM to allow users a wider way of communication.


Questions?


Thank you


Peer to Peer Applications in Ad hoc Networks Author: Jesús Hijas [email protected] Networking Laboratory Helsinki University of Technology Supervisor:

Documents