Transcript Document
Enhancing TCP Fairness in Ad
Hoc Wireless Networks Using
Neighborhood RED
Kaixin Xu, Mario Gerla
University of California, Los Angeles
{xkx, gerla}@cs.ucla.edu
Lantao Qi, Yantai Shu
Tianjin University, Tianjin, China
{ltqi, ytshu}@tju.edu.cn
*This work was supported in part by Office of Naval Research (ONR) "MINUTEMAN“ project under
contract N00014-01-C-0016 and TRW under a Graduate Student Fellowship
*This research was supported in part by the National Natural Science Foundation of China (NSFC) under
grant No. 90104015.
TCP Unfairness in Ad Hoc Networks
Significant TCP unfairness has
been reported in existing
work
Possible reasons
Hidden and exposed terminal
problems
The interaction of TCP back-off timer
and MAC back-off timer
(100, 100)
(350, 350)
(0, 700)
An illustrative simulation
3 TCP flows contending with each
other
Weight of 3 flows, 2:3:2
(600, 100)
FTP 1
FTP 2
(700, 700)
(350, 700)
(350, 1050)
(100, 1300)
FTP 3
(600, 1300)
2
Significant TCP Unfairness
Flow 2 is nearly starved
Original RED fails to improve the fairness
3
Why RED Does Not Work?
Randomly Early Detection (RED)
Active queue management scheme
Average queue size: avg 1 wq avg wq q
Drop probability: pb
occupancy
max p ( avg minth )
maxth minth
, proportional to buffer
Why RED does not work in ad hoc networks?
Penalized TCP flows may experience queue buildup
Congestion is in an area involving multiple nodes
Queue at a single node cannot completely reflect the state
Extend RED to the entire congested area – Neighborhood
of the node
4
Neighborhood and Its Distributed Queue
A node’s neighborhood
consists of the node itself
and the nodes which can
interfere with this node’s
signal
1-hop neighbors directly
interferes
2-hop neighbors may interfere
8
7
2
3
1
A
12
4
6
5
Queue size of the
neighborhood reflects the
degree of local network
congestion
9
10
11
5
Simplified Neighborhood Queue Model
2-hop neighborhood queue
model is not easy to operate
2
Too much overhead
Only some packets in 2-hop
neighbors’ queues should be
counted
Simplified model
Only include 1-hop neighbors
Two queues at each neighbor
Distributed neighborhood queue
– the aggregate of these local
queues
1
3
A
4
6
5
Outgoing Queue
Incoming Queue
6
Characteristics of Neighborhood Queue
Consists of multiple queues located at the neighboring
nodes
Not a FIFO queue due to location dependency
Priority of a sub-queue may change dynamically
Topology changes
Traffic pattern changes
TCP flows sharing the same neighborhood may get
different feedbacks in terms of packet delay and loss
rate
7
Neighborhood Random Early Detection
(NRED)
Extending RED to the distributed neighborhood queue
Key Problems
Counting the size of the distributed neighborhood queue
Calculating proper packet drop probability at each node
Components of Neighborhood RED
Neighborhood Congestion Detection (NCD)
Neighborhood Congestion Notification (NCN)
Distributed Neighborhood Packet Drop (DNPD)
8
Neighborhood Congestion Detection
Direct way: Announce queue size upon changes
Too much overhead, exacerbate congestion
Our method: Indirectly estimate an index of queue size
by monitoring wireless channel
Channel utilization ratio U busy
Queue size index q U
constant packet size
busyW
C
,
W
channel busy time
sampling int erval
is channel bandwidth,
Average queue size is calculated
using RED’s alg.
Congestion: queue size exceeds the
minimal threshold
C
is a
2
1
3
CTS
A
Channel busy 4
6
5
Outgoing Queue
Incoming Queue
9
Neighborhood Congestion Notification
Drop probability over entire neighborhood
queue is calculated following RED algorithm
Drop probability is broadcasted to 1-hop
neighbors
The broadcast message also defines an
effective duration of this congestion notification
On receiving multiple notifications, nodes
choose the largest drop probability
10
Distributed Neighborhood Packet Drop
Each node calculate its local drop probability
based on the whole neighbor queue drop
probability
Local drop probability is proportional to local
node’s channel usage, that is, the transmitting
and receiving ration of channel utilization
Incoming queue drop probability is
proportional to the receiving ratio, while
outgoing queue drop probability is to the
transmitting ratio
11
Verification of Queue Size Estimation
TCP 4
Estimating Node5’s neighborhood
queue size index
Get real queue size by recording
queue size at all nodes
FTP Traffic
TCP 5
TCP 6
(0,0)
(350,0)
(700,0)
1
2
3
TCP 1
(0,350)
4
(350,350)
5
(700,350)
6
TCP 2
(0,700)
7
(350,700)
8
(700,700)
9
TCP 3
HTTP Traffic
12
Performance Evaluation: Simple
Scenario
(100, 100)
Both long-term and short-term
fairness is achieved
Loss of aggregated throughput
(350, 350)
(0, 700)
FTP 2
(700, 700)
(350, 700)
Tradeoff between fairness and throughput
Channel is slightly not fully utilized
(100, 1300)
Overall Throughput
(600, 100)
FTP 1
(350, 1050)
FTP 3
(600, 1300)
Instantaneous Throughput
13
Performance Evaluation: Multiple
Congested Neighborhood
Multiple congested neighborhoods
FTP2 & FTP 5 have more competing flows, are easy to
be starved
FTP 1 FTP 2 FTP 3
FTP 4
FTP 5
FTP 6
Overall Throughput
14
Performance Evaluation: Mobility
1
3
FTP 1
(0, 0)
(400, 0)
Node 5 moves up and down
Moving Up: two flow interfere with each
Moving down: No much interference
NRED can adapt to mobility
(200, 150)
2
(200, 400)
5'
Node 5 moving
up and down
(200, 600)
4
5
FTP 2
(0, 650)
Without NRED
With NRED
6
(400, 650)
15
Conclusions
Significant TCP unfairness has been found and
reported in ad hoc networks
NRED is a network layer solution
Easy to implement
Incremental deployment
Major Contributions
Model of neighborhood queue
Distributed neighborhood queue
Not FIFO, different and dynamic priorities
Network layer solution for enhancing TCP fairness in
ad hoc networks
17
Other major TCP performance
problems over ad hoc networks
TCP’s behavior of increasing congestion
window tends to overshoots multi-hop channel
capacity
Mobility introduced packet loss erroneously
invoking congestion control scheme, thus
reduced throughput unnecessarily
18
Intended solution
Apply a TCP rate control algorithm by
adaptively setting congestion window
according to channel status
Avoid invoking congestion control scheme
erroneously by discovering packet loss causes
Both schemes require feedback from wireless
channel
19
A cross-layer framework of improving
TCP performance over ad hoc
networks
Adjusting window size
TCP rate control
Cross-layer
Information
Feedback
Heuristic
Metrics
Multi-metric Joint
Identification of
packet loss causes
causes
TCP
Responses for
Packet Losses
Actions
20
What metrics considered as feedback
info ?
Channel utilization ratio (busy time ratio)
Channel interference level
Trend of receiving power adaptation (tracking
mobility)
What else?
21
TCP rate control
Tentatively a TCP congestion control model
based on feedback control theory is considered
as the start point of our scheme
Key problem
Adapt the cross-layer congestion measure into the
existing model
22
Information feedback
A similar method to ECN is considered to notify
TCP sender of the network states
Network states include potential congestion,
potential link breakage due to mobility
A special bit in IP header is set accordingly
23
TCP responses
General schemes responding to route failure
Stop sending packets
Freeze TCP state variables
Probing or waiting for valid route
What else?
Updating state variable based on new path?
24