Internet Engineering Task Force                                 S. Floyd
Internet-Draft                                                 M. Allman
Intended status: Best Current Practice                       ICIR / ICSI
Expires: October 2007                                         April 2007

              Specifying New Congestion Control Algorithms

Status of this Memo

    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 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

    The list of Internet-Draft Shadow Directories can be accessed at

Copyright Notice

    Copyright (C) The IETF Trust (2007).


    The IETF's standard congestion control schemes have been widely
    shown to be inadequate for various environments (e.g., high-speed
    networks).  Recent research has yielded many alternate congestion
    control schemes ([RFC3649], [HTCP], [FAST], [BIC], [CompoundTCP],
    [XCP], and many more).  Using these new congestion control
    schemes in the global Internet has possible ramifications to
    both the traffic using the new congestion control and to traffic
    using the currently standardized congestion control.  Therefore,
    the IETF must proceed with caution when dealing with alternate
    congestion control proposals.  The goal of this document is to
    provide guidance for considering alternate congestion control
    algorithms within the IETF.


    Changes from draft-ietf-tsvwg-cc-alt-00.txt:

Expires: October 2007                                           [Page 1]

draft-ietf-tsvwg-cc-alt-01.txt                                April 2007

    * Added text to the introduction to clarify the relationship of this
      document and RFC 2914.  In addition, added a requirement (0) in
      section 3 that says new congestion control schemes that
      significantly diverge from the principles in RFC 2914 must explain
      this divergence.

    Changes from draft-floyd-tsvwg-cc-alt-00.txt:

    * Changed the name to draft-ietf-tsvwg-cc-alt-00.txt.

    * Added a sentence about robustness with various
      queueing algorithms in the routers, especially both RED
      and DropTail.  Suggestion from Jitendra Padhye.

    * Added a sentence about robustness with the routers,
      middleboxes, and such deployed in the current Internet.
      Concern taken from a talk by Henry Sanders.

    * Add a section about minimum requirements necessary for
      approval for deployment in the global Internet.
      Suggestion by Jitendra Padhye.

    * Added more examples to guideline 3 about difficult environments,
      and added that TCP performance in difficult environments is
      still an active research topic.  Suggestion from Doug Leith.

    * Added citations to examples of discussions of these issues
      in Experimental RFCs 3649 and 4782.

    * Added examples of high speed TCP proposals.  Suggestion
      from Bob Braden.

    * Changed the fairness bullets to better reflect that new congestion
      controllers are expected to assess the impact to standard
      congestion controlled flows---without commenting on how that
      assessment should be done.  From discussions with bob Briscoe.

    * Made numerous editing changes suggested by Gorry Fairhurst.

    Changes from draft-floyd-cc-alt-00.txt:

    * Changed the name to draft-floyd-tsvwg-cc-alt-00.txt.

    * Added a bullet about incremental deployment.  Feedback from
      Colin Perkins

    * Clarified the fairness section;  this section is not saying
      that strict TCP-friendliness is a requirement.

    * Clarified that as an alternative to Full Backoff, a flow
      could stop sending when the packet drop rate is above a
      certain threshold.

    * Clarified that the Full Backoff bullet does not require

Expires: October 2007                                           [Page 2]

draft-ietf-tsvwg-cc-alt-01.txt                                April 2007

      that different flows with different round-trip times
      use the same criteria about when they should back off
      to one packet per round-trip time or less.

    * Added a paragraph about Informational RFCs.

    * Added a bullet about response to transient events, including
      routing events or moving from a private to a shared network.


