draft-ietf-tsvwg-cc-alt-02.txt   draft-ietf-tsvwg-cc-alt-03.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
Specifying New Congestion Control Algorithms Specifying New Congestion Control Algorithms
draft-ietf-tsvwg-cc-alt-02.txt draft-ietf-tsvwg-cc-alt-03.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 41 skipping to change at page 1, line 41
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The IETF's standard congestion control schemes have been widely The IETF's standard congestion control schemes have been widely
shown to be inadequate for various environments (e.g., high-speed shown to be inadequate for various environments (e.g., high-speed
networks). Recent research has yielded many alternate congestion networks). Recent research has yielded many alternate congestion
control schemes ([RFC3649], [HTCP], [FAST], [BIC], [CompoundTCP], control schemes that significantly differ from the IETF's congestion
[XCP], and many more). Using these new congestion control control principles. Using these new congestion control schemes in
schemes in the global Internet has possible ramifications to the global Internet has possible ramifications to both the traffic
both the traffic using the new congestion control and to traffic using the new congestion control and to traffic using the currently
using the currently standardized congestion control. Therefore, standardized congestion control. Therefore, the IETF must proceed
the IETF must proceed with caution when dealing with alternate with caution when dealing with alternate congestion control
congestion control proposals. The goal of this document is to proposals. The goal of this document is to provide guidance for
provide guidance for considering alternate congestion control considering alternate congestion control algorithms within the IETF.
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-01.txt:
* Removed references from abstract.
* 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
Editor would necessarily have to follow).
* Added a list of 'difficult environments' the IETF has thought
about in the past (even while admitting that an exhaustive list of
'difficult environments' is impossible to produce).
* Removed section 5 (conclusions). Some felt that it was redundant
and not needed.
* Made a few of the references normative.
* Various small wording tweaks.
Changes from draft-ietf-tsvwg-cc-alt-01.txt:
* Very minor wording tweaks gathered during WGLC. * Very minor wording tweaks gathered during WGLC.
Changes from draft-ietf-tsvwg-cc-alt-00.txt: Changes from draft-ietf-tsvwg-cc-alt-00.txt:
* Added text to the introduction to clarify the relationship of this * Added text to the introduction to clarify the relationship of this
document and RFC 2914. In addition, added a requirement (0) in document and RFC 2914. In addition, added a requirement (0) in
section 3 that says new congestion control schemes that section 3 that says new congestion control schemes that
significantly diverge from the principles in RFC 2914 must explain significantly diverge from the principles in RFC 2914 must explain
this divergence. this divergence.
skipping to change at page 3, line 36 skipping to change at page 3, line 55
community when evaluating whether a proposal is appropriate for community when evaluating whether a proposal is appropriate for
publication in the RFC series. publication in the RFC series.
The guidelines in this document are intended to be consistent with The guidelines in this document are intended to be consistent with
the congestion control principles from [RFC2914] of preventing the congestion control principles from [RFC2914] of preventing
congestion collapse, considering fairness, and optimizing the flow's congestion collapse, considering fairness, and optimizing the flow's
own performance in terms of throughput, delay, and loss. [RFC2914] own performance in terms of throughput, delay, and loss. [RFC2914]
also discusses the goal of avoiding a congestion control `arms race' also discusses the goal of avoiding a congestion control `arms race'
among competing transport protocols. among competing transport protocols.
This document does not give hard-and-fast requirements This document does not give hard-and-fast requirements for an
for an appropriate congestion control scheme. Rather, the document appropriate congestion control scheme. Rather, the document
provides a set of criteria that should be considered and weighed by provides a set of criteria that should be considered and weighed by
the IETF in the context of each proposal. The high-order criteria the IETF in the context of each proposal. The high-order criteria
for any new proposal is that a serious scientific study of the pros for any new proposal is that a serious scientific study of the pros
and cons of the proposal needs to have been done such that the IETF and cons of the proposal needs to have been done such that the IETF
has a well rounded set of information to consider. has a well rounded set of information to consider.
After initial studies, we encourage authors to write a specification After initial studies, we encourage authors to write a specification
of their proposals for publication in the RFC series to allow others of their proposals for publication in the RFC series to allow others
to concretely understand and investigate the wealth of proposals in to concretely understand and investigate the wealth of proposals in
this space. this space.
2. Status 2. Document Status
Following the lead of HighSpeed TCP, alternate congestion control Following the lead of HighSpeed TCP [RFC3649], alternate congestion
algorithms are expected to be published as "Experimental" RFCs until control algorithms are expected to be published as "Experimental"
such time that the community better understands the solution space. RFCs until such time that the community better understands the
Traditionally, the meaning of "Experimental" status has varied in solution space. Traditionally, the meaning of "Experimental" status
its use and interpretation. As part of this document we define two has varied in its use and interpretation. As part of this document
classes of congestion control proposals that can be published we define two classes of congestion control proposals that can be
with the "Experimental" status. The first class includes published with the "Experimental" status. The first class includes
algorithms that are judged to be safe to deploy for best-effort algorithms that are judged to be safe to deploy for best-effort
traffic in the global Internet and further investigated in that traffic in the global Internet and further investigated in that
environment. The second class includes algorithms that, while environment. The second class includes algorithms that, while
promising, are not deemed safe enough for widespread deployment promising, are not deemed safe enough for widespread deployment as
as best-effort traffic on the Internet, but are being specified best-effort traffic on the Internet, but are being specified to
to facilitate investigations in simulation, testbeds, or facilitate investigations in simulation, testbeds, or controlled
controlled environments. The second class can also include environments. The second class can also include algorithms where
algorithms where the IETF does not yet have sufficient understanding the IETF does not yet have sufficient understanding to decide if the
to decide if the algorithm is or is not safe for deployment on algorithm is or is not safe for deployment on the Internet.
the Internet.
Each alternate congestion control algorithm published is required to Each alternate congestion control algorithm published is required to
include a statement in the abstract indicating whether or not the include a statement in the abstract indicating whether or not the
proposal is considered safe for use on the Internet. Each alternate proposal is considered safe for use on the Internet. Each alternate
congestion control algorithm published is also required to include a congestion control algorithm published is also required to include a
statement in the abstract describing environments where the protocol statement in the abstract describing environments where the protocol
is not recommended for deployment. There may be environments where is not recommended for deployment. There may be environments where
the protocol is deemed *safe* for use, but still is not *recommended* the protocol is deemed *safe* for use, but still is not
for use because it does not perform well for the user. *recommended* for use because it does not perform well for the user.
As examples of such statements, [RFC3649] specifying HighSpeed TCP As examples of such statements, [RFC3649] specifying HighSpeed TCP
includes a statement in the abstract stating that the proposal is includes a statement in the abstract stating that the proposal is
Experimental, but may be deployed in the current Internet. In Experimental, but may be deployed in the current Internet. In
contrast, the Quick-Start document [RFC4782] includes a paragraph contrast, the Quick-Start document [RFC4782] includes a paragraph in
in the abstract stating the the mechanism is only being proposed for the abstract stating the the mechanism is only being proposed for
controlled environments. The abstract specifies environments where controlled environments. The abstract specifies environments where
the Quick-Start request could give false positives (and therefore the Quick-Start request could give false positives (and therefore
would be unsafe to deploy). The abstract also specifies would be unsafe to deploy). The abstract also specifies
environments where packets containing the Quick-Start request could environments where packets containing the Quick-Start request could
be dropped in the network; in such an environment, Quick-Start would be dropped in the network; in such an environment, Quick-Start would
not be unsafe to deploy, but deployment would still not be not be unsafe to deploy, but deployment would still not be
recommended because it could cause unnecessary delays for the recommended because it could cause unnecessary delays for the
connections attempting to use Quick-Start. connections attempting to use Quick-Start.
For researchers who are not ready to bring their congestion control For authors of alternate congestion control schemes who are not
mechanisms to the IETF for standardization (either as Experimental ready to bring their congestion control mechanisms to the IETF for
or as Proposed Standard), one possibility would be to submit an standardization (either as Experimental or as Proposed Standard),
internet-draft that documents the alternate congestion control one possibility would be to submit an internet-draft that documents
mechanism for the benefit of the IETF and IRTF communities. This is the alternate congestion control mechanism for the benefit of the
particularly encouraged in order to get algorithm specifications IETF and IRTF communities. This is particularly encouraged in order
widely disseminated to facilitate further research. Such an to get algorithm specifications widely disseminated to facilitate
internet-draft could be submitted to be considered as an further research. Such an internet-draft could be submitted to be
Informational RFC, as a first step in the process towards considered as an Informational RFC, as a first step in the process
standardization. Such a document would also be expected to carry an towards standardization. Such a document would also be expected to
explicit warning against using the scheme in the global Internet. carry an explicit warning against using the scheme in the global
Internet.
Note: we are not changing RFC publication process for non-IETF
produced documents (e.g., those from the IRTF or independent
RFC-Editor submissions). However, we would hope the guidelines in
this document inform the IESG as they consider whether to add a note
to such documents.
3. Guidelines 3. Guidelines
As noted above, authors are expected to do a well-rounded As noted above, authors are expected to do a well-rounded evaluation
evaluation of the pros and cons of proposals brought to the IETF. of the pros and cons of proposals brought to the IETF. The
The following are guidelines to help authors and the IETF community. following are guidelines to help authors and the IETF community.
Concerns that fall outside the scope of these guidelines are Concerns that fall outside the scope of these guidelines are
certainly possible; these guidelines should not be considered certainly possible; these guidelines should not be considered as an
as an all-encompassing check-list. all-encompassing check-list.
(0) Differences with Congestion Control Principles [RFC2914] (0) Differences with Congestion Control Principles [RFC2914]
Proposed congestion control mechanisms that do not take into Proposed congestion control mechanisms should include a clear
account the congestion control principles from [RFC2914] should explanation of the deviations from [RFC2914].
include a clear explanation of their differences.
(1) Impact on Standard TCP, SCTP [RFC2960], and DCCP [RFC4340]. (1) Impact on Standard TCP, SCTP [RFC2960], and DCCP [RFC4340].
Proposed congestion control mechanisms should be evaluated when Proposed congestion control mechanisms should be evaluated when
competing with standard IETF congestion control. Alternate competing with standard IETF congestion control
congestion controllers that have a significantly negative impact [RFC2581,RFC2960,RFC4340]. Alternate congestion controllers
on traffic using standard congestion control may be suspect and that have a significantly negative impact on traffic using
this aspect should be part of the community's decision making standard congestion control may be suspect and this aspect
with regards to the suitability of the alternate congestion should be part of the community's decision making with regards
control mechanism. to the suitability of the alternate congestion control
mechanism.
We note that this bullet is not a requirement for strict We note that this bullet is not a requirement for strict
TCP-friendliness as a prerequisite for an alternate congestion TCP-friendliness as a prerequisite for an alternate congestion
control mechanism to advance to Experimental. As an example, control mechanism to advance to Experimental. As an example,
HighSpeed TCP is a congestion control mechanism that is HighSpeed TCP is a congestion control mechanism that is
Experimental, but that is not TCP-friendly in all environments. Experimental, but that is not TCP-friendly in all environments.
We also note that this guideline does not constrain the We also note that this guideline does not constrain the fairness
fairness offered for non-best-effort traffic. offered for non-best-effort traffic.
As an example from an Experimental RFC, fairness with standard As an example from an Experimental RFC, fairness with standard
TCP is discussed in Sections 4 and 6 of RFC 3649 (High-Speed TCP is discussed in Sections 4 and 6 of [RFC3649] (HighSpeed
TCP) and using spare capacity is discussed in Sections 6, 11.1, TCP) and using spare capacity is discussed in Sections 6, 11.1,
and 12 of RFC 3649 (High-Speed TCP). and 12 of [RFC3649].
(2) Difficult Environments. (2) Difficult Environments.
The proposed algorithms should be assessed in difficult The proposed algorithms should be assessed in difficult
environments such as paths containing wireless links. environments such as paths containing wireless links.
Characteristics of wireless environments are discussed in Characteristics of wireless environments are discussed in
[RFC3819] and in Section 16 of [Tools]. Other difficult [RFC3819] and in Section 16 of [Tools]. Other difficult
environments can include those with multipath routing within environments can include those with multipath routing within a
a connection. We note that there is still much to be desired connection. We note that there is still much to be desired in
in terms of the performance of TCP in some of these difficult terms of the performance of TCP in some of these difficult
environments. For congestion control mechanisms with environments. For congestion control mechanisms with explicit
explicit feedback from routers, difficult environments can feedback from routers, difficult environments can include paths
include paths with non-IP queues at layer-two, IP tunnels, with non-IP queues at layer-two, IP tunnels, and the like. A
and the like. A minimum goal for experimental mechanisms minimum goal for experimental mechanisms proposed for widespread
proposed for widespread deployment in the Internet should deployment in the Internet should be that they do not perform
be that they do not perform significantly worse than TCP significantly worse than TCP in these environments.
in these environments.
While it is impossible to enumerate all possible "difficult
environments", we note that the IETF has previously grappled
with paths with long delays [RFC2488], high delay bandwidth
products [RFC3649], high packet corruption rates [RFC3155],
packet reordering [RFC4653] and significantly slow links
[RFC3150]. Aspects of alternate congestion control that impact
networks with these characteristics should be detailed.
As an example from an Experimental RFC, performance in difficult As an example from an Experimental RFC, performance in difficult
environments is discussed in Sections 6, 9.2, and 10.2 of environments is discussed in Sections 6, 9.2, and 10.2 of
RFC 4782 (Quick-Start). [RFC4782] (Quick-Start).
(3) Investigating a Range of Environments. (3) Investigating a Range of Environments.
Similar to the last criteria, proposed alternate congestion Similar to the last criteria, proposed alternate congestion
controllers should be assessed in a range of environments. controllers should be assessed in a range of environments. For
For instance, proposals should be investigated across a instance, proposals should be investigated across a range of
range of bandwidths, round-trip times, levels of traffic bandwidths, round-trip times, levels of traffic on the reverse
on the reverse path, and levels of statistical multiplexing path, and levels of statistical multiplexing at the congested
at the congested link. Similarly, proposals should be link. Similarly, proposals should be investigated for robust
investigated for robust performance with different queueing performance with different queueing mechanisms in the routers,
mechanisms in the routers, especially Random Early Detection especially Random Early Detection (RED) [FJ03] and Drop-Tail.
(RED) [FJ03] and Drop-Tail. This evaluation is often not This evaluation is often not included in the internet-draft
included in the internet-draft itself, but in related papers itself, but in related papers cited in the draft.
cited in the draft.
A particularly important aspect of evaluating a proposal A particularly important aspect of evaluating a proposal for
for standardization is in understanding where the algorithm standardization is in understanding where the algorithm breaks
breaks down. Therefore, particular attention should be down. Therefore, particular attention should be paid to
paid to characterizing the areas where the proposed mechanism characterizing the areas where the proposed mechanism does not
does not perform well. perform well.
As an example from an Experimental RFC, performance in a range As an example from an Experimental RFC, performance in a range
of environments is discussed in Section 12 of RFC 3649 of environments is discussed in Section 12 of [RFC3649]
(High-Speed TCP) and Section 9.7 of RFC 4782 (Quick-Start). (HighSpeed TCP) and Section 9.7 of [RFC4782] (Quick-Start).
(4) Protection Against Congestion Collapse. (4) Protection Against Congestion Collapse.
The alternate congestion control mechanism should either The alternate congestion control mechanism should either stop
stop sending when the packet drop rate exceeds some threshold sending when the packet drop rate exceeds some threshold
[RFC3714], or should include some notion of "full backoff". [RFC3714], or should include some notion of "full backoff". For
For "full backoff", at some point the algorithm would "full backoff", at some point the algorithm would reduce the
reduce the sending rate to one packet per round-trip time sending rate to one packet per round-trip time and then
and then exponentially backoff the time between single exponentially backoff the time between single packet
packet transmissions if congestion persists. Exactly when transmissions if congestion persists. Exactly when either "full
either "full backoff" or a pause in sending comes into play backoff" or a pause in sending comes into play will be
will be algorithm-specific. However, as discussed in algorithm-specific. However, as discussed in [RFC2914], this
[RFC2914], this requirement is crucial to protect the network requirement is crucial to protect the network in times of
in times of extreme congestion. extreme congestion.
If "full backoff" is used, this bullet does not require If "full backoff" is used, this bullet does not require that the
that the full backoff mechanism must be identical to that full backoff mechanism must be identical to that of TCP
of TCP. As an example, this bullet does not preclude [RFC2988]. As an example, this bullet does not preclude full
full backoff mechanisms that would give flows with backoff mechanisms that would give flows with different
different round-trip times comparable bandwidth during round-trip times comparable bandwidth during backoff.
backoff.
(5) Fairness within the Alternate Congestion Control Algorithm. (5) Fairness within the Alternate Congestion Control Algorithm.
In environments with multiple competing flows all using the In environments with multiple competing flows all using the same
same alternate congestion control algorithm, the proposal alternate congestion control algorithm, the proposal should
should explore how bandwidth is shared among the competing explore how bandwidth is shared among the competing flows.
flows.
(6) Performance with Misbehaving Nodes and Outside Attackers. (6) Performance with Misbehaving Nodes and Outside Attackers.
The proposal should explore how the alternate congestion control The proposal should explore how the alternate congestion control
mechanism performs with misbehaving senders, receivers, or mechanism performs with misbehaving senders, receivers, or
routers. In addition, the proposal should explore how the routers. In addition, the proposal should explore how the
alternate congestion control mechanism performs with outside alternate congestion control mechanism performs with outside
attackers. This can be particularly important for congestion attackers. This can be particularly important for congestion
control mechanisms that involve explicit feedback from routers control mechanisms that involve explicit feedback from routers
along the path. along the path.
As an example from an Experimental RFC, performance with As an example from an Experimental RFC, performance with
misbehaving nodes and outside attackers is discussed in misbehaving nodes and outside attackers is discussed in Sections
Sections 9.4, 9.5, and 9.6 of RFC 4782 (Quick-Start). This 9.4, 9.5, and 9.6 of [RFC4782] (Quick-Start). This includes
includes discussion of misbehaving senders and receivers; discussion of misbehaving senders and receivers; collusion
collusion between misbehaving routers; misbehaving middleboxes; between misbehaving routers; misbehaving middleboxes; and the
and the potential use of Quick-Start to attack routers or potential use of Quick-Start to attack routers or to tie up
to tie up available Quick-Start bandwidth. available Quick-Start bandwidth.
(7) Responses to Sudden or Transient Events. (7) Responses to Sudden or Transient Events.
The proposal should consider how the alternate congestion The proposal should consider how the alternate congestion
control mechanism would perform in the presence of transient control mechanism would perform in the presence of transient
events such as sudden congestion, a routing change, or a events such as sudden congestion, a routing change, or a
mobility event. Routing changes, link disconnections, mobility event. Routing changes, link disconnections,
intermittent link connectivity, and mobility are discussed in intermittent link connectivity, and mobility are discussed in
more detail in Section 17 of [Tools]. more detail in Section 17 of [Tools].
As an example from an Experimental RFC, response to transient As an example from an Experimental RFC, response to transient
events is discussed in Section 9.2 of RFC 4782 (Quick-Start). events is discussed in Section 9.2 of [RFC4782] (Quick-Start).
(8) Incremental Deployment. (8) Incremental Deployment.
The proposal should discuss whether the alternate congestion The proposal should discuss whether the alternate congestion
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 in the current Internet, it would be helpful for the proposal to
to discuss what is known (if anything) about the correct discuss what is known (if anything) about the correct operation
operation of the mechanism with some of the equipment of the mechanism with some of the equipment installed in the
installed in the current Internet, e.g., routers, current Internet, e.g., routers, transparent proxies, WAN
transparent proxies, WAN optimizers, intrusion detection optimizers, intrusion detection systems, home routers, and the
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, the
proposal should consider how this intention is to be carried proposal should consider how this intention is to be carried
out. For example, if a proposed congestion control scheme is out. For example, if a proposed congestion control scheme is
deemed suitable for deployment in controlled environments but deemed suitable for deployment in controlled environments but
unsafe for widespread deployment in the Internet, is it unsafe for widespread deployment in the Internet, is it
sufficient just to have a sentence in the Abstract of the sufficient just to have a sentence in the Abstract of the
document stating this, or are some additional mechanisms needed document stating this, or are some additional mechanisms needed
as well? 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 RFC 4782 (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 This section suggests minimum requirements for a document to be
be approved as Experimental with approval for widespread approved as Experimental with approval for widespread deployment in
deployment in the global Internet. We note that this is not the global Internet. We note that this is not a binding document
a binding document with fixed and unchanging requirements, with fixed and unchanging requirements, but simply a document
but simply a document targeted for approval as Best Current targeted for approval as Best Current Practice.
Practice.
Minimum requirements for approval for widespread deployment include The minimum requirements for approval for widespread deployment in
guideline (1) on assessing the impact on standard congestion the global Internet include the following guidelines (1) on
control. Minimum requirements also include guideline (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,
and guideline (4) on protection against congestion collapse. In guideline (4) on protection against congestion collapse and
order to be approved for widespread deployment, the proposed guideline (8), discussing whether the mechanism allows for
mechanism will also have to meet guideline (8), discussing whether incremental deployment.
the mechanism allows for incremental deployment.
For other guidelines, i.e., (2), (5), (6), and (7), evidence
that the proposed mechanism has significantly more problems
than those of TCP should be a cause for concern in approval for
widespread deployment in the Internet.
5. Conclusions
This document is intended as a guideline for researchers For other guidelines, i.e., (2), (5), (6), and (7), evidence that
in bringing congestion control mechanisms to the IETF to the proposed mechanism has significantly more problems than those of
be considered for Experimental status, and also as a TCP should be a cause for concern in approval for widespread
guideline to the IETF in evaluating such proposals. deployment in the global Internet.
6. Security Considerations 6. 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 7. 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 Thanks to Bob Briscoe, Gorry Fairhurst, Doug Leith, Jitendra Padhye,
Padhye, Colin Perkins, members of TSVWG, and participants at Colin Perkins, members of TSVWG, and participants at the TCP
the TCP Workshop at Microsoft Research for feedback and Workshop at Microsoft Research for feedback and contributions. This
contributions. This document also draws from [Metrics]. document also draws from [Metrics].
Normative References Normative References
Informative References [RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion
Control, RFC 2581, Proposed Standard, April 1999.
[BIC] L. Xu, K. Harfoush, and I. Rhee, Binary Increase Congestion [RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, Best
Control for Fast Long-Distance Networks, Infocom 2004. Current Practice, September 2000.
[CompoundTCP] K. Tan, J. Song, Q. Zhang, and M. Sridharan, A [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Compound TCP Approach for High-speed and Long Distance Networks, Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L.,
Infocom 2006. and V. Paxson, Stream Control Transmission Protocol, RFC 2960,
October 2000.
[FAST] C. Jin, D. Wei and S. Low, FAST TCP: Motivation, [RFC4340] Kohler, E., Handley, M., and S. Floyd, Datagram
Architecture, Algorithms, Performance, Infocom 2004. Congestion Control Protocol (DCCP), RFC 4340, March 2006.
Informative References
[FJ03] Floyd, S., and Jacobson, V., Random Early Detection [FJ03] Floyd, S., and Jacobson, V., Random Early Detection
Gateways for Congestion Avoidance, IEEE/ACM Transactions on Gateways for Congestion Avoidance, IEEE/ACM Transactions on
Networking, V.1 N.4, August 1993. Networking, V.1 N.4, August 1993.
[HTCP] Shorten, R.N. and Leith, D.J., H-TCP: TCP for High-speed
and Long-distance Networks. PFLDnet, 2004.
[Metrics] S. Floyd, Metrics for the Evaluation of Congestion [Metrics] S. Floyd, Metrics for the Evaluation of Congestion
Control Mechanisms. Internet-draft draft-irtf-tmrg-metrics-07, Control Mechanisms. Internet-draft draft-irtf-tmrg-metrics-07,
work in progress, February 2007. work in progress, February 2007.
[RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion [RFC2488] M. Allman, D. Glover, and L. Sanchez. Enhancing TCP Over
Control, RFC 2581, Proposed Standard, April 1999. Satellite Channels using Standard Mechanisms. RFC 2488. January
1999.
[RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, Best [RFC2988] Vern Paxson, Mark Allman. Computing TCP's Retransmission
Current Practice, September 2000. Timer, November 2000. RFC 2988.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., [RFC3150] S. Dawkins, G. Montenegro, M . Kojo, V. Magret, End-to-end
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., Performance Implications of Slow Links, RFC 3150, July 2001.
and V. Paxson, Stream Control Transmission Protocol, RFC 2960,
October 2000. [RFC3155] S. Dawkins, G. Montenegro, M. Kojo, V. Magret, N. Vaidya,
End-to-end Performance Implications of Links with Errors, RFC 3155,
August 2001.
[RFC3649] S. Floyd, HighSpeed TCP for Large Congestion Windows, [RFC3649] S. Floyd, HighSpeed TCP for Large Congestion Windows,
RFC 3649, September 2003. RFC 3649, September 2003.
[RFC3714] S. Floyd and J. Kempf, IAB Concerns Regarding Congestion [RFC3714] S. Floyd and J. Kempf, IAB Concerns Regarding Congestion
Control for Voice Traffic in the Internet, RFC 3714, March 2004. Control for Voice Traffic in the Internet, RFC 3714, March 2004.
[RFC3819] P. Karn, C. Bormann, G. Fairhurst, D. Grossman, R. Ludwig, [RFC3819] P. Karn, C. Bormann, G. Fairhurst, D. Grossman, R. Ludwig,
J. Mahdavi, G. Montenegro, J. Touch, and L. Wood, Advice for Internet J. Mahdavi, G. Montenegro, J. Touch, and L. Wood, Advice for Internet
[RFC4340] Kohler, E., Handley, M., and S. Floyd, Datagram [RFC4653] Sumitha Bhandarkar, A. L. Narasimha Reddy, Mark Allman,
Congestion Control Protocol (DCCP), RFC 4340, March 2006. Ethan Blanton, Improving the Robustness of TCP to Non-Congestion
Events, RFC 4653, August 2006.
[RFC4782] S. Floyd, M. Allman, A. Jain, and P. Sarolahti, [RFC4782] S. Floyd, M. Allman, A. Jain, and P. Sarolahti,
Quick-Start for TCP and IP. RFC 4782, Experimental, January Quick-Start for TCP and IP. RFC 4782, Experimental, January
2007. 2007.
[Tools] S. Floyd and E. Kohler, Tools for the Evaluation of [Tools] S. Floyd and E. Kohler, Tools for the Evaluation of
Simulation and Testbed Scenarios, Internet-draft Simulation and Testbed Scenarios, Internet-draft
draft-irtf-tmrg-tools-03.txt, work in progress, December 2006. draft-irtf-tmrg-tools-03.txt, work in progress, December 2006.
[XCP] D. Katabi, M. Handley, and C. Rohrs, Congestion Control
for High Bandwidth-Delay Product Networks, Sigcomm 2002.
Authors' Addresses Authors' Addresses
Sally Floyd Sally Floyd
ICIR (ICSI Center for Internet Research) ICIR (ICSI Center for Internet Research)
1947 Center Street, Suite 600 1947 Center Street, Suite 600
Berkeley, CA 94704-1198 Berkeley, CA 94704-1198
Phone: +1 (510) 666-2989 Phone: +1 (510) 666-2989
Email: floyd at icir.org Email: floyd at icir.org
URL: http://www.icir.org/floyd/ URL: http://www.icir.org/floyd/
 End of changes. 44 change blocks. 
175 lines changed or deleted 196 lines changed or added

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