In TCP-Reno, when the packet loss occurs, a TCP receiver sends a duplicate ACK immediately while a TCP sender utilizes a fast retransmit mechanism, where the arrival of 3 duplicate ACKs indicates that a packet has been lost and recovers the missing packet without waiting for a retransmission timer to expire. A fast recovery algorithm, in turn, governs the transmission of new data packets until a non-duplicate ACK arrives.

TCP-Vegas introduces a proactive congestion avoidance technique which does not violate the congestion avoidance paradigm of TCP. It is able to utilize extra bandwidth without the network congestion and oscillation in window size, whereas TCP Reno always updates its window size to guarantee full bandwidth utilization, which leads to packet losses constantly.

Read more…

This work analyzes the effect of rate-based pacing over TCP (i.e. Reno and Vegas) with delayed acknowledgement strategy.

TCP acknowledgement (ACK) packets must travel upstream to the TCP source against the downstream flow of TCP data packets. Correlated arrivals of TCP data and ACK packets lead to contention for the wireless channel, which can cause collisions and even packet losses. These problems arise even for a single TCP flow on a multi-hop wireless network. As a result, throughput degrades as the length of the multi-hop path increases.

The TCP data sender transmits data to the TCP data receivers and the receiver transmits ACKs back to the sender as segments arrive. The sender would retransmit any segments that are not acknowledged by the receiver and this provides reliability. Initially, a TCP receiver generates an ACK for every incoming segment. These ACKs are cumulative and acknowledge all in-order segments that have arrived at the receiver. If a receiver has received an out-of-order segment, an ACK is transmitted. However, it will not acknowledge the incoming segment, but rather a duplicate ACK for the last in-order segment is generated.

In an optional delayed acknowledgement strategy, delayed ACKs allow a receiver to refrain from transmitting an ACK for every incoming segment. In the case of rate-based pacing, pacing is a hybrid between pure rate control and TCP’s use of acknowledgments to trigger new data to be sent into the network. This pace or rate should be based on a fraction of prior estimates of data transfer rate, since that is the closest estimate of available bandwidth, which is called the rate-based pacing. Using pacing can be avoided starting TCP slow start after a packet loss or when an idle connection resumes.

Read more…

For wireless ad hoc networks, the issue of routing packets between any pair of nodes becomes a challenging task because the nodes can move randomly within the network. A path that is considered optimal at a given point in time might not work at all a few moments later. Traditional routing protocols, such as DSDV, are proactive in that they maintain routes to all nodes. They react to any change in the topology even if no traffic is affected by the change and they require periodic control messages to maintain routes to every node in the network. As mobility increases, more of scarce resources, such as bandwidth and power, is used. Alternative reactive routing protocols, such as DSR and AODV, determine when routes are needed to route packets to to prevent nodes from updating every possible route in the network.

On the other hand, the role of TCP is important to transport data packets. The TCP protocol provides reliability, flow control, congestion avoidance, fairness, and in-order delivery. Originally, the protocol did not have congestion avoidance, causing the networks to become overloaded. TCP Tahoe introduced congestion avoidance, where dropped packets are used as an indication of congestion, and slow start, where the initial window size keeps doubling until congestion is detected. Later enhancements, such as TCP-Reno, New Reno, Vegas and Westwood, perform differently in wireless environments.

Read more…