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

Versions: 00 draft-floyd-dccp-ccid4

Internet Engineering Task Force                              Sally Floyd
INTERNET-DRAFT                                                      ICIR
draft-floyd-ccid4-00.txt                                    Eddie Kohler
Expires: 18 December 2006                                           UCLA
                                                            18 June 2006


               Profile for DCCP Congestion Control ID 4:
                      the Small-Packet Variant of
                        TFRC Congestion Control


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.

    This Internet-Draft will expire on 18 December 2006.

Abstract

    This document contains the profile for Congestion Control Identifier
    4, the Small-Packet variant of TCP-Friendly Rate Control (TFRC), in
    the Datagram Congestion Control Protocol (DCCP).  CCID 4 is for
    experimental use, and uses TFRC-SP [TFRC-SP], a Small-Packet (SP)
    variant of TFRC designed for applications that send small packets.
    The goal for TFRC-SP is to achieve roughly the same bandwidth in



Floyd/Kohler                                                    [Page 1]

INTERNET-DRAFT          Expires: 18 December 2006              June 2006


    bits per second (bps) as a TCP flow using packets of up to 1500
    bytes but experiencing the same level of congestion.  CCID 4 is for
    experimental use for senders that send small packets and would like
    a TCP-friendly sending rate, possibly with Explicit Congestion
    Notification (ECN), while minimizing abrupt rate changes.














































Floyd/Kohler                                                    [Page 2]

INTERNET-DRAFT          Expires: 18 December 2006              June 2006


Table of Contents

    1. Introduction ...................................................5
    2. Conventions ....................................................5
    3. Usage ..........................................................6
       3.1. Relationship with TFRC ....................................6
       3.2. Example Half-Connection ...................................6
    4. Connection Establishment .......................................7
    5. Congestion Control on Data Packets .............................7
       5.1. Response to Idle and Application-limited Periods ..........8
       5.2. Response to Data Dropped and Slow Receiver ................8
       5.3. Packet Sizes ..............................................9
    6. Acknowledgements ...............................................9
       6.1. Loss Interval Definition ..................................9
            6.1.1. Loss Interval Lengths ..............................9
       6.2. Congestion Control on Acknowledgements ....................9
       6.3. Acknowledgements of Acknowledgements ......................9
       6.4. Quiescence ................................................9
    7. Explicit Congestion Notification ...............................9
    8. Options and Features ..........................................10
       8.1. Window Counter Value .....................................10
       8.2. Elapsed Time Options .....................................11
       8.3. Receive Rate Option ......................................11
       8.4. Send Loss Event Rate Feature .............................11
       8.5. Loss Event Rate Option ...................................11
       8.6. Loss Intervals Option ....................................11
            8.6.1. Option Details ....................................12
    9. Verifying Congestion Control Compliance With ECN ..............13
       9.1. Verifying the ECN Nonce Echo .............................13
       9.2. Verifying the Reported Loss Intervals and Loss Event Rate
       ...............................................................13
    10. Implementation Issues ........................................13
       10.1. Timestamp Usage .........................................13
       10.2. Determining Loss Events at the Receiver .................13
       10.3. Sending Feedback Packets ................................13
    11. Security Considerations ......................................13
    12. IANA Considerations ..........................................13
       12.1. Reset Codes .............................................14
       12.2. Option Types ............................................14
       12.3. Feature Numbers .........................................14
    13. Thanks .......................................................15
    Normative References .............................................15
    Informative References ...........................................15
    Authors' Addresses ...............................................15
    Full Copyright Statement .........................................16
    Intellectual Property ............................................16





Floyd/Kohler                                                    [Page 3]

INTERNET-DRAFT          Expires: 18 December 2006              June 2006


List of Tables

    Table 1: DCCP CCID 4 Options .....................................10
    Table 2: DCCP CCID 4 Feature Numbers .............................10















































Floyd/Kohler                                                    [Page 4]

INTERNET-DRAFT          Expires: 18 December 2006              June 2006


