Other changes proposed to TCP

• Reordering:
  • Sumitha Bhandarkar, Nauzad Sadry, A. L. Narasimha Reddy and Nitin Vaidya, TCP-DCR: A Novel Protocol for Tolerating Wireless Channel Errors.
    "TCP-DCR delays responding to a packet loss indication by a small period of time (one RTT) to allow channel errors to be recovered by link level retransmission... An interested by-product of using TCP-DCR is the inherent robustness it provides against ... degradation due to packet re-ordering in the network."

  • Sumitha Bhandarkar and A. L. Narasimha Reddy, Improving the robustness of TCP to Non-Congestion Events, internet draft draft-ietf-tcpm-tcp-dcr-01.txt, August 2004.
    "This document proposes TCP-DCR, a simple modification to the TCP congestion control algorithm to make it more robust to non-congestion events."

  • Stephan Bohacek, Joao Hespanha, Junsoo Lee, Chansook Lim, Katia Obraczka. TCP-PR: TCP for Persistent Packet Reordering. IEEE 23rd Conf. on Distributed Computing Systems, May 2003.
    "The key feature of TCP-PR is that duplicate ACKs are not used as an indication of packet loss. Rather, TCP-PR relies exclusively on timeout."

  • Ethan Blanton, Mark Allman. On Making TCP More Robust to Packet Reordering.
    ACM Computer Communication Review, 32(1), January 2002.

  • 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.

• Below-Best-Effort TCP and Related Work:
  • Harp:
    Ravi Kokku, Aniruddha Bohra, Samrat Ganguly, and Arun Venkataramani, A Multipath Background Network Architecture, IEEE INFOCOM, May 2007.
    "Background transfers ... dominate Internet traffic today... We present the design and implementation of a network architecture, Harp, for a background-dominated Internet... Harp prioritizes foreground over background transfers... More importantly, Harp uses multipath routing to dissipate background transfers to less-utilized regions of the network... Harp is implemented as an overlay service."

  • 4CP, J. S. Liu, M. Vojnovic, and and D. Gunawardena, 2007.
    "4CP is a congestion control protocol designed to provide service differentiation of normal and low priority traffic (TCP and 4CP respectively)."

  • TCP Low Priority (TCP-LP), A. Kuzmanovic and E. W. Knightly, 2003.
    "The key mechanisms unique to TCP-LP congestion control are the use of one-way packet delays for congestion indications and a TCP-transparent congestion avoidance policy."

  • TCP Nice, Arun Venkataramani, Ravi Kokku, and Mike Dahlin, 2002.
    "makes good use of the spare bandwidth without affecting the traffic already present."

  • Roland Bless, Kathleen Nichols, Klaus Wehrle: "A Lower Effort Per-Domain Behavior for Differentiated Services, RFC 3662, December 2003.

• Corruption:
  • Michael Welzl, TCP Corruption Notification Options, internet draft draft-welzl-tcp-corruption-00.txt, June 2004.
    "This memo specifies options that enable TCP to detect corruption in the presence of link layers which hand over known-corrupt data to upper layers."

  • Wesley Eddy, Shawn Ostermann, Mark Allman, New Techniques for Making Transport Protocols Robust to Corruption-Based Loss, July 2003.
    "This paper explores a technique, called Cumulative Explicit Transport Error Notification (CETEN), that uses information provided by the network to ensure TCP's long-term average sending rate is dictated by only losses due to network congestion."

  • Explicit Transport Error Notification (ETEN).
    "If the TCP sender can distinguish packets that are lost due to congestion from ones that are lost due to errors, a better performance can be achieved."

  • Andrei Gurtov. TCP performance at the presence of congestion and corruption losses.
    Master's Thesis, December 2000.
    "Our largest group of tests is with random errors on a link... TCP with SACK performed significantly better than other modifications under all conditions... The increased initial window gives slightly better throughput... We found that RED worsens the performance when only a single TCP connection is present... For two concurrent TCP connections, RED improves the throughput and the fairness ..., but only for large buffer sizes... We have collected some empirical evidence suggesting that the more careful version of the "bug fix" for preventing multiple fast retransmits should be implemented in all TCPs."

  • Hari Balakrishnan and Randy H. Katz, Explicit Loss Notification and Wireless Web Performance, IEEE Globecom Internet Mini-Conference, Nov. 1998.
    This paper proposes Explicit Loss Notification to improve performance when a mobile host is the TCP sender.

  • Inferring congestion vs. corruption at the transport level. There are also papers that investigate algorithms for the transport end-nodes to infer that certain drops are from corruption rather than congestion, without explicit feedback from routers. My own view would be that the burden is on such approaches to show that they are not ignoring legitimate congestion indications from the network.
    • S.Biaz and N. Vaidya. Discriminating Congestion Losses from Wireless Losses Using Interarrival Times at the Receiver. IEEE Symposium on Application-Specific Systems and Software Engineering and Technology, Mar 1999.
      Presents "TCP-Aware" that aims to distinguish corruption losses from congestion losses based on packet inter-arrival times at receiver. The best accuracy rates of the algorithm can be achieved when the wireless link has the lowest bandwidth on the communication path.

