A New TCP Congestion Control Mechanism over Mobile Ad Hoc Networks by Router-Assisted Approach

1
A New TCP Congestion Control Mechanism over
Mobile Ad Hoc Networks by Router-Assisted Approach

• Student Ho-Cheng Hsiao
• Advisor Yao-Nan Lien
• 2006.10.5

2
Outline

• Introduction
• Related work
• Our router-assisted approach
• Performance evaluation
• Conclusion

3
Outline

• Introduction
• Related work
• Our router-assisted approach
• Performance evaluation
• Conclusion

4
Introduction

• TCP Congestion Control
• Trial-and-error based flow control for control
  congestion
• Connection-oriented
• End-To-End
• Reliable
• Slow Start
• Congestion Avoidance
• Fast Retransmits and Fast Recovery

5
Introduction
6
Introduction

• Objective of TCP Congestion Control Protocol
• Utilize resource as much as it can
• Dissolve congestion
• Avoid congestive collapse
• Generally occur in bottleneck point
• However, the nature of MANET has exposed the
  weakness of TCP
• Lack of infrastructure
• Unstable Medium
• Mobility
• Limited bandwidth
• Difficulty to distinguish loss due to congestion
  or link failure

7
Introduction

• Analysis of TCP problem over MANET (1)
• Slow Start
• It takes several RTTs for slow-start to probe the
  max. available bandwidth in MANET
• Connections spend most of time in Slow Start
  phase due to frequent timeout
• up to 40 of connection time
• Slow-start tends to generate too much packets
• Network overloaded!!

Slow-start always overshoot and cause periodic
packet loss
8
Introduction

• Analysis of TCP problem over MANET (2)
• Loss-based congestion indication
• Event of packet loss congestion (regular
  network)
• by three duplicate ACKs or timeout
• Packet losses in MANET can be classified into
• Congestion loss
• Random loss
• Link failure or route change (in most case)
• Transmission error

Not every loss is due to congestion
9
Introduction

• Analysis of TCP problem over MANET (3)
• AIMD ( Additive Increase and Multiplicative
  Decrease )
• Additive Increase
• Slow convergence to the full available bandwidth
• Multiplicative Decrease
• Unnecessary decrease of congestion window size
  while detecting packet losses
• This scheme is a good way to deal with congestion
  in regular network
• Not a good scheme in MANET!

Avoid unnecessary congestion window drop is the
key to better performance
10
Introduction
What happen if we have more information about it??
11
Introduction

• Explicit Router-assisted Techniques
• Explicit router feedback is able to indicate
  internal network condition
• Several explicit information provided by router
  can enhance the performance of transport protocol
• Available bandwidth (with respect to a path)
• Queue length
• Queue size
• Loss rate

12
Introduction

• Our approach
• Design a new TCP congestion control mechanism
  that is aware of network condition over MANET
• The protocol can dynamically respond with
  different situations according to the explicit
  information from routers

13
Outline

• Introduction
• Related work
• Our router-assisted approach
• Performance evaluation
• Conclusion

14
Related Work

• Router-assisted congestion control
• TCP-F (TCP-Feedback)
• TCP-ELFN (Explicit Link Failure Notificatoin)
• ATCP (Ad Hoc TCP)
• Other proposals
• Adaptive CWL (Congestion Window Limit)

15
Related Work

• TCP-F (TCP-Feedback)
• Sender is able to distinguish route failure and
  network congestion
• Network components detect the route failure and
  notify sender by RFN packet (Route Failure
  Notification)
• Sender then freezes all the variable (RTO and
  cwnd) until it receives the RRN packet (Route
  Recovery Notification)

16
Related Work

• TCP-ELFN (Explicit Link Failure Notification)
• This scheme is based on DSR (Dynamic Source
  Routing)
• ELFN message is similar to host unreachable
  ICMP message. It contains
• Sender and receiver address
• Ports
• Packet sequence number
• Sender disables its retransmission timer and
  enter standby mode after receiving ELFN
• Then sender keeps probing the network by sending
  a small packet to restored the route (nature of
  DSR)

