< draft-ietf-tsvwg-cc-alt-03.txt   draft-ietf-tsvwg-cc-alt-04.txt >
Internet Engineering Task Force S. Floyd Internet Engineering Task Force S. Floyd
Internet-Draft M. Allman Internet-Draft M. Allman
Intended status: Best Current Practice ICIR / ICSI Intended status: Best Current Practice ICIR / ICSI
Expires: November 2007 May 2007 Expires: December 2007 June 2007
Specifying New Congestion Control Algorithms Specifying New Congestion Control Algorithms
draft-ietf-tsvwg-cc-alt-03.txt draft-ietf-tsvwg-cc-alt-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 54 skipping to change at page 1, line 54
control principles. Using these new congestion control schemes in control principles. Using these new congestion control schemes in
the global Internet has possible ramifications to both the traffic the global Internet has possible ramifications to both the traffic
using the new congestion control and to traffic using the currently using the new congestion control and to traffic using the currently
standardized congestion control. Therefore, the IETF must proceed standardized congestion control. Therefore, the IETF must proceed
with caution when dealing with alternate congestion control with caution when dealing with alternate congestion control
proposals. The goal of this document is to provide guidance for proposals. The goal of this document is to provide guidance for
considering alternate congestion control algorithms within the IETF. considering alternate congestion control algorithms within the IETF.
TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION: TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION:
Changes from draft-ietf-tsvwg-cc-alt-01.txt: Changes from draft-ietf-tsvwg-cc-alt-03.txt:
* Minor rewordings in response to IESG review.
Changes from draft-ietf-tsvwg-cc-alt-02.txt:
* Removed references from abstract. * Removed references from abstract.
* Added a note that we are focused on documents produced within the * Added a note that we are focused on documents produced within the
IETF (i.e., these are not guidelines that the IRTF or the RFC IETF (i.e., these are not guidelines that the IRTF or the RFC
Editor would necessarily have to follow). Editor would necessarily have to follow).
* Added a list of 'difficult environments' the IETF has thought * Added a list of 'difficult environments' the IETF has thought
about in the past (even while admitting that an exhaustive list of about in the past (even while admitting that an exhaustive list of
'difficult environments' is impossible to produce). 'difficult environments' is impossible to produce).
skipping to change at page 8, line 18 skipping to change at page 8, line 21
control mechanism allows for incremental deployment in the control mechanism allows for incremental deployment in the
targeted environment. For a mechanism targeted for deployment targeted environment. For a mechanism targeted for deployment
in the current Internet, it would be helpful for the proposal to in the current Internet, it would be helpful for the proposal to
discuss what is known (if anything) about the correct operation discuss what is known (if anything) about the correct operation
of the mechanism with some of the equipment installed in the of the mechanism with some of the equipment installed in the
current Internet, e.g., routers, transparent proxies, WAN current Internet, e.g., routers, transparent proxies, WAN
optimizers, intrusion detection systems, home routers, and the optimizers, intrusion detection systems, home routers, and the
like. like.
As a similar concern, if the alternate congestion control As a similar concern, if the alternate congestion control
mechanism is intended only for specific environments, the mechanism is intended only for specific environments (and not
proposal should consider how this intention is to be carried the global Internet), the proposal should consider how this
out. For example, if a proposed congestion control scheme is intention is to be carried out. The community will have to
deemed suitable for deployment in controlled environments but address the question of whether the scope can be enforced by
unsafe for widespread deployment in the Internet, is it simply stating the restrictions or whether additional protocol
sufficient just to have a sentence in the Abstract of the mechanisms are required to enforce the scoping. The answer will
document stating this, or are some additional mechanisms needed necessarily depend on the change being proposed.
as well?
As an example from an Experimental RFC, deployment issues are As an example from an Experimental RFC, deployment issues are
discussed in Sections 10.3 and 10.4 of [RFC4782] (Quick-Start). discussed in Sections 10.3 and 10.4 of [RFC4782] (Quick-Start).
4. Minimum Requirements 4. Minimum Requirements
This section suggests minimum requirements for a document to be This section suggests minimum requirements for a document to be
approved as Experimental with approval for widespread deployment in approved as Experimental with approval for widespread deployment in
the global Internet. We note that this is not a binding document the global Internet.
with fixed and unchanging requirements, but simply a document
targeted for approval as Best Current Practice.
The minimum requirements for approval for widespread deployment in The minimum requirements for approval for widespread deployment in
the global Internet include the following guidelines (1) on the global Internet include the following guidelines (1) on
assessing the impact on standard congestion control, (3) on assessing the impact on standard congestion control, (3) on
investigation of the proposed mechanism in a range of environments, investigation of the proposed mechanism in a range of environments,
guideline (4) on protection against congestion collapse and guideline (4) on protection against congestion collapse and
guideline (8), discussing whether the mechanism allows for guideline (8), discussing whether the mechanism allows for
incremental deployment. incremental deployment.
For other guidelines, i.e., (2), (5), (6), and (7), evidence that For other guidelines, i.e., (2), (5), (6), and (7), the author must
the proposed mechanism has significantly more problems than those of perform the suggested evaluations and provide recommended analysis.
TCP should be a cause for concern in approval for widespread Evidence that the proposed mechanism has significantly more problems
deployment in the global Internet. than those of TCP should be a cause for concern in approval for
widespread deployment in the global Internet.
6. Security Considerations 5. Security Considerations
This document does not represent a change to any aspect of the This document does not represent a change to any aspect of the
TCP/IP protocol suite and therefore does not directly impact TCP/IP protocol suite and therefore does not directly impact
Internet security. The implementation of various facets of the Internet security. The implementation of various facets of the
Internet's current congestion control algorithms do have security Internet's current congestion control algorithms do have security
implications (e.g., as outlined in [RFC2581]). Alternate congestion implications (e.g., as outlined in [RFC2581]). Alternate congestion
control schemes should be mindful of such pitfalls, as well, and control schemes should be mindful of such pitfalls, as well, and
should examine any potential security issues that may arise. should examine any potential security issues that may arise.
7. IANA Considerations 6. IANA Considerations
This document does not require any IANA action. This document does not require any IANA action.
Acknowledgments Acknowledgments
Discussions with Lars Eggert and Aaron Falk seeded this document. Discussions with Lars Eggert and Aaron Falk seeded this document.
Thanks to Bob Briscoe, Gorry Fairhurst, Doug Leith, Jitendra Padhye, Thanks to Bob Briscoe, Gorry Fairhurst, Doug Leith, Jitendra Padhye,
Colin Perkins, members of TSVWG, and participants at the TCP Colin Perkins, Pekka Savola, members of TSVWG, and participants at
Workshop at Microsoft Research for feedback and contributions. This the TCP Workshop at Microsoft Research for feedback and
document also draws from [Metrics]. contributions. This document also draws from [Metrics].
Normative References Normative References
[RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion [RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion
Control, RFC 2581, Proposed Standard, April 1999. Control, RFC 2581, Proposed Standard, April 1999.
[RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, Best [RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, Best
Current Practice, September 2000. Current Practice, September 2000.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
 End of changes. 9 change blocks. 
23 lines changed or deleted 25 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/