One document matched: draft-ietf-dccp-tfrc-faster-restart-02.txt
Differences from draft-ietf-dccp-tfrc-faster-restart-01.txt
Internet Engineering Task Force E. Kohler
INTERNET-DRAFT UCLA
draft-ietf-dccp-tfrc-faster-restart-02.txt S. Floyd
Expires: September 2007 ICIR
Intended status: Proposed Standard A. Sathiaseelan
University of Aberdeen
2 March 2007
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 September 2007.
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 small packet variant of TFRC [TFRCSP]. We present
Kohler, et al. [Page 1]
INTERNET-DRAFT Expires: September 2007 March 2007
Faster Restart in general terms as a congestion control mechanism,
and further describe how to implement Faster Restart in Datagram
Congestion Control Protocol (DCCP) Congestion Control IDs 3 and 4
[RFC4342], [CCID4].
Kohler, et al. [Page 2]
INTERNET-DRAFT Expires: September 2007 March 2007
Table of Contents
1. Introduction ....................................................4
2. Conventions .....................................................5
3. Faster Restart Congestion Control ...............................5
3.1. Minimum Sending Rate .......................................6
3.2. Receive Rate Adjustment ....................................7
3.2.1. Send Receive Rate Length Feature ....................8
3.3. Feedback Packets ...........................................9
3.4. Nofeedback Timer ..........................................10
4. Faster Restart Discussion ......................................11
5. Simulations of Faster Restart ..................................12
6. Implementation Issues ..........................................12
7. Security Considerations ........................................13
8. IANA Considerations ............................................13
9. Thanks .........................................................13
Normative References ..............................................13
Informative References ............................................13
A. Appendix: Simulations ..........................................14
Authors' Addresses ................................................16
Full Copyright Statement ..........................................17
Intellectual Property .............................................17
Kohler, et al. [Page 3]
INTERNET-DRAFT Expires: September 2007 March 2007
1. Introduction
This document defines congestion control mechanisms that improve the
performance of data-limited and/or occasionally idle TCP-Friendly
Rate Control (TFRC) [RFC3448] flows. A data-limited and/or idle flow
uses less than its fair share of path bandwidth for application-
specific reasons, such as lack of data to send. Existing TFRC (and
TCP) mechanisms prevent such a flow from quickly ramping up to its
fair share of path bandwidth. We present mechanisms that allow
applications to ramp up faster, in a controlled way.
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 [RFC4782]. Similarly, X_recv forces applications with
variable sending rates that wish to ramp up from an application-
limited rate up to a fair-share rate to do so using slow start.
This behavior is safe, though conservative, for best-effort traffic
in the network. A silent application stops receiving feedback about
the condition of the current network path, and thus should not be
able to send at an arbitrary rate. A slowly-sending application
stops receiving feedback about whether current network conditions
would support higher rates. 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 or slow periods, as opposed to at the beginning of
a connection. A flow 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.
Kohler, et al. [Page 4]
INTERNET-DRAFT Expires: September 2007 March 2007
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 TCP initial sending rate of
two or four packets per RTT, depending on packet size, as the result
of an idle or slow period. [RFC3390]. Faster Restart doubles this
allowed sending rate after idle periods: that the allowed sending
rate is never reduced below four packets per RTT, or eight packets
per RTT for small packets, as the result of an idle or slow period.
In addition, because flows already have some (possibly old)
information about the 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 X_recv, since the time interval used by
the receiver to calculate X_recv may include the idle period as well
as active periods on either side. This low value will artificially
depress the sender's send rate. DCCP's TFRC CCIDs 3 and 4 [RFC4342],
[CCID4] report X_recv using a Receive Rate option. We suggest a
change to this Receive Rate option that lets the sender detect and
compensate for such problems.
The congestion control mechanisms here are intended to apply to any
implementations of TFRC, including that in DCCP's CCID 3 and CCID 4
[RFC4342], [CCID4]. While we also believe that TCP could safely use
similar mechanisms, we do not specify them here.
2. 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].
3. Faster Restart Congestion Control
The Faster Restart mechanism refers to several existing TFRC state
variables, including:
R The RTT estimate.
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
Kohler, et al. [Page 5]
INTERNET-DRAFT Expires: September 2007 March 2007
since the last feedback report was sent.
s The packet size in bytes.
X_calc
The safe rate determined by the TCP throughput equation.
Calculated from p, R, and s.
Faster Restart also introduces two new state variables to TFRC, as
follows.
X_active_recv
The receiver's estimated receive rate 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.
T_active_recv
The time at which X_active_recv was measured. It is initialized
to the connection's start time.
X_active_min_rate
The minimum restart rate allowed by Faster Restart in the presence
of idle and/or data-limited periods. Note that Faster Restart
flows can drop below this rate as the result of actual loss
feedback. X_active_min_rate is defined as follows:
X_active_min_rate := min(8*s, max(4*s, 8760 bytes)).
Other variables have values as described in [RFC3448].
3.1. Minimum Sending Rate
The TFRC specification allows a TFRC endpoint to go completely silent
when the sending application runs out of data to send. When Faster
Restart is used, however, the transport layer MUST send a minimum of
X_ping/s packets per second, where X_ping is defined as
X_ping = min(X, s/4R).
That is, the transport layer will send at least one packet per four
round-trip times, as allowed by the current allowed sending rate X.
These packets give the endpoint a continuing stream of RTT samples
and information about network congestion. Extra packets generated by
the transport layer to maintain a minimum sending rate SHOULD NOT be
reported to the receiving application.
DCCP implementations MUST use DCCP-Data or DCCP-DataAck packets with
a zero-length application data area for packets sent to maintain a
minimum sending rate. To that end, this document modifies RFC 4340's
Kohler, et al. [Page 6]
INTERNET-DRAFT Expires: September 2007 March 2007
behavior with respect to zero-length application data area DCCP-Data
and DCCP-DataAck packets. RFC 4340, Section 5.4, specifies that:
A DCCP-Data or DCCP-DataAck packet may have a zero-length
application data area, which indicates that the application sent a
zero-length datagram. This differs from DCCP-Request and DCCP-
Response packets, where an empty application data area indicates
the absence of application data (not the presence of zero-length
application data). The API SHOULD report any received zero-length
datagrams to the receiving application.
This document revises this statement as follows.
A DCCP-Data or DCCP-DataAck packet may have a zero-length
application data area. Such packets may be sent by congestion
control algorithms to maintain a minimum sending rate. As in
DCCP-Request and DCCP-Response packets, an empty application data
area indicates the absence of application data. The API MUST NOT
report any received zero-length datagrams to the receiving
application. The API SHOULD report an error when a sending
application attempts to send a zero-length datagram.
3.2. Receive Rate Adjustment
The X_recv values reported by a TFRC receiver may be artificially
depressed by idle periods. The sender can properly detect and
account for such X_recv values, given some information about whether
a reported X_recv includes information about an idle period. We
describe the relevant algorithm in the context of an implementation
in DCCP's CCID 3 and 4. This implementation adds a new option to
required feedback packets, namely Receive Rate Length.
+--------+--------+--------+--------+--------+
|11000100|00000101| Receive Rate Length |
+--------+--------+--------+--------+--------+
Type=196 Len=5
Receive Rate Length (24 bits)
The Receive Rate Length reports the number of packets used to
calculate the Receive Rate, minus one. 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. Thus, a Receive Rate Length of zero indicates that one
packet was used to calculate Receive Rate.
The Receive Rate Length option allows senders to adjust Receive Rates
before using them in TFRC calculations. The first adjustment applies
to any Receive Rate options, with or without Receive Rate Lengths.
Kohler, et al. [Page 7]
INTERNET-DRAFT Expires: September 2007 March 2007
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 packet contains a
Receive Rate option but not a Receive Rate Length, then 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.
If T1 = T2, then X_recv_in MUST be used as is. Otherwise, assume
that in that interval, the sender was idle for a total of I
seconds. Here, "idle" means that the sender had 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.) 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.
3.2.1. Send Receive Rate Length Feature
The Send Receive Rate Length feature lets DCCP CCID 3 and 4 endpoints
negotiate whether the receiver MUST provide Receive Rate Length
options on its feedback packets. DCCP A sends a "Change R(Send
Receive Rate Length, 1)" option to ask DCCP B to send Receive Rate
Length options as part of its acknowledgement traffic.
Receive Rate Length has feature number 196 and is server-priority.
It takes one-byte Boolean values. DCCP B MUST send Receive Rate
Length options on its feedback packets when Send Receive Rate
Length/B is one, although it MAY send Receive Rate Length options
even when Send Receive Rate Length/B is zero. Values of two or more
Kohler, et al. [Page 8]
INTERNET-DRAFT Expires: September 2007 March 2007
are reserved. A CCID 3 half-connection starts with Send Receive Rate
Length equal to zero.
3.3. 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 highest recent loss- and mark-
free fair 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 four phases. The first phase adjusts the feedback
packet's X_recv to make sure it does not drop too low as the result
of a slow send rate.
The second 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.
Kohler, et al. [Page 9]
INTERNET-DRAFT Expires: September 2007 March 2007
To update X when you receive a feedback packet
----------------------------------------------
/* First phase. Adjust X_recv so send rate doesn't drop
below X_active_min_rate as the result of an idle and/or
slow period. */
If the feedback packet does not indicate a loss or mark
and the old X_recv >= X_active_min_rate/2, then
X_recv := max(X_recv, X_active_min_rate/2).
/* Second phase. Calculate X_fast_max */
/* If achieved X_active_recv <= 10 minutes ago, end
Faster Restart at the full last fair rate; if achieved
X_active_recv >= 30 minutes ago, 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.
/* Third phase. Update X_active_recv */
If the feedback packet does not indicate a loss or mark
and X_recv >= X_fast_max, then
X_active_recv := X_fast_max := X_recv,
T_active_recv := current time.
Else if the feedback packet DOES indicate a loss or mark
and X_recv < X_fast_max, then
X_active_recv := X_fast_max := X_recv/2,
T_active_recv := current time.
/* Fourth 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.
3.4. Nofeedback Timer
RFC 3448, Section 4.4, specifies that the sending rate is cut in half
when the TFRC nofeedback timer expires. This is accomplished by
reducing X_recv. Faster Restart changes this algorithm so that the
sending rate never drops below 4 packets per RTT, or 8 packets per
RTT for small packets, as the result of an idle period. In
particular, Step 1) of the algorithm executed as a result of a
Kohler, et al. [Page 10]
INTERNET-DRAFT Expires: September 2007 March 2007
nofeedback timer is changed to the following:
If the sender has sent no data whatsoever since the
time the nofeedback timer was set,
and X_active_min_rate/2 <= X_recv <= X_active_min_rate,
X_recv := X_active_min_rate/2.
Else if X_calc > 2*X_recv, then
X_recv := max(X_recv/2, s/(2*t_mbi)).
Else
X_recv := X_calc/4.
4. Faster Restart Discussion
TCP has historically dealt with idleness and data-limited flows
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 or
data-limited 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 many minutes
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 is 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. The
available bandwidth might vary over time because of bandwidth used
by higher-priority traffic. All of this might happen 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 the level of statistical multiplexing may not be
Kohler, et al. [Page 11]
INTERNET-DRAFT Expires: September 2007 March 2007
sufficiently high for connections to obtain a deterministic
estimate of the fair rate.
o The network allocates capacity based on traffic conditions, as
happens in some current wireless technologies, such as Bandwidth
on Demand (BoD) links [RFC3819] where capacity is variable and
dependent on several parameters other than network congestion.
Further analysis is required to analyze the effects of these
scenarios.
We note that Faster Restart in TFRC-SP [TFRCSP] is considerably more
restrained that Faster Restart in the default TFRC. In TFRC-SP, the
sender is restricted to sending at most one packet every Min
Interval. Similarly, Faster Restart in the default TFRC is more
restrained than Faster Restart would be if added to TCP; TFRC is
controlled by a sending rate, while TCP is controlled by a window,
and could send in a very bursty pattern without rate-based pacing.
5. Simulations of Faster Restart
Some test case scenarios based on simulation analysis are described
in Appendix A. These simulation follow the guidelines set in
[TFRCSP]. These are:
1. Fairness to standard TCP and TFRC: The simulation tests examine
whether flows that use Faster Restart allow TCP and TFRC flows can
achieve its fair share rate of the path capacity.
2. Fairness within FR: The simulation tests examine how multiple
competing FR flows share the available capacity among them.
3. Response to transient events: The simulation tests examine how a
FR flow reacts to a sudden congestion event.
4. Behaviour in a range of environments: Tests assess a range of
bandwidth, RTTs, and varying idle periods.
>>> A later version of this draft will provide more discussion on
these results in the appendix and implications will be noted here.
6. Implementation Issues
TBA
Kohler, et al. [Page 12]
INTERNET-DRAFT Expires: September 2007 March 2007
7. Security Considerations
DCCP security considerations are discussed in [RFC4340]. Faster
Restart adds no additional security considerations. XXX WE WILL
PROBABLY BE REQUIRED TO ADD SOME STUFF HERE
8. IANA Considerations
This document allocates two values in the "Profile for DCCP
Congestion Control ID 3: TFRC Congestion Control Parameters"
registry. Specifically, it allocates Option Type 196 for the Receive
Rate Length option, and Feature Number 196 for the Send Receive Rate
Length feature.
9. Thanks
We thank the DCCP Working Group for feedback and discussions,
including Gorry Fairhurst. We especially thank 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] Handley, M., Floyd, S., Padhye, J., and J. Widmer,
"TCP Friendly Rate Control (TFRC): Protocol
Specification", RFC 3448, Proposed Standard, January
2003.
[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.
Informative References
[CCID4] Floyd, S., and E. Kohler, "Profile for Datagram
Congestion Control Protocol (DCCP) Congestion ID 4:
TCP-Friendly Rate Control for Small Packets (TFRC-
SP)", Internet-Draft draft-floyd-dccp-ccid4-00.txt,
work in progress, October 2006.
Kohler, et al. [Page 13]
INTERNET-DRAFT Expires: September 2007 March 2007
[MAF04] Medina, A., Allman, M., and S. Floyd, "Measuring the
Evolution of Transport Protocols in the Internet", May
2004, URL "http://www.icir.org/tbit/".
[RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion
Window Validation", RFC 2861, June 2000.
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing
TCP's Initial Window", RFC 3390, October 2002.
[RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman,
D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch,
J., and L. Wood, "Advice for Internet Subnetwork
Designers", RFC 3819, July 2004.
[RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti,
"Quick-Start for TCP and IP", RFC 4782, June 2006.
[TFRCSP] Floyd, S., and E. Kohler, "TCP Friendly Rate Control
(TFRC): the Small-Packet (SP) Variant", Internet-Draft
draft-ietf-dccp-tfrc-voip-07.txt, work in progress,
November 2006.
A. Appendix: Simulations
This appendix describes a set of initial test case scenarios for
simulation analysis of Faster Restart. The topology will be the
classic dumb-bell topology used in many simulations of TCP.
Six types of flow are considered:
o Bulk TCP Flows.
o Interactive (short) TCP Flows.
o TFRC Flows.
o TFRC Flows that employ FR.
o TFRC-SP Flows.
o TFRC Flows that employ FR (TFRC-SP).
The implications on other flows (e.g. using UDP) may be extrapolated
from this.
For these simulations, we consider three application-limited rates.
Kohler, et al. [Page 14]
INTERNET-DRAFT Expires: September 2007 March 2007
o The first resembles constant bit rate (CBR) voice over IP with a
media bit rate of 64 kbps (using packets of size 160 bytes and a
nominal transmit rate of 8000Bps).
o The second resembles constant bit rate (CBR) medium quality video
over IP with a media bit rate of 512 kbps (using packets of size
1000 bytes and a nominal transmit rate of 64000Bps).
o The third class uses an unspecified upper limit on the sending
rate, but experiences period of idleness.
These are intended to be illustrative, rather than exact models of
the application behaviour.
The simulations will model the effect of an idle period in which the
application does not attempt to send any data for a period of time,
then resumes transmission.
In the first case, we shall examine periods of idleness of 1s, 10s,
and 30s with a path RTT of 50ms, 300ms.
The scenarios to be examined are:
o Performance of a long-lived (bulk) TCP flow (e.g. FTP) with TFRC
(with and without FR): The test scenario would involve a single
large FTP flow with varying number of CBR flows. Each CBR flow
becomes idle for 10s and then restarts. The FTP flow starts during
the idle period. The throughput performance of the single FTP flow
would be plotted for varying number of CBR flows. Simulations
would be performed by varying parameters such as CBR rate and
number of silence periods. Does the single FTP flow get at least
1/n share of the bandwidth, where 'n' is the number of TFRC flows
and the single TCP flow? Does the single TCP flow get less share
of the bandwidth while competing with FR flows when compared to
TFRC flows?
o Fairness test: The test scenario would involved 'n' number CBR and
long lived TCP flows. The CBR flows become idle for 10s and then
restarts. During the silence period, the FTP flows arrive. Do all
flows get atleast 1/n share of the bandwidth? Jain's Fairness
Index [JCH84] would be an appropriate measure.
o Performance of small TCP flows (HTTP) with TFRC with and without
FR: The test scenario would involve a single CBR flow running for
50s, becomes ilde between 20s and 30s and then restarts. At 30.s,
a number of HTTP flows are started. The min, max and median of the
request/response time of these HTTP flows would be plotted.
Simulations would be performed by varying several parameters such
Kohler, et al. [Page 15]
INTERNET-DRAFT Expires: September 2007 March 2007
as CBR rate, bottleneck bandwidth, delay and queue size. Do the
request/response times of these HTTP flows differ? If so, by how
much?
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
Arjuna Sathiaseelan <arjuna@erg.abdn.ac.uk>
Electronics Research Group
University of Aberdeen
Aberdeen
UK
Kohler, et al. [Page 16]
INTERNET-DRAFT Expires: September 2007 March 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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 REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
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.
Kohler, et al. [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-22 19:22:52 |