Scalable Network and Transport Protocols AINS Project review, Aug 4, 2004

Scalable Network and Transport

Protocols

AINS Project review, Aug 4, 2004

PI: Mario Gerla

Students: Yeng Lee, JS Park, Guang Yang, Kelvin Zhang, Alok Nadan, Jiwei Chen, Ling Jhy Chen, Tony Sun

Post Doc: JJ Kong

CS Dept,UCLA

Network Research Lab

[email protected]

http://www.cs.ucla.edu/NRL

UCLA/CSDApril 19, 2023

The challenges

Tens of thousands of (mobile) nodes Group communications support QoS requirements Hostile environment

Project Goals• Scalable, robust and secure protocols (routing,

multicast, TCP, video streaming)


Project Tasks MAC Protocols:

MIMO and Beamforming features MIMO MAC; SPACE MAC Integration of MAC and Network Layer

Scalable Routing: Leverages group motion Integration with mobile backbone QoS support Robust to mobility

Scalable Multicast: Team oriented, reliable multicast;

TCP: fair behavior in an ad hoc environment (NRED) TCP in mobile, disruptive environments Delay tolerant delivery TCP Westwood; CapProbe; Ad Hoc Probe

Adaptive video streaming: end to end and network feedback (VTP)

Security Anonymous routing in mobile net; Secure multicast


What we will do with the $$$ left?

Delay tolerant networking Robust transport (TCP, streaming) over mobile,

unreliable nets Will not do

Implementation of delay tolerant network protocols Implementation of MIMO MAC protocols on MIMO

radios Integrated testing of video over dynamic, mobile nets Integration with other efforts leading do integrated

demo

TCP over Geo-routing in Mobile and Lossy Ad Hoc Nets

Mario Gerla and Jiwei Chen


Georouting - Key Idea

Each node knows its geo-coordinates (eg, from GPS or Galileo)

Source knows destination geo-coordinates; it stamps them in the packet

Geo-forwarding: at each hop, the packet is forwarded to the neighbor closest to destination

Options: Each node keeps track of neighbor coordinates Nodes know nothing about neighbor coordinates


Geo routing – key elements Greedy forwarding

Assume each nodes knows own coordinates Source knows coordinates of destination Greedy choice – “select” the most forward node


Got stuck? Perimeter forwarding


Greedy Perimeter Stateless Routing (GPSR)

D is the destination; x is the node where the packet enters perimeter mode; forwarding hops are solid arrows;


Case #1: vertical motion(nodes in each column move up and down)


TCP over GPSR and AODV

Speed(m/s)

Thr

ough

put

(Kbp

s)


Case #2: Random Motion

40 nodes in 1000mx1000m


TCP over GPSR, AODV, DSR and DSDV

Speed(m/s)

Thr

ough

put

(Kbp

s)


Conclusions

Georouting is very robust to mobility In a dense network, even when nodes move, there is

always a neighbor in the right direction TCP is extremely sensitive to path breakage

(timeouts etc) It does very well with georouting

Caveat: georouting requires knowledge of destination geo coordinates

“Direction” forwarding for mobile, large scale

ad hoc networksMario Gerla, Yeng-Zhong Lee, Biao Zhou, Jason Chen

UCLA, CSD, Los Angeles CA

Antonio CarusoUniversity of Lecce, Italy


Distance Vector routing

Main routing scheme in the Internet It is the foundation of all

dissemination/advertising based schemesLANMAR, AODV, DSDV, Directed Diffusion

etc It consists of dissemination of scouting

pkts from sink; this forms a Tree the source follows shortest path in the grid


Distance Vector not robust to mobility

In Distance Vector Routing, node keeps pointer to “predecessor”

Sink

When the predecessor moves, the path is broken Alternate paths, even when available, are not used Current solution is to refresh more frequently -> O/H!!!

Source

DV updatePredecessorData flow

Proposed solution: direction forwarding


Direction Forwarding Distance Vector update creates not only “predecessor”, but

also “direction” entry

Sink