• Link Outages, and Intermittently-Connected Paths:
  • L. Eggert, S. Schuetz, and S. Schmid, TCP Extensions for Immediate Retransmissions, internet draft draft-eggert-tcpm-tcp-retransmit-now-00, July 2004.
    "This document describes a modification to TCP's standard retransmission scheme that improves performance across intermittently connected paths... This extension causes additional, speculative retransmission attempts upon receiving external triggers."

  • James Scott, Glenford Mapp, Link Layer Based TCP Optimisation for Disconnecting Networks, CCR, V.33 N.5, Octover 2003.
    "A smart link layer employing repetition of selected packets at reconnection time is shown to improve TCP's utilization of a disconnecting network."

• Pacing, Rate-Halving, and other Mechanisms for Reducing Bursts:
  • M. Allman and E. Blanton, Notes on Burst Mitigation for Transport Protocols, ACM Computer Communication Review, 35(2), April 2005
    "This note methodically sketches the behavior of the mitigations and presents the tradeoffs of various schemes."

  • A. Aggarwal, S. Savage, and T. Anderson, Understanding the Performance of TCP Pacing, Proceedings of the 2000 IEEE Infocom Conference, Tel-Aviv, Israel, March, 2000.
    "Pacing offers better fairness, throughput, and lower drop rates in some situations. However, ... pacing often has significantly worse throughput than regular TCP because it is susceptible to synchronized losses and it delays congestion signals."

  • J. Kulik, R. Coulter, D. Rockwell, and C. Partridge, A Simulation Study of Paced TCP, BBN Technical Memorandum No. 1218, 1999.
    "We have provided simulation data showing that pacing can significantly improve the performance of TCP." The simulations use Drop-Tail queue management and small-scale statistical multiplexing.

  • Mahdavi, J., The Rate Halving Algorithm, 1999.
    The Rate-Halving algorithm adjusts the congestion window during Fast Recovery by spacing the transmissions over the entire recovery period.

• Responding to Congestion:
  • Ethan Blanton, Mark Allman, Kevin Fall, and Lili Wang, A Conservative SACK-based Loss Recovery Algorithm for TCP, RFC 3517, 2003.

  • S. Floyd, T. Henderson, The NewReno Modification to TCP's Fast Recovery Algorithm, RFC 2582, Experimental, April 1999. Local copies: text, postscript.
    This RFC describes a specific algorithm for responding to partial acknowledgments, referred to as NewReno. This response to partial acknowledgments was first proposed by Janey Hoe in [Hoe95].

  • N. Parvez, A. Mahanti, and C. Williamson, TCP NewReno: Slow-but-Steady or Impatient?, IEEE ICC, June 2006.
    "In this paper, we compare the throughputs of two different TCP NewReno variants, namely Slow-but-Steady and Impatient.... Our results show that the Impatient variant is superior only under very extreme network conditions (i.e., low loss event rates, but many packet drops per loss event). The Slow-but-Steady variant is superior to Impatient, or comparable to Impatient, in all other operating regimes, although RED queues diminish the performance differences observed."

  • Hari Balakrishnan, Venkata Padmanabhan, and Randy H. Katz, The Effects of Asymmetry on TCP Performance ( postscript, gzipped postscript), Third ACM/IEEE Mobicom Conference, Budapest, Hungary, Sep 1997.
    This paper proposes techniques for decreasing the frequency of ACKs on the constrained reverse channel ("ACK congestion control" and "ACK filtering"), techniques to reduce source burstiness when ACKs are infrequent ("sender adaptation via traffic shaping" and "ACK reconstruction"), and algorithms for scheduling data and ACKs at the reverse bottleneck router.

• Delay-Based Congestion Control:
  • Ravi S. Prasad, Manish Jain, Constantinos Dovrolis, On the Effectiveness of Delay-Based Congestion Avoidance, PFLDnet 2004.
    "The debate between Loss-based Congestion Avoidance (LCA) and Delay-based Congestion Avoidance (DCA) is almost as old as TCP congestion control itself... Our objective in this short note is to suggest possible reasons for the weak correlations between delays and losses, and to identify conditions under which DCA schemes can fail to provide robust congestion control."

  • J. Martin and A. Nilsson and I. Rhee, Delay-Based Congestion Avoidance for TCP, IEEE/ACM Transactions on Networking, June 2003.
    Delay-based Congestion Avoidance algorithms (DCA) "will react unnecessarily to RTT variation that is not associated with packet loss. The result is degraded throughput as compared to a similar flow that does not support DCA."

