TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant
RFC 4828

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    dccp mailing list <dccp@ietf.org>, 
    dccp chair <dccp-chairs@tools.ietf.org>
Subject: Document Action: 'TCP Friendly Rate Control (TFRC): the 
         Small-Packet (SP) Variant' to Experimental RFC 

The IESG has approved the following document:

- 'TCP Friendly Rate Control (TFRC): the Small-Packet (SP) Variant '
   <draft-ietf-dccp-tfrc-voip-08.txt> as an Experimental RFC

This document is the product of the Datagram Congestion Control Protocol 
Working Group. 

The IESG contact persons are Lars Eggert and Magnus Westerlund.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dccp-tfrc-voip-08.txt

Technical Summary
 
    This document proposes a mechanism for further experimentation, but
    not for widespread deployment at this time in the global Internet.

    TCP-Friendly Rate Control (TFRC) is a congestion control mechanism
    for unicast flows operating in a best-effort Internet environment
    [RFC3448]. TFRC was intended for applications that use a fixed
    packet size, and was designed to be reasonably fair when competing
    for bandwidth with TCP connections using the same packet size.  This
    document proposes TFRC-SP, a Small-Packet (SP) variant of TFRC, that
    is designed for applications that send small packets.  The design
    goal for TFRC-SP is to achieve the same bandwidth in bps (bits per
    second) as a TCP flow using packets of up to 1500 bytes.  TFRC-SP
    enforces a minimum interval of 10 ms between data packets, to
    prevent a single flow from sending small packets arbitrarily
    frequently.

    Flows using TFRC-SP compete reasonably fairly with large-packet TCP
    and TFRC flows in environments where large-packet flows and small-
    packet flows experience similar packet drop rates.  However, in
    environments where small-packet flows experience lower packet drop
    rates than large-packet flows (e.g., with Drop-Tail queues in units
    of bytes), TFRC-SP can receive considerably more than its share of
    the bandwidth. 

Working Group Summary
 
   This document is a chartered item of the DCCP WG. The document
   provides a description of an experimental method to provide congestion
   control that is based on TFRC, but is adapted to sources that transmit
   small fixed-sized packets at a fixed rate.

   The document also provides simulation results to demonstrate the
   fairness with other IETF-defined transport protocols and may serve as a

   basis for future congestion control methods.
 
Protocol Quality
 
   The document defines a new experimental algorithm.

   Further experimentation is required to understand the implications of
   implementation, its suitability to specific applications and the
   deployment within the general Internet.

   Gorry Fairhurst was the PROTO Document Shepherd and Lars Eggert
   has reviewed this document for the IESG.

Note to RFC Editor
 
Section 3 (feedback from Magnus):
OLD:
       If the
       TFRC implementation knows that the IP layer is using IPv6 instead
       of IPv4, then the connection using TFRC-SP MAY use an estimate of
       40 bytes instead of 60 bytes for H, for simplicity of
       implementation.

NEW:
       However, if the TFRC implementation knows that the IP layer is
       using IPv6 instead of IPv4, then the connection using TFRC-SP MAY
       still use the default estimate of 40 bytes for H instead of the
       actual size of 60 bytes, for simplicity of implementation.

Section 4.5.1 (from Miguel Garcia):
OLD:
    this environments, the sending rate in bytes per RTT is roughly 1.2
NEW:
    these environments, the sending rate in bytes per RTT is roughly 1.2
    ^^^^^

Section 4.5.3 (from Lars):
OLD:
    bytes (becauses the path MTU is known to be less than 576 bytes),
NEW:
    bytes (because the path MTU is known to be less than 576 bytes),
           ^^^^^^^

Section 12 (nit from Miguel Garcia):
OLD:
    for feedback on earlier versions of this draft.

NEW:
    for feedback on earlier versions of this document.
                                             ^^^^^^^^

Section 9 (from secdir review by Juergen Quittek):
OLD:
    There are no security considerations introduced in this document.

    General security considerations for TFRC are discussed in RFC 3448.
    The security considerations for TFRC include the need to protect
    against spoofed feedback, and the need for protection mechanisms to
    protect the congestion control mechanisms against incorrect
    information from the receiver.

    Security considerations for DCCP's Congestion Control ID 3, TFRC
    Congestion Control, are discussed in [RFC4342].  That document
    extensively discussed the mechanisms the sender can use to verify
    the information sent by the receiver.

NEW:
    There are no new security considerations introduced in this
    document.

    The issues of the fairness of TFRC-SP with standard TFRC and TCP in
    a range of environments, including those with byte-based queue
    management at the congested routers, are discussed extensively in
    the main body of this document.

    General security considerations for TFRC are discussed in RFC 3448.
    As with TFRC in RFC 3448, TFRC-SP is not a transport protocol in its
    own right, but a congestion control mechanism that is intended to be
    used in conjunction with a transport protocol.  Therefore security
    primarily needs to be considered in the context of a specific
    transport protocol and its authentication mechanisms.  As discussed
    for TFRC in RFC 3448, any transport protocol that uses TFRC-SP needs
    to protect against spoofed feedback, and to protect the congestion
    control mechanisms against incorrect information from the receiver.
    Again as discussed for TFRC in RFC 3448, we expect that protocols
    incorporating ECN with TFRC-SP will want to use the ECN nonce
    [RFC3540] to protect the sender from the accidental or malicious
    concealment of marked packets

    Security considerations for DCCP's Congestion Control ID 3, TFRC
    Congestion Control, the transport protocol that uses TFRC, are
    discussed in [RFC4342].  That document extensively discussed the
    mechanisms the sender can use to verify the information sent by the
    receiver, including the use of the ECN nonce.

Section (adding acknowledgements):
OLD:
    Eggert, Gorry Fairhurst, Mark Handley, Ladan Gharai, Richard Nelson,
    Colin Perkins, Pete Sholander, Magnus Westerlund, and Joerg Widmer
  
NEW:
    Eggert, Gorry Fairhurst, Mark Handley, Miguel Garcia, Ladan Gharai,
    Richard Nelson, Colin Perkins, Juergen Quittek, Pete Sholander,
    Magnus Westerlund, and Joerg Widmer


New Reference:
NEW:
     [RFC3540]      D. Wetherall, D. Ely, and N. Spring, Robust ECN
                    Signaling with Nonces, RFC 3540, Experimental, June
                    2003.