1.  Introduction

    This document contains the profile for Congestion Control Identifier
    4, the Small-Packet variant of TCP-friendly rate control (TFRC), in
    the Datagram Congestion Control Protocol (DCCP) [RFC 4340].  CCID 4
    differs from CCID 3 in that CCID 4 uses TFRC-PS, while CCID 3 [RFC
    4342] uses standard TFRC [RFC 3448].  This document assumes that the
    reader is familiar with [RFC 4342], instead of repeating from that
    document unnecessarily.

    CCID 4 differs from CCID 3 only in the following respects:

    o  Header size: For TFRC-SP, the allowed transmit rate in bytes per
       second is reduced by a factor that accounts for packet header
       size.  This is specified for TFRC-SP in Section 4.2 of [TFRC-SP],
       and described for CCID 4 in Section 5 below.

    o  Minimum sending rate: TFRC-SP enforces a minimum interval of 10
       ms. between data packets.  This is specified for TFRC-SP in
       Section 4.3 of [TFRC-SP], and described for CCID 4 in Section 5
       below.

    o  Loss rates for short loss intervals: For short lost intervals of
       at most two round-trip times, the loss rate is computed by
       counting the actual number of packets lost or marked.  For such a
       short loss interval with N data packets, including K lost or
       marked data packets, the loss interval length is calculated as
       N/K, instead of as N.  This is specified for TFRC-SP in Section
       4.4 of [TFRC-SP]. The addition of a Dropped Packets field to
       CCID 4's Loss Intervals Option is specified in 8.6 below, and its
       use in calculating the loss event rate is specified in 8.6 below.
       The computation of the loss rate by the receiver for the Loss
       Event Rate option is described for CCID 4 in Section 8.4 below.

    o  The nominal segment size: In TFRC-SP, the nominal segment size
       used by the TCP throughput equation is set to 1460 bytes.  This
       is specified for TFRC-SP in Section 4.5 of RFC 3448, and
       described for CCID 4 in Section 5 below.

2.  Conventions

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in [RFC 2119].

    Additional terminology is described in Section 2 of [RFC 4342].





Floyd/Kohler                                        Section 2.  [Page 5]

INTERNET-DRAFT          Expires: 18 December 2006              June 2006


3.  Usage

    Like CCID 3, CCID 4's congestion control is appropriate for flows
    that would prefer to minimize abrupt changes in the sending rate,
    including streaming media applications with small or moderate
    receiver buffering before playback.

    CCID 4 is designed to be used either by applications that use a
    small fixed segment size, or by applications that change their
    sending rate by varying the segment size.  If CCID 4 is used by an
    application that varies its segment size in response to changes in
    the allowed sending rate in bps, we note that CCID 4 doesn't dictate
    the segment size to be used by the application; this is done by the
    application itself.  The CCID 4 sender determines the allowed
    sending rate in bps, in response to on-going feedback from the
    CCID 4 receiver, and the application can use information about the
    current allowed sending rate to decide whether to change the current
    segment size.

    We note that in some environments there will be a feedback loop,
    with changes in the packet size or in the sending rate in bps
    affecting congestion along the path, therefore affecting the allowed
    sending rate in the future.

3.1.  Relationship with TFRC

    The congestion control mechanisms described here follow the TFRC-SP
    mechanism specified in [TFRC-SP].  As with CCID 3, conformant CCID 4
    implementations MAY track updates to the TCP throughput equation
    directly, as updates are standardized in the IETF, rather than
    waiting for revisions of this document.  However, conformant
    implementations SHOULD wait for explicit updates to CCID 4 before
    implementing other changes to TFRC congestion control.

3.2.  Example Half-Connection

    This example shows the typical progress of a half-connection using
    CCID 4's TFRC Congestion Control, not including connection
    initiation and termination.  The example is informative, not
    normative.  This example differs from that for CCID 3 in [RFC 4342]
    only in that the allowed transmit rate is determined by [TFRC-SP] as
    well as by [RFC 3448].

    1.  The sender transmits DCCP-Data packets, where the sending rate
        is governed by the allowed transmit rate as specified in [TFRC-
        SP].  Each DCCP-Data packet has a sequence number, and the DCCP
        header's CCVal field contains the window counter value, used by
        the receiver in determining when multiple losses belong in a



Floyd/Kohler                                      Section 3.2.  [Page 6]

