draft-ietf-rmt-bb-tfmcc-00.txt   draft-ietf-rmt-bb-tfmcc-01.txt 
Internet Engineering Task Force RMT WG Internet Engineering Task Force RMT WG
INTERNET-DRAFT Joerg Widmer/Univ. Mannheim INTERNET-DRAFT Joerg Widmer/Univ. Mannheim
draft-ietf-rmt-bb-tfmcc-00.txt Mark Handley/ACIRI draft-ietf-rmt-bb-tfmcc-01.txt Mark Handley/ICIR
14 November 2001 1 November 2002
Expires: May 2002 Expires: May 2003
TCP-Friendly Multicast Congestion Control (TFMCC): TCP-Friendly Multicast Congestion Control (TFMCC):
Protocol Specification Protocol Specification
Status of this Document Status of this Document
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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.
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
Expires: May 2002 November 2001 Expires: May 2003 November 2002
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: May 2002 November 2001 Expires: May 2003 November 2002
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
2.2.1. Data Packets. . . . . . . . . . . . . . . . . . . 8 2.2.1. Data Packets. . . . . . . . . . . . . . . . . . . 8
2.2.2. Feedback Packets. . . . . . . . . . . . . . . . . 9 2.2.2. Feedback Packets. . . . . . . . . . . . . . . . . 9
3. Data Sender Protocol. . . . . . . . . . . . . . . . . . 10 3. Data Sender Protocol. . . . . . . . . . . . . . . . . . 10
3.1. Sender Initialization. . . . . . . . . . . . . . . . 10 3.1. Sender Initialization. . . . . . . . . . . . . . . . 10
3.2. Determining the Maximum RTT. . . . . . . . . . . . . 10 3.2. Determining the Maximum RTT. . . . . . . . . . . . . 10
3.3. Adjusting the Sending Rate . . . . . . . . . . . . . 11 3.3. Adjusting the Sending Rate . . . . . . . . . . . . . 11
3.4. Controlling Receiver Feedback. . . . . . . . . . . . 12 3.4. Controlling Receiver Feedback. . . . . . . . . . . . 12
3.5. Assisting Receiver-Side RTT Measurements . . . . . . 13 3.5. Assisting Receiver-Side RTT Measurements . . . . . . 13
3.6. Slowstart. . . . . . . . . . . . . . . . . . . . . . 14 3.6. Slowstart. . . . . . . . . . . . . . . . . . . . . . 14
3.7. Scheduling of Packet Transmissions . . . . . . . . . 14 3.7. Scheduling of Packet Transmissions . . . . . . . . . 15
4. Data Receiver Protocol. . . . . . . . . . . . . . . . . 15 4. Data Receiver Protocol. . . . . . . . . . . . . . . . . 15
4.1. Receiver Initalization . . . . . . . . . . . . . . . 16 4.1. Receiver Initalization . . . . . . . . . . . . . . . 16
4.2. Receiver Leave . . . . . . . . . . . . . . . . . . . 16 4.2. Receiver Leave . . . . . . . . . . . . . . . . . . . 16
4.3. Measurement of the Network Conditions. . . . . . . . 16 4.3. Measurement of the Network Conditions. . . . . . . . 16
4.3.1. Updating the Loss Event Rate. . . . . . . . . . . 16 4.3.1. Updating the Loss Event Rate. . . . . . . . . . . 16
4.3.2. Basic Round-Trip Time Measurement . . . . . . . . 16 4.3.2. Basic Round-Trip Time Measurement . . . . . . . . 16
4.3.3. One-Way Delay Adjustments . . . . . . . . . . . . 17 4.3.3. One-Way Delay Adjustments . . . . . . . . . . . . 17
4.3.4. Receive Rate Measurements . . . . . . . . . . . . 17 4.3.4. Receive Rate Measurements . . . . . . . . . . . . 17
4.4. Setting the Desired Rate . . . . . . . . . . . . . . 18 4.4. Setting the Desired Rate . . . . . . . . . . . . . . 18
4.5. Feedback and Feedback Suppression. . . . . . . . . . 18 4.5. Feedback and Feedback Suppression. . . . . . . . . . 18
5. Calculation of the Loss Event Rate. . . . . . . . . . . 19 5. Calculation of the Loss Event Rate. . . . . . . . . . . 20
5.1. Detection of Lost or Marked Packets. . . . . . . . . 20 5.1. Detection of Lost or Marked Packets. . . . . . . . . 20
5.2. Translation from Loss History to Loss Events . . . . 20 5.2. Translation from Loss History to Loss Events . . . . 21
5.3. Inter-Loss Event Interval. . . . . . . . . . . . . . 21 5.3. Inter-Loss Event Interval. . . . . . . . . . . . . . 22
5.4. Average Loss Interval. . . . . . . . . . . . . . . . 22 5.4. Average Loss Interval. . . . . . . . . . . . . . . . 22
5.5. History Discounting. . . . . . . . . . . . . . . . . 23 5.5. History Discounting. . . . . . . . . . . . . . . . . 23
5.6. Initializing the Loss History after the First 5.6. Initializing the Loss History after the First
Loss Event. . . . . . . . . . . . . . . . . . . . . . . . 25 Loss Event. . . . . . . . . . . . . . . . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . 26 6. Security Considerations . . . . . . . . . . . . . . . . 26
7. IANA Considerations . . . . . . . . . . . . . . . . . . 27 7. IANA Considerations . . . . . . . . . . . . . . . . . . 27
8. Authors' Addresses. . . . . . . . . . . . . . . . . . . 27 8. Authors' Addresses. . . . . . . . . . . . . . . . . . . 27
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . 28 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . 28 10. References . . . . . . . . . . . . . . . . . . . . . . 28
11. Full Copyright Statement . . . . . . . . . . . . . . . 29 11. Full Copyright Statement . . . . . . . . . . . . . . . 29
Expires: May 2002 November 2001 Expires: May 2003 November 2002
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 receivers sets on the order of several thousand conditions and scales to receivers 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: May 2002 November 2001 Expires: May 2003 November 2002
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: May 2002 November 2001 Expires: May 2003 November 2002
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: May 2002 November 2001 Expires: May 2003 November 2002
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: May 2002 November 2001 Expires: May 2003 November 2002
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
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
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
Expires: May 2002 November 2001 Expires: May 2003 November 2002
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
last report, which allows the receiver to measure its RTT. The last report, which allows the receiver to measure its RTT. The
receiver ID is described in the next section. The resolution of the receiver ID is described in the next section. The resolution of the
timestamp echo should be milliseconds and the timestamp should be an timestamp echo should be milliseconds and the timestamp should be an
unsigned integer value no less than 16 bits wide. unsigned integer value no less than 16 bits wide.
o A flag is_CLR indicating whether the receiver with ID r is the CLR. o A flag is_CLR indicating whether the receiver with ID r is the CLR.
skipping to change at page 10, line 5 skipping to change at page 10, line 5
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.
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.
Expires: May 2002 November 2001 Expires: May 2003 November 2002
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
is included in the feedback. If there is a delay t_d between is included in the feedback. If there is a delay t_d between
receiving that last data packet and sending feedback, then ts_i' = receiving that last data packet and sending feedback, then ts_i' =
ts_i + t_d is included in the feedback instead of ts_i. The ts_i + t_d is included in the feedback instead of ts_i. The
representation of the timestamp echo should be the same as that of the representation of the timestamp echo should be the same as that of the
timestamp in the data packets. timestamp in the data packets.
o A feedback round echo fb_nr, reflecting the highest feedback round o A feedback round echo fb_nr, reflecting the highest feedback round
skipping to change at page 10, line 42 skipping to change at page 10, line 42
The main tasks that have to be provided by a TFMCC sender are: The main tasks that have to be provided by a TFMCC sender are:
o adjusting the sending rate, o adjusting the sending rate,
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
To initialize the sender, the value of the sending rate X is set to 1 At initialization of the sender, the maximum RTT is set to a value that
packet/second. The maximum RTT is initialized to a value that should be should be larger than the highest RTT to any of the receivers. It
larger than the highest RTT to any of the receivers. It should not be should not be smaller than 500 milliseconds for operation in the public
smaller than 500 milliseconds for operation in the public Internet. Internet. The sending rate X is initialized to 1 packet per maximum
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
Expires: May 2002 November 2001 Expires: May 2003 November 2002
R_r = t_now - ts_i R_r = t_now - ts_i
where t_now is the time the feedback packet arrived. Receivers will where t_now is the time the feedback packet arrived. Receivers will
have adjusted ts_i for the time interval between receiving the data have adjusted ts_i for the time interval between receiving the last data
packet and sending the corresponding report so that this interval will packet and sending the corresponding report so that this interval will
not be included in R_r. If the instantaneous RTT is larger than the not be included in R_r. If the instantaneous RTT is larger than the
current maximum RTT, the maximum RTT is increased to that value current maximum RTT, the maximum RTT is increased to that value
R_max = R_r R_max = R_r
Otherwise, if no feedback with a higher instantaneous RTT than the Otherwise, if no feedback with a higher instantaneous RTT than the
maximum RTT is received during a feedback round (see Section 3.4), the maximum RTT is received during a feedback round (see Section 3.4), the
maximum RTT is reduced exponentially to maximum RTT is reduced exponentially to
R_max = R_max * 0.95 R_max = R_max * 0.9
which results in a slow decrease over a number of feedback rounds. which results in a slow decrease over a number of feedback rounds.
The maximum RTT is mainly used for feedback suppression among receivers The maximum RTT is mainly used for feedback suppression among receivers
with heterogeneous RTTs. Feedback suppression is closely coupled to the with heterogeneous RTTs. Feedback suppression is closely coupled to the
sending of data packets and for this reason, the maximum RTT must not sending of data packets and for this reason, the maximum RTT must not
decrease below the maximum time interval between consecutive data decrease below the maximum time interval between consecutive data
packets: packets:
R_max = max(R_max, s/X + t_gran) R_max = max(R_max, s/X + t_gran)
skipping to change at page 11, line 46 skipping to change at page 11, line 46
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.
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 that 8s/MaxRTT. this would result in a rate increase of less than 8s/R_max bits/s.
Otherwise X is gradually increased to X_r at an increase rate of no Otherwise X is gradually increased to X_r at an increase rate of no
more than 8s/MaxRTT every MaxRTT seconds. more than 8s/R_max bits/s every R_max seconds.
2 If receiver r is not the CLR but a CLR is present, then receiver r 2 If receiver r is not the CLR but a CLR is present, then receiver r
becomes the current limiting receiver if X_r is less than the becomes the current limiting receiver if X_r is less than the
current sending rate X and the receiver_leave flag of that current sending rate X and the receiver_leave flag of that
Expires: May 2002 November 2001 Expires: May 2003 November 2002
receiver's report is not set. Furthermore, the sending rate is receiver's report is not set. Furthermore, the sending rate is
reduced to X_r. reduced to X_r.
3 If receiver r is not the CLR but a CLR is present and the 3 If receiver r is not the CLR but a CLR is present and the
receiver_leave flag of the CLR's last report was set, then receiver receiver_leave flag of the CLR's last report was set, then receiver
r becomes the current limiting receiver. However, if X_r > X, the r becomes the current limiting receiver. However, if X_r > X, the
sending rate is not increased to X_r for the duration of a feedback sending rate is not increased to X_r for the duration of a feedback
round to allow other (lower rate) receivers to give feedback and be round to allow other (lower rate) receivers to give feedback and be
selected as CLR. selected as CLR.
4 If receiver r is the CLR, the sending rate is set to the minimum of 4 If receiver r is the CLR, the sending rate is set to the minimum of
X_r and X + 8s/MaxRTT. X_r and X + 8s/R_max bits/s.
If the receiver has not yet measured its RTT (i.e., the have_RTT flag is If the receiver has not yet measured its RTT (i.e., the have_RTT flag is
set), the receiver report will include a desired rate that is based on set), the receiver report will include a desired rate that is based on
the maximum RTT rather than the actual RTT to that receiver. In this the maximum RTT rather than the actual RTT to that receiver. In this
case, the sender adjusts the desired rate using its measurement of the case, the sender adjusts the desired rate using its measurement of the
instantaneous RTT R_r to that receiver: instantaneous RTT R_r to that receiver:
X_r' = X_r * R_max / R_r X_r' = X_r * R_max / R_r
X_r' is then used instead of X_r to detect whether to switch to a new X_r' is then used instead of X_r to detect whether to switch to a new
CLR. CLR.
If the TFMCC sender receives no reports from the CLR for at least 10 If the TFMCC sender receives no reports from the CLR for at least 10
RTTs, it assumes that the CLR crashed or left the group. A new CLR is RTTs, it assumes that the CLR crashed or left the group. A new CLR is
selected from the feedback that subsequently arrives at the sender, and selected from the feedback that subsequently arrives at the sender, and
we increase as in case 3 above. we increase as in case 3 above.
In the absence of any feedback from any of the receivers it is necessary In the absence of any feedback from any of the receivers it is necessary
to reduce the sending rate. For every 10 consecutive RTTs without to reduce the sending rate. For every 10 consecutive RTTs without
feedback, the sending rate is cut in half. The rate is at most reduced feedback, the sending rate is cut in half. The rate is at most reduced
to one packet every 64 seconds. Note that when receivers stops to one packet every 64 seconds. Note that when receivers stop receiving
receiving data packets, they will stop sending feedback. This data packets, they will stop sending feedback. This eventually causes
eventually causes the sending to be reduced in the case of network the sending rate to be reduced in the case of network failure. If the
failure. If the network subsequently recovers, a linear increase to the network subsequently recovers, a linear increase to the calculated rate
calculated rate of the CLR will occur at 1 packet/RTT^2. of the CLR will occur at 8s/R_max bits/s every R_max.
3.4. Controlling Receiver Feedback 3.4. Controlling Receiver Feedback
The receivers allowed to send a receiver report are determined in so- The receivers allowed to send a receiver report are determined in so-
called feedback rounds. Feedback rounds have a duration T of six times called feedback rounds. Feedback rounds have a duration T of six times
the maximum RTT. In case the multicast model is ASM, i.e., receiver the maximum RTT. In case the multicast model is ASM, i.e., receiver
feedback is multicast to the whole group, the duration of a feedback feedback is multicast to the whole group, the duration of a feedback
round may be reduced to four times the maximum RTT. round may be reduced to four times the maximum RTT.
Expires: May 2002 November 2001 Expires: May 2003 November 2002
Only receivers wishing to report a rate that is lower than the Only receivers wishing to report a rate that is lower than the
suppression rate X_supp, or those with a higher RTT than MaxRTT may send suppression rate X_supp, or those with a higher RTT than R_max may send
feedback. At the beginning of each feedback round, X_supp is set to the feedback. At the beginning of each feedback round, X_supp is set to the
highest possible value that can be represented. When feedback arrives highest possible value that can be represented. When feedback arrives
at the sender over the course of a feedback round, X_supp is decreased at the sender over the course of a feedback round, X_supp is decreased
such that more and more feedback is suppressed towards the end of the such that more and more feedback is suppressed towards the end of the
round. How receiver feedback is spread out over the feedback round is round. How receiver feedback is spread out over the feedback round is
discussed in Section 4.5. discussed in Section 4.5.
Whenever non-CLR feedback for the current round arrives at the sender, Whenever non-CLR feedback for the current round arrives at the sender,
X_supp is reduced to X_supp is reduced to
X_supp = (1-g) * X_r X_supp = (1-g) * X_r
if X_supp > X_r. Note that X_r must not be adjusted by the sender to if X_supp > X_r. Feedback that causes the corresponding receiver to be
reflect the receiver's RTT in case X_r was calculated using the maximum selected as CLR, but was from a non-CLR receiver at the time of sending
RTT, as is done for setting the sending rate (Section 3.3), otherwise a also contributes to the feedback suppression. Note that X_r must not be
feedback implosion is possible. The parameter g determines to what adjusted by the sender to reflect the receiver's real RTT in case X_r
extent higher rate feedback can suppress lower rate feedback. This was calculated using the maximum RTT, as is done for setting the sending
mechanism guarantees, that the lowest calculated rate reported lies rate (Section 3.3), otherwise a feedback implosion is possible. The
within a factor of g of the actual lowest calculated rate of the parameter g determines to what extent higher rate feedback can suppress
receiver set (see [10]). A value of g of 0.1 is recommended. lower rate feedback. This mechanism guarantees, that the 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
recommended.
The feedback round counter is incremented by one at the end of each After a time span of T, the feedback round ends if non-CLR feedback was
round and the suppression rate X_supp is reset to the highest received during that time. Otherwise, the feedback round ends as soon
representable value. The feedback round counter should restart with as the first non-CLR feedback meesage arrives at the sender but at most
round 0 after a wrap-around of the feedback counter. after 2T. The feedback round counter is incremented by one and the
suppression rate X_supp is reset to the highest representable value.
The feedback round counter restarts with round 0 after a wrap-around.
3.5. Assisting Receiver-Side RTT Measurements 3.5. Assisting Receiver-Side RTT Measurements
Receivers measure their RTT by sending a timestamp with a receiver Receivers measure their RTT by sending a timestamp with a receiver
report, which is echoed in the next data packet. Only one receiver ID report, which is echoed in the next data packet. Only one receiver ID
and timestamp can be included in a data packet. If multiple feedback and timestamp can be included in a data packet. If multiple feedback
messages from different receivers arrive at the sender during the time messages from different receivers arrive at the sender during the time
interval between two data packets, the sender has to decide which interval between two data packets, the sender has to decide which
receiver to allow to measure RTT. receiver to allow to measure RTT.
The sender's timestamp echoes are prioritized in the following order: The sender's timestamp echoes are prioritized in the following order:
1. a new CLR (after a change of CLR's) or a CLR without any previous 1. a new CLR (after a change of CLR's) or a CLR without any previous
RTT measurements RTT measurements
Expires: May 2003 November 2002
2. receivers without any previous RTT measurements in the order of the 2. receivers without any previous RTT measurements in the order of the
feedback round echo of the corresponding receiver report (i.e., feedback round echo of the corresponding receiver report (i.e.,
older feedback first) older feedback first)
Expires: May 2002 November 2001
3. non-CLR receivers with previous RTT measurements, again in 3. non-CLR receivers with previous RTT measurements, again in
ascending order of the feedback round echo of the report ascending order of the feedback round echo of the report
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
skipping to change at page 14, line 29 skipping to change at page 14, line 33
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,
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 increases exponentially. The rate increase is limited to the minimum of
rate reported in the receiver reports. Receivers report twice the rate the rates included in the receiver reports and receivers report twice
at which they currently receive data until they experience a loss event. the rate at which they currently receive data. As in normal congestion
control mode, the receiver with the smallest reported rate becomes CLR.
Since a receiver can never receive data at a rate higher than its link Since a receiver can never receive data at a rate higher than its link
bandwidth, this effectively limits the overshoot to twice this bandwidth, this effectively limits the overshoot to twice this
bandwidth. In case the resulting increase during one MaxRTT is less bandwidth. In case the resulting increase over R_max is less than
than 8s/MaxRTT, the sender may choose to increase the rate by up to 8s/R_max bits/s, the sender may choose to increase the rate by up to
8s/MaxRTT every MaxRTT. The current sending rate is gradually adjusted 8s/R_max bits/s every R_max. The current sending rate is gradually
to the target rate reported in the receiver reports over the course of a adjusted to the target rate reported in the receiver reports over the
RTT. Slowstart is terminated as soon as any one of the receivers course of a RTT. Slowstart is terminated as soon as any one of the
experiences its first packet loss. Since that receiver's calculated receivers experiences its first packet loss. Since that receiver's
rate will be lower than the current sending rate, the receiver will be calculated rate will be lower than the current sending rate, the
selected as CLR. receiver will be selected as CLR.
During slowstart, the upper bound on the rate increase of 8s/MaxRTT During slowstart, the upper bound on the rate increase of 8s/R_max
every RTT does not apply. Only after the TFMCC sender receives the bits/s every RTT does not apply. Only after the TFMCC sender receives
first report with the have_loss flag set is the rate increase limited in the first report with the have_loss flag set is the rate increase
this way. limited in this way.
Expires: May 2003 November 2002
3.7. Scheduling of Packet Transmissions 3.7. Scheduling of Packet Transmissions
As TFMCC is rate-based, and as operating systems typically cannot As TFMCC is rate-based, and as operating systems typically cannot
schedule events precisely, it is necessary to be opportunistic about schedule events precisely, it is necessary to be opportunistic about
Expires: May 2002 November 2001
sending data packets so that the correct average rate is maintained sending data packets so that the correct average rate is maintained
despite the coarse-grain or irregular scheduling of the operating despite the coarse-grain or irregular scheduling of the operating
system. Thus a typical sending loop will calculate the correct inter- system. Thus a typical sending loop will calculate the correct inter-
packet interval, t_ipi, as follows: packet interval, t_ipi, as follows:
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
skipping to change at page 15, line 50 skipping to change at page 16, line 5
4. Data Receiver Protocol 4. Data Receiver Protocol
Receivers measure the current network conditions, namely RTT and loss Receivers measure the current network conditions, namely RTT and loss
event rate, and use this information to calculate a rate that is fair to event rate, and use this information to calculate a rate that is fair to
competing traffic. The rate is then communicated to the sender in competing traffic. The rate is then communicated to the sender in
receiver reports. Due to the potentially large number of receivers, it receiver reports. Due to the potentially large number of receivers, it
is undesirable that all receivers send reports, especially not at the is undesirable that all receivers send reports, especially not at the
same time. same time.
Expires: May 2003 November 2002
In the description of the receiver functionality, we will first address In the description of the receiver functionality, we will first address
how the receivers measure the network parameters and then discuss the how the receivers measure the network parameters and then discuss the
feedback process. feedback process.
Expires: May 2002 November 2001
4.1. Receiver Initalization 4.1. Receiver Initalization
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
skipping to change at page 16, line 46 skipping to change at page 17, line 5
When a receiver gets a data packet that carries the receiver's own ID in When a receiver gets a data packet that carries the receiver's own ID in
the r field, the receiver updates its RTT estimate. the r field, the receiver updates its RTT estimate.
1. The current RTT is calculated as: 1. The current RTT is calculated as:
R_sample = t_now - ts_r R_sample = t_now - ts_r
where t_now is the time the data packet arrives at the receiver and where t_now is the time the data packet arrives at the receiver and
ts_r is the receiver report timestamp echoed in the data packet. ts_r is the receiver report timestamp echoed in the data packet.
2. The smoothed RTT estimate R is updated: Expires: May 2003 November 2002
Expires: May 2002 November 2001 2. The smoothed RTT estimate R is updated:
If no feedback has been received before If no feedback has been received before
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
skipping to change at page 17, line 51 skipping to change at page 18, line 4
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.
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
Expires: May 2003 November 2002
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.
Expires: May 2002 November 2001
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
available yet, the maximum RTT is used instead of the receiver's RTT. available yet, the maximum RTT is used instead of the receiver's RTT.
The desired rate is updated whenever the loss event rate or the RTT The desired rate is updated whenever the loss event rate or the RTT
changes. changes.
As mentioned above, calculation of the desired rate is not possible As mentioned above, calculation of the desired rate is not possible
before the receiver experiences the first loss event and in that case before the receiver experiences the first loss event and in that case
skipping to change at page 18, line 32 skipping to change at page 18, line 34
Let fb_nr be the highest feedback round counter value received by a Let fb_nr be the highest feedback round counter value received by a
receiver. When a new data packet arrives with a higher feedback round receiver. When a new data packet arrives with a higher feedback round
counter than fb_nr, a new feedback round begins and fb_nr is updated. counter than fb_nr, a new feedback round begins and fb_nr is updated.
Outstanding feedback for the old round is cancelled. In case a feedback Outstanding feedback for the old round is cancelled. In case a feedback
number with a value that is more than half the feedback number space number with a value that is more than half the feedback number space
lower than fb_nr is received, the receiver assumes that the feedback lower than fb_nr is received, the receiver assumes that the feedback
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.
If the last data packet received had the receiver's own ID as r and the The CLR sends its feedback independently from all the other receivers
is_CLR flag was set, the receiver immediately sends a feedback packet if once per RTT. Its feedback does not suppress other feedback and cannot
the last feedback packet it sent was at least one RTT ago. be suppressed by other receiver's feedback.
Otherwise, if the receiver's calculated rate is less than the Non-CLR receivers set a feedback timer at the beginning of a feedback
suppression rate or the receiver's RTT is higher than the maximum RTT, round. Using an exponentially weighted random timer mechanism, the
the receiver sets a feedback timer. Using an exponentially weighted feedback timer is set to expire after
random timer mechanism, the feedback timer is set to expire after
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, T is the duration of a feedback round,
N is an estimated upper bound on the number of receivers. N is an estimated upper bound on the number of receivers.
Expires: May 2003 November 2002
N is a constant specific to the TFMCC protocol. Since TFMCC scales to N is a constant specific to the TFMCC protocol. Since TFMCC scales to
up to thousands of receivers, setting N to 10,000 for all receivers (and up to thousands of receivers, setting N to 10,000 for all receivers (and
limiting the TFMCC session to at most 10,000 receivers) is recommended. limiting the TFMCC session to at most 10,000 receivers) is recommended.
Expires: May 2002 November 2001
A feedback packet is sent when the feedback timer expires, unless the A feedback packet is sent when the feedback timer expires, unless the
timer is cancelled beforehand. When the multicast model is ASM, timer is cancelled beforehand. When the multicast model is ASM,
feedback is multicast to the whole group, otherwise the feedback is feedback is multicast to the whole group, otherwise the feedback is
unicast to the sender. The feedback packet includes the calculated rate unicast to the sender. The feedback packet includes the calculated rate
valid at the time the feedback packet is sent (not the rate at the point valid at the time the feedback packet is sent (not the rate at the point
of time when the feedback timer is set). The copy of the timestamp ts_i of time when the feedback timer is set). The copy of the timestamp ts_i
of the last data packet received, which is included in the feedback of the last data packet received, which is included in the feedback
packet, needs to be adjusted by the time interval between receiving the packet, needs to be adjusted by the time interval between receiving the
data packet and sending the report to allow the sender to correctly data packet and sending the report to allow the sender to correctly
infer the instantaneous RTT (i.e., that time interval has to be added to infer the instantaneous RTT (i.e., that time interval has to be added to
the timestamp value). the timestamp value).
The timer is cancelled if a data packet with a lower suppression rate The timer is cancelled if a data packet with a lower suppression rate
than the receiver's calculated rate and and a higher or equal maximum than the receiver's calculated rate and a higher or equal maximum RTT
RTT than the receiver's RTT is received. In case of ASM, it is also than the receiver's RTT is received. Likewise, a data packet indicating
cancelled if a feedback packet from another non-CLR receiver reporting a the beginning of a new feedback round cancels all feedback for older
lower rate is received. rounds. In case of ASM, the timer is also cancelled if a feedback
packet from another non-CLR receiver reporting a lower rate is received.
The feedback suppression process is complicated by the fact that the
calculated rates of the receivers will change during a feedback round.
If the calculated rates decrease rapidly for all receivers, feedback
suppression can no longer prevent a feedback implosion since earlier
feedback will always report a higher rate than current feedback. To make
the feedback suppression mechanism robust in the face of changing rates,
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
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
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.
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).
Expires: May 2003 November 2002
t = t + max(t_now - tr_i - R_max, 0) t = t + max(t_now - tr_i - R_max, 0)
where tr_i is the time when the last data packet arrived at the where tr_i is the time when the last data packet arrived at the
receiver. receiver.
More details on the characteristics of the feedback suppression More details on the characteristics of the feedback suppression
mechanism can be found in [10] and [11]. mechanism can be found in [10] and [11].
5. Calculation of the Loss Event Rate 5. Calculation of the Loss Event Rate
Obtaining an accurate and stable measurement of the loss event rate is Obtaining an accurate and stable measurement of the loss event rate is
of primary importance for TFMCC. Loss rate measurement is performed at of primary importance for TFMCC. Loss rate measurement is performed at
the receiver, based on the detection of lost or marked packets from the the receiver, based on the detection of lost or marked packets from the
sequence numbers of arriving packets. sequence numbers of arriving packets.
Expires: May 2002 November 2001
5.1. Detection of Lost or Marked Packets 5.1. Detection of Lost or Marked Packets
TFMCC assumes that all packets contain a sequence number that is TFMCC assumes that all packets contain a sequence number that is
incremented by one for each packet that is sent. For the purposes of incremented by one for each packet that is sent. For the purposes of
this specification, we require that if a lost packet is retransmitted, this specification, we require that if a lost packet is retransmitted,
the retransmission is given a new sequence number that is the latest in the retransmission is given a new sequence number that is the latest in
the transmission sequence, and not the same sequence number as the the transmission sequence, and not the same sequence number as the
packet that was lost. If a transport protocol has the requirement that packet that was lost. If a transport protocol has the requirement that
it must retransmit with the original sequence number, then the transport it must retransmit with the original sequence number, then the transport
protocol designer must figure out how to distinguish delayed from protocol designer must figure out how to distinguish delayed from
skipping to change at page 20, line 37 skipping to change at page 21, line 5
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
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.
Expires: May 2003 November 2002
For an ECN-capable connection, a marked packet is detected as a For an ECN-capable connection, a marked packet is detected as a
congestion event as soon as it arrives, without having to wait for the congestion event as soon as it arrives, without having to wait for the
arrival of subsequent packets. arrival of subsequent packets.
5.2. Translation from Loss History to Loss Events 5.2. Translation from Loss History to Loss Events
TFMCC requires that the loss event rate be robust to several consecutive TFMCC requires that the loss event rate be robust to several consecutive
packets lost where those packets are part of the same loss event. This packets lost where those packets are part of the same loss event. This
is similar to TCP, which (typically) only performs one halving of the is similar to TCP, which (typically) only performs one halving of the
congestion window during any single RTT. Thus the receivers needs to congestion window during any single RTT. Thus the receivers needs to
map the packet loss history into a loss event record, where a loss event map the packet loss history into a loss event record, where a loss event
is one or more packets lost in a RTT. is one or more packets lost in a RTT.
To determine whether a lost or marked packet should start a new loss To determine whether a lost or marked packet should start a new loss
event, or be counted as part of an existing loss event, we need to event, or be counted as part of an existing loss event, we need to
compare the sequence numbers and timestamps of the packets that arrived compare the sequence numbers and timestamps of the packets that arrived
at the receiver. For a marked packet S_new, its reception time T_new at the receiver. For a marked packet S_new, its reception time T_new
Expires: May 2002 November 2001
can be noted directly. For a lost packet, we can interpolate to infer can be noted directly. For a lost packet, we can interpolate to infer
the nominal "arrival time". Assume: the nominal "arrival time". Assume:
S_loss is the sequence number of a lost packet. S_loss is the sequence number of a lost packet.
S_before is the sequence number of the last packet to arrive with S_before is the sequence number of the last packet to arrive with
sequence number before S_loss. sequence number before S_loss.
S_after is the sequence number of the first packet to arrive with S_after is the sequence number of the first packet to arrive with
sequence number after S_loss. sequence number after S_loss.
skipping to change at page 21, line 35 skipping to change at page 22, line 4
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
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
Expires: May 2003 November 2002
sufficient. sufficient.
If the lost packet S_old was determined to have started the previous If the lost packet S_old was determined to have started the previous
loss event, and we have just determined that S_new has been lost, then loss event, and we have just determined that S_new has been lost, then
we interpolate the nominal arrival times of S_old and S_new, called we interpolate the nominal arrival times of S_old and S_new, called
T_old and T_new respectively. T_old and T_new respectively.
If T_old + R >= T_new, then S_new is part of the existing loss event. If T_old + R >= T_new, then S_new is part of the existing loss event.
Otherwise S_new is the first packet of a new loss event. Otherwise S_new is the first packet of a new loss event.
5.3. Inter-Loss Event Interval 5.3. Inter-Loss Event Interval
If a loss interval, A, is determined to have started with packet If a loss interval, A, is determined to have started with packet
sequence number S_A and the next loss interval, B, started with packet sequence number S_A and the next loss interval, B, started with packet
sequence number S_B, then the number of packets in loss interval A is sequence number S_B, then the number of packets in loss interval A is
given by (S_B - S_A). given by (S_B - S_A).
Expires: May 2002 November 2001
5.4. Average Loss Interval 5.4. Average Loss Interval
To calculate the loss event rate p, we first calculate the average loss To calculate the loss event rate p, we first calculate the average loss
interval. This is done using a filter that weights the n most recent interval. This is done using a filter that weights the n most recent
loss event intervals in such a way that the measured loss event rate loss event intervals in such a way that the measured loss event rate
changes smoothly. changes smoothly.
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)
skipping to change at page 22, line 34 skipping to change at page 23, line 5
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.
Expires: May 2003 November 2002
When calculating the average loss interval we need to decide whether to When calculating the average loss interval we need to decide whether to
include the interval since the most recent packet loss event. We only include the interval since the most recent packet loss event. We only
do this if it is sufficiently large to increase the average loss do this if it is sufficiently large to increase the average loss
interval. interval.
Thus if the most recent loss intervals are I_0 to I_n, with I_0 being Thus if the most recent loss intervals are I_0 to I_n, with I_0 being
the interval since the most recent loss event, then we calculate the the interval since the most recent loss event, then we calculate the
average loss interval I_mean as: average loss interval I_mean as:
Expires: May 2002 November 2001
I_tot0 = 0; I_tot0 = 0;
I_tot1 = 0; I_tot1 = 0;
W_tot = 0; W_tot = 0;
for (i = 0 to n-1) { for (i = 0 to n-1) {
I_tot0 = I_tot0 + (I_i * w_i); I_tot0 = I_tot0 + (I_i * w_i);
W_tot = W_tot + w_i; W_tot = W_tot + w_i;
} }
for (i = 1 to n) { for (i = 1 to n) {
I_tot1 = I_tot1 + (I_i * w_(i-1)); I_tot1 = I_tot1 + (I_i * w_(i-1));
} }
skipping to change at page 23, line 41 skipping to change at page 24, line 5
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.
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:
Expires: May 2003 November 2002
for (i = 1 to n) { for (i = 1 to n) {
DF_i = 1; DF_i = 1;
} }
History discounting also uses a general discount factor DF, also a History discounting also uses a general discount factor DF, also a
floating point number, that is also initialized to 1. First we show how floating point number, that is also initialized to 1. First we show how
the discount factors are used in calculating the average loss interval, the discount factors are used in calculating the average loss interval,
and then we describe later in this section how the discount factors are and then we describe later in this section how the discount factors are
modified over time. modified over time.
As described in Section 5.4 the average loss interval is calculated As described in Section 5.4 the average loss interval is calculated
using the n previous loss intervals I_1, ..., I_n, and the interval I_0 using the n previous loss intervals I_1, ..., I_n, and the interval I_0
Expires: May 2002 November 2001
that represents the number of packets received since the last loss that represents the number of packets received since the last loss
event. The computation of the average loss interval using the discount event. The computation of the average loss interval using the discount
factors is a simple modification of the procedure in Section 5.4, as factors is a simple modification of the procedure in Section 5.4, as
follows: follows:
I_tot0 = I_0 * w_0 I_tot0 = I_0 * w_0
I_tot1 = 0; I_tot1 = 0;
W_tot0 = w_0 W_tot0 = w_0
W_tot1 = 0; W_tot1 = 0;
for (i = 1 to n-1) { for (i = 1 to n-1) {
skipping to change at page 24, line 43 skipping to change at page 25, line 5
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
received since the last loss event. If I_0 is greater than twice received since the last loss event. If I_0 is greater than twice
I_mean, then the new loss interval is considerably larger than the old I_mean, then the new loss interval is considerably larger than the old
ones, and the general discount factor DF is updated to decrease the ones, and the general discount factor DF is updated to decrease the
relative weight on the older intervals, as follows: relative weight on the older intervals, as follows:
Expires: May 2003 November 2002
if (I_0 > 2 * I_mean) { if (I_0 > 2 * I_mean) {
DF = 2 * I_mean/I_0; DF = 2 * I_mean/I_0;
if (DF < THRESHOLD) if (DF < THRESHOLD)
DF = THRESHOLD; DF = THRESHOLD;
} else } else
DF = 1; DF = 1;
A nonzero value for THRESHOLD ensures that older loss intervals from an A nonzero value for THRESHOLD ensures that older loss intervals from an
earlier time of high congestion are not discounted entirely. We earlier time of high congestion are not discounted entirely. We
recommend a THRESHOLD of 0.5. Note that with each new packet arrival, recommend a THRESHOLD of 0.5. Note that with each new packet arrival,
I_0 will increase further, and the discount factor DF will be updated. I_0 will increase further, and the discount factor DF will be updated.
Expires: May 2002 November 2001
When a new loss event occurs, the current interval shifts from I_0 to When a new loss event occurs, the current interval shifts from I_0 to
I_1, loss interval I_i shifts to interval I_(i+1), and the loss interval I_1, loss interval I_i shifts to interval I_(i+1), and the loss interval
I_n is forgotten. The previous discount factor DF has to be I_n is forgotten. The previous discount factor DF has to be
incorporated into the discount array. Because DF_i carries the discount incorporated into the discount array. Because DF_i carries the discount
factor associated with loss interval I_i, the DF_i array has to be factor associated with loss interval I_i, the DF_i array has to be
shifted as well. This is done as follows: shifted as well. This is done as follows:
for (i = 1 to n) { for (i = 1 to n) {
DF_i = DF * DF_i; DF_i = DF * DF_i;
} }
skipping to change at page 25, line 42 skipping to change at page 26, line 5
The number of packets received before the first loss event ususally does The number of packets received before the first loss event ususally 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
sent until the first loss event, the TFMCC receiver calculates the loss sent until the first loss event, the TFMCC receiver calculates the loss
interval that would be required to produce the receive rate X_recv, and interval that would be required to produce the receive rate X_recv, and
uses this synthetic loss interval l_0 to seed the loss history uses this synthetic loss interval l_0 to seed the loss history
mechanism. mechanism.
Expires: May 2003 November 2002
The initial loss interval is calculated by inverting a simplified The initial loss interval is calculated by inverting a simplified
version of the TCP Equation (1). version of the TCP Equation (1).
Expires: May 2002 November 2001
s s
X_recv = sqrt(3/2) * ----------------- X_recv = sqrt(3/2) * -----------------
R * sqrt(1/l_0) R * sqrt(1/l_0)
X_recv * R X_recv * R
==> l_0 = (---------------)^2 ==> l_0 = (---------------)^2
sqrt(3/2) * s sqrt(3/2) * s
The resulting initial loss interval is too small at higher loss rates The resulting initial loss interval is too small at higher loss rates
compared to using the more accurate Eqation (1), which leads to a more compared to using the more accurate Eqation (1), which leads to a more
skipping to change at page 26, line 46 skipping to change at page 27, line 5
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
denial of service. This may occur through spoofed feedback. Thus any denial of service. This may occur through spoofed feedback. Thus any
transport protocol that uses TFMCC should take care to ensure that transport protocol that uses TFMCC should take care to ensure that
feedback is only accepted from valid receivers of the data. The precise feedback is only accepted from valid receivers of the data. The precise
mechanism to achieve this will however depend on the transport protocol mechanism to achieve this will however depend on the transport protocol
itself. itself.
Expires: May 2003 November 2002
Congestion control mechanisms may potentially be manipulated by a greedy Congestion control mechanisms may potentially be manipulated by a greedy
receiver that wishes to receive more than its fair share of network receiver that wishes to receive more than its fair share of network
bandwidth. However, in TFMCC a receiver can only influence the sending bandwidth. However, in TFMCC a receiver can only influence the sending
Expires: May 2002 November 2001
rate if it is the CLR and thus has the lowest calculated rate of all rate if it is the CLR and thus has the lowest calculated rate of all
receivers. If the calculated rate is then manipulated such that it receivers. If the calculated rate is then manipulated such that it
exceeds the calculated rate of the second to lowest receiver, it will exceeds the calculated rate of the second to lowest receiver, it will
cease to be CLR. A greedy receiver can only significantly increase then cease to be CLR. A greedy receiver can only significantly increase then
transmission rate if it is the only participant in the session. If such transmission rate if it is the only participant in the session. If such
scenarios are of concern, possible defenses against such a receiver scenarios are of concern, possible defenses against such a receiver
would normally include some form of nonce that the receiver must feed would normally include some form of nonce that the receiver must feed
back to the sender to prove receipt. However, the details of such a back to the sender to prove receipt. However, the details of such a
nonce would depend on the transport protocol, and in particular on nonce would depend on the transport protocol, and in particular on
whether the transport protocol is reliable or unreliable. whether the transport protocol is reliable or unreliable.
skipping to change at page 27, line 43 skipping to change at page 27, line 47
Joerg Widmer Joerg Widmer
Lehrstuhl Praktische Informatik IV Lehrstuhl Praktische Informatik IV
University of Mannheim University of Mannheim
L 15, 16 - Room 415 L 15, 16 - Room 415
D-68131 Mannheim D-68131 Mannheim
Germany Germany
widmer@informatik.uni-mannheim.de widmer@informatik.uni-mannheim.de
Mark Handley Mark Handley
ACIRI/ICSI ICSI Center for Internet Research
1947 Center St, Suite 600 1947 Center St, Suite 600
Berkeley, CA 94708 Berkeley, CA 94708
mjh@aciri.org mjh@icir.org
Expires: May 2002 November 2001 Expires: May 2003 November 2002
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
Reliable Multicast Research Group, the Reliable Multicast Transport Reliable Multicast Research Group, the Reliable Multicast Transport
Working Group, and the End-to-End Research Group. Working Group, and the End-to-End Research Group.
10. References 10. References
skipping to change at page 29, line 5 skipping to change at page 29, line 5
Transport Protocol for Real-Time Applications", RFC 1889, January Transport Protocol for Real-Time Applications", RFC 1889, January
1996. 1996.
[9] D. Wetherall, D. Ely, and N. Spring, "Robust ECN Signaling with [9] D. Wetherall, D. Ely, and N. Spring, "Robust ECN Signaling with
Nonces", Internet Draft draft-ietf-tsvwg-tcp-nonce-00.txt, January Nonces", Internet Draft draft-ietf-tsvwg-tcp-nonce-00.txt, January
2001, work in progress. Citation for informational purposes only. 2001, work in progress. Citation for informational purposes only.
[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.
Expires: May 2002 November 2001 Expires: May 2003 November 2002
[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. Full Copyright Statement 11. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
 End of changes. 

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