17
Related Work

• ATCP (Ad Hoc TCP)
• A layer called ATCP is inserted between the TCP
  and IP layers of the source node
• ATCP listens to the network state by
• ECN (Explicit Congestion Notification) message
• Congestion!!
• ICMP Destination Unreachable message
• Network Partitioning!!
• Sender can be put into 3 states
• Persist State by ICMP message
• Congestion Control State by ECN message
• Retransmit State by packet loss without ECN
  flag
• Note - After receiving three duplicate ACKs,
  sender does not invoke congestion control and
  puts TCP in Persist State and quickly retransmit
  the loss packet from buffer ( Multipath routing
  or channel loss)
• Recomputation of congestion window size after
  route re-establishment

18
Related Work

• Adaptive CWL (Congestion Window Limit)
• If the congestion window size is greater than an
  upper bound, the TCP performance will degrade.
• Find the BDP (Bandwidth Delay Product) of a path
  in MANET
• They use this upper bound of BDP to dynamically
  adjust TCPs max. window size

?
19
Related Work

• In 29 31 33, they show TCP with a small
  congestion window tends to outperform TCP with
  large congestion window size in wireless multihop
  network (e.g., 1 or 2)
• In 29, Fu et al. reported that , there exists
  an optimal TCP window size W by which TCP
  achieves the best throughput
• However TCP operates at an average window size
  which is much larger than W. (Overshooting)

20
Outline

• Introduction
• Related work
• Our router-assisted approach
• Performance evaluation
• Conclusion

21
Design Philosophy

• Fully utilize the available bandwidth alone the
  path
• Reducing the chance of congestion
• Distinguish the loss between congestion loss and
  random loss

22
Design Procedure

• Estimation of the available bandwidth
• Dynamic adjustment of sender sending rate
  according to router feedback
• Recovery of random lost packets

23
Objective

• Allowing sender to reach appropriate sending rate
  quickly
• Maintain throughput
• Dissolve congestion
• Provide fairness with other TCP variants

24
TCP Muzha

• Window-based router-assisted congestion control
• Sender function
• Modification of Slow Start
• Router function
• Estimation of available bandwidth
• Computation of DRAI (Data Rate Adjustment Index)
• Handling random loss
• Receiver function
• Return the ACK with DRAI back to Sender

25
TCP Muzha

• Modification of slow-start
• Sender dynamically adjusts its sending rate
  according to the router feedback collected by
  receiver.
• Without causing periodic packet loss
• Avoid the overshooting problem
• Router feedback
• We use available bandwidth

26
TCP Muzha

• Router function
• Estimation of available bandwidth
• Most traffic flows are tend to pass through the
  routers which have more bandwidth
• We assume each router is aware of
• Incoming and outgoing traffic state
• Aggregate bandwidth state
• Routers have more precise information regarding
  to TCP flows of a bottleneck node.

27
TCP Muzha

• How to use the available bandwidth?
• Direct publication of actual available bandwidth?
• Seduce greedy TCP sender
• Bandwidth fluctuation
• Our approach
• Routers compute a fuzzilized index according to
  available bandwidth as a guideline for sender to
  adjust sending rate

28
TCP Muzha

• Why index?
• Consistency of bandwidth computation
• Simplicity
• Ease of implementation
• The simplest case
• ECN
• Bi-level data rate adjustment index (0,1)
• By routers assistance , sender is able to
  control its sending rate more precisely
• multi-level data rate adjustment index

29
Data Rate Adjustment Index Conversion -
Multi-level (1/6)

• How many levels are appropriate?
• Currently there is no such research or
  investigation on this topic
• We use simulation to find the possible solution
  in order to adapt to the nature of MANET
• Our leveling conception
• Avoid congestion
• Fine and delicate adjustment of data rate
• Maintain throughput

30
Data Rate Adjustment Index Conversion -
Multi-level (2/6)

• Our previous study