INTERNET-DRAFT          Expires: 18 December 2006              June 2006


        single loss event.

        In the typical case of an ECN-capable half-connection, each
        DCCP-Data and DCCP-DataAck packet is sent as ECN-Capable, with
        either the ECT(0) or the ECT(1) codepoint set.  The use of the
        ECN Nonce with TFRC is described in Section 9.

    2.  The receiver sends DCCP-Ack packets at least once per round-trip
        time acknowledging the data packets, unless the sender is
        sending at a rate of less than one packet per round-trip time,
        as indicated by the TFRC specification [RFC 3448] (Section 6).
        Each DCCP-Ack packet uses a sequence number, identifies the most
        recent packet received from the sender, and includes feedback
        about the recent loss intervals experienced by the receiver.

    3.  The sender continues sending DCCP-Data packets as controlled by
        the allowed transmit rate.  Upon receiving DCCP-Ack packets, the
        sender updates its allowed transmit rate as specified in [RFC
        3448] (Section 4.3)  and [TFRC-SP].  This update is based upon a
        loss event rate calculated by the sender, based on the
        receiver's loss intervals feedback.  If it prefers, the sender
        can also use a loss event rate calculated and reported by the
        receiver.

    4.  The sender estimates round-trip times and calculates a
        nofeedback time, as specified in [RFC 3448] (Section 4.4).  If
        no feedback is received from the receiver in that time (at least
        four round-trip times), the sender halves its sending rate.

4.  Connection Establishment

    The connection establishment is as specified in Section 4 of [RFC
    4342].

5.  Congestion Control on Data Packets

    CCID 4 uses the congestion control mechanisms of TFRC [RFC 3448] and
    TFRC-SP [TFRC-SP].  [TFRC-SP] should be considered normative except
    where specifically indicated.

    Loss Event Rate

    As with CCID 3, the basic operation of CCID 4 centers around the
    calculation of a loss event rate: the number of loss events as a
    fraction of the number of packets transmitted, weighted over the
    last several loss intervals.  For CCID 4, this loss event rate, a
    round-trip time estimate, and a nominal packet size of 1460 bytes
    are plugged into the TCP throughput equation, as specified in



Floyd/Kohler                                        Section 5.  [Page 7]

INTERNET-DRAFT          Expires: 18 December 2006              June 2006


    RFC 3448 (Section 3.1) and [TFRC-SP].

    Because CCID 4 is intended for applications that send small packets,
    the allowed transmit rate derived from the TCP throughput equation
    is reduced by a factor that accounts for packet header size, as
    specified in Section 4.2 of [TFRC-SP].  The header size on data
    packets is estimated as 32 bytes (20 bytes for the IP header, and 12
    bytes for the DCCP-Data header with 24-bit sequence numbers).  If
    the DCCP sender is sending N-byte data packets, the allowed transmit
    rate is reduced by N/(N+32).  CCID 4 senders are limited to this
    fair rate.

    The loss event rate itself is calculated in CCID 4 using recent loss
    interval lengths reported by the receiver.  Loss intervals are
    precisely defined in Section 6.1 of [RFC 4342],  with the
    modification in [TFRC-SP] (Section 3) for loss intervals of at most
    two round-trip times.  In summary, a loss interval is up to 1 RTT of
    possibly lost or ECN-marked data packets, followed by an arbitrary
    number of non-dropped, non-marked data packets.  The CCID 4 Loss
    Intervals option is used to report loss interval lengths; see
    Section 8.6.

    For loss intervals of at most two round-trip times, CCID 4
    calculates the loss event rate for that interval by counting the
    number of packets lost or marked, as described in Section 4.4 of
    [TFRC-SP].  Thus, for such a short loss interval with N data
    packets, including K lost or marked data packets, the loss interval
    length is calculated as N/K, instead as N.

    Unlike CCID 3, the CCID 4 sender enforces a minimum interval of 10
    ms. between data packets, regardless of the allowed transmit rate.

    Other Congestion Control Mechanisms

    The other congestion control mechanisms such as slow-start, feedback
    packets, and the like are exactly as in CCID 3, and are described in
    the subsection on "Other Congestion Control Mechanisms" of Section 5
    in [RFC 4342].

5.1.  Response to Idle and Application-limited Periods

    This is described in Section 5.1 of [RFC 4342].

5.2.  Response to Data Dropped and Slow Receiver

    This is described in Section 5.2 of [RFC 4342].





Floyd/Kohler                                      Section 5.2.  [Page 8]

INTERNET-DRAFT          Expires: 18 December 2006              June 2006


5.3.  Packet Sizes

    CCID 4 is intended for applications that use a fixed small segment
    size, or that vary their segment size in response to congestion.

    The CCID 4 sender uses a segment size of 1460 bytes in the TCP
    throughput equation.  This gives the CCID 4 sender roughly the same
    sending rate in bytes per second as a TFRC flow using 1460-byte
    segments but experiencing the same packet drop rate.

