Internet Engineering Task Force Sally Floyd
INTERNET-DRAFT ICIR
draft-ietf-dccp-tfrc-voip-02.txt Eddie Kohler
Expires: January 2006 UCLA
19 July 2005
TCP Friendly Rate Control (TFRC) for Voice:
VoIP Variant
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 January 2006.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Floyd/Kohler [Page 1]
INTERNET-DRAFT Expires: January 2006 July 2005
Abstract
TCP-Friendly Rate Control (TFRC) is a congestion control mechanism
for unicast flows operating in a best-effort Internet environment
[RFC 3448]. This document proposes a VoIP variant to TFRC. 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. The VoIP variant of TFRC is
designed for applications that send small packets, where the design
goal is to achieve the same bandwidth in bps as a TCP flow using
1500-byte data packets. This variant is referred to in RFC 3448 as
TFRC-PS, for applications that might vary their packet size in
response to congestion. The VoIP variant of TFRC enforces a Min
Interval of 10 ms between data packets, to prevent a single flow
from sending small packets arbitrarily frequently.
Flows using the VoIP variant of TFRC 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 DropTail
queues in units of bytes), the current VoIP variant of TFRC can
receive considerably more than its share of the bandwidth. (We note
however that in all scenarios the VoIP variant of TFRC is better, in
terms of congestion in the network, than the same application in the
absence of congestion control).
Floyd/Kohler [Page 2]
INTERNET-DRAFT Expires: January 2006 July 2005
TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION:
Changes from draft-ietf-dccp-tfrc-voip-01.txt
* Added modified algorithm for calculating the loss event rate,
for short intervals with multiple packet drops.
* Moved Faster Restart to a separate document.
* Added simulations with a configured byte drop rate.
* Added many more simulations, including DropTail with a queue
in bytes.
* Added a discussion of unfairness for DropTail with a queue
in bytes.
Changes from draft-ietf-dccp-tfrc-voip-00.txt
* Added more simulations.
* Added a Related Work section.
Floyd/Kohler [Page 3]
INTERNET-DRAFT Expires: January 2006 July 2005
Table of Contents
1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. VoIP Variant Introduction . . . . . . . . . . . . . . . . . . 5
3. VoIP Variant Congestion Control . . . . . . . . . . . . . . . 7
4. VoIP Variant Discussion . . . . . . . . . . . . . . . . . . . 8
4.1. The TCP Throughput Equation. . . . . . . . . . . . . . . 8
4.2. Accounting for Header Size . . . . . . . . . . . . . . . 9
4.3. The VoIP Min Interval. . . . . . . . . . . . . . . . . . 9
4.4. Counting Packet Losses . . . . . . . . . . . . . . . . . 11
5. A Comparison with RFC 3714. . . . . . . . . . . . . . . . . . 11
6. The VoIP Variant with Applications that Modify the
Packet Size. . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Simulation Results. . . . . . . . . . . . . . . . . . . . . . 12
7.1. Simulations with Configured Drop Rates . . . . . . . . . 12
7.2. Packet Dropping Behavior at Routers with Drop-
Tail Queues . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.3. Packet Dropping Behavior at Routers with AQM . . . . . . 19
8. Discussion. . . . . . . . . . . . . . . . . . . . . . . . . . 22
9. Implementation Issues . . . . . . . . . . . . . . . . . . . . 23
10. Security Considerations. . . . . . . . . . . . . . . . . . . 23
11. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 23
12. Thanks . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Normative References . . . . . . . . . . . . . . . . . . . . . . 23
Informative References . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
13. Related Work on VoIP Variants of TFRC. . . . . . . . . . . . 25
14. Simulation Results with RED Queue Management . . . . . . . . 26
15. A Discussion of Packet Size and Packet Dropping. . . . . . . 27
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 28
Floyd/Kohler [Page 4]
INTERNET-DRAFT Expires: January 2006 July 2005
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 [RFC 2119].
2. VoIP Variant Introduction
This document specifies a VoIP variant for TCP-friendly rate control
(TFRC) [RFC 3448]. TFRC was designed to be reasonably fair when
competing for bandwidth with TCP flows, but to avoid the abrupt
changes in the sending rate characteristic of TCP's congestion
control mechanisms. TFRC is intended for applications such as
streaming media applications where a relatively smooth sending rate
is of importance.
The VoIP variant is intended for flows that need to send frequent
small packets (limited by a minimum interval between packets of 10
ms). Conventional TFRC measures loss rates by estimating the loss
event ratio as described in [RFC 3448], and uses this loss event
rate to determine the sending rate in packets per round-trip time.
This has consequences for the rate a TFRC flow can achieve when
sharing a bottleneck with large-packet TCP flows. In particular, a
low-bandwidth, small-packet TFRC flow sharing a bottleneck with
high-bandwidth, large-packet TCP flows may be forced to slow down,
even though the application's nominal rate in bytes per second is
less than the rate achieved by the TCP flows. Intuitively, this
would be "fair" only if the network limitation was in packets per
second (such as a routing lookup), rather than bytes per second
(such as link bandwidth). Conventional wisdom is that many of the
network limitations in today's Internet are in bytes per second,
even though the network limitations of the future might move back
towards limitations in packets per second.
The VoIP variant of TFRC described here will better support
applications that do not want their sending rates in bytes per
second to suffer from their use of small packets. This variant is
restricted to applications that send packets no more than once every
10 ms (the Min Interval). Given this restriction, the VoIP variant
effectively calculates the TFRC fair rate as if the bottleneck
restriction was in bytes per second. Applications using the VoIP
variant of TFRC could have a fixed packet size, or could vary their
packet size in response to congestion.
The VoIP variant of TFRC is motivated in part by the approach in RFC
3714, which argues that it is acceptable for VoIP flows to assume
that the network limitation is in bytes per second (Bps) rather in
packets per second (pps), and to have the same sending rate in bytes
Floyd/Kohler Section 2. [Page 5]
INTERNET-DRAFT Expires: January 2006 July 2005
per second as a TCP flow with 1500-byte packets and the same packet
drop rate. RFC 3714 states the following:
"While the ideal would be to have a transport protocol that is
able to detect whether the bottleneck links along the path are
limited in Bps or in pps, and to respond appropriately when the
limitation is in pps, such an ideal is hard to achieve. We would
not want to delay the deployment of congestion control for
telephony traffic until such an ideal could be accomplished. In
addition, we note that the current TCP congestion control
mechanisms are themselves not very effective in an environment
where there is a limitation along the reverse path in pps.
While the TCP mechanisms do provide an incentive to use large
data packets, TCP does not include any effective congestion
control mechanisms for the stream of small acknowledgement
packets on the reverse path. Given the arguments above, it
seems acceptable to us to assume a network limitation in Bps
rather than in pps in considering the minimum sending rate of
telephony traffic."
Translating the discussion in [RFC 3714] to the congestion control
mechanisms of TFRC, it seems acceptable to standardize a variant of
TFRC that allows VoIP flows sending small packets to achieve a rough
fairness with TCP flows in terms of the sending rate in Bps, rather
than in terms of the sending rate in pps. This is accomplished by a
small modification to TFRC, as described below.
However, because the bottlenecks in the network in fact can include
limitations in pps as well as in Bps, we pay special attention to
the potential dangers of encouraging a large deployment of best-
effort traffic in the Internet consisting entirely of small packets.
This is discussed in more detail in Section 4.3. In addition, as
again discussed in Section 4.3, the VoIP variant of TFRC includes
the limitation of the Min Interval between packets of 10 ms.
The VoIP variant of TFRC essentially assumes that the small-packet
VoIP TFRC flow receives roughly the same packet drop rate as a
large-packet TFRC or TCP flow. As we show, this assumption is not
correct for all of the simulations in this document.
The VoIP variant of TFRC requires a modification in TFRC's
calculation of the loss event rate, because a VoIP TFRC connection
can send many small packets when a standard TFRC or TCP connection
would send a single large packet. It is not possible for a standard
TFRC or TCP connection to repeatedly send multiple packets per
round-trip time in the face of a high packet drop rate. As a
result, TCP and standard TFRC only respond to a single loss event
per round-trip time, and are still able to detect and respond to
Floyd/Kohler Section 2. [Page 6]
INTERNET-DRAFT Expires: January 2006 July 2005
increasingly heavy packet loss rates. However, in a highly-
congested environment, when a TCP connection might be sending, on
average, one large packet per round-trip time, a corresponding VoIP
TFRC connection might be sending many small packets per round-trip
time. As a result, in order to maintain fairness with TCP, and to
be able to detect changes in the degree of congestion, VoIP TFRC
needs to be sensitive to the actual packet drop rate during periods
of high congestion. This is discussed in more detail in the section
below.
3. VoIP Variant Congestion Control
TFRC uses the TCP throughput equation given in Section 3.1 of [RFC
3448], which gives the allowed sending rate X in bytes per second as
a function of the loss event rate, packet size, and round-trip time.
[RFC 3448] specifies that the packet size s used in the throughput
equation should be the packet size used by the application, or the
estimated mean packet size if there are variations in the packet
size depending on the data. This gives rough fairness with TCP
flows using the same packet size.
The VoIP variant changes this behavior in the following ways.
o The nominal packet size: The nominal packet size s is set to
1460 bytes. Following [RFC 3714], this provides a goal of
fairness, in terms of the sending rate in bytes per second, with
a TCP flow with 1460 bytes of application data per packet but
with the same packet drop rate.
o Taking packet headers into account: The allowed transmit rate X
in bytes per second is reduced by a factor that accounts for
packet header size. This gives the application some incentive,
beyond the Min Interval, not to use unnecessarily small packets.
In particular, we introduce a new parameter H, which represents
the expected size in bytes of network and transport headers to be
used on the TFRC connection's packets. This is used to reduce
the allowed transmit rate X as follows:
X <- X * s_true / (s_true + H),
where s_true is the true average data packet size for the
connection in bytes, excluding the transport and network headers.
The H parameter is set to the constant 40 bytes. Thus, if the
VoIP TFRC application used 40-byte data segments, the allowed
transmit rate X would be halved to account for the fact that half
of the sending rate would be used by the headers. Section 4.2
justifies this definition. However, a connection using the VoIP
Floyd/Kohler Section 3. [Page 7]
INTERNET-DRAFT Expires: January 2006 July 2005
variant MAY instead use a more precise estimate of H, based on
the actual network and transport headers to be used on the
connection's packets. For example, a DCCP connection [DCCP] over
IPv4, where data packets use the DCCP-Data packet type, and there
are no IP or DCCP options, could set H to 20 + 12 = 32 bytes.
o Measuring the loss event rate in times of high loss: During short
loss intervals (those at most two round-trip times), the loss
rate is computed by counting the actual number of packets lost or
marked, not by counting at most one loss event per loss interval.
Without this change, VoIP TFRC could send multiple packets per
round-trip time even in the face of heavy congestion, for a
steady-state behavior of multiple packets dropped each round-trip
time.
In standard TFRC, the TFRC receiver estimates the loss event rate
by calculating the average loss interval in packets, and
inverting to get the loss event rate. Thus, for a short loss
interval with N packets and K losses, standard TFRC calculates
the size of that loss interval as N packets, contributing to a
loss event rate of 1/N. However, for VoIP TFRC, for small loss
intervals of at most two round-trip times, if the loss interval
consists of N packets including K losses, the size of the loss
interval is calculated as N/K, contributing to a loss event rate
of K/N instead of 1/N.
o A minimum interval between packets: The VoIP variant of TFRC
enforces a Min Interval between packets of 10 ms. A flow that
wishes its transport protocol to exceed this Min Interval MUST
use the conventional TFRC equations, rather than the VoIP
variant. The motivation for this is discussed below.
4. VoIP Variant Discussion
4.1. The TCP Throughput Equation
The VoIP variant of TFRC uses the TCP throughput equation given in
[RFC 3448]. As shown in Table 1 of [RFC 3714], for high packet drop
rates, this throughput equation gives rough fairness with most
aggressive possible current TCP: a SACK TCP flow using timestamps
and ECN. Because it is not recommended for routers to use ECN-
marking in highly-congested environments (e.g., with packet drop
rates greater than 10%), we note that it would be useful to have a
throughput equation with a somewhat more moderate sending rate for
packet drop rates of 40% and above.
Floyd/Kohler Section 4.1. [Page 8]
INTERNET-DRAFT Expires: January 2006 July 2005
4.2. Accounting for Header Size
[RFC 3714] makes the optimistic assumption that the limitation of
the network is in bandwidth in bytes per second (Bps), and not in
CPU cycles or in packets per second (pps). However, some attention
must be paid to the load in pps as well as to the load in Bps. Even
aside from the Min Interval, the VoIP variant of TFRC gives the
application some incentive to use fewer but larger packets, when
larger packets would suffice, by including the bandwidth used by the
packet header in the allowed sending rate.
As an example, a sender using 120-byte packets needs a TCP-friendly
rate of 128 Kbps to send 96 Kbps of application data. This is
because the TCP-friendly rate is reduced by a factor of
s_true/(s_true + H) = 120/160, to account for the effect of packet
headers. If the sender suddenly switched to 40-byte data segments,
the allowed sending rate would reduce to 64 Kbps of application
data; and one-byte data segments would reduce the allowed sending
rate to 3.12 Kbps of application data. (In fact, the Min Interval
would prevent senders from achieving these rates, since applications
using the VoIP variant cannot send more than 100 packets per
second.)
The VoIP variant assumes 40 bytes for the header size, although the
header could be larger (due to IP options, IPv6, IP tunnels, and the
like) or smaller (due to header compression) on the wire, because
using the exact header size in bytes would have little additional
benefit. The VoIP variant's use of an assumed 40-byte header is
sufficient to get a rough estimate of the throughput, and to give
the application some incentive not to use unnecessarily-many small
packets. Because we are only aiming at rough fairness, and at a
rough incentive for applications, the use of a 40-byte header in the
calculations of the header bandwidth seems sufficient.
4.3. The VoIP Min Interval
The header size calculation provides an incentive for applications
to use fewer, but larger, packets. Another incentive is that when
the path limitation is in pps, the application using more small
packets is likely to cause higher packet drop rates, and to have to
reduce its sending rate accordingly. That is, if the congestion is
in terms of pps, then the flow sending more pps will increase the
packet drop rate, and have to adjust its sending rate accordingly.
However, the increased congestion caused by the use of small packets
in an environment limited by pps is experienced not only by the flow
using the small packets, but by all of the competing traffic on that
congested link. These incentives are therefore insufficient to
provide sufficient protection for pps network limitations.
Floyd/Kohler Section 4.3. [Page 9]
INTERNET-DRAFT Expires: January 2006 July 2005
The VoIP variant for TFRC, then, includes a Min Interval of 10 ms.
This provides additional restrictions on the use of unnecessarily
many small packets.
One justification for the Min Interval is the practical one that the
applications that currently want to send small packets are the VoIP
applications that send at most one packet every 10 ms, so this
restriction does not affect current traffic. A second justification
is that there is no pressing need for best-effort traffic in the
current Internet to send small packets more frequently than once
every 10 ms (rather than taking the 10 ms delay at the sender, and
merging the two small packets into one larger one). This 10 ms
delay for merging small packets is likely to be dominated by the
network propagation, transmission, and queueing delays of best-
effort traffic in the current Internet. As a result, our judgement
would be that the benefit to the user of having less than 10 ms
between packets is outweighed by the benefit to the network of
avoiding unnecessarily many small packets.
The Min Interval causes the VoIP variant of TFRC not to support
applications sending small packets very frequently. Consider a TFRC
flow with a fixed packet size of 100 bytes, but with a variable
sending rate and a fairly uncongested path. When this flow was
sending at most 100 pps, it would be able to use the VoIP variant of
TFRC. If the flow wished to increase its sending rate to more than
100 pps, but to keep the same packet size, it would no longer be
able to achieve this with the VoIP variant to TFRC, and would have
to switch to the default TFRC, receiving a dramatic, discontinuous
decrease in its allowed sending rate. This seems not only
acceptable, but desirable for the global Internet.
What is to prevent flows from opening multiple connections, each
with a 10 ms Min Interval, and thereby getting around the limitation
of the Min Interval? Obviously, there is nothing to prevent flows
from doing this, just as there is currently nothing to prevent flows
from using UDP, or from opening multiple parallel TCP connections,
or from using their own congestion control mechanism. Of course,
implementations or middleboxes are also free to limit the number of
parallel TFRC connections opened to the same destination in times of
congestion, if that seems desirable. And flows that open multiple
parallel connections are subject to the inconveniences of reordering
and the like. But even without a mechanism to prevent flows from
subverting the Min Interval by opening multiple parallel
connections, it seems useful to include the Min Interval in the VoIP
variant of TFRC.
Floyd/Kohler Section 4.3. [Page 10]
INTERNET-DRAFT Expires: January 2006 July 2005
4.4. Counting Packet Losses
It is not possible for a TCP connection to persistently send
multiple packets per round-trip time in the face of high congestion,
with a steady-state with multiple packets dropped per round-trip
time. For TCP, when one or more packets are dropped each round-trip
time, the sending rate is quickly dropped to less than one packet
per round-trip time. In addition, for TCP with Tahoe, NewReno, or
SACK congestion control mechanisms, the response to congestion is
largely independent of the number of packets dropped per round-trip
time.
As a result, standard TFRC can best achieve fairness with TCP, even
in highly congested environments, by calculating the loss event rate
rather than the packet drop rate, where a loss event is one or more
packets dropped or marked from a window of data.
However, with the VoIP variant of TFRC, it is no longer possible to
achieve fairness with TCP or with standard TFRC by counting only the
loss event rate [WBL04]. Instead of sending one large packet per
round-trip time, the VoIP variant of TFRC could be sending N small
packets (where N small packets equal one large 1500-byte packet).
The loss measurement used with the VoIP variant of TFRC has to be
able to detect a connection that is sending multiple packets per
round-trip time in the face of multiple packet losses or marks per
round-trip time.
In the VoIP variant of TFRC, the loss event rate is calculated by
counting at most one loss event in loss intervals longer than two
round-trip times, and by counting each packet lost or marked in
shorter loss intervals. In particular, for a short loss interval
with N packets, including K lost or marked packets, the loss
interval length is calculated as N/K, instead as N. The average
loss interval I_mean is still averaged over the most recent eight
loss intervals, as specified in Section 5.4 of RFC 3448. Thus, if
eight successive loss intervals are short loss intervals with N
packets and K losses, the loss event rate is calculated as K/N,
rather than as 1/N.
5. A Comparison with RFC 3714
6. The VoIP Variant with Applications that Modify the Packet Size
To be done.
Floyd/Kohler Section 6. [Page 11]
INTERNET-DRAFT Expires: January 2006 July 2005
7. Simulation Results
7.1. Simulations with Configured Drop Rates
In this section we describe simulation results from simulations
comparing the throughput of standard (SACK) TCP flows, TCP flows
with timestamps and ECN, VoIP TFRC flows, and standard TFRC (Stnd
TFRC) flows. In these simulations we configure the router to
randomly drop or mark packets at a specified rate, independently of
the packet size. For each specified packet drop rate, we give a
flow's average sending rate in Kbps over the second half of a
100-second simulation, averaged over ten flows.
Packet TCP ECN TCP TFRC
DropRate SendRate SendRate SendRate
-------- -------- -------- --------
0.001 2020.85 1904.61 982.09
0.005 811.10 792.11 878.08
0.01 515.45 533.19 598.90
0.02 362.93 382.67 431.41
0.04 250.06 252.64 284.82
0.05 204.48 218.16 268.51
0.066 176.40 178.16 211.05
0.1 143.30 148.41 146.03
0.2 78.65 93.23* 55.14
0.3 26.26 59.65* 32.87
0.4 9.87 47.79* 25.45
0.5 3.53 32.01* 18.52
Table 1:
"Total Sending Rates (Kbps) for Configured Packet Drop Rates.
The TFRC flow uses 1460-byte data packets, with a maximum
data sending rate of 1000 Kbps."
* Note: These ECN scenarios are not realistic, as routers are
not likely to mark packets when packet drop/mark rates are 20%
or higher.
Table 1 shows the sending rate for a TCP and a standard TFRC flow
for a range of configured packet drop rates, when both flows have
1460-byte data packets, in order to illustrate the relative fairness
of TCP and TFRC when both flows use the same packet size. For
example, a packet drop rate of 0.1 means that 10% of the TCP and
TFRC packets are dropped. There is good relative fairness until the
packet drop percentages reach 40 and 50%, when the TFRC flow
receives three to five times more bandwidth than the standard TCP
flow. We note that an ECN TCP flow would receive a higher
Floyd/Kohler Section 7.1. [Page 12]
INTERNET-DRAFT Expires: January 2006 July 2005
throughput than the TFRC flow, but this would not be relevant in
practice, as routers are advised to drop rather than mark packets
during high levels of congestion.
Packet TCP ECN TCP VoIP TFRC Stnd TFRC
DropRate SendRate SendRate SendRate SendRate
-------- -------- -------- -------- --------
0.001 1787.54 1993.03 17.71 17.69
0.005 785.11 823.75 18.11 17.69
0.01 533.38 529.01 17.69 17.80
0.02 317.16 399.62 17.69 13.41
0.04 245.42 260.57 17.69 8.84
0.05 216.38 223.75 17.69 7.63
0.066 174.07 184.37 17.69 6.46
0.1 142.75 138.36 17.69 4.29
0.2 58.61 91.54* 17.80 1.94
0.3 21.62 63.96* 10.26 1.00
0.4 10.51 41.74* 4.78 0.77
0.5 1.92 19.03* 2.41 0.56
Table 2:
"Total Sending Rates (Kbps) for Configured Packet Drop Rates.
The TFRC flows use 14-byte data packets, with a maximum
data sending rate of 5.6 Kbps."
* Note: These ECN scenarios are not realistic, as routers are
not likely to mark packets when packet drop/mark rates are 20%
or higher.
Table 2 shows the results of simulations where each VoIP TFRC flow
has a maximum data sending rate of 5.6 Kbps, with 14-byte data
packets and a 32-byte packet header for DCCP and IP. Each TCP flow
has a receive window of 100 packets and a data packet size of 1460
bytes, with a 40-byte packet header for TCP and IP. The TCP flow
uses Sack TCP with Limited Transmit, but without timestamps or ECN.
Each flow has a round-trip time of 240 ms.
The TFRC sending rate in Table 2 is the sending rate for the 14-byte
data packet with the 32-byte packet header. Thus, only 30% of the
TFRC sending rate is for data, and with a packet drop rate of p,
only a fraction 1-p of that data makes it to the receiver. Thus,
the TFRC data receive rate can be considerably less than the TFRC
sending rate in the table. Because TCP uses large packets, 97% of
the TCP sending rate is for data, and the same fraction 1-p of that
data makes it to the receiver.
Floyd/Kohler Section 7.1. [Page 13]
INTERNET-DRAFT Expires: January 2006 July 2005
Table 2 shows that for the 5.6 Kbps data stream with TFRC, Standard
TFRC (Stnd TFRC) gives a very poor sending rate in bps, relative to
the sending rate for the large-packet TCP connection. In contrast,
the sending rate for the VoIP TFRC flow is relatively close to the
desired goal of fairness in bps with TCP.
Table 2 shows that with VoIP TFRC, the 5.6 Kbps data stream doesn't
reduce its sending rate until packet drop rates greater than 20%, as
desired. With packet drop rates of 30-40%, the sending rate for the
VoIP TFRC flow is somewhat less than that of the average large-
packet TCP flow, while for packet drop rates of 50% the sending rate
for the VoIP TFRC flow is somewhat greater than that of the average
large-packet TCP flow.
We note that the high sending rate for ECN TCP in environments with
high marking rates is largely irrelevant, as routers are advised to
drop rather than mark ECN-capable packets in times of high
congestion. The sending rate of a TCP connection using timestamps
is similar to the sending rate shown for a standard TCP connection
without timestamps.
Byte TCP ECN TCP VoIP TFRC Stnd TFRC
DropRate SendRate SendRate SendRate SendRate
-------- -------- -------- -------- --------
0.00001 423.02 406.44 17.69 17.69
0.0001 117.41 114.34 17.69 17.69
0.001 0.41 3.38* 17.69 8.37
0.005 0.26 0.26* 18.39 1.91
0.01 0.31 0.26* 7.07 0.84
0.02 0.29 0.26* 1.61 0.43
0.04 0.12 0.26* 0.17 0.12
0.05 0.15 0.26* 0.08 0.06
Table 3:
"Total Sending Rates (Kbps) for Configured Byte Drop Rates.
The TFRC flows use 14-byte data packets, with a maximum
data sending rate of 5.6 Kbps."
* Note: These ECN scenarios are not realistic, as routers are
not likely to mark packets when packet drop/mark rates are 20%
or higher.
Floyd/Kohler Section 7.1. [Page 14]
INTERNET-DRAFT Expires: January 2006 July 2005
Byte TCP Pkt TFRC Pkt TCP/TFRC
DropRate DropRate DropRate Pkt Drop Ratio
-------- -------- -------- --------------
0.00001 0.015 0.0006 26.59
0.0001 0.13 0.0056 24.94
0.001 0.77 0.054 14.26
0.005 0.99 0.24 4.08
0.01 1.0 0.43 2.32
0.05 1.0 0.94 1.05
Table 4:
"Converting Byte Drop Rates to Packet Drop Rates,
for 1500-byte TCP packets and 56-byte TFRC packets."
In contrast, Table 3 shows the TCP and TFRC send rates for various
byte drop rates. For these simulations, for each *byte*, the packet
containing that byte is dropped with probability p. Table 4
converts the byte drop rate p to packet drop rates for the TCP and
TFRC packets, where the packet drop rate for an N-byte packet is
1-(1-p)^N. Thus, a byte drop rate of 0.001, with each byte being
dropped with probability 0.001, converts to a packet drop rate of
0.77, or 77%, for the 1500-byte TCP packets, and a packet drop rate
of 0.054, or 5.4%, for the 56-byte TFRC packets.
The last column of Table 3 shows the ratio between the TCP packet
drop rate and the TFRC packet drop rate. For low byte drop rates,
this ratio is close to 26.8, the ratio between the TCP and TFRC
packet sizes. For high byte drop rates, where even most small TFRC
packets are likely to be dropped, this drop ratio approaches 1.
As Table 3 shows. with moderate byte drop rates (between 0.1% and
4%), even the standard TFRC flow with 14-byte data packets has
higher throughput than the large-packet TCP flow. In these regimes,
the packet drop rate for TCP is greater than 50%, and the TCP
sending rate no longer varies as 1/sqrt(p), as it does with smaller
packet drop rates. With these equal byte drop rates for the TCP and
TFRC flows, the VoIP variant of TFRC makes the unfairness in favor
of TFRC even worse, with the VoIP TFRC flow receiving significantly
higher throughput than the TCP flow for byte drop rates from 0.1% to
2%.
Floyd/Kohler Section 7.1. [Page 15]
INTERNET-DRAFT Expires: January 2006 July 2005
Packet TCP ECN TCP VoIP TFRC Stnd TFRC
DropRate SendRate SendRate SendRate SendRate
-------- -------- -------- -------- --------
0.001 1908.98 1869.24 183.45 178.35
0.005 854.69 835.10 185.06 138.06
0.01 564.10 531.10 185.33 92.43
0.02 365.38 369.10 185.57 62.18
0.04 220.80 257.81 185.14 45.43
0.05 208.97 219.41 180.08 39.44
0.066 179.04 184.68 168.51 31.16
0.1 141.67 143.88 127.33 21.96
0.2 62.66 91.87* 54.66 9.40
0.3 16.63 65.52* 24.50 4.73
0.4 6.62 42.00* 13.47 3.35
0.5 1.01 21.34* 10.51 2.92
Table 5:
"Total Sending Rates (in Kbps) for Configured Packet Drop Rates.
The TFRC flows use 200-byte data packets, with a maximum
data sending rate of 160 Kbps."
* Note: These ECN scenarios are not realistic, as routers are
not likely to mark packets when packet drop/mark rates are 20%
or higher.
Using configured packet drop rates, Table 5 compares the average
per-flow sending rates when the TFRC flow has a maximum data sending
rate of 160 Kbps, with the application generating 200-byte data
packets at 100 packets per second. As expected with equal packet
drop rates, the performance of Standard TFRC is quite poor, while
the performance of VoIP TFRC is essentially as desired for packet
drop rates up to 30%. Again as expected, with packet drop rates of
40-50% the VoIP TFRC sending rate is somewhat higher than desired.
In general, Tables 2 and 5 show acceptable performance for VoIP TFRC
in environments with stable packet drop rates, where the decision to
drop a packet is independent of the packet size. However, in
realistic environments, the packet size might affect the likelihood
that a packet is dropped. For example, with heavy congestion and a
Drop Tail queue with a fixed number of bytes rather than a fixed
number of packet-sized buffers, small packets might be more likely
than large packets to find room at the end of an almost-full queue.
As a further complication, in a scenario with Active Queue
Management, the AQM mechanism could either be in packet mode,
dropping each packet with equal probability, or in byte mode,
dropping each byte with equal probability. Sections 7.2 and 7.3
show simulations with packets dropped at Drop Tail or AQM queues,
Floyd/Kohler Section 7.1. [Page 16]
INTERNET-DRAFT Expires: January 2006 July 2005
rather that from a probabilistic process.
VoIP mode for TFRC has been added to the NS simulator, and is
illustrated in the validation test "./test-all-friendly" in the
directory tcl/tests. The simulation scripts for the simulations in
this document will be made available in
"http://www.icir.org/tfrc/voipsims.html".
7.2. Packet Dropping Behavior at Routers with DropTail Queues
One of the problems with comparing the throughput of two flows using
different packet sizes is that the packet size itself can influence
the packet drop rate [V00, WBL04].
The default TFRC, without the VoIP variant, was designed for rough
fairness with TCP, for TFRC and TCP flows with the same packet size
and experiencing the same packet drop rate. When the issue of
fairness between flows with different packets sizes is addressed, it
matters whether the packet drop rates experienced by the flows is
related to the packet size. That is, are small VoIP packets just as
likely to be dropped as large TCP packets, or are the smaller
packets less likely to be dropped [WBL04]? And what is the
relationship between the packet-dropping behavior of the path, and
the loss event measurements of TFRC?
Web TCP TCP VoIP_TFRC VoIP_TFRC
Sessions DropRate SendRate DropRate SendRate
-------- -------- -------- -------- --------
10 0.04 316.18 0.05 183.05
25 0.07 227.47 0.07 181.23
50 0.08 181.10 0.08 178.32
100 0.14 85.97 0.12 151.42
200 0.17 61.20 0.14 73.88
400 0.20 27.79 0.18 36.81
800 0.29 3.50 0.27 16.33
1600 0.37 0.63 0.33 6.29
Table 6:
"Simulation Results with Drop-Tail Queues in Packets."
Table 6 shows the results of the second half of 100-second
simulations, with five TCP connections and five VoIP TFRC
connections competing with web traffic in a topology with a 3 Mbps
shared link. The VoIP TFRC application generates 200-byte data
packets every 10 ms, for a maximum data rate of 160 Kbps. The five
TCP connections have roundtrip times from 40 to 240 ms, and the five
TFRC connections have the same set of round-trip times. The SACK
Floyd/Kohler Section 7.2. [Page 17]
INTERNET-DRAFT Expires: January 2006 July 2005
TCP connections in these simulations use the default parameters in
the NS simulator, with Limited Transmit, and a minimum RTO of 200
ms. Adding timestamps to the TCP connection didn't change the
results appreciably. The simulations include reverse-path traffic,
to add some small control packets to the forward path, and some
queueing delay to the reverse path. The number of web sessions is
varied to create different levels of congestion. The DropTail queue
is in units of packets, which each packet in the queue requires a
single buffer, regardless of the packet size.
Table 6 shows the average TCP and TFRC sending rates, each averaged
over the five flows. As expected, the VoIP TCP flows see similar
packet drop rates as the TCP flows, though the VoIP TFRC flows
receives higher throughput than the TCP flows with packet drop rates
of 25% or higher.
Web TCP TCP VoIP_TFRC VoIP_TFRC
Sessions DropRate SendRate DropRate SendRate
-------- -------- -------- -------- --------
10 0.06 239.81 0.00 185.19
25 0.09 189.02 0.01 184.95
50 0.14 99.46 0.01 185.07
100 0.20 16.42 0.02 183.77
200 0.26 4.46 0.03 181.98
400 0.29 4.61 0.05 151.88
800 0.49 1.01 0.08 113.10
1600 0.65 0.67 0.12 65.17
Table 7:
"Simulation Results with Drop-Tail Queues in Bytes."
However, the fairness results can change significantly if the
DropTail queue at the congested output link is in units of bytes
rather than packets. For a queue in packets, the queue has a fixed
number of buffers, and each buffer can hold exactly one packet,
regardless of its size in bytes. For a queue in bytes, the queue
has a fixed number of *bytes*, and an almost-full queue might have
room for a small packet but not for a large one. This, for a
simulation with a Drop-Tail queue in bytes, large packets are more
likely to be dropped than are small ones. The NS simulator doesn't
yet have a more realistic intermediate model, where the queue has a
fixed number of buffers, each buffer has a fixed number of bytes,
and each packet would require one or more free buffers. In this
model, a small packet would use one buffer, while a larger packet
would require several buffers.
Floyd/Kohler Section 7.2. [Page 18]
INTERNET-DRAFT Expires: January 2006 July 2005
As Table 7 shows, with a DropTail queue in bytes, the VoIP TFRC flow
sees a much smaller drop rate than the TCP flow, and as a
consequence receives a much larger sending rate. For example, when
the five TCP flows and five VoIP TFRC flows share the link with 800
web sessions, the five TCP flows see an average drop rate of 49% in
the second half of the simulation, while the five VoIP TFRC flows
receive an average drop rate of 8%, and as a consequence receive
more than 100 times the throughput of the TCP flows. This raises
serious questions about making the assumption that flows with small
packets see the same packet drop rate as flows with larger packets.
Further work will have to include an investigation into the range of
realistic Internet scenarios, in terms of whether large packets are
considerably more likely to be dropped than are small ones.
7.3. Packet Dropping Behavior at Routers with AQM
As expected, the packet dropping behavior also can be varied by
varying the Active Queue Management (AQM) mechanism in the router.
When the routers use RED (Random Early Detection), there are several
parameters than can affect the packet dropping or marking behavior
as a function of the packet size.
First, as with DropTail, the RED queue can be either in units of
packets or of bytes. This can affect the packet dropping behavior
when the RED mechanism is unable to control the average queue size,
and the queue overflows.
Second, and orthogonally, RED can be either in packet mode or in
byte mode. In packet mode, each *packet* has the same probability
of being dropped by RED, while in byte mode, each *byte* has the
same probability of being dropped. In packet mode, large-packet and
small-packet flows receive roughly the same packet drop rate, while
in byte mode, with small to moderate levels of congestion, large-
packet and small-packet flows with the same throughput in bps
receive roughly the same *number* of packet drops. The simulations
reported in the appendix show that for RED in packet mode, the
packet drop rates for the VoIP TFRC flows are similar to those for
the TCP flows, with a resulting acceptable throughput for the VoIP
TFRC flows. This is true with the queue in packets or in bytes,
and with or without Adaptive RED (discussed below). As we show
below, this fairness between TCP and VoIP TFRC flows does not hold
for RED in byte mode.
The third RED parameter that affects the packet dropping or marking
behavior as a function of packet size is whether the RED mechanism
is using Standard RED or Adaptive RED, where the dropping function
is varied as the packet drop rate changes. The use of Adaptive RED
allows the RED mechanism to function more effectively in the
Floyd/Kohler Section 7.3. [Page 19]
INTERNET-DRAFT Expires: January 2006 July 2005
presence of high packet drop rates (e.g., greater than 10%).
Without Adaptive RED, there is a fixed dropping threshold, and all
arriving packets are dropped when the dropping or marking rate
exceeds this threshold. In contrast, with Adaptive RED, the
dropping function is adapted to accommodate these high-drop-rate
regimes. One consequence is that when byte mode is combined with
Adaptive RED, the byte mode extends even to high-drop-rate regimes.
When byte mode is used with standard RED, however, the byte mode is
no longer in use when the drop rate exceeds the fixed dropping
threshold (set by default to 10% in the NS simulator).
In the simulations in this section, we explore the VoIP TFRC
behavior over some of this range of scenarios. In this simulations,
as in Section 7.2 above, the application for the VoIP TFRC flow uses
200-byte data packets, generating 100 packets per second.
Web TCP TCP VoIP_TFRC VoIP_TFRC
Sessions DropRate SendRate DropRate SendRate
-------- -------- -------- -------- --------
10 0.05 305.76 0.04 182.82
25 0.06 224.16 0.06 175.91
50 0.09 159.12 0.08 152.51
100 0.13 90.77 0.11 106.13
200 0.14 48.53 0.14 70.25
400 0.20 22.08 0.19 41.50
800 0.27 3.55 0.25 17.50
1600 0.42 1.87 0.34 8.81
Table 8:
"Simulation Results with RED Queues, Packet Mode.
RED in packet mode, queue in packets, standard RED."
For the simulations in Table 8, with a congested router with a RED
queue in packet mode, the results are similar to those in Table 6
above. The VoIP TCP flow receives similar packet drop rates as the
TCP flow, though it receives higher throughput in the more congested
environments. The simulations are similar with the queue in bytes,
and with or without Adaptive RED. These results seems generally
acceptable.
Floyd/Kohler Section 7.3. [Page 20]
INTERNET-DRAFT Expires: January 2006 July 2005
Web TCP TCP VoIP_TFRC VoIP_TFRC
Sessions DropRate SendRate DropRate SendRate
-------- -------- -------- -------- --------
10 0.04 286.90 0.01 184.92
25 0.07 192.67 0.02 184.06
50 0.11 92.98 0.04 181.69
100 0.17 57.02 0.07 154.88
200 0.17 9.55 0.11 120.83
400 0.29 7.68 0.16 77.38
800 0.36 1.97 0.23 23.79
1600 0.51 0.87 0.30 11.00
Table 9:
"Simulation Results with RED Queues, Byte Mode.
RED in byte mode, queue in bytes, standard RED."
Table 9 shows that with a standard RED queue in byte mode, there is
a somewhat greater different between the packet drop rates between
the TCP and VoIP TFRC flows, particularly for lower packet drop
rates. For the simulation in Table 9, the packet drop rates for the
TCP flows can range from 1 1/2 to four times greater than the packet
drop rates for the VoIP TFRC flows. However, because the VoIP TFRC
flow has an upper bound on the sending rate, its sending rate is not
affected in the lower packet-drop-rate regimes; its sending rate is
only affected in the regimes with packet drop rates of 10% or more.
While the sending rate for VoIP TFRC in the scenarios in Table 9
with higher packet drop rates are greater than desired, the results
are significantly better than that of VoIP flows with no congestion
control at all.
Web TCP TCP VoIP_TFRC VoIP_TFRC
Sessions DropRate SendRate DropRate SendRate
-------- -------- -------- -------- --------
10 0.04 297.74 0.02 185.06
25 0.07 209.42 0.03 184.06
50 0.10 85.34 0.04 182.30
100 0.16 28.18 0.05 181.17
200 0.19 4.18 0.06 177.70
400 0.31 1.87 0.08 154.40
800 0.29 0.77 0.06 170.01
1600 0.59 0.48 0.02 173.91
Table 10:
"Simulation Results with RED Queues, Byte Mode.
RED in byte mode, queue in bytes, Adaptive RED."
Floyd/Kohler Section 7.3. [Page 21]
INTERNET-DRAFT Expires: January 2006 July 2005
In contrast, for the simulations in Table 10, the congested router
uses an Adaptive RED queue in byte mode. For this router, the
output queue is in units of bytes rather than of packets, each
*byte* is dropped with the same probability, and because of the use
of Adaptive RED, this byte-dropping mode extends even for the high-
packet-drop-rate regime.
As Table 10 shows, for a scenario with Adaptive RED in byte mode,
the packet drop rate for the VoIP TFRC traffic is *much* lower than
that for the TCP traffic, and as a consequence, the sending rate for
the VoIP TFRC traffic in a highly congested environment is *much*
higher than that of the TCP traffic. In fact, in these scenarios
the TFRC VoIP congestion control mechanisms are largely ineffective
for the VoIP traffic.
We note that the unfairness in these simulations, in favor of VoIP
TFRC, is even greater than the unfairness shown in Table 7 for a
DropTail queue in bytes. At the same time, it is not known if there
is any deployment in the Internet of any routers with Adaptive RED
in byte mode, or of any AQM mechanisms with similar behavior; we
don't even know the extent of the deployment of standard RED, or or
any of the proposed AQM mechanisms.
8. Discussion
The goal of the VoIP variant of TFRC has been for the TCP flows and
the VoIP TFRC flows to have rough fairness in the sending rate in
bps, in a scenario where each packet receives roughly the same
probability of being dropped. In a scenario where large packets are
more likely to be dropped than small packets, or where flows with a
bursty sending rate are more likely to have packets dropped than are
flows with a smooth sending rate, flows using the VoIP variant of
TFRC could receive more bandwidth than competing TCP flows.
The VoIP variant of TFRC limits the sending rate in packet per
second. The simulations by Tom Phelan explore how a limitation in
sending rate complicates the issue of exploring the fairness between
TCP and VoIP TFRC flows.
For applications with a maximum sending rate of 96 Kbps or less,
VoIP TFRC only restricts the sending rate when the packet drop rate
is fairly high. In this regime, the performance of TFRC is very
much determined by the accuracy of the TCP response function in
representing the actual sending rate of a TCP connection. In this
regime of high packet drop rates, the performance of the TCP
connection is very much affected by the TCP algorithm (e.g., SACK or
not), by the minimum RTO, by the use or not of Limited Transmit, by
Floyd/Kohler Section 8. [Page 22]
INTERNET-DRAFT Expires: January 2006 July 2005
the use of timestamps and/or of ECN, and the like. It is good to
insure that simulations or experiments exploring fairness include
the exploration of fairness with the most aggressive TCP mechanisms
conformance with the current standards. Our simulations use SACK
TCP with Limited Transmit and with a minimum RTO of 200 ms. Adding
the use of timestamps has not made a big difference. We haven't
used ECN, because our judgement is that the use of ECN is not
advisable in high-packet-dropping regimes.
9. Implementation Issues
TBA
10. Security Considerations
TBA
11. IANA Considerations
There are no IANA considerations in this document.
12. Thanks
We thank Tom Phelan for discussions of the VoIP variant of TFRC and
for his paper exploring the fairness between TCP and VoIP TFRC
flows. We thank Joerg Widmer for feedback on earlier versions of
this draft. We also thank the DCCP Working Group for feedback and
discussions.
Normative References
[RFC 2119] S. Bradner. Key Words For Use in RFCs to Indicate
Requirement Levels. RFC 2119.
[RFC 2434] T. Narten and H. Alvestrand. Guidelines for Writing an
IANA Considerations Section in RFCs. RFC 2434.
[RFC 2581] M. Allman, V. Paxson, and W. Stevens. TCP Congestion
Control. RFC 2581.
[RFC 3448] M. Handley, S. Floyd, J. Padhye, and J. Widmer, TCP
Friendly Rate Control (TFRC): Protocol Specification, RFC 3448,
Proposed Standard, January 2003.
Informative References
[CCID 3 PROFILE] S. Floyd, E. Kohler, and J. Padhye. Profile for
DCCP Congestion Control ID 3: TFRC Congestion Control. draft-
Floyd/Kohler [Page 23]
INTERNET-DRAFT Expires: January 2006 July 2005
ietf-dccp-ccid3-06.txt, work in progress, October 2004.
[DCCP] E. Kohler, M. Handley, and S. Floyd. Datagram Congestion
Control Protocol, draft-ietf-dccp-spec-08.txt, work in progress,
October 2004.
[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/".
[P04] T. Phelan, TFRC with Self-Limiting Sources, October 2004. URL
"http://www.phelan-4.com/dccp/".
[RFC 2861] M. Handley, J. Padhye, and S. Floyd. TCP Congestion
Window Validation. RFC 2861, June 2000.
[RFC 3714] S. Floyd and J. Kempf, Editors. IAB Concerns Regarding
Congestion Control for Voice Traffic in the Internet. RFC 3714.
[V00] P. Vasallo. Variable Packet Size Equation-Based Congestion
Control. ICSI Technical Report TR-00-008, April 2000. URL
"http://www.icsi.berkeley.edu/techreports/2000.abstracts/
tr-00-008.html".
[WBL04] J. Widmer, C. Boutremans, and Jean-Yves Le Boudec.
Congestion Control for Flows with Variable Packet Size, ACM CCR,
34(2), 2004.
Authors' Addresses
Sally Floyd <floyd@icir.org>
ICSI Center for Internet Research
1947 Center Street, Suite 600
Berkeley, CA 94704
USA
Eddie Kohler <kohler@cs.ucla.edu>
4531C Boelter Hall
UCLA Computer Science Department
Los Angeles, CA 90095
USA
Floyd/Kohler [Page 24]
INTERNET-DRAFT Expires: January 2006 July 2005
13. Related Work on VoIP Variants of TFRC
Other proposals for variants of TFRC for applications with variable
packet sizes include [WBL04] and [V00]. [V00] proposed that TFRC
should be modified so that flows are not penalized by sending
smaller packets. In particular, [V00] proposes using the path MTU
in the TCP-friendly equation, instead of the actual packet size used
by TFRC, and counting the packet drop rate by using an estimation
algorithm that aggregates both packet drops and received packets
into MTU-sized units.
[WBL04] also argues that adapting TFRC for variable packet sizes by
just using the packet size of a reference TCP flow in the TFRC
equation would not suffice in the high-packet-loss regime; such a
modified TFRC would have a strong bias in favor of smaller packets,
because multiple lost packets in a single round-trip time would be
aggregated into a single packet loss. [WBL04] proposes modifying
the loss measurement process to account for the bias in favor of
smaller packets.
The VoIP Variant proposed in our document differs from [WBL04] in
restricting its attention to flows that send at most 100 packets per
second. The VoIP Variant proposed in our document also differs from
the straw proposal discussed in [WBL04] in that the allowed
bandwidth includes the bandwidth used by packet headers.
[WBL04] discusses four methods for modifying the loss measurement
process, "unbiasing, "virtual packets", "random sampling", and "Loss
Insensitive Period (LIP) scaling". [WBL04] finds only the second
and third methods sufficiently robust when the network drops packets
independently of packet size. They find only the second method
sufficiently robust when the network is more likely to drop large
packets than small packets. Our method for calculating the loss
event rate is somewhat similar to the random sampling method
proposed in [WBL04], except that randomization is not used; instead
of randomization, the exact packet loss rate is computed for short
loss intervals, and the standard loss event rate calculation is used
for longer loss intervals. [WBL04] includes simulations with a
Bernoulli loss model, a Bernoulli loss model with a drop rate
varying over time, and a Gilbert loss model, as well as more
realistic simulations with a range of TCP and TFRC flows.
[WBL04] produces both a byte-mode and a packet-mode variant of the
TFRC transport protocol, for connections over paths with per-byte
and per-packet dropping respectively. We would argue that in the
absence of transport-level mechanisms for determining whether the
packet dropping in the network is per-packet, per-byte, or somewhere
in between, a single TFRC implementation is needed, independently of
Floyd/Kohler Section 13. [Page 25]
INTERNET-DRAFT Expires: January 2006 July 2005
the packet-dropping behaviors of the routers along the path. It
would of course be preferable to have a mechanism that gives roughly
acceptable behavior, to the connection and to the network as a
whole, on paths with both per-byte and per-packet dropping (and on
paths with multiple congested routers, some with per-byte dropping
mechanisms, some with per-packet dropping mechanisms, and some with
dropping mechanisms that lie somewhere between per-byte and per-
packet). A first step will be to investigate the range of behaviors
actually present in today's networks.
14. Simulation Results with RED Queue Management
Web TCP TCP VoIP_TFRC VoIP_TFRC
Sessions DropRate SendRate DropRate SendRate
-------- -------- -------- -------- --------
10 0.04 299.95 0.04 184.15
25 0.06 234.00 0.06 176.43
50 0.08 172.42 0.08 147.82
100 0.11 110.83 0.12 89.78
200 0.13 41.90 0.15 62.37
400 0.23 11.38 0.20 25.05
800 0.27 2.88 0.29 12.26
1600 0.34 0.62 0.35 6.78
Table 11:
"Simulation Results with RED Queues, Packet Mode.
RED in packet mode, queue in packets, Adaptive RED."
Floyd/Kohler Section 14. [Page 26]
INTERNET-DRAFT Expires: January 2006 July 2005
Web TCP TCP VoIP_TFRC VoIP_TFRC
Sessions DropRate SendRate DropRate SendRate
-------- -------- -------- -------- --------
10 0.04 319.87 0.03 183.32
25 0.05 246.38 0.05 175.27
50 0.08 148.18 0.07 152.02
100 0.12 96.38 0.11 92.87
200 0.18 43.30 0.17 55.87
400 0.24 12.58 0.21 20.25
800 0.30 4.22 0.27 20.08
1600 0.35 1.34 0.35 7.21
Table 12:
"Simulation Results with RED Queues, Packet Mode.
RED in packet mode, queue in bytes, Adaptive RED."
Web TCP TCP VoIP_TFRC VoIP_TFRC
Sessions DropRate SendRate DropRate SendRate
-------- -------- -------- -------- --------
10 0.04 326.74 0.03 184.79
25 0.05 260.50 0.04 180.28
50 0.08 173.62 0.07 154.04
100 0.11 81.94 0.10 103.87
200 0.16 48.10 0.14 60.50
400 0.25 8.64 0.19 32.55
800 0.35 7.68 0.26 14.62
1600 0.38 0.77 0.36 7.13
Table 13:
"Simulation Results with RED Queues, Packet Mode.
RED in packet mode, queue in bytes, standard RED."
15. A Discussion of Packet Size and Packet Dropping
This section gives a general summary of the relative advantages of
packet-dropping behavior independent of packet size, versus packet
dropping behavior where large packets are more likely to be dropped
than small ones.
Floyd/Kohler Section 15. [Page 27]
INTERNET-DRAFT Expires: January 2006 July 2005
Advantages of Packet Dropping Independent of Packet Size:
---------------------------------------------------------
1. Adds another incentive for end nodes to use large packets.
2. Matches an environment with a limitation in pps rather than
bps.
---------------------------------------------------------
Advantages of Packet Dropping as a Function of Packet Size:
---------------------------------------------------------
1. Small control packets are less likely to be dropped than are
large data packets, improving TCP performance.
2. Matches an environment with a limitation in bps rather than
pps.
3. Reduces the penalty of TCP and other transport protocols
against flows with small packets (where the allowed sending
rate is roughly a linear function of packet size).
4. A queue limited in bytes is better than a queue limited in
packets for matching the worst-case queue size to the
worst-case queueing delay in seconds.
---------------------------------------------------------
Full Copyright Statement
Copyright (C) The Internet Society 2005. 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 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.
Floyd/Kohler [Page 28]
INTERNET-DRAFT Expires: January 2006 July 2005
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 29]
Internet-Drafts are not archival documents, and copies of Internet-Drafts
that have been deleted from the directory are not available. The
Secretariat does not have any information regarding the future plans of
the author(s) or working group, if applicable, with respect to this
deleted Internet-Draft. For more information, or to request a copy of
the document, please contact the author(s) directly.
Draft Author(s):
S. Floyd <floyd@icir.org>
E. Kohler <kohler@aciri.org>