Aggressive Deceleration
Moderate Acceleration/Deceleration
Aggressive Acceleration
31
Data Rate Adjustment Index Conversion -
Multi-level (3/6)
Parameter Range
Node Number 4 32
Bandwidth 2Mbps
MAC 802.11
Receiver window size 4 ? 8 ? 32
Parameters
Number of levels
Different setting for each level
Level range
Number of Node
Bandwidth

32
Data Rate Adjustment Index Conversion -
Multi-level (4/6)
1
Index 1 Aggressive Deceleration
2
Index 2 Moderate Deceleration
Data Rate Adjustment Index
Index 3 Stabilizing
3
Index 4 Moderate Deceleration
4
Index 5 Aggressive Acceleration
5
33
Data Rate Adjustment Index Conversion -
Multi-level (5/6)

• Each router estimates available bandwidth itself
  and convert this to DRAI
• Total bandwidth / Number of Flow ? Convert
• Then each router compares and marks every passed
  packet with DRAI
• If the value is greater, then DRAI stay untouched
• Otherwise, replace it with new DRAI
• The smallest value of DRAI
• Minimal data Rate Adjustment Index (MRAI)

34
Data Rate Adjustment Index Conversion -
Multi-level (6/6)
11Mbps
1Mbps
1Mbps
11Mbps
1Mbps
5Mbps
Router
Router
Receiver
bottleneck
Sender
1Mbps
35
TCP Muzha

• Handling of Random loss
• The effect of random loss
• Retransmission
• Timeout
• Reduction of congestion window size
• Original indication of packet loss
• 3 duplicate ACK
• Our approach
• 3 duplicate ACK with deceleration marking
  (congestion)
• 3 duplicate ACK with acceleration marking or no
  marking (random loss)

36
TCP Muzha

• We simplify three phases of TCP NewReno into two
  phases
• Congestion Avoidance (CA)
• Fast Retransmit and Fast Recovery (FF)

37
TCP Muzha
38
Outline

• Introduction
• Related work
• TCP Muzha
• Performance evaluation
• Conclusion

39
Performance Evaluation

• Parameters
• Chain topology (432 hops)
• Link Layer IEEE 802.11 MAC
• Bandwidth 2MB/s
• Transmission radius 250m
• Routing AODV

Single TCP Flow
1
2
3
4
5
6
7
8
9
40
Performance Evaluation

• Evaluation metrics
• Congestion window size change
• Throughput
• Retransmission
• Fairness

41
Performance Evaluation

• Metrics
• Congestion window size change
• Throughput
• Retransmission
• Fairness

42
Performance Evaluation
43
Performance Evaluation
44
Performance Evaluation
45
Performance Evaluation

• Metrics
• Congestion window size change
• Throughput
• Retransmission
• Fairness

46
Performance Evaluation
47
Performance Evaluation
48
Performance Evaluation
49
Performance Evaluation

• Metrics
• Congestion window size change
• Throughput
• Retransmission
• Fairness

50
Performance Evaluation
51
Performance Evaluation
52
Performance Evaluation
53
Performance Evaluation

• Metrics
• Congestion window size change
• Throughput
• Retransmission
• Fairness

54
Performance Evaluation

• Fairness test 1
• Cross Topology
• 4 hops, 6 hops, and 8 hops
• Bandwidth 2Mb/s
• Simulation time 50 sec
• Two Sets
• TCP Vegas, TCP NewReno
• TCP Muzha, TCP NewReno
• Fairness test 2
• Throughput dynamics

55
Performance Evaluation

• Fairness Index
• Jains Fairness Index

n Number of Flow ?i throughput of the i-th flow
56
Performance Evaluation

• Fairness comparison - Throughput

57
Performance Evaluation

• Fairness comparison Jains Index

58
Performance Evaluation

• Fairness test 1
• Cross Topology
• 4 hops, 6 hops, and 8 hops
• Bandwidth 2Mb/s
• Two Sets
• TCP Vegas, TCP NewReno
• TCP Muzha, TCP NewReno
• Fairness test 2
• Throughput dynamics
• Three flows, each starts at different times

59
Performance Evaluation
60
Outline

• Introduction
• Related work
• TCP Muzha
• Performance evaluation
• Conclusion

