TCP NewReno has modifications to the fast retransmit and fast recovery of TCP Reno. These modifications are intended to fix the Reno problems without the addi-tion of SACK and only have to be implemented on the sender side.
In TCP Reno, partial ACKs3 bringing the connection out of fast recovery result in a retransmission timeout in the case of multiple packet losses. In TCP NewReno, when a source receives a partial ACK, it does not exit fast recovery [5, 19]. Instead, it assumes that the packet immediately following the most recently acknowledged packet has been lost and hence retransmits the lost packet. Thus, in the case of mul-tiple packet losses, TCP NewReno will retransmit one lost packet per round-trip time until all the lost packets from the same window have been recovered. This avoids requiring multiple fast retransmits from a single window of data, and alleviates re-transmission timeout. It remains in the fast recovery phase until all outstanding packets at the start of that phase have been acknowledged. The implementation details of TCP NewReno are as follows:
(1) Multiple packet losses: A fix for fast recovery to prevent fast retransmit and fast recovery from starting in succession when multiple segments in the same window are dropped. So far, when entering fast retransmit, the packet with the highest sequence number was sent. NewReno performs retransmission and fast recovery algorithm which is similar to Reno. However, the difference between NewReno and Reno is that when a new ACK arrives, NewReno checks whether the ACK covers the highest sequence number when fast retransmit was invoked. If not, this ACK is a partial ACK which signals that another segment was lost from the same window of data. As a result, NewReno retransmits the segment reported, as expected by the partial ACK and resets the retransmission timer, but does not exit fast recovery. On the other hand, if the new ACK covers the highest sequence number, NewReno will exit fast recovery but set CWND to the SSTHRESH and enter congestion avoidance phase.
(2) False fast recovery: NewReno records the highest sequence number ever transmitted after a retransmission timeout. Whenever three dupacks are received, NewReno performs a test to see if it should enter fast recovery. If these ACKs cover the sequence number saved at the previous timeout, then this is a new invocation
3Partial ACK is an acknowledgement that acknowledges some, but not all, of the outstanding packets at the start of the fast recovery phase.
of the fast recovery. In this case, NewReno will enter fast recovery and perform the related actions. If these ACKs do not cover the sequence numbers and acknowledge the receipt of already queued segments at the receiver, NewReno will not enter fast recovery. A sender exits fast recovery only after all the outstanding packets (at the time of first loss) are acked.
NewReno makes a small change to a connection source: it may eliminate TCP Reno’s waiting for a retransmission timeout when multiple packets from a window are lost. Although this can avoid the unnecessary window reduction, the downside is that NewReno may take many RTTs to recover a loss episode, and it must have enough new data around to keep the ACK clock running. In other words, the recovery time of NewReno is still too long.
2.3 SACK
Another way to deal with multiple packet losses is to tell the source which packets have arrived at the destination. Selective Acknowledgments (SACK) does so ex-actly. TCP adapts accumulated acknowledgement strategy to acknowledge success-fully transmitted packets; this improves the robustness of acknowledgement when the path back to the source features a high loss rate. However, the drawback of accumulated acknowledgement is that after a packet loss, the source is unable to determine which packets have been successfully transmitted. Therefore, it is unable to recover more than one lost packet in each round-trip time.
The SACK option field contains a number of SACK blocks, where each SACK block reports a non-contiguous set of data that has been received and buffered.
The destination uses ACK with the SACK option to inform the source that one contiguous block of data has been received out of order at the destination.
When SACK blocks are received by the source, they are used to maintain an image of the receiver queue, i.e., which packets have been missing and which have been received at the destination. A scoreboard is set up to track these transmitted and received packets according to previous information in the SACK option. For
each transmitted packet, the scoreboard records its sequence number and a flag bit that indicates whether the packet has been “SACKed.” A packet with the SACKed bit turned on does not require to be retransmitted, but packets with the SACKed bit off and a sequence number less than the highest SACKed packet are eligible for retransmission. Whether a SACKed packet is on or off, it is removed from the retransmission buffer only when it has been cumulatively acknowledged.
SACK TCP implementation still uses the same congestion control algorithms as TCP Reno. The main difference between SACK TCP and TCP Reno is the behavior in the event of multiple packet losses. SACK TCP refines the fast retransmit and fast recovery strategy of TCP Reno so that multiple lost packets in a single window can be recovered within one round-trip time.
However, there are two shortcomings of SACK. One is that a maximum of 3 or 4 SACK blocks will be allowed in a SACK option. A SACK option that specifies n blocks will have a length of 8 × n + 2 bytes, so the 40 bytes available for TCP options can specify a maximum of 4 blocks. In addition, it is expected that SACK will often be used in conjunction with the Timestamp option used for round-trip time measurement (RTTM), which takes an additional 10 bytes (plus two bytes of padding); thus, a maximum of 3 SACK blocks is allowed in this case. Accordingly, if there are several non-contiguous sets of data at the destination, the sender may not know the whole situation from the SACK option. The other drawback is that if the receiver runs out of buffer space, it will discard the “SACKed” packets with-out reporting this information to the sender. The sender will not retransmit these
“SACKed” packets before it is acknowledged by the Acknowledgment Number field in the TCP header.