
Advanced Wireless Networks - 4G Technologies
.pdf

RANDOM EARLY DETECTION GATEWAYS FOR CONGESTION AVOIDANCE |
279 |
|
800 |
|
|
|
|
|
|
|
700 |
|
|
|
|
|
|
|
600 |
|
|
|
|
|
|
(s) |
500 |
|
|
|
|
|
|
time |
|
|
|
|
|
|
|
400 |
|
|
|
|
|
|
|
Transfer |
|
|
|
|
|
|
|
300 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
200 |
|
|
|
|
M-TCP |
|
|
|
|
|
|
|
TCP |
|
|
100 |
|
|
|
|
500 K file |
|
|
|
|
|
|
|
Normal means |
|
|
0 |
|
|
|
|
|
|
|
1.5 |
2.0 |
2.5 |
3.0 |
3.5 |
4.0 |
4.5 |
Disconnection length (s)
|
2000 |
|
|
|
|
|
|
|
|
1800 |
|
M-TCP |
|
|
|
|
|
|
|
TCP |
|
|
|
|
|
|
|
1600 |
1 MB file |
|
|
|
|
|
|
|
Normal means |
|
|
|
|
|
||
|
|
|
|
|
|
|
||
(s) |
1400 |
|
|
|
|
|
|
|
1200 |
|
|
|
|
|
|
|
|
time |
|
|
|
|
|
|
|
|
1000 |
|
|
|
|
|
|
|
|
Transfer |
|
|
|
|
|
|
|
|
800 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
600 |
|
|
|
|
|
|
|
|
400 |
|
|
|
|
|
|
|
|
200 |
|
|
|
|
|
|
|
|
0 |
|
|
|
|
|
|
|
|
|
1.5 |
2.0 |
2.5 |
3.0 |
3.5 |
4.0 |
4.5 |
Disconnection length (s)
Figure 9.8 M-TCP/TCP vs disconnection length performance – 15 hops TCP connection.
five hops (Figure 9.7) and 15 hops (Figure 9.8) away. We can see that M-TCP offers better performance.
9.4 RANDOM EARLY DETECTION GATEWAYS FOR CONGESTION AVOIDANCE
In this section we discuss random early detection gateways for congestion avoidance in packet-switched networks [25]. RED gateways are designed to accompany a transport-layer congestion control protocol. The gateway detects incipient congestion by computing the average queue size. The gateway could notify connections of congestion either by dropping packets arriving at the gateway or by setting a bit in packet headers. When the average queue size exceeds a preset threshold, the gateway drops or marks each arriving packet with a certain probability, where the exact probability is a function of the average queue size.
280 ADAPTIVE TCP LAYER
Prior to RED, early random drop gateways have been studied as a method for providing congestion avoidance at the gateway. The initial works proposed gateways to monitor the average queue size to detect incipient congestion and to randomly drop packets when congestion is detected. RED gateways differ from the earlier early random drop gateways in several respects: (1) the literate queue size is measured; (2) the gateway is not limited to dropping packets; and (3) the packet-marking probability is a function of the average queue size.
With an even earlier version called random drop gateways, when a packet arrives at the gateway and the queue is full, the gateway randomly chooses a packet from the gateway queue to drop. In the implementation of early random drop gateways, if the queue length exceeds a certain drop level, then the gateway drops each packet arriving at the gateway with a fixed drop probability p. Even then, it was stressed that, in future implementations, the drop level and drop probability should be adjusted dynamically depending on network traffic. With drop tail gateways, each congestion period introduces global synchronization in the network. When the queue overflows, packets are often dropped from several connections, and these connections decrease their windows at the same time. This results in a loss of throughput at the gateway.
9.4.1 The RED algorithm
The RED gateway calculates the average queue sizeWq. The average queue size is compared with a minimum (Wq−) and a maximum (Wq+) threshold. When the average queue size is less than the minimum threshold, no packets are marked. When the average queue size is greater than the maximum threshold, every arriving packet is marked. If marked packets are, in fact, dropped or if all source nodes are cooperative, this ensures that the average queue size does not significantly exceed the maximum threshold. When the average queue size is between the minimum and maximum thresholds, each arriving packet is marked with probability p0, where p0 is a function of the average queue size W q. Each time a packet is marked, the probability that a packet is marked from a particular connection is roughly proportional to that connection’s share of the bandwidth at the gateway.
Thus, the RED gateway has two separate algorithms. The algorithm for computing the average queue size determines the degree of burstiness that will be allowed in the gateway queue. The algorithm for calculating the packet-marking probability determines how frequently the gateway marks packets, given the current level of congestion. The goal is for the gateway to mark packets at fairly evenly spaced intervals, in order to avoid biases and avoid global synchronization, and to mark packets sufficiently frequently to control the average queue size.
The gateway’s calculations of the average queue size take into account the period when the queue is empty (the idle period) by estimating the number m of small packets that could have been transmitted by the gateway during the idle period. After the idle period, the gateway computes the average queue size as if m packets had arrived to an empty queue during that period. As Wq varies from Wq− to Wq+, the packet-marking probability pb varies linearly from
0 to its maximum value P: pb ← P(Wq − Wq−)/(Wq+ − Wq−). The final packet-marking probability pa increases slowly as the count c increases since the last marked packet: pb ←
pb/ (1 − cpb). This ensures that the gateway does not wait too long before marking a packet. The gateway marks each packet that arrives at the gateway when W q > Wq+.



