RFC3448 日本語訳
3448 TCP Friendly Rate Control (TFRC): Protocol Specification. M.Handley, S. Floyd, J. Padhye, J. Widmer. January 2003. (Format: TXT=52657 bytes) (Obsoleted by RFC5348) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Handley
Request for Comments: 3448 S. Floyd
Category: Standards Track ICIR
J. Padhye
Microsoft
J. Widmer
University of Mannheim
January 2003
Network Working Group M. Handley Request for Comments: 3448 S. Floyd Category: Standards Track ICIR J. Padhye Microsoft J. Widmer University of Mannheim January 2003
TCP Friendly Rate Control (TFRC):
Protocol Specification
TCP Friendly Rate Control (TFRC): Protocol Specification
Status of this Memo
Status of this Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
Abstract
This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best- effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as telephony or streaming media where a relatively smooth sending rate is of importance.
This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best- effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as telephony or streaming media where a relatively smooth sending rate is of importance.
Table of Contents
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Mechanism. . . . . . . . . . . . . . . . . . . 3
3.1. TCP Throughput Equation. . . . . . . . . . . . . . 4
3.2. Packet Contents. . . . . . . . . . . . . . . . . . 6
3.2.1. Data Packets. . . . . . . . . . . . . . . . 6
3.2.2. Feedback Packets. . . . . . . . . . . . . . 7
4. Data Sender Protocol. . . . . . . . . . . . . . . . . . 7
4.1. Measuring the Packet Size. . . . . . . . . . . . . 8
4.2. Sender Initialization. . . . . . . . . . . . . . . 8
1. Introduction. . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Mechanism. . . . . . . . . . . . . . . . . . . 3 3.1. TCP Throughput Equation. . . . . . . . . . . . . . 4 3.2. Packet Contents. . . . . . . . . . . . . . . . . . 6 3.2.1. Data Packets. . . . . . . . . . . . . . . . 6 3.2.2. Feedback Packets. . . . . . . . . . . . . . 7 4. Data Sender Protocol. . . . . . . . . . . . . . . . . . 7 4.1. Measuring the Packet Size. . . . . . . . . . . . . 8 4.2. Sender Initialization. . . . . . . . . . . . . . . 8
Handley, et. al. Standards Track [Page 1] RFC 3448 TFRC: Protocol Specification January 2003
Handley, et. al. Standards Track [Page 1] RFC 3448 TFRC: Protocol Specification January 2003
4.3. Sender behavior when a feedback packet is
received. . . . . . . . . . . . . .. . . . . . . . 8
4.4. Expiration of nofeedback timer . . . . . . . . . . 9
4.5. Preventing Oscillations. . . . . . . . . . . . . . 10
4.6. Scheduling of Packet Transmissions . . . . . . . . 11
5. Calculation of the Loss Event Rate (p). . . . . . . . . 12
5.1. Detection of Lost or Marked Packets. . . . . . . . 12
5.2. Translation from Loss History to Loss Events . . . 13
5.3. Inter-loss Event Interval. . . . . . . . . . . . . 14
5.4. Average Loss Interval. . . . . . . . . . . . . . . 14
5.5. History Discounting. . . . . . . . . . . . . . . . 15
6. Data Receiver Protocol. . . . . . . . . . . . . . . . . 17
6.1. Receiver behavior when a data packet is
received . . . . . . . . . . . . . . . . . . . . . 18
6.2. Expiration of feedback timer . . . . . . . . . . . 18
6.3. Receiver initialization. . . . . . . . . . . . . . 19
6.3.1. Initializing the Loss History after the
First Loss Event . . . . . . . . . . . . . 19
7. Sender-based Variants . . . . . . . . . . . . . . . . . 20
8. Implementation Issues . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . 21
10. IANA Considerations . . . . . . . . . . . . . . . . . . 22
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . 22
12. Non-Normative References. . . . . . . . . . . . . . . . 22
13. Authors' Addresses. . . . . . . . . . . . . . . . . . . 23
14. Full Copyright Statement. . . . . . . . . . . . . . . . 24
4.3. Sender behavior when a feedback packet is received. . . . . . . . . . . . . .. . . . . . . . 8 4.4. Expiration of nofeedback timer . . . . . . . . . . 9 4.5. Preventing Oscillations. . . . . . . . . . . . . . 10 4.6. Scheduling of Packet Transmissions . . . . . . . . 11 5. Calculation of the Loss Event Rate (p). . . . . . . . . 12 5.1. Detection of Lost or Marked Packets. . . . . . . . 12 5.2. Translation from Loss History to Loss Events . . . 13 5.3. Inter-loss Event Interval. . . . . . . . . . . . . 14 5.4. Average Loss Interval. . . . . . . . . . . . . . . 14 5.5. History Discounting. . . . . . . . . . . . . . . . 15 6. Data Receiver Protocol. . . . . . . . . . . . . . . . . 17 6.1. Receiver behavior when a data packet is received . . . . . . . . . . . . . . . . . . . . . 18 6.2. Expiration of feedback timer . . . . . . . . . . . 18 6.3. Receiver initialization. . . . . . . . . . . . . . 19 6.3.1. Initializing the Loss History after the First Loss Event . . . . . . . . . . . . . 19 7. Sender-based Variants . . . . . . . . . . . . . . . . . 20 8. Implementation Issues . . . . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . 21 10. IANA Considerations . . . . . . . . . . . . . . . . . . 22 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . 22 12. Non-Normative References. . . . . . . . . . . . . . . . 22 13. Authors' Addresses. . . . . . . . . . . . . . . . . . . 23 14. Full Copyright Statement. . . . . . . . . . . . . . . . 24
1. Introduction
1. Introduction
This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a congestion control mechanism designed for unicast flows operating in an Internet environment and competing with TCP traffic [2]. 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 [7], in an application incorporating end-to-end congestion control at the application level, or in the context of endpoint congestion management [1]. This document does not discuss packet formats or reliability. Implementation-related issues are discussed only briefly, in Section 8.
This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a congestion control mechanism designed for unicast flows operating in an Internet environment and competing with TCP traffic [2]. 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 [7], in an application incorporating end-to-end congestion control at the application level, or in the context of endpoint congestion management [1]. This document does not discuss packet formats or reliability. Implementation-related issues are discussed only briefly, in Section 8.
TFRC is designed to be reasonably fair when competing for bandwidth with TCP flows, where a flow is "reasonably fair" if its sending rate is generally within a factor of two of the sending rate of a TCP flow under the same conditions. However, TFRC has a much lower variation of throughput over time compared with TCP, which makes it more suitable for applications such as telephony or streaming media where a relatively smooth sending rate is of importance.
TFRC is designed to be reasonably fair when competing for bandwidth with TCP flows, where a flow is "reasonably fair" if its sending rate is generally within a factor of two of the sending rate of a TCP flow under the same conditions. However, TFRC has a much lower variation of throughput over time compared with TCP, which makes it more suitable for applications such as telephony or streaming media where a relatively smooth sending rate is of importance.
Handley, et. al. Standards Track [Page 2] RFC 3448 TFRC: Protocol Specification January 2003
Handley, et. al. Standards Track [Page 2] RFC 3448 TFRC: Protocol Specification January 2003
The penalty of having smoother throughput than TCP while competing fairly for bandwidth is that TFRC responds slower than TCP to changes in available bandwidth. Thus TFRC should only be used when the application has a requirement for smooth throughput, in particular, avoiding TCP's halving of the sending rate in response to a single packet drop. For applications that simply need to transfer as much data as possible in as short a time as possible we recommend using TCP, or if reliability is not required, using an Additive-Increase, Multiplicative-Decrease (AIMD) congestion control scheme with similar parameters to those used by TCP.
The penalty of having smoother throughput than TCP while competing fairly for bandwidth is that TFRC responds slower than TCP to changes in available bandwidth. Thus TFRC should only be used when the application has a requirement for smooth throughput, in particular, avoiding TCP's halving of the sending rate in response to a single packet drop. For applications that simply need to transfer as much data as possible in as short a time as possible we recommend using TCP, or if reliability is not required, using an Additive-Increase, Multiplicative-Decrease (AIMD) congestion control scheme with similar parameters to those used by TCP.
TFRC is designed for applications that use a fixed packet size, and vary their sending rate in packets per second in response to congestion. Some audio applications require a fixed interval of time between packets and vary their packet size instead of their packet rate in response to congestion. The congestion control mechanism in this document cannot be used by those applications; TFRC-PS (for TFRC-PacketSize) is a variant of TFRC for applications that have a fixed sending rate but vary their packet size in response to congestion. TFRC-PS will be specified in a later document.
TFRC is designed for applications that use a fixed packet size, and vary their sending rate in packets per second in response to congestion. Some audio applications require a fixed interval of time between packets and vary their packet size instead of their packet rate in response to congestion. The congestion control mechanism in this document cannot be used by those applications; TFRC-PS (for TFRC-PacketSize) is a variant of TFRC for applications that have a fixed sending rate but vary their packet size in response to congestion. TFRC-PS will be specified in a later document.
TFRC is a receiver-based mechanism, with the calculation of the congestion control information (i.e., the loss event rate) in the data receiver rather in the data sender. This is well-suited to an application where the sender is a large server handling many concurrent connections, and the receiver has more memory and CPU cycles available for computation. In addition, a receiver-based mechanism is more suitable as a building block for multicast congestion control.
TFRC is a receiver-based mechanism, with the calculation of the congestion control information (i.e., the loss event rate) in the data receiver rather in the data sender. This is well-suited to an application where the sender is a large server handling many concurrent connections, and the receiver has more memory and CPU cycles available for computation. In addition, a receiver-based mechanism is more suitable as a building block for multicast congestion control.
2. Terminology
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 and indicate requirement levels for compliant TFRC implementations.
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 and indicate requirement levels for compliant TFRC implementations.
3. Protocol Mechanism
3. Protocol Mechanism
For its congestion control mechanism, TFRC directly uses a throughput equation for the allowed sending rate as a function of the loss event rate and round-trip time. In order to compete fairly with TCP, TFRC uses the TCP throughput equation, which roughly describes TCP's sending rate as a function of the loss event rate, round-trip time, and packet size. We define a loss event as one or more lost or marked packets from a window of data, where a marked packet refers to a congestion indication from Explicit Congestion Notification (ECN) [6].
For its congestion control mechanism, TFRC directly uses a throughput equation for the allowed sending rate as a function of the loss event rate and round-trip time. In order to compete fairly with TCP, TFRC uses the TCP throughput equation, which roughly describes TCP's sending rate as a function of the loss event rate, round-trip time, and packet size. We define a loss event as one or more lost or marked packets from a window of data, where a marked packet refers to a congestion indication from Explicit Congestion Notification (ECN) [6].
Handley, et. al. Standards Track [Page 3] RFC 3448 TFRC: Protocol Specification January 2003
Handley, et. al. Standards Track [Page 3] RFC 3448 TFRC: Protocol Specification January 2003
Generally speaking, TFRC's congestion control mechanism works as follows:
Generally speaking, TFRC's congestion control mechanism works as follows:
o The receiver measures the loss event rate and feeds this
information back to the sender.
o The receiver measures the loss event rate and feeds this information back to the sender.
o The sender also uses these feedback messages to measure the
round-trip time (RTT).
o The sender also uses these feedback messages to measure the round-trip time (RTT).
o The loss event rate and RTT are then fed into TFRC's throughput
equation, giving the acceptable transmit rate.
o The loss event rate and RTT are then fed into TFRC's throughput equation, giving the acceptable transmit rate.
o The sender then adjusts its transmit rate to match the calculated
rate.
o The sender then adjusts its transmit rate to match the calculated rate.
The dynamics of TFRC are sensitive to how the measurements are performed and applied. 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 TFRC.
The dynamics of TFRC are sensitive to how the measurements are performed and applied. 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 TFRC.
3.1. TCP Throughput Equation
3.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 TFRC. 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.
Any realistic equation giving TCP throughput as a function of loss event rate and RTT should be suitable for use in TFRC. 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 TFRC is a slightly simplified version of the throughput equation for Reno TCP from [4]. Ideally we'd prefer a throughput equation based on SACK TCP, but no one has yet derived the throughput equation for SACK TCP, and from both simulations and experiments, the differences between the two equations are relatively minor.
The throughput equation we currently recommend for TFRC is a slightly simplified version of the throughput equation for Reno TCP from [4]. Ideally we'd prefer a throughput equation based on SACK TCP, but no one has yet derived the throughput equation for SACK TCP, and from both simulations and experiments, the differences between the two equations are relatively minor.
The throughput equation is:
The throughput equation is:
s
X = ----------------------------------------------------------
R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8) * p * (1+32*p^2)))
s X = ---------------------------------------------------------- R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8) * p * (1+32*p^2)))
Handley, et. al. Standards Track [Page 4] RFC 3448 TFRC: Protocol Specification January 2003
Handley, et. al. Standards Track [Page 4] RFC 3448 TFRC: Protocol Specification January 2003
Where:
Where:
X is the transmit rate in bytes/second.
X is the transmit rate in bytes/second.
s is the packet size in bytes.
s is the packet size in bytes.
R is the round trip time in seconds.
R is the round trip time in seconds.
p is the loss event rate, between 0 and 1.0, of the number of loss
events as a fraction of the number of packets transmitted.
p is the loss event rate, between 0 and 1.0, of the number of loss events as a fraction of the number of packets transmitted.
t_RTO is the TCP retransmission timeout value in seconds.
t_RTO is the TCP retransmission timeout value in seconds.
b is the number of packets acknowledged by a single TCP
acknowledgement.
b is the number of packets acknowledged by a single TCP acknowledgement.
We further simplify this by setting t_RTO = 4*R. A more accurate calculation of t_RTO is possible, but experiments with the current setting have resulted in reasonable fairness with existing TCP implementations [9]. Another possibility would be to set t_RTO = max(4R, one second), to match the recommended minimum of one second on the RTO [5].
We further simplify this by setting t_RTO = 4*R. A more accurate calculation of t_RTO is possible, but experiments with the current setting have resulted in reasonable fairness with existing TCP implementations [9]. Another possibility would be to set t_RTO = max(4R, one second), to match the recommended minimum of one second on the RTO [5].
Many current TCP connections use delayed acknowledgements, sending an acknowledgement for every two data packets received, and thus have a sending rate modeled by b = 2. However, TCP is also allowed to send an acknowledgement for every data packet, and this would be modeled by b = 1. Because many TCP implementations do not use delayed acknowledgements, we recommend b = 1.
Many current TCP connections use delayed acknowledgements, sending an acknowledgement for every two data packets received, and thus have a sending rate modeled by b = 2. However, TCP is also allowed to send an acknowledgement for every data packet, and this would be modeled by b = 1. Because many TCP implementations do not use delayed acknowledgements, we recommend b = 1.
In 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.
In 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 TFRC implementation. The measurement of s is specified in Section 4.1, measurement of R is specified in Section 4.3, and measurement of p is specified in Section 5. In the rest of this document all data rates are measured in bytes/second.
The parameters s (packet size), p (loss event rate) and R (RTT) need to be measured or calculated by a TFRC implementation. The measurement of s is specified in Section 4.1, measurement of R is specified in Section 4.3, and measurement of p is specified in Section 5. In the rest of this document all data rates are measured in bytes/second.
Handley, et. al. Standards Track [Page 5] RFC 3448 TFRC: Protocol Specification January 2003
Handley, et. al. Standards Track [Page 5] RFC 3448 TFRC: Protocol Specification January 2003
3.2. Packet Contents
3.2. Packet Contents
Before specifying the sender and receiver functionality, we describe the contents of the data packets sent by the sender and feedback packets sent by the receiver. As TFRC will be used along with a transport protocol, we do not specify packet formats, as these depend on the details of the transport protocol used.
Before specifying the sender and receiver functionality, we describe the contents of the data packets sent by the sender and feedback packets sent by the receiver. As TFRC will be used along with a transport protocol, we do not specify packet formats, as these depend on the details of the transport protocol used.
3.2.1. Data Packets
3.2.1. Data Packets
Each data packet sent by the data sender contains the following information:
Each data packet sent by the data sender contains the following information:
o A sequence number. 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.
o A sequence number. 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.
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 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 A timestamp indicating when the packet is sent. We denote by ts_i the timestamp of the packet with sequence number i. The resolution 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 reported in packet i is denoted by R_i. The round-trip
time estimate is used by the receiver, along with the timestamp,
to determine when multiple losses belong to the same loss event.
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.
o The sender's current estimate of the round trip time. The estimate reported in packet i is denoted by R_i. The round-trip time estimate is used by the receiver, along with the timestamp, to determine when multiple losses belong to the same loss event. 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.
Handley, et. al. Standards Track [Page 6] RFC 3448 TFRC: Protocol Specification January 2003
Handley, et. al. Standards Track [Page 6] RFC 3448 TFRC: Protocol Specification January 2003
3.2.2. Feedback Packets
3.2.2. Feedback Packets
Each feedback packet sent by the data receiver contains the following information:
Each feedback packet sent by the data receiver contains the following information:
o The timestamp of the last data packet received. We denote this by
t_recvdata. If the last packet received at the receiver has
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 timestamp of the last data packet received. We denote this by t_recvdata. If the last packet received at the receiver has 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
packet at the receiver, and the generation of this feedback
report. We denote this by t_delay.
o The amount of time elapsed between the receipt of the last data packet at the receiver, and the generation of this feedback report. We denote this by t_delay.
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.
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.
o The receiver's current estimate of the loss event rate, p.
o The receiver's current estimate of the loss event rate, p.
4. Data Sender Protocol
4. Data Sender Protocol
The data sender sends a stream of data packets to the data receiver at a controlled rate. When a feedback packet is received from the data receiver, the data sender changes its sending rate, based on the information contained in the feedback report. If the sender does not receive a feedback report for two round trip times, it cuts its sending rate in half. This is achieved by means of a timer called the nofeedback timer.
The data sender sends a stream of data packets to the data receiver at a controlled rate. When a feedback packet is received from the data receiver, the data sender changes its sending rate, based on the information contained in the feedback report. If the sender does not receive a feedback report for two round trip times, it cuts its sending rate in half. This is achieved by means of a timer called the nofeedback timer.
We specify the sender-side protocol in the following steps:
We specify the sender-side protocol in the following steps:
o Measurement of the mean packet size being sent.
o Measurement of the mean packet size being sent.
o The sender behavior when a feedback packet is received.
o The sender behavior when a feedback packet is received.
o The sender behavior when the nofeedback timer expires.
o The sender behavior when the nofeedback timer expires.
o Oscillation prevention (optional)
o Oscillation prevention (optional)
o Scheduling of transmission on non-realtime operating systems.
o Scheduling of transmission on non-realtime operating systems.
Handley, et. al. Standards Track [Page 7] RFC 3448 TFRC: Protocol Specification January 2003
Handley, et. al. Standards Track [Page 7] RFC 3448 TFRC: Protocol Specification January 2003
4.1. Measuring the Packet Size
4.1. Measuring the Packet Size
The parameter s (packet size) is normally known to an application. This may not be so in two cases:
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 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 completely different way of
measuring parameters.
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 completely different way of measuring parameters.
The second class of applications are discussed separately in a separate document on TFRC-PS. For the remainder of this section we assume the sender can estimate the packet size, and that congestion control is performed by adjusting the number of packets sent per second.
The second class of applications are discussed separately in a separate document on TFRC-PS. For the remainder of this section we assume the sender can estimate the packet size, and that congestion control is 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 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 described below. The initial value of tld, for the Time Last Doubled during slow-start, is set to -1.
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 values for R (RTT) and t_RTO are undefined until they are set as described below. The initial value of tld, for the Time Last Doubled 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 of the current round trip time, R, and an estimate of the timeout interval, t_RTO.
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 interval, t_RTO.
When a feedback packet is received by the sender at time t_now, the following actions should be performed:
When a feedback packet is received by the sender at time t_now, the following actions should be performed:
1) Calculate a new round trip sample.
R_sample = (t_now - t_recvdata) - t_delay.
1) Calculate a new round trip sample. R_sample = (t_now - t_recvdata) - t_delay.
Handley, et. al. Standards Track [Page 8] RFC 3448 TFRC: Protocol Specification January 2003
Handley, et. al. Standards Track [Page 8] RFC 3448 TFRC: Protocol Specification January 2003
2) Update the round trip time estimate:
2) Update the round trip time estimate:
If no feedback has been received before
R = R_sample;
Else
R = q*R + (1-q)*R_sample;
If no feedback has been received before R = R_sample; Else R = q*R + (1-q)*R_sample;
TFRC is not sensitive to the precise value for the filter constant q, but we recommend a default value of 0.9.
TFRC is not sensitive to the precise value for the filter constant q, but we recommend a default value of 0.9.
3) Update the timeout interval:
3) Update the timeout interval:
t_RTO = 4*R.
t_RTO = 4*R.
4) Update the sending rate as follows:
4) Update the sending rate as follows:
If (p > 0)
Calculate X_calc using the TCP throughput equation.
X = max(min(X_calc, 2*X_recv), s/t_mbi);
Else
If (t_now - tld >= R)
X = max(min(2*X, 2*X_recv), s/R);
tld = t_now;
If (p > 0) Calculate X_calc using the TCP throughput equation. X = max(min(X_calc, 2*X_recv), s/t_mbi); Else If (t_now - tld >= R) X = max(min(2*X, 2*X_recv), s/R); tld = t_now;
Note that if p == 0, then the sender is in slow-start phase, where
it approximately doubles the sending rate each round-trip time
until a loss occurs. The s/R term gives a minimum sending rate
during slow-start of one packet per RTT. The parameter t_mbi is
64 seconds, and represents the maximum inter-packet backoff
interval in the persistent absence of feedback. Thus, when p > 0
the sender sends at least one packet every 64 seconds.
Note that if p == 0, then the sender is in slow-start phase, where it approximately doubles the sending rate each round-trip time until a loss occurs. The s/R term gives a minimum sending rate during slow-start of one packet per RTT. The parameter t_mbi is 64 seconds, and represents the maximum inter-packet backoff interval in the persistent absence of feedback. Thus, when p > 0 the sender sends at least one packet every 64 seconds.
5) Reset the nofeedback timer to expire after max(4*R, 2*s/X)
seconds.
5) Reset the nofeedback timer to expire after max(4*R, 2*s/X) seconds.
4.4. Expiration of nofeedback timer
4.4. Expiration of nofeedback timer
If the nofeedback timer expires, the sender should perform the following actions:
If the nofeedback timer expires, the sender should perform the following actions:
1) Cut the sending rate in half. If the sender has received feedback
from the receiver, this is done by modifying the sender's cached
copy of X_recv (the receive rate). Because the sending rate is
limited to at most twice X_recv, modifying X_recv limits the
current sending rate, but allows the sender to slow-start,
doubling its sending rate each RTT, if feedback messages resume
reporting no losses.
1) Cut the sending rate in half. If the sender has received feedback from the receiver, this is done by modifying the sender's cached copy of X_recv (the receive rate). Because the sending rate is limited to at most twice X_recv, modifying X_recv limits the current sending rate, but allows the sender to slow-start, doubling its sending rate each RTT, if feedback messages resume reporting no losses.
Handley, et. al. Standards Track [Page 9] RFC 3448 TFRC: Protocol Specification January 2003
Handley, et. al. Standards Track [Page 9] RFC 3448 TFRC: Protocol Specification January 2003
If (X_calc > 2*X_recv)
X_recv = max(X_recv/2, s/(2*t_mbi));
Else
X_recv = X_calc/4;
If (X_calc > 2*X_recv) X_recv = max(X_recv/2, s/(2*t_mbi)); Else X_recv = X_calc/4;
The term s/(2*t_mbi) limits the backoff to one packet every 64
seconds in the case of persistent absence of feedback.
The term s/(2*t_mbi) limits the backoff to one packet every 64 seconds in the case of persistent absence of feedback.
2) The value of X must then be recalculated as described under point
(4) above.
2) The value of X must then be recalculated as described under point (4) above.
If the nofeedback timer expires when the sender does not yet have
an RTT sample, and has not yet received any feedback from the
receiver, then step (1) can be skipped, and the sending rate cut
in half directly:
If the nofeedback timer expires when the sender does not yet have an RTT sample, and has not yet received any feedback from the receiver, then step (1) can be skipped, and the sending rate cut in half directly:
X = max(X/2, s/t_mbi)
X = max(X/2, s/t_mbi)
3) Restart the nofeedback timer to expire after max(4*R, 2*s/X)
seconds.
3) Restart the nofeedback timer to expire after max(4*R, 2*s/X) seconds.
Note that when the sender stops sending, the receiver will stop sending feedback. This will cause the nofeedback timer to start to expire and decrease X_recv. If the sender subsequently starts to send again, X_recv will limit the transmit rate, and a normal slowstart phase will occur until the transmit rate reaches X_calc.
Note that when the sender stops sending, the receiver will stop sending feedback. This will cause the nofeedback timer to start to expire and decrease X_recv. If the sender subsequently starts to send again, X_recv will limit the transmit rate, and a normal slowstart phase will occur until the transmit rate reaches X_calc.
If the sender has been idle since this nofeedback timer was set and X_recv is less than four packets per round-trip time, then X_recv should not be halved in response to the timer expiration. This ensures that the allowed sending rate is never reduced to less than two packets per round-trip time as a result of an idle period.
If the sender has been idle since this nofeedback timer was set and X_recv is less than four packets per round-trip time, then X_recv should not be halved in response to the timer expiration. This ensures that the allowed sending rate is never reduced to less than two packets per round-trip time as a result of an idle period.
4.5. Preventing Oscillations
4.5. Preventing Oscillations
To prevent oscillatory behavior in environments with a low degree of statistical multiplexing it is useful to modify sender's transmit rate to provide congestion avoidance behavior by reducing the transmit rate as the queuing delay (and hence RTT) increases. To do this the sender maintains an estimate of the long-term RTT and modifies its sending rate depending on how the most recent sample of the RTT differs from this value. The long-term sample is R_sqmean, and is set as follows:
To prevent oscillatory behavior in environments with a low degree of statistical multiplexing it is useful to modify sender's transmit rate to provide congestion avoidance behavior by reducing the transmit rate as the queuing delay (and hence RTT) increases. To do this the sender maintains an estimate of the long-term RTT and modifies its sending rate depending on how the most recent sample of the RTT differs from this value. The long-term sample is R_sqmean, and is set as follows:
If no feedback has been received before
R_sqmean = sqrt(R_sample);
Else
R_sqmean = q2*R_sqmean + (1-q2)*sqrt(R_sample);
If no feedback has been received before R_sqmean = sqrt(R_sample); Else R_sqmean = q2*R_sqmean + (1-q2)*sqrt(R_sample);
Handley, et. al. Standards Track [Page 10] RFC 3448 TFRC: Protocol Specification January 2003
Handley, et. al. Standards Track [Page 10] RFC 3448 TFRC: Protocol Specification January 2003
Thus R_sqmean gives the exponentially weighted moving average of the square root of the RTT samples. The constant q2 should be set similarly to q, and we recommend a value of 0.9 as the default.
Thus R_sqmean gives the exponentially weighted moving average of the square root of the RTT samples. The constant q2 should be set similarly to q, and we recommend a value of 0.9 as the default.
The sender obtains the base transmit rate, X, from the throughput function. It then calculates a modified instantaneous transmit rate X_inst, as follows:
The sender obtains the base transmit rate, X, from the throughput function. It then calculates a modified instantaneous transmit rate X_inst, as follows:
X_inst = X * R_sqmean / sqrt(R_sample);
X_inst = X * R_sqmean / sqrt(R_sample);
When sqrt(R_sample) is greater than R_sqmean then the queue is typically increasing and so the transmit rate needs to be decreased for stable operation.
When sqrt(R_sample) is greater than R_sqmean then the queue is typically increasing and so the transmit rate needs to be decreased for stable operation.
Note: This modification is not always strictly required, especially if the degree of statistical multiplexing in the network is high. However, we recommend that it is done because it does make TFRC behave better in environments with a low level of statistical multiplexing. If it is not done, we recommend using a very low value of q, such that q is close to or exactly zero.
Note: This modification is not always strictly required, especially if the degree of statistical multiplexing in the network is high. However, we recommend that it is done because it does make TFRC behave better in environments with a low level of statistical multiplexing. If it is not done, we recommend using a very low value of q, such that q is close to or exactly zero.
4.6. Scheduling of Packet Transmissions
4.6. Scheduling of Packet Transmissions
As TFRC 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 course-grain or irregular scheduling of the operating system. Thus a typical sending loop will calculate the correct inter-packet interval, t_ipi, as follows:
As TFRC 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 course-grain or irregular scheduling of the operating system. Thus a typical sending loop will calculate the correct inter-packet interval, t_ipi, as follows:
t_ipi = s/X_inst;
t_ipi = s/X_inst;
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 application becomes idle, it checks the current time, t_now, and then requests re-scheduling after (t_ipi - (t_now - t_0)) seconds. When the application is re-scheduled, it checks the current time, t_now, again. If (t_now > t_1 - delta) then packet 1 is sent.
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 application becomes idle, it checks the current time, t_now, and then requests re-scheduling after (t_ipi - (t_now - t_0)) seconds. When the application is re-scheduled, it checks the current time, t_now, again. If (t_now > t_1 - delta) then packet 1 is sent.
Now a new t_ipi may be calculated, and used to calculate a nominal send time t_2 for packet 2: t2 = t_1 + t_ipi. The process then repeats, with each successive packet's send time being calculated from the nominal send time of the previous packet.
今、新しいt_ipiは計算されるかもしれません、そして、名目上でaについて計算するのに使用されて、パケット2のために時間t_2を送ってください: t2はt_1+t_ipiと等しいです。 次に、過程を繰り返して、連続したパケットのものが計算された時間を送るそれぞれと共に、名目上から前のパケットの時間を送ってください。
In some cases, when the nominal send time, t_i, of the next packet is calculated, it may already be the case that t_now > t_i - delta. In such a case the packet should be sent immediately. Thus if the operating system has coarse timer granularity and the transmit rate
いくつかの場合では、次のパケットのiは計算されて、それはケースが_現在のそのtであったなら既にそうするかもしれません。(その時、名目上は時間、t_を送ります)。>t_i--デルタ。 すぐに、このような場合にはパケットを送るべきです。 そして、その結果、オペレーティングシステムで粗いタイマ粒状があるかどうか、レートを伝えてください。
Handley, et. al. Standards Track [Page 11] RFC 3448 TFRC: Protocol Specification January 2003
etハンドレー、アル。 規格はRFC3448TFRCを追跡します[11ページ]: プロトコル仕様2003年1月
is high, then TFRC may send short bursts of several packets separated by intervals of the OS timer granularity.
高値、TFRCが数個の短い炸裂を送るかもしれないその時はOSタイマ粒状の間隔で分離されたパケットですか?
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 t_gran seconds, then delta would typically be set to:
パラメタデルタが中に1段階の柔軟性を許容することになっている、パケットの時間を送ってください。 オペレーティングシステムにt_おばあちゃんの秒のスケジューリングタイマ粒状があるなら、デルタによる以下のことように通常設定されるでしょう。
delta = min(t_ipi/2, t_gran/2);
デルタ=分(t_ipi/2、t_おばあちゃん/2)。
t_gran is 10ms on many Unix systems. If t_gran is not known, a value of 10ms can be safely assumed.
t_おばあちゃんは多くのUnixシステムの上の10msです。t_おばあちゃんが知られていないなら、安全に10msの値は想定できます。
5. Calculation of the Loss Event Rate (p)
5. 損失イベント率の計算(p)
Obtaining an accurate and stable measurement of the loss event rate is of primary importance for TFRC. Loss rate measurement is performed at the receiver, based on the detection of lost or marked packets from the sequence numbers of arriving packets. We describe this process before describing the rest of the receiver protocol.
損失イベント率の正確で安定した測定を得るのはTFRCのために第一に重要です。 損失レート測定は受信機で実行されます、到着パケットの一連番号からの無くなっているか著しいパケットの検出に基づいて。 受信機プロトコルの残りについて説明する前に、私たちはこの過程について説明します。
5.1. Detection of Lost or Marked Packets
5.1. 無くなっているか著しいパケットの検出
TFRC 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.
TFRCは、すべてのパケットが送られる各パケットあたり1つ増加される一連番号を含むと仮定します。 この仕様の目的のために、私たちは、無くなっているパケットが再送されるなら、失われたパケットと同じ一連番号ではなく、トランスミッション系列で最新のものである新しい一連番号が「再-トランスミッション」に与えられるのを必要とします。 トランスポート・プロトコルに元の一連番号で再送しなければならないという要件があるなら、トランスポート・プロトコルデザイナーは、どう区別するかが再送されたパケットとどう無くなっている「再-トランスミッション」を検出するかから延着したのを理解しなければなりません。
The receiver maintains 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 receiver 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 is to make TFRC more robust in the presence of reordering. In contrast to TCP, if a packet arrives late (after 3 subsequent packets arrived) in TFRC, the late packet can fill the hole in TFRC's reception record, and the receiver can recalculate the loss event
パケットの損失は無くなっているパケットより高い一連番号がある少なくとも3つのパケットの到着で検出されます。 3つのその後のパケットのための要件は、TCPと同じであり、TFRCを再命令の面前でより強健にすることです。 TCPと対照して、パケットが遅さに(3つのその後のパケットが到着した後に)TFRCに到着するなら、遅いパケットはTFRCのレセプション記録の穴をふさぐことができます、そして、受信機は損失出来事について再計算できます。
Handley, et. al. Standards Track [Page 12] RFC 3448 TFRC: Protocol Specification January 2003
etハンドレー、アル。 規格はRFC3448TFRCを追跡します[12ページ]: プロトコル仕様2003年1月
rate. Future versions of TFRC might make the requirement for three subsequent packets adaptive based on experienced packet reordering, but we do not specify such a mechanism here.
評価してください。 TFRCの将来のバージョンは3のための要件を経験豊富なパケット再命令に基づいて適応型のその後のパケットにするかもしれませんが、私たちはここでそのようなメカニズムを指定しません。
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.
それの次第混雑出来事が到着するとき、電子証券取引ネットワーク有能な接続において、著しいパケットは検出されます、その後のパケットの到着を待つ必要はなくて。
5.2. Translation from Loss History to Loss Events
5.2. 損失歴史から損失出来事までの翻訳
TFRC requires that the loss fraction 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 receiver needs 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 perform this mapping, the receiver needs to know the RTT to use, and this is supplied periodically by the sender, typically as control information piggy-backed onto a data packet. TFRC is not sensitive to how the RTT measurement sent to the receiver is made, but we recommend using the sender's calculated RTT, R, (see Section 4.3) for this purpose.
TFRCは、損失断片がそれらのパケットが同じ損失出来事の一部であるところで失われたいくつかの連続したパケットに強健であることを必要とします。 これはTCPと同様です。(TCPはどんな独身のRTTの間も、混雑ウィンドウのある半分にを(通常)実行するだけです)。 したがって、受信機は、損失イベント記録にパケット損失歴史を写像する必要があります。(そこでは、損失出来事がRTTで失われた1つ以上のパケットです)。 このマッピング、RTTが使用するのを知る受信機の必要性、およびこれを実行するのは定期的に送付者によって供給されます、制御情報が通常データ・パケットに便乗したので。 受信機に送られたRTT測定をしますが、私たちが、このために送付者の計算されたRTT、Rを使用することを(セクション4.3を見ます)どう勧めるかにTFRCは敏感ではありません。
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に、_新しい受信機に到着していて、それがレセプション時間T_新しいように注意できます。 無くなっているパケットに関しては、私たちは、名目上の「到着時間」を推論するのを補間できます。 仮定します:
S_loss is the sequence number of a lost packet.
S_損失は無くなっているパケットの一連番号です。
S_before is the sequence number of the last packet to arrive with
sequence number before S_loss.
S、_以前、S_損失の前の一連番号と共に到着する最後のパケットの一連番号があります。
S_after is the sequence number of the first packet to arrive with
sequence number after S_loss.
S_は後に一連番号後のS_損失と共に到着する最初のパケットの一連番号です。
T_before is the reception time of S_before.
_以前、Sのレセプション時間があります。T、_以前。
T_after is the reception time of S_after.
T_は後に_後のSのレセプション時間です。
Note that T_before can either be before or after T_after due to reordering.
缶の前のT_が_後のTの前または後に再命令のためであることに注意してください。
Handley, et. al. Standards Track [Page 13] RFC 3448 TFRC: Protocol Specification January 2003
etハンドレー、アル。 規格はRFC3448TFRCを追跡します[13ページ]: プロトコル仕様2003年1月
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:
無くなっているパケットのS_損失なので、私たちは_Sの何倍も以前、到着から受信機への名目上の「到着時間」を補間できます。そして、_後のS。 このようにして:
T_loss = T_before + ( (T_after - T_before)
* (S_loss - S_before)/(S_after - S_before) );
T_損失が+の前にT_と等しい、(__後のT--T以前、)、*、(S_の損失--、S、_以前)、/、(__後のS--S以前、)、。
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 before performing this calculation. 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.
系列の_以前Sの間で包装されたスペースと後のS_であるならこの計算を実行する前にこれを考慮に入れるように一連番号を変更しなければならないことに注意してください。 可能な限り大きい一連番号が_後の>Sの前のS_最大、およびS_であるなら、通常、Sの=(S+(S_最大+1)/2)モッズ(S_最大+1)で各一連番号Sを変更するのは十分でしょう。
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 we interpolate the nominal arrival times of S_old and S_new, called T_old and T_new respectively.
迷子になったパケットS_老人が前の損失出来事を出発させたと決心していて、無くなって、次に、私たちが新しい状態でS_老人とS_の名目上の到着時間を補間するということであり、_新しくそれぞれT_老人とTと呼ばれて、私たちがちょうどそのSを_新しく決心したところであるなら。
If T_old + R >= T_new, then S_new is part of the existing loss event. Otherwise S_new is the first packet in a new loss event.
T_の古い+R>がT_と新しい状態で等しいなら、S_新しいのは、既存の損失出来事の一部です。 そうでなければ、S_新しいのは、新しい損失出来事で最初のパケットです。
5.3. Inter-loss Event Interval
5.3. 相互の損失イベント間隔
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).
損失間隔(A)がパケット一連番号Sから始まったと決心していて、次の損失間隔(B)がパケット一連番号S_Bから始まったなら、(S_B--S)は損失間隔Aのパケットの数を与えます。
5.4. Average Loss Interval
5.4. 海損間隔
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.
損失イベント率pについて計算するために、私たちは最初に、海損間隔について計算します。 これは測定損失イベント率がスムーズに変化するような方法でn最新の損失イベント間隔に重みを加えるフィルタを使用し終わっています。
Weights w_0 to w_(n-1) are calculated as:
w_(n-1)への重りw_0は以下として計算されます。
If (i < n/2)
w_i = 1;
Else
w_i = 1 - (i - (n/2 - 1))/(n/2 + 1);
(i<n/2)w_i=1であるなら。 ほかに、w_iは1と等しいです--(i--(n/2--1))/(n/2+1)
Thus if n=8, the values of w_0 to w_7 are:
したがって、n=8であるなら、0対w_7のw_値は以下の通りです。
1.0, 1.0, 1.0, 1.0, 0.8, 0.6, 0.4, 0.2
1.0, 1.0, 1.0, 1.0, 0.8, 0.6, 0.4, 0.2
Handley, et. al. Standards Track [Page 14] RFC 3448 TFRC: Protocol Specification January 2003
etハンドレー、アル。 規格はRFC3448TFRCを追跡します[14ページ]: プロトコル仕様2003年1月
The value n for the number of loss intervals used in calculating the loss event rate determines TFRC's speed in responding to changes in the level of congestion. As currently specified, TFRC 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 TFRC's mechanisms to include a more severe response to two or more round-trip times with heavy packet loss.
損失イベント率について計算する際に費やされた損失間隔の数のための値nは混雑のレベルにおける変化に応じる際にTFRCの速度を測定します。 現在指定されるように、8よりかなりすばらしいnの値にTFRCを使用するべきではありません、TCPと共に世界的なインターネットに参加するかもしれない交通に。 少なくとも、nより多くの8の値がある安全操業は、重いパケット損失に伴う往復の2回以上への、より厳しい応答を含むようにTFRCのメカニズムへの小変化を必要とするでしょう。
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.
海損間隔について計算するとき、私たちは、最新のパケット損失出来事以来の間隔を含んでいるかどうか決める必要があります。 海損間隔を増加させるのが十分大きい場合にだけ、私たちはこれをします。
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にはI_0が最新の損失間隔であるなら最新の損失出来事以来間隔であるI_0であるとI_が意味する海損間隔を見込みます:
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;
I_tot0=0。 I_tot1=0。 W_は=0を加えます。 iは(1〜i=n)のためにn-1) I_tot0=I_tot0+(I_i*w_i)(W_幼児=W_幼児+w_i)への0と等しいです。(I_tot1=I_tot1+(I_i*w_(i-1)); I_は=最大(__I tot0、I tot1)を加えます。 I_は、= I_幼児/W_が合計を意味します。
The loss event rate, p is simply:
損失イベント率、pは単に以下の通りです。
p = 1 / I_mean;
1/I_p=平均。
5.5. History Discounting
5.5. 歴史の値段をひくこと
As described in Section 5.4, the most recent loss interval is only assigned 1/(0.75*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, discussed further in [3] and [9], that allows the TFRC receiver 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.
セクション5.4で説明されるように、全重量の1/(0.75*n)は海損間隔について計算する際に最新の損失間隔に割り当てられるだけです、最新の損失間隔のサイズにかかわらず。 このセクションはTFRC受信機が重りを調整できる[3]と[9]で、より詳しく議論した任意の歴史値段をひくメカニズムについて説明します、最新の損失間隔に一層の相対重量を集結して。(その時、最新の損失間隔は計算された海損間隔の2倍以上大きいです)。
Handley, et. al. Standards Track [Page 15] RFC 3448 TFRC: Protocol Specification January 2003
etハンドレー、アル。 規格はRFC3448TFRCを追跡します[15ページ]: プロトコル仕様2003年1月
To carry out history discounting, we associate a discount factor DF_i with each loss interval L_i, for i > 0, 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:
歴史の値段をひくことを行うために、私たちはそれぞれの損失間隔L_iに割引係数DF_iを関連づけます、i>0のために。そこでは、各割引係数が浮動小数点です。 割り引きアレイはそれぞれの損失間隔の間、値段をひく累積している歴史を維持します。 始めに、割り引きアレイのDF_iの値は1に初期化されます:
for (i = 1 to n) {
DF_i = 1;
}
(1〜i=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.
また、歴史の値段をひくのは一般的な割り引き要素DF、また、浮動小数点を使用します、また、それが1に初期化されます。 まず最初に、私たちは割引係数が海損間隔について計算する際にどう使用されるかを示しています、そして、次に、後でこのセクションで割引係数が時間がたつにつれてどう変更されるかを説明します。
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:
セクション5.4で説明されるように、海損間隔は前のn損失間隔I_1、…を費やすことで計算されます。, 最後の損失出来事以来パケットの数を表すI_0が受信されたI、および間隔。 割引係数を使用する海損間隔の計算はセクション5.4で、手順の簡単な変更です、以下の通りです:
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);
I_0*w_0I_tot1I_tot0==0。 W_tot0はw_0W_tot1=0と等しいです。 等しい..分
The general discounting factor, DF is updated on every packet arrival as follows. First, the receiver computes the weighted average I_mean of the loss intervals I_1, ..., I_n:
司令官が要素を無視して、以下のあらゆるパケット到着のときにDFをアップデートします。 まず最初に、受信機はI_が意味する損失間隔I_1の加重平均を計算します…, I:
I_tot = 0;
W_tot = 0;
for (i = 1 to n) {
W_tot = W_tot + w_(i-1) * DF_i;
I_tot = I_tot + (I_i * w_(i-1) * DF_i);
}
I_mean = I_tot / W_tot;
I_は=0を加えます。 W_は=0を加えます。 W_は=W_幼児+w_(i-1)*DF_iを加えます; (1〜i=n)に関してはI_幼児=I_幼児+(I_i*w_(i-1)*DF_i)、I_は、= I_幼児/W_が合計を意味します。
Handley, et. al. Standards Track [Page 16] RFC 3448 TFRC: Protocol Specification January 2003
etハンドレー、アル。 規格はRFC3448TFRCを追跡します[16ページ]: プロトコル仕様2003年1月
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:
最後の損失出来事以来パケットの数は、I_が意味するこの加重平均がI_0にたとえられるのを受けました。 I_0がI_が意味する2倍より古い方より大きいなら、新しい損失間隔はかなり大きいです、そして、より古い間隔の相対重量を減少させるために一般的な割引係数DFをアップデートします、以下の通りです:
if (I_0 > 2 * I_mean) {
DF = 2 * I_mean/I_0;
if (DF < THRESHOLD)
DF = THRESHOLD;
} else
DF = 1;
(DF<THRESHOLD)DFがTHRESHOLDと等しいなら(2*I_が意味するI_0>)2*I_平均/I DF=_0であるなら、DFはほかの1と等しいです。
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.
THRESHOLDのための非ゼロ値は、高い混雑の以前の時間からの、より古い損失間隔が完全に割り引かれないのを確実にします。 私たちは0.5のTHRESHOLDを推薦します。 それぞれの新しいパケット到着に従って、I_0がさらに増加して、割引係数DFをアップデートすることに注意してください。
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:
新しい損失出来事が起こると、現在の間隔はI_0〜I_1まで移行します、そして、損失間隔I_iは間隔I_(i+1)に移動します、そして、損失間隔Iは忘れられています。 前の割引係数DFは割り引きアレイに組み入れられなければなりません。 DF_私が損失間隔I_iに関連している割引係数を運ぶので、また、DF_iアレイは移動しなければなりません。 これは以下の通り完了しています:
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;
(1〜i=n)、DF*DF DF_i=_i;、(iは0ステップ-1へのn-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 TFRC to response somewhat more quickly to the sudden absence of congestion, as represented by a long current loss interval.
これは、メカニズムを無視しながら、任意の歴史の記述を終了します。 私たちは、これがいくらかはやく混雑の突然の欠如に応答へのTFRCを許容する唯一の目的がことである任意のメカニズムであると強調します、長い当期損失間隔のそばに表されるように。
6. Data Receiver Protocol
6. データ受信装置プロトコル
The receiver periodically sends feedback messages to the sender. Feedback packets should normally be sent at least once per RTT, unless the sender is sending at a rate of less than one packet per RTT, in which case a feedback packet should be send for every data
受信機は定期的にフィードバックメッセージを送付者に送ります。 通常、RTT単位でフィードバックパケットを少なくとも一度送るはずです、その場合、送付者が1RTTあたり1つ未満のパケットのレートで発信しない場合、フィードバックパケットはあらゆるデータのために発信することであるべきです。
Handley, et. al. Standards Track [Page 17] RFC 3448 TFRC: Protocol Specification January 2003
etハンドレー、アル。 規格はRFC3448TFRCを追跡します[17ページ]: プロトコル仕様2003年1月
packet received. A feedback packet should also be sent whenever a new loss event is detected without waiting for the end of an RTT, and whenever an out-of-order data packet is received that removes a loss event from the history.
パケットは受信されました。 また、新しい損失出来事がRTTの端、故障しているデータ・パケットが受け取られているときはいつも、待たないで検出されるときはいつも、歴史から損失出来事を取り除くフィードバックパケットを送るべきです。
If the sender is transmitting at a high rate (many packets per RTT) there may be some advantages to sending periodic feedback messages more than once per RTT as this allows faster response to changing RTT measurements, and more resilience to feedback packet loss. However, there is little gain from sending a large number of feedback messages per RTT.
送付者が高価で(多くの1RTTあたりのパケット)を伝えているなら、1RTTあたりの一度より多くの送付周期的なフィードバックメッセージのいくつかの利点が、これはさらに速くRTT測定を変えるのに応答を許容して、フィードバックパケット損失により多くの弾力を許容するので、あるかもしれません。 しかしながら、多くの1RTTあたりのフィードバックメッセージを送るのからの利得がほとんどありません。
6.1. Receiver behavior when a data packet is received
6.1. データ・パケットが受け取られているときの受信機の振舞い
When a data packet is received, the receiver performs the following steps:
データ・パケットが受け取られているとき、受信機は以下のステップを実行します:
1) Add the packet to the packet history.
1) パケット歴史にパケットを追加してください。
2) Let the previous value of p be p_prev. Calculate the new value of
p as described in Section 5.
2) pの前の値がp_prevであることをさせてください。 セクション5で説明されるようにpの新しい値について計算してください。
3) If p > p_prev, cause the feedback timer to expire, and perform the
actions described in Section 6.2
3) p>p_prev、フィードバックタイマが期限が切れることを引き起こしてくださいといって、セクション6.2で説明された動作を実行してくださいなら
If p <= p_prev no action need be performed.
p<がp_prevと等しいなら、動作は全く実行される必要はありません。
However an optimization might check to see if the arrival of the
packet caused a hole in the packet history to be filled and
consequently two loss intervals were merged into one. If this is
the case, the receiver might also send feedback immediately. The
effects of such an optimization are normally expected to be small.
しかしながら、最適化はいっぱいにされるためにパケット歴史でパケットの到着が穴を引き起こしたかどうか確認するためにチェックしたかもしれません、そして、その結果、2回の損失間隔が1つに合併されました。 また、これがそうであるなら、受信機はすぐに、フィードバックを送るかもしれません。 通常、そのような最適化の効果が小さいと予想されます。
6.2. Expiration of feedback timer
6.2. フィードバックタイマの満了
When the feedback timer at the receiver expires, the action to be taken depends on whether data packets have been received since the last feedback was sent.
受信機のフィードバックタイマが期限が切れるとき、取られるべき動作は最後のフィードバックを送って以来データ・パケットを受け取っているかどうかによります。
Let the maximum sequence number of a packet at the receiver so far be S_m, and the value of the RTT measurement included in packet S_m be R_m. If data packets have been received since the previous feedback was sent, the receiver performs the following steps:
今までのところ受信機のパケットの最大の一連番号がS_mであることをさせてください、そして、R_mになってくださいパケットS_mにRTT測定の値を含んでいて。 前のフィードバックを送って以来データ・パケットを受け取っているなら、受信機は以下のステップを実行します:
1) Calculate the average loss event rate using the algorithm
described above.
1) 上で説明されたアルゴリズムを使用して、海損イベント率について計算してください。
Handley, et. al. Standards Track [Page 18] RFC 3448 TFRC: Protocol Specification January 2003
etハンドレー、アル。 規格はRFC3448TFRCを追跡します[18ページ]: プロトコル仕様2003年1月
2) Calculate the measured receive rate, X_recv, based on the packets
received within the previous R_m seconds.
2) 測定がレート、X_recvを受けて、パケットに基づいて前のR_mの中で秒を得たと見込んでください。
3) Prepare and send a feedback packet containing the information
described in Section 3.2.2
3) セクション3.2.2で説明された情報を含むフィードバックパケットを、準備して、送ってください。
4) Restart the feedback timer to expire after R_m seconds.
4) フィードバックタイマを再開して、R_m後に秒を吐き出してください。
If no data packets have been received since the last feedback was sent, no feedback packet is sent, and the feedback timer is restarted to expire after R_m seconds.
最後のフィードバックを送って以来データ・パケットを全く受け取っていないなら、フィードバックパケットを全く送りません、そして、R_m後に秒を吐き出すためにフィードバックタイマを再開します。
6.3. Receiver initialization
6.3. 受信機初期化
The receiver is initialized by the first packet that arrives at the receiver. Let the sequence number of this packet be i.
受信機は受信機に到着する最初のパケットによって初期化されます。このパケットの一連番号がiであることをさせてください。
When the first packet is received:
最初のパケットが受け取られているとき:
o Set p=0
o p=0を設定してください。
o Set X_recv = 0.
o X_recv=0を設定してください。
o Prepare and send a feedback packet.
o フィードバックパケットを準備して、送ってください。
o Set the feedback timer to expire after R_i seconds.
o フィードバックタイマにR_i秒以降期限が切れるように設定してください。
6.3.1. Initializing the Loss History after the First Loss Event
6.3.1. 最初の損失出来事の後に損失歴史を初期化します。
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 this time. TFRC assumes that the correct data rate after the first loss is half of the sending rate when the loss occurred. TFRC approximates this target rate by X_recv, the receive rate over the most recent round-trip time. After the first loss, instead of initializing the first loss interval to the number of packets sent until the first loss, the TFRC receiver calculates the loss interval that would be required to produce the data rate X_recv, and uses this synthetic loss interval to seed the loss history mechanism.
直接送付レートを計算するのに最初の損失までのパケットの数を使用できません、送付レートがこの間に急速に変化するとき。 TFRCは、損失が発生したとき、最初の損失の後の正しいデータ信号速度が送付レートの半分であると仮定します。 TFRCがX_recvでこの目標金利に近似する、最新の往復の時間レートを受け取ってください。 最初の損失の後に、最初の損失まで送られたパケットの数に最初の損失間隔を初期化することの代わりに、TFRC受信機は、データ信号速度X_recvを生産するのに必要である損失間隔について計算して、損失歴史メカニズムに種を蒔くためにこの合成の損失間隔を費やします。
TFRC does this by finding some value p for which the throughput equation in Section 3.1 gives a sending rate within 5% of X_recv, given the current packet size s and round-trip time R. The first loss interval is then set to 1/p. (The 5% tolerance is introduced simply because the throughput equation is difficult to invert, and we want to reduce the costs of calculating p numerically.)
何らかの値がセクション3.1のスループット方程式がX_recvの5%以内で送付レートを与えるpであることがわかることによって、TFRCはこれをします、次に最初の損失間隔が1/pへのセットである現在のパケットサイズsの、そして、往復の時R.を考えて。 (単にスループット方程式は逆にするのが難しいので、5%の寛容を導入して、数の上で計算のpのコストを削減したいと思います。)
Handley, et. al. Standards Track [Page 19] RFC 3448 TFRC: Protocol Specification January 2003
etハンドレー、アル。 規格はRFC3448TFRCを追跡します[19ページ]: プロトコル仕様2003年1月
7. Sender-based Variants
7. 送付者ベースの異形
It would be possible to implement a sender-based variant of TFRC, where the receiver uses reliable delivery to send information about packet losses to the sender, and the sender computes the packet loss rate and the acceptable transmit rate. However, we do not specify the details of a sender-based variant in this document.
TFRCの送付者ベースの異形を実行するために、パケット損失率と許容できるのがレートを伝えるのは、可能でしょう。そこでは、受信機がパケット損失の情報を送付者に送るのに信頼できる配信を使用して、送付者は計算します。 しかしながら、私たちは本書では送付者ベースの異形の細部を指定しません。
The main advantages of a sender-based variant of TFRC would be that the sender would not have to trust the receiver's calculation of the packet loss rate. However, with the requirement of reliable delivery of loss information from the receiver to the sender, a sender-based TFRC would have much tighter constraints on the transport protocol in which it is embedded.
TFRCの送付者ベースの異形の主な利点は送付者が受信機のパケット損失率の計算を信じる必要はないだろうということでしょう。 しかしながら、損失情報の受信機から送付者までの信頼できる配信の要件によって、送付者ベースのTFRCはそれが埋め込まれているトランスポート・プロトコルにはるかにきつい規制を持っているでしょう。
In contrast, the receiver-based variant of TFRC specified in this document is robust to the loss of feedback packets, and therefore does not require the reliable delivery of feedback packets. It is also better suited for applications such as streaming media from web servers, where it is typically desirable to offload work from the server to the client as much as possible.
対照的に、本書では指定されたTFRCの受信機ベースの異形は、フィードバックパケットの損失に強健であり、したがって、フィードバックパケットの信頼できる配信を必要としません。 また、それはサーバからクライアントまでの仕事をできるだけ積み下ろすのが通常望ましいウェブサーバーからのストリーミング・メディアなどのアプリケーションに合うほうがよいです。
The sender-based and receiver-based variants also have different properties in terms of upgrades. For example, for changes in the procedure for calculating the packet loss rate, the sender would have to be upgraded in the sender-based variant, and the receiver would have to be upgraded in the receiver-based variant.
また、送付者ベースの、そして、受信機ベースの異形には、異なった特性がアップグレードであります。 例えば、パケット損失率について計算するための手順における変化に関して、送付者は送付者ベースの異形でアップグレードしなければならないでしょう、そして、受信機が受信機ベースの異形でアップグレードしなければならないでしょう。
8. Implementation Issues
8. 導入問題
This document has specified the TFRC congestion control mechanism, for use by applications and transport protocols. This section mentions briefly some of the few implementation issues.
このドキュメントはアプリケーションとトランスポート・プロトコルでTFRC混雑制御機構を使用に指定しました。 このセクションは簡潔にわずかな導入問題のいくつかについて言及します。
For t_RTO = 4*R and b = 1, the throughput equation in Section 3.1 can be expressed as follows:
t_RTO=4*Rとb=1に関しては、以下の通りセクション3.1のスループット方程式を言い表すことができます:
s
X = --------
R * f(p)
s X=-------- R*f(p)
for
for
f(p) = sqrt(2*p/3) + (12*sqrt(3*p/8) * p * (1+32*p^2)).
f(p)=sqrt(2*p/3)+(12*sqrt(3*p/8)*p*(1+32*p^2))。
A table lookup could be used for the function f(p).
機能f(p)に索表を使用できました。
Handley, et. al. Standards Track [Page 20] RFC 3448 TFRC: Protocol Specification January 2003
etハンドレー、アル。 規格はRFC3448TFRCを追跡します[20ページ]: プロトコル仕様2003年1月
Many of the multiplications (e.g., q and 1-q for the round-trip time average, a factor of 4 for the timeout interval) are or could be by powers of two, and therefore could be implemented as simple shift operations.
掛け算(往復の時間平均、タイムアウト間隔の間の4の要素のための例えば、qと1-q)の多くは、あるか、または2人の強国であるかもしれなくて、したがって、簡単な交替制として実行できました。
We note that the optional sender mechanism for preventing oscillations described in Section 4.5 uses a square-root computation.
私たちは、セクション4.5で説明された振動を防ぐための任意の送付者メカニズムが平方根計算を使用することに注意します。
The calculation of the average loss interval in Section 5.4 involves multiplications by the weights w_0 to w_(n-1), which for n=8 are:
セクション5.4における海損間隔の計算はw_(n-1)への重りw_0への掛け算にかかわります。(n=8であるときに、掛け算は以下の通りです)。
1.0, 1.0, 1.0, 1.0, 0.8, 0.6, 0.4, 0.2.
1.0, 1.0, 1.0, 1.0, 0.8, 0.6, 0.4, 0.2.
With a minor loss of smoothness, it would be possible to use weights that were powers of two or sums of powers of two, e.g.,
滑らかの小さい方の損失では、2人の強国か2人の強国の合計であった重りを使用するのは例えば可能でしょう。
1.0, 1.0, 1.0, 1.0, 0.75, 0.5, 0.25, 0.25.
1.0, 1.0, 1.0, 1.0, 0.75, 0.5, 0.25, 0.25.
The optional history discounting mechanism described in Section 5.5 is used in the calculation of the average loss rate. The history discounting mechanism is invoked only when there has been an unusually long interval with no packet losses. For a more efficient operation, the discount factor DF_i could be restricted to be a power of two.
セクション5.5で説明された任意の歴史値段をひくメカニズムは海損率の計算に使用されます。 異常に長い間隔がパケット損失なしであったときだけ、歴史値段をひくメカニズムは呼び出されます。 より効率的な操作において、割引係数DF_iは、2のパワーになるように制限されるかもしれません。
9. Security Considerations
9. セキュリティ問題
TFRC 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.
TFRCはそれ自身の権利におけるトランスポート・プロトコルではなく、トランスポート・プロトコルに関連して使用されることを意図する混雑制御機構です。 したがって、セキュリティは、主として特定のトランスポート・プロトコルとその認証機構の文脈で考えられる必要があります。
Congestion control mechanisms can potentially be exploited to create denial of service. This may occur through spoofed feedback. Thus any transport protocol that uses TFRC should take care to ensure that feedback is only accepted from the receiver of the data. The precise mechanism to achieve this will however depend on the transport protocol itself.
サービスの否定を作成するのに潜在的に混雑制御機構を利用できます。 これはだまされたフィードバックで起こるかもしれません。 したがって、TFRCを使用するどんなトランスポート・プロトコルも、フィードバックがデータの受信機から受け入れられるだけであるのを保証するために注意されるべきです。 しかしながら、これを達成する正確なメカニズムはトランスポート・プロトコル自体によるでしょう。
In addition, congestion control mechanisms may potentially be manipulated by a greedy receiver that wishes to receive more than its fair share of network bandwidth. A receiver might do this by claiming to have received packets that in fact were lost due to congestion. 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
さらに、混雑制御機構はそれがネットワーク回線容量の正当な分け前より受信したがっている貪欲な受信機によって潜在的に操作されるかもしれません。 事実上、混雑のため失われたパケットを受けたと主張することによって、受信機はこれをするかもしれません。 通常、そのような受信機に対する可能なディフェンスは受信機が領収書を立証するために送付者にフィードバックしなければならない何らかのフォームの一回だけを含んでいるでしょう。 しかしながら、そのような一回だけの詳細はそうするでしょう。
Handley, et. al. Standards Track [Page 21] RFC 3448 TFRC: Protocol Specification January 2003
etハンドレー、アル。 規格はRFC3448TFRCを追跡します[21ページ]: プロトコル仕様2003年1月
depend on the transport protocol, and in particular on whether the transport protocol is reliable or unreliable.
トランスポート・プロトコルと、特に、トランスポート・プロトコルが信頼できますかそれとも頼り無いか当てにしてください。
We expect that protocols incorporating ECN with TFRC will also want to incorporate feedback from the receiver to the sender using the ECN nonce [WES02]. 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.
私たちは、また、TFRCと共に電子証券取引ネットワークを法人組織にするプロトコルが電子証券取引ネットワーク一回だけ[WES02]を使用することで受信機から送付者までフィードバックを取り入れたくなると予想します。 電子証券取引ネットワーク一回だけは著しいパケットの偶然の、または、悪意がある隠すことから送付者を保護する電子証券取引ネットワークへの変更です。 一方、そのような一回だけの詳細は、トランスポート・プロトコルによって、本書では記述されません。
10. IANA Considerations
10. IANA問題
There are no IANA actions required for this document.
このドキュメントに必要であるIANA動作が全くありません。
11. Acknowledgments
11. 承認
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 like to thank Ken Lofgren, Mike Luby, Eduardo Urzaiz, Vladica Stanisic, Randall Stewart, Shushan Wen, and Wendy Lee (lhh@zsu.edu.cn) for feedback on earlier versions of this document, and to thank Mark Allman for his extensive feedback from using the document to produce a working implementation.
方程式についてのフィードバックと議論がさまざまな人々との輻輳制御を基礎づけたと認めたいと思います、Reliable Multicast Research Group、Reliable Multicast Transport作業部会、およびEndから終わりへのResearch Groupのメンバーを含んでいて。 ドキュメントを使用するのからの彼の大規模なフィードバックが働く実現を起こすように、ケン・レーフグレン、マイクLuby、エドゥアルドUrzaiz、Vladica Stanisic、ランドル・スチュワート、Shushan Wen、およびウェンディー・リー( lhh@zsu.edu.cn )がこのドキュメントの以前のバージョンのフィードバック、マーク・オールマンに感謝するのを感謝申し上げます。
12. Informational References
12. 情報の参照
[1] Balakrishnan, H., Rahul, H., and S. Seshan, "An Integrated
Congestion Management Architecture for Internet Hosts," Proc. ACM
SIGCOMM, Cambridge, MA, September 1999.
[1]Balakrishnan、H.、Rahul、H.、およびS.Seshan、「インターネットホストのための統合混雑管理体系」、Proc。 ACM SIGCOMM、ケンブリッジ(MA)1999年9月。
[2] Floyd, S., Handley, M., Padhye, J. and J. Widmer, "Equation-Based
Congestion Control for Unicast Applications", August 2000, Proc.
ACM SIGCOMM 2000.
[2] フロイドとS.とハンドレーとM.とPadhyeとJ.とJ.ウィトマー、「ユニキャストアプリケーションのための方程式ベースの輻輳制御」、2000年8月、Proc。 ACM SIGCOMM2000。
[3] Floyd, S., Handley, M., Padhye, J. and J. Widmer, "Equation-Based
Congestion Control for Unicast Applications: the Extended
Version", ICSI tech report TR-00-03, March 2000.
[3] フロイド、S.、ハンドレー、M.、Padhye、J.、およびJ.ウィトマー、「方程式ベースの混雑はユニキャストアプリケーションのために制御します」。 「Extendedバージョン」、ICSIの科学技術のレポートTR-00-03、2000年3月。
[4] Padhye, J., Firoiu, V., Towsley, D. and J. Kurose, "Modeling TCP
Throughput: A Simple Model and its Empirical Validation", Proc.
ACM SIGCOMM 1998.
[4]Padhye、J.、Firoiu、V.、Towsley、D.、およびJ.黒瀬、「モデルTCPスループット:」 「Simple ModelとそのEmpirical Validation」、Proc。 ACM SIGCOMM1998。
[5] Paxson V. and M. Allman, "Computing TCP's Retransmission Timer",
RFC 2988, November 2000.
[5] パクソンV.とM.オールマン、「コンピューティングTCPの再送信タイマー」、RFC2988、2000年11月。
Handley, et. al. Standards Track [Page 22] RFC 3448 TFRC: Protocol Specification January 2003
etハンドレー、アル。 規格はRFC3448TFRCを追跡します[22ページ]: プロトコル仕様2003年1月
[6] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP", RFC 3168,
September 2001.
[6]RamakrishnanとK.とフロイドとS.とD.黒、「明白な混雑通知(電子証券取引ネットワーク)のIPへの追加」、RFC3168、2001年9月。
[7] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
A Transport Protocol for Real-Time Applications", RFC 1889,
January 1996.
[7]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、1996年1月。
[8] Wetherall, D., Ely, D., N. Spring, S. Savage, and T. Anderson,
"Robust Congestion Signaling", IEEE International Conference on
Network Protocols, November 2001.
[8]WetherallとD.とイーリーとD.とN.スプリング、S.サヴェージとT.アンダーソン、「強健な混雑シグナリング」、ネットワーク・プロトコル(2001年11月)に関するIEEE国際会議。
[9] Widmer, J., "Equation-Based Congestion Control", Diploma Thesis,
University of Mannheim, February 2000. URL
"http://www.icir.org/tfrc/".
[9] ウィトマー、J.、「方程式ベースの輻輳制御」、卒業証書論文、マンハイム大学、2000年2月。 URL" http://www.icir.org/tfrc/ "。
13. Authors' Addresses
13. 作者のアドレス
Mark Handley ICIR/ICSI 1947 Center St, Suite 600 Berkeley, CA 94708
バークレー、Suite600カリフォルニア マークハンドレーICIR/ICSI1947センター通り、94708
EMail: mjh@icir.org
メール: mjh@icir.org
Sally Floyd ICIR/ICSI 1947 Center St, Suite 600 Berkeley, CA 94708
バークレー、Suite600カリフォルニア サリーフロイドICIR/ICSI1947センター通り、94708
EMail: floyd@icir.org
メール: floyd@icir.org
Jitendra Padhye Microsoft Research
Jitendra Padhyeマイクロソフト研究
EMail: padhye@microsoft.com
メール: padhye@microsoft.com
Joerg Widmer Lehrstuhl Praktische Informatik IV Universitat Mannheim L 15, 16 - Room 415 D-68131 Mannheim Germany
ヨルクウィトマーLehrstuhl Praktische Informatik IV UniversitatマンハイムL15、16--余地の415D-68131マンハイムドイツ
EMail: widmer@informatik.uni-mannheim.de
メール: widmer@informatik.uni-mannheim.de
Handley, et. al. Standards Track [Page 23] RFC 3448 TFRC: Protocol Specification January 2003
etハンドレー、アル。 規格はRFC3448TFRCを追跡します[23ページ]: プロトコル仕様2003年1月
14. Full Copyright Statement
14. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Handley, et. al. Standards Track [Page 24]
etハンドレー、アル。 標準化過程[24ページ]
一覧
スポンサーリンク