6.  Acknowledgements

    The acknowledgements are as specified in Section 6 of [RFC 4342]
    with the exception of the Loss Interval lengths specified below.

6.1.  Loss Interval Definition

    The loss interval definition is as defined in Section 6.1 of [RFC
    4342].

6.1.1.  Loss Interval Lengths

    The Loss Intervals option specified for CCID 3 in [RFC 4342] reports
    three lengths for each loss interval, the lengths of the lossy and
    lossless parts, and a separate data length; the data length is used
    in TFRC's loss event rate calculation.  The Loss Intervals option
    specified in this document for CCID 4 includes an additional Dropped
    Packets field, described below in Section 8.6.

6.2.  Congestion Control on Acknowledgements

    The congestion control on acknowledgements is as specified in
    Section 6.2 of [RFC 4342].

6.3.  Acknowledgements of Acknowledgements

    Procedures for the acknowledgement of acknowledgements are as
    specified in Section 6.3 of [RFC 4342].

6.4.  Quiescence

    The procedure for detecting that the sender has gone quiescent is as
    specified in Section 6.4 of [RFC 4342].

7.  Explicit Congestion Notification

    Procedures for the use of Explicit Congestion Notification (ECN) are
    as specified in Section 7 of [RFC 4342].



Floyd/Kohler                                        Section 7.  [Page 9]

INTERNET-DRAFT          Expires: 18 December 2006              June 2006


8.  Options and Features

    CCID 4 can make use of DCCP's Ack Vector, Timestamp, Timestamp Echo,
    and Elapsed Time options, and its Send Ack Vector and ECN Incapable
    features.  As with CCID 3, the following CCID-specific options
    defined for use with CCID 4.

                   Option                        DCCP-   Section
          Type     Length     Meaning            Data?  Reference
          -----    ------     -------            -----  ---------
         128-191              Reserved
           192        6       Loss Event Rate      N      8.5
           193     variable   Loss Intervals       N      8.6
           194        6       Receive Rate         N      8.3
         195-255              Reserved

                       Table 1: DCCP CCID 4 Options

    The "DCCP-Data?" column indicates that all currently defined
    CCID 4-specific options MUST be ignored when they occur on DCCP-Data
    packets.

    As with CCID 3, the following CCID-specific feature is also defined.

                                        Rec'n Initial        Section
      Number   Meaning                  Rule   Value  Req'd Reference
      ------   -------                  -----  -----  ----- ---------
      128-191  Reserved
        192    Send Loss Event Rate      SP      0      N      8.4
      193-255  Reserved

                   Table 2: DCCP CCID 4 Feature Numbers

    More information is available in Section 8 of [RFC 4342].

8.1.  Window Counter Value

    The use of the Window Counter Value in the DCCP generic header's
    CCVal field is as specified in Section 8.1 of [RFC 4342].

    In addition to their use described in CCID 3, the CCVal counters are
    used by the receiver in CCID 4 to determine when the length of a
    loss interval is at most two round-trip times.  None of these
    procedures require the receiver to maintain an explicit estimate of
    the round-trip time.  However, Section 8.1 of [RFC 4342] gives a
    procedure that implementors may use if they wish to keep such an RTT
    estimate using CCVal.




Floyd/Kohler                                     Section 8.1.  [Page 10]

INTERNET-DRAFT          Expires: 18 December 2006              June 2006


8.2.  Elapsed Time Options

    The use of the Elapsed Time option is defined in Section 8.2 of [RFC
    4342].

8.3.  Receive Rate Option

    The Receive Rate Option is as specified in Section 8.3 of [RFC
    4342].

8.4.  Send Loss Event Rate Feature

    The Send Loss Event Rate feature is as defined in Section 8.4 of
    [RFC 4342].

    See [RFC 3448], Section 5 and [TFRC-SP], Section 4.4 for a normative
    calculation of the loss event rate.  Section 4.4 of [TFRC-SP]
    modifies the calculation of the loss interval size for loss
    intervals of at most two round-trip times.

    If the CCID 4 receiver is using the Loss Event Rate option, the
    receiver needs to be able to determine if a loss interval is short,
    of at most two round-trip times.  The receiver can heuristically
    detect a short loss interval by using the Window Counter in arriving
    data packets.  The sender increases the Window Counter by 1 every
    quarter of a round-trip time, with the caveat that the Window
    Counter is never increased by more than five, modulo 16, from one
    data packet to the next.  Using the Window Counter to detect loss
    intervals of at most two round-trip times could result in some false
    positives, with some longer loss intervals incorrectly identified as
    short ones.