61
Conclusion

• TCP is still a dominant transport layer protocol
  for conventional and emerging application
• We proposed a new TCP scheme over MANET by
  router-assisted approach in order to improve the
  performance of TCP.
• By assistance of router, our scheme has about
  510 throughput improvement and less
  retransmission in MANET.
• Our proposed protocol provides fairness service
  for different flows while coexisting with other
  TCP variants.
• The future work is the further investigation of
  DRAI function and different explicit information
  from router.

62
Discussion

• AIMD
• LIMD
• MIMD

63
Discussion

• Estimation of available bandwidth
• Moving Average

Utilization at time t
Link Utilization Measurement
Moving Average
64
QA
65
(No Transcript)
66
(No Transcript)
67
Discussion

• Model ?
• BDP (Bandwidth-Delay Product)?
• TCP receiver estimates the optimum window size
  according to the router feedback and sets CWL by
  the awnd (Advertised Window)
• Use of Pacing ?

68
TCP Muzha
69
Summary

• MANET is a very unstable network
• Most versions of TCP suffer great performance
  degradation over such network
• Router-assisted approach may not be easy to
  implement on WAN
• However due to the unique characteristic of MANET
  (Hybrid role for each host ) and ease of
  modification, router-assisted approach can be a
  reality to improve the performance of TCP over
  MANET

70
TCP Muzha Ver. 2

• Modification of TCP Muzha
• Congestion Control
• Based on TCP New Reno
• New Data Rate Adjustment Index (DRAI)
• Link Error and packet loss Handling

71
Conclusion

• TCP is still a dominant transport layer protocol
  for conventional and emerging application
• We proposed a new TCP scheme over MANET by
  router-assisted approach in order to improve the
  performance of TCP.
• The future work is the consideration of mobility
  

72
Related Work

• TCP Reno, New Reno and SACK
• TCP Reno
• Slow-Start
• AIMD ( Additive Increase Multiplicative Decrease)
• Fast retransmit and recovery
• Only single packet drop within one window can be
  recovered
• Long retransmission timeout in case of multiple
  packet losses
• New Reno
• Deal with multiple losses within a single window
• Retransmit one lost packet per one RTT until all
  the lost packets from the same window are
  recovered.
• SACK
• Deal with the same problem as New Reno
• Use SACK option field which contains a number of
  SACK blocks
• Lost packets in a single window can be recovered
  within one RTT

73
Related Work

• TCP Vegas
• Vegas measures RTT to calculate the amount of
  packets that sender can transmit
• The congestion window size can only be doubled
  every other RTT and reduced by 1/8 to keep proper
  amount of packets in the network
• Smooth the change of data rate

74
Related Work

• TCP Veno
• Combinations of TCP Vegas and Reno
• Veno uses Vegas to determine types of packet loss
• Random loss or actual congestion
• Veno modifies Reno with less aggressive sending
  rate
• Prevention of unnecessary throughput degradation

75
Related Work

• ECN (Explicit Congestion Notification)
• ECN must be supported by both TCP senders and
  receivers.
• ECN-compliant TCP senders initiate their
  congestion avoidance algorithm after receiving
  marked ACK packets from the TCP receiver
• A RED extension that marks packets to signal
  congestion

76
Related Work

• Anti-ECN
• Routers set a bit in the packet header to
  indicate an under-utilized link
• Allow sender to increase as fast as slow start
  over an uncongested path

77
Related Work

• Quick Start
• Slow start require significant number of RTTs and
  large amount of data to fully use the available
  bandwidth .
• Quick Start allows sender to use higher sending
  rate according to the explicit request permission
  from routers along the path
• If the routers are underutilized, they may
  approve the senders request for a higher sending
  rate

78
Related Work

• XCP (Explicit Congestion control protocol)
• XCP generalizes the ECN
• Instead of one bit congestion indication, XCP
  routers inform the senders about the degree of
  congestion at the bottleneck
• Decoupling of utilization control from fairness
  control

79
Related Work

