draft-ietf-tsvwg-tfrc-03.txt   draft-ietf-tsvwg-tfrc-04.txt 
Internet Engineering Task Force TSV WG Internet Engineering Task Force TSV WG
INTERNET-DRAFT Mark Handley/ACIRI INTERNET-DRAFT Mark Handley/ICIR
draft-ietf-tsvwg-tfrc-03.txt Jitendra Padhye/ACIRI draft-ietf-tsvwg-tfrc-04.txt Jitendra Padhye/ICIR
Sally Floyd/ACIRI Sally Floyd/ICIR
Joerg Widmer/Univ. Mannheim Joerg Widmer/Univ. Mannheim
20 July 2001 27 April 2002
Expires: January 2002 Expires: October 2002
TCP Friendly Rate Control (TFRC): TCP Friendly Rate Control (TFRC):
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 3, line 10 skipping to change at page 3, line 10
but has a much lower variation of throughput over time but has a much lower variation of throughput over time
compared with TCP, making it more suitable for applications compared with TCP, making it more suitable for applications
such as telephony or streaming media where a relatively smooth such as telephony or streaming media where a relatively smooth
sending rate is of importance. sending rate is of importance.
Table of Contents Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Mechanism. . . . . . . . . . . . . . . . . . . 5 3. Protocol Mechanism. . . . . . . . . . . . . . . . . . . 5
3.1. TCP Throughput Equation. . . . . . . . . . . . . . . 5 3.1. TCP Throughput Equation. . . . . . . . . . . . . . . 6
3.2. Packet Contents. . . . . . . . . . . . . . . . . . . 7 3.2. Packet Contents. . . . . . . . . . . . . . . . . . . 7
3.2.1. Data Packets. . . . . . . . . . . . . . . . . . . 7 3.2.1. Data Packets. . . . . . . . . . . . . . . . . . . 7
3.2.2. Feedback Packets. . . . . . . . . . . . . . . . . 8 3.2.2. Feedback Packets. . . . . . . . . . . . . . . . . 8
4. Data Sender Protocol. . . . . . . . . . . . . . . . . . 8 4. Data Sender Protocol. . . . . . . . . . . . . . . . . . 8
4.1. Measuring the Packet Size. . . . . . . . . . . . . . 8 4.1. Measuring the Packet Size. . . . . . . . . . . . . . 9
4.2. Sender Initialization. . . . . . . . . . . . . . . . 9 4.2. Sender Initialization. . . . . . . . . . . . . . . . 9
4.3. Sender behavior when a feedback packet is 4.3. Sender behavior when a feedback packet is
received. . . . . . . . . . . . . . . . . . . . . . . . . 9 received. . . . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Expiration of nofeedback timer . . . . . . . . . . . 10 4.4. Expiration of nofeedback timer . . . . . . . . . . . 11
4.5. Preventing Oscillations. . . . . . . . . . . . . . . 11 4.5. Preventing Oscillations. . . . . . . . . . . . . . . 11
4.6. Scheduling of Packet Transmissions . . . . . . . . . 12 4.6. Scheduling of Packet Transmissions . . . . . . . . . 12
5. Calculation of the Loss Event Rate (p). . . . . . . . . 13 5. Calculation of the Loss Event Rate (p). . . . . . . . . 13
5.1. Detection of Lost or Marked Packets. . . . . . . . . 13 5.1. Detection of Lost or Marked Packets. . . . . . . . . 13
5.2. Translation from Loss History to Loss Events . . . . 13 5.2. Translation from Loss History to Loss Events . . . . 14
5.3. Inter-loss Event Interval. . . . . . . . . . . . . . 15 5.3. Inter-loss Event Interval. . . . . . . . . . . . . . 15
5.4. Average Loss Interval. . . . . . . . . . . . . . . . 15 5.4. Average Loss Interval. . . . . . . . . . . . . . . . 15
5.5. History Discounting. . . . . . . . . . . . . . . . . 16 5.5. History Discounting. . . . . . . . . . . . . . . . . 17
6. Data Receiver Protocol. . . . . . . . . . . . . . . . . 18 6. Data Receiver Protocol. . . . . . . . . . . . . . . . . 19
6.1. Receiver behavior when a data packet is 6.1. Receiver behavior when a data packet is
received. . . . . . . . . . . . . . . . . . . . . . . . . 19 received. . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2. Expiration of feedback timer . . . . . . . . . . . . 19 6.2. Expiration of feedback timer . . . . . . . . . . . . 20
6.3. Receiver initialization. . . . . . . . . . . . . . . 20 6.3. Receiver initialization. . . . . . . . . . . . . . . 20
6.3.1. Initializing the Loss History after the 6.3.1. Initializing the Loss History after the
First Loss Event . . . . . . . . . . . . . . . . . . . . 20 First Loss Event . . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . 22
9. Authors' Addresses. . . . . . . . . . . . . . . . . . . 21 9. Authors' Addresses. . . . . . . . . . . . . . . . . . . 22
10. Acknowledgments. . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgments. . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . 22
NOTE TO RFC EDITOR: PLEASE DELETE THIS NOTE UPON PUBLICATION.
Changes from draft-ietf-tsvwg-tfrc-03.txt:
* Changed one line in the computation of the weighted average I_mean of
the loss intervals from:
W_tot = w_(i-1) * DF_i;
to:
W_tot = W_tot + w_(i-1) * DF_i;
Bug report from Wendy Lee.
* Removed the specification that the sender sends its current transmit
rate. This was only used to initialize X_recv, and is not needed.
* Said that instead of sending the timestamp and the estimate of the
RTT, the sender could send a coarse-grained counter that increments
every quarter RTT. In this case, the receiver also does not have to
send the timestamp back to the sender.
END OF NOTE TO RFC EDITOR.
1. Introduction 1. Introduction
This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a
congestion control mechanism designed for unicast flows operating in a congestion control mechanism designed for unicast flows operating in a
Internet environment and competing with TCP traffic [2]. Instead of Internet environment and competing with TCP traffic [2]. Instead of
specifying a complete protocol, this document simply specifies a specifying a complete protocol, this document simply specifies a
congestion control mechanism that could be used in a transport protocol congestion control mechanism that could be used in a transport protocol
such as RTP [6], in an application incorporating end-to-end congestion such as RTP [6], in an application incorporating end-to-end congestion
control at the application level, or in the context of endpoint control at the application level, or in the context of endpoint
congestion management [BRS99]. This document does not discuss packet congestion management [BRS99]. This document does not discuss packet
skipping to change at page 7, line 41 skipping to change at page 7, line 49
o A sequence number. This number is incremented by one for each data o A sequence number. This number is incremented by one for each data
packet transmitted. The field must be sufficiently large that it packet transmitted. The field must be sufficiently large that it
does not wrap causing two different packets with the same sequence does not wrap causing two different packets with the same sequence
number to be in the receiver's recent packet history at the same number to be in the receiver's recent packet history at the same
time. time.
o A timestamp indicating when the packet is sent. We denote by ts_i o A timestamp indicating when the packet is sent. We denote by ts_i
the timestamp of the packet with sequence number i. The resolution the timestamp of the packet with sequence number i. The resolution
of the timestamp should typically be measured in milliseconds. of the timestamp should typically be measured in milliseconds.
This timestamp is used by the receiver to determine which losses
belong to the same loss event. The timestamp is also echoed by the
receiver to enable the sender to estimate the round-trip time, for
senders that do not save timestamps of transmitted data packets.
We note that as an alternative to a timestamp incremented in
milliseconds, a "timestamp" that increments every quarter of a
round-trip time would be sufficient for determining when losses
belong to the same loss event, in the context of a protocol where
this is understood by both sender and receiver, and where the
sender saves the timestamps of transmitted data packets.
o The sender's current estimate of the round trip time. The estimate o The sender's current estimate of the round trip time. The estimate
reported in packet i is denoted by R_i. reported in packet i is denoted by R_i. The round-trip time
estimate is used by the receiver, along with the timestamp, to
o The sender's current transmit rate. The estimate reported in packet determine when multiple losses belong to the same loss event.
i is denoted by X_i. If the sender sends a coarse-grained "timestamp" that increments
every quarter of a round-trip time, as discussed above, then the
sender does not need to send its current estimate of the round trip
time.
3.2.2. Feedback Packets 3.2.2. Feedback Packets
Each feedback packet sent by the data receiver contains the following Each feedback packet sent by the data receiver contains the following
information: information:
o The timestamp of the last data packet received. We denote this by o The timestamp of the last data packet received. We denote this by
t_recvdata. If the last packet received at the receiver has t_recvdata. If the last packet received at the receiver has
sequence number i, then t_recvdata = ts_i. sequence number i, then t_recvdata = ts_i.
This timestamp is used by the sender to estimate the round-trip
time, and is only needed if the sender does not save timestamps of
transmitted data packets.
o The amount of time elapsed between the receipt of the last data o The amount of time elapsed between the receipt of the last data
packet at the receiver, and the generation of this feedback report. packet at the receiver, and the generation of this feedback report.
We denote this by t_delay. We denote this by t_delay.
o The rate at which the receiver estimates that data was received o The rate at which the receiver estimates that data was received
since the last feedback report was sent. We denote this by X_recv. since the last feedback report was sent. We denote this by X_recv.
o The receiver's current estimate of the loss event rate, p. o The receiver's current estimate of the loss event rate, p.
skipping to change at page 9, line 27 skipping to change at page 9, line 47
The second class of applications are discussed separately in a separate The second class of applications are discussed separately in a separate
document on TFRC-PS. For the remainder of this section we assume the document on TFRC-PS. For the remainder of this section we assume the
sender can estimate the packet size, and that congestion control is sender can estimate the packet size, and that congestion control is
performed by adjusting the number of packets sent per second. performed by adjusting the number of packets sent per second.
4.2. Sender Initialization 4.2. Sender Initialization
To initialize the sender, the value of X is set to 1 packet/second and To initialize the sender, the value of X is set to 1 packet/second and
the nofeedback timer is set to expire after 2 seconds. The initial the nofeedback timer is set to expire after 2 seconds. The initial
values for R (RTT) and t_RTO are undefined until they are set as values for R (RTT) and t_RTO are undefined until they are set as
described above. The intial value of tld, for the Time Last Doubled described below. The intial value of tld, for the Time Last Doubled
during slow-start, is set to -1. during slow-start, is set to -1.
4.3. Sender behavior when a feedback packet is received 4.3. Sender behavior when a feedback packet is received
The sender knows its current sending rate, X, and maintains an estimate The sender knows its current sending rate, X, and maintains an estimate
of the current round trip time, R, and an estimate of the timeout of the current round trip time, R, and an estimate of the timeout
interval, t_RTO. interval, t_RTO.
When a feedback packet is received by the sender at time t_now, the When a feedback packet is received by the sender at time t_now, the
following actions should be performed: following actions should be performed:
skipping to change at page 13, line 7 skipping to change at page 13, line 31
of a packet. If the operating system has a scheduling timer granularity of a packet. If the operating system has a scheduling timer granularity
of t_gran seconds, then delta would typically be set to: of t_gran seconds, then delta would typically be set to:
delta = min(t_ipi/2, t_gran/2); delta = min(t_ipi/2, t_gran/2);
t_gran is 10ms on many Unix systems. If t_gran is not known, a value of t_gran is 10ms on many Unix systems. If t_gran is not known, a value of
10ms can be safely assumed. 10ms can be safely assumed.
5. Calculation of the Loss Event Rate (p) 5. Calculation of the Loss Event Rate (p)
Obtaining a accurate and stable measurement of the loss event rate is of Obtaining an accurate and stable measurement of the loss event rate is
primary importance for TFRC. Loss rate measurement is performed at the of primary importance for TFRC. Loss rate measurement is performed at
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. We describe this process before sequence numbers of arriving packets. We describe this process before
describing the rest of the receiver protocol. describing the rest of the receiver protocol.
5.1. Detection of Lost or Marked Packets 5.1. Detection of Lost or Marked Packets
TFRC assumes that all packets contain a sequence number that is TFRC 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
skipping to change at page 17, line 33 skipping to change at page 18, line 12
} }
p = min(W_tot0/I_tot0, W_tot1/I_tot1); p = min(W_tot0/I_tot0, W_tot1/I_tot1);
The general discounting factor, DF is updated on every packet arrival as The general discounting factor, DF is updated on every packet arrival as
follows. First, the receiver computes the weighted average I_mean of the follows. First, the receiver computes the weighted average I_mean of the
loss intervals I_1, ..., I_n: loss intervals I_1, ..., I_n:
I_tot = 0; I_tot = 0;
W_tot = 0; W_tot = 0;
for (i = 1 to n) { for (i = 1 to n) {
W_tot = w_(i-1) * DF_i; W_tot = W_tot + w_(i-1) * DF_i;
I_tot = I_tot + (I_i * w_(i-1) * DF_i); I_tot = I_tot + (I_i * w_(i-1) * DF_i);
} }
I_mean = I_tot / W_tot; I_mean = I_tot / W_tot;
This weighted average I_mean is compared to I_0, the number of packets This weighted average I_mean is compared to I_0, the number of packets
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:
skipping to change at page 20, line 14 skipping to change at page 20, line 40
6.3. Receiver initialization 6.3. Receiver initialization
The receiver is initialized by the first packet that arrives at the The receiver is initialized by the first packet that arrives at the
receiver. Let the sequence number of this packet be i. receiver. Let the sequence number of this packet be i.
When the first packet is received: When the first packet is received:
o Set p=0 o Set p=0
o Set X_recv = X_send, where X_send is the sending rate the sender o Set X_recv = 0.
reports in the first data packet.
o Prepare and send a feedback packet. o Prepare and send a feedback packet.
o Set the feedback timer to expire after R_i seconds. o Set the feedback timer to expire after R_i seconds.
6.3.1. Initializing the Loss History after the First Loss Event 6.3.1. Initializing the Loss History after the First Loss Event
The number of packets until the first loss can not be used to compute The number of packets until the first loss can not be used to compute
the sending rate directly, as the sending rate changes rapidly during the sending rate directly, as the sending rate changes rapidly during
this time. TFRC assumes that the correct data rate after the first loss this time. TFRC assumes that the correct data rate after the first loss
skipping to change at page 21, line 36 skipping to change at page 22, line 17
Again, the details of such a nonce would depend on the transport Again, the details of such a nonce would depend on the transport
protocol, and are not addressed in this document. protocol, and are not addressed in this document.
8. IANA Considerations 8. IANA Considerations
There are no IANA actions required for this document. There are no IANA actions required for this document.
9. Authors' Addresses 9. Authors' Addresses
Mark Handley, Jitendra Padhye, Sally Floyd Mark Handley, Jitendra Padhye, Sally Floyd
ACIRI/ICSI ICIR/ICSI
1947 Center St, Suite 600 1947 Center St, Suite 600
Berkeley, CA 94708 Berkeley, CA 94708
mjh@aciri.org, padhye@aciri.org, floyd@aciri.org mjh@icir.org, padhye@icir.org, floyd@icir.org
Joerg Widmer Joerg Widmer
Lehrstuhl Praktische Informatik IV Lehrstuhl Praktische Informatik IV
Universitat Mannheim Universitat 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
10. Acknowledgments 10. 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. We would like to Working Group, and the End-to-End Research Group. We would like to
thank Eduardo Urzaiz, Vladica Stanisic, and Shushan Wen for feedback on thank Ken Lofgren, Eduardo Urzaiz, Vladica Stanisic, Shushan Wen, and
earlier versions of this document, and to thank Mark Allman for his Wendy Lee (lhh@zsu.edu.cn) for feedback on earlier versions of this
extensive feedback from using the draft to produce a working document, and to thank Mark Allman for his extensive feedback from using
implementation. the draft to produce a working implementation.
11. References 11. References
[1] Balakrishnan, H., Rahul, H., and Seshan, S., "An Integrated [1] Balakrishnan, H., Rahul, H., and Seshan, S., "An Integrated
Congestion Management Architecture for Internet Hosts," Proc. ACM Congestion Management Architecture for Internet Hosts," Proc. ACM
SIGCOMM, Cambridge, MA, September 1999. SIGCOMM, Cambridge, MA, September 1999.
[2] S. Floyd, M. Handley, J. Padhye, and J. Widmer, "Equation-Based [2] S. Floyd, M. Handley, J. Padhye, and J. Widmer, "Equation-Based
Congestion Control for Unicast Applications", August 2000, Proc Congestion Control for Unicast Applications", August 2000, Proc
SIGCOMM 2000. SIGCOMM 2000.
skipping to change at page 22, line 36 skipping to change at page 23, line 16
[3] S. Floyd, M. Handley, J. Padhye, and J. Widmer, "Equation-Based [3] S. Floyd, M. Handley, J. Padhye, and J. Widmer, "Equation-Based
Congestion Control for Unicast Applications: the Extended Version", Congestion Control for Unicast Applications: the Extended Version",
ICSI tech report TR-00-03, March 2000. ICSI tech report TR-00-03, March 2000.
[4] Padhye, J. and Firoiu, V. and Towsley, D. and Kurose, J., "Modeling [4] Padhye, J. and Firoiu, V. and Towsley, D. and Kurose, J., "Modeling
TCP Throughput: A Simple Model and its Empirical Validation", Proc TCP Throughput: A Simple Model and its Empirical Validation", Proc
ACM SIGCOMM 1998. ACM SIGCOMM 1998.
[5] Widmer, J., "Equation-Based Congestion Control", Diploma Thesis, [5] Widmer, J., "Equation-Based Congestion Control", Diploma Thesis,
University of Mannheim, February 2000. URL University of Mannheim, February 2000. URL
"http://www.aciri.org/tfrc/". "http://www.icir.org/tfrc/".
[6] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A [6] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A
Transport Protocol for Real-Time Applications", RFC 1889, January Transport Protocol for Real-Time Applications", RFC 1889, January
1996. 1996.
[7] K. Ramakrishnan and S. Floyd, "A Proposal to add Explicit Congestion [7] K. Ramakrishnan and S. Floyd, "A Proposal to add Explicit Congestion
Notification (ECN) to IP", RFC 2481, January 1999. Notification (ECN) to IP", RFC 2481, January 1999.
[8] V. Paxson and M. Allman, "Computing TCP's Retransmission Timer", RFC [8] V. Paxson and M. Allman, "Computing TCP's Retransmission Timer", RFC
2988, November 2000. 2988, November 2000.
 End of changes. 

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