TCP Friendly Rate Control (TFRC): Protocol Specification
Draft of message to be sent after approval:
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 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
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 (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 Nonce.