Skip to main content

TCP Friendly Rate Control (TFRC): Protocol Specification
draft-ietf-dccp-rfc3448bis-06

Approval announcement
Draft of message to be sent after approval:

Announcement

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: Protocol Action: 'TCP Friendly Rate Control (TFRC): 
         Protocol Specification' to Proposed Standard 

The IESG has approved the following document:

- 'TCP Friendly Rate Control (TFRC): Protocol Specification '
   <draft-ietf-dccp-rfc3448bis-07.txt> as a Proposed Standard

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-rfc3448bis-07.txt

Ballot Text

Technical Summary
 
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.
 
Working Group Summary
 
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.
 
Protocol Quality
 
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.

Personnel

Gorry Fairhurst (gorry@erg.abdn.ac.uk) was the Document Shepherd.
Lars Eggert (lars.eggert@nokia.com) reviewed the document for the IESG.

Note to RFC Editor
 
Add a new section 10.1 as follows:

   10.1.  Security Considerations for TFRC in DCCP

   TFRC is currently used in Congestion Control ID 3 (CCID 3) [RFC4342]
   of the Datagram Congestion Control Protocol (DCCP) [RFC4340].  The
   Security Considerations section of RFC 4340 [RFC4340] (Section 18)
   discusses some of the security issues of DCCP, including sequence
   number validity checks to protect against hijacked connections.
   Section 18 of RFC 4340 also discusses mechanisms in DCCP to limit
   the potential impact of denial-of-service attacks.

   RFC 4342 specifies the use of TFRC in CCID 3.  RFC 4342 includes
   extensive discussions of the mechanisms the sender can use to verify
   the information sent by the receiver.  When ECN is used with CCID 3,
   the receiver returns ECN Nonce information to the sender, to allow
   the sender to verify information sent by the receiver.  When ECN is
   not used, Section 9 of RFC 4342 discusses how the sender could still
   use various techniques that might catch the receiver in an error in
   reporting congestion.  However, as stated in RFC 4342, this is not
   as robust or non-intrusive as the verification provided by the ECN
   Nonce.

RFC Editor Note