muri-dawn project review ucsc, oct 14 2008
Post on 01-Feb-2016
34 Views
Preview:
DESCRIPTION
TRANSCRIPT
Multicast Applications:ProbeCast and RelayCast
Mario Gerla, Uichin Lee, Soon Oh, SeungHoon LeeCSD, UCLA
www.cs.ucla.edu/NRL
MURI-DAWN Project review
UCSC, Oct 14 2008
Progress in 2007-2008
• Data dissemination (DTN scenarios)– RelayCast: a scalable DTN multicast protocol (ICNP 2008)– Impact of correlated motion on unicast DTN routing (work in
progress)• 2 phase inter-contact time distribution: power law head with
exponential tail• Capacity/delay of DTN unicast routing
• ProbeCast: multicast admission control (Q2SWINET 2008)– Resource probing + pruning, neighborhood proportional drop
(NPROD) for fair share of a channel• Network coding configuration/implementation
– Communication, disk I/O, encoding overhead analysis (using measurement based models)
• MobSim: an interactive vehicular motion simulator
DTN Multicast Routing
• Provides reliable data dissemination (e.g., situation awareness data) even in disrupted environments
• DTN multicast routing strategies – Tree, mesh, ferry/mule, epidemic dissemination– Use mobility-assist routing to deal with disruptions
S
R2
R3
R1R4
SR3
R1R4
R2S
F
R1
F
S
R1
mobility
Disrupted node
Disrupted node
R2
Tree Mesh Ferry/mule Dissemination
mobility
Scaling Properties of DTN Multicast
• Questions:– Achievable DTN multicast throughput; average delay– Compare with existing capacity/delay bounds of ad
hoc wireless networks (Gupta&Kumar)– Trade-offs:
• Infinite buffers: throughput/delay trade-offs• Finite buffers: throughput/buffer tradeoffs
• Modeling approach: – Inter-contact time models – Queueing models (for throughput/delay/buffer
analysis)
Review: 2 Hop Relay
• 2-hop relay:1. Source sends a packet to a relay node2. Relay node delivers a packet to the corresponding
receiver
2-hop Relay by Grossglauser and Tse
Source
Relay
Destination
RelayCast: DTN Multicast Routing
• 2-hop relay based multicast:1. Source sends a packet to a relay node
2. Relay node delivers the packet to ALL multicast receivers
RelayCast: 2-hop relay based multicast
S
Source SR1
R2
R3
Relay Nodes
Phase 1: S_ Ri Phase 2: Ri _ {D1,D2,D3}
D1
D2
D3
D1
D2
D3
D1
D2
D3
D1
D2
D3
Source
Relay
Destinations
D2
D1
D3
Two-Hop Relay Review
• Intuition: average throughput is determined by aggregate encounter rate (src relay and relay destinations)– How often does a destination node encounter any of the relay
nodes? Answer: n*λ• Two-hop relay per node throughput : Θ(nλ)
– Aggregate meeting rate at a destination: nλ– Grossglauser and Tse’s results: Θ(nλ)=Θ(1)
• Recall: λ = 1/n (i.e., speed 1/√n, radio range 1/√n)
RelayCast: Throughput Analysis
• Multicast traffic pattern: – ns sources, each of which is associated with nd
random destinations– Different sources may choose the same node as one
of their receivers• Fraction of sources per receiver : nx = nsnd/n
– A source chooses a node as dest with prob. nd/n• Fraction of aggregate packets per source = 1/nx
• RelayCast throughput: Θ(nλ/nx)=Θ(n2λ/nsnd)– i.e. = (#of nodes) x rate x frct of packets per source
RelayCast: Delay Analysis
• One relay node delivers packets to all receivers• RelayCast delay: Θ(log nd /λ)
– Unlike conventional multicast, delay is proportional to the number of receivers
R2
R3
relaynode
R1
X1X2
X3R
3 2 1 0
3λ 2λ λ
Markov Chain for delivery status:Average delay = average time to absorb
= 1/3λ + 1/2λ+1/λ (memoryless!)D=max(X1, X2, X3)
Comparison with Previous Results• Assumptions; n fixed; r = √logn/n G&K; r=√1/n for 2-hop relay• Throughput scaling comparison with ns= Θ(n)
– nd: # receivers, n: total # nodes• RelayCast is better than conventional multi-hop multicast (r= √logn/n)
Multi-hopUnicast⎟
⎟⎠
⎞⎜⎜⎝
⎛Θ
nnlog1
Gupta & Kumar, TOIT’00
⎟⎟⎠
⎞⎜⎜⎝
⎛Θ
dnnn
1
log
1 Multi-hopMulticast
Shakkottai et al., Mobihoc’07Li et al., Mobicom’07
Tavli, IEEE Com. Letter’06Keshavarz-Haddad et al., Mobicom’06
⎟⎠
⎞⎜⎝
⎛Θn
1Broadcast
Grossglauser & Tse, INFOCOM’01Delay Tolerant Apps
Two -hop Relay( )1Θ
RelayCast: Delay Tolerant Apps
RelayCast⎟⎟⎠
⎞⎜⎜⎝
⎛Θ
dn1
Number of m-cast receivers per source
Per
no
de
thro
ug
hp
ut
wit
h n
s=
Θ(n
)
Simulation Results
• Comparison with Conventional Multicast Protocol– Connected topology
• RelayCast is scalable; ODMRP’s throughput decreases significantly, as # sources increases
* QualNet v3.9.5* Mobility: random waypoint (speed = 20, 30m/s)* Network area size: 1000m*1000m* 100 Nodes, 250m TX range5 destinations
Two-phase Inter-contact Time
• Two-phase distribution: power-law head and exponential tail
Chaintreau06 Karagiannis MobiCom 07
Infocom 06
Levy walk: Rhee Infocom 08• Association times with AP (UCSD) or cell tower (MIT cell)• Direct contact traces: Infocom, cambridge (imotes), MIT-bt
Two-phase Inter-contact Time
• Why two-phase distribution? – One possible cause: flight distance of each random trip [Cai08]– The shorter the flight distance, the higher the correlation
heavier power tail • Examples of correlations:
– Manhattan sightseers: In Time Square, sightseers tend to bump into each other; and then depart for other sights
• Levy flight of human walks [Rhee08]: short flights + occasional long flights
– Vehicular mobility: Constrained by road traffic (+traffic jam)• High correlation among vehicles in close proximity• After leaving locality, vehicles meet like “ships in the night”
• Power-law head while in the local contention area, vs. exponential tail for future encounters
*Cai08: Han Cai and Do Young Eun, Toward Stochastic Anatomy of Inter-meeting Time Distribution under General Mobility Models, MobiHoc’08*Rhee08: Injong Rhee, Minsu Shin, Seongik Hong, Kyunghan Lee and Song Chong, On the Levy-walk Nature of Human Mobility, INFOCOM’08
Two-hop Relay Unicast under Correlated Motion Patterns
• Impact of correlated motion patterns on throughput/delay performance?– Under the average flight distance of Ω(r);
i.e., minimum travel distance ~ one’s radio range– Increase correlation by decreasing flight distance
• Preliminary analytic results :– Throughput: Independent of node speed and degree of correlation (ie,
flight distance)– Average delay is within [1/λ, logn/λ]; i.e., random direction (to wall) and
random walk respectively – Delay monotonically increases with the degree of correlation– Buffer requirement also increases
• Using Little’s results: [Θ(nr/v), Θ(nrlogn/v)]
• Simulation results:– Correlation increases burstiness of traffic in and out of relays
Simulation: Throughput• Degree of correlation via average flight distance L
– 5000m*5000m area– L=R=250m high correlation power law head + exponential tail– L=1000m low correlation almost exponential
• Throughput is independent of the degree of correlations
Average throughput per node as a function of # relay nodes
CCDF of inter-contact time (20m/s)(Log-log plot)
L=250m
log-linear plot
L=1000m
L=250m
Exp
Simulation: Buffer Utilization
• Burstiness increases with the degree of correlation
Cumulative distribution of the number of consecutive encounters
Buffer utilization over time (speed=30m/s)
Summary: DTN Routing under Correlated Motion Patterns
• Per-node throughput is not affected by the degree of correlation
• However, correlation causes increases in:– Variance in the inter-contact time– Average delay– Buffer requirements– Burstiness of inbound/outbound
ProbeCastS. Oh, G. Marfia, M. Gerla, Q2SWINET 2008
The Problem:
• Resource reservation/allocation schemes are ineffective in inelastic multicast in ad hoc nets– Bookkeeping is very cumbersome (as # of
destinations increases); – Also, mobility requires continuous re-
adjustments– Without QoS support, quality will collapse
ODMRP (200K-40K)
0102030405060708090
100
Flow1 Flow2
Packet Delivery Ratio (%)
Flow 1 has 9 receivers with 200Kbps and flow 2 has 3 receivers with 40Kbps
Goal:• Achieving reliable QoS support in inelastic multicast flows (e.g., video and audio stream)
ProbeCast: key insights
• Insight #1: Resource Probing– No a priori resource allocation
– Rather “probe” for resources
• Insight #2: Pruning via Back-pressure– Back-pressure (“prune”) toward the source when resource is unavailable
– Re-route or reject the inelastic flow
• Insight #3: Neighborhood Proportional Drop (NPROD)– Local rate balancing using proportional dropping
– Enforces fair channel sharing “fair back-pressure”
• Main Outcome:– Inelastic flows to acquire resources in fair manner without reservation, yet
preserving reliable QoS
ProbeCast Approach
• Assumptions:– End-to-End FEC – e.g. erasure coding – always ON
– Each flow has packet drop threshold
• Probing– Each node measures resource overload – e.g. packet drop rate
– Broadcast to one hop neighbors own drop rate via piggybacking on packets
• Proportional Drop (N-PROD)– Overhearing neighbors’ drop rates
– Enforcing equal drop rates among flows competing in the same contention domain – packet drop
– Nodes in the same contention domain sharing channel fairly
ProbeCast Approach (Cont.)
• Pruning – Drop-Threshold (DT) for flows
• traffic class and flow age dependent
– Piggybacking DT on the packet Forwarders know Drop Threshold of flows
• Typically, incoming flow has lower threshold than incumbent• When drop rate is > threshold, a flow is back-pressured no
explicit control packets to source
– Source action:• re-route if there is alternative route; • otherwise reject the flow
Probe/Prune + N-PROD at Work
(A) 3 flows in the same contention domain. Lower graphs shows packet delivery ratios, presented by percentages. (B) Flow 3 starts transmitting and other flows’ rates decrease (N-PROD). (C) Since flow 3 drop rate exceeds the threshold, backpressure starts.
Flow 1
Flow 2
0
20
40
60
80
100
Flow 1 Flow 20
20
40
60
80
100
Flow 1 Flow 3 Flow 20
20
40
60
80
100
Flow 1 Flow 3 Flow 2
(A) (B) (C)
Flow 1
Flow 2
Flow 3
Flow 1
Flow 2
Flow 3
Backpressure
Data Rate Coding Rate
Existing flows
Incoming flow
Flow 1
Flow 3
Flow 2
Current RateThreshold
Simulation - Fairness
ProbeCast with N-PROD (200K-40K)
0102030405060708090
100
Flow1 Flow2
Packet Delivery Ratio(%)
• Qualnet Simulation: 50 nodes uniformly distributed 1000 mby 1000 m field • Flow 1 has 9 receivers with 200Kbps and Flow 2 has 3 receivers with 40Kbps• N-PROD eliminates capture problem increasing FAIRNESS
NC Implementation Guidelines S. Lee, U. Lee, K-W. Lee, M. Gerla SECON 2008
• Goal: show that NC can be implemented in military scenarios – Develop configuration guidelines based
on measured data • We start with Network Coding
processing O/H analysis– Linearly proportional to the number of
packets in a generation (= generation size)
– Generation size must be carefully chosen: max node encoding rate > (available) wireless bandwidth
+
X 1 X 2 X 3
e1 e2e3
e1X1+e2X2+e3X3[e1,e2,e3]
generation
NC Throughput Measurement
• Validation through measurements using portable devices
Nokia N800: TI OMAP 2420 (330Mhz)
+ 802.11b
Orinoco8471 WD
IBM Thinkpad R52
Scenario: k contendersin domain (k=1/2/3)
N1
N2
N3
NC Throughput Measurement
• large generation => high CPU O/H => low pkt tx • As the number of contenders increases, pkt tx rate must decrease
can support a larger generation size• For small unit operations, optimal Gen Size < 50 (from experiments)
– Well suited for network coding based streaming (i.e., CodeCast)
0
1
2
3
4
N/AG10G50G100
N/AG10G50G100
N/AG10G50G100
N/AG10G50G100
N/AG10G50G100
N/AG10G50G100
1 Node 2 Nodes 3 Nodes
Average Goodput (Mbps)N1 N1 N2 N1 N2 N3
• G10 = 10 packets in generation• N/A: No network coding
Number of contenders in a domain
MobSim: An Interactive Simulator for Urban Mobility
C. Li, M. Bansal, U. Lee, K.-W. Lee, M. Gerla ACITA Demo Session
• Limitations of current simulators – Non-realistic urban mobility models– Non-interactive simulations
• MobSim design goals:– Programmable mobility model– Interactive simulation environment– Built-in appl modules (eg dissemination)
MobSim Architecture
• Mobility Generator: – Tiger map of target urban area– Underlying vehicle motion pattern (eg, commuting, shopping,
etc)• Application:
– E.g., Data Dissemination Processing Module• Target selection; Agent vehicles, etc
• Real-time Visualization Module • Interactive Simulation UI
Mobility Generator: Tiger map + IDM
Data DisseminationProcessing Module
ApplicationsReal-time
Visualization Module
InteractiveSimulation UI
MobSim
Road-constrained Motion Model
• For each car, pick random start/end points and speed
• Construct the shortest path
• Travel at variable speed on each segment
Start
End
Agent Tracks Target using Last Encounter Routing
• Agent moves in direction hinted by cars that last encountered the target
• While moving, agent continuously looks for fresher encounter information
TT
T-t6
T-t5T-t4
T-t3
T-t2
T-t1
Trajectory
C1C2
Advertise SC2,1Advertise SC1,1
Encounter Point
Single-hopAds
Harvest
Move to Last Encounter Point
MobSim: Simulation Results
• Average search time with varying number of agents and number of nodes
MobSim Screenshot
0
20
40
60
80
100
N:100 N:150 N:200 N:100 N:150 N:200
#Agents=2 #Agents=5
Search time (sec)
Future Work
• Impact of different vehicle and agent motion patterns • Impact of density (e.g., intermittent connectivity)• Bio-inspired multiple agent collaboration algorithm (i.e.,
Lévy jump based searching + datataxis)• Investigate realistic urban warfare scenario (e.g., hints
about enemy movements)
top related