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.