© Manasa Resilience of Flooding Protocol – A Case Study EECS 801 Graduate Reading ©...

© Manasa

Resilience of Flooding Protocol – A Case Study

EECS 801 Graduate Reading

© 2008–Manasa K Aug 14 2008

Manasa K

Department of Electrical Engineering & Computer Science

EECS 801

[email protected]

© Manasa

2


AbstractNetwork state can be characterized by operational metricsand service parameters. Metrics include degree ofconnectivity(density), bandwidth, load factor etc. Serviceparameters include delay, jitter, goodput etc.

In this paper, a case study on Resilinets controlled flooding was

done to understand its transition as it degrades from optimal

performance. Under the affect of different operational metrics

namely load factor, density, mobility.

14 August 2008 Resilience of Controlled Flooding

© Manasa

3

Resilience of Flooding Protocol – A Case Study Outline

• Introduction and Motivation• Case Study of Controlled Flooding • Proposed Evaluation Framework• Simulation Setup• Conclusion and Future Work• Reference


© Manasa

4


Introduction and Motivation• Introduction and Motivation• Case Study of Controlled Flooding • Proposed Evaluation Framework• Simulation Setup• Conclusion and Future Work• Reference


© Manasa

5


Introduction and Motivation• Flooding is most commonly used to compare

other protocol. This is the simplest broadcast routing algorithm.

• But how well does flooding algorithm perform –the approach taken in this paper is to understand “controlled flooding” where each node floods the n/w with a duplicate packet only once, thus overriding “broadcast storm”

• As of today, we do not see many documented study of extensive performance on flooding algorithm


© Manasa

6


Case Study of Controlled Flooding• Introduction and Motivation• Case Study of Controlled Flooding • Proposed Evaluation Framework• Simulation Setup• Conclusion and Future Work• Reference


© Manasa

7


Case Study of Controlled Flooding• The controlled flooding protocol was designed

using existing ns-2 source code.• Here each node sends duplicate packets the

network only once. This is done by storing in memory, the status of each packet at each node. If the node had earlier received the packet it then just drops it else forwards the packet i.e. duplicates/floods the network once. Thus if there are n nodes in the network, we will have network rate to be n times the traffic source rate


© Manasa

8


Proposed Evaluation Framework• Introduction and Motivation• Case Study of Controlled Flooding • Proposed Evaluation Framework• Simulation Setup• Conclusion and Future Work• Reference


© Manasa

9


Proposed Evaluation Framework• The Operational Metrics are defined as below

– Load Factor = (rate*num_sources)/Bandwidth – Density = (∏*range*range*Num_Nodes)/(X*Y) – Mobility = [0,0] , [10,20] (pause time = 0 sec)

rate = source rate (Mbps)range = Transmission range (m)Bandwidth = 12 MbpsX, Y = Simulation region


© Manasa

10


Simulation Set-up• Introduction and Motivation• Case Study of Controlled Flooding • Proposed Evaluation Framework• Simulation Set-up• Conclusion and Future Work• Reference


© Manasa

11


Simulation Set-up• Network Topology

– Simulation Region - 1000 by 1000– Routing Protocol – Resilinets_Flooding– Mac Type – 802.11– Mobility – RandomWayPoint– Number of Nodes – 30– Number of Traffic Sources – 10

• Traffic Setup– CBR/UDP– Rate (Mbps) - (Packet Rate)*(Packet Size)*Bytes

– Packet Interval - 1/(Packet Rate)

– Packet Size - 1000 Bytes

– Rate per Node - .04, .08, .12, .2 , .4 , 1 , 2 and 12 Mbps

– Net Source Rate with 10 sources - .4, .8, 1.2, 2, 4, 10, 20 and 120 Mbps


© Manasa

12

Throughput Efficiency[Fig 1] No Mobility throughput efficiency wrt aggrgate src rate

[Fig 1.1] With Mobility throughput efficiency wrt aggrgate src rate


© Manasa

13

Throughput Efficiency wrt Node Partition

[Fig 2] No Mobility Throughput Efficiency wrt Node Partition

[Fig 2.2] With Mobility Throughput Efficiency wrt Node Partition


© Manasa

14

End – End Delay wrt node partition

[Fig 3] No mobility end-end delay wrt node partition

[Fig 3.1] With Mobility End-End delay wrt Node Partition


© Manasa

15


Conclusion• Introduction and Motivation• Case Study of Controlled Flooding • Proposed Evaluation Framework• Simulation Set-up• Conclusion and Future Work• Reference


© Manasa

16


Conclusion• We have understood the behavior of the

controlled flooding protocol, against operation metrics being the density, load factor and mobility.

• And we see how the protocol transitions from optimal performance and degrades when over flooded and sparsely networked


© Manasa

17


Reference• Introduction and Motivation• Case Study of Controlled Flooding • Proposed Evaluation Framework• Simulation Set-up• Conclusion and Future Work• Reference


© Manasa

18


Reference

[1] Poster: Towards Quantifying Metrics For Resilient and Survivable Networks

ihttps://wiki.ittc.ku.edu/resilinets_wiki/index.php/Metrics_and_Modelling

© Manasa Resilience of Flooding Protocol – A Case Study EECS 801 Graduate Reading ©...

Documents

Transcript of © Manasa Resilience of Flooding Protocol – A Case Study EECS 801 Graduate Reading ©...