RFC4341 日本語訳
4341 Profile for Datagram Congestion Control Protocol (DCCP)Congestion Control ID 2: TCP-like Congestion Control. S. Floyd, E.Kohler. March 2006. (Format: TXT=47868 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Floyd
Request for Comments: 4341 ICIR
Category: Standards Track E. Kohler
UCLA
March 2006
コメントを求めるワーキンググループS.フロイド要求をネットワークでつないでください: 4341年のICIRカテゴリ: 2006年の標準化過程E.コーラーのUCLA行進
Profile for Datagram Congestion Control Protocol (DCCP)
Congestion Control ID 2: TCP-like Congestion Control
データグラム混雑制御プロトコル(DCCP)のために、輻輳制御ID2の輪郭を描いてください: 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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはCongestion Control Identifier2(CCID2)のためのプロフィールを含んでいます、TCPのようなCongestion Control、データグラムCongestion Controlプロトコル(DCCP)で。 CCID2は急速に状態を変えるのに環境で利用可能な帯域幅を利用したくて、TCPのAdditive Increase Multiplicative Decrease(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
1. 序論…2 2. コンベンションと記法…2 3. 用法…3 3.1. TCPとの関係…3 3.2. 半分接続の例…4 4. 接続設立…5 5. データ・パケットにおける混雑コントロール…5 5.1. 空費する応答とアプリケーション限定期間…8 5.2. データの低下して遅い受信機への応答…8 5.3. パケットサイズ…8 6. 承認…9 6.1. 承認の混雑コントロール…9 6.1.1. 検出は、承認を失って、マークしました…10
Floyd & Kohler Standards Track [Page 1] RFC 4341 DCCP CCID2 March 2006
フロイドとコーラー標準化過程[1ページ]RFC4341DCCP CCID2 March 2006
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
6.1.2. Ack比を変えます…10 6.2. 承認の承認…11 6.2.1. 静止を決定します…12 7. 明白な混雑通知…12 8. オプションと特徴…12 9. セキュリティ問題…13 10. IANA問題…13 10.1. コードをリセットしてください…13 10.2. オプションタイプ…13 10.3. 数を特徴としてください…14 11. ありがとうございます…14A.付録: Ack比率減少の派生…15B.付録: Ack比への損失推論誤りの費用…15 標準の参照…17 有益な参照…18
1. Introduction
1. 序論
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.
このドキュメントはCongestion Control Identifier2(CCID2)のためのプロフィールを含んでいます、TCPのようなCongestion Control、データグラムCongestion Controlプロトコル(DCCP)[RFC4340]で。 DCCPは、半分接続のときに使用中の混雑制御機構を指定するのにCongestion Control Identifiers、または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のようなCongestion Control CCIDはTCPの混雑制御機構の近い異形を使用することでデータを送ります、選択している承認(SACK)[RFC2018、RFC3517]の異形を取り入れて。 CCID2はTCPのAdditive Increase Multiplicative Decrease(AIMD)輻輳制御の典型の混雑ウィンドウの突然の変化に順応できる送付者に適当であって、特に急速に状態を変えるのに環境における利用可能な帯域幅を利用したがっている送付者の役に立ちます。 詳しい情報については、アプリケーション要件でセクション3を見てください。
2. Conventions and Notation
2. コンベンションと記法
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[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-送付者」と「HC-受信機」はそれぞれアプリケーションデータと承認を送る終点を指示します。 CCIDsが半分接続のレベルで適用するので、私たちは本書では「送付者」へのHC-送付者と「受信機」へのHC-受信機を簡略化します。 より多くの議論に関して[RFC4340]を見てください。
Floyd & Kohler Standards Track [Page 2] RFC 4341 DCCP CCID2 March 2006
フロイドとコーラー標準化過程[2ページ]RFC4341DCCP CCID2 March 2006
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.
「電子証券取引ネットワークが著しい」という句と「著しさ」は別の方法で注意されない場合電子証券取引ネットワークCongestion Experiencedであるとマークされたパケットを示します。
3. Usage
3. 用法
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.
CCID2(TCPのようなCongestion Control)はDCCPのために長期的に見るとできるだけ多くの帯域幅を受けたがっている流れを当てることです、終わりからエンドへの輻輳制御の使用と一致しています。 また、CCID2流れは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.
単にできるだけ短い間でできるだけ多くのデータを移す必要があるアプリケーションはCCID2を使用するべきです。 これはCCID3、TCP好意的なRate Control(TFRC)[RFC4342]とひどく違います。(送付レートにおける突然の変化を最小にするのを好む流れに、Rate Controlは適切です)。 例えば、CCID2は再生時の前にアプリケーション受信機でかなりのデータ量をバッファリングするストリーミング・メディアアプリケーションのためのCCID3の上でお勧めです、送付レートにおける突然の変化からアプリケーションをいくらか隔離して。 そのようなアプリケーションはTCP自身の上で容易にDCCPのCCID2を選ぶかもしれません、ことによると応用層で何らかのフォームの選択している信頼性を加えて。 また、CCID2も混雑に対応して送付レートを半分にするのがアプリケーションレベル性能を妨げそうにないアプリケーションのためのCCID3の上でお勧めです。
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.
CCID2の追加利点はTCPのような混雑制御機構が合理的によく理解されているということです、TCPのものと全く同様の交通力学で。 それが優位な輸送である15年がインターネットで議定書を作った後にネットワーク研究団体がTCPの力学に関してまだ学んでいる間、いくつかのアプリケーションが、より新しい混雑制御機構のもののTCPのような輻輳制御の、よりよく知られている力学を好むかもしれません。まだ、制御機構は広範囲のインターネット展開のテストに対応していません。
3.1. Relationship with TCP
3.1. 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によって標準化されたメカニズムに従います、そして、私たちは既存のTCPドキュメンテーションを部分的に当てにします、[RFC793]や、[RFC2581]や、[RFC3465]や、[RFC3517]などのように。 TCP輻輳制御は、発展し続けていますが、CCID2実現SHOULDは直接道のTCPの発展よりむしろCCID2に明白なアップデートを待っています。
Floyd & Kohler Standards Track [Page 3] RFC 4341 DCCP CCID2 March 2006
フロイドとコーラー標準化過程[3ページ]RFC4341DCCP CCID2 March 2006
Differences between CCID 2 and straight TCP congestion control include the following:
CCID2とまっすぐなTCP輻輳制御の違いは以下を含んでいます:
o CCID 2 applies congestion control to acknowledgements, a mechanism
not currently standardized for use in TCP.
o CCID2は承認、現在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.
o DCCPがデータグラムプロトコルであるので、ユニットがTCPでバイトで指定される混雑ウィンドウcwndなどのいくつかのパラメタが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文脈のために再設計されました。
3.2. Half-Connection Example
3.2. 半分接続の例
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.
この例はCCID2のTCPのようなCongestion Controlを使用することで半分接続の典型的な進歩を示しています、接続開始と終了を含んでいなくて。 例は規範的であるのではなく、有益です。
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-データ・パケットを送って、パケットの数がどこに発信したかはTCPのように混雑ウィンドウ、cwndによって治められます。 各DCCP-データ・パケットは一連番号を使用します。 また、送付者はAck Ratio特徴オプションにAckパケットで受信機から覆われているためにデータ・パケットの数を指定させます。 Ack Ratioは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].
半分接続ができるのである(電子証券取引ネットワークIncapableの特徴はゼロです、デフォルト)Explicit Congestion Notification(電子証券取引ネットワーク)であると仮定して、ECT(0)かECT(1) codepointのどちらかと電子証券取引ネットワークCapableがセットしたので、各DCCP-データ・パケットを送ります、[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 RatioのためにDCCP-Ackパケット承認にデータ・パケットを送ります。 それぞれのDCCP-Ackパケットは、一連番号を使用して、Ack Vectorを含んでいます。 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.
受信機はAck Vectorオプションで容認された電子証券取引ネットワークNoncesの合計を返します、送付者が、受信機がふらちな事をしていないことをprobabilisticallyに確かめるのを許容して。 また、電子証券取引ネットワークCapableとして受信機からのDCCP-Ackパケットを送ります、送付者がAck Ratioの特徴を使用することでおよそTCPに優しい方法で承認率を制御するので。 受信機がDCCP-Ackパケットの一回だけについて確かめる必要がほとんどありません、送付者がackマルク相場を誤報するのから重要な利益を得ることができないので。
Floyd & Kohler Standards Track [Page 4] RFC 4341 DCCP CCID2 March 2006
フロイドとコーラー標準化過程[4ページ]RFC4341DCCP CCID2 March 2006
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 Vectorsを調べて、それに従って、混雑ウィンドウを調整します。 これが頼り無い転送であるので、送付者は低下しているパケットを再送しません。
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 Ratioを変更することによって、無くなっているか著しい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としての往復の回がする承認の動向をおさえることを通して、または、明白なTimestampオプションを通して往復の回を見積もって、RTO(Timeoutを再送する)がTCPで計算されるようにTimeOut(TO)値について計算します。 TOは、混雑ウィンドウで送付者を制限して、いつ受信機からフィードバックを全く受け取っていないかとき、新しいDCCP-データ・パケットを伝えることができるかを決定します。
4. Connection Establishment
4. コネクション確立
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 Vectorの使用がCCID2半分接続でのMANDATORYであるので、送付者はコネクション確立の一部として「変化R(Ackベクトル、1を送ります)」オプションを受信機に送らなければなりません。 対応を受けるまで、送付者SHOULD NOT送信データは受信機から「L(Ackベクトル、1を送る)を確認します」、DCCPリクエスト・パケットにデータを送るかもしれないのを除いて。
5. Congestion Control on Data Packets
5. データ・パケットにおける輻輳制御
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.
CCID2の混雑制御機構はSACKのベースのTCP[RFC3517]のためのそれらに基づいています、Ack VectorがSACKオプションで伝えられるかもしれないすべての情報を提供するので。
A CCID 2 data sender maintains three integer parameters measured in packets.
CCID2データ送付者はパケットで測定された3つの整数パラメタを維持します。
Floyd & Kohler Standards Track [Page 5] RFC 4341 DCCP CCID2 March 2006
フロイドとコーラー標準化過程[5ページ]RFC4341DCCP CCID2 March 2006
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-応答)
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.
これらのパラメタは操られました、そして、それを除いた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. データ・パケットをAckedしました。 送付者はいくらかのDCCP-Ackでパイプを受け取るように新たに承認された各データ・パケット(Ack Vector州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パケットが受信機で受け取るように(Ack Vector州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
3. タイムアウトを伝えてください。 最終的に、パケットの全体の窓が無くなるといけないので、送付者の必要性はTCPの再送タイムアウトのように扱われたタイムアウトを伝えます。 送付者は、データの窓単位で往復の時間を大部分と一度見積もって、平均した往復の時間、平均偏差、およびタイムアウト値[RFC2988]を維持するのにTCPアルゴリズムを使用します。 (往復の時間あたり1つ以上の測定がこれらの計算に使用されるなら、アバレイジャーの重りは、事実上、平均した往復の時間が測定値から得られるのを保証するように調整されなければならないでしょうに。
Floyd & Kohler Standards Track [Page 6] RFC 4341 DCCP CCID2 March 2006
フロイドとコーラー標準化過程[6ページ]RFC4341DCCP CCID2 March 2006
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.
複数の往復の回の上で。) DCCPがデータを再送しないので、DCCPはTCPの最低1秒のお勧めのタイムアウトを必要としません。 タイマの指数のbackoffはまさにTCPのようにそうです。 aが伝わるとき、タイムアウトは起こって、送付者セットはゼロに運ばれます。 調整は以下に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データ・パケットあたりの一度よりパイプを減少させてはいけません。 例えば、本当の写し承認はパイプに影響してはいけません。 以前に失われているように推論されたパケットの承認を受けるとき、送付者も再びパイプを減少させてはいけません。 その上、送付者は非データ・パケットのためにパイプを減少させてはいけません、DCCP-Acksなどのように、Ack Vectorが彼らの情報を含むでしょうが。
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.
混雑出来事で、CCID2は混雑ウィンドウを減少させます。 混雑出来事は少なくとも1つの無くなっているか著しいパケットを含んでいます。 最初のパケットの損失かマークを検出する前に2番目のパケットを送ったとき、TCPで単一の混雑出来事の一部であると2つの損失かマークを考えるとき。 近似として、パケットを送ったとき、送付者は、RTT見積りを使用して、お互いの1つのRTT見積りの中でパケットを送ったときの単一の混雑出来事の一部である2つの損失かマークがよく見られると考えることができます。 どちらかが、それぞれの混雑出来事においてcwndが半分にされて、次に、ssthreshが新しいcwndに用意ができているとAck Vector州1の(電子証券取引ネットワークが著しい)の承認として明らかに示したか、または「写し承認」を通して推論しました。 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 Vector州0が(電子証券取引ネットワークが著しくない)で混雑ウィンドウは2つの新たに承認されたデータ・パケットあたり1つのパケットによって増加させられます、最大1承認あたりのAck Ratio/2パケットまで。 これで、TCPの現在の規格(バイト勘定を含んでいない)と一致したAppropriate Byte Counting[RFC3465]の変更されたフォームですが、CCID2のAck Ratioが2のデフォルト値よりすばらしいときに、CCID2はTCPと同じくらい積極的に増加します。 cwnd>がssthreshと等しいときに、混雑ウィンドウは無くなっているか著しいパケットなしで承認されたデータの各窓あたり1つのパケットによって増加させられます。 [RFC3390]から約束を守って、cwndパラメタは新しい接続のために高々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パケットによってむしろ解放された複数のデータ・パケットを送るとき、Sendersはレートベースのペースのフォームを使用するかもしれません。
Floyd & Kohler Standards Track [Page 7] RFC 4341 DCCP CCID2 March 2006
フロイドとコーラー標準化過程[7ページ]RFC4341DCCP CCID2 March 2006
5.1. Response to Idle and Application-Limited Periods
5.1. 空費する応答とアプリケーション限定期間
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.
CCID2は可能な範囲内で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送付者SHOULD遅れた出発超過にタイムアウト間隔を推薦します。(そこでは、活動していない期間が期間と定義されます)。 [RFC2861](現在のExperimental)は混雑ウィンドウが送付者が活動していないままでいた往復の毎回の間に半分にされるわずかに適度のメカニズムを示します。
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の混雑ウィンドウが混雑ウィンドウが完全に利用される予定であるというわけではないアプリケーション限定期間の間増加しないのを本質的には示します。
5.2. Response to Data Dropped and Slow Receiver
5.2. データの低下して遅い受信機への応答
DCCP's Data Dropped option lets a receiver declare that a packet was dropped at the end host before delivery to the application -- for instance, because of corruption or receive buffer overflow. 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 Dropped--例えば、不正か受信バッファオーバーフローのために。 受信機は、DCCPのSlow Receiverオプションで送付者のパケットについて行くのに苦労していると宣言します、何もまだ落とされていませんが。 CCID2送付者は[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 Code2(「受信バッファ低下」)を落としてください。 混雑ウィンドウ"cwnd"はDrop Code2として新たに承認された各パケットあたり1つ減少します、それが決して1より下であるまで減少しないのを除いて。
o Exiting slow start. The sender MUST exit slow start whenever it
receives a relevant Data Dropped or Slow Receiver option.
o 遅れた出発を出ます。 関連Data DroppedかSlow Receiverオプションを受け取るときはいつも、送付者は遅れた出発を出なければなりません。
5.3. Packet Size
5.3. パケットサイズ
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.
CCID2は一般に、固定パケットサイズを使用して、1秒あたりのパケットで混雑に対応してそれらの送付レートを変えるアプリケーションのために最適化されます。 パケットの間の時間の固定間隔を必要として、混雑に対応したそれらのパケットレートの代わりにそれらのパケットサイズを変えるアプリケーションには、CCID2は適切ではありません。
Floyd & Kohler Standards Track [Page 8] RFC 4341 DCCP CCID2 March 2006
フロイドとコーラー標準化過程[8ページ]RFC4341DCCP CCID2 March 2006
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.
CCID2はパケットで混雑ウィンドウを維持して、減少に対応してパケットサイズで混雑ウィンドウを増加させません。 しかしながら、何らかの注意が、アプリケーションに混雑に対応して他のアプリケーションレベル要件に対応してそれらのパケットサイズを変えるCCID2を使用することで必要であるかもしれません。
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].)
CCID2実現は不適当にパケットサイズを操っているように見えるアプリケーションがないかどうかチェックするかもしれません。 例えば、アプリケーションは、速いレートを確立して、しばらく小型小包を送って、次に、速いレートを利用するために大きいパケットに切り替わるかもしれません。 (予備のシミュレーションが、アプリケーションがこのようにそれらの総合的な転送レートを増加させることができないかもしれないのを示すので、この操作が習慣[V03]で起こるのは、明確ではありません。)
6. Acknowledgements
6. 承認
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.
一般に、CCID2承認は送付者のデータ・パケットによって歩調を合わせられます。 それぞれの必要な承認はまさに宣言するAck Vectorオプションを含まなければなりません。どのパケットが到着したか、そして、それらのパケットは電子証券取引ネットワークが著しいのであったかどうか 一般に、Ack VectorオプションSHOULDの承認データは受信機の全体のAcknowledgement Windowを覆っています。 [RFC4340]、セクション11.4.2を見てください。 どんなData DroppedオプションSHOULDも同様に受信機の全体のAcknowledgement Windowを覆っています。
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.
CCID2送付者は受信機がDCCP-Ackパケットを発生させる速度に影響を及ぼすDCCPのAck Ratioの特徴を使用します、その結果、逆経路混雑を制御します。 これはTCPと異なっています。(TCPは現在、純粋な承認交通のための輻輳制御を全く持っていません)。 CCID2の逆経路輻輳制御はTCP好意的になろうとしません。 それはただ混雑崩壊を避けて、逆の経路の高いパケット損失かマルク相場があるときTCPよりいくらか良いことになろうとします。 デフォルトAck Ratioは2歳です、そして、このAck RatioとCCID2はTCPのように遅れたacksで振る舞います。 承認ペースとDCCP-DataAckパケットとの関係を含んでいて、[RFC4340](セクション11.3)はさらに詳細にAck Ratioについて説明します。 このドキュメントのセクション6.1.1はCCID2送付者がどう無くなっているか著しい承認を検出するかを説明します、そして、セクション6.1.2はそれがどうAck Ratioを変えるかを説明します。
6.1. Congestion Control on Acknowledgements
6.1. 承認の輻輳制御
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
Ack RatioがRであるときに、受信機は多少Rデータ・パケットあたり1つのDCCP-Ackパケットを送ります。 送付者が往復の時間あたりのcwndデータ・パケットを送るので、承認率は往復の時間あたりのcwnd/R DCCP-Acksと等しいです。 送付者は、承認率がおよそそれに従って、失われていて、DCCP-Ackパケットであるとマークされて、Rを変更するための承認の流れをモニターすることによって好意的なTCPであることを保ちます。 またはDCCP-Ack混雑出来事を含むあらゆるRTT、(すなわち、aが失った。
Floyd & Kohler Standards Track [Page 9] RFC 4341 DCCP CCID2 March 2006
フロイドとコーラー標準化過程[9ページ]RFC4341DCCP CCID2 March 2006
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.
著しいDCCP-Ack)、送付者はAck Ratioを倍にすることによって、承認率を半分にします。 DCCP-Ack混雑出来事を全く含むというわけではないあらゆるRTTに関しては、それはAck Ratioでの漸減で承認率を添加物に増加させます。
6.1.1. Detecting Lost and Marked Acknowledgements
6.1.1. 無くなっていて著しい承認を検出します。
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 Ratioは受信機のパケットのすべてでの集合損失とマークではなく、受信機の非データ・パケットでの損失とマークに依存します。 非データ・パケットカテゴリはアプリケーションデータを運ぶことができないそれらのパケットタイプから成ります: DCCP-Ack、DCCP-閉鎖、DCCP-CloseReq、DCCP-リセット、DCCP-同時性、およびDCCP-SyncAck。 送付者は他のマークと非データ・マークを容易に区別できます。 もっとも、送付者が、無くなっているパケットがデータを運んだかどうかをいつも知ることができるというわけではないので、これは損失で、より困難です。 それにより良い情報がない場合、送付者SHOULDは、Ack Ratio計算の目的のためにあらゆる無くなっているパケットが非データ・パケットであったと仮定します。 必要なら、より良い情報はDCCPのNDP Countオプションで利用可能です。 (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 Ratio SHOULDの如何にかかわらずそれ自身の承認輻輳制御を実行する受信機はデータ・パケットでの損失かマークのためDCCP-Ack承認率を低下させません。
6.1.2. Changing Ack Ratio
6.1.2. 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 Ratioはいつも3つの規制を満たします: (1) Ack Ratioは整数です。 (2) Ack Ratio2がいつも許容できる以外に、Ack Ratioは切り上げられたcwnd/2を超えていません。 (3) Ack Ratioは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 Ratioを変えます。 無くなっているか著しいDCCP-Ackパケットがあるデータのそれぞれの混雑ウィンドウに関しては、Ack Ratioは倍にされます。 そして、連続した混雑が窓を付ける無くなっているか著しいDCCP- Ackパケットのないデータの各cwnd/(R^2--R)に関して、Ack Ratioは1つ減少します。 (派生に関してAppendix Aを見てください。) 特徴交渉でAck Ratioにおける変化は合図されます。 [RFC4340]、セクション11.3を見てください。
Floyd & Kohler Standards Track [Page 10] RFC 4341 DCCP CCID2 March 2006
フロイドとコーラー標準化過程[10ページ]RFC4341DCCP CCID2 March 2006
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 Ratioを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 Ratioが完全に時代について行かせなければならないというわけではありません。 例えば、それは4回か往復の5回あたりの一度、または、毎秒あたりの一度へのAck Ratio renegotiationsか2をレートで制限するかもしれません。 送付者SHOULD NOTは、一度より多くの往復の時間あたりのAck Ratioを再交渉するのを試みます。 さらに、それが2の最小のAck Ratioを実施するかもしれませんか、またはそれは1か2つのパケットのしつこい混雑ウィンドウとの半分接続のための1つにAck Ratioを設定するかもしれません。
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、および少なくとも2とデータの窓あたりの承認に等しいと、受信機はいつもデータの窓あたり少なくとも1つの承認を送ります。 したがって、受信機は逆の経路における非常に重い混雑に直面してさえデータの窓あたり2つのackパケットを送るかもしれません。 しかしながら、私たちは、混雑が十分重いなら、すべてのackパケットが落とされて、次に、送付者が指数関数的に引き返しているタイムアウトに後ろへ下がることに注意するでしょう、TCPのように。 したがって、混雑が逆の経路で十分重いなら、送付者はフォワードパスの送付レートを低下させます。(フォワードパスはまた、逆の経路のレートを低下させます)。
6.2. Acknowledgements of Acknowledgements
6.2. 承認の承認
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 Vector状態を開けることができるように、時折同輩DCCPビーズの承認を承諾しなければなりません。 両方の半分接続が活発であるときに、Aのビーズの承認の承認はAのビーズデータの承認に自動的に含まれています。 しかしながら、BからAとの半分接続が静かであるなら、DCCP Aは時折承認予測するのを送らなければなりません、ヘッダーにAcknowledgement Numberを含んでいる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.
アクティブな送付者SHOULDは混雑ウィンドウ単位で受信機の承認を少なくとも一度承諾します。 もちろん、送付者のアプリケーションは黙り込むかもしれません。 これは問題ではありません。 ackを送るずっと前にどちらの側もデータを送らないとき、送付者は任意に待つことができます。
Floyd & Kohler Standards Track [Page 11] RFC 4341 DCCP CCID2 March 2006
フロイドとコーラー標準化過程[11ページ]RFC4341DCCP CCID2 March 2006
6.2.1. Determining Quiescence
6.2.1. 静止を決定します。
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.
このセクションは、CCID2受信機がどのように対応する送付者がデータを少しの送らないことを決定して、したがって、静かになったかを説明します。 一般情報のために[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 Vectorsを承認して、送付者が少なくともT秒の間、追加データを送らないと、受信機は、送付者が静かであると推論できます。 より正確に、受信機は、少なくともT秒が送付者からどんなデータも受け取らないで経過して、送付者が受信機に受け取られたすべてのデータ・パケットを覆う受信機Ack Vectorsを承認したとき、送付者が静かになったと推論します。
7. Explicit Congestion Notification
7. 明白な混雑通知
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.
CCID2はExplicit Congestion Notification(電子証券取引ネットワーク)[RFC3168]を支持します。 送付者はデータ・パケットに電子証券取引ネットワークNonceを使用するでしょう、そして、受信機はAck Vectorsでそれらの一回だけを反響するでしょう、[RFC4340]で指定されるように、セクション12.2。 また、Ack Vectorで著しいパケットに関する情報を返します。 Ack Vectorの情報を確かに移すので、DCCPは電子証券取引ネットワーク-エコーとCongestion Window Reducedの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]のように電子証券取引ネットワークNonce Echoを計算して、Ack Vectorオプションの一部としてそれを返します。 送付者SHOULDは期待値に対してこれらの電子証券取引ネットワーク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.
CCID2承認が制御された混雑であるので、また、電子証券取引ネットワークは承認に使用されるかもしれません。 この場合、私たちは電子証券取引ネットワークNonceを利用しません、送付者による著しいackパケットの隠すことに対する保護を提供するのが簡単でないだろう、また送付者が承認のマルク相場に関して嘘をつくことに関する多くの動機を持っていないので。
8. Options and Features
8. オプションと特徴
DCCP's Ack Vector option, and its ECN Capable, Ack Ratio, and Send Ack Vector features, are relevant for CCID 2.
CCID2において、DCCPのAck Vectorオプション、電子証券取引ネットワークCapable、Ack Ratio、およびSend Ack Vectorの特徴は関連しています。
Floyd & Kohler Standards Track [Page 12] RFC 4341 DCCP CCID2 March 2006
フロイドとコーラー標準化過程[12ページ]RFC4341DCCP CCID2 March 2006
9. Security Considerations
9. セキュリティ問題
Security considerations for DCCP have been discussed in [RFC4340], and security considerations for TCP have been discussed in [RFC2581].
[RFC4340]でDCCPのためのセキュリティ問題について議論しました、そして、[RFC2581]でTCPのためのセキュリティ問題について議論しました。
[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のような輻輳制御を使用で作成されたどんな新しいセキュリティ問題も意識していません。
10. IANA Considerations
10. IANA問題
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]で言及されます。 また、CCID2は値がIANAによって割り当てられるはずである3セットの数を導入します。 すなわち、CCIDの2特有のReset Codes、オプションタイプ、および特徴番号。 これらの範囲は、どんな未来にもCCIDの2特有の配分がDCCPの対応するグローバルな名前空間を汚染するのを防ぐでしょう。 [RFC4340]、セクション10.3を見てください。 しかしながら、このドキュメントは実験的、そして、テスト使用以外のどんな範囲からのどんな特定の配分も[RFC3692]にしません。 私たちは[RFC2434]に概説されたStandards Action方針を示します。
10.1. Reset Codes
10.1. リセットコード
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 CCID2Reset Code登録の各エントリーはCCIDの2特有のReset Codeを含んでいます。(Reset Codeは範囲128-255の数です)。 Reset Codeの短い記述。 そして、Reset Codeを定義するRFCの参照。 リセットCodes184-190と248-254は永久に、実験的、そして、テスト使用のために予約されます。 残っているReset Codes(128-183、191-247、および255)を現在予約して、Standards Action方針で割り当てるべきです。(それは、IESGレビュー、承認、および標準化過程IETF RFC公表を必要とします)。
10.2. Option Types
10.2. オプションタイプ
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 CCID2オプションタイプ登録の各エントリーはCCIDの2特有のオプションタイプを含んでいます。(タイプは範囲128-255の数です)。 オプションの名前。 そして、オプションタイプを定義するRFCの参照。 オプションタイプは永久に、実験的、そして、テスト使用のために184-190に248-254に予約されます。 残っているオプションタイプ(128-183、191-247、および255)を現在予約して、Standards Action方針で割り当てるべきです。(それは、IESGレビュー、承認、および標準化過程IETF RFC公表を必要とします)。
Floyd & Kohler Standards Track [Page 13] RFC 4341 DCCP CCID2 March 2006
フロイドとコーラー標準化過程[13ページ]RFC4341DCCP CCID2 March 2006
10.3. Feature Numbers
10.3. 特徴番号
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 CCID2特徴数の登録の各エントリーはCCIDの2特有の特徴番号を含んでいます。(それは、範囲128-255の数です)。 特徴の名前。 そして、特徴番号を定義するRFCの参照。 特徴番号は永久に、実験的、そして、テスト使用のために184-190に248-254に予約されます。 残っている特徴番号(128-183、191-247、および255)を現在予約して、Standards Action方針で割り当てるべきです。(それは、IESGレビュー、承認、および標準化過程IETF RFC公表を必要とします)。
11. Thanks
11. 感謝
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.
私たちは彼らの助けについてCCID2を定義する際にマーク・ハンドレーとJitendra Padhyeに感謝します。 また、私たちはこのドキュメントのフィードバックについてDCCP作業部会のマーク・オールマン、アーロン・フォーク、ニルス-エリック・マッツソン、グレッグMinshall、アルンVenkataramani、マグヌスWesterlund、およびメンバーに感謝します。
Floyd & Kohler Standards Track [Page 14] RFC 4341 DCCP CCID2 March 2006
フロイドとコーラー標準化過程[14ページ]RFC4341DCCP CCID2 March 2006
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 Ratioを増加して、減少させるためのアルゴリズムを正当化します。
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を半分にします。 同様に、混雑がリターンパスにある状態で、CCID2はAck Ratioをあらゆる窓に倍にします、乱暴に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の輻輳回避フェーズは各無混雑の窓あたり1MSSでcwndを増加させます。 この混雑回避行動が承認交通に適用されるとき、これは1窓あたりのDCCP-Ackパケットの数をDCCP-Ackパケットのあらゆる無混雑の窓の後の1つ増加させると対応しているでしょう。 私たちは、それが整数であるのでまさにAck Ratioを使用することでこれを達成できません。 代わりに、逆の経路における混雑出来事なしでKの窓を送った後に私たちはAck Ratioを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.
CCID2では、cwnd/(R^2--R)にKを設定することによって、ack交通に関する乱暴なTCP-友情を達成できます。(そこでは、Rが現在のAck Ratioです)。
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.
R=Ack Ratioが#データ・パケット/ackパケットと等しく、Wが混雑Window=#データ・パケット/ウィンドウと等しいので、W/Rは#ackのパケット/窓と等しいです。
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の増分減少させることができるだけであるので、私たちはW/R+KがK無混雑の窓の後にW/(R-1)と等しいように、Kを見つけます。
(W/R) + K = W/(R-1), so
K = W/(R-1) - W/R = W/(R^2 - R).
+ そのように、(R-1)があるK=、(R-1)、R=がある(Rがある)K=、(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
セクション6.1.1で議論するように、送付者は、無くなっているパケットがデータを運んだかどうかとしばしば決心できるというわけではありません。 これは他の損失出来事と非データ損失イベントを切り離す性能を妨げます。 より良い情報がないとき、送付者は、Ack Ratio計算の目的のためにすべての無くなっているパケットが非データ・パケットであったと仮定します。 これは非データ損失イベント速度を過大評価するかもしれません。(それは、また、高いAck Ratioと、そして、その結果、また、遅い承認率に導くことができます)。 それでも情報が通り抜けるすべての承認--DCCP
Floyd & Kohler Standards Track [Page 15] RFC 4341 DCCP CCID2 March 2006
フロイドとコーラー標準化過程[15ページ]RFC4341DCCP CCID2 March 2006
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.
承認は信頼できますが、承認情報はburstierファッションに到着するでしょう。 何らかのフォームのレートベースのペースがなければ、これは送付者のデータ通信量への増加するburstinessに通じるかもしれません。
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 Ratioの問題、およびデータ通信量の結果として起こる増加するburstinessが起こらないとき、数個のケースがあります。 特に、受信機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から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 Ratioによって制限されないので、それらはburstinessを防ぐことができるくらいの頻繁に到着できます。
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の送付レートが低いなら、問題は、burstinessが低率が問題でないので、起こらないでしょう。
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ビーズ送付レートがDCCP Aの送付レートに比例して高いなら、問題は起こらないでしょう、BからAへの損失率がレートを送りながらDCCPビーズを支持するために低くなければならないので。 DCCP AがDCCP- Ackの損失としてあらゆる損失をラベルさえするとき妥当へのAck Ratioが評価するこの領域。
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 Countオプションを送ると(Send NDP Count/Bの特徴は真です)、問題は起こらないでしょう。 そして、多くの場合、送付者は無くなっているパケットがデータ・パケットかDCCP-Acksであったことにかかわらず検出する受信機のNDP Countオプションを使用できます。
o Finally, the problem won't arise if DCCP A rate-paces its data
packets.
o 最終的に、DCCP Aがデータ・パケットにレートで歩調を合わせると、問題は起こらないでしょう。
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.
NDP Countオプションなしですべての承認情報がDCCP-Ackパケットにある状態でDCCP Bがおよそ同じデータ量パケットと非データ・パケットを送るとき、これはケースを出ます。 私たちは現在潜在的費用を定量化します、また、大きいAck Ratioに関して、送付者がDCCP-Ackの損失としてデータパケット損失をmisclassifyingするため。 簡単さのために、私たちはパケット低下率がどんな個々の接続の送付速度からも独立している大規模な統計的多重化の環境を仮定します。
Floyd & Kohler Standards Track [Page 16] RFC 4341 DCCP CCID2 March 2006
フロイドとコーラー標準化過程[16ページ]RFC4341DCCP CCID2 March 2006
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が正しく非データの損失を数えると、Ack Ratioが用意ができているのでBからAへのデータと交通の承認両方には1秒あたりのDパケットの送付レートがあると仮定してください。 次に、DCCP Aが不当に非データの損失にデータの損失をみなすとき、それでも、Bからデータ通信量対Aの送付速度はD ppsですが、Bから承認交通対Aの減少している送付速度はf*D ppsです、f<1で。 パケット損失率がpであることをさせてください。 送付者は(pD+pfD)/fDとして、または、同等にp(1+1/f)として不当に非データ損失速度を見積もっています。 承認交通への輻輳制御メカニズムがTCPおよそ好意的であり、したがって、非データ送付速度とデータ送付速度がxのために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を得ます。 送付者が不当にこのシナリオの非データにロストデータパケットをみなすなら、承認率は0.62の要素によって減少させられます。 これはAからBへのNDP Countオプションか便乗している承認を送るか、または外でデータにレートで歩調を合わせることによって緩和できるだろうデータ通信量へのburstinessの適度の増加をもたらすでしょう。
Normative References
引用規格
[RFC793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、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の選択している承認オプション」、RFC2018、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP
Congestion Control", RFC 2581, April 1999.
[RFC2581] オールマンとM.とパクソン、V.とW.スティーブンス、「TCP輻輳制御」、RFC2581、1999年4月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's
Retransmission Timer", RFC 2988, November 2000.
[RFC2988] パクソンとV.とM.オールマン、「コンピューティングTCPの再送信タイマー」、RFC2988、2000年11月。
Floyd & Kohler Standards Track [Page 17] RFC 4341 DCCP CCID2 March 2006
フロイドとコーラー標準化過程[17ページ]RFC4341DCCP CCID2 March 2006
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The
Addition of Explicit Congestion Notification (ECN) to
IP", RFC 3168, September 2001.
[RFC3168] Ramakrishnan、K.、フロイド、S.、およびD.黒、「明白な混雑通知(電子証券取引ネットワーク)のIPへの追加」、RFC3168(2001年9月)。
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing
TCP's Initial Window", RFC 3390, October 2002.
[RFC3390] オールマンとM.とフロイド、S.とC.ヤマウズラ、「増加するTCPの初期の窓」、RFC3390、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.ワング、「TCPに、保守的な選択している承認(袋)ベースの損失回復アルゴリズム」、RFC3517(2003年4月)。
[RFC3692] Narten, T., "Assigning Experimental and Testing
Numbers Considered Useful", BCP 82, RFC 3692, January
2004.
[RFC3692] Narten、T.、「役に立つと考えられた実験的でテストしている数を割り当てます」、BCP82、RFC3692、2004年1月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March
2006.
[RFC4340] コーラー、E.、ハンドレー、M.、およびS.フロイド、「データグラム混雑制御プロトコル(DCCP)」、RFC4340、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混雑窓の合法化」、RFC2861、2000年6月。
[RFC3465] Allman, M., "TCP Congestion Control with Appropriate
Byte Counting (ABC)", RFC 3465, February 2003.
[RFC3465]オールマン、M.、「適切なバイト勘定(ABC)とのTCP輻輳制御」、RFC3465、2003年2月。
[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.イーリー、「一回だけで合図する体力を要している明白な混雑通知(電子証券取引ネットワーク)」、RFC3540、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)輻輳制御ID3のために以下の輪郭を描きます」。 「TCPに優しい速度制御(TFRC)」、2006年3月のRFC4342。
[V03] Arun Venkataramani, August 2003. Citation for
acknowledgement purposes only.
2003年8月の[V03]アルンVenkataramani。 承認目的だけのための引用。
Floyd & Kohler Standards Track [Page 18] RFC 4341 DCCP CCID2 March 2006
フロイドとコーラー標準化過程[18ページ]RFC4341DCCP CCID2 March 2006
Authors' Addresses
作者のアドレス
Sally Floyd ICSI Center for Internet Research 1947 Center Street, Suite 600 Berkeley, CA 94704 USA
サリーフロイドICSIは米国をInternet Research1947Center通り、Suite600バークレー、カリフォルニア 94704の中心に置きます。
EMail: floyd@icir.org
メール: floyd@icir.org
Eddie Kohler 4531C Boelter Hall UCLA Computer Science Department Los Angeles, CA 90095 USA
エディ・コーラー4531・C BoelterホールUCLAコンピュータサイエンス部のカリフォルニア90095ロサンゼルス(米国)
EMail: kohler@cs.ucla.edu
メール: kohler@cs.ucla.edu
Floyd & Kohler Standards Track [Page 19] RFC 4341 DCCP CCID2 March 2006
フロイドとコーラー標準化過程[19ページ]RFC4341DCCP CCID2 March 2006
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Floyd & Kohler Standards Track [Page 20]
フロイドとコーラー標準化過程[20ページ]
一覧
スポンサーリンク
