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

Received changes through RFC Editor sync (changed abstract to '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 (RFC 3448). 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. This memo defines an Experimental Protocol for the Internet community.')

[Ballot comment]
Section 3.

      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.

It seems the 60 and 40 values should change place in the above sentence.

[Ballot comment]
The document says:

    There are many questions about how an adaptive application would use
    TFRC-SP that are beyond the scope of this document.  In particular,
    an application might wish to avoid unnecessary reductions in the
    packet size.  In this case, an application might wait for some
    period of time before reducing the packet size, to avoid an
    unnecessary reduction in the packet size.  The details of how long
    an application might wait before reducing the packet size can be
    addressed in documents that are more application-specific.

I understand that these issues are beyond the scope of the document,
but I encourage the investigators looking at codec shifts as an example
of potential packet size changes to look at how FEC strategies associated
with specific codecs interact with this form of adaptation.

[Ballot comment]
From the SecDir Review by Juergen Quittek:

  The Security Considerations section claims:
  >
  > There are no security considerations introduced in this document.
  >
  I can live with this statement.  However, it does not seem to be fully
  consistent with the security considerations in RFC 3448 to which this
  document refers.  The security consideration in RFC 3448 also consider
  'attacks' against the fairness performed by a greedy receiver.
  Consequently, shouldn't this also be an issue here?

  The question that may be raised in this context is whether or not TFRC-SP
  makes attacks against fairness more effective.  A rogue sender could
  ignore the 10 ms Min Interval or ignore received feedback.  Would a
  rogue sender be able to get a bigger share of the bandwidth by
  choosing TFRC-SP instead of choosing another congestion control scheme
  such as TFRC?

PROTO Write-up

1) Have the chairs personally reviewed this version of the ID and do
    they believe this ID is sufficiently baked to forward to the IESG
    for publication?

Yes, and v06 includes responses to the WG Chair review and WG inputs following WGLC. v07 corrected language on PMTUD and small NiTs.
No outstanding items remain.


2) Has the document had adequate review from both key WG members and
    key non-WG members? Do you have any concerns about the depth or
    breadth of the reviews that have been performed?

The document is a result of contributions primarily by the authors, and many edit cycles inspired by WG feedback. WGLC was completed in March 2006. The document was announced as  completed WGLC at IETF 65, IETF 66, and IETF 66.

After a further WGLC, the WG now considers this ready for publication.
(No further comments were received by the list or the Chairs at IETF-66, comments were received in the final WGLC seeking clarification of meaning.)

There are likely to be further doubts on implementation, and deployment cases - but these are to be expected for an experimental spec.


3) Do you have concerns that the document needs more review from a
    particular (broader) perspective (e.g., security, operational
    complexity, someone familiar with AAA, etc.)?

No, this document has already been reviewed by people from the AVT WG, and most concerns remaining in the previous revision related to its suitability for particular applications, notably applicability of this profile for VoIP.

Revision v05 removed this concern, and resulted in a name change to not suggest this as "the" solution for VoIP.

4) Do you have any specific concerns/issues with this document that
    you believe the ADs and/or IESG should be aware of? For example,
    perhaps you are uncomfortable with certain parts of the document,
    or whether there really is a need for it, etc., but at the same
    time these issues have been discussed in the WG and the WG has
    indicated it wishes to advance the document anyway.

There was strong WG consensus that there was a need for work on this topic.

At IETF-65, there were discussions on fairness, based on ns-2 simulations, but no practical experience in real networks or with real applications. This solution seems safe compared to other IETF-defined transport protocols, and fair  (except in a few unusual cases of high loss, where TFRC itself is also sub-optimal).

In itself, this represents an experimental change to the way CC is thought about in the IETF.

Applicability of the methods and the way in which the techniques should be developed are not yet clear and further work is required to progress this. The WG therefore proposes publication of this document as a a useful reference for this work and a possible basis for new CC protocols (i.e. Experimental).

5) How solid is the WG consensus behind this document?  Does it
    represent the strong concurrence of a few individuals, with
    others being silent, or does the WG as a whole understand and agree
    with it?

The document has received feedback from many in the WG. There was no feedback suggesting that the document should not be published.

6) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarize what are they upset about.

No.

7) Have the chairs verified that the document adheres to _all_ of the
    ID nits?

Yes.

8) Please provide a draft write-up to appear in the ballot and
      approval announcement:

    - 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 (e.g. to be developed in the DCCP WG).

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

---

The questionnaire and writeup is sent to the ADs and iesg-secretary@ietf.org with a request to publish the document.

The publication request SHOULD also indicate which chair will be shepherding the document, so that this can be entered into the ID Tracker [IDTRACKER].  In addition to making life easier for the ADs, this lets the IETF chair know where to send Gen-ART [GEN-ART] reviews.