The IESG has approved the following document: - 'TCP Friendly Rate Control (TFRC): the Small-Packet (SP) Variant ' <draft-ietf-dccp-tfrc-voip-07.txt> as an Experimental RFC 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-tfrc-voip-07.txt 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. 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. Gorry Fairhurst was the PROTO Document Shepherd and Lars Eggert has reviewed this document for the IESG. Note to RFC Editor Section 3 (feedback from Magnus): OLD: 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. NEW: However, if the TFRC implementation knows that the IP layer is using IPv6 instead of IPv4, then the connection using TFRC-SP MAY still use the default estimate of 40 bytes for H instead of the actual size of 60 bytes, for simplicity of implementation. Section 4.5.1 (from Miguel Garcia): OLD: this environments, the sending rate in bytes per RTT is roughly 1.2 NEW: these environments, the sending rate in bytes per RTT is roughly 1.2 ^^^^^ Section 4.5.3 (from Lars): OLD: bytes (becauses the path MTU is known to be less than 576 bytes), NEW: bytes (because the path MTU is known to be less than 576 bytes), ^^^^^^^ Section 12 (nit from Miguel Garcia): OLD: for feedback on earlier versions of this draft. NEW: for feedback on earlier versions of this document. ^^^^^^^^ Section 9 (from secdir review by Juergen Quittek): OLD: There are no security considerations introduced in this document. General security considerations for TFRC are discussed in RFC 3448. The security considerations for TFRC include the need to protect against spoofed feedback, and the need for protection mechanisms to protect the congestion control mechanisms against incorrect information from the receiver. Security considerations for DCCP's Congestion Control ID 3, TFRC Congestion Control, are discussed in [RFC4342]. That document extensively discussed the mechanisms the sender can use to verify the information sent by the receiver. NEW: There are no new security considerations introduced in this document. The issues of the fairness of TFRC-SP with standard TFRC and TCP in a range of environments, including those with byte-based queue management at the congested routers, are discussed extensively in the main body of this document. General security considerations for TFRC are discussed in RFC 3448. As with TFRC in RFC 3448, TFRC-SP is not a transport protocol in its own right, but a congestion control mechanism that is intended to be used in conjunction with a transport protocol. Therefore security primarily needs to be considered in the context of a specific transport protocol and its authentication mechanisms. As discussed for TFRC in RFC 3448, any transport protocol that uses TFRC-SP needs to protect against spoofed feedback, and to protect the congestion control mechanisms against incorrect information from the receiver. Again as discussed for TFRC in RFC 3448, we expect that protocols incorporating ECN with TFRC-SP will want to use the ECN nonce [RFC3540] to protect the sender from the accidental or malicious concealment of marked packets Security considerations for DCCP's Congestion Control ID 3, TFRC Congestion Control, the transport protocol that uses TFRC, are discussed in [RFC4342]. That document extensively discussed the mechanisms the sender can use to verify the information sent by the receiver, including the use of the ECN nonce. Section (adding acknowledgements): OLD: Eggert, Gorry Fairhurst, Mark Handley, Ladan Gharai, Richard Nelson, Colin Perkins, Pete Sholander, Magnus Westerlund, and Joerg Widmer NEW: Eggert, Gorry Fairhurst, Mark Handley, Miguel Garcia, Ladan Gharai, Richard Nelson, Colin Perkins, Juergen Quittek, Pete Sholander, Magnus Westerlund, and Joerg Widmer New Reference: NEW: [RFC3540] D. Wetherall, D. Ely, and N. Spring, Robust ECN Signaling with Nonces, RFC 3540, Experimental, June 2003. _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
