[要約] RFC 4341は、DCCPのCongestion Control ID 2であるTCP-like Congestion Controlに関するプロファイルです。このRFCの目的は、DCCPのTCPライクな輻輳制御アルゴリズムを定義し、DCCPの性能を向上させることです。
Network Working Group S. Floyd
Request for Comments: 4341 ICIR
Category: Standards Track E. Kohler
UCLA
March 2006
Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control
データグラムの輻輳制御プロトコル（DCCP）輻輳制御ID 2：TCP様渋滞制御のプロファイル
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document contains the profile for Congestion Control Identifier 2 (CCID 2), TCP-like Congestion Control, in the Datagram Congestion Control Protocol (DCCP). CCID 2 should be used by senders who would like to take advantage of the available bandwidth in an environment with rapidly changing conditions, and who are able to adapt to the abrupt changes in the congestion window typical of TCP's Additive Increase Multiplicative Decrease (AIMD) congestion control.
このドキュメントには、Datagram混雑制御プロトコル（DCCP）に、輻輳制御識別子識別子2（CCID 2）のTCP様うっそりコントロールのプロファイルが含まれています。CCID 2は、急速に変化する条件の環境で利用可能な帯域幅を利用したい送信者が使用する必要があります。コントロール。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions and Notation ........................................2
3. Usage ...........................................................3
3.1. Relationship with TCP ......................................3
3.2. Half-Connection Example ....................................4
4. Connection Establishment ........................................5
5. Congestion Control on Data Packets ..............................5
5.1. Response to Idle and Application-Limited Periods ...........8
5.2. Response to Data Dropped and Slow Receiver .................8
5.3. Packet Size ................................................8
6. Acknowledgements ................................................9
6.1. Congestion Control on Acknowledgements .....................9
6.1.1. Detecting Lost and Marked Acknowledgements .........10
6.1.2. Changing Ack Ratio .................................10
6.2. Acknowledgements of Acknowledgements ......................11
6.2.1. Determining Quiescence .............................12
7. Explicit Congestion Notification ...............................12
8. Options and Features ...........................................12
9. Security Considerations ........................................13
10. IANA Considerations ...........................................13
10.1. Reset Codes ..............................................13
10.2. Option Types .............................................13
10.3. Feature Numbers ..........................................14
11. Thanks ........................................................14
A. Appendix: Derivation of Ack Ratio Decrease ....................15
B. Appendix: Cost of Loss Inference Mistakes to Ack Ratio ........15
Normative References ..............................................17
Informative References ............................................18
This document contains the profile for Congestion Control Identifier 2 (CCID 2), TCP-like Congestion Control, in the Datagram Congestion Control Protocol (DCCP) [RFC4340]. DCCP uses Congestion Control Identifiers, or CCIDs, to specify the congestion control mechanism in use on a half-connection.
このドキュメントには、Datagram混雑制御プロトコル（DCCP）[RFC4340]に、混雑制御識別子識別子2（CCID 2）のTCP様うっそりコントロールのプロファイルが含まれています。DCCPは、うっ血制御識別子またはCCIDを使用して、半接続で使用中の混雑制御メカニズムを指定します。
The TCP-like Congestion Control CCID sends data using a close variant of TCP's congestion control mechanisms, incorporating a variant of selective acknowledgements (SACK) [RFC2018, RFC3517]. CCID 2 is suitable for senders who can adapt to the abrupt changes in congestion window typical of TCP's Additive Increase Multiplicative Decrease (AIMD) congestion control, and particularly useful for senders who would like to take advantage of the available bandwidth in an environment with rapidly changing conditions. See Section 3 for more on application requirements.
TCP様鬱血制御CCIDは、TCPの輻輳制御メカニズムの近いバリアントを使用してデータを送信し、選択的承認のバリアント（SACK）[RFC2018、RFC3517]を組み込みます。CCID 2は、TCPの加法増加マルチライブ減少（AIMD）の混雑制御に典型的な混雑ウィンドウの急激な変化に適応できる送信者に適しており、特に急速に変化する環境で利用可能な帯域幅を利用したい送信者に特に役立ちます条件。アプリケーション要件の詳細については、セクション3を参照してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
A DCCP half-connection consists of the application data sent by one endpoint and the corresponding acknowledgements sent by the other endpoint. The terms "HC-Sender" and "HC-Receiver" denote the endpoints sending application data and acknowledgements, respectively. Since CCIDs apply at the level of half-connections, we abbreviate HC-Sender to "sender" and HC-Receiver to "receiver" in this document. See [RFC4340] for more discussion.
DCCPのハーフ接続は、1つのエンドポイントから送信されたアプリケーションデータと、他のエンドポイントによって送信される対応する謝辞で構成されています。「HC-SENDER」と「HC-Receiver」という用語は、それぞれエンドポイントがアプリケーションデータと謝辞を送信することを示しています。CCIDはハーフ接続のレベルで適用されるため、このドキュメントではHC-SENDEを「送信者」に、HC-Receiverを「受信者」に略します。詳細については、[RFC4340]を参照してください。
For simplicity, we say that senders send DCCP-Data packets and receivers send DCCP-Ack packets. Both of these categories are meant to include DCCP-DataAck packets.
簡単にするために、送信者はDCCP-DATAパケットを送信し、レシーバーはDCCP-CACKパケットを送信すると言います。これらのカテゴリは両方とも、DCCP-Dataackパケットを含めることを目的としています。
The phrases "ECN-marked" and "marked" refer to packets marked ECN Congestion Experienced unless otherwise noted.
「ECNマーク」および「マークされた」というフレーズは、特に明記しない限り、経験したECN輻輳がマークされたパケットを指します。
CCID 2, TCP-like Congestion Control, is appropriate for DCCP flows that would like to receive as much bandwidth as possible over the long term, consistent with the use of end-to-end congestion control. CCID 2 flows must also tolerate the large sending rate variations characteristic of AIMD congestion control, including halving of the congestion window in response to a congestion event.
TCP様の混雑制御、CCID 2は、エンドツーエンドの混雑制御の使用と一致して、長期的にできるだけ多くの帯域幅を受け取りたいDCCPフローに適しています。CCID 2フローは、輻輳イベントに応じた輻輳窓の半分を含む、AIMDの混雑制御に特徴的な大きな送信速度の変動にも耐える必要があります。
Applications that simply need to transfer as much data as possible in as short a time as possible should use CCID 2. This contrasts with CCID 3, TCP-Friendly Rate Control (TFRC) [RFC4342], which is appropriate for flows that would prefer to minimize abrupt changes in the sending rate. For example, CCID 2 is recommended over CCID 3 for streaming media applications that buffer a considerable amount of data at the application receiver before playback time, insulating the application somewhat from abrupt changes in the sending rate. Such applications could easily choose DCCP's CCID 2 over TCP itself, possibly adding some form of selective reliability at the application layer. CCID 2 is also recommended over CCID 3 for applications where halving the sending rate in response to congestion is not likely to interfere with application-level performance.
できるだけ短い時間でできるだけ多くのデータを単純に転送する必要があるアプリケーションは、CCID 2を使用する必要があります。これは、CCID 3、TCPフレンドリーレートコントロール（TFRC）[RFC4342]とは対照的です。送信率の急激な変化を最小限に抑えます。たとえば、CCID 2は、再生時間の急激な変更からアプリケーションを断熱する前に、アプリケーションレシーバーでかなりの量のデータをバッファリングするストリーミングメディアアプリケーションのCCID 3よりも推奨されます。このようなアプリケーションは、TCP自体よりもDCCPのCCID 2を簡単に選択でき、アプリケーション層に何らかの形の選択的信頼性を追加する可能性があります。CCID 2は、CCID 3よりも、うっ血に応じて送信率を半分にすることで、アプリケーションレベルのパフォーマンスを妨げる可能性が低いアプリケーションにも推奨されます。
An additional advantage of CCID 2 is that its TCP-like congestion control mechanisms are reasonably well understood, with traffic dynamics quite similar to those of TCP. While the network research community is still learning about the dynamics of TCP after 15 years of its being the dominant transport protocol in the Internet, some applications might prefer the more well-known dynamics of TCP-like congestion control over those of newer congestion control mechanisms, which haven't yet met the test of widespread Internet deployment.
CCID 2の追加の利点は、TCPのような混雑制御メカニズムが合理的によく理解されており、TCPのトラフィックダイナミクスと非常によく似ていることです。ネットワークリサーチコミュニティは、インターネットで支配的な輸送プロトコルである15年後にTCPのダイナミクスについてまだ学んでいますが、一部のアプリケーションは、新しい輻輳制御メカニズムのものに対するTCP様鬱血制御のよりよく知られているダイナミクスを好むかもしれません。、これはまだ広範なインターネット展開のテストを満たしていません。
The congestion control mechanisms described here closely follow mechanisms standardized by the IETF for use in SACK-based TCP, and we rely partially on existing TCP documentation, such as [RFC793], [RFC2581], [RFC3465], and [RFC3517]. TCP congestion control continues to evolve, but CCID 2 implementations SHOULD wait for explicit updates to CCID 2 rather than track TCP's evolution directly.
ここで説明する混雑制御メカニズムは、SACKベースのTCPで使用するためにIETFによって標準化されたメカニズムに密接に従い、[RFC793]、[RFC2581]、[RFC3465]、[RFC3517]などの既存のTCPドキュメントに部分的に依存しています。TCPの混雑制御は進化し続けていますが、CCID 2の実装は、TCPの進化を直接追跡するのではなく、CCID 2の明示的な更新を待つ必要があります。
Differences between CCID 2 and straight TCP congestion control include the following:
CCID 2とストレートTCPの混雑制御の違いには、以下が含まれます。
o CCID 2 applies congestion control to acknowledgements, a mechanism not currently standardized for use in TCP.
o CCID 2は、TCPでの使用のために現在標準化されていないメカニズムであるAumponedgentmentsに混雑制御を適用します。
o DCCP is a datagram protocol, so several parameters whose units are specified in bytes in TCP, such as the congestion window cwnd, have units of packets in DCCP.
o DCCPはデータグラムのプロトコルであるため、輻輳ウィンドウCWNDなど、TCPのバイトでユニットが指定されているいくつかのパラメーターには、DCCPにパケットの単位があります。
o As an unreliable protocol, DCCP never retransmits a packet, so congestion control mechanisms that distinguish retransmissions from new packets have been redesigned for the DCCP context.
o 信頼性の低いプロトコルとして、DCCPはパケットを再送信することはないため、再送信を新しいパケットと区別する輻輳制御メカニズムがDCCPコンテキストのために再設計されています。
This example shows the typical progress of a half-connection using CCID 2's TCP-like Congestion Control, not including connection initiation and termination. The example is informative, not normative.
この例は、CCID 2のTCP様うっ血制御を使用したハーフ接続の典型的な進歩を示しており、接続の開始と終了を含まないことです。この例は有益であり、規範ではありません。
1. The sender sends DCCP-Data packets, where the number of packets sent is governed by a congestion window, cwnd, as in TCP. Each DCCP-Data packet uses a sequence number. The sender also sends an Ack Ratio feature option specifying the number of data packets to be covered by an Ack packet from the receiver; Ack Ratio defaults to two. The DCCP header's CCVal field is set to zero.
1. 送信者はDCCP-DATAパケットを送信します。このパケットは、TCPのように、送信されたパケットの数がCWNDで支配されます。各DCCP-DATAパケットは、シーケンス番号を使用します。また、送信者は、受信者からのACKパケットでカバーされるデータパケットの数を指定するACK比機能オプションも送信します。ACK比はデフォルトで2です。DCCPヘッダーのCCVALフィールドはゼロに設定されています。
Assuming that the half-connection is Explicit Congestion Notification (ECN) capable (the ECN Incapable feature is zero, the default), each DCCP-Data packet is sent as ECN Capable with either the ECT(0) or the ECT(1) codepoint set, as described in [RFC3540].
ハーフ接続が明示的な輻輳通知（ECN）が有能であると仮定すると（ECNの無能力機能はゼロ、デフォルト）、各DCCP-DATAパケットはECT（0）またはECT（1）CodePointのいずれかでECNの能力として送信されます[RFC3540]で説明されているように、設定。
2. The receiver sends a DCCP-Ack packet acknowledging the data packets for every Ack Ratio data packets transmitted by the sender. Each DCCP-Ack packet uses a sequence number and contains an Ack Vector. The sequence number acknowledged in a DCCP-Ack packet is that of the received packet with the highest sequence number; it is not a TCP-like cumulative acknowledgement.
2. 受信者は、送信者が送信したACK比すべてのデータパケットのデータパケットを確認するDCCP-CACKパケットを送信します。各DCCP-CACKパケットはシーケンス番号を使用し、ACKベクトルを含みます。DCCP-CACKパケットで認められているシーケンス番号は、最高のシーケンス番号を持つ受信パケットのシーケンス番号です。TCPのような累積認識ではありません。
The receiver returns the sum of received ECN Nonces via Ack Vector options, allowing the sender to probabilistically verify that the receiver is not misbehaving. DCCP-Ack packets from the receiver are also sent as ECN Capable, since the sender will control the acknowledgement rate in a roughly TCP-friendly way using the Ack Ratio feature. There is little need for the receiver to verify the nonces of its DCCP-Ack packets, since the sender cannot get significant benefit from misreporting the ack mark rate.
受信者は、ACKベクトルオプションを介して受信したECN Noncesの合計を返し、送信者が受信機が誤動作していないことを確率的に確認できるようにします。送信者はACK比機能を使用してほぼTCPに優しい方法で確認レートを制御するため、受信機からのDCCP-ackパケットも有能に送信されます。送信者はACKマークレートを誤って報告することで大きな利益を得ることができないため、受信者がDCCP-ackパケットの非速度を確認する必要はほとんどありません。
3. The sender continues sending DCCP-Data packets as controlled by the congestion window. Upon receiving DCCP-Ack packets, the sender examines their Ack Vectors to learn about marked or dropped data packets and adjusts its congestion window accordingly. Because this is unreliable transfer, the sender does not retransmit dropped packets.
3. 送信者は、輻輳ウィンドウで制御されているように、DCCP-DATAパケットの送信を続けます。DCCP-CACKパケットを受信すると、送信者はACKベクターを調べて、マークされたデータパケットまたはドロップされたデータパケットについて学習し、それに応じてうっ血ウィンドウを調整します。これは信頼できない転送であるため、送信者はドロップされたパケットを再送信しません。
4. Because DCCP-Ack packets use sequence numbers, the sender has some information about lost or marked DCCP-Ack packets. The sender responds to lost or marked DCCP-Ack packets by modifying the Ack Ratio sent to the receiver.
4. DCCP-CACKパケットはシーケンス番号を使用するため、送信者には紛失またはマークのDCCP-CACKパケットに関する情報があります。送信者は、レシーバーに送信されたACK比を変更することにより、紛失またはマークされたDCCP-CACKパケットに応答します。
5. The sender acknowledges the receiver's acknowledgements at least once per congestion window. If both half-connections are active, the sender's acknowledgement of the receiver's acknowledgements is included in the sender's acknowledgement of the receiver's data packets. If the reverse-path half-connection is quiescent, the sender sends at least one DCCP-DataAck packet per congestion window.
5. 送信者は、輻輳ウィンドウごとに少なくとも1回は受信者の謝辞を認めます。両方のハーフ接続がアクティブな場合、受信者の謝辞に対する送信者の承認は、受信者のデータパケットの送信者の謝辞に含まれています。逆パスの半接続が静止している場合、送信者は輻輳ウィンドウごとに少なくとも1つのDCCP-Dataackパケットを送信します。
6. The sender estimates round-trip times, either through keeping track of acknowledgement round-trip times as TCP does or through explicit Timestamp options, and calculates a TimeOut (TO) value much as the RTO (Retransmit Timeout) is calculated in TCP. The TO determines when a new DCCP-Data packet can be transmitted when the sender has been limited by the congestion window and no feedback has been received from the receiver.
6. 送信者は、TCPが行うように往復時間を確認することにより、または明示的なタイムスタンプオプションの往復時間を追跡することにより、ラウンドトリップ時間を推定し、RTO（再送信タイムアウト）がTCPで計算されるようにタイムアウト値を計算します。新しいDCCP-DATAパケットをいつ送信するかを決定します。
Use of the Ack Vector is MANDATORY on CCID 2 half-connections, so the sender MUST send a "Change R(Send Ack Vector, 1)" option to the receiver as part of connection establishment. The sender SHOULD NOT send data until it has received the corresponding "Confirm L(Send Ack Vector, 1)" from the receiver, except that it MAY send data on DCCP-Request packets.
ACKベクトルの使用はCCID 2のハーフ接続で必須であるため、送信者は接続確立の一部として「r（send ack vector、1）」オプションを受信者に送信する必要があります。送信者は、DCCP-Requestパケットにデータを送信することを除いて、対応する「確認l（ackベクター、1）」を受信者から受信するまでデータを送信しないでください。
CCID 2's congestion control mechanisms are based on those for SACK-based TCP [RFC3517], since the Ack Vector provides all the information that might be transmitted in SACK options.
ACKベクトルはSACKオプションで送信される可能性のあるすべての情報を提供するため、CCID 2の混雑制御メカニズムは、SACKベースのTCP [RFC3517]のメカニズムに基づいています。
A CCID 2 data sender maintains three integer parameters measured in packets.
CCID 2データ送信者は、パケットで測定された3つの整数パラメーターを維持します。
1. The congestion window "cwnd", which equals the maximum number of data packets allowed in the network at any time. ("Data packet" means any DCCP packet that contains user data: DCCP-Data, DCCP-DataAck, and occasionally DCCP-Request and DCCP-Response.)
1. 輻輳ウィンドウ「CWND」は、いつでもネットワークで許可されているデータパケットの最大数に等しくなります。（「データパケット」とは、ユーザーデータを含むDCCPパケット：DCCP-DATA、DCCP-DATAACK、およびDCCP-RequestおよびDCCP-Responseを意味します。）
2. The slow-start threshold "ssthresh", which controls adjustments to cwnd.
2. CWNDの調整を制御するスロースタートしきい値「SSthresh」。
3. The pipe value "pipe", which is the sender's estimate of the number of data packets outstanding in the network.
3. パイプ値「パイプ」。これは、ネットワーク内で発行されるデータパケットの数の送信者の推定値です。
These parameters are manipulated, and their initial values determined, according to SACK-based TCP's behavior, except that they are measured in packets, not bytes. The rest of this section provides more specific guidance.
これらのパラメーターは操作され、サックベースのTCPの動作に従って、バイトではなくパケットで測定されていることを除いて、その初期値が決定されます。このセクションの残りの部分は、より具体的なガイダンスを提供します。
The sender MAY send a data packet when pipe < cwnd but MUST NOT send a data packet when pipe >= cwnd. Every data packet sent increases pipe by 1.
送信者は、pipe <cwndの場合はデータパケットを送信できますが、pipe> = cwndの場合はデータパケットを送信してはなりません。送信されるすべてのデータパケットはパイプを1増加させます。
The sender reduces pipe as it infers that data packets have left the network, either by being received or by being dropped. In particular:
送信者は、データパケットが受信またはドロップされることにより、データパケットがネットワークを離れることを推測すると、パイプを削減します。特に：
1. Acked data packets. The sender reduces pipe by 1 for each data packet newly acknowledged as received (Ack Vector State 0 or State 1) by some DCCP-Ack.
1. Ackedデータパケット。送信者は、DCCP-ackによって受信された（ACKベクトル状態0または状態1）に新たに認められたデータパケットごとにパイプを1削減します。
2. Dropped data packets. The sender reduces pipe by 1 for each data packet it can infer as lost due to the DCCP equivalent of TCP's "duplicate acknowledgements". This depends on the NUMDUPACK parameter, the number of duplicate acknowledgements needed to infer a loss. The NUMDUPACK parameter is set to three, as is currently the case in TCP. A packet P is inferred to be lost, rather than delayed, when at least NUMDUPACK packets transmitted after P have been acknowledged as received (Ack Vector State 0 or 1) by the receiver. Note that the acknowledged packets following the hole may be DCCP-Acks or other non-data packets.
2. データパケットをドロップしました。送信者は、TCPの「重複謝辞」に相当するDCCPのために、失われたと推測できるデータパケットごとにパイプを1削減します。これは、numdupackパラメーター、損失を推測するために必要な重複謝辞の数に依存します。TCPの場合と同様に、NumDupackパラメーターは3に設定されています。Packet Pは、受信機が受信（ACKベクター状態0または1）と認識された後に少なくともnumdupackパケットが送信された場合、遅延ではなく失われたと推測されます。穴に続く認められているパケットは、DCCP-CACKまたは他の非DATAパケットである可能性があることに注意してください。
3. Transmit timeouts. Finally, the sender needs transmit timeouts, handled like TCP's retransmission timeouts, in case an entire window of packets is lost. The sender estimates the round-trip time at most once per window of data and uses the TCP algorithms for maintaining the average round-trip time, mean deviation, and timeout value [RFC2988]. (If more than one measurement per round-trip time was used for these calculations, then the weights of the averagers would have to be adjusted to ensure that the average round-trip time is effectively derived from measurements over multiple round-trip times.) Because DCCP does not retransmit data, DCCP does not require TCP's recommended minimum timeout of one second. The exponential backoff of the timer is exactly as in TCP. When a transmit timeout occurs, the sender sets pipe to zero. The adjustments to cwnd and ssthresh are described below.
3. タイムアウトを送信します。最後に、送信者は、パケットのウィンドウ全体が失われた場合に備えて、TCPの再送信タイムアウトのように処理されるタイムアウトを送信する必要があります。送信者は、データのウィンドウごとに最大1回の往復時間を推定し、平均往復時間、平均偏差、およびタイムアウト値[RFC2988]を維持するためにTCPアルゴリズムを使用します。（これらの計算に往復時間ごとに複数の測定が使用された場合、平均往復時間が複数の往復時間にわたる測定から効果的に導出されるように、平均化の重みを調整する必要があります。）DCCPはデータを再送信しないため、DCCPはTCPの推奨最小タイムアウトの1秒を必要としません。タイマーの指数バックオフは、TCPとまったく同じです。送信タイムアウトが発生すると、送信者はパイプをゼロに設定します。CWNDおよびSSTHRESHの調整については、以下に説明します。
The sender MUST NOT decrement pipe more than once per data packet. True duplicate acknowledgements, for example, MUST NOT affect pipe. The sender also MUST NOT decrement pipe again upon receiving acknowledgement of a packet previously inferred as lost. Furthermore, the sender MUST NOT decrement pipe for non-data packets, such as DCCP-Acks, even though the Ack Vector will contain information about them.
送信者は、データパケットごとに1回以上パイプを減少させてはなりません。たとえば、真の重複謝辞は、パイプに影響を与えてはなりません。また、送信者は、以前に失われたと推測されたパケットの承認を受け取ったときに、再びパイプを減少させてはなりません。さらに、ACKベクターにはそれらに関する情報が含まれていても、送信者はDCCP-CACKなどの非DATAパケットのパイプを減少させてはなりません。
Congestion events cause CCID 2 to reduce its congestion window. A congestion event contains at least one lost or marked packet. As in TCP, two losses or marks are considered part of a single congestion event when the second packet was sent before the loss or mark of the first packet was detected. As an approximation, a sender can consider two losses or marks to be part of a single congestion event when the packets were sent within one RTT estimate of one another, using an RTT estimate current at the time the packets were sent. For each congestion event, either indicated explicitly as an Ack Vector State 1 (ECN-marked) acknowledgement or inferred via "duplicate acknowledgements", cwnd is halved, then ssthresh is set to the new cwnd. Cwnd is never reduced below one packet. After a timeout, the slow-start threshold is set to cwnd/2, then cwnd is set to one packet. When halved, cwnd and ssthresh have their values rounded down, except that cwnd is never less than one and ssthresh is never less than two.
輻輳イベントにより、CCID 2は混雑ウィンドウを減らします。混雑イベントには、少なくとも1つの紛失またはマークされたパケットが含まれています。TCPと同様に、2番目のパケットが送信されたときに、2つの損失またはマークが1つの輻輳イベントの一部と見なされます。最初のパケットの損失またはマークが検出されました。近似として、送信者は、パケットが送信された時点でRTT推定電流を使用して、パケットが互いに1つのRTT推定内で送信されたときに、2つの損失またはマークが単一の輻輳イベントの一部であると考えることができます。各輻輳イベントについて、ACKベクター状態1（ECNマーク）の確認として明示的に示されるか、「重複承認」を介して推測される、CWNDは半分になり、SSThreshは新しいCWNDに設定されます。CWNDが1つのパケット以下で縮小されることはありません。タイムアウト後、スロースタートしきい値がCWND/2に設定され、CWNDは1つのパケットに設定されます。半分になると、CWNDとSSthreshの値は、CWNDが1人以上であり、SSthreshが2つ以上になることを除いて、値を締めくくります。
When cwnd < ssthresh, meaning that the sender is in slow-start, the congestion window is increased by one packet for every two newly acknowledged data packets with Ack Vector State 0 (not ECN-marked), up to a maximum of Ack Ratio/2 packets per acknowledgement. This is a modified form of Appropriate Byte Counting [RFC3465] that is consistent with TCP's current standard (which does not include byte counting), but allows CCID 2 to increase as aggressively as TCP when CCID 2's Ack Ratio is greater than the default value of two. When cwnd >= ssthresh, the congestion window is increased by one packet for every window of data acknowledged without lost or marked packets. The cwnd parameter is initialized to at most four packets for new connections, following the rules from [RFC3390]; the ssthresh parameter is initialized to an arbitrarily high value.
cwnd <ssthresh、つまり送信者がスロースタートであることを意味する場合、ACKベクトル状態0（ECNマーク化されていない）を備えた2つの新たに確認されたデータパケットごとに1つのパケットが増加します。謝辞ごとに2つのパケット。これは、TCPの現在の標準（バイトカウントは含まれない）と一致する適切なバイトカウント[RFC3465]の修正された形式ですが、CCID 2のACK比がデフォルト値よりも大きい場合、CCID 2はTCPのように積極的に増加することができます。二。cwnd> = ssthreshの場合、紛失またはマークされたパケットなしで確認されたデータのすべてのウィンドウに対して、輻輳ウィンドウは1つのパケットによって増加します。CWNDパラメーターは、[RFC3390]のルールに従って、新しい接続のために最大4つのパケットに初期化されます。SSthreshパラメーターは、任意に高い値に初期化されます。
Senders MAY use a form of rate-based pacing when sending multiple data packets liberated by a single ack packet, rather than sending all liberated data packets in a single burst.
送信者は、単一のバーストですべての解放されたデータパケットを送信するのではなく、単一のACKパケットによって解放された複数のデータパケットを送信するときに、レートベースのペーシングの形式を使用できます。
CCID 2 is designed to follow TCP's congestion control mechanisms to the extent possible, but TCP does not have complete standardization for its congestion control response to idle periods (when no data packets are sent) or to application-limited periods (when the sending rate is less than that allowed by cwnd). This section is a brief guide to the standards for TCP in this area.
CCID 2は、可能な限りTCPの混雑制御メカニズムに従うように設計されていますが、TCPには、アイドル期間（データパケットが送信されない場合）またはアプリケーション制限期間（送信金が送信される場合）に対する混雑制御応答の完全な標準化はありません。CWNDが許可するものよりも少ない）。このセクションは、この分野のTCPの基準に関する簡単なガイドです。
For idle periods, [RFC2581] recommends that the TCP sender SHOULD slow-start after an idle period, where an idle period is defined as a period exceeding the timeout interval. [RFC2861], currently Experimental, suggests a slightly more moderate mechanism where the congestion window is halved for every round-trip time that the sender has remained idle.
アイドル期間の場合、[RFC2581]は、アイドル期間がタイムアウト間隔を超える期間として定義されるアイドル期間後にTCP送信者がスロースタートすることを推奨しています。現在実験的である[RFC2861]は、送信者がアイドル状態を維持している往復時間ごとに混雑ウィンドウが半分になるというわずかに中程度のメカニズムを示唆しています。
There are currently no standards governing TCP's use of the congestion window during an application-limited period. In particular, it is possible for TCP's congestion window to grow quite large during a long uncongested period when the sender is application limited, sending at a low rate. [RFC2861] essentially suggests that TCP's congestion window not be increased during application-limited periods when the congestion window is not being fully utilized.
現在、アプリケーションが制限された期間中にTCPが輻輳ウィンドウを使用することを管理する基準はありません。特に、送信者がアプリケーションに制限されていて、低い料金で送信される長い間、長い間、TCPの混雑ウィンドウが非常に大きくなる可能性があります。[RFC2861]は、基本的に、輻輳ウィンドウが完全に使用されていないアプリケーション制限期間中にTCPの混雑ウィンドウが増加しないことを示唆しています。
DCCP's Data Dropped option lets a receiver declare that a packet was dropped at the end host before delivery to the application -- for instance, because of corruption or receive buffer overflow. DCCP's Slow Receiver option lets a receiver declare that it is having trouble keeping up with the sender's packets, although nothing has yet been dropped. CCID 2 senders respond to these options as described in [RFC4340], with the following further clarifications.
DCCPのデータドロップされたオプションにより、受信者は、腐敗やバッファオーバーフローのために、アプリケーションに配信する前に、アプリケーションへの配信前に最後のホストでパケットがドロップされたことを宣言できます。DCCPの遅いレシーバーオプションにより、レシーバーは、まだ削除されていませんが、送信者のパケットに追いつくのに苦労していると宣言できます。CCID 2送信者は、[RFC4340]で説明されているように、これらのオプションに応答します。
o Drop Code 2 ("receive buffer drop"). The congestion window "cwnd" is reduced by one for each packet newly acknowledged as Drop Code 2, except that it is never reduced below one.
o ドロップコード2（「バッファドロップを受信」）。輻輳ウィンドウ「CWND」は、ドロップコード2として新たに認められたパケットごとに1つずつ削減されます。
o Exiting slow start. The sender MUST exit slow start whenever it receives a relevant Data Dropped or Slow Receiver option.
o スロースタートを終了します。送信者は、関連するデータを削除または遅いレシーバーオプションを受信するたびにスロースタートを終了する必要があります。
CCID 2 is optimized for applications that generally use a fixed packet size and vary their sending rate in packets per second in response to congestion. CCID 2 is not appropriate for applications that require a fixed interval of time between packets and vary their packet size instead of their packet rate in response to congestion.
CCID 2は、通常、固定パケットサイズを使用し、輻輳に応じて1秒あたりのパケットの送信率を変更するアプリケーション向けに最適化されています。CCID 2は、パケット間の固定時間間隔を必要とするアプリケーションには適していません。
CCID 2 maintains a congestion window in packets and does not increase the congestion window in response to a decrease in the packet size. However, some attention might be required for applications using CCID 2 that vary their packet size not in response to congestion, but in response to other application-level requirements.
CCID 2は、パケットに輻輳ウィンドウを維持し、パケットサイズの減少に応じて輻輳ウィンドウを増加させません。ただし、CCID 2を使用するアプリケーションには、混雑に応じてではなく、他のアプリケーションレベルの要件に応じて異なるアプリケーションに注意が必要になる場合があります。
CCID 2 implementations MAY check for applications that appear to be manipulating the packet size inappropriately. For example, an application might send small packets for a while, building up a fast rate, then switch to large packets to take advantage of the fast rate. (Preliminary simulations indicate that applications may not be able to increase their overall transfer rates this way, so it is not clear that this manipulation will occur in practice [V03].)
CCID 2の実装は、パケットサイズを不適切に操作していると思われるアプリケーションをチェックする場合があります。たとえば、アプリケーションはしばらくの間小さなパケットを送信し、高速レートを構築してから、大規模なパケットに切り替えて高速レートを活用する場合があります。（予備的なシミュレーションでは、アプリケーションがこの方法で全体的な転送率を上げることができない可能性があることを示しているため、この操作が実際に行われることは明らかではありません[V03]。）
CCID 2 acknowledgements are generally paced by the sender's data packets. Each required acknowledgement MUST contain Ack Vector options that declare exactly which packets arrived and whether those packets were ECN-marked. Acknowledgement data in the Ack Vector options SHOULD generally cover the receiver's entire Acknowledgement Window; see [RFC4340], Section 11.4.2. Any Data Dropped options SHOULD likewise cover the receiver's entire Acknowledgement Window.
CCID 2の謝辞は、通常、送信者のデータパケットによってペースを合わせています。必要な各確認には、どのパケットが到着したか、およびそれらのパケットがecnマークされているかどうかを正確に宣言するACKベクターオプションが含まれている必要があります。ACKベクターオプションの確認データは、通常、受信者の確認ウィンドウ全体をカバーする必要があります。[RFC4340]、セクション11.4.2を参照してください。ドロップされたオプションは、同様に、受信者の確認ウィンドウ全体をカバーする必要があります。
CCID 2 senders use DCCP's Ack Ratio feature to influence the rate at which receivers generate DCCP-Ack packets, thus controlling reverse-path congestion. This differs from TCP, which presently has no congestion control for pure acknowledgement traffic. CCID 2's reverse-path congestion control does not try to be TCP friendly; it just tries to avoid congestion collapse, and to be somewhat better than TCP is in the presence of a high packet loss or mark rate on the reverse path. The default Ack Ratio is two, and CCID 2 with this Ack Ratio behaves like TCP with delayed acks. [RFC4340], Section 11.3, describes the Ack Ratio in more detail, including its relationship to acknowledgement pacing and DCCP-DataAck packets. This document's Section 6.1.1 describes how a CCID 2 sender detects lost or marked acknowledgements, and Section 6.1.2 describes how it changes the Ack Ratio.
CCID 2の送信者は、DCCPのACK比機能を使用して、受信機がDCCP-ackパケットを生成する速度に影響を与え、逆パスのうっ血を制御します。これはTCPとは異なります。TCPは現在、純粋な承認トラフィックの混雑制御がありません。CCID 2のリバースパス混雑制御は、TCPフレンドリーになろうとはしません。それはただ鬱血の崩壊を避けようとするだけで、TCPが逆パスに高いパケット損失またはマーク率が存在するよりもやや良くなることです。デフォルトのACK比は2で、このACK比を持つCCID 2は、ACKが遅延したTCPのように動作します。[RFC4340]、セクション11.3は、ACK比をより詳細に説明しています。このドキュメントのセクション6.1.1では、CCID 2の送信者が紛失または顕著な謝辞を検出する方法を説明し、セクション6.1.2では、ACK比の変化方法について説明します。
When Ack Ratio is R, the receiver sends one DCCP-Ack packet per R data packets, more or less. Since the sender sends cwnd data packets per round-trip time, the acknowledgement rate equals cwnd/R DCCP-Acks per round-trip time. The sender keeps the acknowledgement rate roughly TCP friendly by monitoring the acknowledgement stream for lost and marked DCCP-Ack packets and modifying R accordingly. For every RTT containing a DCCP-Ack congestion event (that is, a lost or marked DCCP-Ack), the sender halves the acknowledgement rate by doubling Ack Ratio; for every RTT containing no DCCP-Ack congestion event, it additively increases the acknowledgement rate through gradual decreases in Ack Ratio.
ACK比がRの場合、受信機は多かれ少なかれ、Rデータパケットごとに1つのDCCP-CACKパケットを送信します。送信者は、往復時間ごとにCWNDデータパケットを送信するため、確認レートは往復時間ごとにCWND/R DCCP-CACKに等しくなります。送信者は、紛失およびマークされたDCCP-ackパケットの確認ストリームを監視し、それに応じてRを変更することにより、承認率をほぼTCPフレンドリーに保ちます。DCCP-CACHの輻輳イベント（つまり、紛失またはマークされたDCCP-CACK）を含むすべてのRTTについて、送信者はACK比を2倍にすることで確認レートを半分にします。DCCP-CACKの混雑イベントを含むすべてのRTTについて、ACK比が徐々に減少することにより、確認率を追加します。
All packets from the receiver contain sequence numbers, so the sender can detect both losses and marks on the receiver's packets. The sender infers receiver packet loss in the same way that it infers losses of its data packets: a packet from the receiver is considered lost after at least NUMDUPACK packets with greater sequence numbers have been received.
受信機からのすべてのパケットにはシーケンス番号が含まれているため、送信者はレシーバーのパケットの損失とマークの両方を検出できます。送信者は、データパケットの損失を誘導するのと同じように、受信機パケットの損失を推進します。レシーバーからのパケットは、少なくともより大きなシーケンス番号を持つNumDupackパケットが受信された後、失われたと見なされます。
DCCP-Ack packets are generally small, so they might impose less load on congested network links than DCCP-Data and DCCP-DataAck packets. For this reason, Ack Ratio depends on losses and marks on the receiver's non-data packets, not on aggregate losses and marks on all of the receiver's packets. The non-data packet category consists of those packet types that cannot carry application data: DCCP-Ack, DCCP-Close, DCCP-CloseReq, DCCP-Reset, DCCP-Sync, and DCCP-SyncAck. The sender can easily distinguish non-data marks from other marks. This is harder for losses, though, since the sender can't always know whether a lost packet carried data. Unless it has better information, the sender SHOULD assume, for the purpose of Ack Ratio calculation, that every lost packet was a non-data packet. Better information is available via DCCP's NDP Count option, if necessary. (Appendix B discusses the costs of mistaking data packet loss for non-data packet loss.)
DCCP-CACKパケットは一般に小さいため、DCCP-DataおよびDCCP-Dataackパケットよりも混雑したネットワークリンクに負荷が少ない場合があります。このため、ACK比は、受信者のすべてのパケットの総損失とマークではなく、受信者の非DATAパケットの損失とマークに依存します。非DATAパケットカテゴリは、アプリケーションデータを運ぶことができないパケットタイプのDCCP-CACK、DCCP-Close、DCCP-Closereq、DCCP-Reset、DCCP-Sync、およびDCCP-Syncackで構成されています。送信者は、非DATAマークを他のマークと簡単に区別できます。ただし、これは損失にとってより困難です。送信者は、紛失したパケットがデータを運ぶかどうかを常に知ることができないためです。より良い情報がない限り、送信者は、ACK比の計算を目的として、すべての失われたパケットが非DATAパケットであると仮定する必要があります。必要に応じて、DCCPのNDPカウントオプションを介してより良い情報を利用できます。（付録Bでは、非DATAパケット損失のデータパケット損失を間違えるコストについて説明しています。）
A receiver that implements its own acknowledgement congestion control independent of Ack Ratio SHOULD NOT reduce its DCCP-Ack acknowledgement rate due to losses or marks on its data packets.
ACK比とは無関係に独自の確認渋滞制御を実装するレシーバーは、データパケットの損失またはマークのためにDCCP-ackの確認率を下げるべきではありません。
Ack Ratio always meets three constraints: (1) Ack Ratio is an integer. (2) Ack Ratio does not exceed cwnd/2, rounded up, except that Ack Ratio 2 is always acceptable. (3) Ack Ratio is two or more for a congestion window of four or more packets.
ACK比は常に3つの制約を満たしています：（1）ACK比は整数です。（2）ACK比は、ACK比2が常に許容できることを除いて、CWND/2を超えていません。（3）ACK比は、4つ以上のパケットの輻輳ウィンドウで2つ以上です。
The sender changes Ack Ratio within those constraints as follows. For each congestion window of data with lost or marked DCCP-Ack packets, Ack Ratio is doubled; and for each cwnd/(R^2 - R) consecutive congestion windows of data with no lost or marked DCCP-Ack packets, Ack Ratio is decreased by 1. (See Appendix A for the derivation.) Changes in Ack Ratio are signalled through feature negotiation; see [RFC4340], Section 11.3.
送信者は、次のようにこれらの制約内でACK比を変更します。DCCP-CACKの紛失またはマーク付きのデータの輻輳ウィンドウごとに、ACK比は2倍になります。そして、各CWND/（r^2 -r）DCCP -ackパケットの紛失またはマークのないデータの連続した混雑ウィンドウについて、ACK比は1によって減少します（派生については付録Aを参照）。機能交渉。[RFC4340]、セクション11.3を参照してください。
For a constant congestion window, this gives an Ack sending rate that is roughly TCP friendly. Of course, cwnd usually varies over time; the dynamics will be rather complex, but roughly TCP friendly. We recommend that the sender use the most recent value of cwnd when determining whether to decrease Ack Ratio by 1.
一定の輻輳ウィンドウの場合、これにより、TCPフレンドリーなACK送信率が得られます。もちろん、CWNDは通常、時間とともに変化します。ダイナミクスはかなり複雑ですが、ほぼTCPフレンドリーです。ACK比を1より減少させるかどうかを決定するときに、送信者がCWNDの最新の値を使用することをお勧めします。
The sender need not keep Ack Ratio completely up to date. For instance, it MAY rate-limit Ack Ratio renegotiations to once every four or five round-trip times, or to once every second or two. The sender SHOULD NOT attempt to renegotiate the Ack Ratio more than once per round-trip time. Additionally, it MAY enforce a minimum Ack Ratio of two, or it MAY set Ack Ratio to one for half-connections with persistent congestion windows of 1 or 2 packets.
送信者は、ACK比を完全に最新の状態に保つ必要はありません。たとえば、4〜5回の往復時間ごとに、または1秒または2回に1回、ACK比の再交渉を再交渉を評価する場合があります。送信者は、往復時間ごとにACK比を1回以上再交渉しようとしないでください。さらに、1つまたは2つのパケットの永続的な渋滞ウィンドウを使用して、半接続のためにACK比を1つに設定する場合があります。
Putting it all together, the receiver always sends at least one acknowledgement per window of data when cwnd = 1, and at least two acknowledgements per window of data otherwise. Thus, the receiver could be sending two ack packets per window of data even in the face of very heavy congestion on the reverse path. We would note, however, that if congestion is sufficiently heavy, all the ack packets are dropped, and then the sender falls back on an exponentially backed-off timeout, as in TCP. Thus, if congestion is sufficiently heavy on the reverse path, then the sender reduces its sending rate on the forward path, which reduces the rate on the reverse path as well.
すべてをまとめると、受信者は常に、CWND = 1の場合、データのウィンドウごとに少なくとも1つの確認を送信し、それ以外の場合はデータのウィンドウごとに少なくとも2つの確認を送信します。したがって、レシーバーは、逆パス上の非常に重い輻輳に直面しても、データのウィンドウごとに2つのACKパケットを送信する可能性があります。ただし、混雑が十分に重い場合、すべてのACKパケットがドロップされ、送信者はTCPのように指数関数的に後退したタイムアウトに戻ることに注意してください。したがって、逆のパスで混雑が十分に重い場合、送信者は送信速度を前方パスで減らし、逆パスのレートも削減します。
An active sender DCCP A MUST occasionally acknowledge its peer DCCP B's acknowledgements so that DCCP B can free up Ack Vector state. When both half-connections are active, A's acknowledgements of B's acknowledgements are automatically contained in A's acknowledgements of B's data. If the B-to-A half-connection is quiescent, however, DCCP A must occasionally send acknowledgements proactively, such as by sending a DCCP-DataAck packet that includes an Acknowledgement Number in the header.
アクティブな送信者DCCP Aは、DCCP BがACKベクトル状態を解放できるように、ピアDCCP Bの謝辞を時々認めなければなりません。両方のハーフ接続がアクティブな場合、Bの謝辞のAの謝辞は、BのデータのAの確認に自動的に含まれます。ただし、B-to-Aのハーフ接続が静止している場合、DCCP Aは、ヘッダーに確認番号を含むDCCP-Dataackパケットを送信するなど、肯定的に積極的に送信する必要があります。
An active sender SHOULD acknowledge the receiver's acknowledgements at least once per congestion window. Of course, the sender's application might fall silent. This is no problem; when neither side is sending data, a sender can wait arbitrarily long before sending an ack.
アクティブな送信者は、輻輳ウィンドウごとに少なくとも1回は受信者の謝辞を確認する必要があります。もちろん、送信者の申請は沈黙する可能性があります。これは問題ありません。どちらの側もデータを送信していない場合、送信者はACKを送信する前に任意に長く待つことができます。
This section describes how a CCID 2 receiver determines that the corresponding sender is not sending any data and therefore has gone quiescent. See [RFC4340], Section 11.1, for general information on quiescence.
このセクションでは、CCID 2レシーバーが、対応する送信者がデータを送信しておらず、したがって静止していると判断する方法について説明します。静止に関する一般情報については、[RFC4340]、セクション11.1を参照してください。
Let T equal the greater of 0.2 seconds and two round-trip times. (The receiver may know the round-trip time in its role as the sender for the other half-connection. If it does not, it should use a default RTT of 0.2 seconds, as described in [RFC4340], Section 3.4.) Once the sender acknowledges the receiver's Ack Vectors and the sender has not sent additional data for at least T seconds, the receiver can infer that the sender is quiescent. More precisely, the receiver infers that the sender has gone quiescent when at least T seconds have passed without receiving any data from the sender, and when the sender has acknowledged receiver Ack Vectors covering all data packets received at the receiver.
0.2秒と2回の往復時間の大きいことを等しくします。（受信者は、残りの半分接続の送信者としての往復時間を知っている場合があります。そうでない場合は、[RFC4340]、セクション3.4で説明されているように、0.2秒のデフォルトのRTTを使用する必要があります。）送信者は、受信者のACKベクターと送信者が少なくとも10秒間追加データを送信していないことを認めています。受信者は、送信者が静止していると推測できます。より正確には、受信者は、送信者からデータを受信せずに少なくともt秒が合格した場合、および送信者が受信機で受信したすべてのデータパケットをカバーするレシーバーACKベクターを認めた場合、送信者が静止していることを推測します。
CCID 2 supports Explicit Congestion Notification (ECN) [RFC3168]. The sender will use the ECN Nonce for data packets, and the receiver will echo those nonces in its Ack Vectors, as specified in [RFC4340], Section 12.2. Information about marked packets is also returned in the Ack Vector. Because the information in the Ack Vector is reliably transferred, DCCP does not need the TCP flags of ECN-Echo and Congestion Window Reduced.
CCID 2は、明示的な混雑通知（ECN）[RFC3168]をサポートしています。送信者はデータパケットにECN NonCeを使用し、受信機は[RFC4340]で指定されているように、ACKベクターのそれらの非能力をエコーします。セクション12.2。マークされたパケットに関する情報は、ACKベクターにも返されます。ACKベクトル内の情報は確実に転送されるため、DCCPではECNエコーのTCPフラグとうっ血ウィンドウの削減は必要ありません。
For unmarked data packets, the receiver computes the ECN Nonce Echo as in [RFC3540] and returns it as part of its Ack Vector options. The sender SHOULD check these ECN Nonce Echoes against the expected values, thus protecting against the accidental or malicious concealment of marked packets.
マークされていないデータパケットの場合、受信機は[RFC3540]のようにECNノンセエコーを計算し、ACKベクターオプションの一部として返します。送信者は、これらのECNの非エコーを期待値に対してチェックし、マークされたパケットの偶発的または悪意のある隠蔽から保護する必要があります。
Because CCID 2 acknowledgements are congestion controlled, ECN may also be used for its acknowledgements. In this case we do not make use of the ECN Nonce, because it would not be easy to provide protection against the concealment of marked ack packets by the sender, and because the sender does not have much motivation for lying about the mark rate on acknowledgements.
CCID 2の謝辞は混雑制御されているため、ECNは謝辞にも使用される場合があります。この場合、ECN Nonceを使用しません。なぜなら、送信者によるマークされたACKパケットの隠蔽に対する保護を容易にすることはできないからであり、送信者は謝辞にマークレートについて嘘をつく動機があまりないため。
DCCP's Ack Vector option, and its ECN Capable, Ack Ratio, and Send Ack Vector features, are relevant for CCID 2.
DCCPのACKベクトルオプション、およびECN能力があるACK比、およびACKベクターの機能の送信は、CCID 2に関連しています。
Security considerations for DCCP have been discussed in [RFC4340], and security considerations for TCP have been discussed in [RFC2581].
DCCPのセキュリティ上の考慮事項は[RFC4340]で議論されており、TCPのセキュリティ上の考慮事項は[RFC2581]で議論されています。
[RFC2581] discusses ways in which an attacker could impair the performance of a TCP connection by dropping packets, or by forging extra duplicate acknowledgements or acknowledgements for new data. We are not aware of any new security considerations created by this document in its use of TCP-like congestion control.
[RFC2581]は、攻撃者がパケットをドロップするか、新しいデータの追加の謝辞または謝辞を偽造することにより、TCP接続のパフォーマンスを損なう方法について説明します。TCPのような混雑制御を使用してこのドキュメントによって作成された新しいセキュリティ上の考慮事項を認識していません。
This specification defines the value 2 in the DCCP CCID namespace managed by IANA. This assignment is also mentioned in [RFC4340]. CCID 2 also introduces three sets of numbers whose values should be allocated by IANA; namely, CCID 2-specific Reset Codes, option types, and feature numbers. These ranges will prevent any future CCID 2-specific allocations from polluting DCCP's corresponding global namespaces; see [RFC4340], Section 10.3. However, this document makes no particular allocations from any range, except for experimental and testing use [RFC3692]. We refer to the Standards Action policy outlined in [RFC2434].
この仕様では、IANAが管理するDCCP CCIDネームスペースの値2を定義します。この割り当ては[RFC4340]にも記載されています。CCID 2は、IANAによって値を割り当てる必要がある3セットの数字を導入します。つまり、CCID 2固有のリセットコード、オプションタイプ、および機能番号。これらの範囲は、将来のCCID 2固有の割り当てがDCCPの対応するグローバルネームスペースを汚染することを防ぎます。[RFC4340]、セクション10.3を参照してください。ただし、このドキュメントは、実験およびテストの使用を除き、どの範囲からも特定の割り当てを行いません[RFC3692]。[RFC2434]で概説されている標準アクションポリシーを参照します。
Each entry in the DCCP CCID 2 Reset Code registry contains a CCID 2-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 2リセットコードレジストリの各エントリには、範囲128-255の数字であるCCID 2固有のリセットコードが含まれています。リセットコードの簡単な説明。リセットコードを定義するRFCへの参照。リセットコード184-190および248-254は、実験およびテストの使用のために永続的に予約されています。残りのリセットコード（128-183、191-247、および255）は現在予約されており、IESGのレビューと承認、および標準トラックIETF RFC RFC出版物を必要とする標準アクションポリシーで割り当てる必要があります。
Each entry in the DCCP CCID 2 option type registry contains a CCID 2-specific option type, which is a number in the range 128-255; the name of the option; and a reference to the RFC defining the option type. Option types 184-190 and 248-254 are permanently reserved for experimental and testing use. The remaining option types -- 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 2オプションタイプレジストリの各エントリには、CCID 2固有のオプションタイプが含まれています。これは範囲128-255の数字です。オプションの名前。オプションタイプを定義するRFCへの参照。オプションタイプ184-190および248-254は、実験およびテストの使用のために永続的に予約されています。残りのオプションタイプ（128-183、191-247、および255）は現在予約されており、IESGのレビューと承認、および標準トラックIETF RFC RFC出版物を必要とする標準アクションポリシーに割り当てる必要があります。
Each entry in the DCCP CCID 2 feature number registry contains a CCID 2-specific feature number, which is a number in the range 128-255; the name of the feature; and a reference to the RFC defining the feature number. Feature numbers 184-190 and 248-254 are permanently reserved for experimental and testing use. The remaining feature numbers -- 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 2機能番号レジストリの各エントリには、範囲128-255の数字であるCCID 2固有の特徴番号が含まれています。機能の名前。および機能番号を定義するRFCへの参照。機能番号184-190および248-254は、実験およびテストの使用のために永久に予約されています。残りの機能番号（128-183、191-247、および255）は現在予約されており、IESGのレビューと承認、および標準トラックIETF RFC RFC出版物を必要とする標準アクションポリシーに割り当てる必要があります。
We thank Mark Handley and Jitendra Padhye for their help in defining CCID 2. We also thank Mark Allman, Aaron Falk, Nils-Erik Mattsson, Greg Minshall, Arun Venkataramani, Magnus Westerlund, and members of the DCCP Working Group for feedback on this document.
CCID 2を定義する際に助けてくれたMark HandleyとJitendra Padhyeに感謝します。MarkAllman、Aaron Falk、Nils-Erik Mattsson、Greg Minshall、Arun Venkataramani、Magnus Westerlund、およびDCCPワーキンググループのメンバーは、この文書に関するフィードバックについて。
A. Appendix: Derivation of Ack Ratio Decrease
A.付録：ACK比の導出減少
This section justifies the algorithm for increasing and decreasing the Ack Ratio given in Section 6.1.2.
このセクションでは、セクション6.1.2で与えられたACK比を増加および減少させるためのアルゴリズムを正当化します。
The congestion avoidance phase of TCP halves the cwnd for every window with congestion. Similarly, CCID 2 doubles Ack Ratio for every window with congestion on the return path, roughly halving the DCCP-Ack sending rate.
TCPの混雑回避段階は、混雑のあるすべてのウィンドウのCWNDを半分にします。同様に、CCID 2は、リターンパスに輻輳があるすべてのウィンドウのACK比を2倍にし、DCCP-ack送信率をほぼ半分にします。
The congestion avoidance phase of TCP increases cwnd by one MSS for every congestion-free window. When this congestion avoidance behavior is applied to acknowledgement traffic, this would correspond to increasing the number of DCCP-Ack packets per window by one after every congestion-free window of DCCP-Ack packets. We cannot achieve this exactly using Ack Ratio, since it is an integer. Instead, we must decrease Ack Ratio by one after K windows have been sent without a congestion event on the reverse path, where K is chosen so that the long-term number of DCCP-Ack packets per congestion window is roughly TCP friendly, following AIMD congestion control.
TCPの輻輳回避段階は、渋滞のないウィンドウごとに1つのMSSによってCWNDを増加させます。この混雑回避動作が確認トラフィックに適用されると、これは、DCCP-ackパケットの渋滞のないウィンドウのたびに、ウィンドウあたりのDCCP-ackパケットの数を1つずつ増やすことに対応します。整数であるため、ACK比を使用してこれを正確に達成することはできません。代わりに、k Windowsが逆パスで混雑イベントなしで送信された後、ACK比を1つずつ減らす必要があります。ここで、kを選択して、輻輳ウィンドウごとのDCCP-ackパケットの長期数がほぼTCPフレンドリーであるように、AIMDに続きます。混雑制御。
In CCID 2, rough TCP-friendliness for the ack traffic can be accomplished by setting K to cwnd/(R^2 - R), where R is the current Ack Ratio.
CCID 2では、ACKトラフィックの大まかなTCPフレンドリーは、KをCWND/（r^2 -R）に設定することで実現できます。ここで、Rは現在のACK比です。
This result was calculated as follows:
この結果は次のように計算されました。
R = Ack Ratio = # data packets / ack packets, and
W = Congestion Window = # data packets / window, so
W/R = # ack packets / window.
Requirement: Increase W/R by 1 per congestion-free window. Since we can only reduce R by increments of one, we find K so that, after K congestion-free windows, W/R + K would equal W/(R-1).
要件：混雑のないウィンドウごとにw/rを1倍に増やします。rを1つずつ削減できるため、kを削減することができるため、kの混雑のないウィンドウの後、w/r kがw/（r-1）に等しくなります。
(W/R) + K = W/(R-1), so K = W/(R-1) - W/R = W/(R^2 - R).
（w/r）k = w/（r -1）、したがって、k = w/（r -1）-w/r = w/（r^2 -r）。
B. Appendix: Cost of Loss Inference Mistakes to Ack Ratio
B.付録：損失のコスト推論の間違いとACK比率
As discussed in Section 6.1.1, the sender often cannot determine whether lost packets carried data. This hinders its ability to separate non-data loss events from other loss events. In the absence of better information, the sender assumes, for the purpose of Ack Ratio calculation, that all lost packets were non-data packets. This may overestimate the non-data loss event rate, which can lead to a too-high Ack Ratio, and thus to a too-slow acknowledgement rate. All acknowledgement information will still get through -- DCCP acknowledgements are reliable -- but acknowledgement information will arrive in a burstier fashion. Absent some form of rate-based pacing, this could lead to increased burstiness for the sender's data traffic.
セクション6.1.1で説明したように、送信者は、失われたパケットがデータを掲載したかどうかを判断することができないことがよくあります。これは、他の損失イベントから非DATA損失イベントを分離する能力を妨げます。より良い情報がない場合、送信者は、ACK比の計算を目的として、失われたパケットはすべて非DATAパケットであると想定しています。これにより、非DATA損失イベント率が過大評価されている可能性があります。これにより、ACK比が高すぎる可能性があり、したがって、あまりにもスローの確認率につながる可能性があります。すべての承認情報は引き続き通過します - DCCPの謝辞は信頼できます - しかし、謝辞情報は驚くべき方法で届きます。何らかの形のレートベースのペーシングがなければ、これにより、送信者のデータトラフィックの破裂が増加する可能性があります。
There are several cases when the problem of an overly-high Ack Ratio, and the resulting increased burstiness of the data traffic, will not arise. In particular, call the receiver DCCP B and the sender DCCP A:
過度に高いACK比の問題と、結果として生じるデータトラフィックの破裂の増加が発生しない場合、いくつかのケースがあります。特に、レシーバーDCCP Bと送信者DCCP Aに電話してください。
o The problem won't arise unless DCCP B is sending a significant amount of data itself. When the B-to-A half-connection is quiescent or low rate, most packets sent by DCCP B will, in fact, be pure acknowledgements, and DCCP A's estimate of the DCCP-Ack loss rate will be reasonably accurate.
o DCCP Bがかなりの量のデータ自体を送信しない限り、問題は発生しません。B-to-aのハーフ接続が静止または低いレートである場合、DCCP Bによって送信されたほとんどのパケットは実際には純粋な承認であり、DCCP AのDCCP-ack損失率の推定値はかなり正確になります。
o The problem won't arise if DCCP B habitually piggybacks acknowledgement information on its data packets. The piggybacked acknowledgements are not limited by Ack Ratio, so they can arrive frequently enough to prevent burstiness.
o DCCP Bが習慣的にピギーバックのデータパケットに関する情報を習慣的にピギーバックする場合、問題は発生しません。ピギーバックされた謝辞はACK比に制限されていないため、乱暴さを防ぐのに十分な頻繁に到着することができます。
o The problem won't arise if DCCP A's sending rate is low, since burstiness isn't a problem at low rates.
o DCCP Aの送信率が低い場合、問題は発生しません。
o The problem won't arise if DCCP B's sending rate is high relative to DCCP A's sending rate, since the B-to-A loss rate must be low to support DCCP B's sending rate. This bounds the Ack Ratio to reasonable values even when DCCP A labels every loss as a DCCP-Ack loss.
o DCCP BがDCCP Bの送信率をサポートするために低い損失率が低くなければならないため、DCCP Bの送信率がDCCP Aの送信率に比べて高い場合、問題は発生しません。これにより、DCCPがすべての損失をDCCP-CACK損失としてラベル付けする場合でも、ACK比を妥当な値にバウンドします。
o The problem won't arise if DCCP B sends NDP Count options when appropriate (the Send NDP Count/B feature is true). Then the sender can use the receiver's NDP Count options to detect, in most cases, whether lost packets were data packets or DCCP-Acks.
o DCCP Bが必要に応じてNDPカウントオプションを送信する場合、問題は発生しません（送信NDPカウント/B機能は真）。その後、送信者はレシーバーのNDPカウントオプションを使用して、ほとんどの場合、失われたパケットがデータパケットまたはDCCP-CACKであるかどうかを検出できます。
o Finally, the problem won't arise if DCCP A rate-paces its data packets.
o 最後に、DCCPがデータパケットをレートに掲載した場合、問題は発生しません。
This leaves the case when DCCP B is sending roughly the same amount of data packets and non-data packets, without NDP Count options, and with all acknowledgement information in DCCP-Ack packets. We now quantify the potential cost, in terms of a too-large Ack Ratio, due to the sender's misclassifying data packet losses as DCCP-Ack losses. For simplicity, we assume an environment of large-scale statistical multiplexing where the packet drop rate is independent of the sending rate of any individual connection.
これにより、DCCP BがNDPカウントオプションなしでほぼ同じ量のデータパケットと非DATAパケットを送信し、DCCP-CACKパケットにすべての確認情報を送信している場合があります。DCCP-ack損失として送信者の誤分類データパケット損失のために、あまりにも大きなACK比の観点から、潜在的なコストを定量化します。簡単にするために、パケットドロップレートが個々の接続の送信率とは無関係である大規模な統計的多重化の環境を想定しています。
Assume that when DCCP A correctly counts non-data losses, Ack Ratio is set so that B-to-A data and acknowledgement traffic both have a sending rate of D packets per second. Then when DCCP A incorrectly counts data losses as non-data losses, the sending rate for the B-to-A data traffic is still D pps, but the reduced sending rate for the B-to-A acknowledgement traffic is f*D pps, with f < 1. Let the packet loss rate be p. The sender incorrectly estimates the non-data loss rate as (pD+pfD)/fD, or, equivalently, as p(1 + 1/f). Because the congestion control mechanism for acknowledgement traffic is roughly TCP friendly, and therefore the non-data sending rate and the data sending rate both grow as 1/sqrt(x) for x the packet drop rate, we have
DCCP Aが非DATA損失を正しくカウントすると、ACK比が設定され、B-to-Aデータと確認トラフィックの両方が1秒あたりのDパケットの送信率があると仮定します。次に、DCCP Aがデータ損失を非DATA損失として誤ってカウントする場合、B-to-Aデータトラフィックの送信率は依然としてD PPSですが、B-to-Aの確認トラフィックの送信率の低下はf*d PPSです、f <<1。パケット損失率をp。送信者は、非DATA損失率を（PD PFD）/FD、または同等にP（1 1/F）として誤って推定します。確認トラフィックの混雑制御メカニズムはほぼTCPフレンドリーであるため、Xの非DATA送信率とデータ送信率は両方ともパケットドロップレートの1/SQRT（x）として成長しているため、私たちは持っています。
fD/D = sqrt(p)/sqrt(p(1 + 1/f)),
fd/d = sqrt（p）/sqrt（p（1 1/f））、
so
それで
f^2 = 1/(1 + 1/f).
f^2 = 1/（1 1/f）。
Solving, we get f = 0.62. If the sender incorrectly counts lost data packets as non-data in this scenario, the acknowledgement rate is decreased by a factor of 0.62. This would result in a moderate increase in burstiness for the A-to-B data traffic, which could be mitigated by sending NDP Count options or piggybacked acknowledgements, or by rate-pacing out the data.
解決すると、F = 0.62が取得されます。送信者がこのシナリオで失われたデータパケットを非DATAとして誤ってカウントする場合、確認率は0.62倍に低下します。これにより、A-bデータトラフィックの破裂が中程度の増加になり、NDPカウントオプションやピギーバック型の謝辞を送信するか、データをレートアウトすることで軽減できます。
Normative References
引用文献
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgement Options", RFC 2018, October 1996.
[RFC2018] Mathis、M.、Mahdavi、J.、Floyd、S。、およびA. Romanow、「TCP Selective Ascondage Options」、RFC 2018、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581] Allman、M.、Paxson、V。、およびW. Stevens、「TCP渋滞制御」、RFC 2581、1999年4月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988] Paxson、V。およびM. Allman、「TCPの再送信タイマーのコンピューティング」、RFC 2988、2000年11月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, October 2002.
[RFC3390] Allman、M.、Floyd、S。、およびC. Partridge、「TCPの初期ウィンドウの増加」、RFC 3390、2002年10月。
[RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP", RFC 3517, April 2003.
[RFC3517] Blanton、E.、Allman、M.、Fall、K。、およびL. Wang、「TCPの保守的な選択的承認（SACK）ベースの損失回復アルゴリズム」、RFC 3517、2003年4月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692] Narten、T。、「有用と見なされる実験数とテスト数の割り当て」、BCP 82、RFC 3692、2004年1月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagramうっ血制御プロトコル（DCCP）」、RFC 4340、2006年3月。
Informative References
参考引用
[RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion Window Validation", RFC 2861, June 2000.
[RFC2861] Handley、M.、Padhye、J。、およびS. Floyd、「TCP混雑ウィンドウ検証」、RFC 2861、2000年6月。
[RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte Counting (ABC)", RFC 3465, February 2003.
[RFC3465] Allman、M。、「適切なバイトカウント（ABC）を備えたTCP混雑制御」、RFC 3465、2003年2月。
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003.
[RFC3540] Spring、N.、Wetherall、D。、およびD. Ely、「Noncesによる堅牢な明示的な混雑通知（ECN）シグナル伝達」、RFC 3540、2003年6月。
[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月。
[V03] Arun Venkataramani, August 2003. Citation for acknowledgement purposes only.
[V03] Arun Venkataramani、2003年8月。謝辞のみの引用のみ。
Authors' Addresses
著者のアドレス
Sally Floyd ICSI Center for Internet Research 1947 Center Street, Suite 600 Berkeley, CA 94704 USA
サリーフロイドICSIセンターフォーインターネットリサーチ1947センターストリート、スイート600バークレー、カリフォルニア州94704 USA
EMail: floyd@icir.org
Eddie Kohler 4531C Boelter Hall UCLA Computer Science Department Los Angeles, CA 90095 USA
Eddie Kohler 4531C Boelter Hall UCLAコンピューターサイエンス部ロサンゼルス、カリフォルニア州90095 USA
EMail: kohler@cs.ucla.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。