[要約] RFC 5622は、DCCPのCongestion ID 4で使用されるTFRC-SPプロファイルに関するものです。TFRC-SPは、小さいパケットに対してTCPに似たレート制御を提供することを目的としています。
Network Working Group S. Floyd
Request for Comments: 5622 ICIR
Category: Experimental E. Kohler
UCLA
August 2009
Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)
データグラムのプロファイル混雑制御プロトコル（DCCP）混雑ID 4：小さなパケットのTCPフレンドリーレートコントロール（TFRC-SP）
Abstract
概要
This document specifies a profile for Congestion Control Identifier 4, the small-packet variant of TCP-Friendly Rate Control (TFRC), in the Datagram Congestion Control Protocol (DCCP). CCID 4 is for experimental use, and uses TFRC-SP (RFC 4828), a variant of TFRC designed for applications that send small packets. CCID 4 is considered experimental because TFRC-SP is itself experimental, and is not proposed for widespread deployment in the global Internet at this time. The goal for TFRC-SP is to achieve roughly the same bandwidth in bits per second (bps) as a TCP flow using packets of up to 1500 bytes but experiencing the same level of congestion. CCID 4 is for use for senders that send small packets and would like a TCP-friendly sending rate, possibly with Explicit Congestion Notification (ECN), while minimizing abrupt rate changes.
このドキュメントは、Datagramうっ血制御コントロールプロトコル（DCCP）で、TCPフレンドリーレートコントロール（TFRC）の小パケットバリアントである輻輳制御識別子識別子のプロファイルを指定します。CCID 4は実験的な使用に向けており、小さなパケットを送信するアプリケーション用に設計されたTFRCのバリアントであるTFRC-SP（RFC 4828）を使用します。TFRC-SPはそれ自体が実験的であり、現時点ではグローバルインターネットでの広範な展開については提案されていないため、CCID 4は実験的と見なされます。TFRC-SPの目標は、最大1500バイトのパケットを使用して同じレベルの輻輳を経験するTCPフローとほぼ同じ帯域幅（BPS）を達成することです。CCID 4は、小さなパケットを送信する送信者に使用し、おそらく明示的な渋滞通知（ECN）を使用して、TCPフレンドリーな送信レートを望み、急激なレートの変更を最小限に抑えます。
Status of This Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions .....................................................4
3. Usage ...........................................................4
3.1. Relationship with TFRC and TFRC-SP .........................5
3.2. Example Half-Connection ....................................5
4. Connection Establishment ........................................6
5. Congestion Control on Data Packets ..............................6
5.1. Response to Idle and Application-Limited Periods ...........7
5.2. Response to Data Dropped and Slow Receiver .................7
5.3. Packet Sizes ...............................................7
6. Acknowledgements ................................................8
6.1. Loss Interval Definition ...................................8
6.2. Congestion Control on Acknowledgements .....................8
6.3. Acknowledgements of Acknowledgements .......................8
6.4. Quiescence .................................................8
7. Explicit Congestion Notification ................................8
8. Options and Features ............................................9
8.1. Window Counter Value ......................................10
8.2. Elapsed Time Options ......................................10
8.3. Receive Rate Option .......................................10
8.4. Send Loss Event Rate Feature ..............................10
8.5. Loss Event Rate Option ....................................11
8.6. Loss Intervals Option .....................................11
8.7. Dropped Packets Option ....................................11
8.7.1. Example ............................................13
9. Verifying Congestion Control Compliance with ECN ...............14
9.1. Verifying the ECN Nonce Echo ..............................14
9.2. Verifying the Reported Loss Intervals and Loss
Event Rate ................................................14
10. Implementation Issues .........................................14
10.1. Timestamp Usage ..........................................14
10.2. Determining Loss Events at the Receiver ..................15
10.3. Sending Feedback Packets .................................15
11. Design Considerations .........................................15
11.1. The Field Size in the Loss Intervals Option ..............15
11.2. The Field Size in the Dropped Packets Option .............16
12. Experimental Status of This Document ..........................17
13. Security Considerations .......................................17
14. IANA Considerations ...........................................17
14.1. Reset Codes ..............................................17
14.2. Option Types .............................................17
14.3. Feature Numbers ..........................................18
15. Thanks ........................................................18
16. References ....................................................18
16.1. Normative References .....................................18
16.2. Informative References ...................................19
List of Tables
テーブルのリスト
Table 1: DCCP CCID 4 Options .......................................9
Table 2: DCCP CCID 4 Feature Numbers ...............................9
This document specifies an experimental profile for Congestion Control Identifier 4, TCP-Friendly Rate Control for Small Packets (TFRC-SP), in the Datagram Congestion Control Protocol (DCCP) [RFC4340]. CCID 4 is a modified version of Congestion Control Identifier 3, CCID 3, which has been specified in [RFC4342]. This document assumes that the reader is familiar with CCID 3, instead of repeating from that document unnecessarily.
このドキュメントは、Datagram輻輳制御プロトコル（DCCP）[RFC4340]で、小パケットのTCPフレンドリーレートコントロール（TFRC-SP）の輻輳制御識別子識別子4の実験プロファイルを指定します。CCID 4は、[RFC4342]で指定されている輻輳制御識別子3、CCID 3の修正バージョンです。このドキュメントは、読者が不必要にそのドキュメントから繰り返すのではなく、CCID 3に精通していることを前提としています。
CCID 3 uses TCP-Friendly Rate Control (TFRC), which is now specified in RFC 5348 [RFC5348]. CCID 4 differs from CCID 3 in that CCID 4 uses TFRC-SP [RFC4828], an experimental, small-packet variant of TFRC. The original specification of TFRC, RFC 3448 [RFC3448], has been obsoleted by RFC 5348. The CCID 3 and TFRC-SP documents both predate RFC 5348 and refer instead to RFC 3448 for the specification of TFRC. However, this document assumes that RFC 5348 will be used instead of RFC 3448 for the specification of TFRC.
CCID 3は、現在RFC 5348 [RFC5348]で指定されているTCPフレンドリーレートコントロール（TFRC）を使用しています。CCID 4は、CCID 4がTFRCの実験的で小パケットバリアントであるTFRC-SP [RFC4828]を使用するという点でCCID 3とは異なります。TFRCの元の仕様であるRFC 3448 [RFC3448]は、RFC 5348によって廃止されています。CCID3およびTFRC-SPドキュメントは両方ともRFC 5348より前のドキュメントで、代わりにTFRCの仕様についてはRFC 3448を参照してください。ただし、このドキュメントでは、TFRCの仕様にはRFC 3448の代わりにRFC 5348が使用されると想定しています。
CCID 4 differs from CCID 3 only in the following respects:
CCID 4は、CCID 3とは次の点でのみ異なります。
o Header size: For TFRC-SP, the allowed transmit rate in bytes per second is reduced by a factor that accounts for packet header size. This is specified for TFRC-SP in Section 4.2 of [RFC4828], and described for CCID 4 in Section 5 below.
o ヘッダーサイズ：TFRC-SPの場合、許可された送信率は、パケットヘッダーサイズを説明する係数によって減少します。これは、[RFC4828]のセクション4.2のTFRC-SPに指定され、以下のセクション5のCCID 4について説明します。
o Maximum sending rate: TFRC-SP enforces a minimum interval of 10 milliseconds between data packets. This is specified for TFRC-SP in Section 4.3 of [RFC4828], and described for CCID 4 in Section 5 below.
o 最大送信レート：TFRC-SPは、データパケット間で10ミリ秒の最小間隔を強制します。これは、[RFC4828]のセクション4.3のTFRC-SPに指定され、以下のセクション5のCCID 4について説明します。
o Loss rates for short loss intervals: For short loss intervals of at most two round-trip times (RTTs), the loss rate is computed by counting the actual number of packets lost or marked. For such a short loss interval with N data packets, including K lost or marked data packets, the loss interval length is calculated as N/K, instead of as N. This is specified for TFRC-SP in Section 4.4 of [RFC4828]. If the sender is computing the loss event rate, the Dropped Packets option specified in Section 8.7 is required, in addition to the default CCID 3's Loss Intervals option. Section 8.7 describes the use of the Dropped Packets option in calculating the loss event rate. The computation of the loss rate by the receiver for the Loss Event Rate option is described for CCID 4 in Section 8.4 below.
o 短い損失間隔の損失率：最大2つの往復時間（RTT）の短い損失間隔では、損失率は、失われたパケットの実際の数をカウントすることによって計算されます。Kの紛失またはマークされたデータパケットを含むnデータパケットを使用したこのような短い損失間隔では、[RFC4828]のセクション4.4でTFRC-SPに指定されているのではなく、損失間隔の長さがn/kとして計算されます。送信者が損失イベント率を計算している場合、デフォルトのCCID 3の損失間隔オプションに加えて、セクション8.7で指定されたドロップされたパケットオプションが必要です。セクション8.7では、損失イベント率の計算におけるドロップされたパケットオプションの使用について説明します。損失イベント率オプションのレシーバーによる損失率の計算については、以下のセクション8.4のCCID 4について説明します。
o The nominal segment size: In TFRC-SP, the nominal segment size used by the TCP throughput equation is set to 1460 bytes. This is specified for TFRC-SP in Section 4.5 of [RFC4828], and described for CCID 4 in Section 5 below.
o 名目セグメントサイズ：TFRC-SPでは、TCPスループット方程式で使用される名目セグメントサイズが1460バイトに設定されています。これは、[RFC4828]のセクション4.5のTFRC-SPに指定され、以下のセクション5のCCID 4について説明します。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
Additional terminology is described in Section 2 of [RFC4342].
追加の用語は、[RFC4342]のセクション2で説明されています。
Like CCID 3, CCID 4's 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.
CCID 3と同様に、CCID 4の混雑制御は、再生前に小型または中程度のレシーバーバッファリングを備えたストリーミングメディアアプリケーションを含む、送信率の急激な変化を最小限に抑えることを好むフローに適しています。
CCID 4 is designed to be used either by applications that use a small fixed segment size, or by applications that change their sending rate by varying the segment size. If CCID 4 is used by an application that varies its segment size in response to changes in the allowed sending rate in bps, we note that CCID 4 doesn't dictate the segment size to be used by the application; this is done by the application itself. The CCID 4 sender determines the allowed sending rate in bps, in response to on-going feedback from the CCID 4 receiver, and the application can use information about the current allowed sending rate to decide whether to change the current segment size.
CCID 4は、小さな固定セグメントサイズを使用するアプリケーション、またはセグメントサイズを変化させることで送信率を変更するアプリケーションのいずれかによって使用されるように設計されています。CCID 4が、BPSの許可された送信率の変更に応じてセグメントサイズを変えるアプリケーションで使用されている場合、CCID 4はアプリケーションで使用されるセグメントサイズを決定しないことに注意してください。これは、アプリケーション自体によって行われます。CCID 4送信者は、CCID 4レシーバーからの継続的なフィードバックに応じて、BPSの送信レートを決定し、アプリケーションは電流が許可されているレートに関する情報を使用して、現在のセグメントサイズを変更するかどうかを決定できます。
We note that in some environments, there will be a feedback loop, with changes in the packet size or in the sending rate in bps affecting congestion along the path, therefore affecting the allowed sending rate in the future.
一部の環境では、パケットサイズまたはBPSの送信速度がパスに沿った混雑に影響するため、フィードバックループがあるため、将来の送信許可レートに影響することに注意してください。
The congestion control mechanisms described here follow the TFRC-SP mechanism specified in [RFC4828]. As with CCID 3, conformant CCID 4 implementations MAY track updates to the TCP throughput equation directly, as updates are standardized in the IETF, rather than waiting for revisions of this document. This document is based on CCID 3 [RFC4342], TFRC, and TFRC-SP. For TFRC, RFC 3448 [RFC3448] has been obsoleted by RFC 5348 [RFC5348].
ここで説明する混雑制御メカニズムは、[RFC4828]で指定されたTFRC-SPメカニズムに従います。CCID 3と同様に、コンフォーマントCCID 4実装は、このドキュメントの改訂を待つのではなく、IETFで更新が標準化されるため、TCPスループット方程式の更新を直接追跡する場合があります。このドキュメントは、CCID 3 [RFC4342]、TFRC、およびTFRC-SPに基づいています。TFRCの場合、RFC 3448 [RFC3448]はRFC 5348 [RFC5348]によって廃止されました。
This example shows the typical progress of a half-connection using CCID 4's TFRC Congestion Control, not including connection initiation and termination. The example is informative, not normative. This example differs from that for CCID 3 in [RFC4342] only in one respect; with CCID 4, the allowed transmit rate is determined by [RFC4828] as well as by [RFC5348].
この例は、接続の開始と終了を含まないCCID 4のTFRC混雑制御を使用したハーフ接続の典型的な進行を示しています。この例は有益であり、規範ではありません。この例は、[RFC4342]のCCID 3の例とは1つの点でのみ異なります。CCID 4では、許容される送信率は[RFC4828]と[RFC5348]によって決定されます。
1. The sender transmits DCCP-Data packets, where the sending rate is governed by the allowed transmit rate as specified in [RFC4828]. Each DCCP-Data packet has a sequence number, and the DCCP header's CCVal field contains the window counter value, used by the receiver in determining when multiple losses belong in a single loss event.
1. 送信者は、[RFC4828]で指定されているように、送信率が許容される送信率によって支配されるDCCP-DATAパケットを送信します。各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 [RFC5348] (Section 6). Each DCCP-Ack packet uses a sequence number, identifying the most recent packet received from the sender and includes feedback about the recent loss intervals experienced by the receiver.
2. 受信者はDCCP-ackパケットを送信し、往復時間ごとに送信者が1パケット未満のレートで送信しない限り、ラウンドトリップ時間ごとに少なくとも1回データパケットを認めます[RFC5348]（セクション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 [RFC5348] (Section 4.3) and [RFC4828]. This update is based upon a loss event rate calculated by the sender, based on the receiver's loss-interval feedback. If it prefers, the sender can also use a loss event rate calculated and reported by the receiver.
3. 送信者は、許可された送信率によって制御されるように、DCCP-DATAパケットの送信を続けます。DCCP-CACKパケットを受信すると、送信者は[RFC5348]（セクション4.3）および[RFC4828]で指定されているように、許可された送信率を更新します。このアップデートは、受信者の損失間型フィードバックに基づいて、送信者によって計算された損失イベント率に基づいています。それが好まれる場合、送信者は、計算およびレシーバーによって計算され報告された損失イベント率を使用することもできます。
4. The sender estimates round-trip times and calculates a nofeedback time, as specified in [RFC5348] (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. 送信者は、[RFC5348]で指定されているように、往復時間を推定し、ノーフィードバック時間を計算します（セクション4.4）。その時点でレシーバーからフィードバックが受け取られていない場合（少なくとも4回の往復時間）、送信者は送信率を半分にします。
The connection establishment is as specified in Section 4 of [RFC4342].
接続確立は、[RFC4342]のセクション4で指定されているとおりです。
CCID 4 uses the congestion control mechanisms of TFRC [RFC5348] and TFRC-SP [RFC4828]. [RFC4828] MUST be considered normative except where specifically indicated.
CCID 4は、TFRC [RFC5348]およびTFRC-SP [RFC4828]の輻輳制御メカニズムを使用しています。[RFC4828]は、具体的に示されている場合を除き、規範的と見なされなければなりません。
Loss Event Rate
損失イベント率
As with CCID 3, the basic operation of CCID 4 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. For CCID 4, this loss event rate, a round-trip time estimate, and a nominal packet size of 1460 bytes are plugged into the TCP throughput equation, as specified in RFC 5348 (Section 3.1) and [RFC4828].
CCID 3と同様に、CCID 4の基本的な動作は、損失イベント率の計算に集中します。送信されたパケットの数の一部としての損失イベントの数は、最後のいくつかの損失間隔で重み付けされています。CCID 4の場合、この損失イベント率、往復時間推定、および1460バイトの名目パケットサイズは、RFC 5348（セクション3.1）および[RFC4828]で指定されているように、TCPスループット方程式に差し込まれます。
Because CCID 4 is intended for applications that send small packets, the allowed transmit rate derived from the TCP throughput equation is reduced by a factor that accounts for packet header size, as specified in Section 4.2 of [RFC4828]. The header size on data packets is estimated as 36 bytes (20 bytes for the IPv4 header and 16 bytes for the DCCP-Data header with 48-bit sequence numbers). If the DCCP sender is sending N-byte data packets, the allowed transmit rate is reduced by N/(N+36). CCID 4 senders are limited to this fair rate. The header size would be 32 bytes instead of 36 bytes when 24-bit sequence numbers were used in the DCCP-Data header.
CCID 4は小さなパケットを送信するアプリケーションを対象としているため、[RFC4828]のセクション4.2で指定されているように、TCPスループット方程式から導出された許可された送信速度は、パケットヘッダーサイズを説明する因子によって減少します。データパケットのヘッダーサイズは、36バイト（IPv4ヘッダーで20バイト、48ビットシーケンス番号を持つDCCP-DATAヘッダーの16バイト）として推定されます。DCCP送信者がnバイトデータパケットを送信している場合、許容される送信率はn/（n 36）によって低下します。CCID 4の送信者は、この公正な料金に限定されています。ヘッダーサイズは、DCCP-DATAヘッダーで24ビットシーケンス番号が使用された場合、36バイトではなく32バイトになります。
As explained in Section 4.2 of [RFC4828], the actual header could be larger or smaller than the assumed value due to IP or DCCP options, IPv6, IP tunnels, header compression, and the like. Because we are only aiming at rough fairness, and at a rough incentive for applications, the default use of a 32-byte or 36-byte header in the calculations of the header bandwidth is sufficient for both IPv4 and IPv6.
[RFC4828]のセクション4.2で説明したように、実際のヘッダーは、IPまたはDCCPオプション、IPv6、IPトンネル、ヘッダー圧縮などにより、想定値よりも大きくまたは小さくなる可能性があります。私たちは大まかな公平性のみを目指しているため、アプリケーションの大まかなインセンティブでは、ヘッダー帯域幅の計算で32バイトまたは36バイトのヘッダーのデフォルト使用で十分です。
If the sender is calculating the loss event rate itself, the loss event rate can be calculated using recent loss interval lengths reported by the receiver. Loss intervals are precisely defined in Section 6.1 of [RFC4342], with the modification in [RFC4828] (Section 3) for loss intervals of at most two round-trip times. 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. The CCID 3 Loss Intervals option is used to report loss interval lengths; see Section 8.6.
送信者が損失イベント率自体を計算している場合、レシーバーが報告した最近の損失間隔の長さを使用して損失イベント率を計算できます。損失間隔は[RFC4342]のセクション6.1で正確に定義されており、[RFC4828]（セクション3）の変更は、最大2回の往復時間の損失間隔についてです。要約すると、損失間隔は、最大1 RTTの紛失またはECNマークされたデータパケットの続きで、その後、任意の数の非ドロップされたマークされていないデータパケットが続きます。CCID 3損失間隔オプションは、損失間隔の長さを報告するために使用されます。セクション8.6を参照してください。
For loss intervals of at most two round-trip times, CCID 4 calculates the loss event rate for that interval by counting the number of packets lost or marked, as described in Section 4.4 of [RFC4828]. Thus, for such a short loss interval with N data packets, including K lost or marked data packets, the loss interval length is calculated as N/K, instead as N. The Dropped Packets option is used to report K, the count of lost or marked data packets.
最大2回の往復時間の損失間隔では、CCID 4は、[RFC4828]のセクション4.4で説明されているように、失われたまたはマークされたパケットの数をカウントすることにより、その間隔の損失イベント率を計算します。したがって、Kの紛失またはマークされたデータパケットを含むnデータパケットを使用したこのような短い損失間隔では、代わりにN/kとして損失間隔の長さが計算されます。ドロップされたパケットオプションは、失われたkを報告するために使用されます。またはマークされたデータパケット。
Unlike CCID 3, the CCID 4 sender enforces a minimum interval of 10 ms between data packets, regardless of the allowed transmit rate. If operating system scheduling granularity makes this impractical, up to one additional packet MAY be sent per timeslice, providing that no more than three packets are sent in any 30 ms interval.
CCID 3とは異なり、CCID 4 Senderは、許可された送信率に関係なく、データパケット間で10ミリ秒の最小間隔を実施します。オペレーティングシステムのスケジューリングのGranularityがこれを非現実的にする場合、タイムスライスごとに最大1つの追加パケットを送信することができ、30ミリ秒の間隔で3つのパケットが送信されないことを条件とします。
Other Congestion Control Mechanisms
その他の混雑制御メカニズム
The other congestion control mechanisms such as slow-start and feedback packets are exactly as in CCID 3, and are described in the subsection on "Other Congestion Control Mechanisms" of Section 5 in [RFC4342].
スロースタートパケットやフィードバックパケットなどの他の輻輳制御メカニズムは、CCID 3とまったく同じであり、[RFC4342]のセクション5の「他の混雑制御メカニズム」に関するサブセクションで説明されています。
This is described in Section 5.1 of [RFC4342]. If Faster Restart is standardized in the IETF for TFRC [KFS07], then Faster Restart MAY be implemented in CCID4 without having to wait for an explicit update to this document.
これは、[RFC4342]のセクション5.1で説明されています。TFRC [KFS07]のIETFでより高速な再起動が標準化されている場合、このドキュメントの明示的な更新を待つことなく、CCID4でより速い再起動を実装できます。
This is described in Section 5.2 of [RFC4342].
これは、[RFC4342]のセクション5.2で説明されています。
CCID 4 is intended for applications that use a fixed small segment size, or that vary their segment size in response to congestion.
CCID 4は、固定された小さなセグメントサイズを使用するアプリケーション、またはうっ血に応じてセグメントサイズを変えるアプリケーションを対象としています。
The CCID 4 sender uses a segment size of 1460 bytes in the TCP throughput equation. This gives the CCID 4 sender roughly the same sending rate in bytes per second as a TFRC flow using 1460-byte segments but experiencing the same packet drop rate.
CCID 4送信者は、TCPスループット方程式で1460バイトのセグメントサイズを使用します。これにより、CCID 4 Senderは、1460バイトセグメントを使用して同じパケットドロップレートを使用してTFRCフローとほぼ同じ送信レートを1秒あたりにバイトに与えます。
The acknowledgements are as specified in Section 6 of [RFC4342] with the exception of the Loss Interval lengths specified below.
謝辞は、[RFC4342]のセクション6で指定されているとおりです。
The loss interval definition is as defined in Section 6.1 of [RFC4342], except as specified below. Section 6.1.1 of RFC 4342 specifies that for all loss intervals except the first one, the data length equals the sequence length minus the number of non-data packets the sender transmitted during the loss interval, with a minimum data length of one packet. For short loss intervals of at most two round-trip times, TFRC-SP computes the loss interval length as the data length divided by the number of dropped or marked data packets (rather than as the data length of the loss interval).
損失間隔の定義は、[RFC4342]のセクション6.1で定義されているとおりです。ただし、以下に指定されている場合を除きます。RFC 4342のセクション6.1.1は、最初のものを除くすべての損失間隔について、データの長さがシーケンス長に等しく、損失間隔中に送信された非DATAパケットの数を差し引いて、1つのパケットの最小データ長で送信されることを指定します。最大2回の往復時間の短い損失間隔では、TFRC-SPは、データの長さを削除またはマークされたデータパケットの数（損失間隔のデータ長としてではなく）で割ったため、損失間隔の長さを計算します。
Section 5.4 of RFC 4342 describes when to use the most recent loss interval in the calculation of the average loss interval. [RFC4828] adds to this procedure the restriction that the most recent loss interval is only used in the calculation of the average loss interval if the most recent loss interval is greater than two round-trip times. The pseudocode is given in Section 3 of [RFC4828].
RFC 4342のセクション5.4では、平均損失間隔の計算で最新の損失間隔をいつ使用するかについて説明します。[RFC4828]は、最新の損失間隔が2回の往復時間を超える場合、最新の損失間隔が平均損失間隔の計算でのみ使用されるという制限をこの手順に追加します。擬似コードは[RFC4828]のセクション3に示されています。
The congestion control on acknowledgements is as specified in Section 6.2 of [RFC4342].
謝辞に関する混雑制御は、[RFC4342]のセクション6.2で指定されているとおりです。
Procedures for the acknowledgement of acknowledgements are as specified in Section 6.3 of [RFC4342].
謝辞の謝辞の手順は、[RFC4342]のセクション6.3で指定されているとおりです。
The procedure for detecting that the sender has gone quiescent is as specified in Section 6.4 of [RFC4342].
送信者が静止したことを検出する手順は、[RFC4342]のセクション6.4で指定されているとおりです。
Procedures for the use of Explicit Congestion Notification (ECN) are as specified in Section 7 of [RFC4342].
明示的な混雑通知（ECN）の使用手順は、[RFC4342]のセクション7で指定されているとおりです。
CCID 4 can make use of DCCP's Ack Vector, Timestamp, Timestamp Echo, and Elapsed Time options, and its Send Ack Vector and ECN Incapable features. CCID 4 also imports the currently defined CCID-3-specific options and features [RFC4342], augmented by the Dropped Packets option specified in this document. Each CCID4-specific option and feature contains the same data as the corresponding CCID 3 option or feature, and is interpreted in the same way, except as specified elsewhere in this document (or in a subsequent IETF standards-track RFC that updates or obsoletes this specification).
CCID 4は、DCCPのACKベクター、タイムスタンプ、タイムスタンプエコー、およびELAPSED TIMEオプション、およびその送信ACKベクターとECNの不能な機能を使用できます。CCID 4は、現在定義されているCCID-3固有のオプションと機能[RFC4342]をインポートし、このドキュメントで指定されたドロップされたパケットオプションによって補強されています。各CCID4固有のオプションと機能には、対応するCCID 3オプションまたは機能と同じデータが含まれており、このドキュメントの他の場所（またはこれを更新または廃止する後続のIETF標準トラックRFCで指定されている場合を除き、同じ方法で解釈されます。仕様）。
Option DCCP- Section
Type Length Meaning Data? Reference
----- ------ ------- ----- ---------
128-183 Unassigned
184-190 Reserved for
experimental
and testing use
191 Unassigned
192 6 Loss Event Rate N 8.5
193 variable Loss Intervals N 8.6
194 6 Receive Rate N 8.3
195 variable Dropped Packets N 8.7
196-247 Unassigned
248-254 Reserved for
experimental
and testing use
255 Unassigned
Table 1: DCCP CCID 4 Options
表1：DCCP CCID 4オプション
The "DCCP-Data?" column indicates that all currently defined CCID4- specific options MUST be ignored when they occur on DCCP-Data packets.
「dccp-data？」列は、DCCP-DATAパケットで発生する場合、現在定義されているすべてのCCID4固有のオプションを無視する必要があることを示しています。
As with CCID 3, the following CCID-specific features are also defined.
CCID 3と同様に、次のCCID固有の機能も定義されています。
Number Meaning Rule Value Req'd Reference
------ ------- ----- ----- ----- ---------
128-183 Unassigned
184-190 Reserved for experimental
and testing use
191 Unassigned
192 Send Loss Event Rate SP 0 N 8.4
193-247 Unassigned
248-254 Reserved for experimental
and testing use
255 Unassigned
Table 2: DCCP CCID 4 Feature Numbers
表2：DCCP CCID 4機能番号
More information is available in Section 8 of [RFC4342].
詳細については、[RFC4342]のセクション8をご覧ください。
The use of the Window Counter Value in the DCCP generic header's CCVal field is as specified in Section 8.1 of [RFC4342]. In addition to their use described in CCID 3, the CCVal counters are used by the receiver in CCID 4 to determine when the length of a loss interval is at most two round-trip times. None of these procedures require the receiver to maintain an explicit estimate of the round-trip time. However, Section 8.1 of [RFC4342] gives a procedure that implementors may use if they wish to keep such an RTT estimate using CCVal.
DCCPジェネリックヘッダーのCCVALフィールドでのウィンドウカウンター値の使用は、[RFC4342]のセクション8.1で指定されているとおりです。CCID 3で説明されているそれらの使用に加えて、CCVALカウンターはCCID 4のレシーバーによって使用され、損失間隔の長さが最大2回の往復時間であるかを判断します。これらの手順のいずれも、受信者が往復時間の明示的な推定値を維持する必要はありません。ただし、[RFC4342]のセクション8.1は、CCVALを使用してそのようなRTT推定を維持したい場合に実装者が使用できる手順を示しています。
The use of the Elapsed Time option is defined in Section 8.2 of [RFC4342].
Elapsed Timeオプションの使用は、[RFC4342]のセクション8.2で定義されています。
The Receive Rate option is as specified in Section 8.3 of [RFC4342].
受信料オプションは、[RFC4342]のセクション8.3で指定されているとおりです。
The Send Loss Event Rate feature is as defined in Section 8.4 of [RFC4342].
送信損失イベントレート機能は、[RFC4342]のセクション8.4で定義されています。
See [RFC5348], Section 5, and [RFC4828], Section 4.4, for a normative calculation of the loss event rate. Section 4.4 of [RFC4828] modifies the calculation of the loss interval size for loss intervals of at most two round-trip times.
損失イベント率の規範的計算については、[RFC5348]、セクション5、および[RFC4828]、セクション4.4を参照してください。[RFC4828]のセクション4.4は、最大2回の往復時間の損失間隔の損失間隔の計算を変更します。
If the CCID 4 receiver is using the Loss Event Rate option, the receiver needs to be able to determine if a loss interval is short, of at most two round-trip times. The receiver can heuristically detect a short loss interval by using the Window Counter in arriving data packets. The sender increases the Window Counter by 1 every quarter of a round-trip time, with the caveat that the Window Counter is never increased by more than five, modulo 16, from one data packet to the next. Using the Window Counter to detect loss intervals of at most two round-trip times could result in some false positives, with some longer loss intervals incorrectly identified as short ones. For example, if the loss interval contained data packets with only two Window Counter values, say, k and k+5, then the receiver could not tell if the loss interval was at most two round-trip times long or not. Similarly, if the sender sent data packets with Window Counter values of 4, 8, 12, 0, 5, but the packets with Window Counter values of 8, 12, and 0 were lost in the network, then the receiver would only receive data packets with Window Counter values of 4 and 5, and would incorrectly infer that the loss interval was at most two round-trip times.
CCID 4レシーバーが損失イベントレートオプションを使用している場合、レシーバーは、最大2回の往復時間の損失間隔が短いかどうかを判断できる必要があります。レシーバーは、データパケットの到着時にウィンドウカウンターを使用して、短い損失間隔をヒューリスティックに検出できます。送信者は、ウィンドウカウンターが5つ以上のデータパケットから次のデータパケットまで5つ以上増加することはないという警告を使用して、往復時間の四半期ごとに1つのウィンドウカウンターを増やします。ウィンドウカウンターを使用して、最大2回の往復時間の損失間隔を検出すると、いくつかの誤検知が生じる可能性があり、いくつかの長い損失間隔が短いものと誤って識別されます。たとえば、損失間隔に2つのウィンドウカウンター値（たとえばKとK 5のみのデータパケットが含まれていた場合、レシーバーは損失間隔が最大2回の往復時間であるかどうかを判断できませんでした。同様に、送信者がウィンドウカウンター値が4、8、12、0、5のデータパケットを送信したが、8、12、および0のウィンドウカウンター値を持つパケットがネットワークで失われた場合、レシーバーはデータのみを受信しますウィンドウカウンター値は4と5のパケットであり、損失間隔が最大2回の往復時間であったことを誤って推測します。
The Loss Event Rate option is as specified in Section 8.5 of [RFC4342].
損失イベント率オプションは、[RFC4342]のセクション8.5で指定されているとおりです。
See [RFC5348] (Section 5) and [RFC4828] for a normative calculation of the loss event rate.
損失イベント率の規範的計算については、[RFC5348]（セクション5）および[RFC4828]を参照してください。
The Loss Intervals option is as specified in Section 8.6 of [RFC4342].
損失間隔オプションは、[RFC4342]のセクション8.6で指定されているとおりです。
This section describes the Dropped Packets option, a mechanism for reporting the number of lost and marked packets per loss interval. By reporting both the Loss Intervals and Dropped Packets options on the feedback packets, the receiver gives the sender sufficient information to calculate the loss event rate, or to verify the calculation of the reported loss event rate, if the sender so desires.
このセクションでは、ドロップされたパケットオプションについて説明します。これは、損失間隔ごとに失われたパケットとマークされたパケットの数を報告するメカニズムについて説明します。フィードバックパケットに損失間隔とドロップされたパケットオプションの両方を報告することにより、受信者は送信者に損失イベント率を計算するか、報告された損失イベント率の計算を検証するのに十分な情報を提供します。
The core information reported by CCID 4 receivers is a list of recent loss intervals, where 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. Loss intervals model the congestion behavior of TCP NewReno senders, which reduce their sending rate at most once per window of data packets. Consequently, the number of packets lost in a loss interval is not important for either TCP's or TFRC's congestion response. CCID 3's Loss Intervals option reports the length of each loss interval's lossy part, not the number of packets that were actually lost or marked in that lossy part.
CCID 4レシーバーによって報告されたコア情報は、最近の損失間隔のリストであり、損失間隔は紛失またはECNマークされたデータパケットから始まります。紛失またはマークされている可能性のある、またはマークされていない場合があるパケットの最大1つの往復時間のパケットを続けます。任意の長いシリーズの一連のドロップされていないマーク化されていないデータパケットで完了します。損失間隔は、TCP Newreno送信者の輻輳動作をモデル化し、データパケットのウィンドウごとにせいぜい1回の送信率を低下させます。その結果、損失間隔で失われたパケットの数は、TCPまたはTFRCの輻輳応答のいずれにとっても重要ではありません。CCID 3の損失間隔オプションオプション各損失間隔の損失部分の長さは、その損失部分で実際に失われたりマークされたりしたパケットの数ではありません。
However, for computing the loss event rate for periods that include short loss intervals the TFRC-SP sender needs to know the number of packets lost or marked in a loss interval, over and above the length of the loss interval in packets. The Dropped Packets option, a CCID4-specific option, reports this information. Together with the existing Loss Intervals option, the Dropped Packets option allows the CCID 4 sender to discover exactly how many packets were dropped from each loss interval. The receiver reports the number of lost or marked packets in its recently observed loss intervals using the Dropped Packets option.
ただし、短い損失間隔を含む期間の損失イベント率を計算するために、TFRC-SP送信者は、パケットの損失間隔の長さの上にある損失間隔で失われたりマークされているパケットの数を知る必要があります。CCID4固有のオプションであるドロップされたパケットオプションは、この情報を報告します。既存の損失間隔オプションとともに、ドロップされたパケットオプションを使用すると、CCID 4 Senderが各損失間隔からいくつのパケットが削除されたかを正確に発見できます。受信者は、ドロップされたパケットオプションを使用して、最近観察された損失間隔で失われたパケットまたはマークされたパケットの数を報告します。
The Dropped Packets Option is specified as follows:
ドロップされたパケットオプションは、次のように指定されています。
+--------+--------+-------...-------+--------+-------
|11000011| Length | Drop Count | More Drop Counts...
+--------+--------+-------...-------+--------+-------
Type=195 3 bytes
Figure 1: Dropped Packets Option
図1：ドロップされたパケットオプション
The Dropped Packets option contains information about one to 84 consecutive loss intervals, always including the most recent loss interval. As with the Loss Intervals option, intervals are listed in reverse chronological order. Should more than 84 loss intervals need to be reported, multiple Dropped Packets options can be sent; the second option begins where the first left off, and so forth.
ドロップされたパケットオプションには、最新の損失間隔を含む1〜84連続の損失間隔に関する情報が含まれています。損失間隔オプションと同様に、間隔は逆年代順にリストされます。84を超える損失間隔を報告する必要がある場合、複数のドロップされたパケットオプションを送信できます。2番目のオプションは、最初のオプションから始まります。
One Drop Count is specified per loss interval. Drop Count is a 24- bit number that equals the number of packets, lost or received, ECN-marked during the corresponding loss interval. By definition, this number MUST NOT exceed the corresponding loss interval's Loss Length.
損失間隔ごとに1つのドロップカウントが指定されます。ドロップカウントは、対応する損失間隔中にeCNマークされた、紛失または受信したパケットの数に等しい24ビット数です。定義上、この数値は、対応する損失間隔の損失長を超えてはなりません。
CCID 4 receivers MUST report Dropped Packets options with every feedback packet. Any packet containing a Loss Intervals option MUST also contain a Dropped Packets option covering the same loss intervals. If a feedback packet does not include a relevant Dropped Packets option, and the CCID 4 sender is computing the loss event rate itself, the sender MUST treat the relevant loss intervals' Drop Counts as equal to the corresponding Loss Lengths, as specified below.
CCID 4レシーバーは、フィードバックパケットごとにドロップされたパケットオプションを報告する必要があります。損失間隔オプションを含むパケットは、同じ損失間隔をカバーするドロップされたパケットオプションも含める必要があります。フィードバックパケットに関連するドロップされたパケットオプションが含まれておらず、CCID 4送信者が損失イベントレート自体を計算している場合、送信者は、以下に指定するように、関連する損失間隔のドロップカウントを対応する損失長に等しく扱う必要があります。
Consider a CCID 4 receiver. As specified in Section 8.6.1 of RFC 4342, the receiver sends the Loss Intervals option for all intervals that have not been acknowledged by the sender. When this receiver sends a feedback packet containing information about the N most recent loss intervals (packaged in one or more Loss Intervals options), then the receiver includes on the same feedback packet one or more Dropped Packets options covering exactly those N loss intervals. CCID 4 senders MUST ignore Drop Counts information for loss intervals not covered by a Loss Intervals option on the same feedback packet. Conversely, a CCID 4 sender might want to interpolate Drop Counts information for a loss interval not covered by any Dropped Packets options; such a sender MUST use the corresponding loss interval's Loss Length as its Drop Count.
CCID 4レシーバーを検討してください。RFC 4342のセクション8.6.1で指定されているように、受信者は、送信者によって認められていないすべての間隔で損失間隔オプションを送信します。このレシーバーが、Nの最新の損失間隔に関する情報を含むフィードバックパケットを送信すると（1つ以上の損失間隔オプションでパッケージ化されています）、レシーバーは同じフィードバックパケットに、それらのn損失間隔を正確にカバーする1つ以上のドロップされたパケットオプションを含めます。CCID 4送信者は、同じフィードバックパケットの損失間隔オプションでカバーされていない損失間隔のドロップカウント情報を無視する必要があります。逆に、CCID 4送信者は、ドロップカウント情報を補間したい場合があります。このような送信者は、対応する損失間隔の損失長をドロップカウントとして使用する必要があります。
Each loss interval's Drop Count MUST, by definition, be less than or equal to its Loss Length. A Drop Count that exceeds the corresponding Loss Length MUST be treated as equal to the Loss Length.
各損失間隔のドロップカウントは、定義上、損失長以下でなければなりません。対応する損失長を超えるドロップカウントは、損失長に等しいと扱わなければなりません。
Consider the following sequence of packets, where "-" represents a safely delivered packet and "*" represents a lost or marked packet. This sequence is repeated from [RFC4342].
「 - 」は安全に配信されたパケットを表し、「*」は紛失またはマークされたパケットを表すパケットの次のシーケンスを考えてください。このシーケンスは[RFC4342]から繰り返されます。
Sequence
Numbers: 0 10 20 30 40 44
| | | | | |
----------*--------***-*--------*----------*-
Figure 2: Sequence of Delivered (-) and Lost (*) Packets
図2：配信（ - ）および紛失（*）パケットのシーケンス
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
Figure 3: Loss Intervals for the Packet Sequence
図3：パケットシーケンスの損失間隔
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; for interpretation of this option, see [RFC4342]. A Dropped Packets option sent in tandem on this packet would contain the bytes 195,14, 0,0,1, 0,0,4, 0,0,1, 0,0,0. This 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;このオプションの解釈については、[RFC4342]を参照してください。このパケットにタンデムで送信されたドロップされたパケットオプションには、バイト195,14、0,0,1、0,0,4、0,0,1、0,0,0が含まれます。これは次のように解釈されます。
195 The Dropped Packets option number.
195ドロップされたパケットオプション番号。
14 The length of the option, including option type and length bytes. This option contains information about (14 - 2)/3 = 4 loss intervals. Note that the two most recent sequence numbers are not yet part of any loss interval -- the Loss Intervals option includes them in its Skip Length -- and are thus not included in the Dropped Packets option.
14オプションタイプと長さのバイトを含むオプションの長さ。このオプションには、（14-2）/3 = 4損失間隔に関する情報が含まれています。最新の2つのシーケンス番号は、損失間隔の一部ではないことに注意してください - 損失間隔オプションにはスキップ長に含まれるため、ドロップされたパケットオプションに含まれていません。
0,0,1 These bytes define the Drop Count for L3, which is 1. As required, the Drop Count is less than or equal to L3's Loss Length, which is also 1.
0,0,1これらのバイトは、L3のドロップカウントを定義します。これは1です。必要に応じて、ドロップカウントはL3の損失長以下です。
0,0,4 The Drop Count for L2 is 4.
0,0,4 L2のドロップカウントは4です。
0,0,1 The Drop Count for L1 is 1.
0,0,1 L1のドロップカウントは1です。
0,0,0 Finally, the Drop Count for L0 is 0.
0,0,0最後に、L0のドロップカウントは0です。
Verifying congestion control compliance with ECN is as discussed in Section 9 of [RFC4342].
ECNの混雑制御コンプライアンスの検証は、[RFC4342]のセクション9で説明しているとおりです。
Procedures for verifying the ECN Nonce Echo are as specified in Section 9.1 of [RFC4342].
ECNノンセエコーを検証するための手順は、[RFC4342]のセクション9.1で指定されているとおりです。
Section 9.2 of [RFC4342] discusses the sender's possible verification of loss intervals and loss event rate information reported by the receiver.
[RFC4342]のセクション9.2は、受信者が報告した損失間隔と損失イベント率情報の送信者の可能な検証について説明します。
The use of the Timestamp option is as discussed in Section 10.1 of [RFC4342].
タイムスタンプオプションの使用は、[RFC4342]のセクション10.1で説明したとおりです。
The use of the window counter by the receiver to determine if multiple lost packets belong to the same loss event is as described in Section 10.2 of [RFC4342].
レシーバーによるウィンドウカウンターの使用は、複数の失われたパケットが同じ損失イベントに属しているかどうかを判断します。
The procedure for sending feedback packets is as described in Section 10.3 of [RFC4342].
フィードバックパケットを送信する手順は、[RFC4342]のセクション10.3で説明されているとおりです。
This section discusses design considerations for the field sizes in the Loss Intervals and Dropped Packets options.
このセクションでは、損失間隔のフィールドサイズの設計上の考慮事項とドロップされたパケットオプションについて説明します。
Section 8.6 of RFC 4342 specifies a Loss Intervals option with three fields for each loss interval, for reporting the Lossless Length, Loss Length, and Data Length. Each field is specified to be three bytes. Section 8.6 of this document specifies that CCID 4 use the same Loss Intervals option as CCID 3, with the same field sizes. This has the significant advantage of minimizing the implementation differences between CCID 3 and CCID 4. However, it has been suggested that CCID 4 *could* use a Loss Intervals option with smaller field sizes, since a CCID 4 sender enforces a minimum interval of 10 ms between data packets. This section explains the reason for CCID 4 to use the same Loss Intervals option as specified for CCID 3.
RFC 4342のセクション8.6は、損失の長さ、損失の長さ、およびデータの長さを報告するために、各損失間隔に3つのフィールドを持つ損失間隔オプションを指定します。各フィールドは、3バイトに指定されています。このドキュメントのセクション8.6は、CCID 4が同じフィールドサイズのCCID 3と同じ損失間隔オプションを使用することを指定しています。これには、CCID 3とCCID 4の実装の違いを最小化するという重要な利点があります。ただし、CCID 4 Senderが10の最小間隔を強制するため、CCID 4 *はフィールドサイズの低い損失間隔オプションを使用できることが示唆されています。データパケット間のMS。このセクションでは、CCID 4がCCID 3に指定された同じ損失間隔オプションを使用する理由について説明します。
The Lossless Length field reports the number of packets in the loss intervals' lossless part, and the Loss Length field reports the number of packets in the loss interval's lossy part. The Data Length field reports the number of packets in the loss interval's data length (excluding non-data packets). A two-byte Data Length field can report a data length of 65,536 packets, corresponding to a loss event rate of 0.00002; this is enough to give the CCID 4 sender an allowed sending rate of roughly 250 packets per RTT, which is enough for a connection with a round-trip time of at most 2.5 seconds. For a CCID 4 connection with a larger round-trip time, the three-byte Lossless Length and Data Length fields would be needed.
ロスレスの長さフィールドは、損失間隔のロスレス部分のパケットの数を報告し、損失の長さフィールドは、損失間隔の損失部分のパケットの数を報告します。データの長さフィールドは、損失間隔のデータ長（非DATAパケットを除く）のパケットの数を報告します。2バイトのデータ長さフィールドは、0.00002の損失イベント率に対応する65,536パケットのデータ長を報告できます。これは、CCID 4送信者にRTTあたり約250パケットの送信率を許可するのに十分であり、これは最大2.5秒の往復時間との接続に十分です。より大きな往復時間を伴うCCID 4接続の場合、3バイトの損失レスの長さとデータの長さフィールドが必要になります。
For the Loss Length field in the Loss Intervals option, reporting the number of packets in the one-RTT lossy part of the loss interval, a one-byte field would not be sufficient for a CCID 4 connection with a long RTT (three seconds or longer). For the Loss Length field, a two-byte field should be sufficient for CCID 4. However, our judgement is that the advantages of using the same Loss Intervals option as in CCID 3 outweigh any advantages of using a CCID 4 Loss Intervals option that uses eight bytes instead of nine bytes for reporting the fields for each loss interval.
損失間隔オプションの損失長フィールドの場合、損失間隔の1-RTT損失部分のパケットの数を報告すると、長いRTT（3秒または3秒またはより長いです）。損失の長さフィールドの場合、2バイトフィールドではCCID 4に十分である必要があります。ただし、CCID 3と同じ損失間隔オプションを使用することの利点は、使用するCCID 4損失間隔オプションを使用することの利点を上回るということです。各損失間隔のフィールドを報告するための9バイトの代わりに8バイト。
Section 8.7 specifies the Dropped Packets option for reporting the number of lost or marked packets per loss interval, allocating three bytes for the drop count field for each loss interval reported. The three-byte field is partly for simplicity, to give the same field size as the fields in the Loss Intervals option specified in RFC 4342. It has been suggested that CCID 4 *could* use a smaller field size for the Dropped Packets option. This section discusses the issue of the size of the drop count field in the Dropped Packets option.
セクション8.7は、損失間隔ごとに失われたパケットまたはマークされたパケットの数を報告するためのドロップされたパケットオプションを指定し、報告された各損失間隔のドロップカウントフィールドに3バイトを割り当てます。3バイトフィールドは、RFC 4342で指定された損失間隔オプションでフィールドと同じフィールドサイズを与えるために、一部は簡単に使用できます。CCID4 *は、ドロップされたパケットオプションに小さなフィールドサイズを使用できることが示唆されています。このセクションでは、ドロップされたパケットオプションのドロップカウントフィールドのサイズの問題について説明します。
It is not necessary to specify a three-byte field for the Dropped Packets option. A one-byte field would allow a reported drop count of 255, and a two-byte field would allow a reported drop count of 65,535. A two-byte field would clearly be sufficient for the drop count field for CCID 4.
ドロップされたパケットオプションに3バイトフィールドを指定する必要はありません。1バイトのフィールドは、報告された255のドロップカウントを可能にし、2バイトフィールドは報告された65,535のドロップカウントを許可します。CCID 4のドロップカウントフィールドには明らかに2バイトフィールドで十分です。
In fact, a one-byte field would *probably* be adequate for reporting the drop count for a loss interval in a CCID 4 connection. Because a CCID 4 sender enforces a minimum interval of 10 ms between data packets, a sender would need a round-trip time of over 2.55 seconds to have more than 255 packets lost or marked in a single loss interval; round-trip times of greater than three seconds are not unusual for some flows traversing satellite links. The drop count field is used in CCID 4 to compute the actual loss rate for short loss intervals, rather than using the loss event rate that is used for longer loss intervals. If a loss interval of at most two round-trip times included N packets sent, with more than 255 of those packets lost or marked, a drop count field of one byte would allow a drop count of at most 255 to be reported, resulting in a computed loss rate for that interval of 255/N. This loss rate might be less than the actual loss rate, but it is significantly higher than the loss event rate of 1/N, and should be sufficient to prevent a steady-state condition of a CCID 4 connection with multiple packets dropped each round-trip time. Thus, a one-byte field would probably be adequate for reporting the drop count for a loss interval in a CCID 4 connection. However, at the moment this document specifies a three-byte field, for consistency with the field size in the Loss Intervals option.
実際、1バイトのフィールドは、おそらく * CCID 4接続の損失間隔のドロップカウントを報告するのに適しています。CCID 4 Senderはデータパケット間で10 msの最小間隔を実施するため、送信者は、255以上のパケットを単一の損失間隔で紛失またはマークするには、2.55秒以上の往復時間が必要です。3秒を超える往復時間は、衛星リンクを横断する一部のフローでは珍しいことではありません。ドロップカウントフィールドは、CCID 4で使用され、長い損失間隔で使用される損失イベント率を使用するのではなく、短い損失間隔で実際の損失率を計算します。最大2回の往復時間の損失間隔には、nパケットが送信され、255以上のパケットが失われたりマークされている場合、1つのバイトのドロップカウントフィールドが最大255のドロップカウントを報告し、結果として生じます。255/nのその間隔の計算された損失率。この損失率は実際の損失率よりも少ないかもしれませんが、1/nの損失イベント率よりも大幅に高く、複数のパケットとのCCID 4接続の定常状態を防ぐのに十分であるはずです。旅行の時間。したがって、CCID 4接続での損失間隔のドロップカウントを報告するのに、おそらく1バイトのフィールドが適切です。ただし、現時点では、このドキュメントは、損失間隔オプションのフィールドサイズとの一貫性を得るために、3バイトフィールドを指定しています。
TFRC-SP is a congestion control mechanism defined in RFC 4828. Section 10 of [RFC4828] describes why TFRC-SP is currently specified as experimental and why it is not intended for widespread deployment at this time in the global Internet. Since TFRC-SP is Experimental, CCID 4 is therefore also considered experimental. If the IETF publishes a Standards-Track RFC that changes the status of TFRC-SP, then CCID 4 should then be updated to reflect the change of status.
TFRC-SPは、RFC4828で定義されている輻輳制御メカニズムです。[RFC4828]のセクション10は、TFRC-SPが現在実験的として指定されている理由と、グローバルインターネットでの現時点での広範な展開を意図していない理由を説明しています。したがって、TFRC-SPは実験的であるため、CCID 4も実験的と見なされます。IETFがTFRC-SPのステータスを変更する標準トラックRFCを公開する場合、CCID 4を更新してステータスの変更を反映する必要があります。
Security considerations include those discussed in Section 11 of [RFC4342]. There are no new security considerations introduced by CCID 4.
セキュリティ上の考慮事項には、[RFC4342]のセクション11で説明したものが含まれます。CCID 4によって導入された新しいセキュリティ上の考慮事項はありません。
This specification defines the value 4 in the DCCP CCID namespace managed by IANA. This is a permanent codepoint, as is needed for experimentation across the Internet using different codebases.
この仕様では、IANAが管理するDCCP CCID名空間の値4を定義します。これは、異なるコードベースを使用してインターネット全体で実験に必要な永続的なコードポイントです。
CCID 4 also uses three sets of numbers whose values have been allocated by IANA, namely CCID4-specific Reset Codes, option types, and feature numbers. 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 [RFC5226].
CCID 4は、IANAによって値が割り当てられた3セットの数字、つまりCCID4固有のリセットコード、オプションタイプ、および機能番号を使用します。このドキュメントは、実験およびテストの使用を除き、リセットコード範囲からの特定の割り当てを行いません[RFC3692]。[RFC5226]で概説されている標準アクションポリシーを参照します。
Each entry in the DCCP CCID 4 Reset Code registry contains a CCID4- 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 4リセットコードレジストリの各エントリには、範囲128-255の数字であるCCID4固有のリセットコードが含まれています。リセットコードの簡単な説明。リセットコードを定義するRFCへの参照。リセットコード184-190および248-254は、実験およびテストの使用のために永続的に予約されています。残りのリセットコード（128-183、191-247、および255）は現在予約されており、IESGのレビューと承認、および標準トラックIETF RFC RFC出版物を必要とする標準アクションポリシーで割り当てる必要があります。
Each entry in the DCCP CCID 4 option type registry contains a CCID4- 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 includes the value 195 allocated for the Dropped Packets option. This document allocates option types 192-195, and option types 184-190 and 248-254 are permanently reserved for experimental and testing use. The remaining option types -- 128-183, 191, 196-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 4オプションタイプレジストリの各エントリには、範囲128-255の数字であるCCID4固有のオプションタイプが含まれています。「損失間隔」などのオプションの名前。オプションタイプを定義するRFCへの参照。レジストリは、セクション8の表1の値を使用して最初に入力されます。これには、ドロップされたパケットオプションに割り当てられた値195が含まれます。このドキュメントにはオプションタイプ192-195が割り当てられ、オプションタイプ184-190および248-254は、実験およびテストの使用のために永続的に予約されています。残りのオプションタイプ（128-183、191、196-247、および255）は現在予約されており、IESGのレビューと承認、および標準トラックIETF RFC RFC出版物を必要とする標準アクションポリシーで割り当てる必要があります。
Each entry in the DCCP CCID 4 feature number registry contains a CCID4-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 4機能番号レジストリの各エントリには、CCID4固有の特徴番号が含まれています。これは範囲128-255の数字です。「損失イベント率を送信する」などの機能の名前。および機能番号を定義するRFCへの参照。レジストリは、セクション8の表2の値を使用して最初に入力されます。このドキュメントには、機能番号192が割り当てられ、機能番号184-190および248-254は、実験およびテストの使用のために永続的に予約されています。残りの機能番号（128-183、191、193-247、および255）は現在予約されており、IESGのレビューと承認、および標準トラックIETF RFC RFC出版物を必要とする標準アクションポリシーで割り当てる必要があります。
We thank Gorry Fairhurst, Alfred Hoenes, Ian McDonald, Gerrit Renker, and Leandro Sales for feedback on this document.
Gorry Fairhurst、Alfred Hoenes、Ian McDonald、Gerrit Renker、Leardroの販売に、このドキュメントのフィードバックをしてくれたことに感謝します。
[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月。
[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月。
[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, March 2006.
[RFC4342] Floyd、S.、Kohler、E。、およびJ. Padhye、「データグラムの混雑制御プロトコル（DCCP）混雑制御IDのプロファイル：TCPに優しいレート制御（TFRC）」、RFC 4342、2006年3月。
[RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant", RFC 4828, April 2007.
[RFC4828] Floyd、S。およびE. Kohler、「TCP Friendly Rate Control（TFRC）：The Small-Packet（SP）Variant」、RFC 4828、2007年4月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008.
[RFC5348] Floyd、S.、Handley、M.、Padhye、J。、およびJ. Widmer、「TCP Friendry Rate Control（TFRC）：プロトコル仕様」、RFC 5348、2008年9月。
[KFS07] Kohler, E., Floyd, S., and A. Sathiaseelan, "Faster Restart for TCP Friendly Rate Control (TFRC)", Work in Progress, July 2008.
[KFS07] Kohler、E.、Floyd、S。、およびA. Sathiaseelan、「TCP Friendly Rate Control（TFRC）のより速い再起動」、2008年7月の作業。
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