[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 draft-floyd-tsvwg-cc-alt

Network Working Group                                           S. Floyd
Internet-Draft                                                 M. Allman
Expires: December 2006                                       ICIR / ICSI
                                                            October 2006


              Specifying New Congestion Control Algorithms
                       draft-floyd-cc-alt-00.txt

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.

    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.

Copyright Notice

    Copyright (C) The Internet Society (2006).

Abstract

    The IETF's standard congestion control schemes have been widely
    shown to be inadequate for various environments (e.g., high-speed or
    wireless networks).  Recent research has yielded many alternate
    congestion control schemes.  Using these new congestion control
    schemes in the global Internet has possible ramifications to both
    the network 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.

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

Expires: April 2007                                             [Page 1]

draft-floyd-cc-alt-00.txt                                   October 2006

    authors proposing alternate congestion control and for the IETF
    community when evaluating whether a proposal is appropriate for
    publication in the RFC series.

    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 is algorithms that are
    judged to be safe to deploy in the global Internet and further
    investigated in that environment.  The second class is algorithms
    that, while promising, are not deemed safe enough for deployment on
    the Internet, but are being specified to facilitate investigations
    via simulation and testbeds.

    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 even though it may not be unsafe
    for use.

    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 [QuickStart] 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 would 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.


Expires: April 2007                                             [Page 2]

draft-floyd-cc-alt-00.txt                                   October 2006

3.  Guidelines

    As noted above, authors are expected to do a well-rounded
    evaluations 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 and these guidelines should not be used as a
    check-list.

    (1) Fairness to Standard TCP, SCTP, and DCCP.

        In environments where standard congestion control is able to
        make reasonable use of the available bandwidth the proposed
        change should not significantly change this state.

        For instance, in a situation where each of N flows uses 1/N of
        the network capacity, a new congestion control scheme should not
        significantly deviate from this state.  For instance, a flow
        using an alternate congestion controller that took half the
        capacity and left each of the remaining N flows with 1/2N of the
        capacity would be suspect.

    (2) Using Spare Capacity.

        Similar to point (1), alternate congestion control algorithms
        may take up spare capacity in the network, but may not steal
        significant amounts of capacity from flows using currently
        standardized congestion control.

        For instance, consider the case where N flows cannot naturally
        use all the capacity and equally share one-third of the capacity
        (with each flow using 1/3N of the capacity).  A single flow
        using an alternate congestion control scheme could use the
        unused two-thirds of capacity.  However, the flow using
        alternate congestion control should not steal significant
        amounts of additional capacity from the N standard flows.

    (3) Difficult Environments.

        An assessment of proposed algorithms in difficult environments
        such as paths containing wireless links and paths with
        reverse-path congestion.  In addition, proposed algorithms
        should be evaluated in situations where the bottleneck has high
        and low levels of statistical multiplexing.

    (4) 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 and round-trip times.  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 extending the

Expires: April 2007                                             [Page 3]

draft-floyd-cc-alt-00.txt                                   October 2006

        investigation into areas where the proposal does not perform
        well.

    (5) Full Backoff.

        All alternate congestion control algorithms ultimately should
        include some notion of "full backoff".  That is, at some point
        the algorithm should 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 this "full backoff" comes into play will be
        algorithm-specific.  However, this requirement is crucial to
        protect the network in times of extreme congestion.

    (6) Fairness within the Alternate Congestion Control Algorithm.

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

    (7) 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
        along the path.

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

5.  IANA Considerations

    This document does not require any IANA action.

Acknowledgments

    Discussions with Lars Eggert and Aaron Falk seeded this document.
    This document also draws from [Metrics].

Normative References

Informative References

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

Expires: April 2007                                             [Page 4]

draft-floyd-cc-alt-00.txt                                   October 2006


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

    [Metrics]  S. Floyd, Metrics for the Evaluation of Congestion
    Control Mechanisms.  Internet-draft draft-irtf-tmrg-metrics-04,
    work in progress, August 2006.

    [QuickStart] S. Floyd, M. Allman, A. Jain, and P. Sarolahti,
    Quick-Start for TCP and IP.  Internet-draft
    draft-ietf-tsvwg-quickstart-07.txt, work in progress, October
    2006.  Approved for Experimental.

Authors' Addresses

    Sally Floyd
    Phone: +1 (510) 666-2989
    ICIR (ICSI Center for Internet Research)
    Email: floyd@icir.org
    URL: http://www.icir.org/floyd/

    Mark Allman
    ICSI Center for Internet Research
    1947 Center Street, Suite 600
    Berkeley, CA 94704-1198
    Phone: (440) 235-1792
    Email: mallman@icir.org
    URL: http://www.icir.org/mallman/

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

Disclaimer of Validity

Expires: April 2007                                             [Page 5]

draft-floyd-cc-alt-00.txt                                   October 2006


    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.

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.

Acknowledgment

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




































Expires: April 2007                                             [Page 6]


Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/