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
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document contains the profile for Congestion Control Identifier 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.
この文書では、データグラム輻輳制御プロトコル（DCCP）に、輻輳制御識別子2（CCID 2）、TCPのような輻輳制御のためのプロファイルが含まれています。 CCID 2は、急速に変化する状況での環境で利用可能な帯域幅を利用したい送信者によって使用されなければならない、と誰がTCPの添加剤は、乗算減少を増やす（AIMD）輻輳の典型的な輻輳ウィンドウの急激な変化に適応することができますコントロール。
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.
この文書は、データグラム輻輳制御プロトコル（DCCP）[RFC4340]に、輻輳制御識別子2（CCID 2）、TCPのような輻輳制御のためのプロファイルを含みます。 DCCPは、半接続で使用中の輻輳制御機構を指定するには、輻輳制御識別子、またはのCCIDsを使用しています。
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は、選択的肯定応答（SACK）の変異体[RFC2018、RFC3517]を組み込んで、TCPの輻輳制御機構のクローズ変異体を使用してデータを送信します。 TCPの添加剤の典型的な輻輳ウィンドウの急激な変化に適応できる送信者は、乗算減少（AIMD）輻輳制御、および急速に変化する環境で利用可能な帯域幅を利用したい送信者のために特に有用を増やすためにCCID 2が適当です条件。アプリケーション要件の詳細については、セクション3を参照してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
A DCCP half-connection consists of the application data sent by one endpoint and the corresponding acknowledgements sent by the other endpoint. The terms "HC-Sender" and "HC-Receiver" denote the endpoints sending application data and acknowledgements, respectively. Since CCIDs apply at the level of half-connections, we abbreviate HC-Sender to "sender" and HC-Receiver to "receiver" in this document. See [RFC4340] for more discussion.
DCCP半接続は、一方のエンドポイントによって送信されたアプリケーションデータ及び他のエンドポイントによって送信され、対応する肯定応答から成ります。用語「HC-送信者」及び「HC-受信機」は、それぞれ、アプリケーションデータおよび肯定応答を送信するエンドポイントを示します。 CCIDsハーフ接続のレベルで適用されますので、私たちは、「送信者」とHC-レシーバこのドキュメントの「受信機」へとHC-送信者を短縮します。より多くの議論のための[RFC4340]を参照してください。
For simplicity, we say that senders send DCCP-Data packets and receivers send DCCP-Ack packets. Both of these categories are meant to include DCCP-DataAck packets.
簡単にするために、我々は、送信者がDCCP - データパケットと受信機がDCCP-ACKパケットを送信する送信することを言います。これらのカテゴリの両方がDCCP-DataAckパケットを含むことを意味します。
The phrases "ECN-marked" and "marked" refer to packets marked ECN Congestion Experienced unless otherwise noted.
パケットを参照してください「と記された」フレーズ「ECN-マーク」とは、特に断りのない限り、経験豊富なECNの輻輳をマーク。
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.
CCID 2、TCPのような輻輳制御は、エンドツーエンドの輻輳制御の使用と一致し、長期的に可能な限り多くの帯域幅を、受け取りたい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の実装は、CCID 2に明示的なアップデートを待つのではなく、直接TCPの進化を追跡する必要があります。
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での使用のために標準化されていないメカニズムを輻輳制御を適用します。
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.
DCCPデータグラムプロトコルはO、かかる輻輳ウィンドウ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.送信者は、TCPのように、送信されたパケットの数が輻輳ウィンドウによって支配されているDCCP - データパケット、CWNDを送信します。各DCCP - データパケットは、シーケンス番号を使用しています。送信者は、受信機からのACKパケットによってカバーされるデータパケットの数を指定したAck比フィーチャオプションを送信します。 2にACK比率のデフォルト値。 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 - データパケットは、ECT（0）かECT（1）コードポイントのいずれかとすることができる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-ACKパケットを送信します。各DCCP-Ackパケットは、シーケンス番号を使用してのAckベクトルが含まれています。 DCCP-Ackパケットで確認応答シーケンス番号が最も高いシーケンス番号を有する受信したパケットのそれです。それは、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.
受信側は、送信側が受信側確率が誤動作されていないことを確認することができ、肯定応答ベクトルオプションを介して受信したECNナンスの和を返します。送信側がACK比率機能を使用しておおよそTCPフレンドリーな方法で確認応答速度を制御するので、受信機からのDCCP-ACKパケットはまた、可能ECNとして送信されます。送信側が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 - データパケットを送信し続けます。 DCCP-ACKパケットを受信すると、送信者はマークまたはドロップされたデータパケットについて学ぶために彼らの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-ACKパケットは、シーケンス番号を使用しているため、送信者は、紛失したり、マークDCCP-ACKパケットに関するいくつかの情報を持っています。送信者は受信者に送信されたAck比を変更することで、紛失またはマークDCCP-ACKパケットに応答します。
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つの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が行うか、明示的なタイムスタンプ・オプションを使用して、タイムアウト（TO）RTOほど値が（タイムアウトを再送信）TCPで計算される計算として承認往復時間を追跡することによって。 TOは、送信者が混雑ウィンドウによって制限されてきたとのフィードバックが受信機から受信されていない場合、新しいDCCP - データパケットが送信されることができるときを決定します。
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（Ackをベクトル、1を送信）」受信機にオプションを送らなければなりません。それは、対応する受信されるまで送信側がデータを送るべきではありません、受信機からのDCCP-Requestパケットにデータを送信することができることを除いて「確認Lを（1のAckベクトル、送信）」。
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 Vectorが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-データ、DCCP-DataAck、およびDCCP - 要求とDCCP-Response）を
2. The slow-start threshold "ssthresh", which controls adjustments to cwnd.
cwndをするための調整を制御2.スロースタート閾値「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.
これらのパラメータは、それらは、パケットではなく、バイト単位で測定されていることを除いて、SACKベースの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.
送信者は、データパケットを送信することができたときにパイプ<cwndのが、データ・パケットパイプ送ってはいけません> =に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. ACKされたデータパケット。送信者は、いくつかの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に設定されています。パケットPが遅れるのではなく、失われると推定される受信した、Pの後に送信されたときに、少なくともNUMDUPACKパケットが（肯定応答ベクトル状態0又は1）が受信機によって肯定応答されています。穴次肯定応答パケットはDCCP-Acksをまたは他の非データ・パケットであってもよいことに留意されたいです。
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回のラウンドトリップ時間を推定し、平均偏差、平均往復時間を維持するためのTCPアルゴリズムを使用し、タイムアウト値[RFC2988]。 （ラウンドトリップ時間ごとに複数の測定がこれらの計算に使用した場合、平均器の重みは、平均往復時間を効果的に複数の往復時間にわたって測定から導出されることを確実にするために調整されなければなりません。） DCCPはデータを再送しないので、DCCPは、1秒のTCPの推奨最小タイムアウトを必要としません。タイマーの指数バックオフは正確に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.
送信者は、データパケットごとに複数回パイプをデクリメントしてはなりません。真の重複確認応答は、例えば、パイプに影響してはいけません。送信者はまた、失われたとして、以前に推測されたパケットの確認応答を受信すると、再びパイプをデクリメントしてはなりません。さらに、送信側は、ACKベクターは、それらの情報が含まれていますにもかかわらず、このようDCCP-Acksをなどの非データパケットのためのパイプをデクリメントしてはなりません。
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を引き起こします。輻輳イベントは、少なくとも一つの紛失またはマークされたパケットが含まれています。第2のパケットが検出された最初のパケットの損失やマークの前に送信された場合、TCPのように、2敗又はマークは単一の輻輳イベントの一部とみなされます。近似として、送信側がパケットを、パケットが送信された時点でのRTT推定電流を用いて、互いのRTT推定値内に送信されたときに単一の輻輳イベントの一部であるために、2つの損失やマークを考慮することができます。各輻輳イベントのためには、ACKベクトル状態1（ECN-マーク）確認応答として明示的に示されているいずれか、または「重複確認応答」を介して、推論、CWNDを半分にし、SSTHRESHを新しいCWNDに設定されています。 CWNDは1つのパケット未満に低減されることはありません。タイムアウト後、スロースタート閾値は/ 2をcwndをするように設定され、その後、CWNDは、一つのパケットに設定されています。半減するとそれにcwndが1未満になることはありませんとSSTHRESHが2未満になることはありませんを除いて、CWNDとSSTHRESHは、それらの値は、切り捨てています。
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比の最大値まで、のAckベクトル状態0（ECN-マークされていない）との2つのずつ、新たに承認されたデータパケットのための一つのパケットだけ増加させ承認あたり2つのパケット。これは、適切なバイトカウント（バイトカウントを含まない）TCPの現在の標準と一致している[RFC3465]の改変された形態であるが、CCID 2の肯定応答の比が既定値よりも大きい場合CCID 2はTCPとして積極的に増加することができ二。 > = SSTHRESH cwndをすると、輻輳ウィンドウが失われたり、マークされたパケットなしに認めデータのすべてのウィンドウのための一つのパケットによって増加します。 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のDataオプションは、受信機がパケットをアプリケーションに配信する前に、エンドホストでドロップされたことを宣言することができます下落しました。 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は」それが1以下に低減されることはありませんことを除いて、新たにドロップコード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は、一般的に固定パケットサイズを使用し、輻輳に応答して第2あたりのパケットでそれらの送信レートを変えるアプリケーション用に最適化されます。 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ベクトルオプションを含まなければなりません。肯定応答ベクトルオプションで確認応答データは、一般に、受信機の全体の確認応答ウィンドウをカバーすべきです。 [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の肯定応答比フィーチャを使用します。これは現在、純粋な承認トラフィックの輻輳制御を持っていないTCPとは異なります。 CCID 2のリバースパス輻輳制御はTCPフレンドリーになろうとしません。それだけで輻輳崩壊を回避するために、およびTCPが高いパケット損失の存在であるよりも幾分良好であるか、または逆の経路上の率をマークしようとします。デフォルトのAck比は2であり、このAckを比でCCID 2遅延ACKとTCPのように振る舞います。 [RFC4340]、セクション11.3は、ペーシングおよびDCCP-DataAckパケットを了承との関係を含め、より詳細に肯定応答比を記載しています。このドキュメントのセクション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データパケットごとにDCCP-ACKパケットを送信します。送信者は往復の時間あたりのcwndのデータパケットを送信しているので、確認応答率は、ラウンドトリップ時間あたりのcwnd / R DCCP-ACKが等しいです。送信者は、失われたとマークされDCCP-ACKパケットに対する肯定応答ストリームを監視し、それに応じてRを変更することで、おおよそTCP優しい承認率を維持します。 DCCP-Ackの輻輳イベントを含むすべてのRTT（つまり、紛失またはマークDCCP-Ackのである）の場合、送信側は、ACK比率を2倍にすることにより、確認応答率を半減します。すべてのRTTが全くDCCP-Ackの輻輳イベントを含まないため、それは付加的の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-ACKパケットは、一般的に小さくしているので、彼らはDCCP - データとDCCP-DataAckパケットよりも混雑ネットワークリンクにはあまり負荷を課すかもしれません。このため、Ackを比率ではなく、受信機のすべてのパケットに集約損失やマークの受信機の非データパケットを、上の損失やマークに依存します。 DCCP-Ackを、DCCP-クローズ、DCCP-CloseReq、DCCP-リセット、DCCP-同期、およびDCCP-SyncAck：非データパケットのカテゴリは、アプリケーションデータを運ぶことができないそれらのパケットタイプで構成されています。送信者は、簡単に他のマークから非データマークを区別することができます。送信者は常に失われたパケットはデータを実施するかどうかを知ることができないので、これは、しかし、損失のために困難です。それは、より良い情報を持っていない限り、送信者は、すべての失われたパケットが非データパケットだったことは、ACK比率計算の目的のために、前提とすべきです。必要に応じて、より良い情報は、DCCPのNDPカウントオプションを介して利用可能です。 （付録Bは、非データパケット損失のためのデータパケットの損失を誤るコストについて説明します。）
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比はCWND / 2を超えない場合は、ACK比率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-ACKパケットを有するデータの各輻輳ウィンドウのためには、ACK比率が2倍になります。各CWND /（R ^ 2 - R）には、失われたまたはマークDCCP-ACKパケットを有するデータの連続的な輻輳ウィンドウは、ACK比は1だけ減少される（導出については、付録Aを参照。）のAck比の変更はを通じてシグナリングされます機能ネゴシエーション。 [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フレンドリーになります。私たちは、1でのAck比率を減少させるかどうかを判断する際、送信者は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比を維持する必要はありません。例えば、それはレートを制限するかもしれAckを比再交渉を一度4または5往復時間に、または1秒に1回または2に。送信者は複数回往復時間あたりよりのAck比を再交渉を試みるべきではありません。さらに、それは2の最小のAck比を強制する場合もあれば、1つのまたは2のパケットの持続的な輻輳ウィンドウを持つハーフの接続のための1つのにACK比率を設定することができます。
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.
一緒にすべてを入れて、受信機は常にそうでない= 1 cwndをするときに、データのウィンドウごとに少なくとも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 BがAckでベクトルの状態を解放できるように、アクティブな送信者DCCP Aは時折そのピアDCCP Bの承認を確認する必要があります。半接続の両方がアクティブである場合、Bの確認応答のAの肯定応答が自動的にBのデータのAの確認応答に含まれています。 Bツー半接続が静止している場合、しかし、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.
アクティブな送信者は輻輳ウィンドウごとに少なくとも一度受信者の承認を認めるべきです。もちろん、送信者のアプリケーションは、サイレント落ちるかもしれません。これは問題ありません。どちらの側がデータを送信しているとき、送信者は長い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.
Tは0.2秒と2往復時間の大きいを等しくしてみましょう。 （受信機は、他の半分接続の送信者としての役割に往復時間を知っているかもしれません。そうでない場合は、[RFC4340]、セクション3.4で説明したように、それは、0.2秒のデフォルトRTTを使用する必要があります。）一度送信者が受信者のAckをベクトルを認識し、送信者が少なくともT秒のための追加のデータを送信していない、受信側は送信者が静止していることを推測することができます。より正確には、受信機は、少なくとも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]、セクション12.2で指定されるように、受信機は、自身のACKベクターにおけるそれらのナンスをエコーします。マークされたパケットに関する情報もAckをベクトルで返されます。 Ack Vector内の情報が確実に伝達されているので、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ベクトルオプションの一部として返します。送信者は、このようにマークされたパケットの偶発的または悪質な隠蔽からの保護、期待値に対してこれらの電子証券取引ネットワークのNonceエコーズをチェックする必要があります。
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は、その肯定応答のために使用することもできます。送信者によってマークされたACKパケットの隠蔽に対する保護を提供することは容易ではありませんので、送信者が受信確認のマーク率について嘘のために多くの動機を持っていないので、このケースでは、電子証券取引ネットワークのNonceを使用しません。
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特有のリセットコード、オプションタイプ、および機能番号。これらの範囲はDCCPの対応するグローバル名前空間を汚染から将来CCID 2固有の割り当てを防止します。 [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の公表を要求する標準化活動方針、で割り当てる必要があります。
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オプションタイプレジストリ内の各エントリは範囲128〜255の数でありCCID 2固有のオプションタイプを含み、オプションの名前。およびオプションタイプを定義するRFCへの参照。オプションの種類184から190と248から254は恒久的な実験とテスト用に予約されています。残りのオプションの種類 - 128から183まで、191から247、および255 - 現在予約されており、IESGレビューと承認および標準化過程IETF 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の公表を要求する標準化活動方針、で割り当てる必要があります。
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.
私たちは、我々はまた、このドキュメントにフィードバックするために、マークオールマン、アーロンフォーク、ニルス・エリック・マットソン、グレッグMinshall、アルンVenkataramani、マグヌスウェスター、およびDCCP作業部会のメンバーに感謝CCID 2を定義する際に彼らの助けのためのマーク・ハンドリーとJitendra Padhyeに感謝します。
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は略DCCP-Ackの送信レートを半分に、戻り経路上の混雑を持つすべてのウィンドウに対する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パケットのすべての混雑のないウィンドウの後1によってウィンドウごとDCCP-ACKパケットの数を増やすことに対応します。それが整数であるため、我々は、この正確に使用したAck比を達成することはできません。代わりに、私たちKウィンドウ次々てACK比率を減少しなければならないが、輻輳ウィンドウごとのDCCP-ACKパケットの長期的な数はAIMD以下、およそTCPフレンドリーになるように、Kが選択されている逆の経路、上の輻輳イベントなしで送られてきました輻輳制御。
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.
、Rは現在のAck比である - CCID 2において、ACKトラフィックの粗いTCPフレンドリーは、/（R R ^ 2）cwndをするためにKを設定することによって達成することができます。
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).
要件：混雑のない窓あたり1でW / Rを大きくしてください。我々は唯一の増分でRを減少させることができるので、我々はW /（R-1）のように、K輻輳無窓の後、W / R + Kが等しくなるKを見つけます。
(W/R) + K = W/(R-1), so K = W/(R-1) - W/R = W/(R^2 - R).
（R / W）+ 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項で述べたように、送信者は多くの場合、失われたパケットはデータを搭載するかどうかを判断することはできません。これは、他の損失イベントから非データ損失イベントを分離する能力を妨げます。より良い情報がない場合には、送信者がすべて失われたパケットが非データ・パケットだったことは、ACK比率計算の目的のために、想定しています。これは高すぎるの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.
DCCP Bは、データ自体が大量に送信されていない限り、Oの問題が発生しません。 B-へ半接続が休止または低速である場合には、DCCP Bによって送信された大部分のパケットは、実際には、DCCP-Ackの損失率のこと純粋な確認応答、およびDCCP Aの推定値はかなり正確になります。
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.
DCCP Bは、習慣的にそのデータパケットの送達確認情報をピギーバックした場合、Oの問題が発生しません。彼らは頻繁に十分なバーストを防ぐために着くことができるようにピギーバック確認応答は、肯定応答比によって限定されるものではありません。
o The problem won't arise if DCCP A's sending rate is low, since burstiness isn't a problem at low rates.
DCCP Aの送信レートが低い場合にはバースト性が低いレートでの問題ではないので、Oの問題は、発生しません。
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.
DCCP Bの送信レートは、DCCP Aの送信速度に比べて高い場合にはB・ツー・ロス率はDCCP Bの送信レートをサポートするために低くなければならないので、Oの問題は、発生しません。これはDCCP AはDCCP-Ackの損失として、すべての損失にラベルを付けても、妥当な値に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の問題は、適切な（B機能が真である/カウントNDPを送信）するときDCCP Bは、NDPカウントオプションを送信した場合に発生しません。そして、送信者は、失われたパケットは、データパケットまたはDCCP-ACKをしたかどうか、ほとんどの場合、検出するために、受信機のNDPカウントオプションを使用することができます。
o Finally, the problem won't arise if DCCP A rate-paces its data packets.
DCCP Aのそのデータパケットをレートは、ペーシング場合O最後に、問題が発生しません。
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カウントオプションなし、およびDCCP-ACKパケット内のすべての送達確認情報と、おおよそのデータパケットと非データパケットの同じ量を送信している場合を残します。私たちは今、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
B・ツー・データと確認応答トラフィックの両方が毎秒Dパケットの送信レートを持つようにDCCP Aが正しく非データ損失をカウントしたときには、ACK比率が設定されているものとします。そして、DCCP Aが誤っ非データ損失、B・ツー・データ・トラフィックは、まだD PPSですが、B・ツー・承認トラフィックのために減少し、送信速度が* fとD PPSため、送信速度などのデータ損失をカウントしたときに、F <1でパケット損失率をpとします。送信者が誤って（PD + PFD）/ FD、または、等価的に、P（1 + 1 / f）のような非データ損失率を推定します。 （x）は、パケットのドロップ率xに対して、我々は承認トラフィックのための輻輳制御機構は、おおよそTCPフレンドリーであるため、非データ送信レートとレートのデータ送信は、1 / SQRTとして成長の両方ので
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を取得します。送信者が誤ってこのシナリオでは非データとして失われたデータパケットをカウントした場合は、確認応答率は0.62倍に低下しています。これは、NDPはオプションまたはピギーバック確認をカウント送信することにより、またはレートペーシングデータをアウトによって軽減することができ、A-に-Bのデータトラフィックのためのバースト性の緩やかな増加をもたらすでしょう。
Normative References
引用規格
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]ポステル、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]マティス、M.、Mahdavi、J.、フロイド、S.、とA. Romanow、 "TCPの選択確認応答オプション"、RFC 2018、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]オールマン、M.、パクソン、V.、およびW.スティーブンス、 "TCP輻輳制御"、RFC 2581、1999年4月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988]パクソン、V.とM.オールマン、 "コンピューティング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.
"IPに明示的輻輳通知の添加（ECN）" [RFC3168]ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、RFC 3168、2001年9月。
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, October 2002.
[RFC3390]オールマン、M.、フロイド、S.、およびC.ヤマウズラ、 "増加するTCPの初期ウィンドウ"、RFC 3390、2002年10月。
[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]ブラントン、E.、オールマン、M.、秋、K.、およびL.王は、 "保守的な選択的確認応答（SACK）はTCPのために損失回復アルゴリズムをベース"、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]コーラー、E.、ハンドリー、M.、およびS.フロイド、 "データグラム輻輳制御プロトコル（DCCP）"、RFC 4340、2006年3月。
Informative References
参考文献
[RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion Window Validation", RFC 2861, June 2000.
[RFC2861]ハンドレー、M.、Padhye、J.、およびS.フロイド、 "TCP輻輳ウィンドウ検証"、RFC 2861、2000年6月。
[RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte Counting (ABC)", RFC 3465, February 2003.
[RFC3465]オールマン、M.、RFC 3465、2003年2月 "適切なバイトカウント（ABC）とTCP輻輳制御"。
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003.
[RFC3540]春、N.、Wetherall、D.、およびD.イーリー、 "ロバスト明示的輻輳通知（ECN）ナンスとシグナリング"、RFC 3540、2003年6月。
[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月。
[V03] Arun Venkataramani, August 2003. Citation for acknowledgement purposes only.
[V03]アルンVenkataramani、確認のみを目的とした2003年8月の引用。
Authors' Addresses
著者のアドレス
Sally Floyd ICSI Center for Internet Research 1947 Center Street, Suite 600 Berkeley, CA 94704 USA
インターネットリサーチ1947センターストリートのためのサリーフロイドICSIセンター、スイート600バークレー、CA 94704 USA
EMail: floyd@icir.org
メールアドレス：floyd@icir.org
Eddie Kohler 4531C Boelter Hall UCLA Computer Science Department Los Angeles, CA 90095 USA
エディー・コーラー4531C BoelterホールUCLAコンピュータサイエンス学部ロサンゼルス、CA 90095 USA
EMail: kohler@cs.ucla.edu
メールアドレス：kohler@cs.ucla.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。