draft-ietf-rmt-bb-tfmcc-04.txt   draft-ietf-rmt-bb-tfmcc-05.txt 
Internet Engineering Task Force RMT WG Internet Engineering Task Force RMT WG
INTERNET-DRAFT Joerg Widmer/EPFL INTERNET-DRAFT Joerg Widmer/DoCoMo Euro-Labs
draft-ietf-rmt-bb-tfmcc-04.txt Mark Handley/ICIR draft-ietf-rmt-bb-tfmcc-05.txt Mark Handley/UCL
14 October 2004 4 October 2005
Expires: April 2005 Expires: April 2006
TCP-Friendly Multicast Congestion Control (TFMCC): TCP-Friendly Multicast Congestion Control (TFMCC):
Protocol Specification Protocol Specification
Status of this Document Status of this Document
By submitting this Internet-Draft, I certify that any applicable patent By submitting this Internet-Draft, each author represents that any
or other IPR claims of which I am aware have been disclosed, or will be applicable patent or other IPR claims of which he or she is aware have
disclosed, and any of which I become aware will be disclosed, in been or will be disclosed, and any of which he or she becomes aware will
accordance with RFC 3668. be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material time. It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as "work in progress." or to cite them other than as "work in progress."
skipping to change at page 2, line 5 skipping to change at page 2, line 5
This document is a product of the IETF RMT WG. Comments should be This document is a product of the IETF RMT WG. Comments should be
addressed to the authors, or the WG's mailing list at rmt@lbl.gov. addressed to the authors, or the WG's mailing list at rmt@lbl.gov.
Abstract Abstract
This document specifies TCP-Friendly Multicast Congestion This document specifies TCP-Friendly Multicast Congestion
Control (TFMCC). TFMCC is a congestion control mechanism for Control (TFMCC). TFMCC is a congestion control mechanism for
multicast transmissions in a best-effort Internet environment. multicast transmissions in a best-effort Internet environment.
Expires: April 2005 October 2004 Expires: April 2006 October 2005
It is a single-rate congestion control scheme, where the It is a single-rate congestion control scheme, where the
sending rate is adapted to the receiver experiencing the worst sending rate is adapted to the receiver experiencing the worst
network conditions. TFMCC is reasonably fair when competing network conditions. TFMCC is reasonably fair when competing
for bandwidth with TCP flows and has a relatively low for bandwidth with TCP flows and has a relatively low
variation of throughput over time, making it suitable for variation of throughput over time, making it suitable for
applications such as streaming media where a relatively smooth applications such as streaming media where a relatively smooth
sending rate is of importance. sending rate is of importance.
Expires: April 2005 October 2004 Expires: April 2006 October 2005
Table of Contents Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology. . . . . . . . . . . . . . . . . . . . . 5 1.1. Terminology. . . . . . . . . . . . . . . . . . . . . 5
1.2. Related Documents. . . . . . . . . . . . . . . . . . 5 1.2. Related Documents. . . . . . . . . . . . . . . . . . 5
1.3. Environmental Requirements and Considerations. . . . 5 1.3. Environmental Requirements and Considerations. . . . 5
2. Protocol Overview . . . . . . . . . . . . . . . . . . . 6 2. Protocol Overview . . . . . . . . . . . . . . . . . . . 6
2.1. TCP Throughput Equation. . . . . . . . . . . . . . . 7 2.1. TCP Throughput Equation. . . . . . . . . . . . . . . 7
2.2. Packet Contents. . . . . . . . . . . . . . . . . . . 8 2.2. Packet Contents. . . . . . . . . . . . . . . . . . . 8
skipping to change at page 4, line 4 skipping to change at page 4, line 4
5.4. Average Loss Interval. . . . . . . . . . . . . . . . 23 5.4. Average Loss Interval. . . . . . . . . . . . . . . . 23
5.5. History Discounting. . . . . . . . . . . . . . . . . 24 5.5. History Discounting. . . . . . . . . . . . . . . . . 24
5.6. Initializing the Loss History after the First 5.6. Initializing the Loss History after the First
Loss Event. . . . . . . . . . . . . . . . . . . . . . . . 27 Loss Event. . . . . . . . . . . . . . . . . . . . . . . . 27
6. Security Considerations . . . . . . . . . . . . . . . . 28 6. Security Considerations . . . . . . . . . . . . . . . . 28
7. IANA Considerations . . . . . . . . . . . . . . . . . . 28 7. IANA Considerations . . . . . . . . . . . . . . . . . . 28
8. Authors' Addresses. . . . . . . . . . . . . . . . . . . 29 8. Authors' Addresses. . . . . . . . . . . . . . . . . . . 29
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . 29 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . 29
10. References . . . . . . . . . . . . . . . . . . . . . . 29 10. References . . . . . . . . . . . . . . . . . . . . . . 29
11. Copyright Notice . . . . . . . . . . . . . . . . . . . 30 11. Copyright Notice . . . . . . . . . . . . . . . . . . . 30
Expires: April 2005 October 2004 Expires: April 2006 October 2005
1. Introduction 1. Introduction
This document specifies TCP-Friendly Multicast Congestion Control This document specifies TCP-Friendly Multicast Congestion Control
(TFMCC) [11]. TFMCC is a source-based, single-rate congestion control (TFMCC) [11]. TFMCC is a source-based, single-rate congestion control
scheme that builds upon the unicast TCP-Friendly Rate Control mechanism scheme that builds upon the unicast TCP-Friendly Rate Control mechanism
(TFRC) [2]. TFMCC is stable and responsive under a wide range of network (TFRC) [2]. TFMCC is stable and responsive under a wide range of network
conditions and scales to receiver sets on the order of several thousand conditions and scales to receiver sets on the order of several thousand
receivers. To support scalability, as much congestion control receivers. To support scalability, as much congestion control
functionality as possible is located at the receivers. Each receiver functionality as possible is located at the receivers. Each receiver
skipping to change at page 5, line 5 skipping to change at page 5, line 5
data as possible in as short a time as possible, PGMCC [7] may be more data as possible in as short a time as possible, PGMCC [7] may be more
suitable. suitable.
TFMCC is designed for applications that use a fixed packet size, and TFMCC is designed for applications that use a fixed packet size, and
vary their sending rate in packets per second in response to congestion. vary their sending rate in packets per second in response to congestion.
Some audio applications require a fixed interval of time between packets Some audio applications require a fixed interval of time between packets
and vary their packet size instead of their packet rate in response to and vary their packet size instead of their packet rate in response to
congestion. The congestion control mechanism in this document cannot be congestion. The congestion control mechanism in this document cannot be
used by those applications. used by those applications.
Expires: April 2005 October 2004 Expires: April 2006 October 2005
1.1. Terminology 1.1. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" are to be interpreted as described in RFC 2119 and indicate "OPTIONAL" are to be interpreted as described in RFC 2119 and indicate
requirement levels for compliant TFMCC implementations. requirement levels for compliant TFMCC implementations.
1.2. Related Documents 1.2. Related Documents
skipping to change at page 6, line 5 skipping to change at page 6, line 5
a receiver will not be received by other receivers. a receiver will not be received by other receivers.
TFMCC inherently works with all types of networks, including LANs, WANs, TFMCC inherently works with all types of networks, including LANs, WANs,
Intranets, the Internet, asymmetric networks, wireless networks, and Intranets, the Internet, asymmetric networks, wireless networks, and
satellite networks. However, in some network environments varying the satellite networks. However, in some network environments varying the
sending rate to the receivers may not be advantageous (e.g., for a sending rate to the receivers may not be advantageous (e.g., for a
satellite or wireless network, there may be no mechanism for receivers satellite or wireless network, there may be no mechanism for receivers
to effectively reduce their reception rate since there may be a fixed to effectively reduce their reception rate since there may be a fixed
transmission rate allocated to the session). transmission rate allocated to the session).
Expires: April 2005 October 2004 Expires: April 2006 October 2005
2. Protocol Overview 2. Protocol Overview
TFMCC extends the basic mechanisms of TFRC into the multicast domain. TFMCC extends the basic mechanisms of TFRC into the multicast domain.
In order to compete fairly with TCP, TFMCC receivers individually In order to compete fairly with TCP, TFMCC receivers individually
measure the prevalent network conditions and calculate a rate that is measure the prevalent network conditions and calculate a rate that is
TCP-friendly on the path from the sender to themselves. The rate is TCP-friendly on the path from the sender to themselves. The rate is
determined using an equation for TCP throughput, which roughly describes determined using an equation for TCP throughput, which roughly describes
TCP's sending rate as a function of the loss event rate, round-trip time TCP's sending rate as a function of the loss event rate, round-trip time
(RTT), and packet size. We define a loss event as one or more lost or (RTT), and packet size. We define a loss event as one or more lost or
skipping to change at page 7, line 5 skipping to change at page 7, line 5
The sending rate increases when the CLR reports a calculated rate The sending rate increases when the CLR reports a calculated rate
higher than the current sending rate. higher than the current sending rate.
The dynamics of TFMCC are sensitive to how the measurements are The dynamics of TFMCC are sensitive to how the measurements are
performed and applied and what feedback suppression mechanism is chosen. performed and applied and what feedback suppression mechanism is chosen.
We recommend specific mechanisms below to perform and apply these We recommend specific mechanisms below to perform and apply these
measurements. Other mechanisms are possible, but it is important to measurements. Other mechanisms are possible, but it is important to
understand how the interactions between mechanisms affect the dynamics understand how the interactions between mechanisms affect the dynamics
of TFMCC. of TFMCC.
Expires: April 2005 October 2004 Expires: April 2006 October 2005
2.1. TCP Throughput Equation 2.1. TCP Throughput Equation
Any realistic equation giving TCP throughput as a function of loss event Any realistic equation giving TCP throughput as a function of loss event
rate and RTT should be suitable for use in TFMCC. However, we note that rate and RTT should be suitable for use in TFMCC. However, we note that
the TCP throughput equation used must reflect TCP's retransmit timeout the TCP throughput equation used must reflect TCP's retransmit timeout
behavior, as this dominates TCP throughput at higher loss rates. We behavior, as this dominates TCP throughput at higher loss rates. We
also note that the assumptions implicit in the throughput equation about also note that the assumptions implicit in the throughput equation about
the loss event rate parameter have to be a reasonable match to how the the loss event rate parameter have to be a reasonable match to how the
loss rate or loss event rate is actually measured. While this match is loss rate or loss event rate is actually measured. While this match is
skipping to change at page 8, line 4 skipping to change at page 8, line 4
control. control.
The parameters s (packet size), p (loss event rate) and R (RTT) need to The parameters s (packet size), p (loss event rate) and R (RTT) need to
be measured or calculated by a TFMCC implementation. The measurement of be measured or calculated by a TFMCC implementation. The measurement of
R is specified in Section 4.3.2, and the measurement of p is specified R is specified in Section 4.3.2, and the measurement of p is specified
in Section 5. The parameter s (packet size) is normally known to an in Section 5. The parameter s (packet size) is normally known to an
application. This may not be so in two cases: application. This may not be so in two cases:
o The packet size naturally varies depending on the data. In this case, o The packet size naturally varies depending on the data. In this case,
although the packet size varies, that variation is not coupled to the although the packet size varies, that variation is not coupled to the
Expires: April 2005 October 2004 Expires: April 2006 October 2005
transmit rate. It should normally be safe to use an estimate of the transmit rate. It should normally be safe to use an estimate of the
mean packet size for s. mean packet size for s.
o The application needs to change the packet size rather than the number o The application needs to change the packet size rather than the number
of packets per second to perform congestion control. This would of packets per second to perform congestion control. This would
normally be the case with packet audio applications where a fixed normally be the case with packet audio applications where a fixed
interval of time needs to be represented by each packet. Such interval of time needs to be represented by each packet. Such
applications need to have a different way of measuring parameters. applications need to have a different way of measuring parameters.
skipping to change at page 9, line 4 skipping to change at page 9, line 4
not wrap causing two different packets with the same sequence number not wrap causing two different packets with the same sequence number
to be in the receiver's recent packet history at the same time. In to be in the receiver's recent packet history at the same time. In
most cases the sequence number will be supplied by the transport most cases the sequence number will be supplied by the transport
protocol used along with TFMCC. protocol used along with TFMCC.
o A suppression rate X_supp in bits/s. Only receivers with a calculated o A suppression rate X_supp in bits/s. Only receivers with a calculated
rate lower than the suppression rate are eligible to give feedback, rate lower than the suppression rate are eligible to give feedback,
unless their RTT is higher than the maximum RTT described below in unless their RTT is higher than the maximum RTT described below in
which case they are also eligible to give feedback. The suppression which case they are also eligible to give feedback. The suppression
rate should be represented as a 12 bit floating point value with 5 rate should be represented as a 12 bit floating point value with 5
Expires: April 2005 October 2004 Expires: April 2006 October 2005
bits for the unsigned exponent and 7 bits for the unsigned mantissa bits for the unsigned exponent and 7 bits for the unsigned mantissa
(to represent rates from 100 bit/s to 400 Gbit/s with an error of less (to represent rates from 100 bit/s to 400 Gbit/s with an error of less
than 1%). than 1%).
o A timestamp ts_i indicating when the packet is sent. The resolution o A timestamp ts_i indicating when the packet is sent. The resolution
of the timestamp should typically be milliseconds and the timestamp of the timestamp should typically be milliseconds and the timestamp
should be an unsigned integer value no less than 16 bits wide. should be an unsigned integer value no less than 16 bits wide.
o A receiver ID r and a copy of the timestamp ts_r of that receiver's o A receiver ID r and a copy of the timestamp ts_r of that receiver's
skipping to change at page 10, line 5 skipping to change at page 10, line 5
o A unique receiver ID r. In most cases the receiver ID will be o A unique receiver ID r. In most cases the receiver ID will be
supplied by the transport protocol, but it may simply be the IP supplied by the transport protocol, but it may simply be the IP
address of the receiver. address of the receiver.
o A flag have_RTT indicating whether the receiver has made at least one o A flag have_RTT indicating whether the receiver has made at least one
RTT measurement since it joined the session. RTT measurement since it joined the session.
o A flag have_loss indicating whether the receiver experienced at least o A flag have_loss indicating whether the receiver experienced at least
one loss event since it joined the session. one loss event since it joined the session.
Expires: April 2005 October 2004 Expires: April 2006 October 2005
o A flag receiver_leave indicating that the receiver will leave the o A flag receiver_leave indicating that the receiver will leave the
session (and should therefore not be CLR). session (and should therefore not be CLR).
o A timestamp ts_r indicating when the feedback packet is sent. The o A timestamp ts_r indicating when the feedback packet is sent. The
representation of the timestamp should be the same as that of the representation of the timestamp should be the same as that of the
timestamp echo in the data packets. timestamp echo in the data packets.
o An echo of the timestamp of the last data packet received. If the o An echo of the timestamp of the last data packet received. If the
last packet received at the receiver has sequence number i, then ts_i last packet received at the receiver has sequence number i, then ts_i
skipping to change at page 11, line 4 skipping to change at page 11, line 4
o controlling receiver feedback, and o controlling receiver feedback, and
o assisting receiver-side RTT measurements. o assisting receiver-side RTT measurements.
3.1. Sender Initialization 3.1. Sender Initialization
At initialization of the sender, the maximum RTT is set to a value that At initialization of the sender, the maximum RTT is set to a value that
should be larger than the highest RTT to any of the receivers. It should be larger than the highest RTT to any of the receivers. It
should not be smaller than 500 milliseconds for operation in the public should not be smaller than 500 milliseconds for operation in the public
Internet. The sending rate X is initialized to 1 packet per maximum Internet. The sending rate X is initialized to 1 packet per maximum
Expires: April 2005 October 2004 Expires: April 2006 October 2005
RTT. RTT.
3.2. Determining the Maximum RTT 3.2. Determining the Maximum RTT
For each feedback packet that arrives at the sender, the sender computes For each feedback packet that arrives at the sender, the sender computes
the instantaneous RTT to the receiver as the instantaneous RTT to the receiver as
R_r = t_now - ts_i R_r = t_now - ts_i
skipping to change at page 12, line 5 skipping to change at page 12, line 5
where t_gran is the granularity of the sender's system clock (see where t_gran is the granularity of the sender's system clock (see
Section 3.7). Section 3.7).
3.3. Adjusting the Sending Rate 3.3. Adjusting the Sending Rate
When a feedback packet from receiver r arrives at the sender, the sender When a feedback packet from receiver r arrives at the sender, the sender
has to check whether it is necessary to adjust the transmission rate and has to check whether it is necessary to adjust the transmission rate and
to switch to a new CLR. to switch to a new CLR.
Expires: April 2005 October 2004 Expires: April 2006 October 2005
How the rate is adjusted depends on the desired rate X_r of the receiver How the rate is adjusted depends on the desired rate X_r of the receiver
report. We distinguish four cases: report. We distinguish four cases:
1 If no CLR is present, receiver r becomes the current limiting 1 If no CLR is present, receiver r becomes the current limiting
receiver. The sending rate X is directly set to X_r, so long as receiver. The sending rate X is directly set to X_r, so long as
this would result in a rate increase of less than 8s/R_max bits/s this would result in a rate increase of less than 8s/R_max bits/s
(i.e., 1 packet per R_max). Otherwise X is gradually increased to (i.e., 1 packet per R_max). Otherwise X is gradually increased to
X_r at an increase rate of no more than 8s/R_max bits/s every R_max X_r at an increase rate of no more than 8s/R_max bits/s every R_max
seconds. seconds.
skipping to change at page 13, line 4 skipping to change at page 13, line 4
If the TFMCC sender receives no reports from the CLR for 4 RTTs, the If the TFMCC sender receives no reports from the CLR for 4 RTTs, the
sending rate is cut in half unless the CLR was selected less than 10 sending rate is cut in half unless the CLR was selected less than 10
RTTs ago. In addition, if the sender receives no reports from the CLR RTTs ago. In addition, if the sender receives no reports from the CLR
for at least 10 RTTs, it assumes that the CLR crashed or left the group. for at least 10 RTTs, it assumes that the CLR crashed or left the group.
A new CLR is selected from the feedback that subsequently arrives at the A new CLR is selected from the feedback that subsequently arrives at the
sender, and we increase as in case 3 above. sender, and we increase as in case 3 above.
If no new CLR can be selected (i.e., in the absence of any feedback from If no new CLR can be selected (i.e., in the absence of any feedback from
any of the receivers) it is necessary to further reduce the sending any of the receivers) it is necessary to further reduce the sending
rate. For every 10 consecutive RTTs without feedback, the sending rate rate. For every 10 consecutive RTTs without feedback, the sending rate
Expires: April 2005 October 2004 Expires: April 2006 October 2005
is cut in half. The rate is at most reduced to one packet every 8 is cut in half. The rate is at most reduced to one packet every 8
seconds. seconds.
Note that when receivers stop receiving data packets, they will stop Note that when receivers stop receiving data packets, they will stop
sending feedback. This eventually causes the sending rate to be reduced sending feedback. This eventually causes the sending rate to be reduced
in the case of network failure. If the network subsequently recovers, a in the case of network failure. If the network subsequently recovers, a
linear increase to the calculated rate of the CLR will occur at 8s/R_max linear increase to the calculated rate of the CLR will occur at 8s/R_max
bits/s every R_max. bits/s every R_max.
skipping to change at page 14, line 4 skipping to change at page 14, line 4
parameter g determines to what extent higher rate feedback can suppress parameter g determines to what extent higher rate feedback can suppress
lower rate feedback. This mechanism guarantees, that the lowest lower rate feedback. This mechanism guarantees, that the lowest
calculated rate reported lies within a factor of g of the actual lowest calculated rate reported lies within a factor of g of the actual lowest
calculated rate of the receiver set (see [10]). A value of g of 0.1 is calculated rate of the receiver set (see [10]). A value of g of 0.1 is
recommended. recommended.
To allow receivers to suppress their feedback, the sender's suppression To allow receivers to suppress their feedback, the sender's suppression
rate needs to be updated whenever feedback is received. This rate needs to be updated whenever feedback is received. This
suppression rate has to be communicated to the receivers in a timely suppression rate has to be communicated to the receivers in a timely
manner, either by including it in the data packet header or, if separate manner, either by including it in the data packet header or, if separate
Expires: April 2005 October 2004 Expires: April 2006 October 2005
congestion control messages are used, by sending a message with the congestion control messages are used, by sending a message with the
suppression rate whenever the rate changes significantly (i.e., when it suppression rate whenever the rate changes significantly (i.e., when it
is reduced to less than (1-g) times the previously advertised is reduced to less than (1-g) times the previously advertised
suppression rate). suppression rate).
After a time span of T, the feedback round ends if non-CLR feedback was After a time span of T, the feedback round ends if non-CLR feedback was
received during that time. Otherwise, the feedback round ends as soon received during that time. Otherwise, the feedback round ends as soon
as the first non-CLR feedback message arrives at the sender but at most as the first non-CLR feedback message arrives at the sender but at most
after 2T. The feedback round counter is incremented by one and the after 2T. The feedback round counter is incremented by one and the
skipping to change at page 15, line 4 skipping to change at page 15, line 4
4. the CLR 4. the CLR
Ties are broken in favor of the receiver with the lowest reported rate. Ties are broken in favor of the receiver with the lowest reported rate.
It is necessary to account for the time that elapses between receiving a It is necessary to account for the time that elapses between receiving a
report and sending the next data packet. This time needs to be deducted report and sending the next data packet. This time needs to be deducted
from the RTT and thus has to be added to the receiver's timestamp value. from the RTT and thus has to be added to the receiver's timestamp value.
Whenever no feedback packets arrive in the interval between two data Whenever no feedback packets arrive in the interval between two data
packets, the CLR's last timestamp, adjusted by the appropriate offset, packets, the CLR's last timestamp, adjusted by the appropriate offset,
Expires: April 2005 October 2004 Expires: April 2006 October 2005
is echoed. When the number of packets per RTT is so low that all is echoed. When the number of packets per RTT is so low that all
packets carry a non-CLR receiver's timestamp, the CLR's timestamp and ID packets carry a non-CLR receiver's timestamp, the CLR's timestamp and ID
are included in a data packet at least once per feedback round. are included in a data packet at least once per feedback round.
3.6. Slowstart 3.6. Slowstart
TFMCC uses a slowstart mechanism to quickly approach its fair bandwidth TFMCC uses a slowstart mechanism to quickly approach its fair bandwidth
share at the start of a session. During slowstart, the sending rate share at the start of a session. During slowstart, the sending rate
increases exponentially. The rate increase is limited to the minimum of increases exponentially. The rate increase is limited to the minimum of
skipping to change at page 16, line 5 skipping to change at page 16, line 5
t_ipi = s/X t_ipi = s/X
When a sender first starts sending at time t_0, it calculates t_ipi, and When a sender first starts sending at time t_0, it calculates t_ipi, and
calculates a nominal send time t_1 = t_0 + t_ipi for packet 1. When the calculates a nominal send time t_1 = t_0 + t_ipi for packet 1. When the
application becomes idle, it checks the current time, t_now, and then application becomes idle, it checks the current time, t_now, and then
requests re-scheduling after (t_ipi - (t_now - t_0)) seconds. When the requests re-scheduling after (t_ipi - (t_now - t_0)) seconds. When the
application is re-scheduled, it checks the current time, t_now, again. application is re-scheduled, it checks the current time, t_now, again.
If (t_now > t_1 - delta) then packet 1 is sent (see below for delta). If (t_now > t_1 - delta) then packet 1 is sent (see below for delta).
Expires: April 2005 October 2004 Expires: April 2006 October 2005
Now a new t_ipi may be calculated, and used to calculate a nominal send Now a new t_ipi may be calculated, and used to calculate a nominal send
time t_2 for packet 2: t2 = t_1 + t_ipi. The process then repeats, with time t_2 for packet 2: t2 = t_1 + t_ipi. The process then repeats, with
each successive packet's send time being calculated from the nominal each successive packet's send time being calculated from the nominal
send time of the previous packet. send time of the previous packet.
In some cases, when the nominal send time, t_i, of the next packet is In some cases, when the nominal send time, t_i, of the next packet is
calculated, it may already be the case that t_now > t_i - delta. In calculated, it may already be the case that t_now > t_i - delta. In
such a case the packet should be sent immediately. Thus if the such a case the packet should be sent immediately. Thus if the
operating system has coarse timer granularity and the transmit rate is operating system has coarse timer granularity and the transmit rate is
skipping to change at page 17, line 4 skipping to change at page 17, line 4
The receiver is initialized when it receives the first data packet. The The receiver is initialized when it receives the first data packet. The
RTT is set to the maximum RTT value contained in the data packet. This RTT is set to the maximum RTT value contained in the data packet. This
initial value is used as the receiver's RTT until the first real RTT initial value is used as the receiver's RTT until the first real RTT
measurement is made. The loss event rate is initialized to 0. measurement is made. The loss event rate is initialized to 0.
4.2. Receiver Leave 4.2. Receiver Leave
A receiver that sends feedback but wishes to leave the TFMCC session A receiver that sends feedback but wishes to leave the TFMCC session
within the next feedback round may indicate the pending leave by setting within the next feedback round may indicate the pending leave by setting
Expires: April 2005 October 2004 Expires: April 2006 October 2005
the receiver_leave flag in its report. If the leaving receiver is the the receiver_leave flag in its report. If the leaving receiver is the
CLR, the receiver_leave flag should be set for all the reports within CLR, the receiver_leave flag should be set for all the reports within
the feedback round before the leave takes effect. the feedback round before the leave takes effect.
4.3. Measurement of the Network Conditions 4.3. Measurement of the Network Conditions
Receivers have to update their estimate of the network parameters with Receivers have to update their estimate of the network parameters with
each new data packet they receive. each new data packet they receive.
skipping to change at page 18, line 5 skipping to change at page 18, line 5
R = R_sample R = R_sample
Else Else
R = q*R + (1-q)*R_sample R = q*R + (1-q)*R_sample
A filter parameter q of 0.5 is recommended for non-CLR receivers. A filter parameter q of 0.5 is recommended for non-CLR receivers.
The CLR performs RTT measurements much more frequently and hence The CLR performs RTT measurements much more frequently and hence
should use a higher filter value. We recommend using q=0.9. Note should use a higher filter value. We recommend using q=0.9. Note
that TFMCC is not sensitive to the precise value for the filter that TFMCC is not sensitive to the precise value for the filter
constant. constant.
Expires: April 2005 October 2004 Expires: April 2006 October 2005
Optionally, sender-based instead of receiver-based RTT measurements may Optionally, sender-based instead of receiver-based RTT measurements may
be used. The sender already determines the RTT to a receiver from the be used. The sender already determines the RTT to a receiver from the
receiver's echo of the sender's own timestamp for the calculation of the receiver's echo of the sender's own timestamp for the calculation of the
maximum RTT. For sender-based RTT measurements, this RTT measurement maximum RTT. For sender-based RTT measurements, this RTT measurement
needs to be communicated to the receiver. Instead of including an echo needs to be communicated to the receiver. Instead of including an echo
of the receiver's timestamp, the sender includes the receiver's RTT in of the receiver's timestamp, the sender includes the receiver's RTT in
the next data packet, using the prioritization rules described in the next data packet, using the prioritization rules described in
Section 3.5. Section 3.5.
skipping to change at page 19, line 5 skipping to change at page 19, line 5
The same one-way delay adjustments should be applied to the RTT supplied The same one-way delay adjustments should be applied to the RTT supplied
by the sender when using sender-based RTT measurements. by the sender when using sender-based RTT measurements.
4.3.4. Receive Rate Measurements 4.3.4. Receive Rate Measurements
When a receiver has not experienced any loss events, it cannot calculate When a receiver has not experienced any loss events, it cannot calculate
a TCP-friendly rate to include in the receiver reports. Instead, the a TCP-friendly rate to include in the receiver reports. Instead, the
receiver measures the current receive rate and sets the desired rate X_r receiver measures the current receive rate and sets the desired rate X_r
to twice the receive rate. to twice the receive rate.
Expires: April 2005 October 2004 Expires: April 2006 October 2005
The receive rate in bits/s is measured as the number of bits received The receive rate in bits/s is measured as the number of bits received
over the last k RTTs, taking into account the IP and transport packet over the last k RTTs, taking into account the IP and transport packet
headers, but excluding the link-layer packet headers. A value for k headers, but excluding the link-layer packet headers. A value for k
between 2 and 4 is recommended. between 2 and 4 is recommended.
4.4. Setting the Desired Rate 4.4. Setting the Desired Rate
When a receiver measures a non-zero loss event rate, it calculates the When a receiver measures a non-zero loss event rate, it calculates the
desired rate using Equation (1). In case no RTT measurement is desired rate using Equation (1). In case no RTT measurement is
skipping to change at page 20, line 4 skipping to change at page 20, line 4
round counter wrapped and also cancels the feedback timer and updates round counter wrapped and also cancels the feedback timer and updates
fb_nr. fb_nr.
The CLR sends its feedback independently from all the other receivers The CLR sends its feedback independently from all the other receivers
once per RTT. Its feedback does not suppress other feedback and cannot once per RTT. Its feedback does not suppress other feedback and cannot
be suppressed by other receiver's feedback. be suppressed by other receiver's feedback.
Non-CLR receivers set a feedback timer at the beginning of a feedback Non-CLR receivers set a feedback timer at the beginning of a feedback
round. Using an exponentially weighted random timer mechanism, the round. Using an exponentially weighted random timer mechanism, the
feedback timer is set to expire after feedback timer is set to expire after
Expires: April 2005 October 2004 Expires: April 2006 October 2005
t = max(T * (1 + log(x)/log(N)), 0) t = max(T * (1 + log(x)/log(N)), 0)
where where
x is a random variable uniformly distributed in (0,1], x is a random variable uniformly distributed in (0,1],
T is the duration of a feedback round (i.e., 6 * R_max), T is the duration of a feedback round (i.e., 6 * R_max),
N is an estimated upper bound on the number of receivers. N is an estimated upper bound on the number of receivers.
skipping to change at page 21, line 5 skipping to change at page 21, line 5
it is necessary to introduce X_fbr, the calculated rate of a receiver at it is necessary to introduce X_fbr, the calculated rate of a receiver at
the beginning of a feedback round. A receiver needs to suppress its the beginning of a feedback round. A receiver needs to suppress its
feedback not only when the suppression rate is less than the receiver's feedback not only when the suppression rate is less than the receiver's
current calculated rate but also in the case that the suppression rate current calculated rate but also in the case that the suppression rate
falls below X_fbr. falls below X_fbr.
When the maximum RTT changes significantly during one feedback round, it When the maximum RTT changes significantly during one feedback round, it
is necessary to reschedule the feedback timer in proportion to the is necessary to reschedule the feedback timer in proportion to the
change. change.
Expires: April 2005 October 2004 Expires: April 2006 October 2005
t = t * R_max / R_max' t = t * R_max / R_max'
where R_max is the new maximum RTT and R_max' is the previous maximum where R_max is the new maximum RTT and R_max' is the previous maximum
RTT. The same considerations hold, when the last data packets were RTT. The same considerations hold, when the last data packets were
received more than a time interval of R_max ago. In this case, it is received more than a time interval of R_max ago. In this case, it is
necessary to add the difference of the inter-packet gap and the maximum necessary to add the difference of the inter-packet gap and the maximum
RTT to the feedback time to prevent a feedback implosion (e.g., in case RTT to the feedback time to prevent a feedback implosion (e.g., in case
the sender crashed). the sender crashed).
skipping to change at page 22, line 4 skipping to change at page 22, line 4
The receivers each maintain a data structure that keeps track of which The receivers each maintain a data structure that keeps track of which
packets have arrived and which are missing. For the purposes of packets have arrived and which are missing. For the purposes of
specification, we assume that the data structure consists of a list of specification, we assume that the data structure consists of a list of
packets that have arrived along with the timestamp when each packet was packets that have arrived along with the timestamp when each packet was
received. In practice this data structure will normally be stored in a received. In practice this data structure will normally be stored in a
more compact representation, but this is implementation-specific. more compact representation, but this is implementation-specific.
The loss of a packet is detected by the arrival of at least three The loss of a packet is detected by the arrival of at least three
packets with a higher sequence number than the lost packet. The packets with a higher sequence number than the lost packet. The
requirement for three subsequent packets is the same as with TCP, and is requirement for three subsequent packets is the same as with TCP, and is
Expires: April 2005 October 2004 Expires: April 2006 October 2005
to make TFMCC more robust in the presence of reordering. In contrast to to make TFMCC more robust in the presence of reordering. In contrast to
TCP, if a packet arrives late (after 3 subsequent packets arrived) at a TCP, if a packet arrives late (after 3 subsequent packets arrived) at a
receiver, the late packet can fill the hole in the reception record, and receiver, the late packet can fill the hole in the reception record, and
the receiver can recalculate the loss event rate. Future versions of the receiver can recalculate the loss event rate. Future versions of
TFMCC might make the requirement for three subsequent packets adaptive TFMCC might make the requirement for three subsequent packets adaptive
based on experienced packet reordering, but we do not specify such a based on experienced packet reordering, but we do not specify such a
mechanism here. mechanism here.
For an ECN-capable connection, a marked packet is detected as a For an ECN-capable connection, a marked packet is detected as a
skipping to change at page 23, line 4 skipping to change at page 23, line 4
T_before is the reception time of S_before. T_before is the reception time of S_before.
T_after is the reception time of S_after. T_after is the reception time of S_after.
Note that T_before can either be before or after T_after due to Note that T_before can either be before or after T_after due to
reordering. reordering.
For a lost packet S_loss, we can interpolate its nominal "arrival time" For a lost packet S_loss, we can interpolate its nominal "arrival time"
at the receiver from the arrival times of S_before and S_after. Thus at the receiver from the arrival times of S_before and S_after. Thus
Expires: April 2005 October 2004 Expires: April 2006 October 2005
T_loss = T_before + ( (T_after - T_before) T_loss = T_before + ( (T_after - T_before)
* (S_loss - S_before)/(S_after - S_before) ); * (S_loss - S_before)/(S_after - S_before) );
Note that if the sequence space wrapped between S_before and S_after, Note that if the sequence space wrapped between S_before and S_after,
then the sequence numbers must be modified to take this into account then the sequence numbers must be modified to take this into account
before performing the calculation. If the largest possible sequence before performing the calculation. If the largest possible sequence
number is S_max, and S_before > S_after, then modifying each sequence number is S_max, and S_before > S_after, then modifying each sequence
number S by S' = (S + (S_max + 1)/2) mod (S_max + 1) would normally be number S by S' = (S + (S_max + 1)/2) mod (S_max + 1) would normally be
sufficient. sufficient.
skipping to change at page 24, line 4 skipping to change at page 24, line 4
Weights w_0 to w_(n-1) are calculated as: Weights w_0 to w_(n-1) are calculated as:
If (i < n/2) If (i < n/2)
w_i = 1; w_i = 1;
Else Else
w_i = 1 - (i - (n/2 - 1))/(n/2 + 1); w_i = 1 - (i - (n/2 - 1))/(n/2 + 1);
Thus if n=8, the values of w_0 to w_7 are: Thus if n=8, the values of w_0 to w_7 are:
1.0, 1.0, 1.0, 1.0, 0.8, 0.6, 0.4, 0.2 1.0, 1.0, 1.0, 1.0, 0.8, 0.6, 0.4, 0.2
Expires: April 2005 October 2004 Expires: April 2006 October 2005
The value n for the number of loss intervals used in calculating the The value n for the number of loss intervals used in calculating the
loss event rate determines TFMCC's speed in responding to changes in the loss event rate determines TFMCC's speed in responding to changes in the
level of congestion. As currently specified, TFMCC should not be used level of congestion. As currently specified, TFMCC should not be used
for values of n significantly greater than 8, for traffic that might for values of n significantly greater than 8, for traffic that might
compete in the global Internet with TCP. At the very least, safe compete in the global Internet with TCP. At the very least, safe
operation with values of n greater than 8 would require a slight change operation with values of n greater than 8 would require a slight change
to TFMCC's mechanisms to include a more severe response to two or more to TFMCC's mechanisms to include a more severe response to two or more
round-trip times with heavy packet loss. round-trip times with heavy packet loss.
skipping to change at page 25, line 5 skipping to change at page 25, line 5
As described in Section 5.4, the most recent loss interval is only As described in Section 5.4, the most recent loss interval is only
assigned 4/(3*n) of the total weight in calculating the average loss assigned 4/(3*n) of the total weight in calculating the average loss
interval, regardless of the size of the most recent loss interval. This interval, regardless of the size of the most recent loss interval. This
section describes an optional history discounting mechanism that allows section describes an optional history discounting mechanism that allows
the TFMCC receivers to adjust the weights, concentrating more of the the TFMCC receivers to adjust the weights, concentrating more of the
relative weight on the most recent loss interval, when the most recent relative weight on the most recent loss interval, when the most recent
loss interval is more than twice as large as the computed average loss loss interval is more than twice as large as the computed average loss
interval. interval.
Expires: April 2005 October 2004 Expires: April 2006 October 2005
To carry out history discounting, we associate a discount factor DF_i To carry out history discounting, we associate a discount factor DF_i
with each loss interval L_i, where each discount factor is a floating with each loss interval L_i, where each discount factor is a floating
point number. The discount array maintains the cumulative history of point number. The discount array maintains the cumulative history of
discounting for each loss interval. At the beginning, the values of discounting for each loss interval. At the beginning, the values of
DF_i in the discount array are initialized to 1: DF_i in the discount array are initialized to 1:
for (i = 0 to n) { for (i = 0 to n) {
DF_i = 1; DF_i = 1;
} }
skipping to change at page 26, line 5 skipping to change at page 26, line 5
for (i = 1 to n) { for (i = 1 to n) {
I_tot1 = I_tot1 + (I_i * w_(i-1) * DF_i); I_tot1 = I_tot1 + (I_i * w_(i-1) * DF_i);
W_tot1 = W_tot1 + w_(i-1) * DF_i; W_tot1 = W_tot1 + w_(i-1) * DF_i;
} }
p = min(W_tot0/I_tot0, W_tot1/I_tot1); p = min(W_tot0/I_tot0, W_tot1/I_tot1);
The general discounting factor, DF is updated on every packet arrival as The general discounting factor, DF is updated on every packet arrival as
follows. First, a receiver computes the weighted average I_mean of the follows. First, a receiver computes the weighted average I_mean of the
loss intervals I_1, ..., I_n: loss intervals I_1, ..., I_n:
Expires: April 2005 October 2004 Expires: April 2006 October 2005
I_tot = 0; I_tot = 0;
W_tot = 0; W_tot = 0;
for (i = 1 to n) { for (i = 1 to n) {
W_tot = w_(i-1) * DF_i; W_tot = w_(i-1) * DF_i;
I_tot = I_tot + (I_i * w_(i-1) * DF_i); I_tot = I_tot + (I_i * w_(i-1) * DF_i);
} }
I_mean = I_tot / W_tot; I_mean = I_tot / W_tot;
This weighted average I_mean is compared to I_0, the number of packets This weighted average I_mean is compared to I_0, the number of packets
skipping to change at page 27, line 4 skipping to change at page 27, line 4
DF_(i+1) = DF_i; DF_(i+1) = DF_i;
} }
I_0 = 1; I_0 = 1;
DF_0 = 1; DF_0 = 1;
DF = 1; DF = 1;
This completes the description of the optional history discounting This completes the description of the optional history discounting
mechanism. We emphasize that this is an optional mechanism whose sole mechanism. We emphasize that this is an optional mechanism whose sole
purpose is to allow TFMCC to response somewhat more quickly to the purpose is to allow TFMCC to response somewhat more quickly to the
sudden absence of congestion, as represented by a long current loss sudden absence of congestion, as represented by a long current loss
Expires: April 2005 October 2004 Expires: April 2006 October 2005
interval. interval.
5.6. Initializing the Loss History after the First Loss Event 5.6. Initializing the Loss History after the First Loss Event
The number of packets received before the first loss event usually does The number of packets received before the first loss event usually does
not reflect the current loss event rate. When the first loss event not reflect the current loss event rate. When the first loss event
occurs, a TFMCC receiver assumes that the correct data rate is the rate occurs, a TFMCC receiver assumes that the correct data rate is the rate
at which data was received during the last RTT when the loss occurred. at which data was received during the last RTT when the loss occurred.
Instead of initializing the first loss interval to the number of packets Instead of initializing the first loss interval to the number of packets
skipping to change at page 28, line 5 skipping to change at page 28, line 5
than the actual RTT. As a consequence, the receiver will calculate a than the actual RTT. As a consequence, the receiver will calculate a
too high desired rate when the first RTT measurement R is made and the too high desired rate when the first RTT measurement R is made and the
initial loss interval is still in the loss history. The receiver has to initial loss interval is still in the loss history. The receiver has to
adjust l_0 as follows: adjust l_0 as follows:
l_0 = l_0 * (R/R_max)^2 l_0 = l_0 * (R/R_max)^2
No action needs to be taken when the first RTT measurement is made after No action needs to be taken when the first RTT measurement is made after
the initial loss interval left the loss history. the initial loss interval left the loss history.
Expires: April 2005 October 2004 Expires: April 2006 October 2005
6. Security Considerations 6. Security Considerations
TFMCC is not a transport protocol in its own right, but a congestion TFMCC is not a transport protocol in its own right, but a congestion
control mechanism that is intended to be used in conjunction with a control mechanism that is intended to be used in conjunction with a
transport protocol. Therefore security primarily needs to be considered transport protocol. Therefore security primarily needs to be considered
in the context of a specific transport protocol and its authentication in the context of a specific transport protocol and its authentication
mechanisms. mechanisms.
Congestion control mechanisms can potentially be exploited to create Congestion control mechanisms can potentially be exploited to create
skipping to change at page 29, line 5 skipping to change at page 29, line 5
incorporate feedback from the receiver to the sender using the ECN nonce incorporate feedback from the receiver to the sender using the ECN nonce
[WES01]. The ECN nonce is a modification to ECN that protects the [WES01]. The ECN nonce is a modification to ECN that protects the
sender from the accidental or malicious concealment of marked packets. sender from the accidental or malicious concealment of marked packets.
Again, the details of such a nonce would depend on the transport Again, the details of such a nonce would depend on the transport
protocol, and are not addressed in this document. protocol, and are not addressed in this document.
7. IANA Considerations 7. IANA Considerations
There are no IANA actions required for this document. There are no IANA actions required for this document.
Expires: April 2005 October 2004 Expires: April 2006 October 2005
8. Authors' Addresses 8. Authors' Addresses
Joerg Widmer Joerg Widmer
EPFL (Swiss Federal Institute of Technology - Lausanne) DoCoMo Euro-Labs
CH-1015 Lausanne, Switzerland Landsberger Str. 312, Munich, Germany
joerg.widmer@epfl.ch widmer@acm.org
Mark Handley Mark Handley
UCL (University College London) UCL (University College London)
Gower Street, London WC1E 6BT, UK Gower Street, London WC1E 6BT, UK
m.handley@cs.ucl.ac.uk m.handley@cs.ucl.ac.uk
9. Acknowledgments 9. Acknowledgments
We would like to acknowledge feedback and discussions on equation-based We would like to acknowledge feedback and discussions on equation-based
congestion control with a wide range of people, including members of the congestion control with a wide range of people, including members of the
skipping to change at page 30, line 5 skipping to change at page 30, line 5
Dissertation, Stanford University, Department of Computer Science, Dissertation, Stanford University, Department of Computer Science,
Stanford, California, August 2001. Stanford, California, August 2001.
[4] J. Padhye, V. Firoiu, D. Towsley, and J. Kurose, "Modeling TCP [4] J. Padhye, V. Firoiu, D. Towsley, and J. Kurose, "Modeling TCP
Throughput: A Simple Model and its Empirical Validation", Proc ACM Throughput: A Simple Model and its Empirical Validation", Proc ACM
SIGCOMM 1998. SIGCOMM 1998.
[5] V. Paxson and M. Allman, "Computing TCP's Retransmission Timer", RFC [5] V. Paxson and M. Allman, "Computing TCP's Retransmission Timer", RFC
2988, November 2000. 2988, November 2000.
Expires: April 2005 October 2004 Expires: April 2006 October 2005
[6] K. Ramakrishnan and S. Floyd, "A Proposal to add Explicit Congestion [6] K. Ramakrishnan and S. Floyd, "A Proposal to add Explicit Congestion
Notification (ECN) to IP", RFC 2481, January 1999. Notification (ECN) to IP", RFC 2481, January 1999.
[7] L. Rizzo, "pgmcc: a TCP-friendly single-rate multicast congestion [7] L. Rizzo, "pgmcc: a TCP-friendly single-rate multicast congestion
control scheme", Proc ACM SIGCOMM 2000, Stockholm, August 2000 control scheme", Proc ACM SIGCOMM 2000, Stockholm, August 2000
[8] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A [8] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A
Transport Protocol for Real-Time Applications", RFC 1889, January Transport Protocol for Real-Time Applications", RFC 1889, January
1996. 1996.
skipping to change at page 30, line 30 skipping to change at page 30, line 30
[10] J. Widmer and T. Fuhrmann, "Extremum Feedback for Very Large [10] J. Widmer and T. Fuhrmann, "Extremum Feedback for Very Large
Multicast Groups", Proc NGC 2001, London, November 2001. Multicast Groups", Proc NGC 2001, London, November 2001.
[11] J. Widmer and M. Handley, "Extending Equation-Based Congestion [11] J. Widmer and M. Handley, "Extending Equation-Based Congestion
Control to Multicast Applications", Proc ACM SIGCOMM 2001, San Control to Multicast Applications", Proc ACM SIGCOMM 2001, San
Diego, August 2001 Diego, August 2001
11. Copyright Notice 11. Copyright Notice
Copyright (C) The Internet Society (2004). This document is subject to Copyright (C) The Internet Society (2005). This document is subject to
the rights, licenses and restrictions contained in BCP 78, and except as the rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights. set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 34 change blocks. 
41 lines changed or deleted 41 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/