Adding Acknowledgement Congestion Control to TCP
RFC 5690
Document | Type |
RFC - Informational
(February 2010; No errata)
Was draft-floyd-tcpm-ackcc (gen)
|
|
---|---|---|---|
Authors | Jana Iyengar , David Ros , Andres Arcia , Sally Floyd | ||
Last updated | 2015-10-14 | ||
Stream | ISE | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | ISE state | (None) | |
Consensus Boilerplate | Unknown | ||
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5690 (Informational) | |
Telechat date | |||
Responsible AD | Lars Eggert | ||
Send notices to | rfc-editor@rfc-editor.org |
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 thatShow full document text