• TCP-Muzha
• Router-assisted approach
• Find out where the bottleneck is and the
  information of the bottleneck
• Multi-level Date Rate Adjustment Index
• Fuzzy multilevel congestion notification

80
Our Approach

• AIMD vs AIAD vs MIAD vs MIMD
• AI 1,2,3
• AD 1,2,3
• MI 1.125, 0.19, 0.25
• MD 0.5, 0.65, 0.8
• Final four setting
• AIMD (1, 0.8)
• AIAD (1, 3)
• MIMD (1.125, 0.8)
• MIAD (1.125, 3)

81
Performance Evaluation
82
Performance Evaluation
Muzha
SACK
NewReno
Vegas
83
Introduction

• TCP overshooting problem

84
Related Work

• TCP-Bus (Buffering capacity and Sequence
  information)
• Based on source-initiated on-demand ABR routing
  protocol
• If a route fails ,pivoting node notify source
• Explicit Route Disconnection Notification
• With the sequence number of the TCP segment in
  the head of queue
• During the route re-establishment, packets sent
  are buffered,RTO doubled
• When a route is discovery, the receiver sends to
  the sender the last sequence number it has
  successfully received
• The sender only selectively retransmit the lost
  packets and the intermediate node starts sending
  the buffered packets.
• Reliable retransmission of the control message
  (ERDN/ERSN)
• Detect the channel after sending the control
  message
• Retransmission if sending fails
• Contribution
• packets buffered, reliable transmission of
  control packet

85
TCP Muzha
DRAI Meaning Change of CWND
5 Aggressive Acceleration cwnd cwnd 2
4 Moderate Acceleration cwnd cwnd1
3 Stabilizing cwnd cwnd
2 Moderate Deceleration cwnd cwnd -1
1 Aggressive Deceleration cwnd cwnd 1/2
86
Performance Evaluation

• Index Comparison (4 hops) (Bar graph)

TCP Newreno TCP Vegas TCP Muzha
Avg. Throughput (kbps) 175 214 186
Avg. Retransmission 14 6 10
Fairness ( with Newreno) 0.925 0.99
87
Performance Evaluation

• Index Comparison (6 hops)

TCP Newreno TCP Vegas TCP Muzha
Avg. Throughput (kbps) 54 89 65
Avg. Retransmission 16 6 10
Fairness ( with Newreno) 0.74 0.99
88
Performance Evaluation

• Index Comparison (8 hops)

TCP Newreno TCP Vegas TCP Muzha
Avg. Throughput (kbps) 34 35 37
Avg. Retransmission 25 9 18
Fairness ( with Newreno) 0.89 0.99
89
Performance Evaluation

• 4 hop cross topology

Vegas Newreno
Muzha Newreno
Throughput (Kbps) Delay (ms)
Flow1 (Vegas) 35.7 72.4
Flow2 (Newreno) 118.0 100.4
Aggregate 153.7
Fairness 0.72
Throughput (Kbps) Delay (ms)
Flow1 (Muhza) 106.0 63.9
Flow2 (Newreno) 102.0 65.3
Aggregate 208
Fairness 0.99
90
Performance Evaluation

• 6 hop cross topology

Vegas Newreno
Muzha Newreno
Throughput (Kbps) Delay (ms)
Flow1 (Vegas) 23.2 264.0
Flow2 (Newreno) 89.9 101.6
Aggregate 113.1
Fairness 0.74
Throughput (Kbps) Delay (ms)
Flow1 (Muhza) 65.3 119.5
Flow2 (Newreno) 53.6 112.4
Aggregate 118.9
Fairness 0.99
91
Performance Evaluation

• 8 hop cross topology

Vegas Newreno
Muzha Newreno
Throughput (Kbps) Delay (ms)
Flow1 (Vegas) 20.2 91.9
Flow2 (Newreno) 41.7 168.0
Aggregate 61.9
Fairness 0.89
Throughput (Kbps) Delay (ms)
Flow1 (Muhza) 43.7 97.2
Flow2 (Newreno) 36.8 112.4
Aggregate 80.5
Fairness 0.99