TCP- and UDP-based applications
Last updated
Last updated
Why does TCP perform poorly in ad-hoc/vehicular networks?
Developed for wire-line networks.
Assumes all losses are due to congestion.
Many TCP variants have been proposed.
How good are they?
Are they sufficient?
Are there any other alternatives?
Are non-TCP protocols the solution?
Conventional TCP: Tahoe, Reno, New-Reno.
Sending rate is controlled by:
Congestion window (cwnd): limits the number of packets in flight.
Slow-start threshold (ssthresh): when congestion avoidance starts.
Loss detection.
3 duplicate ACKs (faster, more efficient).
The retransmission timer expires (slower, less, efficient).
Overview of congestion control mechanisms:
Slow-start phase: cwnd starts from 1 and increases exponentially.
Congestion avoidance (CA): cwnd increases linearly.
Fast retransmit and fast recovery: Triggered by 3 duplicate ACKs.
Route stability and availability.
Packets can be lost due to “noise”.
Difficult to estimate time-out, RTT, bandwidth.
Intra-flow and inter-flow contentions.
More than 4 hops throughput drops dramatically.
Effects: Reduce sending rate.
Buffered packets (Data and ACKs) at intermediate nodes are dropped.
Sender encounters timeouts.
Under prolonged disconnection, a series of timeouts may be encountered.
Effects: Incorrect execution of congestion control -> performance drops.
The wireless channel is error-prone compared to the wireline.
Fading, interference, noise.
Effects: Performance drops and many unnecessary retransmissions exist.
Variability: Spikes are not uncommon here.
Spikes throw off parameter estimation and tuning.
RTO, window size, slow-start threshold.
Effects: performance drops significantly under a high-loss environment.
Losing a retransmitted packet hurts.
TCP can recover from one loss (fast retransmission).
Wired networks: packet loss rate is low.
Here, high packet loss makes the problem significant.