• Responding to Initial Duplicate Acknowledgements:
  • M. Allman, H. Balakrishnan, and S. Floyd, Enhancing TCP's Loss Recovery Using Limited Transmit, RFC 3042, Proposed Standard, January 2001.
    "The Limited Transmit algorithm calls for sending a new data segment in response to each of the first two duplicate acknowledgments that arrive at the sender."
    TBIT tests show roughly 25% of the web servers tested in early 2004 use Limited Transmit.

• Slow-start, and Restart of Idle Connections:
  • Allman, M., Floyd, S., and Partridge, C.. Increasing TCP's Initial Window, RFC 3390, October 2002. "This document specifies an optional standard for TCP to increase the permitted initial window from one or two segment(s) to roughly 4K bytes."

  • M. Allman, TCP Congestion Control with Appropriate Byte Counting (ABC), RFC 3465, February 2003.
    "Rather than the traditional method of increasing the congestion window by a constant amount for each arriving acknowledgment, the document suggests basing the increase on the number of previously unacknowledged bytes each ACK covers."

  • Amit Jain and Sally Floyd, Quick-Start for TCP and IP, expired internet-draft draft-amit-quick-start-02.txt, October 2002.
    "This draft outlines an optional Quick-Start mechanism for transport protocols to determine an optional allowed initial congestion window or initial sending rate at the start of a data transfer."

  • Mark Allman, TCP Byte Counting Refinements, ACM Computer Communication Review, July 1999.
    This paper proposes a restricted byte-counting algorithm (instead of TCP's current ACK-counting algorithm) for use with TCP's window increase mechanism.

  • Mark Allman, On the Generation and Use of TCP Acknowledgments, ACM CCR, October 1998.
    This paper compares acking-every-packet and delayed-ack mechanisms with three alternate mechanisms: acking-every-packet only during slow-start; unlimited byte-counting; and limited byte-counting. With unlimited byte-counting, the sender increases its congestion window based on the number of bytes covered by each ack. With limited byte-counting, the increase of the congestion window for each ack is limited to two segments.

  • Handley, M., Padhye, J., and Floyd, S., TCP Congestion Window Validation. RFC 2861, Experimental, June 2000. Or the technical report: UMass CMPSCI Technical Report 99-77, ( gzipped postscript), September 1999. Local copy: (postscript).
    This paper proposes mechanisms for decaying TCP's congestion window after periods when the sender is idle or application-limited.

  • Venkata Padmanabhan, TCP Fast Start: A Technique For Speeding Up Web Transfers, Global Internet '98 Conference, November 1998.
    This paper proposes that the sender caches network parameters, and uses higher drop priority for packets sent during Fast Start.

  • Mohit Aron and Peter Druschel, TCP: Improving Start-up Dynamics by Adaptive Timers and Congestion Control, TR98-318, Rice University, 1998.
    This paper proposes the use of packet pacing in the initial slow-start, and proposes a method for conservatively estimating the initial ssthresh. This paper also proposes decoupling the clock granularity used for measuring the roundtrip time from that used for scheduling events, allowing for shorter retransmission timeouts.

  • Vikram Visweswaraiah and John Heidemann, Improving Restart of Idle TCP Connections, Technical Report 97-661, University of Southern California, November, 1997.
    This paper proposes pacing packets during a restart of an idle TCP connection until the "ACK clock" can be restarted.

  • J. C. Hoe, Improving the Start-up Behavior of a Congestion Control Scheme for TCP , SIGCOMM 96, 1996.

• Retransmit Timeouts:
  • R. Ludwig, M. Meyer, RFC 3522: The Eifel Detection Algorithm for TCP, RFC 3522, April 2003.
    "The Eifel detection algorithm allows a TCP sender to detect a posteriori whether it has entered loss recovery unnecessarily." The Eifel detection algorithm requires timestamps.

  • P. Sarolahti, M. Kojo, F-RTO: An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and SCTP, internet draft draft-ietf-tcpm-frto-01.txt, July 2004.
    "This document describes the F-RTO detection algorithm for detecting spurious TCP retransmission timeouts." The F-RTO algorithm does not require timestamps.

  • Reiner Ludwig, Andrei Gurtov, The Eifel Response Algorithm for TCP, internet draft draft-ietf-tsvwg-tcp-eifel-response-05.txt, March 2004.
    "Based on an appropriate detection algorithm, the Eifel response algorithm provides a way for a TCP sender to respond to a detected spurious timeout."

  • Reiner Ludwig, Keith Sklower, The Eifel Retransmission Timer, CCR, July 2000.
    This paper proposes a new TCP retransmission timer mechanism, the Eifel retransmission timer.

  • Reiner Ludwig and Randy Katz, The Eifel Algorithm: Making TCP Robust Against Spurious Retransmissions, CCR, January 2000.
    This paper proposes mechanisms to eliminate the retransmission ambiguity from TCP, in part to prevent the unnecessary retransmissions that can result from a spurious retransmit timeout. Eliminating the retransmission ambiguity requires using either timestamps or new flags in the TCP header to distinguish between original and retransmitted data packets.

• TCP Over Wireless:
  • F. Anjum and L. Tassiulas, L., Comparative Study of Various TCP Versions over a Wireless Link with Correlated Losses, IEEE/ACM Transactions on Networking, Volume 11, Issue 3, June 2003
    "The performance of NewReno is worse than the performance of Tahoe in many situations." "The performance of Sack is always seen to be the best and the most robust, thereby arguing for the implementation of TCP-Sack over the wireless channel."

  • Pasi Sarolahti. Performance Analysis of TCP Enhancements for Congested Reliable Wireless Links..
    Master's Thesis, February 2001.
    This paper explores TCP over slow wireless links, and considers the effects of RED at the last-hop router. The paper also proposes using the advertised window to limit the number of outstanding packets and to share the window space among parallel connections.

  • Panu Kuhlber. Effect of Delays and Packet Drops on TCP-based Wireless Data Communication..
    Master's Thesis, February 2001.
    This paper explores TCP over slow wireless links, and considers the effects of Sack TCP, larger initial windows, and limitations on the receiver's advertised window.

  • Thomas Henderson and Randy Katz, Transport Protocols for Internet-Compatible Satellite Networks, IEEE Journal on Selected Areas in Communications, 1999.
    This paper compares the performance of various TCP implementations in a satellite environment, and discusses the use of a satellite gateway, proxy, or web cache to "split" transport connections in a manner transparent to users. The paper proposes a new transport protocol, Satellite Transport Protocol (STP), optimized for the asymmetric bandwidth and high latency of satellite environments.

• Other:
  • W. Noureddine and F. Tobagi, The Transmission Control Protocol, an introduction to TCP and a research survey, Technical Report, July 2002.
    "In this document, we describe the various mechanisms for reliable data delivery and congestion control implemented in TCP, discuss their evolution, and present a survey of the main TCP-related research areas."

  • M. Allman and A. Falk, On the Effective Evaluation of TCP, ACM Computer Communications Review, October 1999.
    This paper discusses issues in the evaluation of TCP performance.

  • Stefan Savage, Neal Cardwell, David Wetherall, and Tom Anderson, TCP Congestion Control with a Misbehaving Receiver, ACM Computer Communications Review, October 1999.

  • Reuven Cohen and Srinivas Ramanathan, TCP for High Performance in Hybrid Fiber Coaxial Broad-Band Access Networks, IEEE/ACM Transactions on Networking, Vol. 6, No. 1, February 1998.
    This paper proposes proper sizing of TCP socket buffers, an initial window of two packets (as opposed to one packet), smaller MSS values to counterack problems with delayed ACKs and ACK losses, a finer granularity for TCP timers, and Fast Retransmit triggered by a single dup ACK.

  • T. Faber, J. Touch and W. Yue, Avoiding the TCP TIME_WAIT state at Busy Servers, Working Draft, September 1997.
    This internet draft describes two methods for avoiding the accumulation of TCP TIME_WAIT states at a network server, including a TCP modification that causes clients rather than servers to enter TIME_WAIT state.

  • J. Touch, TCP Control Block Interdependence, RFC 2140, April 1997.
    This informational RFC proposes interdependent TCP control blocks for sharing TCP state among concurrent connections or across similar connection instances.

The Commercial World: Selected Pointers

• TCP Rate Control, Packeteer. This applies rate-based flow control policies to both individual traffic flows and classes of flows.

TCP and DiffServ

Other pointers

• TCP/IP RESEARCH PAPERS. Pointers to a collection of papers on TCP, up to 1998.

• The TCP page from DMOZ, the Open Directory Project.

• IETF's TCP Over Satellite (tcpsat) Working Group.

• IETF's Performance Implications of Link Characteristics (pilc) Working Group.

• Research - TCP/IP over something - Air Links - Wireless Links. PAN Jianping's annotated pointers.

• TCPng BOF (postscript of viewgraphs, minutes), San Jose IETF, December 1994.

• Publications from U.C. Berkeley's Daedalus Project. This includes pointers to papers by Hari Balakrishnan, Tom Henderson, Randy Katz, Venkat Padmanabhan, and others about TCP and other issues.

• LSAM (Large-Scale Active Middleware) Publications. This includes pointers to papers by John Heidemann, Joe Touch, and others about TCP and web performance.

Return to [Sally Floyd].
Last modified: January 2008.