summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4654.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4654.txt')
-rw-r--r--doc/rfc/rfc4654.txt1795
1 files changed, 1795 insertions, 0 deletions
diff --git a/doc/rfc/rfc4654.txt b/doc/rfc/rfc4654.txt
new file mode 100644
index 0000000..af05899
--- /dev/null
+++ b/doc/rfc/rfc4654.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+Network Working Group J. Widmer
+Request for Comments: 4654 DoCoMo Euro-Labs
+Category: Experimental M. Handley
+ UCL
+ August 2006
+
+
+ TCP-Friendly Multicast Congestion Control (TFMCC):
+ Protocol Specification
+
+Status of This Memo
+
+ This memo defines an Experimental Protocol for the Internet
+ community. It does not specify an Internet standard of any kind.
+ Discussion and suggestions for improvement are requested.
+ Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document specifies TCP-Friendly Multicast Congestion Control
+ (TFMCC). TFMCC is a congestion control mechanism for multicast
+ transmissions in a best-effort Internet environment. It is a
+ single-rate congestion control scheme, where the sending rate is
+ adapted to the receiver experiencing the worst network conditions.
+ TFMCC is reasonably fair when competing for bandwidth with TCP flows
+ and has a relatively low variation of throughput over time, making it
+ suitable for applications where a relatively smooth sending rate is
+ of importance, such as streaming media.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Widmer & Handley Experimental [Page 1]
+
+RFC 4654 TFMCC: Protocol Specification August 2006
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Related Documents ..........................................4
+ 1.2. Environmental Requirements and Considerations ..............4
+ 2. Protocol Overview ...............................................5
+ 2.1. TCP Throughput Equation ....................................6
+ 2.2. Packet Contents ............................................7
+ 2.2.1. Sender Packets ......................................8
+ 2.2.2. Feedback Packets ....................................9
+ 3. Data Sender Protocol ...........................................10
+ 3.1. Sender Initialization .....................................10
+ 3.2. Determining the Maximum RTT ...............................10
+ 3.3. Adjusting the Sending Rate ................................11
+ 3.4. Controlling Receiver Feedback .............................12
+ 3.5. Assisting Receiver-Side RTT Measurements ..................14
+ 3.6. Slowstart .................................................15
+ 3.7. Scheduling of Packet Transmissions ........................15
+ 4. Data Receiver Protocol .........................................16
+ 4.1. Receiver Initialization ...................................17
+ 4.2. Receiver Leave ............................................17
+ 4.3. Measurement of the Network Conditions .....................17
+ 4.3.1. Updating the Loss Event Rate .......................17
+ 4.3.2. Basic Round-Trip Time Measurement ..................17
+ 4.3.3. One-Way Delay Adjustments ..........................18
+ 4.3.4. Receive Rate Measurements ..........................19
+ 4.4. Setting the Desired Rate ..................................19
+ 4.5. Feedback and Feedback Suppression .........................20
+ 5. Calculation of the Loss Event Rate .............................22
+ 5.1. Detection of Lost or Marked Packets .......................22
+ 5.2. Translation from Loss History to Loss Events ..............23
+ 5.3. Inter-Loss Event Interval .................................24
+ 5.4. Average Loss Interval .....................................24
+ 5.5. History Discounting .......................................25
+ 5.6. Initializing the Loss History after the First Loss Event ..27
+ 6. Security Considerations ........................................28
+ 7. Acknowledgments ................................................29
+ 8. References .....................................................29
+ 8.1. Normative References ......................................29
+ 8.2. Informative References ....................................29
+
+
+
+
+
+
+
+
+
+
+
+Widmer & Handley Experimental [Page 2]
+
+RFC 4654 TFMCC: Protocol Specification August 2006
+
+
+1. Introduction
+
+ This document specifies TCP-Friendly Multicast Congestion Control
+ (TFMCC) [3]. TFMCC is a source-based, single-rate congestion control
+ scheme that builds upon the unicast TCP-Friendly Rate Control
+ mechanism (TFRC) [4]. TFMCC is stable and responsive under a wide
+ range of network conditions and scales to receiver sets on the order
+ of several thousand receivers. To support scalability, as much
+ congestion control functionality as possible is located at the
+ receivers. Each receiver continuously determines a desired receive
+ rate that is TCP-friendly for the path from the sender to this
+ receiver. Selected receivers then report the rate to the sender in
+ feedback packets.
+
+ TFMCC is a building block as defined in RFC 3048 [1]. Instead of
+ specifying a complete protocol, this document simply specifies a
+ congestion control mechanism that could be used in a transport
+ protocol such as RTP [11], in an application incorporating end-to-end
+ congestion control at the application level. This document does not
+ discuss packet formats, reliability, or implementation-related
+ issues.
+
+ TFMCC is designed to be reasonably fair when competing for bandwidth
+ with TCP flows. A multicast flow is "reasonably fair" if its sending
+ rate is generally within a factor of two of the sending rate of a TCP
+ flow from the sender to the slowest receiver of the multicast group
+ under the same network conditions.
+
+ In general, TFMCC has a low variation of throughput, which makes it
+ suitable for applications where a relatively smooth sending rate is
+ of importance, such as streaming media. The penalty of having smooth
+ throughput while competing fairly for bandwidth is a reduced
+ responsiveness to changes in available bandwidth. Thus TFMCC should
+ be used when the application has a requirement for smooth throughput,
+ in particular, avoiding halving of the sending rate in response to a
+ single packet drop. For applications that simply need to multicast
+ as much data as possible in as short a time as possible, PGMCC [10]
+ may be more suitable.
+
+ This memo contains part of the definitions necessary to fully specify
+ a Reliable Multicast Transport protocol in accordance with RFC 2357.
+ As per RFC 2357, the use of any reliable multicast protocol in the
+ Internet requires an adequate congestion control scheme. This
+ document specifies an experimental congestion control scheme. While
+ waiting for initial deployment and experience to show this scheme to
+ be effective and scalable, the IETF publishes this scheme in the
+ "Experimental" category.
+
+
+
+
+Widmer & Handley Experimental [Page 3]
+
+RFC 4654 TFMCC: Protocol Specification August 2006
+
+
+ It is the intent of the Reliable Multicast Transport (RMT) Working
+ Group to re-submit the specification as an IETF Proposed Standard as
+ soon as the scheme is deemed adequate.
+
+1.1. Related Documents
+
+ As described in RFC 3048 [1], TFMCC is a building block that is
+ intended to be used, in conjunction with other building blocks, to
+ help specify a protocol instantiation. It follows the general
+ guidelines provided in RFC 3269 [2]. In particular, TFMCC is a
+ suitable congestion control building block for NACK-Oriented Reliable
+ Multicast (NORM) [5].
+
+1.2. Environmental Requirements and Considerations
+
+ TFMCC is intended to be a congestion control scheme that can be used
+ in a complete protocol instantiation that delivers objects and
+ streams (both reliable content delivery and streaming of multimedia
+ information).
+
+ TFMCC is most applicable for sessions that deliver a substantial
+ amount of data (i.e., in length from hundreds of kilobytes to many
+ gigabytes) and whose duration is on the order of tens of seconds or
+ more.
+
+ TFMCC is intended for multicast delivery. There are currently two
+ models of multicast delivery: the Any-Source Multicast (ASM) model as
+ defined in [6] and the Source-Specific Multicast (SSM) model as
+ defined in [7]. TFMCC works with both multicast models, but in a
+ slightly different way. When ASM is used, feedback from the
+ receivers is multicast to the sender, as well as to all other
+ receivers. Feedback can be either multicast on the same group
+ address used for sending data or on a separate multicast feedback
+ group address. For SSM, the receivers must unicast the feedback
+ directly to the sender. Hence, feedback from a receiver will not be
+ received by other receivers.
+
+ TFMCC inherently works with all types of networks that allow bi-
+ directional communication, including LANs, WANs, Intranets, the
+ Internet, asymmetric networks, wireless networks, and satellite
+ networks. However, in some network environments varying the sending
+ rate to the receivers may not be advantageous (e.g., for a satellite
+ or wireless network, there may be no mechanism for receivers to
+ effectively reduce their reception rate since there may be a fixed
+ transmission rate allocated to the session).
+
+
+
+
+
+
+Widmer & Handley Experimental [Page 4]
+
+RFC 4654 TFMCC: Protocol Specification August 2006
+
+
+ The difference in responsiveness of TFMCC and TCP may result in
+ significant throughput differences in case of a very low bitrate.
+ TFMCC requires an estimate of the loss event rate to calculate a fair
+ sending rate. This estimate may be inaccurate in case TFMCC receives
+ only very few packets per RTT. TFMCC should not be used together
+ with TCP if the capacity of the bottleneck link is less than 30KBit/s
+ (e.g., a very slow modem connection). TFMCC may also achieve a rate
+ that is very different from the average TCP rate in case buffer space
+ at the bottleneck is severely underprovisioned. In particular, TFMCC
+ is less susceptible to small buffer sizes since TFMCC spaces out
+ packets in time, whereas TCP sends them back to back. Thus TCP is
+ much more likely to see a packet loss if buffer space is scarce.
+
+ TFMCC is designed for applications that use a fixed packet size and
+ vary their sending rate in packets per second in response to
+ congestion. Some applications (e.g., those using audio) require a
+ fixed interval of time between packets and vary their packet size
+ instead of their packet rate in response to congestion. The
+ congestion control mechanism in this document cannot be used by those
+ applications.
+
+2. Protocol Overview
+
+ TFMCC extends the basic mechanisms of TFRC into the multicast domain.
+ In order to compete fairly with TCP, TFMCC receivers individually
+ measure the prevalent network conditions and calculate a rate that is
+ TCP-friendly on the path from the sender to themselves. The rate is
+ 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 (RTT), and packet size. We define a loss event as
+ one or more lost or marked packets from the packets received during
+ one RTT, where a marked packet refers to a congestion indication from
+ Explicit Congestion Notification (ECN) [9]. The sending rate of the
+ multicast transmission is adapted to the receiver experiencing the
+ worst network conditions.
+
+ Basically, TFMCC's congestion control mechanism works as follows:
+
+ o Each receiver measures the loss event rate and its RTT to the
+ sender.
+
+ o Each receiver then uses this information, together with an equation
+ for TCP throughput, to derive a TCP-friendly sending rate.
+
+
+
+
+
+
+
+
+Widmer & Handley Experimental [Page 5]
+
+RFC 4654 TFMCC: Protocol Specification August 2006
+
+
+ o Through a distributed feedback suppression mechanism, only a subset
+ of the receivers are allowed to give feedback to prevent a feedback
+ implosion at the sender. The feedback mechanism ensures that
+ receivers reporting a low desired transmission rate have a high
+ probability of sending feedback.
+
+ o Receivers whose feedback is not suppressed report the calculated
+ transmission rate back to the sender in so-called receiver reports.
+ The receiver reports serve two purposes: they inform the sender
+ about the appropriate transmit rate, and they allow the receivers
+ to measure their RTT.
+
+ o The sender selects the receiver that reports the lowest rate as
+ current limiting receiver (CLR). Whenever feedback with an even
+ lower rate reaches the sender, the corresponding receiver becomes
+ CLR and the sending rate is reduced to match that receiver's
+ calculated rate. The sending rate increases when the CLR reports a
+ calculated rate higher than the current sending rate.
+
+ The dynamics of TFMCC are sensitive to how the measurements are
+ performed and applied and to what feedback suppression mechanism is
+ chosen. We recommend specific mechanisms below to perform and apply
+ these measurements. Other mechanisms are possible, but it is
+ important to understand how the interactions between mechanisms
+ affect the dynamics of TFMCC.
+
+2.1. TCP Throughput Equation
+
+ 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 the TCP throughput equation used must reflect TCP's
+ retransmit timeout behavior, as this dominates TCP throughput at
+ higher loss rates. We 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 loss rate or loss event rate is actually
+ measured. While this match is not perfect for the throughput
+ equation and loss rate measurement mechanisms given below, in
+ practice the assumptions turn out to be close enough.
+
+ The throughput equation we currently recommend for TFMCC is a
+ slightly simplified version of the throughput equation for Reno TCP
+ from [8]:
+
+ 8 s
+ X = --------------------------------------------------------- (1)
+ R * (sqrt(2*p/3) + (12*sqrt(3*p/8) * p * (1+32*p^2)))
+
+
+
+
+
+Widmer & Handley Experimental [Page 6]
+
+RFC 4654 TFMCC: Protocol Specification August 2006
+
+
+ where
+
+ X is the transmit rate in bits/second.
+
+ s is the packet size in bytes.
+
+ R is the round-trip time in seconds.
+
+ p is the loss event rate, between 0.0 and 1.0, of the number of
+ loss events as a fraction of the number of packets transmitted.
+
+ In the future, different TCP equations may be substituted for this
+ equation. The requirement is that the throughput equation be a
+ reasonable approximation of the sending rate of TCP for conformant
+ TCP congestion control.
+
+ 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 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 application. This may not be so in two cases:
+
+ 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 transmit rate. It should normally be safe to use an
+ estimate of the mean packet size for s.
+
+ o The application needs to change the packet size rather than the
+ number of packets per second to perform congestion control. This
+ would normally be the case with packet audio applications where a
+ fixed interval of time needs to be represented by each packet.
+ Such applications need to have a different way of measuring
+ parameters.
+
+ Currently, TFMCC cannot be used for the second class of applications.
+
+2.2. Packet Contents
+
+ Before specifying the sender and receiver functionality, we describe
+ the congestion control information contained in packets sent by the
+ sender and feedback packets from the receivers. Information from the
+ sender can either be sent in separate congestion control messages or
+ piggybacked onto data packets. If separate congestion control
+ messages are sent at time intervals larger than the time interval
+ between data packets (e.g., once per feedback round), it is necessary
+ to be able to include timestamp information destined for more than
+ one receiver to allow a sufficient number of receivers to measure
+ their RTT.
+
+
+
+Widmer & Handley Experimental [Page 7]
+
+RFC 4654 TFMCC: Protocol Specification August 2006
+
+
+ As TFMCC will be used along with a transport protocol, we do not
+ specify packet formats, since these depend on the details of the
+ transport protocol used. The recommended representation of the
+ header fields is given below. Alternatively, if the computational
+ overhead of a floating point representation is prohibitive, fixed
+ point arithmetic can be used at the expense of larger packet headers.
+ Sender and receivers of a specific TFMCC instance need to agree on a
+ common encoding for the header fields.
+
+2.2.1. Sender Packets
+
+ Each packet sent by the data sender contains the following
+ information:
+
+ o A sequence number i. This number is incremented by one for each
+ data packet transmitted. The field must be sufficiently large that
+ it does 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 most cases, the sequence number will be supplied
+ by the transport protocol used along with TFMCC.
+
+ 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, unless their RTT is higher than the maximum RTT
+ described below, in which case they are also eligible to give
+ feedback. The suppression 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 (to represent rates from 100 bit/s
+ to 400 Gbit/s with an error of less than 1%).
+
+ o A timestamp ts_i indicating when the packet is sent. The
+ resolution of the timestamp should typically be milliseconds, and
+ the timestamp should be an unsigned integer value no less than 16
+ bits wide.
+
+ o A receiver ID r and a copy of the timestamp tr_r' = tr_r of that
+ receiver's last report, which allows the receiver to measure its
+ RTT. If there is a delay ts_d between receiving the report from
+ receiver r and sending the data packet, then tr_r' = tr_r + ts_d is
+ included in the packet instead. The receiver ID is described in
+ the next section. The resolution of the timestamp echo should be
+ milliseconds, and the timestamp should be an unsigned integer value
+ no less than 16 bits wide. If separate congestion control messages
+ are used instead of piggybacked ones, the packet needs to contain a
+ list of receiver IDs with corresponding timestamps to allow a
+ sufficient number of receivers to simultaneously measure their RTT.
+ For the default values used for the feedback process, this
+ corresponds to a list size on the order of 10 to 20 entries.
+
+
+
+Widmer & Handley Experimental [Page 8]
+
+RFC 4654 TFMCC: Protocol Specification August 2006
+
+
+ o A flag is_CLR indicating whether the receiver with ID r is the CLR.
+
+ o A feedback round counter fb_nr. This counter is incremented by the
+ sender at the beginning of a new feedback round to notify the
+ receivers that all feedback for older rounds should be suppressed.
+ The feedback round counter should be at least 4 bits wide.
+
+ o A maximum RTT value R_max, representing the maximum of the RTTs of
+ all receivers. The RTT should be measured in milliseconds. An
+ 8-bit floating point value with 4 bits for the unsigned exponent
+ and 4 bits for the unsigned mantissa (to represent RTTs from 1
+ millisecond to 64 seconds with an error of ca. 6%) should be used
+ for the representation.
+
+2.2.2. Feedback Packets
+
+ Each feedback packet sent by a data receiver contains the following
+ information:
+
+ 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
+ address of the receiver.
+
+ o A flag have_RTT indicating whether the receiver has made at least
+ one RTT measurement since it joined the session.
+
+ o A flag have_loss indicating whether the receiver experienced at
+ least one loss event since it joined the session.
+
+ o A flag receiver_leave indicating that the receiver will leave the
+ session (and should therefore not be CLR).
+
+ o A timestamp tr_r indicating when the feedback packet is sent. The
+ representation of the timestamp should be the same as that of the
+ timestamp echo in the data packets.
+
+ o An echo ts_i' of the timestamp of the last data packet received.
+ If the last packet received at the receiver has sequence number i,
+ then ts_i' = ts_i is included in the feedback. If there is a delay
+ tr_d between receiving that last data packet and sending feedback,
+ then ts_i' = ts_i + tr_d is included in the feedback instead. The
+ representation of the timestamp echo should be the same as that of
+ the timestamp in the data packets.
+
+ o A feedback round echo fb_nr, reflecting the highest feedback round
+ counter value received so far. The representation of the feedback
+ round echo should be the same as the one used for the feedback
+ round counter in the data packets.
+
+
+
+Widmer & Handley Experimental [Page 9]
+
+RFC 4654 TFMCC: Protocol Specification August 2006
+
+
+ o The desired sending rate X_r. This is the rate calculated by the
+ receiver to be TCP-friendly on the path from the sender to this
+ receiver. The representation of the desired sending rate should be
+ the same as that of the suppression rate in the data packets.
+
+3. Data Sender Protocol
+
+ The data sender multicasts a stream of data packets to the data
+ receivers at a controlled rate. Whenever feedback is received, the
+ sender checks if it is necessary to switch CLRs and to readjust the
+ sending rate.
+
+ The main tasks that have to be provided by a TFMCC sender are:
+
+ o adjusting the sending rate,
+
+ o controlling receiver feedback, and
+
+ o assisting receiver-side RTT measurements.
+
+3.1. Sender Initialization
+
+ 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 not be smaller than 500 milliseconds for operation in the
+ public Internet. The sending rate X is initialized to 1 packet per
+ maximum RTT.
+
+3.2. Determining the Maximum RTT
+
+ For each feedback packet that arrives at the sender, the sender
+ computes the instantaneous RTT to the receiver as
+
+ R_r = ts_now - ts_i'
+
+ where ts_now is the time the feedback packet arrived. Receivers will
+ have adjusted ts_i' for the time interval between receiving the last
+ data packet and sending the corresponding report so that this
+ interval will not be included in R_r. If the actual RTT is smaller
+ than the resolution of the timestamps and ts_now equals ts_i', then
+ R_r is set to the smallest positive RTT value larger than 0 (i.e., 1
+ millisecond in our case). If the instantaneous RTT is larger than
+ the current maximum RTT, the maximum RTT is increased to that value:
+
+ R_max = R_r
+
+
+
+
+
+
+Widmer & Handley Experimental [Page 10]
+
+RFC 4654 TFMCC: Protocol Specification August 2006
+
+
+ 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 reduced to
+
+ R_max = MAX(R_max * 0.9, R_peak)
+
+ where R_peak is the peak receiver RTT measured during the feedback
+ round.
+
+ The maximum RTT is mainly used for feedback suppression among
+ receivers with heterogeneous RTTs. Feedback suppression is closely
+ coupled to the sending of data packets, and for this reason, the
+ maximum RTT must not decrease below the maximum time interval between
+ consecutive data packets:
+
+ R_max = max(R_max, 8s/X + ts_gran)
+
+ where ts_gran is the granularity of the sender's system clock (see
+ Section 3.7).
+
+3.3. Adjusting the Sending Rate
+
+ 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 to switch to a new CLR.
+
+ How the rate is adjusted depends on the desired rate X_r of the
+ receiver report. We distinguish four cases:
+
+ 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
+ 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 X_r at an increase rate of no 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 becomes the current limiting receiver if X_r is less than the
+ current sending rate X and the receiver_leave flag of that
+ receiver's report is not set. Furthermore, the sending rate is
+ reduced to X_r.
+
+ 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 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 round to allow other (lower rate)
+ receivers to give feedback and be selected as CLR.
+
+
+
+Widmer & Handley Experimental [Page 11]
+
+RFC 4654 TFMCC: Protocol Specification August 2006
+
+
+ 4. If receiver r is the CLR, the sending rate is set to the minimum
+ of X_r and X + 8s/R_max bits/s.
+
+ If the receiver has not yet measured its RTT but already experienced
+ packet loss (indicated by the corresponding flags in the receiver
+ report), 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 case, the sender adjusts the desired rate using its
+ measurement of the instantaneous RTT R_r to that receiver:
+
+ 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
+ CLR.
+
+ 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
+ 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. A new CLR is selected from the feedback that subsequently
+ arrives at the 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 any of the receivers) it is necessary to reduce the sending rate
+ further. For every 10 consecutive RTTs without feedback, the sending
+ rate is cut in half. The rate is at most reduced to one packet every
+ 8 seconds.
+
+ Note that when receivers stop receiving data packets, they will stop
+ sending feedback. This eventually causes the sending rate to be
+ reduced 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 bits/s every R_max.
+
+ An application using TFMCC may have a minimum sending rate
+ requirement, where the application becomes unusable if the sending
+ rate continuously falls below this minimum rate. The application
+ should exclude receivers that report such a low rate from the
+ multicast group. The specific mechanism to do this is application
+ dependent and beyond the scope of this document.
+
+3.4. Controlling Receiver Feedback
+
+ The receivers allowed to send a receiver report are determined in so-
+ 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 feedback is multicast to the whole group) the duration of a
+ feedback round may be reduced to four times the maximum RTT.
+
+
+
+Widmer & Handley Experimental [Page 12]
+
+RFC 4654 TFMCC: Protocol Specification August 2006
+
+
+ Only receivers wishing to report a rate that is lower than the
+ 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 highest possible value that can be represented. When
+ feedback arrives 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 round. How receiver feedback is spread out
+ over the feedback round is discussed in Section 4.5.
+
+ Whenever non-CLR feedback for the current round arrives at the
+ sender, X_supp is reduced to
+
+ X_supp = (1-g) * X_r
+
+ if X_supp > X_r. Feedback that causes the corresponding receiver to
+ be selected as CLR, but that was from a non-CLR receiver at the time
+ of sending, also contributes to the feedback suppression. Note that
+ X_r must not be adjusted by the sender to reflect the receiver's real
+ RTT in case X_r was calculated using the maximum RTT, as is done for
+ setting the sending rate (Section 3.3); otherwise, a feedback
+ implosion is possible. The parameter g determines to what extent
+ higher rate feedback can suppress 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 [13]). A value of g of 0.1 is recommended.
+
+ To allow receivers to suppress their feedback, the sender's
+ suppression rate needs to be updated whenever feedback is received.
+ This 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 congestion control messages are used, by sending a
+ message with the suppression rate whenever the rate changes
+ significantly (i.e., when it is reduced to less than (1-g) times the
+ previously advertised suppression rate).
+
+ 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 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 suppression rate X_supp is reset to the highest representable
+ value. The feedback round counter restarts with round 0 after a
+ wrap-around.
+
+
+
+
+
+
+
+
+
+Widmer & Handley Experimental [Page 13]
+
+RFC 4654 TFMCC: Protocol Specification August 2006
+
+
+3.5. Assisting Receiver-Side RTT Measurements
+
+ Receivers measure their RTT by sending a timestamp with a receiver
+ report, which is echoed by the sender. If congestion control
+ information is piggybacked onto data packets, usually only one
+ receiver ID and timestamp can be included. If multiple feedback
+ messages from different receivers arrive at the sender during the
+ time interval between two data packets, the sender has to decide
+ which receiver to allow to measure the RTT. The same applies if
+ separate congestion control messages allow echoing multiple receiver
+ timestamps simultaneously, but the number of receivers that gave
+ feedback since the last congestion control message exceeds the list
+ size.
+
+ 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
+ RTT measurements
+
+ 2. receivers without any previous RTT measurements in the order of
+ the feedback round echo of the corresponding receiver report
+ (i.e., older feedback first)
+
+ 3. non-CLR receivers with previous RTT measurements, again in
+ ascending order of the feedback round echo of the report
+
+ 4. the CLR
+
+ 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 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.
+
+ Whenever no feedback packets arrive in the interval between two data
+ 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 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.
+
+
+
+
+
+
+
+
+
+Widmer & Handley Experimental [Page 14]
+
+RFC 4654 TFMCC: Protocol Specification August 2006
+
+
+3.6. Slowstart
+
+ TFMCC uses a slowstart mechanism to quickly approach its fair
+ bandwidth share at the start of a session. During slowstart, the
+ sending rate increases exponentially. The rate increase is limited
+ to the minimum of the rates included in the receiver reports, and
+ receivers report twice 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 bandwidth, this effectively limits the
+ overshoot to twice this bandwidth. In case the resulting increase
+ over R_max is less than 8s/R_max bits/s, the sender may choose to
+ increase the rate by up to 8s/R_max bits/s every R_max. The current
+ sending rate is gradually adjusted to the target rate reported in the
+ receiver reports over the course of an RTT. Slowstart is terminated
+ as soon as any one of the receivers experiences its first packet
+ loss. Since that receiver's calculated rate will be lower than the
+ current sending rate, the receiver will be selected as CLR.
+
+ During slowstart, the upper bound on the rate increase of 8s/R_max
+ bits/s every RTT does not apply. Only after the TFMCC sender
+ receives the first report with the have_loss flag set is the rate
+ increase limited in this way.
+
+ Slowstart may also be used after the sender has been idle for some
+ time, to quickly reach the previous sending rate. When the sender
+ stops sending data packets, it records the current sending rate X' =
+ X. Every 10 RTTs, the allowed sending rate will be halved due to
+ lack of receiver feedback, as specified in Section 3.3. This halving
+ may take place multiple times. When the sender resumes, it may
+ perform a slowstart from the current allowed rate up to the recorded
+ rate X'. Slowstart ends after the first packet loss by any of the
+ receivers or as soon as X' is reached.
+
+ To this end, receivers have to clear the have_loss flag after 10 RTTs
+ without data packets as specified in Section 4.3.1. The have_loss
+ flag is only used during slowstart. Therefore, clearing the flag has
+ no effect if no packets arrived due to network partitioning or packet
+ loss.
+
+3.7. Scheduling of Packet Transmissions
+
+ As TFMCC is rate-based, and as operating systems typically cannot
+ schedule events precisely, it is necessary to be opportunistic about
+ sending data packets so that the correct average rate is maintained
+ despite the coarse-grain or irregular scheduling of the operating
+ system. Thus, a typical sending loop will calculate the correct
+ inter-packet interval, ts_ipi, as follows:
+
+
+
+Widmer & Handley Experimental [Page 15]
+
+RFC 4654 TFMCC: Protocol Specification August 2006
+
+
+ ts_ipi = 8s/X
+
+ When a sender first starts sending at time t_0, it calculates ts_ipi
+ and calculates a nominal send time, t_1 = t_0 + ts_ipi, for packet 1.
+ When the application becomes idle, it checks the current time,
+ ts_now, and then requests re-scheduling after (ts_ipi - (ts_now -
+ t_0)) seconds. When the application is re-scheduled, it checks the
+ current time, ts_now, again. If (ts_now > t_1 - delta) then packet 1
+ is sent (see below for delta).
+
+ Now, a new ts_ipi may be calculated and used to calculate a nominal
+ send time, t_2, for packet 2: t_2 = t_1 + ts_ipi. The process then
+ repeats with each successive packet's send time being calculated from
+ the nominal send time of the previous packet. Note that the actual
+ send time ts_i, and not the nominal send time, is included as
+ timestamp in the packet header.
+
+ In some cases, when the nominal send time, t_i, of the next packet is
+ calculated, it may already be the case that ts_now > t_i - delta. In
+ such a case, the packet should be sent immediately. Thus, if the
+ operating system has coarse timer granularity and the transmit rate
+ is high, then TFMCC may send short bursts of several packets
+ separated by intervals of the OS timer granularity.
+
+ The parameter delta is to allow a degree of flexibility in the send
+ time of a packet. If the operating system has a scheduling timer
+ granularity of ts_gran seconds, then delta would typically be set to:
+
+ delta = min(ts_ipi/2, ts_gran/2)
+
+ ts_gran is 10 milliseconds on many Unix systems. If ts_gran is not
+ known, a value of 10 milliseconds can be safely assumed.
+
+4. Data Receiver Protocol
+
+ Receivers measure the current network conditions (namely, RTT and
+ loss 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 receiver reports. Due to the potentially large number of
+ receivers, it is undesirable that all receivers send reports,
+ especially not at the same time.
+
+ In the description of the receiver functionality, we will first
+ address how the receivers measure the network parameters and then
+ discuss the feedback process.
+
+
+
+
+
+
+Widmer & Handley Experimental [Page 16]
+
+RFC 4654 TFMCC: Protocol Specification August 2006
+
+
+4.1. Receiver Initialization
+
+ 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 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.
+ Also, the flags receiver_leave, have_RTT, and have_loss are cleared.
+
+4.2. Receiver Leave
+
+ A receiver that sends feedback but wishes to leave the TFMCC session
+ within the next feedback round may indicate the pending leave by
+ setting 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 the feedback round before the leave takes effect.
+
+4.3. Measurement of the Network Conditions
+
+ Receivers have to update their estimate of the network parameters
+ with each new data packet they receive.
+
+4.3.1. Updating the Loss Event Rate
+
+ When a data packet is received, the receiver adds the packet to the
+ packet history. It then recalculates the new value of the loss event
+ rate p. The loss event rate measurement mechanism is described
+ separately in Section 5.
+
+ When a loss event is detected, the flag have_loss is set. In case no
+ data packets are received for 10 consecutive RTTs, the flag is
+ cleared to allow the sender to slowstart. It is set again when new
+ data packets arrive and a loss event is detected.
+
+4.3.2. Basic Round-Trip Time Measurement
+
+ When a receiver gets a data packet that carries the receiver's own ID
+ in the r field, the receiver updates its RTT estimate.
+
+ 1. The current RTT is calculated as:
+
+ R_sample = tr_now - tr_r'
+
+ where tr_now is the time the data packet arrives at the receiver
+ and tr_r' is the receiver report timestamp echoed in the data
+ packet. If the actual RTT is smaller than the resolution of the
+ timestamps and tr_now equals tr_r', then R_sample is set to the
+ smallest positive RTT value larger than 0 (i.e., 1 millisecond in
+ our case).
+
+
+
+Widmer & Handley Experimental [Page 17]
+
+RFC 4654 TFMCC: Protocol Specification August 2006
+
+
+ 2. The smoothed RTT estimate R is updated:
+
+ If no feedback has been received before
+ R = R_sample
+
+ Else
+ R = q*R + (1-q)*R_sample
+
+ A filter parameter q of 0.5 is recommended for non-CLR receivers.
+ The CLR performs RTT measurements much more frequently and hence
+ 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 constant.
+
+ Optionally, sender-based RTT measurements may be used instead of
+ receiver-based ones. 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 maximum RTT. For sender-based RTT
+ measurements, this RTT measurement 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 the next data packet, using
+ the prioritization rules described in Section 3.5.
+
+ To simplify sender operation, smoothing of RTT samples as described
+ above should still be done at the receiver.
+
+4.3.3. One-Way Delay Adjustments
+
+ When an RTT measurement is performed, the receiver also determines
+ the one-way delay D_r from itself to the sender:
+
+ D_r = tr_r' - ts_i
+
+ where ts_i and tr_r' are the timestamp and receiver report timestamp
+ echo contained in the data packet. With each new data packet j, the
+ receiver can now calculate an updated RTT estimate as:
+
+ R' = max(D_r + tr_now - ts_j, 1 millisecond)
+
+ In between RTT measurements, the updated R' is used instead of the
+ smoothed RTT R. Like the RTT samples, R' must be strictly positive.
+ When a new measurement is made, all interim one-way delay
+ measurements are discarded (i.e., the smoothed RTT is updated
+ according to Section 4.3.2 without taking the interim one-way delay
+ adjustments into account).
+
+
+
+
+
+
+Widmer & Handley Experimental [Page 18]
+
+RFC 4654 TFMCC: Protocol Specification August 2006
+
+
+ For the one-way delay measurements, the clocks of sender and
+ receivers need not be synchronized. Clock skew will cancel itself
+ out when both one-way measurements are added to form an RTT estimate,
+ as long as clock drift between real RTT measurements is negligible.
+
+ The same one-way delay adjustments should be applied to the RTT
+ supplied by the sender when using sender-based RTT measurements.
+
+4.3.4. Receive Rate Measurements
+
+ When a receiver has not experienced any loss events, it cannot
+ calculate 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 to twice the receive rate.
+
+ 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
+ headers, but excluding the link-layer packet headers. A value for k
+ between 2 and 4 is recommended.
+
+4.4. Setting the Desired Rate
+
+ When a receiver measures a non-zero loss event rate, it calculates
+ the desired rate using Equation (1). In case no RTT measurement is
+ available yet, the maximum RTT is used instead of the receiver's RTT.
+ The desired rate X_r is updated whenever the loss event rate or the
+ RTT changes.
+
+ A receiver may decide not to report desired rates that are below 1
+ packet per 8 seconds, since a sender is very slow to recover from
+ such low sending rates. In this case, the receiver reports a desired
+ rate of 1 packet per 8 seconds. However, it must leave the multicast
+ group if for more than 120 seconds, the calculated rate falls below
+ the reported rate and the current sending rate is higher than the
+ receiver's calculated rate.
+
+ As mentioned above, calculation of the desired rate is not possible
+ before the receiver experiences the first loss event. In that case,
+ twice the rate at which data is received is included in the receiver
+ reports as X_r to allow the sender to slowstart as described in
+ Section 3.6. This is also done when the sender resumes sending data
+ packets after the have_loss flag was cleared due to the sender being
+ idle.
+
+
+
+
+
+
+
+
+Widmer & Handley Experimental [Page 19]
+
+RFC 4654 TFMCC: Protocol Specification August 2006
+
+
+4.5. Feedback and Feedback Suppression
+
+ 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 counter than fb_nr, a new feedback round begins and fb_nr is
+ updated. Outstanding feedback for the old round is canceled. In
+ case a feedback 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 round counter wrapped and also cancels the
+ feedback timer and updates fb_nr.
+
+ The CLR sends its feedback independently from all the other receivers
+ once per RTT. Its feedback does not suppress other feedback and
+ cannot be suppressed by other receiver's feedback.
+
+ Non-CLR receivers set a feedback timer at the beginning of a feedback
+ round. Using an exponentially weighted random timer mechanism, the
+ feedback timer is set to expire after
+
+ t = max(T * (1 + log(x)/log(N)), 0)
+
+ where
+
+ x is a random variable uniformly distributed in (0,1],
+
+ 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 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 limiting the TFMCC session to at most 10,000
+ receivers) is recommended.
+
+ A feedback packet is sent when the feedback timer expires, unless the
+ timer is canceled beforehand. When the multicast model is ASM,
+ feedback is multicast to the whole group; otherwise, the feedback is
+ 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 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 packet, needs to be adjusted by the time interval
+ between receiving the 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 the timestamp value).
+
+
+
+
+
+
+Widmer & Handley Experimental [Page 20]
+
+RFC 4654 TFMCC: Protocol Specification August 2006
+
+
+ The timer is canceled if a data packet is received that has a lower
+ suppression rate than the receiver's calculated rate and a higher or
+ equal maximum RTT than the receiver's RTT. Likewise, a data packet
+ indicating the beginning of a new feedback round cancels all feedback
+ for older rounds. In case of ASM, the timer is also canceled if a
+ feedback packet is received from another non-CLR receiver reporting a
+ lower rate.
+
+ 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 is necessary to reschedule the feedback timer in proportion to the
+ change.
+
+ t = t * R_max / R_max'
+
+ 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
+ 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 RTT to the feedback time to prevent a feedback implosion
+ (e.g., in case the sender crashed).
+
+ t = t + max(tr_now - tr_i - R_max, 0)
+
+ where tr_i is the time when the last data packet arrived at the
+ receiver.
+
+ More details on the characteristics of the feedback suppression
+ mechanism can be found in [13] and [3].
+
+
+
+
+
+
+
+
+
+
+
+Widmer & Handley Experimental [Page 21]
+
+RFC 4654 TFMCC: Protocol Specification August 2006
+
+
+5. Calculation of the Loss Event Rate
+
+ Obtaining an accurate and stable measurement of the loss event rate
+ is of primary importance for TFMCC. Loss rate measurement is
+ performed at the receiver, based on the detection of lost or marked
+ packets from the sequence numbers of arriving packets.
+
+5.1. Detection of Lost or Marked Packets
+
+ TFMCC assumes that all packets contain a sequence number that is
+ incremented by one for each packet that is sent. For the purposes of
+ 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 transmission sequence, and not the same sequence
+ number as the packet that was lost. If a transport protocol has the
+ requirement that it must retransmit with the original sequence
+ number, then the transport protocol designer must figure out how to
+ distinguish delayed from retransmitted packets and how to detect lost
+ retransmissions.
+
+ The receivers each maintain a data structure that keeps track of
+ which packets have arrived and which are missing. For the purposes
+ 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 received. In practice, this data structure will normally
+ be stored in a more compact representation, but this is
+ implementation-specific.
+
+ 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
+ requirement for three subsequent packets is the same as with TCP, and
+ it is 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 receiver, the late packet can fill the hole in the
+ reception record, and the receiver can recalculate the loss event
+ rate. Future versions of TFMCC might make the requirement for three
+ subsequent packets adaptive based on experienced packet reordering,
+ but we do not specify such a mechanism here.
+
+ 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 arrival of subsequent packets.
+
+
+
+
+
+
+
+
+
+Widmer & Handley Experimental [Page 22]
+
+RFC 4654 TFMCC: Protocol Specification August 2006
+
+
+5.2. Translation from Loss History to Loss Events
+
+ 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 is similar to TCP, which (typically) only performs
+ one halving of the congestion window during any single RTT. Thus the
+ receivers need to map the packet loss history into a loss event
+ record, where a loss event is one or more packets lost in an RTT.
+
+ 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
+ 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 can be noted directly. For a lost packet, we can
+ interpolate to infer the nominal "arrival time". Assume:
+
+ S_loss is the sequence number of a lost packet.
+
+ S_before is the sequence number of the last packet to arrive with
+ sequence number before S_loss.
+
+ S_after is the sequence number of the first packet to arrive with
+ sequence number after S_loss.
+
+ T_before is the reception time of S_before.
+
+ T_after is the reception time of S_after.
+
+ Note that T_before can be either before or after T_after due to
+ reordering.
+
+ 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
+
+ T_loss = T_before + ( (T_after - T_before)
+ * (S_loss - S_before)/(S_after - S_before) );
+
+ Note that if the sequence space wrapped between S_before and S_after,
+ the sequence numbers must be modified to take this into account
+ before the calculation is performed. If the largest possible
+ 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 sufficient.
+
+
+
+
+
+
+
+Widmer & Handley Experimental [Page 23]
+
+RFC 4654 TFMCC: Protocol Specification August 2006
+
+
+ If the lost packet S_old was determined to have started the previous
+ loss event, and if we have just determined that S_new has been lost,
+ then we interpolate the nominal arrival times of S_old and S_new,
+ called T_old and T_new, respectively.
+
+ 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.
+
+5.3. Inter-Loss Event Interval
+
+ 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_B, then the number of packets in loss
+ interval A is given by (S_B - S_A).
+
+5.4. Average Loss Interval
+
+ 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 loss event intervals in such a way that the measured loss
+ event rate changes smoothly.
+
+ Weights w_0 to w_(n-1) are calculated as:
+
+ If (i < n/2)
+ w_i = 1;
+ Else
+ w_i = 1 - (i - (n/2 - 1))/(n/2 + 1);
+
+ 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
+
+ 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 level of congestion. As currently specified, TFMCC should not be
+ used for values of n significantly greater than 8, for traffic that
+ might 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 to TFMCC's mechanisms to include a more severe response to two
+ or more round-trip times with heavy packet loss.
+
+ When calculating the average loss interval, we need to decide whether
+ to include the interval since the most recent packet loss event. We
+ only do this if it is sufficiently large to increase the average loss
+ interval.
+
+
+
+
+
+Widmer & Handley Experimental [Page 24]
+
+RFC 4654 TFMCC: Protocol Specification August 2006
+
+
+ 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 average loss interval I_mean as:
+
+ I_tot0 = 0;
+ I_tot1 = 0;
+ W_tot = 0;
+ for (i = 0 to n-1) {
+ I_tot0 = I_tot0 + (I_i * w_i);
+ W_tot = W_tot + w_i;
+ }
+ for (i = 1 to n) {
+ I_tot1 = I_tot1 + (I_i * w_(i-1));
+ }
+ I_tot = max(I_tot0, I_tot1);
+ I_mean = I_tot/W_tot;
+
+ The loss event rate, p is simply:
+
+ p = 1 / I_mean;
+
+5.5. History Discounting
+
+ 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
+ interval, regardless of the size of the most recent loss interval.
+ This section describes an optional history discounting mechanism that
+ allows the TFMCC receivers to adjust the weights, concentrating more
+ of the 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 interval.
+
+ 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
+ point number. The discount array maintains the cumulative history of
+ discounting for each loss interval. At the beginning, the values of
+ DF_i in the discount array are initialized to 1:
+
+ for (i = 0 to n) {
+ DF_i = 1;
+ }
+
+ History discounting also uses a general discount factor DF, also a
+ floating point number, that is also initialized to 1. First, we show
+ how the discount factors are used in calculating the average loss
+ interval, and then we describe later in this section how the discount
+ factors are modified over time.
+
+
+
+
+Widmer & Handley Experimental [Page 25]
+
+RFC 4654 TFMCC: Protocol Specification August 2006
+
+
+ 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 that represents the number of packets received since the last
+ loss event. The computation of the average loss interval using the
+ discount factors is a simple modification of the procedure in Section
+ 5.4, as follows:
+
+ I_tot0 = I_0 * w_0
+ I_tot1 = 0;
+ W_tot0 = w_0
+ W_tot1 = 0;
+ for (i = 1 to n-1) {
+ I_tot0 = I_tot0 + (I_i * w_i * DF_i * DF);
+ W_tot0 = W_tot0 + w_i * DF_i * DF;
+ }
+ for (i = 1 to n) {
+ I_tot1 = I_tot1 + (I_i * w_(i-1) * DF_i);
+ W_tot1 = W_tot1 + w_(i-1) * DF_i;
+ }
+ p = min(W_tot0/I_tot0, W_tot1/I_tot1);
+
+ The general discounting factor DF is updated on every packet arrival
+ as follows. First, a receiver computes the weighted average I_mean
+ of the loss intervals I_1, ..., I_n:
+
+ I_tot = 0;
+ W_tot = 0;
+ for (i = 1 to n) {
+ W_tot = w_(i-1) * DF_i;
+ I_tot = I_tot + (I_i * w_(i-1) * DF_i);
+ }
+ I_mean = I_tot / W_tot;
+
+ 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 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 relative weight on the older intervals, as follows:
+
+ if (I_0 > 2 * I_mean) {
+ DF = 2 * I_mean/I_0;
+ if (DF < THRESHOLD)
+ DF = THRESHOLD;
+ } else
+ DF = 1;
+
+
+
+
+
+
+Widmer & Handley Experimental [Page 26]
+
+RFC 4654 TFMCC: Protocol Specification August 2006
+
+
+ A nonzero value for THRESHOLD ensures that older loss intervals from
+ an earlier time of high congestion are not discounted entirely. We
+ 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.
+
+ 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_n is forgotten. The previous discount factor DF has to be
+ 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 shifted as well. This is done as follows:
+
+ for (i = 1 to n) {
+ DF_i = DF * DF_i;
+ }
+ for (i = n-1 to 0 step -1) {
+ DF_(i+1) = DF_i;
+ }
+ I_0 = 1;
+ DF_0 = 1;
+ DF = 1;
+
+ This completes the description of the optional history discounting
+ mechanism. We emphasize that this is an optional mechanism whose
+ sole purpose is to allow TFMCC to respond more quickly to the sudden
+ absence of congestion, as represented by a long current loss
+ interval.
+
+5.6. Initializing the Loss History after the First Loss Event
+
+ The number of packets received before the first loss event usually
+ does 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 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 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 it uses this synthetic loss interval l_0 to
+ seed the loss history mechanism.
+
+ The initial loss interval is calculated by inverting a simplified
+ version of the TCP Equation (1).
+
+
+
+
+
+
+
+
+Widmer & Handley Experimental [Page 27]
+
+RFC 4654 TFMCC: Protocol Specification August 2006
+
+
+ 8s
+ X_recv = sqrt(3/2) * -----------------
+ R * sqrt(1/l_0)
+
+ X_recv * R
+ ==> l_0 = (----------------)^2
+ sqrt(3/2) * 8s
+
+ The resulting initial loss interval is too small at higher loss rates
+ compared to using the more accurate Equation (1), which leads to a
+ more conservative initial loss event rate.
+
+ If a receiver still uses the initial RTT R_max instead of its real
+ RTT, the initial loss interval is too large in case the initial RTT
+ is higher than the actual RTT. As a consequence, the receiver will
+ calculate too high a 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 adjust l_0 as follows:
+
+ l_0 = l_0 * (R/R_max)^2
+
+ No action needs to be taken when the first RTT measurement is made
+ after the initial loss interval left the loss history.
+
+6. Security Considerations
+
+ 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
+ transport protocol. Therefore, security primarily needs to be
+ considered in the context of a specific transport protocol and its
+ authentication mechanisms.
+
+ Congestion control mechanisms can potentially be exploited to create
+ denial of service. This may occur through spoofed feedback. Thus,
+ any transport protocol that uses TFMCC should take care to ensure
+ that feedback is only accepted from valid receivers of the data.
+ However, the precise mechanism to achieve this will depend on the
+ transport protocol itself.
+
+ Congestion control mechanisms may potentially be manipulated by a
+ greedy receiver that wishes to receive more than its fair share of
+ network bandwidth. However, in TFMCC a receiver can only influence
+ the sending 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 exceeds the calculated rate of the second to lowest
+ receiver, it will cease to be CLR. A greedy receiver can only
+ significantly increase the transmission rate if it is the only
+ participant in the session. If such scenarios are of concern,
+
+
+
+Widmer & Handley Experimental [Page 28]
+
+RFC 4654 TFMCC: Protocol Specification August 2006
+
+
+ possible defenses against such a receiver 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 nonce would depend on the
+ transport protocol and, in particular, on whether the transport
+ protocol is reliable or unreliable.
+
+ It is possible that a receiver sends feedback claiming that it has a
+ very low calculated rate. This will reduce the rate of the multicast
+ session and might render it useless but obviously cannot hurt the
+ network itself.
+
+ We expect that protocols incorporating ECN with TFMCC will also want
+ to incorporate feedback from the receiver to the sender using the ECN
+ nonce [12]. The ECN nonce is a modification to ECN that protects the
+ sender from the accidental or malicious concealment of marked
+ packets. Again, the details of such a nonce would depend on the
+ transport protocol and are not addressed in this document.
+
+7. Acknowledgments
+
+ We would like to acknowledge feedback and discussions on equation-
+ based congestion control with a wide range of people, including
+ members of the Reliable Multicast Research Group, the Reliable
+ Multicast Transport Working Group, and the End-to-End Research Group.
+ We would particularly like to thank Brian Adamson, Mark Pullen, Fei
+ Zhao, and Magnus Westerlund for feedback on earlier versions of this
+ document.
+
+8. References
+
+8.1. Normative References
+
+ [1] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S.,
+ and M. Luby, "Reliable Multicast Transport Building Blocks for
+ One-to-Many Bulk-Data Transfer", RFC 3048, January 2001.
+
+ [2] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable
+ Multicast Transport (RMT) Building Blocks and Protocol
+ Instantiation documents", RFC 3269, April 2002.
+
+8.2. Informative References
+
+ [3] J. Widmer and M. Handley, "Extending Equation-Based Congestion
+ Control to Multicast Applications", Proc ACM Sigcomm 2001, San
+ Diego, August 2001.
+
+
+
+
+
+
+Widmer & Handley Experimental [Page 29]
+
+RFC 4654 TFMCC: Protocol Specification August 2006
+
+
+ [4] S. Floyd, M. Handley, J. Padhye, and J. Widmer, "Equation-Based
+ Congestion Control for Unicast Applications", Proc ACM SIGCOMM
+ 2000, Stockholm, August 2000.
+
+ [5] Adamson, B., Bormann, C., Handley, M., and J. Macker,
+ "Negative-Acknowledgment (NACK)-Oriented Reliable Multicast
+ (NORM) Building Blocks", RFC 3941, November 2004.
+
+ [6] Deering, S., "Host extensions for IP multicasting", STD 5, RFC
+ 1112, August 1989.
+
+ [7] H. W. Holbrook, "A Channel Model for Multicast," Ph.D.
+ Dissertation, Stanford University, Department of Computer
+ Science, Stanford, California, August 2001.
+
+ [8] J. Padhye, V. Firoiu, D. Towsley, and J. Kurose, "Modeling TCP
+ Throughput: A Simple Model and its Empirical Validation", Proc
+ ACM SIGCOMM 1998.
+
+ [9] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
+ Explicit Congestion Notification (ECN) to IP", RFC 3168,
+ September 2001.
+
+ [10] L. Rizzo, "pgmcc: a TCP-friendly single-rate multicast
+ congestion control scheme", Proc ACM Sigcomm 2000, Stockholm,
+ August 2000.
+
+ [11] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
+ "RTP: A Transport Protocol for Real-Time Applications", STD 64,
+ RFC 3550, July 2003.
+
+ [12] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
+ Congestion Notification (ECN) Signaling with Nonces", RFC 3540,
+ June 2003.
+
+ [13] J. Widmer and T. Fuhrmann, "Extremum Feedback for Very Large
+ Multicast Groups", Proc NGC 2001, London, November 2001.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Widmer & Handley Experimental [Page 30]
+
+RFC 4654 TFMCC: Protocol Specification August 2006
+
+
+Authors' Addresses
+
+ Joerg Widmer
+ DoCoMo Euro-Labs
+ Landsberger Str. 312, Munich, Germany
+ EMail: widmer@acm.org
+
+
+ Mark Handley
+ UCL (University College London)
+ Gower Street, London WC1E 6BT, UK
+ EMail: m.handley@cs.ucl.ac.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Widmer & Handley Experimental [Page 31]
+
+RFC 4654 TFMCC: Protocol Specification August 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Widmer & Handley Experimental [Page 32]
+