8.5.  Loss Event Rate Option

    The Loss Event Rate Option is as specified in Section 8.5 of [RFC
    4342].

    See [RFC 3448] (Section 5) and [TFRC-SP] for a normative calculation
    of loss event rate.

8.6.  Loss Intervals Option

    In CCID 3, each Loss Interval reported in the Loss Intervals Option
    includes a Lossless Length, Loss Length, and Data Length.  The Data
    Length is used in the calculation of the loss event rate, and the
    Lossless Length is used for the ECN Nonce Echo.  In CCID 4, each
    Loss Interval includes an additional 3-byte field, the Dropped
    Packets field.



Floyd/Kohler                                     Section 8.6.  [Page 11]

INTERNET-DRAFT          Expires: 18 December 2006              June 2006


    +--------+--------+--------+--------...--------+--------+---
    |11000001| Length |  Skip  |   Loss Interval   | More Loss
    |        |        | Length |                   | Intervals...
    +--------+--------+--------+--------...--------+--------+---
     Type=193                         12 bytes

    For CCID 4, each 12-byte Loss Interval contains four fields, as
    follows:

      ____________________ Loss Interval _________________________
     /                                                            \
    +-------...-------+------...------+-----...-----+------...-----+
    | Lossless Length |E| Loss Length | Data Length | Dropped Pkts |
    +-------...-------+------...------+-----...-----+------...-----+
          3 bytes          3 bytes        3 bytes        3 bytes

    The receiver reports its observed loss intervals using a Loss
    Intervals option.  Section 6.1 defines loss intervals.  This option
    MUST be sent by the data receiver on all required acknowledgements.
    The option reports up to 21 loss intervals seen by the receiver
    (although TFRC currently uses at most the latest 9 of these).  This
    lets the sender calculate a loss event rate and probabilistically
    verify the receiver's ECN Nonce Echo.

    The Loss Intervals option serves several purposes, as described in
    Section 8.6 of [RFC 4342].

    Loss Intervals options MUST NOT be sent on DCCP-Data packets, and
    any Loss Intervals options on received DCCP-Data packets MUST be
    ignored.

8.6.1.  Option Details

    The details for the use of the Loss Intervals Option are as
    described in Section 8.6.1 of [RFC 4342], with the exception of the
    added field for Dropped Packets.

    Dropped Packets: Dropped Packets, a 24-bit number, specifies the
    number of dropped or marked packets in the loss interval.  For Loss
    Intervals of at most two round-trip times, the Dropped Packets field
    MUST report the receiver's estimate of the number of dropped or
    marked data packets in that loss interval.  For Loss Intervals
    greater than two round-trip times, the Dropped Packets field MAY
    instead be set to zero.







Floyd/Kohler                                   Section 8.6.1.  [Page 12]

INTERNET-DRAFT          Expires: 18 December 2006              June 2006


9.  Verifying Congestion Control Compliance With ECN

    Verifying congestion control compliance with ECN is as discussed in
    Section 9 of [RFC 4342].

9.1.  Verifying the ECN Nonce Echo

    Procedures for verifying the ECN Nonce Echo are as specified in
    Section 9.1 of [RFC 4342].

9.2.  Verifying the Reported Loss Intervals and Loss Event Rate

    Section 9.2 of [RFC 4342] discusses the sender's possible
    verification of loss intervals and loss event rate information
    reported by the receiver.

10.  Implementation Issues

10.1.  Timestamp Usage

    The use of the Timestamp option is as discussed in Section 10.1 of
    [RFC 4342].

10.2.  Determining Loss Events at the Receiver

    The use of the window counter by the receiver to determine if
    multiple lost packets belong to the same loss event is as described
    in Section 10.2 of [RFC 4342].

10.3.  Sending Feedback Packets

    The procedure for sending feedback packets is as described in
    Section 10.3 of [RFC 4342].


11.  Security Considerations

    Security considerations include those discussed in Section 11 of
    [RFC 4342]. There are no new security considerations introduced by
    CCID 4.

