Download 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 min th )
max th min th
, 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
busyW
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