timestamps can have considerably higher sending rates than TCP
connections that do not use timestamps, in environments with high
packet drop rates. For TCP connections with fine-grained timestamps,
a valid round-trip time measurement is obtained when a retransmitted
packet is successfully received and acknowledged by the receiver; in
this case a backed-off retransmit timer can be un-backed-off as well.
For TCP connections without timestamps, a valid round-trip time
measurement is only obtained when the transmission of a new packet is
received and acknowledged by the receiver. This limits the
opportunities for the un-backing-off of a backed-off retransmit
timer. In this document, in considering relative fairness, we use a
TCP connection without timestamps, since this is the dominant use of
TCP in the Internet.
A separate claim that has sometimes been raised in terms of fairness
is that best-effort VoIP traffic is inherently more important that
other best-effort traffic (e.g., web surfing, peer-to-peer traffic,
or multi-player games), and therefore merits a larger share of the
bandwidth in times of high congestion. Our assumption in this
document is that TCP traffic includes pressing email messages,
business documents, and emergency information downloaded from web
pages, as well as the more recreational uses cited above. Thus, we
do not agree that best-effort VoIP traffic should be exempt from
end-to-end congestion control due to any claims of inherently more
valuable content. (One could equally logically argue that because
email and instant messaging are more efficient forms of communication
than VoIP in terms of bandwidth usage, as a result email and instant
messaging are more valuable uses of scarce bandwidth in times of high
congestion.) In fact, the network is incapable of making a judgment
about the relative user value of traffic. The default assumption is
that all best-effort traffic has equal value to the network provider
and to the user.
We note that this discussion of relative fairness does not in any way
challenge the right of ISPs to allocate bandwidth on congested links
to classes of traffic in any way that they choose. (For example,
administrators rate-limit the bandwidth used by peer-to-peer traffic
on some links in the network, to ensure that bandwidth is also
available for other classes of traffic.) This discussion merely
argues that there is no reason for entire classes of best-effort
traffic to be exempt from end-to-end congestion control.
4. Current efforts in the IETF
There are four efforts currently underway in IETF to address issues
of congestion control for real time traffic: an upgrade of the RTP
specification, TFRC, DCCP, and work on audio codecs.
4.1. RTP
RFC 1890, the original RTP Profile for Audio and Video Control, does
not discuss congestion control [RFC1890]. The revised document on
"RTP Profile for Audio and Video Conferences with Minimal Control"
[RFC3551] discusses congestion control in Section 2. [RFC3551] says
the following:
"If best-effort service is being used, RTP receivers SHOULD
monitor packet loss to ensure that the packet loss rate is within
acceptable parameters. Packet loss is considered acceptable if a
TCP flow across the same network path and experiencing the same
network conditions would achieve an average throughput, measured
on a reasonable timescale, that is not less than the RTP flow is
achieving. This condition can be satisfied by implementing
congestion control mechanisms to adapt the transmission rate (or
the number of layers subscribed for a layered multicast session),
or by arranging for a receiver to leave the session if the loss
rate is unacceptably high."
"The comparison to TCP cannot be specified exactly, but is
intended as an "order-of-magnitude" comparison in timescale and
throughput. The timescale on which TCP throughput is measured is
the round-trip time of the connection. In essence, this
requirement states that it is not acceptable to deploy an
application (using RTP or any other transport protocol) on the
best-effort Internet which consumes bandwidth arbitrarily and does
not compete fairly with TCP within an order of magnitude."
Note that [RFC3551] says that receivers "SHOULD" monitor packet loss.
[RFC3551] does not explicitly say that the RTP senders and receivers
"MUST" detect and respond to a persistent high loss rate. Since
congestion collapse can be considered a "danger to the Internet" the
use of "MUST" would be appropriate for RTP traffic in the best-effort
Internet, where the VoIP traffic shares a link with other traffic,
since "danger to the Internet" is one of two criteria given in RFC
2119 for the use of "MUST" [RFC2119]. Different requirements may
hold for a private best-effort IP network provisioned solely for
VoIP, where the VoIP traffic does not interact with the wider
Internet.
4.2. TFRC
As mentioned in RFC 3267, equation-based congestion control is one of
the possibilities for VoIP. TCP Friendly Rate Control (TFRC) is the
equation-based congestion control mechanism that has been
standardized in the IETF. The TFRC specification, "TCP Friendly Rate
Control (TFRC): Protocol Specification" [RFC3448], says the
following:
"TFRC ... is reasonably fair when competing for bandwidth with TCP
flows, but has a much lower variation of throughput over time
compared with TCP, making it more suitable for applications such
as telephony or streaming media where a relatively smooth sending
rate is of importance. ... TFRC is designed for applications
that use a fixed packet size, and vary their sending rate in
packets per second in response to congestion. Some audio
applications require a fixed interval of time between packets and
vary their packet size instead of their packet rate in response to
congestion. The congestion control mechanism in this document
cannot be used by those applications; TFRC-PS (for TFRC-
PacketSize) is a variant of TFRC for applications that have a
fixed sending rate but vary their packet size in response to
congestion. TFRC-PS will be specified in a later document."
There is no draft available for TFRC-PS yet, unfortunately, but
several researchers are still working on these issues.
4.3. DCCP
The Datagram Congestion Control Protocol (DCCP) is a transport
protocol being standardized in the IETF for unreliable flows, with
the application being able to specify either TCP-like or TFRC
congestion control [DCCP03].
DCCP currently has two Congestion Control IDentifiers or CCIDs; these
are CCID 2 for TCP-like congestion control and CCID 3 for TFRC
congestion control. As TFRC-PS becomes available and goes through
the standards process, we would expect DCCP to create a new CCID,
CCID 4, for use with TFRC-PS congestion control.
4.4. Adaptive Rate Audio Codecs
A critical component in the design of any real-time application is
the selection of appropriate codecs, specifically codecs that operate
at a low sending rate, or that will reduce the sending rate as
throughput decreases and/or packet loss increases. Absent this, and
in the absence of the response to congestion recommended in this
document, the real-time application is likely to significantly
increase the risk of Internet congestion collapse, thereby adversely
impacting the health of the deployed Internet. If the codec is
capable of reducing its bit rate in response to congestion, this
improves the scaling of the number of VoIP or TCP sessions capable of
sharing a congested link while still providing acceptable performance
to users. Many current audio codecs are capable of sending at a low
bit rate, in some cases adapting their sending rate in response to
congestion indications from the network.
RFC 3267 describes RTP payload formats for use with the Adaptive
Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) audio
codecs [RFC 3267]. The AMR codec supports eight speech encoding
modes having bit rates between 4.75 and 12.2 kbps, with the speech
encoding performed on 20 ms speech frames, and is able to reduce the
transmission rate during silence periods. The payload format
specified in RFC 3267 includes forward error correction (FEC) and
frame interleaving to increase robustness against packet loss
somewhat. The AMR codec was chosen by the Third Generation
Partnership Project (3GPP) as the mandatory codec for third
generation (3G) cellular systems, and RFC 3267 recommends that AMR or
AMR-WB applications using the RTP payload format specified in RFC
3267 use congestion control, though no specific mechanism is
recommended. RFC 3267 gives "Equation-Based Congestion Control for
Unicast Applications" as an example of a congestion control mechanism
suitable for real-time flows [FHPW00].
The "Internet Low Bit Rate Codec", iLBC, is an IETF effort to develop
an IPR-free codec for robust voice communication over IP [ILBRC].
The codec is designed for graceful speech quality degradation in the
case of lost packets, and has a payload bit rate of 13.33 kbps for 30
ms frames or 15.20 kbps for 20 ms frames.
There are several unencumbered low-rate codec algorithms in Ivox (the
Interactive VOice eXchange) [IVOX], with plans to add additional
variable rate codecs. For example, LPC2400 (a.k.a. LQ2400) is a 2400
bps LPC based codec with an enhancement to permit "silence
detection". The 2400 bps codec is reported to have a "slight robotic
quality" [A03] (even without the additional complications of packet
loss). The older multirate codec described in [KFK79, KF82] is an
LPC codec that works at two rates, 2.4 kbps and 9.6 kbps, and can
optionally send additional "residual" bits for enhanced quality at a
higher bit rate.
Off-the-shelf ITU-T vocoders such as G.711 were generally designed
explicitly for circuit-switched networks and are not as well-adapted
for Internet use, even with the addition of FEC on top.
4.5. Differentiated Services and Related Topics
The Differentiated Services Working Group [DIFFSERV], which concluded
in 2003, completed standards for the Differentiated Services Field
(DS Field) in the IPv4 and IPv6 Headers [RFC2474], including several
per-hop forwarding behaviors [RFC2597, RFC3246]. The Next Steps in
Signaling Working Group [NSIS] is developing an optimized signalling
protocol for QoS, based in part on earlier work of the Resource
Reservation Setup Protocol Working Group [RSVP]. We do not discuss
these and related efforts further in this document, since this
document concerns only that VoIP traffic that might be carried as
best-effort traffic over some congested link in the Internet.
5. Assessing Minimum Acceptable Sending Rates
Current IETF work in the DCCP and AVT working groups does not
consider the problem of applications that have a minimum sending rate
and are not able to go below that sending rate. This clearly must be
addressed in the TFRC-PS draft. As suggested in the RTP document, if
the loss rate is persistently unacceptably high relative to the
current sending rate, and the best-effort application is unable to
lower its sending rate, then the only acceptable answer is for that
flow to discontinue sending on that link. For a multicast session,
this could be accomplished by the receiver withdrawing from the
multicast group. For a unicast session, this could be accomplished
by the unicast connection terminating, at least for a period of time.
We can formulate a problem statement for the minimum sending rate in
the following way. Consider a best-effort, adaptive audio
application that is able to adapt down to a minimum sending rate of N
Bps (bytes per second) of application data, sending M packets per
second. Is this a sufficiently low sending rate that the best-effort
flow is never required to terminate due to congestion, or to reduce
its sending rate in packets per second still further? In other words,
is N Bps an acceptable minimum sending rate for the application,
which can be continued in the face of congestion without terminating
or suspending the application?
We assume, generously for VoIP, 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). If the limitation in the network is in
bandwidth, this is a limitation in Bps, while if the limitation is in
router processing capacity in packets, this would be a limitation in
pps. We note that TCP sends fixed-size data packets, and reduces its
sending rate in pps when it adapts to network congestion, thus
reducing the load on the forward path both in Bps and in pps. In
contrast, for adaptive VoIP applications, the adaption is sometimes
to keep the same sending rate in pps, but to reduce the packet size,
reducing the sending rate in Bps. This fits the needs of audio as an
application, and is a good response on a network path where the
limitation is in Bps. Such behavior would be a less appropriate
response for a network path where the limitation is in pps.
If the network limitation in fact is in Bps, then all that matters in
terms of congestion is a flow’s sending rate on the wire in Bps. If
this assumption of a network limitation in Bps is false, then the
sending rate in pps could contribute to congestion even when the
sending rate in Bps is quite moderate. 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.
Assuming 40-byte packet headers (IP, RTP, and UDP or DCCP), the
application data sending rate of N Bps and M pps translates to a
sending rate on the wire of B = N+40M Bps. If the application uses
additional FEC (Forward Error Correction), the FEC bits must be added
in as well. In our example, we ignore bandwidth adjustments that are
needed to take into account the additional overhead for FEC or the
reduced sending rate for silence periods. We also are not taking
into account the possible role of header compression on congested
edge links, which can reduce significantly the number of bytes used
for headers on those links.
Now, consider an equivalent-rate TCP connection with data packets of
P bytes and a round-trip time of R seconds. Taking into account
header size, such a TCP connection with a sending rate on the wire of
B Bps is sending B/(P+40) pps, or, equivalently, BR/(P+40) ppr
(packets per round-trip time).
Restating the question in terms of the above expressions for VoIP and
TCP: if the best-effort VoIP connection is experiencing a persistent
packet drop rate of D, and is at its minimum sending rate on the wire
of B Bps, when should the application or transport protocol terminate
or suspend the VoIP connection?
One answer to this question is to find the sending rate in ppr for a
TCP connection sending at the same rate on the wire in Bps, and to
use the TCP response function to determine whether a conformant TCP
connection would be able to maintain a sending rate close to that
sending rate with the same persistent drop rate D. If the sending
rate of the VoIP connection is significantly higher than the sending
rate of a conformant TCP connection under the same conditions, and
the VoIP connection is unable to reduce its sending rate on the wire,
then the VoIP connection should terminate or suspend.
As discussed above, there are two reasons for requiring the
application to terminate:
1) Avoiding congestion collapse, given the possibility of multiple
congested links,
2) Fairness for congestion-controlled TCP traffic sharing the
link.
In addition, if an application requires a minimum service level from
the network in order to operate, and that service level is
consistently not achieved, then the application should terminate or
suspend sending.
One counter-argument is that users will just hang up anyway with a
high packet drop rate so there is no point in enforcing a minimum
acceptable rate. Users might hang up, but they might also just keep
on talking, with the occasional noise getting though, for minutes or
longer waiting for a short period of clarity. Another counter-
argument is that nobody really benefits from VoIP connections being
terminated or suspended when persistent packet drop rates exceed the
allowable packet drop rate for the configured minimum sending rate.
This is untrue, since the termination of these VoIP connections could
allow competing TCP and VoIP traffic to make some progress.
In the next section, we illustrate the approach outlined above for
VoIP flows with minimum sending rates of 4.75 and 64 kbps
respectively, and show that in practice such an approach would not
seem too burdensome for VoIP traffic. This approach implies that the
VoIP traffic would terminate or suspend when the packet drop rate
significantly exceeds 40% for a VoIP flow with a minimum sending rate
of 4.75 kbps. If VoIP is to deliver "carrier quality" or even near
"carrier quality" on best-effort links, conditioning deployment on
the ability to maintain maximum sending rates during periods of
persistent packet drops rates exceeding 40% does not suggest a
service model that will see widespread acceptance among consumers, no
matter what the price differential. Good packet throughput is vital
for the delivery of acceptable VoIP service.
For a VoIP flow that stops sending because its minimum sending rate
is too high for the steady-state packet drop rate, we have not
addressed the question of when a VoIP flow might be able to start
sending again, to see if the congestion on the end-to-end path has
changed. This issue has been addressed in a proposal for
Probabilistic Congestion Control [PCC].
We note that if the congestion indications are in the form of ECN-
marked packets (Explicit Congestion Notification), as opposed to
dropped packets, then the answers about when a flow with a minimum
sending rate would have to stop sending are somewhat different. ECN
allows routers to explicitly notify end-nodes of congestion by ECN-
marking instead of dropping packets [RFC3168]. If packets are ECN-
marked instead of dropped in the network, then there are no concerns
of congestion collapse or of user quality (for the ECN-capable
traffic, at any rate), and what remains are concerns of fairness with
competing flows. Second, in regimes with very high congestion, TCP
has a higher sending rate with ECN-marked than with dropped packets,
in part because of different dynamics in terms of un-backing-off a
backed-off retransmit timer.
5.1. Drop Rates at 4.75 kbps Minimum Sending Rate
Consider an adaptive audio application with an RTT of R=0.1 seconds
that is able to adapt down to a minimum sending rate of 4.75 kbps
application data, sending M=20 packets per second. This sending rate
translates to N=593 Bps of application data, for a sending rate on
the wire of B=1393 Bps. An equivalent-rate TCP connection with data
packets of P=1460 bytes and a round-trip time of R=0.1 seconds would
be sending BR/(P+40) = 0.09 ppr.
Table 1 in the Appendix looks at the packet drop rate experienced by
a TCP connection with the RTO set to twice the RTT, and gives the
corresponding sending rate of the TCP connection in ppr. The second
column gives the sending rate estimated by the standard analytical
approach, and the third, fourth, and fifth columns give the average
sending rate from simulations with random packet drops or marks. The
sixth column gives the sending rates from experiments on a 4.8-
RELEASE FreeBSD machine. The analytical approaches require an RTO
expressed as a multiple of the RTT, and Table 1 shows the results for
the RTO set to 2 RTT. In the simulations, the minimum RTO is set to
twice the RTT. See the Appendix for more details.
For a sending rate of 0.09 ppr and an RTO set to 2 RTT, Table 1 shows
that the analytical approach gives a corresponding packet drop rate
of roughly 50%, while the simulations in the fifth column and the
experiments in the sixth column give a packet drop rate of between
35% and 40% to maintain a sending rate of 0.09 ppr. (For a reference
TCP connection using timestamps, shown in the fourth column, the
simulations give a packet drop rate of 55% to maintain a sending rate
of 0.09 ppr.) Of the two approaches for determining TCP’s
relationship between the sending rate and the packet drop rate, the
analytic approach and the use of simulations, we consider the
simulations to be the most realistic, for reasons discussed in the
Appendix. This suggests a packet drop rate of 40% would be
reasonable for a TCP connection with an average sending rate of 0.09
ppr. As a result, a VoIP connection with an RTT of 0.1 sec and a
minimum sending rate of 4.75 kbps would be required to terminate or
suspend when the persistent packet drop rate significantly exceeds
40%.
These estimates are sensitive to the assumed round-trip time of the
TCP connection. If we assumed instead that the equivalent-rate TCP
connection had a round-trip time of R=0.01 seconds, the equivalent-
rate TCP connection would be sending BR/(P+40) = 0.009 ppr. However,
we have also assumed a minimum RTO for TCP connections of 0.1
seconds, which in this case would mean an RTO of at least 10 RTT.
For this setting of the RTO, we would use Table 2 from the appendix
to determine the average TCP sending rate for a particular packet
drop rate. The simulations in the fifth column of Table 2 suggest
that a TCP connection with an RTT of 0.01 sec and an RTO of 10 RTT
would be able to send 0.009 ppr with a packet drop rate of 45%. (For
the same TCP connection using timestamps, shown in the fourth column,
the simulations give a packet drop rate of 60-65% to maintain a
sending rate of 0.009 ppr.)
Thus, for a VoIP connection with an RTT of 0.01 sec and a minimum
sending rate of 4.75 kbps, the VoIP connection would be required to
terminate or suspend when the persistent packet drop rate exceeded
45%.
5.2. Drop Rates at 64 kbps Minimum Sending Rate
The effect of increasing the minimum acceptable sending rate to 64
kbps is effectively to decrease the packet drop rate at which the
application should terminate or suspend sending. For this section,
consider a codec with a minimum sending rate of 64 kbps, or N=8000
Bps, and a packet sending rate of M=50 pps. (This would be
equivalent to 160-byte data packets, with 20 ms. per packet.) The
sending rate on the wire is B = N+40M Bps, including headers, or
10000 Bps. A TCP connection having that sending rate, with packets
of size P=1460 bytes and a round-trip time of R=0.1 seconds, sends
BR/(P+40) = 0.66 ppr. From the fifth column of Table 1, for an RTO
of 2 RTT, this corresponds to a packet drop rate between 20 and 25%.
[For a TCP connection using fine-grained timestamps, as shown in the
fourth column of Table 1, this sending rate corresponds to a packet
drop rate between 25% and 35%.] As a result, a VoIP connection with
an RTT of 0.1 sec and a minimum sending rate of 64 kbps would be
required to terminate or suspend when the persistent packet drop rate
significantly exceeds 25%.
For an equivalent-rate TCP connection with a round-trip time of
R=0.01 seconds and a minimum RTO of 0.1 seconds (giving an RTO of 10