[要約] RFC 4342は、DCCPのCongestion Control ID 3であるTCP-Friendly Rate Control（TFRC）のプロファイルに関するものです。このRFCの目的は、ネットワークの混雑制御を改善し、TCPとの公平な共存を実現するためにTFRCを使用する方法を定義することです。
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)
Datagramのプロファイル混雑制御プロトコル（DCCP）混雑制御ID 3：TCPフレンドリーレートコントロール（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).
Copyright（c）The Internet Society（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.
このドキュメントには、Datagram混雑制御プロトコル（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.
このドキュメントには、Datagram混雑制御プロトコル（DCCP）[RFC4340]に、混雑制御識別子識別子3、TCPフレンドリーレート制御（TFRC）のプロファイルが含まれています。DCCPは、うっ血制御識別子またはCCIDを使用して、半接続で使用中の混雑制御メカニズムを指定します。
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または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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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のハーフ接続は、1つのエンドポイントから送信されたアプリケーションデータと、他のエンドポイントによって送信される対応する謝辞で構成されています。「HC-SENDER」と「HC-Receiver」という用語は、それぞれエンドポイントがアプリケーションデータと謝辞を送信することを示しています。CCIDはハーフ接続のレベルで適用されるため、このドキュメントではHC-SENDEを「送信者」に、HC-Receiverを「受信者」に略します。詳細については、[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-DATAパケットを送信し、レシーバーはDCCP-CACKパケットを送信すると言います。これらのカテゴリは両方とも、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：1秒あたりのバイトの受信率。[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混雑制御は、再生前に小規模または中程度のレシーバーバッファリングを備えたストリーミングメディアアプリケーションを含む、送信率の急激な変化を最小限に抑えることを好むフローに適しています。DCCPのCCID 2 [RFC4341]のようなTCPのような混雑制御は、各輻輳イベントに応答して送信率を半分にするため、比較的スムーズな送信率を提供できません。
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メカニズムが、DO 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-DATAパケットを送信します。送信率は、[RFC3448]、セクション3.2で指定されている許可された送信率によって準拠しています。各DCCP-DATAパケットにはシーケンス番号があり、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-DATAおよびDCCP-DATAACKパケットがECNの能力として送信され、ECT（0）またはECT（1）CodePointセットのいずれかがあります。TFRCを使用したECN NonCeの使用については、セクション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仕様（[RFC3448]で示されているように、送信者がラウンドトリップ時間ごとに1パケット未満のレートで送信していない限り、往復時間ごとに少なくとも1回データパケットを認めるDCCP-CACKパケットを送信します。セクション6）。各DCCP-CACKパケットは、シーケンス番号を使用し、送信者から受信した最新のパケットを識別し、受信機が経験した最近の損失間隔に関するフィードバックを含みます。
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-DATAパケットの送信を続けます。DCCP-CACKパケットを受信すると、送信者は[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で指定されているように、ラウンドトリップ時間を推定し、ノーフィードバック時間を計算します。その時点でレシーバーからフィードバックが受け取られていない場合（少なくとも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の交渉中または後に、クライアントおよび/またはサーバーは、Send Ack Vectorの値をネゴシエートし、損失イベント率の機能を送信することをお勧めします。
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]で指定されているように、セクション3.1で指定されているTCPスループット方程式に差し込まれます。その結果、現代の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 Intervals option is used to report loss interval lengths; see Section 8.6.
損失イベント率自体は、受信者によって報告された最近の損失間隔の長さを使用してCCID 3で計算されます。損失間隔は、セクション6.1で正確に定義されています。要約すると、損失間隔は最大1 RTTの紛失またはECNマークされたデータパケットの続きで、その後、任意の数の非ドロップされていないマークされていないデータパケットが続きます。したがって、長い損失間隔は、うっ血率が低いことを表します。CCID 3損失間隔オプションは、損失間隔の長さを報告するために使用されます。セクション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.
送信者はスロースタートフェーズで開始し、各ラウンドトリップ時間の送信レートをほぼ2倍にします。スロースタートフェーズは、データパケットドロップまたはマークの受信者のレポートによって終了します。その後、送信者は損失イベント率を使用して、許可された送信率を計算します。
[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は、次のように、往復時間ごとに1つのパケットの初期送信率（RTT）を指定します。送信者は、許可された送信率を1秒あたり1パケットに初期化します。受信機からフィードバックパケットが受信されるとすぐに、送信者は往復時間を測定し、RTTごとに1つのパケットに最初の許可された送信率を設定します。ただし、初期のTCPウィンドウは1つのセグメントでしたが、[RFC2581]は2つのセグメントの初期TCPウィンドウを許可し、[RFC3390]により3つまたは4つのセグメント（最大4380バイト）の初期TCPウィンドウが許可されます。[RFC3390]は、MIN（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ごとに少なくとも2つのパケット、および最大4つのパケットを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で説明されているように、送信者の往復時間の測定では、フィードバックパケットに含まれる経過時間および/またはタイムスタンプエコーオプションを使用します。Elapsed Timeオプションは必要ですが、タイムスタンプエコーオプションは必要ありません。送信者は、最新の測定値に大きく重み付けされた平均往復時間を維持します。
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-DATAパケットには、シーケンス番号が含まれています。各DCCP-DATAパケットには、セクション8.1で説明されているように、ウィンドウカウンター値も含まれています。ウィンドウカウンターは、通常、四半期ごとの往復時間ごとに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 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.
TFRCはウィンドウベースではなくレートベースであり、ネットワークでフィードバックパケットをドロップできるため、送信者は受信機からの肯定的なフィードバックがない場合に送信率を下げるためのメカニズムを必要とします。セクション6で説明されているように、受信者はラウンドトリップ時間ごとにフィードバックパケットを約1回送信します。[RFC3448]、セクション4.3で指定されているように、送信者は、少なくとも4回の往復時間、またはデータパケット間の間隔の2倍のいずれか大きい方にnofeedbackタイマーを設定します。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.
送信者がレシーバーからフィードバックパケットを受け取らず、結果としてRTTごとに1つのパケットに許可された送信率を設定することができない場合、NoFeedbackタイマーで送信率は1秒あたり1パケットの初期レートで残されます。2秒後に期限切れになります。NoFeedbackタイマーが期限切れになるたびに、許可された送信率が半分になります。したがって、受信機からフィードバックが受信されない場合、許可された送信率が1秒あたり1パケットを超えることはなく、1秒あたり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では、許可された送信率が、アイドル期間の結果として、往復時間ごとに2つのパケットに減少することはありません。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.
送信者の許可送信率は、受信者が報告した受信率の最大2倍に制限されています。したがって、アプリケーションが制限された期間の後、送信者は、損失イベント率によって決定される許可された送信率に達するまで、最大の往復時間から次の時間までの送信率を最大2倍にすることができます。
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のデータドロップされたオプションにより、受信者は、腐敗やバッファオーバーフローのために、アプリケーションに配信する前に、アプリケーションへの配信前に最後のホストでパケットがドロップされたことを宣言できます。その遅いレシーバーオプションにより、受信者は、まだ削除されていませんが、送信者のパケットに追いつくのに苦労していると宣言できます。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つのパケットによって削減されます。
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のスループット計算（[RFC3448]、セクション4.3）の「MIN（...、2*X_RECV）」節を介して受信者によって報告された受信率の最大2倍に制限されます。送信者が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は、最新の確認で受信機によって報告された1秒あたりのバイトの受信レートに等しくなります。
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でドロップされたことを示すデータをドロップしたオプションを受信した場合、送信レートの上限はRTTごとに最大3つのパケットによって減少します。
max(X_inrecv - 3*s/RTT, min(X_inrecv, s/RTT)).
max（x_inrecv -3*s/rtt、min（x_inrecv、s/rtt））。
Again, s is the packet size in bytes.
繰り返しますが、Sはバイトのパケットサイズです。
3. X_recv is then set to min(X_inrecv, X_drop/2).
3. x_recvはmin（x_inrecv、x_drop/2）に設定されます。
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は、固定パケットサイズを使用するアプリケーションを対象としており、輻輳に応じて1秒あたりのパケットで送信率を変更します。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スループット方程式で使用されます。CCID 3の実装は、セクション6.1で定義されている損失間隔の場合、たとえば最新の4つの損失間隔で、複数の往復時間にわたって平均化されたセグメントサイズとしてSを計算する場合があります。あるいは、CCID 3の実装では、最大パケットサイズを使用してsを導き出すことができます。この場合、Sは最大セグメントサイズ（MSS）に設定され、デフォルトのDCCPおよびIPパケットヘッダーは含まれないデータセグメントの最大サイズです。送信された各パケットは、実際のセグメントサイズに関係なく1つのMSSとしてカウントされ、TCPスループット方程式は、1秒あたりのパケットの送信レートを指定するものとして解釈できます。
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.
受信者は、送信者が頻繁にパケットを送信している場合、ラウンドトリップ時間ごとに約1回、フィードバックパケットを送信者に送信します。このレートは、[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.
各フィードバックパケットには、この接続でこれまでに受信された最大の有効なシーケンス番号に等しい確認番号が含まれています。（もちろん、「最大」は円形のシーケンス空間で測定されます。）各フィードバックパケットには、少なくとも次のオプションも含まれています。Asconedcement番号フィールドにシーケンス番号が表示されるパケットの。これらのオプションは[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. セクション8.3で定義されている受信料オプションは、最後のDCCP-CACKが送信されてからデータが受信されたレートを指定します。
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の混雑制御メカニズムでは必要ありません。Loss間隔オプションは、送信率を管理し、受信機フィードバックを確率的に検証するために必要なすべての情報を提供します。ただし、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つの往復時間のパケットを続けます。任意の長いシリーズの一連のドロップされていないマーク化されていないデータパケットで完了します。たとえば、ここに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.
[RFC3448]、セクション5.2のように、損失部分の長さは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のさらなる議論については、[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マークされた非DATAパケットは、損失間隔のロスレス部分で自由に発生する可能性があります。（非DATAパケットは、アプリケーションデータを運ぶことができないパケットタイプで構成されています。つまり、DCCP-CACK、DCCP-CLOSE、DCCP-CLOSEREQ、DCCP-RESET、DCCP-SYNCACK、および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は、2つのハーフ接続のコンテキストで適用され、1つのハーフ接続共有シーケンス番号スペースからのDCCP-DATAおよびDCCP-DATAACKパケットが、他のハーフ接続からのDCCP-CACKパケットを使用します。CCID 3の混雑制御の目的のために、損失間隔の長さにはデータパケットを含める必要があり、逆の半分接続から確認パケットを除外する必要があります。ただし、各損失間隔のパケットの総数を報告することも役立ちます（たとえば、ECN NonCe検証を促進するため）。
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.
最初を除くすべての損失間隔について、データ長は、最小データ長が1つのパケットであることを除き、損失間隔中に送信される非DATAパケットの数を差し引いてシーケンス長に等しくなります。より良い情報がない場合、エンドポイントは、損失間隔にデータパケットのみが含まれていると控えめに仮定する必要があります。その場合、データの長さはシーケンス長に等しくなります。より精度を高めるために、送信者は、送信されたパケットが含まれるデータを記憶することにより、間隔で非DATAパケットの正確な数を計算できます。受信者は、データの長さにそれらを含めないことで受信した非DATAパケットを考慮し、受信したパケットの場合、DCCPのNDPカウントオプションを使用して失われたデータパケットと失われた非DATAパケットを区別できる場合があります。
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パケットをドロップすると仮定します。レシーバーは、シーケンス番号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）によって決定されます。謝辞の送信率は比較的低く、ラウンドトリップ時間ごとに約1回 - 承認に関する明示的な渋滞制御は必要ありません。
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ベクターまたはドロップされたデータを使用すると、送信者であるDCCP Aは、受信者がACKベクターまたはデータをドロップした状態を解放できるように、受信者の謝辞を時々確認する必要があります。両方のハーフ接続がアクティブな場合、必要な謝辞は、Bのデータに対するAの謝辞に含まれます。ただし、B-to-Aの半接続が静止している場合、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ベクトルまたはデータを削除した場合、アクティブな送信者は、おそらく2つまたは3つの倍の倍の訓練時間ごとに、おそらくDCCP-DATAACKパケットを送信することにより、往復時間ごとに約1回受信者の謝辞を確認する必要があります。謝辞オプションは必要ありません。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 Loss Intervals option is bounded in size (and receiver state), so acks-of-acks are not required.
送信者は、ACKベクターやデータドロップされたオプションが含まれていない場合でも、受信者の謝辞を確認することを選択できます。たとえば、定期的な謝辞は、損失間隔のサイズを縮小する可能性があります。ただし、ACKベクターとドロップされたデータとは異なり、損失間隔オプションはサイズ（および受信者状態）に制限されているため、ACK-of-of-of-of-of-ofは必要ありません。
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.
0.2秒と2回の往復時間の大きいことを等しくします。（CCID 3レシーバーには、往復時間の大まかな測定値があるため、謝辞をペースできるようになります。）受信者は、送信者から追加データを受信せずに通過した後、送信者が静止したことを検出します。
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対応のハーフ接続の典型的なケース（レシーバーのECNの無能力機能がゼロに設定されている場合）では、[RFC4340]で指定されているように、セクション12.2で指定されているデータパケットにECN NonCEを使用します。ECN Nonceに関する情報は、Receiver Optionを使用して受信機によって返される必要があり、ACKベクトルオプションにはECN NonCe Sumを含める必要があります。送信者は、各パケットのECN NonCe Sumを使用してテーブルを維持し、この情報を使用して、損失間隔またはACKベクターオプションで返されたECN NonCe Sumを確率的に検証することができます。セクション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ベクトル、タイムスタンプ、タイムスタンプエコー、およびELAPSED TIMEオプション、およびその送信ACKベクターとECNの不能な機能を使用できます。さらに、CCID 3で使用するために、次のCCID固有のオプションが定義されています。
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-data？」列は、現在定義されているすべてのCCID 3-特定のオプションがDCCP-DATAパケットで発生する場合に無視する必要があることを示しています。
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に設定され、[RFC3448]、セクション3.2.1で説明されているように、往復時間の四半期ごとに1倍に増加します。ウィンドウカウンターは、比較を含むすべての操作に対して円形の算術モジュロ16を使用します。円形算術の詳細については、[RFC4340]、セクション3.1を参照してください。参照のために、DCCPジェネリックヘッダーは次のとおりです。（図は[RFC4340]、セクション5.1から繰り返されます。これは、24ビットシーケンス番号フィールドの一般的なヘッダーも示しています。）
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フィールドには、RTT粒度で4つの往復時間を表現するのに十分なスペースがあります。送信者は、隣接するパケットにCCValを包むことを避けなければなりません。たとえば、2つのデータキャリーパケットがパケットを介入せずに4回の往復時間を離した場合です。したがって、送信者は、CCVALを設定するために次のアルゴリズムを使用する必要があります。アルゴリズムは3つの変数を使用します。「last_wc」は送信された最後のウィンドウカウンター値を保持し、 "last_wc_time"はウィンドウカウンター値「last_wc」を備えた最初のパケットが送信され、「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.
When this algorithm is used, adjacent data-carrying packets' CCVal counters never differ by more than five, modulo 16.
このアルゴリズムを使用すると、隣接するデータキャリーパケットのCCVALカウンターは、5を超えることはありません。
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で送信されたパケットの承認を受け取った後、送信者は必要に応じてウィンドウカウンターを増やす必要があります。これにより、後続のパケットが少なくとも（WC 4）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）を再計算する必要があります。）2、3、または4は、t（k）とt（k d）の両方が存在すると言います（パケットはウィンドウカウンターkとk dで受信されました）。次に、値（t（k d）-t（k）） * 4/dは、往復時間の推定値として機能する場合があります。RTT推定には、D = 4の値を優先する必要があります。具体的には、次のパケットが到着したと言います。
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.
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の頻繁な確認レートのためにレシーバーで遅延する必要があります。受信者は、少なくともすべてのフィードバックパケットにElapsed Timeオプションを含める必要がありますが、少なくとも1つの最近のデータパケット（つまり、以前のDCCP-CACKが送信された後に受信したパケット）が含まれている場合、タイムスタンプオプションが含まれている場合、レシーバーには対応するものを含める必要があります。タイムスタンプエコーオプション、経過時間値も同様です。これらのオプションタイプはすべて、メイン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-DATAパケットに送信してはなりません。受信したDCCP-DATAパケットの受信レートオプションは無視する必要があります。
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は、「変更r（送信イベント率、1）」オプションを送信します。DCCPBに、承認トラフィックの一部として損失イベントレートオプションを送信するように依頼します。
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バイトのブール値が必要です。DCCP Bは、送信損失イベントレート/Bが1つである場合、謝辞に損失イベントレートオプションを送信する必要がありますが、送信損失イベントレート/Bがゼロの場合でも損失イベントレートオプションが送信される場合があります。2つ以上の値が予約されています。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のデータパケットが含まれます）。各損失イベントにデータパケットの損失がちょうど1つある場合、損失イベント率はデータパケットドロップレートと同じです。
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を参照してください。損失イベント率の計算では、セクション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-DATAパケットに送信しないでください。受信したDCCP-DATAパケットの損失イベントレートオプションは無視する必要があります。
+--------+--------+--------+--------...--------+--------+---
|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は、損失間隔を定義します。このオプションは、必要なすべての謝辞でデータ受信機によって送信する必要があります。このオプションは、受信機が見た最大28の損失間隔を報告していますが、TFRCは現在、これらの最新9を使用しています。これにより、送信者は損失イベント率を計算し、受信者のECNノンセエコーを確率的に検証できます。
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-DATAパケットに送信しないでください。受信したDCCP-DATAパケットの損失間隔オプションは無視する必要があります。
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.
損失間隔オプションには、最新の損失間隔を含む1〜28回連続した損失間隔に関する情報が含まれています。間隔は逆年代順にリストされています。28を超える損失間隔を報告する必要がある場合、複数の損失間隔オプションを送信できます。2番目のオプションは、最初のオプションから始まります。オプションには、（1）NINTERVAL 1損失間隔がまだなかった場合、または（2）送信者の謝辞のために、以前に送信された損失があることを知っている場合、少なくとも最新のNINTERVAL 1 = 9の損失間隔に関する情報を含める必要があります。インターバル情報が受信されました。この2番目のケースでは、受信者は、送信者が既に知っている損失間隔を送信する必要はありませんが、少なくとも1つの損失間隔を送信する必要があります。
The NINTERVAL parameter is equal to "n" as defined in [RFC3448], Section 5.4.
NINTERVALパラメーターは、[RFC3448]、セクション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以下でなければなりません。複数の損失間隔オプションを含むパケットでは、2番目と後続のオプションのスキップ長はゼロに等しくなければなりません。ゼロ以外のスキップ長を持つこのようなオプションは無視する必要があります。
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ノンセエコー（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ノンセエコーは、損失間隔のロスレス部品（ロスレスの長さのパケットが長い）。ロスレスの長さが0の場合、受信機の場合、またはロスレスの長さにデータパケットが含まれていなかった場合、ECN NonCe Echoは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ビットの数値である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のパケットに送信された損失間隔オプション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。このオプションは次のように解釈されます。
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オプションタイプと長さのバイトを含むオプションの長さ。このオプションには、（39-3）/9 = 4損失間隔に関する情報が含まれています。
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つのパケットです。したがって、最新の損失間隔L3は、シーケンス番号44-2 1 = 43の直前に終了します。
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で始まります。1.間隔のデータ長は10であるため、受信者は間隔に1つの非DATAパケットが含まれていると考えています。
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これはL2を定義します。L2は、シーケンス番号32-8 = 24でロスレス部分が始まります。その損失のある部分は、シーケンス番号24-5 = 19から始まります。ECN NonCe Echo（パケットの場合[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 NonCe Echo（パケットの場合[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非CEエコー（パケットの場合[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 echoes（およびおそらくACKベクターのecn nonce echoes）を使用して、レシーバーがすべてのドロップされたパケットまたはマークされたパケットを正しく報告していることを確率的に確認できます。ECNが使用されていない場合でも（受信者の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 NonCe Echoを確認するために、送信者は各データパケットのECN NonCe Sumを含むテーブルを維持します。[RFC3540]で定義されているように、シーケンス番号sの非CE合計は、シーケンス番号範囲[i、s]のデータパケットnoncesの1ビット合計（排他的またはパリティ）です。ここで、私は初期シーケンス番号です。。Noncesum（s）は、シーケンス番号sのこの非CEサムを表し、非セクサム（i-1）を0として定義します。NoncesumはDCCP-ackなどの非DATAパケットの非セースを考慮していないことに注意してください。次に、シーケンス番号xからy、包括的であるパケットの間隔の非CEエコーは、次の1ビット合計に等しくなければなりません。
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 NonCEエコーが返されるため、誤った受信機 - 紛失またはマークされたデータパケットを「受信していない」と報告する受信機を意味します。各損失間隔の正しいノンセエコーを推測する可能性。
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.
ACKベクトルオプションに含まれるECN NonCe Echoを検証するために、送信者は各パケットに送信されるECN NonCe値を備えたテーブルを維持します。ACKベクターオプションは、どのパケットがマークされていないかを明示的に示しています。送信者は、1ビット合計を使用してこれらのパケットのNoncesを追加し、結果をACKベクターのオプションタイプにエンコードしたNonCeエコーと比較します。繰り返しますが、誤動作の受信者は、ACKベクターの正しいノンセエコーを推測する可能性が50％しかありません。あるいは、ACKベクターのECN NonCEエコーは、ECN Nonceからではなく、ECN NonCe Sumsの表から計算される場合があります。ACKベクトルに、マークされていない非ドロップのパケットの長い走行が多数含まれている場合、NonCe Sumベースの計算は、おそらく簡単なNonCeベースの計算よりも高速になります。
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.
ACK VectorのECN NonCe Echoは、データパケットと非DATAパケットの両方で測定され、損失間隔オプションはデータパケットのみのECN NonCeエコーを報告していることに注意してください。したがって、2つのオプションを検証するには、異なる非CE SUMテーブルが必要です。
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ノンセエコーを確率的に検証することに加えて、送信者は、必要な場合、レシーバーが報告した損失間隔と損失イベント率を検証することもできます。具体的には、損失間隔オプションは、受信者が見た各損失間隔のサイズを明示的に報告します。送信者は、受信者が保存されたウィンドウカウンター情報を使用して、2つの損失イベントを1つの報告された損失間隔に誤って組み合わせていないことを確認できます。送信者は、損失イベント率オプションを、損失間隔オプションを使用して計算する損失イベント率と比較することもできます。
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は、各データパケットにタイムスタンプが含まれており、代替実装としてRTTの四半期ごとに増分される「タイムスタンプ」を提供することを指定しています。「損失履歴から損失イベントへの翻訳」に関するセクション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とyは、x_prev <s <= y_prevになり、c（x_prev）からc（s）までの距離が4を超えるように、シーケンス番号sのパケットが存在する場合、異なる損失イベントに属します（距離は距離があります。数Dで、c（x_prev）d = c（s）（mod wctrmax）（wctrmax）、wctrmaxはウィンドウカウンターの最大値です。
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.
つまり、受信者は、xとyの間に受信されたパケットが存在する場合、c（x_prev）からc（s）までの距離が4を超える場合にのみ、損失xとyを個別の損失イベントと見なします。この複雑な計算は、必要です。ウィンドウカウンタースペースがxとyの間で完全に包まれている場合を処理するために。そのスペースが包まれない場合、受信者はc（x_prev）からc（y_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を使用したデータパケットを確認するという確認を受信すると、送信者は必要に応じてウィンドウカウンターを増やします。複数の損失イベントを単一の損失イベントとして誤って解釈します。
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-CACKパケットを受け取らず、送信者はそれに応じて送信率を下げます。
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秒後にタイマーをリセットして期限切れになります。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をウィンドウカウンターの最大の受信値に設定します。受信者がlast_counter 4以上のウィンドウカウンター値を持つデータパケットを受信した場合、受信者は新しいフィードバックパケットを送信します。（「グレート」と「最大」は、円形の窓カウンタースペースで測定されます。）
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.
ただし、フィードバックタイマーは、送信者が送信率を不必要に半分にすることを防ぐために、まれな場合には依然として役立つ可能性があります。特に、受信者でフィードバックタイマーを使用すると、送信者での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.
1：フィードバックメッセージAが送信されます。2：フィードバックタイマーが使用されていれば、フィードバックメッセージが送信されていました。
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：フィードバックタイマーが使用され、2でフィードバックメッセージが送信された場合、送信者のNoFeedbackタイマーは失効していました。
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の間にウィンドウカウンターを持つデータパケットを受け取っていません。K4以上のウィンドウカウンターを持つデータパケットは、新しいフィードバックパケットの送信をトリガーしましたが、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プロトコルは、フィードバックパケットを受信した後、送信者がnofeedbackタイマーを少なくとも4倍の往復時間推定値に設定することを指定します。NoFeedbackタイマーが期限切れになる前に送信者がフィードバックパケットを受け取らない場合、送信者は送信率を半分にします。図では、送信者はフィードバックメッセージa（時間1）を受信し、nofeedbackタイマーを約4回の往復時間（時間4）に期限切れにするように設定します。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.
DCCPのセキュリティ上の考慮事項は[RFC4340]で議論されており、TFRCのセキュリティ上の考慮事項は[RFC3448]、セクション9で議論されています。TFRCのセキュリティ上の考慮事項には、スプーフィングされたフィードバックから保護する必要性と、混雑制御メカニズムを保護する必要性が含まれます。受信機からの誤った情報に対して。
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 Nonce情報を送信者に返します。ECNが使用されない場合、セクション9が示しているように、送信者は渋滞を報告するエラーで受信機をキャッチする可能性のあるさまざまな手法を使用できますが、これはECN 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 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オプションタイプレジストリの各エントリには、CCID 3固有のオプションタイプが含まれています。これは範囲128-255の数字です。「損失間隔」などのオプションの名前。オプションタイプを定義するRFCへの参照。レジストリは、セクション8の表1の値を使用して最初に入力されます。このドキュメントは、オプションタイプ192-194を割り当て、オプションタイプ184-190および248-254は、実験およびテストの使用のために永続的に予約されています。残りのオプションタイプ（128-183、191、195-247、および255）は現在予約されており、IESGのレビューと承認、および標準トラックIETF RFC 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への参照。レジストリは、セクション8の表2の値を使用して最初に入力されます。このドキュメントには、機能番号192が割り当てられ、機能番号184-190および248-254は、実験およびテストの使用のために永続的に予約されています。残りの機能番号（128-183、191、193-247、および255）は現在予約されており、IESGのレビューと承認、および標準トラックIETF RFC 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.
CCID 3を定義する際に助けてくれたマークハンドリーに感謝します。マークオールマン、アーロンフォーク、ラダンガライ、サラカールバーグ、グレッグミンショール、アルンベンカタラマニ、デビッドフォス、ユフェイワン、マグナスウェスターランド、およびDCCPワーキンググループのメンバーにも感謝します。このドキュメントのバージョンに関するフィードバック。
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. 送信者の送信者の制限は、ある往復時間から次の往復時間まで（または、より具体的には、送信率を前の往復時間に報告された受信率の最大2倍に制限する）までの制限です）。
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. 4回の往復時間のアイドル期間後に許可された送信率を半分にすることの制限（おそらく、往復時間ごとに2〜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].
5. [RFC3448]で使用される応答関数、セクション3.1。これは、パケットドロップレートが高い環境でのTCPの動作と密接に一致しません[RFC3714]。
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回の往復時間の古い送信率を維持できます。1つの可能性は、8つの小さなパケットの最初のウィンドウで、フィードバックなしで2つの往復の後に送信率が低下するため、最初の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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Allman、M.、Paxson、V。、およびW. Stevens、「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.
[RFC3168] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, October 2002.
[RFC3390] Allman、M.、Floyd、S。、およびC. Partridge、「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] Handley、M.、Floyd、S.、Padhye、J。、およびJ. Widmer、「TCP Friendry Rate Control（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] Kohler、E.、Handley、M。、およびS. Floyd、「Datagramうっ血制御プロトコル（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] Spring、N.、Wetherall、D。、およびD. Ely、「Noncesによる堅牢な明示的な混雑通知（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] Floyd、S。およびJ. Kempf、「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] Floyd、S。およびE. Kohler、「データグラムの混雑制御プロトコルのプロファイル（DCCP）混雑制御ID 2：TCP様渋滞制御」、RFC 4341、2006年3月。
[V03] Arun Venkataramani, August 2003. Citation for acknowledgement purposes only.
[V03] Arun Venkataramani、2003年8月。謝辞のみの引用のみ。
Authors' Addresses
著者のアドレス
Sally Floyd ICSI Center for Internet Research 1947 Center Street, Suite 600 Berkeley, CA 94704 USA
サリーフロイドICSIセンターフォーインターネットリサーチ1947センターストリート、スイート600バークレー、カリフォルニア州94704 USA
EMail: floyd@icir.org
Eddie Kohler 4531C Boelter Hall UCLA Computer Science Department Los Angeles, CA 90095 USA
Eddie Kohler 4531C Boelter Hall UCLAコンピューターサイエンス部ロサンゼルス、カリフォルニア州90095 USA
EMail: kohler@cs.ucla.edu
Jitendra Padhye Microsoft Research One Microsoft Way Redmond, WA 98052 USA
Jitendra Padhye Microsoft Research One Microsoft Way Redmond、WA 98052 USA
EMail: padhye@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。