RFC4342 日本語訳
4342 Profile for Datagram Congestion Control Protocol (DCCP)Congestion Control ID 3: TCP-Friendly Rate Control (TFRC). S. Floyd,E. Kohler, J. Padhye. March 2006. (Format: TXT=83054 bytes) (Updated by RFC5348) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Floyd
Request for Comments: 4342 ICIR
Category: Standards Track E. Kohler
UCLA
J. Padhye
Microsoft Research
March 2006
コメントを求めるワーキンググループS.フロイド要求をネットワークでつないでください: 4342年のICIRカテゴリ: 2006年の標準化過程E.コーラーのUCLA J.Padhyeマイクロソフト研究行進
Profile for Datagram Congestion Control Protocol (DCCP)
Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)
データグラム混雑制御プロトコル(DCCP)のために、輻輳制御ID3の輪郭を描いてください: TCPに優しい速度制御(TFRC)
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 3, TCP-Friendly Rate Control (TFRC), in the Datagram Congestion Control Protocol (DCCP). CCID 3 should be used by senders that want a TCP-friendly sending rate, possibly with Explicit Congestion Notification (ECN), while minimizing abrupt rate changes.
このドキュメントはCongestion Control Identifier3のためのプロフィールを含んでいます、TCP好意的なRate Control(TFRC)、データグラムCongestion Controlプロトコル(DCCP)で。 CCID3はTCPに優しい送付レートが欲しい送付者によって使用されるべきです、突然のレート変化を最小にしていてことによるとExplicit Congestion Notification(電子証券取引ネットワーク)と共に。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions .....................................................3
3. Usage ...........................................................3
3.1. Relationship with TFRC .....................................4
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 ...........7
5.2. Response to Data Dropped and Slow Receiver .................8
5.3. Packet Sizes ...............................................9
6. Acknowledgements ................................................9
6.1. Loss Interval Definition ..................................10
6.1.1. Loss Interval Lengths ..............................12
6.2. Congestion Control on Acknowledgements ....................13
1. 序論…2 2. コンベンション…3 3. 用法…3 3.1. TFRCとの関係…4 3.2. 半分接続の例…4 4. 接続設立…5 5. データ・パケットにおける混雑コントロール…5 5.1. 空費する応答とアプリケーション限定期間…7 5.2. データの低下して遅い受信機への応答…8 5.3. パケットサイズ…9 6. 承認…9 6.1. 損失間隔定義…10 6.1.1. 損失間隔の長さ…12 6.2. 承認の混雑コントロール…13
Floyd, et al. Standards Track [Page 1] RFC 4342 DCCP CCID3 TFRC March 2006
フロイド、他 規格は2006年のDCCP CCID3 TFRC行進のときにRFC4342を追跡します[1ページ]。
6.3. Acknowledgements of Acknowledgements ......................13
6.4. Determining Quiescence ....................................14
7. Explicit Congestion Notification ...............................14
8. Options and Features ...........................................14
8.1. Window Counter Value ......................................15
8.2. Elapsed Time Options ......................................17
8.3. Receive Rate Option .......................................17
8.4. Send Loss Event Rate Feature ..............................18
8.5. Loss Event Rate Option ....................................18
8.6. Loss Intervals Option .....................................18
8.6.1. Option Details .....................................19
8.6.2. Example ............................................20
9. Verifying Congestion Control Compliance with ECN ...............22
9.1. Verifying the ECN Nonce Echo ..............................22
9.2. Verifying the Reported Loss Intervals and Loss
Event Rate ................................................23
10. Implementation Issues .........................................23
10.1. Timestamp Usage ..........................................23
10.2. Determining Loss Events at the Receiver ..................24
10.3. Sending Feedback Packets .................................25
11. Security Considerations .......................................27
12. IANA Considerations ...........................................28
12.1. Reset Codes ..............................................28
12.2. Option Types .............................................28
12.3. Feature Numbers ..........................................28
13. Thanks ........................................................29
A. Appendix: Possible Future Changes to CCID 3 ....................30
Normative References ..............................................31
Informative References ............................................31
6.3. 承認の承認…13 6.4. 静止を決定します…14 7. 明白な混雑通知…14 8. オプションと特徴…14 8.1. 窓の対価…15 8.2. 経過時間オプション…17 8.3. レートオプションを受け取ってください…17 8.4. 損失イベントレート機能を送ってください…18 8.5. 損失イベントレートオプション…18 8.6. 損失間隔オプション…18 8.6.1. オプションの詳細…19 8.6.2. 例…20 9. 混雑について確かめて、電子証券取引ネットワークへのコンプライアンスを制御してください…22 9.1. 電子証券取引ネットワーク一回だけについて確かめて、反響してください…22 9.2. 報告された損失間隔と損失出来事について確かめて、評価してください…23 10. 実現問題…23 10.1. タイムスタンプ用法…23 10.2. 受信機で損失出来事を決定します…24 10.3. フィードバックパケットを送ります…25 11. セキュリティ問題…27 12. IANA問題…28 12.1. コードをリセットしてください…28 12.2. オプションタイプ…28 12.3. 数を特徴としてください…28 13. ありがとうございます…29A.付録: 可能な未来はCCID3に変化します…30 標準の参照…31 有益な参照…31
List of Tables
テーブルのリスト
Table 1: DCCP CCID 3 Options ......................................14 Table 2: DCCP CCID 3 Feature Numbers ..............................15
テーブル1: DCCP CCID3オプション…14 テーブル2: DCCP CCID3は数を特徴とします…15
1. Introduction
1. 序論
This document contains the profile for Congestion Control Identifier 3, TCP-Friendly Rate Control (TFRC), 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 Identifier3のためのプロフィールを含んでいます、TCP好意的なRate Control(TFRC)、データグラムCongestion Controlプロトコル(DCCP)[RFC4340]で。 DCCPは、半分接続のときに使用中の混雑制御機構を指定するのにCongestion Control Identifiers、またはCCIDsを使用します。
TFRC is a receiver-based congestion control mechanism that provides a TCP-friendly sending rate while minimizing the abrupt rate changes characteristic of TCP or of TCP-like congestion control [RFC3448]. The sender's allowed sending rate is set in response to the loss
TFRCは突然のレートを最小にするとTCPかTCPのような輻輳制御の特性が変化しますが[RFC3448]、TCPに優しい送付レートを提供する受信機ベースの混雑制御機構です。 送付者の許容送付レートは損失に対応して設定されます。
Floyd, et al. Standards Track [Page 2] RFC 4342 DCCP CCID3 TFRC March 2006
フロイド、他 規格は2006年のDCCP CCID3 TFRC行進のときにRFC4342を追跡します[2ページ]。
event rate, which is typically reported by the receiver to the sender. See Section 3 for more on application requirements.
イベント率。(その率は受信機によって送付者に通常報告されます)。 詳しい情報については、アプリケーション要件でセクション3を見てください。
2. Conventions
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]で説明されるように本書では解釈されることであるべきですか?
All multi-byte numerical quantities in CCID 3, such as arguments to options, are transmitted in network byte order (most significant byte first).
CCID3のオプションへの議論などのすべてのマルチバイト数量がネットワークバイトオーダーで伝えられる、(最も重要なバイト、1番目)
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]を見てください。
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であるとマークされたパケットを示します。
This document uses a number of variables from [RFC3448], including the following:
このドキュメントは以下を含む[RFC3448]から多くの変数を使用します:
o X_recv: The receive rate in bytes per second. See [RFC3448],
Section 3.2.2.
o _X recv: 1秒あたりのバイトで表現されるレートを受け取ってください。 [RFC3448]、セクション3.2.2を見てください。
o s: The packet size in bytes. See [RFC3448], Section 3.1.
o s: バイトで表現されるパケットサイズ。 [RFC3448]、セクション3.1を見てください。
o p: The loss event rate. See [RFC3448], Section 3.1.
o p: 損失イベント率。 [RFC3448]、セクション3.1を見てください。
3. Usage
3. 用法
CCID 3's TFRC congestion control is appropriate for flows that would prefer to minimize abrupt changes in the sending rate, including streaming media applications with small or moderate receiver buffering before playback. TCP-like congestion control, such as that of DCCP's CCID 2 [RFC4341], halves the sending rate in response to each congestion event and thus cannot provide a relatively smooth sending rate.
送付レートにおける突然の変化を最小にするのを好む流れに、CCID3のTFRC輻輳制御は適切です、再生の前の小さいか適度の受信機バッファリングによるストリーミング・メディアアプリケーションを含んでいて。 DCCPのCCID2[RFC4341]のものなどのTCPのような輻輳制御は、それぞれの混雑出来事に対応して送付レートを半分にして、その結果、比較的滑らかな送付レートを提供できません。
Floyd, et al. Standards Track [Page 3] RFC 4342 DCCP CCID3 TFRC March 2006
フロイド、他 規格は2006年のDCCP CCID3 TFRC行進のときにRFC4342を追跡します[3ページ]。
As explained in [RFC3448], Section 1, the penalty of having smoother throughput than TCP while competing fairly for bandwidth with TCP is that the TFRC mechanism in CCID 3 responds slower to changes in available bandwidth than do TCP or TCP-like mechanisms. Thus, CCID 3 should only be used for applications with a requirement for smooth throughput. For applications that simply need to transfer as much data as possible in as short a time as possible, we recommend using TCP-like congestion control, such as CCID 2.
[RFC3448]、セクション1で説明されるように、TCPと共に帯域幅を公正に競争している間、TCPより滑らかなスループットを持つ刑罰はCCID3のTFRCメカニズムがTCPかTCPのようなメカニズムより利用可能な帯域幅の変化に遅く応じるということです。その結果、CCID3はアプリケーションに滑らかなスループットのための要件で使用されるだけであるべきです。 単にできるだけ短い間でできるだけ多くのデータを移す必要があるアプリケーションのために、私たちは、TCPのような輻輳制御を使用することを勧めます、CCID2などのように。
CCID 3 should also not be used by applications that change their sending rate by varying the packet size, rather than by varying the rate at which packets are sent. A new CCID will be required for these applications.
また、パケットが送られるレートを変えることによってというよりむしろパケットサイズを変えることによってそれらの送付レートを変えるアプリケーションでCCID3を使用するべきではありません。 新しいCCIDがこれらのアプリケーションに必要でしょう。
3.1. Relationship with TFRC
3.1. TFRCとの関係
The congestion control mechanisms described here follow the TFRC mechanism standardized by the IETF [RFC3448]. Conforming CCID 3 implementations MAY track updates to the TCP throughput equation directly, as updates are standardized in the IETF, rather than wait for revisions of this document. However, conforming implementations SHOULD wait for explicit updates to CCID 3 before implementing other changes to TFRC congestion control.
ここで説明された混雑制御機構はIETF[RFC3448]によって標準化されたTFRCメカニズムに従います。 CCID3実現を従わせると、アップデートは直接TCPスループット方程式に追跡されるかもしれません、アップデートがこのドキュメントの改正を待っているよりIETFでむしろ標準化されるとき。 しかしながら、TFRC輻輳制御への他の変化を実行する前に、従っている実現SHOULDはCCID3に明白なアップデートを待ちます。
3.2. Half-Connection Example
3.2. 半分接続の例
This example shows the typical progress of a half-connection using CCID 3's TFRC Congestion Control, not including connection initiation and termination. The example is informative, not normative.
この例はCCID3のTFRC Congestion Controlを使用することで半分接続の典型的な進歩を示しています、接続開始と終了を含んでいなくて。 例は規範的であるのではなく、有益です。
1. The sender transmits DCCP-Data packets. Its sending rate is
governed by the allowed transmit rate as specified in [RFC3448],
Section 3.2. Each DCCP-Data packet has a sequence number and the
DCCP header's CCVal field contains the window counter value, which
is used by the receiver in determining when multiple losses belong
in a single loss event.
1. 送付者はDCCP-データ・パケットを伝えます。 送付レートは治められて、許容が指定されるようにレートを伝えるということ[RFC3448]であり、セクションは3.2です。 各DCCP-データ・パケットには、一連番号があります、そして、DCCPヘッダーのCCVal分野は窓の対価を含んでいます。(いつ、単一の損失出来事には複数の損失があるかを決定する際にそれは、受信機によって使用されます)。
In the typical case of an ECN-capable half-connection, each DCCP-
Data and DCCP-DataAck packet is sent as ECN Capable, with either
the ECT(0) or the ECT(1) codepoint set. The use of the ECN Nonce
with TFRC is described in Section 9.
電子証券取引ネットワーク有能な半分接続、それぞれのDCCPデータ、およびDCCP-DataAckの典型的な場合では、電子証券取引ネットワークCapableとしてパケットを送ります、ECT(0)かECT(1) codepointセットのどちらかで。 TFRCとの電子証券取引ネットワークNonceの使用はセクション9で説明されます。
2. The receiver sends DCCP-Ack packets acknowledging the data packets
at least once per round-trip time, unless the sender is sending at
a rate of less than one packet per round-trip time, as indicated
by the TFRC specification ([RFC3448], Section 6). Each DCCP-Ack
packet uses a sequence number, identifies the most recent packet
2. DCCP-Ackパケットは受信機で往復の時間単位でデータ・パケットを少なくとも一度承認します、送付者が往復の時間あたり1つ未満のパケットのレートで発信しない場合、TFRC仕様([RFC3448]、セクション6)で示されるように。 それぞれのDCCP-Ackパケットは、一連番号を使用して、最新のパケットを特定します。
Floyd, et al. Standards Track [Page 4] RFC 4342 DCCP CCID3 TFRC March 2006
フロイド、他 規格は2006年のDCCP CCID3 TFRC行進のときにRFC4342を追跡します[4ページ]。
received from the sender, and includes feedback about the recent
loss intervals experienced by the receiver.
受信機によって経験された最近の損失およそ間隔で、送付者から受信して、フィードバックを含んでいます。
3. The sender continues sending DCCP-Data packets as controlled by
the allowed transmit rate. Upon receiving DCCP-Ack packets, the
sender updates its allowed transmit rate as specified in
[RFC3448], Section 4.3. This update is based on a loss event rate
calculated by the sender using the receiver's loss intervals
feedback. If it prefers, the sender can also use a loss event
rate calculated and reported by the receiver.
3. 送付者は、制御されて、許容がレートを伝えるのでDCCP-データ・パケットを送り続けています。 それは許容されました。DCCP-Ackパケット、送付者アップデートを受ける、[RFC3448]、セクション4.3で指定されているとしてレートを伝えてください。 このアップデートは受信機の損失間隔フィードバックを使用することで送付者によって計算された損失イベント率に基づいています。 好む、また、送付者は受信機によって計算されて、報告された損失イベント率を使用できます。
4. The sender estimates round-trip times and calculates a nofeedback
time, as specified in [RFC3448], Section 4.4. If no feedback is
received from the receiver in that time (at least four round-trip
times), the sender halves its sending rate.
4. 送付者は、[RFC3448]、セクション4.4で指定されるように往復の回を見積もって、nofeedback時間について計算します。 その時(往復の少なくとも4回)受信機からフィードバックを全く受け取らないなら、送付者は送付レートを半分にします。
4. Connection Establishment
4. コネクション確立
The client initiates the connection by using mechanisms described in the DCCP specification [RFC4340]. During or after CCID 3 negotiation, the client and/or server may want to negotiate the values of the Send Ack Vector and Send Loss Event Rate features.
クライアントは、DCCP仕様[RFC4340]で説明されたメカニズムを使用することによって、接続を開始します。 交渉かCCID3交渉の後に、クライアント、そして/または、サーバはSend Ack VectorとSend Loss Event Rateの特徴の値を交渉したがっているかもしれません。
5. Congestion Control on Data Packets
5. データ・パケットにおける輻輳制御
CCID 3 uses the congestion control mechanisms of TFRC [RFC3448]. The following discussion summarizes information from [RFC3448], which should be considered normative except where specifically indicated otherwise.
CCID3はTFRC[RFC3448]の混雑制御機構を使用します。 以下の議論は[RFC3448]から情報をまとめます。(それは、別の方法で明確に示されるところを除いて、規範的であると考えられるべきです)。
Loss Event Rate
損失イベント率
The basic operation of CCID 3 centers around the calculation of a loss event rate: the number of loss events as a fraction of the number of packets transmitted, weighted over the last several loss intervals. This loss event rate, a round-trip time estimate, and the average packet size are plugged into the TCP throughput equation, as specified in [RFC3448], Section 3.1. The result is a fair transmit rate close to what a modern TCP would achieve in the same conditions. CCID 3 senders are limited to this fair rate.
CCID3の基本的な操作は損失イベント率の計算を中心に置きます: パケットの数の部分としての損失出来事の数は伝わりました、ここいくつかの損失間隔にわたって荷重しています。 TCPスループット方程式はこの損失イベント率、往復の時間見積り、および平均したパケットサイズにプラグを差し込まれます、[RFC3448]で指定されるように、セクション3.1。 結果はフェアが近代的なTCPが同じ状態で達成することの近くでレートを伝えるということです。 CCID3送付者はこの公正なレートに制限されます。
The loss event rate itself is calculated in CCID 3 using recent loss interval lengths reported by the receiver. Loss intervals are precisely defined in Section 6.1. In summary, a loss interval is up to 1 RTT of possibly lost or ECN-marked data packets, followed by an arbitrary number of non-dropped, non-marked data packets. Thus, long loss intervals represent low congestion rates. The CCID 3 Loss
損失イベント率自体は、CCID3で受信機によって報告された最近の損失間隔の長さを使用することで計算されます。損失間隔はセクション6.1で正確に定義されます。 概要では、損失間隔は非低下して、非著しいデータ・パケットの特殊活字の数字があとに続いたことによると無くなっているか電子証券取引ネットワークが著しいデータ・パケットの最大1RTTです。 したがって、長い損失間隔は低混雑率を表します。 CCID3の損失
Floyd, et al. Standards Track [Page 5] RFC 4342 DCCP CCID3 TFRC March 2006
フロイド、他 規格は2006年のDCCP CCID3 TFRC行進のときにRFC4342を追跡します[5ページ]。
Intervals option is used to report loss interval lengths; see Section 8.6.
間隔オプションは損失間隔の長さを報告するのに使用されます。 セクション8.6を見てください。
Other Congestion Control Mechanisms
他の混雑制御機構
The sender starts in a slow-start phase, roughly doubling its allowed sending rate each round-trip time. The slow-start phase is ended by the receiver's report of a data packet drop or mark, after which the sender uses the loss event rate to calculate its allowed sending rate.
往復の毎回およそ許容送付レートを倍にして、送付者は遅れた出発フェーズで始めます。 遅れた出発フェーズは受信機のデータ・パケット滴かマークのレポートによって終わらされます。(その時、送付者は、許容送付レートについて計算するのに損失イベント率を使用しました後)。
[RFC3448], Section 4, specifies an initial sending rate of one packet per round-trip time (RTT) as follows: The sender initializes the allowed sending rate to one packet per second. As soon as a feedback packet is received from the receiver, the sender has a measurement of the round-trip time and then sets the initial allowed sending rate to one packet per RTT. However, while the initial TCP window used to be one segment, [RFC2581] allows an initial TCP window of two segments, and [RFC3390] allows an initial TCP window of three or four segments (up to 4380 bytes). [RFC3390] gives an upper bound on the initial window of min(4*MSS, max(2*MSS, 4380 bytes)).
[RFC3448](セクション4)は以下の往復の時間(RTT)あたり1つのパケットの初期の送付レートを指定します: 送付者は1秒あたり1つのパケットに許容送付レートを初期化します。 受信機からフィードバックパケットを受け取るとすぐに、送付者は、往復の現代の測定を持って、次に、1RTTあたり1つのパケットに初期の許容送付レートを設定します。 しかしながら、初期のTCPの窓は以前、1つのセグメントでしたが、[RFC2581]は2つのセグメントの初期のTCPの窓を許容します、そして、[RFC3390]は3か4つのセグメント(最大4380バイト)の初期のTCPの窓を許容します。 [RFC3390]は分の初期の窓の上で上限を与えます(4*MSS、(2*MSS、4380バイト)に最大限にしてください)。
Therefore, in contrast to [RFC3448], the initial CCID 3 sending rate is allowed to be at least two packets per RTT, and at most four packets per RTT, depending on the packet size. The initial rate is only allowed to be three or four packets per RTT when, in terms of segment size, that translates to at most 4380 bytes per RTT.
したがって、[RFC3448]と対照して初期のCCID3送付レートはRTTと、ほとんどの1RTTあたり4つのパケットの少なくとも2つのパケットであることが許容されています、パケットサイズによって。 それがセグメントサイズに関して高々1RTTあたり4380バイトしか翻訳されないときだけ、初期のレートは1RTTあたり3か4つのパケットであることが許容されています。
The sender's measurement of the round-trip time uses the Elapsed Time and/or Timestamp Echo option contained in feedback packets, as described in Section 8.2. The Elapsed Time option is required, while the Timestamp Echo option is not. The sender maintains an average round-trip time heavily weighted on the most recent measurements.
送付者の往復の現代の測定はオプションがフィードバックパケットに含んだElapsed Time、そして/または、Timestamp Echoを使用します、セクション8.2で説明されるように。 Elapsed Timeオプションが必要ですが、Timestamp Echoオプションはそうではありません。 送付者は最新の測定値でずっしりと荷重しているのに平均した往復の時間を維持します。
Each DCCP-Data packet contains a sequence number. Each DCCP-Data packet also contains a window counter value, as described in Section 8.1. The window counter is generally incremented by one every quarter round-trip time. The receiver uses it as a coarse-grained timestamp to determine when a packet loss should be considered part of an existing loss interval and when it must begin a new loss interval.
各DCCP-データ・パケットは一連番号を含んでいます。 また、各DCCP-データ・パケットはセクション8.1で説明されるように窓の対価を含んでいます。 一般に、ウィンドウカウンタは4分の1の往復の毎回1つ増加されています。 受信機は、パケット損失がいつ既存の損失間隔の一部であると考えられるべきであるか、そして、それがいつ新しい損失間隔を始めなければならないかを決定するのに下品なタイムスタンプとしてそれを使用します。
Because TFRC is rate-based instead of window-based, and because feedback packets can be dropped in the network, the sender needs some mechanism for reducing its sending rate in the absence of positive feedback from the receiver. As described in Section 6, the receiver sends feedback packets roughly once per round-trip time. As specified in [RFC3448], Section 4.3, the sender sets a nofeedback
窓のベースの代わりにネットワークでフィードバックパケットを落とすことができるのでTFRCがレートベースであるので、送付者は受信機からの積極的なフィードバックがないとき送付レートを低下させるのに何らかのメカニズムを必要とします。セクション6で説明されるように、受信機は往復の時間に一度手荒くフィードバックパケットを送ります。 [RFC3448]、セクション4.3で指定されるように、送付者はnofeedbackを設定します。
Floyd, et al. Standards Track [Page 6] RFC 4342 DCCP CCID3 TFRC March 2006
フロイド、他 規格は2006年のDCCP CCID3 TFRC行進のときにRFC4342を追跡します[6ページ]。
timer to at least four round-trip times, or to twice the interval between data packets, whichever is larger. If the sender hasn't received a feedback packet from the receiver when the nofeedback timer expires, then the sender halves its allowed sending rate. The allowed sending rate is never reduced below one packet per 64 seconds. Note that not all acknowledgements are considered feedback packets, since feedback packets must contain valid Loss Intervals, Elapsed Time, and Receive Rate options.
より大きい往復の少なくとも4回、またはデータ・パケットの間隔の2倍までのタイマ。 nofeedbackタイマが期限が切れるとき、送付者が受信機からフィードバックパケットを受けていないなら、送付者は許容送付レートを半分にします。 許容送付レートは決して64秒あたり1つ未満のパケットまで低下しません。 すべての承認がフィードバックパケットであると考えられるというわけではないことに注意してください、フィードバックパケットが有効なLoss Intervals、Elapsed Time、およびReceive Rateオプションを含まなければならないので。
If the sender never receives a feedback packet from the receiver, and as a consequence never gets to set the allowed sending rate to one packet per RTT, then the sending rate is left at its initial rate of one packet per second, with the nofeedback timer expiring after two seconds. The allowed sending rate is halved each time the nofeedback timer expires. Thus, if no feedback is received from the receiver, the allowed sending rate is never above one packet per second and is quickly reduced below one packet per second.
受信機、結果が、1RTTあたり1つのパケットに許容送付レートを設定し決して始めないとき送付者がフィードバックパケットを決して受けないなら、送付レートは1秒あたり1つのパケットの初期のレートで残されます、nofeedbackタイマが2秒以降期限が切れていて。 nofeedbackタイマが期限が切れるたびに許容送付レートは半分にされます。 したがって、受信機からフィードバックを全く受け取らないなら、許容送付レートを1秒あたり1つのパケットの上に決してなくて、急速に1秒あたり1つ未満のパケットまで低下させます。
The feedback packets from the receiver contain a Receive Rate option specifying the rate at which data packets arrived at the receiver since the last feedback packet. The allowed sending rate can be at most twice the rate received at the receiver in the last round-trip time. This may be less than the nominal fair rate if, for example, the application is sending less than its fair share.
受信機からのフィードバックパケットは最後のフィードバックパケット以来データ・パケットが受信機に到着したレートを指定するReceive Rateオプションを含んでいます。 許容送付レートは高々受信機に最後の往復の時間で受け取られたレートの2倍であることができます。 例えば、アプリケーションが発信しないなら、これは名目上の公正なレートより正当な分け前より少ないかもしれません。
5.1. Response to Idle and Application-Limited Periods
5.1. 空費する応答とアプリケーション限定期間
One consequence of the nofeedback timer is that the sender reduces the allowed sending rate when the sender has been idle for a significant period of time. In [RFC3448], Section 4.4, the allowed sending rate is never reduced to fewer than two packets per round- trip time as the result of an idle period. CCID 3 revises this to take into account the larger initial windows allowed by [RFC3390]: the allowed sending rate is never reduced to less than the [RFC3390] initial sending rate as the result of an idle period. If the allowed sending rate is less than the initial sending rate upon entry to the idle period, then it will still be less than the initial sending rate when the idle period is exited. However, if the allowed sending rate is greater than or equal to the initial sending rate upon entry to the idle period, then it should not be reduced below the initial sending rate no matter how long the idle period lasts.
nofeedbackタイマの1つの結果は送付者が重要な期間の間活動していないときに、送付者が許容送付レートを低下させるということです。 [RFC3448]、セクション4.4では、許容送付レートは活動していない期間の結果として決して丸い旅行時間あたり2つ未満のパケットまで低下しません。 CCID3は[RFC3390]によって許容されたより大きい初期の窓を考慮に入れるためにこれを改訂します: 許容送付レートは活動していない期間の結果として[RFC3390]初期の送付レート以下に決して低下しません。 活動していない期間が出られるとき、許容送付レートがエントリーでの初期の送付レートより活動していない期間に初期の送付レートより少ないなら、それはまだ以下になっているでしょう。 しかしながら、許容送付レートがそう以上なら、活動していない期間までエントリーでの初期の送付レートであり、そして、活動していない期間がどれくらい長い間続いても、それは初期の送付速度より下で減少するべきではありません。
The sender's allowed sending rate is limited to at most twice the receive rate reported by the receiver. Thus, after an application- limited period, the sender can at most double its sending rate from one round-trip time to the next, until it reaches the allowed sending rate determined by the loss event rate.
受信機によって報告されたレートを受け取ってください。送付者の許容送付レートが高々二度制限される、その結果、アプリケーション限定期間の後に送付者は送付レートを高々往復の1回から次の回まで倍にすることができます、損失イベント率に従って決定している許容送付レートに達するまで。
Floyd, et al. Standards Track [Page 7] RFC 4342 DCCP CCID3 TFRC March 2006
フロイド、他 規格は2006年のDCCP CCID3 TFRC行進のときにRFC4342を追跡します[7ページ]。
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. Its 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 3 senders respond to these options as described in [RFC4340], with the following further clarifications.
受信機がオプションで宣言するパケットが落とされた終わりが配送の前にアプリケーションに接待するDCCPのData Dropped--例えば、不正か受信バッファオーバーフローのために。 受信機は、Slow Receiverオプションで送付者のパケットについて行くのに苦労していると宣言します、何もまだ落とされていませんが。 CCID3送付者は[RFC4340]で以下のさらなる明確化で説明されるようにこれらのオプションに応じます。
o Drop Code 2 ("receive buffer drop"). The allowed sending rate is
reduced by one packet per RTT for each packet newly acknowledged
as Drop Code 2, except that it is never reduced below one packet
per RTT as a result of Drop Code 2.
o Code2(「受信バッファ低下」)を落としてください。 許容送付レートはDrop Code2として新たに承認された各パケットのために1RTTあたり1つのパケットによって低下させられます、それがDrop Code2の結果、決して1RTTあたり1つ未満のパケットまで減少しないのを除いて。
o Adjusting the receive rate X_recv. A CCID 3 sender SHOULD also
respond to non-network-congestion events, such as those implied by
Data Dropped and Slow Receiver options, by adjusting X_recv, the
receive rate reported by the receiver in Receive Rate options (see
Section 8.3). The CCID 3 sender's allowed sending rate is limited
to at most twice the receive rate reported by the receiver via the
"min(..., 2*X_recv)" clause in TFRC's throughput calculations
([RFC3448], Section 4.3). When the sender receives one or more
Data Dropped and Slow Receiver options, the sender adjusts X_recv
as follows:
o 適応、レートX_recvを受けてください。 また送付者SHOULDが非ネットワークの混雑出来事に反応させるCCID3、_ものがData DroppedとSlow Receiverオプションで含意した調整しているX recvによるそのようなもの、受信機によってReceive Rateオプションで報告されたレートを受け取ってください(セクション8.3を見てください)。 CCID3送付者の許容送付レートが高々二度制限される、受信機によってTFRCのスループット計算([RFC3448]、セクション4.3)における「分(… 2*X_はrecvする)」節で報告されたレートを受け取ってください。 送付者が1Data DroppedとSlow Receiverオプションを受け取るとき、送付者は以下のX_recvを調整します:
1. X_inrecv is equal to the Receive Rate in bytes per second
reported by the receiver in the most recent acknowledgement.
1. X_inrecvは受信機によって最新の承認で2番目に報告されているのあたりのバイトで表現されるReceive Rateと等しいです。
2. X_drop is set to the sending rate upper bound implied by Data
Dropped and Slow Receiver options. If the sender receives a
Slow Receiver option, which requests that the sender not
increase its sending rate for roughly a round-trip time
[RFC4340], then X_drop should be set to X_inrecv. Similarly,
if the sender receives a Data Dropped option indicating, for
example, that three packets were dropped with Drop Code 2, then
the upper bound on the sending rate will be decreased by at
most three packets per RTT, by the sender setting X_drop to
2. X_低下はData DroppedとSlow Receiverオプションで含意された送付レート上限に設定されます。 送付者がSlow Receiverオプション(送付者がおよそ往復の時間[RFC4340]の送付速度を増加させないよう要求する)を受け取るなら、X_低下はX_inrecvに設定されるべきです。 同様に、送付者が例えば3つのパケットがDrop Code2と共に落とされたのを示すData Droppedオプションを受け取ると、ほとんどの1RTTあたり3つのパケットで送付レートの上限減少するでしょう、X_が落ちる送付者設定のそばで
max(X_inrecv - 3*s/RTT, min(X_inrecv, s/RTT)).
最大限にしてください(X_inrecv--3*s/RTT、分(X_inrecv、s/RTT))。
Again, s is the packet size in bytes.
一方、sはバイトで表現されるパケットサイズです。
3. X_recv is then set to min(X_inrecv, X_drop/2).
3. そして、X_recvは分に用意ができています(X_inrecv、X_低下/2)。
As a result, the next round-trip time's sending rate will be
limited to at most 2*(X_drop/2) = X_drop. The effects of the Slow
Receiver and Data Dropped options on X_recv will mostly vanish by
その結果、次の往復の時間の送付レートは高々2*(X_低下/2)=X_低下に制限されるでしょう。 recvがほとんど消え失せるX_へのSlow ReceiverとData Droppedオプションの効果
Floyd, et al. Standards Track [Page 8] RFC 4342 DCCP CCID3 TFRC March 2006
フロイド、他 規格は2006年のDCCP CCID3 TFRC行進のときにRFC4342を追跡します[8ページ]。
the round-trip time after that, which is appropriate for this
non-network-congestion feedback. This procedure MUST only be used
for those Drop Codes not related to corruption (see [RFC4340]).
Currently, this is limited to Drop Codes 0, 1, and 2.
その後の往復の時間。(この非ネットワークの混雑フィードバックに、その時間は適切です)。 不正に関連しないそれらのDrop Codesにこの手順を用いるだけでよいです([RFC4340]を見てください)。 現在、これはDrop Codes0、1、および2に制限されます。
5.3. Packet Sizes
5.3. パケットサイズ
CCID 3 is intended for applications that use a fixed packet size, and that vary their sending rate in packets per second in response to congestion. CCID 3 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. However, some attention might be required for applications using CCID 3 that vary their packet size not in response to congestion, but in response to other application-level requirements.
CCID3は固定パケットサイズを使用して、1秒あたりのパケットで混雑に対応してそれらの送付レートを変えるアプリケーションのために意図します。 パケットの間の時間の固定間隔を必要として、混雑に対応したそれらのパケットレートの代わりにそれらのパケットサイズを変えるアプリケーションには、CCID3は適切ではありません。 しかしながら、何らかの注意が、アプリケーションに混雑に対応して他のアプリケーションレベル要件に対応してそれらのパケットサイズを変えるCCID3を使用することで必要であるかもしれません。
The packet size s is used in the TCP throughput equation. A CCID 3 implementation MAY calculate s as the segment size averaged over multiple round trip times -- for example, over the most recent four loss intervals, for loss intervals as defined in Section 6.1. Alternately, a CCID 3 implementation MAY use the Maximum Packet Size to derive s. In this case, s is set to the Maximum Segment Size (MSS), the maximum size in bytes for the data segment, not including the default DCCP and IP packet headers. Each packet transmitted then counts as one MSS, regardless of the actual segment size, and the TCP throughput equation can be interpreted as specifying the sending rate in packets per second.
パケットサイズsはTCPスループット方程式で使用されます。 セグメントサイズが複数の周遊旅行回、例えば最新の4の損失の上で間隔を平均して、CCID3実現はsについて計算するかもしれません、セクション6.1で定義される損失間隔の間。 交互に、CCID3実現は、sを引き出すのにMaximum Packet Sizeを使用するかもしれません。 この場合、sはMaximum Segment Size(MSS)に設定されます、データ・セグメントのためのバイトで表現される最大サイズ、デフォルトDCCPとIPパケットのヘッダーを含んでいなくて。 各パケットは実際のセグメントサイズにかかわらず1MSSとして当時のカウントを伝えました、そして、1秒あたりのパケットで送付レートを指定しながら、TCPスループット方程式は解釈できます。
CCID 3 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].)
CCID3実現は不適当にパケットサイズを操っているように見えるアプリケーションがないかどうかチェックするかもしれません。 例えば、アプリケーションは、速いレートを確立して、しばらく小型小包を送って、次に、速いレートを利用するために大きいパケットに切り替わるかもしれません。 (予備のシミュレーションが、アプリケーションがこのようにそれらの総合的な転送レートを増加させることができないかもしれないのを示すので、この操作が習慣[V03]で起こるのは、明確ではありません。)
6. Acknowledgements
6. 承認
The receiver sends a feedback packet to the sender roughly once per round-trip time, if the sender is sending packets that frequently. This rate is determined by the TFRC protocol as specified in [RFC3448], Section 6.
受信機は往復の時間に一度手荒くフィードバックパケットを送付者に送ります、送付者がそんなに頻繁にパケットを送るなら。 このレートは[RFC3448]、セクション6の指定されるとしてのTFRCプロトコルによって測定されます。
Each feedback packet contains an Acknowledgement Number, which equals
the greatest valid sequence number received so far on this
connection. ("Greatest" is, of course, measured in circular sequence
space.) Each feedback packet also includes at least the following
options:
それぞれのフィードバックパケットはAcknowledgement Numberを含んでいます。(Acknowledgement Numberはこの接続のときに今までのところ受け取られている最大級の有効な一連番号と等しいです)。 (「最もすばらしい」であることは、もちろん測定された円形の系列スペースです。) また、それぞれのフィードバックパケットは少なくとも以下のオプションを含んでいます:
Floyd, et al. Standards Track [Page 9] RFC 4342 DCCP CCID3 TFRC March 2006
フロイド、他 規格は2006年のDCCP CCID3 TFRC行進のときにRFC4342を追跡します[9ページ]。
1. An Elapsed Time and/or Timestamp Echo option specifying the amount
of time elapsed since the arrival at the receiver of the packet
whose sequence number appears in the Acknowledgement Number field.
These options are described in [RFC4340], Section 13.
1. 一連番号のパケットの受信機への到着がAcknowledgement Number分野に現れるので、時間を指定するElapsed Time、そして/または、Timestamp Echoオプションは経過しました。 これらのオプションは[RFC4340]、セクション13で説明されます。
2. A Receive Rate option, defined in Section 8.3, specifying the rate
at which data was received since the last DCCP-Ack was sent.
2. 最後のDCCP-Ackを送ったので、どのデータにレートを指定するセクション8.3で定義されたReceive Rateオプションを受け取りました。
3. A Loss Intervals option, defined in Section 8.6, specifying the
most recent loss intervals experienced by the receiver. (The
definition of a loss interval is provided below.) From Loss
Intervals, the sender can easily calculate the loss event rate p
using the procedure described in [RFC3448], Section 5.4.
3. セクション8.6(間隔が受信機で経験した指定している最新の損失)で定義された(損失間隔の定義を以下に提供します。)Loss Intervalsオプション Loss Intervalsから、送付者は[RFC3448](セクション5.4)で説明された手順を用いる損失イベント率pについて容易に計算できます。
Acknowledgements not containing at least these three options are not considered feedback packets.
少なくともこれらを含んでいなくて、3つのオプションがフィードバックパケットであることは考えられないという承認。
The receiver MAY also include other options concerning the loss event rate, including Loss Event Rate, which gives the loss event rate calculated by the receiver (Section 8.5), and DCCP's generic Ack Vector option, which reports the specific sequence numbers of any lost or marked packets ([RFC4340], Section 11.4). Ack Vector is not required by CCID 3's congestion control mechanisms: the Loss Intervals option provides all the information needed to manage the transmit rate and probabilistically verify receiver feedback. However, Ack Vector may be useful for applications that need to determine exactly which packets were lost. The receiver MAY also include other acknowledgement-related options, such as DCCP's Data Dropped option ([RFC4340], Section 11.7).
また、受信機は損失イベント率に関して別の選択肢を含むかもしれません、受信機(セクション8.5)によって計算された損失イベント率を与えるLoss Event RateとDCCPの一般的なAck Vectorオプション(どんな無くなっているか著しいパケット([RFC4340]、セクション11.4)の特定の一連番号も報告する)を含んでいて。 Ack VectorはCCID3の混雑制御機構によって必要とされません: Loss Intervalsオプションが管理するのに必要であるすべての情報を提供する、レートを伝えてください、そして、probabilisticallyに受信機フィードバックを確かめてください。 しかしながら、Ack Vectorはどのパケットが失われたかをまさに決定する必要があるアプリケーションの役に立つかもしれません。 また、受信機はDCCPのData Droppedオプションなどの他の承認関連のオプション([RFC4340]、セクション11.7)を含むかもしれません。
If the HC-Receiver is also sending data packets to the HC-Sender, then it MAY piggyback acknowledgement information on those data packets more frequently than TFRC's specified acknowledgement rate allows.
また、HC-受信機がHC-送付者にデータ・パケットを送るなら、それはTFRCの指定された承認率が許容するより頻繁にそれらのデータ・パケットの承認情報を背負うかもしれません。
6.1. Loss Interval Definition
6.1. 損失間隔定義
As described in [RFC3448], Section 5.2, a loss interval begins with a lost or ECN-marked data packet; continues with at most one round-trip time's worth of packets that may or may not be lost or marked; and completes with an arbitrarily long series of non-dropped, non-marked data packets. For example, here is a single loss interval, assuming that sequence numbers increase as you move right:
[RFC3448]、セクション5.2で説明されるように、損失間隔は無くなっているか電子証券取引ネットワークが著しいデータ・パケットと共に始まります。 往復の回の高々1つのものの間、失われているか、またはマークされるかもしれないパケットの価値を続行します。 そして、任意に長いシリーズの非低下して、非著しいデータ・パケットで、完成します。 例えば、ここに、あなたが右に移るのに従って一連番号が増加すると仮定して、単一の損失間隔があります:
Floyd, et al. Standards Track [Page 10] RFC 4342 DCCP CCID3 TFRC March 2006
フロイド、他 規格は2006年のDCCP CCID3 TFRC行進のときにRFC4342を追跡します[10ページ]。
Lossy Part
<= 1 RTT __________ Lossless Part __________
/ \/ \
*----*--*--*-------------------------------------
^ ^ ^ ^
losses or marks
損失性パート<は1RTTと等しいです。__________ Lossless部分__________ / \/ \ *----*--*--*------------------------------------- ^ ^ ^ ^損失かマーク
Note that a loss interval's lossless part might be empty, as in the first interval below:
下の最初の間隔のように損失間隔のlossless部分が空であるかもしれないことに注意してください:
Lossy Part Lossy Part
<= 1 RTT <= 1 RTT _____ Lossless Part _____
/ \/ \/ \
*----*--*--***--------*-*---------------------------
^ ^ ^ ^^^ ^ ^
\_ Int. 1 _/\_____________ Interval 2 _____________/
1RTT損失性部分損失性パート<=<が1RTTと等しいです。_____ Lossless部分_____ / \/ \/ \ *----*--*--***--------*-*--------------------------- ^ ^ ^ ^^^ ^ ^ \_Int。 1 _/\_____________ 間隔2_____________/
As in [RFC3448], Section 5.2, the length of the lossy part MUST be less than or equal to 1 RTT. CCID 3 uses window counter values, not receive times, to determine whether multiple packets occurred in the same RTT and thus belong to the same loss event; see Section 10.2. A loss interval whose lossy part lasts for more than 1 RTT, or whose lossless part contains a dropped or marked data packet, is invalid.
[RFC3448]、セクション5.2のように、損失性部分の長さは1RTTであるに違いありません。 CCID3は回を受けるのではなく、複数のパケットが同じRTTに起こったかどうか決定して、その結果、同じ損失出来事に属すのに窓の対価を使用します。 セクション10.2を見てください。 損失性部分が1RTTのために持続するか、またはlosslessが離れている損失間隔は、低下したか著しいデータ・パケットを含んでいて、無効です。
A missing data packet doesn't begin a new loss interval until NDUPACK packets have been seen after the "hole", where NDUPACK = 3. Thus, up to NDUPACK of the most recent sequence numbers (including the sequence numbers of any holes) might temporarily not be part of any loss interval while the implementation waits to see whether a hole will be filled. See [RFC3448], Section 5.1, and [RFC2581], Section 3.2, for further discussion of NDUPACK.
NDUPACKパケットが「穴」、どこNDUPACK=3時以降見られるかまで、欠測値パケットは新しい損失間隔を始めません。 したがって、実現が、穴がふさがれるかどうかを見るのを待っている間、最新の一連番号のNDUPACKまで、(どんな穴の一連番号も含んでいます)は一時どんな損失間隔の一部でないかもしれません。 NDUPACKのさらなる議論に関して[RFC3448]、セクション5.1、および[RFC2581]、セクション3.2を見てください。
As specified by [RFC3448], Section 5, all loss intervals except the first begin with a lost or marked data packet, and all loss intervals are as long as possible, subject to the validity constraints above.
[RFC3448]、セクション5によって指定されるように、1番目を除いたすべての損失間隔が無くなっているか著しいデータ・パケットと共に始まります、そして、すべての損失間隔ができるだけ上の正当性規制を条件として長いです。
Lost and ECN-marked non-data packets may occur freely in the lossless part of a loss interval. (Non-data packets consist of those packet types that cannot carry application data; namely, DCCP-Ack, DCCP- Close, DCCP-CloseReq, DCCP-Reset, DCCP-Sync, and DCCP-SyncAck.) In the absence of better information, a receiver MUST conservatively assume that every lost packet was a data packet and thus must occur in some lossy part. DCCP's NDP Count option can help the receiver determine whether a particular packet contained data; see [RFC4340], Section 7.7.
無くなっていて電子証券取引ネットワークが著しい非データ・パケットは損失間隔のlossless地域に自由に起こるかもしれません。 (非データ・パケットはアプリケーションデータを運ぶことができないそれらのパケットタイプから成ります; すなわち、DCCP-Ack、DCCP閉鎖、DCCP-CloseReq、DCCP-リセット、DCCP-同時性、およびDCCP-SyncAck) より良い情報がないとき、受信機はあらゆる無くなっているパケットがデータ・パケットであり、その結果、何らかの損失性部分に起こらなければならないと保守的に仮定しなければなりません。 DCCPのNDP Countオプションは、受信機が、特定のパケットがデータを含んだかどうか決定するのを助けることができます。 [RFC4340]、セクション7.7を見てください。
Floyd, et al. Standards Track [Page 11] RFC 4342 DCCP CCID3 TFRC March 2006
フロイド、他 規格は2006年のDCCP CCID3 TFRC行進のときにRFC4342を追跡します[11ページ]。
6.1.1. Loss Interval Lengths
6.1.1. 損失間隔の長さ
[RFC3448] defines the TFRC congestion control mechanism in terms of a one-way transfer of data, with data packets going from the sender to the receiver and feedback packets going from the receiver back to the sender. However, CCID 3 applies in a context of two half- connections, with DCCP-Data and DCCP-DataAck packets from one half- connection sharing sequence number space with DCCP-Ack packets from the other half-connection. For the purposes of CCID 3 congestion control, loss interval lengths should include data packets and should exclude the acknowledgement packets from the reverse half-connection. However, it is also useful to report the total number of packets in each loss interval (for example, to facilitate ECN Nonce verification).
[RFC3448]は片道データ転送でTFRC混雑制御機構を定義します、データ・パケットが送付者から受信機まで行っていて、フィードバックパケットが受信機から送付者まで行っていて。 しかしながら、CCID3は2つの半分接続の文脈で適用します、半分接続からのDCCP-データとDCCP-DataAckパケットがもう片方の半分接続からDCCP-Ackパケットと一連番号スペースを共有していて。 CCID3輻輳制御の目的のために、損失間隔の長さは、データ・パケットを含むべきであり、逆の半分接続に確認応答パケットを入れないようにするべきです。 しかしながら、また、それぞれの損失間隔(例えば電子証券取引ネットワークのNonce検証を容易にする)のパケットの総数を報告するのも役に立ちます。
CCID 3's Loss Intervals option thus reports three lengths for each loss interval, the lengths of the lossy and lossless parts defined above and a separate data length. First, the lossy and lossless lengths are measured in sequence numbers. Together, they sum to the interval's sequence length, which is the total number of packets the sender transmitted during the interval. This is easily calculated in DCCP as the greatest packet sequence number in the interval minus the greatest packet sequence number in the preceding interval (or, if there is no preceding interval, then the predecessor to the half- connection's initial sequence number). The interval's data length, however, is the number used in TFRC's loss event rate calculation, as defined in [RFC3448], Section 5, and is calculated as follows.
その結果、CCID3のLoss Intervalsオプションはそれぞれの損失間隔、損失性の長さ、上で定義されたlossless部分、および別々のデータの長さのために3つの長さを報告します。 まず最初に、損失性とlosslessの長さは一連番号で測定されます。 彼らは間隔の系列の長さへ一緒に、まとめます。(それは、送付者が間隔の間に伝えたパケットの総数です)。 これは間隔における最大級のパケット一連番号としてDCCPで容易に前の間隔(次に、どんな前の間隔もないときの半分接続の初期シーケンス番号への前任者)における最大級のパケット一連番号を引いて計算されます。 間隔のデータの長さは、しかしながら、[RFC3448]、セクション5で定義されるようにTFRCの損失イベントレート計算に使用される数であり、以下の通り計算されます。
For all loss intervals except the first, the data length equals the sequence length minus the number of non-data packets the sender transmitted during the loss interval, except that the minimum data length is one packet. In the absence of better information, an endpoint MUST conservatively assume that the loss interval contained only data packets, in which case the data length equals the sequence length. To achieve greater precision, the sender can calculate the exact number of non-data packets in an interval by remembering which sent packets contained data; the receiver can account for received non-data packets by not including them in the data length, and for packets that were not received, it may be able to discriminate between lost data packets and lost non-data packets using DCCP's NDP Count option.
1番目を除いたすべての損失間隔の間、データの長さは送付者が損失間隔の間に伝えた非データ・パケットの数を引いて系列の長さと等しいです、最小のデータの長さが1つのパケットであるのを除いて。 より良い情報がないとき、終点は、損失間隔がデータ・パケットだけを含んだと保守的に仮定しなければなりません、その場合、データの長さが系列の長さと等しいです。 より大きい精度を達成するために、合間にどれが含まれたデータをパケットに送ったかを覚えていることによって、送付者は非データ・パケットのはっきりした数について計算できます。 受信機はデータの長さにそれらを含んでいないことによって、容認された非データ・パケットの原因になることができます、そして、受け取られなかったパケットに関して、それはDCCPのNDP Countオプションを使用することでロストデータパケットと無くなっている非データ・パケットを区別できるかもしれません。
The first loss interval's data length is undefined until the first loss event. [RFC3448], Section 6.3.1 specifies how the first loss interval's data length is calculated once the first loss event has occurred; this calculation uses X_recv, the most recent receive rate, as input. Until this first loss event, the loss event rate is zero,
最初の損失間隔のデータの長さは最初の損失出来事まで未定義です。 [RFC3448]、セクション6.3.1は最初の損失出来事がいったん起こると最初の損失間隔のデータの長さがどう計算されるかを指定します。 この計算は最新の状態でX_recvを使用します。入力としてレートを受け取ってください。 この最初の損失出来事まで、損失イベント率はゼロです。
Floyd, et al. Standards Track [Page 12] RFC 4342 DCCP CCID3 TFRC March 2006
フロイド、他 規格は2006年のDCCP CCID3 TFRC行進のときにRFC4342を追跡します[12ページ]。
as is the data length reported for the interval in the Loss Intervals option.
そのままで、データの長さは間隔の間、Loss Intervalsオプションで報告しました。
The first loss interval's data length might be less than, equal to, or even greater than its sequence length. Any other loss interval's data length must be less than or equal to its sequence length.
最初の損失間隔のデータの長さが、より少ないかもしれない、系列の長さより等しいか、またはさらに大きいです。 いかなる他の損失間隔のデータの長さもその系列の、より長さ以下であるに違いありません。
A sender MAY use the loss event rate or loss interval data lengths as reported by the receiver, or it MAY recalculate loss event rate and/or loss interval data lengths based on receiver feedback and additional information. For example, assume the network drops a DCCP-Ack packet with sequence number 50. The receiver might then report a loss interval beginning at sequence number 50. If the sender determined that this loss interval actually contained no lost or ECN-marked data packets, then it might coalesce the loss interval with the previous loss interval, resulting in a larger allowed transmit rate.
送付者が受信機によって報告されるように損失イベント率か損失間隔データの長さを使用するかもしれませんか、またはそれは受信機フィードバックと追加情報に基づくrecalculate損失イベント率、そして/または、損失間隔データの長さを使用するかもしれません。 例えば、ネットワークが一連番号50でDCCP-Ackパケットを落とすと仮定してください。 そして、受信機は一連番号50で始まる損失間隔を報告するかもしれません。 この損失間隔が実際に無くなっていないか電子証券取引ネットワークが著しいデータ・パケットを含んで、次に、前の損失間隔、aでは、より大きい結果になることで損失間隔を合体させるかもしれないと決心している送付者であるなら、許容されて、レートを伝えてください。
6.2. Congestion Control on Acknowledgements
6.2. 承認の輻輳制御
The rate and timing for generating acknowledgements is determined by the TFRC algorithm ([RFC3448], Section 6). The sending rate for acknowledgements is relatively low -- roughly once per round-trip time -- so there is no need for explicit congestion control on acknowledgements.
TFRCアルゴリズム([RFC3448]、セクション6)で承認を発生させるレートとタイミングは測定されます。 承認の送付速度はおよそ往復の時間に一度比較的低いです--したがって、承認の明白な輻輳制御の必要は全くありません。
6.3. Acknowledgements of Acknowledgements
6.3. 承認の承認
TFRC acknowledgements don't generally need to be reliable, so the sender generally need not acknowledge the receiver's acknowledgements. When Ack Vector or Data Dropped is used, however, the sender, DCCP A, MUST occasionally acknowledge the receiver's acknowledgements so that the receiver can free up Ack Vector or Data Dropped state. When both half-connections are active, the necessary acknowledgements will be contained in A's acknowledgements to B's data. If the B-to-A half-connection goes quiescent, however, DCCP A must send an acknowledgement proactively.
TFRC承認を一般に信頼できさせる必要はないので、一般に、送付者は受信機の承認を承諾する必要はありません。 しかしながら、Ack VectorかData Droppedが使用されているとき、送付者(DCCP A)は、受信機がAck VectorかData Dropped状態を開けることができるように、時折受信機の承認を承諾しなければなりません。 両方の半分接続が活発であるときに、必要な承認はAの承認にビーズデータに含まれるでしょう。 しかしながら、BからAとの半分接続が静かになるなら、DCCP Aは承認を予測して送らなければなりません。
Thus, when Ack Vector or Data Dropped is used, an active sender MUST acknowledge the receiver's acknowledgements approximately once per round-trip time, within a factor of two or three, probably by sending a DCCP-DataAck packet. No acknowledgement options are necessary, just the Acknowledgement Number in the DCCP-DataAck header.
Ack VectorかData Droppedが使用されているとき、したがって、活発な送付者は往復の時間単位で受信機の承認をおよそ一度承諾しなければなりません、2か3の要素の中で、たぶんDCCP-DataAckパケットを送ることによって。 どんな承認オプションも必要でなく、まさしくDCCP-DataAckのAcknowledgement Numberはヘッダーです。
The sender MAY choose to acknowledge the receiver's acknowledgements even if they do not contain Ack Vectors or Data Dropped options. For instance, regular acknowledgements can shrink the size of the Loss Intervals option. Unlike Ack Vector and Data Dropped, however, the
Ack VectorsかData Droppedオプションを含まないでも、送付者は、受信機の承認を承諾するのを選ぶかもしれません。 例えば、定期的な承認はLoss Intervalsオプションのサイズを縮めることができます。 しかしながらAck VectorとData Droppedと異なって。
Floyd, et al. Standards Track [Page 13] RFC 4342 DCCP CCID3 TFRC March 2006
フロイド、他 規格は2006年のDCCP CCID3 TFRC行進のときにRFC4342を追跡します[13ページ]。
Loss Intervals option is bounded in size (and receiver state), so acks-of-acks are not required.
損失Intervalsオプションはサイズ(そして、受信機状態)において境界があるので、acksのacksは必要ではありません。
6.4. Determining Quiescence
6.4. 静止を決定します。
This section describes how a CCID 3 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.
このセクションは、CCID3受信機がどのように対応する送付者がデータを少しの送らないことを決定して、したがって、静かになったかを説明します。 一般情報のために[RFC4340]、セクション11.1を静止に見てください。
Let T equal the greater of 0.2 seconds and two round-trip times. (A CCID 3 receiver has a rough measure of the round-trip time so that it can pace its acknowledgements.) The receiver detects that the sender has gone quiescent after T seconds have passed without receiving any additional data from the sender.
Tを等しさに0.2秒と往復の2回について、よりすばらしくしてください。 (CCID3受信機には、往復の現代の荒い基準が承認に歩調を合わせることができるように、あります。) 受信機はそれを検出します。送付者は秒が送付者からどんな追加データも受け取らないで通ったTの後に静かになりました。
7. Explicit Congestion Notification
7. 明白な混雑通知
CCID 3 supports Explicit Congestion Notification (ECN) [RFC3168]. In the typical case of an ECN-capable half-connection (where the receiver's ECN Incapable feature is set to zero), the sender will use the ECN Nonce for its data packets, as specified in [RFC4340], Section 12.2. Information about the ECN Nonce MUST be returned by the receiver using the Loss Intervals option, and any Ack Vector options MUST include the ECN Nonce Sum. The sender MAY maintain a table with the ECN nonce sum for each packet and use this information to probabilistically verify the ECN nonce sums returned in Loss Intervals or Ack Vector options. Section 9 describes this further.
CCID3はExplicit Congestion Notification(電子証券取引ネットワーク)[RFC3168]を支持します。 電子証券取引ネットワーク有能な半分接続(受信機の電子証券取引ネットワークIncapableの特徴がゼロに設定されるところ)の典型的な場合では、送付者はデータ・パケットに電子証券取引ネットワークNonceを使用するでしょう、[RFC4340]で指定されるように、セクション12.2。 Loss Intervalsオプションを使用して、受信機で電子証券取引ネットワークNonceに関する情報を返さなければなりません、そして、どんなAck Vectorオプションも電子証券取引ネットワークNonce Sumを含まなければなりません。 送付者は、各パケットのために電子証券取引ネットワークの一回だけの合計があるテーブルを維持して、probabilisticallyにLoss IntervalsかAck Vectorオプションで返された電子証券取引ネットワークの一回だけの合計について確かめるのにこの情報を使用するかもしれません。 セクション9はさらにこれについて説明します。
8. Options and Features
8. オプションと特徴
CCID 3 can make use of DCCP's Ack Vector, Timestamp, Timestamp Echo, and Elapsed Time options, and its Send Ack Vector and ECN Incapable features. In addition, the following CCID-specific options are defined for use with CCID 3.
CCID3はそのDCCPのAck Vector、Timestamp、Timestamp Echo、Elapsed Timeオプション、Send Ack Vector、および電子証券取引ネットワークIncapableの特徴を利用できます。 さらに、以下のCCID特有のオプションはCCID3との使用のために定義されます。
Option DCCP- Section
Type Length Meaning Data? Reference
----- ------ ------- ----- ---------
128-191 Reserved
192 6 Loss Event Rate N 8.5
193 variable Loss Intervals N 8.6
194 6 Receive Rate N 8.3
195-255 Reserved
DCCP輪切り形長さの意味データをゆだねますか? 参照----- ------ ------- ----- --------- 128-191 予約された192 6Loss Event Rate N8.5 193可変Loss Intervals N8.6 194 6Receive Rate N8.3 195-255Reserved
Table 1: DCCP CCID 3 Options
テーブル1: DCCP CCID3オプション
Floyd, et al. Standards Track [Page 14] RFC 4342 DCCP CCID3 TFRC March 2006
フロイド、他 規格は2006年のDCCP CCID3 TFRC行進のときにRFC4342を追跡します[14ページ]。
The "DCCP-Data?" column indicates that all currently defined CCID 3- specific options MUST be ignored when they occur on DCCP-Data packets.
「DCCP-データ?」コラムは、DCCP-データ・パケットの上に起こるとき、すべての現在定義されたCCID3の特定のオプションを無視しなければならないのを示します。
The following CCID-specific feature is also defined.
また、以下のCCID特有の特徴は定義されます。
Rec'n Initial Section
Number Meaning Rule Value Req'd Reference
------ ------- ----- ----- ----- ---------
128-191 Reserved
192 Send Loss Event Rate SP 0 N 8.4
193-255 Reserved
意味規則値のReqが参照をつけるRec'nの初期のセクション番号------ ------- ----- ----- ----- --------- 128-191 予約された192は損失イベントレートSP0に8.4 193-255が予約したNを送ります。
Table 2: DCCP CCID 3 Feature Numbers
テーブル2: DCCP CCID3特徴番号
The column meanings are described in [RFC4340], Table 4. "Rec'n Rule" defines the feature's reconciliation rule, where "SP" means server-priority. "Req'd" specifies whether every CCID 3 implementation MUST understand a feature; Send Loss Event Rate is optional, in that it behaves like an extension ([RFC4340], Section 15).
Table4、コラム意味は[RFC4340]で説明されます。 "Rec'n Rule"はフィーチャーの和解規則を定義します。そこでは、"SP"がサーバ優先権を意味します。 「Reqはそうするでしょう」は、あらゆるCCID3実現が特徴を理解しなければならないかどうか指定します。 発信してください。Loss Event Rateは、拡大([RFC4340]、セクション15)のように反応するので、任意です。
8.1. Window Counter Value
8.1. 窓の対価
The data sender stores a 4-bit window counter value in the DCCP generic header's CCVal field on every data packet it sends. This value is set to 0 at the beginning of the transmission and generally increased by 1 every quarter of a round-trip time, as described in [RFC3448], Section 3.2.1. Window counters use circular arithmetic modulo 16 for all operations, including comparisons; see [RFC4340], Section 3.1, for more information on circular arithmetic. For reference, the DCCP generic header is as follows. (The diagram is repeated from [RFC4340], Section 5.1, which also shows the generic header with a 24-bit Sequence Number field.)
データ送付者は一般的なヘッダーのCCValがそれが送るあらゆるデータ・パケットの上でさばくDCCPに4ビットの窓の対価を格納します。 この値はトランスミッションの始めの0へのセットであり、一般に、増加する1は往復の時間のあらゆる4分の1です、[RFC3448]、セクション3.2.1で説明されるように。 ウィンドウカウンタは比較を含むすべての操作に円形の算数の法16を使用します。 円形の演算の詳しい情報に関して[RFC4340]、セクション3.1を見てください。 参照において、DCCPの一般的なヘッダーは以下の通りです。 (ダイヤグラムは[RFC4340]、また、24ビットのSequence Number分野がある一般的なヘッダーを見せているセクション5.1から繰り返されます。)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Dest Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Offset | CCVal | CsCov | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Type |1| Reserved | Sequence Number (high bits) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Sequence Number (low bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソース港| Destポート| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データは相殺されます。| CCVal| CsCov| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Res| タイプ|1| 予約されます。| Number(高いビット)+++++++++++++++++++++++++++++++++ 系列系列Number(低ビット)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Floyd, et al. Standards Track [Page 15] RFC 4342 DCCP CCID3 TFRC March 2006
フロイド、他 規格は2006年のDCCP CCID3 TFRC行進のときにRFC4342を追跡します[15ページ]。
The CCVal field has enough space to express 4 round-trip times at quarter-RTT granularity. The sender MUST avoid wrapping CCVal on adjacent packets, as might happen, for example, if two data-carrying packets were sent 4 round-trip times apart with no packets intervening. Therefore, the sender SHOULD use the following algorithm for setting CCVal. The algorithm uses three variables: "last_WC" holds the last window counter value sent, "last_WC_time" is the time at which the first packet with window counter value "last_WC" was sent, and "RTT" is the current round-trip time estimate. last_WC is initialized to zero, and last_WC_time to the time of the first packet sent. Before sending a new packet, proceed like this:
CCVal分野には、4分の1RTT粒状で往復の4回を言い表すことができるくらいのスペースがあります。 送付者は、隣接しているパケットにCCValを包装するのを避けなければなりません、例えば、パケットに介入しないで往復の4倍離れて2つのデータを運ぶパケットを送るなら起こるとき。 したがって、送付者SHOULDは、CCValを設定するのに以下のアルゴリズムを使用します。 アルゴリズムは3つの変数を使用します: 「最後の_トイレ」は、最後の窓の対価が送られるままにします、そして、「最後の_トイレ_時間」は窓の対価「最終_トイレ」がある最初のパケットが送られた時間です、そして、"RTT"は現在の往復の時間見積りです。最後の_トイレは、__時間から最初のパケットの時間が送ったトイレをゼロに合わせて、持続するように初期化されます。 新しいパケットを送る前に、このように、続いてください:
Let quarter_RTTs = floor((current_time - last_WC_time) / (RTT/4)).
If quarter_RTTs > 0, then:
Set last_WC := (last_WC + min(quarter_RTTs, 5)) mod 16.
Set last_WC_time := current_time.
Set the packet header's CCVal field to last_WC.
4分の1_RTTs=床((現在の_時間--最後の_トイレ_時間)/(RTT/4))を貸してください。 4分の1_RTTs>0、その時なら: (_トイレ+分(4分の1_RTTs、5)が続きます)モッズ風の16の最後の_トイレ:=を設定してください。 最後の_のトイレ_時間の:=の現在の_時間を決めてください。 最後の_トイレにパケットのヘッダーのCCVal分野を設定してください。
When this algorithm is used, adjacent data-carrying packets' CCVal counters never differ by more than five, modulo 16.
このアルゴリズムが中古の、そして、隣接しているデータ携帯であるときに、パケットのCCValカウンタは5以上、法16で決して異なりません。
The window counter value may also change as feedback packets arrive. In particular, after receiving an acknowledgement for a packet sent with window counter WC, the sender SHOULD increase its window counter, if necessary, so that subsequent packets have window counter value at least (WC + 4) mod 16.
また、フィードバックパケットが到着するのに応じて、窓の対価は変化するかもしれません。 窓のカウンタトイレと共に送られたパケットのための承認を受けた後に特に、送付者SHOULDが必要ならウィンドウカウンタを増加させるので、ウィンドウカウンタはその後のパケットで少なくとも(トイレ+4)モッズ風の16を評価します。
The CCVal counters are used by the receiver to determine whether multiple losses belong to a single loss event, to determine the interval to use for calculating the receive rate, and to determine when to send feedback packets. None of these procedures require the receiver to maintain an explicit estimate of the round-trip time. However, implementors who wish to keep such an RTT estimate may do so using CCVal. Let T(I) be the arrival time of the earliest valid received packet with CCVal = I. (Of course, when the window counter value wraps around to the same value mod 16, we must recalculate T(I).) Let D = 2, 3, or 4 and say that T(K) and T(K+D) both exist (packets were received with window counters K and K+D). Then the value (T(K+D) - T(K)) * 4/D MAY serve as an estimate of the round- trip time. Values of D = 4 SHOULD be preferred for RTT estimation. Concretely, say that the following packets arrived:
CCValカウンタが複数の損失が間隔を決定するために単一の損失出来事に属すか否かに関係なく、決定する受信機によって計算する使用に使用される、レートを受け取ってください、いつフィードバックパケットを送るかを決定します。 これらの手順のいずれも、往復の現代の明白な見積りを維持するために受信機を必要としません。 しかしながら、したがって、そのようなRTT見積りを保ちたい作成者は、CCValを使用することでそうするかもしれません。 CCVal=I.でT(I)が最も早い有効な容認されたパケットの到着時間であることをさせてください。(もちろん、窓の対価が同じ値モッズ風の16に巻きつけられるとき、私たちはrecalculate T(I)を巻きつけられなければなりません) 2、3、またはD=4をさせてください、そして、T(K)とT(K+D)がともに存在すると言ってください(ウィンドウカウンタKとK+Dでパケットを受け取りました)。 次に、値、(T(K+D)--T(K))*4/Dは丸い旅行時間の見積りとして機能するかもしれません。 Dの値は4SHOULDと等しいです。RTT見積りのために、好まれます。 具体的に、以下のパケットが到着したと言ってください:
Time: T1 T2 T3 T4 T5 T6 T7 T8 T9
------*---*---*-*----*------------*---*----*--*---->
CCVal: K-1 K-1 K K K+1 K+3 K+4 K+3 K+4
時間: T1 T2 T3 T4 T5 T6 T7 T8 T9------*---*---*-*----*------------*---*----*--*---->CCVal: K-1KのK-1K K+1K+3K+4K+3K+4
Floyd, et al. Standards Track [Page 16] RFC 4342 DCCP CCID3 TFRC March 2006
フロイド、他 規格は2006年のDCCP CCID3 TFRC行進のときにRFC4342を追跡します[16ページ]。
Then T7 - T3, the difference between the receive times of the first packet received with window counter K+4 and the first packet received with window counter K, is a reasonable round-trip time estimate. Because of the necessary constraint that measurements only come from packet pairs whose CCVals differ by at most 4, this procedure does not work when the inter-packet sending times are significantly greater than the RTT, resulting in packet pairs whose CCVals differ by 5. Explicit RTT measurement techniques, such as Timestamp and Timestamp Echo, should be used in that case.
次に、T7--、T3、間の違い、ウィンドウカウンタKで窓の反対のK+4と最初のパケットを受け取っていて受け取られた最初のパケットの倍を受けてください、そして、妥当な往復の時間は見積りですか? 測定値がCCValsが高々4時までに異なるパケット組から来るだけであるという必要な規制のために、相互パケット送付回数がRTTよりかなりすばらしいときに、この手順は利きません、CCValsが5時までに異なるパケット組をもたらして。 TimestampやTimestamp Echoなどの明白なRTT測定技術はその場合使用されるべきです。
8.2. Elapsed Time Options
8.2. 経過時間オプション
The data receiver MUST include an elapsed time value on every required acknowledgement. This helps the sender distinguish between network round-trip time, which it must include in its rate equations, and delay at the receiver due to TFRC's infrequent acknowledgement rate, which it need not include. The receiver MUST at least include an Elapsed Time option on every feedback packet, but if at least one recent data packet (i.e., a packet received after the previous DCCP- Ack was sent) included a Timestamp option, then the receiver SHOULD include the corresponding Timestamp Echo option, with Elapsed Time value, as well. All of these option types are defined in the main DCCP specification [RFC4340].
データ受信装置はあらゆる必要な承認の経過時間値を含まなければなりません。 これは、送付者がネットワークの往復の時間を見分けるのを助けます。(それはTFRCの珍しい承認率のため受信機にレート方程式、および遅れに時間を含まなければなりません)。それは率を含む必要はありません。 受信機はあらゆるフィードバックパケットにおけるElapsed Timeオプションを少なくとも含まなければなりませんが、少なくとも1つの最近のデータパケット(すなわち、前のDCCP- Ackを送った後に受け取るパケット)がTimestampオプションを含んでいたなら、受信機SHOULDはまた、Elapsed Time値がある対応するTimestamp Echoオプションを含んでいます。 これらのオプションタイプのすべてが主なDCCP仕様[RFC4340]に基づき定義されます。
8.3. Receive Rate Option
8.3. レートオプションを受け取ってください。
+--------+--------+--------+--------+--------+--------+
|11000010|00000110| Receive Rate |
+--------+--------+--------+--------+--------+--------+
Type=194 Len=6
+--------+--------+--------+--------+--------+--------+ |11000010|00000110| レートを受け取ってください。| +--------+--------+--------+--------+--------+--------+ タイプ=194レン=6
This option MUST be sent by the data receiver on all required acknowledgements. Its four data bytes indicate the rate at which the receiver has received data since it last sent an acknowledgement, in bytes per second. To calculate this receive rate, the receiver sets t to the larger of the estimated round-trip time and the time since the last Receive Rate option was sent. (Received data packets' window counters can be used to produce a suitable RTT estimate, as described in Section 8.1.) The receive rate then equals the number of data bytes received in the most recent t seconds, divided by t.
データ受信装置はすべての必要な承認にこのオプションを送らなければなりません。 4データ・バイトがそれが最後に承認を送ったので受信機が受信データを持っているレートを示します、1秒あたりのバイトで。 これについて計算するには、レート(最後のReceive Rateオプションを送って以来のおよそ往復の現代について、より大きいことへのセットtと時間の受信機)を受け取ってください。 (適当なRTT見積りを起こすのにセクション8.1で説明されるように受信データパケットのウィンドウカウンタを使用できます。) データ・バイトの数がtが割られた最新のt秒に受けたレートの当時の同輩を受けてください。
Receive Rate options MUST NOT be sent on DCCP-Data packets, and any Receive Rate options on received DCCP-Data packets MUST be ignored.
DCCP-データ・パケットでオプションを送ってはいけないRateを受けてください。そうすれば、容認されたDCCP-データ・パケットにおけるどんなReceive Rateオプションも無視しなければなりません。
Floyd, et al. Standards Track [Page 17] RFC 4342 DCCP CCID3 TFRC March 2006
フロイド、他 規格は2006年のDCCP CCID3 TFRC行進のときにRFC4342を追跡します[17ページ]。
8.4. Send Loss Event Rate Feature
8.4. 損失イベントレート機能を送ってください。
The Send Loss Event Rate feature lets CCID 3 endpoints negotiate whether the receiver MUST provide Loss Event Rate options on its acknowledgements. DCCP A sends a "Change R(Send Loss Event Rate, 1)" option to ask DCCP B to send Loss Event Rate options as part of its acknowledgement traffic.
Send Loss Event Rateの特徴で、受信機が承認のときにオプションをLoss Event Rateに供給しなければならないか否かに関係なく、CCID3終点は交渉します。 DCCP Aは、承認交通の一部としてオプションをLoss Event Rateに送るようにDCCP Bに頼むために「変化R(損失イベント率、1を送ります)」オプションを送ります。
Send Loss Event Rate has feature number 192 and is server-priority. It takes one-byte Boolean values. DCCP B MUST send Loss Event Rate options on its acknowledgements when Send Loss Event Rate/B is one, although it MAY send Loss Event Rate options even when Send Loss Event Rate/B is zero. Values of two or more are reserved. A CCID 3 half-connection starts with Send Loss Event Rate equal to zero.
発信してください。Loss Event Rateは特徴No.192を持って、サーバ優先権です。 それは1バイトのブール値を取ります。 承認のときにSend Loss Event Rate/Bが1であるときに、DCCP BはオプションをLoss Event Rateに送らなければなりません、Send Loss Event Rate/Bがゼロでさえあるときに、オプションをLoss Event Rateに送るかもしれませんが。 2以上の値は予約されています。 CCID3半分接続はゼロに合わせるために等しいSend Loss Event Rateから始まります。
8.5. Loss Event Rate Option
8.5. 損失イベントレートオプション
+--------+--------+--------+--------+--------+--------+
|11000000|00000110| Loss Event Rate |
+--------+--------+--------+--------+--------+--------+
Type=192 Len=6
+--------+--------+--------+--------+--------+--------+ |11000000|00000110| 損失イベント率| +--------+--------+--------+--------+--------+--------+ タイプ=192レン=6
The option value indicates the inverse of the loss event rate, rounded UP, as calculated by the receiver. Its units are data packets per loss interval. Thus, if the Loss Event Rate option value is 100, then the loss event rate is 0.01 loss events per data packet (and the average loss interval contains 100 data packets). When each loss event has exactly one data packet loss, the loss event rate is the same as the data packet drop rate.
受信機によって計算されているとしてオプション価値は切り上げられた損失イベント率の逆を示します。損失間隔あたりユニットはデータ・パケットです。 したがって、Loss Event Rateオプション価値が100であるなら、1データ・パケットあたり損失イベント率は0.01回の損失出来事(海損間隔は100のデータ・パケットを含んでいる)です。 それぞれの損失出来事にちょうど1回のデータパケット損失があるとき、損失イベント率はデータパケット滴が評価するのと同じです。
See [RFC3448], Section 5, for a normative calculation of loss event rate. Before any losses have occurred, when the loss event rate is zero, the Loss Event Rate option value is set to "11111111111111111111111111111111" in binary (or, equivalently, to 2^32 - 1). The loss event rate calculation uses loss interval data lengths, as defined in Section 6.1.1.
損失イベント率の標準の計算に関して[RFC3448]、セクション5を見てください。 損失イベント率がゼロであるときに、どんな損失も発生する前に、Loss Event Rateオプション価値がバイナリーで「11111111111111111111111111111111」に設定される、(同等な2^32--1、) 損失イベントレート計算はセクション6.1.1で定義されるように損失間隔データの長さを使用します。
Loss Event Rate options MUST NOT be sent on DCCP-Data packets, and any Loss Event Rate options on received DCCP-Data packets MUST be ignored.
DCCP-データ・パケットで損失Event Rateオプションを送ってはいけません、そして、容認されたDCCP-データ・パケットにおけるどんなLoss Event Rateオプションも無視しなければなりません。
8.6. Loss Intervals Option
8.6. 損失間隔オプション
+--------+--------+--------+--------...--------+--------+---
|11000001| Length | Skip | Loss Interval | More Loss
| | | Length | | Intervals...
+--------+--------+--------+--------...--------+--------+---
Type=193 9 bytes
+--------+--------+--------+--------...--------+--------+--- |11000001| 長さ| スキップ| 損失間隔| より多くの損失| | | 長さ| | 間隔… +--------+--------+--------+--------...--------+--------+--- =193 9バイトをタイプしてください。
Floyd, et al. Standards Track [Page 18] RFC 4342 DCCP CCID3 TFRC March 2006
フロイド、他 規格は2006年のDCCP CCID3 TFRC行進のときにRFC4342を追跡します[18ページ]。
Each 9-byte Loss Interval contains three fields, as follows:
それぞれの9バイトのLoss Intervalは以下の通り3つの分野を含んでいます:
____________________ Loss Interval _____________________
/ \
+--------...-------+--------...--------+--------...--------+
| Lossless Length |E| Loss Length | Data Length |
+--------...-------+--------...--------+--------...--------+
3 bytes 3 bytes 3 bytes
____________________ 損失間隔_____________________ / \ +--------...-------+--------...--------+--------...--------+ | Losslessの長さ|E| 損失の長さ| データの長さ| +--------...-------+--------...--------+--------...--------+ 3バイト3バイト3バイト
The receiver reports its observed loss intervals using a Loss Intervals option. Section 6.1 defines loss intervals. This option MUST be sent by the data receiver on all required acknowledgements. The option reports up to 28 loss intervals seen by the receiver, although TFRC currently uses at most the latest 9 of these. This lets the sender calculate a loss event rate and probabilistically verify the receiver's ECN Nonce Echo.
受信機は、Loss Intervalsオプションを使用することで観測された損失間隔を報告します。 セクション6.1は損失間隔を定義します。 データ受信装置はすべての必要な承認にこのオプションを送らなければなりません。 オプションは受信機によって見られた最大28回の損失間隔を報告します、TFRCが現在、これら最新の9つを高々使用しますが。 これで、送付者は、損失イベント率について計算して、probabilisticallyに受信機の電子証券取引ネットワークNonce Echoについて確かめることができます。
The Loss Intervals option serves several purposes.
Loss Intervalsオプションはいくつかの目的に役立ちます。
o The sender can use the Loss Intervals option to calculate the loss
event rate.
o 送付者は、損失イベント率について計算するのにLoss Intervalsオプションを使用できます。
o Loss Intervals information is easily checked for consistency
against previous Loss Intervals options, and against any Loss
Event Rate calculated by the receiver.
o 損失Intervals情報は一貫性がないかどうか容易に前のLoss Intervalsオプションに対して受信機によって計算されたどんなLoss Event Rateに対してチェックされます。
o The sender can probabilistically verify the ECN Nonce Echo for
each Loss Interval, reducing the likelihood of misbehavior.
o 不正行為の見込みを減少させて、送付者は各Loss Intervalのためにprobabilisticallyに電子証券取引ネットワークNonce Echoについて確かめることができます。
Loss Intervals options MUST NOT be sent on DCCP-Data packets, and any Loss Intervals options on received DCCP-Data packets MUST be ignored.
DCCP-データ・パケットで損失Intervalsオプションを送ってはいけません、そして、容認されたDCCP-データ・パケットにおけるどんなLoss Intervalsオプションも無視しなければなりません。
8.6.1. Option Details
8.6.1. オプションの詳細
The Loss Intervals option contains information about one to 28 consecutive loss intervals, always including the most recent loss interval. Intervals are listed in reverse chronological order. Should more than 28 loss intervals need to be reported, then multiple Loss Intervals options can be sent; the second option begins where the first left off, and so forth. The options MUST contain information about at least the most recent NINTERVAL + 1 = 9 loss intervals unless (1) there have not yet been NINTERVAL + 1 loss intervals, or (2) the receiver knows, because of the sender's acknowledgements, that some previously transmitted loss interval information has been received. In this second case, the receiver need not send loss intervals that the sender already knows about, except that it MUST transmit at least one loss interval regardless.
Loss Intervalsオプションはいつも最新の損失間隔を含む1〜28回の連続した損失間隔の情報を含んでいます。 間隔は新しい順に記載されています。 間隔がオプションを送ることができる報告され、次に、複数のLoss Intervalsになるように必要とする28以上の損失はそうするべきです。 2番目のオプションは、1番目がやめたところで始まるので、先へ始まります。 オプションは(1) そこでないなら+ 1 = 9 損失間隔がまだ受信機が知っているNINTERVAL+1の損失間隔、または(2)でないというおよそ少なくとも情報の最新のNINTERVALを含まなければなりません、何らかの以前に伝えられた損失間隔情報を受け取ったという送付者の承認のために。 この2番目の場合では、受信機は送付者が既に知っている損失間隔を送る必要はありません、不注意に少なくとも1回の損失間隔を伝えなければならないのを除いて。
Floyd, et al. Standards Track [Page 19] RFC 4342 DCCP CCID3 TFRC March 2006
フロイド、他 規格は2006年のDCCP CCID3 TFRC行進のときにRFC4342を追跡します[19ページ]。
The NINTERVAL parameter is equal to "n" as defined in [RFC3448], Section 5.4.
NINTERVALパラメタは[RFC3448]、セクション5.4で定義されるように「n」と等しいです。
Loss interval sequence numbers are delta encoded starting from the Acknowledgement Number. Therefore, Loss Intervals options MUST NOT be sent on packets without an Acknowledgement Number, and any Loss Intervals options received on such packets MUST be ignored.
損失間隔一連番号はAcknowledgement Numberから始めて、コード化されたデルタです。 したがって、パケットでAcknowledgement NumberなしでLoss Intervalsオプションを送ってはいけません、そして、そのようなパケットの上に受け取られたどんなLoss Intervalsオプションも無視しなければなりません。
The first byte of option data is Skip Length, which indicates the number of packets up to and including the Acknowledgement Number that are not part of any Loss Interval. As discussed above, Skip Length must be less than or equal to NDUPACK = 3. In a packet containing multiple Loss Intervals options, the Skip Lengths of the second and subsequent options MUST equal zero; such options with nonzero Skip Lengths MUST be ignored.
オプションデータの最初のバイトはSkip Lengthです。(そのSkip LengthはどんなLoss Intervalの一部でないAcknowledgement Numberを含めてパケットの数を示します)。 上で議論するように、Skip Lengthは3NDUPACK=歳以下であるに違いありません。 複数のLoss Intervalsオプションを含むパケットでは、2番目の、そして、その後のオプションのSkip Lengthsはゼロと等しくなければなりません。 非零Skip Lengthsとのそのようなオプションを無視しなければなりません。
Loss Interval structures follow Skip Length. Each Loss Interval consists of a Lossless Length, a Loss Length, an ECN Nonce Echo (E), and a Data Length.
損失Interval構造はSkip Lengthに続きます。 各Loss IntervalはLossless Length、Loss Length、電子証券取引ネットワークNonce Echo(E)、およびData Lengthから成ります。
Lossless Length, a 24-bit number, specifies the number of packets in the loss interval's lossless part. Note again that this part may contain lost or marked non-data packets.
Lossless Length(24ビットの数)は損失間隔のlossless部分のパケットの数を指定します。 この部分が無くなっているか著しい非データ・パケットを含むかもしれないことにもう一度注意してください。
Loss Length, a 23-bit number, specifies the number of packets in the loss interval's lossy part. The sum of the Lossless Length and the Loss Length equals the loss interval's sequence length. Receivers SHOULD report the minimum valid Loss Length for each loss interval, making the first and last sequence numbers in each lossy part correspond to lost or marked data packets.
損失Length(23ビットの数)は損失間隔の損失性部分のパケットの数を指定します。 Lossless LengthとLoss Lengthの合計は損失間隔の系列の長さと等しいです。 受信機SHOULDはそれぞれの損失間隔の間、最小の有効なLoss Lengthを報告します、それぞれの損失性部分の1番目と最後の一連番号を無くなっているか著しいデータ・パケットに対応させている。
The ECN Nonce Echo, stored in the high-order bit of the 3-byte field containing Loss Length, equals the one-bit sum (exclusive-or, or parity) of data packet nonces received over the loss interval's lossless part (which is Lossless Length packets long). If Lossless Length is 0, the receiver is ECN Incapable, or the Lossless Length contained no data packets, then the ECN Nonce Echo MUST be reported as 0. Note that any ECN nonces on received non-data packets MUST NOT contribute to the ECN Nonce Echo.
Loss Lengthを含んでいて、3バイトの分野の高位のビットに格納された電子証券取引ネットワークNonce Echoは損失間隔のlossless部分(長い間、Lossless Lengthパケットである)の上受け取られたデータ・パケット一回だけの1ビットの合計(排他的論理和、または同等)と等しいです。 Lossless Lengthはデータ・パケットを全く含みませんでした、そして、次に、Lossless Lengthが0歳であるなら、受信機は電子証券取引ネットワークIncapableであるか0として電子証券取引ネットワークNonce Echoを報告しなければなりません。 容認された非データ・パケットの上のどんな電子証券取引ネットワーク一回だけも電子証券取引ネットワークNonce Echoに貢献してはいけないことに注意してください。
Finally, Data Length, a 24-bit number, specifies the loss interval's data length, as defined in Section 6.1.1.
最終的に、Data Length(24ビットの数)はセクション6.1.1で定義されるように損失間隔のデータの長さを指定します。
8.6.2. Example
8.6.2. 例
Consider the following sequence of packets, where "-" represents a safely delivered packet and "*" represents a lost or marked packet.
パケットの以下の系列を考えてください。そこでは、「-」が安全に渡されたパケットを表して、「*」は無くなっているか著しいパケットを表します。
Floyd, et al. Standards Track [Page 20] RFC 4342 DCCP CCID3 TFRC March 2006
フロイド、他 規格は2006年のDCCP CCID3 TFRC行進のときにRFC4342を追跡します[20ページ]。
Sequence
Numbers: 0 10 20 30 40 44
| | | | | |
----------*--------***-*--------*----------*-
一連番号: 0 10 20 30 40 44 | | | | | | ----------*--------***-*--------*----------*-
Assuming that packet 43 was lost, not marked, this sequence might be divided into loss intervals as follows:
パケット43がマークされるのではなく、失われたと仮定する場合、この系列は以下の損失間隔に分割されるかもしれません:
0 10 20 30 40 44
| | | | | |
----------*--------***-*--------*----------*-
\________/\_______/\___________/\_________/
L0 L1 L2 L3
0 10 20 30 40 44 | | | | | | ----------*--------***-*--------*----------*- \________/\_______/\___________/\_________/L0 L1 L2 L3
A Loss Intervals option sent on a packet with Acknowledgement Number 44 to acknowledge this set of loss intervals might contain the bytes 193,39,2, 0,0,10, 128,0,1, 0,0,10, 0,0,8, 0,0,5, 0,0,10, 0,0,8, 0,0,1, 0,0,8, 0,0,10, 128,0,0, 0,0,15. This option is interpreted as follows.
Loss Intervalsオプションは、このセットの損失間隔がバイト193、39、2、0、0、10、128、0、1、0、0、10、0、0、8、0、0、5、0、0、10、0、0、8、0、0、1、0、0、8、0、0、10、128、0、0、0、0、15を含むかもしれないと認めるためにAcknowledgement Number44があるパケットを転送しました。 このオプションは以下の通り解釈されます。
193 The Loss Intervals option number.
193 Loss Intervalsオプション番号。
39 The length of the option, including option type and length bytes.
This option contains information about (39 - 3)/9 = 4 loss
intervals.
39 オプションタイプと長さのバイトを含むオプションの長さ。 このオプションは(39--3)/9 = 4損失およそ間隔の間の情報を含んでいます。
2 The Skip Length is 2 packets. Thus, the most recent loss
interval, L3, ends immediately before sequence number 44 - 2 + 1
= 43.
2 Skip Lengthは2つのパケットです。 したがって、最新の損失間隔(L3)は一連番号44--2+1 = 43の直前終わります。
0,0,10, 128,0,1, 0,0,10
These bytes define L3. L3 consists of a 10-packet lossless part
(0,0,10), preceded by a 1-packet lossy part. Continuing to
subtract, the lossless part begins with sequence number 43 - 10 =
33, and the lossy part begins with sequence number 33 - 1 = 32.
The ECN Nonce Echo for the lossless part (namely, packets 33
through 42, inclusive) equals 1. The interval's data length is
10, so the receiver believes that the interval contained exactly
one non-data packet.
0、0、10、128、0、1、0、0、10TheseバイトはL3を定義します。 L3は1パケットの損失性部分が先行した10パケットのlossless部分(0、0、10)から成ります。 損失性部分は一連番号33で始まります--引き続けていて、lossless部分は一連番号43で10 = 33に始まります、そして、1 = 32。 losslessのための電子証券取引ネットワークNonce Echoが離れている、(すなわち、パケット33〜42、包括的である、)、同輩1 間隔のデータの長さが10であるので、受信機は、間隔がちょうど1つの非データ・パケットを含んだと信じています。
0,0,8, 0,0,5, 0,0,10
This defines L2, whose lossless part begins with sequence number
32 - 8 = 24; whose lossy part begins with sequence number 24 - 5
= 19; whose ECN Nonce Echo (for packets [24,31]) equals 0; and
whose data length is 10.
losslessは一連番号32でだれのものを離れさせ始めますか--0、0、8、0、0、5、0、0、10ThisがL2を定義して、8 = 24 だれの損失性は一連番号24で離れ始めますか--5 = 19 電子証券取引ネットワークNonce Echo(パケット[24、31]のための)同輩0。 そして、だれのデータの長さは10ですか?
Floyd, et al. Standards Track [Page 21] RFC 4342 DCCP CCID3 TFRC March 2006
フロイド、他 規格は2006年のDCCP CCID3 TFRC行進のときにRFC4342を追跡します[21ページ]。
0,0,8, 0,0,1, 0,0,8
L1's lossless part begins with sequence number 11, its lossy part
begins with sequence number 10, its ECN Nonce Echo (for packets
[11,18]) equals 0, and its data length is 8.
0、0、8、0、0、1、0、0、8L1のlossless部分は一連番号11で始まります、部分が一連番号10で始める損失性、電子証券取引ネットワークNonce Echo、(パケット、[11、18が)0と等しく、データの長さは8です。
0,0,10, 128,0,0, 0,0,15
L0's lossless part begins with sequence number 0, it has no lossy
part, its ECN Nonce Echo (for packets [0,9]) equals 1, and its
data length is 15. (This must be the first loss interval in the
connection; otherwise, a data length greater than the sequence
length would be invalid.)
0、0、10、128、0、0、0、0、15L0のlossless部分は一連番号0で始まります、そして、それには、損失性部分が全くありません、そして、電子証券取引ネットワークNonce Echo(パケット[0、9]のための)は1と等しいです、そして、データの長さは15です。 (これは接続で最初の損失間隔であるに違いありません; そうでなければ、系列の長さが無効であるだろうより大きいデータの長さ)
9. Verifying Congestion Control Compliance with ECN
9. 電子証券取引ネットワークへの輻輳制御コンプライアンスについて確かめます。
The sender can use Loss Intervals options' ECN Nonce Echoes (and possibly any Ack Vectors' ECN Nonce Echoes) to probabilistically verify that the receiver is correctly reporting all dropped or marked packets. Even if ECN is not used (the receiver's ECN Incapable feature is set to one), the sender could still check on the receiver by occasionally not sending a packet, or sending a packet out-of- order, to catch the receiver in an error in Loss Intervals or Ack Vector information. This is not as robust or non-intrusive as the verification provided by the ECN Nonce, however.
送付者は、受信機が正しくパケットであると落とされるか、またはマークされたすべてを報告していることをprobabilisticallyに確かめるのに、Loss Intervalsオプションの電子証券取引ネットワークNonceエコーズ(そして、ことによるとどんなAck Vectorsの電子証券取引ネットワークNonceエコーズも)を使用できます。 電子証券取引ネットワークが使用されていなくても(受信機の電子証券取引ネットワークIncapableの特徴は1つに設定されます)、送付者が時折までにパケットを送らないか、またはパケットを出さないことでまだ受信機について検査しているかもしれない、-、-Loss Intervalsの誤りかAck Vector情報で受信機に間に合うには、注文してください。 これは、しかしながら、電子証券取引ネットワークNonceによって提供された検証ほど、強健でもなくて、また非押しつけがましくもありません。
9.1. Verifying the ECN Nonce Echo
9.1. 電子証券取引ネットワークの一回だけのエコーについて確かめます。
To verify the ECN Nonce Echo included with a Loss Intervals option, the sender maintains a table with the ECN nonce sum for each data packet. As defined in [RFC3540], the nonce sum for sequence number S is the one-bit sum (exclusive-or, or parity) of data packet nonces over the sequence number range [I,S], where I is the initial sequence number. Let NonceSum(S) represent this nonce sum for sequence number S, and define NonceSum(I - 1) as 0. Note that NonceSum does not account for the nonces of non-data packets such as DCCP-Ack. Then the Nonce Echo for an interval of packets with sequence numbers X to Y, inclusive, should equal the following one-bit sum:
Loss IntervalsオプションでNonce Echoを含んでいて、電子証券取引ネットワークについて確かめるために、送付者は各データ・パケットのために電子証券取引ネットワークの一回だけの合計があるテーブルを維持します。 [RFC3540]で定義されるように、一連番号Sのための一回だけの合計は一連番号範囲[I、S]の上のデータ・パケット一回だけの1ビットの合計(排他的論理和、または同等)です。そこでは、Iが初期シーケンス番号です。 NonceSum(S)に一連番号Sのためにこの一回だけの合計を表させてください、そして、NonceSum(私--1)を0と定義してください。 NonceSumがDCCP-Ackなどの非データ・パケットの一回だけを説明しないことに注意してください。 次に、一連番号のXからYがあるパケットの間隔の間の包括的なNonce Echoは以下の1ビットの合計と等しいはずです:
NonceSum(X - 1) + NonceSum(Y)
NonceSum(X--1)+NonceSum(Y)
Since an ECN Nonce Echo is returned for the lossless part of each Loss Interval, a misbehaving receiver -- meaning a receiver that reports a lost or marked data packet as "received non-marked", to avoid rate reductions -- has only a 50% chance of guessing the correct Nonce Echo for each loss interval.
それぞれのLoss Intervalのlossless部分に電子証券取引ネットワークNonce Echoを返すので、ふらちな事する受信機(レート減少を避けるために「非著しい状態で、受け取る」ように無くなっているか著しいデータ・パケットを報告する受信機を意味する)には、それぞれの損失間隔の間、正しいNonce Echoを推測するという50%の確率しかありません。
To verify the ECN Nonce Echo included with an Ack Vector option, the sender maintains a table with the ECN nonce value sent for each packet. The Ack Vector option explicitly says which packets were
Ack VectorオプションでNonce Echoを含んでいて、電子証券取引ネットワークについて確かめるために、送付者は各パケットのために電子証券取引ネットワークの一回だけの値を送るテーブルを維持します。 Ack Vectorオプションは、パケットがどれであったかを明らかに言います。
Floyd, et al. Standards Track [Page 22] RFC 4342 DCCP CCID3 TFRC March 2006
フロイド、他 規格は2006年のDCCP CCID3 TFRC行進のときにRFC4342を追跡します[22ページ]。
received non-marked; the sender just adds up the nonces for those packets using a one-bit sum and compares the result to the Nonce Echo encoded in the Ack Vector's option type. Again, a misbehaving receiver has only a 50% chance of guessing an Ack Vector's correct Nonce Echo. Alternatively, an Ack Vector's ECN Nonce Echo may also be calculated from a table of ECN nonce sums, rather than from ECN nonces. If the Ack Vector contains many long runs of non-marked, non-dropped packets, the nonce sum-based calculation will probably be faster than a straightforward nonce-based calculation.
非著しい状態で、受信します。 送付者は、それらのパケットのために1ビットの合計を使用することで一回だけをただ合計して、Ack Vectorのオプションタイプでコード化されたNonce Echoと結果を比較します。 一方、ふらちな事する受信機には、Ack Vectorの正しいNonce Echoを推測するという50%の確率しかありません。 あるいはまた、また、Ack Vectorの電子証券取引ネットワークNonce Echoは電子証券取引ネットワーク一回だけからというよりむしろ電子証券取引ネットワークの一回だけの合計のテーブルから計算されるかもしれません。 Ack Vectorが非著しくて、非低下しているパケットの多くのロングランを含んでいると、一回だけの合計ベースの計算はたぶん簡単な一回だけベースの計算よりさらに速くなるでしょう。
Note that Ack Vector's ECN Nonce Echo is measured over both data packets and non-data packets, while the Loss Intervals option reports ECN Nonce Echoes for data packets only. Thus, different nonce sum tables are required to verify the two options.
Ack Vectorの電子証券取引ネットワークNonce Echoがデータ・パケットと非データ・パケットの両方の上で測定されることに注意してください、Loss Intervalsオプションはデータ・パケットだけのために電子証券取引ネットワークNonceエコーズを報告しますが。 したがって、異なった一回だけの合計テーブルが、2つのオプションについて確かめるのに必要です。
9.2. Verifying the Reported Loss Intervals and Loss Event Rate
9.2. 報告された損失間隔と損失イベント率について確かめます。
Besides probabilistically verifying the ECN Nonce Echoes reported by the receiver, the sender may also verify the loss intervals and any loss event rate reported by the receiver, if it so desires. Specifically, the Loss Intervals option explicitly reports the size of each loss interval as seen by the receiver; the sender can verify that the receiver is not falsely combining two loss events into one reported Loss Interval by using saved window counter information. The sender can also compare any Loss Event Rate option to the loss event rate it calculates using the Loss Intervals option.
さらにprobabilisticallyに電子証券取引ネットワークNonceエコーズについて確かめるのは受信機で報告しました、そして、また、送付者は損失間隔について確かめるかもしれません、そして、どんな損失イベント率も受信機で報告しました、そう望んでいるなら。 明確に、Loss Intervalsオプションは受信機によって見られるように明らかにそれぞれの損失間隔のサイズを報告します。 送付者は、受信機が救われた窓のカウンタ情報を使用することによって2回の損失出来事を間違って1報告されたLoss Intervalに結合していないことを確かめることができます。 また、送付者は、Loss Intervalsオプションを使用することでそれが計算する損失イベント率にどんなLoss Event Rateオプションもたとえることができます。
Note that in some cases the loss event rate calculated by the sender could differ from an explicit Loss Event Rate option sent by the receiver. In particular, when a number of successive packets are dropped, the receiver does not know the sending times for these packets and interprets these losses as a single loss event. In contrast, if the sender has saved the sending times or window counter information for these packets, then the sender can determine if these losses constitute a single loss event or several successive loss events. Thus, with its knowledge of the sending times of dropped packets, the sender is able to make a more accurate calculation of the loss event rate. These kinds of differences SHOULD NOT be misinterpreted as attempted receiver misbehavior.
いくつかの場合、送付者によって計算された損失イベント率が受信機によって送られた明白なLoss Event Rateオプションと異なるかもしれないことに注意してください。多くの連続したパケットが落とされるとき、受信機は、特に、これらのパケットで送付回を知らないで、単一の損失出来事としてこれらの損失を解釈します。 対照的に、送付者がこれらのパケットのための送付回か窓のカウンタ情報を保存したなら、送付者は、これらの損失が単一の損失出来事か数回の連続した損失出来事を構成するかどうかと決心できます。 したがって、低下しているパケットの送付倍に関する知識で、送付者は損失イベント率の、より正確な計算をすることができます。 これらの種類、違いのSHOULD NOTでは、試みられた受信機不正行為として誤解されてください。
10. Implementation Issues
10. 導入問題
10.1. Timestamp Usage
10.1. タイムスタンプ用法
CCID 3 data packets need not carry Timestamp options. The sender can store the times at which recent packets were sent; the Acknowledgement Number and Elapsed Time option contained on each required acknowledgement then provide sufficient information to
パケットが必要とするCCID3データはTimestampオプションを運びません。 送付者は最近のパケットが送られた回を格納できます。 オプションがそれぞれに含んだAcknowledgement NumberとElapsed Timeはその時が十分な情報を提供する承認を必要としました。
Floyd, et al. Standards Track [Page 23] RFC 4342 DCCP CCID3 TFRC March 2006
フロイド、他 規格は2006年のDCCP CCID3 TFRC行進のときにRFC4342を追跡します[23ページ]。
compute the round trip time. Alternatively, the sender MAY include Timestamp options on some of its data packets. The receiver will respond with Timestamp Echo options including Elapsed Times, allowing the sender to calculate round-trip times without storing sent packets' timestamps at all.
周遊旅行時間を計算してください。 あるいはまた、送付者はいくつかのデータ・パケットにおけるTimestampオプションを入れるかもしれません。 Timestamp EchoオプションがElapsedタイムズを含んでいて、受信機は応じるでしょう、送付者が全く送られたパケットのタイムスタンプを格納しないで往復の回について計算するのを許容して。
10.2. Determining Loss Events at the Receiver
10.2. 受信機で損失出来事を決定します。
The window counter is used by the receiver to determine whether multiple lost packets belong to the same loss event. The sender increases the window counter by one every quarter round-trip time. This section describes in detail the procedure for using the window counter to determine when two lost packets belong to the same loss event.
ウィンドウカウンタは受信機によって使用されて、複数の無くなっているパケットが同じ損失出来事に属すかどうか決定します。 送付者は4分の1の往復の毎回1のウィンドウカウンタを増加させます。 このセクションは詳細に2つの無くなっているパケットがいつ同じ損失出来事に属すかを決定するのにウィンドウカウンタを使用するための手順について説明します。
[RFC3448], Section 3.2.1 specifies that each data packet contains a timestamp and gives as an alternative implementation a "timestamp" that is incremented every quarter of an RTT, as is the window counter in CCID 3. However, [RFC3448], Section 5.2 on "Translation from Loss History to Loss Events" is written in terms of timestamps, not in terms of window counters. In this section, we give a procedure for the translation from loss history to loss events that is explicitly in terms of window counters.
[RFC3448]、セクション3.2.1は、RTTについて各データ・パケットがタイムスタンプを含むと指定して、代替の実現としてあらゆる四半期増加される「タイムスタンプ」を与えます、CCID3のウィンドウカウンタのように。 しかしながら、[RFC3448]、「損失歴史から損失出来事までの翻訳」でのセクション5.2はウィンドウカウンタで書かれているのではなく、タイムスタンプで書かれています。 このセクションでは、私たちはウィンドウカウンタに関して明らかに損失歴史から損失出来事までの翻訳のための手順を与えます。
To determine whether two lost packets with sequence numbers X and Y belong to different loss events, the receiver proceeds as follows. Assume Y > X in circular sequence space.
2が負けたかどうか決定するために、一連番号XとYがあるパケットは異なった損失出来事(以下の受信機売り上げ)に属します。 円形の系列スペースでYが>Xであると仮定してください。
o Let X_prev be the greatest valid sequence number received with
X_prev < X.
o X_prevがX_prev<Xで受け取られた最大級の有効な一連番号であることをさせてください。
o Let Y_prev be the greatest valid sequence number received with
Y_prev < Y.
o Y_prevがY_prev<Yで受け取られた最大級の有効な一連番号であることをさせてください。
o Given a sequence number N, let C(N) be the window counter value
associated with that packet.
o 一連番号Nを考えて、C(N)がそのパケットに関連している窓の対価であることをさせてください。
o Packets X and Y belong to different loss events if there exists a
packet with sequence number S so that X_prev < S <= Y_prev, and
the distance from C(X_prev) to C(S) is greater than 4. (The
distance is the number D so that C(X_prev) + D = C(S) (mod
WCTRMAX), where WCTRMAX is the maximum value for the window
counter -- in our case, 16.)
o 一連番号Sがあるパケットが存在しているならパケットXとYが異なった損失出来事に属すので、X_prev<S<はY_prevと等しいです、そして、C(X_prev)からC(S)までの距離は4以上です。 (距離が数Dであるので、C(X_prev)+DはC(S)(モッズWCTRMAX)(WCTRMAXは私たちのケース、16におけるウィンドウカウンタへの最大値である)と等しいです。)
That is, the receiver only considers losses X and Y as separate
loss events if there exists some packet S received between X and
Y, with the distance from C(X_prev) to C(S) greater than 4. This
complex calculation is necessary in order to handle the case where
XとYの間に受け取られたあるパケットSが存在している場合にだけ、すなわち、受信機は、損失XとYが別々の損失出来事であるとみなします、C(X_prev)からC(S)より多くの4までの距離で。 この複雑な計算がケースを扱うのに必要である、どこ
Floyd, et al. Standards Track [Page 24] RFC 4342 DCCP CCID3 TFRC March 2006
フロイド、他 規格は2006年のDCCP CCID3 TFRC行進のときにRFC4342を追跡します[24ページ]。
window counter space wrapped completely between X and Y. When
that space does not wrap, the receiver can simply check whether
the distance from C(X_prev) to C(Y_prev) is greater than 4; if so,
then X and Y belong to separate loss events.
窓のカウンタのスペースは完全XとY.の間でスペースが包装しないWhenを包装しました、と受信機はC(X_prev)からC(Y_prev)までの距離が4以上であるか否かに関係なく、単にチェックできます。 そうだとすれば、そして、XとYは別々の損失出来事に属します。
Window counters can help the receiver disambiguate multiple losses after a sudden decrease in the actual round-trip time. When the sender receives an acknowledgement acknowledging a data packet with window counter i, the sender increases its window counter, if necessary, so that subsequent data packets are sent with window counter values of at least i+4. This can help minimize errors where the receiver incorrectly interprets multiple loss events as a single loss event.
ウィンドウカウンタは、受信機が急減の後に実際の往復の時間で複数の損失のあいまいさを除くのを助けることができます。 送付者がウィンドウカウンタiがあるデータ・パケットを承認しながら承認を受けるとき、送付者が必要ならウィンドウカウンタを増加させるので、少なくともi+4の窓の対価と共に順次データパケットを送ります。 これは、受信機が単一の損失出来事として不当に複数の損失出来事を解釈するところで誤りを最小にするのを助けることができます。
We note that if all of the packets between X and Y are lost in the network, then X_prev and Y_prev are equal, and the series of consecutive losses is treated by the receiver as a single loss event. However, the sender will receive no DCCP-Ack packets during a period of consecutive losses, and the sender will reduce its sending rate accordingly.
私たちは、XとYの間のパケットのすべてがネットワークで失われているならX_prevとY_prevが等しく、連敗のシリーズが単一の損失出来事として受信機によって扱われることに注意します。 しかしながら、送付者は連敗の期間、DCCP-Ackパケットを全く受けないでしょう、そして、送付者は送付レートをそれに従って、低下させるでしょう。
As an alternative to the window counter, the sender could have sent its estimate of the round-trip time to the receiver directly in a round-trip time option; the receiver would use the sender's round- trip time estimate to infer when multiple lost or marked packets belong in the same loss event. In some respects, a round-trip time option would give a more precise encoding of the sender's round-trip time estimate than does the window counter. However, the window counter conveys information about the relative *sending* times for packets, while the receiver could only use the round-trip time option to distinguish between the relative *receive* times (in the absence of timestamps). That is, the window counter will give more robust performance when there is a large variation in delay for packets sent within a window of data. Slightly more speculatively, a round-trip time option might possibly be used more easily by middleboxes attempting to verify that a flow used conforming end-to-end congestion control.
ウィンドウカウンタに代わる手段として、送付者は直接往復の時間オプションで往復の現代の見積りを受信機に送ったかもしれません。 同じ損失出来事には複数の無くなっているか著しいパケットがあると、受信機は推論する送付者の丸い旅行時間見積りを使用するでしょう。 ある点で、往復の時間オプションは送付者の往復の時間見積りのウィンドウカウンタより正確なコード化を与えるでしょう。 *しかしながら、ウィンドウカウンタはパケットのために*回を送りながら、親類*に関して情報を伝達して、受信機が親類を見分けるのに往復の時間オプションを使用しているだけであるかもしれない間、*回(タイムスタンプがないとき)を受けてください。 データの窓の中で送られたパケットのための遅れの大きい変化があるとき、すなわち、ウィンドウカウンタは、より体力を要している性能を与えるでしょう。 わずかに投機的に、往復の時間オプションはことによると終わりから終わりへの混雑を従わせながら使用される流れが制御されることを確かめるのを試みるmiddleboxesによって、より容易に使用されるかもしれません。
10.3. Sending Feedback Packets
10.3. 送付フィードバックパケット
[RFC3448], Sections 6.1 and 6.2 specify that the TFRC receiver must send a feedback packet when a newly calculated loss event rate p is greater than its previous value. CCID 3 follows this rule.
[RFC3448]、セクション6.1と6.2は新たに計算された損失イベント率pが前の値より大きいときに、TFRC受信機がフィードバックパケットを送らなければならないと指定します。 CCID3はこの規則に従います。
In addition, [RFC3448], Section 6.2, specifies that the receiver use a feedback timer to decide when to send additional feedback packets. If the feedback timer expires and data packets have been received since the previous feedback was sent, then the receiver sends a
さらに、[RFC3448](セクション6.2)は、受信機がいつ追加フィードバックパケットを送るかを決めるのにフィードバックタイマを使用すると指定します。 フィードバックタイマが期限が切れて、前のフィードバックを送って以来データ・パケットを受け取っているなら、受信機はaを送ります。
Floyd, et al. Standards Track [Page 25] RFC 4342 DCCP CCID3 TFRC March 2006
フロイド、他 規格は2006年のDCCP CCID3 TFRC行進のときにRFC4342を追跡します[25ページ]。
feedback packet. When the feedback timer expires, the receiver resets the timer to expire after R_m seconds, where R_m is the most recent estimate of the round-trip time received from the sender. CCID 3 receivers, however, generally use window counter values instead of a feedback timer to determine when to send additional feedback packets. This section describes how.
フィードバックパケット。 フィードバックタイマが期限が切れると、受信機はR_m後に秒を吐き出すためにタイマをリセットします、R_mが送付者からの往復の受付時刻の最新の見積りであるところで。 しかしながら、一般に、CCID3受信機は、いつ追加フィードバックパケットを送るかを決定するのにフィードバックタイマの代わりに窓の対価を使用します。 このセクションはその方法を説明します。
Whenever the receiver sends a feedback message, the receiver sets a
local variable last_counter to the greatest received value of the
window counter since the last feedback message was sent, if any data
packets have been received since the last feedback message was sent.
If the receiver receives a data packet with a window counter value
greater than or equal to last_counter + 4, then the receiver sends a
new feedback packet. ("Greater" and "greatest" are measured in
circular window counter space.)
フィードバックメッセージを送るときはいつも、受信機は最後のフィードバックメッセージを送って以来のウィンドウカウンタの最も大きい容認された値に局所変数最終_カウンタを設定します、最後のフィードバックメッセージを送って以来何かデータ・パケットを受け取っているなら。 受信機が受信されるなら、窓の対価があるデータパケットは_カウンタ+4をより持続して、次に、受信機は新しいフィードバックパケットを送ります。 (「大」で「最もすばらしいこと」は円形の窓のカウンタのスペースで測定されます。)
This procedure ensures that when the sender is sending at a rate less than one packet per round-trip time, the receiver sends a feedback packet after each data packet. Similarly, this procedure ensures that when the sender is sending several packets per round-trip time, the receiver will send a feedback packet each time that a data packet arrives with a window counter at least four greater than the window counter when the last feedback packet was sent. Thus, the feedback timer is not necessary when the window counter is used.
この手順は、送付者がレートで往復の時間あたり1つ未満のパケットを送るとき、受信機が各データ・パケットの後にフィードバックパケットを送るのを確実にします。 同様に、この手順は、送付者がいくつかの往復の時間あたりのパケットを送るとき、受信機が最後のフィードバックパケットを送ったとき、少なくとも4のウィンドウカウンタがウィンドウカウンタより大きい状態でデータ・パケットが到着する各回をフィードバックパケットに送るのを確実にします。 ウィンドウカウンタが使用されているとき、したがって、フィードバックタイマは必要ではありません。
However, the feedback timer still could be useful in some rare cases to prevent the sender from unnecessarily halving its sending rate. In particular, one could construct scenarios where the use of the feedback timer at the receiver would prevent the unnecessary expiration of the nofeedback timer at the sender. Consider the case below, in which a feedback packet is sent when a data packet arrives with a window counter of K.
しかしながら、フィードバックタイマスチール写真は、送付者が不必要に送付レートを半分にするのを防ぐためにいくつかのまれなケースで役に立つかもしれません。 特に、1つは受信機のフィードバックタイマの使用が送付者でnofeedbackタイマの不要な満了を防ぐシナリオを構成するかもしれません。 以下の場合を考えてください。(データ・パケットがKのウィンドウカウンタと共に到着するとき、フィードバックパケットはそれで送られます)。
Window
Counters: K K+1 K+2 K+3 K+4 K+5 K+6 ... K+15 K+16 K+17 ...
| | | | | | | | | |
Data | | | | | | | | | |
Packets | | | | | | | | | |
Received: - - --- - ... - - -- - -- -- -
| | | | | |
| | | | | |
Events: 1: 2: 3: 4: 5: 6:
"A" "B" Timer "B"
sent sent received
ウィンドウカウンタ: K K+1K+2K+3K+4K+5K+6… K+15K+16K+17… | | | | | | | | | | データ| | | | | | | | | | パケット| | | | | | | | | | 受け取られている: - - --- - ... - - -- - -- -- - | | | | | | | | | | | | 出来事: 1: 2: 3: 4: 5: 6: 「B」が送った「B」タイマは受け取られていた状態で発信しました。
1: Feedback message A is sent.
2: A feedback message would have been sent if feedback
timers had been used.
1: フィードバックメッセージAを送ります。 2: フィードバックタイマを使用したなら、フィードバックメッセージを送ったでしょうに。
Floyd, et al. Standards Track [Page 26] RFC 4342 DCCP CCID3 TFRC March 2006
フロイド、他 規格は2006年のDCCP CCID3 TFRC行進のときにRFC4342を追跡します[26ページ]。
3: Feedback message B is sent.
4: Sender's nofeedback timer expires.
5: Feedback message B is received at the sender.
6: Sender's nofeedback timer would have expired if feedback
timers had been used, and the feedback message at 2 had
been sent.
3: フィードバックメッセージBを送ります。 4: 送付者のnofeedbackタイマは期限が切れます。 5: 送付者にフィードバックメッセージBを受け取ります。 6: フィードバックタイマが使用されたなら、送付者のnofeedbackタイマは期限が切れたでしょうに、そして、2時のフィードバックメッセージを送りました。
The receiver receives data after the feedback packet has been sent but has received no data packets with a window counter between K+4 and K+14. A data packet with a window counter of K+4 or larger would have triggered sending a new feedback packet, but no feedback packet is sent until time 3.
受信機は、フィードバックパケットを送った後にデータを受け取りますが、ウィンドウカウンタがK+4とK+14の間ある状態で、データ・パケットを全く受けていません。 時間3まで新しいフィードバックパケットを送りますが、どんなフィードバックパケットも送らないK+4か、より大きいことのウィンドウカウンタがあるパケットが引き金となったデータを送ります。
The TFRC protocol specifies that after a feedback packet is received, the sender sets a nofeedback timer to at least four times the round- trip time estimate. If the sender doesn't receive any feedback packets before the nofeedback timer expires, then the sender halves its sending rate. In the figure, the sender receives feedback message A (time 1) and then sets the nofeedback timer to expire roughly four round-trip times later (time 4). The sender starts sending again just before the nofeedback timer expires but doesn't receive the resulting feedback message until after its expiration, resulting in an unnecessary halving of the sending rate. If the connection had used feedback timers, the receiver would have sent a feedback message when the feedback timer expired at time 2, and the halving of the sending rate would have been avoided.
TFRCプロトコルは、フィードバックパケットが受け取られていた後に送付者が丸い旅行時間見積りの少なくとも4倍にnofeedbackタイマを設定すると指定します。 nofeedbackタイマが期限が切れる前に送付者がどんなフィードバックパケットも受けないなら、送付者は送付レートを半分にします。 図では、送付者は、フィードバックメッセージA(時間1)を受け取って、次に、後で(時間4)nofeedbackタイマに往復のおよそ4回期限が切れるように設定します。 送付者は、nofeedbackタイマが期限が切れるすぐ前に再び発信し始めますが、満了の後まで結果として起こるフィードバックメッセージを受け取りません、送付レートの不要な半分にをもたらして。 フィードバックタイマが時2に期限が切れたとき、接続がフィードバックタイマを使用したなら、受信機はフィードバックメッセージを送ったでしょうに、そして、送付レートの半分には避けられたでしょう。
For implementors who wish to implement a feedback timer for the data receiver, we suggest estimating the round-trip time from the most recent data packet, as described in Section 8.1. We note that this procedure does not work when the inter-packet sending times are greater than the RTT.
データ受信装置のためにフィードバックタイマを実行したがっている作成者に関しては、私たちは、最新のデータ・パケットから往復の時間を見積もっていることを提案します、セクション8.1で説明されるように。 私たちは、相互パケット送付回数がRTTよりすばらしいときに、この手順が働かないことに注意します。
11. Security Considerations
11. セキュリティ問題
Security considerations for DCCP have been discussed in [RFC4340], and security considerations for TFRC have been discussed in [RFC3448], Section 9. The security considerations for TFRC include the need to protect against spoofed feedback and the need to protect the congestion control mechanisms against incorrect information from the receiver.
[RFC4340]でDCCPのためのセキュリティ問題について議論しました、そして、[RFC3448](セクション9)でTFRCのためのセキュリティ問題について議論しました。 TFRCのためのセキュリティ問題はだまされたフィードバックから守る必要性と不正確な情報に対して受信機から混雑制御機構を保護する必要性を含んでいます。
In this document, we have extensively discussed the mechanisms the sender can use to verify the information sent by the receiver. When ECN is used, the receiver returns ECN Nonce information to the sender. When ECN is not used, then, as Section 9 shows, the sender could still use various techniques that might catch the receiver in
本書では、私たちは手広く送付者が受信機によって送られた情報について確かめるのに使用できるメカニズムについて議論しました。電子証券取引ネットワークが使用されているとき、受信機は電子証券取引ネットワークNonce情報を送付者に返します。 次に、セクション9が示すように電子証券取引ネットワークが使用されないとき、送付者はまだ受信機に引っかかるかもしれない様々なテクニックを使用できました。
Floyd, et al. Standards Track [Page 27] RFC 4342 DCCP CCID3 TFRC March 2006
フロイド、他 規格は2006年のDCCP CCID3 TFRC行進のときにRFC4342を追跡します[27ページ]。
an error in reporting congestion, but this is not as robust or non- intrusive as the verification provided by the ECN Nonce.
混雑を報告することにおける誤り、これだけが、電子証券取引ネットワークNonceによって提供された検証ほど、強健でもなくて、また非押しつけがましくもありません。
12. IANA Considerations
12. IANA問題
This specification defines the value 3 in the DCCP CCID namespace managed by IANA. This assignment is also mentioned in [RFC4340].
この仕様はIANAによって管理されたDCCP CCID名前空間で値3を定義します。 また、この課題は[RFC4340]で言及されます。
CCID 3 also introduces three sets of numbers whose values should be allocated by IANA; namely, CCID 3-specific Reset Codes, option types, and feature numbers. These ranges will prevent any future CCID 3- specific allocations from polluting DCCP's corresponding global namespaces; see [RFC4340], Section 10.3. However, we note that this document makes no particular allocations from the Reset Code range, except for experimental and testing use [RFC3692]. We refer to the Standards Action policy outlined in [RFC2434].
また、CCID3は値がIANAによって割り当てられるはずである3セットの数を導入します。 すなわち、CCIDの3特有のReset Codes、オプションタイプ、および特徴番号。 これらの範囲は、どんな未来にもCCID3の特定の配分がDCCPの対応するグローバルな名前空間を汚染するのを防ぐでしょう。 [RFC4340]、セクション10.3を見てください。 しかしながら、私たちは、このドキュメントがReset Code範囲からどんな特定の配分もしないことに注意します、実験的、そして、テスト使用[RFC3692]を除いて。 私たちは[RFC2434]に概説されたStandards Action方針を示します。
12.1. Reset Codes
12.1. リセットコード
Each entry in the DCCP CCID 3 Reset Code registry contains a CCID 3- 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 CCID3Reset Code登録の各エントリーはCCID3の特定の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公表を必要とします)。
12.2. Option Types
12.2. オプションタイプ
Each entry in the DCCP CCID 3 option type registry contains a CCID 3-specific option type, which is a number in the range 128-255; the name of the option, such as "Loss Intervals"; and a reference to the RFC defining the option type. The registry is initially populated using the values in Table 1, in Section 8. This document allocates option types 192-194, and option types 184-190 and 248-254 are permanently reserved for experimental and testing use. The remaining option types -- 128-183, 191, 195-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 CCID3オプションタイプ登録の各エントリーはCCIDの3特有のオプションタイプを含んでいます。(タイプは範囲128-255の数です)。 「損失間隔」などのオプションの名前。 そして、オプションタイプを定義するRFCの参照。 Table1、セクション8で値を使用することで登録は初めは、居住されます。 このドキュメントはオプションタイプ192-194を割り当てます、そして、オプションタイプは永久に、実験的、そして、テスト使用のために184-190に248-254に予約されます。 残っているオプションタイプ(128-183、191、195-247、および255)を現在予約して、Standards Action方針で割り当てるべきです。(それは、IESGレビュー、承認、および標準化過程IETF RFC公表を必要とします)。
12.3. Feature Numbers
12.3. 特徴番号
Each entry in the DCCP CCID 3 feature number registry contains a CCID 3-specific feature number, which is a number in the range 128-255; the name of the feature, such as "Send Loss Event Rate"; and a reference to the RFC defining the feature number. The registry is
DCCP CCID3特徴数の登録の各エントリーはCCIDの3特有の特徴番号を含んでいます。(それは、範囲128-255の数です)。 「損失イベント率を送ってください」などの特徴の名前。 そして、特徴番号を定義するRFCの参照。 登録はそうです。
Floyd, et al. Standards Track [Page 28] RFC 4342 DCCP CCID3 TFRC March 2006
フロイド、他 規格は2006年のDCCP CCID3 TFRC行進のときにRFC4342を追跡します[28ページ]。
initially populated using the values in Table 2, in Section 8. This document allocates feature number 192, and feature numbers 184-190 and 248-254 are permanently reserved for experimental and testing use. The remaining feature numbers -- 128-183, 191, 193-247, and 255 -- are currently reserved and should be allocated with the Standards Action policy, which requires IESG review and approval and standards-track IETF RFC publication.
初めは、Table2、セクション8で値を使用することで居住されています。 このドキュメントは特徴No.192を割り当てます、そして、特徴番号は永久に、実験的、そして、テスト使用のために184-190に248-254に予約されます。 残っている特徴番号(128-183、191、193-247、および255)を現在予約して、Standards Action方針で割り当てるべきです。(それは、IESGレビュー、承認、および標準化過程IETF RFC公表を必要とします)。
13. Thanks
13. 感謝
We thank Mark Handley for his help in defining CCID 3. We also thank Mark Allman, Aaron Falk, Ladan Gharai, Sara Karlberg, Greg Minshall, Arun Venkataramani, David Vos, Yufei Wang, Magnus Westerlund, and members of the DCCP Working Group for feedback on versions of this document.
私たちは彼の助けについてCCID3を定義する際にマーク・ハンドレーに感謝します。 また、私たちはこのドキュメントのバージョンのフィードバックについてDCCP作業部会のマーク・オールマン、アーロン・フォーク、Ladan Gharai、サラKarlberg、グレッグMinshall、アルンVenkataramani、デヴィッドVos、Yufeiワング、マグヌスWesterlund、およびメンバーに感謝します。
Floyd, et al. Standards Track [Page 29] RFC 4342 DCCP CCID3 TFRC March 2006
フロイド、他 規格は2006年のDCCP CCID3 TFRC行進のときにRFC4342を追跡します[29ページ]。
A. Appendix: Possible Future Changes to CCID 3
A。 付録: CCID3への可能な将来の変化
There are a number of cases where the behavior of TFRC as specified in [RFC3448] does not match the desires of possible users of DCCP. These include the following:
件数が[RFC3448]の指定されるとしてのTFRCの動きがDCCPの可能なユーザの願望に合っていないところにあります。 これらは以下を含んでいます:
1. The initial sending rate of at most four packets per RTT, as
specified in [RFC3390].
1. [RFC3390]で指定されるように高々1RTTあたり4つのパケットのレートを送る初期。
2. The receiver's sending of an acknowledgement for every data packet
received, when the receiver receives at a rate less than one
packet per round-trip time.
2. 受信機のあらゆるデータ・パケットのための承認の発信は受信されました、受信機がレートで往復の時間あたり1つ未満のパケットを受けるとき。
3. The sender's limitation of at most doubling the sending rate from
one round-trip time to the next (or, more specifically, of
limiting the sending rate to at most twice the reported receive
rate over the previous round-trip time).
3. 送付者の送付レートを高々往復の1回から次の回まで倍にする(前の往復の時間、より特に送付レートを高々報告の2倍に制限するのにおいて、レートを受け取ってください)制限。
4. The limitation of halving the allowed sending rate after an idle
period of four round-trip times (possibly down to the initial
sending rate of two to four packets per round-trip time).
4. (ことによると往復の時間あたり2〜4つのパケットの初期の送付レート)の往復の4倍の活動していない期間の後に許容送付レートを半分にする制限。
5. The response function used in [RFC3448], Section 3.1, which does
not closely match the behavior of TCP in environments with high
packet drop rates [RFC3714].
5. [RFC3448]、密接に高いパケット低下率[RFC3714]に環境における、TCPの動きに合っていないセクション3.1で使用されるレスポンス関数。
One suggestion for higher initial sending rates is an initial sending rate of up to eight small packets per RTT, when the total packet size, including headers, is at most 4380 bytes. Because the packets would be rate-paced out over a round-trip time, instead of sent back-to-back as they would be in TCP, an initial sending rate of eight small packets per RTT with TFRC-based congestion control would be considerably milder than the impact of an initial window of eight small packets sent back-to-back in TCP. As Section 5.1 describes, the initial sending rate also serves as a lower bound for reductions of the allowed sending rate during an idle period.
より高い初期の送付レートのための1つの提案が1RTTあたり最大8つの小型小包の初期の送付レートです、ヘッダーを含む総パケットサイズが高々4380バイトであるときに。 それらがTCPで歩調を合わせられるようにパケットは送りにされるの代わりに往復の時間の外でレートによって背中合わせの状態で歩調を合わせられるでしょう、したがって、TFRCベースの輻輳制御があるRTTあたり8つの小型小包の初期の送付レートが8つの小型小包の初期の窓の衝撃がTCPで背中合わせの状態で発信したよりかなり温和でしょう。 また、セクション5.1が説明するように、初期の送付レートは活動していない期間、許容送付レートの減少のための下界として機能します。
We note that with CCID 3, the sender is in slow-start in the beginning and responds promptly to the report of a packet loss or mark. However, in the absence of feedback from the receiver, the sender can maintain its old sending rate for up to four round-trip times. One possibility would be that for an initial window of eight small packets, the initial nofeedback timer would be set to two round-trip times instead of four, so that the sending rate would be reduced after two round-trips without feedback.
私たちは、送付者がCCID3と共に、初めに、遅れた出発にいて、パケット損失かマークのレポートに即座に応じることに注意します。 しかしながら、受信機からのフィードバックがないとき、送付者は往復の4回まで古い送付レートを維持できます。 1つの可能性は8つの小型小包の初期の窓において、初期のnofeedbackタイマが4の代わりに往復の2回に設定されるだろうということでしょう、送付レートが2つの周遊旅行の後にフィードバックなしで低下するように。
Floyd, et al. Standards Track [Page 30] RFC 4342 DCCP CCID3 TFRC March 2006
フロイド、他 規格は2006年のDCCP CCID3 TFRC行進のときにRFC4342を追跡します[30ページ]。
Research and engineering will be needed to investigate the pros and cons of modifying these limitations in order to allow larger initial sending rates, to send fewer acknowledgements when the data sending rate is low, to allow more abrupt changes in the sending rate, or to allow a higher sending rate after an idle period.
研究と工学が、より大きい初期の送付レートを許容するようにこれらの制限を変更する賛否両論を調査するか、データ送付速度が低いときに、より少ない承認を送るか、送付レートにおける、より突然の変化を許容するか、または活動していない期間の後により高い送付レートを許容するのに必要でしょう。
Normative References
引用規格
[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月。
[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月。
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer,
"TCP Friendly Rate Control (TFRC): Protocol
Specification", RFC 3448, January 2003.
[RFC3448] ハンドレー、M.、フロイド、S.、Padhye、J.、およびJ.ウィトマー、「TCPの好意的なレートは(TFRC)を制御します」。 「プロトコル仕様」、RFC3448、2003年1月。
[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
有益な参照
[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月。
Floyd, et al. Standards Track [Page 31] RFC 4342 DCCP CCID3 TFRC March 2006
フロイド、他 規格は2006年のDCCP CCID3 TFRC行進のときにRFC4342を追跡します[31ページ]。
[RFC3714] Floyd, S. and J. Kempf, "IAB Concerns Regarding
Congestion Control for Voice Traffic in the Internet",
RFC 3714, March 2004.
[RFC3714] フロイド、S.、およびJ.ケンフ、「混雑に関するIAB心配はインターネットの音声トラヒックに制御します」、RFC3714、2004年3月。
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram
Congestion Control Protocol (DCCP) Congestion Control
ID 2: TCP-like Congestion Control", RFC 4341, March
2006.
[RFC4341] フロイド、S.、およびE.コーラーは「データグラム混雑制御プロトコル(DCCP)輻輳制御ID2のために以下の輪郭を描きます」。 「TCPのような輻輳制御」、RFC4341、2006年3月。
[V03] Arun Venkataramani, August 2003. Citation for
acknowledgement purposes only.
2003年8月の[V03]アルンVenkataramani。 承認目的だけのための引用。
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
Jitendra Padhye Microsoft Research One Microsoft Way Redmond, WA 98052 USA
Jitendra Padhyeマイクロソフトは1つのマイクロソフト方法でワシントン98052レッドモンド(米国)について研究します。
EMail: padhye@microsoft.com
メール: padhye@microsoft.com
Floyd, et al. Standards Track [Page 32] RFC 4342 DCCP CCID3 TFRC March 2006
フロイド、他 規格は2006年のDCCP CCID3 TFRC行進のときにRFC4342を追跡します[32ページ]。
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, et al. Standards Track [Page 33]
フロイド、他 標準化過程[33ページ]
一覧
スポンサーリンク
