Adding Acknowledgement Congestion Control to TCP
RFC 5690

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 06

Independent Submission                                          S. Floyd
Request for Comments: 5690                                          ICIR
Category: Informational                                         A. Arcia
ISSN: 2070-1721                                                   D. Ros
                                                        TELECOM Bretagne
                                                              J. Iyengar
                                             Franklin & Marshall College
                                                           February 2010

            Adding Acknowledgement Congestion Control to TCP

Abstract

   This document describes a possible congestion control mechanism for
   acknowledgement (ACKs) traffic in TCP.  The document specifies an
   end-to-end acknowledgement congestion control mechanism for TCP that
   uses participation from both TCP hosts: the TCP data sender and the
   TCP data receiver.  The TCP data sender detects lost or Explicit
   Congestion Notification (ECN)-marked ACK packets, and tells the TCP
   data receiver the ACK Ratio R to use to respond to the congestion on
   the reverse path from the data receiver to the data sender.  The TCP
   data receiver sends roughly one ACK packet for every R data packets
   received.  This mechanism is based on the acknowledgement congestion
   control in the Datagram Congestion Control Protocol's (DCCP's)
   Congestion Control Identifier (CCID) 2.  This acknowledgement
   congestion control mechanism is being specified for further
   evaluation by the network community.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This is a contribution to the RFC Series, independently of any other
   RFC stream.  The RFC Editor has chosen to publish this document at
   its discretion and makes no statement about its value for
   implementation or deployment.  Documents approved for publication by
   the RFC Editor are not a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc5690.

Floyd, et al.                 Informational                     [Page 1]
RFC 5690              TCPM - ACK Congestion Control        February 2010

IESG Note

   The content of this RFC was at one time considered by the IETF, and
   therefore it may resemble a current IETF work in progress or a
   published IETF work.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Table of Contents

   1. Introduction ....................................................3
   2. Conventions and Terminology .....................................4
   3. Overview ........................................................4
   4. Acknowledgement Congestion Control ..............................6
      4.1. The ACK Congestion Control Permitted Option ................6
      4.2. The TCP ACK Ratio Option ...................................7
      4.3. The Receiver: Implementing the ACK Ratio ...................7
      4.4. The Sender: Determining Lost or Marked ACK Packets .........8
           4.4.1. The Sender: Detecting Lost ACK Packets
                  after a Congestion Event ...........................10
      4.5. The Sender: Adjusting the ACK Ratio .......................10
           4.5.1. Possible Addition: Decreasing the ACK Ratio
                  after a Congestion Window Decrease .................12
      4.6. The Receiver: Sending ACKs for Out-of-Order Data
           Segments ..................................................12
      4.7. The Sender: Response to ACK Packets .......................13
      4.8. Possible Addition: Receiver Bounds on the ACK Ratio .......15
   5. Possible Complications .........................................15
      5.1. Possible Complication: Delayed Acknowledgements ...........15
      5.2. Possible Complication: Duplicate Acknowledgements .........15
      5.3. Possible Complication: Two-Way Traffic ....................16
      5.4. Possible Complication: Reordering of ACK Packets ..........16
      5.5. Possible Complication: Abrupt Changes in the ACK Path .....17
      5.6. Possible Complication: Corruption .........................17
      5.7. Possible Complication: ACKs That Don't Contribute
           to Congestion .............................................17
      5.8. Possible Complication: TCP Implementations that