TCP FOR MOBILE AD HOC NETWORKS |
283 |
|
15 |
|
|
|
|
|
|
|
queue (in packets) |
10 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Average |
5 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
0 |
|
|
|
|
|
|
|
|
8 |
10 |
12 |
14 |
16 |
18 |
20 |
22 |
Buffer size
|
1.0 |
|
|
|
|
|
|
|
utilization |
|
|
|
|
|
|
|
|
Average link |
0.9 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
0.8 |
|
|
|
|
|
|
|
|
8 |
10 |
12 |
14 |
16 |
18 |
20 |
22 |
Buffer size
Figure 9.11 Drop tail gateway average queue length and link utilization.
connections, the throughput of the connection is observed to be extremely poor because TCP treats lost or delayed acknowledgments as congestion. In this section, we present an approach where a thin layer between Internet protocol and standard TCP is inserted that corrects these problems and maintains high end-to-end TCP throughput. This sublayer will be referred to as the ad-hoc TCP sublayer or A-TCP [26].
9.5.1 Effect of route recomputations
As we will see in Chapter 13, when an old route is no longer available, the network layer at the sender attempts to find a new route to the destination. In dynamic source routing (DSR) this is done via route discovery messages while in destination-sequenced distance-vectoring (DSDV) table exchanges are triggered that eventually result in a new route being found. It is possible that discovering a new route may take significantly longer than the RTO at the sender. As a result, the TCP sender times out, retransmits a packet, and invokes congestion control. Thus, when a new route is discovered, the throughput will continue to be small
284 ADAPTIVE TCP LAYER
for some time because TCP at the sender grows its congestion window using the slow start and congestion avoidance algorithm. This is again undesirable behavior because the TCP connection will be very inefficient. If we imagine a network in which route computations are done frequently (due to high node mobility), the TCP connection will never get an opportunity to transmit at the maximum negotiated rate (i.e. the congestion window will always be significantly smaller than the advertised window size from the receiver).
9.5.2 Effect of network partitions
It is likely that the ad hoc network may periodically get partitioned for several seconds at a time. If the sender and the receiver of a TCP connection lie in different partitions, all the sender’s packets get dropped by the network, resulting in the sender invoking congestion control. If the partition lasts for a significant amount of time (say, several times longer than the RTO), the situation gets even worse because of a phenomeon called serial timeouts. A serial timeout is a condition wherein multiple consecutive retransmissions of the same segment are transmitted to the receiver while it is disconnected from the sender. All these retransmissions are, thus, lost. Since the retransmission timer at the sender is doubled with each unsuccessful retransmission attempt (until it reaches 64 s), several consecutive failures can lead to inactivity lasting 1 or 2 minutes, even when the sender and receiver get reconnected.
9.5.3 Effect of multipath routing
As we will see in Chapter 13,some routing protocols, such as the temporally ordered routing algorithm (TORA) , maintain multiple routes between source destination pairs, the purpose of which is to minimize the frequency of route recomputation. Unfortunately, this sometimes results in a significant number of out-of-sequence packets arriving at the receiver. The effect of this is that the receiver generates duplicate ACKs which cause the sender (on receipt of three duplicate ACKs) to invoke congestion control.
The congestion window in TCP imposes an acceptable data rate for a particular connection based on congestion information that is derived from timeout events as well as from duplicate ACKs. In an ad hoc network, since routes change during the lifetime of a connection, we lose the relationship between the congestion window (CWND) size and the tolerable data rate for the route. In other words, the CWND as computed for one route may be too large for a newer route, resulting in network congestion when the sender transmits at the full rate allowed by the old CWND.
9.5.4 ATCP sublayer
The ATCP sublayer utilizes network layer feedback (from intermediate hops) to put the TCP sender into either a persist state, congestion control state or retransmit state. So, when the network is partitioned, the TCP sender is put into persist mode so that it does not needlessly transmit and retransmit packets. On the other hand, when packets are lost due to error (as opposed to congestion), the TCP sender retransmits packets without invoking congestion control. Finally, when the network is truly congested, the TCP sender invokes congestion control normally.
TCP FOR MOBILE AD HOC NETWORKS |
285 |
We do not have to modify standard TCP itself when we want to maintain compatibility with the standard TCP/IP suite. Therefore, to implement this solution, we can insert a thin layer called ATCP (ad hoc TCP) between IP and TCP that listens to the network state information provided by ECN [27] messages and by ICMP ‘destination unreachable’ messages and then puts TCP at the sender into the appropriate state. Thus, on receipt of a ‘destination unreachable’ message, the TCP state at the sender is frozen (the sender enters the persist state) until a new route is found, ensuring that the sender does not invoke congestion control. Furthermore, the sender does not send packets into the network during the period when no route exists between the source and destination.
The ECN, which will be discussed later in more detail, is used as a mechanism by which the sender is notified of impending network congestion along the route followed by the TCP connection. On receipt of an ECN, the sender invokes congestion control without waiting for a timeout event (which may be caused, more often than not, due to lost packets). Thus, the benefits of A-TCP sublayer are:
Standard TCP/IP is unmodified.
ATCP is invisible to TCP and, therefore, nodes with and without ATCP can interoperate. The only drawback is that nodes without ATCP will see all the performance problems associated with running TCP over ad hoc networks.
ATCP does not interfere with TCPs functioning in cases where the TCP connection is between a node in the wireline network and another in the wireless ad hoc network.
There are in the literature papers dealing with different aspects of TCP problem in ad hoc networks. Holland and Vaidya [28], for example, investigate the impact of link breakage on TCP performance in such networks. They use dynamic source routing (DSR), discussed in Chapter 13 (see also Johnson and Maltz [29]), as the underlying routing protocol (simulated in NS2). DSR is an on-demand routing protocol where a sender finds a route to the destination by flooding route request packets. DSR’s performance is optimized by allowing intermediate nodes to respond to route request packets using cached routes. Unfortunately, if the cached information maintained at a intermediate node is stale, the time it takes to find a new route can be very long (several seconds). Thus, TCP running on top of DSR sees very poor throughput. The paper proposes the use of explicit link failure notification (ELFN) to improve TCP performance. Here, the TCP sender is notified that a link has failed, and it disables its retransmission timer and enters a stand-by mode. In stand-by mode, the TCP sender periodically sends a packet in its congestion window to the destination. When an ACK is received, TCP leaves the stand-by mode, restores its retransmission timers and resumes transmission as normal.
Chandran et al. [30] discusses a similar scheme for improving TCP performance in ad hoc networks in the presence of failures. Here, the router detecting a failed route generates a route failure notification (RFN) packet toward the source. The TCP source that receives this packet enters a snooze state which is very similar to TCP’s persist state. When the route is re-established, a route re-establishment notification (RRN) is sent to the source by any router on the previous route that detected the new route. This packet removes the source from the snooze state. In this method, the source continues using the old congestion window size for the new route. This is a problem because the congestion window size is route-specific (since it seeks to approximate the available bandwidth). Chandran et al. [30] also does not consider the effects of congestion, out-of-order packets and bit error.
286 ADAPTIVE TCP LAYER
9.5.5 ATCP protocol design
In this section we discuss the design of an ATCP that attempts to provide an integral solution to the problems of running TCP over multihop wireless networks. Such a protocol should have the following characteristics [26]:
(1)It should Improve TCP performance for connections set up in ad hoc wireless networks. As already discussed, TCP performance is affected by the problems of high BER and disconnections due to route recomputation or partition. In each of these cases, the TCP sender mistakenly invokes congestion control. A good protocol should provide only retransmissions for packets lost due to high BER, without shrinking the congestion window. Also, the sender should stop transmitting and resume when a new route has been found.the As above, in the case of transient partition, the sender should stop transmitting until it is reconnected to the receiver. In the case of multipath routing when TCP at the sender receives duplicate ACKs, it should not invoke congestion control because multipath routing shuffles the order in which packets are received.
(2)It should maintain TCP’s congestion control. If losses are caused due to network congestion, we want TCP to shrink its congestion window in response to losses and invoke slow start.
(3)It should have appropriate CWND. When there is a change in the route (e.g. a reconnection after a brief partition), the congestion window should be recomputed.
(4)It should maintain end-to-end TCP semantics in order to ensure that applications do not crash.
(5)It should be compatible with standard TCP because we cannot assume that all machines deployed in an ad hoc network will have ATCP installed.
The above functionalities are implemented within a separate sublayer, the ATCP, placed between the network and TCP layer in the protocol stack (TCP/ATCP/IP stack). This layer monitors the TCP state and the state of the network (based on ECN and ICMP messages) and takes appropriate action. Figure 9.12 illustrates ATCP’s four possible states: normal, congested, loss and disconnected. When the TCP connection is initially established, ATCP at the sender is in the normal state.
In this state, ATCP does nothing and is invisible. Let us now examine ATCP’s behavior under four circumstances.
9.5.5.1 Lossy channel
When the connection from the sender to the receiver is lossy, it is likely that some segments will not arrive at the receiver or may arrive out-of-order. Thus, the receiver may generate duplicate acknowledgment (ACKs) in response to out-of-sequence segments. When TCP receives three consecutive duplicate ACKs, it retransmits the appropriate segment and shrinks the congestion window. It is also possible that, due to lost ACKs, the TCP sender’s RTO may expire, causing it to retransmit one segment and invoke congestion control.
ATCP in its normal state counts the number of duplicate ACKs received for any segment. When it sees that three duplicate ACKs have been received, it does not forward the third
