(E.5) A TCP MUST return to step (E.2) to ensure that as many bytes
as are appropriate are transmitted. This provides robustness
to ACK loss that can be (largely) compensated for using SACK
information.
(E.6) DupThresh MUST be reset via:
DupThresh = max (LT_F * (FlightSize / SMSS),3)
where FlightSize is the total number of bytes that have not
been cumulatively acknowledged (which is different from
"pipe").
3.4. Entering Loss Recovery
When a segment is deemed lost via the algorithms in [RFC3517],
Extended Limited Transmit MUST be terminated, leaving the algorithms
in [RFC3517] to govern TCP’s behavior. One slight change to
[RFC3517] MUST be made, however. In Section 5, step (2) of [RFC3517]
MUST be changed to:
(2) ssthresh = cwnd = (FlightSizePrev / 2)
This ensures that the congestion control modifications are made with
respect to the amount of data in the network before FlightSize was
increased by Extended Limited Transmit.
Note: Once the algorithm in [RFC3517] takes over from Extended
Limited Transmit, the DupThresh value MUST be held constant until the
loss recovery phase is terminated.
4. Advantages
The major advantages of TCP-NCR are twofold. As discussed in Section
1, TCP-NCR will open up the design space for network applications and
components that are currently constrained by TCP’s lack of robustness
to packet reordering. The second advantage is in terms of an
increase in TCP performance.
[BR04] presents ns-2 [NS-2] simulations of a pre-cursor to the TCP-
NCR algorithm specified in this document, called TCP-DCR (Delayed
Congestion Response). The paper shows that TCP-DCR aids performance
in comparison to unmodified TCP in the presence of packet reordering.
In addition, the extended version of [BR04] presents results based on
emulations involving Linux (kernel 2.4.24). These results show that
the performance of TCP-DCR is similar to Linux’s native
implementation that seeks to "undo" wrong decisions according to
duplicate-SACK (DSACK) [RFC2883] feedback (similar to the schemes
outlined in [ZKFP03]), when packets are reordered by less than one
RTT. The advantage of using TCP-DCR over the DSACK-based scheme is
that the DSACK-based scheme tries to estimate the exact amount of
reordering in the network using fairly complex algorithms, whereas
TCP-DCR achieves similar results with less complicated modifications.
In addition, [BR04,BSRV04] illustrate the ability of TCP-DCR to allow
for the improvement of other parts of the system. For example, these
papers show that increasing TCP’s robustness to packet reordering
allows a novel wireless ARQ mechanism to be added at the link-layer.
The added robustness of the link-layer to channel errors, in turn,
increases TCP performance by not requiring TCP to retransmit packets
that were dropped due to corruption (and thus also prevents TCP from
needlessly reducing the sending rate when retransmitting these
segments).
5. Disadvantages
Although all the changes outlined above are implemented in the
sender, the receiver also potentially has a part to play. In
particular, TCP-NCR increases the receiver’s buffering requirement by
up to an extra cwnd -- in the case of the TCP sender using Aggressive
Limited Transmit and actual loss occurring in the network.
Therefore, to maximize the benefits from TCP-NCR, receivers should
advertise a large window to absorb the extra out-of-order traffic.
In the case that the additional buffer requirements are not met, the
use of the above algorithm takes into account the reduced advertised
window -- with a corresponding loss in robustness to packet
reordering.
In addition, using TCP-NCR could delay the delivery of data to the
application by up to one RTT because the fast retransmission point is
delayed by roughly one RTT in TCP-NCR. Applications that are
sensitive to such delays should turn off the TCP-NCR option. For
instance, a socket option could be introduced to allow applications
to control whether NCR would be used for a particular connection.
Finally, the use of TCP-NCR makes the recovery from congestion events
sluggish in comparison to the standard reaction in [RFC2581]. [BR04,
BSRV04] show (via simulation) that the delay in congestion response
has minimal impact on the connection itself and the traffic sharing a
bottleneck. [BBFS01] also indicates (again, via simulation) that
"slowly responsive" congestion control may be safe for deployment in
the Internet. These studies suggest that schemes that slightly delay
congestion control decisions may be reasonable; however, further
experimentation on the Internet is required to verify these results.
6. Related Work
Over the past few years, several solutions have been proposed to
improve the performance of TCP in the face of segment reordering.
These schemes generally fall into one of two categories (with some
overlap): mechanisms that try to prevent spurious retransmits from
happening and mechanisms that try to detect spurious retransmits and
"undo" the needless congestion control state changes that have been
taken.
[BA02,ZKFP03] attempt to prevent segment reordering from triggering
spurious retransmits by using various algorithms to approximate the
duplicate ACK threshold required to disambiguate loss and reordering
over a given network path at a given time. TCP-NCR similarly tries
to prevent spurious retransmits. However, TCP-NCR takes a simplified
approach compared to those in [BA02, ZKFP03], in that TCP-NCR simply
delays retransmission by an amount based on the current cwnd (in
comparison to standard TCP), while the other schemes use relatively
complex algorithms in an attempt to derive a more precise value for
DupThresh that depends on the current patterns of packet reordering.
While TCP-NCR offers simplicity, the other schemes may offer more
precision such that applications would not be forced to wait as long
for their retransmissions. Future work could be undertaken to
achieve robustness without needless delay.
On the other hand, several schemes have been developed to detect and
mitigate needless retransmissions after the fact. [RFC3522, RFC3708,
BA02, RFC4015, RFC4138] present algorithms to detect spurious
retransmits and mitigate the changes these events made to the
congestion control state. TCP-NCR could be used in conjunction with
these algorithms, with TCP-NCR attempting to prevent spurious
retransmits and some other scheme kicking in if the prevention
failed. In addition, note that TCP-NCR is concentrated on preventing
spurious fast retransmits; some of the above algorithms also attempt
to detect and mitigate spurious timeout-based retransmits.
7. Security Considerations
General attacks against the congestion control of TCP are described
in [RFC2581]. SACK-based loss recovery for TCP [RFC3517] mitigates
some of the duplicate ACK attacks against TCP’s congestion control.
This document builds upon that work, and the Extended Limited
Transmit algorithms specified in this document have been designed to
thwart the ACK division problems that are described in [RFC3465].
8. Acknowledgments
Feedback from Lars Eggert, Ted Faber, Wesley Eddy, Gorry Fairhurst,
Sally Floyd, Sara Landstrom, Nauzad Sadry, Pasi Sarolahti, Joe Touch,
Nitin Vaidya, and the TCPM working group have contributed
significantly to this document. Our thanks to all!
9. References
9.1. Normative References
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgement Options", RFC 2018, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing
TCP’s Loss Recovery Using Limited Transmit", RFC 3042,
January 2001.
[RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A
Conservative Selective Acknowledgment (SACK)-based Loss
Recovery Algorithm for TCP", RFC 3517, April 2003.
9.2. Informative References
[BA02] E. Blanton and M. Allman, "On Making TCP More Robust to
Packet Reordering," ACM Computer Communication Review,
January 2002.
[BBFS01] D. Bansal, H. Balakrishnan, S. Floyd and S. Shenker,
"Dynamic Behavior of Slowly Responsive Congestion Control
Algorithms", Proceedings of ACM SIGCOMM, Sep. 2001.
[BPS99] J. Bennett, C. Partridge, and N. Shectman, "Packet
reordering is not pathological network behavior," IEEE/ACM
Transactions on Networking, December 1999.
[BR04] Sumitha Bhandarkar and A. L. Narasimha Reddy, "TCP-DCR:
Making TCP Robust to Non-Congestion Events", In the
Proceedings of Networking 2004 conference, May 2004.
Extended version available as tech report TAMU-ECE-2003-04.
[BSRV04] Sumitha Bhandarkar, Nauzad Sadry, A. L. Narasimha Reddy and
Nitin Vaidya, "TCP-DCR: A Novel Protocol for Tolerating
Wireless Channel Errors", to appear in IEEE Transactions on
Mobile Computing.
[GPL04] Ladan Gharai, Colin Perkins and Tom Lehman, "Packet
Reordering, High Speed Networks and Transport Protocol
Performance", ICCCN 2004, October 2004.
[Jac88] V. Jacobson, "Congestion Avoidance and Control", Computer
Communication Review, vol. 18, no. 4, pp. 314-329, Aug.
1988. ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z.
[JIDKT03] S. Jaiswal, G. Iannaccone, C. Diot, J. Kurose, and D.
Towsley, "Measurement and Classification of Out-of-Sequence
Packets in a Tier-1 IP Backbone," Proceedings of IEEE
INFOCOM, 2003.
[KM02] I. Keslassy and N. McKeown, "Maintaining packet order in
twostage switches," Proceedings of the IEEE Infocom, June
2002
[MAF05] A. Medina, M. Allman, S. Floyd. Measuring the Evolution of
Transport Protocols in the Internet. ACM Computer
Communication Review, 35(2), April 2005.
[NS-2] ns-2 Network Simulator. http://www.isi.edu/nsnam/
[Pax97] V. Paxson, "End-to-End Internet Packet Dynamics,"
Proceedings of ACM SIGCOMM, September 1997.
[RFC896] Nagle, J., "Congestion control in IP/TCP internetworks",
RFC 896, January 1984.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An
Extension to the Selective Acknowledgement (SACK) Option
for TCP", RFC 2883, July 2000.
[RFC2960] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H.
Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, V.
Paxson. Stream Control Transmission Protocol. October
2000.
[RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte
Counting (ABC)", RFC 3465, February 2003.
[RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for
TCP", RFC 3522, April 2003.
[RFC3708] Blanton, E. and M. Allman, "Using TCP Duplicate Selective
Acknowledgement (DSACKs) and Stream Control Transmission
Protocol (SCTP) Duplicate Transmission Sequence Numbers
(TSNs) to Detect Spurious Retransmissions", RFC 3708,
February 2004.
[RFC4015] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm for
TCP", RFC 4015, February 2005.
[RFC4138] Sarolahti, P. and M. Kojo, "Forward RTO-Recovery (F-RTO):
An Algorithm for Detecting Spurious Retransmission Timeouts
with TCP and the Stream Control Transmission Protocol
(SCTP)", RFC 4138, August 2005.
[ZKFP03] M. Zhang, B. Karp, S. Floyd, L. Peterson, "RR-TCP: A
Reordering-Robust TCP with DSACK", in Proceedings of the
Eleventh IEEE International Conference on Networking
Protocols (ICNP 2003), Atlanta, GA, November, 2003.
Authors’ Addresses
Sumitha Bhandarkar
Dept. of Elec. Engg.
214 ZACH
College Station, TX 77843-3128
Phone: (512) 468-8078
EMail: sumitha@tamu.edu
URL: http://students.cs.tamu.edu/sumitha/
A. L. Narasimha Reddy
Professor
Dept. of Elec. Engg.
315C WERC
College Station, TX 77843-3128
Phone: (979) 845-7598
EMail: reddy@ee.tamu.edu
URL: http://ee.tamu.edu/~reddy/
Mark Allman
ICSI Center for Internet Research
1947 Center Street, Suite 600
Berkeley, CA 94704-1198
Phone: (440) 235-1792
EMail: mallman@icir.org
URL: http://www.icir.org/mallman/
Ethan Blanton
Purdue University Computer Science
305 North University Street
West Lafayette, IN 47907
EMail: eblanton@cs.purdue.edu
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).