Network Working Group S. Floyd
Request for Comments: 4342 ICIR
Category: Standards Track E. Kohler
UCLA
J. Padhye
Microsoft Research
March 2006
Profile for Datagram Congestion Control Protocol (DCCP)
Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document contains the profile for Congestion Control Identifier 3, TCP-Friendly Rate Control (TFRC), in the Datagram Congestion Control Protocol (DCCP). CCID 3 should be used by senders that want a TCP-friendly sending rate, possibly with Explicit Congestion Notification (ECN), while minimizing abrupt rate changes.
この文書では、データグラム輻輳制御プロトコル（DCCP）で、輻輳制御識別子3、TCPフレンドリーレート制御（TFRC）のプロファイルが含まれています。突然のレートの変更を最小限に抑えながら、CCID 3は、おそらく明示的輻輳通知（ECN）と、TCPフレンドリーな送信レートをしたい送信者によって使用されるべきです。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions .....................................................3
3. Usage ...........................................................3
3.1. Relationship with TFRC .....................................4
3.2. Half-Connection Example ....................................4
4. Connection Establishment ........................................5
5. Congestion Control on Data Packets ..............................5
5.1. Response to Idle and Application-Limited Periods ...........7
5.2. Response to Data Dropped and Slow Receiver .................8
5.3. Packet Sizes ...............................................9
6. Acknowledgements ................................................9
6.1. Loss Interval Definition ..................................10
6.1.1. Loss Interval Lengths ..............................12
6.2. Congestion Control on Acknowledgements ....................13
6.3. Acknowledgements of Acknowledgements ......................13
6.4. Determining Quiescence ....................................14
7. Explicit Congestion Notification ...............................14
8. Options and Features ...........................................14
8.1. Window Counter Value ......................................15
8.2. Elapsed Time Options ......................................17
8.3. Receive Rate Option .......................................17
8.4. Send Loss Event Rate Feature ..............................18
8.5. Loss Event Rate Option ....................................18
8.6. Loss Intervals Option .....................................18
8.6.1. Option Details .....................................19
8.6.2. Example ............................................20
9. Verifying Congestion Control Compliance with ECN ...............22
9.1. Verifying the ECN Nonce Echo ..............................22
9.2. Verifying the Reported Loss Intervals and Loss
Event Rate ................................................23
10. Implementation Issues .........................................23
10.1. Timestamp Usage ..........................................23
10.2. Determining Loss Events at the Receiver ..................24
10.3. Sending Feedback Packets .................................25
11. Security Considerations .......................................27
12. IANA Considerations ...........................................28
12.1. Reset Codes ..............................................28
12.2. Option Types .............................................28
12.3. Feature Numbers ..........................................28
13. Thanks ........................................................29
A. Appendix: Possible Future Changes to CCID 3 ....................30
Normative References ..............................................31
Informative References ............................................31
List of Tables
テーブルのリスト
Table 1: DCCP CCID 3 Options ......................................14
Table 2: DCCP CCID 3 Feature Numbers ..............................15
This document contains the profile for Congestion Control Identifier 3, TCP-Friendly Rate Control (TFRC), in the Datagram Congestion Control Protocol (DCCP) [RFC4340]. DCCP uses Congestion Control Identifiers, or CCIDs, to specify the congestion control mechanism in use on a half-connection.
この文書では、データグラム輻輳制御プロトコル（DCCP）[RFC4340]で、輻輳制御識別子3、TCPフレンドリーレート制御（TFRC）のプロファイルが含まれています。 DCCPは、半接続で使用中の輻輳制御機構を指定するには、輻輳制御識別子、またはのCCIDsを使用しています。
TFRC is a receiver-based congestion control mechanism that provides a TCP-friendly sending rate while minimizing the abrupt rate changes characteristic of TCP or of TCP-like congestion control [RFC3448]. The sender's allowed sending rate is set in response to the loss event rate, which is typically reported by the receiver to the sender. See Section 3 for more on application requirements.
TFRCはTCPまたはTCPのような輻輳制御の特性の急激な速度変化[RFC3448]を最小にしながら、TCP向け送信速度を提供し、受信機ベースの輻輳制御機構です。送信者の許可の送信レートは、通常、送信者に受信機によって報告された損失イベント率に応じて設定されています。アプリケーション要件の詳細については、セクション3を参照してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
All multi-byte numerical quantities in CCID 3, such as arguments to options, are transmitted in network byte order (most significant byte first).
そのようなオプションの引数としてCCID 3内のすべてのマルチバイト数量は、ネットワークバイト順（最上位バイト）で送信されます。
A DCCP half-connection consists of the application data sent by one endpoint and the corresponding acknowledgements sent by the other endpoint. The terms "HC-Sender" and "HC-Receiver" denote the endpoints sending application data and acknowledgements, respectively. Since CCIDs apply at the level of half-connections, we abbreviate HC-Sender to "sender" and HC-Receiver to "receiver" in this document. See [RFC4340] for more discussion.
DCCP半接続は、一方のエンドポイントによって送信されたアプリケーションデータ及び他のエンドポイントによって送信され、対応する肯定応答から成ります。用語「HC-送信者」及び「HC-受信機」は、それぞれ、アプリケーションデータおよび肯定応答を送信するエンドポイントを示します。 CCIDsハーフ接続のレベルで適用されますので、私たちは、「送信者」とHC-レシーバこのドキュメントの「受信機」へとHC-送信者を短縮します。より多くの議論のための[RFC4340]を参照してください。
For simplicity, we say that senders send DCCP-Data packets and receivers send DCCP-Ack packets. Both of these categories are meant to include DCCP-DataAck packets.
簡単にするために、我々は、送信者がDCCP - データパケットと受信機がDCCP-ACKパケットを送信する送信することを言います。これらのカテゴリの両方がDCCP-DataAckパケットを含むことを意味します。
The phrases "ECN-marked" and "marked" refer to packets marked ECN Congestion Experienced unless otherwise noted.
パケットを参照してください「と記された」フレーズ「ECN-マーク」とは、特に断りのない限り、経験豊富なECNの輻輳をマーク。
This document uses a number of variables from [RFC3448], including the following:
このドキュメントは、次のような[RFC3448]からの変数の数を使用しています。
o X_recv: The receive rate in bytes per second. See [RFC3448], Section 3.2.2.
O X_recv：秒あたりのバイト数で速度を受け取ります。 [RFC3448]、セクション3.2.2を参照してください。
o s: The packet size in bytes. See [RFC3448], Section 3.1.
O S：バイト単位のパケットサイズ。 [RFC3448]、セクション3.1を参照してください。
o p: The loss event rate. See [RFC3448], Section 3.1.
OのP：損失イベント率。 [RFC3448]、セクション3.1を参照してください。
CCID 3's TFRC congestion control is appropriate for flows that would prefer to minimize abrupt changes in the sending rate, including streaming media applications with small or moderate receiver buffering before playback. TCP-like congestion control, such as that of DCCP's CCID 2 [RFC4341], halves the sending rate in response to each congestion event and thus cannot provide a relatively smooth sending rate.
CCID 3のTFRC輻輳制御は、再生前に小さなまたは中程度の受信バッファリングストリーミングメディアアプリケーションなどの送信レートの急激な変化を、最小限に抑えることを好むだろうフローに適しています。 TCPのような輻輳制御、例えばDCCPのCCID 2 [RFC4341]のものとは、各輻輳イベントに応答して送信レートを半分にし、従って、比較的滑らかな送信速度を提供することができません。
As explained in [RFC3448], Section 1, the penalty of having smoother throughput than TCP while competing fairly for bandwidth with TCP is that the TFRC mechanism in CCID 3 responds slower to changes in available bandwidth than do TCP or TCP-like mechanisms. Thus, CCID 3 should only be used for applications with a requirement for smooth throughput. For applications that simply need to transfer as much data as possible in as short a time as possible, we recommend using TCP-like congestion control, such as CCID 2.
[RFC3448]、セクション1で説明したように、TCPと帯域幅を公平に競争しながら、TCPよりも滑らかなスループットを有するのペナルティは、CCID 3におけるTFRC機構がTCPまたはTCPのようなメカニズムを行うよりも、利用可能な帯域幅の変化に遅く応答することです。従って、CCID 3は、滑らかなスループットの要件を有する用途に使用されるべきです。単純に、できるだけ短い時間でできるだけ多くのデータを転送する必要があるアプリケーションのために、私たちは、このようなCCID 2として、TCPのような輻輳制御を使用することをお勧めします。
CCID 3 should also not be used by applications that change their sending rate by varying the packet size, rather than by varying the rate at which packets are sent. A new CCID will be required for these applications.
CCID 3もなく、パケットが送信されるレートを変えることによって、パケットサイズを変化させることによって、その送信レートを変更するアプリケーションで使用すべきではありません。新しいCCIDは、これらのアプリケーションのために必要となります。
The congestion control mechanisms described here follow the TFRC mechanism standardized by the IETF [RFC3448]. Conforming CCID 3 implementations MAY track updates to the TCP throughput equation directly, as updates are standardized in the IETF, rather than wait for revisions of this document. However, conforming implementations SHOULD wait for explicit updates to CCID 3 before implementing other changes to TFRC congestion control.
ここで説明した輻輳制御メカニズムは、IETF [RFC3448]によって標準化されたTFRCメカニズムに従います。準拠CCID 3の実装は、更新がIETFで標準化されているように、直接TCPスループット方程式への更新を追跡するのではなく、この文書の改訂を待つことができます。しかし、適合実装はTFRCの輻輳制御に他の変更を実装する前に、CCID 3への明示的なアップデートを待つべき。
This example shows the typical progress of a half-connection using CCID 3's TFRC Congestion Control, not including connection initiation and termination. The example is informative, not normative.
この例では、接続開始と終了を含まない、CCID 3のTFRC輻輳制御を使用して、半接続の典型的な進行を示します。例では、規範的、有益ではありません。
1. The sender transmits DCCP-Data packets. Its sending rate is governed by the allowed transmit rate as specified in [RFC3448], Section 3.2. Each DCCP-Data packet has a sequence number and the DCCP header's CCVal field contains the window counter value, which is used by the receiver in determining when multiple losses belong in a single loss event.
1.送信者はDCCP - データパケットを送信します。 [RFC3448]、セクション3.2で指定されるように、その送信レートが許容送信レートによって支配されています。各DCCP - データパケットは、シーケンス番号とDCCPヘッダーのCCValフィールドは、複数の損失が単一損失イベントに属している場合を決定する際に受信機によって使用されるウィンドウのカウンタ値が含まれています。
In the typical case of an ECN-capable half-connection, each DCCP-Data and DCCP-DataAck packet is sent as ECN Capable, with either the ECT(0) or the ECT(1) codepoint set. The use of the ECN Nonce with TFRC is described in Section 9.
ECN-可能な半接続の典型的なケースでは、各DCCP-データとDCCP-DataAckパケットがいずれかECT（0）かECT（1）がセットコードポイントと、ECN可能として送信されます。 TFRCとECNノンスを使用することは、セクション9に記載されています。
2. The receiver sends DCCP-Ack packets acknowledging the data packets at least once per round-trip time, unless the sender is sending at a rate of less than one packet per round-trip time, as indicated by the TFRC specification ([RFC3448], Section 6). Each DCCP-Ack packet uses a sequence number, identifies the most recent packet received from the sender, and includes feedback about the recent loss intervals experienced by the receiver.
2.受信機は、TFRC仕様によって示されるように、送信者は、ラウンドトリップ時間当たり未満のパケットのレートで送信されていない限り、少なくとも一回のラウンドトリップ時間当たりのデータパケットを承認DCCP-ACKパケットを送信する（[RFC3448 ]、 セクション6）。各DCCP-Ackパケットは、シーケンス番号を使用して送信者から受信した最新のパケットを識別し、受信機によって経験最近損失間隔に関するフィードバックを含みます。
3. The sender continues sending DCCP-Data packets as controlled by the allowed transmit rate. Upon receiving DCCP-Ack packets, the sender updates its allowed transmit rate as specified in [RFC3448], Section 4.3. This update is based on a loss event rate calculated by the sender using the receiver's loss intervals feedback. If it prefers, the sender can also use a loss event rate calculated and reported by the receiver.
3.送信者は、許容送信レートによって制御されるようDCCP - データパケットを送信し続けます。 DCCP-ACKパケットを受信すると[RFC3448]で指定されるように、送信者がその許容送信率を更新し、セクション4.3。このアップデートは、受信機の損失間隔のフィードバックを使用して送信者によって算出した損失イベント率に基づいています。それは好む場合は、送信者はまた、受信機によって計算され、報告された損失イベント率を使用することができます。
4. The sender estimates round-trip times and calculates a nofeedback time, as specified in [RFC3448], Section 4.4. If no feedback is received from the receiver in that time (at least four round-trip times), the sender halves its sending rate.
4.送信者の推定往復時間をして、[RFC3448]、セクション4.4で指定されるように、NOFEEDBACK時間を算出します。何のフィードバックは（少なくとも4つのラウンドトリップ時間）その時に受信機から受信されない場合、送信者はその送信レートを半分にします。
The client initiates the connection by using mechanisms described in the DCCP specification [RFC4340]. During or after CCID 3 negotiation, the client and/or server may want to negotiate the values of the Send Ack Vector and Send Loss Event Rate features.
クライアントは、DCCP仕様[RFC4340]で説明されたメカニズムを使用して接続を開始します。 CCID 3ネゴシエーションの間または後に、クライアントおよび/またはサーバが送信のAckベクトルの値を交渉し、ロスイベントレート機能を送信することもできます。
CCID 3 uses the congestion control mechanisms of TFRC [RFC3448]. The following discussion summarizes information from [RFC3448], which should be considered normative except where specifically indicated otherwise.
CCID 3はTFRCの輻輳制御メカニズム[RFC3448]を使用します。以下の議論は、特に他に示される場合を除いて規定考慮すべきである[RFC3448]、からの情報を要約します。
Loss Event Rate
ロスイベントレート
The basic operation of CCID 3 centers around the calculation of a loss event rate: the number of loss events as a fraction of the number of packets transmitted, weighted over the last several loss intervals. This loss event rate, a round-trip time estimate, and the average packet size are plugged into the TCP throughput equation, as specified in [RFC3448], Section 3.1. The result is a fair transmit rate close to what a modern TCP would achieve in the same conditions. CCID 3 senders are limited to this fair rate.
最後のいくつかの損失間隔で重み付けして送信されるパケットの数の割合、などの損失イベントの数：損失イベント率の計算の周りCCID 3つのセンターの基本的な操作。 [RFC3448]で指定されるように、この損失イベント率、ラウンドトリップ時間推定値、および平均パケットサイズは、TCPスループット方程式に差し込まれ、セクション3.1。その結果、現代のTCPは、同じ条件で達成するであろうものに近い公正な転送レートです。 CCID 3の送信者は、このフェアレートに制限されています。
The loss event rate itself is calculated in CCID 3 using recent loss interval lengths reported by the receiver. Loss intervals are precisely defined in Section 6.1. In summary, a loss interval is up to 1 RTT of possibly lost or ECN-marked data packets, followed by an arbitrary number of non-dropped, non-marked data packets. Thus, long loss intervals represent low congestion rates. The CCID 3 Loss
損失イベント率自体は、受信機によって報告された最近の損失間隔の長さを使用して、CCID 3で計算されます。損失間隔は正確に6.1節で定義されています。要約すると、損失間隔は、非ドロップ、非マークされたデータ・パケットの任意の数が続く可能性が紛失またはECN-マークされたデータパケットのRTT、1までです。このように、長い損失間隔は低混雑率を表しています。 CCID 3損失
Intervals option is used to report loss interval lengths; see Section 8.6.
間隔オプションは損失間隔の長さを報告するために使用されます。 8.6節を参照してください。
Other Congestion Control Mechanisms
他の輻輳制御機構
The sender starts in a slow-start phase, roughly doubling its allowed sending rate each round-trip time. The slow-start phase is ended by the receiver's report of a data packet drop or mark, after which the sender uses the loss event rate to calculate its allowed sending rate.
送信者は、おおよそその許可送信率、各ラウンドトリップ時間を倍増、スロースタートフェーズで開始されます。スロースタートフェーズは、送信者がその許可の送信レートを計算するために、損失イベント率を使用した後、データパケットドロップまたはマークの受信者の報告によって終了されます。
[RFC3448], Section 4, specifies an initial sending rate of one packet per round-trip time (RTT) as follows: The sender initializes the allowed sending rate to one packet per second. As soon as a feedback packet is received from the receiver, the sender has a measurement of the round-trip time and then sets the initial allowed sending rate to one packet per RTT. However, while the initial TCP window used to be one segment, [RFC2581] allows an initial TCP window of two segments, and [RFC3390] allows an initial TCP window of three or four segments (up to 4380 bytes). [RFC3390] gives an upper bound on the initial window of min(4*MSS, max(2*MSS, 4380 bytes)).
次のように[RFC3448]、第4節では、ラウンドトリップ時間ごとにパケット（RTT）の初期送信レートを指定：送信者は、毎秒1つのパケット許容送信レートを初期化します。すぐにフィードバックパケットは、受信機から受信されると、送信者は、往復時間の測定を持ち、その後、RTTごとに1つのパケットに初期許可送信レートを設定します。しかし、一つのセグメントであることが使用される初期のTCPウィンドウが、[RFC2581]は二つのセグメントの初期のTCPウィンドウを可能にし、[RFC3390]は3つのまたは4つのセグメント（4380バイトまで）の初期のTCPウィンドウを可能にします。 [RFC3390]は分（4 * MSS、MAX（2 * MSS、4380バイト））の初期ウィンドウの上限を与えます。
Therefore, in contrast to [RFC3448], the initial CCID 3 sending rate is allowed to be at least two packets per RTT, and at most four packets per RTT, depending on the packet size. The initial rate is only allowed to be three or four packets per RTT when, in terms of segment size, that translates to at most 4380 bytes per RTT.
したがって、[RFC3448]とは対照的に、初期CCID 3送信レートはRTTあたり少なくとも二つのパケットが許可されると、RTTあたり最大で4つのパケットは、パケットサイズに応じ。初期速度のみセグメントサイズの点で、それはRTTごとに最大で4380バイトに変換するとき、RTTあたり3つのまたは4つのパケットが許可されます。
The sender's measurement of the round-trip time uses the Elapsed Time and/or Timestamp Echo option contained in feedback packets, as described in Section 8.2. The Elapsed Time option is required, while the Timestamp Echo option is not. The sender maintains an average round-trip time heavily weighted on the most recent measurements.
8.2節で説明したように、ラウンドトリップ時間の送信者の測定には、フィードバックパケットに含まれる経過時間および/またはタイムスタンプエコーオプションを使用しています。タイムスタンプエコーオプションがない間経過時間オプションは、必要とされます。送信者は重く、最新の測定値に加重平均ラウンドトリップ時間を維持します。
Each DCCP-Data packet contains a sequence number. Each DCCP-Data packet also contains a window counter value, as described in Section 8.1. The window counter is generally incremented by one every quarter round-trip time. The receiver uses it as a coarse-grained timestamp to determine when a packet loss should be considered part of an existing loss interval and when it must begin a new loss interval.
各DCCP - データパケットは、シーケンス番号が含まれています。 8.1節で説明したように各DCCP - データパケットはまた、ウインドウカウンタ値を含みます。窓カウンタは一般に、1つの四半期ごとのラウンドトリップ時間ずつインクリメントされます。受信機は、パケット損失が既存の損失間隔とするとき、それは新たな損失間隔を開始しなければならないの一部とみなされるべきであるときを決定するために粗いタイムスタンプとして使用します。
Because TFRC is rate-based instead of window-based, and because feedback packets can be dropped in the network, the sender needs some mechanism for reducing its sending rate in the absence of positive feedback from the receiver. As described in Section 6, the receiver sends feedback packets roughly once per round-trip time. As specified in [RFC3448], Section 4.3, the sender sets a nofeedback
TFRCは、レートベースの代わりに、ウィンドウベースであるため、フィードバックパケットがネットワークにドロップすることができるので、送信側は受信側からの肯定的なフィードバックが存在しない場合に、その送信レートを低減するための何らかのメカニズムが必要です。第6節で説明したように、受信機は、大別回往復時間当たりのフィードバックパケットを送信します。 [RFC3448]、セクション4.3で指定されているように、送信者がNOFEEDBACKを設定し、
timer to at least four round-trip times, or to twice the interval between data packets, whichever is larger. If the sender hasn't received a feedback packet from the receiver when the nofeedback timer expires, then the sender halves its allowed sending rate. The allowed sending rate is never reduced below one packet per 64 seconds. Note that not all acknowledgements are considered feedback packets, since feedback packets must contain valid Loss Intervals, Elapsed Time, and Receive Rate options.
少なくとも4つの往復時間に、またはどちらか大きい方のデータパケットの間に二回の間隔にタイマー。 NOFEEDBACKタイマーが満了したときに、送信者が受信機からのフィードバックパケットを受信していない場合は、送信者は、その許可され、送信レートを半分にします。許可の送信レートは、64秒ごとに1つのパケット未満に低減されることはありません。フィードバックパケットは、経過時間を有効ロス間隔を含み、およびレートのオプションを受信しなければならないためではない、すべての確認応答は、フィードバックパケットとみなされることに注意してください。
If the sender never receives a feedback packet from the receiver, and as a consequence never gets to set the allowed sending rate to one packet per RTT, then the sending rate is left at its initial rate of one packet per second, with the nofeedback timer expiring after two seconds. The allowed sending rate is halved each time the nofeedback timer expires. Thus, if no feedback is received from the receiver, the allowed sending rate is never above one packet per second and is quickly reduced below one packet per second.
送信者はNOFEEDBACKタイマーで、受信機からのフィードバックパケットを受信していない、そしてその結果はRTTごとに1つのパケットに許可される送信レートを設定するために取得することはありませんように、その後、送信レートは毎秒1つのパケットの当初の割合で残っているんならば2秒後に期限切れ。許可される送信レートはNOFEEDBACKタイマーが切れるたびに半分になります。いかなるフィードバックが受信機から受信されない場合したがって、許容送信レートは決して秒ごとにパケットを超えていると迅速毎秒1つのパケット以下に低減されます。
The feedback packets from the receiver contain a Receive Rate option specifying the rate at which data packets arrived at the receiver since the last feedback packet. The allowed sending rate can be at most twice the rate received at the receiver in the last round-trip time. This may be less than the nominal fair rate if, for example, the application is sending less than its fair share.
受信機からのフィードバックパケットは、データパケットが最後のフィードバックパケットので、受信機に到着する速度を指定して受信レートオプションが含まれています。許可される送信レートは、最後のラウンドトリップ時間に受信機で受信し、せいぜい2倍のレートすることができます。例えば、アプリケーションはその公正なシェアよりも少ない送信している場合、これは名目公正率よりも小さくすることができます。
One consequence of the nofeedback timer is that the sender reduces the allowed sending rate when the sender has been idle for a significant period of time. In [RFC3448], Section 4.4, the allowed sending rate is never reduced to fewer than two packets per round-trip time as the result of an idle period. CCID 3 revises this to take into account the larger initial windows allowed by [RFC3390]: the allowed sending rate is never reduced to less than the [RFC3390] initial sending rate as the result of an idle period. If the allowed sending rate is less than the initial sending rate upon entry to the idle period, then it will still be less than the initial sending rate when the idle period is exited. However, if the allowed sending rate is greater than or equal to the initial sending rate upon entry to the idle period, then it should not be reduced below the initial sending rate no matter how long the idle period lasts.
NOFEEDBACKタイマーの1つの結果は、送信者は送信者がかなりの期間アイドル状態になっている許可送信率を減少させることです。 [RFC3448]、セクション4.4で、許容送信レートは、アイドル期間の結果として、ラウンドトリップ時間当たり未満の二つのパケットに低減されることはありません。許可の送信レートは、[RFC3390]未満にまで低減されることはありませんアイドル期間の結果としての割合を送信する初期：CCID 3は、[RFC3390]で許可された大きな初期ウィンドウを考慮に入れて、これを修正します。許可される送信レートがアイドル期間に入ると、初期送信レートよりも小さい場合、それはまだアイドル期間が終了した初期送信レートよりも小さくなります。しかし許さ送信率がより大きいか、アイドル期間に入ると、最初の送信レートに等しい場合、それは関係なく、アイドル期間の持続時間を初期送信レート以下に低減しないべきではありません。
The sender's allowed sending rate is limited to at most twice the receive rate reported by the receiver. Thus, after an application-limited period, the sender can at most double its sending rate from one round-trip time to the next, until it reaches the allowed sending rate determined by the loss event rate.
送信者の許可の送信レートは、受信機によって報告された高々二回受信レートに制限されています。したがって、アプリケーションが制限された期間の後、送信者は、せいぜい、それは損失イベント率によって決まる許可され、送信速度に達するまでのは、1往復時間から次へと送信レート倍増させることができます。
DCCP's Data Dropped option lets a receiver declare that a packet was dropped at the end host before delivery to the application -- for instance, because of corruption or receive buffer overflow. Its Slow Receiver option lets a receiver declare that it is having trouble keeping up with the sender's packets, although nothing has yet been dropped. CCID 3 senders respond to these options as described in [RFC4340], with the following further clarifications.
なぜなら破損の、例えばまたはバッファオーバーフローを受け取る - DCCPのDataオプションは、受信機がパケットをアプリケーションに配信する前に、エンドホストでドロップされたことを宣言することができます下落しました。そのスローレシーバーオプションは、受信機が何もまだドロップされていないものの、それは、トラブルの送信者のパケットに追いついを持っていることを宣言することができます。 CCID 3送信者は、以下のさらなる明確化して、[RFC4340]に記載されているように、これらのオプションに応答します。
o Drop Code 2 ("receive buffer drop"). The allowed sending rate is reduced by one packet per RTT for each packet newly acknowledged as Drop Code 2, except that it is never reduced below one packet per RTT as a result of Drop Code 2.
Oドロップコード2（「バッファのドロップを受け取ります」）。許可の送信レートは、それがドロップコード2の結果として、RTTごとに1つのパケット未満に低減されることはありませんことを除いて、新たにドロップコード2として認めパケットごとにRTTごとに1つのパケットだけ低減されます。
o Adjusting the receive rate X_recv. A CCID 3 sender SHOULD also respond to non-network-congestion events, such as those implied by Data Dropped and Slow Receiver options, by adjusting X_recv, the receive rate reported by the receiver in Receive Rate options (see Section 8.3). The CCID 3 sender's allowed sending rate is limited to at most twice the receive rate reported by the receiver via the "min(..., 2*X_recv)" clause in TFRC's throughput calculations ([RFC3448], Section 4.3). When the sender receives one or more Data Dropped and Slow Receiver options, the sender adjusts X_recv as follows:
O率X_recvを受けるの調整。 CCID 3送信者はまた、そのようなデータによって示唆されるような非ネットワーク輻輳のイベントに応答しなければならX_recv、受信機によって報告された受信率（8.3節を参照）レートのオプションを受信を調整することで、低速レシーバーオプションを落として。 CCID 3送信者の許可の送信レートは、TFRCのスループットの計算における「分（...、2 * X_recv）」条項（[RFC3448]、セクション4.3）を介して受信機によって報告高々二回受ける割合に制限されています。送信者は、1つまたは複数のドロップされるデータとスローレシーバーオプションを受信すると、以下のように、送信者はX_recvを調整します：
1. X_inrecv is equal to the Receive Rate in bytes per second reported by the receiver in the most recent acknowledgement.
1. X_inrecvは、最新の承認における受信機によって報告された秒あたりのバイト数で受信レートに等しいです。
2. X_drop is set to the sending rate upper bound implied by Data Dropped and Slow Receiver options. If the sender receives a Slow Receiver option, which requests that the sender not increase its sending rate for roughly a round-trip time [RFC4340], then X_drop should be set to X_inrecv. Similarly, if the sender receives a Data Dropped option indicating, for example, that three packets were dropped with Drop Code 2, then the upper bound on the sending rate will be decreased by at most three packets per RTT, by the sender setting X_drop to
2. X_dropは上位データでドロップインプライドとスローレシーバーオプションバインド送信レートに設定されています。送信者は送信者がおおよそのラウンドトリップ時間[RFC4340]のためにその送信レートを増加させないことを要求したスローレシーバーオプションを、受信した場合、その後、X_dropはX_inrecvに設定する必要があります。送信者は3つのパケットがドロップコード2を用いて滴下したことを、例えば、指示データドロップオプションを受信した場合、同様に、送信速度で、次に上限はにX_dropを設定する送信者によって、RTTあたり最大で3つのパケットだけ減少されます
max(X_inrecv - 3*s/RTT, min(X_inrecv, s/RTT)).
MAX（X_inrecv - 3 * S / RTT、分（X_inrecv、S / RTT））。
Again, s is the packet size in bytes.
ここでも、Sは、バイト単位のパケットサイズです。
As a result, the next round-trip time's sending rate will be limited to at most 2*(X_drop/2) = X_drop. The effects of the Slow Receiver and Data Dropped options on X_recv will mostly vanish by the round-trip time after that, which is appropriate for this non-network-congestion feedback. This procedure MUST only be used for those Drop Codes not related to corruption (see [RFC4340]). Currently, this is limited to Drop Codes 0, 1, and 2.
その結果、次のラウンドトリップ時間の送信速度は、最大2 *（X_drop / 2）= X_dropに制限されます。 X_recv上の受信機とのデータがドロップされたスローオプションの効果は、主にこの非ネットワーク輻輳のフィードバックのために適切であることの後のラウンドトリップ時間で消えます。この手順は、（[RFC4340]を参照）の破損に関連しないものドロップコードのために使用されなければなりません。現在、これはコード0、1、および2をドロップするように制限されています。
CCID 3 is intended for applications that use a fixed packet size, and that vary their sending rate in packets per second in response to congestion. CCID 3 is not appropriate for applications that require a fixed interval of time between packets and vary their packet size instead of their packet rate in response to congestion. However, some attention might be required for applications using CCID 3 that vary their packet size not in response to congestion, but in response to other application-level requirements.
CCID 3は固定パケットサイズを使用するアプリケーションのために意図され、それは輻輳に応答して第2あたりのパケットでそれらの送信レートを変化させます。 CCID 3は、パケット輻輳に応答して、それらのパケットサイズの代わりに、それらのパケットレートを変えるとの間の時間の一定間隔を必要とする用途には適していません。しかし、いくつかの注意がない混雑に応じて、他のアプリケーション・レベルの要件に応じて、そのパケットのサイズを変えるCCID 3を使用するアプリケーションのために必要となる場合があります。
The packet size s is used in the TCP throughput equation. A CCID 3 implementation MAY calculate s as the segment size averaged over multiple round trip times -- for example, over the most recent four loss intervals, for loss intervals as defined in Section 6.1. Alternately, a CCID 3 implementation MAY use the Maximum Packet Size to derive s. In this case, s is set to the Maximum Segment Size (MSS), the maximum size in bytes for the data segment, not including the default DCCP and IP packet headers. Each packet transmitted then counts as one MSS, regardless of the actual segment size, and the TCP throughput equation can be interpreted as specifying the sending rate in packets per second.
パケットサイズSは、TCPスループット方程式で使用されています。例えば、最新の4回の損失間隔にわたって、損失間隔については、セクション6.1で定義されるよう - セグメントサイズは、複数の往復時間にわたって平均としてCCID 3の実装は、Sを算出してもよいです。代わりに、CCID 3実装がsを導出する最大パケットサイズを使用するかもしれません。この場合、Sは、最大セグメントサイズ（MSS）、デフォルトDCCPとIPパケットヘッダを含まないデータセグメントの最大サイズ（バイト）に設定されています。次いで、送信される各パケットは1 MSSとしてカウントに関係なく、実際のセグメントサイズ、およびTCPスループット方程式の秒あたりのパケットで送信速度を指定するものとして解釈することができます。
CCID 3 implementations MAY check for applications that appear to be manipulating the packet size inappropriately. For example, an application might send small packets for a while, building up a fast rate, then switch to large packets to take advantage of the fast rate. (Preliminary simulations indicate that applications may not be able to increase their overall transfer rates this way, so it is not clear that this manipulation will occur in practice [V03].)
CCID 3の実装が不適切にパケットサイズを操作しているように見えるアプリケーションのためにチェックすること。たとえば、アプリケーションが速い速度を利用するために、大きなパケットに切り替え、その後、速い速度を構築、しばらくの間、小さなパケットを送信することがあります。 （予備的シミュレーションは、アプリケーションがこのよう彼らの全体的な転送速度を向上することができないかもしれないことを示しているので、この操作は練習[V03]に起こるであろうことは明らかではありません。）
The receiver sends a feedback packet to the sender roughly once per round-trip time, if the sender is sending packets that frequently. This rate is determined by the TFRC protocol as specified in [RFC3448], Section 6.
送信者が頻繁にパケットを送信する場合、受信機は、大体一回のラウンドトリップ時間あたりの送信者にフィードバックパケットを送信します。 [RFC3448]、セクション6で指定されるように、このレートは、TFRCプロトコルによって決定されます。
Each feedback packet contains an Acknowledgement Number, which equals the greatest valid sequence number received so far on this connection. ("Greatest" is, of course, measured in circular sequence space.) Each feedback packet also includes at least the following options:
各フィードバックパケットは、この接続上で、これまでに受けた最大の有効なシーケンス番号に等しく承認番号が含まれています。 （「グレイ」は、もちろん、円形の配列空間で測定された）各フィードバックパケットは、少なくとも以下のオプションが含まれます。
1. An Elapsed Time and/or Timestamp Echo option specifying the amount of time elapsed since the arrival at the receiver of the packet whose sequence number appears in the Acknowledgement Number field. These options are described in [RFC4340], Section 13.
1.アン経過時間および/または配列番号確認応答番号フィールドに表示されたパケットの受信機に到着してからの経過時間の量を指定するタイムスタンプエコーオプション。これらのオプションは、[RFC4340]、セクション13に記載されています。
2. A Receive Rate option, defined in Section 8.3, specifying the rate at which data was received since the last DCCP-Ack was sent.
2. A最後のDCCP-ACKが送信されたため、データを受信したレートを指定し、8.3節で定義されたレートオプションを、受信します。
3. A Loss Intervals option, defined in Section 8.6, specifying the most recent loss intervals experienced by the receiver. (The definition of a loss interval is provided below.) From Loss Intervals, the sender can easily calculate the loss event rate p using the procedure described in [RFC3448], Section 5.4.
3.受信機が経験した最も最近の損失間隔を指定して、セクション8.6で定義された損失間隔オプションは、。 （損失間隔の定義は以下に提供されている。）損失間隔から、送信者は容易に、[RFC3448]に記載の手順を使用して、5.4節の損失イベント率pを算出することができます。
Acknowledgements not containing at least these three options are not considered feedback packets.
謝辞は、少なくともこれらの3つのオプションが考慮されていないフィードバックパケットを含みません。
The receiver MAY also include other options concerning the loss event rate, including Loss Event Rate, which gives the loss event rate calculated by the receiver (Section 8.5), and DCCP's generic Ack Vector option, which reports the specific sequence numbers of any lost or marked packets ([RFC4340], Section 11.4). Ack Vector is not required by CCID 3's congestion control mechanisms: the Loss Intervals option provides all the information needed to manage the transmit rate and probabilistically verify receiver feedback. However, Ack Vector may be useful for applications that need to determine exactly which packets were lost. The receiver MAY also include other acknowledgement-related options, such as DCCP's Data Dropped option ([RFC4340], Section 11.7).
受信機はまた、失われたかの特定のシーケンス番号を報告する受信機（セクション8.5）で計算損失イベント率を与える損失イベント率、およびDCCPの汎用のAckベクトルオプション、などの損失イベント率に関する他のオプションを含むことができます。マークされたパケット（[RFC4340]、セクション11.4）。 Ackベクトルは、CCID 3の輻輳制御メカニズムによって必要とされていない：ロス間隔オプションは、送信レートを管理し、確率的に受信機からのフィードバックを検証するために必要なすべての情報を提供します。しかし、ベクタのAckパケットが失われたかを正確に決定する必要があるアプリケーションに有用である可能性があります。受信機はまた、DCCPのデータのような他の肯定応答関連のオプションは、オプション（[RFC4340]、セクション11.7）を滴下含むかもしれません。
If the HC-Receiver is also sending data packets to the HC-Sender, then it MAY piggyback acknowledgement information on those data packets more frequently than TFRC's specified acknowledgement rate allows.
HC-Receiverのも、HC-Senderにデータパケットを送信している場合、それはTFRCの指定承認率が許すよりも頻繁に、それらのデータパケットの送達確認情報を背負うかもしれません。
As described in [RFC3448], Section 5.2, a loss interval begins with a lost or ECN-marked data packet; continues with at most one round-trip time's worth of packets that may or may not be lost or marked; and completes with an arbitrarily long series of non-dropped, non-marked data packets. For example, here is a single loss interval, assuming that sequence numbers increase as you move right:
[RFC3448]、セクション5.2で説明したように、損失間隔が紛失またはECNマーク付きデータ・パケットから始まります。失われたり、マークされてもしなくてもよいか、パケットの最大1つのラウンドトリップ時間の価値を続行します。非落とし、非マークされたデータパケットの任意に長いシリーズで完了します。たとえば、ここにあなたが右に移動ように、そのシーケンス番号の増加を想定し、単一の損失間隔であります：
Lossy Part
<= 1 RTT __________ Lossless Part __________
/ \/ \
*----*--*--*-------------------------------------
^ ^ ^ ^
losses or marks
Note that a loss interval's lossless part might be empty, as in the first interval below:
下記の最初の区間のように、損失間隔のロスレス部分が空であるかもしれないことに注意してください。
Lossy Part Lossy Part
<= 1 RTT <= 1 RTT _____ Lossless Part _____
/ \/ \/ \
*----*--*--***--------*-*---------------------------
^ ^ ^ ^^^ ^ ^
\_ Int. 1 _/\_____________ Interval 2 _____________/
As in [RFC3448], Section 5.2, the length of the lossy part MUST be less than or equal to 1 RTT. CCID 3 uses window counter values, not receive times, to determine whether multiple packets occurred in the same RTT and thus belong to the same loss event; see Section 10.2. A loss interval whose lossy part lasts for more than 1 RTT, or whose lossless part contains a dropped or marked data packet, is invalid.
セクション5.2、[RFC3448]のように、損失性部分の長さは、より少ない又は1 RTTに等しくなければなりません。 CCID 3は、複数のパケットが同一のRTTで発生し、したがって、同一の損失イベントに属するかどうかを決定するために、時間を受信しないウィンドウカウンタ値を使用します。 10.2節を参照してください。その損失のある部分の損失間隔は、そのロスレス一部ドロップまたはマークされたデータパケットが含まれ、無効である以上1 RTT、または継続します。
A missing data packet doesn't begin a new loss interval until NDUPACK packets have been seen after the "hole", where NDUPACK = 3. Thus, up to NDUPACK of the most recent sequence numbers (including the sequence numbers of any holes) might temporarily not be part of any loss interval while the implementation waits to see whether a hole will be filled. See [RFC3448], Section 5.1, and [RFC2581], Section 3.2, for further discussion of NDUPACK.
かもしれないNDUPACKパケットは「穴」の後に見られているまで、欠落したデータパケットは、新たな損失間隔を開始しませんNDUPACK = 3.したがって、最新のシーケンス番号のNDUPACKまで（いずれかの穴のシーケンス番号を含む）ここで、実装は穴が満たされるかどうかを見るために待っている間、一時的に損失間隔の一部ではありません。 NDUPACKのさらなる議論のために、[RFC3448]、セクション5.1、および[RFC2581]、セクション3.2を参照してください。
As specified by [RFC3448], Section 5, all loss intervals except the first begin with a lost or marked data packet, and all loss intervals are as long as possible, subject to the validity constraints above.
[RFC3448]、セクション5で指定されるように、以外のすべての損失間隔は、最初の紛失またはマークされたデータ・パケットで始まり、すべての損失間隔は、可能な限り上記妥当性の制約を受けています。
Lost and ECN-marked non-data packets may occur freely in the lossless part of a loss interval. (Non-data packets consist of those packet types that cannot carry application data; namely, DCCP-Ack, DCCP-Close, DCCP-CloseReq, DCCP-Reset, DCCP-Sync, and DCCP-SyncAck.) In the absence of better information, a receiver MUST conservatively assume that every lost packet was a data packet and thus must occur in some lossy part. DCCP's NDP Count option can help the receiver determine whether a particular packet contained data; see [RFC4340], Section 7.7.
失われたとECN-マーク非データパケットは、損失間隔の可逆部分に自由に起こり得ます。 （非データパケットは、アプリケーションデータを運ぶことができないこれらのパケットタイプから成る;すなわち、DCCP-ACK、DCCP-閉じる、DCCP-CloseReq、DCCP - リセット、DCCP同期、およびDCCP-SyncAck。）より良い情報がない場合、受信機は、保守的に、すべての失われたパケットは、データパケットだったと仮定しなければなりませんので、いくつかの非可逆部分で発生する必要があります。 DCCPのNDPカウントオプションは、受信機は、特定のパケットがデータを含んでいるかどうか判断するのに役立つことができます。 [RFC4340]、セクション7.7を参照してください。
[RFC3448] defines the TFRC congestion control mechanism in terms of a one-way transfer of data, with data packets going from the sender to the receiver and feedback packets going from the receiver back to the sender. However, CCID 3 applies in a context of two half-connections, with DCCP-Data and DCCP-DataAck packets from one half-connection sharing sequence number space with DCCP-Ack packets from the other half-connection. For the purposes of CCID 3 congestion control, loss interval lengths should include data packets and should exclude the acknowledgement packets from the reverse half-connection. However, it is also useful to report the total number of packets in each loss interval (for example, to facilitate ECN Nonce verification).
[RFC3448]は、データパケットが送信者に受信機から行くレシーバーとフィードバックパケットに送信者から行くと、データの一方向転送の点でTFRC輻輳制御機構を定義します。しかし、CCID 3は、他の半接続からDCCP-ACKパケットを有する1つの半接続共有シーケンス番号空間からDCCP-データとDCCP-DataAckパケットと、二つの半接続のコンテキストに適用されます。 CCID 3輻輳制御の目的のために、損失間隔の長さは、データパケットを含まなければならないし、逆半接続から確認応答パケットを除外すべきです。しかし、（例えば、ECNノンスの検証を容易にするために）、各損失間隔でパケットの合計数を報告することが有用です。
CCID 3's Loss Intervals option thus reports three lengths for each loss interval, the lengths of the lossy and lossless parts defined above and a separate data length. First, the lossy and lossless lengths are measured in sequence numbers. Together, they sum to the interval's sequence length, which is the total number of packets the sender transmitted during the interval. This is easily calculated in DCCP as the greatest packet sequence number in the interval minus the greatest packet sequence number in the preceding interval (or, if there is no preceding interval, then the predecessor to the half-connection's initial sequence number). The interval's data length, however, is the number used in TFRC's loss event rate calculation, as defined in [RFC3448], Section 5, and is calculated as follows.
CCID 3の損失間隔オプションは、このように各損失間隔のための3つの長さの、上記で定義された不可逆的可逆部分の長さと、別個のデータ長を報告します。まず、非可逆とロスレス長さはシーケンス番号で測定されています。一緒に、彼らは、送信者が期間中に送信したパケットの合計数である区間のシーケンス長に合計します。これは容易に間隔における最大パケットシーケンス番号マイナス先行区間の最大パケットシーケンス番号（無先行間隔が存在しない場合、または、半接続の初期シーケンス番号に次に前身）としてDCCPで計算されます。間隔のデータ長が、しかしながら、[RFC3448]で定義されるように、第5 TFRCの損失イベント率の計算に使用される番号であり、次のように計算されます。
For all loss intervals except the first, the data length equals the sequence length minus the number of non-data packets the sender transmitted during the loss interval, except that the minimum data length is one packet. In the absence of better information, an endpoint MUST conservatively assume that the loss interval contained only data packets, in which case the data length equals the sequence length. To achieve greater precision, the sender can calculate the exact number of non-data packets in an interval by remembering which sent packets contained data; the receiver can account for received non-data packets by not including them in the data length, and for packets that were not received, it may be able to discriminate between lost data packets and lost non-data packets using DCCP's NDP Count option.
最初以外のすべての損失間隔のために、データ長は、シーケンス長さに等しいマイナス非データの数が最小のデータ長が一つのパケットであることを除いて、損失間隔の間に送信された送信者がパケット。より良い情報がない場合、エンドポイントは、保守的損失間隔はデータ長は、シーケンス長に等しい場合にのみデータパケットを、含んでいることを前提としなければなりません。より高い精度を達成するために、送信側はパケットがデータを含んでいた送信覚えによって間隔で非データパケットの正確な数を計算することができます。受信機がデータ長でそれらを含めないことで、受信しなかったパケットのために受信非データパケットを占めることができ、失われたデータパケットを区別することが可能とDCCPのNDPカウントオプションを使用して、非データパケットを失ったことがあります。
The first loss interval's data length is undefined until the first loss event. [RFC3448], Section 6.3.1 specifies how the first loss interval's data length is calculated once the first loss event has occurred; this calculation uses X_recv, the most recent receive rate, as input. Until this first loss event, the loss event rate is zero, as is the data length reported for the interval in the Loss Intervals option.
最初の損失間隔のデータ長は、最初の損失のイベントまで、未定義です。 [RFC3448]、セクション6.3.1は、最初の損失イベントが発生した後に最初の損失間隔のデータの長さを計算する方法を指定します。この計算は、入力として、X_recv、最新の受信レートを使用しています。損失間隔オプションでの間隔で報告されるデータの長さがあるように、この最初の損失のイベントまでは、損失イベント率は、ゼロです。
The first loss interval's data length might be less than, equal to, or even greater than its sequence length. Any other loss interval's data length must be less than or equal to its sequence length.
最初の損失間隔のデータ長に等しい、より小さい、またはその配列の長さよりも大きいかもしれません。他の損失間隔のデータ長は、その配列の長さ以下でなければなりません。
A sender MAY use the loss event rate or loss interval data lengths as reported by the receiver, or it MAY recalculate loss event rate and/or loss interval data lengths based on receiver feedback and additional information. For example, assume the network drops a DCCP-Ack packet with sequence number 50. The receiver might then report a loss interval beginning at sequence number 50. If the sender determined that this loss interval actually contained no lost or ECN-marked data packets, then it might coalesce the loss interval with the previous loss interval, resulting in a larger allowed transmit rate.
受信機によって報告されているように、送信者は、損失イベント率または損失間隔データ長を使用してもよく、またはそれは、損失イベント率および/または受信機のフィードバックと付加情報に基づいて損失間隔データ長を再計算してもよいです。例えば、ネットワークは、シーケンス番号50とDCCP-Ackパケットをドロップし、送信者がこの損失間隔は実際には失われたか、ECN-マークされたデータパケットが含まれていないと判断した場合、受信機は、その後、シーケンス番号50から始まる損失間隔を報告することがありますと仮定それは、より大きな許容送信率をもたらす、以前の損失間隔の損失間隔を合体するかもしれません。
The rate and timing for generating acknowledgements is determined by the TFRC algorithm ([RFC3448], Section 6). The sending rate for acknowledgements is relatively low -- roughly once per round-trip time -- so there is no need for explicit congestion control on acknowledgements.
肯定応答を生成するための速度及びタイミングは、TFRCアルゴリズム（[RFC3448]、セクション6）によって決定されます。大体一回のラウンドトリップ時間あたり - - 確認応答のための送信レートは比較的低いので、謝辞に明示的輻輳制御のための必要はありません。
TFRC acknowledgements don't generally need to be reliable, so the sender generally need not acknowledge the receiver's acknowledgements. When Ack Vector or Data Dropped is used, however, the sender, DCCP A, MUST occasionally acknowledge the receiver's acknowledgements so that the receiver can free up Ack Vector or Data Dropped state. When both half-connections are active, the necessary acknowledgements will be contained in A's acknowledgements to B's data. If the B-to-A half-connection goes quiescent, however, DCCP A must send an acknowledgement proactively.
TFRC確認応答は、一般的に信頼性がある必要はありませんので、送信者は、一般的に、受信者の承認を認める必要はありません。 Ackベクトルまたはデータが使用されているドロップしたときの受信機がAckでベクトルを解放することができたり、データの状態がドロップされたように、しかし、送信者、DCCP Aは、時折受信者の承認を確認する必要があります。半接続の両方がアクティブである場合、必要な肯定応答は、BのデータにAの確認応答に含まれるであろう。 B-へ半接続が休止状態になった場合、しかし、DCCP Aは積極的に確認応答を送信する必要があります。
Thus, when Ack Vector or Data Dropped is used, an active sender MUST acknowledge the receiver's acknowledgements approximately once per round-trip time, within a factor of two or three, probably by sending a DCCP-DataAck packet. No acknowledgement options are necessary, just the Acknowledgement Number in the DCCP-DataAck header.
したがって、Ackをベクトルまたはデータが使用されているドロップしたとき、アクティブな送信者はおそらくDCCP-DataAckパケットを送信することにより、二、三倍以内で、約一回のラウンドトリップ時間あたりの受信者の承認を確認する必要があります。肯定応答オプションはDCCP-DataAckヘッダ内だけ肯定応答番号、必要ではありません。
The sender MAY choose to acknowledge the receiver's acknowledgements even if they do not contain Ack Vectors or Data Dropped options. For instance, regular acknowledgements can shrink the size of the Loss Intervals option. Unlike Ack Vector and Data Dropped, however, the
送信者は、彼らがAckでのベクトルが含まれていないか、データがオプションを落とした場合でも、受信者の承認を認めることを選ぶかもしれません。例えば、定期的な確認応答は損失間隔オプションのサイズを縮小することができます。 Ackベクトルとデータとは異なり、アイテムドロップ
Loss Intervals option is bounded in size (and receiver state), so acks-of-acks are not required.
ACKSオブのACKが必要とされないので、損失間隔オプションは、サイズ（及び受信状態）に制限されます。
This section describes how a CCID 3 receiver determines that the corresponding sender is not sending any data and therefore has gone quiescent. See [RFC4340], Section 11.1, for general information on quiescence.
このセクションでは、CCID 3受信機は、対応する送信者が任意のデータを送信しないため、静止なったと判断する方法について説明します。静止状態での一般的な情報については、[RFC4340]、セクション11.1を参照してください。
Let T equal the greater of 0.2 seconds and two round-trip times. (A CCID 3 receiver has a rough measure of the round-trip time so that it can pace its acknowledgements.) The receiver detects that the sender has gone quiescent after T seconds have passed without receiving any additional data from the sender.
Tは0.2秒と2往復時間の大きいを等しくしてみましょう。 （それはその確認応答のペースできるように、CCID 3受信機は、ラウンドトリップ時間の目安を持っています。）受信機はT秒が送信者からの追加のデータを受信せずに通過した後に、送信者が静止状態になったことを検知します。
CCID 3 supports Explicit Congestion Notification (ECN) [RFC3168]. In the typical case of an ECN-capable half-connection (where the receiver's ECN Incapable feature is set to zero), the sender will use the ECN Nonce for its data packets, as specified in [RFC4340], Section 12.2. Information about the ECN Nonce MUST be returned by the receiver using the Loss Intervals option, and any Ack Vector options MUST include the ECN Nonce Sum. The sender MAY maintain a table with the ECN nonce sum for each packet and use this information to probabilistically verify the ECN nonce sums returned in Loss Intervals or Ack Vector options. Section 9 describes this further.
CCID 3は、明示的輻輳通知（ECN）[RFC3168]をサポートしています。 （受信者の電子証券取引ネットワークできない機能がゼロに設定されている）ECN-可能な半接続の典型的な場合には、送信者は[RFC4340]で指定されるように、そのデータパケットのECN nonceを使用する、セクション12.2。 ECNナンスに関する情報は損失間隔のオプションを使用して受信機で返さなければならない、そしてどんなのAckベクトルオプションは、ECNのNonce合計を含まなければなりません。送信者は、各パケットのECN一回だけの合計を持つテーブルを維持し、確率的損失間隔またはのAckベクトルオプションで返さECNナンス合計を確認するために、この情報を使用することができます。第9章は、これをさらに説明します。
CCID 3 can make use of DCCP's Ack Vector, Timestamp, Timestamp Echo, and Elapsed Time options, and its Send Ack Vector and ECN Incapable features. In addition, the following CCID-specific options are defined for use with CCID 3.
CCID 3はDCCPのAckをベクトル、タイムスタンプ、タイムスタンプエコー、経過時間オプション、およびその送信のAckベクトルとECNできない機能を利用することができます。加えて、以下のCCID特有のオプションは、CCID 3との使用のために定義されています。
Option DCCP- Section
Type Length Meaning Data? Reference
----- ------ ------- ----- ---------
128-191 Reserved
192 6 Loss Event Rate N 8.5
193 variable Loss Intervals N 8.6
194 6 Receive Rate N 8.3
195-255 Reserved
Table 1: DCCP CCID 3 Options
表1：DCCP CCID 3つのオプション
The "DCCP-Data?" column indicates that all currently defined CCID 3- specific options MUST be ignored when they occur on DCCP-Data packets.
"DCCP-データ？"列には、DCCP - データパケットに発生したときに現在定義されているすべてのCCIDの3-特有のオプションを無視しなければなりませんことを示しています。
The following CCID-specific feature is also defined.
以下のCCID特有の機能も定義されています。
Rec'n Initial Section
Number Meaning Rule Value Req'd Reference
------ ------- ----- ----- ----- ---------
128-191 Reserved
192 Send Loss Event Rate SP 0 N 8.4
193-255 Reserved
Table 2: DCCP CCID 3 Feature Numbers
表2：DCCP CCID 3機能番号
The column meanings are described in [RFC4340], Table 4. "Rec'n Rule" defines the feature's reconciliation rule, where "SP" means server-priority. "Req'd" specifies whether every CCID 3 implementation MUST understand a feature; Send Loss Event Rate is optional, in that it behaves like an extension ([RFC4340], Section 15).
カラムの意味は[RFC4340]に記載され、表4「Rec'nルール」は「SP」は、サーバの優先順位を意味機能のリコンシリエーション・ルールを定義します。 「Req'dは、」すべてのCCID 3実装が機能を理解しなければならないかどうかを指定します。それは拡張子（[RFC4340]、セクション15）のように振る舞うことに送るロスイベントレートは、オプションです。
The data sender stores a 4-bit window counter value in the DCCP generic header's CCVal field on every data packet it sends. This value is set to 0 at the beginning of the transmission and generally increased by 1 every quarter of a round-trip time, as described in [RFC3448], Section 3.2.1. Window counters use circular arithmetic modulo 16 for all operations, including comparisons; see [RFC4340], Section 3.1, for more information on circular arithmetic. For reference, the DCCP generic header is as follows. (The diagram is repeated from [RFC4340], Section 5.1, which also shows the generic header with a 24-bit Sequence Number field.)
データ送信元の店舗は、送信するすべてのデータパケットのDCCPジェネリックヘッダーのCCValフィールド内の4ビットのウィンドウカウンタ値。この値は、送信の開始時に0に設定され、一般に1往復時間の四半期ごとに増加し、[RFC3448]に記載されているように、セクション3.2.1れます。ウインドウカウンタは比較を含むすべての操作のための円形の算術モジュロ16を使用します。円形の演算の詳細については、[RFC4340]、セクション3.1を参照してください。参考のために、DCCPジェネリックヘッダは以下の通りです。 （図は、24ビットのシーケンス番号フィールドを有するジェネリックヘッダを示している[RFC4340]、セクション5.1、から繰り返されます。）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Dest Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Offset | CCVal | CsCov | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Type |1| Reserved | Sequence Number (high bits) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Sequence Number (low bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CCVal field has enough space to express 4 round-trip times at quarter-RTT granularity. The sender MUST avoid wrapping CCVal on adjacent packets, as might happen, for example, if two data-carrying packets were sent 4 round-trip times apart with no packets intervening. Therefore, the sender SHOULD use the following algorithm for setting CCVal. The algorithm uses three variables: "last_WC" holds the last window counter value sent, "last_WC_time" is the time at which the first packet with window counter value "last_WC" was sent, and "RTT" is the current round-trip time estimate. last_WC is initialized to zero, and last_WC_time to the time of the first packet sent. Before sending a new packet, proceed like this:
CCValフィールドは、4分の1 RTTの粒度で4往復時間を表現するのに十分なスペースがあります。送信者は、2つのデータを運ぶパケットが介在なしパケットを離れて4往復時間を送った場合、例えば、起こるかもしれないとして、隣接するパケットにCCValを包む避けなければなりません。したがって、送信者はCCValを設定するための以下のアルゴリズムを使用すべきです。このアルゴリズムは、三つの変数を使用しています：「last_WCは、」ウィンドウカウンタ値「last_WC」との最初のパケットが送信された時間があり、「last_WC_time」最後に送信されたウィンドウのカウンタ値を保持し、「RTTは、」現在のラウンドトリップ時間の推定値であります。 last_WCは、送信された最初のパケットの時にゼロに初期化し、last_WC_timeされます。新しいパケットを送信する前に、次のように進みます。
Let quarter_RTTs = floor((current_time - last_WC_time) / (RTT/4)). If quarter_RTTs > 0, then: Set last_WC := (last_WC + min(quarter_RTTs, 5)) mod 16. Set last_WC_time := current_time. Set the packet header's CCVal field to last_WC.
quarter_RTTs =床（ - last_WC_time）/（RTT / 4）（CURRENT_TIME）をしてみましょう。セットlast_WC：=（last_WC +分（quarter_RTTs、5））MOD 16セットlast_WC_time：= CURRENT_TIME quarter_RTTs> 0の場合、もし。 last_WCにパケットヘッダのCCValフィールドを設定します。
When this algorithm is used, adjacent data-carrying packets' CCVal counters never differ by more than five, modulo 16.
このアルゴリズムを使用する場合、隣接するデータ伝送パケットのCCValカウンタは、以上の5、モジュロ16によって異なることはありません。
The window counter value may also change as feedback packets arrive. In particular, after receiving an acknowledgement for a packet sent with window counter WC, the sender SHOULD increase its window counter, if necessary, so that subsequent packets have window counter value at least (WC + 4) mod 16.
フィードバックパケットが到着するようにウィンドウカウンタ値も変更してもよいです。必要に応じて後続のパケットは、少なくとも（WC + 4）ウィンドウカウンタ値を有するように、特に、ウインドウカウンタWCで送信されたパケットに対する肯定応答を受信した後、送信者は、そのウィンドウカウンタを増やす必要があり、MOD 16。
The CCVal counters are used by the receiver to determine whether multiple losses belong to a single loss event, to determine the interval to use for calculating the receive rate, and to determine when to send feedback packets. None of these procedures require the receiver to maintain an explicit estimate of the round-trip time. However, implementors who wish to keep such an RTT estimate may do so using CCVal. Let T(I) be the arrival time of the earliest valid received packet with CCVal = I. (Of course, when the window counter value wraps around to the same value mod 16, we must recalculate T(I).) Let D = 2, 3, or 4 and say that T(K) and T(K+D) both exist (packets were received with window counters K and K+D). Then the value (T(K+D) - T(K)) * 4/D MAY serve as an estimate of the round-trip time. Values of D = 4 SHOULD be preferred for RTT estimation. Concretely, say that the following packets arrived:
CCValカウンタは受信速度を計算するために使用する間隔を決定するために、フィードバックパケットを送信するタイミングを決定するために、複数の損失が単一損失イベントに属するかどうかを決定するために受信機によって使用されます。これらの手順のいずれも往復時間の明示的な推定値を維持するために受信機を必要としません。しかし、そのようなRTT推定値を保持したい実装はCCValを使用してそれを行うことができます。 = T（I）はCCVal = I.（もちろん、窓のカウンタ値が同じ値のmod 16にラップアラウンドするとき、我々はT（I）を再計算する必要があります。）してみましょうDで最も早い有効受信したパケットの到着時刻とします2、3、または4とは、T（K）及びT（K + D）の両方が、（パケットがウィンドウで受信されたKとK + Dカウンタ）が存在することを言います。次いで、値（T（K + D） - T（K））* 4 / D往復時間の推定値として機能することができます。 D = 4の値は、RTT推定のために好まれるべきです。具体的には、次のパケットが到着したことを言います：
Time: T1 T2 T3 T4 T5 T6 T7 T8 T9
------*---*---*-*----*------------*---*----*--*---->
CCVal: K-1 K-1 K K K+1 K+3 K+4 K+3 K+4
Then T7 - T3, the difference between the receive times of the first packet received with window counter K+4 and the first packet received with window counter K, is a reasonable round-trip time estimate. Because of the necessary constraint that measurements only come from packet pairs whose CCVals differ by at most 4, this procedure does not work when the inter-packet sending times are significantly greater than the RTT, resulting in packet pairs whose CCVals differ by 5. Explicit RTT measurement techniques, such as Timestamp and Timestamp Echo, should be used in that case.
次いで、T7 - T3、ウィンドウカウンタK + 4と窓カウンタKで受信した最初のパケットで受信した最初のパケットの受信時間の差は、合理的なラウンドトリップ時間推定値です。インターパケット送信時間は、そのCCVals明示5によって異なるパケットペアで、その結果、RTTよりも著しく大きい場合ため測定が唯一そのCCValsせいぜい4だけ異なるパケットペアから来る必要な制約のため、この手順が機能しませんこのようなタイムスタンプ及びタイムスタンプエコーとしてRTT測定技術は、その場合に使用されるべきです。
The data receiver MUST include an elapsed time value on every required acknowledgement. This helps the sender distinguish between network round-trip time, which it must include in its rate equations, and delay at the receiver due to TFRC's infrequent acknowledgement rate, which it need not include. The receiver MUST at least include an Elapsed Time option on every feedback packet, but if at least one recent data packet (i.e., a packet received after the previous DCCP-Ack was sent) included a Timestamp option, then the receiver SHOULD include the corresponding Timestamp Echo option, with Elapsed Time value, as well. All of these option types are defined in the main DCCP specification [RFC4340].
データ受信機は、すべての必要な肯定応答に経過時間の値を含まなければなりません。これは、送信者が原因それは含める必要はありませんTFRCの不定期承認率、受信機でのネットワークの往復がその速度式に含める必要があり、時間、および遅延を区別するのに役立ちます。受信機は、少なくとも、すべてのフィードバックパケットの経過時間オプションを含まなければならないが、少なくとも一つの最近のデータパケットは（つまりは、前のDCCP-Ackの後に受信したパケットが送信された）タイムスタンプオプションが含まれている場合、受信機は対応を含むべきですタイムスタンプエコー経過時間の値を持つオプション、だけでなく。これらのオプションの種類はすべて、メインDCCP仕様[RFC4340]で定義されています。
+--------+--------+--------+--------+--------+--------+
|11000010|00000110| Receive Rate |
+--------+--------+--------+--------+--------+--------+
Type=194 Len=6
This option MUST be sent by the data receiver on all required acknowledgements. Its four data bytes indicate the rate at which the receiver has received data since it last sent an acknowledgement, in bytes per second. To calculate this receive rate, the receiver sets t to the larger of the estimated round-trip time and the time since the last Receive Rate option was sent. (Received data packets' window counters can be used to produce a suitable RTT estimate, as described in Section 8.1.) The receive rate then equals the number of data bytes received in the most recent t seconds, divided by t.
このオプションは、すべての必要な確認応答でデータ受信機によって送らなければなりません。その4つのデータ・バイトは、それが最後の秒あたりのバイト数で、肯定応答を送信するので、受信機がデータを受信した速度を示します。この受信率を計算するために、受信機は、推定往復時間の大きい方と最後の受信レートオプションが送信された以降の時間にTを設定します。 （8.1節で説明したように受信されたデータ・パケットのウィンドウカウンタは、適切なRTTの推定値を生成するために使用することができる。）受信速度は、データの個数をtで割った、最新のt秒で受信したバイト数に等しいです。
Receive Rate options MUST NOT be sent on DCCP-Data packets, and any Receive Rate options on received DCCP-Data packets MUST be ignored.
受信レートオプションはDCCP - データパケットに送ってはいけませんし、任意のものを無視しなければなりません受信DCCP - データパケットのレートオプションを受け取ります。
The Send Loss Event Rate feature lets CCID 3 endpoints negotiate whether the receiver MUST provide Loss Event Rate options on its acknowledgements. DCCP A sends a "Change R(Send Loss Event Rate, 1)" option to ask DCCP B to send Loss Event Rate options as part of its acknowledgement traffic.
送信ロスイベントレート機能は、CCID 3つのエンドポイントは、受信機がその確認応答のロスイベント料金のオプションを提供しなければならないかどうかを交渉することができます。 DCCP Aは、その確認応答トラフィックの一部としてロスイベントレートのオプションを送信するためにDCCP Bに頼むために「変化Rは、（損失イベントレートを送る、1）」オプションを送ります。
Send Loss Event Rate has feature number 192 and is server-priority. It takes one-byte Boolean values. DCCP B MUST send Loss Event Rate options on its acknowledgements when Send Loss Event Rate/B is one, although it MAY send Loss Event Rate options even when Send Loss Event Rate/B is zero. Values of two or more are reserved. A CCID 3 half-connection starts with Send Loss Event Rate equal to zero.
ロスイベントレートは、機能番号192を持っており、サーバーの優先順位で送信します。これは、1バイトのブール値をとります。送信ロスイベントレート/ Bがゼロのときでも、それはロスイベントレートオプションを送るかもしれないが送るロスイベントレート/ Bは、1であるとき、DCCP Bは、その確認応答のロスイベントレートオプションを送らなければなりません。二つ以上の値が予約されています。 CCID 3半接続はゼロに等しい送信ロスイベントレートから始まります。
+--------+--------+--------+--------+--------+--------+
|11000000|00000110| Loss Event Rate |
+--------+--------+--------+--------+--------+--------+
Type=192 Len=6
The option value indicates the inverse of the loss event rate, rounded UP, as calculated by the receiver. Its units are data packets per loss interval. Thus, if the Loss Event Rate option value is 100, then the loss event rate is 0.01 loss events per data packet (and the average loss interval contains 100 data packets). When each loss event has exactly one data packet loss, the loss event rate is the same as the data packet drop rate.
オプションの値は、受信機によって計算され、切り上げ、損失イベント率の逆数を示します。その単位は損失間隔あたりのデータパケットです。したがって、ロスイベントレートオプション値が100の場合、その後、損失イベント率はデータパケットあたり0.01損失イベントである（と平均損失間隔は100個のデータパケットを含みます）。各損失事象が正確に一つのデータ・パケット損失を有する場合、損失イベント率は、データパケットドロップレートと同じです。
See [RFC3448], Section 5, for a normative calculation of loss event rate. Before any losses have occurred, when the loss event rate is zero, the Loss Event Rate option value is set to "11111111111111111111111111111111" in binary (or, equivalently, to 2^32 - 1). The loss event rate calculation uses loss interval data lengths, as defined in Section 6.1.1.
損失イベント率の規範的な計算のために、[RFC3448]、セクション5を参照してください。いかなる損失が発生した前に、損失イベント率がゼロの場合、損失イベント・レート・オプションの値は、バイナリ（ - 1または、同等に、2 ^ 32）に「11111111111111111111111111111111」に設定されています。セクション6.1.1で定義されるように損失イベント率の計算は、損失間隔データ長を使用します。
Loss Event Rate options MUST NOT be sent on DCCP-Data packets, and any Loss Event Rate options on received DCCP-Data packets MUST be ignored.
ロスイベントレートオプションはDCCP - データパケットに送ってはいけませんし、受信したDCCP - データパケットの損失イベント・レート・オプションは無視しなければなりません。
+--------+--------+--------+--------...--------+--------+---
|11000001| Length | Skip | Loss Interval | More Loss
| | | Length | | Intervals...
+--------+--------+--------+--------...--------+--------+---
Type=193 9 bytes
Each 9-byte Loss Interval contains three fields, as follows:
以下のように各9バイトの損失間隔は、3つのフィールドが含まれています。
____________________ Loss Interval _____________________
/ \
+--------...-------+--------...--------+--------...--------+
| Lossless Length |E| Loss Length | Data Length |
+--------...-------+--------...--------+--------...--------+
3 bytes 3 bytes 3 bytes
The receiver reports its observed loss intervals using a Loss Intervals option. Section 6.1 defines loss intervals. This option MUST be sent by the data receiver on all required acknowledgements. The option reports up to 28 loss intervals seen by the receiver, although TFRC currently uses at most the latest 9 of these. This lets the sender calculate a loss event rate and probabilistically verify the receiver's ECN Nonce Echo.
受信機は、損失間隔のオプションを使用して、その観測された損失間隔を報告します。 6.1節では損失間隔を定義します。このオプションは、すべての必要な確認応答でデータ受信機によって送らなければなりません。 TFRCは現在、最大でこれらの最新の9を使用していますが、オプションでは、受信機によって見られる28回の損失間隔にまで報告しています。これは、送信者が損失イベント率を計算し、確率的に受信者の電子証券取引ネットワークのNonceエコーを確認することができます。
The Loss Intervals option serves several purposes.
損失間隔オプションは、いくつかの目的を果たします。
o The sender can use the Loss Intervals option to calculate the loss event rate.
O送信者は、損失イベント率を計算するために損失間隔のオプションを使用することができます。
o Loss Intervals information is easily checked for consistency against previous Loss Intervals options, and against any Loss Event Rate calculated by the receiver.
O損失間隔情報を簡単に以前の損失間隔のオプションに対する整合性がチェックされ、受信機によって計算された損失イベントレートに対して。
o The sender can probabilistically verify the ECN Nonce Echo for each Loss Interval, reducing the likelihood of misbehavior.
O送信者は確率的不正行為の可能性を低減する、各損失間隔のECNノンスエコーを検証することができます。
Loss Intervals options MUST NOT be sent on DCCP-Data packets, and any Loss Intervals options on received DCCP-Data packets MUST be ignored.
損失間隔オプションはDCCP - データパケットに送ってはいけませんし、受信したDCCP - データパケットの損失間隔のオプションを無視しなければなりません。
The Loss Intervals option contains information about one to 28 consecutive loss intervals, always including the most recent loss interval. Intervals are listed in reverse chronological order. Should more than 28 loss intervals need to be reported, then multiple Loss Intervals options can be sent; the second option begins where the first left off, and so forth. The options MUST contain information about at least the most recent NINTERVAL + 1 = 9 loss intervals unless (1) there have not yet been NINTERVAL + 1 loss intervals, or (2) the receiver knows, because of the sender's acknowledgements, that some previously transmitted loss interval information has been received. In this second case, the receiver need not send loss intervals that the sender already knows about, except that it MUST transmit at least one loss interval regardless.
損失間隔オプションは、常に最新のロス間隔を含む28点の連続した損失間隔、1つの情報が含まれています。間隔が新しい順にリストされています。 28の以上の損失間隔は、複数の損失間隔のオプションを送信することができ、報告する必要がある必要があります。最初は、などやめて、どこ番目のオプションが開始されます。 （1）まだNINTERVAL + 1の損失間隔が行われていない、または（2）受信機が知っている、なぜなら、送信者の確認応答を、あらかじめいくつかのことをしない限り、オプションは+ 1 = 9損失間隔少なくとも最新のNINTERVALについての情報を含まなければなりません送信損失間隔情報が受信されています。この第二のケースでは、受信機は、それが区間にかかわらず、少なくとも一つの損失を送信しなければならないことを除いて、送信者がすでに知っていることの損失間隔を送信する必要はありません。
The NINTERVAL parameter is equal to "n" as defined in [RFC3448], Section 5.4.
[RFC3448]で定義されるようNINTERVALパラメータは、セクション5.4「N」に等しいです。
Loss interval sequence numbers are delta encoded starting from the Acknowledgement Number. Therefore, Loss Intervals options MUST NOT be sent on packets without an Acknowledgement Number, and any Loss Intervals options received on such packets MUST be ignored.
損失間隔のシーケンス番号が確認応答番号から始まるエンコードされたデルタです。そのため、損失間隔のオプションは、承認番号なしのパケットに送ってはいけませんし、そのようなパケットで受信したすべての損失間隔のオプションを無視しなければなりません。
The first byte of option data is Skip Length, which indicates the number of packets up to and including the Acknowledgement Number that are not part of any Loss Interval. As discussed above, Skip Length must be less than or equal to NDUPACK = 3. In a packet containing multiple Loss Intervals options, the Skip Lengths of the second and subsequent options MUST equal zero; such options with nonzero Skip Lengths MUST be ignored.
オプションデータの最初のバイトは、パケットの数まで、あらゆる損失間隔の一部ではない承認番号を含むことを示すスキップの長さ、です。上述したように、複数の損失間隔オプションを含むパケット内NDUPACK = 3以下でなければならない長さをスキップ、ゼロに等しくなければならない目以降のオプションのスキップ長。ゼロ以外のスキップ長さのようなオプションを無視しなければなりません。
Loss Interval structures follow Skip Length. Each Loss Interval consists of a Lossless Length, a Loss Length, an ECN Nonce Echo (E), and a Data Length.
損失間隔構造は、長さをスキップ従ってください。間隔は、ロスレスの長さで構成され、各損失、損失長、ECNのNonceエコー（E）、およびデータ長。
Lossless Length, a 24-bit number, specifies the number of packets in the loss interval's lossless part. Note again that this part may contain lost or marked non-data packets.
ロスレス長、24ビットの数は、損失間隔のロスレス部分のパケット数を指定します。この部分は、非データ・パケットを紛失したり、マーク含有することができることに再び注意してください。
Loss Length, a 23-bit number, specifies the number of packets in the loss interval's lossy part. The sum of the Lossless Length and the Loss Length equals the loss interval's sequence length. Receivers SHOULD report the minimum valid Loss Length for each loss interval, making the first and last sequence numbers in each lossy part correspond to lost or marked data packets.
損失長、23ビットの数は、損失間隔の非可逆部分のパケット数を指定します。ロスレス長と損失長の合計は損失間隔の配列の長さに等しいです。レシーバは、各非可逆部分の最初と最後のシーケンス番号が失われたり、マークされたデータパケットに対応させ、それぞれの損失間隔のための有効な最小損失長を報告する必要があります。
The ECN Nonce Echo, stored in the high-order bit of the 3-byte field containing Loss Length, equals the one-bit sum (exclusive-or, or parity) of data packet nonces received over the loss interval's lossless part (which is Lossless Length packets long). If Lossless Length is 0, the receiver is ECN Incapable, or the Lossless Length contained no data packets, then the ECN Nonce Echo MUST be reported as 0. Note that any ECN nonces on received non-data packets MUST NOT contribute to the ECN Nonce Echo.
損失間隔の可逆部を介して受信したデータパケットナンスの損失長を含む3バイトのフィールドの上位ビットに格納されているECNノンスエコー、1ビットの和（排他的論理和、またはパリティ）に等しい（あります長いロスレス長パケット）。ロスレスの長さが0である場合、受信機はできないECNである、または可逆の長さがデータ・パケットを含まない場合、ECNノンスエコーが受信非データパケット上の任意のECNのナンスがECNノンスに寄与しなければならないこと0注意として報告しなければなりませんエコー。
Finally, Data Length, a 24-bit number, specifies the loss interval's data length, as defined in Section 6.1.1.
セクション6.1.1で定義されるように、最終的に、データ長が24ビットの数は、損失間隔のデータ長を指定します。
Consider the following sequence of packets, where "-" represents a safely delivered packet and "*" represents a lost or marked packet.
場合は、パケットの次のシーケンスを考えてみましょう「 - 」安全にお届けパケットを表し、「*」紛失またはマークされたパケットを表しています。
Sequence
Numbers: 0 10 20 30 40 44
| | | | | |
----------*--------***-*--------*----------*-
Assuming that packet 43 was lost, not marked, this sequence might be divided into loss intervals as follows:
次のようにパケット43がマークされていない、失われたと仮定すると、このシーケンスは損失間隔に分割されることがあります。
0 10 20 30 40 44
| | | | | |
----------*--------***-*--------*----------*-
\________/\_______/\___________/\_________/
L0 L1 L2 L3
A Loss Intervals option sent on a packet with Acknowledgement Number 44 to acknowledge this set of loss intervals might contain the bytes 193,39,2, 0,0,10, 128,0,1, 0,0,10, 0,0,8, 0,0,5, 0,0,10, 0,0,8, 0,0,1, 0,0,8, 0,0,10, 128,0,0, 0,0,15. This option is interpreted as follows.
謝辞ナンバー44のパケットで送信された損失間隔オプションは、0,0バイト193,39,2、0,0,10、128,0,1、0,0,10が含まれている可能性がある損失間隔のこのセットを確認します、8、0,0,5、0,0,10、0,0,8、0,0,1、0,0,8、0,0,10、128,0,0、0,0,15 。このオプションは次のように解釈されます。
193 The Loss Intervals option number.
193のロス間隔オプション番号。
39 The length of the option, including option type and length bytes. This option contains information about (39 - 3)/9 = 4 loss intervals.
オプションのタイプと長さバイトを含む39オプションの長さ。 / 9 = 4損失間隔 - このオプションは、（3 39）に関する情報を含んでいます。
2 The Skip Length is 2 packets. Thus, the most recent loss interval, L3, ends immediately before sequence number 44 - 2 + 1 = 43.
2スキップの長さは2つのパケットです。 2 + 1 = 43 - このように、最新の損失間隔L3は、配列番号44の直前に終了します。
0,0,10, 128,0,1, 0,0,10 These bytes define L3. L3 consists of a 10-packet lossless part (0,0,10), preceded by a 1-packet lossy part. Continuing to subtract, the lossless part begins with sequence number 43 - 10 = 33, and the lossy part begins with sequence number 33 - 1 = 32. The ECN Nonce Echo for the lossless part (namely, packets 33 through 42, inclusive) equals 1. The interval's data length is 10, so the receiver believes that the interval contained exactly one non-data packet.
0,0,10、128,0,1、0,0,10これらのバイトは、L3を定義します。 L3は、1パケット損失のある部分が先行10パケット可逆部（0,0,10）からなります。減算し続け、可逆部は、シーケンス番号43から始まる - 10 = 33、及び非可逆部33は、シーケンス番号で始まる - 1 = 32、可逆部（すなわち、パケット33〜42、包括的）のためにECNノンスエコーに等しいです1.間隔のデータ長が10であるので、受信機は、間隔は正確に一つの非データパケットを含んでいたと考えています。
0,0,8, 0,0,5, 0,0,10 This defines L2, whose lossless part begins with sequence number 32 - 8 = 24; whose lossy part begins with sequence number 24 - 5 = 19; whose ECN Nonce Echo (for packets [24,31]) equals 0; and whose data length is 10.
0,0,8、0,0,5、0,0,10これはロスレス部分シーケンス番号32から始まるL2、定義 - 8 = 24。その損失のある部分は、配列番号24で始まる - 5 = 19。そのECNノンスエコー（パケットの[24,31]）が0に等しいです。そして、そのデータ長が10です。
0,0,8, 0,0,1, 0,0,8 L1's lossless part begins with sequence number 11, its lossy part begins with sequence number 10, its ECN Nonce Echo (for packets [11,18]) equals 0, and its data length is 8.
0,0,8、0,0,1、0,0,8 L1の可逆部分は配列番号11で始まり、その損失のある部分は、配列番号10、そのECNノンスエコー（パケットの[11,18]）で始まり、0に等しいです、そのデータ長は8です。
0,0,10, 128,0,0, 0,0,15 L0's lossless part begins with sequence number 0, it has no lossy part, its ECN Nonce Echo (for packets [0,9]) equals 1, and its data length is 15. (This must be the first loss interval in the connection; otherwise, a data length greater than the sequence length would be invalid.)
0,0,10、128,0,0、0,0,15 L0の可逆部分がシーケンス番号0で始まる、そのECNノンスエコー（パケットの[0,9]）が1に等しく、いかなる非可逆部を有していない、そのデータ長は（これは接続の最初の損失間隔でなければならず、シーケンスの長さが無効であろうよりもそれ以外の場合は、データ長以上である。）15です。
The sender can use Loss Intervals options' ECN Nonce Echoes (and possibly any Ack Vectors' ECN Nonce Echoes) to probabilistically verify that the receiver is correctly reporting all dropped or marked packets. Even if ECN is not used (the receiver's ECN Incapable feature is set to one), the sender could still check on the receiver by occasionally not sending a packet, or sending a packet out-of-order, to catch the receiver in an error in Loss Intervals or Ack Vector information. This is not as robust or non-intrusive as the verification provided by the ECN Nonce, however.
送信者は損失間隔を使用することができますオプションECNのNonceエコーズ（そしておそらく任意のAckをベクトルECNのNonceエコーズ）が確率的に受信機がすべて正しく廃棄またはマークされたパケットを報告していることを確認します。 ECNは、（受信者の電子証券取引ネットワークできない機能が1に設定されている）を使用しない場合であっても、送信者はまだエラーで受信機をキャッチするために、時折パケットを送信しない、またはアウトオブオーダーパケットを送信することにより、受信機でチェックすることができます損失間隔またはのAckベクトル情報インチしかしこれは、ECNのNonceが提供する検証ほど堅牢でまたは非侵入ではありません。
To verify the ECN Nonce Echo included with a Loss Intervals option, the sender maintains a table with the ECN nonce sum for each data packet. As defined in [RFC3540], the nonce sum for sequence number S is the one-bit sum (exclusive-or, or parity) of data packet nonces over the sequence number range [I,S], where I is the initial sequence number. Let NonceSum(S) represent this nonce sum for sequence number S, and define NonceSum(I - 1) as 0. Note that NonceSum does not account for the nonces of non-data packets such as DCCP-Ack. Then the Nonce Echo for an interval of packets with sequence numbers X to Y, inclusive, should equal the following one-bit sum:
ECNナンスエコーが損失間隔オプションに含まれていることを確認するには、送信者は、各データパケットのECN一回だけの合計とテーブルを維持しています。 [RFC3540]で定義されるように、シーケンス番号Sのためのノンス和がIが初期シーケンス番号であるシーケンス番号範囲[I、S]、上のデータパケットのナンスの1ビットの和（排他的論理和、またはパリティ）であります。 NonceSumは、DCCP-Ackのような非データ・パケットのナンスを考慮していないことを - （1 I）0注としてNonceSum（S）は、シーケンス番号Sは、このナンス和を表し、NonceSumを定義しよう。次いで、Yの配列番号Xを有するパケットの間隔のノンスエコー、包括的には、次の1ビットの和に等しくなければなりません。
NonceSum(X - 1) + NonceSum(Y)
NonceSum（X - 1）+ NonceSum（Y）
Since an ECN Nonce Echo is returned for the lossless part of each Loss Interval, a misbehaving receiver -- meaning a receiver that reports a lost or marked data packet as "received non-marked", to avoid rate reductions -- has only a 50% chance of guessing the correct Nonce Echo for each loss interval.
ECNナンスエコーは、各損失のロスレス一部のために返されるので間隔、誤動作の受信機 - 率の低下を避けるために、「非マーク受け取った」として、紛失またはマークされたデータパケットを報告する受信機を意味するが - のみ50あり各損失間隔の正しいナンスエコーを推測するの％の確率。
To verify the ECN Nonce Echo included with an Ack Vector option, the sender maintains a table with the ECN nonce value sent for each packet. The Ack Vector option explicitly says which packets were received non-marked; the sender just adds up the nonces for those packets using a one-bit sum and compares the result to the Nonce Echo encoded in the Ack Vector's option type. Again, a misbehaving receiver has only a 50% chance of guessing an Ack Vector's correct Nonce Echo. Alternatively, an Ack Vector's ECN Nonce Echo may also be calculated from a table of ECN nonce sums, rather than from ECN nonces. If the Ack Vector contains many long runs of non-marked, non-dropped packets, the nonce sum-based calculation will probably be faster than a straightforward nonce-based calculation.
ECNナンスエコーのAckベクトルオプションに含まれていることを確認するには、送信者は、各パケットのために送られたECN一回だけの値を持つテーブルを維持します。 Ackベクトルオプションは、明示的にパケットがマーキングされていない受信されたと言います。送信者は、ちょうど1ビットの合計を使用して、それらのパケットのためのナンスを加算し、ACKベクトルのオプションタイプでエンコードされたNonceエコーの結果を比較します。ここでも、誤動作の受信機は、ACKベクトルの正しいナンスエコーを推測するだけで、50％のチャンスがあります。代替的には、ACKベクトルのECNノンスエコーはまた、ECNノンス和のテーブルからではなく、ECNのナンスから計算することができます。 Ack Vectorが非マーク、非ドロップされたパケットの多くのロングランが含まれている場合は、一回だけの合計に基づく計算は、おそらく簡単なナンスベースの計算よりも速くなります。
Note that Ack Vector's ECN Nonce Echo is measured over both data packets and non-data packets, while the Loss Intervals option reports ECN Nonce Echoes for data packets only. Thus, different nonce sum tables are required to verify the two options.
損失間隔のオプションは、データパケットのための電子証券取引ネットワークのNonceエコーズを報告しながらのAckベクトルのECNノンスエコーは、データパケットと非データパケットの両方に渡って測定されることに注意してください。このように、異なるナンス和テーブルは二つのオプションを確認するために必要とされています。
Besides probabilistically verifying the ECN Nonce Echoes reported by the receiver, the sender may also verify the loss intervals and any loss event rate reported by the receiver, if it so desires. Specifically, the Loss Intervals option explicitly reports the size of each loss interval as seen by the receiver; the sender can verify that the receiver is not falsely combining two loss events into one reported Loss Interval by using saved window counter information. The sender can also compare any Loss Event Rate option to the loss event rate it calculates using the Loss Intervals option.
それ望むそうであれば確率、受信機によって報告されたECNノンスエコーを確認する以外に、送信者はまた、損失間隔及び受信機によって報告された損失イベント率を検証することができます。受信機で見られるように具体的に、損失間隔オプションは、明示的にそれぞれの損失間隔の大きさを報告します。送信者は、受信機が誤って保存されたウィンドウのカウンタ情報を使用することにより、1つの報告損失間隔に2つの損失イベントを組み合わせていないことを確認することができます。送信者はまた、損失間隔のオプションを使用して計算し、損失イベント率にいかなる損失イベントレートオプションを比較することができます。
Note that in some cases the loss event rate calculated by the sender could differ from an explicit Loss Event Rate option sent by the receiver. In particular, when a number of successive packets are dropped, the receiver does not know the sending times for these packets and interprets these losses as a single loss event. In contrast, if the sender has saved the sending times or window counter information for these packets, then the sender can determine if these losses constitute a single loss event or several successive loss events. Thus, with its knowledge of the sending times of dropped packets, the sender is able to make a more accurate calculation of the loss event rate. These kinds of differences SHOULD NOT be misinterpreted as attempted receiver misbehavior.
いくつかのケースでは、送信側で計算損失イベント率は、受信機によって送信された明示的なロスイベントレートオプションとは異なる可能性があることに注意してください。具体的には、連続するパケットの数がドロップされる場合、受信機は、これらのパケットの送信時刻を知っていて、単一の損失イベントとしてこれらの損失を解釈しません。送信者は、これらのパケットの送信回数またはウィンドウカウンタ情報を保存している場合、これらの損失は、単一の損失事象またはいくつかの連続した損失事象を構成する場合は対照的に、送信者が決定することができます。このように、ドロップされたパケットの送信回数の知識と、送信者は、損失イベント率のより正確な計算をすることができます。違いのこれらの種類を試み、受信不正行為と誤解されるべきではありません。
CCID 3 data packets need not carry Timestamp options. The sender can store the times at which recent packets were sent; the Acknowledgement Number and Elapsed Time option contained on each required acknowledgement then provide sufficient information to compute the round trip time. Alternatively, the sender MAY include Timestamp options on some of its data packets. The receiver will respond with Timestamp Echo options including Elapsed Times, allowing the sender to calculate round-trip times without storing sent packets' timestamps at all.
CCID 3データパケットは、タイムスタンプオプションを運ぶ必要はありません。送信者は、最近のパケットが送信された時刻を格納することができます。各必要な承認に含まれる承認番号と経過時間オプションは、往復時間を計算するのに十分な情報を提供しています。また、送信者は、そのデータパケットの一部にタイムスタンプオプションを含むかもしれません。受信機は、送信者がすべてで送信されたパケットのタイムスタンプを保存せずに往復時間を計算することができ、経過時間を含むタイムスタンプエコーオプションで応答します。
The window counter is used by the receiver to determine whether multiple lost packets belong to the same loss event. The sender increases the window counter by one every quarter round-trip time. This section describes in detail the procedure for using the window counter to determine when two lost packets belong to the same loss event.
ウインドウカウンタは、複数の失われたパケットが同じ損失イベントに属するかどうかを決定するために受信機によって使用されます。送信者は、四半期ごとに1ラウンドトリップ時間によって窓カウンタが増加します。このセクションでは、2つの失われたパケットが同じ損失イベントに属しているかを決定するために、ウィンドウのカウンタを使用するための詳細な手順を説明します。
[RFC3448], Section 3.2.1 specifies that each data packet contains a timestamp and gives as an alternative implementation a "timestamp" that is incremented every quarter of an RTT, as is the window counter in CCID 3. However, [RFC3448], Section 5.2 on "Translation from Loss History to Loss Events" is written in terms of timestamps, not in terms of window counters. In this section, we give a procedure for the translation from loss history to loss events that is explicitly in terms of window counters.
[RFC3448]、セクション3.2.1は、ウィンドウカウンタは、しかし、CCID 3にあるように、RTTの四半期ごとにインクリメントされ、「タイムスタンプ」、[RFC3448]を各データパケットにはタイムスタンプが含まれていることを指定し、代替実装として提供し、 「損失歴史から損失イベントへの翻訳」の5.2節は、タイムスタンプの面ではなく、窓のカウンターの観点で書かれています。このセクションでは、窓のカウンターの観点から明示的である損失イベントへの損失履歴から翻訳のための手順を与えます。
To determine whether two lost packets with sequence numbers X and Y belong to different loss events, the receiver proceeds as follows. Assume Y > X in circular sequence space.
次のようにシーケンス番号X及びYを有する2つの失われたパケットが、異なる損失イベントに受信進行に属するかどうかを決定します。円形シーケンス空間のY> Xを想定しています。
o Let X_prev be the greatest valid sequence number received with X_prev < X.
O X_prevがX_prev <Xで受信最大の有効なシーケンス番号とします
o Let Y_prev be the greatest valid sequence number received with Y_prev < Y.
O Y_prevがY_prev <Y.を受け、最大の有効なシーケンス番号とします
o Given a sequence number N, let C(N) be the window counter value associated with that packet.
Oシーケンス番号Nが与えられると、C（N）は、そのパケットに関連付けられたウィンドウカウンタ値とします。
o Packets X and Y belong to different loss events if there exists a packet with sequence number S so that X_prev < S <= Y_prev, and the distance from C(X_prev) to C(S) is greater than 4. (The distance is the number D so that C(X_prev) + D = C(S) (mod WCTRMAX), where WCTRMAX is the maximum value for the window counter -- in our case, 16.)
O X_prev <S <= Y_prevようにシーケンス番号Sでパケットが存在する場合のパケットXとYは異なる損失事象に属し、C（S）に対してC（X_prev）からの距離（距離が4よりも大きいです数D WCTRMAXウィンドウカウンタの最大値であり、C（X_prev）+ D = C（S）（MOD WCTRMAX）、その結果 - 私達の場合には、16）
That is, the receiver only considers losses X and Y as separate loss events if there exists some packet S received between X and Y, with the distance from C(X_prev) to C(S) greater than 4. This complex calculation is necessary in order to handle the case where window counter space wrapped completely between X and Y. When that space does not wrap, the receiver can simply check whether the distance from C(X_prev) to C(Y_prev) is greater than 4; if so, then X and Y belong to separate loss events.
この複雑な計算が必要であるC（S）4より大きいとC（X_prev）からの距離で、Sは、XとYの間に受信されたいくつかのパケットが存在する場合には、受信機は、別個の損失事象として損失XとYを考慮していますその空間は、ラップしない場合XとYとの間に完全に包まれたウィンドウのカウンタースペースケースに対応するため、受信機は、単にC（Y_prev）にC（X_prev）からの距離が4よりも大きいか否かを確認することができます。そうならば、その後、XとYは、損失イベントを分離するために属しています。
Window counters can help the receiver disambiguate multiple losses after a sudden decrease in the actual round-trip time. When the sender receives an acknowledgement acknowledging a data packet with window counter i, the sender increases its window counter, if necessary, so that subsequent data packets are sent with window counter values of at least i+4. This can help minimize errors where the receiver incorrectly interprets multiple loss events as a single loss event.
ウィンドウカウンタは、受信機が、実際のラウンドトリップ時間が急激に減少した後、複数の損失を明確にすることができます。送信者は、私は窓カウンターでデータパケットを承認確認応答を受信した場合、必要に応じて後続のデータパケットは、少なくともI + 4のウィンドウカウンタ値で送信されるように、送信者は、そのウィンドウカウンタを増加させます。これは、受信機が誤って、単一の損失イベントなど、複数の損失事象を解釈し、エラーを最小限に抑えることができます。
We note that if all of the packets between X and Y are lost in the network, then X_prev and Y_prev are equal, and the series of consecutive losses is treated by the receiver as a single loss event. However, the sender will receive no DCCP-Ack packets during a period of consecutive losses, and the sender will reduce its sending rate accordingly.
我々は、XとYとの間のすべてのパケットがネットワークで失われた場合、その後X_prevとY_prevが等しく、連続損失一連の単一損失イベントとして受信機によって処理されることに注意してください。ただし、送信者は連敗の期間中に何のDCCP-ACKパケットを受信しませんし、送信者は、それに応じて送信レートが低下します。
As an alternative to the window counter, the sender could have sent its estimate of the round-trip time to the receiver directly in a round-trip time option; the receiver would use the sender's round-trip time estimate to infer when multiple lost or marked packets belong in the same loss event. In some respects, a round-trip time option would give a more precise encoding of the sender's round-trip time estimate than does the window counter. However, the window counter conveys information about the relative *sending* times for packets, while the receiver could only use the round-trip time option to distinguish between the relative *receive* times (in the absence of timestamps). That is, the window counter will give more robust performance when there is a large variation in delay for packets sent within a window of data. Slightly more speculatively, a round-trip time option might possibly be used more easily by middleboxes attempting to verify that a flow used conforming end-to-end congestion control.
窓カウンタの代替として、送信者は、ラウンドトリップ時間オプションで直接受信機へのラウンドトリップ時間の見積りを送ったかもしれません。受信機は、複数の紛失やマークされたパケットは、同じ損失イベントに属している場合に推測するために、送信者のラウンドトリップ時間の推定値を使用します。いくつかの点では、ラウンドトリップ時間のオプションは、ウィンドウカウンタの場合よりも、送信者の往復時間の見積もりをより正確にエンコーディングを与えるだろう。しかし、ウィンドウカウンタは、*（タイムスタンプが存在しない状態で）*回を受け取る受信機が唯一の相対的な区別するために、ラウンドトリップ時間のオプションを使用することができながら、パケットのための*回を送る*相対に関する情報を伝えます。データのウィンドウ内で送信されるパケットの遅延に大きな変動があった場合には、ウィンドウカウンタは、より堅牢な性能が得られますされています。もう少し投機的に、ラウンドトリップ時間オプションは、おそらくフローは、エンドツーエンドの輻輳制御を準拠使用ことを確認しようとするミドルボックスによって、より簡単に使用される可能性があります。
[RFC3448], Sections 6.1 and 6.2 specify that the TFRC receiver must send a feedback packet when a newly calculated loss event rate p is greater than its previous value. CCID 3 follows this rule.
[RFC3448]セクション6.1および6.2は、新たに計算された損失イベント率pが前の値よりも大きい場合TFRC受信機がフィードバックパケットを送信しなければならないことを指定します。 CCID 3は、この規則に従います。
In addition, [RFC3448], Section 6.2, specifies that the receiver use a feedback timer to decide when to send additional feedback packets. If the feedback timer expires and data packets have been received since the previous feedback was sent, then the receiver sends a feedback packet. When the feedback timer expires, the receiver resets the timer to expire after R_m seconds, where R_m is the most recent estimate of the round-trip time received from the sender. CCID 3 receivers, however, generally use window counter values instead of a feedback timer to determine when to send additional feedback packets. This section describes how.
また、[RFC3448]、6.2節では、受信機が追加のフィードバックパケットを送信するタイミングを決定するためにフィードバックタイマーを使用することを指定します。フィードバックタイマーの期限が切れると、前のフィードバックが送信されたため、データパケットが受信された場合、受信機は、フィードバックパケットを送信します。フィードバックタイマーが満了すると、受信機はR_Mは、送信者から受信した往復時間の最新の推定値であるR_M秒、後に期限切れにするタイマーをリセットします。 CCID 3つの受信機は、しかし、一般たときに追加のフィードバックパケットを送信するかを決定する代わりに、フィードバックタイマーの窓カウンタ値を使用します。このセクションでは、方法を説明します。
Whenever the receiver sends a feedback message, the receiver sets a local variable last_counter to the greatest received value of the window counter since the last feedback message was sent, if any data packets have been received since the last feedback message was sent. If the receiver receives a data packet with a window counter value greater than or equal to last_counter + 4, then the receiver sends a new feedback packet. ("Greater" and "greatest" are measured in circular window counter space.)
受信機は、フィードバックメッセージを送信するたびに、最後のフィードバック・メッセージが送信されたので、任意のデータ・パケットが受信された場合、最後のフィードバックメッセージが、送信されたため、受信機はウインドウカウンタの最大受信値をローカル変数last_counterを設定します。受信機は+ 4 last_counter以上ウインドウカウンタ値とデータ・パケットを受信した場合、受信機は新しいフィードバックパケットを送信します。 （「大」と「最大」は円形の窓カウンタ空間で測定されます。）
This procedure ensures that when the sender is sending at a rate less than one packet per round-trip time, the receiver sends a feedback packet after each data packet. Similarly, this procedure ensures that when the sender is sending several packets per round-trip time, the receiver will send a feedback packet each time that a data packet arrives with a window counter at least four greater than the window counter when the last feedback packet was sent. Thus, the feedback timer is not necessary when the window counter is used.
この手順では、送信者は、往復時間あたりのレートで未満1つのパケットを送信しているとき、受信機は各データパケットの後にフィードバックパケットを送信することを保証します。同様に、この手順では、送信者は、ラウンドトリップ時間ごとに複数のパケットを送信すると、受信機は、データパケットがウィンドウのカウンターよりも少なくとも4つの大きな窓のカウンター最後のフィードバックパケットで到着するたびに、フィードバックパケットを送信することを保証します送信されました。窓カウンタを使用する場合はこのように、フィードバック・タイマーは必要ありません。
However, the feedback timer still could be useful in some rare cases to prevent the sender from unnecessarily halving its sending rate. In particular, one could construct scenarios where the use of the feedback timer at the receiver would prevent the unnecessary expiration of the nofeedback timer at the sender. Consider the case below, in which a feedback packet is sent when a data packet arrives with a window counter of K.
しかし、フィードバック・タイマーはまだ不必要にその送信レートを半減から送信者を防ぐために、いくつかのまれなケースで役に立つかもしれません。特に、1は、受信機におけるフィードバックタイマーの使用は、送信側でNOFEEDBACKタイマーの不要な満了を妨げるシナリオを構築することができます。データパケットがKの窓カウンターで到着したときに、フィードバックパケットが送信される以下の場合を考えます
Window
Counters: K K+1 K+2 K+3 K+4 K+5 K+6 ... K+15 K+16 K+17 ...
| | | | | | | | | |
Data | | | | | | | | | |
Packets | | | | | | | | | |
Received: - - --- - ... - - -- - -- -- -
| | | | | |
| | | | | |
Events: 1: 2: 3: 4: 5: 6:
"A" "B" Timer "B"
sent sent received
1: Feedback message A is sent.
2: A feedback message would have been sent if feedback
timers had been used.
3: Feedback message B is sent. 4: Sender's nofeedback timer expires. 5: Feedback message B is received at the sender. 6: Sender's nofeedback timer would have expired if feedback timers had been used, and the feedback message at 2 had been sent.
3：Bが送信されるフィードバックメッセージ。 4：送信者のNOFEEDBACKタイマーが満了します。 5：フィードバックメッセージBは、送信側で受信されます。 6：フィードバックのタイマーが使用されていた場合には送信者のNOFEEDBACKタイマーが期限切れになっているだろう、と2のフィードバックメッセージが送られていました。
The receiver receives data after the feedback packet has been sent but has received no data packets with a window counter between K+4 and K+14. A data packet with a window counter of K+4 or larger would have triggered sending a new feedback packet, but no feedback packet is sent until time 3.
受信機は、フィードバックパケットが送信された後にデータを受信するがK + 4とK + 14の間の窓カウンターではデータ・パケットを受信していません。 K + 4以上のウィンドウカウンタを有するデータパケットは、新しいフィードバックパケットを送信引き起こしたであろうが、全くフィードバックパケットは、時間3まで送信されません。
The TFRC protocol specifies that after a feedback packet is received, the sender sets a nofeedback timer to at least four times the round-trip time estimate. If the sender doesn't receive any feedback packets before the nofeedback timer expires, then the sender halves its sending rate. In the figure, the sender receives feedback message A (time 1) and then sets the nofeedback timer to expire roughly four round-trip times later (time 4). The sender starts sending again just before the nofeedback timer expires but doesn't receive the resulting feedback message until after its expiration, resulting in an unnecessary halving of the sending rate. If the connection had used feedback timers, the receiver would have sent a feedback message when the feedback timer expired at time 2, and the halving of the sending rate would have been avoided.
TFRCプロトコルは、フィードバックパケットを受信した後、送信者は、少なくとも4回のラウンドトリップ時間の見積もりにNOFEEDBACKタイマーをセットすることを指定します。 NOFEEDBACKタイマーが切れる前に、送信者が任意のフィードバックパケットを受信しない場合、送信者はその送信レートを半分にします。同図において、送信側はフィードバックメッセージA（時間1）を受信した後、約4往復時間後（時間4）期限切れにNOFEEDBACKタイマーをセットします。送信者はNOFEEDBACKタイマーが切れる直前に再び送信を開始しますが、送信レートの不必要な半減で、その結果、その満了後まで、得られたフィードバックメッセージを受信しません。接続は、フィードバックタイマーを使用していた場合は、フィードバック・タイマーは時間2の有効期限が切れたときに受信機は、フィードバックメッセージを送っているだろう、と送信レートの半分は回避されていたであろう。
For implementors who wish to implement a feedback timer for the data receiver, we suggest estimating the round-trip time from the most recent data packet, as described in Section 8.1. We note that this procedure does not work when the inter-packet sending times are greater than the RTT.
データ受信のためのフィードバックタイマーを実装したい実装のために、我々は、8.1節で説明したように、最新のデータパケットから往復時間を推定示唆しています。私たちは、パケット間の送信時間はRTTより大きい場合、この手順が機能しないことに注意してください。
Security considerations for DCCP have been discussed in [RFC4340], and security considerations for TFRC have been discussed in [RFC3448], Section 9. The security considerations for TFRC include the need to protect against spoofed feedback and the need to protect the congestion control mechanisms against incorrect information from the receiver.
TFRCのためのセキュリティの考慮事項は、偽装されたフィードバックと輻輳制御機構を保護する必要性から保護する必要性を含んでDCCPのためのセキュリティの考慮事項は、[RFC4340]で議論されてきた、とTFRCのためのセキュリティの考慮事項は、[RFC3448]で議論されている、第9節受信機からの誤った情報に対して。
In this document, we have extensively discussed the mechanisms the sender can use to verify the information sent by the receiver. When ECN is used, the receiver returns ECN Nonce information to the sender. When ECN is not used, then, as Section 9 shows, the sender could still use various techniques that might catch the receiver in an error in reporting congestion, but this is not as robust or non-intrusive as the verification provided by the ECN Nonce.
この文書では、我々は広範囲に送信者が受信者から送信された情報を検証するために使用できるメカニズムを議論してきました。 ECNを使用する場合、受信側は送信側にECNノンス情報を返します。 ECNを使用しない場合は、その後、第9節が示すように、送信者はまだ輻輳を報告するには、エラーで受信機をキャッチ可能性がある様々な技術を使用することができますが、これは電子証券取引ネットワークのNonceが提供する検証ほど堅牢でまたは非侵入ではありません。
This specification defines the value 3 in the DCCP CCID namespace managed by IANA. This assignment is also mentioned in [RFC4340].
この仕様は、IANAが管理しDCCP CCID名前空間に値3を定義します。この割り当てはまた、[RFC4340]に記載されています。
CCID 3 also introduces three sets of numbers whose values should be allocated by IANA; namely, CCID 3-specific Reset Codes, option types, and feature numbers. These ranges will prevent any future CCID 3- specific allocations from polluting DCCP's corresponding global namespaces; see [RFC4340], Section 10.3. However, we note that this document makes no particular allocations from the Reset Code range, except for experimental and testing use [RFC3692]. We refer to the Standards Action policy outlined in [RFC2434].
CCID 3はまた、数値IANAによって割り当てられるべき番号3組を紹介します。すなわち、CCID 3特有のリセットコード、オプションタイプ、および機能番号。これらの範囲はDCCPの対応するグローバル名前空間を汚染から任意の将来のCCIDの3-具体的な配分を防ぐことができます。 [RFC4340]、セクション10.3を参照してください。しかし、私たちは、この文書は、実験やテストの使用[RFC3692]を除いて、リセットコードの範囲からは特に割り当てを行わないことに注意してください。私たちは、[RFC2434]に概説され標準化アクションポリシーを参照してください。
Each entry in the DCCP CCID 3 Reset Code registry contains a CCID 3- specific Reset Code, which is a number in the range 128-255; a short description of the Reset Code; and a reference to the RFC defining the Reset Code. Reset Codes 184-190 and 248-254 are permanently reserved for experimental and testing use. The remaining Reset Codes -- 128-183, 191-247, and 255 -- are currently reserved and should be allocated with the Standards Action policy, which requires IESG review and approval and standards-track IETF RFC publication.
DCCP CCID 3リセットコードレジストリ内の各エントリは範囲128〜255の数でありCCID -3-特定リセットコードを含み、リセットコードの短い説明。そして、リセットコードを定義するRFCへの参照。 184から190と248から254が永久的に実験とテスト使用のために予約されているコードをリセットします。残りのリセットコード - 128から183まで、191から247、および255 - 現在予約されており、IESGレビューと承認および標準化過程IETF RFCの公表を要求する標準化活動方針、で割り当てる必要があります。
Each entry in the DCCP CCID 3 option type registry contains a CCID 3-specific option type, which is a number in the range 128-255; the name of the option, such as "Loss Intervals"; and a reference to the RFC defining the option type. The registry is initially populated using the values in Table 1, in Section 8. This document allocates option types 192-194, and option types 184-190 and 248-254 are permanently reserved for experimental and testing use. The remaining option types -- 128-183, 191, 195-247, and 255 -- are currently reserved and should be allocated with the Standards Action policy, which requires IESG review and approval and standards-track IETF RFC publication.
DCCP CCID 3オプションタイプレジストリ内の各エントリは範囲128〜255の数でありCCID 3固有のオプションタイプを含み、こうした「損失間隔」としてオプションの名前、;およびオプションタイプを定義するRFCへの参照。レジストリは、最初にこの文書は、オプションタイプ192から194、およびオプションのタイプ184から190を割り当て、248-254項8において、表1の値を使用して移入され恒久的実験および試験使用のために予約されています。残りのオプションの種類 - 128から183、191、195から247、および255 - 現在予約されており、IESGレビューと承認および標準化過程IETF RFCの公表を要求する標準化活動方針、で割り当てる必要があります。
Each entry in the DCCP CCID 3 feature number registry contains a CCID 3-specific feature number, which is a number in the range 128-255; the name of the feature, such as "Send Loss Event Rate"; and a reference to the RFC defining the feature number. The registry is initially populated using the values in Table 2, in Section 8. This document allocates feature number 192, and feature numbers 184-190 and 248-254 are permanently reserved for experimental and testing use. The remaining feature numbers -- 128-183, 191, 193-247, and 255 -- are currently reserved and should be allocated with the Standards Action policy, which requires IESG review and approval and standards-track IETF RFC publication.
DCCP CCID 3フィーチャー番号レジストリ内の各エントリは範囲128〜255の数でありCCID 3 - 特定の機能番号が含まれ;そのような「ロスイベントレートを送る」などの機能の名前、;そして、機能番号を定義するRFCへの参照。レジストリは、最初にこの文書は、機能番号192を割り当て、機能番号184から190及び248から254が永久的実験及び試験の使用のために予約されている第8に、表2の値を使用して移入されます。残りの機能番号 - 128から183、191、193から247、および255 - 現在予約されており、IESGレビューと承認および標準化過程IETF RFCの公表を要求する標準化活動方針、で割り当てる必要があります。
We thank Mark Handley for his help in defining CCID 3. We also thank Mark Allman, Aaron Falk, Ladan Gharai, Sara Karlberg, Greg Minshall, Arun Venkataramani, David Vos, Yufei Wang, Magnus Westerlund, and members of the DCCP Working Group for feedback on versions of this document.
私たちは、我々はまた、マーク・オールマン、アーロンフォーク、ラダンGharai、サラKarlberg、グレッグMinshall、アルンVenkataramani、デビッド・ヴォス、Yufei王、マグヌスウェスター、およびDCCPワーキンググループのメンバーのために感謝CCID 3を定義する際に彼の助けのためのマーク・ハンドリーに感謝しますこのドキュメントのバージョンのフィードバック。
A. Appendix: Possible Future Changes to CCID 3
A.付録：CCID 3への可能性のある将来の変更
There are a number of cases where the behavior of TFRC as specified in [RFC3448] does not match the desires of possible users of DCCP. These include the following:
[RFC3448]で指定されているTFRCの動作はDCCPの可能性ユーザーの要望と一致しない例がいくつかあります。これには次のものがあります。
1. The initial sending rate of at most four packets per RTT, as specified in [RFC3390].
1. [RFC3390]で指定されるようにRTTあたり最大で4つのパケットの初期送信レート、。
2. The receiver's sending of an acknowledgement for every data packet received, when the receiver receives at a rate less than one packet per round-trip time.
2.受信側の送信確認応答のすべてのデータパケットのためには、受信機は、ラウンドトリップ時間あたり1つのパケット未満のレートで受信すると、受信しました。
3. The sender's limitation of at most doubling the sending rate from one round-trip time to the next (or, more specifically, of limiting the sending rate to at most twice the reported receive rate over the previous round-trip time).
3.最大で1往復時間から次へと送信レートを倍の送信者の制限（最大に送信レートを制限する、より具体的に、または二回報告は、前のラウンドトリップ時間にわたり率を受けます）。
4. The limitation of halving the allowed sending rate after an idle period of four round-trip times (possibly down to the initial sending rate of two to four packets per round-trip time).
4.（おそらく往復時間あたり2〜4のパケットの最初の送信速度まで）4つのラウンドトリップ時間のアイドル期間後に許可される送信レートを半分の制限。
5. The response function used in [RFC3448], Section 3.1, which does not closely match the behavior of TCP in environments with high packet drop rates [RFC3714].
密接高いパケット損失率[RFC3714]と環境におけるTCPの挙動と一致していない[RFC3448]で使用される前記応答関数、セクション3.1、。
One suggestion for higher initial sending rates is an initial sending rate of up to eight small packets per RTT, when the total packet size, including headers, is at most 4380 bytes. Because the packets would be rate-paced out over a round-trip time, instead of sent back-to-back as they would be in TCP, an initial sending rate of eight small packets per RTT with TFRC-based congestion control would be considerably milder than the impact of an initial window of eight small packets sent back-to-back in TCP. As Section 5.1 describes, the initial sending rate also serves as a lower bound for reductions of the allowed sending rate during an idle period.
高い初期送信レートの1つの提案は、ヘッダを含めた総パケットサイズは、ほとんどの4380バイトであるときに、RTTあたり最大8つの小さなパケットの最初の送信レートです。パケットが往復時間をかけてペースレートの代わりに、彼らはTCPになるようバックツーバック送信されますので、TFRCベースの輻輳制御とRTTごとに8つの小さなパケットの最初の送信レートはかなりだろうバックツーバックTCPで送信された8つの小さなパケットの初期ウィンドウの影響よりも穏やか。 5.1節で説明したように、初期送信レートはまた、アイドル期間中に許可される送信レートの削減の下限として働きます。
We note that with CCID 3, the sender is in slow-start in the beginning and responds promptly to the report of a packet loss or mark. However, in the absence of feedback from the receiver, the sender can maintain its old sending rate for up to four round-trip times. One possibility would be that for an initial window of eight small packets, the initial nofeedback timer would be set to two round-trip times instead of four, so that the sending rate would be reduced after two round-trips without feedback.
当社は、CCID 3で、送信者が最初にスロースタートであり、パケット損失やマークのレポートに迅速に応答することに注意してください。しかし、受信機からのフィードバックが存在しない場合に、送信者は、最大4つの往復時間のためにその古い送信レートを維持することができます。一つの可能性は、送信速度がフィードバックなしで2往復した後に減少するであろうように、8つの小さなパケットの最初のウィンドウのために、初期NOFEEDBACKタイマーは、代わりに4の2往復時間に設定されることになります。
Research and engineering will be needed to investigate the pros and cons of modifying these limitations in order to allow larger initial sending rates, to send fewer acknowledgements when the data sending rate is low, to allow more abrupt changes in the sending rate, or to allow a higher sending rate after an idle period.
リサーチとエンジニアリングは、データ送信レートが低い場合は送信レートでより多くの急激な変化を可能にするために、または許可するように、少数の確認応答を送信するために、より大きな初期の送信レートを、可能にするためにこれらの制限を変更することの長所と短所を調査するために必要とされるであろうアイドル期間の後に高い送信レート。
Normative References
引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]オールマン、M.、パクソン、V.、およびW.スティーブンス、 "TCP輻輳制御"、RFC 2581、1999年4月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
"IPに明示的輻輳通知の添加（ECN）" [RFC3168]ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、RFC 3168、2001年9月。
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, October 2002.
[RFC3390]オールマン、M.、フロイド、S.、およびC.ヤマウズラ、 "増加するTCPの初期ウィンドウ"、RFC 3390、2002年10月。
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[RFC3448]ハンドレー、M.、フロイド、S.、Padhye、J.、およびJ.ウィトマー、 "TCPフレンドリーレート制御（TFRC）：プロトコル仕様"、RFC 3448、2003年1月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692] Narten氏、T.、 "役に立つと考えられ割り当て実験とテスト番号"、BCP 82、RFC 3692、2004年1月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]コーラー、E.、ハンドリー、M.、およびS.フロイド、 "データグラム輻輳制御プロトコル（DCCP）"、RFC 4340、2006年3月。
Informative References
参考文献
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003.
[RFC3540]春、N.、Wetherall、D.、およびD.イーリー、 "ロバスト明示的輻輳通知（ECN）ナンスとシグナリング"、RFC 3540、2003年6月。
[RFC3714] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet", RFC 3714, March 2004.
[RFC3714]フロイド、S.とJ.ケンプ、「インターネットで音声トラフィックのための輻輳制御に関するIAB心配」、RFC 3714、2004年3月。
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control", RFC 4341, March 2006.
[RFC4341]フロイド、S.、およびE.コーラー、 "データグラム輻輳制御プロトコル（DCCP）輻輳制御ID 2用のプロフィール：TCPのような輻輳制御"、RFC 4341、2006年3月。
[V03] Arun Venkataramani, August 2003. Citation for acknowledgement purposes only.
[V03]アルンVenkataramani、確認のみを目的とした2003年8月の引用。
Authors' Addresses
著者のアドレス
Sally Floyd ICSI Center for Internet Research 1947 Center Street, Suite 600 Berkeley, CA 94704 USA
インターネットリサーチ1947センターストリートのためのサリーフロイドICSIセンター、スイート600バークレー、CA 94704 USA
EMail: floyd@icir.org
メールアドレス：floyd@icir.org
Eddie Kohler 4531C Boelter Hall UCLA Computer Science Department Los Angeles, CA 90095 USA
エディー・コーラー4531C BoelterホールUCLAコンピュータサイエンス学部ロサンゼルス、CA 90095 USA
EMail: kohler@cs.ucla.edu
メールアドレス：kohler@cs.ucla.edu
Jitendra Padhye Microsoft Research One Microsoft Way Redmond, WA 98052 USA
98052 USA OF Jitendra Padhyeマイクロソフトリサーチ1つのマイクロソフト道、レッドモンド、
EMail: padhye@microsoft.com
メールアドレス：padhye@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。