Skip to main content

TCP Friendly Rate Control (TFRC): Protocol Specification
RFC 5348

Revision differences

Document history

Date Rev. By Action
2020-01-21
06 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2018-12-20
06 (System)
Received changes through RFC Editor sync (changed abstract to 'This document specifies TCP Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast …
Received changes through RFC Editor sync (changed abstract to 'This document specifies TCP Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best-effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as streaming media where a relatively smooth sending rate is of importance.

This document obsoletes RFC 3448 and updates RFC 4342. [STANDARDS-TRACK]')
2017-05-16
06 (System) Changed document authors from "Jitendra Padhye, Sally Floyd, Joerg Widmer" to "Jitendra Padhye, Sally Floyd, Joerg Widmer, Mark Handley"
2016-11-30
06 (System) Closed request for Last Call review by SECDIR with state 'Unknown'
2015-10-14
06 (System) Notify list changed from dccp-chairs@ietf.org, draft-ietf-dccp-rfc3448bis@ietf.org to (None)
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2008-09-25
06 Cindy Morgan State Changes to RFC Published from RFC Ed Queue by Cindy Morgan
2008-09-25
06 Cindy Morgan [Note]: 'RFC 5348' added by Cindy Morgan
2008-09-25
06 (System) RFC published
2008-05-29
06 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2008-05-29
06 (System) IANA Action state changed to No IC from In Progress
2008-05-29
06 (System) IANA Action state changed to In Progress
2008-05-29
06 Cindy Morgan IESG state changed to Approved-announcement sent
2008-05-29
06 Cindy Morgan IESG has approved the document
2008-05-29
06 Cindy Morgan Closed "Approve" ballot
2008-05-23
06 (System) Removed from agenda for telechat - 2008-05-22
2008-05-22
06 Cindy Morgan State Changes to Approved-announcement to be sent from IESG Evaluation by Cindy Morgan
2008-05-22
06 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2008-05-22
06 Tim Polk
[Ballot comment]
I support Russ's discuss on the importance of a change summary.  Having diffed the
RFC and the ID, this appears to be a …
[Ballot comment]
I support Russ's discuss on the importance of a change summary.  Having diffed the
RFC and the ID, this appears to be a very significant revision covering many issues.
The change summary will help ensure readers find the appropriate changes.

It would be nice if the security considerations section was updated with some examples.
The document punts most security issues  to the "specific transport protocol and its
authentication mechanisms" and that is probably appropriate.  However, I would assume
that the details have been worked out for TCP since publication of 3448, and that
references to those solutions could easily be included.  That would be helpful in my opinion.
2008-05-22
06 Tim Polk
[Ballot comment]
I support Russ's discuss on the importance of a change summary.  Having diffed the
RFC and the ID, this appears to be a …
[Ballot comment]
I support Russ's discuss on the importance of a change summary.  Having diffed the
RFC and the ID, this appears to be a very significant revision covering many issues.
The change summary will help ensure readers find the appropriate changes.

It would be nice if the security considerations section was updated with some examples.
The document punts most security issues  to the "specific transport protocol and its authentication mechanisms" and that is probably appropriate.  However, I would assume
that the details have been worked out for TCP and that references to those solutions
could easily be included.  That would be helpful in my opinion.
2008-05-22
06 Tim Polk
[Ballot comment]
I support Russ's discuss on the importance of a change summary.  Having diffed the
RFC and the ID, this appears to be a …
[Ballot comment]
I support Russ's discuss on the importance of a change summary.  Having diffed the
RFC and the ID, this appears to be a very significant revision covering many issues.
The change summary will help ensure readers find the appropriate changes.

It would be nice if the security considerations section was updated with some examples.
The document punts most security issues  to the "specific transport protocol and its authentication mechanisms" and that is probably appropriate.  However, I would assume
that the details have been worked out for TCP and that references to those solutions
could easily be included.  That would be helpful in my opinion.
2008-05-22
06 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk
2008-05-22
06 Tim Polk
[Ballot comment]
I support Russ's discuss on the importance of a change summary.  Having diffed the
RFC and the ID, this appears to be a …
[Ballot comment]
I support Russ's discuss on the importance of a change summary.  Having diffed the
RFC and the ID, this appears to be a very significant revision covering many issues.
The change summary will help ensure readers find the appropriate changes.
2008-05-22
06 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to Yes from No Objection by Magnus Westerlund
2008-05-22
06 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2008-05-22
06 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2008-05-22
06 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson
2008-05-21
06 Chris Newman [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman
2008-05-21
06 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2008-05-21
06 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2008-05-21
06 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2008-05-21
06 Russ Housley
[Ballot discuss]
I agree that the detailed change history should not be included in
  the final RFC; however, it is very helpful to include …
[Ballot discuss]
I agree that the detailed change history should not be included in
  the final RFC; however, it is very helpful to include a summary of
  the changes since RFC 3448, which is obsoleted by this document once
  it is approved.  Another appendix would be a fine solution.
2008-05-21
06 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2008-05-20
06 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2008-05-20
06 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2008-05-19
06 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2008-05-19
06 Pasi Eronen [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen
2008-05-17
06 Lars Eggert Placed on agenda for telechat - 2008-05-22 by Lars Eggert
2008-05-17
06 Lars Eggert [Ballot Position Update] New position, Yes, has been recorded for Lars Eggert
2008-05-17
06 Lars Eggert Ballot has been issued by Lars Eggert
2008-05-17
06 Lars Eggert Created "Approve" ballot
2008-05-17
06 Lars Eggert State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Lars Eggert
2008-05-16
06 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2008-05-09
06 Amanda Baber IANA Last Call comments:

As described in the IANA Considerations section, we understand this document
to have NO IANA Actions.
2008-05-02
06 Samuel Weiler Request for Last Call review by SECDIR is assigned to Blake Ramsdell
2008-05-02
06 Samuel Weiler Request for Last Call review by SECDIR is assigned to Blake Ramsdell
2008-05-02
06 Cindy Morgan Last call sent
2008-05-02
06 Cindy Morgan State Changes to In Last Call from Last Call Requested by Cindy Morgan
2008-05-02
06 Lars Eggert [Note]: 'Document shepherd: Gorry Fairhurst (gorry@erg.abdn.ac.uk).' added by Lars Eggert
2008-05-02
06 Lars Eggert [Note]: 'The document shepherd is G. Fairhurst, DCCP WG Chair.' added by Lars Eggert
2008-05-02
06 Lars Eggert State Change Notice email list have been change to dccp-chairs@tools.ietf.org, draft-ietf-dccp-rfc3448bis@tools.ietf.org from dccp-chairs@tools.ietf.org
2008-05-02
06 Lars Eggert State Changes to Last Call Requested from AD Evaluation by Lars Eggert
2008-05-02
06 Lars Eggert Last Call was requested by Lars Eggert
2008-05-02
06 (System) Ballot writeup text was added
2008-05-02
06 (System) Last call text was added
2008-05-02
06 (System) Ballot approval text was added
2008-05-02
06 Lars Eggert State Changes to AD Evaluation from Publication Requested by Lars Eggert
2008-05-02
06 Lars Eggert AD review performed during WGLC.
2008-05-01
06 Cindy Morgan State Changes to Publication Requested from AD is watching by Cindy Morgan
2008-05-01
06 Cindy Morgan
    (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of …
    (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

I have read this document and I think this is ready for publication.
The document shepherd is G. Fairhurst, DCCP WG Chair.

    (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

Yes, the document was reviewed in a WGLC 27-Feb-08 to 21-Mar-08
(extended because this covered the period surrounding an IETF meeting).

The WGLC revealed a set of issues, which have been addressed in this
revision of the draft. There were no objections to publishing this
as a standards-track replacement for RFC 3448.

    (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

No.

    (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

This is a revised version of RFC 3448. The algorithms presented are
complex. They are believed to be safe for use in the general Internet.

I am certain this is a considerable improvement in clarity than provided
in RFC 3448, although there is some scope for rewriting this in future
to improve the document, this would be a significant task. I can not
currently WG see energy to undertake this, nor is there the needed
implementation and operational experience to support this at this time.


    (1.e)  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?

This document had the support of the IETF DCCP WG.

    (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No.

    (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

Yes.

    (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

The references have been verified.

    (1.i)  Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

There are no IANA actions required for this document.

    (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

Not appropriate.

    (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up?  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary
              Relevant content can frequently be found in the abstract
              and/or introduction of the document.  If not, this may be
              an indication that there are deficiencies in the abstract
              or introduction.

This document is a product of the DCCP WG in the IETF Transport Area.
It specifies the TCP-Friendly Rate Control (TFRC) algorithm.  TFRC is a
congestion control mechanism for unicast flows operating in a best-
effort Internet environment.  It is reasonably fair when competing
for bandwidth with TCP flows, but has a much lower variation of
throughput over time compared with TCP, making it more suitable for
applications such as streaming media where a relatively smooth
sending rate is of importance.

If published, this document will obsolete RFC 3448 and update RFC 4342.

          Working Group Summary
              Was there anything in WG process that is worth noting?  For
              example, was there controversy about particular points or
              were there decisions where the consensus was particularly
              rough?

This document corrects and updated RFC 3448 (including addressing issues
noted in the RFC3448 Errata). It includes a set of other issues arising
from simulation of RFC 3448, implementation, and use by applications.
It also includes significant restructuring and editorial work to improve
the readability. Because of the significant changes in this revised spec,
the WG agreed this document should not be used as a request TFRC to
progress along the Standards Track.

          Document Quality
              Are there existing implementations of the protocol?  Have a
              significant number of vendors indicated their plan to
              implement the specification?  Are there any reviewers that
              merit special mention as having done a thorough review,
              e.g., one that resulted in important changes or a
              conclusion that the document had no substantive issues?  If
              there was a MIB Doctor, Media Type or other expert review,
              what was its course (briefly)?  In the case of a Media Type
              review, on what date was the request posted?

The DCCP WG has reached consensus that this document is ready for
publication, and recommends publication on the IETF Standards Track. It
was not possible to contact the full set of authors in the period
leading up to the WGLC (a separate note has been sent to the ADs).

The document specifies an algorithm, rather than a protocol.
There are currently therefore no full implementations of this new
specification. However, some parts of this have been implemented
widely (based on RFC 3448 and its updates) and several implementaters
have used this as the basis for their implementation / simulation in
the context of DCCP CCID-3 (RFC4342) . Several of these people provided
feedback (before and at WGLC) that have resulted in changes being made
to the spec. There have been no reported interoperability tests.

The WG decided that this document should also update the algorithm
specified for TFRC in RFC 4342. This topic was first raised at IETF-68.
The proposal to update RFC 4342 was confirmed at IETF-71.

  (end)
2008-04-12
06 (System) New version available: draft-ietf-dccp-rfc3448bis-06.txt
2008-02-25
05 (System) New version available: draft-ietf-dccp-rfc3448bis-05.txt
2008-01-25
04 (System) New version available: draft-ietf-dccp-rfc3448bis-04.txt
2007-11-19
03 (System) New version available: draft-ietf-dccp-rfc3448bis-03.txt
2007-07-10
02 (System) New version available: draft-ietf-dccp-rfc3448bis-02.txt
2007-03-07
01 (System) New version available: draft-ietf-dccp-rfc3448bis-01.txt
2006-10-17
06 Lars Eggert Draft Added by Lars Eggert in state AD is watching
2006-10-16
00 (System) New version available: draft-ietf-dccp-rfc3448bis-00.txt