Reliability

Papers referenced:
"RCRT: Rate-Controlled Reliable Transport for Wireless Sensor Networks" by Paek and Govindan
"Flush: A Reliable Bulk Transport Protocol for Multihop Wireless Networks" by Kim, Fonseca, Dutta, Tavakoli, Culler, Levis, Shenker, and Stoica

Overview

Motivation: high data rate applications that must get data reliability from one or more sources to a sink.

Observations:

TCP-like congestion detection not appropriate for high-loss wireless environment.

Goals:

Reliable delivery
Congestion detection
Rate adaptation

RCRT

Overview:

The sink is more powerful than the source.
The sink may receive data from multiple sources.
The source buffers packets and uses cumulative ACKs to advance the window.
The sink uses NACKs to request missing packets.
The sink buffers out-or-order packets.

Function	Where	How
End-to-end retransmissions	Source and sink	End-to-end NACKs
Congestion detection	Sink	Based on time to recover loss
Rate adaptation	Sink	Based on total traffic, with additive increase and decrease based on loss rate
Rate allocation	Sink	Based on application-specified capacity allocation policy

End-to-end Reliability

The source maintains a copy of all packets sent.
The sink sends NACKs for missing packets and maintains out-of-order packets.
The source retransmits packets for which it received a NACK.
All feedback packets contain a cumulative ACK. The source can use this ACK to overwrite the retransmit buffer.

Congestion Detection

TCP assumes that a single packet loss means that the network is congested. This can lead to poor performance in loss-prone wireless networks.
RCRT assumes that "the network is uncongested as long as end-to-end losses are repaired 'quickly enough'".
The time to recover from a loss is used as the congestion indicator.
The time to recover should be about 1 RTT.
Ci is the average congestion level for node i. If Ci exceeds an upper threshold U(U=4) the network is congested. If it falls back to a lower threshold L (L=1) the network is uncongested.

Rate Adaptation

RCRT uses AIMD to increase/decrease the rate of traffic in response to congestion.
When the network is not congested, the sum of the current assigned rates is increased as follows:

R(t+1) = R(t) + A
A is a constant (e.g., .5 pkts/second)

When the network is congested, the sum of the assigned rates is decreased as follows:

R(t+1) = M(t)R(t)
M(t) is computed based on the loss rate.

M(t) = pi(t)/(2-pi(t))

pi is the packet delivery ratio
ri is the current rate (number of packets sent)
pi*ri is the number of packets delivered
ri(1-pi) is the number of feedback (NACK) packets sent
ri/pi is the amount of traffic to the sink (original packets + retransmits)
(ri(1-pi))/pi is the amount of traffic from the sink
total traffic is ri*((2-pi)/pi
rate is reduced by pi/(2-pi)
Example:

ri = 100
pi = .75
75 out of 100 packets are delivered
25 NACKs are sent
a total of 133.33 packets are sent from source to sink
a total of 33.333 packets are sent from sink to source
M(t) is .6
new rate is 60, 45/60 packets are delivered, 15 NACKs are sent, 80 packets are sent from src to sink, 20 packets are sent from sink to source, total of 100 packets are sent

The rate is adapted no more frequently than once per every 2 RTT.

Rate Allocation

Based on demand or equally divided.

Flush

Overview:

One source is active at a given time.
The sink requests a single, large data object.
Four phases: topology query, data transfer, acknowledgement, integrity check

Topology query

Determine the number of hops from source to sink to tune the RTT and compute a timeout.

Data transfer

Source transmits data to sink.
Over long paths, pipelining occurs.
Rate estimation is done dynamically.

Acknowledgement

Sink sends NACKs for packets not received.
When the source receives a NACK it retransmits the data.

Integrity check

The sink verifies the data and submits a new request if the integrity check fails.

Rate Control

Observation: sending packets quickly poses problems for multihop networks.

Nodes cannot send and receive at the same time.
A node transmitting a packet cannot receive the next packet -- intra-path interference.
Rate mismatches cause buffer overflow.

Rules

A node should only transmit when its successor is free from interference.
A node's sending rate cannot exceed the sending rate of its successor.

The inter-packet delay is the sum of the time it takes to transmit a packet, the time it takes the next hop to transmit, and the time it takes the packet to move out of the next hop's interference range.
With every data packet, each node sends its transmission time and the time for the packet to move out of its interference range.
Node i can hear this information from node i-1 and use it to calculate the inter-packet delay.

Sami Rollins

Date: 2008-01-15