From: The IESG <email@example.com>
To: IETF-Announce <firstname.lastname@example.org>
Cc: Internet Architecture Board <email@example.com>,
RFC Editor <firstname.lastname@example.org>,
dccp mailing list <email@example.com>,
dccp chair <firstname.lastname@example.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
The IESG contact persons are Lars Eggert and Magnus Westerlund.
A URL of this Internet-Draft is:
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.
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.
Gorry Fairhurst (email@example.com) was the Document Shepherd.
Lars Eggert (firstname.lastname@example.org) 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