Skip to main content

TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant
draft-ietf-dccp-tfrc-voip-07

Revision differences

Document history

Date Rev. By Action
2006-12-24
07 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Juergen Quittek.
2006-12-20
07 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2006-12-18
07 Amy Vezza IESG state changed to Approved-announcement sent
2006-12-18
07 Amy Vezza IESG has approved the document
2006-12-18
07 Amy Vezza Closed "Approve" ballot
2006-12-18
07 Lars Eggert State Changes to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed by Lars Eggert
2006-12-18
07 Lars Eggert RFC Editor Note updated, good to go.
2006-12-15
07 Amy Vezza State Changes to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation by Amy Vezza
2006-12-15
07 (System) Removed from agenda for telechat - 2006-12-14
2006-12-14
07 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2006-12-14
07 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2006-12-14
07 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson
2006-12-14
07 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2006-12-14
07 Magnus Westerlund
[Ballot comment]
Section 3.

      If the
      TFRC implementation knows that the IP layer is using IPv6 instead
    …
[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.
2006-12-14
07 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2006-12-13
07 David Kessens [Ballot Position Update] New position, No Objection, has been recorded by David Kessens
2006-12-13
07 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2006-12-13
07 Ted Hardie
[Ballot comment]
The document says:

    There are many questions about how an adaptive application would use
    TFRC-SP that are beyond the …
[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.
2006-12-13
07 Ted Hardie [Ballot Position Update] New position, Yes, has been recorded by Ted Hardie
2006-12-13
07 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2006-12-12
07 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2006-12-12
07 Brian Carpenter [Ballot Position Update] New position, No Objection, has been recorded by Brian Carpenter
2006-12-12
07 Lars Eggert State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Lars Eggert
2006-12-12
07 Yoshiko Fong IANA Last Call Comment:

As described in the IANA Considerations section, we understand
this document to have NO IANA Actions.
2006-12-11
07 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2006-12-11
07 Russ Housley
[Ballot comment]
From the SecDir Review by Juergen Quittek:

  The Security Considerations section claims:
  >
  > There are no security considerations introduced …
[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?
2006-12-11
07 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2006-12-07
07 Lars Eggert Placed on agenda for telechat - 2006-12-14 by Lars Eggert
2006-12-07
07 Lars Eggert [Ballot Position Update] New position, Yes, has been recorded for Lars Eggert
2006-12-07
07 Lars Eggert Ballot has been issued by Lars Eggert
2006-12-07
07 Lars Eggert Created "Approve" ballot
2006-12-05
07 Samuel Weiler Request for Last Call review by SECDIR is assigned to Juergen Quittek
2006-12-05
07 Samuel Weiler Request for Last Call review by SECDIR is assigned to Juergen Quittek
2006-11-27
07 Amy Vezza Last call sent
2006-11-27
07 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2006-11-26
07 Lars Eggert [Note]: 'PROTO Document Shepherd: Gorry Fairhurst' added by Lars Eggert
2006-11-26
07 Lars Eggert State Changes to Last Call Requested from Publication Requested by Lars Eggert
2006-11-26
07 Lars Eggert Last Call was requested by Lars Eggert
2006-11-26
07 (System) Ballot writeup text was added
2006-11-26
07 (System) Last call text was added
2006-11-26
07 (System) Ballot approval text was added
2006-11-25
07 Dinara Suleymanova
PROTO Write-up

1) Have the chairs personally reviewed this version of the ID and do
    they believe this ID is sufficiently baked to …
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.
2006-11-25
07 Dinara Suleymanova State Changes to Publication Requested from AD is watching by Dinara Suleymanova
2006-11-22
07 (System) New version available: draft-ietf-dccp-tfrc-voip-07.txt
2006-10-26
07 (System) State Changes to AD is watching from Dead by system
2006-10-25
06 (System) New version available: draft-ietf-dccp-tfrc-voip-06.txt
2006-09-04
07 (System) State Changes to Dead from AD is watching by system
2006-09-04
07 (System) Document has expired
2006-03-23
07 Lars Eggert Shepherding AD has been changed to Lars Eggert from Allison Mankin
2006-03-23
07 Lars Eggert Draft Added by Lars Eggert in state AD is watching
2006-03-03
05 (System) New version available: draft-ietf-dccp-tfrc-voip-05.txt
2006-01-25
04 (System) New version available: draft-ietf-dccp-tfrc-voip-04.txt
2006-01-17
03 (System) New version available: draft-ietf-dccp-tfrc-voip-03.txt
2005-02-22
01 (System) New version available: draft-ietf-dccp-tfrc-voip-01.txt
2005-01-10
00 (System) New version available: draft-ietf-dccp-tfrc-voip-00.txt