12.  IANA Considerations

    This specification defines the value 4 in the DCCP CCID namespace
    managed by IANA.

    CCID 4 also uses three sets of numbers whose values should be
    allocated by IANA, namely CCID 4-specific Reset Codes, option types,



Floyd/Kohler                                      Section 12.  [Page 13]

INTERNET-DRAFT          Expires: 18 December 2006              June 2006


    and feature numbers.  This document makes no particular allocations
    from the Reset Code range, except for experimental and testing use
    [RFC 3692].  We refer to the Standards Action policy outlined in
    [RFC 2434].

12.1.  Reset Codes

    Each entry in the DCCP CCID 4 Reset Code registry contains a
    CCID 4-specific Reset Code, which is a number in the range 128-255;
    a short description of the Reset Code; and a reference to the RFC
    defining the Reset Code.  Reset Codes 184-190 and 248-254 are
    permanently reserved for experimental and testing use.  The
    remaining Reset Codes -- 128-183, 191-247, and 255 -- are currently
    reserved, and should be allocated with the Standards Action policy,
    which requires IESG review and approval and standards-track IETF RFC
    publication.

12.2.  Option Types

    Each entry in the DCCP CCID 4 option type registry contains a
    CCID 4-specific option type, which is a number in the range 128-255;
    the name of the option, such as "Loss Intervals"; and a reference to
    the RFC defining the option type.  The registry is initially
    populated using the values in Table 1, in Section 8.  This document
    allocates option types 192-194, and option types 184-190 and 248-254
    are permanently reserved for experimental and testing use.  The
    remaining option types -- 128-183, 191, 195-247, and 255 -- are
    currently reserved, and should be allocated with the Standards
    Action policy, which requires IESG review and approval and
    standards-track IETF RFC publication.

12.3.  Feature Numbers

    Each entry in the DCCP CCID 4 feature number registry contains a
    CCID 4-specific feature number, which is a number in the range
    128-255; the name of the feature, such as "Send Loss Event Rate";
    and a reference to the RFC defining the feature number.  The
    registry is initially populated using the values in Table 2, in
    Section 8.  This document allocates feature number 192, and feature
    numbers 184-190 and 248-254 are permanently reserved for
    experimental and testing use.  The remaining feature numbers --
    128-183, 191, 193-247, and 255 -- are currently reserved, and should
    be allocated with the Standards Action policy, which requires IESG
    review and approval and standards-track IETF RFC publication.







Floyd/Kohler                                    Section 12.3.  [Page 14]

INTERNET-DRAFT          Expires: 18 December 2006              June 2006


13.  Thanks


Normative References

     [RFC 2119]     S. Bradner. Key Words For Use in RFCs to Indicate
                    Requirement Levels. RFC 2119.

     [RFC 2434]     T. Narten and H. Alvestrand.  Guidelines for Writing
                    an IANA Considerations Section in RFCs.  RFC 2434.

     [RFC 3448]     M. Handley, S. Floyd, J. Padhye, and J. Widmer, TCP
                    Friendly Rate Control (TFRC): Protocol
                    Specification, RFC 3448, Proposed Standard, January
                    2003.

     [RFC 3692]     T. Narten.  Assigning Experimental and Testing
                    Numbers Considered Useful.  RFC 3692.

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

     [RFC 4342]     Floyd, S., Kohler, E., and J. Padhye.  Profile for
                    Datagram Congestion Control Protocol (DCCP)
                    Congestion Control ID 3: TCP-Friendly Rate Control
                    (TFRC), RFC 4342, March 2006.

     [TFRC-SP]      S. Floyd and E. Kohler.  TCP Friendly Rate Control
                    (TFRC): the Small-Packet (SP) Variant.  Internet-
                    draft draft-ietf-dccp-tfrc-voip-05.txt, March 2005.

Informative References

Authors' Addresses

    Sally Floyd <floyd@icir.org>
    ICSI Center for Internet Research
    1947 Center Street, Suite 600
    Berkeley, CA 94704
    USA

    Eddie Kohler <kohler@cs.ucla.edu>
    4531C Boelter Hall
    UCLA Computer Science Department
    Los Angeles, CA 90095
    USA




Floyd/Kohler                                                   [Page 15]

INTERNET-DRAFT          Expires: 18 December 2006              June 2006


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.














Floyd/Kohler                                                   [Page 16]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/