A Discourse on
Flush: A Reliable Bulk Transport
Protocol for Multihop Wireless Networks
By
Kirti Chawla
kirti@cs.virginia.edu
Overview
Analysis
Flush
Open
Research
Problems
Comparison
Overview
Water-body Level Monitoring
Volcanic Activity Monitoring
Structural Health Monitoring
Sensor
Network
Central
Command
and Control
Overview
Flush
Claims
•
•
•
•
•
End-to-end reliability
Reduced transfer time
High throughput
Adaptive behavior
Scalability
Overview
Flush
Source
Sink
Assumes/Uses
•
•
•
•
•
Key Premise
Non-interfering inter-path network flows
Implicit snooping of control information
Per hop rate control
Efficient per hop and end-to-end acknowledgments
Best-effort forward routing and reverse delivery
Overview
Flush
Sink
Integrity Check
Real-World
Phenomena
Data Transfer
Topology Query
Dynamic
Rate
Estimation
Acknowledgment
Phases
•
•
•
•
Topology query
Data transfer
Acknowledgment
Integrity check
Source
Analysis
Flush Claim 1: End-to-End Reliability
• What happens when wrong RTT estimate is used ?
• Does this technique relies on other components ?
• Which is better: a single NACK or a series of NACKs ?
Complete
DATA
NACK
1, 5, 7 missing
Sink
DATA
Source
Analysis
Flush Claim 2: Reduced Transfer Time
Conceptual Model
1
B
Scenario 1: N = 1, Rate = 1
1
R(N, I) = min(N, I + 2)
2
1
B
Scenario 1: N = 2, Rate = 1/2,
I=0
3
2
1
B
• Is R(N, I) necessary ?
Scenario 1: N = 3, Rate = 1/3,
I=1
• Is R(N, I) sufficient ?
4
3
2
1
B
Scenario 1: N = 4, Rate = 1/4,
I=2
5
4
3
2
1
B
Scenario 1: N = 5, Rate = 1/5,
I=3
Analysis
Flush Claim 2: Reduced Transfer Time
Implementation
• A node should only transmit when its successor is free from interference.
• Sending rate of node is always less than its successor.
δi
i–2
i–3
Ii-1
• Does δi, and fi change due to environment impact ?
δi-1
di
• What if nodes intermittently become invisible ?
Di = max(di , Di-1 )
i–1
i
di = δi + (δi-1 + fi-1 )
fi-1
i–4
Analysis
Flush Claim 3: High Throughput
High Throughput
Protocol Engine
Routing Layer
Packet Delay Estimator
Queuing
Link Layer
Protocol Overhead
Analysis
Flush Claim 3: High Throughput
Protocol Engine
Implements block transfer service with 3 data object sizes 917 KB,
1.1 MB, and 2.2 MB
Routing Layer
Uses MintRoute (a CTP) to converge packets from source to sink
and Bcast (flood protocol) to send transfer request and NACK
Pkt Delay Estimator
Implements dynamic rate control and interference estimation,
provides delay parameters (D, δ, and f) to protocol engine and sets
send rate
Analysis
Flush Claim 3: High Throughput
• How much computation cycles per node is required
to execute compressor ?
• What is the impact of having compressor on energy
consumption, node lifetime, and latency ?
Queuing
Act as buffer space to mitigate side-effects of dynamic rate control,
and controlled draining of queue ensures bounded delay
Link Layer
Snoops on channel to estimate RSSI and delay parameter values and
uses link-layer re-transmission to reduce end-to-end transmission
Protocol Overhead
Default data payload is of 17 bytes, later version uses 35 byte
payload and proposed use of per node compressor to increase delay
resolution and enhance throughput
Analysis
Flush Claim 3: High Throughput
Analysis
Flush Claim 3: High Throughput
Analysis
Flush Claim 3: High Throughput
Analysis
Flush Claim 3: High Throughput
Analysis
Flush Claim 3: High Throughput
Analysis
Flush Claim 3: High Throughput
Analysis
Flush Claim 4: Adaptive Behavior
Adaptive Behavior
Intermediate Link Loss
• Is there any other type of network change (e.g.,
irregular radio pattern, variable rate node) that
might affect adaptive behavior of Flush ?
Route Change
Analysis
Flush Claim 4: Adaptive Behavior
Analysis
Flush Claim 4: Adaptive Behavior
Analysis
Flush Claim 5: Scalability
Source
Sink
3 ft.
• Does 243 ft. network span captures the operational
variability of real-life network span (e.g., Golden
bridge monitor network spans 4200 feet and works
continuously) ?
243 ft., 48 Hops
Analysis
Flush Claim 5: Scalability
Analysis
Modeling Feedback Control in Flush
Environmental Noise
Target
Node
Controller
Ref. Delay
Intra-path Interference
Delay
Transducer
Rate
Comparison
Flush and ATP
Flush
ATP
• Flush uses dynamic rate-based control in
wireless sensor networks.
• ATP introduces rate-based transmission in adhoc networks.
• Flush keeps track of local delay and infers
neighbor delay, and interference delay and
injects these values in outgoing packet.
• ATP keeps track of local delay and inserts this
value in the outgoing packet, for the subsequent
nodes to infer rate.
Key similarity: Rate based transmission and delay parameters in outgoing packets
Key difference: Sensor network use-case (Flush) vs. Ad-hoc network use-case (ATP)
Reference: ATP: A Reliable Transport Protocol for Ad-Hoc Networks | Authors: K. Sundaresan et al.
Comparison
Flush and HBH
Flush
HBH
• Flush uses dynamic rate-based control in
wireless sensor networks.
• HBH introduces dynamic adjustment in service
rates at a switch.
• Flush uses delay parameters as a feedback
mechanism to control transfer rate.
• HBH uses feedback control to fine-tune service
rate.
Key similarity: Dynamic rate and feedback control
Key difference: Sensor network use-case (Flush) vs. General network use-case (HBH)
Reference: On Hop-by-Hop Rate-Based Congestion Control | Authors: Partho Pratim Mishra et al.
Comparison
Flush and RMST
Flush
• Flush uses end-to-end NACKs.
• Flush requires reverse delivery mechanism to
provide NACKs to sink to source.
RMST
• RMST is reliable data transport protocol that
uses end-to-end and hop-by-hop NACKs.
• RMST requires a back channel to deliver
NACKs to upstream neighbors.
Key similarity: Hop-by-hop NACKs and reverse/back delivery channel
Key difference: Considers interference (Flush) versus Considers diffusion (RMST)
Reference: RMST: Reliable Data Transport in Sensor Neetworks | Authors: F. Stann et al.
Comparison
Flush and SPEED
Flush
• Flush uses delay parameters as feedback
mechanism to adjust throughput.
• Flush relies on snooping to reduce control
overhead.
SPEED
• SPEED employs delay estimation and feedback
control to maintain single hop relay speed.
• SPEED aims for minimal control overhead.
Key similarity: Feedback control based rates and minimization of control overhead
Key difference: Lack of void avoidance and soft-real time end-to-end delivery
Reference: A Spatiotemporal Communication Protocol for Wireless Sensor Networks | Authors: Tian He et
al.
Problems
Open Research Problems
• Remove the restriction of having non-interfering inter-path network flows.
• Graceful degradation of throughput over large scale.
• Enhance throughput (given that current throughput = 9370 bps).
What do you think might be other research problems ?
Why the protocol was named Flush ?