RFC4654 日本語訳
4654 TCP-Friendly Multicast Congestion Control (TFMCC): ProtocolSpecification. J. Widmer, M. Handley. August 2006. (Format: TXT=72190 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Widmer
Request for Comments: 4654 DoCoMo Euro-Labs
Category: Experimental M. Handley
UCL
August 2006
コメントを求めるワーキンググループJ.ウィトマーの要求をネットワークでつないでください: 4654年のDoCoMoユーロ研究室カテゴリ: 実験的なM.ハンドレーUCL2006年8月
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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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好意的なMulticast Congestion Control(TFMCC)を指定します。 TFMCCはベストエフォート型インターネット環境におけるマルチキャスト送信のための混雑制御機構です。 それは単一賃率輻輳制御計画です、送付レートが経験する中でネットワーク状態最も悪い受信機に適合させられるところで。 TFMCCはTCP流れで帯域幅を競争するとき、合理的に公正であり、時間がたつにつれてスループットの比較的低い変化を持っています、それを比較的滑らかな送付レートが重要であるアプリケーションに適するようにして、ストリーミング・メディアなどのように。
Widmer & Handley Experimental [Page 1] RFC 4654 TFMCC: Protocol Specification August 2006
ウィトマーとハンドレー実験的な[1ページ]RFC4654TFMCC: プロトコル仕様2006年8月
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
1. 序論…3 1.1. ドキュメントについて話します…4 1.2. 環境要求事項と問題…4 2. 概観について議定書の中で述べてください…5 2.1. TCPスループット方程式…6 2.2. パケットコンテンツ…7 2.2.1. 送付者パケット…8 2.2.2. フィードバックパケット…9 3. データ送付者は議定書を作ります…10 3.1. 送付者初期設定…10 3.2. 最大のRTTを決定します…10 3.3. 発信を調整して、評価してください…11 3.4. 受信機フィードバックを制御します…12 3.5. 受信機サイドRTT測定値を補助します…14 3.6. Slowstart…15 3.7. パケット伝送のスケジューリング…15 4. データ受信機は議定書を作ります…16 4.1. 受信機初期設定…17 4.2. 受信機休暇…17 4.3. ネットワーク状態の測定…17 4.3.1. 損失出来事をアップデートして、評価してください…17 4.3.2. 基本的な往復の時間測定…17 4.3.3. 片道遅れ調整…18 4.3.4. レート測定値を受け取ってください…19 4.4. 必要なレートを設定します…19 4.5. フィードバックとフィードバック抑圧…20 5. 損失イベント率の計算…22 5.1. 無くなっているか著しいパケットの検出…22 5.2. 損失歴史から損失出来事までの翻訳…23 5.3. 相互の損失イベント間隔…24 5.4. 損失間隔を平均してください…24 5.5. 歴史の値段をひくこと…25 5.6. 最初の損失出来事の後に損失歴史を初期化します。27 6. セキュリティ問題…28 7. 承認…29 8. 参照…29 8.1. 標準の参照…29 8.2. 有益な参照…29
Widmer & Handley Experimental [Page 2] RFC 4654 TFMCC: Protocol Specification August 2006
ウィトマーとハンドレー実験的な[2ページ]RFC4654TFMCC: プロトコル仕様2006年8月
1. Introduction
1. 序論
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好意的なMulticast Congestion Control(TFMCC)[3]を指定します。 TFMCCはユニキャストのTCP好意的なRate Controlメカニズム(TFRC)[4]を当てにするソースベースの、そして、ただ一つのレートの輻輳制御計画です。 TFMCCはさまざまなネットワーク状態とスケールの下で数1,000台の受信機の注文の受信機セットに安定していて敏感です。 スケーラビリティを支持するために、できるだけ多くの輻輳制御の機能性が受信機に位置しています。 各受信機は、望まれていたaが経路に、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はRFC3048[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は使用されるべきです、特に、送付レートが1パケット滴に対応して半分にされるのを避けて。 単にできるだけ短い間でできるだけ多くのデータをマルチキャストに必要とするアプリケーションに、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.
このメモはRFC2357によると、Reliable Multicast Transportプロトコルを完全に指定するのに必要な定義の一部を含んでいます。 RFC2357に従って、インターネットでのどんな信頼できるマルチキャストプロトコルの使用も適切な輻輳制御計画を必要とします。 このドキュメントは実験的な輻輳制御計画を指定します。 初期の展開と経験が、この計画が有効であって、スケーラブルであることを示すのを待っている間、IETFは「実験的な」カテゴリにおけるこの計画を発行します。
Widmer & Handley Experimental [Page 3] RFC 4654 TFMCC: Protocol Specification August 2006
ウィトマーとハンドレー実験的な[3ページ]RFC4654TFMCC: プロトコル仕様2006年8月
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.
それは計画の次第IETF Proposed Standardが適切であると考えられるときReliable Multicast Transport(RMT)作業部会が仕様を再提出する意図です。
1.1. Related Documents
1.1. 関連ドキュメント
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].
RFC3048[1]で説明されるように、TFMCCはプロトコル具体化を指定するのを助けるのに他のブロックに関連して使用されることを意図するブロックです。 一般的ガイドラインがRFC3269[2]に提供されたということになります。 TFMCCは特に、ナックが指向のReliable Multicast(NORM)[5]のための適当な混雑制御建家です。
1.2. Environmental Requirements and Considerations
1.2. 環境要求事項と問題
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]で定義されるAny-ソースMulticast(ASM)モデルとSource特有のMulticast(SSM)は[7]で定義されるようにモデル化します。 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、イントラネット、インターネット、非対称のネットワーク、ワイヤレス・ネットワーク、および衛星ネットワークを含んでいて。 しかしながら、いくつかのネットワーク環境で、送付レートを受信機に変えるのは有利でないかもしれません(例えば、衛星かワイヤレス・ネットワークのために、セッションまで割り当てられた固定通信速度があるかもしれないので事実上、受信機がそれらのレセプション率を低下させるメカニズムは全くないかもしれません)。
Widmer & Handley Experimental [Page 4] RFC 4654 TFMCC: Protocol Specification August 2006
ウィトマーとハンドレー実験的な[4ページ]RFC4654TFMCC: プロトコル仕様2006年8月
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の反応性の違いは非常に低いbitrateの場合に重要なスループット差をもたらすかもしれません。 TFMCCは、公正な送付レートに計算するために損失イベント率の見積りを必要とします。 TFMCCが1RTTあたりのほんのわずかなパケットだけを受けるといけないので、この見積りは不正確であるかもしれません。 ボトルネックリンクの容量が30KBit/s(例えば、非常に遅いモデム接続)より少ないなら、TCPと共にTFMCCを使用するべきではありません。 また、TFMCCはボトルネックのバッファ領域が厳しくunderprovisionedされるといけないので平均したTCPレートと非常に異なったレートを達成するかもしれません。 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秒あたりのパケットで混雑に対応してそれらの送付レートを変えるアプリケーションのために設計されています。 いくつかのアプリケーション(例えば、オーディオを使用するもの)が、パケットの間の時間の固定間隔を必要として、混雑に対応したそれらのパケットレートの代わりにそれらのパケットサイズを変えます。 それらのアプリケーションで本書では混雑制御機構を使用できません。
2. Protocol Overview
2. プロトコル概観
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スループット(およそ、損失イベント率、往復の時間(RTT)、およびパケットサイズの関数としてTCPの送付レートを記述する)に方程式を使用することで決定しています。 私たちが損失出来事を1つと定義するか、または以上は、1RTTの間に受け取られたパケットから、パケットを失ったか、マークしました。そこでは、著しいパケットがExplicit Congestion Notification(電子証券取引ネットワーク)[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スループットのための方程式と共にこの情報を使用します。
Widmer & Handley Experimental [Page 5] RFC 4654 TFMCC: Protocol Specification August 2006
ウィトマーとハンドレー実験的な[5ページ]RFC4654TFMCC: プロトコル仕様2006年8月
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.
TFMCCの力学は測定がどう実行されて、適用されるかと、そして、どんなフィードバック抑圧メカニズムが選ばれているかに敏感です。 私たちは、以下の特定のメカニズムがこれらの測定を実行して、当てはまることを勧めます。 他のメカニズムは可能ですが、メカニズムの間の相互作用がどのようにTFMCCの力学に影響するかを理解しているのは重要です。
2.1. TCP Throughput Equation
2.1. TCPスループット方程式
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のものはタイムアウトの振舞いを再送します、これが、より高い損失率でTCPスループットを支配するとき。 また、私たちは、損失イベントレートパラメタに関するスループット方程式による暗黙の仮定が損失率か損失イベント率が実際にどう測定されるかへの妥当なマッチでなければならないことに注意します。 スループット方程式と以下に与えられた損失レート測定メカニズムには、このマッチが完全でない間、実際には、仮定は、十分近くにあるように判明します。
The throughput equation we currently recommend for TFMCC is a slightly simplified version of the throughput equation for Reno TCP from [8]:
私たちが現在TFMCCのために推薦するスループット方程式は[8]からのリノTCPのためのスループット方程式のわずかに簡易型のバージョンです:
8 s
X = --------------------------------------------------------- (1)
R * (sqrt(2*p/3) + (12*sqrt(3*p/8) * p * (1+32*p^2)))
8秒間X=--------------------------------------------------------- (1) R*(sqrt(2*p/3)+(12*sqrt(3*p/8)*p*(1+32*p^2)))
Widmer & Handley Experimental [Page 6] RFC 4654 TFMCC: Protocol Specification August 2006
ウィトマーとハンドレー実験的な[6ページ]RFC4654TFMCC: プロトコル仕様2006年8月
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方程式をこの方程式に代入するかもしれません。 要件はスループット方程式がconformant 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(パケットサイズ)はアプリケーションに知られています。 したがって、コネtwoは、これがそうでなく、以下をケースに入れます。
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 アプリケーションは、輻輳制御を実行するために1秒あたりのパケットの数よりむしろパケットサイズを変える必要があります。 通常、これは時間の固定間隔が各パケットによって表される必要があるパケットオーディオアプリケーションでのそうでしょう。 そのようなアプリケーションはパラメタを測定する異なった方法を必要とします。
Currently, TFMCC cannot be used for the second class of applications.
現在、アプリケーションの二等にTFMCCを使用できません。
2.2. Packet Contents
2.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.
送付者と受信機の機能性を指定する前に、私たちは受信機から送付者によって送られたパケットとフィードバックパケットに含まれた混雑制御情報について説明します。 送付者からの情報を別々の輻輳制御メッセージで送るか、またはデータ・パケットに背負うことができます。 データ・パケット(例えば、1フィードバックに一度ラウンド)の時間間隔より大きい時間間隔で、別々の輻輳制御メッセージを送るなら、十分な数の受信機が1台以上の受信機でそれらのRTTを測定できるように運命づけられたタイムスタンプ情報は含むことができるのが必要です。
Widmer & Handley Experimental [Page 7] RFC 4654 TFMCC: Protocol Specification August 2006
ウィトマーとハンドレー実験的な[7ページ]RFC4654TFMCC: プロトコル仕様2006年8月
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.
TFMCCがトランスポート・プロトコルと共に使用されるとき、私たちはパケット・フォーマットを指定しません、これらが使用されるトランスポート・プロトコルの詳細によるので。 ヘッダーフィールドのお勧めの表現を以下に与えます。 あるいはまた、浮動小数点表示のコンピュータのオーバーヘッドがひどく高いなら、より大きいパケットのヘッダーを犠牲にして固定小数点演算を使用できます。 特定のTFMCC例の送付者と受信機は、ヘッダーフィールドのための一般的なコード化に同意する必要があります。
2.2.1. Sender Packets
2.2.1. 送付者パケット
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 ビット/sの抑圧レートX_supp。 計算されたレートが抑圧率より低い受信機だけがフィードバックする資格がある、その場合、また、それらのRTTが以下で説明された最大のRTTほど高くない場合、彼らもフィードバックする資格があります。 無記名の解説者のための5ビットと無記名の仮数のための7ビット(1%未満の誤りで100ビット/sから400Gbit/sまでレートを表す)で抑圧率は12ビットの浮動小数点値として表されるべきです。
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 パケットがいつ送られるかを示すタイムスタンプt_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 '受信機ID rとタイムスタンプtr_rのコピー'はその受信機の最後のレポートのtr_rと等しいです。(受信機はレポートでRTTを測定できます)。 '受信機rからレポートを受け取って、データ・パケットを送るとき、遅れtがあれば、tr_r'=tr_r+tは代わりにパケットに含まれています。 受信機IDは次のセクションで説明されます。 タイムスタンプエコーの解決はミリセカンドであるべきです、そして、タイムスタンプは幅16ビット未満の符号のない整数値のノーであるべきです。 別々の輻輳制御メッセージが便乗しているものの代わりに使用されるなら、パケットは、十分な数の受信機が同時にそれらのRTTを測定するのを許容するために対応するタイムスタンプで受信機IDのリストを含む必要があります。 フィードバックの過程に使用されるデフォルト値のために、これは10〜20のエントリーの注文のリストサイズに対応しています。
Widmer & Handley Experimental [Page 8] RFC 4654 TFMCC: Protocol Specification August 2006
ウィトマーとハンドレー実験的な[8ページ]RFC4654TFMCC: プロトコル仕様2006年8月
o A flag is_CLR indicating whether the receiver with ID r is the CLR.
o 旗はそうです。_ID rがある受信機がCLRであるかどうかを示す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 カウンタfb_nrの周りのフィードバック。 このカウンタは、より古いラウンドのためのすべてのフィードバックが抑圧されるべきであるように受信機に通知するために丸い新しいフィードバックの始めの送付者によって増加されます。 フィードバックラウンドカウンタは幅少なくとも4ビットであるべきです。
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 すべての受信機のRTTsの最大を表す最大のRTT値のR_最大。 RTTはミリセカンドで測定されるべきです。 無記名の解説者のための4ビットと無記名の仮数のための4ビットがある8ビットの浮動小数点値(caの誤りで1ミリセカンドから64秒までRTTsを表すために。 6%) 表現に使用されるべきです。
2.2.2. Feedback Packets
2.2.2. フィードバックパケット
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 ユニークな受信機ID r。 多くの場合、トランスポート・プロトコルから受信機IDを供給するでしょうが、それは単に受信機のIPアドレスであるかもしれません。
o A flag have_RTT indicating whether the receiver has made at least
one RTT measurement since it joined the session.
o 旗で、_RTTは、受信機がセッションに参加して以来少なくとも1つのRTT測定をしているかどうかを示します。
o A flag have_loss indicating whether the receiver experienced at
least one loss event since it joined the session.
o 旗には、_セッションに参加したので受信機が少なくとも1回の損失出来事を経験したかどうかを示す損失があります。
o A flag receiver_leave indicating that the receiver will leave the
session (and should therefore not be CLR).
o 受信機がセッション(そして、したがって、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 最後のデータ・パケットに関するタイムスタンプの'エコーt_i'は受信されました。 '受信機に受け取られた最後のパケットが一連番号iを持っているなら、t_i'=t_iはフィードバックに含まれています。 'その最後のデータ・パケットを受けて、フィードバックを送るとき、遅れtrがあれば、t_i'=t_i+trは代わりにフィードバックに含まれています。 タイムスタンプエコーの表現はデータ・パケットでタイムスタンプのものと同じであるべきです。
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 エコーfb_nrの周りのフィードバックであり、対価の周りで最も高いフィードバックを反映するのは今までのところ、受信されました。 フィードバックラウンドエコーの表現はデータ・パケットのフィードバックラウンドカウンタに使用されるものと同じであるべきです。
Widmer & Handley Experimental [Page 9] RFC 4654 TFMCC: Protocol Specification August 2006
ウィトマーとハンドレー実験的な[9ページ]RFC4654TFMCC: プロトコル仕様2006年8月
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送付者からこの受信機までに優しくなるように受信機によって計算されたレートです。必要な送付レートの表現はデータ・パケットで抑圧率のものと同じであるべきです。
3. Data Sender Protocol
3. データ送付者プロトコル
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.
aのデータ受信装置へのデータ・パケットの流れが制御したデータ送付者マルチキャストは評価します。 フィードバックが受け取られているときはいつも、送付者は、CLRsを切り換えて、送付レートを再調整するのが必要であるかどうかチェックします。
The main tasks that have to be provided by a TFMCC sender are:
TFMCC送付者によって提供されなければならない主なタスクは以下の通りです。
o adjusting the sending rate,
o 送付レートを調整します。
o controlling receiver feedback, and
o そして受信機フィードバックを制御する。
o assisting receiver-side RTT measurements.
o 受信機サイドRTT測定値を補助します。
3.1. Sender Initialization
3.1. 送付者初期設定
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.
送付者の初期化では、最大のRTTは最も高いRTTより受信機のいずれにも大きいはずである値に用意ができています。 それは公共のインターネットでの操作の割には500ミリセカンドより小さいはずがありません。 送付レートXは最大のRTTあたり1つのパケットに初期化されます。
3.2. Determining the Maximum RTT
3.2. 最大の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=t--t_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:
現在t_が時間であるところに、フィードバックパケットは到着しました。 '受信機はこの間隔がR_rに含まれないように最後のデータ・パケットを受けて、対応するレポートを送るところの時間間隔の間のt_i'を調整してしまうでしょう。 '実際のRTTがタイムスタンプとtの解決より小さいなら、_は現在、t_iと等しく'、次に、R_rは0(すなわち、私たちの場合における1ミリセカンド)より大きい最も小さい上向きのRTT値に設定されます。 瞬時に起こっているRTTが現在の最大のRTTより大きいなら、最大のRTTはその値に増加します:
R_max = R_r
R_最大=R_r
Widmer & Handley Experimental [Page 10] RFC 4654 TFMCC: Protocol Specification August 2006
ウィトマーとハンドレー実験的な[10ページ]RFC4654TFMCC: プロトコル仕様2006年8月
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)
R_最大=最大(0.9に、R_が最大限にするR_最大*)
where R_peak is the peak receiver RTT measured during the feedback round.
R_がどこでピークに達するかは、フィードバックの間にぐるりと測定されたピーク受信機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は異種のRTTsがある受信機の中のフィードバック抑圧に主に使用されます。 フィードバック抑圧は密接にデータ・パケットの発信と結合されます、そして、この理由で、最大のRTTは連続したデータ・パケットの最大の時間間隔の下で減少してはいけません:
R_max = max(R_max, 8s/X + ts_gran)
R_最大=最大(R_最大、8/X+t_のおばあちゃん)
where ts_gran is the granularity of the sender's system clock (see Section 3.7).
t_おばあちゃんが送付者のシステムの粒状であるところでは、時間を計ってください(セクション3.7を見てください)。
3.3. Adjusting the Sending Rate
3.3. 送付レートを調整します。
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. どんなCLRも存在していないなら、受信機rは現在の制限受信機になります。送付レートXは直接X_rに設定されます、これが8未満/R_最大ビット/s(すなわち、R_最大あたり1つのパケット)の増税をもたらすだろう限り。 さもなければ、Xによる徐々にX_rに増加して、増加で、秒があらゆるR_が最大限にする8/R_最大ビット/sだけについて評価しているということです。
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. 受信機rがCLRではありませんが、CLRが存在しているなら、受信機rは受信機のものが設定されないと報告するX_rが現在の送付レートXより少ないか、そして、受信機_休暇が弛む現在の制限受信機になります。 その上、送付レートはX_rに低下します。
3. If receiver r is not the CLR but a CLR is present and the
receiver_leave flag of the CLR's last report was set, then
receiver r becomes the current limiting receiver. However, if
X_r > X, the sending rate is not increased to X_r for the
duration of a feedback round to allow other (lower rate)
receivers to give feedback and be selected as CLR.
3. 受信機rがCLRではありませんが、CLRが存在していて、_休暇が旗を揚げさせるCLRの最後のレポートの受信機が設定されたなら、受信機rは現在の制限受信機になります。しかしながら、X_r>Xであるなら、送付レートは他の(低料金)受信機がフィードバックして、CLRとして選定されるのを許容するために丸いフィードバックの持続時間のためにX_rに増加しません。
Widmer & Handley Experimental [Page 11] RFC 4654 TFMCC: Protocol Specification August 2006
ウィトマーとハンドレー実験的な[11ページ]RFC4654TFMCC: プロトコル仕様2006年8月
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. 受信機rがCLRであるなら、送付レートはX_rの最小限に設定されます、そして、X+8/R_はビット/sに最大限にします。
If the receiver has not yet measured its RTT but already experienced packet loss (indicated by the corresponding flags in the receiver report), the receiver report will include a desired rate that is based on the maximum RTT rather than the actual RTT to that receiver. In this case, the sender adjusts the desired rate using its measurement of the instantaneous RTT R_r to that receiver:
受信機がまだRTTを測定していませんが、既にパケット損失を経験したなら(受信機レポートの対応する旗で、示されます)、受信機レポートは実際のRTTよりむしろ最大のRTTに基づいている必要なレートをその受信機に含むでしょう。この場合、送付者は瞬時に起こっているRTT R_rの測定をその受信機に使用することで必要なレートを調整します:
X_r' = X_r * R_max / R_r
'X_r'はX_r*R_最大/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.
CLRが10選択されたRTTsでなく、またTFMCC送付者が4RTTsのためにCLRからレポートを全く受け取らないなら、送付レートが半分に切られる、前 さらに、送付者が少なくとも10RTTsのためにCLRからレポートを全く受け取らないなら、それは、CLRがグループを墜落したか、または出たと仮定します。 新しいCLRは次に送付者に到着するフィードバックから選択されます、そして、私たちはケース3のように増加します、上です。
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.
どんな新しいCLRも選択できないなら(すなわち、受信機のどれかからのどんなフィードバックがないとき)、送付レートをさらに低下させるのが必要です。 フィードバックのない10連続したRTTs毎に関しては、送付レートは半分に切られます。 レートは8秒毎に1つのパケットまで高々減少されています。
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_が最大限にする8/R_最大ビット/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.
TFMCCを使用するアプリケーションは最小の送付レート要件を持っているかもしれません、送付レートが絶え間なくこの最低料率の下まで下がるならアプリケーションが使用不可能になるところで。 アプリケーションはマルチキャストグループからそのような低率を報告する受信機を除くべきです。 アプリケーションに依存していて、このドキュメントの範囲を超えてこれをする特定のメカニズム。
3.4. Controlling Receiver Feedback
3.4. 受信機フィードバックを制御します。
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倍に減少するかもしれません。
Widmer & Handley Experimental [Page 12] RFC 4654 TFMCC: Protocol Specification August 2006
ウィトマーとハンドレー実験的な[12ページ]RFC4654TFMCC: プロトコル仕様2006年8月
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.
R_最大より高いRTTと共に抑圧率のX_suppかそれらより低いレートを報告したがっている受信機だけがフィードバックを送るかもしれません。 それぞれのフィードバックラウンドの始めに、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
X_suppは(1g)*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がケースX_rに受信機の本当のRTTを反映するように送付者によって調整されてはいけないというメモは送付レート(セクション3.3)を設定するためにしているように最大のRTTを使用することで計算されました。 さもなければ、フィードバック内部破裂は可能です。 パラメタ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).
それらのフィードバックを抑圧するために受信機を許容するために、送付者の抑圧率は、フィードバックが受け取られているときはいつも、アップデートする必要があります。 レートがかなり(すなわち、それはいつ以前に広告を出した抑圧率の(1g)倍以下に減少しますか)変化するときはいつも、この抑圧率は、どちらかデータパケットのヘッダーにそれを含んでいることによって直ちに受信機に伝えられなければならないか、または別々の輻輳制御メッセージが使用されているなら、抑圧と共にメッセージを送ることによって、評価しなければなりません。
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で再開します。
Widmer & Handley Experimental [Page 13] RFC 4654 TFMCC: Protocol Specification August 2006
ウィトマーとハンドレー実験的な[13ページ]RFC4654TFMCC: プロトコル仕様2006年8月
3.5. Assisting Receiver-Side RTT Measurements
3.5. 受信機サイドRTT測定値を補助します。
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.
受信機は、受信機レポートでタイムスタンプを送ることによって、それらのRTTを測定します。(それは、送付者によって反映されます)。 混雑制御情報がデータ・パケットに背負われるなら、通常1台の受信機だけのIDとタイムスタンプを含むことができます。 異なった受信機からの複数のフィードバックメッセージが2つのデータ・パケットの時間間隔の間、送付者に到着するなら、送付者は、RTTを測定するのをどの受信機を許容したらよいかを決めなければなりません。 別々の輻輳制御メッセージで同時の複数の受信機タイムスタンプを反響して、最後の輻輳制御メッセージがリストサイズを超えているのでフィードバックした受信機の数を反響するなら、同じくらいは適用されます。
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. 新しいCLR(CLRの変化の後の)か少しも前のRTT測定値のない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. 対応する受信機レポートのフィードバックラウンドエコーの注文における少しも前のRTT測定値のない受信機(すなわち、より古いフィードバック、1番目)
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.
レポートを受け取って、次のデータ・パケットを送るとき経過する時間を説明するのが必要です。 今回は、RTTから差し引かれて、その結果、受信機のタイムスタンプ値に加えなければならない必要があります。
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の最後のタイムスタンプは反映されます。 1RTTあたりのパケットの数が非常に下位であるのですべてのパケットが少なくとも一度非CLR受信機のタイムスタンプを運ぶとき、CLRのタイムスタンプとIDはデータ・パケットにフィードバック単位でぐるりと含まれています。
Widmer & Handley Experimental [Page 14] RFC 4654 TFMCC: Protocol Specification August 2006
ウィトマーとハンドレー実験的な[14ページ]RFC4654TFMCC: プロトコル仕様2006年8月
3.6. Slowstart
3.6. Slowstart
TFMCC uses a slowstart mechanism to quickly approach its fair bandwidth share at the start of a session. During slowstart, the sending rate increases exponentially. The rate increase is limited to the minimum of the rates included in the receiver reports, and receivers report twice the rate at which they currently receive data. As in normal congestion control mode, the receiver with the smallest reported rate becomes CLR. Since a receiver can never receive data at a rate higher than its link bandwidth, this effectively limits the overshoot to twice this bandwidth. In case the resulting increase over R_max is less than 8s/R_max bits/s, the sender may choose to increase the rate by up to 8s/R_max bits/s every R_max. The current sending rate is gradually adjusted to the target rate reported in the receiver reports over the course of an RTT. Slowstart is terminated as soon as any one of the receivers experiences its first packet loss. Since that receiver's calculated rate will be lower than the current sending rate, the receiver will be selected as CLR.
TFMCCは、セッションの始めですばやく公正な帯域幅株にアプローチするのにslowstartメカニズムを使用します。 slowstartの間、送付レートは指数関数的に増加します。 増税は受信機レポートにレートを含む最小限に制限されます、そして、受信機は彼らが現在データを受け取るレートの2倍を報告します。 正常な輻輳制御モードのように、最もわずかな報告されたレートがある受信機はCLRになります。 以来に受信機が事実上、リンク帯域幅より高く、これが制限するレートでデータを決して受け取ることができない、この帯域幅の2倍に飛び越えてください。 R_最大より結果として起こる増加が8未満/R_最大ビット/sであるといけないので、送付者は、あらゆるR_が最大限にする最大8/R_最大ビット/sでレートを増加させるのを選ぶかもしれません。 現在の送付レートは徐々にRTTの過程の上の受信機レポートで報告された目標金利に調整されます。 受信機のどれかが最初のパケット損失を経験するとすぐに、Slowstartは終えられます。 その受信機の計算されたレートが現在の送付レートよりさらに低くなるので、受信機は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、あらゆるRTTがそうするというわけではない8/R_最大ビット/sの増税での上限の間、適用してください。 _損失旗を持ってください。TFMCC送付者が最初のレポートを受け取った後、だけ設定されているのは、このように制限された増税です。
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.Every10'送付者が、データ・パケットを送るのを止めると、現在の送付レートXを記録する'=RTTs、許容送付レートは受信機フィードバックの不足のため半分にされるでしょう、セクション3.3で指定されるように。 この半分には複数の回行われるかもしれません。 '送付者が再開すると、記録されたレートXまでの現在の許容レートからslowstartを実行するかもしれません'。 '受信機のどれかかX'の次第最初のパケット損失に達した後にSlowstartは終わります。
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.
このために受信機がきれいにされなければならない、_損失を10RTTsの後にセクション4.3における指定されるとしてのデータ・パケットなしで.1に旗を揚げさせます。 損失旗がslowstartに使用されるだけである_を持ってください。 したがって、パケットが全くネットワーク仕切りかパケット損失のため到着しなかったなら、旗をきれいにするのは効き目がありません。
3.7. Scheduling of Packet Transmissions
3.7. パケット伝送のスケジューリング
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:
TFMCCがレートベースであり、オペレーティングシステムが通常正確に出来事の計画をすることができないので、送付データ・パケットに関して便宜主義的であるのが必要であるので、オペレーティングシステムの粗粉か不規則なスケジューリングにもかかわらず、適度の平均相場は維持されます。 したがって、典型的な送付輪は以下の通り正しい相互パケット間隔、t_ipiについて計算するでしょう:
Widmer & Handley Experimental [Page 15] RFC 4654 TFMCC: Protocol Specification August 2006
ウィトマーとハンドレー実験的な[15ページ]RFC4654TFMCC: プロトコル仕様2006年8月
ts_ipi = 8s/X
t_ipi=8/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に最初に発信し始めるとき、それは、t_ipiについて計算して、名目上でaについて計算します。t_0+t_時間、t_1=ipiを送ってください、パケット1のために。 アプリケーションがなるときには怠けてください、とそれは_現在現在の時間、tをチェックして、時期変更を要求しました。(次に、後、t_はipiされます--、(_現在のt--t_0)秒。 アプリケーションが_現在時期変更されるとき、それは再び現在の時間、tをチェックします。 (t_現在>t_1--デルタ)その時なら、パケット1を送ります(デルタのために以下を見てください)。
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.
今、名目上でaについて計算するのに計算されているかもしれなくて、使用される新しいt_ipiはパケット2のために時間、t_2を送ります: t_2はt_1+t_ipiと等しいです。 連続したパケットのそれぞれのものがある当時の反復が計算された時間を送る過程は名目上から前のパケットの時間を送ります。 実際が名目上ではなく、私が送る時間t_に時間を送ることに注意して、タイムスタンプとしてパケットのヘッダーに含まれています。
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.
いくつかの場合では、次のパケットのiは計算されて、それはケースがそのt_であったなら既にそうするかもしれません。(その時、名目上は時間、t_を送ります)。現在の>t_i--デルタ。 このような場合には、すぐに、パケットを送るべきです。 伝わってください。そして、その結果、オペレーティングシステムで粗いタイマ粒状があるかどうか、レートが高い、次に、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:
パラメタデルタが中に1段階の柔軟性を許容することになっている、パケットの時間を送ってください。 オペレーティングシステムにt_おばあちゃんの秒のスケジューリングタイマ粒状があるなら、デルタによる以下のことように通常設定されるでしょう。
delta = min(ts_ipi/2, ts_gran/2)
デルタ=分(t_ipi/2、t_おばあちゃん/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.
t_おばあちゃんは多くのUnixシステムの上の10ミリセカンドです。t_おばあちゃんが知られていないなら、安全に10ミリセカンドの値は想定できます。
4. Data Receiver Protocol
4. データ受信装置プロトコル
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.
受信機の機能性の記述では、私たちは、最初に、受信機がどう回路パラメータを測定するかを記述して、次に、フィードバックの過程について議論するつもりです。
Widmer & Handley Experimental [Page 16] RFC 4654 TFMCC: Protocol Specification August 2006
ウィトマーとハンドレー実験的な[16ページ]RFC4654TFMCC: プロトコル仕様2006年8月
4.1. Receiver Initialization
4.1. 受信機初期設定
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.
最初のデータ・パケットを受けるとき、受信機は初期化されます。 RTTはデータ・パケットに含まれた最大のRTT値に用意ができています。 この初期の値は受信機のRTTとして最初の本当のRTT測定をするまで使用されます。 損失イベント率は0に初期化されます。 また、旗の受信機_はいなくなります、そして、_RTTを持ってください、そして、_損失を晴らしてありますか?
4.2. Receiver Leave
4.2. 受信機休暇
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セッションを残すという願望を送る受信機は、_休暇が旗を揚げさせる受信機をレポートにはめ込むことによって、未定の休暇を示すかもしれません。 退出受信機がCLRであるなら、休暇が実施する前に_休暇が旗を揚げさせる受信機はフィードバックラウンドの中のすべてのレポートのためのセットであるべきです。
4.3. Measurement of the Network Conditions
4.3. ネットワーク状態の測定
Receivers have to update their estimate of the network parameters with each new data packet they receive.
受信機は彼らが受けるそれぞれの新しいデータ・パケット単位の彼らの回路パラメータの見積りをアップデートしなければなりません。
4.3.1. Updating the Loss Event Rate
4.3.1. 損失イベント率をアップデートします。
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.
損失出来事が検出されるとき、旗は検出されました。_損失は設定されます。 10連続したRTTsのためにデータ・パケットを全く受け取らないといけないので、旗はslowstartに送付者を許容するためにきれいにされます。 新しいデータ・パケットが到着するとき、それは再び設定されます、そして、損失出来事は検出されます。
4.3.2. Basic Round-Trip Time Measurement
4.3.2. 基本的な往復の時間測定
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_は_現在、=trを抽出します--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_はデータ・パケットが受信機とtr_rに到着する時ですか'はデータ・パケットで反映された受信機レポートタイムスタンプです。 '実際のRTTはタイムスタンプの解決より小さく、tr_は現在、tr_rと等しい'なら、R_サンプルが0(すなわち、私たちの場合における1ミリセカンド)より大きい最も小さい上向きのRTT値に設定されます。
Widmer & Handley Experimental [Page 17] RFC 4654 TFMCC: Protocol Specification August 2006
ウィトマーとハンドレー実験的な[17ページ]RFC4654TFMCC: プロトコル仕様2006年8月
2. The smoothed RTT estimate R is updated:
2. 平坦なRTT見積りRをアップデートします:
If no feedback has been received before
R = R_sample
RがR_サンプルと等しい前にフィードバックを全く受け取っていないなら
Else
R = q*R + (1-q)*R_sample
ほかのR=q*R+(1-q)*R_サンプル
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.
任意に、送付者ベースのRTT測定は受信機ベースのものの代わりに使用されるかもしれません。 送付者は最大のRTTの計算のためにRTTを送付者の自己のタイムスタンプに関する受信機のエコーから受信機に既に決定します。 送付者ベースのRTT測定値のために、このRTT測定は、受信機とコミュニケートする必要があります。受信機のタイムスタンプのエコーを含んでいることの代わりに送付者は次のデータ・パケットで受信機のRTTを入れます、セクション3.5で説明された優先順位づけ規則を使用して。
To simplify sender operation, smoothing of RTT samples as described above should still be done at the receiver.
送付者操作を簡素化するために、まだ上で説明されるとしてのRTTのサンプルのスムージングを受信機にしているべきです。
4.3.3. One-Way Delay Adjustments
4.3.3. 片道遅れ調整
When an RTT measurement is performed, the receiver also determines the one-way delay D_r from itself to the sender:
また、RTT測定が実行されるとき、受信機はそれ自体から送付者まで片道遅れD_rを決定します:
D_r = tr_r' - ts_i
'D_rはtr_rと等しいです'--t_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:
'tの_iとtr_r'がタイムスタンプと受信機であるところでは、データ・パケットに含まれたタイムスタンプエコーを報告してください。 それぞれの新しいデータ・パケットjで、受信機は今、以下としてアップデートされたRTT見積りについて計算できます。
R' = max(D_r + tr_now - ts_j, 1 millisecond)
'R'=最大(_現在のD_r+tr--t_j、1ミリセカンド)
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測定値、アップデートして、Rが'RTTが抽出する平坦なRTT R.Like、Rの代わりに、使用される'という必須は厳密にそうです。積極的。 新しい測定をするとき、すべての当座の片道遅れ測定値が捨てます(当座の片道遅れ調整を考慮に入れないで、セクション4.3.2に従って、すなわち、平坦なRTTをアップデートします)。
Widmer & Handley Experimental [Page 18] RFC 4654 TFMCC: Protocol Specification August 2006
ウィトマーとハンドレー実験的な[18ページ]RFC4654TFMCC: プロトコル仕様2006年8月
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に適用されるべきです。
4.3.4. Receive Rate Measurements
4.3.4. レート測定値を受け取ってください。
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を評価する、レートを受け取ってください。
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.
ビットの数がIPを考慮に入れて、最後のk RTTsの上で受信して、パケットのヘッダーを輸送するとき測定されますが、リンクレイヤパケットのヘッダーを除きながら、ビット/sのレートを受け取ってください。 2と4の間のkのための値はお勧めです。
4.4. Setting the Desired Rate
4.4. 必要なレートを設定します。
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.
受信機が非ゼロ損失イベント率を測定すると、それは、Equation(1)を使用することで必要なレートについて計算します。 どんなRTT測定もまだ利用可能でないといけないので、最大のRTTは受信機のRTTの代わりに使用されます。 損失イベント率かRTTが変化するときはいつも、必要なレートX_rをアップデートします。
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.
以上のように、受信機が最初の損失出来事を経験する前に必要なレートの計算は可能ではありません。 その場合、データが受信されているレートの2倍は、セクション3.6で説明されるようにslowstartに送付者を許容するためにX_rとして受信機レポートに含まれています。 また、送付者が、データ・パケットを送った後を再開するときこれをする、_損失旗は活動していない送付者のためきれいにされましたか?
Widmer & Handley Experimental [Page 19] RFC 4654 TFMCC: Protocol Specification August 2006
ウィトマーとハンドレー実験的な[19ページ]RFC4654TFMCC: プロトコル仕様2006年8月
4.5. Feedback and Feedback Suppression
4.5. フィードバックとフィードバック抑圧
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は他のすべての受信機からフィードバックを1RTTに一度独自に送ります。 フィードバックは、他のフィードバックを抑圧しないで、他の受信機のフィードバックで抑圧できません。
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)
t=最大(T*(1+ログ(x)/ログ(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_は最大限にする)です。
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から1万に、すべての受信機(TFMCCセッションを高々1万台の受信機しか制限しないで)を課するのはお勧めです。
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であるときに、フィードバックは全体のグループへのマルチキャストです。 さもなければ、フィードバックは送付者へのユニキャストです。 フィードバックパケットはフィードバックパケットが送られる時代(フィードバックタイマが設定される時のポイントのレートでない)に有効な計算されたレートを含んでいます。 最後のデータ・パケットのt_私が受け取ったタイムスタンプのコピーは、送付者が正しく瞬時に起こっているRTTを推論するのを許容するためにデータ・パケットを受けて、レポートを送るところの間隔で調整される必要があります(すなわち、その時間間隔はタイムスタンプ値に加えられなければなりません)。(タイムスタンプはフィードバックパケットに含まれています)。
Widmer & Handley Experimental [Page 20] RFC 4654 TFMCC: Protocol Specification August 2006
ウィトマーとハンドレー実験的な[20ページ]RFC4654TFMCC: プロトコル仕様2006年8月
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'
't=t*R_最大/R_最大'
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_がどこに最大限にするかは、新しい最大のRTTとR_最大です'は前の最大のRTTです。 最後のデータ・パケットがR_の時間間隔よりさらに受け取られていたとき、同じ問題保持が最大限にする、前 この場合、相互パケットギャップと最大のRTTの違いをフィードバック内部破裂を防ぐフィードバック時間に加えるのが必要です(例えば、送付者がクラッシュするといけなかったので)。
t = t + max(tr_now - tr_i - R_max, 0)
t=t+最大(_現在のtr--tr_i--R_最大、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]でフィードバック抑圧メカニズムの特性に関するその他の詳細を見つけることができます。
Widmer & Handley Experimental [Page 21] RFC 4654 TFMCC: Protocol Specification August 2006
ウィトマーとハンドレー実験的な[21ページ]RFC4654TFMCC: プロトコル仕様2006年8月
5. Calculation of the Loss Event Rate
5. 損失イベント率の計算
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のために第一に重要です。 損失レート測定は受信機で実行されます、到着パケットの一連番号からの無くなっているか著しいパケットの検出に基づいて。
5.1. Detection of Lost or Marked Packets
5.1. 無くなっているか著しいパケットの検出
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と同じです、そして、それで、TFMCCは再命令の面前でより強健になることになっています。 パケットが遅さに(3つのその後のパケットが到着した後に)受信機に到着するなら、遅いパケットはレセプション記録の穴をふさぐことができます、そして、TCPと対照して、受信機は損失出来事が評定するrecalculateをふさぐことができます。 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.
それの次第混雑出来事が到着するとき、電子証券取引ネットワーク有能な接続において、著しいパケットは検出されます、その後のパケットの到着を待つ必要はなくて。
Widmer & Handley Experimental [Page 22] RFC 4654 TFMCC: Protocol Specification August 2006
ウィトマーとハンドレー実験的な[22ページ]RFC4654TFMCC: プロトコル仕様2006年8月
5.2. Translation from Loss History to Loss Events
5.2. 損失歴史から損失出来事までの翻訳
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と同様です。(TCPはどんな独身のRTTの間も、混雑ウィンドウのある半分にを(通常)実行するだけです)。 したがって、受信機は、損失イベント記録にパケット損失歴史を写像する必要があります。(そこでは、損失出来事が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に、_新しい受信機に到着していて、それがレセプション時間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 be either before or after T_after due to reordering.
缶の前のT_がどちらか_後のTの前または後に再命令のためであることに注意してください。
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, 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.
系列の_以前Sの間で包装されたスペースと後のS_であるなら、計算が実行される前にこれを考慮に入れるように一連番号を変更しなければならないことに注意してください。 可能な限り大きい一連番号が_後の>Sの前のS_最大、およびS_であるなら、通常、Sの=(S+(S_最大+1)/2)モッズ(S_最大+1)で各一連番号Sを変更するのは十分でしょう。
Widmer & Handley Experimental [Page 23] RFC 4654 TFMCC: Protocol Specification August 2006
ウィトマーとハンドレー実験的な[23ページ]RFC4654TFMCC: プロトコル仕様2006年8月
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.
迷子になったパケット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 of 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
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の速度を測定します。 現在指定されるように、8よりかなりすばらしいnの値にTFMCCを使用するべきではありません、TCPと共に世界的なインターネットに参加するかもしれない交通に。 少なくとも、nより多くの8の値がある安全操業は、重いパケット損失に伴う往復の2回以上への、より厳しい応答を含むようにTFMCCのメカニズムへの小変化を必要とするでしょう。
When calculating the average loss interval, we need to decide whether to include the interval since the most recent packet loss event. We only do this if it is sufficiently large to increase the average loss interval.
海損間隔について計算するとき、私たちは、最新のパケット損失出来事以来の間隔を含んでいるかどうか決める必要があります。 海損間隔を増加させるのが十分大きい場合にだけ、私たちはこれをします。
Widmer & Handley Experimental [Page 24] RFC 4654 TFMCC: Protocol Specification August 2006
ウィトマーとハンドレー実験的な[24ページ]RFC4654TFMCC: プロトコル仕様2006年8月
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 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.
セクション5.4で説明されるように、全重量の4/(3*n)は海損間隔について計算する際に最新の損失間隔に割り当てられるだけです、最新の損失間隔のサイズにかかわらず。 このセクションはTFMCC受信機が重りを調整できる任意の歴史値段をひくメカニズムについて説明します、最新の損失間隔に一層の相対重量を集結して。(その時、最新の損失間隔は計算された海損間隔の2倍以上大きいです)。
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:
歴史の値段をひくことを行うために、私たちはそれぞれの損失間隔L_iに割引係数DF_iを関連づけます。そこでは、各割引係数が浮動小数点です。 割り引きアレイはそれぞれの損失間隔の間、値段をひく累積している歴史を維持します。 始めに、割り引きアレイのDF_iの値は1に初期化されます:
for (i = 0 to n) {
DF_i = 1;
}
(0〜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に初期化されます。 まず最初に、私たちは割引係数が海損間隔について計算する際にどう使用されるかを示しています、そして、次に、後でこのセクションで割引係数が時間がたつにつれてどう変更されるかを説明します。
Widmer & Handley Experimental [Page 25] RFC 4654 TFMCC: Protocol Specification August 2006
ウィトマーとハンドレー実験的な[25ページ]RFC4654TFMCC: プロトコル仕様2006年8月
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, a 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_(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_(i-1)*DF_iを加えます; (1〜i=n)に関してはI_幼児=I_幼児+(I_i*w_(i-1)*DF_i)、I_は、= I_幼児/W_が合計を意味します。
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と等しいです。
Widmer & Handley Experimental [Page 26] RFC 4654 TFMCC: Protocol Specification August 2006
ウィトマーとハンドレー実験的な[26ページ]RFC4654TFMCC: プロトコル仕様2006年8月
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 TFMCC to respond more quickly to the sudden absence of congestion, as represented by a long current loss interval.
これは、メカニズムを無視しながら、任意の歴史の記述を終了します。 私たちは、これがTFMCCが、よりすばやく混雑の突然の欠如に応じるのを許容する唯一の目的がことである任意のメカニズムであると強調します、長い当期損失間隔のそばに表されるように。
5.6. Initializing the Loss History after the First Loss Event
5.6. 最初の損失出来事の後に損失歴史を初期化します。
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.
通常、最初の損失出来事が当期損失出来事を反映しない前に受け取られたパケットの数は評価します。 最初の損失出来事が起こると、TFMCC受信機は、正しいデータ信号速度が損失が発生したときデータが最後のRTTの間に受け取られたレートであると仮定します。 最初の損失出来事まで送られたパケットの数に最初の損失間隔を初期化することの代わりにTFMCC受信機が生産するのに必要である損失間隔について計算する、レートX_recvを受けてください。そうすれば、それは、損失歴史メカニズムに種を蒔くためにこの合成の損失間隔l_0を費やします。
The initial loss interval is calculated by inverting a simplified version of the TCP Equation (1).
創業期欠損間隔は、TCP Equation(1)の簡易型のバージョンを逆にすることによって、計算されます。
Widmer & Handley Experimental [Page 27] RFC 4654 TFMCC: Protocol Specification August 2006
ウィトマーとハンドレー実験的な[27ページ]RFC4654TFMCC: プロトコル仕様2006年8月
8s
X_recv = sqrt(3/2) * -----------------
R * sqrt(1/l_0)
8s X_recvはsqrt(3/2)*と等しいです。----------------- R*sqrt(1/l_0)
X_recv * R
==> l_0 = (----------------)^2
sqrt(3/2) * 8s
>l_0=(----------------)^2sqrt(3/2)*X_recv*R=8
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.
より保存している創業期欠損イベント率に通じるより正確なEquation(1)を使用すると比べて、結果として起こる創業期欠損間隔は、より高い損失率が小さ過ぎます。
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_最大を使用しているなら、初期のRTTが実際のRTTより高いといけないので、創業期欠損間隔は大き過ぎます。 結果として、受信機はいつ、最初のRTT測定Rをして、創業期欠損間隔がまだ損失歴史にあるかを高過ぎる必要なレートに見込むでしょう。 受信機は以下のl_0を調整しなければなりません:
l_0 = l_0 * (R/R_max)^2
l_0=l_0*(R/R_は最大限にする)^2
No action needs to be taken when the first RTT measurement is made after the initial loss interval left the loss history.
どんな動作も、創業期欠損間隔が損失歴史を残した後に最初のRTT測定をするとき、取る必要がありません。
6. Security Considerations
6. セキュリティ問題
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.
サービスの否定を作成するのに潜在的に混雑制御機構を利用できます。 これはだまされたフィードバックで起こるかもしれません。 したがって、TFMCCを使用するどんなトランスポート・プロトコルも、フィードバックがデータの有効な受信機から受け入れられるだけであるのを保証するために注意されるべきです。 しかしながら、これを達成する正確なメカニズムはトランスポート・プロトコル自体によるでしょう。
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,
混雑制御機構はそれがネットワーク回線容量の正当な分け前より受信したがっている貪欲な受信機によって潜在的に操作されるかもしれません。 しかしながら、TFMCCでは、受信機は送付レートに影響を及ぼすだけであって、CLRであり、その結果、すべての受信機の最も低い計算されたレートを持つことができます。 計算されたレートがあると、2番目対最も低い受信機の計算されたレートを超えるように操られて、それは、CLRであることをやめるでしょう。 貪欲な受信機はそれがセッションの唯一の関係者である場合にだけ通信速度をかなり増加させることができます。 そのようなシナリオが重要であるなら
Widmer & Handley Experimental [Page 28] RFC 4654 TFMCC: Protocol Specification August 2006
ウィトマーとハンドレー実験的な[28ページ]RFC4654TFMCC: プロトコル仕様2006年8月
possible defenses against such a receiver would normally include some form of nonce that the receiver must feed back to the sender to prove receipt. However, the details of such a nonce would depend on the transport protocol and, in particular, on whether the transport protocol is reliable or unreliable.
通常、そのような受信機に対する可能なディフェンスは受信機が領収書を立証するために送付者にフィードバックしなければならない何らかのフォームの一回だけを含んでいるでしょう。 しかしながら、そのような一回だけの詳細はトランスポート・プロトコルが特にプロトコルであって信頼できるか、または頼り無いかにおける輸送によるでしょう。
It is possible that a receiver sends feedback claiming that it has a very low calculated rate. This will reduce the rate of the multicast session and might render it useless but obviously cannot hurt the network itself.
フィードバックが、受信機でそれには非常に低い計算されたレートがあると主張するのは、可能です。 これは、マルチキャストセッションの速度を低下させて、それを役に立たなくするかもしれませんが、明らかにネットワーク自体に害を与えることができません。
We expect that protocols incorporating ECN with TFMCC will also want to incorporate feedback from the receiver to the sender using the ECN nonce [12]. The ECN nonce is a modification to ECN that protects the sender from the accidental or malicious concealment of marked packets. Again, the details of such a nonce would depend on the transport protocol and are not addressed in this document.
私たちは、また、TFMCCと共に電子証券取引ネットワークを法人組織にするプロトコルが電子証券取引ネットワーク一回だけ[12]を使用することで受信機から送付者までフィードバックを取り入れたくなると予想します。 電子証券取引ネットワーク一回だけは著しいパケットの偶然の、または、悪意がある隠すことから送付者を保護する電子証券取引ネットワークへの変更です。 一方、そのような一回だけの詳細は、トランスポート・プロトコルによって、本書では記述されません。
7. Acknowledgments
7. 承認
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.
方程式についてのフィードバックと議論がさまざまな人々との輻輳制御を基礎づけたと認めたいと思います、Reliable Multicast Research Group、Reliable Multicast Transport作業部会、およびEndから終わりへのResearch Groupのメンバーを含んでいて。 このドキュメントの以前のバージョンのフィードバックについて特にブライアン・アダムソン、マーク・ピューレン、Feiチャオ、およびマグヌスWesterlundに感謝申し上げます。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[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]Whetten、B.、Vicisano、L.、カーモード、R.、ハンドレー、M.、フロイド、S.、およびM.Luby、「多くへの1のための信頼できるマルチキャスト輸送ブロックバルク・データ転送」、RFC3048(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] カーモード、R.、およびL.Vicisanoは「ドキュメントをBlocksとプロトコルInstantiationに造って、Reliable Multicast Transport(RMT)のためにGuidelinesを書きます」、RFC3269、2002年4月。
8.2. Informative References
8.2. 有益な参照
[3] J. Widmer and M. Handley, "Extending Equation-Based Congestion
Control to Multicast Applications", Proc ACM Sigcomm 2001, San
Diego, August 2001.
[3] J.ウィトマーとM.ハンドレー「方程式ベースの輻輳制御をマルチキャストアプリケーションに広げている」Proc ACM Sigcomm2001、サンディエゴ2001年8月。
Widmer & Handley Experimental [Page 29] RFC 4654 TFMCC: Protocol Specification August 2006
ウィトマーとハンドレー実験的な[29ページ]RFC4654TFMCC: プロトコル仕様2006年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] S.フロイド、M.ハンドレー、J.Padhye、およびJ.ウィトマー、「ユニキャストアプリケーションのための方程式ベースの輻輳制御」、Proc ACM SIGCOMM2000、ストックホルム(2000年8月)。
[5] Adamson, B., Bormann, C., Handley, M., and J. Macker,
"Negative-Acknowledgment (NACK)-Oriented Reliable Multicast
(NORM) Building Blocks", RFC 3941, November 2004.
[5] アダムソン、B.、ボルマン、C.、ハンドレー、M.、およびJ.Macker、「否定応答の(ナック)指向の信頼できるマルチキャスト(標準)ブロック」、RFC3941(2004年11月)。
[6] Deering, S., "Host extensions for IP multicasting", STD 5, RFC
1112, August 1989.
[6] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、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.ホルブルック、「マルチキャストのためのチャンネルモデル」、博士号Dissertation、スタンフォード大学、コンピュータサイエンス学部、スタンフォード、カリフォルニア(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] J.Padhye、V.Firoiu、D.Towsley、およびJ.黒瀬、「モデルTCPスループット:」 「Simple ModelとそのEmpirical Validation」、Proc ACM SIGCOMM1998
[9] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP", RFC 3168,
September 2001.
[9]Ramakrishnan、K.、フロイド、S.、およびD.黒、「明白な混雑通知(電子証券取引ネットワーク)のIPへの追加」、RFC3168(2001年9月)。
[10] L. Rizzo, "pgmcc: a TCP-friendly single-rate multicast
congestion control scheme", Proc ACM Sigcomm 2000, Stockholm,
August 2000.
[10] L.リゾー、「以下をpgmccします」。 Proc ACM Sigcomm2000、ストックホルム2000年8月の「TCPに優しい単一賃率マルチキャスト輻輳制御計画。」
[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.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[12] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
Congestion Notification (ECN) Signaling with Nonces", RFC 3540,
June 2003.
[12] スプリング、N.、Wetherall、D.、およびD.イーリー、「一回だけで合図する体力を要している明白な混雑通知(電子証券取引ネットワーク)」、RFC3540、2003年6月。
[13] J. Widmer and T. Fuhrmann, "Extremum Feedback for Very Large
Multicast Groups", Proc NGC 2001, London, November 2001.
[13] J.ウィトマーとT.フールマン、「非常に大きいマルチキャストグループのための極値フィードバック」、Proc NGC2001、ロンドン2001年11月。
Widmer & Handley Experimental [Page 30] RFC 4654 TFMCC: Protocol Specification August 2006
ウィトマーとハンドレー実験的な[30ページ]RFC4654TFMCC: プロトコル仕様2006年8月
Authors' Addresses
作者のアドレス
Joerg Widmer DoCoMo Euro-Labs Landsberger Str. 312, Munich, Germany EMail: widmer@acm.org
ヨルクウィトマーDoCoMoユーロ研究室ランツベルガーStr。 312 ミュンヘン(ドイツ)はメールされます: widmer@acm.org
Mark Handley UCL (University College London) Gower Street, London WC1E 6BT, UK EMail: m.handley@cs.ucl.ac.uk
ハンドレーUCL(ユニバーシティ・カレッジロンドン)がガウアー・ストリート、ロンドンWC1E 6BTイギリスのメールであるとマークしてください: m.handley@cs.ucl.ac.uk
Widmer & Handley Experimental [Page 31] RFC 4654 TFMCC: Protocol Specification August 2006
ウィトマーとハンドレー実験的な[31ページ]RFC4654TFMCC: プロトコル仕様2006年8月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Widmer & Handley Experimental [Page 32]
ウィトマーとハンドレーExperimentalです。[32ページ]
一覧
スポンサーリンク
