Simulation-based comparisons of Tahoe, Reno and SACK TCP
Summary (4 min read)
1 Introduction
- Current implementations of TCP use an acknowledgment number field that contains a cumulative acknowledgment, indicating the TCP receiver has received all of the data up to the indicated byte.
- Several transport protocols have provided for selective acknowledgment (SACK) of received data.
- The authors use simulations to show how the SACK option defined in [MMFR96] can be of substantial benefit relative to TCP without SACK.
- Without SACK, Reno TCP has performance problems when multiple packets are dropped from one window of data.
2 Tahoe TCP
- Modern TCP implementations contain a number of algorithms aimed at controlling network congestion while maintaining good user throughput.
- These TCPs did little to minimize network congestion.
- The Tahoe TCP implementation added a number of new algorithms and refinements to earlier implementations.
- All modifications have been described elsewhere [Jac88, Ste94].
- With Fast Retransmit, after receiving a small number of duplicate acknowledgments for the same TCP segment (dup ACKs), the data sender infers that a packet has been lost and retransmits the packet without waiting for a retransmission timer to expire, leading to higher channel utilization and connection throughput.
3 Reno TCP
- The Reno TCP implementation retained the enhancements incorporated into Tahoe, but modified the Fast Retransmit operation to include Fast Recovery [Jac90].
- This threshold, usually known as tcprexmtthresh, is generally set to three.
- Instead of slow-starting, as is performed by a Tahoe TCP sender, the Reno sender uses additional incoming dup ACKs to clock subsequent outgoing packets.
- After entering Fast Recovery and retransmitting a single packet, the sender effectively waits until half a window of dup ACKs have been received, and then sends a new packet for each additional dup ACK that is received.
- Reno's Fast Recovery algorithm is optimized for the case when a single packet is dropped from a window of data.
4 New-Reno TCP
- At the same time, the authors use New-Reno TCP to explore the fundamental limitations of TCP performance in the absence of SACK.
- In New-Reno, partial ACKs do not take TCP out of Fast Recovery.
- Thus, when multiple packets are lost from a single window of data, New-Reno can recover without a retransmission timeout, retransmitting one lost packet per round-trip time until all of the lost packets from that window have been retransmitted.
- The bursts of packets upon exiting Fast Recovery with New-Reno TCP are illustrated in Section 6 in the simulations with three and four packet drops.
- She suggests the data sender send a new packet for every two dup ACKs received during Fast Recovery, to keep the “flywheel” of ACK and data packets going.
5 SACK TCP
- The SACK TCP implementation in this paper, called “Sack1” in their simulator, is also discussed in [Flo96b, Flo96a].
- When the SACK option is used with the Timestamp option specified for TCP Extensions for High Performance [BBJ92], then the SACK option has room for only three SACK blocks [MMFR96].
- The congestion control algorithms implemented in their SACK TCP are a conservative extension of Reno's congestion control, in that they use the same algorithms for increasing and decreasing the congestion window, and make minimal changes to the other congestion control algorithms.
- The sender retransmits a packet and cuts the congestion window in half.
- For any succeeding partial ACKs, pipe was incremented when the retransmitted packet entered the pipe, but was never decremented for the packet assumed to have been dropped.
6 Simulations
- This section describes simulations from four scenarios, with from one to four packets dropped from a window of data.
- The results of the Tahoe simulations are similar in all four scenarios.
- The Tahoe sender recovers with a For those reading the SACK code in the simulator, the boolean overhead parameter significantly complicates the code, but is only of concern in the simulator.
- For the scenario in Figure 3 with two dropped packets, the sender goes through Fast Retransmit and Fast Recovery twice in succession, unnecessarily reducing the congestion window twice.
6.1 The simulation scenario
- All of these simulations can be run on their simulator ns with the command test-sack.
- The second and third connections have limited data to send, and are included to achieve the desired pattern of packet drops for the first connection.
- Readers interested in the exact details of the simulation set-up are referred to the files test-sack and sack.tcl in their simulator ns [MF95].
- The simulation set run by the test-sack script includes simulations with multiple connections, two-way traffic, and data receivers that send an ACK for every two data packets received.
- Packets delayed at but not dropped will generate two colinear marks for a constant packet number, spaced by the queueing delay.
6.2 One Packet Loss
- Tahoe, Reno, New-Reno, and SACK TCP with one dropped packet.
- In Figure 2 with Tahoe TCP, packets 0–13 are sent without error as the sending TCP's congestion window increases exponentially from 1 to 15 according to the Slow-Start algorithm.
- The figure contains a square for each packet as it arrives and leaves the congested gateway.
- The third dup ACK triggers a retransmission of packet 14, puts the sender into Fast Recovery, and reduces its congestion window and SlowStart threshold to seven.
6.3 Two Packet Losses
- Tahoe, Reno, New-Reno, and SACK TCP with two dropped packets.
- The Reno sender is often forced to wait for a retransmit timeout to recover from two packets dropped from a window of data.
- At the time the first ACK for packet 27 is received, the sender exits Fast Recovery with a congestion window of seven, having been reduced from 15 after the first loss.
- At this point, the protocol initializes the pipe as follows:.
- The five additional dup ACKs for packet 27 minus one for the retransmission of packet 28 allow the sender to send packets 36–39.
6.4 Three Packet Losses
- Tahoe, Reno, New-Reno, and SACK TCP with three dropped packets.
- The sender continues in Slow-Start until packet 37, where it switches to Congestion Avoidance.
- When three packets are dropped from a window of data, the Reno sender is almost always forced to wait for a retransmit timeout.
- The next partial ACK acknowledges packet 27 and causes the sender to retransmit packet 28 and reduce its usable window to seven.
- The next three ACKs acknowledge packet 25 and contain SACK information indicating a hole at packets 26 and 28.
6.5 Four Packet Losses
- Tahoe, Reno, New-Reno, and SACK TCP with four dropped packets.
- New-Reno requires four roundtrip times to recover and to retransmit the four dropped packets, while the SACK TCP sender recovers quickly and smoothly.
- Upon receiving this ACK, the sender immediately retransmits packet 24 and sets its usable window to the congestion window of seven.
- This partial ACK, corresponding to the receiver receiving the retransmitted packet 14, causes the sender to reduce pipe by two, and also contains SACK information indicating holes at packets 24 and 26.
- Once again, the sender avoids retransmitting packet 28 and continues by sending packets 36 and 37.
7 A trace of Reno TCP
- The TCP trace in this section is taken from actual Internet traffic measurements, but exhibits behavior similar to that in their simulator.
- As a result, in the Congestion Avoidance phase the data sender normally sends two data packets for every ACK packet received.
- This is similar to the Reno behavior illustrated in the simulator.
- Thus, 13% of Vern's TCP traces are likely to include Reno TCP with multiple packet drops and an unnecessary retransmit timeout.
8 Future directions for selective acknowledgments
- The addition of selective acknowledgments allows additional improvements to TCP, in addition to improving the congestion control behavior when multiple packets are dropped in one window of data.
- [MM96] explores TCP congestion control algorithms for TCP with SACK.
- Further, with SACK the sender will know which packet has left the network, allowing the sender to make an informed guess about whether this is likely to be the last dup ACK that it will receive.
- The New-Reno and SACK implementations in their simulator use a “maxburst” parameter to limit the potential burstiness of the sender for the first window of packets sent after exiting from Fast Recovery.
- These proposals are not necessarily original with us, but are from general discussions in the research community about the use of SACK.
9 Conclusions
- And have examined a TCP implementation that incorporates selective acknowledgments into Reno TCP while making minimal changes to TCP's underlying congestion control algorithms.the authors.
- The authors assume that the addition of selective acknowledgments to TCP will open the way to further developments of the TCP protocol.
Did you find this useful? Give us your feedback
Citations
2,237 citations
2,145 citations
1,787 citations
1,602 citations
Cites background or methods or result from "Simulation-based comparisons of Tah..."
...The approach in [ FF96 ] is more conservative, and does not attempt to accurately track the actual number of outstanding packets after a partial acknowledgement is received....
[...]
...In contrast, the variant of NewReno illustrated in [ FF96 ] simply set the congestion window to ssthresh when a partial acknowledgement was received....
[...]
...(This behavior is illustrated in the New-Reno TCP simulation of Figure 5 in [ FF96 ], and on page 11 of [F98])....
[...]
...We note that the response to partial acknowledgements specified in Section 3 of this document and in RFC 2582 differs from the response in [ FF96 ], even though both approaches only retransmit one packet in response to a partial acknowledgement....
[...]
...(The [ FF96 ] behavior can be seen in the NS simulator by setting the variable "partial_window_deflation_" for "Agent/TCP/Newreno" to 0; the behavior specified in Section 3 is achieved by setting "partial_window_deflation_" to 1.)...
[...]
1,580 citations
References
6,198 citations
5,620 citations
1,639 citations
"Simulation-based comparisons of Tah..." refers background or methods in this paper
...We use simulations to show how the SACK option definedin [ MMFR96 ] can be of substantial benefitrelative to TCP without SACK....
[...]
...The SACK option follows the format in [ MMFR96 ]....
[...]
...The current proposal for adding SACK to TCP is given in [ MMFR96 ]....
[...]
...The 1990 “Sack” TCP implementation on our previous simulator is from Steven McCanne and Sally Floyd, and does not conform to the formats in [ MMFR96 ]....
[...]
...The first block in a SACK option is required to report the data receiver' s most recently received segment, and the additional SACK blocks repeat the most recently reported SACK blocks [ MMFR96 ]....
[...]
1,384 citations
1,325 citations