RFC 2018

RFC 2018
Title	TCP Selective Acknowledgment Options
Number	2018
Author	M. Mathis, J. Mahdavi, S. Floyd, A. Romanow
Date	October 1996
Updates	RFC 793
Status	Proposed Standard
Series	Request for Comments

RFC 2018 is a seminal Request for Comments document that defines the TCP Selective Acknowledgment (SACK) mechanism. Published in October 1996 by authors including Matt Mathis and Sally Floyd, it addresses a critical inefficiency in the original Transmission Control Protocol specification. The standard enables a TCP receiver to inform the sender about non-contiguous blocks of data that have been successfully received, significantly improving performance in lossy network conditions. This enhancement became a cornerstone for modern high-speed data transmission over networks like the Internet.

Overview

RFC 2018 was developed to solve a fundamental performance problem inherent in the cumulative acknowledgment scheme defined in the original TCP protocol, RFC 793. Under the traditional scheme, a receiver could only acknowledge the last in-order byte received, forcing the sender to retransmit all data from the first lost packet upon detecting a gap, a process known as go-back-N retransmission. This inefficiency, particularly detrimental on networks with high bandwidth-delay product or significant packet loss, was a known issue within the Internet Engineering Task Force. The proposal, building on earlier work in the research community, was advanced as a Proposed Standard to extend the TCP header with new options, allowing for more granular feedback. Its development was closely associated with the End-to-End Research Group and researchers at institutions like Lawrence Berkeley National Laboratory.

Technical Content

The document specifies the exact format and procedures for the TCP Selective Acknowledgment option within a TCP segment header. The option is negotiated during the initial TCP three-way handshake using the TCP Sack-Permitted Option defined in a companion document, RFC 2018's immediate predecessor, RFC 2018. Once permitted, the receiver can include SACK blocks in its acknowledgment segments. Each SACK block consists of two 32-bit fields defining the left and right edges of a contiguous block of data that has been received and queued. The RFC meticulously details edge cases, such as the generation of SACK blocks for duplicate segments and the management of the option's limited space within the TCP header, which is constrained by the maximum TCP header length. It also specifies that SACK information does not replace the fundamental TCP acknowledgment number field, which continues to indicate the next expected in-order byte.

TCP Selective Acknowledgment (SACK) Mechanism

The core mechanism allows a receiver, upon receiving out-of-order segments, to send back specific SACK blocks informing the sender which data ranges have been successfully stored in its buffer. For example, if a sender transmits segments 1-10 and segments 3 and 7 are lost, the receiver can acknowledge segment 2 and send SACK blocks for ranges covering segments 4-6 and 8-10. This enables the sender's algorithms, such as the Fast Retransmit algorithm, to retransmit only the specific missing segments (3 and 7) rather than all segments from 3 onward. This selective retransmission is a key component of advanced congestion control strategies and is integral to the performance of subsequent algorithms like TCP NewReno and TCP CUBIC. The mechanism effectively transforms the sender's retransmission strategy from a simple go-back-N to a more efficient selective repeat protocol.

Impact and Adoption

The adoption of TCP Selective Acknowledgment had a transformative impact on the performance and robustness of the global Internet, particularly as network speeds and latencies increased. It became a standard feature in all major operating systems, including those from Microsoft (Windows), various Berkeley Software Distribution derivatives, and Linux kernel implementations. Its importance was magnified with the rise of high-speed wide area network links and the challenges of wireless networks, where packet loss is not always due to congestion. The SACK mechanism is considered a prerequisite for effectively utilizing large TCP window scale factors, as defined in RFC 1323. Widespread implementation was a critical step before the deployment of later advanced congestion avoidance algorithms.

Relationship to Other RFCs

RFC 2018 is part of a closely related series of documents from the same period that updated core TCP functionality. It directly updates the original protocol specification, RFC 793. Its capability is negotiated using the Sack-Permitted Option defined in its sister document, RFC 2018. The mechanism is often discussed in conjunction with the TCP Timestamps Option from RFC 1323, which aids in measuring round-trip time for retransmitted segments. Later, the SACK-based loss recovery methods were formalized and extended in documents like RFC 6675, which made the original RFC 2018 algorithm obsolete by providing a more precise specification. It also relates to congestion control standards such as RFC 5681.

Implementation Considerations

While the concept is powerful, implementers must carefully handle several subtleties to avoid interoperability issues or performance degradation. A primary consideration is the limited space available for SACK blocks in the TCP header; typically, only three or four blocks can be included, requiring the receiver to strategically report the most informative blocks. Senders must correctly interpret SACK information to avoid retransmitting data that has already been SACKed, a scenario covered by the Duplicate-SACK (DSACK) extension defined in RFC 2883. Furthermore, in environments with misbehaving or malicious endpoints, excessive SACK options could be used in ACK storms or other attacks, necessitating defensive logic. Proper implementation is also crucial for compatibility with network devices performing TCP offload engine functions or middleboxes that may manipulate TCP traffic.

Category:Internet Standards Category:Request for Comments Category:Internet protocols Category:Computer networking