Internet Engineering Task Force Eddie Kohler INTERNET-DRAFT UCLA draft-ietf-dccp-tfrc-faster-restart-00.txt Sally Floyd Expires: January 2006 ICIR 21 July 2005 Faster Restart for TCP Friendly Rate Control (TFRC) Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of BCP 78. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 2006. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract TCP-Friendly Rate Control (TFRC) is a congestion control mechanism for unicast flows operating in a best-effort Internet environment Floyd/Kohler [Page 1]
INTERNET-DRAFT Expires: January 2006 July 2005 [RFC 3448]. This document introduces Faster Restart, an optional mechanism for safely improving the behavior of interactive flows that use TFRC. Faster Restart is proposed for use with both the default TFRC and with the VoIP variant of TFRC. Floyd/Kohler [Page 2]
INTERNET-DRAFT Expires: January 2006 July 2005 Table of Contents 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Faster Restart Congestion Control . . . . . . . . . . . . . . 5 3.1. Feedback Packets . . . . . . . . . . . . . . . . . . . . 6 4. Faster Restart Discussion . . . . . . . . . . . . . . . . . . 7 5. Simulations of Faster Restart . . . . . . . . . . . . . . . . 8 6. Implementation Issues . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Thanks. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Normative References . . . . . . . . . . . . . . . . . . . . . . 9 Informative References . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 10 Floyd/Kohler [Page 3]
INTERNET-DRAFT Expires: January 2006 July 2005 1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. 2. Introduction In any RTT, a TFRC flow may not send more than twice X_recv, the amount that was received in the previous RTT. The TFRC nofeedback timer reduces this number by half during each nofeedback timer interval (at least four RTT) in which no feedback is received. The effect of this is that applications must slow start after going idle for any significant length of time, in the absence of mechanisms such as Quick-Start [JFAS05]. This behavior is safe, though conservative, for best-effort traffic in the network. A silent application stops receiving feedback about current network conditions, and thus should not be able to send at an arbitrary rate. But this behavior can damage the perceived performance of interactive applications such as voice. Connections for interactive telephony and conference applications, for example, will usually have one party active at a time, with seamless switching between active parties. A slow start on every switch between parties may seriously degrade perceived performance. Some of the strategies suggested for coping with this problem, such as sending padding data during application idle periods, might have worse effects on the network than simply switching onto the desired rate with no slow start. There is some justification for somewhat accelerating the slow start process after idle periods (as opposed to at the beginning of a connection). A connection that fairly achieves a sending rate of X has proved, at least, that some path between the endpoints can support that rate. The path might change, due to endpoint reset or routing adjustments; or many new connections might start up, significantly reducing the application's fair rate. However, it seems reasonable to allow an application to contribute to transient congestion in times of change, in return for improving application responsiveness after idle periods. This document suggests a relatively simple approach to this problem. Some protocols using TFRC [CCID 3 PROFILE] already specify that the allowed sending rate is never reduced below the RFC-3390 sending rate of four packets per RTT during an idle period. Faster Restart specifies that the allowed sending rate is never reduced below eight packets per RTT, for small packets. In addition, because flows already have some (possibly old) information about the path, Faster Floyd/Kohler Section 2. [Page 4]
INTERNET-DRAFT Expires: January 2006 July 2005 Restart allows flows to quadruple their sending rate in every congestion-free RTT, instead of doubling, up to the previously achieved rate. Any congestion event stops this faster restart and switches TFRC into congestion avoidance. 3. Faster Restart Congestion Control DRAFT DRAFT DRAFT A connection goes "idle" when the application has nothing to send for at least a nofeedback interval (as least four round-trip times). However, when Faster Restart is used, the transport layer MUST send a "ping" packet every several round trip times, to continue getting RTT samples and some idea of the loss event rate. The Faster Restart mechanism refers to several existing TFRC state variables, including: R The RTT estimate; kept current during any idle periods as described above. X The current allowed sending rate in bytes per second. p The recent loss event rate. X_recv The rate at which the receiver estimates that data was received since the last feedback report was sent. Note that this includes "ping" packets sent during idle periods (above) as well as application packets. Faster Restart also introduces two new state variables to TFRC, as follows. X_active_recv The receiver's estimated receive reported during a recent active sending period. An active sending period is a period in which the sender was neither idle nor in faster restart. It is initialized to 0 until there has been an active sending period. T_active_recv The time at which X_active_recv was measured. It is initialized to the connection's start time. Other variables have values as described in [RFC 3448]. Floyd/Kohler Section 3. [Page 5]
INTERNET-DRAFT Expires: January 2006 July 2005 3.1. Feedback Packets The Faster Restart algorithm replaces for the 4th step of Section 4.3, "Sender behavior when a feedback packet is received", of [RFC 3448]. The replacement code has two goals: 1. It keeps track of the active receive rate, X_active_recv. This parameter models the connection's most relevant loss- and mark- free transmit rate, and represents an upper bound on the rate achievable through faster restart. Thus, X_active_recv is increased as the connection achieves higher congestion-free transmit rates, and reduced on congestion feedback, to prevent inappropriate faster restart until a new stable active rate is achieved. Specifically, on congestion feedback at low rates, the sender sets X_active_recv to X_recv/2; this allows limited faster restart up to a likely-safe rate, and lowers the likelihood that badly-timed transient congestion will wholly cripple the faster restart mechanism. 2. It adjusts the receive rate, X_recv, more aggressively during faster restart periods, up to the limit of X_active_recv. The code works in three phases. The first phase determines X_fast_max, the adjusted rate at which faster restart should stop. Full faster restart up to X_active_recv should be allowed for short idle periods, but more conservative behavior should prevail after longer idle periods. Thus, if 10 minutes or less have elapsed since the last active-period measurement (T_active_recv), the code sets X_fast_max to the full value of X_active_recv. If 30 minutes or more have elapsed, X_fast_max is set to 0. Linear interpolation is used between these extremes. The second phase adjusts X_active_recv based on the feedback packet's contents and the value of X_fast_max. Finally, the third phase sets X based on X_fast_max, X_recv, and X_calc, the calculated send rate. Several temporary variables are used, namely X_fast_max, delta_T, F, and X_recv_limit. Floyd/Kohler Section 3.1. [Page 6]
INTERNET-DRAFT Expires: January 2006 July 2005 To update X when you receive a feedback packet ---------------------------------------------- /* First phase. Calculate X_fast_max */ /* If idle for <= 10 minutes, end faster restart at the full last fair rate; if idle for >= 30 minutes, don't do faster restart; in between, interpolate. */ delta_T := now - T_active_recv, F := (30 min - min(max(delta_T, 10 min), 30 min)) / 20 min, X_fast_max := F*X_active_recv. /* Second phase. Update X_active_recv */ If the feedback packet corresponds to an active period and does not indicate a loss or mark, then If X_recv >= X_fast_max, then X_active_recv := X_fast_max := X_recv, T_active_recv := current time. Else if X_recv < X_fast_max and the feedback packet DOES indicate a loss or mark, X_active_recv := X_fast_max := X_recv/2, T_active_recv := current time. /* Third phase. Calculate X */ If p > 0, Calculate X_calc using the TCP throughput equation. X_recv_limit := 2*X_recv. If X_recv_limit < X_fast_max, X_recv_limit := min(4*X_recv, X_fast_max). X := max(min(X_calc, X_recv_limit), s/t_mbi). Else If (t_now - tld >= R) X := max(min(2*X, 2*X_recv), s/R); tld := now. 4. Faster Restart Discussion TCP has historically dealt with idleness either by keeping cwnd entirely open ("immediate start") or by entering slow start, as recommended in RFC 2581. The first option is too liberal, the second too conservative. Clearly a short idle period is not a new connection: recent evidence shows that the connection could fairly sustain some rate. However, longer idle periods are more problematic, and idle periods of hours would seem to require slow start. RFC 2861 [RFC 2861], which is fairly widely implemented [MAF04], gives a moderate mechanism for TCP, where the congestion window is halved for every round-trip time that the sender has remained idle, and the window in re-opened in slow-start when the idle period is over. Floyd/Kohler Section 4. [Page 7]
INTERNET-DRAFT Expires: January 2006 July 2005 Faster Restart should be acceptable for TFRC if its worst-case scenario is acceptable. Realistic worst-case scenarios might include the following scenarios: o The path changes and the old rate isn't acceptable on the new path. RTTs are shorter on the new path too, so Faster Restart clobbers other connections for multiple RTTs, not just one. o Two (or more) connections enter Faster Restart simultaneously. The packet drop rate can be twice as bad, for one RTT, than if they had slow-started after their idle periods. o In addition to connections Fast-Restarting, there are short TCP or DCCP connections starting and stopping all the time, with initial windows of three or four packets. There are also TCP connections with short quiescent periods (web browsing sessions using HTTP 1.1). The audio and video connections have idle periods. And the available bandwidth might vary over time, because of bandwidth used by higher-priority traffic (routing traffic, and diffserv). All of this is happening at once, so the aggregate arrival rate naturally varies from one RTT to the next. And the congested link is an access link, not a backbone link, so the level of statistical multiplexing is not high enough to make everything just look like lovely white noise. Further analysis is required to analyze the effects of these scenarios. We note that Faster Restart in VoIP TFRC is considerably more restrained that Faster Restart in the default TFRC; in VoIP TFRC, the sender is restricted to sending at most one packet every Min Interval. Similarly, Faster Restart in the default TFRC is more restrained that Faster Restart would be if added to TCP; TFRC is controlled of a sending rate, while TCP is controlled by a window, and could send in a very bursty pattern, in the absence of rate- based pacing. 5. Simulations of Faster Restart TBA 6. Implementation Issues TBA Floyd/Kohler Section 6. [Page 8]
INTERNET-DRAFT Expires: January 2006 July 2005 7. Security Considerations TBA 8. IANA Considerations There are no IANA considerations in this document. 9. Thanks We thank the DCCP Working Group for feedback and discussions. Normative References [RFC 2119] S. Bradner. Key Words For Use in RFCs to Indicate Requirement Levels. RFC 2119. [RFC 2434] T. Narten and H. Alvestrand. Guidelines for Writing an IANA Considerations Section in RFCs. RFC 2434. [RFC 2581] M. Allman, V. Paxson, and W. Stevens. TCP Congestion Control. RFC 2581. [RFC 3448] M. Handley, S. Floyd, J. Padhye, and J. Widmer, TCP Friendly Rate Control (TFRC): Protocol Specification, RFC 3448, Proposed Standard, January 2003. Informative References [CCID 3 PROFILE] S. Floyd, E. Kohler, and J. Padhye. Profile for DCCP Congestion Control ID 3: TFRC Congestion Control. draft- ietf-dccp-ccid3-06.txt, work in progress, October 2004. [DCCP] E. Kohler, M. Handley, and S. Floyd. Datagram Congestion Control Protocol, draft-ietf-dccp-spec-08.txt, work in progress, October 2004. [JFAS05] A. Jain, S. Floyd, M. Allman, and P. Sarolahti. Quick- Start for TCP and IP. Internet-draft draft-amit-quick- start-04.txt, work in progress, February 2004. [MAF04] A. Medina, M. Allman, and A. Floyd, Measuring the Evolution of Transport Protocols in the Internet, May 2004, URL "http://www.icir.org/tbit/". [P04] T. Phelan, TFRC with Self-Limiting Sources, October 2004. URL "http://www.phelan-4.com/dccp/". Floyd/Kohler [Page 9]
INTERNET-DRAFT Expires: January 2006 July 2005 [RFC 2861] M. Handley, J. Padhye, and S. Floyd. TCP Congestion Window Validation. RFC 2861, June 2000. [RFC 3714] S. Floyd and J. Kempf, Editors. IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet. RFC 3714. Authors' Addresses Eddie Kohler <kohler@cs.ucla.edu> 4531C Boelter Hall UCLA Computer Science Department Los Angeles, CA 90095 USA Sally Floyd <floyd@icir.org> ICSI Center for Internet Research 1947 Center Street, Suite 600 Berkeley, CA 94704 USA Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Floyd/Kohler [Page 10]
INTERNET-DRAFT Expires: January 2006 July 2005 Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Floyd/Kohler [Page 11]