1.  Introduction

    This document provides guidelines for the IETF to use when
    evaluating suggested congestion control algorithms that
    significantly differ from the general congestion control principles
    outlined in [RFC2914].  The guidance is intended to be useful to
    authors proposing alternate congestion control and for the IETF
    community when evaluating whether a proposal is appropriate for
    publication in the RFC series.

    The guidelines in this document are intended to be consistent with
    the congestion control principles from [RFC2914] of preventing
    congestion collapse, considering fairness, and optimizing the flow's
    own performance in terms of throughput, delay, and loss.  [RFC2914]
    also discusses the goal of avoiding a congestion control `arms race'
    among competing transport protocols.

    This document does not give hard-and-fast rules for what makes for
    an appropriate congestion control scheme.  Rather, the document
    provides a set of criteria that should be considered and weighed by
    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
    and cons of the proposal needs to have been done such that the IETF
    has a well rounded set of information to consider.

    After initial studies, we encourage authors to write a specification
    of their proposals for publication in the RFC series to allow others
    to concretely understand and investigate the wealth of proposals in
    this space.

2.  Status

    Following the lead of HighSpeed TCP, alternate congestion control
    algorithms are expected to be published as "Experimental" RFCs until
    such time that the community better understands the solution space.
    Traditionally, the meaning of "Experimental" status has varied in
    its use and interpretation.  As part of this document we define two
    classes of congestion control proposals that can be published
    with the "Experimental" status.  The first class includes
    algorithms that are judged to be safe to deploy for best-effort
    traffic in the global Internet and further investigated in that
    environment.  The second class includes algorithms that, while

Expires: October 2007                                           [Page 3]

draft-ietf-tsvwg-cc-alt-01.txt                                April 2007

    promising, are not deemed safe enough for widespread deployment
    as best-effort traffic on the Internet, but are being specified
    to facilitate investigations in simulation, testbeds, or
    controlled environments.  The second class can also include
    algorithms where the IETF does not yet have sufficient understanding
    to decide if the algorithm is or is not safe for deployment on
    the Internet.

    Each alternate congestion control algorithm published is required to
    include a statement in the abstract indicating whether or not the
    proposal is considered safe for use on the Internet.  Each alternate
    congestion control algorithm published is also required to include a
    statement in the abstract describing environments where the protocol
    is not recommended for deployment.  There may be environments where
    the protocol is deemed *safe* for use, but still is not *recommended*
    for use because it does not perform well for the user.

    As examples of such statements, [RFC3649] specifying HighSpeed TCP
    includes a statement in the abstract stating that the proposal is
    Experimental, but may be deployed in the current Internet.  In
    contrast, the Quick-Start document [RFC4782] includes a paragraph
    in the abstract stating the the mechanism is only being proposed for
    controlled environments.  The abstract specifies environments where
    the Quick-Start request could give false positives (and therefore
    would be unsafe to deploy).  The abstract also specifies
    environments where packets containing the Quick-Start request could
    be dropped in the network; in such an environment, Quick-Start would
    not be unsafe to deploy, but deployment would still not be
    recommended because it could cause unnecessary delays for the
    connections attempting to use Quick-Start.

    For researchers who are not ready to bring their congestion control
    mechanisms to the IETF for standardization (either as Experimental
    or as Proposed Standard), one possibility would be to submit an
    internet-draft that documents the alternate congestion control
    mechanism for the benefit of the IETF and IRTF communities.  This is
    particularly encouraged in order to get algorithm specifications
    widely disseminated to facilitate further research.  Such an
    internet-draft could be submitted to be considered as an
    Informational RFC, as a first step in the process towards
    standardization.  Such a document would also be expected to carry an
    explicit warning against using the scheme in the global Internet.

3.  Guidelines

    As noted above, authors are expected to do a well-rounded
    evaluation of the pros and cons of proposals brought to the IETF.
    The following are guidelines to help authors and the IETF community.
    Concerns that fall outside the scope of these guidelines are
    certainly possible; these guidelines should not be considered
    as an all-encompassing check-list.

    (0) Differences with Congestion Control Principles [RFC2914]

Expires: October 2007                                           [Page 4]

draft-ietf-tsvwg-cc-alt-01.txt                                April 2007

        Proposed congestion control mechanisms that do not take into
        account the congestion control principles from [RFC2914] should
        include a clear explanation of their differences.

    (1) Impact on Standard TCP, SCTP [RFC2960], and DCCP [RFC4340].

        Proposed congestion control mechanisms should be evaluated when
        competing with standard IETF congestion control.  Alternate
        congestion controllers that have a significantly negative impact
        on traffic using standard congestion control may be suspect and
        this aspect should be part of the community's decision making
        with regards to the suitability of the alternate congestion
        control mechanism.

        We note that this bullet is not a requirement for strict
        TCP-friendliness as a prerequisite for an alternate congestion
        control mechanism to advance to Experimental.  As an example,
        HighSpeed TCP is a congestion control mechanism that is
        Experimental, but that is not TCP-friendly in all environments.
        We also note that this guideline does not constrain the
        fairness offered for non-best-effort traffic.

        As an example from an Experimental RFC, fairness with standard
        TCP is discussed in Sections 4 and 6 of RFC 3649 (High-Speed
        TCP) and using spare capacity is discussed in Sections 6, 11.1,
        and 12 of RFC 3649 (High-Speed TCP).

    (2) Difficult Environments.

        The proposed algorithms should be assessed in difficult
        environments such as paths containing wireless links.
        Characteristics of wireless environments are discussed in
        [RFC3819] and in Section 16 of [Tools].  Other difficult
        environments can include those with multipath routing within
        a connection.  We note that there is still much to be desired
        in terms of the performance of TCP in some of these difficult
        environments.  For congestion control mechanisms with
        explicit feedback from routers, difficult environments can
        include paths with non-IP queues at layer-two, IP tunnels,
        and the like.  A minimum goal for experimental mechanisms
        proposed for widespread deployment in the Internet should
        be that they do not perform significantly worse than TCP
        in these environments.

        As an example from an Experimental RFC, performance in difficult
        environments is discussed in Sections 6, 9.2, and 10.2 of
        RFC 4782 (Quick-Start).

    (3) Investigating a Range of Environments.

        Similar to the last criteria, proposed alternate congestion
        controllers should be assessed in a range of environments.
        For instance, proposals should be investigated across a
        range of bandwidths, round-trip times, levels of traffic

Expires: October 2007                                           [Page 5]

draft-ietf-tsvwg-cc-alt-01.txt                                April 2007

        on the reverse path, and levels of statistical multiplexing
        at the congested link.  Similarly, proposals should be
        investigated for robust performance with different queueing
        mechanisms in the routers, especially Random Early Detection
        (RED) [FJ03] and Drop-Tail.  This evaluation is often not
        included in the internet-draft itself, but in related papers
        cited in the draft.

        A particularly important aspect of evaluating a proposal
        for standardization is in understanding where the algorithm
        breaks down.  Therefore, particular attention should be
        paid to characterizing the areas where the proposed mechanism
        does not perform well.

        As an example from an Experimental RFC, performance in a range
        of environments is discussed in Section 12 of RFC 3649
        (High-Speed TCP) and Section 9.7 of RFC 4782 (Quick-Start).

    (4) Protection Against Congestion Collapse.

        The alternate congestion control mechanism should either
        stop sending when the packet drop rate exceeds some threshold
        [RFC3714], or should include some notion of "full backoff".
        For "full backoff", at some point the algorithm would
        reduce the sending rate to one packet per round-trip time
        and then exponentially backoff the time between single
        packet transmissions if congestion persists.  Exactly when
        either "full backoff" or a pause in sending comes into play
        will be algorithm-specific.  However, as discussed in
        [RFC2914], this requirement is crucial to protect the network
        in times of extreme congestion.

        If "full backoff" is used, this bullet does not require
        that the full backoff mechanism must be identical to that
        of TCP.  As an example, this bullet does not preclude
        full backoff mechanisms that would give flows with
        different round-trip times comparable bandwidth during

    (5) Fairness within the Alternate Congestion Control Algorithm.

        In environments with multiple competing flows all using the
        same alternate congestion control algorithm, the proposal
        should explore how bandwidth is shared among the competing

    (6) Performance with Misbehaving Nodes and Outside Attackers.

        The proposal should explore how the alternate congestion control
        mechanism performs with misbehaving senders, receivers, or
        routers.  In addition, the proposal should explore how the
        alternate congestion control mechanism performs with outside
        attackers.  This can be particularly important for congestion
        control mechanisms that involve explicit feedback from routers

Expires: October 2007                                           [Page 6]

draft-ietf-tsvwg-cc-alt-01.txt                                April 2007

        along the path.

        As an example from an Experimental RFC, performance with
        misbehaving nodes and outside attackers is discussed in
        Sections 9.4, 9.5, and 9.6 of RFC 4782 (Quick-Start).  This
        includes discussion of misbehaving senders and receivers;
        collusion between misbehaving routers; misbehaving middleboxes;
        and the potential use of Quick-Start to attack routers or
        to tie up available Quick-Start bandwidth.

    (7) Responses to Sudden or Transient Events.

        The proposal should consider how the alternate congestion
        control mechanism would perform in the presence of transient
        events such as sudden congestion, a routing change, or a
        mobility event.  Routing changes, link disconnections,
        intermittent link connectivity, and mobility are discussed in
        more detail in Section 17 of [Tools].

        As an example from an Experimental RFC, response to transient
        events is discussed in Section 9.2 of RFC 4782 (Quick-Start).

    (8) Incremental Deployment.

        The proposal should discuss whether the alternate congestion
        control mechanism allows for incremental deployment in the
        targeted environment.  For a mechanism targeted for deployment
        in the current Internet, it would be helpful for the proposal
        to discuss what is known (if anything) about the correct
        operation of the mechanism with some of the equipment
        installed in the current Internet, e.g., routers,
        transparent proxies, WAN optimizers, intrusion detection
        systems, home routers, and the like.

        As a similar concern, if the alternate congestion control
        mechanism is intended only for specific environments, the
        proposal should consider how this intention is to be carried
        out.  For example, if a proposed congestion control scheme is
        deemed suitable for deployment in controlled environments but
        unsafe for widespread deployment in the Internet, is it
        sufficient just to have a sentence in the Abstract of the
        document stating this, or are some additional mechanisms needed
        as well?

        As an example from an Experimental RFC, deployment issues are
        discussed in Sections 10.3 and 10.4 of RFC 4782 (Quick-Start).

4.  Minimum Requirements

    This section suggests minimum requirements for a document to
    be approved as Experimental with approval for widespread
    deployment in the global Internet.  We note that this is not
    a binding document with fixed and unchanging requirements,
    but simply a document targeted for approval as Best Current

Expires: October 2007                                           [Page 7]

draft-ietf-tsvwg-cc-alt-01.txt                                April 2007


    Minimum requirements for approval for widespread deploy include
    guideline (1) on assessing the impact on standard congestion
    control.  Minimum requirements also include guideline (3) on
    investigation of the proposed mechanism in a range of environments,
    and guideline (4) on protection against congestion collapse.  In
    order to be approved for widespread deployment, the proposed
    mechanism will also have to meet guideline (8), discussing whether
    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
    in bringing congestion control mechanisms to the IETF to
    be considered for Experimental status, and also as a
    guideline to the IETF in evaluating such proposals.

6.  Security Considerations

    This document does not represent a change to any aspect of the
    TCP/IP protocol suite and therefore does not directly impact
    Internet security.  The implementation of various facets of the
    Internet's current congestion control algorithms do have security
    implications (e.g., as outlined in [RFC2581]).  Alternate congestion
    control schemes should be mindful of such pitfalls, as well, and
    should examine any potential security issues that may arise.

7.  IANA Considerations

    This document does not require any IANA action.


    Discussions with Lars Eggert and Aaron Falk seeded this document.
    Thanks to Bob Briscoe, Gorry Fairhurst, Doug Leith, Jitendra
    Padhye, Colin Perkins, members of TSVWG, and participants at
    the TCP Workshop at Microsoft Research for feedback and
    contributions.  This document also draws from [Metrics].

Normative References

Informative References

    [BIC] L. Xu, K. Harfoush, and I. Rhee, Binary Increase Congestion
    Control for Fast Long-Distance Networks, Infocom 2004.

    [CompoundTCP] K. Tan, J. Song, Q. Zhang, and M. Sridharan, A
    Compound TCP Approach for High-speed and Long Distance Networks,

Expires: October 2007                                           [Page 8]

draft-ietf-tsvwg-cc-alt-01.txt                                April 2007

    Infocom 2006.

    [FAST] C. Jin, D. Wei and S. Low, FAST TCP: Motivation,
    Architecture, Algorithms, Performance, Infocom 2004.

    [FJ03] Floyd, S., and Jacobson, V., Random Early Detection
    Gateways for Congestion Avoidance, IEEE/ACM Transactions on
    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
    Control Mechanisms.  Internet-draft draft-irtf-tmrg-metrics-07,
    work in progress, February 2007.

    [RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion
    Control, RFC 2581, Proposed Standard, April 1999.

    [RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, Best
    Current Practice, September 2000.

    [RFC2960]  Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
    Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L.,
    and V. Paxson, Stream Control Transmission Protocol, RFC 2960,
    October 2000.

    [RFC3649] S. Floyd, HighSpeed TCP for Large Congestion Windows,
    RFC 3649, September 2003.

    [RFC3714] S. Floyd and J. Kempf, IAB Concerns Regarding Congestion
    Control for Voice Traffic in the Internet, RFC 3714, March 2004.

    [RFC3819] P. Karn, C. Bormann, G. Fairhurst, D. Grossman, R. Ludwig,
    J. Mahdavi, G. Montenegro, J. Touch, and L. Wood, Advice for Internet
    Subnetwork Designers, RFC 3819, July 2004

    [RFC4340]  Kohler, E., Handley, M., and S. Floyd, Datagram
    Congestion Control Protocol (DCCP), RFC 4340, March 2006.

    [RFC4782] S. Floyd, M. Allman, A. Jain, and P. Sarolahti,
    Quick-Start for TCP and IP.  RFC 4782, Experimental, January

    [Tools] S. Floyd and E. Kohler, Tools for the Evaluation of
    Simulation and Testbed Scenarios, Internet-draft
    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

    Sally Floyd

Expires: October 2007                                           [Page 9]

draft-ietf-tsvwg-cc-alt-01.txt                                April 2007

    ICIR (ICSI Center for Internet Research)
    1947 Center Street, Suite 600
    Berkeley, CA 94704-1198
    Phone: +1 (510) 666-2989
    Email: floyd at

    Mark Allman
    ICSI Center for Internet Research
    1947 Center Street, Suite 600
    Berkeley, CA 94704-1198
    Phone: (440) 235-1792
    Email: mallman at

Intellectual Property Statement

    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

    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

Disclaimer of Validity

    This document and the information contained herein are provided on

Copyright Statement

    Copyright (C) The IETF Trust (2007).  This document is subject
    to the rights, licenses and restrictions contained in BCP 78, and

Expires: October 2007                                          [Page 10]

draft-ietf-tsvwg-cc-alt-01.txt                                April 2007

    except as set forth therein, the authors retain all their rights.


    Funding for the RFC Editor function is currently provided by the
    Internet Society.

Expires: October 2007                                          [Page 11]