period of four round-trip times (possibly down to the initial
sending rate of two to four packets per round-trip time).
5. The response function used in [RFC3448], Section 3.1, which does
not closely match the behavior of TCP in environments with high
packet drop rates [RFC3714].
One suggestion for higher initial sending rates is an initial sending
rate of up to eight small packets per RTT, when the total packet
size, including headers, is at most 4380 bytes. Because the packets
would be rate-paced out over a round-trip time, instead of sent
back-to-back as they would be in TCP, an initial sending rate of
eight small packets per RTT with TFRC-based congestion control would
be considerably milder than the impact of an initial window of eight
small packets sent back-to-back in TCP. As Section 5.1 describes,
the initial sending rate also serves as a lower bound for reductions
of the allowed sending rate during an idle period.
We note that with CCID 3, the sender is in slow-start in the
beginning and responds promptly to the report of a packet loss or
mark. However, in the absence of feedback from the receiver, the
sender can maintain its old sending rate for up to four round-trip
times. One possibility would be that for an initial window of eight
small packets, the initial nofeedback timer would be set to two
round-trip times instead of four, so that the sending rate would be
reduced after two round-trips without feedback.
Research and engineering will be needed to investigate the pros and
cons of modifying these limitations in order to allow larger initial
sending rates, to send fewer acknowledgements when the data sending
rate is low, to allow more abrupt changes in the sending rate, or to
allow a higher sending rate after an idle period.
Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP
Congestion Control", RFC 2581, April 1999.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The
Addition of Explicit Congestion Notification (ECN) to
IP", RFC 3168, September 2001.
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing
TCP’s Initial Window", RFC 3390, October 2002.
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer,
"TCP Friendly Rate Control (TFRC): Protocol
Specification", RFC 3448, January 2003.
[RFC3692] Narten, T., "Assigning Experimental and Testing
Numbers Considered Useful", BCP 82, RFC 3692, January
2004.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March
2006.
Informative References
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust
Explicit Congestion Notification (ECN) Signaling with
Nonces", RFC 3540, June 2003.
[RFC3714] Floyd, S. and J. Kempf, "IAB Concerns Regarding
Congestion Control for Voice Traffic in the Internet",
RFC 3714, March 2004.
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram
Congestion Control Protocol (DCCP) Congestion Control
ID 2: TCP-like Congestion Control", RFC 4341, March
2006.
[V03] Arun Venkataramani, August 2003. Citation for
acknowledgement purposes only.
Authors’ Addresses
Sally Floyd
ICSI Center for Internet Research
1947 Center Street, Suite 600
Berkeley, CA 94704
USA
EMail: floyd@icir.org
Eddie Kohler
4531C Boelter Hall
UCLA Computer Science Department
Los Angeles, CA 90095
USA
EMail: kohler@cs.ucla.edu
Jitendra Padhye
Microsoft Research
One Microsoft Way
Redmond, WA 98052
USA
EMail: padhye@microsoft.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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
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.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).