TCP Selective Acknowledgement Options
- Mathis, M., Mahdavi, J., Floyd, S., and Romanow, A.,
TCP Selective Acknowledgement Options.
RFC 2018,
April 1996.
Local copy
(text,
postscript).
Abstract.
-
An Extension to the Selective Acknowledgement (SACK) Option for
TCP.
Floyd, S.,
Mahdavi, J.,
Mathis, M., and
Podolsky, M..
RFC 2883, Proposed Standard,
July 2000.
Local copy:
(
text,
postscript).
-
What fraction of the bytes/packets/TCP-flows in the Internet are
SACK-capable?
Papers on SACK (Selective Acknowledgment) TCP
-
Fall, K., and Floyd, S.,
Simulation-based Comparisons of Tahoe, Reno, and SACK TCP
(pdf).
Computer Communication Review, V. 26 N. 3, July 1996, pp. 5-21.
Abstract.
The simulations in this paper can be run in NS with the command
"./test-all-tcpVariants" in tcl/test.
This is a revised version of
Comparisons of Tahoe, Reno, and Sack TCP.
Technical report, December 1995.
- Floyd, S.,
Issues of TCP with SACK.
Technical report, January 1996.
- Mathis, M., and Mahdavi, J.,
Forward Acknowledgement: Refining TCP Congestion Control,
SIGCOMM 96, August 1996.
-
Rohit Goyal et al.,
Selective Acknowledgements and UBR+ Drop Policies to Improve TCP/UBR
Performance over Terrestrial and Satellite Networks,
ATM Forum/97-0423, April 1997.
-
Floyd, S.,
Re: TCP and out-of-order delivery,
Message ID <199902030027.QAA06775@owl.ee.lbl.gov> to the
end-to-end-interest mailing list,
February 1999.
This note proposes a clarification of SACK that would allow the
TCP sender to correctly infer, after the fact, when an assumed packet
drop was simply a reordered packet.
Implementations
-
SACK is turned on by default in
Microsoft Windows 98.
This default
is controlled by the SackOpts registry entry in the location
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP.
-
SACK is turned on by default in Sun's Solaris 8 and Solaris 9.
-
The
TBIT Web Page also has information about SACK deployment.
-
Experimental TCP Selective Acknowledgment
Implementations.
This web page from the Pittsburgh Supercomputing Center (PSC)
has pointers to both experimental and commercial implementations of SACK TCP.
Last updated in 1999.
-
Enabling High Performance Data Transfers on
Hosts.
This web page from PSC
has discussions about extensions to TCP for high bandwidth.
Last updated in 1999.
Evaluations
-
M. Allman, C. Hayes, H. Kruse, S. Ostermann,
TCP Performance over Satellite Links,
Ohio University, 5th International Conference on Telecommunication Systems, 1997.
"When network congestion and higher bit error rates are present, the
addition of selective acknowledgements (SACK) can ... improve performance
in some cases."
-
Bruyeron, R., and Hemon, B.,
A report on experiments with TCP Sack.
TCP Selective Acknowledgement,
UCLA Internet Research Lab.
Also R. Bruyeron, B. Hemon, and L. Zhang,
Experimentations with TCP Selective Acknowledgment,
CCR Vol. 28 N. 2, April 1998.
This paper concludes that SACK improves TCP throughput significantly
in moderate congestion (with a packet loss rate between 2 and 4%),
and that the negative impact of SACK on competing non-SACK TCP
connections is small.
- N.K.G. Samaraweera and G. Fairhurst,
Reinforcement of TCP Error Recovery for Wireless Communication,
"The SACK option and New-Reno modifications ... were found to
significantly improve TCP performance especially over wireless links
(e.g., satellite links)."
Related Papers
-
Hari Balakrishnan, V. Padmanabhan, S. Seshan, M. Stemm, R. Katz,
TCP Behavior of a Busy Internet Server: Analysis and Improvements.
Technical Report UCB/CSD-97-966, University of California, Berkeley, CA, August 1997.
From traces of traffic to a busy web server, this paper concludes because
of small congestion windows, TCP Reno enhanced with SACK would only
avoid 4% of the retransmit timeouts.
Pointers to other information
Return to
[
Sally Floyd].
Last modified: September 2016