idnits 2.17.1 draft-floyd-tcpm-ackcc-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 208: '...don't follow the MUST of sending an AC...' RFC 2119 keyword, line 245: '... MAY increase cwnd by more than 2 ...' RFC 2119 keyword, line 477: '... [RFC2581] recommends that the receiver SHOULD acknowledge out-of-...' RFC 2119 keyword, line 689: '... "a TCP receiver SHOULD send an immedi...' RFC 2119 keyword, line 824: '... SHOULD send an immediate duplicate ...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1091 has weird spacing: '...on with a dat...' -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (4 July 2009) is 5409 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4340' is mentioned on line 1462, but not defined == Missing Reference: 'RFC4341' is mentioned on line 1465, but not defined == Missing Reference: 'RFC2581' is mentioned on line 1453, but not defined ** Obsolete undefined reference: RFC 2581 (Obsoleted by RFC 5681) == Missing Reference: 'RFC3465' is mentioned on line 1459, but not defined == Missing Reference: 'RFC4727' is mentioned on line 1469, but not defined == Missing Reference: 'RFC3692' is mentioned on line 1456, but not defined == Missing Reference: 'RFC2119' is mentioned on line 1450, but not defined Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Floyd 3 INTERNET-DRAFT ICIR 4 Intended status: Informational A. Arcia 5 Expires: 4 January 2010 D. Ros 6 TELECOM Bretagne 7 J. Iyengar 8 Franklin & Marshall College 9 4 July 2009 11 Adding Acknowledgement Congestion Control to TCP 12 draft-floyd-tcpm-ackcc-06.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 This document may contain material from IETF Documents or IETF 20 Contributions published or made publicly available before November 21 10, 2008. The person(s) controlling the copyright in some of this 22 material may not have granted the IETF Trust the right to allow 23 modifications of such material outside the IETF Standards Process. 24 Without obtaining an adequate license from the person(s) controlling 25 the copyright in such materials, this document may not be modified 26 outside the IETF Standards Process, and derivative works of it may 27 not be created outside the IETF Standards Process, except to format 28 it for publication as an RFC or to translate it into languages other 29 than English. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on 4 January 2010. 49 Copyright Notice 51 Copyright (c) 2009 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents in effect on the date of 56 publication of this document (http://trustee.ietf.org/license-info). 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. 60 Abstract 62 This document describes a possible congestion control mechanism for 63 acknowledgement traffic (ACKs) in TCP. The document specifies an 64 end-to-end acknowledgement congestion control mechanism for TCP that 65 uses participation from both TCP hosts, the TCP data sender and the 66 TCP data receiver. The TCP data sender detects lost or ECN-marked 67 ACK packets, and tells the TCP data receiver the ACK Ratio R to use 68 to respond to the congestion on the reverse path from the data 69 receiver to the data sender. The TCP data receiver sends roughly one 70 ACK packet for every R data packets received. This mechanism is 71 based on the acknowledgement congestion control in DCCP's CCID 2. 72 This acknowledgement congestion control mechanism is being specified 73 for further evaluation by the network community. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 2. Conventions and Terminology. . . . . . . . . . . . . . . . . . 8 79 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 4. Acknowledgement Congestion Control . . . . . . . . . . . . . . 10 81 4.1. The ACK Congestion Control Permitted Option . . . . . . . 10 82 4.2. The TCP ACK Ratio Option. . . . . . . . . . . . . . . . . 11 83 4.3. The Receiver: Implementing the ACK Ratio. . . . . . . . . 11 84 4.4. The Sender: Determining Lost or Marked ACK Pack- 85 ets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 4.4.1. The Sender: Detecting Lost ACK Packets 87 After a Congestion Event. . . . . . . . . . . . . . . . . . 14 88 4.5. The Sender: Adjusting the ACK Ratio . . . . . . . . . . . 14 89 4.5.1. Possible Addition: Decreasing the ACK 90 Ratio after a Congestion Window Decrease. . . . . . . . . . 15 91 4.6. The Receiver: Sending ACKs for Out-of-Order Data 92 Segments . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 93 4.7. The Sender: Response to ACK Packets . . . . . . . . . . . 17 94 4.8. Possible Addition: Receiver Bounds on the ACK 95 Ratio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 96 5. Possible Complications . . . . . . . . . . . . . . . . . . . . 19 97 5.1. Possible Complication: Delayed 98 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 99 5.2. Possible Complication: Duplicate Acknowledge- 100 ments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 101 5.3. Possible Complication: Two-Way Traffic. . . . . . . . . . 19 102 5.4. Possible Complication: Reordering of ACK Pack- 103 ets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 104 5.5. Possible Complication: Abrupt Changes in the ACK 105 Path.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 106 5.6. Possible Complication: Corruption.. . . . . . . . . . . . 20 107 5.7. Possible Complication: ACKs That Don't Contrib- 108 ute to Congestion. . . . . . . . . . . . . . . . . . . . . . . 21 109 5.8. Possible Complication: TCP Implementations that 110 Skip ACK Packets . . . . . . . . . . . . . . . . . . . . . . . 24 111 5.9. Possible Complication: Router or Middlebox-based 112 ACK Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 24 113 5.10. Possible Complication: Data-Limited Senders. . . . . . . 25 114 5.11. Other Issues . . . . . . . . . . . . . . . . . . . . . . 25 115 6. Evaluating ACK Congestion Control. . . . . . . . . . . . . . . 25 116 6.1. Contention in Wireless Links or in non-switched 117 Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 118 6.2. Keep-alive and Other Special ACK Packets. . . . . . . . . 26 119 7. Measurements of ACK Traffic and Congestion . . . . . . . . . . 26 120 8. Acknowledgement Congestion Control in DCCP's CCID 2. . . . . . 27 121 9. Security Considerations. . . . . . . . . . . . . . . . . . . . 27 122 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 123 11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 29 124 12. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 29 125 A. Appendix: Related Work . . . . . . . . . . . . . . . . . . . . 29 126 A.1. ECN-only Mechanisms . . . . . . . . . . . . . . . . . . . 30 127 A.2. Receiver-only Mechanisms. . . . . . . . . . . . . . . . . 30 128 A.3. Middlebox-based Mechanisms. . . . . . . . . . . . . . . . 31 129 B. Appendix: Design Considerations. . . . . . . . . . . . . . . . 31 130 B.1. The TCP ACK Ratio Option, or an AckNow bit in 131 data packets?. . . . . . . . . . . . . . . . . . . . . . . . . 31 132 Normative References (if standardized). . . . . . . . . . . . . . 32 133 Informative References. . . . . . . . . . . . . . . . . . . . . . 33 134 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . 36 135 TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION: 137 Changes from draft-floyd-tcpm-ackcc-05.txt: 139 * Added a paragraph about Experimental TCP Option numbers. 140 IESG Feedback from Lars Eggert. 142 * Added a subsection on "Possible Complication: Data-Limited 143 Senders". Feedback from Ilpo Jarvinen. 145 * Added a sentence clarifying the ACK Congestion Control 146 Permitted option. 148 * Added a subsection on "The Sender: Detecting Lost ACK 149 Packets After a Congestion Event" 151 Changes from draft-floyd-tcpm-ackcc-05.txt: 153 * Minor editing. 155 Changes from draft-floyd-tcpm-ackcc-04.txt: 157 * Changed desired status of document from Experimental to 158 Informational, with associated editing changes. 160 * Specified that ACK packets are only sent as ECN-Capable 161 if ECN-capability has been negotiated as specified in RFC 3168. 163 * Added a section on "Possible Addition: Decreasing the 164 ACK Ratio after a Congestion Window Decrease". 166 * Minor editing. Feedback from Alfred Hoenes. 168 Changes from draft-floyd-tcpm-ackcc-03.txt: 170 * General editing. Feedback from Alfred Hoenes. 172 * General editing. Feedback from Gorry Fairhurst. 174 * Added a subsection on "Contention in Wireless Links 175 or in non-switched Ethernet". 177 * Modified Section 4.4 to say that the sender doesn't try to 178 detect lost ACK packets during loss events even if 179 the ACK Ratio is two. 181 * Added a paragraph to Section 4.4 about "Detecting lost ACK 182 packets after changes in the ACK Ratio". 184 Changes from draft-floyd-tcpm-ackcc-02.txt: 186 * Cited RFC 3449 (PILC), RFC 3135 (PILC), and RFC 2760 (TCPSAT). 187 From December 2007 Working Group meeting. 189 * Added a note about the problem of effective ACK Congestion 190 Control for environments with systematic reordering in the 191 data path. 193 * General editing. Feedback from Alfred Hoenes. 195 * Added more about keep-alive packets and window update packets. 196 Feedback from Anantha Ramaiah. 198 * Clarified that SACK "SHOULD" be used. We don't know enough 199 to say "MUST". 201 Changes from draft-floyd-tcpm-ackcc-01.txt: 203 * Added a section on "Keep-alive Packets". Feedback from 204 Anantha Ramaiah. 206 * Added a section on "Possible Complication: TCP Implementations that 207 Skip ACK Packets". Motivated by reports at IETF that many 208 high-bandwidth TCPs don't follow the MUST of sending an ACK for 209 every other packet, if they don't have time. 211 * Added that receivers might have buffer limitations that require 212 that they ack at least every K packets, for some K. Feedback 213 from Sara Landstrom. 215 * Added to the discussion of "Possible Complication: Two-Way 216 Traffic". Feedback from Sara Landstrom. 218 * Added a section on "Possible Complication: Router or 219 Middlebox-based ACK Mechanisms". Feedback from Sara Landstrom. 221 * Added that SACK is required with ACK congestion control. 222 Feedback from Sara Landstrom. 224 * Added a discussion of "Reducing the TCP Acknowledgment Frequency" 225 to the related work section. 227 * Moved the Related Work section to the appendix. 228 Feedback from Alfred Hoenes. 230 * General editing from feedback from Alfred Hoenes. 232 * Added an appendix on "Design Considerations", with a subsection 233 on "The TCP ACK Ratio Option, or an AckNow bit in data packets?". 235 Changes from draft-floyd-tcpm-ackcc-00.txt: 237 * Added a discussion of environments where the reverse path 238 is congested, but the TCP ACK traffic does not significantly 239 contribute to that congestion. In this case, the goal is 240 to minimize the negative impact of AckCC on TCP performance. 241 Feedback from Armando Caro. 243 * In Section 5.7, added that when ABC is used with Aggregate 244 Congestion Control, and rate-based pacing is also used, the sender 245 MAY increase cwnd by more than 2 MSS. 246 Feedback from Armando Caro. 248 * Added a section about measurements of ACK traffic and congestion. 249 Feedback from Armando Caro. 251 * Added a section on the possibility of a TCP receiver-imposed 252 lower bound on the ACK Ratio. Suggested by Mark Allman. 254 * Added to the discussion of the minimum ACK sending rate. 255 Suggested by Mark Allman. 257 * Added a note that if the TCP receiver doesn't sent an ACK for 258 every duplicate data packet, the sender's Fast Recovery 259 procedure will have to be modified to take this into 260 account. Feedback from Mark Allman. 262 * Added a discussion of evaluating ACK Congestion Control. 263 From feedback from Mark Allman. 265 * Some general editing in response to feedback from Mark Allman. 267 END OF SECTION TO BE DELETED. 269 1. Introduction 271 This document describes a congestion control mechanism for 272 acknowledgements (ACKs) to TCP. This mechanism is based on the 273 acknowledgement congestion control in DCCP's CCID 2 [RFC4340], 274 [RFC4341], which is a successor to the TCP acknowledgement congestion 275 control mechanism proposed by Balakrishnan et at. in [BPK97]. 277 In this document we use the terminology of senders and receivers, 278 with the sender sending data traffic, and the receiver sending 279 acknowledgement traffic in response. In CCID 2's acknowledgement 280 congestion control, specified in Section 6.1 of [RFC4341], the 281 receiver uses an ACK Ratio R reported to it by the sender, sending 282 roughly one ACK packet for every R data packets received. The CCID 2 283 sender keeps the acknowledgement rate roughly TCP friendly by 284 monitoring the acknowledgement stream for lost and marked ACK packets 285 and modifying the ACK Ratio accordingly. For every RTT containing an 286 ACK congestion event (that is, a lost or marked ACK packet), the 287 sender halves the acknowledgement rate by doubling the ACK Ratio; for 288 every RTT containing no ACK congestion event, the sender additively 289 increases the acknowledgement rate through gradual decreases in the 290 ACK Ratio. 292 The goal of this document is to explore a similar congestion control 293 mechanism for acknowledgement traffic for TCP. The assumption is 294 that in some environments with congestion on the reverse path, 295 reducing the sending rate for ACK traffic traversing the congested 296 path can help to reduce the congestion itself. For those 297 environments where the reverse path is congested but where TCP ACK 298 traffic does not appreciably contribute to that aggregate congestion, 299 the goal is for TCP's ACK congestion control to have a minimal 300 negative effect on the performance of the TCP connection. 302 Adding acknowledgement congestion control as an option in TCP would 303 require the following: 305 * An agreement from the TCP hosts on the use of ACK congestion 306 control. For the mechanism specified in this document, the TCP hosts 307 would use a new TCP option, the ACK Congestion Control Permitted 308 Option. 310 * A mechanism for the TCP sender to detect lost and ECN-marked pure 311 acknowledgement packets. 313 * A mechanism for adjusting the ACK Ratio. The TCP sender would 314 adjust the ACK Ratio as specified in Section 6.1.2 of [RFC4341]. 316 * A method for the TCP sender to inform the TCP receiver of a new 317 value for the ACK Ratio. For the mechanism specified in this 318 document, the TCP sender would use a new TCP option, the ACK Ratio 319 Option. 321 2. Conventions and Terminology 323 MSS refers to the Maximum Segment Size. 325 3. Overview 327 This section gives an overview of acknowledgement congestion control 328 for TCP. 330 --------------------------------------------------------------- 331 TCP Node A Router TCP Node B 332 (data sender) (data receiver) 333 ---------- ------ ---------- 334 <--- SYN with AckCC Permitted. 335 SYN/ACK with AckCC Permitted ---> 336 . . . 337 Data packets ---> 338 <--- one ACK packet 339 for every two data packets 340 . . . 341 Sender detects a lost ACK packet. 342 Data packet with an ACK Ratio option of 4 ---> 343 <--- one ACK packet 344 for at least every four data packets 345 . . . 346 Sender detects a period with no lost ACK packets. 347 Data packet with an ACK Ratio option of 3 ---> 348 <--- one ACK packet 349 for at least every three data packets 350 --------------------------------------------------------------- 352 Figure 1: Acknowledgement Congestion Control, Node B as the 353 connection initiator, for a connection without ECN. 355 Figure 1 gives an example of Acknowledgement Congestion Control 356 (AckCC) with TCP Node B as the connection initiator. 358 During connection initiation, TCP host B sends an ACK Congestion 359 Control Permitted option on its SYN or SYN/ACK packet. This allows 360 TCP host A (now called the sender) to send instructions to TCP host B 361 (now called the receiver) about the ACK Ratio to use in responding to 362 data packets. 364 Also during connection initiation, TCP host A sends an ACK Congestion 365 Control Permitted option on its SYN or SYN/ACK packet. In 366 combination with TCP host B's sending of an ACK Congestion Control 367 Permitted option, and with the negotiation of ECN-Capability as 368 specified in RFC 3168, this would allow TCP host B to send its ACK 369 packets as ECN-Capable. 371 The TCP receiver starts with an ACK Ratio of two, generally sending 372 one ACK packet for every two data packets received. 374 The TCP sender detects a lost or ECN-marked ACK packet from the TCP 375 receiver, and sends an ACK Ratio option of four to the receiver. The 376 TCP receiver changes to an ACK Ratio of four, sending one ACK packet 377 for at most four data packets. The TCP sender uses Appropriate Byte 378 Counting and rate-based pacing in responding to these ACK packets. 380 The TCP sender detects a period with no lost ACK packets, and sends 381 an ACK Ratio option of three to the TCP receiver. The TCP receiver 382 changes back to an ACK Ratio of three, sending one ACK packet for at 383 most three data packets. 385 4. Acknowledgement Congestion Control 387 The goal of the mechanism proposed in this document is to control 388 pure ACK traffic on the path from the TCP data receiver to the TCP 389 data sender. Note that the approach outlined here is an end-to-end 390 one (as is the approach followed by DCCP's CCID 2 [RFC4341]), but it 391 may also take advantage of explicit congestion information from the 392 network conveyed by ECN [RFC3168], if available. The ECN 393 specification [RFC3168, section 6.1.4] prohibits a TCP receiver from 394 setting the ECT(0) or ECT(1) codepoints in IP packets carrying pure 395 ACKs, but *only* as long as the receiver does *not* implement any 396 form of ACK congestion control. Unlike some of the related work 397 cited in the appendix, in this document we are proposing an end-to- 398 end ACK congestion control mechanism that controls congestion on the 399 reverse path (the path followed by the ACK traffic) by detecting and 400 responding either marked or dropped ACK packets. 402 4.1. The ACK Congestion Control Permitted Option 404 The TCP end-points would negotiate the use of ACK Congestion Control 405 (ACKCC) with a TCP option, the ACK Congestion Control Permitted 406 Option. The option number would be allocated by IANA. 408 The ACK Congestion Control Permitted option can only be sent on 409 packets that have the SYN bit set. If TCP end-point A receives an 410 ACK Congestion Control Permitted option from TCP end-point B, then 411 the TCP end-points may use ACK Congestion Control on the pure 412 acknowledgements sent from B to A. This means that TCP end-point A 413 may send ACK Ratio values to TCP end-point B, for TCP end-point B to 414 use on pure acknowledgement packets. Equivalently, if TCP end-point 415 A *does not* receive an ACK Congestion Control Permitted option from 416 TCP end-point B, then TCP end-point A knows not to waste its time 417 detecting lost ACK packets and adjusting and sending the ACK Ratio 418 values. 420 If TCP end-point B receives an ACK Congestion Control Permitted 421 option from TCP end-point A, then the TCP end-points may use ACK 422 Congestion Control on the pure acknowledgements sent from A to B. 424 If TCP end-point B receives an ACK Congestion Control Permitted 425 option from TCP end-point A and also sent an ACK Congestion Control 426 Permitted option to TCP end-point A, and ECN-capability has been 427 negotiated, then TCP end-point B can send its pure ACK packets as 428 ECN-Capable. 430 TCP ACK Congestion Control Permitted Option: 432 Kind: TBD1 434 +-----------+-----------+ 435 | Kind=TBD1 | Length=2 | 436 +-----------+-----------+ 438 When ACK Congestion Control is used, the default initial ACK Ratio is 439 two, with the receiver acknowledging at least every other data 440 packet. 442 4.2. The TCP ACK Ratio Option 444 The sender uses a ACK Ratio TCP Option to communicate the ACK Ratio 445 value from the sender to the receiver. 447 TCP ACK Ratio Option: 449 Kind: TBD2 451 +-----------+-----------+-----------+ 452 | Kind=TBD2 | Length=3 | ACK Ratio | 453 +-----------+-----------+-----------+ 455 The ACK Ratio Option is only sent on data packets. Because TCP uses 456 reliable delivery for data packets, the TCP sender can tell if the 457 TCP receiver has received an ACK Ratio Option. 459 4.3. The Receiver: Implementing the ACK Ratio 461 With an ACK Ratio of R, the receiver should send one pure ACK for 462 every R newly received data packets unless the delayed ACK timer 463 expires first. A receiver could simply maintain a counter that 464 increments by one for each new data packet received, and send an ACK 465 packet when the counter reaches R. The receiver would reset the 466 counter to zero whenever a pure or piggybacked ACK is sent, 468 If the receiver has buffer limitations, the receiver might have to 469 acknowledge K packets, for some K less than the current ACK Ratio R. 470 In this case, the sender could observe from the acknowledgements that 471 the receiver is acknowledging less than R packets. 473 It is possible for there to be lost or marked ACK packets when there 474 haven't yet been any lost or marked data packets. Thus, the sender 475 could increase the ACK Ratio R even during the initial slow-start. 477 [RFC2581] recommends that the receiver SHOULD acknowledge out-of- 478 order data packets immediately, sending an immediate duplicate ACK 479 when it receives a data segment above a gap in the sequence space, 480 and sending an immediate ACK when it receives a data segment that 481 fills in all or part of a gap in the sequence space. 483 When ACK Congestion Control is being used and the ACK Ratio is at 484 most two, the TCP receiver acknowledges each out-of-order data packet 485 immediately. For an ACK Ratio greater than two, Section 4.6 486 specifies in detail the receiver's behavior for sending ACKs for out- 487 of-order data packets. 489 4.4. The Sender: Determining Lost or Marked ACK Packets 491 The TCP data sender uses its knowledge of the ACK Ratio in use by the 492 receiver to infer when an ACK packet has been lost. 494 Because the TCP sender knows the ACK Ratio R in use by the receiver, 495 the TCP sender knows that in the absence of dropped or reordered 496 acknowledgement packets, each new acknowledgement received will 497 acknowledge at most R additional data packets. Thus, if the sender 498 receives an acknowledgement acknowledging more than R data packets, 499 and does not receive a subsequent acknowledgement acknowledging a 500 strict subset (with a smaller cumulative acknowledgement, or with the 501 same cumulative acknowledgement but a strict subset of data 502 acknowledged in SACK blocks), then the sender can infer that an ACK 503 packet has been dropped. The use of SACK options in ACK packets 504 would help the sender in detecting lost ACK packets. 506 Similarly, the TCP sender knows that in the absence of dropped or 507 delayed data packets from the sender, and in the absence of delayed 508 acknowledgements due to a timer expiring at the receiver, each new 509 pure acknowledgement received will acknowledge at least R additional 510 data packets. In terms of ACK congestion control, the TCP sender 511 does not have to take any actions when it receives an acknowledgement 512 acknowledging less than R additional packets. 514 Out-of-order data packets: If the ACK Ratio is at most two, then the 515 TCP receiver sends a DupACK for every out-of-order data packet. In 516 this case, the TCP sender should be able to detect lost DupACK 517 packets by counting the number of DupACKs that arrive between the 518 beginning of the loss event and the arrival of the first full or 519 partial ACK, and comparing this number with the number of DupACKs 520 that should have arrived (based on the number of packets being ACKed 521 by the full or partial ACK). Simulations and/or experiments will be 522 needed to determine whether, in practice, it works for the TCP sender 523 to assess lost ACK packets during loss events, for an ACK Ratio of at 524 most two. 526 If the ACK Ratio is greater than two, the TCP receiver does not send 527 a DupACK for every out-of-order data packet, as specified in Section 528 4.6. For simplicity, the TCP sender does not attempt to detect lost 529 ACK packets during loss events involving forward-path data traffic. 530 That is, as soon as the sender infers a packet loss for a forward- 531 path data packet, it stops detection of ACK loss on the reverse path. 532 The sender waits until a new cumulative acknowledgement is received 533 that covers the retransmitted data, and then restarts detection of 534 ACK loss for reverse-path traffic. 536 Detecting lost ACK packets after changes in the ACK Ratio: In 537 detecting lost ACK packets, the sender relies on its knowledge of the 538 ACK Ratio used by the receiver. But when the sender makes a change 539 in the ACK Ratio, and then receives ACK packets, how does the sender 540 know whether the receiver was using the new or the old ACK Ratio when 541 it sent those ACK packets? As specified in the next section, the 542 sender can make only one of two possible changes to the ACK Ratio 543 within one round-trip time. The sender can decrease the ACK Ratio by 544 one, from R to R-1, or the sender can double the ACK Ratio, 545 increasing it from R to 2R. But, in detecting lost ACK packets after 546 an increase in the ACK Ratio, the sender needs to know whether the 547 receiver was using the old ACK Ratio R or the new ACK Ratio 2R. 549 The sender sends ACK Ratio Options only on data packets, and these 550 data packets are acknowledged by the receiver. One possibility would 551 be for the sender to save the sequence number of the last data packet 552 that contained an ACK Ratio Option, and to remember whether that ACK 553 Ratio Option was for an increase or a decrease in the ACK Ratio. 554 Then, if the sender receives an ACK packet acknowledging the saved 555 sequence number, then the sender knows that the receiver has begun 556 using the new ACK Ratio. 558 It *might* be sufficient for the sender just to save the information 559 of whether the last change in the ACK Ratio was an increase or a 560 decrease, without saving the sequence number associated with the last 561 ACK Ratio Option. In this way, if the sender recently increased the 562 ACK Ratio from R to 2R, the sender could be more cautious in 563 detecting lost ACK packets. Another possibility would be that after 564 sending an ACK Ratio Option, the sender waits until that data has 565 been ACKed, with the new ACK Ratio in use by the receiver, before 566 resuming the detection of lost ACK packets. However, we do not 567 explore either of these approaches in more detail in this document. 569 4.4.1. The Sender: Detecting Lost ACK Packets After a Congestion Event 571 After a sender's retransmit timeout or fast retransmit, the sender 572 might retransmit a number of data packets dropped from a single 573 window of data. In particular, during a loss recovery period (from 574 the sender's detection of the congestion event up until the sender 575 receives an acknowledgement of all data packets transmitted before 576 the loss recovery period began) retransmitted data packets can fill 577 holes in the receiver's sequence space. resulting in irregular jumps 578 in the cumulative acknowledgement field in ACK packets from the 579 receiver. These jumps in the cumulative acknowleldgement field make 580 it difficult for the sender to reliably detect lost ACK packets 581 during a loss recovery period. 583 Because of this uneven progress of the cumulative acknowledgement 584 field during a loss recovery period, the sender should not attempt to 585 detect lost ACK packets during a loss recovery period. As a 586 consequence, the sender will not increase the ACK Ratio in response 587 to ACK packets that are lost during a loss recovery period. 589 4.5. The Sender: Adjusting the ACK Ratio 591 The TCP sender will adjust the ACK Ratio as specified in Section 592 6.1.2 of [RFC4341], as follows. 594 The ACK Ratio always meets the following three constraints. 596 (1) The ACK Ratio is an integer. 598 (2) The minimum ACK sending rate: The ACK Ratio does not exceed 599 max(2, cwnd/(K*MSS)), rounded up, for K=2. As a result, the TCP 600 receiver generally sends at least two ACKs in response to a window of 601 at least four full-sized segments. 603 (3) If the congestion window is at least as large as four full-sized 604 segments, then the ACK Ratio is at least two. In other words, an ACK 605 Ratio of one is only allowed when the congestion window is at most 606 three full-sized segments. 608 The sender changes the ACK Ratio within those constraints as follows. 609 For each congestion window of data with lost or marked ACK packets, 610 the ACK Ratio R is doubled; and for each cwnd/(MSS*(R^2 - R)) 611 consecutive congestion windows of data with no lost or marked ACK 612 packets, the ACK Ratio is decreased by 1. (See Appendix A of RFC 613 4341 for the derivation. Note that Appendix A of RFC 4341 assumes a 614 congestion window W in packets, while we use cwnd in bytes.) As 615 stated in the previous section, when the ACK Ratio is greater than 616 two the sender does not attempt to detect lost ACK packets during 617 loss events for forward-path traffic. 619 For a constant congestion window, these modifications to the ACK 620 ratio give an ACK sending rate that is roughly TCP friendly. Of 621 course, cwnd usually varies over time; the dynamics will be rather 622 complex, but roughly TCP friendly. We recommend that the sender 623 determines when to decrease the ACK Ratio by one (i.e., by 624 calculating the number of in-order data packets to count) right after 625 an ACK loss event. 627 The frequency of ACK Ratio negotiations: The sender need not keep the 628 ACK Ratio completely up to date. For instance, it may rate-limit ACK 629 Ratio renegotiations to once every four or five round-trip times, or 630 to once every second or two. The sender should not attempt to change 631 the ACK Ratio more than once per round-trip time. In particular, 632 before sending a packet with a new value for the ACK Ratio, the 633 sender should verify that the receiver has acknowledged a data packet 634 containing an ACK Ratio Option for the old value of the ACK Ratio. 635 Additionally, the sender may enforce a minimum ACK Ratio of two, or 636 it may set the ACK Ratio to one for half-connections with persistent 637 congestion windows of 1 or 2 packets. 639 The minimum ACK sending rate: From rule (2) above, the TCP receiver 640 always sends at least K=2 ACKs for a window of data, even in the face 641 of very heavy congestion on the reverse path. We would note, 642 however, that if congestion is sufficiently heavy, all the ack 643 packets are dropped, and then the sender falls back on an 644 exponentially backed-off timeout. Thus, if congestion is sufficiently 645 heavy on the reverse path, then the sender reduces its sending rate 646 on the forward path, which reduces the rate on the reverse path as 647 well. One possibility would be to use a higher minimum ACK sending 648 rate, adding a constant upper bound on the ACK Ratio. That is, if 649 the ACK Ratio also had an upper bound of J, independent of cwnd, then 650 the receiver would always send at least one ACK for every J data 651 packets, regardless of the level of congestion on the reverse path. 653 4.5.1. Possible Addition: Decreasing the ACK Ratio after a Congestion 654 Window Decrease 656 After a lost or ECN-marked data packet, the data sender halves the 657 congestion window, thus halving the sending rate for data packets, 658 while making no change to the ACK Ratio R. As a result, after a 659 congestion event involving a data packet, the sending rate for ACK 660 packets on the return path is also halved. If the congestion event 661 was a lost or ECN-marked data packet, this was due to congestion on 662 the forward path, which may have been unrelated to conditions on the 663 reverse path. Thus, it has been suggested that the sender could 664 decrease the ACK Ratio R when it halves the congestion window; in 665 this case, the halving of the sending rate for data packets would not 666 be accompanied by a halving of the sending rate for ACK packets also. 668 However, there are a few cases where a congestion event involving 669 data packets could in fact have been caused by congestion on the 670 reverse path. As one example, the path could include a congested 671 multiaccess link where forward-path and reverse-path traffic can 672 interfere with each other. Thus, in this case it might be desirable 673 if a congestion event resulted in a reduction in the sending rate of 674 ACK packets as well as of data packets. 676 As a second example of a congestion event involving congestion of the 677 reverse path, a congestion event could be caused not by a dropped or 678 ECN-marked data packet, but by a window of dropped ACK packets, 679 resulting in a retransmit timeout at the data sender. After a 680 retransmit timeout, the TCP sender will slow-start, reducing the 681 congestion window to the initial window, and setting the ACK Ratio to 682 at most two. 684 Until further investigation, the sender will not decrease the ACK 685 Ratio as a result of a congestion event involving a data packet. 687 4.6. The Receiver: Sending ACKs for Out-of-Order Data Segments 689 RFC 2581 says that "a TCP receiver SHOULD send an immediate duplicate 690 ACK when an out-of-order segment arrives." After three duplicate 691 ACKs are received, the TCP sender infers a packet loss and implements 692 Fast Retransmit and Fast Recovery, retransmitting the missing packet. 693 When the ACK Ratio is at most two, the TCP receiver should still send 694 an immediate duplicate ACK when an out-of-order segment arrives. 696 In general, when the ACK Ratio is greater than two, the TCP receiver 697 still should send an immediate duplicate ACK for each of the first 698 three out-of-order segments that arrive in a reordering event. (We 699 define a reordering event at the receiver as beginning when an out- 700 of-order segment arrives, and ending when the receiver holds no more 701 out-of-order segments.) However, when the ACK Ratio is greater than 702 two, after the first three duplicate ACKs have been sent, the TCP 703 receiver should perform ACK congestion control on the remaining ACKs 704 to be sent during the current reordering event. That is, after the 705 first three duplicate ACKs have been sent, the TCP receiver should 706 return to sending an ACK for every R segments, instead of sending an 707 ACK for every out-of-order segment in that reordering event. [We 708 note that the Fast Recovery procedure of the TCP sender might have to 709 be modified to take this change into account.] In addition, a 710 receiver must not withhold an ACK for more than 500 ms. 712 We note that in an environment with systematic reordering in the data 713 path (e.g., every set of K data packets arrives in inverted order, 714 for some value of K), the guideline above could result in the 715 receiver sending an ACK for every data packet, regardless of the ACK 716 Ratio. In such an environment with persistent reordering, the 717 receiver may decide not to send an immediate duplicate ACK for each 718 of the first three out-of-order segments that arrive in a reordering 719 event. We leave the investigation of mechanisms for effective ACK 720 Congestion Control in environments with systematic reordering for 721 future work. 723 4.7. The Sender: Response to ACK Packets 725 The use of a large ACK Ratio can generate line rate data bursts at a 726 TCP sender. When the ACK Ratio is greater than two, the TCP sender 727 should use some form of burst mitigation, or rate-based pacing for 728 sending data packets in response to a single acknowledgement. The 729 use of rate-based pacing will be limited by the timer granularity at 730 the TCP sender. 732 We note that the interaction of ACK congestion control and burst 733 mitigation schemes needs further study. 735 Byte counting at the sender: In addition to the impact of a large ACK 736 Ratio on the burstiness of the TCP sender's sending rate, a large ACK 737 Ratio can also affect the data sending rate by slowing down the 738 increase of the congestion window cwnd. As specified in RFC 2581, in 739 slow-start the TCP sender increases cwnd by one full-sized segment 740 for each new ACK received (in this context, a "new ACK" is an ACK 741 that acknowledges new data). RFC 2581 also specifies that in 742 congestion avoidance, the TCP sender increases cwnd by roughly 1/cwnd 743 full-sized segments for each ACK received, resulting in an increase 744 in cwnd of roughly one full-sized segment per round-trip time. In 745 this case, the use of a large ACK Ratio would slow down the increase 746 of the sender's congestion window. 748 RFC 2581 notes that during congestion avoidance it is also acceptable 749 to count the number of bytes acknowledged by new ACKs, and to 750 increase cwnd based on the number of bytes acknowledged, rather than 751 on the number of new ACKs received. Thus, the sender should use this 752 form of byte counting with Acknowledgement Congestion Control, so 753 that the Acknowledgement Congestion Control doesn't slow down the 754 window increases for the data traffic sent by the sender. Because 755 rate-based pacing should be used with Acknowledgement Congestion 756 Control, as recommended earlier in this section, the TCP sender may 757 increase the congestion window by more than two MSS for each ACK. 759 We note that for Appropriate Byte Counting (ABC) as specified in 760 [RFC3465], during Slow-Start the sender is allowed to increase the 761 congestion window by at most two MSS for each ACK. It has not yet 762 been determined whether, with Acknowledgement Congestion Control, the 763 TCP sender could use ABC during Slow-Start. If ABC is used with 764 Acknowledgement Congestion Control, then when the TCP sender is in 765 slow-start and the ACK Ratio is greater than two, the TCP sender may 766 increase the congestion window by more that two MSS in response to a 767 single ACK. Section 4.2 of [LL07] explores some of the issues with 768 the use of ABC for TCP connections with a fixed ACK Ratio greater 769 than two. 771 Inferring lost data packets: As cited earlier, RFC 2581 infers that a 772 packet has been lost after it receives three duplicate 773 acknowledgements. Because ACK Congestion Control is only used when 774 there is congestion on the reverse path, after a packet loss one or 775 more of the three duplicate ACKs sent by the receiver could be lost 776 on the reverse path, and the receiver might wait until it has 777 received R more out-of-order segments before sending the next 778 duplicate ACK. All this could slow down Fast Recovery and Fast 779 Retransmit quite a bit. The use of SACK can help reduce the 780 potential delay in detecting a lost packet. With SACK, a TCP sender 781 can use the information in the SACK option to detect when the 782 receiver has received at least three out-of-order data packets, and 783 to initiate Fast Retransmit and Fast Recovery in this case, even if 784 the TCP sender has not yet received three dup ACKs. 786 4.8. Possible Addition: Receiver Bounds on the ACK Ratio 788 It has been suggested that in some environments, the TCP receiver 789 might want to set lower bounds on the ACK Ratio. For example, the 790 TCP receiver might know from configuration or from past experience 791 that the bandwidth on the return path is limited, and might want to 792 set a lower bound (greater than two) on the ACK Ratio R. If this is 793 included, this would require a TCP Option from the TCP receiver to 794 the TCP sender reporting the lower bound on the ACK Ratio. Care 795 would also be needed so that the lower bound on the ACK Ratio was 796 only in effect when the TCP sender's congestion window was 797 sufficiently high. 799 5. Possible Complications 801 5.1. Possible Complication: Delayed Acknowledgements 803 The receiver could send a delayed acknowledgement acknowledging a 804 single packet, even when the ACK Ratio is two or more. 806 This should not cause false positives (when the TCP sender infers a 807 loss when no loss happened). The TCP sender only infers that a pure 808 ACK packet has been lost when no data packet has been lost, and an 809 ACK packet arrives acknowledging more than R new packets. 811 Delayed acknowledgements could, however, cause false negatives, with 812 the TCP sender unable to detect the loss of an ACK packet sent as a 813 delayed acknowledgement. False negatives seem acceptable; this would 814 result in approximate ACK congestion control, which would be better 815 than no ACK congestion control at all. In particular, when this form 816 of false negative occurs, it is because the receiver is sending 817 acknowledgements at such a low rate that it is sending delayed 818 acknowledgements, rather than acknowledging at least R data packets 819 with each acknowledgement. 821 5.2. Possible Complication: Duplicate Acknowledgements. 823 As discussed in Section 4.3, RFC 2581 states that "a TCP receiver 824 SHOULD send an immediate duplicate ACK when an out-of-order segment 825 arrives", and that "a TCP receiver SHOULD send an immediate ACK when 826 the incoming segment fills in all or part of a gap in the sequence 827 space" [RFC2581]. When ACK Congestion Control is used, the TCP 828 receiver instead uses the guidelines from Section 4.6 to govern the 829 sending of duplicate ACKs. More work would be useful to evaluate the 830 advantages and disadvantages of this approach in terms of the 831 potential delay in triggering Fast Retransmit, and to explore 832 alternate possibilities. 834 5.3. Possible Complication: Two-Way Traffic. 836 In a TCP connection with two-way traffic, the receiver could send 837 some pure ACK packets, and some acknowledgements piggy-backed on data 838 packets. The receiver would still follow the rule of only sending a 839 pure ACK packet when there is a need for a delayed ACK, or there are 840 R new data packets to acknowledge. 842 In a connection with two-way traffic, the TCP sender would not always 843 be able to infer when a pure ACK packet had been lost. For example, 844 the receiver could send a pure ACK packet acknowledging packet K, and 845 soon afterwards, the receiver could send a newly-generated data 846 packet for the reverse-path flow also acknowledging packet K. The 847 pure ACK packet could be dropped in the network, and the sender would 848 not be able to detect this drop. 850 Fortunately, there are limitations to the potential problems caused 851 by undetected ACK losses in two-way traffic. The sender will only 852 fail to detect the loss of a pure ACK packet if the ACK packet was 853 followed by a data packet with the same acknowledgement number. If 854 the reverse-path traffic for the connection is dominated by data 855 traffic, then the congestion control for the data traffic is more 856 important than the congestion control for the pure ACK traffic. If 857 the reverse-path traffic is dominated by pure ACK traffic, then the 858 sender would detect any losses of pure ACK packets followed by other 859 pure ACK packets, and this would include most of the pure ACK packets 860 for that connection. Thus, the sender's failure to detect the loss 861 of a pure ACK packet followed by a data packet with the same 862 acknowledgement number would not disable acknowledgement congestion 863 control for a TCP connection with two-way traffic. 865 5.4. Possible Complication: Reordering of ACK Packets. 867 It is possible for ACK packets to be reordered on the reverse path. 868 The TCP sender could either use a parallel mechanism to the DupACK 869 threshold to infer when an ACK packet has been lost, as with TCP, or, 870 more robustly, the TCP sender could wait an entire round-trip time 871 before inferring that an ACK packet has been lost [RFC4653]. 873 5.5. Possible Complication: Abrupt Changes in the ACK Path. 875 What happens when there are abrupt changes in the reverse path, such 876 as from vertical handovers? Can there be any problems that would be 877 worse than those experienced by a TCP connection that is not using 878 ACK congestion control? 880 5.6. Possible Complication: Corruption. 882 As with data packets, it is possible for ACK packets to be dropped in 883 the network due to corruption rather than congestion. The current 884 assumption of ACK congestion control is that all losses should be 885 taken as indications of congestion. If there is ever some better 886 mechanism for identifying and responding to corrupted TCP data 887 packets, the same solution hopefully would apply to corrupted ACK 888 packets as well. 890 One problem with the interaction of packet corruption and congestion 891 control, for both data and ACK packets, is that it is not always 892 obvious when the packet corruption is related to congestion, and when 893 the packet corruption is independent of the level of congestion on 894 the corrupting link. In environments where packet corruption exists 895 and is independent of the level of congestion on the corrupting link, 896 applying ACK congestion control would only make the connection more 897 sensitive to ACK packet corruption, by reducing the number of ACKs 898 that are sent. 900 5.7. Possible Complication: ACKs That Don't Contribute to Congestion. 902 It is possible for the ACK packets in a TCP connection to traverse a 903 congested path where ACK packets are dropped, but where the ACK 904 packets themselves don't significantly contribute to the congestion 905 on the path. In scenarios where ACK packets are dropped but where 906 ACK traffic doesn't make a significant contribution of the congestion 907 on the path, the use of ACK Congestion Control would not contribute 908 to reducing the aggregate congestion on the path. In this case, one 909 goal is to minimize the negative impact of ACK Congestion Control on 910 the overall performance of the TCP connection. 912 J TCP conns. link L -> J TCP conns. 913 data -> |---| |---| <- ACKs 914 <-------------> | | | | <-------------> 915 | | <-------------> | | 916 <-------------> | | | | <-------------> 917 K TCP conns. |---| |---| K TCP conns. 918 ACKs -> <- link L1 <- data 920 A scenario with J forward and K reverse TCP connections. 922 To explore the relative contribution of ACK traffic on congestion, it 923 is useful to consider a simple scenario with a congested 924 unidirectional link L carrying data traffic from J TCP connections 925 (the forward TCP connections) and ACK traffic from K TCP connections 926 (the reverse TCP connections). We assume that all TCP connections 927 have the same round-trip time R and the same data packet size S of 928 1500 bytes. We further assume that all of the forward TCP 929 connections have the same data packet drop rate p and the same 930 congestion window W, and that all of the reverse TCP connections have 931 the same congestion window W1 and the same ACK packet drop rate p1. 932 (The packet drop rate for data packets is defined as the fraction of 933 arriving data packets that are dropped; similarly, the packet drop 934 rate for ACK packets is the fraction of arriving ACK packets that are 935 dropped.) The J TCP connections each use a bandwidth on link L of 936 1500*W/R bytes per second, and the K TCP connections, without ACK 937 Congestion Control, each use a bandwidth on link L of 40*(W1/2)/R 938 bytes per second. This gives a ratio of 75*(J/K)*(W/W1) for TCP data 939 bandwidth to TCP ACK bandwidth on link L. The ratio J/K is the ratio 940 between the number of forward and reverse TCP connections on link L, 941 and could have a wide range of values (e.g., large for an access link 942 from a web server, and small for an access link to a web server). 943 For this scenario, the ratio W/W1 is largely a function of the 944 different levels of congestion on the forward and reverse paths. 946 To explore the possibilities, we will consider some of the range of 947 congestion control mechanisms for the congested link. First, we 948 consider scenarios where the limitation on the congested path is in 949 the link bandwidth in bytes per second. 951 Cases (1), (2), (3), (5), and (7) below represent the best scenarios 952 for ACK Congestion Control, where the fraction of packet drops for 953 TCP ACK packets roughly matches the TCP ACK packets' contribution to 954 congestion. [In several of these cases this is at best a rough match 955 because the data packets are a factor in the bandwidth and in the 956 queue limitations, while the TCP ACK packets are only a factor in the 957 queue limitations.] Cases (4) and (8) below represent problematic 958 scenarios where the fraction of packet drops for TCP ACK packets is 959 much higher than the TCP ACK packets' contribution to congestion (in 960 terms of taking space in a congested queue, using scarce CPU cycles 961 at the congested router, or using scarce bandwidth). Case (6) below 962 represents scenarios where ACK Congestion Control would not be 963 effective because it would not be invoked. In the scenarios in case 964 (6), the fraction of packet drops for TCP ACK packets would be much 965 smaller than the TCP ACK packets' contribution to congestion. 967 (1) The Drop-Tail queue for link L is measured in packets. In this 968 case, the congested queue can accommodate N packets, regardless of 969 packet size, there is a limitation of both bandwidth in bytes per 970 second and also in queue space in packets, and large data packets and 971 small TCP ACK packets should see similar packet drop rates. Although 972 TCP ACK packets most likely aren't a major factor in the bandwidth 973 limitation, they can be a significant contribution to the limitation 974 of queue space. So, while the packet drop rate for ACK packets could 975 be high in times of congestion, the ACK packets are contributing to 976 that congestion somewhat by using scarce buffer space. 978 (2) The Drop-Tail queue is measured in bytes. In this case, the 979 congested queue can accommodate M bytes of packets, and TCP ACK 980 packets don't make a significant contribution to either the bandwidth 981 limitation or to the limitation in queue space. It is also the case 982 that in this scenario, even if there is heavy congestion, the packet 983 drop rate for TCP ACK packets should be small (because small ACK 984 packets can often find space on the congested queue when large data 985 packets can't find space). In this case, ACK Congestion Control 986 should not present any problems; the TCP ACK packets aren't 987 contributing significantly to congestion, and aren't experiencing 988 significant packet drop rates. 990 (3) The RED queue is in packet mode, and is measured in packets. 991 This is similar to case (1) above. Because the queue is measured in 992 packets, small TCP ACK packets contribute to the limitation in queue 993 space, but not to the limitation in link bandwidth. Because the 994 queue is in packet mode, large data packets and small TCP ACK packets 995 should see similar packet drop rates. 997 (4) The RED queue is in packet mode, but is measured in bytes. 998 Because the queue is measured in bytes, small TCP ACK packets don't 999 contribute significantly to either the limitation in queue space or 1000 to the limitation in link bandwidth. Because the queue is in packet 1001 mode, large data packets and small TCP ACK packets should see similar 1002 packet drop rates. If it existed, this case would be problematic, 1003 because the TCP ACK packets would not be contributing significantly 1004 to the congestion, but they would see a similar packet drop rate as 1005 the large data packets that are contributing to congestion. 1007 (5) The RED queue is in byte mode, and is measured in bytes. This is 1008 similar to case (2) above. Because the queue is measured in bytes, 1009 small TCP ACK packets don't contribute significantly to either the 1010 limitation in queue space or to the limitation in link bandwidth. At 1011 the same time, because the queue is in byte mode, small TCP ACK 1012 packets see much smaller packet drop rates that those of large data 1013 packets. 1015 (6) The RED queue is in byte mode, but is measured in packets. 1016 Because the queue is measured in packets, small TCP ACK packets 1017 contribute to the limitation in queue space, but not to the 1018 limitation in link bandwidth. Because the queue is in byte mode, 1019 small TCP ACK packets see much smaller packet drop rates that those 1020 of large data packets. If this case existed, TCP ACK packets would 1021 contribute somewhat to congestion, but would see a much smaller 1022 packet drop rate than that of large data packets. 1024 Next, we consider scenarios where the limitation on the congested 1025 link is in CPU cycles at the router in packets per second, not in 1026 bandwidth in bytes per second. 1028 (7) The CPU load imposed by TCP ACK packets is similar to the load 1029 imposed by other packets (e.g., TCP data packets). ACK Congestion 1030 Control would be useful in this scenario, particularly if TCP ACK 1031 packets saw the same packet drop rates as TCP data packets. 1033 (8) The CPU load imposed by TCP ACK packets is much less than the 1034 load imposed by other packets (e.g., TCP data packets). If TCP ACK 1035 packets saw a smaller packet drop rate than TCP data packets, then 1036 the TCP ACK packet drop rate would roughly match the TCP ACK packets' 1037 contribution to congestion, and this would be good. If TCP ACK 1038 packets saw the same packet drop rate as TCP data packets, this case 1039 would be problematic, because the TCP ACK packets would not be 1040 contributing significantly to the congestion, but they would see a 1041 similar packet drop rate as the large data packets that are 1042 contributing to congestion. 1044 5.8. Possible Complication: TCP Implementations that Skip ACK Packets 1046 It has been reported in IETF meetings that current TCP 1047 implementations do not always acknowledge at least every other data 1048 packet, as required by the TCP specifications. In particular, it has 1049 been reported that if a TCP receiver receives many data packets in a 1050 burst, before it is able to send an acknowledgement, then it might 1051 send a single acknowledgement for the burst of packets. We note that 1052 such a behavior would cause complications for a TCP connection that 1053 used ACK congestion control, as the sender would not be able to 1054 determine when an ACK packet had been dropped in the network, and 1055 when the packet had been skipped by the receiver because it was 1056 processing a burst of data packet arrivals. 1058 One possibility for addressing this problem would be for TCP 1059 receivers using ACK congestion control to be required to send an 1060 acknowledgement for each R packets, for ACK Ratio R. In this case, 1061 if the receiver received a large burst of data packets back-to-back, 1062 the receiver would be required to send a responding burst of ACK 1063 packets, one for each set of R data packets. 1065 A second possibility for addressing this problem would be to define a 1066 TCP option or flag that the TCP receiver could use when sending an 1067 ACK packet to inform the sender that the TCP receiver `skipped' some 1068 ACK packets, so that the sender should not infer ACK loss if some 1069 previous ACK packets seem to be missing. 1071 Future work will explore the costs and benefits of these two 1072 approaches. 1074 5.9. Possible Complication: Router or Middlebox-based ACK Mechanisms 1076 One possible complication would be the interaction of ACK Congestion 1077 Control with router-based or middlebox-based ACK mechanisms such as 1078 ACK filtering along the reverse path [BPK97] [WWCM99] [BA03] [KLS07]. 1079 We are not aware of the deployment of ACK filtering in the Internet, 1080 but any testing of ACK congestion control would have to look for 1081 interactions with any middlebox-based mechanisms regarding ACK 1082 packets. In particular, we would consider interactions of ACK 1083 congestion control with the possible deployment of ACK filtering on 1084 satellite links, cable modems, or the like. 1086 5.10. Possible Complication: Data-Limited Senders 1088 The mechanism for adjusting the ACK Ratio is designed with the goal 1089 of having the TCP receiver send at least two ACKs in response to each 1090 window of at least four full-sized data packets. However, with ACK 1091 Congestion Control in combination with a data-limited sender, it is 1092 possible for the sender to send at least four full-sized data packets 1093 in a round-trip time, with the receiver sending less than two ACKs in 1094 response. 1096 As an example, consider a connection where the the sender's 1097 congestion window W is greater than four and the ACK Ratio R is at 1098 its maximum value of W/2. If the sender becomes data-limited and 1099 sends less than W data packets in a round-trip time, then the 1100 receiver can send less than two ACK packets in response. This 1101 behavior makes the connection more sensitive to the loss of an 1102 occasional ACK packet. 1104 Of course, there is still the safety mechanism of the receiver 1105 sending an ACK packet when the delayed ACK timer expires. However, 1106 more work would be useful to explore the conflicting goals of a 1107 congestion-controlled ACK flow and a timely ACK response to the 1108 sender for the specific case of a connection with a data-limited 1109 sender and a congested ACK path. 1111 5.11. Other Issues 1113 Are there any problems caused by the combination of two-way traffic 1114 and reordering? Or other issues that have not yet been addressed? 1116 6. Evaluating ACK Congestion Control 1118 Evaluating ACK Congestion Control will have two components: (1) 1119 evaluating the effects of ACK Congestion Control on an individual TCP 1120 connection; and (2) evaluating the effects of ACK Congestion Control 1121 on aggregate traffic (including the effects of ACK Congestion Control 1122 on the aggregate congestion of the path). 1124 The first part, evaluating ACK Congestion Control on the performance 1125 of an individual TCP connection, will have to examine those scenarios 1126 where ACK Congestion Control might help the performance of a TCP 1127 connection, and those scenarios where the use of ACK Congestion 1128 Control might cause problems. 1130 The second part, evaluating the effects of ACK Congestion Control on 1131 aggregate traffic, should consider scenarios where the use of ACK 1132 Congestion Control helps all of the connections sharing a path by 1133 reducing the aggregate congestion on the path. This part should also 1134 see if there are scenarios where ACK Congestion Control causes 1135 problems by increasing the burstiness of aggregate traffic, or by 1136 otherwise changing traffic dynamics. 1138 6.1. Contention in Wireless Links or in non-switched Ethernet 1140 One possible benefit of ACK congestion control is that it could 1141 reduce contention in wireless links, shared Ethernet, or other 1142 environments with contention between forward-path and reverse-path 1143 traffic [AJ03] [KIA07]. At the same time, contention on the shared 1144 medium won't necessarily result in dropped ACK packets, and therefore 1145 wouldn't necessarily be detected by ACK congestion control. 1147 6.2. Keep-alive and Other Special ACK Packets 1149 Some TCP hosts send keep-alive packets when no data or ACK packets 1150 have been received over a long period of time [KEEP-ALIVE]. This 1151 keep-alive mechanism is not addressed in TCP specifications. 1152 However, such keep-alive packets, if used, should not interact with 1153 ACK congestion control one way or another. For ACK congestion 1154 control, the ACK Ratio is set small enough to allow the receiver to 1155 generally send at least two ACKs for a window of data. In addition, 1156 the receiver uses a delayed ACK timer with the ACK Ratio, always 1157 sending an acknowledgement if the delayed ACK timer expires. Thus, 1158 ACK congestion control will never cause the receiver to delay 1159 indefinitely in sending an acknowledgement for a received data 1160 packet. 1162 Some TCP implementations send pure ACK packets as window probes, to 1163 solicit an ACK packet from the other end with current window 1164 information. Such ACK packets will generally be orthogonal to the 1165 ACK Congestion Control specified in this draft. 1167 TCP receivers also can send pure ACK packets as window update packets 1168 announcing a new value for the receive window, even when the 1169 acknowledgement number and SACK options in the ACK packet are not 1170 new. The receiver may send window update packets even if the ACK 1171 Congestion Control mechanism would say that it is not time yet to 1172 send a pure ACK. The sender will not necessarily be able to detect 1173 the loss of a window update ACK packet. 1175 7. Measurements of ACK Traffic and Congestion 1177 There are a number of studies about the traffic composition on 1178 various links in the Internet, reporting the fraction of bandwidth 1179 used by TCP data and by TCP ACK traffic [Studies]. 1181 Are there any studies that show the relative packet drop rates for 1182 TCP data and ACK traffic, for particular links or for particular TCP 1183 connections? 1185 Are there any studies of congested links that show the fraction of 1186 traffic on the congested link, or in the congested queue, that 1187 consist of TCP ACK packets? 1189 8. Acknowledgement Congestion Control in DCCP's CCID 2 1191 In the transport protocol DCCP [RFC4340], the congestion control 1192 mechanism for the CCID 2 profile is based on that of TCP. This 1193 section briefly discusses some of the issues that have been addressed 1194 in the acknowledgement congestion control already standardized in 1195 CCID 2. 1197 Rate-based pacing: For CCID 2, RFC 4341 says that "senders MAY use a 1198 form of rate-based pacing when sending multiple data packets 1199 liberated by a single ACK packet, rather than sending all liberated 1200 data packets in a single burst." However, rate-based pacing is not 1201 required in CCID 2. 1203 Increasing the congestion window: For CCID 2, RFC 4341 says that 1204 "when cwnd < ssthresh, meaning that the sender is in slow-start, the 1205 congestion window is increased by one packet for every two newly 1206 acknowledged data packets with ACK Vector State 0 (not ECN-marked), 1207 up to a maximum of ACK Ratio/2 packets per acknowledgement. This is 1208 a modified form of Appropriate Byte Counting [RFC3465] that is 1209 consistent with TCP's current standard (which does not include byte 1210 counting), but allows CCID 2 to increase as aggressively as TCP when 1211 CCID 2's ACK Ratio is greater than the default value of two. When 1212 cwnd >= ssthresh, the congestion window is increased by one packet 1213 for every window of data acknowledged without lost or marked 1214 packets." 1216 9. Security Considerations 1218 What are the sender's incentives to cheat on ACK congestion control? 1219 What are the receiver's incentives to cheat? What are the avenues 1220 open for cheating? 1222 As long as ACK congestion control is optional, neither host can be 1223 forced to use ACK congestion control if it doesn't want to. So ACK 1224 congestion control will only be used if the sender or receiver have 1225 some chance of receiving some benefit. 1227 As long as ACK congestion control is optional for TCP, there is 1228 little incentive for the TCP end nodes to cheat on non-ECN-based ACK 1229 congestion control. There is nothing now that requires TCP hosts to 1230 use congestion control in response to dropped ACK packets. 1232 What avenues for cheating are opened by the use of ECN-Capable ACK 1233 packets? If the end nodes can use ECN to have ACK packets marked 1234 rather than dropped, and if the end nodes can then avoid the use of 1235 ACK congestion control that goes along with the use of ECN on ACK 1236 packets, then the end nodes could have an incentive to cheat. 1237 Senders could cheat by not instructing the receiver to use a higher 1238 ACK Ratio; the receiver would have a hard time detecting this 1239 cheating. Receivers could cheat by not using the ACK Ratio they were 1240 instructed to use, but senders could easily detect this cheating. 1241 However, receivers could also cheat by not using ACK congestion 1242 control and still sending ACK packets as ECN-capable, so ACK 1243 congestion control is not a necessary component for receivers to 1244 cheat about sending ECN-capable ACK packets. One question would be 1245 whether there is any way for receivers to cheat about sending ECN- 1246 Capable ACK packets and not using appropriate ACK congestion control 1247 without this cheating being easily detected by the sender. 1249 What about the ability of routers or middleboxes to detect TCP 1250 receivers that cheat by inappropriately sending ACK packets as ECN- 1251 capable? The router will only know if the receiver is authorized to 1252 send ACK packets as ECN-Capable if the router can see traffic on both 1253 the forward and reverse paths, and monitored both the SYN and SYN/ACK 1254 packets (and was able to read the TCP options in the packet headers). 1255 If ACK congestion control has been negotiated, the router will only 1256 know if ACK congestion control is being used correctly by the 1257 receiver if it can monitor the ACK Ratio options sent from the sender 1258 to the receiver. If ACK congestion control is being used, the router 1259 will not necessarily be able to tell if ACK congestion control is 1260 being used correctly by the sender, because drops of ACK packets 1261 might be occurring after the ACK packets have left the router. 1262 However, if the router sees the ACK Ratio options sent from the 1263 sender, the router will be able to tell if the sender is correctly 1264 accounting for those ACK packets that are dropped or ECN-marked on 1265 the path from the receiver to the router. 1267 10. IANA Considerations 1269 No IANA action is needed at this time. If this document was advanced 1270 as Experimental or Proposed Standard, then IANA would allocate the 1271 option numbers for the two TCP options, the ACK Congestion Control 1272 Permitted Option, and the ACK Ratio Option. In this case, the 1273 following two lines would be added to the TCP Option Numbers registry 1274 (currently located at http://www.iana.org/assignments/tcp- 1275 parameters): 1277 Kind Length Meaning Reference 1278 ---- ------ --------------------------------- ----------- 1279 TBD1 2 ACK Congestion Control Permitted [RFC{this}] 1280 TBD2 3 ACK Ratio [RFC{this}] 1282 In the absence of TCP option numbers allocated by IANA, experimenters 1283 may use the TCP Option Numbers set aside for Experimentation in 1284 RFC4727 [RFC4727]. As stressed in Section 1 of RFC 3692 [RFC3692], 1285 the TCP Option Numbers in the experimental range are intended for 1286 experimentation and testing and not for wide or general deployments; 1287 these option numbers could be in use by other experimentors for other 1288 purposes. 1290 11. Conclusions 1292 This document specifies a congestion control mechanism for 1293 acknowledgement traffic (ACKs) for TCP, and discusses the possible 1294 complications. We are deferring a recommendation on the use of this 1295 mechanism for TCP until it has been evaluated more fully. 1297 12. Acknowledgements 1299 Many thanks for feedback from Mark Allman, Armando Caro, Alfred 1300 Hoenes, Ilpoo Jarvinen, Sara Landstrom, Anantha Ramaiah, and Michael 1301 Welzl, and for contributed text from Michael Welzl. 1303 A. Appendix: Related Work 1305 There exist several papers dealing with controlling congestion in the 1306 reverse path of a TCP connection, especially in the context of 1307 networks with bandwidth asymmetry. Some of these proposals require 1308 explicit support from routers or middleboxes, whereas others are 1309 "pure" end-to-end schemes. 1311 RFC 3449 [RFC3449] discusses TCP performance problems that arise in 1312 TCP connections over asymmetric paths. Section 3 of RFC 3449 1313 describes in detail how congestion on the ACK path can affect overall 1314 TCP performance. RFC 3449 also outlines a number of proposed 1315 mitigations, including ACK Congestion Control. The experimental ACK 1316 Congestion Control mechanism discussed in the RFC relies on ECN, with 1317 the TCP sender detecting congestion on the ACK path from ECN-marked 1318 packets. The RFC also discusses two receiver-based mechanisms, 1319 Window Prediction Mechanism (WPM) [CLP98] and Acknowledgement based 1320 on Cwnd Estimation (ACE) [MJW00], for using a dynamic ACK Ratio. 1321 RFC 3449 also considers link and network layer techniques that 1322 address congestion on the upstream path. These include header 1323 compression, and bandwidth management techniques for the upstream 1324 link including ACK filtering and ACK reconstruction. 1326 RFC 3135 [RFC3135] on "Performance Enhancing Proxies Intended to 1327 Mitigate Link-Related Degradations" surveys a range of Performance 1328 Enhancing Proxies used to improve TCP behavior, including proxies for 1329 ACK filtering and reconstruction. RFC 2760 [RFC2760] on "Ongoing TCP 1330 Research Related to Satellites" discusses both ACK Congestion Control 1331 and ACK Filtering and Reconstruction, with detailed descriptions of 1332 the mechanisms proposed by Balakrishnan et al. in [BPK97]. 1334 Landstrom et al. in [LL07] explore a mechanism where the receiver 1335 sends only four acknowledgements per window of data, along with the 1336 sender using a form of Appropriate Byte Counting. In addition, the 1337 receiver reverts to a lower acknowledgement frequency after a 1338 timeout, to avoid unnecessary Retransmit Timeouts. One conclusion of 1339 the paper is that pacing at the sender introduces an additional 1340 delay, and might not be necessary. A key result of the paper is that 1341 with the use of some form of byte counting at the sender, it is 1342 possible for TCP to use a lower acknowledgement frequency than that 1343 of delayed acknowledgements. 1345 A.1. ECN-only Mechanisms 1347 Balakrishnan et al. in [BPK97] describe the use of ECN to detect 1348 congestion in the return path, in order to reduce the sending rate of 1349 ACKs. The use of a RED queue in the reverse path allows for marking 1350 of ACK packets. The sender echoes back ECN congestion marks to the 1351 receiver. The receiver keeps an ACK ratio d (called the "delayed-ACK 1352 factor"), specifying the number of data segments that have to be 1353 received before the receiver sends a new ACK. The ACK ratio d is 1354 managed using multiplicative-increase, additive-decrease; upon 1355 reception of a congestion mark, the receiver doubles the value of d 1356 (hence dividing the ACK sending rate by two). The ACK ratio 1357 decreases linearly for each RTT in which no ECN-marked ACKs are 1358 received. Multiple congestion marks received in an RTT are treated 1359 as a single congestion event, i.e., d can be doubled at most once per 1360 RTT. The TCP timestamp option is used to keep track of the RTT 1361 values. 1363 A.2. Receiver-only Mechanisms 1365 In [MJW00], Tam Ming-Chit et al. propose a receiver-based method for 1366 calculating an "appropriate" number of ACKs per congestion window 1367 (cwnd) of data, in order to alleviate congestion on the reverse path. 1368 The sender's cwnd is estimated at the receiver by counting the number 1369 of received packets per RTT (which also has to be estimated by the 1370 receiver). From this estimate, a simple algorithm is used to compute 1371 the number of ACKs to be sent per cwnd. The algorithm enforces a 1372 lower bound on the number of ACKs per cwnd, aiming at minimizing the 1373 probability of timeout at the sender due to ACK loss. Similarly, the 1374 ACK ratio is upper-bounded so as to avoid excessive ACK delay. 1376 Blandford et al. [BGG+07] propose an end-to-end, receiver-oriented 1377 scheme called "smartacking". The algorithm is based upon the 1378 receiver monitoring the inter-segment arrival time for data packets 1379 and adapting the ACK sending rate in response. When the bottleneck 1380 link is underutilized, ACKs are sent frequently (up to one ACK per 1381 received segment) to promote fast growth of the congestion window. 1382 On the other hand, when the bottleneck is close to full utilization, 1383 the algorithm tries to reduce control traffic overhead and slow 1384 congestion window growth by generating ACKs at the minimum rate 1385 needed to keep the data pipe full. 1387 Reducing the number of ACKs (or, equivalently, increasing the amount 1388 of bytes acknowledged by each ACK) can increase the burstiness of the 1389 TCP sender. Hence, any mechanism as those cited above should be 1390 coupled with a burst mitigation technique, Rate-Based Pacing, that 1391 paces the sending of data segments [AB05] [ASA00] [BPK97]. 1393 A.3. Middlebox-based Mechanisms 1395 ACK filtering (AF) [BPK97] from Balakrishnan et al. is a router-based 1396 technique that tries to reduce the number of ACKs sent over the 1397 congested return link. With AF, an arriving ACK may replace 1398 preceding, older ACKs at the bottleneck queue. An aggressive 1399 replacement policy might guarantee that at most one ACK per 1400 connection is waiting in the queue, alleviating congestion. However, 1401 as in other proposals, care must be taken to avoid sender timeouts in 1402 case the (too few) ACKs resulting from the filtering get lost. The 1403 idea of filtering ACKs has been extended in [YMH03] to deal with SACK 1404 information. 1406 Aweya et al. [AOM02] present a middlebox-based approach for 1407 mitigating data packet bursts and for controlling the uplink ACK 1408 congestion. The main idea is to perform pacing on ACK segments on an 1409 edge device close to the sender, so as to control the ACK arrival 1410 rate at the sender. 1412 B. Appendix: Design Considerations 1414 B.1. The TCP ACK Ratio Option, or an AckNow bit in data packets? 1416 In the ACK congestion control mechanism specified in this document, 1417 the sender uses the TCP ACK Ratio Option to tell the receiver the ACK 1418 Ratio to use. An alternate approach to the TCP ACK Ratio Option 1419 could be for the sender to use an AckNow bit in the TCP header of 1420 data packets, telling the receiver to acknowledge this data packet. 1421 In the discussion below, we call these two approaches the TCP ACK 1422 Ratio Option approach and the AckNow approach. 1424 An advantage of an AckNow approach is that it would require less 1425 state from the receiver; the receiver would not need to maintain a 1426 variable for the current ACK Ratio, and would not need to keep track 1427 of the number of data packets unacked to date. 1429 However, a disadvantage of the AckNow approach is that the sender 1430 does not know when packets will be reordered, delayed, or dropped on 1431 the path to the receiver. In particular, the sender does not have 1432 control over whether a data packet with the AckNow bit set is 1433 reordered, delayed, or dropped in the network. For this reason, we 1434 have chosen the approach of the sender determining the ACK Ratio that 1435 should be used, and sending the ACK Ratio to the receiver, rather 1436 than the sender telling the receiver exactly which data packets to 1437 acknowledge. 1439 An additional disadvantage of the AckNow approach is that it would 1440 add complications and add difficulties for the default cases of the 1441 receiver using an ACK Ratio of one or two, as is done in the absence 1442 of ACK congestion control. 1444 For these reasons, we have specified that the sender determines the 1445 ACK Ratio to use and tells the receiver, rather than the sender 1446 setting an AckNow bit in the TCP Header of selected data packets. 1448 Normative References (if standardized) 1450 [RFC2119] S. Bradner, "Key Words For Use in RFCs to Indicate 1451 Requirement Levels", RFC 2119, March 1997. 1453 [RFC2581] Allman, M., V. Paxson, and W. Stevens, "TCP Congestion 1454 Control", RFC 2581, April 1999. 1456 [RFC3692] Narton, T., "Assigning Experimental and Testing Numbers 1457 Considered Useful", RFC 3692, January 2004. 1459 [RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte 1460 Counting (ABC)", RFC 3465, Experimental, February 2003. 1462 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion 1463 Control Protocol (DCCP)", RFC 4340, March 2006. 1465 [RFC4341] Floyd, S., and E. Kohler, "Profile for Datagram Congestion 1466 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 1467 Congestion Control", RFC 4341, March 2006. 1469 [RFC4727] Fenner, B., "Experimental Values in IPv4, IPv6, ICMPv4, 1470 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 1472 Informative References 1474 [RFC2760] Allman, M., Dawkins, S., Glover, D., Griner, J., Henderson, 1475 T., Heidemann, J., Kruse, H., Ostermann, S., Scott, K., Semke, J., 1476 Touch, J. and D. Tran, "Ongoing TCP Research Related to 1477 Satellites", RFC 2760, February 2000. 1479 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z. 1480 Shelby, "Performance Enhancing Proxies Intended to Mitigate Link- 1481 Related Degradations", RFC 3135, June 2001. 1483 [RFC3168] K. Ramakrishnan, S. Floyd and D. Black, "The Addition of 1484 Explicit Congestion Notification (ECN) to IP", RFC 3168, September 1485 2001. 1487 [RFC3449] H. Balakrishnan, V. N. Padmanabhan, G. Fairhurst, and M. 1488 Sooriyabandara, "TCP Performance Implications of Network Path 1489 Asymmetry", RFC 3449, December 2002. 1491 [RFC4653] S. Bhandarkar, A. L. N. Reddy, M. Allman and E. Blanton, 1492 "Improving the Robustness of TCP to Non-Congestion Events", RFC 1493 4653, August 2006. 1495 [ASA00] A. Aggarwal, S. Savage, and T. Anderson, "Understanding the 1496 Performance of TCP Pacing", INFOCOM (3), pp. 1157-1165, 2000. 1498 [AB05] M. Allman and E. Blanton, "Notes on Burst Mitigation for 1499 Transport Protocols", SIGCOMM Comput. Commun. Rev., 35(2):5360, 1500 2005. 1502 [AJ03] E. Altman and T. Jimenez, "Novel Delayed ACK Techniques for 1503 Improving TCP Performance in Multihop Wireless Networks", Proc. of 1504 the Personal Wireless Communications, 2003. 1506 [AOM02] J. Aweya, M. Ouellette, and D. Y. Montuno, "A Self- 1507 regulating TCP Acknowledgement (ack) Pacing Scheme". Int. J. Netw. 1508 Manag., 12(3):145163, 2002. 1510 [BA03] C. Barakat and E. Altman, "On ACK Filtering on a Slow Reverse 1511 Channel", International Journal of Satellite Communications and 1512 Networking, V.21 N.3, 2003. 1514 [BPK97] Balakrishnan, H., V. Padmanabhan, and Katz, R., "The Effects 1515 of Asymmetry on TCP Performance", Third ACM/IEEE Mobicom 1516 Conference, September 1997. 1518 [BGG+07] D.K. Blandford, S.A. Goldman, S. Gorinsky, Y. Zhou, and D.R. 1519 Dooly, "Smartacking: Improving TCP Performance from the Receiving 1520 End", Journal of Internet Engineering, 1(1), 2007. 1522 [CLP98] Calveras, A., Linares, J., and J. Paradells, "Window 1523 Prediction Mechanism for Improving TCP in Wireless Asymmetric 1524 Links". Proc. IEEE Global Communications Conference (GLOBECOM), 1525 Sydney Australia, November 1998, pp. 533-538. 1527 [KIA07] Keceli, F., I. Inan, and E. Ayanoglu, "TCP ACK Congestion 1528 Control and Filtering for Fairness Provision in the Uplink of IEEE 1529 802.11 Infrastructure Basic Service Set", Proc. IEEE ICC 2007, 1530 June 2007. 1532 [KEEP-ALIVE] Fabio Busatto, "TCP Keepalive HOWTO", May 2007, URL 1533 "http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/index.html". 1535 [KLS07] H. Kim, H. Lee, and S. Shin, "On the Cross-Layer Impact of 1536 TCP ACK Thinning on IEEE 802.11 Wireless MAC Dynamics", IEICE 1537 Transactions on Communications, 2007 1539 [LL07] Landstrom, S., and Larzon, L.-A., "Reducing the TCP 1540 Acknowledgement Frequency", CCR, July 2007. 1542 [MJW00] Ming-Chit, I.T., Jinsong, D., and W. Wang, "Improving TCP 1543 Performance Over Asymmetric Networks", ACM SIGCOMM, ACM Computer 1544 Communications Review (CCR), Vol.30, No.3, 2000. 1546 [Studies] Web page on "Measurement Studies of End-to-End Congestion 1547 Control in the Internet", URL 1548 "http://www.icir.org/floyd/ccmeasure.html". 1550 [WWCM99] H. Wu, J. Wu, S. Cheng, and J. Ma, "ACK Filtering on 1551 Bandwidth Asymmetry Networks", IEEE Communications, 1999. 1553 [YMH03] L. Yu, Y. Minhua, and Z. Huimin, "The Improvement of TCP 1554 Performance in Bandwidth Asymmetric Network", IEEE PIMRC, 1555 1:482-486, September 2003. 1557 Authors' Addresses 1558 Sally Floyd 1559 ICSI Center for Internet Research 1560 1947 Center Street, Suite 600 1561 Berkeley, CA 94704 1562 USA 1564 EMail: floyd@icir.org 1566 Andres Arcia 1567 Networking, Security & Multimedia (RSM) Dpt. 1568 TELECOM Bretagne 1569 Rue de la Chataigneraie, CS 17607 1570 35576 Cesson Sevigne Cedex 1571 France 1573 Email:ae arcia telecom-bretagne eu 1575 Universidad de Los Andes 1576 Facultad de Ingenieria 1577 Nucleo La Hechicera 1578 Merida, Merida 5101 1579 Venezuela 1581 EMail: amoret ula ve 1582 URI: http://www.ula.ve 1584 Janardhan R. Iyengar 1585 Math and Computer Science 1586 Franklin & Marshall College 1587 P. O. Box 3003 1588 Lancaster, PA 17604-3003 1589 USA 1591 Email: jiyengar fandm edu 1593 David Ros 1594 Networking, Security & Multimedia (RSM) Dpt. 1595 TELECOM Bretagne 1596 Rue de la Chataigneraie, CS 17607 1597 35576 Cesson Sevigne Cedex 1598 France 1600 Email: David Ros telecom-bretagne eu 1602 Acknowledgement 1604 Funding for the RFC Editor function is provided by the IETF 1605 Administrative Support Activity (IASA).