One document matched: draft-ietf-dccp-tfrc-faster-restart-01.txt
Differences from draft-ietf-dccp-tfrc-faster-restart-00.txt
Internet Engineering Task Force Eddie Kohler
INTERNET-DRAFT UCLA
draft-ietf-dccp-tfrc-faster-restart-01.txt Sally Floyd
Expires: December 2006 ICIR
25 June 2006
Faster Restart for TCP Friendly Rate Control (TFRC)
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 2006.
Abstract
TCP-Friendly Rate Control (TFRC) is a congestion control mechanism
for unicast flows operating in a best-effort Internet environment
[RFC3448]. This document introduces Faster Restart, an optional
mechanism for safely improving the behavior of interactive flows
that use TFRC. Faster Restart is proposed for use with both the
default TFRC and with the VoIP variant of TFRC.
Floyd/Kohler [Page 1]
INTERNET-DRAFT Expires: December 2006 June 2006
Table of Contents
1. Conventions ....................................................3
2. Introduction ...................................................3
3. Faster Restart Congestion Control ..............................4
3.1. Feedback Packets ..........................................5
4. Receive Rate Adjustment ........................................6
5. Faster Restart Discussion ......................................8
6. Simulations of Faster Restart ..................................9
7. Implementation Issues ..........................................9
8. Security Considerations ........................................9
9. IANA Considerations ............................................9
10. Thanks ........................................................9
Normative References ..............................................9
Informative References ...........................................10
Authors' Addresses ...............................................10
Full Copyright Statement .........................................10
Intellectual Property ............................................11
Floyd/Kohler [Page 2]
INTERNET-DRAFT Expires: December 2006 June 2006
1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Introduction
In any RTT, a TFRC flow may not send more than twice X_recv, the
amount that was received in the previous RTT. The TFRC nofeedback
timer reduces this number by half during each nofeedback timer
interval (at least four RTT) in which no feedback is received. The
effect of this is that applications must slow start after going idle
for any significant length of time, in the absence of mechanisms
such as Quick-Start [JFAS05].
This behavior is safe, though conservative, for best-effort traffic
in the network. A silent application stops receiving feedback about
current network conditions, and thus should not be able to send at
an arbitrary rate. But this behavior can damage the perceived
performance of interactive applications such as voice. Connections
for interactive telephony and conference applications, for example,
will usually have one party active at a time, with seamless
switching between active parties. A slow start on every switch
between parties may seriously degrade perceived performance. Some
of the strategies suggested for coping with this problem, such as
sending padding data during application idle periods, might have
worse effects on the network than simply switching onto the desired
rate with no slow start.
There is some justification for somewhat accelerating the slow start
process after idle periods (as opposed to at the beginning of a
connection). A connection that fairly achieves a sending rate of X
has proved, at least, that some path between the endpoints can
support that rate. The path might change, due to endpoint reset or
routing adjustments; or many new connections might start up,
significantly reducing the application's fair rate. However, it
seems reasonable to allow an application to contribute to transient
congestion in times of change, in return for improving application
responsiveness after idle periods.
This document suggests a relatively simple approach to this problem.
Some protocols using TFRC [RFC4342] already specify that the allowed
sending rate is never reduced below the RFC-3390 sending rate of
four packets per RTT during an idle period. Faster Restart
specifies that the allowed sending rate is never reduced by an idle
period below eight packets per RTT, for small packets. In addition,
because flows already have some (possibly old) information about the
Floyd/Kohler Section 2. [Page 3]
INTERNET-DRAFT Expires: December 2006 June 2006
path, Faster Restart allows flows to quadruple their sending rate in
every congestion-free RTT, instead of doubling, up to the previously
achieved rate. Any congestion event stops this faster restart and
switches TFRC into congestion avoidance.
This document also addresses a more general problem with idle
periods. The first feedback packet sent after an idle period may
report an artificially low Receive Rate, since the time interval
used by the receiver to calculate the Receive Rate will include the
idle period as well as active periods on either side. This low
Receive Rate will artificially depress the sender's send rate. We
suggest a change to the Receive Rate option that lets the sender
detect and compensate for such problems.
3. Faster Restart Congestion Control
DRAFT DRAFT DRAFT
A connection goes "idle" when the application has nothing to send
for at least a nofeedback interval (as least four round-trip times).
However, when Faster Restart is used, the transport layer MUST send
a "ping" packet every several round trip times, to continue getting
RTT samples and some idea of the loss event rate.
The Faster Restart mechanism refers to several existing TFRC state
variables, including:
R The RTT estimate; kept current during any idle periods as
described above.
X The current allowed sending rate in bytes per second.
p The recent loss event rate.
X_recv
The rate at which the receiver estimates that data was received
since the last feedback report was sent. Note that this
includes "ping" packets sent during idle periods (above) as well
as application packets.
Faster Restart also introduces two new state variables to TFRC, as
follows.
X_active_recv
The receiver's estimated receive reported during a recent active
sending period. An active sending period is a period in which
the sender was neither idle nor in faster restart. It is
initialized to 0 until there has been an active sending period.
Floyd/Kohler Section 3. [Page 4]
INTERNET-DRAFT Expires: December 2006 June 2006
T_active_recv
The time at which X_active_recv was measured. It is initialized
to the connection's start time.
Other variables have values as described in [RFC3448].
3.1. Feedback Packets
The Faster Restart algorithm replaces for the 4th step of Section
4.3, "Sender behavior when a feedback packet is received", of
[RFC3448]. The replacement code has two goals:
1. It keeps track of the active receive rate, X_active_recv. This
parameter models the connection's most relevant loss- and mark-
free transmit rate, and represents an upper bound on the rate
achievable through faster restart. Thus, X_active_recv is
increased as the connection achieves higher congestion-free
transmit rates, and reduced on congestion feedback, to prevent
inappropriate faster restart until a new stable active rate is
achieved. Specifically, on congestion feedback at low rates,
the sender sets X_active_recv to X_recv/2; this allows limited
faster restart up to a likely-safe rate, and lowers the
likelihood that badly-timed transient congestion will wholly
cripple the faster restart mechanism.
2. It adjusts the receive rate, X_recv, more aggressively during
faster restart periods, up to the limit of X_active_recv.
The code works in three phases. The first phase determines
X_fast_max, the adjusted rate at which faster restart should stop.
Full faster restart up to X_active_recv should be allowed for short
idle periods, but more conservative behavior should prevail after
longer idle periods. Thus, if 10 minutes or less have elapsed since
the last active-period measurement (T_active_recv), the code sets
X_fast_max to the full value of X_active_recv. If 30 minutes or
more have elapsed, X_fast_max is set to 0. Linear interpolation is
used between these extremes.
The second phase adjusts X_active_recv based on the feedback
packet's contents and the value of X_fast_max.
Finally, the third phase sets X based on X_fast_max, X_recv, and
X_calc, the calculated send rate. Several temporary variables are
used, namely X_fast_max, delta_T, F, and X_recv_limit.
Floyd/Kohler Section 3.1. [Page 5]
INTERNET-DRAFT Expires: December 2006 June 2006
To update X when you receive a feedback packet
----------------------------------------------
/* First phase. Calculate X_fast_max */
/* If idle for <= 10 minutes, end faster restart at the
full last fair rate; if idle for >= 30 minutes,
don't do faster restart; in between, interpolate. */
delta_T := now - T_active_recv,
F := (30 min - min(max(delta_T, 10 min), 30 min)) / 20 min,
X_fast_max := F*X_active_recv.
/* Second phase. Update X_active_recv */
If the feedback packet corresponds to an active period
and does not indicate a loss or mark, then
If X_recv >= X_fast_max, then
X_active_recv := X_fast_max := X_recv,
T_active_recv := current time.
Else if X_recv < X_fast_max and the feedback packet
DOES indicate a loss or mark,
X_active_recv := X_fast_max := X_recv/2,
T_active_recv := current time.
/* Third phase. Calculate X */
X_recv_limit := 2*X_recv.
If X_recv_limit < X_fast_max,
X_recv_limit := min(4*X_recv, X_fast_max).
If p > 0,
Calculate X_calc using the TCP throughput equation.
X := max(min(X_calc, X_recv_limit), s/t_mbi).
Else
If (t_now - tld >= R)
X := max(min(2*X, X_recv_limit), s/R);
tld := now.
4. Receive Rate Adjustment
DRAFT DRAFT DRAFT
To allow the sender to properly detect and account for Receive Rates
artificially depressed by idle periods, we extend the Receive Rate
option and change the way it is processed. The extended Receive
Rate option appears as follows:
Floyd/Kohler Section 4. [Page 6]
INTERNET-DRAFT Expires: December 2006 June 2006
+--------+--------+--------+--------+--------+--------+
|11000010|00001001| Receive Rate |
+--------+--------+--------+--------+--------+--------+
Type=194 Len=9
+--------+--------+--------+
| Receive Rate Length |
+--------+--------+--------+
Receive Rate Length (24 bits)
The Receive Rate Length specifies exactly how many packets were
used to calculate the Receive Rate. It is specified relative to
the feedback packet's Acknowledgement Number. If a feedback
packet's Receive Rate was calculated using data packet sequence
numbers S1...S2, inclusive, where S2 is the feedback packet's
Acknowledgement Number, then Receive Rate Length will be set to
S2 - S1.
In addition to this new form of Receive Rate option, we allow
senders to adjust feedback packets' Receive Rates before using them
in TFRC calculations. The first adjustment applies to any Receive
Rate options, with or without Receive Rate Lengths.
o Assume that the sender receives two feedback packets with
Acknowledgement Numbers A1 and A2, respectively. Further assume
that the sender sent no data packets in between Sequence Numbers
A1+1 and A2. (All those packets must have been pure
acknowledgements, Sync and SyncAck packets, and so forth.) Then
the sender MAY, at its discretion, ignore the second feedback
packet's Receive Rate option. Note that when the sender decides
to ignore such an option, it MUST NOT reset the nofeedback timer
as it normally would; the nofeedback timer will go off as if the
second feedback packet had never been received.
The second adjustment applies only to packets containing a Receive
Rate Length as well as a Receive Rate. If a Receive Rate option
does not contain a Receive Rate Length, the sender MUST use that
Receive Rate as is. We refer to the original Receive Rate, as
encoded in the option, as X_recv_in.
o Assume that the sender receives a feedback packet with
Acknowledgement Number S2 and Receive Rate Length RRL. Let
S1 = S2 - RRL; then the feedback packet's Receive Rate was
calculated using sequence numbers S1...S2, inclusive. Assume
that the sender sent packet S1 at time T1, and packet S2 at time
T2. Further assume that in that interval, the sender was idle
for a total of I seconds. Here, "idle" means that the sender had
Floyd/Kohler Section 4. [Page 7]
INTERNET-DRAFT Expires: December 2006 June 2006
nothing to send for a contiguous period of at least one-half
round trip time. (Note that this definition of idleness is less
conservative than that applied to the Faster Restart algorithm.
[XXX?]) Then the sender MAY act as if the feedback packet
specified a Receive Rate of
X_recv_in*(T2 - T1 + I)/(T2 - T1),
rather than the nominal Receive Rate of X_recv_in. The inflation
factor, (T2 - T1 + I)/(T2 - T1), compensates for the idle periods
by removing their effect.
5. Faster Restart Discussion
TCP has historically dealt with idleness either by keeping cwnd
entirely open ("immediate start") or by entering slow start, as
recommended in RFC 2581. The first option is too liberal, the
second too conservative. Clearly a short idle period is not a new
connection: recent evidence shows that the connection could fairly
sustain some rate. However, longer idle periods are more
problematic, and idle periods of hours would seem to require slow
start. RFC 2861 [RFC2861], which is fairly widely implemented
[MAF04], gives a moderate mechanism for TCP, where the congestion
window is halved for every round-trip time that the sender has
remained idle, and the window in re-opened in slow-start when the
idle period is over.
Faster Restart should be acceptable for TFRC if its worst-case
scenario is acceptable. Realistic worst-case scenarios might include
the following scenarios:
o The path changes and the old rate isn't acceptable on the new
path. RTTs are shorter on the new path too, so Faster Restart
clobbers other connections for multiple RTTs, not just one.
o Two (or more) connections enter Faster Restart simultaneously.
The packet drop rate can be twice as bad, for one RTT, than if
they had slow-started after their idle periods.
o In addition to connections Fast-Restarting, there are short TCP
or DCCP connections starting and stopping all the time, with
initial windows of three or four packets. There are also TCP
connections with short quiescent periods (web browsing sessions
using HTTP 1.1). The audio and video connections have idle
periods. And the available bandwidth might vary over time,
because of bandwidth used by higher-priority traffic (routing
traffic, and diffserv). All of this is happening at once, so the
aggregate arrival rate naturally varies from one RTT to the next.
And the congested link is an access link, not a backbone link, so
Floyd/Kohler Section 5. [Page 8]
INTERNET-DRAFT Expires: December 2006 June 2006
the level of statistical multiplexing is not high enough to make
everything just look like lovely white noise.
Further analysis is required to analyze the effects of these
scenarios.
We note that Faster Restart in VoIP TFRC is considerably more
restrained that Faster Restart in the default TFRC; in VoIP TFRC,
the sender is restricted to sending at most one packet every Min
Interval. Similarly, Faster Restart in the default TFRC is more
restrained that Faster Restart would be if added to TCP; TFRC is
controlled of a sending rate, while TCP is controlled by a window,
and could send in a very bursty pattern, in the absence of rate-
based pacing.
6. Simulations of Faster Restart
TBA
7. Implementation Issues
TBA
8. Security Considerations
DCCP security considerations are discussed in [RFC4340]. Faster
Restart adds no additional security considerations.
9. IANA Considerations
There are no IANA considerations in this document.
10. Thanks
We thank the DCCP Working Group for feedback and discussions. We
especially thank Arjuna Sathiaseelan and Vlad Balan for pointing out
problems with the mechanisms discussed in previous versions of the
draft.
Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3448] M. Handley, S. Floyd, J. Padhye, and J. Widmer, TCP
Friendly Rate Control (TFRC): Protocol
Floyd/Kohler [Page 9]
INTERNET-DRAFT Expires: December 2006 June 2006
Specification, RFC 3448, Proposed Standard, January
2003.
Informative References
[JFAS05] A. Jain, S. Floyd, M. Allman, and P. Sarolahti.
Quick-Start for TCP and IP. Internet-draft draft-
amit-quick-start-04.txt, work in progress, February
2004.
[MAF04] A. Medina, M. Allman, and A. Floyd, Measuring the
Evolution of Transport Protocols in the Internet,
May 2004, URL "http://www.icir.org/tbit/".
[RFC2861] M. Handley, J. Padhye, and S. Floyd. TCP Congestion
Window Validation. RFC 2861, June 2000.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March
2006.
[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for
Datagram Congestion Control Protocol (DCCP)
Congestion Control ID 3: TCP-Friendly Rate Control
(TFRC)", RFC 4342, March 2006.
Authors' Addresses
Eddie Kohler <kohler@cs.ucla.edu>
4531C Boelter Hall
UCLA Computer Science Department
Los Angeles, CA 90095
USA
Sally Floyd <floyd@icir.org>
ICSI Center for Internet Research
1947 Center Street, Suite 600
Berkeley, CA 94704
USA
Full Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
Floyd/Kohler [Page 10]
INTERNET-DRAFT Expires: December 2006 June 2006
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Floyd/Kohler [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-22 19:22:52 |