Adding Acknowledgement Congestion Control to TCP
RFC 5690
|
| Document |
Type |
|
RFC - Informational
(February 2010; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
ISE
|
|
Formats |
|
plain text
pdf
html
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
Show full document text