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)
小さなパケット用のTCPフレンドリーレート制御（TFRC-SP）：データグラム輻輳制御プロトコル（DCCP）輻輳ID 4のプロフィール
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.
この文書では、データグラム輻輳制御プロトコル（DCCP）で、輻輳制御識別子4、TCPフレンドリーレート制御（TFRC）の小パケットバリアントのプロファイルを指定します。 CCID 4は、実験用であり、TFRC-SP（RFC 4828）、小さなパケットを送信するアプリケーションのために設計されたTFRCの変異体を使用します。 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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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.
この文書は、データグラム輻輳制御プロトコル（DCCP）[RFC4340]に、輻輳制御識別子4、小パケットのTCPフレンドリーレート制御（TFRC-SP）の実験プロファイルを指定します。 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そのCCID 4 CCID 3から4と異なるが、TFRCの実験、小パケットの変異体をTFRC-SP [RFC4828]を使用します。 TFRC、RFC 3448 [RFC3448]の元の仕様は、CCID 3及びTFRC-SPの文書はRFC 5348に先行し、TFRCの仕様については、RFC 3448に代わりに参照双方RFC 5348.によって廃止されています。しかし、この文書はRFC 5348は、TFRCの仕様のための代わりにRFC 3448で使用されることを前提としています。
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の）の短い損失間隔の場合、損失率が失われたり、マークされたパケットの実際の数を数えることによって計算されます。 N個のデータパケットを有するこのような短い損失間隔、Kはデータ・パケットを紛失したり、マークを含むため、損失間隔の長さは、Nとしてこれは[RFC4828]のセクション4.4にTFRC-SPのために指定されている代わりに、N / Kとして計算されます。送信者は、損失イベント率を計算した場合、8.7節で指定されたドロップパケットオプションはデフォルトCCID 3の損失間隔のオプションに加えて、必要とされます。 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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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メカニズムに従います。更新がなく、この文書の改訂を待っより、IETFで標準化されているようにCCID 3と同様に、準拠CCID 4の実装は、直接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の場合とは異なります。 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 - データパケットを送信します。各DCCP - データパケットはシーケンス番号を有し、DCCPヘッダーのCCValフィールドは、複数の損失が単一損失イベントに属している場合を決定する際に受信機によって使用されるウィンドウのカウンタ値を含んでいます。
In the typical case of an ECN-capable half-connection, each DCCP-Data and DCCP-DataAck packet is sent as ECN-capable, with either the ECT(0) or the ECT(1) codepoint set. The use of the ECN Nonce with TFRC is described in Section 9.
ECN-可能な半接続の典型的なケースでは、各DCCP-データとDCCP-DataAckパケットがECT（0）または（1）ECT設定コードポイントのいずれかで、ECN-可能として送信されます。 TFRCとECNノンスを使用することは、セクション9に記載されています。
2. The receiver sends DCCP-Ack packets, acknowledging the data packets at least once per round-trip time, unless the sender is sending at a rate of less than one packet per round-trip time [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.受信側は、送信側がラウンドトリップ時間当たり未満のパケット[RFC5348]（第6節）の速度で送信されていない限り、少なくとも一回のラウンドトリップ時間当たりのデータパケットを認め、DCCP-ACKパケットを送信します。各DCCP-Ackパケットは、送信者から受信した最新のパケットを識別、シーケンス番号を使用し、受信機によって経験最近損失間隔に関するフィードバックを含みます。
3. The sender continues sending DCCP-Data packets as controlled by the allowed transmit rate. Upon receiving DCCP-Ack packets, the sender updates its allowed transmit rate as specified in [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 - データパケットを送信し続けます。 [RFC5348]（セクション4.3）で指定され、[RFC4828]としてDCCP-ACKパケットを受信すると、送信者は、その許容送信率を更新します。このアップデートは、受信側の損失間隔のフィードバックに基づいて、送信側で計算損失イベント率、に基づいています。それは好む場合は、送信者はまた、受信機によって計算され、報告された損失イベント率を使用することができます。
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）で指定されるように、NOFEEDBACK時間を算出します。何のフィードバックは（少なくとも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つのセンターの基本的な動作と同様。 RFC 5348（セクション3.1）と[RFC4828]で指定されるようにCCID 4のために、この損失イベント率、ラウンドトリップ時間推定、および1460バイトの公称パケット・サイズは、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は小さなパケットを送信するアプリケーションのために意図されているので、TCPスループット方程式に由来する許容送信レートは、[RFC4828]のセクション4.2で指定されるように、パケットのヘッダ・サイズを考慮に低減されます。データ・パケットにヘッダサイズは36バイト（IPv4ヘッダーのための20バイト、48ビットのシーケンス番号とDCCP-データヘッダは16バイト）として推定されます。 DCCPの送信者がNバイトのデータ・パケットを送信している場合、許容送信レートがN /（N + 36）によって低減されます。 CCID 4の送信者は、このフェアレートに制限されています。 24ビットのシーケンス番号がDCCP-データヘッダで使用された場合、ヘッダサイズは32バイトの代わりに36バイトであろう。
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バイトのヘッダのデフォルトの使用は、IPv4とIPv6の両方のために十分です。
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.
最大で2往復時間の損失間隔のために[RFC4828]で変更（第3節）と[RFC4342]の6.1節、。要約すると、損失間隔は、非ドロップ、非マークされたデータ・パケットの任意の数が続く可能性が紛失またはECN-マークされたデータパケットのRTT、1までです。 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.
[RFC4828]のセクション4.4で説明したように最大2つのラウンドトリップ時間の損失間隔で、CCID 4は、失われた、またはマーキングされたパケットの数をカウントすることによって、その間隔の損失イベント率を算出します。したがって、N個のデータパケットを有するこのような短い損失間隔、損失間隔長はN.ザがパケットをドロップ代わりとして、N / Kとして計算され、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送信者に関係なく、許容送信レートのデータパケットの間の10ミリ秒の最小間隔を強制します。オペレーティングシステムのスケジューリング粒度が一つの追加のパケットまで、これは非実用的にする場合は3つ以下のパケットが任意の30ミリ秒間隔で送信されていることを提供し、タイムスライスごとに送信されるかもしれません。
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バイトのセグメントサイズを使用します。これは、1460バイトのセグメントを使用して同じパケットドロップ率を経験TFRCフローとしてCCID 4送信者を秒あたりのバイト数にほぼ同じ送信レートを与えます。
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は、最初のものを除くすべての損失間隔のために、データ長がシーケンス長に等しいマイナス非データの数が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].
[RFC4342]のセクション7で指定されるように明示的輻輳通知（ECN）を使用するための手順です。
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をベクトル、タイムスタンプ、タイムスタンプエコー、経過時間オプション、およびその送信の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-データ？"列には、DCCP - データパケットに発生したときに現在定義されているすべての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.
[RFC4342]のセクション8.1で指定されるようDCCPジェネリックヘッダのCCValフィールドのウィンドウカウンタ値を使用することです。 CCID 3に記載のそれらの使用に加えて、CCValカウンタは、損失間隔の長さは最大2ラウンドトリップ時間であるときを決定するためにCCID 4に受信機によって使用されます。これらの手順のいずれも往復時間の明示的な推定値を維持するために受信機を必要としません。ただし、[RFC4342]のセクション8.1は、彼らがCCValを使用して、このようなRTT推定値を保持したい場合は実装者が使用することができます手順を説明します。
The use of the Elapsed Time option is defined in Section 8.2 of [RFC4342].
経過時間オプションの使用は[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往復時間の、損失の間隔が短いかどうかを判断できるようにする必要があります。受信機は、ヒューリスティックデータパケット到着にウィンドウカウンタを使用して、短いロス間隔を検出することができます。送信者は、ウィンドウカウンタは次の1つのデータパケットから、以上の5、モジュロ16によって増加されることはありませんことを。警告で、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つのラウンドトリップ時間の価値を続行します。非落とし、非マークされたデータパケットの任意に長いシリーズで完了します。損失間隔は、データパケットのウィンドウごとに最大で1回自分の送信レートを下げるTCP NewRenoの送信者の混雑の挙動をモデル化します。その結果、損失間隔で失われたパケットの数は、いずれかの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送信者がそれぞれの損失間隔から廃棄された正確にどのように多くのパケットを発見することができます。受信機は、最近、ドロップされたパケットのオプションを使用して損失間隔を観察し、その中に紛失したり、マークされたパケットの数を報告します。
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.
ドロップされたパケットのオプションは、常に最新のロス間隔を含む84点の連続した損失間隔、1つの情報が含まれています。損失間隔のオプションと同じように、間隔が新しい順にリストされています。以上の84点の損失間隔は、複数のドロップパケットのオプションを送信することができ、報告する必要がある必要があります。最初は、などやめて、どこ番目のオプションが開始されます。
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.
一滴のカウントは損失間隔ごとに指定されています。カウントは、パケットの数に等しい24ビット数、紛失または受信、対応する損失間隔の間にECN-マークされているドロップします。定義によると、この数は、対応する損失間隔の損失長を超えてはなりません。
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損失間隔をカバーするよりドロップパケットのオプションに含まれています。 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のパケットで送信された損失間隔オプションは、0,0バイト193,39,2、0,0,10、128,0,1、0,0,10が含まれている可能性がある損失間隔のこのセットを確認します、8、0,0,5、0,0,10、0,0,8、0,0,1、0,0,8、0,0,10、128,0,0、0,0,15 ;このオプションの解釈のために、[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オプションの長さ。 / 3 = 4損失間隔 - このオプションは、（2 14）に関する情報を含んでいます。損失間隔オプションは、そのスキップの長さでそれらを含んでいる - - 最近の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これらのバイトは、必要に応じて1であるL3、のドロップ数を定義し、ドロップカウントも1であるL3の損失長、以下です。
0,0,4 The Drop Count for L2 is 4.
L2のための0,0,4ドロップカウントは4です。
0,0,1 The Drop Count for L1 is 1.
L1のための0,0,1ドロップカウントは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].
[RFC4342]のセクション9で説明したようにECNと輻輳制御コンプライアンスを検証することです。
Procedures for verifying the ECN Nonce Echo are as specified in Section 9.1 of [RFC4342].
[RFC4342]のセクション9.1で指定されるようにECNノンスエコーを検証するための手順です。
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].
[RFC4342]のセクション10.2で説明したように、複数の失われたパケットが同じ損失イベントに属するかどうかを決定するために受信機によってウィンドウカウンタを使用することです。
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送信者が10の最小間隔を強制するので、CCID 4 * *は、小さいフィールドサイズと損失間隔オプションを使用することができることが示唆されているましたデータパケット間のミリ秒。このセクションでは、CCID 3に指定したのと同じ損失間隔のオプションを使用するには、CCID 4の理由を説明します。
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.
ロスレス長フィールドは損失間隔ロスレス部分にパケットの数を報告し、損失長フィールドは損失間隔の非可逆部分のパケット数を報告します。データ長フィールドは、（非データパケットを除く）の損失間隔のデータ長のパケット数を報告します。 2バイトのデータ長フィールドは、0.00002の損失イベント率に対応し、65,536パケットのデータ長を報告することができます。これは、CCID 4送信者に最大2.5秒の往復時間との接続のために十分であるRTTあたりおよそ250のパケットの許可送信レートを与えるのに十分です。大きなラウンドトリップ時間との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.
損失間隔の一RTT損失のある部分でのパケットの数を報告し、損失間隔オプションの損失Lengthフィールドは、1バイトのフィールドは、長いRTTとCCID 4の接続のために十分ではない（3秒以上より長いです）。損失長フィールドの場合、2バイトのフィールドは、CCID 4で十分ですが、当方の判断は、CCID 3と同様の損失間隔のオプションを使用する利点は、使用するCCID 4損失間隔のオプションを使用して任意の利点を上回るということです8バイトの代わりに、それぞれの損失間隔のフィールドを報告するための9バイト。
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.に指定された損失間隔オプションのフィールドと同じフィールドサイズを与えるために、簡単にするために、部分的であることは、CCID 4 *は*ドロップパケットオプションの小さいフィールドサイズを使用できることが示唆されています。このセクションでは、ドロップされたパケットのオプションのドロップカウントフィールドのサイズの問題について説明します。
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の報告のドロップ数を可能にすることが可能になります。 2バイトのフィールドは、明らかCCID 4のドロップカウントフィールドには十分だろう。
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送信側がデータパケット間は10msの最小間隔を強制しているため、送信者は、単一の損失間隔で失われたり、マーク255個のを超えるパケットを持つように2.55秒以上の往復時間が必要になります。より大きい3秒の往復時間は、衛星リンクを通過する一部のフローで珍しいことではないです。ドロップカウントフィールドはかなり長い損失間隔のために使用される損失イベント率を使用するよりも、短い損失間隔に対する実際の損失率を計算するためにCCID 4で使用されています。高々2往復時間のロス間隔が失われたり、マークされ、それらのパケットの255を超えると、送信されたN個のパケットが含まれている場合、1バイトのドロップ・カウント・フィールドは最大255のドロップ数が、結果として報告することができるようになります255 / Nの間隔の計算された損失率。この損失率は、実際の損失率よりも小さいかもしれないが、それは1 / Nの損失イベント率よりも有意に高く、複数のパケットとCCID 4の接続が各ラウンドを落としたの定常状態条件を防止するのに十分であるべきです旅行の時間。このように、1バイトのフィールドは、おそらくCCID 4接続の損失間隔のドロップ数を報告するための適当でしょう。しかし、現時点では、この文書には、損失間隔オプションでフィールドのサイズとの整合性のために、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は、現在実験として指定され、なぜそれがグローバルなインターネットにおけるこの時点で広範囲の展開のために意図されていない理由をTFRC-SPは、RFC 4828. [RFC4828]のセクション10で定義された輻輳制御機構で説明します。 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によって割り当てられた番号、つまりCCID4特異リセットコード、オプションの種類、および機能番号3組を使用します。この文書では、実験と[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の公表を要求する標準化活動方針、で割り当てる必要があります。
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への参照。レジストリは、最初にこれを落としたパケットのオプションのために割り当てられた値195を含む項8において、表1の値を使用して移入されます。この文書では、オプションタイプ192から195、およびオプションのタイプ184から190と248から254が永久的に、実験やテスト用に予約されていますが割り当てられます。残りのオプションの種類 - 128から183、191、196から247、および255 - 現在予約されている、とIESGレビューと承認および標準化過程IETF 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フィーチャー番号レジストリ内の各エントリは範囲128 255の数でありCCID4固有の機能番号が含まれ;そのような「ロスイベントレートを送る」などの機能の名前、;そして、機能番号を定義するRFCへの参照。レジストリは、最初にこの文書は、機能番号192を割り当て、機能番号184から190及び248から254が永久的実験及び試験の使用のために予約されている第8に、表2の値を使用して移入されます。残りの機能番号 - 128から183、191、193から247、および255 - 現在予約されている、とIESGレビューと承認および標準化過程IETF RFCの公表を要求する標準化活動方針、で割り当てる必要があります。
We thank Gorry Fairhurst, Alfred Hoenes, Ian McDonald, Gerrit Renker, and Leandro Sales for feedback on this document.
私たちは、この文書についてのフィードバックのためにGorry Fairhurst、アルフレッドHoenes、イアン・マクドナルド、ヘリット・Renker、およびレアンドロ販売に感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[RFC3448]ハンドレー、M.、フロイド、S.、Padhye、J.、およびJ.ウィトマー、 "TCPフレンドリーレート制御（TFRC）：プロトコル仕様"、RFC 3448、2003年1月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692] Narten氏、T.、 "役に立つと考えられ割り当て実験とテスト番号"、BCP 82、RFC 3692、2004年1月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]コーラー、E.、ハンドリー、M.、およびS.フロイド、 "データグラム輻輳制御プロトコル（DCCP）"、RFC 4340、2006年3月。
[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]フロイド、S.、コーラー、E.、およびJ. Padhye、 "データグラム混雑制御プロトコル（DCCP）輻輳制御ID 3のプロフィール：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]フロイド、S.、およびE.コーラー、 "TCPフレンドリーレート制御（TFRC）：小パケット（SP）バリアント"、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]フロイド、S.、ハンドリー、M.、Padhye、J.、およびJ.ウィトマー、 "TCPフレンドリーレート制御（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]コーラー、E.、フロイド、S.、およびA. Sathiaseelan、 "TCPフレンドリーレート制御（TFRC）のためのより高速な再起動"、進歩、2008年7月に作業。
Authors' Addresses
著者のアドレス
Sally Floyd ICSI Center for Internet Research 1947 Center Street, Suite 600 Berkeley, CA 94704 USA
インターネットリサーチ1947センターストリートのためのサリーフロイドICSIセンター、スイート600バークレー、CA 94704 USA
EMail: floyd@icir.org
メールアドレス：floyd@icir.org
Eddie Kohler 4531C Boelter Hall UCLA Computer Science Department Los Angeles, CA 90095 USA
エディー・コーラー4531C BoelterホールUCLAコンピュータサイエンス学部ロサンゼルス、CA 90095 USA
EMail: kohler@cs.ucla.edu
メールアドレス：kohler@cs.ucla.edu