Select “most productive” neighbor in forward direction If the network is reasonably dense, the path is salvaged

Source

DV updatePredecessorData flow

“Direction” to Sink


How to compute the “direction” Need “stable” local orientation system (say, virtual

compass) to determine direction of update GPS will do (e.g., neighbors exchange (X, Y)

coordinates) But, if I have GPS, I may as well use Geo Routing (more

later) Several non-GPS coordinate system have been recently

proposed Sextant [Mobihoc ’05]; beacon DV; RFID’s etc

Local (rather than global) reference is required; Local reference system must be refreshed fast enough

to track avg local motion


Computation of the “direction”

)(tan

)()(

12

121

212

212

XX

YY

YYXXr

−−

=

−+−=

−θ

Computation of the “direction”

Where the polar angle is the radian from the x-axis that is used as the direction of the predecessor node.

Suppose node A receives DV update packets from B & C Compute the “directions” to predecessors node B & C,

respectively,

A

C

B),( bb rθ

),( cc rθ

)1,( cθ

)1,( bθ

dθ

“Direction” to a destination

Unit vectors are used to combine the two “directions”

Directions to predecessors


Direction Forwarding vs Geo routing Geo-routing:

Direction points to destination This direction may be unfeasible (holes, etc) Global geo-coordinates (eg, GPS) Geo Location Server Robust to mobility

Directional Forwarding Direction of updates (always feasible) Local position reference system Advertisements from destination Robust to mobility

Case study: apply Direct Forwarding (DFR) to LANMAR Routing LANMAR builds upon existing routing protocols

(1) “local ” routing algorithm that keeps accurate routes within local scope < k hops (e.g., OLSR, FSR)

(2) Landmark routes advertised to all mobiles using a Distance Vector approach

Logical GroupLogical Group

LandmarkLandmark

LANMAR (cont) A packet to “local” destination is routed

directly using local tables A packet to remote destination is routed to

Landmark corresponding to logical address Once the landmark is “in sight”, the direct

route to destination is found in local tables.

Logical SubnetLogical Subnet

LandmarkLandmark


LANMAR +DFR

LANMAR has proved to be very scalable to size However, as speed increases, performance

degrades, even with group mobility! Problem was traced to failure of DV route

advertising in high mobility We first tried to refresh more frequently: it did

not work! Next step: try DFR


Simulation Experiments Simulator: QualNet 3.8

Standard IEEE 802.11 radio with a channel rate of 2Mbps and transmission range of 367 meters.

Network field size: 2250m by 2250m LANMAR is the protocol “hosting” DFR

225 nodes (or 360 nodes) equally distributed in 9 groups

Mobility model: Group Mobility model Traffic: CBR, 1 packets/sec, 512 bytes/packet

The # of source-destination pairs is varied in the simulations to vary the offered traffic load


Performance as a function of speed

Delivery ratio vs. speed (Including packet loss due to disconnected

destination)

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 2 4 6 8 10 12 14 16Mobility (m/sec)

Delivery FractionLANMAR(225 nodes)

DFR(225 nodes)

LANMAR(360 nodes)

DFR(360 nodes)

DFR

LANMAR


Performance as a function of speed (cont.)

Delivery ratio vs. speed (Excluding packet loss due to disconnected

destination)

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 2 4 6 8 10 12 14 16Mobility (m/sec)

Delivery Fraction LANMAR(225 nodes)

DFR(225 nodes)

LANMAR(360 nodes)

DFR(360 nodes)

DFR

LANMAR


Conclusions and Future Work

DFR: new forwarding strategy for table driven routing

Direction Forwarding can improve LANMAR performance dramatically at high speeds

Future Work: Test LANMAR + DFR under local reference system Apply DFR concept to AODV TCP over {LANMAR, AODV} + DFR Compare DFR with other backup route schemes Test DFR under more general mobility models


Thank You !!!http://www.cs.ucla.edu/NRL

Scalable Network and Transport Protocols AINS Project review, Aug 4, 2004

Documents

Transcript of Scalable Network and Transport Protocols AINS Project review, Aug 4, 2004