Internet Engineering Task Force Sally Floyd INTERNET-DRAFT ICIR draft-ietf-dccp-tfrc-voip-00.txt Eddie Kohler Expires: July 2005 UCLA 6 January 2005 TCP Friendly Rate Control (TFRC) for Voice: VoIP Variant and Faster Restart Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 July 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Floyd/Kohler [Page 1]
INTERNET-DRAFT Expires: July 2005 January 2005 Abstract TCP-Friendly Rate Control (TFRC) is a congestion control mechanism for unicast flows operating in a best-effort Internet environment [RFC 3448]. This document adds a VoIP variant to TFRC. TFRC was intended for applications that use a fixed packet size, and was designed to be reasonably fair when competing for bandwidth with TCP connections using the same packet size. The VoIP variant of TFRC is designed for applications that send small packets, where the design goal is to achieve the same bandwidth in bps as a TCP flow using 1500-byte data packets. The VoIP variant of TFRC enforces a Min Interval of 10 ms between data packets, to prevent a single flow from sending small packets arbitrarily frequently. This document also introduces faster restart, a mechanism for safely improving the behavior of interactive flows that use TFRC. Floyd/Kohler [Page 2]
INTERNET-DRAFT Expires: July 2005 January 2005 Table of Contents 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. VoIP Variant Introduction . . . . . . . . . . . . . . . . . . 4 3. VoIP Variant Congestion Control . . . . . . . . . . . . . . . 5 4. VoIP Variant Discussion . . . . . . . . . . . . . . . . . . . 6 4.1. The TCP Throughput Equation. . . . . . . . . . . . . . . 6 4.2. Accounting for Header Size . . . . . . . . . . . . . . . 7 4.3. The VoIP Min Interval. . . . . . . . . . . . . . . . . . 7 5. Faster Restart Introduction . . . . . . . . . . . . . . . . . 9 6. Faster Restart Congestion Control . . . . . . . . . . . . . . 10 6.1. Entering and Leaving Idle Periods. . . . . . . . . . . . 11 6.2. Feedback Packets . . . . . . . . . . . . . . . . . . . . 11 7. Faster Restart Discussion . . . . . . . . . . . . . . . . . . 12 8. Simulations of the VoIP Variant of TFRC . . . . . . . . . . . 13 8.1. Packet Dropping Behavior at Routers. . . . . . . . . . . 13 9. Simulations of Faster Restart . . . . . . . . . . . . . . . . 14 10. Implementation Issues. . . . . . . . . . . . . . . . . . . . 15 11. Security Considerations. . . . . . . . . . . . . . . . . . . 15 12. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 15 13. Thanks . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Normative References . . . . . . . . . . . . . . . . . . . . . . 15 Informative References . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 16 Floyd/Kohler [Page 3]
INTERNET-DRAFT Expires: July 2005 January 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. VoIP Variant Introduction This document specifies a VoIP variant for TCP-friendly rate control (TFRC) [RFC 3448]. TFRC was designed to be reasonably fair when competing for bandwidth with TCP flows, but to avoid the abrupt changes in the sending rate characteristic of TCP's congestion control mechanisms. TFRC is intended for applications such as streaming media applications where a relatively smooth sending rate is of importance. The VoIP variant is intended for flows that need to send frequent small packets. Conventional TFRC measures loss rates by estimating the loss event ratio as described in [RFC 3448], without considering packet size. This has consequences for the rate a TFRC flow can achieve when sharing a bottleneck with large-packet TCP flows. In particular, a low-bandwidth, small-packet TFRC flow sharing a bottleneck with high-bandwidth, large-packet TCP flows may be forced to slow down, even though the application's nominal rate in bytes per second is less than the rate achieved by the TCP flows. Intuitively, this would be "fair" only if the network limitation was in packets per second (such as a routing lookup), rather than bytes per second (such as link bandwidth). Conventional wisdom is that many of the network limitations in today's Internet are in bytes per second, even though the network limitations of the future might move back towards limitations in packets per second. The VoIP variant of TFRC described here will better support applications that do not want their sending rates in bytes per second to suffer from their use of small packets. This variant is restricted to applications that send packets no more than once every 10 ms (the Min Interval). Given this restriction, the VoIP variant effectively calculates the TFRC fair rate as if the bottleneck restriction was in bytes per second. Applications using the VoIP variant of TFRC could have a fixed packet size, or could vary their packet size in response to congestion. The VoIP variant of TFRC is motivated by the approach in [RFC 3714], which argued that it was acceptable for VoIP flows to assume that the network limitation was in bytes per second (Bps) rather in packets per second (pps), and to have the allowed drop rates for the VoIP flow be determined by the drop rates experienced by a TCP flow with 1500-byte packets and the same sending rate in Bps as the VoIP Floyd/Kohler Section 2. [Page 4]
INTERNET-DRAFT Expires: July 2005 January 2005 flow. [RFC 3714] states the following: "While the ideal would be to have a transport protocol that is able to detect whether the bottleneck links along the path are limited in Bps or in pps, and to respond appropriately when the limitation is in pps, such an ideal is hard to achieve. We would not want to delay the deployment of congestion control for telephony traffic until such an ideal could be accomplished. In addition, we note that the current TCP congestion control mechanisms are themselves not very effective in an environment where there is a limitation along the reverse path in pps. While the TCP mechanisms do provide an incentive to use large data packets, TCP does not include any effective congestion control mechanisms for the stream of small acknowledgement packets on the reverse path. Given the arguments above, it seems acceptable to us to assume a network limitation in Bps rather than in pps in considering the minimum sending rate of telephony traffic." Translating the discussion in [RFC 3714] to the congestion control mechanisms of TFRC, it seems acceptable to standardize a variant of TFRC that allows VoIP flows sending small packets to achieve a rough fairness with TCP flows in terms of the sending rate in Bps, rather than in terms of the sending rate in pps. This is accomplished by a simple two-line modification at the TFRC sender, as described below. No changes are required at the TFRC receiver. However, because the bottlenecks in the network in fact can include limitations in pps as well as in Bps, we pay special attention to the potential dangers of encouraging a large deployment of best- effort traffic in the Internet consisting entirely of small packets. This is discussed in more detail in Section 4.3. In addition, as again discussed in Section 4.3, the VoIP variant of TFRC includes the limitation of the Min Interval between packets of 10 ms. 3. VoIP Variant Congestion Control TFRC uses the TCP throughput equation given in Section 3.1 of [RFC 3448], which gives the allowed sending rate X in bytes per second as a function of the loss event rate, packet size, and round-trip time. [RFC 3448] specifies that the packet size s used in the throughput equation should be the packet size used by the application, or the estimated mean packet size if there are variations in the packet size depending on the data. This gives rough fairness with TCP flows using the same packet size. The VoIP variant changes this behavior in the following ways. Floyd/Kohler Section 3. [Page 5]
INTERNET-DRAFT Expires: July 2005 January 2005 o The nominal packet size s is set to 1460 bytes. Following [RFC 3714], this provides a goal of fairness, in terms of the sending rate in bytes per second, with a TCP flow with 1460 bytes of application data per packet. o The allowed transmit rate X in bytes per second is reduced by a factor that accounts for packet header size. This gives the application some incentive, beyond the Min Interval, not to use unnecessarily small packets. In particular, we introduce a new parameter H, which represents the expected size in bytes of network and transport headers to be used on the TFRC connection's packets. This is used to reduce the allowed transmit rate X as follows: X <- X * s_true / (s_true + H), where s_true is the true average packet size for the connection in bytes. The H parameter is set to the constant 40 bytes. Thus, if the VoIP TFRC application used 40-byte data segments, the allowed transmit rate X would be halved to account for the fact that half of the sending rate would be used by the headers. Section 4.2 justifies this definition. However, a connection using the VoIP variant MAY instead use a more precise estimate of H, based on the actual network and transport headers to be used on the connection's packets. For example, a DCCP connection [DCCP] over IPv4, where data packets use the DCCP-Data packet type, and there are no IP or DCCP options, could set H to 20 + 12 = 32 bytes. o Finally, the VoIP variant of TFRC enforces a Min Interval between packets of 10 ms. A flow that wished to exceed this Min Interval MUST use the conventional TFRC equations, rather than the VoIP variant. The motivation for this is discussed below. 4. VoIP Variant Discussion 4.1. The TCP Throughput Equation The VoIP variant of TFRC uses the TCP throughput equation given in [RFC 3448]. As shown in Table 1 of [RFC 3714], for high packet drop rates, this throughput equation gives rough fairness with most aggressive possible current TCP: a SACK TCP flow using timestamps and ECN. Floyd/Kohler Section 4.1. [Page 6]
INTERNET-DRAFT Expires: July 2005 January 2005 4.2. Accounting for Header Size [RFC 3714] makes the optimistic assumption that the limitation of the network is in bandwidth in bytes per second (Bps), and not in CPU cycles or in packets per second (pps). However, some attention must be paid to the load in pps as well as to the load in Bps. Even aside from the Min Interval, the VoIP variant of TFRC gives the application some incentive to use fewer but larger packets, when larger packets would suffice, by including the bandwidth used by the packet header in the allowed sending rate. As an example, a sender using 120-byte packets needs a TCP-friendly rate of 128 Kbps to send 96 Kbps of application data. This is because the TCP-friendly rate is reduced by a factor of s_true/(s_true + H) = 120/160, to account for the effect of packet headers. If the sender suddenly switched to 40-byte data segments, the allowed sending rate would reduce to 64 Kbps of application data; and one-byte data segments would reduce the allowed sending rate to 3.12 Kbps of application data. (In fact, the Min Interval would prevent senders from achieving these rates, since applications using the VoIP variant cannot send more than 100 packets per second.) The VoIP variant assumes 40 bytes for the header size, although the header could be larger (due to IP options, IPv6, IP tunnels, and the like) or smaller (due to header compression) on the wire, because using the exact header size in bytes would have little additional benefit. The VoIP variant's use of an assumed 40-byte header is sufficient to get a rough estimate of the throughput, and to give the application some incentive not to use unnecessarily-many small packets. Because we are only aiming at rough fairness, and at a rough incentive for applications, the use of a 40-byte header in the calculations of the header bandwidth seems sufficient. 4.3. The VoIP Min Interval The header size calculation provides an incentive for applications to use fewer, but larger, packets. Another incentive is that when the path limitation is in pps, the application using more small packets is likely to receive more packet drops, and to have to reduce its sending rate accordingly. That is, if the congestion is in terms of pps, then the flow sending more pps will receive more congestion indications, and have to adjust its sending rate accordingly. However, the increased congestion caused by the use of small packets in an environment limited by pps is experienced not only by the flow using the small packets, but by all of the competing traffic on that congested link. These incentives are therefore insufficient to provide sufficient protection for pps Floyd/Kohler Section 4.3. [Page 7]
INTERNET-DRAFT Expires: July 2005 January 2005 network limitations. The VoIP variant for TFRC, then, includes a Min Interval of 10 ms. This provides additional restrictions on the use of unnecessarily many small packets. One justification for the Min Interval is the practical one that the applications that currently want to send small packets are the VoIP applications that send at most one packet every 10 ms, so this restriction does not affect current traffic. A second justification is that there is no pressing need for best-effort traffic in the current Internet to send small packets more frequently than once every 10 ms (rather than taking the 10 ms delay at the sender, and merging the two small packets into one larger one). This 10 ms delay for merging small packets is likely to be dominated by the network propagation, transmission, and queueing delays of best- effort traffic in the current Internet. As a result, our judgement would be that the benefit to the user of having less than 10 ms between packets is outweighed by the benefit to the network of avoiding unnecessarily many small packets. The Min Interval causes the VoIP variant of TFRC not to support applications sending small packets very frequently. Consider a TFRC flow with a fixed packet size of 100 bytes, but with a variable sending rate and a fairly uncongested path. When this flow was sending at most 100 pps, it would be able to use the VoIP variant of TFRC. If the flow wished to increase its sending rate to more than 100 pps, but to keep the same packet size, it would no longer be able to achieve this with the VoIP variant to TFRC, and would have to swich to the default TFRC, receiving a dramatic, discontinuous decrease in its allowed sending rate. This seems not only acceptable, but desirable for the global Internet. What is to prevent flows from opening multiple connections, each with a 10 ms Min Interval, and thereby getting around the limitation of the Min Interval? Obviously, there is nothing to prevent flows from doing this, just as there is currently nothing to prevent flows from using UDP, or from opening multiple parallel TCP connections, or from using their own congestion control mechanism. Of course, implementations are also free to limit the number of parallel TFRC connections opened to the same destination in times of congestion, if that seems desirable. And flows that open multiple parallel connections are subject to the inconveniences of reordering and the like. But even without a mechanism to prevent flows from subverting the Min Interval by opening multiple parallel connections, it seems useful to include the Min Interval in the VoIP variant of TFRC. Floyd/Kohler Section 4.3. [Page 8]
INTERNET-DRAFT Expires: July 2005 January 2005 5. Faster Restart 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. This behavior is safe for 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. Incurring slow start on every switch between parties may cause perceived performance to seriously degrade. 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. Soome 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 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. Floyd/Kohler Section 5. [Page 9]
INTERNET-DRAFT Expires: July 2005 January 2005 6. 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. Faster Restart introduces four new state variables to TFRC, as follows. T_idle The time the connection went idle. X_fast_max The rate at which to turn off faster restart; 0 if not in faster restart. Initially 0. X_active_recv The rate at which packets were received in the last active sending period. An active sending period is a period in which the sender was neither idle nor in fast restart. It is initialized to 0 until there has been an active sending period. T_active_recv The most recent time in an active sending period. Several previously existing state variables are also particularly important, as follows. 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. Other variables have values as described in [RFC 3448]. Floyd/Kohler Section 6. [Page 10]
INTERNET-DRAFT Expires: July 2005 January 2005 6.1. Entering and Leaving Idle Periods When the application has nothing to send (an idle period is entered), TFRC sets T_idle := now. When the application has something to send, TFRC uses the following code to determine whether it is leaving an idle period, and if so, how the sending rate should be adjusted. The code will use Faster Restart up to the full last fair rate after an idle period of 10 minutes or less; will not use Fast Testart after an idle period of 30 minutes or more; and interpolates between these extremes after idle periods between 10 and 30 minutes. If (now - T_idle) > max(R, 1 / max(X_calc, s/t_mbi)), /* If idle for <= 10 minutes, end fast start at the full last fair rate; if idle for >= 30 minutes, don't do fast start; in between, interpolate. */ delta_T := now - T_active_recv F := (30 min - min(max(delta_T, 10 min), 30 min)) / 20 min /* Initialize X_fast_max to a fraction of the last active rate */ X_fast_max := F*X_active_recv /* Alter the cached X_recv so we start out between 4 and 8 packets/RTT */ X_recv := max(2*s/R, X_recv) 6.2. Feedback Packets The core of the Faster Restart algorithm is a replacement for the 4th step of Section 4.3, Sender behavior when a feedback packet is received, of [RFC 3448], as follows. Floyd/Kohler Section 6.2. [Page 11]
INTERNET-DRAFT Expires: July 2005 January 2005 To update X when you receive a feedback packet ---------------------------------------------- If (2*X_recv < X_fast_max) and the feedback packet indicates a loss or mark, /* Stop faster restart at the first sign of congestion */ X_fast_max := 0, X_recv := X_recv/2. If p > 0, Calculate X_calc using the TCP throughput equation. If (2*X_recv < X_fast_max), /* Faster restart case */ X := max(min(X_calc, 4*X_recv), s/t_mbi). Else X_fast_max := 0, /* Stop faster restart */ X := max(min(X_calc, 2*X_recv), s/t_mbi). Else If (t_now - tld >= R) X := max(min(2*X, 2*X_recv), s/R); tld := now. 7. 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. 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. Floyd/Kohler Section 7. [Page 12]
INTERNET-DRAFT Expires: July 2005 January 2005 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. 8. Simulations of the VoIP Variant of TFRC VoIP mode for TFRC has been added to the NS simulator, and is illustrated in the validation test "./test-all-friendly" in the directory tcl/tests. 8.1. Packet Dropping Behavior at Routers The default TFRC, without the VoIP variant, was designed for rough fairness with TCP, for TFRC and TCP flows with the same packet size, and experiencing the same packet drop rate. When the issue of fairness between flows with different packets sizes is addressed, it matters whether the packet drop rates experienced by the flows is related to the packet size. That is, are small VoIP packets just as likely to be dropped as large TCP packets, or are the smaller packets less likely to be dropped [WBL02]? In our simulations of TCP flows competing with a VoIP TFRC flow with smaller packets, in a scenario with a congested router with a DropTail queue, the VoIP TCP flow receives more than its fair share in bytes per second. This is the case even for a scenario where the Floyd/Kohler Section 8.1. [Page 13]
INTERNET-DRAFT Expires: July 2005 January 2005 TCP flows are the most aggressive, with SACK TCP, timestamps, and ECN. This is in part because in the simulations with a DropTail queue, even one measured in packets rather than in bytes, the TFRC flow with a smooth sending rate and small packets receives a smaller packet drop rate than the TCP flow with a burstier sending rate and larger packets. As expected, the packet dropping behavior can be varied by varying the Active Queue Management mechanism in the router. When the routers use RED in packet mode, where each *packet* has the same probability of being dropped, the TFRC and TCP flows receive roughly the same packet drop rate. In contrast, when the routers use RED in byte mode, where each *byte* has the same probability of being dropped, the TFRC flow sees a much smaller packet drop rate than the TCP flows. The goal of the VoIP variant of TFRC has been for the TCP flows and the VoIP TFRC flows to have rough fairness in the sending rate in bps, in a scenario where each packet receives roughly the same probability of being dropped. In a scenario where large packets are more likely to be dropped than small packets, or where flows with a bursty sending rate are more likely to have packets dropped than are flows with a smooth sending rate, flows using the VoIP variant of TFRC could receive more bandwidth than competing TCP flows. Although the VoIP variant of TFRC doesn't require that applications are limited by a maximum sending rate, in fact VoIP flows do have such a limitation. As illustrated in the simulations by Tom Phelan, this complicates the issue of exploring the fairness between TCP and VoIP TFRC flows. In addition, for VoIP TFRC flows with a maximum sending rate of 96 Kbps, or with a smaller maximum sending rate, VoIP TFRC only reduces the sending rate of these flows when the packet drop rate is fairly high. In this regime, the performance of TFRC is very much determined by the accuracy of the TCP response function in representing the actual sending rate of a TCP connection. In this regime of high packet drop rates, the performance of the TCP connection is very much affected by the TCP algorithm (e.g., SACK or not), by the use of timestamps and/or of ECN, by the minimum RTO, by the use or not of Limited Transmit, and the like. Thus, for simulations in this regime, there are many parameters to consider. 9. Simulations of Faster Restart TBA Floyd/Kohler Section 9. [Page 14]
INTERNET-DRAFT Expires: July 2005 January 2005 10. Implementation Issues TBA 11. Security Considerations TBA 12. IANA Considerations There are no IANA considerations in this document. 13. Thanks Tom Phelan. The DCCP Working Group. 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. [MAF04] Alberto Medina, Mark Allman, and Sally Floyd, Measuring the Evolution of Transport Protocols in the Internet, May 2004, URL "http://www.icir.org/tbit/". [RFC 2861] M. Handley, J. Padhye, and S. Floyd. TCP Congestion Window Validation. RFC 2861, June 2000. Floyd/Kohler [Page 15]
INTERNET-DRAFT Expires: July 2005 January 2005 [RFC 3714] S. Floyd and J. Kempf, Editors. IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet. RFC 3714. [WBL02] J. Widmer, C. Boutremans, and Jean-Yves Le Boudec, Congestion Control for Flows with Variable Packet Size, Technical Report. Authors' Addresses Sally Floyd <floyd@icir.org> ICSI Center for Internet Research 1947 Center Street, Suite 600 Berkeley, CA 94704 USA Eddie Kohler <kohler@cs.ucla.edu> 4531C Boelter Hall UCLA Computer Science Department Los Angeles, CA 90095 USA Full Copyright Statement Copyright (C) The Internet Society 2004. 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. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an Floyd/Kohler [Page 16]
INTERNET-DRAFT Expires: July 2005 January 2005 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 17]
