[要約] RFC 4654は、TCPに優しいマルチキャスト輻輳制御（TFMCC）のプロトコル仕様を提供しています。このRFCの目的は、マルチキャスト通信においてTCPとの公平な共存を実現するための輻輳制御メカニズムを定義することです。
Network Working Group J. Widmer
Request for Comments: 4654 DoCoMo Euro-Labs
Category: Experimental M. Handley
UCL
August 2006
TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification
TCPフレンドリーマルチキャスト輻輳制御（TFMCC）：プロトコル仕様
Status of This Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document specifies TCP-Friendly Multicast Congestion Control (TFMCC). TFMCC is a congestion control mechanism for multicast transmissions in a best-effort Internet environment. It is a single-rate congestion control scheme, where the sending rate is adapted to the receiver experiencing the worst network conditions. TFMCC is reasonably fair when competing for bandwidth with TCP flows and has a relatively low variation of throughput over time, making it suitable for applications where a relatively smooth sending rate is of importance, such as streaming media.
このドキュメントは、TCPに優しいマルチキャスト輻輳制御（TFMCC）を指定しています。TFMCCは、最高のインターネット環境におけるマルチキャストトランスミッションの輻輳制御メカニズムです。これは、最悪のネットワーク条件を経験する受信機に送信率が適合している単一率の混雑制御スキームです。TFMCCは、TCPフローと帯域幅を競う場合に合理的に公平であり、時間の経過とともにスループットの変動が比較的低いため、ストリーミングメディアなど、比較的スムーズな送信率が重要であるアプリケーションに適しています。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Related Documents ..........................................4
1.2. Environmental Requirements and Considerations ..............4
2. Protocol Overview ...............................................5
2.1. TCP Throughput Equation ....................................6
2.2. Packet Contents ............................................7
2.2.1. Sender Packets ......................................8
2.2.2. Feedback Packets ....................................9
3. Data Sender Protocol ...........................................10
3.1. Sender Initialization .....................................10
3.2. Determining the Maximum RTT ...............................10
3.3. Adjusting the Sending Rate ................................11
3.4. Controlling Receiver Feedback .............................12
3.5. Assisting Receiver-Side RTT Measurements ..................14
3.6. Slowstart .................................................15
3.7. Scheduling of Packet Transmissions ........................15
4. Data Receiver Protocol .........................................16
4.1. Receiver Initialization ...................................17
4.2. Receiver Leave ............................................17
4.3. Measurement of the Network Conditions .....................17
4.3.1. Updating the Loss Event Rate .......................17
4.3.2. Basic Round-Trip Time Measurement ..................17
4.3.3. One-Way Delay Adjustments ..........................18
4.3.4. Receive Rate Measurements ..........................19
4.4. Setting the Desired Rate ..................................19
4.5. Feedback and Feedback Suppression .........................20
5. Calculation of the Loss Event Rate .............................22
5.1. Detection of Lost or Marked Packets .......................22
5.2. Translation from Loss History to Loss Events ..............23
5.3. Inter-Loss Event Interval .................................24
5.4. Average Loss Interval .....................................24
5.5. History Discounting .......................................25
5.6. Initializing the Loss History after the First Loss Event ..27
6. Security Considerations ........................................28
7. Acknowledgments ................................................29
8. References .....................................................29
8.1. Normative References ......................................29
8.2. Informative References ....................................29
This document specifies TCP-Friendly Multicast Congestion Control (TFMCC) [3]. TFMCC is a source-based, single-rate congestion control scheme that builds upon the unicast TCP-Friendly Rate Control mechanism (TFRC) [4]. TFMCC is stable and responsive under a wide range of network conditions and scales to receiver sets on the order of several thousand receivers. To support scalability, as much congestion control functionality as possible is located at the receivers. Each receiver continuously determines a desired receive rate that is TCP-friendly for the path from the sender to this receiver. Selected receivers then report the rate to the sender in feedback packets.
このドキュメントは、TCPに優しいマルチキャスト輻輳制御（TFMCC）[3]を指定しています。TFMCCは、ユニキャストTCPフレンドリーレート制御メカニズム（TFRC）に基づいているソースベースの単一率輻輳制御スキームです[4]。TFMCCは、数千の受信機の順序でレシーバーセットに幅広いネットワーク条件とスケールの下で安定しており、応答します。スケーラビリティをサポートするために、可能な限り多くの混雑制御機能が受信機に配置されます。各レシーバーは、送信者からこのレシーバーへのパスに対してTCPに優しい目的の受信レートを継続的に決定します。選択したレシーバーは、フィードバックパケットでレートを送信者に報告します。
TFMCC is a building block as defined in RFC 3048 [1]. Instead of specifying a complete protocol, this document simply specifies a congestion control mechanism that could be used in a transport protocol such as RTP [11], in an application incorporating end-to-end congestion control at the application level. This document does not discuss packet formats, reliability, or implementation-related issues.
TFMCCは、RFC 3048 [1]で定義されているビルディングブロックです。完全なプロトコルを指定する代わりに、このドキュメントは、アプリケーションレベルにエンドツーエンドの輻輳制御を組み込んだアプリケーションで、RTP [11]などの輸送プロトコルで使用できる混雑制御メカニズムを単純に指定するだけです。このドキュメントでは、パケット形式、信頼性、または実装関連の問題については説明していません。
TFMCC is designed to be reasonably fair when competing for bandwidth with TCP flows. A multicast flow is "reasonably fair" if its sending rate is generally within a factor of two of the sending rate of a TCP flow from the sender to the slowest receiver of the multicast group under the same network conditions.
TFMCCは、TCPフローと帯域幅を競う際に合理的に公平になるように設計されています。マルチキャストフローは、送信率が一般に、送信者から同じネットワーク条件下でマルチキャストグループの最も遅いレシーバーへのTCPフローの送信率の2倍以内にある場合、「合理的に公平」です。
In general, TFMCC has a low variation of throughput, which makes it suitable for applications where a relatively smooth sending rate is of importance, such as streaming media. The penalty of having smooth throughput while competing fairly for bandwidth is a reduced responsiveness to changes in available bandwidth. Thus TFMCC should be used when the application has a requirement for smooth throughput, in particular, avoiding halving of the sending rate in response to a single packet drop. For applications that simply need to multicast as much data as possible in as short a time as possible, PGMCC [10] may be more suitable.
一般に、TFMCCにはスループットの変動が低いため、ストリーミングメディアなど、比較的スムーズな送信率が重要であるアプリケーションに適しています。帯域幅と公正に競合しながらスムーズなスループットを持つことのペナルティは、利用可能な帯域幅の変化に対する応答性の低下です。したがって、アプリケーションにスムーズなスループットの要件、特に単一のパケットドロップに応答した送信率の半分を回避するための要件がある場合、TFMCCを使用する必要があります。できるだけ短い時間でできるだけ多くのデータをマルチキャストする必要があるアプリケーションの場合、PGMCC [10]がより適している場合があります。
This memo contains part of the definitions necessary to fully specify a Reliable Multicast Transport protocol in accordance with RFC 2357. As per RFC 2357, the use of any reliable multicast protocol in the Internet requires an adequate congestion control scheme. This document specifies an experimental congestion control scheme. While waiting for initial deployment and experience to show this scheme to be effective and scalable, the IETF publishes this scheme in the "Experimental" category.
このメモには、RFC 2357に従って信頼性の高いマルチキャストトランスポートプロトコルを完全に指定するために必要な定義の一部が含まれています。RFC2357によると、インターネットでの信頼できるマルチキャストプロトコルの使用には、適切な混雑制御スキームが必要です。このドキュメントは、実験的な混雑制御スキームを指定します。IETFは、このスキームが効果的かつスケーラブルであることを示すための初期展開と経験を待っている間、このスキームを「実験的」カテゴリに公開します。
It is the intent of the Reliable Multicast Transport (RMT) Working Group to re-submit the specification as an IETF Proposed Standard as soon as the scheme is deemed adequate.
信頼できるマルチキャストトランスポート（RMT）ワーキンググループが、スキームが適切であると判断されるとすぐに、IETF提案標準として仕様を再提出することが意図されています。
As described in RFC 3048 [1], TFMCC is a building block that is intended to be used, in conjunction with other building blocks, to help specify a protocol instantiation. It follows the general guidelines provided in RFC 3269 [2]. In particular, TFMCC is a suitable congestion control building block for NACK-Oriented Reliable Multicast (NORM) [5].
RFC 3048 [1]で説明されているように、TFMCCは、他のビルディングブロックと組み合わせて、プロトコルのインスタンス化を指定するために使用することを目的としたビルディングブロックです。これは、RFC 3269 [2]で提供される一般的なガイドラインに従います。特に、TFMCCは、NACK指向の信頼できるマルチキャスト（NORM）[5]の適切な混雑制御ビルディングブロックです。
TFMCC is intended to be a congestion control scheme that can be used in a complete protocol instantiation that delivers objects and streams (both reliable content delivery and streaming of multimedia information).
TFMCCは、オブジェクトとストリーム（信頼できるコンテンツ配信とマルチメディア情報のストリーミングの両方）を提供する完全なプロトコルインスタンス化で使用できる混雑制御スキームであることを目的としています。
TFMCC is most applicable for sessions that deliver a substantial amount of data (i.e., in length from hundreds of kilobytes to many gigabytes) and whose duration is on the order of tens of seconds or more.
TFMCCは、かなりの量のデータ（つまり、数百キロバイトから多くのギガバイトまで）を提供するセッションに最も適用でき、その期間は数秒以上です。
TFMCC is intended for multicast delivery. There are currently two models of multicast delivery: the Any-Source Multicast (ASM) model as defined in [6] and the Source-Specific Multicast (SSM) model as defined in [7]. TFMCC works with both multicast models, but in a slightly different way. When ASM is used, feedback from the receivers is multicast to the sender, as well as to all other receivers. Feedback can be either multicast on the same group address used for sending data or on a separate multicast feedback group address. For SSM, the receivers must unicast the feedback directly to the sender. Hence, feedback from a receiver will not be received by other receivers.
TFMCCは、マルチキャスト配信を目的としています。現在、マルチキャスト配信には2つのモデルがあります。[6]で定義されている任意のソースマルチキャスト（ASM）モデルと、[7]で定義されているソース固有のマルチキャスト（SSM）モデルです。TFMCCは両方のマルチキャストモデルで動作しますが、わずかに異なる方法で動作します。ASMを使用すると、受信機からのフィードバックは、送信者および他のすべての受信機にマルチキャストされます。フィードバックは、データの送信に使用される同じグループアドレスのマルチキャストまたは別のマルチキャストフィードバックグループアドレスのいずれかです。SSMの場合、受信機はフィードバックを送信者に直接ユニカストする必要があります。したがって、レシーバーからのフィードバックは、他のレシーバーによって受信されません。
TFMCC inherently works with all types of networks that allow bi-directional communication, including LANs, WANs, Intranets, the Internet, asymmetric networks, wireless networks, and satellite networks. However, in some network environments varying the sending rate to the receivers may not be advantageous (e.g., for a satellite or wireless network, there may be no mechanism for receivers to effectively reduce their reception rate since there may be a fixed transmission rate allocated to the session).
TFMCCは、LAN、WAN、イントラネット、インターネット、非対称ネットワーク、ワイヤレスネットワーク、衛星ネットワークなど、双方向通信を可能にするあらゆる種類のネットワークで本質的に動作します。ただし、受信機への送信率を変化させるネットワーク環境によっては、有利ではない場合があります（たとえば、衛星またはワイヤレスネットワークの場合、受信機がに割り当てられた固定透過率があるため、受信率を効果的に減らすメカニズムがない場合があります。セッション）。
The difference in responsiveness of TFMCC and TCP may result in significant throughput differences in case of a very low bitrate. TFMCC requires an estimate of the loss event rate to calculate a fair sending rate. This estimate may be inaccurate in case TFMCC receives only very few packets per RTT. TFMCC should not be used together with TCP if the capacity of the bottleneck link is less than 30KBit/s (e.g., a very slow modem connection). TFMCC may also achieve a rate that is very different from the average TCP rate in case buffer space at the bottleneck is severely underprovisioned. In particular, TFMCC is less susceptible to small buffer sizes since TFMCC spaces out packets in time, whereas TCP sends them back to back. Thus TCP is much more likely to see a packet loss if buffer space is scarce.
TFMCCとTCPの応答性の違いは、ビットレートが非常に低い場合に重大なスループットの違いをもたらす可能性があります。TFMCCでは、公正な送信率を計算するために、損失イベント率の見積もりが必要です。この推定値は、TFMCCがRTTごとに非常に少ないパケットしか受信していない場合に不正確になる可能性があります。Bottleneckリンクの容量が30kbit/s未満の場合（たとえば、非常に遅いモデム接続）、TFMCCをTCPと一緒に使用しないでください。TFMCCは、ボトルネックのバッファースペースが深刻に支持されている場合、平均TCPレートとは非常に異なるレートを達成する場合があります。特に、TFMCCはTFMCCが時間内にパケットを出力するため、TFMCCは小さなバッファーサイズの影響を受けにくいですが、TCPはそれらを背中合わせに送ります。したがって、バッファースペースが不足している場合、TCPはパケット損失を見る可能性がはるかに高くなります。
TFMCC is designed for applications that use a fixed packet size and vary their sending rate in packets per second in response to congestion. Some applications (e.g., those using audio) require a fixed interval of time between packets and vary their packet size instead of their packet rate in response to congestion. The congestion control mechanism in this document cannot be used by those applications.
TFMCCは、固定パケットサイズを使用し、混雑に応じて1秒あたりのパケットの送信率を変更するアプリケーション向けに設計されています。一部のアプリケーション（たとえば、オーディオを使用しているもの）は、パケット間の固定時間間隔を必要とし、混雑に応じてパケットレートではなくパケットサイズを変化させます。このドキュメントの混雑制御メカニズムは、これらのアプリケーションでは使用できません。
TFMCC extends the basic mechanisms of TFRC into the multicast domain. In order to compete fairly with TCP, TFMCC receivers individually measure the prevalent network conditions and calculate a rate that is TCP-friendly on the path from the sender to themselves. The rate is determined using an equation for TCP throughput, which roughly describes TCP's sending rate as a function of the loss event rate, round-trip time (RTT), and packet size. We define a loss event as one or more lost or marked packets from the packets received during one RTT, where a marked packet refers to a congestion indication from Explicit Congestion Notification (ECN) [9]. The sending rate of the multicast transmission is adapted to the receiver experiencing the worst network conditions.
TFMCCは、TFRCの基本的なメカニズムをマルチキャストドメインに拡張します。TCPと公正に競争するために、TFMCCレシーバーは一般的なネットワーク条件を個別に測定し、送信者から自分自身へのパス上でTCPに優しいレートを計算します。レートは、TCPスループットの方程式を使用して決定されます。これは、TCPの送信速度を、損失イベント率、往復時間（RTT）、およびパケットサイズの関数として大まかに説明しています。損失イベントを、1つのRTT中に受信したパケットからの1つまたは複数の紛失またはマークされたパケットと定義します。マークされたパケットは、明示的な輻輳通知（ECN）からのうっ血の表示を指します[9]。マルチキャスト伝送の送信率は、最悪のネットワーク条件を経験する受信機に適合しています。
Basically, TFMCC's congestion control mechanism works as follows:
基本的に、TFMCCの混雑制御メカニズムは次のように機能します。
o Each receiver measures the loss event rate and its RTT to the sender.
o 各レシーバーは、損失イベント率とそのRTTを送信者に測定します。
o Each receiver then uses this information, together with an equation for TCP throughput, to derive a TCP-friendly sending rate.
o 次に、各レシーバーは、この情報をTCPスループットの方程式とともに使用して、TCPに優しい送信率を導き出します。
o Through a distributed feedback suppression mechanism, only a subset of the receivers are allowed to give feedback to prevent a feedback implosion at the sender. The feedback mechanism ensures that receivers reporting a low desired transmission rate have a high probability of sending feedback.
o
o Receivers whose feedback is not suppressed report the calculated transmission rate back to the sender in so-called receiver reports. The receiver reports serve two purposes: they inform the sender about the appropriate transmit rate, and they allow the receivers to measure their RTT.
o フィードバックが抑制されていない受信者は、いわゆる受信機レポートで、計算された伝送速度を送信者に戻します。受信者のレポートは、2つの目的を果たします。彼らは、適切な送信率について送信者に通知し、レシーバーがRTTを測定できるようにします。
o The sender selects the receiver that reports the lowest rate as current limiting receiver (CLR). Whenever feedback with an even lower rate reaches the sender, the corresponding receiver becomes CLR and the sending rate is reduced to match that receiver's calculated rate. The sending rate increases when the CLR reports a calculated rate higher than the current sending rate.
o 送信者は、現在の制限レシーバー（CLR）として最低レートを報告する受信機を選択します。さらに低いレートでフィードバックが送信者に到達すると、対応する受信機がCLRになり、送信率がそのレシーバーの計算レートに一致するように低下します。CLRが現在の送信率よりも高い計算レートを報告すると、送信率が増加します。
The dynamics of TFMCC are sensitive to how the measurements are performed and applied and to what feedback suppression mechanism is chosen. We recommend specific mechanisms below to perform and apply these measurements. Other mechanisms are possible, but it is important to understand how the interactions between mechanisms affect the dynamics of TFMCC.
Any realistic equation giving TCP throughput as a function of loss event rate and RTT should be suitable for use in TFMCC. However, we note that the TCP throughput equation used must reflect TCP's retransmit timeout behavior, as this dominates TCP throughput at higher loss rates. We also note that the assumptions implicit in the throughput equation about the loss event rate parameter have to be a reasonable match to how the loss rate or loss event rate is actually measured. While this match is not perfect for the throughput equation and loss rate measurement mechanisms given below, in practice the assumptions turn out to be close enough.
損失イベント率とRTTの関数としてTCPスループットを与える現実的な方程式は、TFMCCでの使用に適している必要があります。ただし、使用されるTCPスループット方程式は、TCPの再送信タイムアウト動作を反映する必要があることに注意してください。また、損失イベント率パラメーターに関するスループット方程式に暗示される仮定は、損失率または損失イベント率が実際にどのように測定されるかと合理的な一致でなければならないことに注意してください。この一致は、以下に示すスループット方程式および損失率の測定メカニズムに最適ではありませんが、実際には、仮定は十分に近いことが判明しています。
The throughput equation we currently recommend for TFMCC is a slightly simplified version of the throughput equation for Reno TCP from [8]:
8 s
X = --------------------------------------------------------- (1)
R * (sqrt(2*p/3) + (12*sqrt(3*p/8) * p * (1+32*p^2)))
where
ただし
X is the transmit rate in bits/second.
xはビット/秒単位の送信率です。
s is the packet size in bytes.
Sはバイトのパケットサイズです。
R is the round-trip time in seconds.
rは秒単位の往復時間です。
p is the loss event rate, between 0.0 and 1.0, of the number of loss events as a fraction of the number of packets transmitted.
Pは、送信されたパケットの数の一部としての損失イベントの数の0.0〜1.0の損失イベント率です。
In the future, different TCP equations may be substituted for this equation. The requirement is that the throughput equation be a reasonable approximation of the sending rate of TCP for conformant TCP congestion control.
将来的には、この方程式に異なるTCP方程式を置き換えることができます。要件は、スループット方程式が、コンフォーマントTCP混雑制御のTCPの送信率の合理的な近似であることです。
The parameters s (packet size), p (loss event rate), and R (RTT) need to be measured or calculated by a TFMCC implementation. The measurement of R is specified in Section 4.3.2, and the measurement of p is specified in Section 5. The parameter s (packet size) is normally known to an application. This may not be so in two cases:
パラメーターs（パケットサイズ）、p（損失イベント率）、およびr（RTT）は、TFMCC実装によって測定または計算する必要があります。Rの測定値はセクション4.3.2で指定され、Pの測定はセクション5で指定されています。パラメーターS（パケットサイズ）は通常、アプリケーションで知られています。これは2つの場合ではそうではないかもしれません。
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 パケットサイズは自然にデータによって異なります。この場合、パケットサイズは異なりますが、その変動は送信速度に結合されていません。通常、sの平均パケットサイズの推定値を使用することは安全である必要があります。
o The application needs to change the packet size rather than the number of packets per second to perform congestion control. This would normally be the case with packet audio applications where a fixed interval of time needs to be represented by each packet. Such applications need to have a different way of measuring parameters.
o アプリケーションは、混雑制御を実行するために、毎秒パケット数ではなくパケットサイズを変更する必要があります。これは通常、各パケットで固定された時間間隔を表す必要があるパケットオーディオアプリケーションの場合です。このようなアプリケーションには、パラメーターを測定する別の方法が必要です。
Currently, TFMCC cannot be used for the second class of applications.
現在、TFMCCは2番目のクラスのアプリケーションに使用できません。
Before specifying the sender and receiver functionality, we describe the congestion control information contained in packets sent by the sender and feedback packets from the receivers. Information from the sender can either be sent in separate congestion control messages or piggybacked onto data packets. If separate congestion control messages are sent at time intervals larger than the time interval between data packets (e.g., once per feedback round), it is necessary to be able to include timestamp information destined for more than one receiver to allow a sufficient number of receivers to measure their RTT.
As TFMCC will be used along with a transport protocol, we do not specify packet formats, since these depend on the details of the transport protocol used. The recommended representation of the header fields is given below. Alternatively, if the computational overhead of a floating point representation is prohibitive, fixed point arithmetic can be used at the expense of larger packet headers. Sender and receivers of a specific TFMCC instance need to agree on a common encoding for the header fields.
Each packet sent by the data sender contains the following information:
o A sequence number i. This number is incremented by one for each data packet transmitted. The field must be sufficiently large that it does not wrap, causing two different packets with the same sequence number to be in the receiver's recent packet history at the same time. In most cases, the sequence number will be supplied by the transport protocol used along with TFMCC.
o シーケンス番号i。この数値は、送信されたデータパケットごとに1つずつ増加します。フィールドは包むほど十分に大きくなければならず、同じシーケンス番号を持つ2つの異なるパケットがレシーバーの最近のパケット履歴に同時にあるようにします。ほとんどの場合、シーケンス番号は、TFMCCとともに使用される輸送プロトコルによって提供されます。
o A suppression rate X_supp in bits/s. Only receivers with a calculated rate lower than the suppression rate are eligible to give feedback, unless their RTT is higher than the maximum RTT described below, in which case they are also eligible to give feedback. The suppression rate should be represented as a 12-bit floating point value with 5 bits for the unsigned exponent and 7 bits for the unsigned mantissa (to represent rates from 100 bit/s to 400 Gbit/s with an error of less than 1%).
o 抑制率x_supp in bits/s。RTTが以下で説明する最大RTTよりも高い場合を除き、抑制率よりも低い計算レートのレシーバーのみがフィードバックを与える資格があります。その場合、フィードバックを提供する資格もあります。抑制率は、署名されていない指数で5ビット、署名されていないマンティッサで7ビットの12ビットの12ビットの浮動小数点値として表す必要があります（100ビット/sから400 gbit/sのレートを表し、1％未満の誤差）。
o A timestamp ts_i indicating when the packet is sent. The resolution of the timestamp should typically be milliseconds, and the timestamp should be an unsigned integer value no less than 16 bits wide.
o パケットがいつ送信されるかを示すタイムスタンプTS_I。タイムスタンプの解像度は通常、ミリ秒である必要があり、タイムスタンプは幅16ビット以上の署名されていない整数値である必要があります。
o A receiver ID r and a copy of the timestamp tr_r' = tr_r of that receiver's last report, which allows the receiver to measure its RTT. If there is a delay ts_d between receiving the report from receiver r and sending the data packet, then tr_r' = tr_r + ts_d is included in the packet instead. The receiver ID is described in the next section. The resolution of the timestamp echo should be milliseconds, and the timestamp should be an unsigned integer value no less than 16 bits wide. If separate congestion control messages are used instead of piggybacked ones, the packet needs to contain a list of receiver IDs with corresponding timestamps to allow a sufficient number of receivers to simultaneously measure their RTT. For the default values used for the feedback process, this corresponds to a list size on the order of 10 to 20 entries.
o
o A flag is_CLR indicating whether the receiver with ID r is the CLR.
o ID rのレシーバーがCLRであるかどうかを示すフラグIS_CLR。
o A feedback round counter fb_nr. This counter is incremented by the sender at the beginning of a new feedback round to notify the receivers that all feedback for older rounds should be suppressed. The feedback round counter should be at least 4 bits wide.
o
o A maximum RTT value R_max, representing the maximum of the RTTs of all receivers. The RTT should be measured in milliseconds. An 8-bit floating point value with 4 bits for the unsigned exponent and 4 bits for the unsigned mantissa (to represent RTTs from 1 millisecond to 64 seconds with an error of ca. 6%) should be used for the representation.
o すべての受信機のRTTの最大値を表す最大RTT値R_MAX。RTTはミリ秒単位で測定する必要があります。署名されていない指数に4ビット、署名されていないマンティッサの4ビット（1ミリ秒から64秒のRTTを表すには、6％の誤差を表す）を表現に使用する必要があります。
Each feedback packet sent by a data receiver contains the following information:
o A unique receiver ID r. In most cases, the receiver ID will be supplied by the transport protocol, but it may simply be the IP address of the receiver.
o
o A flag have_RTT indicating whether the receiver has made at least one RTT measurement since it joined the session.
o フラグは、受信機がセッションに参加してから少なくとも1つのRTT測定を行ったかどうかを示す_RTTを持っています。
o A flag have_loss indicating whether the receiver experienced at least one loss event since it joined the session.
o
o A flag receiver_leave indicating that the receiver will leave the session (and should therefore not be CLR).
o 受信者がセッションを離れることを示すフラグレシーバー_Leave（したがって、CLRであってはなりません）。
o A timestamp tr_r indicating when the feedback packet is sent. The representation of the timestamp should be the same as that of the timestamp echo in the data packets.
o フィードバックパケットがいつ送信されるかを示すタイムスタンプTR_R。タイムスタンプの表現は、データパケットのタイムスタンプエコーの表現と同じでなければなりません。
o An echo ts_i' of the timestamp of the last data packet received. If the last packet received at the receiver has sequence number i, then ts_i' = ts_i is included in the feedback. If there is a delay tr_d between receiving that last data packet and sending feedback, then ts_i' = ts_i + tr_d is included in the feedback instead. The representation of the timestamp echo should be the same as that of the timestamp in the data packets.
o
o A feedback round echo fb_nr, reflecting the highest feedback round counter value received so far. The representation of the feedback round echo should be the same as the one used for the feedback round counter in the data packets.
o
o The desired sending rate X_r. This is the rate calculated by the receiver to be TCP-friendly on the path from the sender to this receiver. The representation of the desired sending rate should be the same as that of the suppression rate in the data packets.
o 目的の送信レートX_R。これは、送信者からこのレシーバーへのパスでTCPフレンドリーであるとレシーバーによって計算されたレートです。目的の送信率の表現は、データパケットの抑制率の表現と同じでなければなりません。
The data sender multicasts a stream of data packets to the data receivers at a controlled rate. Whenever feedback is received, the sender checks if it is necessary to switch CLRs and to readjust the sending rate.
The main tasks that have to be provided by a TFMCC sender are:
o adjusting the sending rate,
o 送信率の調整、
o controlling receiver feedback, and
o レシーバーフィードバックの制御、および
o assisting receiver-side RTT measurements.
o レシーバー側のRTT測定を支援します。
At initialization of the sender, the maximum RTT is set to a value that should be larger than the highest RTT to any of the receivers. It should not be smaller than 500 milliseconds for operation in the public Internet. The sending rate X is initialized to 1 packet per maximum RTT.
For each feedback packet that arrives at the sender, the sender computes the instantaneous RTT to the receiver as
送信者に到着する各フィードバックパケットについて、送信者は瞬間的なRTTを受信者に計算します。
R_r = ts_now - ts_i'
r_r = ts_now -ts_i '
where ts_now is the time the feedback packet arrived. Receivers will have adjusted ts_i' for the time interval between receiving the last data packet and sending the corresponding report so that this interval will not be included in R_r. If the actual RTT is smaller than the resolution of the timestamps and ts_now equals ts_i', then R_r is set to the smallest positive RTT value larger than 0 (i.e., 1 millisecond in our case). If the instantaneous RTT is larger than the current maximum RTT, the maximum RTT is increased to that value:
TS_NOWは、フィードバックパケットが到着した時期です。レシーバーは、最後のデータパケットを受信してから対応するレポートを送信するまでの時間間隔でTS_I 'を調整し、この間隔がR_Rに含まれないようにします。実際のRTTがタイムスタンプの解像度よりも小さい場合、TS_NOWはTS_I 'に等しい場合、R_Rは0より大きい最小の正のRTT値に設定されます（つまり、この場合は1ミリ秒）。瞬間RTTが現在の最大RTTよりも大きい場合、最大RTTはその値に増加します。
R_max = R_r
Otherwise, if no feedback with a higher instantaneous RTT than the maximum RTT is received during a feedback round (see Section 3.4), the maximum RTT is reduced to
それ以外の場合、フィードバックラウンド中に最大RTTよりも高い瞬間RTTを使用したフィードバックがない場合（セクション3.4を参照）、最大RTTはに削減されます
R_max = MAX(R_max * 0.9, R_peak)
where R_peak is the peak receiver RTT measured during the feedback round.
ここで、R_Peakはフィードバックラウンド中に測定されたピークレシーバーRTTです。
The maximum RTT is mainly used for feedback suppression among receivers with heterogeneous RTTs. Feedback suppression is closely coupled to the sending of data packets, and for this reason, the maximum RTT must not decrease below the maximum time interval between consecutive data packets:
最大RTTは、主に不均一なRTTを持つ受信機のフィードバック抑制に使用されます。フィードバック抑制は、データパケットの送信に密接に結びついています。このため、最大RTTは、連続したデータパケット間の最大時間間隔を下回ってはなりません。
R_max = max(R_max, 8s/X + ts_gran)
where ts_gran is the granularity of the sender's system clock (see Section 3.7).
ここで、TS_Granは送信者のシステムクロックの粒度です（セクション3.7を参照）。
When a feedback packet from receiver r arrives at the sender, the sender has to check whether it is necessary to adjust the transmission rate and to switch to a new CLR.
受信者Rからのフィードバックパケットが送信者に到着すると、送信者は送信速度を調整し、新しいCLRに切り替える必要があるかどうかを確認する必要があります。
How the rate is adjusted depends on the desired rate X_r of the receiver report. We distinguish four cases:
レートの調整方法は、受信者レポートの目的のレートX_Rに依存します。4つのケースを区別します。
1. If no CLR is present, receiver r becomes the current limiting receiver. The sending rate X is directly set to X_r, so long as this would result in a rate increase of less than 8s/R_max bits/s (i.e., 1 packet per R_max). Otherwise X is gradually increased to X_r at an increase rate of no more than 8s/R_max bits/s every R_max seconds.
1.
2. If receiver r is not the CLR but a CLR is present, then receiver r becomes the current limiting receiver if X_r is less than the current sending rate X and the receiver_leave flag of that receiver's report is not set. Furthermore, the sending rate is reduced to X_r.
2.
3. If receiver r is not the CLR but a CLR is present and the receiver_leave flag of the CLR's last report was set, then receiver r becomes the current limiting receiver. However, if X_r > X, the sending rate is not increased to X_r for the duration of a feedback round to allow other (lower rate) receivers to give feedback and be selected as CLR.
3. 受信機RがCLRではなく、CLRが存在し、CLRの最後のレポートのレシーバー_Leaveフラグが設定された場合、レシーバーRは現在の制限レシーバーになります。ただし、X_R> Xの場合、フィードバックラウンドの期間中、送信レートはX_Rに増加しません。
4. If receiver r is the CLR, the sending rate is set to the minimum of X_r and X + 8s/R_max bits/s.
4.
If the receiver has not yet measured its RTT but already experienced packet loss (indicated by the corresponding flags in the receiver report), the receiver report will include a desired rate that is based on the maximum RTT rather than the actual RTT to that receiver. In this case, the sender adjusts the desired rate using its measurement of the instantaneous RTT R_r to that receiver:
X_r' = X_r * R_max / R_r
X_r' is then used instead of X_r to detect whether to switch to a new CLR.
X_R 'は、X_Rの代わりに使用され、新しいCLRに切り替えるかどうかを検出します。
If the TFMCC sender receives no reports from the CLR for 4 RTTs, the sending rate is cut in half unless the CLR was selected less than 10 RTTs ago. In addition, if the sender receives no reports from the CLR for at least 10 RTTs, it assumes that the CLR crashed or left the group. A new CLR is selected from the feedback that subsequently arrives at the sender, and we increase as in case 3, above.
TFMCC送信者が4つのRTTのCLRからレポートを受け取らない場合、CLRが10 RTT以内に選択されていない限り、送信率は半分に削減されます。さらに、送信者が少なくとも10個のRTTでCLRからレポートを受け取らない場合、CLRがクラッシュまたはグループを去ったと仮定します。新しいCLRは、その後送信者に到着するフィードバックから選択され、上記の場合のように増加します。
If no new CLR can be selected (i.e., in the absence of any feedback from any of the receivers) it is necessary to reduce the sending rate further. For every 10 consecutive RTTs without feedback, the sending rate is cut in half. The rate is at most reduced to one packet every 8 seconds.
Note that when receivers stop receiving data packets, they will stop sending feedback. This eventually causes the sending rate to be reduced in the case of network failure. If the network subsequently recovers, a linear increase to the calculated rate of the CLR will occur at 8s/R_max bits/s every R_max.
受信機がデータパケットの受信を停止すると、フィードバックの送信を停止することに注意してください。これにより、最終的には、ネットワーク障害の場合に送信率が低下します。ネットワークがその後回復すると、CLRの計算された速度に対する線形増加は、すべてのR_MAXで8S/R_MAXビット/sで発生します。
An application using TFMCC may have a minimum sending rate requirement, where the application becomes unusable if the sending rate continuously falls below this minimum rate. The application should exclude receivers that report such a low rate from the multicast group. The specific mechanism to do this is application dependent and beyond the scope of this document.
The receivers allowed to send a receiver report are determined in so-called feedback rounds. Feedback rounds have a duration T of six times the maximum RTT. In case the multicast model is ASM (i.e., receiver feedback is multicast to the whole group) the duration of a feedback round may be reduced to four times the maximum RTT.
受信者は、レシーバーレポートを送信することを許可されています。いわゆるフィードバックラウンドで決定されます。フィードバックラウンドでは、最大RTTの6倍の期間Tがあります。マルチキャストモデルがASM（つまり、レシーバーフィードバックがグループ全体にマルチキャストである場合）の場合、フィードバックラウンドの期間は最大RTTの4倍に削減できます。
Only receivers wishing to report a rate that is lower than the suppression rate X_supp or those with a higher RTT than R_max may send feedback. At the beginning of each feedback round, X_supp is set to the highest possible value that can be represented. When feedback arrives at the sender over the course of a feedback round, X_supp is decreased such that more and more feedback is suppressed towards the end of the round. How receiver feedback is spread out over the feedback round is discussed in Section 4.5.
抑制率X_Suppよりも低いレートを報告したいレシーバーのみ、またはR_MAXよりも高いRTTを持つレートがフィードバックを送信する可能性があります。各フィードバックラウンドの開始時に、X_Suppは、表現できる最高の値に設定されます。フィードバックラウンドの過程で送信者にフィードバックが到着すると、X_Suppが減少し、ラウンドの終了に向けてますます多くのフィードバックが抑制されます。受信者のフィードバックがフィードバックラウンドに広がる方法については、セクション4.5で説明します。
Whenever non-CLR feedback for the current round arrives at the sender, X_supp is reduced to
現在のラウンドの非CLRフィードバックが送信者に到着するたびに、X_Suppは
X_supp = (1-g) * X_r
if X_supp > X_r. Feedback that causes the corresponding receiver to be selected as CLR, but that was from a non-CLR receiver at the time of sending, also contributes to the feedback suppression. Note that X_r must not be adjusted by the sender to reflect the receiver's real RTT in case X_r was calculated using the maximum RTT, as is done for setting the sending rate (Section 3.3); otherwise, a feedback implosion is possible. The parameter g determines to what extent higher rate feedback can suppress lower rate feedback. This mechanism guarantees that the lowest calculated rate reported lies within a factor of g of the actual lowest calculated rate of the receiver set (see [13]). A value of g of 0.1 is recommended.
x_supp> x_rの場合。対応する受信機をCLRとして選択するフィードバックは、送信時の非CLRレシーバーによるものであり、フィードバック抑制にも寄与します。送信率を設定するために行われるように、X_Rが最大RTTを使用して計算された場合に、受信者の実際のRTTを反映するために、送信者によってX_Rを調整してはなりません（セクション3.3）。それ以外の場合、フィードバックの爆発が可能です。パラメーターGは、より高いレートフィードバックがより低いレートフィードバックをどの程度抑制できるかを決定します。このメカニズムは、報告された最低計算速度が、受信機セットの実際の最低計算速度のgの係数内にあることを保証します（[13]を参照）。0.1のgの値が推奨されます。
To allow receivers to suppress their feedback, the sender's suppression rate needs to be updated whenever feedback is received. This suppression rate has to be communicated to the receivers in a timely manner, either by including it in the data packet header or, if separate congestion control messages are used, by sending a message with the suppression rate whenever the rate changes significantly (i.e., when it is reduced to less than (1-g) times the previously advertised suppression rate).
受信者がフィードバックを抑制できるようにするには、フィードバックを受け取るたびに送信者の抑制率を更新する必要があります。この抑制率は、データパケットヘッダーに含めるか、別々の混雑制御メッセージが使用されている場合、レートが大幅に変化するたびに抑制率とともにメッセージを送信することにより、タイムリーに受信機に通信する必要があります（つまり、以前に宣伝された抑制率の（1 g）倍未満に削減されると）。
After a time span of T, the feedback round ends if non-CLR feedback was received during that time. Otherwise, the feedback round ends as soon as the first non-CLR feedback message arrives at the sender but at most after 2T. The feedback round counter is incremented by one, and the suppression rate X_supp is reset to the highest representable value. The feedback round counter restarts with round 0 after a wrap-around.
Tの時間期間の後、その間に非CLRフィードバックが受信された場合、フィードバックラウンドは終了します。それ以外の場合、フィードバックラウンドは、最初の非CLRフィードバックメッセージが送信者に到着するとすぐに終了しますが、最大で2Tの後に終了します。フィードバックラウンドカウンターは1つで増加し、抑制率X_Suppは最高の表現可能な値にリセットされます。フィードバックラウンドカウンターは、ラップアラウンドの後にラウンド0で再起動します。
Receivers measure their RTT by sending a timestamp with a receiver report, which is echoed by the sender. If congestion control information is piggybacked onto data packets, usually only one receiver ID and timestamp can be included. If multiple feedback messages from different receivers arrive at the sender during the time interval between two data packets, the sender has to decide which receiver to allow to measure the RTT. The same applies if separate congestion control messages allow echoing multiple receiver timestamps simultaneously, but the number of receivers that gave feedback since the last congestion control message exceeds the list size.
The sender's timestamp echoes are prioritized in the following order:
送信者のタイムスタンプエコーは、次の順序で優先されます。
1. a new CLR (after a change of CLR's) or a CLR without any previous RTT measurements
1. 以前のRTT測定なしの新しいCLR（CLRの変更後）またはCLR
2. receivers without any previous RTT measurements in the order of the feedback round echo of the corresponding receiver report (i.e., older feedback first)
2.
3. non-CLR receivers with previous RTT measurements, again in ascending order of the feedback round echo of the report
3. 以前のRTT測定を伴う非CLRレシーバー、再びレポートのフィードバックラウンドエコーの昇順
4. the CLR
4. CLR
Ties are broken in favor of the receiver with the lowest reported rate.
It is necessary to account for the time that elapses between receiving a report and sending the next data packet. This time needs to be deducted from the RTT and thus has to be added to the receiver's timestamp value.
Whenever no feedback packets arrive in the interval between two data packets, the CLR's last timestamp, adjusted by the appropriate offset, is echoed. When the number of packets per RTT is so low that all packets carry a non-CLR receiver's timestamp, the CLR's timestamp and ID are included in a data packet at least once per feedback round.
2つのデータパケット間の間隔にフィードバックパケットが届かない場合は、適切なオフセットによって調整されたCLRの最後のタイムスタンプが反響します。RTTあたりのパケットの数が非常に低いため、すべてのパケットが非CLRレシーバーのタイムスタンプを運ぶ場合、CLRのタイムスタンプとIDは、フィードバックラウンドごとに少なくとも1回データパケットに含まれます。
TFMCC uses a slowstart mechanism to quickly approach its fair bandwidth share at the start of a session. During slowstart, the sending rate increases exponentially. The rate increase is limited to the minimum of the rates included in the receiver reports, and receivers report twice the rate at which they currently receive data. As in normal congestion control mode, the receiver with the smallest reported rate becomes CLR. Since a receiver can never receive data at a rate higher than its link bandwidth, this effectively limits the overshoot to twice this bandwidth. In case the resulting increase over R_max is less than 8s/R_max bits/s, the sender may choose to increase the rate by up to 8s/R_max bits/s every R_max. The current sending rate is gradually adjusted to the target rate reported in the receiver reports over the course of an RTT. Slowstart is terminated as soon as any one of the receivers experiences its first packet loss. Since that receiver's calculated rate will be lower than the current sending rate, the receiver will be selected as CLR.
During slowstart, the upper bound on the rate increase of 8s/R_max bits/s every RTT does not apply. Only after the TFMCC sender receives the first report with the have_loss flag set is the rate increase limited in this way.
Slowstart may also be used after the sender has been idle for some time, to quickly reach the previous sending rate. When the sender stops sending data packets, it records the current sending rate X' = X. Every 10 RTTs, the allowed sending rate will be halved due to lack of receiver feedback, as specified in Section 3.3. This halving may take place multiple times. When the sender resumes, it may perform a slowstart from the current allowed rate up to the recorded rate X'. Slowstart ends after the first packet loss by any of the receivers or as soon as X' is reached.
SlowStartは、送信者がしばらくの間アイドル状態になった後に使用され、以前の送信率に迅速に到達することもできます。送信者がデータパケットの送信を停止すると、現在の送信レートx '= Xを記録します。10個のRTTごとに、セクション3.3で指定されているように、受信機フィードバックの不足により許可された送信率が半分になります。この半分は複数回行われる可能性があります。送信者が再開すると、記録されたレートx 'までの現在の許可率からスロースタートを実行する場合があります。SlowStartは、受信機のいずれかによる最初のパケット損失の後、またはx 'に到達するとすぐに終了します。
To this end, receivers have to clear the have_loss flag after 10 RTTs without data packets as specified in Section 4.3.1. The have_loss flag is only used during slowstart. Therefore, clearing the flag has no effect if no packets arrived due to network partitioning or packet loss.
この目的のために、セクション4.3.1で指定されているように、データパケットなしで10 RTTSの後、受信機はhave_lossフラグをクリアする必要があります。have_lossフラグは、slowstart中にのみ使用されます。したがって、ネットワークのパーティション化やパケットの損失のためにパケットが到着しなかった場合、フラグをクリアすることは効果がありません。
As TFMCC is rate-based, and as operating systems typically cannot schedule events precisely, it is necessary to be opportunistic about sending data packets so that the correct average rate is maintained despite the coarse-grain or irregular scheduling of the operating system. Thus, a typical sending loop will calculate the correct inter-packet interval, ts_ipi, as follows:
ts_ipi = 8s/X
When a sender first starts sending at time t_0, it calculates ts_ipi and calculates a nominal send time, t_1 = t_0 + ts_ipi, for packet 1. When the application becomes idle, it checks the current time, ts_now, and then requests re-scheduling after (ts_ipi - (ts_now - t_0)) seconds. When the application is re-scheduled, it checks the current time, ts_now, again. If (ts_now > t_1 - delta) then packet 1 is sent (see below for delta).
送信者が最初に時間T_0で送信を開始すると、TS_IPIを計算し、パケット1の名目上の送信時間、T_1 = T_0 TS_IPIを計算します。（TS_IPI-（TS_NOW -T_0））秒。アプリケーションが再スケジュールされると、現在の時刻ts_nowをチェックします。（ts_now> t_1 -delta）の場合、パケット1が送信されます（Deltaについては以下を参照）。
Now, a new ts_ipi may be calculated and used to calculate a nominal send time, t_2, for packet 2: t_2 = t_1 + ts_ipi. The process then repeats with each successive packet's send time being calculated from the nominal send time of the previous packet. Note that the actual send time ts_i, and not the nominal send time, is included as timestamp in the packet header.
In some cases, when the nominal send time, t_i, of the next packet is calculated, it may already be the case that ts_now > t_i - delta. In such a case, the packet should be sent immediately. Thus, if the operating system has coarse timer granularity and the transmit rate is high, then TFMCC may send short bursts of several packets separated by intervals of the OS timer granularity.
場合によっては、次のパケットの公称送信時間T_Iが計算されると、既にTS_NOW> T_I -DELTAである可能性があります。そのような場合、パケットはすぐに送信する必要があります。したがって、オペレーティングシステムに粗いタイマーの粒度が高く、送信速度が高い場合、TFMCCは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 ts_gran seconds, then delta would typically be set to:
パラメーターデルタは、パケットの送信時間にある程度の柔軟性を可能にすることです。オペレーティングシステムにTS_GRAN秒のスケジューリングタイマーの粒度がある場合、通常、デルタは以下に設定されます。
delta = min(ts_ipi/2, ts_gran/2)
delta = min（ts_ipi/2、ts_gran/2）
ts_gran is 10 milliseconds on many Unix systems. If ts_gran is not known, a value of 10 milliseconds can be safely assumed.
TS_GRANは、多くのUNIXシステムで10ミリ秒です。TS_GRANが不明な場合、10ミリ秒の値を安全に想定できます。
Receivers measure the current network conditions (namely, RTT and loss event rate) and use this information to calculate a rate that is fair to competing traffic. The rate is then communicated to the sender in receiver reports. Due to the potentially large number of receivers, it is undesirable that all receivers send reports, especially not at the same time.
受信者は、現在のネットワーク条件（つまり、RTTおよび損失イベント率）を測定し、この情報を使用して、競合するトラフィックに公平なレートを計算します。レートは、受信者レポートで送信者に伝えられます。潜在的に多数のレシーバーがあるため、すべてのレシーバーがレポートを送信することは望ましくありません。
In the description of the receiver functionality, we will first address how the receivers measure the network parameters and then discuss the feedback process.
受信者機能の説明では、まず、受信機がネットワークパラメーターを測定する方法に対処し、次にフィードバックプロセスについて説明します。
The receiver is initialized when it receives the first data packet. The RTT is set to the maximum RTT value contained in the data packet. This initial value is used as the receiver's RTT until the first real RTT measurement is made. The loss event rate is initialized to 0. Also, the flags receiver_leave, have_RTT, and have_loss are cleared.
A receiver that sends feedback but wishes to leave the TFMCC session within the next feedback round may indicate the pending leave by setting the receiver_leave flag in its report. If the leaving receiver is the CLR, the receiver_leave flag should be set for all the reports within the feedback round before the leave takes effect.
フィードバックを送信しますが、次のフィードバックラウンド内でTFMCCセッションを離れたいレシーバーは、レポートにreceiver_Leaveフラグを設定することにより、保留中の休暇を示す場合があります。去るレシーバーがCLRである場合、休暇が有効になる前に、フィードバックラウンド内のすべてのレポートに対してReceiver_Leaveフラグを設定する必要があります。
Receivers have to update their estimate of the network parameters with each new data packet they receive.
受信者は、受信した新しいデータパケットごとにネットワークパラメーターの推定値を更新する必要があります。
When a data packet is received, the receiver adds the packet to the packet history. It then recalculates the new value of the loss event rate p. The loss event rate measurement mechanism is described separately in Section 5.
データパケットが受信されると、受信者はパケット履歴にパケットを追加します。次に、損失イベント率pの新しい値を再計算します。損失イベント率測定メカニズムについては、セクション5で別々に説明します。
When a loss event is detected, the flag have_loss is set. In case no data packets are received for 10 consecutive RTTs, the flag is cleared to allow the sender to slowstart. It is set again when new data packets arrive and a loss event is detected.
損失イベントが検出されると、フラグがhave_lossが設定されます。10回連続のRTTでデータパケットが受信されなかった場合、送信者がスロースタートできるようにフラグがクリアされます。新しいデータパケットが到着し、損失イベントが検出されると再度設定されます。
When a receiver gets a data packet that carries the receiver's own ID in the r field, the receiver updates its RTT estimate.
受信者がRフィールドにレシーバー自身のIDを運ぶデータパケットを取得すると、レシーバーはRTTの見積もりを更新します。
1. The current RTT is calculated as:
1. 現在のRTTは次のように計算されます。
R_sample = tr_now - tr_r'
r_sample = tr_now -tr_r '
where tr_now is the time the data packet arrives at the receiver and tr_r' is the receiver report timestamp echoed in the data packet. If the actual RTT is smaller than the resolution of the timestamps and tr_now equals tr_r', then R_sample is set to the smallest positive RTT value larger than 0 (i.e., 1 millisecond in our case).
ここでは、TR_NOWはデータパケットが受信機に到着し、TR_R 'がデータパケットに響き渡るレシーバーレポートです。実際のRTTがタイムスタンプの解像度よりも小さい場合、TR_NOWはTR_R 'に等しい場合、R_Sampleは0より大きい最小の正のRTT値に設定されます（つまり、この場合は1ミリ秒）。
2. The smoothed RTT estimate R is updated:
2.
If no feedback has been received before R = R_sample
Else
R = q*R + (1-q)*R_sample
A filter parameter q of 0.5 is recommended for non-CLR receivers. The CLR performs RTT measurements much more frequently and hence should use a higher filter value. We recommend using q=0.9. Note that TFMCC is not sensitive to the precise value for the filter constant.
0.5のフィルターパラメーターQを、非CLR受信機に推奨します。CLRはRTT測定をはるかに頻繁に実行するため、より高いフィルター値を使用する必要があります。Q = 0.9を使用することをお勧めします。TFMCCは、フィルター定数の正確な値に敏感ではないことに注意してください。
Optionally, sender-based RTT measurements may be used instead of receiver-based ones. The sender already determines the RTT to a receiver from the receiver's echo of the sender's own timestamp for the calculation of the maximum RTT. For sender-based RTT measurements, this RTT measurement needs to be communicated to the receiver. Instead of including an echo of the receiver's timestamp, the sender includes the receiver's RTT in the next data packet, using the prioritization rules described in Section 3.5.
To simplify sender operation, smoothing of RTT samples as described above should still be done at the receiver.
送信者操作を簡素化するには、上記のRTTサンプルのスムージングは、受信者でまだ行われる必要があります。
When an RTT measurement is performed, the receiver also determines the one-way delay D_r from itself to the sender:
D_r = tr_r' - ts_i
D_R = TR_R '-TS_I
where ts_i and tr_r' are the timestamp and receiver report timestamp echo contained in the data packet. With each new data packet j, the receiver can now calculate an updated RTT estimate as:
R' = max(D_r + tr_now - ts_j, 1 millisecond)
In between RTT measurements, the updated R' is used instead of the smoothed RTT R. Like the RTT samples, R' must be strictly positive. When a new measurement is made, all interim one-way delay measurements are discarded (i.e., the smoothed RTT is updated according to Section 4.3.2 without taking the interim one-way delay adjustments into account).
RTT測定の間では、RTTサンプルのように、スムーズ化されたRTT Rの代わりに更新されたR 'が使用されます。R'は厳密に正でなければなりません。新しい測定が行われると、すべての暫定的な一方向遅延測定が破棄されます（つまり、滑らかなRTTがセクション4.3.2に従って更新されます。
For the one-way delay measurements, the clocks of sender and receivers need not be synchronized. Clock skew will cancel itself out when both one-way measurements are added to form an RTT estimate, as long as clock drift between real RTT measurements is negligible.
一元配置遅延測定では、送信者と受信機のクロックを同期する必要はありません。クロックスキューは、実際のRTT測定間のクロックドリフトが無視できる限り、両方の一元配置測定値を追加してRTT推定を形成するとキャンセルされます。
The same one-way delay adjustments should be applied to the RTT supplied by the sender when using sender-based RTT measurements.
送信者ベースのRTT測定を使用する際に、送信者が提供するRTTに同じ一方向遅延調整を適用する必要があります。
When a receiver has not experienced any loss events, it cannot calculate a TCP-friendly rate to include in the receiver reports. Instead, the receiver measures the current receive rate and sets the desired rate X_r to twice the receive rate.
受信者が損失イベントを経験していない場合、受信者レポートに含めるTCPに優しいレートを計算することはできません。代わりに、受信機は現在の受信率を測定し、目的のレートX_Rを受信率の2倍に設定します。
The receive rate in bits/s is measured as the number of bits received over the last k RTTs, taking into account the IP and transport packet headers, but excluding the link-layer packet headers. A value for k between 2 and 4 is recommended.
BITS/sの受信率は、IPおよびトランスポートパケットヘッダーを考慮して、Link-Layerパケットヘッダーを除く、最後のK RTTで受信したビットの数として測定されます。2〜4の間のkの値が推奨されます。
When a receiver measures a non-zero loss event rate, it calculates the desired rate using Equation (1). In case no RTT measurement is available yet, the maximum RTT is used instead of the receiver's RTT. The desired rate X_r is updated whenever the loss event rate or the RTT changes.
受信者がゼロ以外の損失イベント率を測定すると、式（1）を使用して目的の速度を計算します。RTT測定がまだ利用できない場合は、受信者のRTTの代わりに最大RTTが使用されます。目的のレートX_Rは、損失イベント率またはRTTが変更されるたびに更新されます。
A receiver may decide not to report desired rates that are below 1 packet per 8 seconds, since a sender is very slow to recover from such low sending rates. In this case, the receiver reports a desired rate of 1 packet per 8 seconds. However, it must leave the multicast group if for more than 120 seconds, the calculated rate falls below the reported rate and the current sending rate is higher than the receiver's calculated rate.
受信者は、送信者がこのような低送り率から回復するのが非常に遅いため、8秒あたり1パケット未満の希望のレートを報告しないことを決定する場合があります。この場合、受信機は8秒あたり1パケットの目的のレートを報告します。ただし、120秒以上にわたって計算されたレートが報告されたレートを下回り、現在の送信率が受信者の計算レートよりも高い場合、マルチキャストグループを離れる必要があります。
As mentioned above, calculation of the desired rate is not possible before the receiver experiences the first loss event. In that case, twice the rate at which data is received is included in the receiver reports as X_r to allow the sender to slowstart as described in Section 3.6. This is also done when the sender resumes sending data packets after the have_loss flag was cleared due to the sender being idle.
上記のように、受信者が最初の損失イベントを経験する前に、目的のレートの計算は不可能です。その場合、セクション3.6で説明されているように、送信者がSlowStartを許可するために、受信者レポートにデータを受信するレートの2倍がX_Rとして含まれています。これは、送信者がアイドル状態になっているためにHAS_LOSSフラグがクリアされた後、送信者がデータパケットの送信を再開するときにも行われます。
Let fb_nr be the highest feedback round counter value received by a receiver. When a new data packet arrives with a higher feedback round counter than fb_nr, a new feedback round begins and fb_nr is updated. Outstanding feedback for the old round is canceled. In case a feedback number with a value that is more than half the feedback number space lower than fb_nr is received, the receiver assumes that the feedback round counter wrapped and also cancels the feedback timer and updates fb_nr.
FB_NRを、受信者が受け取った最高のフィードバックラウンドカウンター値とします。FB_NRよりも高いフィードバックラウンドカウンターで新しいデータパケットが到着すると、新しいフィードバックラウンドが開始され、FB_NRが更新されます。古いラウンドの優れたフィードバックがキャンセルされます。FB_NRよりも低いフィードバック番号スペースの半分を超える値のフィードバック番号が受信された場合、受信者はフィードバックラウンドカウンターがラップされていると想定し、フィードバックタイマーをキャンセルし、FB_NRを更新します。
The CLR sends its feedback independently from all the other receivers once per RTT. Its feedback does not suppress other feedback and cannot be suppressed by other receiver's feedback.
CLRは、RTTごとに1回、他のすべての受信機から独立してフィードバックを送信します。そのフィードバックは他のフィードバックを抑制せず、他の受信者のフィードバックでは抑制できません。
Non-CLR receivers set a feedback timer at the beginning of a feedback round. Using an exponentially weighted random timer mechanism, the feedback timer is set to expire after
非CLRレシーバーは、フィードバックラウンドの開始時にフィードバックタイマーを設定します。指数関数的に重み付けされたランダムタイマーメカニズムを使用して、フィードバックタイマーは後に期限切れに設定されています
t = max(T * (1 + log(x)/log(N)), 0)
where
ただし
x is a random variable uniformly distributed in (0,1],
xは（0,1]で均一に分布したランダム変数です。
T is the duration of a feedback round (i.e., 6 * R_max),
Tは、フィードバックラウンドの期間（つまり、6 * r_max）です。
N is an estimated upper bound on the number of receivers.
nは、受信機の数の推定上限です。
N is a constant specific to the TFMCC protocol. Since TFMCC scales to up to thousands of receivers, setting N to 10,000 for all receivers (and limiting the TFMCC session to at most 10,000 receivers) is recommended.
nは、TFMCCプロトコルに固有の定数です。TFMCCは最大数千のレシーバーにスケーリングするため、すべてのレシーバーにNを10,000に設定します（およびTFMCCセッションを最大10,000レシーバーに制限することをお勧めします）。
A feedback packet is sent when the feedback timer expires, unless the timer is canceled beforehand. When the multicast model is ASM, feedback is multicast to the whole group; otherwise, the feedback is unicast to the sender. The feedback packet includes the calculated rate valid at the time the feedback packet is sent (not the rate at the point of time when the feedback timer is set). The copy of the timestamp ts_i of the last data packet received, which is included in the feedback packet, needs to be adjusted by the time interval between receiving the data packet and sending the report to allow the sender to correctly infer the instantaneous RTT (i.e., that time interval has to be added to the timestamp value).
フィードバックパケットは、フィードバックタイマーの有効期限が切れたときに送信されます。マルチキャストモデルがASMの場合、フィードバックはグループ全体にマルチキャストです。それ以外の場合、フィードバックは送信者のユニキャストです。フィードバックパケットには、フィードバックパケットが送信された時点で有効な計算レートが含まれます（フィードバックタイマーが設定された時点ではレートではありません）。フィードバックパケットに含まれている最後のデータパケットのタイムスタンプTS_Iのコピーは、データパケットの受信とレポートを送信するまでの時間間隔で調整する必要があります。、その時間間隔をタイムスタンプ値に追加する必要があります）。
The timer is canceled if a data packet is received that has a lower suppression rate than the receiver's calculated rate and a higher or equal maximum RTT than the receiver's RTT. Likewise, a data packet indicating the beginning of a new feedback round cancels all feedback for older rounds. In case of ASM, the timer is also canceled if a feedback packet is received from another non-CLR receiver reporting a lower rate.
受信者の計算速度よりも低い抑制レートを有するデータパケットが受信され、レシーバーのRTTよりも高いまたは等しいRTTが受信されると、タイマーがキャンセルされます。同様に、新しいフィードバックラウンドの開始を示すデータパケットは、古いラウンドのすべてのフィードバックをキャンセルします。ASMの場合、より低いレートを報告する別の非CLRレシーバーからフィードバックパケットが受信された場合、タイマーもキャンセルされます。
The feedback suppression process is complicated by the fact that the calculated rates of the receivers will change during a feedback round. If the calculated rates decrease rapidly for all receivers, feedback suppression can no longer prevent a feedback implosion, since earlier feedback will always report a higher rate than current feedback. To make the feedback suppression mechanism robust in the face of changing rates, it is necessary to introduce X_fbr, the calculated rate of a receiver at the beginning of a feedback round. A receiver needs to suppress its feedback not only when the suppression rate is less than the receiver's current calculated rate but also in the case that the suppression rate falls below X_fbr.
フィードバック抑制プロセスは、フィードバックラウンド中に受信機の計算されたレートが変化するという事実によって複雑になります。すべての受信機で計算されたレートが急速に低下した場合、フィードバック抑制はフィードバックの爆発を防ぐことができなくなります。これは、以前のフィードバックは常に現在のフィードバックよりも高いレートを報告するためです。レートの変化に直面してフィードバック抑制メカニズムを堅牢にするには、フィードバックラウンドの開始時にレシーバーの計算レートであるX_FBRを導入する必要があります。受信者は、抑制率が受信者の現在の計算率よりも少ない場合だけでなく、抑制率がX_FBRを下回る場合にもフィードバックを抑制する必要があります。
When the maximum RTT changes significantly during one feedback round, it is necessary to reschedule the feedback timer in proportion to the change.
最大RTTが1回のフィードバックラウンド中に大幅に変化する場合、変更に比例してフィードバックタイマーを再スケジュールする必要があります。
t = t * R_max / R_max'
where R_max is the new maximum RTT and R_max' is the previous maximum RTT. The same considerations hold when the last data packets were received more than a time interval of R_max ago. In this case, it is necessary to add the difference of the inter-packet gap and the maximum RTT to the feedback time to prevent a feedback implosion (e.g., in case the sender crashed).
ここで、R_MAXは新しい最大RTTおよびR_MAX 'は以前の最大RTTです。最後のデータパケットがr_maxの時間間隔よりも前に受信された場合、同じ考慮事項が当てはまります。この場合、フィードバックの崩壊を防ぐために、パケット間ギャップと最大RTTの差をフィードバック時間に追加する必要があります（たとえば、送信者がクラッシュした場合）。
t = t + max(tr_now - tr_i - R_max, 0)
where tr_i is the time when the last data packet arrived at the receiver.
ここで、TR_Iは、最後のデータパケットが受信機に到着した時間です。
More details on the characteristics of the feedback suppression mechanism can be found in [13] and [3].
フィードバック抑制メカニズムの特性の詳細については、[13]および[3]に記載されています。
Obtaining an accurate and stable measurement of the loss event rate is of primary importance for TFMCC. Loss rate measurement is performed at the receiver, based on the detection of lost or marked packets from the sequence numbers of arriving packets.
TFMCCにとって、損失イベント率の正確で安定した測定値を取得することが主に重要です。到着パケットのシーケンス番号からの紛失またはマークされたパケットの検出に基づいて、レシーバーで損失率測定が実行されます。
TFMCC assumes that all packets contain a sequence number that is incremented by one for each packet that is sent. For the purposes of this specification, we require that if a lost packet is retransmitted, the retransmission is given a new sequence number that is the latest in the transmission sequence, and not the same sequence number as the packet that was lost. If a transport protocol has the requirement that it must retransmit with the original sequence number, then the transport protocol designer must figure out how to distinguish delayed from retransmitted packets and how to detect lost retransmissions.
TFMCCは、すべてのパケットに送信されるパケットごとに1つずつ増加するシーケンス番号が含まれていると想定しています。この仕様の目的のために、失われたパケットが再送信された場合、再送信に送信シーケンスの最新のシーケンス番号が与えられ、失われたパケットと同じシーケンス番号ではないことが必要です。トランスポートプロトコルには、元のシーケンス番号で再送信する必要があるという要件がある場合、トランスポートプロトコル設計者は、再送信されたパケットから遅延したものを区別する方法と、失われた再送信を検出する方法を把握する必要があります。
The receivers each maintain a data structure that keeps track of which packets have arrived and which are missing. For the purposes of specification, we assume that the data structure consists of a list of packets that have arrived along with the timestamp when each packet was received. In practice, this data structure will normally be stored in a more compact representation, but this is implementation-specific.
受信機はそれぞれ、どのパケットが到着し、どれが欠落しているかを追跡するデータ構造を維持します。仕様の目的のために、データ構造は、各パケットが受信されたときにタイムスタンプとともに到着したパケットのリストで構成されていると想定しています。実際には、このデータ構造は通常、よりコンパクトな表現に保存されますが、これは実装固有です。
The loss of a packet is detected by the arrival of at least three packets with a higher sequence number than the lost packet. The requirement for three subsequent packets is the same as with TCP, and it is to make TFMCC more robust in the presence of reordering. In contrast to TCP, if a packet arrives late (after 3 subsequent packets arrived) at a receiver, the late packet can fill the hole in the reception record, and the receiver can recalculate the loss event rate. Future versions of TFMCC might make the requirement for three subsequent packets adaptive based on experienced packet reordering, but we do not specify such a mechanism here.
パケットの損失は、失われたパケットよりも高いシーケンス番号を持つ少なくとも3つのパケットの到着によって検出されます。3つの後続のパケットの要件はTCPと同じであり、Reorderingの存在下でTFMCCをより堅牢にすることです。TCPとは対照的に、レシーバーでパケットが遅れて（後続の3つのパケットが到着した後）到着した場合、遅いパケットは受信記録の穴を埋め、レシーバーは損失イベント率を再計算できます。TFMCCの将来のバージョンは、経験豊富なパケットの並べ替えに基づいて、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.
ECN対応の接続の場合、マークされたパケットは、後続のパケットの到着を待つことなく、到着するとすぐに輻輳イベントとして検出されます。
TFMCC requires that the loss event rate be robust to several consecutive packets lost where those packets are part of the same loss event. This is similar to TCP, which (typically) only performs one halving of the congestion window during any single RTT. Thus the receivers need to map the packet loss history into a loss event record, where a loss event is one or more packets lost in an RTT.
TFMCCでは、これらのパケットが同じ損失イベントの一部である場合、損失イベントレートが紛失したいくつかの連続したパケットに対して堅牢であることを要求しています。これはTCPに似ており、（通常）単一のRTTの間に混雑ウィンドウの1つの半分のみを実行します。したがって、受信機は、パケット損失履歴を損失イベント記録にマッピングする必要があります。このイベントでは、損失イベントはRTTで1つ以上のパケットが失われます。
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_newの場合、その受信時間t_newに直接注意することができます。紛失したパケットの場合、公称の「到着時間」を推測するために補間することができます。推定：
S_loss is the sequence number of a lost packet.
S_LOSSは、失われたパケットのシーケンス番号です。
S_before is the sequence number of the last packet to arrive with sequence number before S_loss.
s_beforeは、s_lossの前にシーケンス番号で到着する最後のパケットのシーケンス番号です。
S_after is the sequence number of the first packet to arrive with sequence number after S_loss.
T_before is the reception time of S_before.
t_beforeはs_beforeの受信時間です。
T_after is the reception time of S_after.
Note that T_before can be either before or after T_after due to reordering.
T_BEFOREは、並べ替えのためにT_Afterの前または後のいずれかであることに注意してください。
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_LOSSの場合、S_BEFOREDとS_AFTERの到着時間から受信機に名目上の「到着時間」を補間することができます。したがって
T_loss = T_before + ( (T_after - T_before)
* (S_loss - S_before)/(S_after - S_before) );
Note that if the sequence space wrapped between S_before and S_after,
the sequence numbers must be modified to take this into account
before the calculation is performed. If the largest possible
sequence number is S_max, and S_before > S_after, then modifying each
sequence number S by S' = (S + (S_max + 1)/2) mod (S_max + 1) would
normally be sufficient.
If the lost packet S_old was determined to have started the previous loss event, and if we have just determined that S_new has been lost, then we interpolate the nominal arrival times of S_old and S_new, called T_old and T_new, respectively.
Lost Packet S_OLDが以前の損失イベントを開始したと判断された場合、S_NEWが失われたと判断した場合は、それぞれT_OLDとT_NEWと呼ばれるS_OLDとS_NEWの名目到着時間を補間します。
If T_old + R >= T_new, then S_new is part of the existing loss event. Otherwise, S_new is the first packet of a new loss event.
t_old r> = t_newの場合、s_newは既存の損失イベントの一部です。それ以外の場合、S_NEWは新しい損失イベントの最初のパケットです。
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_Aと次の損失間隔bで開始されたと判断された場合、bはパケットシーケンス番号S_Bで始まり、損失間隔aのパケットの数は（s_b -s_a）で与えられます。
To calculate the loss event rate p, we first calculate the average loss interval. This is done using a filter that weights the n most recent loss event intervals in such a way that the measured loss event rate changes smoothly.
Weights w_0 to w_(n-1) are calculated as:
ウェイトw_0からw_（n-1）は次のように計算されます。
If (i < n/2)
w_i = 1;
Else
w_i = 1 - (i - (n/2 - 1))/(n/2 + 1);
Thus if n=8, the values of w_0 to w_7 are:
したがって、n = 8の場合、w_0からw_7の値は次のとおりです。
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
The value n for the number of loss intervals used in calculating the loss event rate determines TFMCC's speed in responding to changes in the level of congestion. As currently specified, TFMCC should not be used for values of n significantly greater than 8, for traffic that might compete in the global Internet with TCP. At the very least, safe operation with values of n greater than 8 would require a slight change to TFMCC's mechanisms to include a more severe response to two or more round-trip times with heavy packet loss.
損失イベント率の計算に使用される損失間隔の数の値nは、うっ血レベルの変化に応答する際にTFMCCの速度を決定します。現在指定されているように、TFMCCは、TCPとグローバルなインターネットで競合する可能性のあるトラフィックに対して、8を超えるnの値に使用しないでください。少なくとも、Nの値が8を超える安全な動作は、TFMCCのメカニズムにわずかな変更が必要であり、重いパケット損失を伴う2つ以上の往復時間に対するより深刻な反応を含める必要があります。
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_0からI_Nの場合、I_0が最新の損失イベント以来の間隔である場合、平均損失間隔i_meanを次のように計算します。
I_tot0 = 0;
I_tot1 = 0;
W_tot = 0;
for (i = 0 to n-1) {
I_tot0 = I_tot0 + (I_i * w_i);
W_tot = W_tot + w_i;
}
for (i = 1 to n) {
I_tot1 = I_tot1 + (I_i * w_(i-1));
}
I_tot = max(I_tot0, I_tot1);
I_mean = I_tot/W_tot;
The loss event rate, p is simply:
損失イベント率、pは単純です：
p = 1 / I_mean;
As described in Section 5.4, the most recent loss interval is only assigned 4/(3*n) of the total weight in calculating the average loss interval, regardless of the size of the most recent loss interval. This section describes an optional history discounting mechanism that allows the TFMCC receivers to adjust the weights, concentrating more of the relative weight on the most recent loss interval, when the most recent loss interval is more than twice as large as the computed average loss interval.
To carry out history discounting, we associate a discount factor DF_i with each loss interval L_i, where each discount factor is a floating point number. The discount array maintains the cumulative history of discounting for each loss interval. At the beginning, the values of DF_i in the discount array are initialized to 1:
for (i = 0 to n) {
DF_i = 1;
}
History discounting also uses a general discount factor DF, also a floating point number, that is also initialized to 1. First, we show how the discount factors are used in calculating the average loss interval, and then we describe later in this section how the discount factors are modified over time.
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で説明したように、平均損失間隔は、前の損失間隔I_1、...、i_n、および最後の損失イベント以降に受信したパケットの数を表す間隔I_0を使用して計算されます。割引係数を使用した平均損失間隔の計算は、次のようにセクション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);
The general discounting factor DF is updated on every packet arrival as follows. First, a receiver computes the weighted average I_mean of the loss intervals I_1, ..., I_n:
一般的な割引係数DFは、次のようにすべてのパケット到着について更新されます。まず、レシーバーは、損失間隔の加重平均i_meanを計算しますi_1、...、i_n：
I_tot = 0;
W_tot = 0;
for (i = 1 to n) {
W_tot = w_(i-1) * DF_i;
I_tot = I_tot + (I_i * w_(i-1) * DF_i);
}
I_mean = I_tot / W_tot;
This weighted average I_mean is compared to I_0, the number of packets received since the last loss event. If I_0 is greater than twice I_mean, then the new loss interval is considerably larger than the old ones, and the general discount factor DF is updated to decrease the relative weight on the older intervals, as follows:
if (I_0 > 2 * I_mean) {
DF = 2 * I_mean/I_0;
if (DF < THRESHOLD)
DF = THRESHOLD;
} else
DF = 1;
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.
しきい値のゼロ以外の値は、高い輻輳の初期の時期からの古い損失間隔が完全に割引されないことを保証します。0.5のしきい値をお勧めします。新しいパケット到着ごとに、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_Nは忘れられます。以前の割引係数DFは、割引アレイに組み込む必要があります。DF_Iは損失間隔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;
This completes the description of the optional history discounting mechanism. We emphasize that this is an optional mechanism whose sole purpose is to allow TFMCC to respond more quickly to the sudden absence of congestion, as represented by a long current loss interval.
これにより、オプションの履歴割引メカニズムの説明が完了します。これは、長い電流損失間隔で表されるように、TFMCCが混雑の突然の不在により迅速に対応できるようにすることを唯一の目的とするオプションのメカニズムであることを強調します。
The number of packets received before the first loss event usually does not reflect the current loss event rate. When the first loss event occurs, a TFMCC receiver assumes that the correct data rate is the rate at which data was received during the last RTT when the loss occurred. Instead of initializing the first loss interval to the number of packets sent until the first loss event, the TFMCC receiver calculates the loss interval that would be required to produce the receive rate X_recv, and it uses this synthetic loss interval l_0 to seed the loss history mechanism.
The initial loss interval is calculated by inverting a simplified version of the TCP Equation (1).
8s
X_recv = sqrt(3/2) * -----------------
R * sqrt(1/l_0)
X_recv * R
==> l_0 = (----------------)^2
sqrt(3/2) * 8s
The resulting initial loss interval is too small at higher loss rates compared to using the more accurate Equation (1), which leads to a more conservative initial loss event rate.
If a receiver still uses the initial RTT R_max instead of its real RTT, the initial loss interval is too large in case the initial RTT is higher than the actual RTT. As a consequence, the receiver will calculate too high a desired rate when the first RTT measurement R is made and the initial loss interval is still in the loss history. The receiver has to adjust l_0 as follows:
レシーバーが実際のRTTの代わりに初期RTT R_MAXを使用している場合、初期RTTが実際のRTTよりも高い場合、初期損失間隔が大きすぎます。結果として、最初のRTT測定Rが行われ、初期損失間隔がまだ損失履歴にある場合、受信機は目的の高いレートを計算しすぎます。受信者は、次のようにL_0を調整する必要があります。
l_0 = l_0 * (R/R_max)^2
No action needs to be taken when the first RTT measurement is made after the initial loss interval left the loss history.
最初のRTT測定が最初の損失間隔が損失履歴を離れた後に行われた場合、アクションを実行する必要はありません。
TFMCC is not a transport protocol in its own right, but a congestion control mechanism that is intended to be used in conjunction with a transport protocol. Therefore, security primarily needs to be considered in the context of a specific transport protocol and its authentication mechanisms.
TFMCCは、それ自体が輸送プロトコルではなく、輸送プロトコルと組み合わせて使用することを目的とした輻輳制御メカニズムです。したがって、セキュリティは、特定の輸送プロトコルとその認証メカニズムのコンテキストで主に考慮する必要があります。
Congestion control mechanisms can potentially be exploited to create denial of service. This may occur through spoofed feedback. Thus, any transport protocol that uses TFMCC should take care to ensure that feedback is only accepted from valid receivers of the data. However, the precise mechanism to achieve this will depend on the transport protocol itself.
Congestion control mechanisms may potentially be manipulated by a greedy receiver that wishes to receive more than its fair share of network bandwidth. However, in TFMCC a receiver can only influence the sending rate if it is the CLR and thus has the lowest calculated rate of all receivers. If the calculated rate is then manipulated such that it exceeds the calculated rate of the second to lowest receiver, it will cease to be CLR. A greedy receiver can only significantly increase the transmission rate if it is the only participant in the session. If such scenarios are of concern, possible defenses against such a receiver would normally include some form of nonce that the receiver must feed back to the sender to prove receipt. However, the details of such a nonce would depend on the transport protocol and, in particular, on whether the transport protocol is reliable or unreliable.
混雑制御メカニズムは、ネットワーク帯域幅の公正なシェアを超えて多くを受け取ることを希望する貪欲なレシーバーによって操作される可能性があります。ただし、TFMCCでは、受信者はCLRである場合にのみ送信率に影響を与える可能性があるため、すべての受信機の計算率が最も低くなります。計算された速度が操作され、2番目から最低受信機の計算レートを超えるように操作された場合、CLRになります。貪欲なレシーバーは、セッションの唯一の参加者である場合にのみ、伝送速度を大幅に上げることができます。そのようなシナリオが懸念される場合、そのような受信者に対する防御の可能性には、通常、受信者が領収書を証明するために送信者にフィードバックする必要がある何らかの形のノンセが含まれます。ただし、このようなノンセの詳細は、輸送プロトコル、特に輸送プロトコルが信頼性があるか信頼できないかに依存します。
It is possible that a receiver sends feedback claiming that it has a very low calculated rate. This will reduce the rate of the multicast session and might render it useless but obviously cannot hurt the network itself.
レシーバーは、計算レートが非常に低いと主張するフィードバックを送信する可能性があります。これにより、マルチキャストセッションの速度が低下し、役に立たなくなる可能性がありますが、明らかにネットワーク自体を傷つけることはできません。
We expect that protocols incorporating ECN with TFMCC will also want to incorporate feedback from the receiver to the sender using the ECN nonce [12]. The ECN nonce is a modification to ECN that protects the sender from the accidental or malicious concealment of marked packets. Again, the details of such a nonce would depend on the transport protocol and are not addressed in this document.
ECNをTFMCCに組み込んだプロトコルは、ECN NonCeを使用して受信機から送信者へのフィードバックを組み込むことも期待しています[12]。ECN Nonceは、マークされたパケットの偶発的または悪意のある隠蔽から送信者を保護するECNの変更です。繰り返しますが、このようなノンセの詳細はトランスポートプロトコルに依存し、このドキュメントでは対処されていません。
We would like to acknowledge feedback and discussions on equation-based congestion control with a wide range of people, including members of the Reliable Multicast Research Group, the Reliable Multicast Transport Working Group, and the End-to-End Research Group. We would particularly like to thank Brian Adamson, Mark Pullen, Fei Zhao, and Magnus Westerlund for feedback on earlier versions of this document.
[1] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S., and M. Luby, "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer", RFC 3048, January 2001.
[1]
[2] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.
[2] Kermode、R。およびL. Vicisano、「信頼できるマルチキャストトランスポート（RMT）ビルディングブロックとプロトコルインスタンス化ドキュメントの著者ガイドライン」、RFC 3269、2002年4月。
[3] J. Widmer and M. Handley, "Extending Equation-Based Congestion Control to Multicast Applications", Proc ACM Sigcomm 2001, San Diego, August 2001.
[3] J. WidmerおよびM. Handley、「方程式ベースの混雑制御をマルチキャストアプリケーションに拡張」、Proc ACM Sigcomm 2001、サンディエゴ、2001年8月。
[4] S. Floyd, M. Handley, J. Padhye, and J. Widmer, "Equation-Based Congestion Control for Unicast Applications", Proc ACM SIGCOMM 2000, Stockholm, August 2000.
[4]
[5] Adamson, B., Bormann, C., Handley, M., and J. Macker, "Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks", RFC 3941, November 2004.
[5] Adamson、B.、Bormann、C.、Handley、M。、およびJ. Macker、「ネガティブ・クノウレッド（NACK）指向の信頼できるマルチキャスト（NORM）ビルディングブロック」、RFC 3941、2004年11月。
[6] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[6] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[7] H. W. Holbrook, "A Channel Model for Multicast," Ph.D. Dissertation, Stanford University, Department of Computer Science, Stanford, California, August 2001.
[7] H. W.ホルブルック、「マルチキャストのチャネルモデル」、博士号論文、スタンフォード大学、2001年8月、カリフォルニア州スタンフォード大学コンピューターサイエンス学科。
[8] J. Padhye, V. Firoiu, D. Towsley, and J. Kurose, "Modeling TCP Throughput: A Simple Model and its Empirical Validation", Proc ACM SIGCOMM 1998.
[8]
[9] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[9] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。
[10] L. Rizzo, "pgmcc: a TCP-friendly single-rate multicast congestion control scheme", Proc ACM Sigcomm 2000, Stockholm, August 2000.
[10] L. Rizzo、「PGMCC：TCPフレンドリーなシングルレートマルチキャスト輻輳制御スキーム」、Proc ACM Sigcomm 2000、ストックホルム、2000年8月。
[11] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[11] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[12] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003.
[12] Spring、N.、Wetherall、D。、およびD. Ely、「堅牢な明示的な混雑通知（ECN）ノンセスによるシグナル伝達」、RFC 3540、2003年6月。
[13] J. Widmer and T. Fuhrmann, "Extremum Feedback for Very Large Multicast Groups", Proc NGC 2001, London, November 2001.
[13] J. WidmerとT. Fuhrmann、「非常に大規模なマルチキャストグループの極限フィードバック」、Proc NGC 2001、ロンドン、2001年11月。
Authors' Addresses
著者のアドレス
Joerg Widmer DoCoMo Euro-Labs Landsberger Str. 312, Munich, Germany EMail: widmer@acm.org
Joerg Widmer Docomo Euro-Labs Landsberger str。312、ミュンヘン、ドイツメール：widmer@acm.org
Mark Handley UCL (University College London) Gower Street, London WC1E 6BT, UK EMail: m.handley@cs.ucl.ac.uk
Mark Handley UCL（University College London）Gower Street、London WC1E 6BT、英国メール：m.handley@cs.ucl.ac.uk
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。