Network Working Group S. Floyd
Request for Comments: 4782 M. Allman
Category: Experimental ICIR
A. Jain
F5 Networks
P. Sarolahti
Nokia Research Center
January 2007
Quick-Start for TCP and IP
Status of This Memo
このメモのステータス
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
This document specifies an optional Quick-Start mechanism for transport protocols, in cooperation with routers, to determine an allowed sending rate at the start and, at times, in the middle of a data transfer (e.g., after an idle period). While Quick-Start is designed to be used by a range of transport protocols, in this document we only specify its use with TCP. Quick-Start is designed to allow connections to use higher sending rates when there is significant unused bandwidth along the path, and the sender and all of the routers along the path approve the Quick-Start Request.
この文書では、開始時と、時間で、（アイドル期間の後に、例えば、）データ転送の途中で許容送信レートを決定するために、ルータと協働して、トランスポートプロトコルのための任意のクイックスタート機構を指定します。クイックスタートは、トランスポートプロトコルの範囲で使用するように設計されていますが、この文書では、我々は唯一のTCPでの使用を指定します。クイックスタートは、パスに沿った重要な未使用の帯域幅がある場合には接続が高い送信レートを使用できるように設計されており、送信者とパスに沿ったルーターの全てはクイックスタートリクエストを承認します。
This document describes many paths where Quick-Start Requests would not be approved. These paths include all paths containing routers, IP tunnels, MPLS paths, and the like that do not support Quick-Start. These paths also include paths with routers or middleboxes that drop packets containing IP options. Quick-Start Requests could be difficult to approve over paths that include multi-access layer-two networks. This document also describes environments where the Quick-Start process could fail with false positives, with the sender incorrectly assuming that the Quick-Start Request had been approved by all of the routers along the path. As a result of these concerns, and as a result of the difficulties and seeming absence of motivation for routers, such as core routers to deploy Quick-Start, Quick-Start is being proposed as a mechanism that could be of use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet.
この文書では、クイックスタート要求が承認されない多くのパスを記述します。これらのパスは、クイックスタートをサポートしていないすべてのルータを含むパス、IPトンネル、MPLSパス、などが挙げられます。これらのパスは、IPオプションを含むパケットをドロップするルーターやミドルボックスとのパスが含まれています。クイックスタートの要求は、マルチアクセスレイヤ2ネットワークを含む経路を介して承認することは困難である可能性があります。また、このドキュメントでは、クイック・スタート・プロセスは、送信者が誤ってクイックスタート要求は、パスに沿ってすべてのルータによって承認されていたと仮定して、偽陽性と失敗する可能性があり環境について説明します。これらの懸念の結果として、および問題の結果として、およびクイックスタートを展開するようなコアルータとしてルータのためのモチベーションの欠如を見かけ上、クイックスタートは、制御された環境において有用であり得るメカニズムとして提案されていますそして、ではないグローバルなインターネットにおけるユビキタス展開するためのものか、適切であろうメカニズムとして。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Conventions and Terminology ................................5
2. Assumptions and General Principles ..............................6
2.1. Overview of Quick-Start ....................................7
3. The Quick-Start Option in IP ...................................10
3.1. The Quick-Start Option for IPv4 ...........................10
3.2. The Quick-Start Option for IPv6 ...........................13
3.3. Processing the Quick-Start Request at Routers .............14
3.3.1. Processing the Report of Approved Rate .............15
3.4. The QS Nonce ..............................................16
4. The Quick-Start Mechanisms in TCP ..............................18
4.1. Sending the Quick-Start Request ...........................19
4.2. The Quick-Start Response Option in the TCP header .........20
4.3. TCP: Sending the Quick-Start Response .....................21
4.4. TCP: Receiving and Using the Quick-Start Response Packet ..22
4.5. TCP: Controlling Acknowledgement Traffic on the
Reverse Path ..............................................24
4.6. TCP: Responding to a Loss of a Quick-Start Packet .........26
4.7. TCP: A Quick-Start Request for a Larger Initial Window ....26
4.7.1. Interactions with Path MTU Discovery ...............26
4.7.2. Quick-Start Request Packets that are
Discarded by Routers or Middleboxes ................27
4.8. TCP: A Quick-Start Request in the Middle of a Connection ..28
4.9. An Example Quick-Start Scenario with TCP ..................29
5. Quick-Start and IPsec AH .......................................30
6. Quick-Start in IP Tunnels and MPLS .............................31
6.1. Simple Tunnels that Are Compatible with Quick-Start .......33
6.1.1. Simple Tunnels that Are Aware of Quick-Start .......33
6.2. Simple Tunnels that Are Not Compatible with Quick-Start ...34
6.3. Tunnels That Support Quick-Start ..........................35
6.4. Quick-Start and MPLS ......................................35
7. The Quick-Start Mechanism in Other Transport Protocols .........36
8. Using Quick-Start ..............................................37
8.1. Determining the Rate to Request ...........................37
8.2. Deciding the Permitted Rate Request at a Router ...........37
9. Evaluation of Quick-Start ......................................38
9.1. Benefits of Quick-Start ...................................38
9.2. Costs of Quick-Start ......................................39
9.3. Quick-Start with QoS-Enabled Traffic ......................41
9.4. Protection against Misbehaving Nodes ......................41
9.4.1. Misbehaving Senders ................................41
9.4.2. Receivers Lying about Whether the Request
was Approved .......................................43
9.4.3. Receivers Lying about the Approved Rate ............43
9.4.4. Collusion between Misbehaving Routers ..............44
9.5. Misbehaving Middleboxes and the IP TTL ....................46
9.6. Attacks on Quick-Start ....................................46
9.7. Simulations with Quick-Start ..............................47
10. Implementation and Deployment Issues ..........................47
10.1. Implementation Issues for Sending Quick-Start Requests ...47
10.2. Implementation Issues for Processing Quick-Start
Requests .................................................48
10.3. Possible Deployment Scenarios ............................48
10.4. A Comparison with the Deployment Problems of ECN .........50
11. Security Considerations .......................................50
12. IANA Considerations ...........................................52
12.1. IP Option ................................................52
12.2. TCP Option ...............................................52
13. Conclusions ...................................................53
14. Acknowledgements ..............................................53
Appendix A. Related Work ..........................................54
A.1. Fast Start-Ups without Explicit Information from Routers ..54
A.2. Optimistic Sending without Explicit Information from
Routers ...................................................56
A.3. Fast Start-Ups with Other Information from Routers ........56
A.4. Fast Start-Ups with More Fine-Grained Feedback from
Routers ...................................................57
A.5. Fast Start-ups with Lower-Than-Best-Effort Service ........58
Appendix B. Design Decisions ......................................59
B.1. Alternate Mechanisms for the Quick-Start Request:
ICMP and RSVP .............................................59
B.1.1. ICMP ...............................................59
B.1.2. RSVP ...............................................60
B.2. Alternate Encoding Functions ..............................61
B.3. The Quick-Start Request: Packets or Bytes? ................63
B.4. Quick-Start Semantics: Total Rate or Additional Rate? .....64
B.5. Alternate Responses to the Loss of a Quick-Start Packet ...65
B.6. Why Not Include More Functionality? .......................66
B.7. Alternate Implementations for a Quick-Start Nonce .........69
B.7.1. An Alternate Proposal for the Quick-Start Nonce ....69
B.7.2. The Earlier Request-Approved Quick-Start Nonce .....69
Appendix C. Quick-Start with DCCP .................................70
Appendix D. Possible Router Algorithm .............................72
Appendix E. Possible Additional Uses for the Quick-Start ..........74
Normative References ..............................................75
Informative References ............................................75
Each connection begins with a question: "What is the appropriate sending rate for the current network path?" The question is not answered explicitly, but each TCP connection determines the sending rate by probing the network path and altering the congestion window (cwnd) based on perceived congestion. Each TCP connection starts with a pre-configured initial congestion window (ICW). Currently, TCP allows an initial window of between one and four segments of maximum segment size (MSS) ([RFC2581], [RFC3390]). The TCP connection then probes the network for available bandwidth using the slow-start procedure ([Jac88], [RFC2581]), doubling cwnd during each congestion-free round-trip time (RTT).
各接続は質問から始まる：「現在のネットワーク・パスのための適切な送信レートは何ですか？」質問は、明示的に答えていないが、各TCPコネクションは、ネットワークパスを探査し、認知輻輳に基づいて輻輳ウィンドウ（CWND）を変更することによって、送信速度を決定します。各TCPコネクションは、あらかじめ設定された初期輻輳ウィンドウ（ICW）で始まります。現在、TCP最大セグメントサイズ（MSS）の1〜4つのセグメント（[RFC2581]、[RFC3390]）の初期ウィンドウを可能にします。 TCP接続が次にスロースタート手順を使用して、利用可能な帯域幅のネットワークをプローブ（[Jac88]、[RFC2581]）、各渋滞フリーラウンドトリップ時間（RTT）の間CWNDを倍加。
The slow-start algorithm can be time-consuming --- especially over
networks with large bandwidth or long delays. It may take a number
of RTTs in slow-start before the TCP connection begins to fully use
the available bandwidth of the network. For instance, it takes
log_2(N) - 2 round-trip times to build cwnd up to N segments,
assuming an initial congestion window of 4 segments. This time in
slow-start is not a problem for large file transfers, where the
slow-start stage is only a fraction of the total transfer time.
However, in the case of moderate-sized transfers, the connection
might carry out its entire transfer in the slow-start phase, taking
many round-trip times, where one or two RTTs might have been
sufficient when using the currently available bandwidth along the
path.
A fair amount of work has already been done to address the issue of choosing the initial congestion window for TCP, with RFC 3390 allowing an initial window of up to four segments based on the MSS used by the connection [RFC3390]. Our underlying premise is that explicit feedback from all the routers along the path would be required, in the current architecture, for best-effort connections to use initial windows significantly larger than those allowed by [RFC3390], in the absence of other information about the path.
仕事のかなりの量は、すでに接続[RFC3390]で使用されるMSSに基づいて、最大4つのセグメントの初期ウィンドウを可能RFC 3390で、TCPの初期輻輳ウィンドウを選択する問題に対処するために行われました。私たちの基本的な前提は、パスに沿った全てのルータからの明示的なフィードバックがに関する他の情報が存在しない場合に、[RFC3390]で許可されたものより有意に大きい初期ウィンドウを使用するためのベストエフォート型の接続のために、現在のアーキテクチャでは、必要とされるだろうということです道。
In using Quick-Start, a TCP host (say, host A) would indicate its desired sending rate in bytes per second, using a Quick-Start Option in the IP header of a TCP packet. Each router along the path could, in turn, either approve the requested rate, reduce the requested rate, or indicate that the Quick-Start Request is not approved. (We note that the `routers' referred to in this document also include the IP-layer processing of the Quick-Start Request at the sender.) In approving a Quick-Start Request, a router does not give preferential treatment to subsequent packets from that connection; the router is only asserting that it is currently underutilized and believes there is sufficient available bandwidth to accommodate the sender's requested rate. The Quick-Start mechanism can determine if there are routers along the path that do not understand the Quick-Start Option, or have not agreed to the Quick-Start rate request. TCP host B communicates the final rate request to TCP host A in a transport-level Quick-Start Response in an answering TCP packet.
クイックスタートを使用して、TCPホスト（例えば、ホストA）は、TCPパケットのIPヘッダ内のクイックスタート・オプションを使用して、秒あたりのバイト数でその所望の送信速度を示すであろう。パスに沿った各ルータは、今度は、要求された割合を承認要求率を低下させる、またはクイックスタート要求が承認されていないことを示している可能性がありどちらか。 （私たちは、この文書で言及 `ルータはも、送信側のクイックスタート要求のIPレイヤの処理が含まれることに注意してください。）クイックスタートリクエストを承認するには、ルータはから後続のパケットに優遇措置を与えるものではありませんその接続;ルータは、それが現在活用されていないと、送信者の要求率を収容するのに十分な利用可能な帯域幅があると考えていることを主張しています。クイック・スタート・オプションを理解していない、またはクイックスタートレート要求に同意していないパスに沿ったルータが存在する場合はクイックスタートメカニズムを決定することができます。 TCPホストBが応答TCPパケット内のトランスポート・レベルクイックスタート応答におけるTCPホストAへの最終的なレート要求を伝えます。
If the Quick-Start Request is approved by all routers along the path, then the TCP host can send at up to the approved rate for a window of data. Subsequent transmissions will be governed by the default TCP congestion control mechanisms of that connection. If the Quick-Start Request is not approved, then the sender would use the default congestion control mechanisms.
クイックスタート要求がパスに沿った全てのルータによって承認されている場合、TCPホストは、データのウィンドウのために承認されたレートまでで送信することができます。後続の送信は、その接続のデフォルトのTCPの輻輳制御機構によって支配されます。クイックスタート要求が承認されない場合、送信者は、デフォルトの輻輳制御メカニズムを使用します。
Quick-Start would not be the first mechanism for explicit communication from routers to transport protocols about sending rates. Explicit Congestion Notification (ECN) gives explicit congestion control feedback from routers to transport protocols, based on the router detecting congestion before buffer overflow [RFC3168]. In contrast, routers would not use Quick-Start to give congestion information, but instead would use Quick-Start as an optional mechanism to give permission to transport protocols to use higher sending rates, based on the ability of all the routers along the path to determine if their respective output links are significantly underutilized.
クイックスタートは、金利送信についてのプロトコルを輸送するためのルータからの明示的な通信のための最初のメカニズムではないでしょう。明示的輻輳通知（ECN）は、バッファオーバーフロー[RFC3168]の前に輻輳を検出するルータに基づいて、プロトコルを輸送するルータからの明示的な輻輳制御フィードバックを与えます。これとは対照的に、ルータは、渋滞情報を提供するクイックスタートを使用することはありませんが、その代わりにパスに沿った全てのルータの能力に基づいて、高い送信レートを使用するプロトコルを輸送する許可を与えるために、オプションのメカニズムとして、クイックスタートを使用しますそれぞれの出力リンクが大幅に十分に活用されているかどうかを判断。
Section 2 gives an overview of Quick-Start. The formal specifications for Quick-Start are contained in Sections 3, 4, 6.1.1, and 6.3. In particular, Quick-Start is specified for IPv4 and for IPv6 in Section 3, and is specified for TCP in Section 4. Section 6 consists mostly of a non-normative discussion of interactions of Quick-Start with IP tunnels and MPLS; however, Section 6.1.1 and 6.3 specify behavior for IP tunnels that are aware of Quick-Start.
第2節では、クイックスタートの概要を説明します。クイックスタートのための正式な仕様は、セクション3、4、6.1.1、および6.3に含まれています。具体的には、クイックスタートは、第3節でのIPv4およびIPv6のために指定され、セクションにTCPのために指定されている4セクション6は、IPトンネルとMPLSとクイックスタートの相互作用の非規範的な議論の大部分から成り、しかし、セクション6.1.1と6.3は、クイックスタートを認識しているIPトンネルの動作を指定します。
The rest of the document is non-normative, as follows. Section 5 shows that Quick-Start is compatible with IPsec AH (Authentication Header). Section 7 gives a non-normative set of guidelines for specifying Quick-Start in other transport protocols, and Section 8 discusses using Quick-Start in transport end-nodes and routers. Section 9 gives an evaluation of the costs and benefits of Quick-Start, and Section 10 discusses implementation and deployment issues. The appendices discuss related work, Quick-Start design decisions, and possible router algorithms.
次のように文書の残りの部分は、非規範的です。セクション5は、クイックスタートがIPSec AH（認証ヘッダ）と互換性があることを示しています。第7節は、トランスポートエンドノードとルータでクイックスタートを使用した非標準他のトランスポートプロトコルにクイックスタートを指定するための一連のガイドライン、および第8節について議論を与えます。第9章は、クイックスタートのコストとベネフィットの評価を与え、そして第10節は、実装と展開の問題について説明します。付録には、関連する作品、クイックスタートの設計上の決定、および可能なルータアルゴリズムを議論します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
This section describes the assumptions and general principles behind the design of the Quick-Start mechanism.
このセクションでは、クイック・スタート・メカニズムの設計の背後にある仮定し、一般的な原則を説明しています。
Assumptions:
仮定：
* The data transfer in the two directions of a connection traverses different queues, and possibly even different routers. Thus, any mechanism for determining the allowed sending rate would have to be used independently for each direction.
*接続の2つの方向のデータ転送は、異なるキュー、およびおそらくは異なるルータを横断します。したがって、許容送信レートを決定するための任意の機構は、各方向に対して独立して使用しなければなりません。
* The path between the two endpoints is relatively stable, such that the path used by the Quick-Start Request is generally the same path used by the Quick-Start packets one round-trip time later. [ZDPS01] shows this assumption should be generally valid. However, [RFC3819] discusses a range of Bandwidth on Demand subnets that could cause the characteristics of the path to change over time.
* 2つのエンドポイント間のパスは、クイックスタート要求によって使用されるパスは、一般に、1つのラウンドトリップ時間後クイックスタートパケットによって使用されるのと同じ経路であるように、比較的安定しています。 [ZDPS01]が示すように、この仮定は、一般的に有効にする必要があります。ただし、[RFC3819]は、パスの特性が時間の経過と共に変化する可能性がありデマンドサブネット上の帯域幅の範囲について説明します。
* Any new mechanism must be incrementally deployable and might not be supported by all the routers and/or end-hosts. Thus, any new mechanism must be able to accommodate non-supporting routers or end-hosts without disturbing the current Internet semantics. We note that, while Quick-Start is incrementally deployable in this sense, a Quick-Start Request cannot be approved for a particular connection unless both end-nodes and all the routers along the path have been configured to support Quick-Start.
*すべての新しいメカニズムは、増分展開可能でなければならず、すべてのルータおよび/またはエンドホストによってサポートされない場合があります。このように、任意の新しいメカニズムは、現在のインターネットのセマンティクスを乱すことなく、非サポートするルータまたはエンドホストに対応できなければなりません。私たちは、クイックスタートは、この意味では、増分展開可能である一方で、クイックスタートの要求が両方のエンドノードでない限り、特定の接続を承認することはできませんし、パスに沿ったすべてのルータがクイックスタートをサポートするように設定されている、ということに注意してください。
General Principles:
一般原理：
* Our underlying premise is that explicit feedback from all the routers along the path would be required, in the current architecture, for best-effort connections to use initial windows significantly larger than those allowed by [RFC3390], in the absence of other information about the path.
*私たちの基本的な前提は、ベストエフォート型の接続がに関するその他の情報がない場合には、[RFC3390]で許可されたものより有意に大きい初期ウィンドウを使用するためのパスに沿ってすべてのルーターからの明示的なフィードバックは、現在のアーキテクチャでは、必要とされるだろうということですパス。
* A router should only approve a Quick-Start Request if the output link is underutilized. Any other approach will result in either per-flow state at the router, or the possibility of a (possibly transient) queue at the router.
出力リンクが十分に活用されている場合*ルータはクイックスタートリクエストを承認する必要があります。他のアプローチは、ルータ、またはルータで（おそらく過渡）キューの可能性のいずれかでフロー毎の状態をもたらすであろう。
* No per-flow state should be required at the router. Note that, while per-flow state is not required, we also do not preclude a router from storing per-flow state for making Quick-Start decisions or for checking for misbehaving nodes.
*いいえ、フローごとの状態は、ルータで必要とされるべきでありません。フローごとの状態は必須ではありませんが、我々はまた、クイックスタート意思決定を行うためまたはノードを不正な動作をチェックするため、フローごとの状態を保存するからルータを排除しない、ということに注意してください。
In this section, we give an overview of the use of Quick-Start with TCP to request a higher congestion window. The description in this section is non-normative; the normative description of Quick-Start with IP and TCP follows in Sections 3 and 4. Quick-Start could be used in the middle of a connection, e.g., after an idle or underutilized period, as well as for the initial sending rate; these uses of Quick-Start are discussed later in the document.
このセクションでは、我々は、より高い輻輳ウィンドウを要求するTCPとクイックスタートの使用の概要を与えます。このセクションの説明は、非規範的です。セクション3および4における規範IPクイックスタートの説明およびTCP以下のクイックスタートは、例えば、アイドル又は活用されていない期間の後、ならびに初期送信レートのために、接続の途中で使用することができます。クイックスタートのこれらの用途は、文書の後半で説明されています。
Quick-Start requires end-points and routers to work together, with end-points requesting a higher sending rate in the Quick-Start (QS) option in IP, and routers along the path approving, modifying, discarding, or ignoring (and therefore disallowing) the Quick-Start Request. The receiver uses reliable, transport-level mechanisms to inform the sender of the status of the Quick-Start Request. For example, when TCP is used, the TCP receiver sends feedback to the sender using a Quick-Start Response option in the TCP header. In addition, Quick-Start assumes a unicast, congestion-controlled transport protocol; we do not consider the use of Quick-Start for multicast traffic.
クイックスタートは、エンドポイントがIPでクイックスタート（QS）オプションでより高い送信率を要求すると、一緒に動作するようにエンドポイントとルータを必要とし、経路に沿ったルータは、承認、変更、廃棄、または無視し（したがって）クイックスタート要求を許可しません。受信機は、クイック・スタート・リクエストのステータスの送信者に通知するために信頼性の高い、トランスポートレベルのメカニズムを使用しています。たとえば、TCPを使用する場合、TCP受信機はTCPヘッダ内のクイックスタート応答オプションを使用して、送信者にフィードバックを送信します。また、クイックスタートは、ユニキャスト、輻輳制御トランスポートプロトコルを想定します。私たちは、マルチキャストトラフィックのためのクイックスタートの使用を考慮していません。
When sent as a request, the Quick-Start Option includes a request for a sending rate in bits per second, and a Quick-Start Time to Live (QS TTL) to be decremented by every router along the path that understands the option and approves the request. The Quick-Start TTL is initialized by the sender to a random value. The transport receiver returns the rate, information about the TTL, and the Quick-Start Nonce to the sender using transport-level mechanisms; for TCP, the receiver sends this information in the Quick-Start Response in the TCP header. In particular, the receiver computes the difference between the Quick-Start TTL and the IP TTL (the TTL in the IP header) of the Quick-Start Request packet, and returns this in the Quick-Start Response. The sender uses the TTL difference to determine if all the routers along the path decremented the Quick-Start TTL, approving the Quick-Start Request.
要求として送信される場合、クイックスタートオプションオプションを理解し、承認経路に沿った全てのルータだけデクリメントするbps単位での送信レート要求、ライブするクイックスタートタイム（QS TTL）を含みますリクエスト。クイックスタートTTLは、ランダムな値に送信者によって初期化されます。トランスポート受信機は、トランスポートレベルのメカニズムを使用して送信者にレート、TTLについての情報、およびクイックスタートnonceを返します。 TCPのために、受信機は、TCPヘッダ内のクイックスタート応答にこの情報を送信します。特に、受信機は、クイックスタートTTLとクイックスタート要求パケットのIP TTL（IPヘッダのTTL）との差を計算し、クイックスタート応答でこれを返します。送信者は、パスに沿ってすべてのルータがクイックスタートリクエストを承認、クイックスタートTTLを減らさかどうかを判断するためにTTL差を使用しています。
If the request is approved by all the routers along the path, then the TCP sender combines this allowed rate with the measurement of the round-trip time, and ends up with an allowed TCP congestion window. This window is sent rate-paced over the next round-trip time, or until an ACK packet is received.
リクエストはパスに沿った全てのルータによって承認されている場合は、TCPの送信側がラウンドトリップ時間の測定と、この許容レートを組み合わせ、および許可されたTCP輻輳ウィンドウで終わります。このウィンドウには、レートのペースで次のラウンドトリップ時間にわたり、またはACKパケットが受信されるまで送信されます。
Figure 1 shows a successful use of Quick-Start, with the sender's IP layer and both routers along the path approving the Quick-Start Request, and the TCP receiver using the Quick-Start Response to return information to the TCP sender. In this example, Quick-Start is used by TCP to establish the initial congestion window.
図1は、TCP送信者に情報を返すためにクイックスタートレスポンスを使用して、送信者のIP層とクイックスタートリクエストを承認経路に沿って、両方のルータ、およびTCP受信機とクイックスタート、の使用の成功を示しています。この例では、クイックスタートは、最初の輻輳ウィンドウを確立するためにTCPによって使用されます。
Sender Router 1 Router 2 Receiver
------ -------- -------- --------
| <IP TTL: 63>
| <QS TTL: 91>
| <TTL Diff: 28>
| Quick-Start Request
| in SYN or SYN/ACK.
| IP: Decrement QS TTL
| to approve request -->
|
| Decrement
| QS TTL
| to approve
| request -->
|
| Decrement
| QS TTL
| to approve
| request -->
|
| <IP TTL: 60>
| <QS TTL: 88>
| <TTL Diff: 28>
| Return Quick-Start
| info to sender in
| Quick-Start Response
| <-- in TCP ACK packet.
|
| <TTL Diff: 28>
| Quick-Start approved,
| translate to cwnd.
| Report Approved Rate.
V Send cwnd paced over one RTT. -->
Figure 1: A Successful Quick-Start Request.
図1：成功したクイックスタート要求。
Figure 2 shows an unsuccessful use of Quick-Start, with one of the routers along the path not approving the Quick-Start Request. If the Quick-Start Request is not approved, then the sender uses the default congestion control mechanisms for that transport protocol, including the default initial congestion window, response to idle periods, etc.
図2は、パスに沿ったルータの1つは、クイック・スタート・リクエストを承認しないとクイックスタートの失敗の使用を示しています。クイックスタート要求が承認されない場合、送信者は、などの期間をアイドル状態にデフォルトの初期輻輳ウィンドウ、応答を含め、そのトランスポートプロトコルのデフォルトの輻輳制御メカニズムを使用しています
Sender Router 1 Router 2 Receiver
------ -------- -------- --------
| <IP TTL: 63>
| <QS TTL: 91>
| <TTL Diff: 28>
| Quick-Start Request
| in SYN or SYN/ACK.
| IP: Decrement QS TTL
| to approve request -->
|
| Decrement
| QS TTL
| to approve
| request -->
|
| Forward packet
| without modifying
| Quick-Start Option. -->
|
| <IP TTL: 60>
| <QS TTL: 89>
| <TTL Diff: 29>
| Return Quick-Start
| info to sender in
| Quick-Start Response
| <-- in TCP ACK packet.
|
| <TTL Diff: 29>
| Quick-Start not approved.
| Report approved rate.
V Use default initial cwnd. -->
Figure 2: An Unsuccessful Quick-Start Request.
図2：失敗したクイックスタート要求。
The Quick-Start Request for IPv4 is defined as follows:
次のようにIPv4のためのクイックスタートの要求が定義されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option | Length=8 | Func. | Rate | QS TTL |
| | | 0000 |Request| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QS Nonce | R |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The Quick-Start Option for IPv4.
A Quick-Start Request.
The first byte contains the option field, which includes the one-bit copy flag, the 2-bit class field, and the 5-bit option number.
最初のバイトは、1ビットのコピーフラグ、2ビットのクラスフィールド、5ビットのオプション番号を含むオプションフィールドを含んでいます。
The second byte contains the length field, indicating an option length of eight bytes.
2番目のバイトは8バイトのオプションの長さを示す、長さフィールドが含まれています。
The third byte includes a four-bit Function field. If the Function field is set to "0000", then the Quick-Start Option is a Rate Request. In this case, the second half of the third byte is a four-bit Rate Request field.
3番目のバイトは、4ビットの機能フィールドを含みます。ファンクション・フィールドが「0000」に設定されている場合は、クイック・スタート・オプションは、レート要求です。この場合には、3バイト目の後半4ビットレート要求フィールドです。
For a Rate Request, the fourth byte contains the Quick-Start TTL (QS TTL) field. The sender MUST set the QS TTL field to a random value. Routers that approve the Quick-Start Request decrement the QS TTL (mod 256) by the same amount that they decrement the IP TTL. (As elsewhere in this document, we use the term `router' imprecisely to also include the Quick-Start functionality at the IP layer at the sender.) The QS TTL is used by the sender to detect if all the routers along the path understood and approved the Quick-Start option.
レート要求のために、4番目のバイトは、クイックスタートTTL（QS TTL）フィールドが含まれています。送信者はランダムな値にQS TTLフィールドを設定しなければなりません。クイックスタートリクエストを承認するルータは、彼らがIP TTLをデクリメント同じ量だけQS TTL（MOD 256）をデクリメントします。 （他の場所でこの文書に記載されているように、我々は不正確にも、送信者のIP層でのクイックスタート機能が含まれるように用語 `ルータ」を使用しています。）QS TTLは、パス上のすべてのルータがわかるかどうかを検出するために送信者によって使用されていますそして、クイックスタートオプションを承認しました。
For a Rate Request, the transport sender MUST calculate and store the TTL Diff, the difference between the IP TTL value, and the QS TTL value in the Quick-Start Request packet, as follows:
次のようにレート要求のために、トランスポート・送信者は、クイックスタート要求パケットにTTL差分、IP TTL値との差、およびQS TTL値を計算し、保存する必要があります：
TTL Diff = ( IP TTL - QS TTL ) mod 256 (1)
TTL差分=（IP TTL - QS TTL）MOD 256（1）
For a Rate Request, bytes 5-8 contain a 30-bit QS Nonce, discussed in Section 3.4, and a two-bit Reserved field. The sender SHOULD set the reserved field to zero, and routers and receivers SHOULD ignore the reserved field. The sender SHOULD set the 30-bit QS Nonce to a random value.
レート要求に対して、5-8は3.4節で説明した30ビットQSノンス、および2ビットのReservedフィールドを含むバイト。送信者はゼロに予約フィールドを設定する必要があり、ルータおよび受信機は、予約フィールドを無視する必要があります。送信者はランダムな値に30ビットのQSノンスを設定する必要があります。
The sender initializes the Rate Request to the desired sending rate, including an estimate of the transport and IP header overhead. The encoding function for the Rate Request sets the request rate to K*2^N bps (bits per second), for N the value in the Rate Request field, and for K set to 40,000. For N=0, the rate request would be set to zero, regardless of the encoding function. This is illustrated in Table 1 below. For the four-bit Rate Request field, the request range is from 80 Kbps to 1.3 Gbps. Alternate encodings that were considered for the Rate Request are given in Appendix B.2.
送信者は、輸送およびIPヘッダのオーバーヘッドの推定値を含む、所望の送信レートにレート要求を初期化します。レート要求はK * 2 ^ NのBPS（ビット毎秒）に要求レートを設定するための符号化関数は、Nのレート要求フィールドにおいて、およびKの値は40,000に設定されています。 N = 0のため、レート要求に関係なく符号化関数のゼロに設定されることになります。これは、以下の表1に示されています。 4ビットレート要求フィールドは、要求の範囲は1.3 Gbpsの80 Kbpsのです。レート要求のために考慮された代替エンコーディングが付録B.2に記載されています。
N Rate Request (in Kbps)
--- ----------------------
0 0
1 80
2 160
3 320
4 640
5 1,280
6 2,560
7 5,120
8 10,240
9 20,480
10 40,960
11 81,920
12 163,840
13 327,680
14 655,360
15 1,310,720
Table 1: Mapping from Rate Request Field to Rate Request in Kbps.
表1：Kbps単位でリクエストを評価するためにレート要求フィールドからのマッピング。
Routers can approve the Quick-Start Request for a lower rate by decreasing the Rate Request in the Quick-Start Request. Section 4.2 discusses the Quick-Start Response from the TCP receiver to the TCP sender, and Section 4.4 discusses the TCP sender's mechanism for determining if a Quick-Start Request has been approved.
ルータは、クイックスタート要求におけるレート要求を減少させることにより、より低いレートのクイック・スタート・リクエストを承認することができます。 4.2節は、TCPの送信元にTCP受信機からクイックスタートレスポンスについて説明し、4.4節では、クイック・スタート・リクエストが承認されたかどうかを決定するためのTCP送信者のメカニズムについて説明します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option | Length=8 | Func. | Rate | Not Used |
| | | 1000 | Report| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QS Nonce | R |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The Quick-Start Option for IPv4.
Report of Approved Rate.
If the Function field in the third byte of the Quick-Start Option is set to "1000", then the Quick-Start Option is a Report of Approved Rate. In this case, the second four bits in the third byte are the Rate Report field, formatted exactly as in the Rate Request field in a Rate Request. For a Report of Approved Rate, the fourth byte of the Quick-Start Option is not used. Bytes 5-8 contain a 30-bit QS Nonce and a 2-bit Reserved field.
クイック・スタート・オプションの3番目のバイトでの関数フィールドが「1000」に設定されている場合は、クイック・スタート・オプションは、承認率の報告書です。この場合には、3バイト目に第4ビットは、レート要求にレート要求フィールドと全くフォーマットレートレポートフィールドです。承認率の報告書については、クイック・スタート・オプションの4番目のバイトは使用されません。バイト5-8は、30ビットQSノンスと2ビットのReservedフィールドを含みます。
After an approved Rate Request, the sender MUST report the Approved Rate, using a Quick-Start Option configured as a Report of Approved Rate with the Rate Report field set to the approved rate, and the QS Nonce set to the QS Nonce sent in the Quick-Start Request. The packet containing the Report of Approved Rate MUST be either a control packet sent before the first Quick-Start data packet, or a Quick-Start Option in the first data packet itself. The Report of Approved Rate does not have to be sent reliably; for example, if the approved rate is reported in a separate control packet, the sender does not necessarily know if the control packet has been dropped in the network. If the packet containing the Quick-Start Request is acknowledged, but the acknowledgement packet does not contain a Quick-Start Response, then the sender MUST assume that the Quick-Start Request was denied, and set a Report of Approved Rate with a rate of zero. Routers may choose to ignore the Report of Approved Rate, or to use the Report of Approved Rate but ignore the QS Nonce. Alternately, some routers that use the Report of Approved Rate may choose to match the QS Nonce, masked by the approved rate, with the QS Nonce seen in the original request.
承認されたレート要求した後、送信者は、承認されたレートに設定レートReportフィールドで承認されたレートの報告書として構成されたクイック・スタート・オプションを使用して、承認されたレートを報告しなければなりません、とQS nonceがに送信されQSナンスに設定しましたクイックスタート要求。承認されたレートのレポートを含むパケットは、最初のクイックスタートデータパケットの前に送信された制御パケット、または最初のデータパケット自体にクイックスタート・オプションのいずれかでなければなりません。承認されたレートの報告書は確実に送信する必要はありません。承認されたレートは、別の制御パケットで報告された場合に制御パケットがネットワークにドロップされた場合、たとえば、送信者は必ずしも知りません。クイックスタート要求を含むパケットを認めているが、確認応答パケットは、クイックスタートレスポンスが含まれていない場合、送信者は、クイックスタートの要求が拒否されたと仮定し、率で承認されたレートのレポートを設定しなければなりませんゼロ。ルータは認定速度の報告書を無視する、または承認されたレートのレポートを使用しますが、QS nonceを無視することもできます。代わりに、承認されたレートのレポートを使用する一部のルータは、元の要求に見QSノンスと、承認された率でマスクされたQS nonceを、一致することもできます。
If the Rate Request is denied, the sender MUST send a Report of Approved Rate with the Rate Report field set to zero.
レート要求が拒否された場合、送信者はゼロに設定レートReportフィールドで承認されたレートの報告書を送らなければなりません。
We note that, unlike a Quick-Start Request sent at the beginning of a connection, when a Quick-Start Request is sent in the middle of a connection, the connection could already have an established congestion window or sending rate. The Rate Request is the requested total rate for the connection, including the current rate of the connection; the Rate Request is *not* a request for an additional sending rate over and above the current sending rate. If the Rate Request is denied, or lowered to a value below the connection's current sending rate, then the sender ignores the request, and reverts to the default congestion control mechanisms of the transport protocol.
私たちは、クイックスタート要求は、接続の途中で送信され、接続の開始時に送信されたクイックスタート要求とは異なり、接続がすでに確立された輻輳ウィンドウまたは送信レートを持つことができる、ということに注意してください。レート要求は、接続の現在のレートを含む接続のための要求の合計率、です。レート要求は、* *現在の送信レートを超えると、上記の追加の送信レートの要求ではありません。レート要求が拒否された、または接続の現在の送信速度より低い値に低下させた場合、送信者は、要求を無視し、トランスポートプロトコルのデフォルトの輻輳制御メカニズムに戻ります。
The use of the Quick-Start Option does not require the additional use of the Router Alert Option [RFC2113].
クイック・スタート・オプションを使用すると、ルータアラートオプション[RFC2113]の追加の使用を必要としません。
We note that in IPv4, a change in IP options at routers requires recalculating the IP header checksum.
私たちは、IPv4で、ルータのIPオプションの変更は、IPヘッダのチェックサムを再計算する必要があることに注意してください。
The Quick-Start Option for IPv6 is placed in the Hop-by-Hop Options extension header that is processed at every network node along the communication path [RFC2460]. The option format following the generic Hop-by-Hop Options header is identical to the IPv4 format, with the exception that the Length field should exclude the common type and length fields in the option format and be set to 6 bytes instead of 8 bytes.
IPv6のためのクイック・スタート・オプションは、通信経路[RFC2460]に沿ったすべてのネットワークノードで処理されるホップバイホップオプション拡張ヘッダ内に配置されます。一般的なホップバイホップオプションヘッダに続くオプションのフォーマットは、長さフィールドは、オプション形式の一般的なタイプと長さフィールドを除外する必要があり、6バイトの代わりに8バイトに設定されることを除いて、IPv4形式と同一です。
For a Quick-Start Request, the transport receiver compares the Quick-Start TTL with the IPv6 Hop Limit field to calculate the TTL Diff. (The Hop Limit in IPv6 is the equivalent of the TTL in IPv4.) That is, TTL Diff MUST be calculated and stored as follows:
クイックスタートの要求のため、トランスポート・レシーバは、TTL差分を計算するためのIPv6ホップLimitフィールドでクイックスタートTTLを比較します。 （IPv6におけるホップリミットIPv4のTTLと同等である。）すなわち、以下のようにTTL差分を算出し、記憶しなければなりません。
TTL Diff = ( IPv6 Hop Limit - QS TTL ) mod 256 (2)
TTL差分=（IPv6のホップリミット - QS TTL）MOD 256（2）
Unlike IPv4, modifying or deleting the Quick-Start IPv6 Option does not require checksum re-calculation, because the IPv6 header does not have a checksum field, and modifying the Quick-Start Request in the IPv6 Hop-by-Hop options header does not affect the IPv6 pseudo-header checksum used in upper-layer checksum calculations.
IPv4のとは異なり、変更またはチェックサムの再計算を必要としないクイックスタートIPv6のオプションを削除し、IPv6ヘッダチェックサムフィールドを持っていないため、とIPv6のホップバイホップオプションヘッダ内のクイックスタート要求をしない変更します上層のチェックサムの計算に使用されるIPv6の疑似ヘッダチェックサムに影響を与えます。
Appendix A of RFC 2460 requires that all packets with the same flow label must be originated with the same hop-by-hop header contents, which would be incompatible with Quick-Start. However, a later IPv6 flow label specification [RFC3697] updates the use of flow labels in IPv6 and removes this restriction. Therefore, Quick-Start is compatible with the current IPv6 specifications.
RFC 2460の付録Aには、同じフローラベルを持つすべてのパケットが、クイックスタートと互換性がないのと同じホップバイホップヘッダの内容、で始まっしなければならないことを要求しています。しかし、後のIPv6フローラベル仕様[RFC3697]はIPv6におけるフローラベルの使用を更新し、この制限を取り除きます。したがって、クイックスタートは、現在のIPv6の仕様と互換性があります。
The Quick-Start Request does not report the current sending rate of the connection sending the request; in the default case of a router (or IP-layer implementation at an end-node) that does not maintain per-flow state, a router makes the conservative assumption that the flow's current sending rate is zero. Each participating router can either terminate or approve the Quick-Start Request. A router MUST only approve a Quick-Start Request if the output link is underutilized, and if the router judges that the output link will continue to be underutilized if this and earlier approved requests are used by the senders. Otherwise, the router reduces or terminates the Quick-Start Request.
クイックスタート要求は、要求を送信し、接続の現在の送信レートを報告しません。フロー毎の状態を維持しないルータ（またはエンドノードのIP層の実装）のデフォルトの場合には、ルータは、フローの現在の送信速度がゼロであること保守的な仮定を行います。各参加ルータは、終了またはクイックスタートリクエストを承認することができます。出力リンクが十分に活用されている場合、ルータは、唯一のクイックスタートリクエストを承認しなければならない、とルータが判断した場合、この以前の承認要求が送信者によって使用されている場合は出力リンクが十分に利用され続けること。そうしないと、ルータはクイックスタート要求を減少させるか、または終了します。
While the paragraph above defines the *semantics* of approving a Quick-Start Request, this document does not specify the specific algorithms to be used by routers in processing Quick-Start Requests or Reports. This is similar to RFC 3168, which specifics the semantics of the ECN codepoints in the IP header, but does not specify specific algorithms for routers to use in deciding when to drop or mark packets before buffer overflow.
上記の段落はクイックスタートのリクエストを承認する*セマンティクス*を定義しますが、この文書では、クイックスタートの要求またはレポートの処理中にルータが使用する特定のアルゴリズムが指定されていません。これは、IPヘッダ内のECNコードポイントのセマンティクスを詳細RFC 3168、と同様であるが、ルータがドロップまたはバッファオーバーフローの前にパケットをマークするときを決定する際に使用するための特定のアルゴリズムを指定していません。
A router that wishes to terminate the Quick-Start Request SHOULD either delete the Quick-Start Request from the IP header or zero the QS TTL, QS Nonce, and Rate Request fields. Deleting the Quick-Start Request saves resources because downstream routers will have no option to process, but zeroing the Rate Request field may be more efficient for routers to implement. As suggested in [B05], future additions to Quick-Start could define error codes for routers to insert into the QS Nonce field to report back to the sender the reason that the Quick-Start Request was denied, e.g., that the router is denying all Quick-Start Requests at this time, or that this router, as a matter of policy, does not grant Quick-Start requests. A router that doesn't understand the Quick-Start Option will simply forward the packet with the Quick-Start Request unchanged (ensuring that the TTL Diff will not match and Quick-Start will not be used).
クイックスタート要求を終了したいルータがIPヘッダからクイックスタート要求を削除するか、QS TTL、QSノンス、及びレート要求フィールドをゼロにすべきであるいずれか。下流のルータが処理するオプションを持っていないでしょうが、レート要求フィールドをゼロにすると、ルータが実装するために、より効率的な可能性があるので、クイックスタート要求を削除すると、リソースを節約できます。 [B05]で示唆したように、クイックスタートへの将来の追加は、ルータが拒否されていること、例えば、送信者にクイックスタート要求が拒否されたことを理由を報告するためにQSナンスフィールドに挿入するルータのエラーコードを定義することができますすべてのクイックスタートは、この時点で要求し、またはこのルータは、政策の問題として、クイックスタート要求を許可しないこと。クイック・スタート・オプションを理解していないルータは、単純に（TTL差分が一致せず、クイックスタートが使用されないことを保証する）そのままクイックスタート要求を持つパケットを転送します。
If the participating router has decided to approve the Quick-Start Request, it does the following:
参加ルータはクイックスタート要求を承認することを決定した場合、次のことを行います。
* The router MUST decrement the QS TTL by the amount the IP TTL is decremented (usually one).
*ルータは、IP TTLがデクリメントさ量（通常は1）でQS TTLをデクリメントしなければなりません。
* If the router is only willing to approve a Rate Request less than that in the Quick-Start Request, then the router replaces the Rate Request with a smaller value. The router MUST NOT increase the Rate Request in the Quick-Start Request. If the router decreases the Rate Request, the router MUST also modify the QS Nonce, as described in Section 3.4.
ルータが少ないクイックスタート要求よりもレート要求を承認するだけで喜んでいる場合*、ルータは小さな値とレート要求を置き換えます。ルータは、クイックスタート要求におけるレート要求を増やしてはなりません。ルータはレート要求を減少させる場合は、セクション3.4で説明したように、ルータはまた、QSノンスを変更する必要があります。
* In IPv4, the router MUST update the IP header checksum.
* IPv4では、ルータは、IPヘッダのチェックサムを更新する必要があります。
If the router approves the Quick-Start Request, this approval SHOULD be taken into account in the router's decision to accept or reject subsequent Quick-Start Requests (e.g., using a variable that tracks the recent aggregate of accepted Quick-Start Requests). This consideration of earlier approved Quick-Start Requests is necessary to ensure that the router only approves a Quick-Start Request when the router judges that the output link will remain underutilized if this and earlier Quick-Start Requests are used by the senders.
ルータはクイックスタートリクエストを承認した場合、この承認を受け入れるか、後続のクイックスタートの要求を拒否するようにルーターの決定に考慮されるべきである（例えば、受け入れクイックスタート要求の最近の集計を追跡する変数を使用して）。以前承認されたクイックスタート要求のこの考慮事項は、ルータはこれだけ以前のクイックスタート要求が送信者によって使用されている場合は出力リンクが残ることをルータ裁判官が活用されていないクイックスタートリクエストを承認することを保証する必要があります。
In addition, the approval of a Quick-Start Request SHOULD NOT be used by the router to affect the treatment of the data packets that arrive from this connection in the next few round-trip times. That is, the approval by the router of a Quick-Start Request does not give differential treatment for Quick-Start data packets at that router; it is only a statement from the router that the router believes that the subsequent Quick-Start data packets from this connection will not change the current underutilized state of the router.
また、クイック・スタート・リクエストの承認は、次のいくつかの往復時間で、この接続から到着したデータパケットの治療に影響を与えるために、ルータで使用することはできません。これは、クイック・スタート・リクエストのルータの承認がそのルータのクイックスタートのデータパケットに対して異なる待遇を与えるものではありません、です。それが唯一のルータは、この接続からその後のクイックスタートのデータパケットは、ルータの現在十分に活用されていない状態を変更しないと考えているルータからの声明です。
A non-participating router forwards the Quick-Start Request unchanged, without decrementing the QS TTL. The non-participating router still decrements the TTL field in the IP header, as is required for all routers [RFC1812]. As a result, the sender will be able to detect that the Quick-Start Request had not been understood or approved by all of the routers along the path.
非参加ルータはQS TTLをデクリメントせずに、そのままクイックスタート要求を転送します。すべてのルータ[RFC1812]のために必要とされるように、非参加ルータは依然として、IPヘッダ内のTTLフィールドをデクリメントします。その結果、送信者は、クイックスタート要求がパスに沿ったルーターの全てが理解または承認されていなかったことを検出することができるようになります。
A router that uses multipath routing for packets within a single connection MUST NOT approve a Quick-Start Request. This is discussed in more detail in Section 9.2.
単一の接続内のパケットのためのマルチパスルーティングを使用するルータは、クイックスタートリクエストを承認してはなりません。これは、9.2節で詳しく説明されています。
If the Quick-Start Option has the Function field set to "1000", then this is a Report of Approved Rate, rather than a Rate Request. The router MAY ignore such an option, and, in any case, it MUST NOT modify the contents of the option for a Report of Approved Rate. However, the router MAY use the Approved Rate report to check that the sender is not lying about the approved rate. If the reported Approved Rate is higher than the rate that the router actually approved for this connection in the previous round-trip time, then the router may implement some policy for cheaters. For instance, the router MAY decide to deny future Quick-Start Requests from this sender, including, if desired, deleting Quick-Start Requests from future packets from this sender. Section 9.4.1 discusses misbehaving
クイック・スタート・オプションは、「1000」に設定された機能フィールドを持っている場合、これは承認率の報告書ではなく、レート要求です。ルータは、このようなオプションを無視してもよい（MAY）、そして、どのような場合には、それが承認されたレートのレポートのオプションの内容を変更してはいけません。しかし、ルータは、送信者が承認率について横たわっていないことを確認するために承認された料金のレポートを使用するかもしれません。報告された承認されたレートは、ルータが実際に前回のラウンドトリップ時間にこの接続のために承認されたレートよりも高い場合、ルータは、不正行為のために、いくつかの政策を実施することができます。たとえば、ルータが必要であれば、この送信者から将来のパケットからのクイックスタート要求を削除する、を含む、この送信者から今後のクイックスタート要求を拒否することもできます。 9.4.1項は、不正な動作について説明します
senders in more detail. From the Report of Approved Rate, the router can also learn if some of the downstream routers have approved the Quick-Start Request for a smaller rate or denied the use of Quick-Start, and adjust its bandwidth allocations accordingly.
より詳細に送信者。承認されたレートのレポートから、ルータが下流ルータの一部は小さい率のためのクイックスタートリクエストを承認またはクイックスタートの使用を否定している場合も学び、それに応じて帯域幅の割り当てを調整することができます。
The QS Nonce gives the Quick-Start sender some protection against receivers lying about the value of the received Rate Request. This is particularly important if the receiver knows the original value of the Rate Request (e.g., when the sender always requests the same value, and the receiver has a long history of communication with that sender). Without the QS Nonce, there is nothing to prevent the receiver from reporting back to the sender a Rate Request of K, when the received Rate Request was, in fact, less than K.
QSナンスは、クイックスタートの送信者に受信レート要求の値について嘘受信機に対してある程度の保護を提供します。受信機は（送信者が常に同じ値を要求し、受信機はその送信者とのコミュニケーションの長い歴史を持っているなど、）レート要求の元の値を知っている場合、これは特に重要です。 QSナンスがなければ、送信者に受信レート要求をしたとき、実際には、以下K.よりK、のレート要求の報告から受信を防ぐためには何もありません
Table 2 gives the format for the 30-bit QS Nonce.
表2は、30ビットQSノンスのフォーマットを与えます。
Bits Purpose
--------- ------------------
Bits 0-1: Rate 15 -> Rate 14
Bits 2-3: Rate 14 -> Rate 13
Bits 4-5: Rate 13 -> Rate 12
Bits 6-7: Rate 12 -> Rate 11
Bits 8-9: Rate 11 -> Rate 10
Bits 10-11: Rate 10 -> Rate 9
Bits 12-13: Rate 9 -> Rate 8
Bits 14-15: Rate 8 -> Rate 7
Bits 16-17: Rate 7 -> Rate 6
Bits 18-19: Rate 6 -> Rate 5
Bits 20-21: Rate 5 -> Rate 4
Bits 22-23: Rate 4 -> Rate 3
Bits 24-25: Rate 3 -> Rate 2
Bits 26-27: Rate 2 -> Rate 1
Bits 28-29: Rate 1 -> Rate 0
Table 2: The QS Nonce.
表2：QSナンス。
The transport sender MUST initialize the QS Nonce to a random value. If the router reduces the Rate Request from rate K to rate K-1, then the router MUST set the field in the QS Nonce for "Rate K -> Rate K-1" to a new random value. Similarly, if the router reduces the Rate Request by N steps, the router MUST set the 2N bits in the relevant fields in the QS Nonce to a new random value. The receiver MUST report the QS Nonce back to the sender.
トランスポート送信者はランダムな値にQS nonceを初期化する必要があります。新しいランダムな値に - ルータは率Kからのレート要求は、K-1を評価するために減少した場合、ルータは「>レートK-1レートK」のためにQSナンスにフィールドを設定しなければなりません。同様に、ルータはNステップによるレート要求を減少させる場合、新しいランダム値にQSノンスにおける関連分野の2Nビットを設定しなければならないルータ。受信機は、送信者にQS nonceを報告しなければなりません。
If the Rate Request was not decremented in the network, then the QS Nonce should have its original value. Similarly, if the Rate Request was decremented by N steps in the network, and the receiver reports back a Rate Request of K, then the last 2K bits of the QS Nonce should have their original value.
レート要求がネットワークに減らされていなかった場合は、QS nonceが元の値を持つ必要があります。レート要求がバックNネットワークのステップ、およびレシーバレポートKのレート要求だけデクリメントされた場合、同様に、次にQSノンスの最後2Kビットは、それらの元の値を有するべきです。
With the QS Nonce, the receiver has a 1/4 chance of cheating about each step change in the rate request. Thus, if the rate request is reduced by two steps in the network, the receiver has a 1/16 chance of successfully reporting that the original request was approved, as this requires reporting the original value for the QS nonce. Similarly, if the rate request is reduced many steps in the network, and the receiver receives a QS Option with a rate request of K, the receiver has a 1/16 chance of guessing the original values for the fields in the QS nonce for "Rate K+2 -> Rate K+1" and "Rate K+1 -> Rate K". Thus, the receiver has a 1/16 chance of successfully lying and saying that the received rate request was K+2 instead of K.
QSナンスを使用すると、受信機は、レート要求の各ステップ変化について、不正行為の1/4のチャンスを持っています。レート要求は、ネットワーク内の2つのステップによって減少されている場合、これはQSナンスのために元の値を報告して必要とするこのように、受信機は、成功した元の要求が承認されたことを報告するの1/16のチャンスを持っています。レート要求は、ネットワーク内の多くの工程を低減し、受信機は、Kのレート要求にQSオプションを受信した場合、同様に、受信機は、「ためのQSナンスにおけるフィールドの元の値を推測するの1/16機会を有しますレートK + 2 - >レートK + 1" と "率K + 1 - >レートK"。したがって、受信機が正常に横たわって、受信したレート要求が代わりにKのK + 2であったというの1/16機会を有します
We note that the protection offered by the QS Nonce is the same whether one router makes all the decrements in the rate request, or whether they are made at different routers along the path.
私たちは、QSナンスによって提供される保護は1つのルータがレート要求にすべての減分を作るか、またはそれらはパスに沿って異なるルータで行われているかどうかと同じであることに注意してください。
The requirements for randomization for the sender and routers in setting `random' values in the QS Nonce are not stringent -- almost any form of pseudo-random numbers will do. The requirement is that the original value for the QS Nonce is not easily predictable by the receiver, and in particular, the nonce MUST NOT be easily determined from inspection of the rest of the packet or from previous packets. In particular, the nonce MUST NOT be based only on a combination of specific packet header fields. Thus, if two bits of the QS Nonce are changed by a router along the path, the receiver should not be able to guess those two bits from the other 28 bits in the QS Nonce.
QSナンスに `ランダム」値を設定することで、送信者とルータのためのランダム化のための要件が厳しくない - 疑似乱数のほぼすべてのフォームが行います。要件は、QSノンスの元の値が受信機によって容易に予測できない、特に、nonceが容易パケットの残りの検査から、または前のパケットから決定されてはならないことです。特に、ノンスは、特定のパケットヘッダフィールドの組み合わせに基づいてはいけません。 QSノンスの2ビットは、経路に沿ったルータによって変更された場合にこのように、受信機は、QSノンス内の他の28ビットから、これら2つのビットを推測することができないはずです。
An additional requirement is that the receiver cannot be able to tell, from the QS Nonce itself, which numbers in the QS Nonce were generated by the sender, and which were generated by routers along the path. This makes it harder for the receiver to infer the value of the original rate request, making it one step harder for the receiver to cheat.
追加の要件は、受信機がQSノンス内の数字は、パスに沿ったルータによって生成された送信者によって生成され、そしてたQSノンス自体から、伝えることができないことです。これは、一歩難しく受信機はカンニングできるようにすること、それは難しく、受信機が元のレート要求の値を推測できるようになります。
Section 9.4 also considers issues of receiver cheating in more detail.
9.4節は、より詳細に浮気受信機の問題点を検討します。
This section describes how the Quick-Start mechanism would be used in TCP. We first sketch the procedure and then tightly define it in the subsequent subsections.
このセクションでは、クイックスタートメカニズムがTCPで使用される方法を説明します。私たちは、最初の手順をスケッチして、しっかりとそれ以降のサブセクションで定義します。
If a TCP sender (say, host A) would like to use Quick-Start, the TCP sender puts the requested sending rate in bits per second, appropriately formatted, in the Quick-Start Option in the IP header of the TCP packet, called the Quick-Start Request packet. (We will be somewhat loose in our use of "packet" vs. "segment" in this section.) When used for initial start-up, the Quick-Start Request packet can be either the SYN or SYN/ACK packet, as illustrated in Figure 1. The requested rate includes an estimate for the transport and IP header overhead. The TCP receiver (say, host B) returns the Quick-Start Response option in the TCP header in the responding SYN/ACK packet or ACK packet, called the Quick-Start Response packet, informing host A of the results of their request.
TCPの送信者（たとえば、ホストA）はクイックスタートを使用したい場合は、TCPの送信者と呼ばれる、TCPパケットのIPヘッダ内のクイックスタートオプションで、適切にフォーマット、ビット毎秒で要求された送信レートを置きますクイックスタート要求パケット。 （私たちは、このセクションの「セグメント」対「パケット」の私達の使用中に多少緩いとなります。）最初の起動に使用する場合、クイックスタートRequestパケットがSYNまたはSYN / ACKパケットのいずれかになります、示されているように図1に要求されたレートは、トランスポートおよびIPヘッダのオーバーヘッドの推定値を含みます。 TCP受信機（例えば、ホストB）が応答SYN / ACKパケットまたはACKパケットにTCPヘッダ内のクイックスタート応答オプションを返し、その要求の結果のホストAに通知する、クイックスタート応答パケットと呼ばれます。
If the acknowledging packet does not contain a Quick-Start Response, or contains a Quick-Start Response with the wrong value for the TTL Diff or the QS Nonce, then host A MUST assume that its Quick-Start request failed. In this case, host A sends a Report of Approved Rate with a Rate Report of zero, and uses TCP's default congestion control procedure. For initial start-up, host A uses the default initial congestion window ([RFC2581], [RFC3390]).
認めパケットがクイックスタートレスポンスが含まれている、またはTTL差分またはQSナンスのために間違った値を持つクイックスタートレスポンスが含まれていない場合、ホストAは、そのクイックスタート要求が失敗したと仮定しなければなりません。この場合、ホストAは、ゼロの速度レポートで承認されたレートのレポートを送信し、TCPのデフォルトの輻輳制御手順を使用しています。最初の起動のために、ホストAはデフォルトの初期輻輳ウィンドウ（[RFC2581]、[RFC3390]）を使用しています。
If the returning packet contains a valid Quick-Start Response, then host A uses the information in the response, along with its measurement of the round-trip time, to determine the Quick-Start congestion window (QS-cwnd). Quick-Start data packets are defined as data packets sent as the result of a successful Quick-Start request, up to the time when the first Quick-Start packet is acknowledged. The sender also sends a Report of Approved Rate. In order to use Quick-Start, the TCP host MUST use rate-based pacing [VH97] to transmit Quick-Start packets at the rate indicated in the Quick-Start Response, at the level of granularity possible by the sending host. We note that the limitations of interrupt timing on computers can limit the ability of the TCP host in rate-pacing the outgoing packets.
返送パケットが有効クイックスタートレスポンスが含まれている場合、Aはクイックスタートの輻輳ウィンドウ（QS-のcwnd）を決定するために、ラウンドトリップ時間のその測定値とともに、応答内の情報を使用するホスト。クイックスタートデータパケットは、まずクイックスタートパケットが確認される時まで、成功したクイックスタート要求の結果として送信されるデータパケットとして定義されています。送信者はまた、承認されたレートのレポートを送信します。クイックスタートを使用するために、TCPホストは、送信ホストが可能な粒度のレベルでクイックスタート応答に示された速度でのクイック・スタート・パケットを送信する[VH97]レートベースペーシングを使用しなければなりません。私たちは、コンピュータ上の割り込みタイミングの制約がレートペーシング発信パケットにおけるTCPホストの能力を制限できることに注意してください。
The two TCP end-hosts can independently decide whether to request Quick-Start. For example, host A could send a Quick-Start Request in the SYN packet, and host B could also send a Quick-Start Request in the SYN/ACK packet.
2つのTCPエンドホストは独立してクイックスタートを要求するかどうかを決定することができます。例えば、ホストAは、SYNパケット内のクイックスタート要求を送信することができ、ホストBはまた、SYN / ACKパケットでクイックスタート要求を送信することができます。
When sending a Quick-Start Request, the TCP sender SHOULD send the request on a packet that requires an acknowledgement, such as a SYN, SYN/ACK, or data packet. In this case, if the packet is acknowledged but no Quick-Start Response is included, then the sender knows that the Quick-Start Request has been denied, and can send a Report of Approved Rate.
クイックスタートリクエストを送信する場合、TCPの送信者は、SYN、SYN / ACK、またはデータパケットとして、承認を必要とするパケットにリクエストを送信すべきです。パケットが確認されたが、何のクイックスタートレスポンスが含まれていない場合この場合、送信者は、クイックスタート要求が拒否されていることを知っている、と承認率のレポートを送信することができます。
In addition to the use of Quick-Start when a connection is established, there are several additional points in a connection when a transport protocol may want to issue a Rate Request. We first reiterate the notion that Quick-Start is a coarse-grained mechanism. That is, Quick-Start's Rate Requests are not meant to be used for fine-grained control of the transport's sending rate. Rather, the transport MAY issue a Rate Request when no information about the appropriate sending rate is available, and the default congestion control mechanisms might be significantly underestimating the appropriate sending rate.
トランスポートプロトコルは、レート要求を発行することもできたときに接続が確立されたクイックスタートの使用に加えて、接続のいくつかの追加点があります。私たちは、最初のクイックスタートは粗粒のメカニズムであるという考えを改めて表明する。これは、クイックスタートのレート要求はトランスポートの送信レートをきめ細かく制御するために使用されることを意図していない、です。むしろ、適切な送信レートに関する情報がないときは、輸送料金のリクエストを発行することができる、およびデフォルトの輻輳制御メカニズムが大幅に適切な送信レートを過小評価かもしれません。
The following are potential points where Quick-Start may be useful:
以下のクイックスタートが有用である可能性がある潜在的なポイントは以下のとおりです。
(1) At or soon after connection initiation, when the transport has no idea of the capacity of the network path, as discussed above. (A transport that uses TCP Control Block sharing [RFC2140], the Congestion Manager [RFC3124], or other mechanisms for sharing congestion information may not need Quick-Start to determine an appropriate rate.)
（1）において、またはすぐ接続開始後、上述のようにトランスポートが、ネットワーク経路の能力のない考えを持っている場合。 （ブロック[RFC2140]を共有するTCPコントロールを使用するトランスポートは、渋滞情報を共有するための輻輳マネージャ[RFC3124]、または他のメカニズムが適切なレートを決定するために、クイックスタートを必要としなくてもよいです。）
(2) After an idle period when the transport no longer has a validated estimate of the available bandwidth for this flow. (An example could be a persistent-HTTP connection when a new HTTP request is received after an idle period.)
（2）輸送は、もはやこのフローのために利用可能な帯域幅の検証推定値を有する休止期間の後。 （新しいHTTP要求がアイドル期間後に受信されたときの例では、永続HTTP接続とすることができます。）
(3) After a host has received explicit indications that one of the endpoints has moved its point of network attachment. This can happen due to some underlying mobility mechanism like Mobile IP ([RFC3344], [RFC3775]). Some transports, such as Steam Control Transmission Protocol (SCTP) [RFC2960], may associate with multiple IP addresses and can switch addresses (and therefore network paths) in mid-connection. If the transport has concrete knowledge of a changing network path, then the current sending rate may not be appropriate, and the transport sender may use Quick-Start to probe the network to see if it can send at a higher rate. (Alternatively, traditional slow-start should be used in this case when Quick-Start is not available.)
（3）ホストは、エンドポイントの1つは、ネットワークアタッチメントのそのポイントを移動したことを明示的な指示を受信した後。これは、モバイルIP（[RFC3344]、[RFC3775]）のようないくつかの基本的なモビリティ機構に発生する可能性があります。このような蒸気制御伝送プロトコル（SCTP）[RFC2960]などのいくつかのトランスポートは、複数のIPアドレスに関連付けることができ、中間接続のアドレス（したがって、ネットワーク経路）を切り替えることができます。トランスポートが変化するネットワークパスの具体的な知識を持っている場合は、現在の送信レートは適切ではないかもしれない、とトランスポート送信者は、それが高いレートで送信できるかどうかを確認するためにネットワークをプローブするクイックスタートを使用することができます。 （クイックスタートが利用できない場合に代わりに、伝統的なスロースタートは、この場合に使用する必要があります。）
(4) After an application-limited period, when the sender has been using only a small amount of its appropriate share of the network capacity and has no valid estimate for its fair share. In this case, Quick-Start may be an appropriate mechanism to determine if the sender can send at a higher rate. For instance, consider an application that steadily exchanges low- rate control messages and suddenly needs to transmit a large amount of data.
（4）送信側がネットワーク容量のその適切なシェアの少量を用いて、その公正な取り分のために有効な推定値を有するされていないアプリケーションが制限された期間の後。この場合、クイックスタートは、送信者がより高い速度で送信できるかどうかを決定するための適切な機構であってもよいです。例えば、着実に低レート制御メッセージを交換し、突然、大量のデータを送信する必要があるアプリケーションを考えてみます。
Of the above, this document recommends that a TCP sender MAY attempt to use Quick-Start in cases (1) and (2). It is NOT RECOMMENDED that a TCP sender use Quick-Start for case (3) at the current time. Case (3) requires external notifications not presently defined for TCP or other transport protocols. Finally, a TCP SHOULD NOT use Quick-Start for case (4) at the current time. Case (4) requires further thought and investigation with regard to how the transport protocol could determine it was in a situation that would warrant transmitting a Quick-Start Request.
上記のうち、このドキュメントでは、TCPの送信者がケースにクイックスタートを使用しようとするかもしれないことをお勧めします（1）及び（2）。 TCPの送信者は、現在の時点でケース（3）のためのクイックスタートを使用することをお勧めしません。 （3）ケースは、現在、TCPまたはその他のトランスポートプロトコルのために定義されていない外部の通知が必要です。最後に、TCPは、現時点でのケース（4）のためのクイックスタートを使用しないでください。 （4）ケースは、トランスポートプロトコルは、それがクイックスタートリクエストを送信する正当だろうな状況にあった決定することができるかに関して更なる思想と調査が必要。
As a general guideline, a TCP sender SHOULD NOT request a sending rate larger than it is able to use over the next round-trip time of the connection (or over 100 ms, if the round-trip time is not known), except as required to round up the desired sending rate to the next-highest allowable request.
一般的なガイドラインとして、TCPの送信者は場合を除き、（ラウンドトリップ時間が知られていない場合、または100 ms以上）接続の次のラウンドトリップ時間を超える使用することができますよりも大きな送信レートを要求すべきでありません次に高い許容要求に対して所望の送信レートを切り上げるために必要。
In any circumstances, the sender MUST NOT make a QS request if it has made a QS request within the most recent round-trip time.
それは最新の往復時間内QS要求を行った場合、どのような状況では、送信者は、QS要求してはなりません。
Section 4.7 discusses some of the issues of using Quick-Start at connection initiation, and Section 4.8 discusses issues that arise when Quick-Start is used to request a larger sending rate after an idle period.
4.7節は、接続開始時にクイックスタートを使用しての問題のいくつかについて説明し、4.8節は、クイックスタートがアイドル期間の後に、より大きな送信レートを要求するために使用されたときに発生する問題について説明します。
In order to approve the use of Quick-Start, the TCP receiver responds to the receipt of a Quick-Start Request with a Quick-Start Response, using the Quick-Start Response Option in the TCP header. TCP's Quick-Start Response option is defined as follows:
クイックスタートの使用を承認するためには、TCP受信機はTCPヘッダ内のクイックスタート応答オプションを使用して、クイックスタートレスポンスとクイックスタート要求の受信に応答します。以下のようにTCPのクイックスタート応答オプションが定義されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length=8 | Resv. | Rate | TTL Diff |
| | | |Request| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QS Nonce | R |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: The Quick-Start Response Option in the TCP Header.
図5：TCPヘッダのクイックスタート応答オプション。
The first byte of the Quick-Start Response option contains the option kind, identifying the TCP option.
クイックスタート応答オプションの最初のバイトは、TCPオプションを識別し、オプションの種類が含まれています。
The second byte of the Quick-Start Response option contains the option length in bytes. The length field MUST be set to 8 bytes.
クイックスタート応答オプションの2番目のバイトは、バイト単位のオプションの長さが含まれています。長さフィールドは、8バイトに設定しなければなりません。
The third byte of the Quick-Start Response option contains a four-bit Reserved field, and the four-bit allowed Rate Request, formatted as in the Quick-Start Rate Request option.
クイックスタート応答オプションの3番目のバイトは、クイックスタートレート要求オプションでフォーマットされたとして4ビットの予約フィールド、および4ビットの許可レート要求が含まれています。
The fourth byte of the TCP option contains the TTL Diff. The TTL Diff contains the difference between the IP TTL and QS TTL fields in the received Quick-Start Request packet, as calculated in equations (1) or (2) (depending on whether IPv4 or IPv6 is used).
TCPオプションの4番目のバイトは、TTL差分が含まれています。 TTL差分は、式（1）又は（2）（IPv4またはIPv6が使用されるかどうかに応じて）で計算し、受信したクイックスタート要求パケットにIP TTLおよびQS TTLフィールドとの間の差を含んでいます。
Bytes 5-8 of the TCP option contain the 30-bit QS Nonce and a two-bit Reserved field.
TCPオプションのバイト5-8は、30ビットのQSノンスと2ビットの予約フィールドが含まれています。
We note that, while there are limitations on the potential size of the Quick-Start Response Option, a Quick-Start Response Option of eight bytes should not be a problem. The TCP Options field can contain up to 40 bytes. Other TCP options that might be used in a SYN or SYN/ACK packet include Maximum Segment Size (four bytes), Time Stamp (ten bytes), Window Scale (three bytes), and Selective Acknowledgments Permitted (two bytes).
私たちは、クイックスタート応答オプションの潜在的な大きさに制限がありますが、8バイトのクイックスタート応答オプションが問題になることはありません、ということに注意してください。 TCPオプションフィールドには、最大40バイトを含めることができます。 SYNまたはSYN / ACKパケットで使用されるかもしれない他のTCPオプションは、最大セグメントサイズ（4バイト）、タイムスタンプ（10バイト）、ウィンドウスケール（3バイト）、および選択謝辞許可（2バイト）が含まれます。
An end host (say, host B) that receives an IP packet containing a Quick-Start Request passes the Quick-Start Request, along with the value in the IP TTL field, to the receiving TCP layer.
エンドホストは、（例えば、ホストB）クイックスタート要求を含むIPパケットを受信する受信TCP層に、IP TTLフィールドの値と共に、クイックスタート要求を渡します。
If the TCP host is willing to permit the Quick-Start Request, then a Quick-Start Response option is included in the TCP header of the corresponding acknowledgement packet. The Rate Request in the Quick-Start Response option is set to the received value of the Rate Request in the Quick-Start Option, or to a lower value if the TCP receiver is only willing to allow a lower Rate Request. The TTL Diff in the Quick-Start Response is set to the difference between the IP TTL value and the QS TTL value as given in equation (1) or (2) (depending on whether IPv4 or IPv6 is used). The QS Nonce in the Response is set to the received value of the QS Nonce in the Quick-Start Option.
TCPホストがクイックスタート要求を許可する意志がある場合は、クイックスタート応答オプションは、対応する肯定応答パケットのTCPヘッダに含まれています。 TCP受信機は低レート要求を可能にするだけで喜んであればレート要求にクイックスタート応答オプションは、クイックスタートオプションで、以下の値にレート要求の受信した値に設定されています。式で与えられるようにクイックスタート応答におけるTTL差分は、IP TTL値とQS TTL値との差に設定されている（1）又は（2）（IPv4またはIPv6が使用されるかどうかに応じて）。応答したQSナンスは、クイックスタートオプションでQSナンスの受信した値に設定されています。
If an end host receives an IP packet with a Quick-Start Request with a rate request of zero, then that host SHOULD NOT send a Quick-Start Response.
エンドホストがゼロのレート要求にクイックスタート要求を持つIPパケットを受信した場合、そのホストは、クイックスタートレスポンスを送るべきではありません。
The Quick-Start Response MUST NOT be resent if it is lost in the network. Packet loss could be an indication of congestion on the return path, in which case it is better not to approve the Quick-Start Request.
それがネットワーク内で失われた場合クイックスタートレスポンスを再送してはなりません。パケット損失は、クイックスタートリクエストを承認しない方がよい。その場合には、リターンパス上の輻輳の兆候である可能性があります。
A TCP host (say, TCP host A) that sent a Quick-Start Request and receives a Quick-Start Response in an acknowledgement first checks that the Quick-Start Response is valid. The Quick-Start Response is valid if it contains the correct value for the TTL Diff, and an equal or lesser value for the Rate Request than that transmitted in the Quick-Start Request. In addition, if the received Rate Request is K, then the rightmost 2K bits of the QS Nonce must match those bits in the QS Nonce sent in the Quick-Start Request. If these checks are not successful, then the Quick-Start Request failed, and the TCP host MUST use the default TCP congestion window that it would have used without Quick-Start. If the rightmost 2K bits of the QS Nonce do not match those bits in the QS Nonce sent in the Quick-Start Request, for a received Rate Request of K, then the TCP host MUST NOT send additional Quick-Start Requests during the life of the connection. Whether or not the Quick-Start Request was successful, the host receiving the Quick-Start Response MUST send a Report of Approved Rate. Similarly, if the packet containing the Quick-Start Request is acknowledged, but the acknowledgement does not include a Quick-Start Response, then the sender MUST send a Report of Approved Rate.
クイックスタート要求を送信し、クイックスタート応答が有効であることを確認最初にチェックしてクイックスタートレスポンスを受信するTCPホスト（たとえば、TCPホストA）。それはTTL差分のための正しい値、およびクイックスタート要求で送信されたものよりレート要求に対して同等以下の値が含まれている場合、クイックスタート応答が有効です。また、受信されたレート要求がKである場合、QSノンスの右端2KビットがQSノンスにそれらのビットと一致しなければなりませんクイックスタートリクエストで送信。これらのチェックが成功しない場合は、クイックスタート要求は失敗し、TCPホストは、クイックスタートせずに使用しているだろう、デフォルトのTCP輻輳ウィンドウを使用しなければなりません。 QSナンスの右端の2Kビットは、Kの受信レート要求のために、クイックスタート要求で送信されたQSナンスでこれらのビットが一致しない場合は、TCPホストはの寿命の間に、追加のクイック・スタート・リクエストを送ってはいけません接続。クイックスタートの要求が成功したかどうかにかかわらず、クイックスタートレスポンスを受信したホストは、承認されたレートの報告書を送らなければなりません。クイックスタート要求を含むパケットを認めているが、確認応答がクイックスタートレスポンスが含まれていない場合は同様に、送信者は、承認されたレートの報告書を送らなければなりません。
If the checks of the TTL Diff and the Rate Request are successful, and the TCP host is going to use the Quick-Start Request, it MUST start using it within one round-trip time of receiving the Quick-Start Response, or within three seconds, whichever is smaller. To use the Quick-Start Request, the host sets its Quick-Start congestion window (in terms of MSS-sized segments), QS-cwnd, as follows:
TTLのDiffとレート要求のチェックが成功している、とTCPホストがクイックスタート要求を使用しようとしている、それはクイックスタートレスポンスを受け取るの1往復時間以内にそれを使用して起動、または3内でなければならない場合いずれか小さい方秒、。次のようにクイックスタート要求を使用するために、ホストは、（MSSサイズのセグメントに関して）そのクイックスタート輻輳ウィンドウを設定し、QS-CWND：
QS-cwnd = (R * T) / (MSS + H) (3) where R is the Rate Request in bytes per second, T is the measured round-trip time in seconds, and H is the estimated TCP/IP header size in bytes (e.g., 40 bytes).
QS-CWND =（R * T）/（MSS + H）Rは、秒あたりのバイト数でレート要求である場合（3）、Tは秒単位で測定された往復時間であり、Hは、推定されたTCP / IPヘッダサイズでありますバイト単位（例えば、40バイト）。
Derivation: the sender is allowed to transmit at R bytes per second including packet headers, but only R*MSS/(MSS+H) bytes per second, or equivalently R*T*MSS/(MSS+H) bytes per round-trip time, of application data.
派生：送信者がRで送信することが許可され、パケットヘッダを含む秒あたりのバイト数が、唯一のR * MSS /（MSS + H）は、秒あたりのバイト数、または等価的にR * T * MSS /（MSS + H）が往復当たりのバイトアプリケーションデータの時、。
The TCP host SHOULD set its congestion window cwnd to QS-cwnd only if QS-cwnd is greater than cwnd; otherwise, QS-cwnd is ignored. If QS-cwnd is used, the TCP host sets a flag that it is in Quick-Start mode, and while in Quick-Start mode, the TCP sender MUST use rate-based pacing to pace out Quick-Start packets at the approved rate. If, during Quick-Start mode, the TCP sender receives ACKs for packets sent before this Quick-Start mode was entered, these ACKs are processed as usual, following the default congestion control mechanisms. Quick-Start mode ends when the TCP host receives an ACK for one of the Quick-Start packets.
TCPホストは、QS-にcwndがcwndは以上である場合にのみ、QS-のcwndにその輻輳ウィンドウcwndを設定すべきです。それ以外の場合は、QS-にcwndは無視されます。 QS-のcwndを使用する場合、TCPホストは、クイックスタートモードであるフラグを設定し、クイックスタートモードでは、TCPの送信者は、承認されたレートでクイックスタートパケットをペーシングするレートベースペーシングを使用する必要がありますが。 、クイックスタートモード中に、TCPの送信者は、このクイックスタートモードに入る前に送信されるパケットのACKを受信した場合、これらのACKは、デフォルトの輻輳制御メカニズム以下、いつものように処理されます。 TCPホストがクイックスタートパケットのいずれかのACKを受信したときにクイックスタートモードが終了します。
If the congestion window has not been fully used when the first ack arrives ending the Quick-Start mode, then the congestion window is decreased to the amount that has actually been used so far. This is necessary because when the Quick-Start Response is received, the TCP sender's round-trip-time estimate might be longer than for succeeding round-trip times, e.g., because of delays at routers processing the IP Quick-Start Option, or because of delays at the receiver in responding to the Quick-Start Request packet. In this case, an overly large round-trip-time estimate could have caused the TCP sender to translate the approved Quick-Start sending rate in bytes per second into a congestion window that is larger than needed, with the TCP sender receiving an ACK for the first Quick- Start packet before the entire congestion window has been used. Thus, when the TCP sender receives the first ACK for a Quick-Start packet, the sender MUST reduce the congestion window to the amount that has actually been used.
最初のACKがクイックスタートモードを終了到着したときに輻輳ウィンドウが完全に使用されていない場合には、輻輳ウィンドウは、実際にこれまで使用されている量まで減少しています。クイックスタートレスポンスを受信したときに、TCP送信者の往復時間の見積もりが長い往復時間を、後続のためのより可能性があるためこれは、IPクイック・スタート・オプションを処理するルータでの遅延の、またはので、例えば、必要ですクイックスタートRequestパケットへの対応に受信機での遅延の。この場合には、過度に大きなラウンドトリップ時間推定はのためのACKを受信TCP送信側で、必要以上に大きい輻輳ウィンドウに秒あたりのバイト数で承認されたクイックスタート送信レートを変換するTCPの送信者が発生することがありました全体の輻輳ウィンドウの前に最初のQuick-スタートパケットが使用されてきました。このように、TCPの送信者はクイックスタートパケットの最初のACKを受信すると、送信者が実際に使用されている量に輻輳ウィンドウを縮小しなければなりません。
As an example, a TCP sender with an approved Quick-Start Request of R KBps, B-byte packets including headers, and an RTT estimate of T seconds, would translate the Rate Request of R KBps to a congestion window of R*T/B packets. The TCP sender would send the Quick-Start packets rate-paced at R KBps. However, if the actual current round-trip time was T/2 seconds instead of T seconds, then the sender would begin to receive acknowledgements for Quick-Start packets after T/2 seconds. Following the paragraph above, the TCP sender would then reduce its congestion window from R*T/B to approximately R*T/(B*2) packets, the actual number of packets that were needed to fill the pipe at a sending rate of R KBps. (Note: this is just an illustration; the congestion window is actually set to the amount of data sent before the ACK arrives and not based on equations above.)
たとえば、RのKbpsでの承認されたクイックスタート要求にTCPの送信者として、ヘッダを含むBバイトのパケット、およびT秒のRTT推定値は、Rの輻輳ウィンドウにRのKBPSのレート要求を翻訳します* T / Bパケット。クイックスタートを送信し、TCPの送信者は、レートペースRのKbpsでパケット。実際、現在の往復時間がT / 2秒の代わりに、T秒だった場合は、送信者は、T / 2秒後にクイックスタートパケットの確認応答を受信し始めます。上記段落以下、TCP送信者は、次いで、約R * T /（B * 2）パケットにR * T / Bからの送信速度でパイプを満たすために必要とされたパケットの実際の数を、その輻輳ウィンドウを減少させますRのkbpsの。 （注：これは単なる例示であり、ACKは、上記の式に基づいて、到達していない前に、輻輳ウィンドウは、実際に送信されるデータの量に設定されています。）
After Quick-Start mode is exited and the congestion window adjusted if necessary, the TCP sender returns to using the default congestion-control mechanisms, processing further incoming ACK packets as specified by those congestion control mechanisms. For example, if the TCP sender was in slow-start prior to the Quick-Start Request, and no packets were lost or marked since that time, then the sender continues in slow-start after exiting Quick-Start mode, as allowed by ssthresh.
クイックスタートモードが終了し、必要に応じて輻輳ウィンドウを調整した後、それらの輻輳制御機構によって指定され、さらに、受信ACKパケットを処理し、デフォルトの輻輳制御機構を使用するTCP送信者に戻ります。 SSTHRESHによって許可されたTCPの送信者がでた場合たとえば、クイックスタート要求する前にスロースタート、およびパケットがその時以来失われないか、マークされた、送信者は、クイックスタートモードを終了した後、スロースタートで継続します。
To add robustness, the TCP sender MUST use Limited Slow-Start [RFC3742] along with Quick-Start. With Limited Slow-Start, the TCP sender limits the number of packets by which the congestion window is increased for one window of data during slow-start.
堅牢性を追加するには、TCPの送信者は、クイックスタートと一緒に限定スロースタート[RFC3742]を使用しなければなりません。リミテッドスロースタートでは、TCPの送信側は、輻輳ウィンドウは、スロースタート時のデータの一つのウィンドウのために増加することにより、パケットの数を制限します。
When Quick-Start is used at the beginning of a connection, before any packet marks or losses have been reported, the TCP host MAY use the reported Rate Request to set the slow-start threshold to a desired value, e.g., to some small multiple of the congestion window. A possible future research topic is how the sender might modify the slow-start threshold at the beginning of a connection to avoid overshooting the path capacity. (The initial value of ssthresh is allowed to be arbitrarily high, and some TCP implementations use the size of the advertised window for ssthresh [RFC2581].)
任意のパケットマークまたは損失が報告されている前に、クイックスタートは、接続の開始時に使用されている場合は、TCPホストは、いくつかの小さな倍数に、例えば、所望の値にスロースタートしきい値を設定すると報告レート要求を使用するかもしれ輻輳ウィンドウの。将来の研究課題は、送信者が、パスの容量をオーバーシュートを避けるために、接続の開始時にスロースタートしきい値を変更する可能性がある方法です。 （SSTHRESHの初期値を任意に高いことが許可され、そしていくつかのTCP実装はSSTHRESH [RFC2581]のための広告ウィンドウのサイズを使用します。）
When a Quick-Start Request is approved for a TCP sender, the resulting Quick-Start data traffic can result in a sudden increase in traffic for pure ACK packets on the reverse path. For example, for the largest Quick-Start Request of 1.3 Gbps, given a TCP sender with 1500-byte packets and a TCP receiver with delayed acknowledgements acking every other packet, this could result in 17.3 Mbps of acknowledgement traffic on the reverse path.
クイックスタート要求がTCP送信者が承認されると、結果としてクイックスタートデータトラフィックは逆の経路上の純粋なACKパケットのトラフィックの急激な増加につながることができます。たとえば、1500バイトのパケットと他のすべてのパケットを肯定応答（ACK）遅延確認応答とTCP受信機とのTCPの送信者を指定した1.3 Gbpsの最大のクイックスタート要求のために、これは逆の経路上の承認トラフィックの17.3 Mbpsのにつながる可能性があります。
One possibility, in cases with large Quick-Start Requests, would be for TCP receivers to send Quick-Start Requests to request bandwidth for the acknowledgement traffic on the reverse path. However, in our view, a better approach would be for TCP receivers to simply control the rate of sending acknowledgement traffic. The optimal future solution would involve the explicit use of congestion control for TCP acknowledgement traffic, as is done now for the acknowledgement traffic in DCCP's CCID2 [RFC4341].
一つの可能性は、大規模なクイックスタート要求を持つ場合には、逆の経路上の承認トラフィックの帯域幅を要求するクイックスタート要求を送信するためにTCP受信機のためになります。しかし、我々の見解では、より良いアプローチは、単に確認応答トラフィックを送信する速度を制御するTCP受信機のためになります。 DCCPのCCID2 [RFC4341]で確認トラフィックのために今行われているように、最適な将来のソリューションは、TCP確認応答トラフィックの輻輳制御を明示的に使用を伴うだろう。
In the absence of congestion control for acknowledgement traffic, the TCP receiver could limit its sending rate for ACK packets sent in response to Quick-Start data packets. The following information is needed by the TCP receiver:
承認交通のための輻輳制御がない場合には、TCP受信機はクイックスタートデータパケットに応答して送信されるACKパケットのその送信レートを制限することができます。以下の情報は、TCP受信機によって必要とされています。
* The RTT: TCP naturally measures the RTT of the path and therefore should have a sample of the RTT. If the TCP receiver does not have a measurement of the round-trip time, it can use the time between the receipt of the Quick-Start Request and the Report of Approved Rate.
* RTT：TCPは、当然、パスのRTTを測定し、したがって、RTTのサンプルを持っている必要があります。 TCP受信機が往復時間の測定を持っていない場合は、クイックスタート要求と承認率の報告書の受領の間の時間を使うことができます。
* The Approved Rate Request (R): When the TCP receiver receives the Quick-Start Response packet, the receiver knows the value of the approved Rate Request.
*承認されたレート要求（R）：TCP受信機はクイックスタート応答パケットを受信すると、受信機が承認されたレート要求の値を知っています。
* The MSS: TCP advertises the MSS during the initial three-way handshake; therefore, the receiver should have an understanding of the packet size the sender will be using. If the receiver does not have such an understanding or wishes to confirm the negotiated MSS, the size of the first data packet can be used.
* MSS：TCPは、最初の3ウェイハンドシェイク中にMSSをアドバタイズ。そのため、受信側は送信者が使用するパケットのサイズを理解している必要があります。受信機は、このような理解を持っているか、ネゴシエートMSSを確認することを希望しない場合は、最初のデータ・パケットのサイズを使用することができます。
With this set of information, the TCP receiver can restrict its sending rate for pure acknowledgment traffic to at most 100 pure ACK packets per RTT by sending at most one ACK for every K data packets, for the ACK Ratio K set to R*RTT/(100*8*MSS). The receiver would acknowledge the first Quick-Start data packet, and every succeeding K data packets. Thus, for a somewhat extreme case of R=1.3 Gbps, RTT=0.2 seconds, and MSS=1500 bytes, K would be set to 216, and the receiver would acknowledge every 216 data packets. From [RFC2581], the ACK Ratio K should have a minimum value of two. When the ACK Ratio is greater than two, and the TCP sender receives acknowledgements each acknowledging more than two data packets, the TCP sender may want to use rate-based pacing to control the burstiness of its outgoing data traffic.
情報のこのセットでは、TCP受信機は/ * Rに設定されACK比Kのために、すべてのK個のデータパケットに対して最大1つのACKを送信することにより、RTTあたり最大で100の純粋なACKパケットにRTTを純粋承認トラフィックのその送信レートを制限することができます（100 * 8 * MSS）。受信機は、最初のクイックスタートデータパケット、およびすべての後続のKデータパケットを認めるだろう。したがって、R = 1.3 Gbpsの、RTT = 0.2秒、及びMSS = 1500バイトの多少極端な場合のために、Kは216に設定される、受信機は、すべての216のデータパケットを認めるであろう。 [RFC2581]から、ACK比率Kは、2の最小値を有するべきです。 ACK比が2より大きく、送信側が受信したTCPは、それぞれ二つ以上のデータパケットを認める謝辞場合は、TCPの送信者は、その送信データトラフィックのバースト性を制御するためにレートベースペーシングを使用したい場合があります。
In the absence of explicit congestion control mechanisms, the TCP end nodes cannot determine the packet drop rate for pure acknowledgement traffic. This is true with or without Quick-Start. However, the TCP receiver could limit its increase in the sending rate for pure ACK packets by at most doubling the sending rate for pure ACK packets from one round-trip time to the next. The TCP receiver would do this by halving the ACK Ratio each round-trip time.
明示的な輻輳制御機構の非存在下で、TCPのエンドノードは、純粋な肯定応答トラフィックのパケットドロップ率を決定することができません。これは、クイックスタートの有無にかかわらず真です。しかし、TCP受信機は最大1つのラウンドトリップ時間から次へと純粋なACKパケットの送信レートを2倍にすることにより、純粋なACKパケットの送信レートでの増加を制限することができます。 TCP受信機はACK比率に各ラウンドトリップ時間を半分にすることにより、これを行うだろう。
Note that the above is one particular mechanism that could be used to control the ACK stream. Future work that investigates this scheme and others in detail is encouraged.
上記は、ACKストリームを制御するために使用することができる一つの特定のメカニズムであることに留意されたいです。詳細にこのスキームなどを調査し、将来の作業が奨励されています。
For TCP, we have defined a "Quick-Start packet" as one of the packets sent in the window immediately following a successful Quick-Start Request. After detecting the loss or ECN-marking of a Quick-Start packet, TCP MUST revert to the default congestion control procedures that would have been used if the Quick-Start Request had not been approved. For example, if Quick-Start is used for setting the initial window, and a packet from the initial window is lost or marked, then the TCP sender MUST then slow-start with the default initial window that would have been used if Quick-Start had not been used. In addition to reverting to the default congestion control mechanisms, the sender MUST take into account that the Quick-Start congestion window was too large. Thus, the sender SHOULD decrease ssthresh to, at most, half the number of Quick-Start packets that were successfully transmitted. Appendix B.5 discusses possible alternatives in responding to the loss of a Quick-Start packet.
TCPのために、私たちはすぐに成功したクイックスタート要求を次のウィンドウに送られたパケットの1つとして、「クイックスタートパケット」を定義しています。クイックスタートパケットの損失やECNマーキングを検出した後、TCPは、クイックスタート要求が承認されていない場合に使用されていたであろう、デフォルトの輻輳制御手順に元に戻す必要があります。例えば、クイックスタートは、初期ウィンドウを設定するために使用されている場合、初期ウィンドウからのパケットが失われたり、マークされ、その後、TCP送信者は、クイックスタートした場合に使用されていたであろう、デフォルトの初期画面でスロースタートしなければなりません使用されていませんでした。デフォルトの輻輳制御機構への復帰に加え、送信者は、クイックスタートの輻輳ウィンドウがあまりにも大きかったことを考慮しなければなりません。したがって、送信者は、せいぜい、に正常に送信されたクイックスタートパケットの数の半分をSSTHRESHを減少させるはずです。付録B.5は、クイックスタートパケットの損失への対応に可能な選択肢について説明します。
If a Quick-Start packet is lost or ECN-marked, then the sender SHOULD NOT make future Quick-Start Requests for this connection.
クイックスタートパケットが失われたり、ECN-マークされている場合、送信者は、この接続のための今後のクイックスタート要求を行うべきではありません。
We note that ECN [RFC3168] MAY be used with Quick-Start. As is always the case with ECN, the sender's congestion control response to an ECN-marked Quick-Start packet is the same as the response to a dropped Quick-Start packet, thus reverting to slow start in the case of Quick-Start packets marked as experiencing congestion.
私たちは、ECN [RFC3168]はクイックスタートで使用することができることに注意してください。常にECNの場合と同様に、ECN-マーククイックスタートパケットに送信側の輻輳制御応答は、このようにマーククイックスタートパケットの場合に開始を遅らせるために戻す、ドロップクイックスタートパケットに対する応答と同じです混雑を経験として。
Some of the issues of using Quick-Start are related to the specific scenario in which Quick-Start is used. This section discusses the following issues that arise when Quick-Start is used by TCP to request a larger initial window: (1) interactions with Path MTU Discovery (PMTUD); and (2) Quick-Start Request packets that are discarded by middleboxes.
クイックスタートを使用しての問題の一部は、クイックスタートが使用される特定のシナリオに関連しています。このセクションでは、クイックスタートが大きな初期ウィンドウ要求するためにTCPで使用されるときに発生する、次の問題について説明します。パスMTUディスカバリ（PMTUD）と（1）の相互作用を。及び（2）ミドルボックスによって破棄されているクイックスタートRequestパケット。
One issue when Quick-Start is used to request a large initial window concerns the interactions between the large initial window and Path MTU Discovery. Some of the issues are discussed in RFC 3390:
クイックスタートが大きい初期ウィンドウを要求するために使用される1つの問題は、大きな初期ウィンドウとパスMTUディスカバリーの間の相互作用に関するものです。問題の一部は、RFC 3390で説明されています。
"When larger initial windows are implemented along with Path MTU Discovery [RFC1191], alternatives are to set the `Don't Fragment' (DF) bit in all segments in the initial window, or to set the `Don't Fragment' (DF) bit in one of the segments. It is an open question as to which of these two alternatives is best."
「大きな初期ウィンドウがパスMTUディスカバリー[RFC1191]に沿って実装されている場合は、代替案は（ 『初期ウィンドウ内のすべてのセグメントに（DF）ビット、または`フラグメント不可に設定する』`分割不可を設定していますセグメントの一つでDF）ビット。それは最善であるこれら二つの選択肢のどちらにオープン質問です。」
If the sender knows the Path MTU when the initial window is sent (e.g., from a PMTUD cache or from some other IETF-approved method), then the sender SHOULD use that MTU for segments in the initial window. Unfortunately, the sender doesn't necessarily know the Path MTU when it sends packets in the initial window. In this case, the sender should be conservative in the packet size used. Sending a large number of overly large packets with the DF bit set is not desirable, but sending a large number of packets that are fragmented in the network can be equally undesirable.
送信側は初期画面が送信されるパスMTU（例えば、PMTUDキャッシュから、またはいくつかの他のIETF承認法から）を知っている場合、送信側は初期ウィンドウ内のセグメントのためにそのMTUを使用すべきです。それが最初のウィンドウでパケットを送信する場合残念ながら、送信者は必ずしもパスMTUを知りません。この場合、送信者が使用するパケットのサイズは保守的でなければなりません。 DFビットが設定された過度に大多数のパケットを送信することは望ましくないが、ネットワークに断片化されたパケットを大量に送信することも同様に望ましくないとすることができます。
If the sender doesn't know the Path MTU when the initial window is sent, the sender SHOULD send one large packet in the initial window with the DF bit set, and send the remaining packets in the initial window with a smaller MTU of 576 bytes (or 1280 bytes with IPv6).
送信者は、初期ウィンドウが送信されたときに、送信者はDFビットが設定された初期ウィンドウに一つの大きなパケットを送信し、576バイトの小さいMTUと初期画面に残っているパケットを送信すべきであるパスMTUを知らない場合には（IPv6で又は1280バイト）。
A second possibility would be for the sender to delay sending the Quick-Start Request for one round-trip time by sending the Quick-Start Request with the first window of data, while also doing Path MTU Discovery.
第二の可能性はまた、パスMTUディスカバリをしている間、データの最初のウィンドウとクイックスタートリクエストを送信することにより、1往復時間のためのクイックスタートリクエストを送信遅らせるために、送信者のためになります。
The sender may be using an iterative approach such as Packetization Layer Path MTU Discovery (PLPMTUD) [MH06] for Path MTU Discovery, where the sender tests successively larger MTUs. If a probe is successfully delivered, then the MTU can be raised to reflect the value used in that probe. We would note that PLPMTUD does not allow the sender to determine the Path MTU before sending the initial window of data.
送信者は、パスMTU探索のためのパケット化層のパスMTU探索（PLPMTUD）[MH06]、送信テスト順次大きいのMTUとして反復的なアプローチを用いてもよいです。プローブが正常に配信されている場合は、MTUはそのプローブに使用される値を反映して上昇させることができます。私たちは、PLPMTUDは、送信者がデータの初期ウィンドウを送信する前にパスMTUを決定することはできませんのでご注意ます。
4.7.2. Quick-Start Request Packets that are Discarded by Routers or Middleboxes
4.7.2. ルータまたはのMiddleboxesによって破棄されているクイックスタート要求パケット
It is always possible for a TCP SYN packet carrying a Quick-Start request to be dropped in the network due to congestion, or to be blocked due to interactions with routers or middleboxes, where a middlebox is defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host [RFC3234]. Measurement studies of interactions between transport protocols and middleboxes [MAF04] show that for 70% of the Web servers investigated, no connection is established if the TCP SYN packet contains an unknown IP option (and for 43% of the Web servers, no connection is established if the TCP SYN packet contains an IP TimeStamp Option). In both cases, this is presumably due to routers or middleboxes along that path.
これは、輻輳によるネットワークで廃棄されるクイックスタート要求を搬送するTCP SYNパケットを常に可能である、又はによるミドルボックスは別に機能を実行する任意の中間のボックスとして定義されているルータ又は中間装置との相互作用にブロックしますソースホストと宛先ホスト[RFC3234]の間のデータ経路上のIPルータの通常の、標準機能。トランスポートプロトコルとミドルボックス[MAF04]との間の相互作用の測定の研究では、Webサーバーの70％が調査のためのTCP SYNパケットが不明なIPオプションが含まれている場合は、何も接続が確立されていない（とWebサーバの43％のため、何も接続されていないことを示していますTCP SYNパケットがIPタイムスタンプオプションが含まれている場合）を設立しました。両方の場合において、これは、その経路に沿ったルータ又は中間装置におそらく起因しています。
If the TCP sender doesn't receive a response to the SYN or SYN/ACK packet containing the Quick-Start Request, then the TCP sender SHOULD resend the SYN or SYN/ACK packet without the Quick-Start Request.
TCPの送信者がクイックスタート要求を含むSYNまたはSYN / ACKパケットに対する応答を受信しない場合には、TCPの送信者は、クイックスタート要求せずにSYNまたはSYN / ACKパケットを再送する必要があります。
Similarly, if the TCP sender receives a TCP reset in response to the SYN or SYN/ACK packet containing the Quick-Start Request, then the TCP sender SHOULD resend the SYN or SYN/ACK packet without the Quick-Start Request [RFC3360].
TCP送信者がクイックスタート要求を含むSYNまたはSYN / ACKパケットに応答してTCPリセットを受信した場合、同様に、次に、TCP送信者は、クイックスタート要求[RFC3360]なしSYNまたはSYN / ACKパケットを再送すべきです。
RFCs 1122 and 2988 specify that the sender should set the initial RTO (retransmission timeout) to three seconds, though many TCP implementations set the initial RTO to one second. For a TCP SYN packet sent with a Quick-Start request, the TCP sender SHOULD use an initial RTO of three seconds.
RFC 1122および2988には、多くのTCP実装は1秒に初期RTOを設定しても、送信者が、3秒に初期RTO（再送タイムアウト）を設定する必要があることを指定します。クイックスタート要求で送信されたTCP SYNパケットの場合は、TCPの送信側は3秒の初期RTOを使用すべきです。
We note that if the TCP SYN packet is using the IP Quick-Start Option for a Quick-Start Request, and it is also using bits in the TCP header to negotiate ECN-capability with the TCP host at the other end, then the drop of a TCP SYN packet could be due to congestion, a router or middlebox dropping the packet because of the IP Option, or a router or middlebox dropping the packet because of the information in the TCP header negotiating ECN. In this case, the sender could resend the dropped packet without either the Quick-Start or the ECN requests. Alternately, the sender could resend the dropped packet with only the ECN request in the TCP header, resending the TCP SYN packet without either the Quick-Start or the ECN requests if the second TCP SYN packet is dropped. The second choice seems reasonable, given that a TCP SYN packet today is more likely to be blocked due to policies that discard packets with IP Options than due to policies that discard packets with ECN requests in the TCP header [MAF04].
私たちは、TCP SYNパケットがクイックスタート要求のためのIPクイック・スタート・オプションを使用している、そしてまた、ドロップ、その後、もう一方の端にTCPホストとECN-の能力を交渉するためにTCPヘッダー内のビットを使用している場合ことに注意してくださいTCP SYNパケットの、輻輳によるため、IPオプション、またはECNを交渉TCPヘッダであるため情報のパケットを落とすルータやミドルのパケットを落とすルータまたはミドルとすることができます。この場合、送信者は、クイックスタートやECN要求のいずれかなしにドロップされたパケットを再送することができます。代わりに、送信者は、第二のTCP SYNパケットがドロップされた場合はクイックスタートやECN要求のいずれかなしにTCP SYNパケットを再送する、TCPヘッダー内のみECN要求にドロップされたパケットを再送することができます。 2番目の選択肢は、今日は、TCPヘッダ[MAF04]でECN要求のパケットを破棄する方針に起因するよりもIPオプションを持つパケットを廃棄したポリシーのためにブロックされる可能性が高いTCP SYNパケットことを考えると、妥当なようです。
This section discusses the following issues that arise when Quick-Start is used by TCP to request a larger window in the middle of a connection, such as after an idle period: (1) determining the rate to request; (2) when to make a request; and (3) the response if Quick-Start packets are dropped.
このセクションでは、クイックスタートは、このようなアイドル期間の後に、接続の途中でより大きなウィンドウを要求するためにTCPによって使用されるときに生じる次の問題について説明：（1）要求するレートを決定します。 （2）場合、要求を作ります。 （3）レスポンスクイックスタートパケットが破棄された場合。
(1) Determining the rate to request: For a connection that has not yet had a congestion event (that is, a marked or dropped packet), the TCP sender is not restricted in the rate that it requests. As an example, a server might wait and send a Quick-Start Request after a short interaction with the client.
（1）要求に対する割合の決定：まだ輻輳イベントを持っていない接続の場合（つまり、マークまたはドロップされたパケット）、TCPの送信者は、それが要求した料金に限定されるものではありません。例として、サーバはクライアントとの短い対話後のクイックスタート要求を待って送信することがあります。
To use a Quick-Start Request in a connection that has already
experienced a congestion event, and that has not had a recent
mobility event, the TCP sender can determine the largest
congestion window that the TCP connection achieved since the last
packet drop and translate this to a sending rate to get the maximum allowed request rate. If the request is granted, then
the sender essentially restarts with its old congestion window
from before it was reduced, for example, during an idle period.
A Quick-Start Request sent in the middle of a TCP connection SHOULD be sent on a data packet.
TCPコネクションの途中で送信されたクイックスタート要求は、データパケットに送ってください。
(2) When to make a request: A TCP connection MAY make a Quick-Start Request before the connection has experienced a congestion event, or after an idle period of at least one RTO.
（2）場合は、要求を作成するには：接続が輻輳イベントを経験した、または少なくとも一つのRTOのアイドル期間の後にする前にTCP接続がクイックスタート要求を行うことができます。
(3) Response if Quick-Start packets are dropped: If Quick-Start packets are dropped in the middle of connection, then the sender MUST revert to half the Quick-Start window, or to the congestion window that the sender would have used if the Quick-Start request had not been approved, whichever is smaller.
クイックスタートパケットは、接続の途中で破棄された場合、送信者は半分クイックスタート画面に戻す、または送信者があれば使用していた輻輳ウィンドウにしなければならない：クイックスタートパケットが破棄された場合（3）の対応クイックスタート要求はいずれか小さい方、承認されていませんでした。
The following is an example scenario of when both hosts request Quick-Start for setting their initial windows. This is similar to Figures 1 and 2 in Section 2.1, except that it illustrates a TCP connection with both TCP hosts sending Quick-Start Requests.
以下は、両方のホストが彼らの最初のウィンドウを設定するためのクイックスタートを要求した場合のシナリオの例です。これは、クイック・スタート・リクエストを送信して、両方のTCPホストとのTCP接続を示していることを除いて、2.1節で、図1および図2と同様です。
* The TCP SYN packet from Host A contains a Quick-Start Request in the IP header.
*ホストAからのTCP SYNパケットは、IPヘッダ内のクイックスタート要求が含まれています。
* Routers along the forward path modify the Quick-Start Request as appropriate.
*往路ルータは、必要に応じて、クイックスタート要求を変更します。
* Host B receives the Quick-Start Request in the SYN packet, and calculates the TTL Diff. If Host B approves the Quick-Start Request, then Host B sends a Quick-Start Response in the TCP header of the SYN/ACK packet. Host B also sends a Quick-Start Request in the IP header of the SYN/ACK packet.
*ホストBは、SYNパケット内のクイックスタート要求を受信し、TTL差分を計算します。ホストBは、クイックスタートリクエストを承認する場合、ホストBはSYN / ACKパケットのTCPヘッダにクイックスタートレスポンスを送信します。ホストBはまた、SYN / ACKパケットのIPヘッダ内のクイックスタート要求を送信します。
* Routers along the reverse path modify the Quick-Start Request as appropriate.
*逆の経路に沿ってルータは、必要に応じて、クイックスタート要求を変更します。
* Host A receives the Quick-Start Response in the SYN/ACK packet, and checks the TTL Diff, Rate Request, and QS Nonce for validity. If they are valid, then Host A sets its initial congestion window appropriately, and sets up rate-based pacing to be used with the initial window. If the Quick-Start Response is not valid, then Host A uses TCP's default initial window. In either case, Host A sends a Report of Approved Rate.
*ホストAは、SYN / ACKパケット内のクイックスタートレスポンスを受信して、有効性のためにTTL差分、レート要求、およびQS nonceをチェックします。彼らが有効である場合、ホストAは、適切にその初期の輻輳ウィンドウを設定し、初期ウィンドウで使用するレートベースペーシングを設定します。クイックスタートレスポンスが有効でない場合、Aは、TCPのデフォルトの初期ウィンドウを使用するホスト。いずれの場合も、ホストAは、承認されたレートのレポートを送信します。
Host A also calculates the TTL Diff for the Quick-Start Request in the incoming SYN/ACK packet, and sends a Quick-Start Response in the TCP header of the ACK packet.
ホストも、着信SYN / ACKパケットでクイックスタート要求のTTL差分を算出し、ACKパケットのTCPヘッダにクイックスタート応答を送信します。
* Host B receives the Quick-Start Response in an ACK packet, and checks the TTL Diff, Rate Request, and QS Nonce for validity. If the Quick-Start Response is valid, then Host B sets its initial congestion window appropriately, and sets up rate-based pacing to be used with its initial window. If the Quick-Start Response is not valid, then Host B uses TCP's default initial window. In either case, Host B sends a Report of Approved Rate.
*ホストBは、ACKパケットにクイックスタートレスポンスを受信して、有効性のためにTTL差分、レート要求、およびQS nonceをチェックします。クイックスタート応答が有効である場合、ホストBは、適切にその初期の輻輳ウィンドウを設定し、その初期ウィンドウで使用するレートベースペーシングを設定します。クイックスタートレスポンスが有効でない場合、Bは、TCPのデフォルトの初期ウィンドウを使用するホスト。いずれの場合も、ホストBは、承認されたレートのレポートを送信します。
This section shows that Quick-Start is compatible with IPsec Authentication Header (AH). AH uses an Integrity Check Value (ICV) in the IPsec Authentication Header to verify both message authentication and integrity [RFC4302]. Changes to the Quick-Start Option in the IP header do not affect this AH ICV. The tunnel considerations in Section 6 below apply to all IPsec tunnels, regardless of what IPsec headers or processing are used in conjunction with the tunnel.
このセクションでは、クイックスタートのIPsec認証ヘッダ（AH）と互換性があることを示しています。 AHは、メッセージ認証及び完全性[RFC4302]の両方を検証するためのIPsec認証ヘッダ内のインテグリティ・チェック値（ICV）を使用します。 IPヘッダ内のクイックスタートオプションの変更点は、このAH ICVは影響を与えません。以下のセクション6にトンネルの考慮に関わらずのIPsecヘッダや処理がトンネルに関連して使用されるものの、すべてのIPSecトンネルに適用します。
Because the contents of the Quick-Start Option can change along the path, it is important that these changes not affect the IPsec Authentication Header Integrity Check Value (AH ICV). For IPv4, RFC 4302 requires that unrecognized IPv4 options be zeroed for AH ICV computation purposes, so Quick-Start IP Option data changing en route does not cause problems with existing IPsec AH implementations for IPv4. If the Quick-Start Option is recognized, it MUST be treated as a mutable IPv4 option, and hence be completely zeroed for AH ICV calculation purposes. IPv6 option numbers explicitly indicate whether the option is mutable; the third-highest order bit in the IANA-allocated option type has the value 1 to indicate that the Quick-Start Option data can change en route. RFC 4302 requires that the option data of any such option be zeroed for AH ICV computation purposes. Therefore, changes to the Quick-Start Option in the IP header do not affect the calculation of the AH ICV.
クイック・スタート・オプションの内容は、パスに沿って変更することができますので、これらの変更は、IPsecの認証ヘッダーの整合性がバリュー（AH ICV）をチェック影響を与えないことが重要です。 IPv4の場合、RFC 4302が認識されていないIPv4オプションは、IPv4の既存のIPsec AHの実装に問題が発生することはありませんので、クイックスタートIPオプションデータが途中で変更し、AH ICV計算のためにゼロにすることが必要です。クイック・スタート・オプションが認識されている場合は、変更可能なIPv4のオプションとして扱う必要があり、それゆえ完全にAH ICV計算目的のためにゼロにすること。 IPv6のオプション番号を明示的にオプションが変更可能であるかどうかを示します。 IANAに割り当てられたオプションタイプで三最上位ビットは、クイックスタートオプションデータが途中で変更することができることを示す値1を有しています。 RFC 4302には、どのようなオプションのオプションデータは、AH ICV計算のためにゼロにすることが必要です。そのため、IPヘッダ内のクイックスタート・オプションへの変更は、AH ICVの計算には影響を与えません。
This section considers interactions between Quick-Start and IP tunnels, including IPsec ([RFC4301]), IP in IP [RFC2003], GRE [RFC2784], and others. This section also considers interactions between Quick-Start and MPLS [RFC3031].
このセクションでは、IPsec（[RFC4301]）、IPにおけるIP [RFC2003]、GRE [RFC2784]、およびその他を含むクイックスタートとIPトンネルとの間の相互作用を考慮する。このセクションでは、クイックスタートやMPLS [RFC3031]の間の相互作用を考慮します。
In the discussion, we use TTL Diff, defined earlier as the difference between the IP TTL and the Quick-Start TTL, mod 256. Recall that the sender considers the Quick-Start Request approved only if the value of TTL Diff for the packet entering the network is the same as the value of TTL Diff for the packet exiting the network.
議論では、我々はIP TTLおよびクイックスタートTTL、送信側はパケットのTTL差分の値が入っている場合のみ、承認されたクイックスタート要求を考慮することのmod 256リコールの差として定義され、以前のTTL差分を、使用しますネットワークは、ネットワークから出るパケットのTTL差分の値と同じです。
Simple tunnels: IP tunnel modes are generally based on adding a new "outer" IP header that encapsulates the original or "inner" IP header and its associated packet. In many cases, the new "outer" IP header may be added and removed at intermediate points along a path, enabling the network to establish a tunnel without requiring endpoint participation. We denote tunnels that specify that the outer header be discarded at tunnel egress as "simple tunnels", and we denote tunnels where the egress saves and uses information from the outer header before discarding it as "non-simple tunnels". An example of a "non-simple tunnel" would be a tunnel configured to support ECN, where the egress router might copy the ECN codepoint in the outer header to the inner header before discarding the outer header [RFC3168].
単純なトンネル：IPトンネルモードは、一般に、元のまたは「内側」IPヘッダとそれに関連するパケットをカプセル化する新しい「外側」IPヘッダを付加することに基づいています。多くの場合、新たな「外部」IPヘッダは、エンドポイントの参加を必要とせずにトンネルを確立するためにネットワークを可能にする経路に沿った中間点で添加し、除去することができます。我々は、外側のヘッダが「単純トンネル」としてトンネル出口で廃棄するように指定トンネルを示し、我々は、出力が保存され、「非単純なトンネル」としてそれを廃棄する前に、外部ヘッダからの情報を使用してトンネルを示します。 「非単純なトンネル」の例は、出口ルータは、外部ヘッダ[RFC3168]を廃棄する前に内側のヘッダーにアウターヘッダ内のECNコードポイントをコピーする可能性がECNをサポートするように設定されたトンネルであろう。
__ Tunnels Compatible with Quick-Start / Simple Tunnels __/ \ \__ Tunnels Not Compatible with Quick-Start (False Positives!)
__クイックスタート/シンプルトンネルとトンネルの互換性__ / \ \ __クイックスタートに対応していないトンネル（偽陽性！）
__ Tunnels Supporting Quick-Start
/
/
Non-Simple Tunnels __/_____ Tunnels Compatible with Quick-Start,
\ but Not Supporting Quick-Start
\
\__ Tunnels Not Compatible with Quick-Start?
Figure 6: Categories of Tunnels.
図6：トンネルのカテゴリー。
Tunnels that are compatible with Quick-Start: We say that an IP tunnel `is not compatible with Quick-Start' if the use of a Quick-Start Request over such a tunnel allows false positives, where the TCP sender incorrectly believes that the Quick-Start Request was approved by all routers along the path. If the use of Quick-Start over the tunnel does not cause false positives, we say that the IP tunnel `is compatible with Quick-Start'.
クイックスタートと互換性があるトンネル：我々は、TCPの送信者が誤ってクイックと考えているところ、このようなトンネルを介しクイックスタート要求の使用は、偽陽性を許可する場合は、IPトンネルは `「クイックスタートと互換性がないことを言います-start要求は、パスに沿ってすべてのルータによって承認されました。トンネル上のクイックスタートの使用は偽陽性を生じない場合、我々は、IPトンネルが `「クイックスタートと互換性があることを言います。
If the IP TTL of the inner header is decremented during forwarding before tunnel encapsulation takes place, then the simple tunnel is compatible with Quick-Start, with Quick-Start Requests being rejected. Section 6.1 describes in more detail the ways that a simple tunnel can be compatible with Quick-Start.
内部ヘッダのIP TTLは、トンネルカプセル化が行われる前に、転送中にデクリメントされる場合、単純なトンネルは拒否されるクイックスタート要求に、クイックスタートと互換性があります。 6.1節では、より詳細にシンプルなトンネルはクイックスタートと互換性を持つことができる方法について説明します。
There are some simple tunnels that are not compatible with Quick-Start, allowing `false positives' where the TCP sender incorrectly believes that the Quick-Start Request was approved by all routers along the path. This is discussed in Section 6.2 below.
TCPの送信者が誤っクイックスタート要求がパス上のすべてのルータによって承認されたと考えている `偽陽性を許可するクイックスタートと互換性がありませんいくつかの簡単なトンネルがあります。これは、以下のセクション6.2で説明されています。
One of our tasks in the future will be to investigate the occurrence of tunnels that are not compatible with Quick-Start, and to track the extent to which such tunnels are modified over time. The evaluation of the problem of false positives from tunnels that are not compatible with Quick-Start will affect the progression of Quick-Start from Experimental to Proposed Standard, and will affect the degree of deployment of Quick-Start while in Experimental mode.
将来における当社のタスクの1つは、クイックスタートと互換性がありませんトンネルの発生を調査するために、そして、そのようなトンネルが時間の経過とともに変更される範囲を追跡することになります。クイックスタートと互換性がありませんトンネルからの偽陽性の問題の評価は実験からのProposed Standardへのクイックスタートの進行に影響を与えるだろう、と実験モード中にクイックスタートの展開の度合いに影響を与えます。
Tunnels that support Quick-Start: We say that an IP tunnel `supports Quick-Start' if it allows routers along the tunnel path to process the Quick-Start Request and give feedback, resulting in the appropriate possible acceptance of the Quick-Start Request. Some tunnels that are compatible with Quick-Start support Quick-Start, while others do not. We note that a simple tunnel is not able to support Quick-Start.
私たちは、それがクイック・スタート・リクエストを処理し、フィードバックを与えるためにトンネルの経路に沿ってルータを許可する場合は、IPトンネルは `クイックスタート要求の適切な可能承諾が得られ、「クイックスタートをサポートしていることを言う：クイックスタートをサポートするトンネル。他の人がいない間クイックスタートと互換性があるいくつかのトンネルは、クイックスタートをサポートしています。私たちは、単純なトンネルはクイックスタートをサポートすることができないことに注意してください。
From a security point of view, the use of Quick-Start in the outer header of an IP tunnel might raise security concerns because an adversary could tamper with the Quick-Start information that propagates beyond the tunnel endpoint, or because the Quick-Start Option exposes information to network scanners. Our approach is to make supporting Quick-Start an option for IP tunnels. That is, in environments or tunneling protocols where the risks of using Quick-Start are judged to outweigh its benefits, the tunnel can simply delete the Quick-Start Option or zero the Quick-Start rate request and QS TTL fields before encapsulation. The result is that there are two viable options for IP tunnels to be compatible with Quick-Start. The first option is the simple tunnel described above and in Section 6.1, where the tunnel is compatible with Quick-Start but does not
セキュリティの観点から、IPトンネルの外側のヘッダー内のクイックスタートを使用すると、敵がトンネルのエンドポイントを超えて伝播するクイックスタート情報を改ざんする可能性があるため、セキュリティ上の懸念を提起、またはかもしれないクイック・スタート・オプション理由ネットワークスキャナに情報を公開しています。我々のアプローチは、IPトンネルのオプションをクイックスタート支援することです。これは、環境やクイックスタートを使用してのリスクが利益を上回ると判断されたトンネリングプロトコルでは、トンネルは、単にクイック・スタート・オプションを削除するか、カプセル化する前に、クイックスタートレート要求とQS TTLフィールドをゼロにすることができ、あります。その結果は、クイックスタートと互換性を持つようにするIPトンネルのための2つの実行可能な選択肢があるということです。最初のオプションは、単純なトンネルは、トンネルはクイックスタートと互換性がありませんが、6.1節、上に記載されています
support Quick-Start, where all Quick-Start Requests along the path will be rejected. The second approach is a Quick-Start-capable mode, described in Section 6.3, where the tunnel actively supports Quick-Start.
パス上のすべてのクイックスタートの要求が拒否されるクイックスタートをサポートしています。第2のアプローチは、トンネルが積極的にクイックスタートをサポートセクション6.3に記載のクイックスタート可能なモードです。
This section describes the ways that a simple tunnel can be compatible with Quick-Start but not support Quick-Start, resulting in the rejection of all Quick-Start Requests that traverse the tunnel.
このセクションでは、単純なトンネルはクイックスタートと互換性があるが、トンネルを通過するすべてのクイックスタート要求の拒絶をもたらす、クイックスタートをサポートすることができない方法を記載しています。
If the tunnel ingress for the simple tunnel is at a router, the IP TTL of the inner header is generally decremented during forwarding before tunnel encapsulation takes place. In this case, TTL Diff will be changed, correctly causing the Quick-Start Request to be rejected. For a simple tunnel, it is preferable if the Quick-Start Request is not copied to the outer header, saving the routers within the tunnel from unnecessarily processing the Quick-Start Request. However, the Quick-Start Request will be rejected correctly in this case whether or not the Quick-Start Request is copied to the outer header.
単純なトンネルのトンネル入口がルータである場合、トンネルカプセル化が行われる前に、内部ヘッダのIP TTLは、一般に、転送中にデクリメントされます。この場合、TTL差分が正しくクイックスタート要求が拒否される原因と、変更されます。クイックスタート要求が不必要クイックスタート要求を処理からトンネル内のルータの保存、外部ヘッダにコピーされていない場合は、単純なトンネルのために、それが好ましいです。しかし、クイックスタート要求はクイックスタート要求は外側のヘッダーにコピーされているかどうか、この場合に正しく拒否されます。
If a tunnel ingress is aware of Quick-Start, but does not want to support Quick-Start, then the tunnel ingress MUST either zero the Quick-Start rate request, QS TTL, and QS Nonce fields, or remove the Quick-Start Option from the inner header before encapsulation. Section 6.3 describes the procedures for a tunnel that does want to support Quick-Start.
トンネル入口は、クイックスタートを認識しているが、クイックスタートをサポートしたくない場合は、トンネル入口のいずれかクイックスタートレート要求、QS TTL、およびQS Nonceのフィールドをゼロ、またはクイック・スタート・オプションを削除する必要がありますカプセル化の前に内側のヘッダーから。 6.3節は、クイックスタートをサポートしたいんトンネルの手順を説明します。
Deleting the Quick-Start Option or zeroing the Quick-Start rate request *after decapsulation* also serves to prevent the propagation of Quick-Start information, and is compatible with Quick-Start. If the outer header does not contain a Quick-Start Request, a Quick-Start-aware tunnel egress MUST reject the inner Quick-Start Request by zeroing the Rate Request field in the inner header, or by deleting the Quick-Start Option.
*クイックスタート・オプションを削除するか、デカプセル化後のクイックスタートレート要求*をゼロにすることも、クイックスタート情報の伝播を防止するためのものであり、クイックスタートと互換性があります。外部ヘッダは、クイックスタート要求を含まない場合、クイックスタート対応トンネル出口は、内部ヘッダにレート要求フィールドをゼロにすることによって、またはクイックスタートオプションを削除して内側クイックスタート要求を拒絶しなければなりません。
If the tunnel ingress is at a sending host or router where the IP TTL is not decremented prior to encapsulation, and neither tunnel endpoint is aware of Quick-Start, then this allows false positives, described in the section below.
トンネル入口はIP TTLはカプセル化の前にデクリメントされ、どちらのトンネルエンドポイントは、クイックスタートを認識していない送信側ホストまたはルータである場合、これは、以下のセクションで説明し、偽陽性を可能にします。
Sometimes a tunnel implementation that does not support Quick-Start is independent of the TCP sender or a router implementation that supports Quick-Start. In these cases, it is possible that a Quick-Start Request gets erroneously approved without the routers in the tunnel having individually approved the request, causing a false positive.
時々、クイックスタートをサポートしていないトンネルの実装は、TCPの送信者やクイックスタートをサポートするルータの実装とは無関係です。これらの場合には、クイックスタート要求が誤っトンネルは、要求を承認個別有する偽陽性を引き起こすルータなしに承認されることを可能です。
If a tunnel ingress is a separate component from the TCP sender or IP forwarding, it is possible that a packet with a Quick-Start option is encapsulated without the IP TTL being decremented first, or with both IP TTL and QS TTL being decremented before the tunnel encapsulation takes place. If the tunnel ingress does not know about Quick-Start, a valid Quick-Start Request with unchanged TTL Diff traverses in the inner header, while the outer header most likely does not carry a Quick-Start Request. If the tunnel egress also does not support Quick-Start, it remains possible that the Quick-Start Request would be falsely approved, because the packet is decapsulated using the Quick-Start Request from the inner header, and the value of TTL Diff echoed to the sender remains unchanged. For example, such a scenario can occur with a Bump-In-The-Stack (BITS), an IPsec encryption implementation where the data encryption occurs between the network drivers and the TCP/IP protocol stack [RFC4301].
トンネル入口がTCP送信者またはIP転送とは別個の部品である場合には、クイック・スタート・オプションを使用してパケットをIP TTLが最初にデクリメントされず、又はIP TTLおよび前デクリメントさQS TTLの両方にカプセル化されることが可能ですトンネルカプセル化が行われます。トンネル入口は、クイックスタートについて知らない場合は、外側のヘッダーは、最も可能性の高いクイックスタート要求を運ぶことはありませんが、そのままTTLのDiffと有効なクイックスタートリクエストは、インナーヘッダに横断します。トンネル出口はまた、クイックスタートをサポートしていない場合、それは、パケットが内部ヘッダからクイックスタート要求を使用してデカプセル化されているため、クイックスタート要求が誤って、承認されることが可能なままであり、TTL差分の値にエコー送信者は変更されません。例えば、そのようなシナリオは、バンプ・イン・ザ・スタック（BITS）、データの暗号化は、ネットワークドライバとTCP / IPプロトコルスタック[RFC4301]の間で発生するIPSec暗号化の実装で発生することができます。
As one example, if a remote access VPN client uses a BITS structure, then Quick-Start obstacles between the client and the VPN gateway won't be seen. This is a particular problem because the path between the client and the VPN gateway is likely to contain the most congested part of the path. Because most VPN clients are reported to use BITS [H05], we will explore this in more detail.
リモートアクセスVPNクライアントがBITS構造を使用する場合、一例として、クライアントとVPNゲートウェイの間に障害物が見られることはありませんクイックスタート。クライアントとVPNゲートウェイ間のパスは、パスの最も混雑の部分が含まれている可能性があるので、これは特に問題です。ほとんどのVPNクライアントは、BITS [H05]を使用することが報告されているので、我々はこれをより詳細に見ていきます。
A Bump-In-The-Wire (BITW) is an IPsec encryption implementation where the encryption occurs on an outboard processor, offloading the encryption processing overhead from the host or router [RFC4301]. The BITW device is usually IP addressable, which means that the IP TTL is decremented before the packet is passed to the BITW. If the QS TTL is not decremented, then the value of TTL Diff is changed, and the Quick-Start Request will be denied. However, if the BITW supports a host and does not have its own IP address, then the IP TTL is not decremented before the packet is passed from the host to the BITW, and a false positive could occur.
バンプ・イン・ザ・ワイヤ（BITW）は、暗号化は、ホスト又はルータ[RFC4301]から暗号処理オーバーヘッドをオフロード、外側プロセッサ上で発生するIPSec暗号化の実装です。 BITWデバイスは、パケットがBITWに渡される前にIP TTLがデクリメントされていることを意味し、通常のIPアドレス指定可能です。 QS TTLをデクリメントされていない場合は、TTL差分の値が変更され、クイックスタート要求が拒否されます。 BITWがホストをサポートし、独自のIPアドレスを持っていない場合は、そのパケットがホストからBITWに渡される前に、IP TTLが減算されていない、と偽陽性が発生する可能性があります。
Other tunnels that need to be looked at are IP tunnels over non-network protocols, such as IP over TCP and IP over UDP [RFC3948], and tunnels using the Layer Two Tunneling Protocol [RFC2661].
見する必要がある他のトンネルは、レイヤ2トンネリングプロトコル[RFC2661]を使用して、このようなUDP上のTCPとIPオーバーIP [RFC3948]、およびトンネルなどの非ネットワーク・プロトコル、オーバーIPトンネルです。
Section 9.2 discusses the related issue of non-IP queues, such as layer-two Ethernet or ATM (Asynchronous Transfer Mode) networks, as another instance of possible bottlenecks that do not participate in the Quick-Start feedback.
9.2節は、クイックスタート、フィードバックに参加していない可能性のボトルネックの別のインスタンスとして、そのような層、2つのイーサネットまたはATM（非同期転送モード）ネットワークなどの非IPキューの関連問題について説明します。
This section discusses tunnels configured to support Quick-Start.
このセクションでは、クイックスタートをサポートするために構成されたトンネルについて説明します。
If the tunnel ingress node chooses to locally approve the Quick-Start Request, then the ingress node MUST decrement the Quick-Start TTL at the same time it decrements the IP TTL, and MUST copy IP TTL and the Quick-Start Option from the inner IP header to the outer header. During encapsulation, the tunnel ingress MUST zero the Quick-Start rate request field in the inner header to ensure that the Quick-Start Request will be rejected if the tunnel egress does not support Quick-Start.
トンネル入口ノードがローカルクイックスタート要求を承認することを選択した場合、その後、入口ノードはIP TTLをデクリメントし、同時にクイックスタートTTLをデクリメントしなければならない、およびIP TTLおよび内側からクイックスタートオプションをコピーする必要があります外部ヘッダのIPヘッダ。カプセル化の間、トンネル入口は、トンネル出口クイックスタートをサポートしていない場合、クイックスタート要求が拒否されることを保証するために、内部ヘッダでクイックスタートレート要求フィールドをゼロにしなければなりません。
If the tunnel ingress node does not choose to locally approve the Quick-Start Request, then it MUST either delete the Quick-Start option from the inner header before encapsulation, or zero the QS TTL and the Rate Request fields before encapsulation.
トンネル入口ノードは、クイックスタートリクエストを承認、それはカプセル化の前に、内部ヘッダからクイックスタートオプションを削除、またはカプセル化の前にQS TTLおよびレート要求フィールドをゼロにしなければならない、ローカルに選択しない場合。
Upon decapsulation, if the outer header contains a Quick-Start option, the tunnel egress MUST copy the IP TTL and the Quick-Start option from the outer IP header to the inner header.
外部ヘッダは、クイック・スタート・オプションが含まれている場合デカプセル化の際、トンネル出口は、内部ヘッダに外側のIPヘッダからIP TTLおよびクイック・スタート・オプションをコピーする必要があります。
IPsec uses the IKE (Internet Key Exchange) Protocol for security associations. We do not consider the interactions between Quick-Start and IPsec with IKEv1 [RFC2409] in this document. Now that the RFC for IKEv2 [RFC4306] is published, we plan to specify a modification of IPsec to allow the support of Quick-Start to be negotiated; this modification will specify the negotiation between tunnel endpoints to allow or forbid support for Quick-Start within the tunnel. This was done for ECN for IPsec tunnels, with IKEv1 [RFC3168, Section 9.2]. This negotiation of Quick-Start capability in an IPsec tunnel will be specified in a separate IPsec document. This document will also include a discussion of the potential effects of an adversary's modifications of the Quick-Start field (as in Sections 18 and 19 of RFC 3168), and of the security considerations of exposing the Quick-Start rate request to network scanners.
IPsecは、セキュリティアソシエーションのIKE（Internet Key Exchange）プロトコルを使用しています。私たちは、この文書に記載されているのIKEv1 [RFC2409]でクイックスタートとIPsecの間の相互作用を考慮していません。今のIKEv2 [RFC4306]のためのRFCが公開されていることを、私たちは、クイックスタートのサポートを交渉することができるようにするには、IPSecの変更を指定することを計画します。この変更は、トンネル内のクイックスタートのサポートを許可または禁止するトンネルエンドポイント間の交渉を指定します。これはIKEv1の[RFC3168、セクション9.2]で、IPsecトンネルのためのECNのために行きました。 IPsecトンネルでのクイックスタート機能のこの交渉は、別のIPsec文書で指定されます。また、このドキュメントは（セクション18及びRFC 3168の19のように）、およびネットワークスキャナへクイックスタートレート要求を露出させるのセキュリティ問題のクイックスタートフィールドの敵の変更の潜在的な効果の説明を含むことになります。
The behavior of Quick-Start with MPLS is similar to the behavior of Quick-Start with IP Tunnels. For those MPLS paths where the IP TTL is decremented as part of traversing the MPLS path, these paths are compatible with Quick-Start, but do not support Quick-Start; Quick-
MPLSとクイックスタートの振る舞いは、IPトンネルを使ったクイックスタートの動作に似ています。 IP TTLがMPLSパスを横切るの一部としてデクリメントされるものMPLSパスのために、これらのパスは、クイックスタートと互換性があるが、クイックスタートをサポートしていません。 Quick-
Start Requests that are traversing these paths will be correctly understood by the transport sender as having been denied. Any MPLS paths where the IP TTL is not decremented as part of traversing the MPLS path would be not compatible with Quick-Start; such paths would result in false positives, where the TCP sender incorrectly believes that the Quick-Start Request was approved by all routers along the path.
正しく拒否されたとして、トランスポート送信者によって理解されるであろうこれらのパスを横断している要求を開始します。 IP TTLがMPLSパスを横切るの一部としてデクリメントされていない任意のMPLSパスは、クイックスタートと互換性がないであろう。 TCPの送信者が誤っクイックスタート要求がパス上のすべてのルータによって承認されたと考えているところ、このようなパスは偽陽性をもたらすでしょう。
For cases where the ingress node to the MPLS path is aware of Quick-Start, this node should either zero the Quick-Start rate request, QS TTL, and QS Nonce fields, or remove the Quick-Start Option from the IP header.
MPLSパスの入口ノードは、クイックスタートを認識している場合のために、このノードは、クイックスタートレート要求、QS TTL、およびQSノンスフィールドをゼロにすべきであるか、IPヘッダからのクイック・スタート・オプションを削除します。
The section earlier specified the use of Quick-Start in TCP. In this section, we generalize this to give guidelines for the use of Quick-Start with other transport protocols. We also discuss briefly how Quick-Start could be specified for other transport protocols.
セクションでは、以前のTCPでのクイックスタートの使用を指定しました。このセクションでは、我々は他のトランスポートプロトコルとクイックスタートを使用するための指針を与えるために、これを一般化します。また、クイックスタートは、他のトランスポートプロトコルを指定することができる方法について簡単に説明します。
The general guidelines for Quick-Start in transport protocols are as follows:
次のようにトランスポートプロトコルでのクイックスタートのための一般的なガイドラインは以下のとおりです。
* Quick-Start is only specified for unicast transport protocols with appropriate congestion control mechanisms. Note: Quick-Start is not a replacement for standard congestion control techniques, but meant to augment their operation.
*クイックスタートは、適切な輻輳制御メカニズムとユニキャストトランスポートプロトコル用に指定されています。注：クイックスタートは、標準の輻輳制御技術に代わるものではありませんが、その操作を強化するためのもの。
* A transport-level mechanism is needed for the Quick-Start Response from the receiver to the sender. This response contains the Rate Request, TTL Diff, and QS Nonce.
*トランスポートレベルのメカニズムは、受信側から送信側へのクイック・スタート・レスポンスのために必要とされています。この応答は、レート要求、TTL差分、およびQS nonceを含んでいます。
* The sender checks the validity of the Quick-Start Response.
*送信者は、クイックスタート応答の有効性をチェックします。
* The sender has an estimate of the round-trip time, and translates the Quick-Start Response into an allowed window or allowed sending rate. The sender sends a Report of the Approved Rate. The sender starts sending Quick-Start packets, rate-paced out at the approved sending rate.
*送信者は、ラウンドトリップ時間の推定値を持っており、許可ウィンドウにクイックスタート応答または許可送信レートを変換します。送信者は、承認されたレートのレポートを送信します。送信者は、承認された送信レートでのレートペースクイックスタートパケットを、送信を開始します。
* After the sender receives the first acknowledgement packet for a Quick-Start packet, no more Quick-Start packets are sent. The sender adjusts its current congestion window or sending rate to be consistent with the actual amount of data that was transmitted in that round-trip time.
送信者がクイックスタートパケットの最初の確認応答パケットを受信した後*、これ以上のクイックスタートパケットが送信されます。送信者は、現在の輻輳ウィンドウを調整したり、その往復時間に送信されたデータの実際の量と一致するようにレートを送ります。
* When the last Quick-Start packet is acknowledged, the sender continues using the standard congestion control mechanisms of that protocol.
最後のクイックスタートパケットが確認された場合*、送信者はそのプロトコルの標準の輻輳制御機構を使用し続けています。
* If one of the Quick-Start packets is lost, then the sender reverts to the standard congestion control method of that protocol that would have been used if the Quick-Start Request had not been approved. In addition, the sender takes into account the information that the Quick-Start congestion window was too large (e.g., by decreasing ssthresh in TCP).
クイックスタートパケットの1つが失われた場合*、送信者は、クイックスタート要求が承認されていない場合に使用されていたであろうそのプロトコルの標準輻輳制御方法に戻ります。また、送信者は、クイックスタートの輻輳ウィンドウは、（TCPでSSTHRESHを減少させることによって、例えば）あまりにも大きかったことを考慮に情報を取ります。
As discussed in [SAF06], the data sender does not necessarily have information about the size of the data transfer at connection initiation; for example, in request-response protocols such as HTTP, the server doesn't know the size or name of the requested object during connection initiation. [SAF06] explores some of the performance implications of overly large Quick-Start Requests, and discusses heuristics that end-nodes could use to size their requests appropriately. For example, the sender might have information about the bandwidth of the last-mile hop, the size of the local socket buffer, or of the TCP receive window, and could use this information in determining the rate to request. Web servers that mostly have small objects to transfer might decide not to use Quick-Start at all, since Quick-Start would be of little benefit to them.
【SAF06]で説明したように、データ送信側は、必ずしも、接続開始時のデータ転送のサイズに関する情報を有していません。例えば、HTTPなどの要求応答プロトコルでは、サーバーは接続開始時に要求されたオブジェクトのサイズや名前を知りません。 [SAF06]過度に大きいクイックスタート要求のパフォーマンスへの影響のいくつかを探求し、エンドノードが適切にサイズに彼らの要求を使用することができヒューリスティックを説明します。例えば、送信者はラストマイルホップの帯域幅についての情報を持っているかもしれない、またはTCPのローカルソケットバッファのサイズは、ウィンドウを受け取り、その要求にレートを決定する際に、この情報を使用することができます。主に転送する小さなオブジェクトを持っているWebサーバーは、クイックスタートがそれらにはほとんど有益であろうことから、全くクイックスタートを使用しないことを決定することがあります。
Quick-Start will be more effective if Quick-Start Requests are not larger than necessary; every Quick-Start Request that is approved but not used (or not fully used) takes away from the bandwidth pool available for granting successive Quick-Start Requests.
クイックスタート要求が必要以上に大きくない場合はクイックスタートは、より効果的になります。承認されたが、使用されていない（または完全に使用されていない）されているすべてのクイックスタートの要求が連続したクイックスタート要求を許可するために利用可能な帯域幅プールから奪います。
In this section, we briefly outline how a router might decide whether or not to approve a Quick-Start Request. The router should ask the following questions:
このセクションでは、我々は簡単にルータがクイックスタート要求を承認するか否かを決定する方法を説明します。ルータは、次の質問をする必要があります。
* Has the router's output link been underutilized for some time (e.g., several seconds)?
*ルータの出力リンクは、いくつかの時間（例えば、数秒）のために十分に活用されていますか？
* Would the output link remain underutilized if the arrival rate were to increase by the aggregate rate requests that the router has approved over the last fraction of a second?
到着率は、ルータが第二の最後の一部分の上に承認した集約レート要求によって増加した場合*出力リンクが活用されていないままでしょうか？
In order to answer the last question, the router must have some knowledge of the available bandwidth on the output link and of the Quick-Start bandwidth that could arrive due to recently approved Quick-Start Requests. In this way, if an underutilized router experiences a flood of Quick-Start Requests, the router can begin to deny Quick-Start Requests while the output link is still underutilized.
最後の質問に答えるためには、ルータは、出力リンクに起因し、最近承認されたクイックスタート要求に到着する可能性クイックスタート帯域幅の利用可能な帯域幅のある程度の知識を持っている必要があります。活用されていないルータは、クイックスタート要求の洪水を経験する場合は、この方法では、ルータは出力リンクがまだ十分に活用されている間クイックスタート要求を拒否し始めることができます。
A simple way for the router to keep track of the potential bandwidth from recently approved requests is to maintain two counters: one for the total aggregate Rate Requests that have been approved in the current time interval [T1, T2], and one for the total aggregate Rate Requests approved over a previous time interval [T0, T1]. However, this document doesn't specify router algorithms for approving Quick-Start Requests, or make requirements for the appropriate time intervals for remembering the aggregate approved Quick-Start bandwidth. A possible router algorithm is given in Appendix E, and more discussion of these issues is available in [SAF06].
ルータが最近承認された要求からの潜在的な帯域幅を把握するための簡単な方法は、二つのカウンタを維持することです：現在の時間間隔[T1、T2]で承認されている総計レート要求の一つであり、合計1前回の時間間隔[T0、T1]の上に承認された集約レート要求。しかし、この文書では、クイックスタート要求を承認するためのルータのアルゴリズムを指定する、または集約は、クイック・スタートの帯域幅を承認覚えるために適切な時間間隔のための要件がありません。可能なルータアルゴリズムは、付録Eに与えられ、これらの問題の多くの議論は[SAF06]で利用可能です。
* If the router's output link has been underutilized and the aggregate of the Quick-Start Request Rate options granted is low enough to prevent a near-term bandwidth shortage, then the router could approve the Quick-Start Request.
*ルータの出力リンクが十分に活用されており、許可されたクイックスタート要求レートのオプションの集合体が短期的な帯域幅の不足を防ぐのに十分低い場合、ルータは、クイック・スタート・リクエストを承認することができます。
Section 10.2 discusses some of the implementation issues in processing Quick-Start Requests at routers. [SAF06] discusses the range of possible Quick-Start algorithms at the router for deciding whether to approve a Quick-Start Request. In order to explore the limits of the possible functionality at routers, [SAF06] also discusses Extreme Quick-Start mechanisms at routers, where the router would keep per-flow state concerning approved Quick-Start requests.
10.2節は、ルータのクイックスタート要求の処理での実装上の問題のいくつかを説明します。 [SAF06]クイックスタート要求を承認するかどうかを決定するためのルータで可能クイックスタートアルゴリズムの範囲について説明します。ルータで可能な機能の限界を探るためには、[SAF06]また、ルータが承認されたクイックスタート要求に関するフローごとの状態を続けるだろうルータでエクストリームクイックスタートメカニズムは、説明します。
The main benefit of Quick-Start is the faster start-up for the transport connection itself. For a small TCP transfer of one to five packets, Quick-Start is probably of very little benefit; at best, it might shorten the connection lifetime from three to two round-trip times (including the round-trip time for connection establishment). Similarly, for a very large transfer, where the slow-start phase would have been only a small fraction of the connection lifetime, Quick-Start would be of limited benefit. Quick-Start would not significantly shorten the connection lifetime, but it might eliminate or at least shorten the start-up phase. However, for moderate-sized connections in a well-provisioned environment, Quick-Start could possibly allow the entire transfer of M packets to be completed in one round-trip time (after the initial round-trip time for the SYN exchange), instead of the log_2(M)-2 round-trip times that it would normally take for the data transfer, in an uncongested environments (assuming an initial window of four packets).
クイックスタートの主な利点は、トランスポート接続自体の速く起動です。 1〜5個のパケットの小さなTCP転送では、クイックスタートは、おそらく非常に少ない有益です。最高の状態で、それは（接続確立のための往復時間を含む）3 2への往復時間からの接続寿命を短くする可能性があります。同様に、スロースタートフェーズは、接続寿命のごく一部であったであろう非常に大規模な転送のために、クイックスタートは、限定された有益であろう。クイックスタートが大幅に接続寿命を短くしないだろうが、それは排除するか、少なくとも起動段階を短縮することがあります。しかし、よくプロビジョニング環境における中規模の接続のために、クイックスタートは、おそらくMパケットの転送全体が（SYN交換のための最初のラウンドトリップ時間後）1ラウンドトリップ時間で完了することを可能にすることができ、代わりに往復時間は、それが正常に非輻輳環境では、データ転送にかかることlog_2（M）-2（4つのパケットの最初のウィンドウを仮定）。
This section discusses the costs of Quick-Start for the connection and for the routers along the path.
このセクションでは、接続のために、パスに沿ってルータのクイックスタートのコストについて説明します。
The cost of having a Quick-Start Request packet dropped: Measurement studies cited earlier [MAF04] suggest that on a wide range of paths in the Internet, TCP SYN packets containing unknown IP options will be dropped. Thus, for the sender one risk in using Quick-Start is that the packet carrying the Quick-Start Request could be dropped in the network. It is particularly costly to the sender when a TCP SYN packet is dropped, because in this case the sender should wait for an RTO of three seconds before re-sending the SYN packet, as specified in Section 4.7.2.
クイックスタートRequestパケットを持つことのコストが低下した：以前に引用した測定の研究[MAF04]は、インターネットでのパスの広い範囲に、未知のIPオプションを含むTCP SYNパケットが破棄されることを示唆しています。このように、送信者のためのクイックスタートを使用して1つのリスクは、クイックスタート要求を運ぶパケットがネットワークで廃棄される可能性があることです。第4.7.2項で指定されるように、この場合に、送信者は、SYNパケットを再送信する前に3秒のRTOを待つ必要があるので、TCP SYNパケットがドロップされたときに、送信者には特に高価です。
The cost of having a Quick-Start data packet dropped: Another risk for the sender in using Quick-Start lies in the possibility of suffering from congestion-related losses of the Quick-Start data packets. This should be an unlikely situation because routers are expected to approve Quick-Start Requests only when they are significantly underutilized. However, a transient increase in cross-traffic in one of the routers, a sudden decrease in available bandwidth on one of the links, or congestion at a non-IP queue could result in packet losses even when the Quick-Start Request was approved by all of the routers along the path. If a Quick-Start packet is dropped, then the sender reverts to the congestion control mechanisms it would have used if the Quick-Start Request had not been approved, so the performance cost to the connection of having a Quick-Start packet dropped is small, compared to the performance without Quick-Start. (On the other hand, the performance difference between Quick-Start with a Quick-Start packet dropped and Quick-Start with no Quick-Start packet dropped can be considerable.)
クイックスタートデータパケットを持つことのコストが低下した：クイックスタートを使用して、送信者のためのもう一つのリスクは、クイックスタートデータパケットの輻輳関連の損失に苦しんでの可能性です。ルータはそれらが大幅に十分に活用されている場合にのみ、クイックスタートの要求を承認することが期待されているので、これはそうな状況でなければなりません。しかし、ルータの1つでクロストラフィックの一過性の上昇、突然のリンクのいずれかで利用可能な帯域幅の減少、または非IPキューでの輻輳がクイックスタート要求が承認された場合でも、パケットの損失を被る可能性がありパスに沿ったルーターのすべて。クイックスタートパケットが破棄された場合、送信者は、クイックスタート要求が承認されていなかったので、クイックスタートパケットがドロップされたの接続にパフォーマンスコストが小さい場合、それは使用していただろう輻輳制御メカニズムに戻ります、クイックスタートなしのパフォーマンスに比べて。 （一方、クイックスタートパケットとクイックスタート間の性能差が滴下しないクイックスタートパケットとクイックスタートがかなりあることができる落ちました。）
Added complexity at routers: The main cost of Quick-Start at routers concerns the costs of added complexity. The added complexity at the end-points is moderate, and might easily be outweighed by the benefit of Quick-Start to the end hosts. The added complexity at the routers is also somewhat moderate; it involves estimating the unused bandwidth on the output link over the last several seconds, processing the Quick-Start request, and keeping a counter of the aggregate Quick-Start rate approved over the last fraction of a second. However, this added complexity at routers adds to the development cycle, and could prevent the addition of other competing functionality to routers. Thus, careful thought would have to be given to the addition of Quick-Start to IP.
ルータの複雑さを追加しました：ルータのクイックスタートの主なコストは、追加の複雑さのコストに関するものです。エンドポイントでの追加複雑さが中程度で、簡単にエンドホストへのクイックスタートの利益を上回る可能性があります。ルータの追加複雑さもやや緩やかです。それはクイックスタートリクエストを処理し、最後の数秒間の出力リンク上の未使用の帯域幅を推定し、第二の最後の一部分上に承認集約クイックスタート率のカウンタを維持することを伴います。ただし、ルーターでこの追加の複雑さは、開発サイクルに追加し、ルータに他の競合の機能の追加を防ぐことができます。このように、慎重に考えたのは、IPへのクイックスタートのほかに与えなければなりません。
The slow path in routers: Another drawback of Quick-Start is that packets containing the Quick-Start Request message might not take the fast path in routers, particularly in the beginning of Quick-Start's deployment in the Internet. This would mean some extra delay for the end hosts, and extra processing burden for the routers. However, as discussed in Sections 4.1 and 4.7, not all packets would carry the Quick-Start option. In addition, for the underutilized links where Quick-Start Requests could actually be approved, or in typical environments where most of the packets belong to large flows, the burden of the Quick-Start Option on routers would be considerably reduced. Nevertheless, it is still conceivable, in the worst case, that many packets would carry Quick-Start Requests; this could slow down the processing of Quick-Start packets in routers considerably. As discussed in Section 9.6, routers can easily protect against this by enforcing a limit on the rate at which Quick-Start Requests will be considered. [RW03] and [RW04] contain measurements of the impact of IP Option Processing on packet round-trip times.
ルータでの低速パス：クイックスタートの別の欠点は、クイックスタート要求メッセージを含むパケットは、特にインターネットでのクイックスタートの展開の初めに、ルータで高速パスを取ることではないかもしれないということです。これは、いくつかのエンドホストのための余分な遅延、およびルータのための余分な処理負担を意味します。セクション4.1と4.7で説明したようにしかし、ではなく、すべてのパケットは、クイックスタートオプションを運ぶでしょう。また、クイックスタートの要求が実際に承認することができ、またはパケットのほとんどが大きな流れに属している典型的な環境では、ルータ上のクイック・スタート・オプションの負担が大幅に軽減されるだろう十分に活用されていないリンクのため。それにもかかわらず、多くのパケットがクイックスタート要求を運ぶだろうと、最悪の場合には、まだ考えられます。これはかなりのルーターにクイックスタートパケットの処理が遅くなる可能性があります。セクション9.6で説明したように、ルータは簡単にクイックスタートの要求が考慮される速度の制限を強制することで、この障害を防ぐことができます。 [RW03]および[RW04]パケット往復時間のIPオプション処理の影響の測定を含みます。
Multiple paths:
複数のパス：
One limitation of Quick-Start is that it presumes that the data packets of a connection will follow the same path as the Quick-Start request packet. If this is not the case, then the connection could be sending the Quick-Start packets, at the approved rate, along a path that was already congested, or that became congested as a result of this connection. Thus, Quick-Start could give poor performance when there is a routing change immediately after the Quick-Start Request is approved, and the Quick-Start data packets follow a different path from that of the original Quick-Start Request. This is, however, similar to what would happen for a connection with sufficient data, if the connection's path was changed in the middle of the connection, which had already established the allowed initial rate.
クイックスタートの1つの制限は、接続のデータパケットは、クイックスタート要求パケットと同じ道をたどるだろうということを前提としていることです。そうでない場合は、接続がすでに混雑した道に沿って、承認された速度で、クイックスタートパケットを送信することができ、またはそれは、この接続の結果として、混雑となりました。このように、クイックスタートリクエストが承認された直後にルーティング変更がある場合クイックスタートは、パフォーマンスの低下を与えることができる、クイック・スタート・データ・パケットは、オリジナルのクイックスタート要求とは異なるパスをたどります。これは、しかし、接続のパスがすでに許可初期速度を確立したコネクションの途中で変更された場合、十分なデータとの接続のために何が起こるかに似ています。
As specified in Section 3.3, a router that uses multipath routing for packets within a single connection must not approve a Quick-Start Request. Quick-Start would not perform robustly in an environment with multipath routing, where different packets in a connection routinely follow different paths. In such an environment, the Quick-Start Request and some fraction of the packets in the connection might take an underutilized path, while the rest of the packets take an alternate, congested path.
3.3節で規定されているように、単一の接続内のパケットのためのマルチパスルーティングを使用するルータは、クイックスタートリクエストを承認してはなりません。クイックスタートは、接続の異なるパケットが日常異なるパスをたどるマルチパスルーティング、ある環境で確実に実行していないでしょう。パケットの残りの部分は別の、混雑したパスを取る一方で、このような環境では、接続のクイックスタート要求パケットのある部分は、十分に活用されていないパスがかかる場合があります。
Non-IP queues: A problem of any mechanism for feedback from routers at the IP level is that there can be queues and bottlenecks in the end-to-end path that are not in IP-level routers. As an example, these include queues in layer-two Ethernet or ATM networks. One possibility would be that an IP-level router adjacent to such a non-IP queue or bottleneck would be configured to reject Quick-Start Requests if that was appropriate. One would hope that, in general, IP networks are configured so that non-IP queues between IP routers do not end up being the congested bottlenecks.
非IPキュー：IPレベルでルータからのフィードバックのための任意のメカニズムの問題はIPレベルのルータにないエンドツーエンドパスのキューとボトルネックが存在し得るということです。一例として、これらは、レイヤ2イーサネットまたはATMネットワークのキューを含みます。一つの可能性は、このような非IPキューやボトルネックに隣接したIPレベルのルータはそれが適切であった場合はクイックスタート要求を拒否するように構成されることになります。 IPルータとの間の非IPキューが混雑し、ボトルネックになってしまうしないように、一つは、一般的には、IPネットワークが設定されている、ことを望んでいるだろう。
The discussion in this document has largely been of Quick-Start with default, best-effort traffic. However, Quick-Start could also be used by traffic using some form of differentiated services, and routers could take the traffic class into account when deciding whether or not to grant the Quick-Start Request. We don't address this context further in this paper, since it is orthogonal to the specification of Quick-Start.
このドキュメントの議論は、主に、デフォルト、ベストエフォートトラフィックとクイックスタートでてきました。しかし、クイックスタートも差別化されたサービスのいくつかのフォームを使用してトラフィックが使用することができ、およびクイックスタート要求を許可するかどうかを決定する場合、ルータは、アカウントにトラフィッククラスを取ることができます。それはクイックスタートの仕様に直交しているので、私たちは、この論文ではさらに、このコンテキストに対応していません。
Routers are also free to take into account their own priority classifications in processing Quick-Start Requests.
ルータはまた、クイックスタート要求を処理する際に考慮に自分の優先順位の分類を取ることは自由です。
In this section, we discuss the protection against senders, receivers, or colluding routers or middleboxes lying about the Quick-Start Request.
ここでは、送信者、受信者、または共謀ルータやクイックスタート要求について嘘ミドルボックスに対する保護を議論します。
A transport sender could try to transmit data at a higher rate than that approved in the Quick-Start Request. The network could use a traffic policer to protect against misbehaving senders that exceed the approved rate, for example, by dropping packets that exceed the allowed transmission rate. The required Report of Approved Rate allows traffic policers to check that the Report of Approved Rate does not exceed the Rate Request actually approved at that point in the network in the previous Quick-Start Request from that connection. The required Approved Rate report also allows traffic policers to check that the sender's sending rate does not exceed the rate in the Report of Approved Rate.
トランスポート送信者は、クイックスタート要求に承認されたものよりも高いレートでデータを送信しようとすることができます。ネットワークは、例えば、許容される伝送速度を超過したパケットをドロップすることにより、承認されたレートを超え誤動作の送信者から保護するトラフィックポリサーを使用することができます。承認されたレートの必要な報告書は、トラフィックポリサーが承認率の報告書は、実際にその接続から、前のクイックスタート要求でネットワークにその時点で承認されたレート要求を超えていないことを確認することができます。必要な承認レート報告書はまた、トラフィックポリサーは、送信者の送信速度は、承認率の報告書でレートを超えないことを確認することができます。
If a router or receiver receives an Approved Rate report that is larger than the Rate Request in the Quick-Start Request approved for that sender for that connection in the previous round-trip time, then the router or receiver could deny future Quick-Start Requests from that sender, e.g., by deleting the Quick-Start Request from future packets from that sender. We note that routers are not required to use Approved Rate reports to check if senders are cheating; this is at the discretion of the router.
ルータまたは受信機は、前のラウンドトリップ時間でその接続のためにその送信者のために承認されたクイックスタート要求におけるレート要求よりも大きい承認レート報告を受けた場合は、ルータまたは受信機は、将来のクイックスタートの要求を拒否することができその送信者からの、例えば、その送信者からの将来のパケットからのクイックスタート要求を削除することもできます。私たちは、ルータは送信者が浮気をしているかどうかを確認するために承認された料金のレポートを使用する必要はありませんことに注意してください。これは、ルータの裁量です。
If a router sees a Report of Approved Rate, and did not see an earlier Quick-Start Request, then either the sender could be cheating, or the connection's path could have changed since the Quick-Start Request was sent. In either case, the router could decide to deny future Quick-Start Requests for this connection. In particular, it is reasonable for the router to deny a Quick-Start request if either the sender is cheating, or if the connection path suffers from path changes or multipathing.
ルータは認定速度の報告書を見て、以前のクイックスタートリクエストを見ていない場合は、送信者のどちらかが浮気することができ、またはクイック・スタート・リクエストが送信されたため、接続のパスが変更された可能性があります。いずれの場合も、ルータはこの接続のための今後のクイックスタート要求を拒否することを決定することもできます。送信者が浮気されたいずれかの場合、または接続パスは、パスの変更やマルチパスに苦しんでいる場合、ルータはクイックスタート要求を拒否するため、特に、それが合理的です。
If a router approved a Quick-Start Request, but does not see a subsequent Approved Rate report, then there are several possibilities: (1) the request was denied and/or dropped downstream, and the sender did not send a Report of Approved Rate; (2) the request was approved, but the sender did not send a Report of Approved Rate; (3) the Approved Rate report was dropped in the network; or (4) the Approved Rate report took a different path from the Quick-Start Request. In any of these cases, the router would be justified in denying future Quick-Start Requests for this connection.
ルータはクイックスタートリクエストを承認したが、その後の承認レートレポートを表示しない場合は、いくつかの可能性があります：（1）要求が拒否されたおよび/または下流の落下、および送信者が承認率のレポートを送っていなかったました; （2）要求が承認されましたが、送信者が承認率のレポートを送信しませんでした。 （3）承認された料金のレポートは、ネットワークに滴下しました。または（4）承認された料金のレポートでは、クイック・スタート・リクエストは異なる経路を取りました。いずれの場合も、ルータは、この接続のための今後のクイックスタートの要求を拒否して正当化されるだろう。
In any of the cases mentioned in the three paragraphs above (i.e., an Approved Rate report that is larger than the Rate Request in the earlier Quick-Start Request, a Report of Approved Rate with no preceding Rate Request, or a Rate Request with no Report of Approved Rate), a traffic policer may assume that Quick-Start is not being used appropriately, or is being used in an unsuitable environment (e.g., with multiple paths), and take some corresponding action.
以前のクイックスタート要求におけるレート要求よりも大きい場合（すなわち、承認された料金のレポート、無直前のレート要求、または全くないとのレート要求と承認率の報告書上記の3つの段落で言及したいずれの場合であっても承認されたレートの報告書）、トラフィックポリサーは）クイックスタートが適切に使用されていない、または複数のパスで、例えば（適さない環境で使用されていることを前提とし、いくつかの対応するアクションがかかる場合があります。
What are the incentives for a sender to cheat by over-sending after a Quick-Start Request? Assuming that the sender's interests are measured by a performance metric such as the completion time for its connections, sometimes it might be in the sender's interests to cheat, and sometimes it might not; in some cases, it could be difficult for the sender to judge whether it would be in its interests to cheat. The incentives for a sender to cheat by over-sending after a Quick-Start Request are not that different from the incentives for a sender to cheat by over-sending even in the absence of Quick-Start, with one difference: the use of Quick-Start could help a sender evade policing actions from policers in the network. The Report of Approved Rate is designed to address this and to make it harder for senders to use Quick-Start to `cover' their cheating.
オーバー送信クイックスタート要求の後によるカンニングする送信者に対するインセンティブは何ですか？送信者の利益は、そのようなその接続のための完了時間などの性能メトリックによって測定されていると仮定すると、時にはそれがカンニングする送信者の利益になるかもしれませんが、時にはそれがないかもしれません。送信者は、それがカンニングするその利益になるかどうかを判断するためにいくつかのケースでは、それが困難である可能性があります。クイックの使用：クイックスタート要求した後、オーバー送信することにより、カンニングする送信者のためのインセンティブが1つの違いで、でもクイックスタートの不存在下で過剰送信することにより、カンニングする送信者に対するインセンティブと大差はありません-startは、ネットワーク内のポリサーからアクションをポリシング送信者EVADEを助けることができます。承認されたレートの報告書は、これに対処するために、それは難しいの送信者が自分の浮気 `カバー」にクイックスタートを使用できるようにするために設計されています。
One form of misbehavior would be for the receiver to lie to the sender about whether the Quick-Start Request was approved, by falsely reporting the TTL Diff and QS Nonce. If a router that understands the Quick-Start Request denies the request by deleting the request or by zeroing the QS TTL and QS Nonce, then the receiver can "lie" about whether the request was approved only by successfully guessing the value of the TTL Diff and QS Nonce to report. The chance of the receiver successfully guessing the correct value for the TTL Diff is 1/256, and the chance of the receiver successfully guessing the QS nonce for a reported rate request of K is 1/(2K).
クイックスタート要求が承認されたかどうかについては、受信機が誤ってTTLのDiffとQS nonceを報告することによって、送信者に嘘をつくために不正行為の一つの形態は次のようになります。クイックスタート要求を理解しているルータは要求を削除するか、QS TTLおよびQS nonceをゼロにすることにより、要求を拒否した場合、受信機要求が正常にTTL差分の値を推測することでのみ承認されたかどうかについての缶「嘘」報告するとQSナンス。正常TTL差分の正しい値を推測する受信機の機会は1/256であり、そして正常Kの報告レート要求用QS nonceを推測受信機の可能性は1 /（2K）です。
However, if the Quick-Start Request is denied only by a non-Quick-Start-capable router, or by a router that is unable to zero the QS TTL and QS Nonce fields, then the receiver could lie about whether the Quick-Start Requests were approved by modifying the QS TTL in successive requests received from the same host. In particular, if the sender does not act on a Quick-Start Request, then the receiver could decrement the QS TTL by one in the next request received from that host before calculating the TTL Diff, and decrement the QS TTL by two in the following received request, until the sender acts on one of the Quick-Start Requests.
しかし、クイックスタート要求が唯一の非クイックスタート対応ルータによって拒否された場合、またはQS TTLおよびQS Nonceのフィールドをゼロにすることができないルータによって、受信機は偽ることができクイックスタートか要求が同じホストから受信した連続する要求でQS TTLを変更することにより、承認されました。送信者がクイックスタート要求に作用していない場合は特に、受信機はTTL差分を計算する前に、そのホストから受信した次の要求で1によってQS TTLをデクリメントでき、以下の二つでQS TTLをデクリメントクイックスタート要求の一つに、送信者の行為まで、要求を受信しました。
Unfortunately, if a router doesn't understand Quick-Start, then it is not possible for that router to take an active step such as zeroing the QS TTL and QS Nonce to deny a request. As a result, the QS TTL is not a fail-safe mechanism for preventing lying by receivers in the case of non-Quick-Start-capable routers.
ルータはクイックスタートを理解していない場合は残念ながら、そのルータは、このような要求を拒否するようにQS TTLとQS nonceをゼロとして積極的ステップを取ることは不可能です。その結果、QS TTLは非クイックスタート対応ルータの場合、受信機によって横たわっ防止のためのフェイルセーフ機構ではありません。
What would be the incentives for a receiver to cheat in reporting on a Quick-Start Request, in the absence of a mechanism such as the QS Nonce? In some cases, cheating would be of clear benefit to the receiver, resulting in a faster completion time for the transfer. In other cases, where cheating would result in Quick-Start packets being dropped in the network, cheating might or might not improve the receiver's performance metric, depending on the details of that particular scenario.
受信機は、このようなQSナンスのようなメカニズムが存在しない場合には、クイック・スタート・リクエストに報告でカンニングするためのインセンティブは何でしょうか？いくつかのケースでは、不正行為は、転送のために速く完了時間をもたらす、受信機への明確な有益であろう。他の例では、不正行為は、ネットワーク内で廃棄されるクイックスタートパケットにつながるところ、不正行為は、またはその特定のシナリオの内容に応じて、受信機の性能指標を改善しない場合があります。
A second form of receiver misbehavior would be for the receiver to lie to the sender about the Rate Request for an approved Quick-Start Request, by increasing the value of the Rate Request field. However, the receiver doesn't necessarily know the Rate Request in the original Quick-Start Request sent by the sender, and a higher Rate Request reported by the receiver will only be considered valid by the sender if it is no higher than the Rate Request originally requested by the sender. For example, if the sender sends a Quick-Start Request with a Rate Request of X, and the receiver reports receiving a Quick-Start Request with a Rate Request of Y > X, then the sender knows that either some router along the path malfunctioned (increasing the Rate Request inappropriately), or the receiver is lying about the Rate Request in the received packet.
受信機は、レート要求フィールドの値を増加させることにより、承認されたクイックスタート要求のためのレート要求について送信者に嘘をつくための受信機の不正行為の二番目の形式は次のようになります。しかし、受信機は、必ずしも送信者によって送信された元のクイックスタート要求におけるレート要求を知らない、それがレート要求よりも高くない場合は受信機によって報告された高いレート要求は、送信者のみで有効と見なされますもともとは、送信者から要求されました。送信者がXのレート要求、およびY> Xのレート要求にクイックスタート要求を受信する受信機レポートとクイックスタート要求を送信した場合、送信者は、パスに沿って、いくつかのルータが故障いずれかのことを知っています（不適切レート要求を増加させる）、又は受信機は、受信したパケットにおけるレート要求に関する横たわっています。
If the sender sends a Quick-Start Request with a Rate Request of Z, the receiver receives the Quick-Start Request with an approved Rate Request of X, and reports a Rate Request of Y, for X < Y <= Z, then the receiver only succeeds in lying to the sender about the approved rate if the receiver successfully reports the rightmost 2Y bits in the QS nonce.
送信者がZのレート要求とクイックスタートリクエストを送信する場合、受信機は、<Y <= Z、そしてXのために、Xの承認レート要求とクイックスタート要求を受信し、Yのレート要求を報告します受信機は受信機が正常にQSのナンスの右端2Yビットを報告した場合、承認率について送信者に横たわっに成功しました。
If senders often use a configured default value for the Rate Request, then receivers would often be able to guess the original Rate Request, and this would make it easier for the receiver to lie about the value of the Rate Request field. Similarly, if the receiver often communicates with a particular sender, and the sender always uses the same Rate Request for that receiver, then the receiver might over time be able to infer the original Rate Request used by the sender.
送信者は、多くの場合、レート要求のために設定されたデフォルト値を使用する場合、受信機は、多くの場合、元のレート要求を推測することができるだろう、これはそれが簡単に受信機がレート要求フィールドの値について嘘をつくためになるだろう。受信機は、多くの場合、特定の送信者と通信し、送信者は、常にその受信機に同じレート要求を使用している場合も同様に、受信機は、時間をかけて、送信者が使用し、元のレート要求を推測することができるかもしれません。
There are several possible additional forms of protection against receivers lying about the value of the Rate Request. One possible additional protection would be for a router that decreases a Rate Request in a Quick-Start Request to report the decrease directly to the sender. However, this could lead to many reports back to the sender for a single request, and could also be used in address-spoofing attacks.
レート要求の値について嘘受信機に対する保護のいくつかの可能な追加の形式があります。一つの可能性のある追加の保護は、送信者への直接の減少を報告するクイックスタート要求におけるレート要求を減少させるルータのためになります。しかし、これは単一の要求のために送信者に多くの報告につながる可能性、およびアドレススプーフィング攻撃でも使用することができます。
A second limited form of protection would be for senders to use some degree of randomization in the requested Rate Request, so that it is difficult for receivers to guess the original value for the Rate Request. However, this is difficult because there is a fairly coarse granularity in the set of rate requests available to the sender, and randomizing the initial request only offers limited protection, in any case.
受信機は、レート要求の元の値を推測することは困難であるように、送信者は、要求されたレート要求にランダムある程度のを使用するための保護の第二の限定された形は次のようになります。送信者に利用可能率の要求のセットではかなり粗い粒度があるのでしかし、これは困難であり、最初の要求をランダム化することだけでどのような場合には、限られた保護を提供しています。
In addition to protecting against misbehaving receivers, it is necessary to protect against misbehaving routers. Consider collusion between an ingress router and an egress router belonging to the same intranet. The ingress router could decrement the Rate Request at the ingress, with the egress router increasing it again at the egress. The routers between the ingress and egress that approved the decremented rate request might not have been willing to approve the larger, original request.
不正動作する受信機からの保護に加えて、不正動作するルータから保護することが必要です。入口ルータと同じイントラネットに属する出口ルータ間の共謀を考えてみましょう。入口ルータは、出口ルータは、出口で再びそれが増加すると、入口でレート要求を減少できます。減算レート要求を承認した入力および出力の間にルータが大きく、元の要求を承認して喜んでされていない可能性があります。
Another form of collusion would be for the ingress router to inform the egress router out-of-band of the TTL Diff and QS Nonce for the request packet at the ingress. This would enable the egress router to modify the QS TTL and QS Nonce so that it appeared that all the routers along the path had approved the request. There does not appear to be any protection against a colluding ingress and egress router. Even if an intermediate router had deleted the Quick-Start Option from the packet, the ingress router could have sent the Quick-Start Option to the egress router out-of-band, with the egress router inserting the Quick-Start Option, with a modified QS TTL field, back in the packet.
共謀の別の形態は、入口で要求パケットのための帯域外TTLのDiffとQSナンスの出口ルータに通知するために、入口ルータのためになります。パスに沿ってすべてのルータが要求を承認していたように見えたように、これはQS TTLとQS nonceを修正するために出口ルータを可能にします。結託の入力および出力ルータに対する任意の保護があるように表示されません。中間ルータは、パケットからクイック起動オプションを削除した場合でも、入口ルータはと、出口ルータは、クイック・スタート・オプションを挿入すると、アウトオブバンド出口ルータへのクイック・スタート・オプションを送信している可能性がQS TTLフィールドはバックパケットで、修正しました。
However, unlike ECN, there is somewhat less of an incentive for cooperating ingress and egress routers to collude to falsely modify the Quick-Start Request so that it appears to have been approved by all the routers along the path. With ECN, a colluding ingress router could falsely mark a packet as ECN-capable, with the colluding egress router returning the ECN field in the IP header to its original non-ECN-capable codepoint, and congested routers along the path could have been fooled into not dropping that packet. This collusion would give an unfair competitive advantage to the traffic protected by the colluding ingress and egress routers.
しかし、ECNとは異なり、パス上のすべてのルータによって承認されたと表示されるようにクイックスタート要求を変更偽っする共謀して入力および出力ルータを協力のためのインセンティブのやや少ないがあります。 ECNと、結託の入口ルータは、その元の非ECN-可能なコードポイントのIPヘッダ内のECNフィールドを返す共謀出口ルータと、ECN-可能としてパケットをマーク誤っでき、経路に沿った輻輳ルータはだまされている可能性がそのパケットをドロップしませんに。この共謀は共謀入力および出力ルータによって保護されたトラフィックに不公正な競争上の優位性を与えるだろう。
In contrast, with Quick-Start, the collusion of the ingress and egress routers to make it falsely appear that a Quick-Start Request was approved sometimes would give an advantage to the traffic covered by that collusion, and sometimes would give a disadvantage, depending on the details of the scenario. If some router along the path really does not have enough available bandwidth to approve the Quick-Start Request, then Quick-Start packets sent as a result of the falsely approved request could be dropped in the network, to the possible disadvantage of the connection. Thus, while the ingress and egress routers could collude to prevent intermediate routers from denying a Quick-Start Request, it would not always be to the connection's advantage for this to happen. One defense against such a collusion would be for some router between the ingress and egress nodes that denied the request to monitor connection performance, penalizing connections that seem to be using Quick-Start after a Quick-Start Request was denied, or that are reporting an Approved Rate higher than that actually approved by that router.
これとは対照的に、クイックスタートで、入力および出力ルータの共謀は、誤って時々承認されたクイックスタートの要求が応じて、その共謀によってカバーされたトラフィックに優位性を与えるだろう、と時々不利益を与えることを見えるようにしますシナリオの詳細について。パスに沿ったいくつかのルータが本当にクイックスタート要求を承認するための十分な利用可能な帯域幅を持っていない場合、接続の可能な欠点に、ネットワーク内で廃棄される可能性が誤って承認された要求の結果として送信されたパケットをクイック起動します。入力および出力ルータはクイックスタート要求を拒否から中間ルータを防ぐために共謀ができながら、この現象が発生するためこのように、それは常に接続の利点にはならないでしょう。このよう共謀に対する一つの防衛は、クイックスタート要求が拒否された後にクイックスタートを使用しているように見える、または報告されている接続を罰する、接続のパフォーマンスを監視するための要求を拒否しましたイングレスと出口ノードの間にいくつかのルータのためになります実際にそのルータによって承認されたものよりも高い承認率。
If the congested router is ECN-capable, and the colluding ingress and egress routers are lying about ECN-capability as well as about Quick-Start, then the result could be that the Quick-Start Request falsely appears to the sender to have been approved, and the Quick-
混雑ルータがECN-可能であり、結託の入力および出力ルータがECN-機能についてだけでなく、クイックスタートについて嘘をついている、そしてその結果は、クイックスタート要求が誤って承認されているように送信者に表示されることが考えられた場合、およびQuick-
Start packets falsely appear to the congested router to be ECN-capable. In this case, the colluding routers might succeed in giving a competitive advantage to the traffic protected by their collusion (if no intermediate router is monitoring to catch such misbehavior).
開始パケットが誤ってECN-ことができるように混雑してルータに表示されます。 （中間のルータは、このような不正行為をキャッチするために監視されていない場合）この場合は、共謀のルータは彼らの共謀によって保護されたトラフィックに競争上の優位性を与えることに成功する可能性があります。
One possible difficulty is that of traffic normalizers [HKP01], or other middleboxes along that path, that rewrite IP TTLs in order to foil other kinds of attacks in the network. If such a traffic normalizer rewrote the IP TTL, but did not adjust the Quick-Start TTL by the same amount, then the sender's mechanism for determining if the request was approved by all routers along the path would no longer be reliable. Rewriting the IP TTL could result in false positives (with the sender incorrectly believing that the Quick-Start Request was approved) as well as false negatives (with the sender incorrectly believing that the Quick-Start Request was denied).
一つの可能な難しさは、その経路に沿ってトラフィックの正規化[HKP01]、又は他の中間装置から、順番にその書き換えたIPのTTLは、ネットワーク内の攻撃の他の種類の箔にすることです。そのようなトラフィックの正規化は、IP TTLを書き直した場合は、同じ量だけクイックスタートTTLを調整していなかった、そして、要求はパス上のすべてのルータによって承認されたかどうかを決定するための送信者のメカニズムは、もはや信頼できないだろう。 IP TTLを書き換えることだけでなく、（送信者が誤っクイックスタート要求が拒否されたことを信じて）偽陰性（送信者が誤っクイックスタート要求が承認されたことを信じて）偽陽性につながる可能性があります。
As discussed in [SAF06], Quick-Start is vulnerable to two kinds of attacks: (1) attacks to increase the routers' processing and state load and (2) attacks with bogus Quick-Start Requests to temporarily tie up available Quick-Start bandwidth, preventing routers from approving Quick-Start Requests from other connections. Routers can protect against the first kind of attack by applying a simple limit on the rate at which Quick-Start Requests will be considered by the router.
ルータの処理および状態負荷を増大させることと、（2）偽クイックスタート要求に攻撃を一時的に利用可能なクイックスタートをタイアップする（1）攻撃：[SAF06]で説明したように、クイックスタートは、攻撃の二種類に脆弱です帯域幅は、他の接続からのクイックスタート要求を承認からルータを防ぎます。ルータは、クイックスタート要求がルータによって考慮される速度に簡単な制限を適用することによって、攻撃の第一種から保護することができます。
The second kind of attack, to tie up the available Quick-Start bandwidth, is more difficult to defend against. As discussed in [SAF06], Quick-Start Requests that are not going to be used, either because they are from malicious attackers or because they are denied by routers downstream, can result in short-term `wasting' of potential Quick-Start bandwidth, resulting in routers denying subsequent Quick-Start Requests that, if approved, would in fact have been used.
利用できるクイックスタート帯域幅を拘束する攻撃の第二種は、身を守ることがより困難です。使用する予定されていない[SAF06]、クイックスタート要求で説明したように、どちらかの彼らは、悪意のある攻撃者からのものか、それらが下流のルータによって拒否されているため、短期的には `潜在的なクイックスタート帯域幅の「無駄になる可能性があるため、、承認された場合、実際に使用されていたであろう、後続のクイックスタート要求を拒否ルータになります。
We note that the likelihood of malicious attacks would be minimized significantly when Quick-Start was deployed in a controlled environment such as an intranet, where there was some form of centralized control over the users in the system. We also note that this form of attack could potentially make Quick-Start unusable, but it would not do any further damage; in the worst case, the network would function as a network without Quick-Start.
私たちは、クイックスタートがこのようなシステム内のユーザを集中管理のいくつかのフォームがあったイントラネットなどの制御された環境に配備されたとき、悪意のある攻撃の可能性が大幅に最小化されることに注意してください。また、この形式の攻撃は、潜在的にクイックスタートが使用できなくなる可能性があり、それは任意のさらなる損傷しないだろうことに注意してください。最悪の場合には、ネットワークは、クイックスタートせずにネットワークとして機能します。
[SAF06] considers the potential of Extreme Quick-Start algorithms at routers, which keep per-flow state for Quick-Start connections, in protecting the availability of Quick-Start bandwidth in the face of frequent, overly large Quick-Start Requests.
【SAF06】頻繁に、過度に大きなクイックスタート要求に直面してクイックスタート帯域幅の可用性を保護する、クイックスタート接続ごとのフロー状態を維持ルータにおけるエクストリームクイックスタートアルゴリズムの可能性を考慮する。
Quick-Start was added to the NS simulator [SH02] by Srikanth Sundarrajan, and additional functionality was added by Pasi Sarolahti. The validation test is at `test-all-quickstart' in the `tcl/test' directory in NS. The initial simulation studies from [SH02] show a significant performance improvement using Quick-Start for moderate-sized flows (between 4 KB and 128 KB) in underutilized environments. These studies are of file transfers, with the improvement measured as the relative increase in the overall throughput for the file transfer. The study shows that potential improvement from Quick-Start is proportional to the delay-bandwidth product of the path.
クイックスタートはスリカンスSundarrajanでNSシミュレータ[SH02]に加え、追加の機能がパシSarolahtiによって追加されました。検証テストは、NSでディレクトリ `TCL /テストに '`テスト・オール・クイックスタートです。 [SH02]から初期シミュレーション研究は活用されていない環境で（4キロバイト及び128キロバイトの間）中規模フローに対してクイックスタートを使用して、パフォーマンスの大幅な改善を示します。これらの研究は、ファイル転送のための全体的なスループットの相対的な増加として測定される改善と、ファイル転送です。研究では、クイックスタートからの潜在的な改善がパスの遅延と帯域幅の積に比例することを示しています。
The Quick-Start simulations in [SAF06] explore the following: the potential benefit of Quick-Start for the connection, the relative benefits of different router-based algorithms for approving Quick-Start Requests, and the effectiveness of Quick-Start as a function of the senders' algorithms for choosing the size of the rate request.
[SAF06]でクイックスタートのシミュレーションは以下を探る：接続のためのクイックスタートの潜在的な利益、クイックスタート要求を承認するための別のルータベースのアルゴリズムの相対的な利点、および機能などのクイックスタートの有効性をレート要求のサイズを選択するための送信者のアルゴリズムの。
This section discusses some of the implementation issues with Quick-Start. This section also discusses some of the key deployment issues, such as the chicken-and-egg deployment problems of mechanisms that have to be deployed in both routers and end nodes in order to work, and the problems posed by the wide deployment of middleboxes today that block the use of known or unknown IP Options.
このセクションでは、クイックスタートと実装の問題のいくつかを説明します。また、このセクションでは、このような機能するためには、ルータとエンドノードの両方で展開する必要があるメカニズムの鶏と卵の展開の問題、そして今日ミドルボックスの幅広い展開によって生じる問題として、主要な展開の問題のいくつかを議論しますそれは、既知または未知のIPオプションの使用をブロックします。
Section 4.7 discusses some of the issues with deciding the initial sending rate to request. Quick-Start raises additional issues about the communication between the transport protocol and the application, and about the use of past history with Quick-Start in the end node.
4.7節では、要求に初期送信レートを決定するとの問題のいくつかを説明します。クイックスタートは、トランスポートプロトコルとアプリケーション間の通信に関する追加の問題を提起し、エンドノードでのクイックスタートと過去の歴史の使用に関する。
One possibility is that a protocol implementation could provide an API for applications to indicate when they want to request Quick-Start, and what rate they would like to request. In the conventional socket API, this could be a socket option that is set before a connection is established. Some applications, such as those that use TCP for bulk transfers, do not have interest in the transmission rate, but they might know the amount of data that can be sent immediately. Based on this, the sender implementation could decide whether Quick-Start would be useful, and what rate should be requested.
一つの可能性は、プロトコルの実装が、彼らはクイックスタートを要求したい場合に示すために、アプリケーションのためのAPIを提供することができ、どのような割合、彼らが要求したいということです。従来のソケットAPIで、これは、接続が確立される前に設定されているソケットオプションである可能性があります。バルク転送にTCPを使用するものなどの一部のアプリケーションでは、伝送速度に興味を持っていないが、彼らはすぐに送信できるデータの量を知っているかもしれません。これに基づき、送信側の実装では、クイックスタートが有用であるかどうかを決めることができ、どのような割合は、要求されなければなりません。
We note that when Quick-Start is used, the TCP sender is required to save the QS Nonce and the TTL Diff when the Quick-Start Request is sent, and to implement an additional timer for the paced transmission of Quick-Start packets.
私たちは、クイックスタートを使用する場合、TCPの送信者がQSノンスとクイックスタートリクエストが送信されたTTL差分を保存するために、およびクイックスタートパケットのペース伝送のための追加のタイマーを実装するために必要であることに注意してください。
A router or other network host must be able to determine the approximate bandwidth of its outbound network interfaces in order to process incoming Quick-Start rate requests, including those that originate from the host itself. One possibility would be for hosts to rely on configuration information to determine link bandwidths; this has the drawback of not being robust to errors in configuration. Another possibility would be for network device drivers to infer the bandwidth for the interface and to communicate this to the IP layer.
ルータまたは他のネットワークホストは、ホスト自体に由来するものを含む着信クイックスタートレート要求を処理するために、そのアウトバウンドネットワークインタフェースのおおよその帯域幅を決定することができなければなりません。一つの可能性は、リンク帯域幅を決定するために、構成情報に依存するホストのためになります。これはコンフィギュレーションのエラーに対してロバストではないという欠点があります。ネットワークデバイスドライバは、インターフェイスの帯域幅を推測すると、IPレイヤにこれを通信するための別の可能性があろう。
Particular issues will arise for wireless links with variable bandwidth, where decisions will have to be made about how frequently the host gets updates of the changing bandwidth. It seems appropriate that Quick-Start Requests would be handled particularly conservatively for links with variable bandwidth; to avoid cases where Quick-Start Requests are approved, the link bandwidth is reduced, and the data packets that are sent end up being dropped.
特定の問題は、意思決定は、ホストが変化する帯域幅のアップデートを取得する頻度について行われなければならない可変帯域幅、との無線リンクのために発生します。クイックスタート要求が可変帯域幅とのリンクのために特に保守的に処理されるのが適当と思われます。クイックスタート要求が承認されている例を避けるために、リンクの帯域幅が減少し、アップエンドに送信されたデータパケットはドロップされています。
Difficult issues also arise for paths with multi-access links (e.g., Ethernet). Routers or end-nodes with multi-access links should be particularly conservative in granting Quick-Start Requests. In particular, for some multi-access links, there may be no procedure for an attached node to use to determine whether all parts of the multi-access link have been underutilized in the recent past.
困難な問題は、マルチアクセスリンク（例えば、イーサネット（登録商標））とのパスを生じます。マルチアクセスリンクを持つルータまたはエンド・ノードは、クイックスタート要求を許可する上で特に保守的でなければなりません。特に、いくつかのマルチアクセスリンクのために、マルチアクセスリンクのすべての部分が、最近では十分に活用されているかどうかを決定するために使用するように接続されたノードのための手順が存在しない場合があります。
Because of possible problems discussed above concerning using Quick-Start over some network paths and the security issues discussed in Section 11, the most realistic initial deployment of Quick-Start would most likely take place in intranets and other controlled environments. Quick-Start is most useful on high bandwidth-delay paths that are significantly underutilized. The primary initial users of Quick-Start would likely be in organizations that provide network services to their users and also have control over a large portion of the network path.
そのため、セクション11で述べたいくつかのネットワークパスとセキュリティの問題上でクイックスタートを使用してに関する上述の問題が発生していること、クイックスタートの最も現実的な初期配備は、最も可能性の高いイントラネットおよびその他の制御された環境で行われます。クイックスタートが大幅に十分に活用されている高帯域幅、遅延パスに最も有用です。クイックスタートの主要な初期ユーザーは、おそらく自分のユーザーにネットワークサービスを提供し、またネットワークパスの大部分を管理している組織になります。
Quick-Start is not currently intended for ubiquitous deployment in the global Internet. In particular, Quick-Start should not be enabled by default in end-nodes or in routers; instead, when Quick-Start is used, it should be explicitly enabled by users or system administrators.
クイックスタートは、現在、グローバルなインターネットにおけるユビキタス展開するためのものではありません。具体的には、クイックスタートは、エンド・ノードまたはルータではデフォルトで有効にすべきではありません。クイックスタートを使用した場合に代わりに、それが明示的にユーザーやシステム管理者によって有効にする必要があります。
Below are a few examples of networking environments where Quick-Start would potentially be useful. These are the environments that might consider an initial deployment of Quick-Start in the routers and end-nodes, where the incentives for routers to deploy Quick-Start might be the most clear.
以下は、クイックスタートが潜在的に有用であろうネットワーク環境の例をいくつか示します。これらは、クイックスタートを展開するルータのためのインセンティブが最も明確かもしれないルータやエンドノードでのクイックスタートの初期配備を検討するかもしれない環境です。
* Centrally administrated organizational intranets: These intranets often have large network capacity, with networks that are underutilized for much of the time [PABL+05]. Such intranets might also include high-bandwidth and high-delay paths to remote sites. In such an environment, Quick-Start would be of benefit to users, and there would be a clear incentive for the deployment of Quick-Start in routers. For example, Quick-Start could be quite useful in high-bandwidth networks used for scientific computing.
*中心部の組織のイントラネットを投与され：これらのイントラネットは、しばしば時間の多くを十分に活用されているネットワーク[PABL + 05]で、大規模なネットワーク容量を持っています。このようなイントラネットは、リモートサイトへの高帯域幅、高遅延パスが含まれる場合があります。このような環境では、クイックスタートは、ユーザーに有益であろう、とルータでクイックスタートを展開するための明確なインセンティブが存在することになります。例えば、クイックスタートは、科学技術計算のために使用される高帯域幅のネットワークで非常に有用である可能性があります。
* Wireless networks: Quick-Start could also be useful in high-delay environments of Cellular Wide-Area Wireless Networks, such as the GPRS [BW97] and their enhancements and next generations. For example, GPRS EDGE (Enhanced Data for GSM Evolution) is expected to provide wireless bandwidth of up to 384 Kbps (roughly 32 1500-byte packets per second) while the GPRS round-trip times range typically from a few hundred milliseconds to over a second, excluding any possible queueing delays in the network [GPAR02]. In addition, these networks sometimes have variable additional delays due to resource allocation that could be avoided by keeping the connection path constantly utilized, starting from initial slow-start. Thus, Quick-Start could be of significant benefit to users in these environments.
*ワイヤレスネットワーク：クイックスタートはまた、GPRS [BW97]とその機能強化し、次の世代としてセルラー広域無線ネットワークの高遅延環境で有用である可能性があります。例えば、（GSM進化のためのデータを拡張）のGPRS EDGEはGPRS往復時間は数百ミリ秒から上に、典型的には範囲ながら、最大384 Kbpsの（秒あたりおおよそ32 1500バイトのパケット）の無線帯域幅を提供することが期待されます二、[GPAR02]ネットワーク内の任意の可能なキューイング遅延を除きます。また、これらのネットワークは時々初期スロースタートから始めて、常に利用接続パスを保つことによって避けることができる資源配分による変数の追加遅延を有します。このように、クイックスタートは、これらの環境では、ユーザーに大きな利益をもたらす可能性があります。
* Paths over satellite links: Geostationary Orbit (GEO) satellite links have one-way propagation delays on the order of 250 ms while the bandwidth can be measured in megabits per second [RFC2488]. Because of the considerable bandwidth-delay product on the link, TCP's slow-start is a major performance limitation in the beginning of the connection. A large initial congestion window would be useful to users of such satellite links.
*衛星リンクを介してパス：帯域幅は次の[RFC2488]あたりのメガビットで測定することができるが静止軌道（GEO）衛星リンクは250ミリ秒程度の一方向伝搬遅延を有しています。そのため、リンク上のかなりの帯域遅延積の、TCPのスロースタートは、接続の開始時における主要な性能限界です。大きな初期輻輳ウィンドウは、このような衛星リンクのユーザーに有用であろう。
* Single-hop paths: Quick-Start should work well over point-to-point single-hop paths, e.g., from a host to an adjacent server. Quick-Start would work over a single-hop IP path consisting of a multi-access link only if the host was able to determine if the path to the next IP hop has been significantly underutilized over the recent past. If the multi-access link includes a layer-2 switch, then the attached host cannot necessarily determine the status of the other links in the layer-2 network.
*シングルホップ経路：クイックスタートは、隣接サーバにホストから、例えば、ポイント・ツー・ポイントのシングルホップ経路上に良好に動作すべきです。クイックスタートは、ホストが次のIPホップへのパスが大幅に最近の過去の上に十分に活用されたかどうかを決定することができた場合にのみ、マルチアクセスリンクからなるシングルホップIPパス上に働くだろう。マルチアクセスリンクは、レイヤ2スイッチを含む場合、次に接続されたホストは、必ずしもレイヤ2ネットワーク内の他のリンクの状態を判断することができません。
Given the glacially slow rate of deployment of ECN in the Internet to date [MAF05], it is disconcerting to note that some of the deployment problems of Quick-Start are even greater than those of ECN. First, unlike ECN, which can be of benefit even if it is only deployed on one of the routers along the end-to-end path, a connection's use of Quick-Start requires Quick-Start deployment on all of the routers along the end-to-end path. Second, unlike ECN, which uses an allocated field in the IP header, Quick-Start requires the extra complications of an IP Option, which can be difficult to pass through the current Internet [MAF05].
これまでのインターネット[MAF05]にECNの展開の氷河ゆっくりとした速度を考えると、クイックスタートの展開問題のいくつかは、ECNのものよりも、大きいことに注意することは当惑です。まず、それが唯一のエンド・ツー・エンドのパスに沿ったルータの1つに配備されている場合でも有益である可能ECNとは異なり、クイックスタートの接続の使用は、端部に沿って、ルータのすべてのクイックスタートの展開が必要です-to-エンドパス。第二に、IPヘッダに割り当てられたフィールドを使用していますECNとは異なり、クイックスタートは、現在のインターネット[MAF05]を通過することが困難な場合がIPオプションの余分な合併症を必要とします。
However, in spite of these issues, there is some hope for the deployment of Quick-Start, at least in protected corners of the Internet, because the potential benefits of Quick-Start to the user are considerably more dramatic than those of ECN. Rather than simply replacing the occasional dropped packet by an ECN-marked packet, Quick-Start is capable of dramatically increasing the throughput of connections in underutilized environments [SAF06].
ユーザーへのクイックスタートの潜在的な利点は、かなり多くの劇的なECNのものよりあるのでしかし、これらの問題にもかかわらず、クイックスタートを展開するためのいくつかの希望は、少なくともインターネットの保護されたコーナーでは、そこにあります。むしろ単に時折を交換するよりもECN-マークパケットでパケットを落とし、クイックスタートが劇的に活用されていない環境で[SAF06]に接続のスループットを増加させることができます。
Sections 9.4 and 9.6 discuss the security considerations related to Quick-Start. Section 9.4 discusses the potential abuse of Quick-Start by senders or receivers lying about whether the request was approved or about the approved rate, and of routers in collusion to misuse Quick-Start. Section 9.5 discusses potential problems with traffic normalizers that rewrite IP TTLs in packet headers. All these problems could result in the sender using a Rate Request that was inappropriately large, or thinking that a request was approved when it was in fact denied by at least one router along the path. This inappropriate use of Quick-Start could result in congestion and an unacceptable level of packet drops along the path. Such congestion could also be part of a Denial of Service attack.
セクション9.4と9.6は、クイックスタートに関連するセキュリティ上の考慮事項について説明します。 9.4節では、要求が承認されたかどうかについて、または承認率について嘘の送信者や受信機のクイックスタートの可能性虐待について説明し、共謀のルータのクイックスタートを誤用します。 9.5節では、パケットヘッダ内のIP TTLを書き換えるトラフィック正規化の潜在的な問題について説明します。すべてのこれらの問題は、不適切に大きな、またはそれは実際には、パスに沿って、少なくとも1つのルータによって拒否された場合は、要求が承認されたことを考えていたレート要求を使用して、送信者につながる可能性があります。クイックスタートのこの不適切な使用は混雑し、パスに沿ってパケットドロップの許容できないレベルにつながる可能性があります。このような混雑はまた、サービス拒否攻撃の一部である可能性があります。
Section 9.6 discusses a potential attack on the routers' processing and state load from an attack of Quick-Start Requests. Section 9.6 also discusses a potential attack on the available Quick-Start bandwidth by sending bogus Quick-Start Requests for bandwidth that will not, in fact, be used. While this impacts the global usability of Quick-Start, it does not endanger the network as a whole since TCP uses standard congestion control if Quick-Start is not available.
セクション9.6は、クイックスタート要求の攻撃からのルータの処理および状態負荷に対する潜在的な攻撃を論じています。セクション9.6はまた、実際には、使用されることはありません帯域幅のための偽のクイックスタートリクエストを送信して利用できるクイックスタート帯域幅に対する潜在的な攻撃を論じています。クイックスタートが使用できない場合、TCPは、標準的な輻輳制御を使用していますので、この影響クイックスタートのグローバルなユーザビリティが、それは全体としてネットワークを危険にさらすことはありません。
Section 4.7.2 discusses the potential problem of packets with Quick-Start Requests dropped by middleboxes along the path.
セクション4.7.2は、パスに沿った中間ボックスでドロップクイックスタート要求を持つパケットの潜在的な問題を論じています。
As discussed in Section 5, for IPv4 IPsec Authentication Header Integrity Check Value (AH ICV) calculation, the Quick-Start Option is a mutable IPv4 option and hence completely zeroed for AH ICV calculation purposes. This is also the treatment required by RFC 4302 for unrecognized IPv4 options. The IPv6 Quick-Start Option's IANA-allocated option type indicates that it is a mutable option; hence, according to RFC 4302, its option data is required to be zeroed for AH ICV computation purposes. See RFC 4302 for further explanation.
セクション5で論じたように、IPv4のIPsecの認証ヘッダー整合性の値（AH ICV）計算をチェックする、クイック・スタート・オプションは、可変のIPv4オプションひいては完全AH ICV計算のためにゼロです。また、これは認識されていないIPv4オプションについては、RFC 4302で必要とされる治療法です。 IPv6のクイック・スタート・オプションのIANAに割り当てられたオプションタイプは、それが変更可能な選択肢であることを示しています。したがって、RFC 4302によれば、そのオプションデータは、AH ICV計算のためにゼロにする必要があります。詳しい説明については、RFC 4302を参照してください。
Section 6.2 discusses possible problems of Quick-Start used by connections carried over simple tunnels that are not compatible with Quick-Start. In this case, it is possible that a Quick-Start Request is erroneously considered approved by the sender without the routers in the tunnel having individually approved the request, causing a false positive.
6.2節は、クイックスタートと互換性がありません、単純なトンネルで運ば接続で使用クイックスタートの可能性のある問題について説明します。この場合には、クイックスタート要求を誤って個々に有するトンネル内のルータせずに、送信者によって承認された偽陽性を引き起こして、要求を承認したとみなされることが可能です。
We note two high-order points here. First, the Quick-Start Nonce goes a long way towards preventing large-scale cheating. Second, even if a host occasionally uses Quick-Start when it is not approved by the entire network path, the network will not collapse. Quick-Start does not remove TCP's basic congestion control mechanisms; these will kick in when the network is heavily loaded, relegating any Quick-Start mistake to a transient.
ここでは上位2点に注意してください。まず、クイックスタートナンスは、大規模な不正行為を防止することに向けた長い道のりを行きます。第二に、それは全体のネットワークパスによって承認されていない場合、ホストが時折クイックスタートを使用した場合でも、ネットワークが崩壊しません。クイックスタートは、TCPの基本的な輻輳制御メカニズムを削除しません。ネットワークの負荷が高いときに、これらは一時的に任意のクイックスタートミスを格下げ、でキックします。
Quick-Start requires an IP Option and a TCP Option.
クイックスタートは、IPオプションとTCPオプションが必要です。
Quick-Start requires both an IPv4 Option Number (Section 3.1) and an IPv6 Option Number (Section 3.2).
クイックスタートは、IPv4オプション番号（3.1節）とIPv6オプション番号（3.2節）の両方が必要です。
IPv4 Option Number:
IPv4のオプション番号：
Copy Class Number Value Name
---- ----- ------ ----- ----
0 00 25 25 QS - Quick-Start
IPv6 Option Number [RFC2460]:
IPv6のオプション番号[RFC2460]：
HEX act chg rest
--- --- --- -----
6 00 1 00110 Quick-Start
For the IPv6 Option Number, the first two bits indicate that the IPv6 node may skip over this option and continue processing the header if it doesn't recognize the option type, and the third bit indicates that the Option Data may change en-route.
IPv6のオプション番号のため、最初の2ビットは、オプションタイプを認識しない場合にIPv6ノードは、このオプションをスキップし、ヘッダを処理し続けることができることを示し、第3ビットは、オプションデータは、EN-経路変更することができることを示しています。
In both cases, this document should be listed as the reference document.
両方の場合において、この文書は参考文献として記載されるべきです。
Quick-Start requires a TCP Option Number (Section 4.2).
クイックスタートは、TCPオプション番号（4.2節）が必要です。
TCP Option Number:
TCPオプション番号：
Kind Length Meaning
---- ------ ------------------------------
27 8 Quick-Start Response
This document should be listed as the reference document.
この文書は参考文書として表示されます。
We are presenting the Quick-Start mechanism as a simple, understandable, and incrementally deployable mechanism that would be sufficient to allow some connections to start up with large initial rates, or large initial congestion windows, in over-provisioned, high-bandwidth environments. We expect there will be an increasing number of over-provisioned, high-bandwidth environments where the Quick-Start mechanism, or another mechanism of similar power, could be of significant benefit to a wide range of traffic. We are presenting the Quick-Start mechanism as a request for the community to provide feedback and experimentation on issues relating to Quick-Start.
私たちは、いくつかの接続がオーバープロビジョニング、高帯域幅の環境では、大規模な初期速度、または大きな初期輻輳ウィンドウで起動することを可能にするのに十分である、シンプルに理解、およびインクリメンタル展開可能なメカニズムとしてクイックスタートメカニズムを提示しています。私たちは、クイック・スタート・メカニズム、または類似の電力の別のメカニズムは、トラフィックの広い範囲に大きな利益をもたらす可能性があり、オーバープロビジョニング、高帯域幅環境の増加があるだろう期待しています。私たちは、クイックスタートに関連する問題についてのフィードバックや実験を提供するために、コミュニティのための要求としてクイックスタートメカニズムを提示しています。
The authors wish to thank Mark Handley for discussions of these issues. The authors also thank the End-to-End Research Group, the Transport Services Working Group, and members of IPAM's program on Large-Scale Communication Networks for both positive and negative feedback on this proposal. We thank Srikanth Sundarrajan for the initial implementation of Quick-Start in the NS simulator, and for the initial simulation study. Many thanks to David Black and Joe Touch for extensive feedback on Quick-Start and IP tunnels. We also thank Mohammed Ashraf, John Border, Bob Briscoe, Martin Duke, Tom Dunigan, Mitchell Erblich, Gorry Fairhurst, John Heidemann, Paul Hyder, Dina Katabi, and Vern Paxson for feedback. Thanks also to Gorry Fairhurst for the suggestion of adding the QS Nonce to the Report of Approved Rate.
著者らは、これらの問題の議論のためのマーク・ハンドリーに感謝したいです。著者らはまた、この提案の両方の正と負のフィードバックのための大規模通信ネットワーク上のエンド・ツー・エンドの研究グループ、転送サービスワーキンググループ、およびIPAMのプログラムのメンバーに感謝します。私たちは、NSシミュレータでのクイックスタートの最初の実装のため、初期シミュレーション研究のためのスリカンスSundarrajanに感謝します。クイックスタートとIPトンネルに関する広範なフィードバックのためのデビッド・ブラックとジョー・タッチに感謝します。また、フィードバックのためにモハメド・アシュラフ、ジョン・ボーダー、ボブ・ブリスコー、マーティン・デューク、トムDunigan、ミッチェルErblich、Gorry Fairhurst、ジョンHeidemann、ポール・ハイダル、ダイナ・カタビ、およびバーン・パクソンに感謝します。承認されたレートの報告書にQS nonceを追加する提案についてもGorry Fairhurstに感謝します。
The version of the QS Nonce in this document is based on a proposal from Guohan Lu [L05]. Earlier versions of this document contained an eight-bit QS Nonce, and subsequent versions discussed the possibility of a four-bit QS Nonce.
この文書に記載されているQSノンスのバージョンはGuohan呂[L05]からの提案に基づいています。この文書の以前のバージョンは、8ビットQSノンスを含有し、及びその後のバージョンでは、4ビットQSノンスの可能性を議論しました。
This document builds upon the concepts described in [RFC3390], [AHO98], [RFC2415], and [RFC3168]. Some of the text on Quick-Start in tunnels was borrowed directly from RFC 3168.
この文書では、[AHO98]、[RFC2415]及び[RFC3168]、[RFC3390]に記載された概念に基づいて構築します。トンネル内のクイック・スタートのテキストの一部は、RFC 3168から直接借りました。
This document is the development of a proposal originally by Amit Jain for Initial Window Discovery.
この文書では、初期ウィンドウ発見のためのアミット・ジェインによってもともとの提案の開発です。
Appendix A. Related Work
付録A.関連作品
The Quick-Start proposal, taken together with HighSpeed TCP [RFC3649] or other transport protocols for high-bandwidth transfers, could go a significant way towards extending the range of performance for best-effort traffic in the Internet. However, there are many things that the Quick-Start proposal would not accomplish. Quick-Start is not a congestion control mechanism, and would not help in making more precise use of the available bandwidth -- that is, of achieving the goal of high throughput with low delay and low packet-loss rates. Quick-Start would not give routers more control over the decrease rates of active connections.
高速TCP [RFC3649]や高帯域幅の転送のための他のトランスポートプロトコルと一緒になってクイックスタートの提案は、インターネットでのベストエフォートトラフィックのパフォーマンスの範囲を拡大に向けての重要な道を行くことができます。しかし、クイックスタートの提案は実現しないことを多くのものがあります。クイックスタートは、輻輳制御機構ではなく、利用可能な帯域幅をより正確に使用することには役に立たない - つまり、低遅延、低パケット損失率と高スループットの目標を達成します。クイックスタートは、ルータにアクティブな接続の減少率をより詳細に制御を与えないだろう。
In addition, any evaluation of Quick-Start must include a discussion of the relative benefits of approaches that use no explicit information from routers, and of approaches that use more fine-grained feedback from routers as part of a larger congestion control mechanism. We discuss several classes of proposals in the sections below.
また、クイックスタートのいずれかの評価は、ルータから、より大きな輻輳制御機構の一部としてのルータから、よりきめの細かいフィードバックを使用するアプローチの明示的な情報を使用しないアプローチの相対的な利点の議論を含まなければなりません。私たちは、以下のセクションでの提案のいくつかのクラスを議論します。
A.1. Fast Start-Ups without Explicit Information from Routers
A.1。ファスト・スタート・アップルータからの明示的な情報なし
One possibility would be for senders to use information from the packet streams to learn about the available bandwidth, without explicit information from routers. These techniques would not allow a start-up as fast as that available from Quick-Start in an underutilized environment; one already has to have sent some packets in order to use the packet stream to learn about available bandwidth. However, these techniques could allow a start-up considerably faster than the current Slow-Start. While it seems clear that approaches *without* explicit feedback from the routers will be strictly less powerful than is possible *with* explicit feedback, it is also possible that approaches that are more aggressive than Slow-Start are possible without the complexity involved in obtaining explicit feedback from routers.
送信者がルーターからの明示的な情報がなく、利用可能な帯域幅について学ぶためにパケットストリームからの情報を使用するようにするための1つの可能性は次のようになります。これらの技術は活用されていない環境でのクイックスタートからの利用可能な限り速く起動を許可しないでしょう。一つは、すでに利用可能な帯域幅について学ぶためにパケットストリームを使用するために、いくつかのパケットを送信している必要があります。しかし、これらの技術は、起動電流スロースタートよりもかなり速くする可能性があります。それは*明示的なフィードバックと*ルーターからの明示的なフィードバックが可能であるよりも厳密に小さい強力になります*なし*近づく明確なようだが、スロースタートより積極的なアプローチを得ることに伴う複雑させずに可能であることも可能ですルータからの明示的なフィードバック。
Periodic packet streams: [JD02] explores the use of periodic packet streams to estimate the available bandwidth along a path. The idea is that the one-way delays of a periodic packet stream show an increasing trend when the stream's rate is higher than the available bandwidth (due to an increasing queue). While [JD02] states that the proposed mechanism does not cause significant increases in network utilization, losses, or delays when done by one flow at a time, the approach could be problematic if conducted concurrently by a number of flows. [JD02] also gives an overview of some of the earlier work on inferring the available bandwidth from packet trains.
周期的なパケットストリーム：[JD02】経路に沿って利用可能な帯域幅を推定する周期パケット・ストリームの使用を探ります。アイデアは、ストリームの割合は（上昇によりキューに）利用可能な帯域幅よりも高い場合には定期的なパケットストリームの一方向遅延が増加傾向を示すことです。 【JD02]は一度に一つの流れによって行われたときに提案されたメカニズムは、ネットワーク使用率、損失や遅延の有意な増加を引き起こさないことを述べながら、フローの数で同時に行われた場合、このアプローチは、問題となる可能性があります。 [JD02]もパケットトレインから利用可能な帯域幅を推定する上で、以前の作品のいくつかの概要を説明します。
Swift-Start: The Swift Start proposal from [PRAKS02] combines packet-pair and packet-pacing techniques. An initial congestion window of four segments is used to estimate the available bandwidth along the path. This estimate is then used to dramatically increase the congestion window during the second RTT of data transmission.
スウィフトスタート：[PRAKS02]からスウィフトスタートの提案は、パケットペアやパケットペーシング技術を兼ね備えています。 4つのセグメントの最初の輻輳ウィンドウは、パスに沿って利用可能な帯域幅を推定するために使用されます。この推定値は、その後、劇的第RTTデータの送信中に混雑ウィンドウを増加させるために使用されます。
SPAND: In the TCP/SPAND proposal from [ZQK00] for speeding up short data transfers, network performance information would be shared among many co-located hosts to estimate each connection's fair share of the network resources. Based on such estimation and the transfer size, the TCP sender would determine the optimal initial congestion window size. The design for TCP/SPAND uses a performance gateway that monitors all traffic entering and leaving an organization's network.
SPAND：[ZQK00]短いデータ転送を高速化するために、ネットワークのパフォーマンス情報は、ネットワークリソースの各接続の公正なシェアを推定するために、多くの同じ場所に配置するホスト間で共有されるだろうから、TCP / SPANDの提案で。そのような推定と転送サイズに基づいて、TCPの送信者は、最適な初期の輻輳ウィンドウサイズを決定します。 TCP / SPANDのデザインは、すべてのトラフィックが入ると組織のネットワークを残して監視し、パフォーマンスのゲートウェイを使用しています。
Sharing information among TCP connections: The Congestion Manager [RFC3124] and TCP control block sharing [RFC2140] both propose sharing congestion information among multiple TCP connections with the same endpoints. With the Congestion Manager, a new TCP connection could start with a high initial cwnd, if it was sharing the path and the cwnd with a pre-existing TCP connection to the same destination that had already obtained a high congestion window. RFC 2140 discusses ensemble sharing, where an established connection's congestion window could be `divided up' to be shared with a new connection to the same host. However, neither of these approaches addresses the case of a connection to a new destination, with no existing or recent connection (and therefore congestion control state) to that destination.
TCP接続の間で情報を共有する：輻輳マネージャ[RFC3124]とTCP制御ブロックを共有する[RFC2140]は両方とも同じエンドポイントと複数のTCP接続の間で渋滞情報を共有提案します。それはすでに高い輻輳ウィンドウを得ていた同じ宛先への既存のTCP接続でパスとのcwndを共有していた場合輻輳Managerでは、新しいTCP接続は、高い初期のcwndを開始することができます。 RFC 2140は、確立された接続の輻輳ウィンドウは、 `「分割することができ、同じホストへの新しい接続と共有するアンサンブル共有を、説明します。しかし、これらのアプローチのどちらがその宛先への既存または最近の接続（したがって、輻輳制御状態）で、新しい宛先への接続の場合に対応しています。
While continued research on the limits of the ability of TCP and other transport protocols to learn of available bandwidth without explicit feedback from the router seems useful, we note that there are several fundamental advantages of explicit feedback from routers.
ルータからの明示的なフィードバックなしで利用可能な帯域幅を学ぶためのTCPや他のトランスポートプロトコルの能力の限界に継続的な研究が有用と思われるが、我々は、ルータからの明示的なフィードバックのいくつかの基本的な利点があることに注意してください。
(1) Explicit feedback is faster than implicit feedback: One advantage of explicit feedback from the routers is that it allows the transport sender to reliably learn of available bandwidth in one round-trip time.
（1）明示的なフィードバックは、暗示的なフィードバックよりも高速です：ルータからの明示的なフィードバックの利点の一つは、それがトランスポート送信者が確実に1ラウンドトリップ時間に利用可能な帯域幅を知ることを可能にするということです。
(2) Explicit feedback is more reliable than implicit feedback: Techniques that attempt to assess the available bandwidth at connection start-up using implicit techniques are more error-prone than techniques that involve every element in the network path. While explicit information from the network can be wrong, it has a much better chance of being appropriate than an end-host trying to *estimate* an appropriate sending rate using "block box" probing techniques of the entire path.
（2）明示的なフィードバックは、暗示的なフィードバックよりも信頼性がある：接続で利用可能な帯域幅が起動暗黙の技術を使用して評価しようとする技術は、より多くのエラーが発生しやすいネットワークパス内のすべての要素を伴う技術よります。ネットワークからの明示的な情報が間違っている可能性がありますが、それは*推定*パス全体の技術をプロービング「ブロックボックス」を使用して、適切な送信レートしようとしているエンドホストより適切であることのより良いチャンスがあります。
A.2. Optimistic Sending without Explicit Information from Routers
A.2。楽観ルータからの明示的な情報なしで送信
Another possibility that has been suggested [S02] is for the sender to start with a large initial window without explicit permission from the routers and without bandwidth estimation techniques and for the first packet of the initial window to contain information, such as the size or sending rate of the initial window. The proposal would be that congested routers would use this information in the first data packet to drop or delay many or all of the packets from that initial window. In this way, a flow's optimistically large initial window would not force the router to drop packets from competing flows in the network. Such an approach would seem to require some mechanism for the sender to ensure that the routers along the path understood the mechanism for marking the first packet of a large initial window.
送信者は、このようなサイズや送信など、ルータからの明示的な許可なしにして、帯域幅推定技術なしとの情報を格納するための初期ウィンドウの最初のパケットのために大きな初期ウィンドウで開始するために提案されたもう一つの可能性[S02]は、初期ウィンドウの割合。提案は混雑ルータがドロップするか、その初期ウィンドウからパケットの多くまたはすべてを遅らせるために最初のデータパケットにこの情報を使用することになります。このように、流れ者の楽観大きな初期ウィンドウには、ネットワーク内の競合フローからのパケットをドロップするようにルータを強制しないでしょう。そのようなアプローチは、経路に沿ったルータが大きい初期ウィンドウの最初のパケットをマーキングするための機構を理解することを確実にするために、送信者のためのいくつかのメカニズムを必要とすると思われます。
Obviously, there would be a number of questions to consider about an approach of optimistic sending.
もちろん、楽観送信のアプローチについて検討する質問の数が存在することになります。
(1) Incremental deployment: One question would be the potential complications of incremental deployment, where some of the routers along the path might not understand the packet information describing the initial window.
（1）インクリメンタル展開：一つの疑問は、パスに沿ったルーターのいくつかは、最初のウィンドウを記述したパケット情報を理解していない可能性があります増分展開の潜在的な合併症、だろう。
(2) Congestion collapse: There could also be concerns about congestion collapse if many flows used large initial windows, many packets were dropped from optimistic initial windows, and many congested links ended up carrying packets that are only going to be dropped downstream.
（2）輻輳崩壊：多くのフローが大きな初期ウィンドウを使用した場合も、輻輳崩壊の懸念がある可能性があり、多くのパケットのみを下流ドロップしようとしているパケットを運ぶことになった楽観初期ウィンドウ、および多くの混雑したリンクから削除されました。
(3) Distributed Denial of Service attacks: A third question would be the potential role of optimistic senders in amplifying the damage done by a Distributed Denial of Service (DDoS) attack (assuming attackers use compliant congestion control in the hopes of "flying under the radar").
（3）サービス拒否攻撃を分散：3番目の質問は、分散型サービス拒否（DDoS攻撃）攻撃によるダメージを増幅するのに楽観的な送信者の潜在的な役割になります（と仮定すると、攻撃者は、下の飛行」を期待して準拠した輻輳制御を使用レーダー"）。
(4) Performance hits if a packet is dropped: A fourth issue would be to quantify the performance hit to the connection when a packet is dropped from one of the initial windows.
パケットが破棄された場合（4）パフォーマンスヒット：第四の問題は、パケットが最初のウィンドウのいずれかからドロップされたときに、接続にパフォーマンスヒットを定量化することです。
A.3. Fast Start-Ups with Other Information from Routers
A.3。ルータから他の情報とファスト・スタートアップ
There have been several proposals somewhat similar to Quick-Start, where the transport protocol collects explicit information from the routers along the path.
トランスポートプロトコルは、パスに沿ったルーターからの明示的な情報を収集し、クイックスタート、と少し似て、いくつかの提案がなされています。
An IP Option about the free buffer size: In related work, [P00] investigates the use of a slightly different IP option for TCP connections to discover the available bandwidth along the path. In that proposal, the IP option would query the routers along the path about the smallest available free buffer size. Also, the IP option would have been sent after the initial SYN exchange, when the TCP sender already had an estimate of the round-trip time.
空きバッファサイズに関するIPオプション：TCP接続がパスに沿って利用可能な帯域幅を発見するために、関連する作業では、[P00]はわずかに異なるIPオプションの使用を調査します。その提案では、IPオプションは最小の使用可能な空きバッファのサイズについての経路に沿ってルータを照会します。 TCPの送信者がすでに往復時間の見積もりを持っていたときも、IPオプションは、最初のSYN交換後に送られていたであろう。
The Performance Transparency Protocol: The Performance Transparency Protocol (PTP) includes a proposal for a single PTP packet that would collect information from routers along the path from the sender to the receiver [W00]. For example, a single PTP packet could be used to determine the bottleneck bandwidth along a path.
パフォーマンス透明プロトコル：パフォーマンス透明プロトコル（PTP）は、受信[W00]の送信者からの経路に沿ってルータから情報を収集することになる単一のPTPパケットの提案を含みます。例えば、単一のPTPのパケットが経路に沿ったボトルネック帯域幅を決定するために使用することができます。
ETEN: Additional proposals for end nodes to collect explicit information from routers include one variant of Explicit Transport Error Notification (ETEN), which includes a cumulative mechanism to notify endpoints of aggregate congestion statistics along the path [KAPS02]. (A second variant in [KSEPA04] does not depend on cumulative congestion statistics from the network.)
ETEN：ルータからの明示的な情報を収集するためにエンドノードのための追加の提案は、パス[KAPS02]に沿って集約輻輳統計のエンドポイントに通知する累積機構を含む明示的なトランスポート・エラー通知（ETEN）、のいずれかの変異体が含まれます。 （[KSEPA04]における第二の変形例では、ネットワークからの累積輻輳統計に依存しません。）
A.4. Fast Start-Ups with more Fine-Grained Feedback from Routers
A.4。ルータからのより多くのファイングレインフィードバックによる高速スタートアップ
Proposals for more fine-grained, congestion-related feedback from routers include XCP [KHR02], MaxNet [MaxNet], and AntiECN marking [K03]. Appendix B.6 discusses in more detail the relationship between Quick-Start and proposals for more fine-grained per-packet feedback from routers.
ルータから、よりきめ細かい、輻輳に関するフィードバックのための提案は、マーキングXCP [KHR02]、MAXNET [MAXNET]、及びAntiECN [K03]を含みます。付録B.6は、より詳細にクイックスタートやルータからのよりきめ細かいパケットごとのフィードバックのための提案との関係について説明します。
XCP: Proposals, such as XCP for new congestion control mechanisms based on more feedback from routers, are more powerful than Quick-Start, but also are more complex to understand and more difficult to deploy. XCP routers maintain no per-flow state, but provide more fine-grained feedback to end-nodes than the one-bit congestion feedback of ECN. The per-packet feedback from XCP can be positive or negative, and specifies the increase or decrease in the sender's congestion window when this packet is acknowledged. XCP is a full-fledge congestion control scheme, whereas Quick-Start represents a quick check to determine if the network path is significantly underutilized such that a connection can start faster and then fall back to TCP's standard congestion control algorithms.
XCP：ルーターからのより多くのフィードバックをもとに、新たな輻輳制御メカニズムのためのXCPとして提案は、クイックスタートよりも強力ですが、また理解し、より複雑で展開するのがより困難です。 XCPルータにはフローごとの状態を維持しないが、ECNの1ビット輻輳フィードバックよりも、ノードを終了するために、よりきめ細かなフィードバックを提供します。 XCPからパケット単位のフィードバックは、正または負であり、このパケットが確認されたときに、送信者の輻輳ウィンドウの増減を指定することができます。クイックスタートは、ネットワークパスが大きく、接続が速く開始し、TCPの標準輻輳制御アルゴリズムにフォールバックすることができるように十分に活用されたかどうかを判断するための簡単なチェックを表し、一方、XCPは、フルひな鳥を育てるの輻輳制御方式です。
AntiECN: The AntiECN proposal is for a single bit in the packet header that routers could set to indicate that they are underutilized. For each TCP ACK arriving at the sender indicating that a packet has been received with the Anti-ECN bit set, the sender would be able to increase its congestion window by one packet, as it would during slow-start.
AntiECN：AntiECN提案は、ルータは、それらが十分に活用されていることを示すように設定することができ、パケットヘッダ内の単一のビットのためのものです。各TCP ACKパケットがアンチECNビットを設定して受信されたことを示す送信側に到着するために、送信者は、それはスロースタートの際と同じように、一つのパケットによってその輻輳ウィンドウを増加させることができるだろう。
A.5. Fast Start-Ups with Lower-Than-Best-Effort Service
A.5。低い - ベストエフォート型サービスによる高速スタートアップ
There have been proposals for routers to provide a Lower Effort differentiated service that would be lower than best effort [RFC3662]. Such a service could carry traffic for which delivery is strictly optional, or could carry traffic that is important but that has low priority in terms of time. Because it does not interfere with best-effort traffic, Lower Effort services could be used by transport protocols that start up faster than slow-start. For example, [SGF05] is a proposal for the transport sender to use low-priority traffic for much of the initial traffic, with routers configured to use strict priority queueing.
ベストエフォート[RFC3662]よりも低くなる低努力差別化サービスを提供するルータのための提案がなされてきました。このようなサービスは、配信が厳密にオプションである、または重要であるが、それは時間的に低い優先度を持つトラフィックを運ぶことができたのトラフィックを運ぶことができます。それはベストエフォートトラフィックに干渉しないので、低エフォートサービスは、より高速なスロースタートよりも起動トランスポートプロトコルで使用することができます。例えば、[SGF05]厳密なプライオリティキューイングを使用するように構成されたルータと、初期トラフィックの大部分のために低優先度のトラフィックを使用するトランスポート送信者の提案です。
A separate but related issue is that of below-best-effort TCP, variants of TCP that would not rely on Lower Effort services in the network, but would approximate below-best-effort traffic by detecting and responding to congestion sooner than standard TCP. TCP Nice [V02] and TCP Low Priority (TCP-LP) [KK03] are two such proposals for below-best-effort TCP, with the purpose of allowing TCP connections to use the bandwidth unused by TCP and other traffic in a non-intrusive fashion. Both TCP Nice and TCP Low Priority use the default slow-start mechanisms of TCP.
別のしかし関連の問題は、以下の-ベストエフォート型のTCP、ネットワーク内の低エフォートサービスに依存していないだろうが、検出および標準のTCPよりも早く輻輳に応答することにより、下記のベストエフォート型トラフィックを近似うTCPの変種。 TCPニース[V02]およびTCP低優先度（TCP-LPは）[KK03] TCPコネクションが非でTCPおよびその他のトラフィックによって未使用の帯域幅の使用を可能にすることを目的とし、以下、ベストエフォート型のTCP用の2つのそのような提案されています侵入ファッション。 TCPニースとTCP低優先度の両方がデフォルトでTCPのスロースタートメカニズムを使用します。
We note that Quick-Start is quite different from either a Lower-Effort service or a below-best-effort variant of TCP. Unlike these proposals, Quick-Start is intended to be useful for best-effort traffic that wishes to receive at least as much bandwidth as competing best-effort connections.
私たちは、クイックスタートが低エフォート型サービスやTCPの下に、ベストエフォート型のバリアントのいずれかとは全く異なることに注意してください。これらの提案とは異なり、クイックスタートはベストエフォート型の接続を競合と少なくとも同じくらいの帯域幅を受信したいベストエフォートトラフィックのために有用であることが意図されます。
Appendix B. Design Decisions
付録B.設計の決定
B.1. Alternate Mechanisms for the Quick-Start Request: ICMP and RSVP
B.1。 ICMPやRSVP：クイックスタート要求するための代替機構
This document has proposed using an IP Option for the Quick-Start Request from the sender to the receiver, and using transport mechanisms for the Quick-Start Response from the receiver back to the sender. In this section, we discuss alternate mechanisms, and consider whether ICMP ([RFC792], [RFC4443]) or RSVP [RFC2205] protocols could be used for delivering the Quick-Start Request.
この文書は、送信側から受信側へのクイックスタート要求のためのIPオプションを使用して、バック受信側から送信側へのクイック・スタート・レスポンスのためのトランスポート・メカニズムを使用して提案しています。このセクションでは、我々は別のメカニズムを議論し、ICMP（[RFC792]、[RFC4443]）またはRSVP [RFC2205]はプロトコルかどうかを検討クイックスタート要求を配信するために使用することができます。
B.1.1. ICMP
B.1.1。 ICMP
Being a control protocol used between Internet nodes, one could argue that ICMP is the ideal method for requesting permission for faster start-up from routers. The ICMP header is above the IP header. Quick-Start could be accomplished with ICMP as follows: If the ICMP protocol is used to implement Quick-Start, the equivalent of the Quick-Start IP option would be carried in the ICMP header of the ICMP Quick-Start Request. The ICMP Quick-Start Request would have to pass by the routers on the path to the receiver, possibly using the IP Router Alert option [RFC2113]. A router that approves the Quick-Start Request would take the same actions as in the case with the Quick-Start IP Option, and forward the packet to the next router along the path. A router that does not approve the Quick-Start Request, even with a decreased value for the Requested Rate, would delete the ICMP Quick-Start Request, and send an ICMP Reply to the sender that the request was not approved. If the ICMP Reply was dropped in the network, and did not reach the receiver, the sender would still know that the request was not approved from the absence of feedback from the receiver. If the ICMP Quick-Start Request was dropped in the network due to congestion, the sender would assume that the request was not approved. The ICMP message would need the source and destination port numbers for demultiplexing at the end nodes. If the ICMP Quick-Start Request reached the receiver, the receiver would use transport-level or application-level mechanisms to send a response to the sender, exactly as with the IP Option.
インターネットノード間で使用される制御プロトコルなので、一つはICMPルーターからより高速起動のための許可を要求するための理想的な方法であると主張することができます。 ICMPヘッダは、IPヘッダの上にあります。次のようにクイックスタートは、ICMPを用いて達成することができる：ICMPプロトコルはクイックスタートを実現するために使用されている場合、クイックスタートIPオプションの等価物は、ICMPクイックスタート要求のICMPヘッダで運ばれることになります。 ICMPクイックスタート要求はおそらくIPルータアラートオプション[RFC2113]を使用して、受信機へのパス上のルータを通過しなければなりません。クイックスタートリクエストを承認するルータは、クイックスタートIPオプション付きの場合と同じ行動を取ると、パスに沿って次のルータにパケットを転送します。でも、要求されたレートのために減少した値で、クイックスタートリクエストを承認していないルータは、ICMPクイックスタート要求を削除し、要求が承認されなかったことを送信者にICMP応答を送信します。 ICMP返信がネットワークに滴下し、受信機に到達しなかった場合、送信者は、まだ要求が受信機からのフィードバックの欠如から承認されていなかったことを知っているだろう。 ICMPクイックスタート要求が輻輳によるネットワークで落とされた場合、送信者は、要求が承認されなかったことを前提としています。 ICMPメッセージは、エンドノードに逆多重化するためのソースおよび宛先ポート番号を必要とします。 ICMPクイックスタート要求が受信機に到達した場合、受信機は正確にIPオプションと同様に、送信者への応答を送信するために、トランスポート・レベルまたはアプリケーションレベルのメカニズムを使用します。
One benefit of using ICMP would be that the delivery of the TCP SYN packet or other initial packet would not be delayed by IP option processing at routers. A greater advantage is that if middleboxes were blocking packets with Quick-Start Requests, using the Quick-Start Request in a separate ICMP packet would mean that the middlebox behavior would not affect the connection as a whole. (To get this robustness to middleboxes with TCP using an IP Quick-Start Option, one would have to have a TCP-level Quick-Start Request packet that could be sent concurrently with, but separately from, the TCP SYN packet.)
ICMPを使用する利点の1つは、TCP SYNパケットまたは他の最初のパケットの配信が、ルータでIPオプションの処理によって遅延されないということでしょう。大きな利点は、ミドルボックスは、別のICMPパケット内のクイックスタート要求を使用して、クイックスタート要求を持つパケットをブロックした場合にはミドルの振る舞いは、全体としての接続に影響を与えないことを意味するということです。 （IPクイック・スタート・オプションを使用してTCPとミドルボックスに、この堅牢性を得るために、一つはと同時に送ることができるTCPレベルクイックスタート要求パケットを持っている必要がありますが、個別にTCP SYNパケット、から。）
However, there are a number of disadvantages to using ICMP. Some firewalls and middleboxes may not forward the ICMP Quick-Start Request packets. (If an ICMP Reply packet from a router to the sender is dropped in the network, the sender would still know that the request was not approved, as stated earlier, so this would not be as serious of a problem.) In addition, it would be difficult, if not impossible, for a router in the middle of an IP tunnel to deliver an ICMP Reply packet to the actual source, for example, when the inner IP header is encrypted, as in IPsec ESP tunnel mode [RFC4301]. Again, however, the ICMP Reply packet would not be essential to the correct operation of ICMP Quick-Start.
ただし、ICMPを使用する多くの欠点があります。一部のファイアウォールおよびミドルボックスは、ICMPクイックスタートRequestパケットを転送しない場合があります。 （送信者へのルータからICMP応答パケットがネットワーク内でドロップされた場合、送信者はまだ先に述べたように、要求が、承認されなかったことを知っているであろう、ので、これは問題のように深刻ではないでしょう。）また、それを例えば、実際のソースにICMPリプライパケットを配信するIPトンネルの中央にルータの困難、不可能ではないであろう、内側IPヘッダは、IPSec ESPトンネルモード[RFC4301]のように、暗号化されている場合。ここでも、しかし、ICMP応答パケットは、ICMPクイックスタートの正しい動作に必須ではありません。
Unauthenticated out-of-band ICMP messages could enable some types of attacks by third-party malicious hosts that are not possible when the control information is carried in-band with the IP packets that can only be altered by the routers on the connection path. Finally, as a minor concern, using ICMP would cause a small amount of additional traffic in the network, which is not the case when using IP options.
アウトオブバンドICMPメッセージ認証されていないが、制御情報のみの接続経路上のルータによって変更することができるIPパケットに帯域内で実施されたときに可能ではありませんサードパーティ製の悪意のあるホストによってある種の攻撃を可能にすることができます。最後に、マイナーな懸念として、ICMPを使用すると、IPオプションを使用している場合ではありませんネットワークに追加の少量のトラフィックを、引き起こします。
B.1.2. RSVP
B.1.2。お返事お願いします
With some modifications, RSVP [RFC2205] could be used as a bearer protocol for carrying the Quick-Start Requests. Because routers are expected to process RSVP packets more extensively than the normal transport protocol IP packets, delivering a Quick-Start rate request using an RSVP packet would seem an appealing choice. However, Quick-Start with RSVP would require a few differences from the conventional usage of RSVP. Quick-Start would not require periodical refreshing of soft state, because Quick-Start does not require per-connection state in routers. Quick-Start Requests would be transmitted downstream from the sender to receiver in the RSVP Path messages, which is different from the conventional RSVP model where the reservations originate from the receiver. Furthermore, the Quick-Start Response would be sent using the transport-level or application-level mechanisms, instead of using the RSVP Resv message.
いくつかの変更を加えて、RSVP [RFC2205]はクイックスタート要求を搬送するためのベアラプロトコルとして使用することができます。ルータは魅力的な選択肢を思わRSVPパケットを使用してクイックスタートレート要求を提供し、より広範囲に通常のトランスポートプロトコルIPパケットよりもRSVPパケットを処理することが予想されるため。しかし、RSVPとクイックスタートは、RSVPの従来の使用法からのいくつかの違いが必要となります。クイックスタートは、ルータに接続ごとの状態を必要としないので、クイックスタートは、柔らかい状態の定期的なリフレッシュを必要としません。クイックスタート要求は、予約は、受信機から発信従来のRSVPモデルと異なるのRSVP Pathメッセージで送信側から受信側へ下流に送信されます。また、クイックスタート応答はトランスポート・レベルまたはアプリケーション・レベルのメカニズムを使用して、代わりにRSVP Resvメッセージを使用して送信されることになります。
If RSVP was used for carrying a Quick-Start Request, a new "Quick-Start Request" class object would be included in the RSVP Path message that is sent from the sender to receiver. The object would contain the rate request field in addition to the common length and type fields. The Send_TTL field in the RSVP common header could be used as the equivalent of the QS TTL field. The Quick-Start capable routers along the path would inspect the Quick-Start Request object in the RSVP Path message, decrement Send_TTL, and adjust the rate request field if needed. If an RSVP router did not understand the Quick-Start Request object, it would reject the entire RSVP message and send an RSVP PathErr message back to the sender. When an RSVP message with the Quick-Start Request object reaches the receiver, the receiver sends a Quick-Start Reply message in the corresponding transport protocol header in the same way as described in the context of IP options earlier. If the RSVP message with the Quick-Start Request object was dropped along the path, the transport sender would simply proceed with the normal congestion control procedures.
RSVPは、クイックスタート要求を運ぶために使用された場合は、新たに「クイックスタート要求」クラスのオブジェクトは、送信側から受信側に送信されるRSVP Pathメッセージに含まれることになります。オブジェクトは、共通の長さとタイプのフィールドに加えて、レート要求フィールドを含むであろう。 RSVP共通ヘッダ内Send_TTLフィールドはQS TTLフィールドの等価物として使用することができます。パスに沿ったクイックスタートが可能なルータは、RSVP Pathメッセージ、デクリメントSend_TTL、中クイック・スタート・リクエスト・オブジェクトを検査し、必要に応じてレート要求フィールドを調整します。 RSVPルータはクイックスタートRequestオブジェクトを理解していなかった場合、それは全体のRSVPメッセージを拒否し、送信者にRSVPののPathErrメッセージを送信します。 RSVPメッセージは、クイックスタート要求オブジェクトが受信機に到達すると、受信機は、クイックスタートを送信先にIPオプションの文脈で説明したのと同じ方法で、対応するトランスポート・プロトコル・ヘッダ内のメッセージを返信。クイック・スタート・リクエスト・オブジェクトとRSVPメッセージは、パスに沿って落下させた場合には、トランスポート送信者は、単に通常の輻輳制御手順を進めます。
Much of the discussion about benefits and drawbacks of using ICMP for making the Quick-Start Request also applies to the RSVP case. If the Quick-Start Request was transmitted in a separate packet instead of as an IP option, the transport protocol packet delivery would not be delayed due to IP option processing at the routers, and the initial transport packets would reach their destination more reliably. The possible disadvantages of using ICMP and RSVP are also expected to be similar: middleboxes in the network may not be able to forward the Quick-Start Request messages, and the IP tunnels might cause problems for processing the Quick-Start Requests.
クイックスタート要求を行うためにICMPを使用することの利点と欠点についての議論の多くはまた、RSVPの場合に適用されます。クイックスタート要求が別のパケットではなく、IPオプションとして送信された場合は、トランスポートプロトコルのパケット配信は、ルータによるIPオプションの処理に遅れることはないだろう、と最初のトランスポートパケットをより確実に目的地に到達します。 ICMPやRSVPを使用しての可能性のある欠点も同様のことが予想されています。ネットワーク上のミドルボックスは、クイックスタート要求メッセージを転送することができないかもしれない、とIPトンネルは、クイックスタート要求を処理するための問題を引き起こす可能性があります。
B.2. Alternate Encoding Functions
B.2。代替エンコーディング機能
In this section, we look at alternate encoding functions for the Rate Request field in the Quick-Start Request. The main requirements for this function is that it should have a sufficiently wide range for the requested rate. There is no need for overly fine-grained precision in the requested rate. Similarly, while it would be attractive for the encoding function to be easily computable, it is also possible for end-nodes and routers to simply store the table giving the mapping between the value N in the Rate Request field, and the actual rate request f(N). In this section, we consider possible encoding methods for Rate Request fields of different sizes, including four-bit, eight-bit, and larger Rate Request fields.
このセクションでは、クイックスタート要求におけるレート要求フィールドの代替エンコーディング機能を見てください。この機能のための主な要件は、それが要求された率のために十分に広い範囲を持っていなければならないということです。要求されたレートでの過度きめの細かい精度の必要はありません。符号化機能を容易に計算されることが魅力的であろうが、エンドノード及びルータは、単に値Nレート要求フィールドに、実際のレート要求Fとの間のマッピングを与えるテーブルを格納するために同様に、ことも可能です（N）。このセクションでは、4ビット、8ビット、およびより大きなレート要求フィールドを含む、異なるサイズのレート要求フィールドのための可能な符号化方法を検討します。
Linear functions: One possible proposal would be for the Rate Request field to be formatted in bits per second, scaled so that one unit equals M Kbps, for some fixed value of M. Thus, for the value N in the Rate Request field, the requested rate would be M*N Kbps.
線形関数：一つの可能な提案は、レート要求フィールドの値nに対して、M.いくつかの固定値用したがって、一の単位はM Kbpsのに等しくなるようにスケーリングされ、ビット毎秒でフォーマットされるレート要求フィールドのためになります要求されたレートは、M×N個のKbpsのだろう。
Powers of two: If a granularity of factors of two is sufficient for the Rate Request, then the encoding function with the most range would be for the requested rate to be K*2^N; for N, the value in the Rate Request field; and for K, some constant. For N=0, the rate request would be set to zero, regardless of the encoding function. For example, for K=40,000 and an eight-bit Rate Request field, the request range would be from 80 Kbps to 40*2^255 Kbps. This clearly would be an unnecessarily large request range.
2の累乗の2つの要因の粒度は、レート要求に対して十分である場合、最も範囲の符号化関数は、K * 2 ^ Nが要求レートのためであろう。 Nのため、レート要求フィールドの値。そしてK、いくつかの定数について。 N = 0のため、レート要求に関係なく符号化関数のゼロに設定されることになります。例えば、K = 40,000及び8ビットレート要求フィールドに、要求範囲は、80 Kbpsの40 * 2 ^ 255 kbpsになるであろう。これは明らかに不必要に大きな要求範囲になります。
For a four-bit Rate Request field, the upper limit on the rate request is 1.3 Gbps. It seems to us that an upper limit of 1.3 Gbps would be fine for the Quick-Start rate request, and that connections wishing to start up with a higher initial sending rate should be encouraged to use other mechanisms, such as the explicit reservation of bandwidth. If an upper limit of 1.3 Gbps was not acceptable, then five or six bits could be used for the Rate Request field.
4ビットレート要求フィールドに、レート要求の上限は1.3 Gbpsです。このような帯域幅の明示的な予約として、1.3 Gbpsの上限は、クイックスタートレート要求のための罰金、およびより高い初期送信レートで起動したいの接続が他のメカニズムを使用することを奨励されるべきであるということだろうと私たちに思わ。 1.3 Gbpsの上限が許容されなかった場合、5つのまたは6ビットは、レート要求フィールドを使用することができます。
The lower limit of 80 Kbps could be useful for flows with round-trip times of a second or more. For a flow with a round-trip time of one second, as is typical in some wireless networks, the TCP initial window of 4380 bytes allowed by [RFC3390] (given appropriate packet sizes) would translate to an initial sending rate of 35 Kbps. Thus, for TCP flows, a rate request of 80 Kbps could be useful for some flows with large round-trip times.
80 Kbpsでの下限値は秒以上の往復時間と流れのために有用であり得ます。いくつかの無線ネットワークにおいて典型的であるように、1秒の往復時間と流れについては、[RFC3390]（適切なパケットサイズを与えられる）によって許可される4380バイトのTCP初期ウィンドウは、35 Kbpsでの初期送信レートに変換することになります。このように、TCPフローのために、80 Kbpsのレート要求が大きな往復時間を持つ一部のフローに有用であり得ます。
The lower limit of 80 Kbps could also be useful for some non-TCP flows that send small packets, with at most one small packet every 10 ms. A rate request of 80 Kbps would translate to a rate of a hundred 100-byte packets per second (including packet headers). While some small-packet flows with large round-trip times might find a smaller rate request of 40 Kbps to be useful, our assumption is that a lower limit of 80 Kbps on the rate request will be generally sufficient. Again, if the lower limit of 80 kbps was not acceptable, then extra bits could be used for the Rate Request field.
80 Kbpsでの下限も、せいぜい一つの小さなパケットごとに10ミリ秒で、小さなパケットを送信するいくつかの非TCPフローのために有用である可能性があります。 80 Kbpsでのレート要求は、（パケットヘッダを含む）毎秒百100バイトのパケットのレートに変換することになります。いくつかの小さなパケットが大きい往復時間と流れて40 Kbpsでの小さなレート要求が有用であることを見つけるかもしれませんが、私たちの仮定は、レートリクエストに応じて80 Kbpsでの下限は、一般的に十分であろうということです。 80 kbpsの下限が許容可能でなかった場合、再度、余分なビットは、レート要求フィールドを使用することができます。
If the granularity of factors of two was too coarse, then the encoding function could use a base less than two. An alternate form for the encoding function would be to use a hybrid of linear and exponential functions.
両者の要因の粒度が粗すぎるれた場合、符号化関数は2つ未満の塩基を使用することができます。符号化機能の代替形態は、線形および指数関数のハイブリッドを使用することであろう。
A mantissa and exponent representation: Section 4.4 of [B05] suggests a mantissa and exponent representation for the Quick-Start encoding function. With e and f as the binary numbers in the exponent and mantissa fields, and with 0 <= f < 1, this would represent the rate (1+f)*2^e. [B05] suggests a mantissa field for f of 8, 16, or 24 bits, with an exponent field for e of 8 bits. This representation would allow larger rate requests, with an encoding that is less coarse than the powers-of-two encoding used in this document.
仮数と指数表現：[B05]のセクション4.4クイックスタートコード関数の仮数と指数表現を示唆しています。指数および仮数フィールドにバイナリ数としてEおよびFと、0 <= F <1で、これは速度（1 + F）* 2 ^ Eを表すことになります。 [B05]は8ビットのEの指数フィールドと、Fの8、16、または24ビットのための仮数部を示唆しています。この表現は、本書で使用される電力-の二エンコーディング未満粗い符号化と、より大きなレート要求を、可能にするであろう。
Constraints of the transport protocol: We note that the Rate Request is also constrained by the abilities of the transport protocol. For example, for TCP with Window Scaling, the maximum window is at most 2**30 bytes. For a TCP connection with a long, 1 second round-trip time, this would give a maximum sending rate of 1.07 Gbps.
トランスポートプロトコルの制約：私たちは、レート要求は、トランスポートプロトコルの能力によって制約されることに注意してください。たとえば、ウィンドウ・スケーリングTCPのために、最大ウィンドウは、最大2 ** 30バイトです。長い、1秒ラウンドトリップ時間とのTCP接続の場合、これは、1.07 Gbpsの最大送信レートを与えるだろう。
B.3. The Quick-Start Request: Packets or Bytes?
B.3。クイックスタート要求：パケットまたはバイト？
One of the design questions is whether the Rate Request field should be in bytes per second or in packets per second. We discuss this separately from the perspective of the transport, and from the perspective of the router.
設計問題の一つは、レート要求フィールドは秒あたりのバイト数または秒あたりのパケットであるべきかどうかです。私たちは、輸送の観点から、ルータの観点とは別に、これを議論します。
For TCP, the results from the Quick-Start Request are translated into a congestion window in bytes, using the measured round-trip time and the MSS. This window applies only to the bytes of data payload, and does not include the bytes in the TCP or IP packet headers. Other transport protocols would conceivably use the Quick-Start Request directly in packets per second, or could translate the Quick-Start Request to a congestion window in packets.
TCPの場合は、クイック・スタート・リクエストの結果は、測定されたラウンドトリップ時間とMSSを使用して、バイト単位の輻輳ウィンドウに変換されます。このウィンドウにはデータペイロードのバイトに適用され、TCPやIPパケットのヘッダ内のバイトが含まれていません。他のトランスポートプロトコルが考えられる秒あたりのパケットに直接クイックスタート要求を使用し、またはパケットの輻輳ウィンドウへのクイック・スタート・リクエストを変換できます。
The assumption of this document is that the router only approves the Quick-Start Request when the output link is significantly underutilized. For this, the router could measure the available bandwidth in bytes per second, or could convert between packets and bytes by some mechanism.
このドキュメントの仮定は、ルータは出力のみリンクが大幅に十分に活用されていないクイックスタートリクエストを承認するということです。このために、ルータは、秒あたりのバイト数で利用可能な帯域幅を測定することができ、または何らかのメカニズムによってパケットとバイトの間で変換できます。
If the Quick-Start Request was in bytes per second, and applied only to the data payload, then the router would have to convert from bytes per second of data payload, to bytes per second of packets on the wire. If the Rate Request field was in bytes per second, and the sender ended up using very small packets, this could translate to a significantly larger number in terms of bytes per second on the wire. Therefore, for a Quick-Start Request in bytes per second, it makes most sense for this to include the transport and IP headers as well as the data payload. Of course, this will be, at best, a rough approximation on the part of the sender; the transport-level sender might not know the size of the transport and IP headers in bytes, and might know nothing at all about the separate headers added in IP tunnels downstream. This rough estimate seems sufficient, however, given the overall lack of fine precision in Quick-Start functionality.
クイックスタート要求が秒あたりのバイト数にあった、とデータペイロードにのみ適用された場合、ルータは、ワイヤ上のパケットの秒あたりのバイト数に、データペイロードの秒あたりのバイト数から変換する必要があります。レート要求フィールドは秒あたりのバイト数で、送信者が非常に小さいパケットを使用して終了した場合、これは、ワイヤ上秒あたりのバイト数の面でかなり大きな数に変換することができます。したがって、秒あたりのバイト数でのクイックスタートの要求のために、それは、トランスポートとIPヘッダとデータペイロードを含めるには、このための最も理にかなっています。もちろん、これは、最高の状態で、送信者の一部に大まかな近似になります。トランスポートレベルの送信者は、バイト単位での輸送およびIPヘッダのサイズを知らないかもしれない、と下流のIPトンネルに追加別のヘッダーについて全く何も知らないかもしれません。この概算は、クイックスタート機能で細かい精度の全体的な不足与えられた、しかし、十分なようです。
It has been suggested that the router could possibly use information from the MSS option in the TCP packet header of the SYN packet to convert the Quick-Start Request from packets per second to bytes per second, or vice versa. This would be problematic for several reasons. First, if IPsec is used, the TCP header will be encrypted. Second, the MSS option is defined as the maximum MSS that the TCP sender expects to receive, not the maximum MSS that the TCP sender plans to send [RFC793]. However, it is probably often the case that this MSS also applies as an upper bound on the MSS used by the TCP sender in sending.
ルータはおそらくクイックスタート秒あたりのバイト数1秒あたりのパケットからの要求、またはその逆に変換するためにSYNパケットのTCPパケットヘッダにMSSオプションからの情報を使用することが示唆されています。これは、いくつかの理由で問題となります。 IPsecを使用する場合はまず、TCPヘッダは暗号化されます。第二に、MSSオプションはTCPの送信側が受信することを期待することを最大のMSSとして定義されている、いない最大のMSSは、TCPの送信者は[RFC793]に送信することを計画していること。しかし、それはこのMSSはまた、送信時にTCPの送信者によって使用されるMSSの上限として適用されている場合は、おそらく多くの場合です。
We note that the sender does not necessarily know the Path MTU when the Quick-Start Request is sent, or when the initial window of data is sent. Thus, with IPv4, packets from the initial window could end up being fragmented in the network if the "Don't Fragment" (DF) bit is not set [RFC1191]. A Rate Request in bytes per second is reasonably robust to fragmentation. Clearly, a Rate Request in packets per second is less robust in the presence of fragmentation. Interactions between larger initial windows and Path MTU Discovery are discussed in more detail in RFC 3390 [RFC3390].
私たちは、クイック・スタート・リクエストが送信されたとき、またはデータの初期ウィンドウが送信されたとき、送信者は、必ずしもパスMTUを知らないことに注意してください。したがって、IPv4では、初期画面からのパケットは、「フラグメントない」（DF）ビットが[RFC1191]を設定されていない場合、ネットワーク内の断片化されてしまう可能性があります。バイト毎秒レート要求は、断片化に合理的に堅牢です。明らかに、秒あたりのパケットにおけるレート要求は、断片化の存在下であまり堅牢です。大きい初期ウィンドウとパスMTU探索の間の相互作用は、RFC 3390 [RFC3390]でより詳細に議論されます。
For a Quick-Start Request in bytes per second, the transport senders would have the additional complication of estimating the bandwidth usage added by the packet headers.
秒あたりのバイト数でのクイックスタートの要求のため、輸送の送信者は、パケットヘッダによって追加の帯域幅使用量を推定する追加の合併症を持っているでしょう。
We have chosen a Rate Request field in bytes per second rather than in packets per second because it seems somewhat more robust, particularly to routers.
それは特にルータに、ややより堅牢なようですので、私たちは毎秒ではなく、秒あたりのパケット内のバイトでレート要求フィールドを選択しました。
B.4. Quick-Start Semantics: Total Rate or Additional Rate?
B.4。クイックスタート意味：総レートまたは追加のレート？
For a Quick-Start Request sent in the middle of a connection, there are two possible semantics for the Rate Request field, as follows:
以下のような接続の途中で送信されたクイックスタートの要求のため、レート要求フィールドのための2つの可能なセマンティクスは、あります。
(1) Total Rate: The requested Rate Request is the requested total rate for the connection, including the current rate; or
（1）総レート：要求されたレート要求は現在のレートを含む接続のために要求された合計レートです。または
(2) Additional Rate: The requested Rate Request is the requested increase in the total rate for that connection, over and above the current sending rate.
（2）追加レート：要求されたレート要求を超えると、現在の送信レートの上に、その接続の合計率が要求された増加です。
When the Quick-Start Request is sent after an idle period, the current sending rate is zero, and there is no difference between (1) and (2) above. However, a Quick-Start Request can also be sent in the middle of a connection that has not been idle, e.g., after a mobility event, or after an application-limited period when the sender is suddenly ready to send at a much higher rate. In this case, there can be a significant difference between (1) and (2) above. In this section, we consider briefly the tradeoffs between these two options, and explain why we have chosen the `Total Rate' semantics.
クイック開始要求がアイドル期間の後に送信されると、現在の送信速度がゼロであり、（1）及び（2）上記の違いはありません。しかし、クイックスタート要求は、モビリティイベントの後、または送信者が突然、はるかに高いレートで送信する準備ができているアプリケーションが制限された期間の後、例えば、アイドル状態になっていない接続の真ん中にもを送信することができます。この場合には、有意差が存在することができる（1）及び（2）。このセクションでは、これらの2つのオプションの簡単にトレードオフを考慮し、我々は `合計レート」のセマンティクスを選択した理由を説明します。
The Total Rate semantics makes it easier for routers to "allocate" the same rate to all connections. This lends itself to fairness, and improves convergence times between old and new connections. With the Additional Rate semantics, the router would not necessarily know the current sending rates of the flows requesting additional rates, and therefore would not have sufficient information to use fairness as a metric in granting rate requests. With the Total Rate semantics, the fairness is automatic; the router is not granting rate requests for *additional* bandwidth without knowing the current sending rates of the different flows.
合計料金のセマンティクスは、それが簡単にルータがすべての接続に同じレートを「割り当てる」できるようになります。これは、公平性に適していて、古いものと新しい接続との間のコンバージェンス時間を向上させます。追加料金のセマンティクスを使用すると、ルータは必ずしもレート要求を許可におけるメトリックとして公平性を使用するのに十分な情報を持っていないので、追加料金を要求フローの現在の送信レートを知っているではないでしょう。合計料金のセマンティクスでは、公平性が自動的に行われます。ルータは、異なるフローの現在の送信レートを知らなくても*追加*帯域幅のレート要求を許可されていません。
The Additional Rate semantics also lends itself to gaming by the connection, with senders sending frequent Quick-Start Requests in the hope of gaining a higher rate. If the router is granting the same maximum rate for all rate requests, then there is little benefit to a connection of sending a rate request over and over again. However, if the router is granting an *additional* rate with each rate request, over and above the current sending rate, then it is in a connection's interest to send as many rate requests as possible, even if very few of them are, in fact, granted.
追加料金のセマンティクスも高いレートを得るの希望で頻繁にクイックスタート要求を送信する送信者と、接続によってゲームに適しています。ルータは、すべてのレート要求に同じ最大速度を付与されている場合は、何度も繰り返しレート要求を送信する接続にはほとんど利点があります。ルータは各レート要求を持つ*追加*率を付与された場合は、以上の現在の送信レートの上に、それはそれらの非常に少数がに、ある場合でも、できるだけ多くのレート要求を送信するために、接続の利益になります事実、付与されました。
Appendix E discusses a Report of Current Sending Rate as one possible function in the Quick-Start Option. However, we have not standardized this possible use at this time.
付録Eは、クイックスタートオプションの1つの可能な関数としてレートを送信する現在の報告書について説明します。しかし、現時点では、この使用の可能性を標準化していません。
B.5. Alternate Responses to the Loss of a Quick-Start Packet
B.5。クイックスタートパケットの損失に代替応答
Section 4.6 discusses TCP's response to the loss of a Quick-Start packet in the initial window. This section discusses several alternate responses.
4.6節は、初期ウィンドウのQuick-Startパケットの損失に対するTCPの応答について説明します。このセクションでは、いくつかの代替応答について説明します。
One possible alternative to reverting to the default Slow-Start after the loss of a Quick-Start packet from the initial window would have been to halve the congestion window and continue in congestion avoidance. However, we note that this would not have been a desirable response for either the connection or for the network as a whole. The packet loss in the initial window indicates that Quick-Start failed in finding an appropriate congestion window, meaning that the congestion window after halving may easily also be wrong.
初期画面からクイックスタートパケットの損失の後にデフォルトのスロースタートに戻すに対する1つの可能な選択肢は、輻輳ウィンドウを半減し、輻輳回避に継続することであっただろう。しかし、私たちは、これはどちらかの接続またはネットワーク全体にとって望ましい応答なかったであろうことに注意してください。最初のウィンドウでのパケット損失はクイックスタートが半減後の輻輳ウィンドウを簡単にも間違っているかもしれつまり、適切な輻輳ウィンドウを見つけることに失敗したことを示します。
A more moderate alternate would be to continue in congestion avoidance from a window of (W-D)/2, where W is the Quick-Start congestion window, and D is the number of packets dropped or marked from that window. However, such an approach would implicitly assume that the number of Quick-Start packets delivered is a good indication of the appropriate available bandwidth for that flow, even though other packets from that window were dropped in the network. And, further, that using half the number of segments that were successfully transmitted is conservative enough to account for the possibly inaccurate congestion window indication. We believe that such an assumption would require more analysis at this point, particularly in a network with a range of packet dropping mechanisms at the router, and we cannot recommend it at this time.
Wは、クイックスタート輻輳ウィンドウであり、そしてDは、パケットの数が廃棄又はそのウィンドウからマークされている場合、より穏やかな代替は、（W-D）/ 2、の窓から輻輳回避に継続するであろう。しかし、このようなアプローチは、暗黙的に配信クイックスタートパケットの数は、そのウィンドウから他のパケットがネットワークで落とされたとしても、その流れのための適切な利用可能な帯域幅の良い指標であることを前提としています。そして、さらに、正常に送信されたセグメントの数の半分を使用していることは、おそらく不正確な輻輳ウィンドウの表示を説明するには十分保守的です。私たちは、そのような仮定は、特にルータのメカニズムを落とすパケットの範囲とネットワークで、この時点でより多くの分析が必要であろうと信じて、私たちは、この時点でそれをお勧めすることはできません。
Another drawback of approaches that don't revert back to slow-start when a Quick-Start packet in the initial window is dropped is that such approaches could give the TCP receiver a greater incentive to lie about the Quick-Start Request. If the sender reverts to slow-start when a Quick-Start packet in the initial window is dropped, this diminishes the benefit a receiver would get from a Quick-Start request that resulted in a dropped or ECN-marked packet.
最初のウィンドウで、クイックスタートパケットがドロップされたときにスタートを遅らせるために戻って戻らないアプローチの別の欠点は、このようなアプローチは、TCP受信機にクイックスタート要求について嘘をつくより大きなインセンティブを与えることができるということです。送信者は、最初のウィンドウ内のクイックスタートパケットがドロップされたときにスロースタートに戻り場合、これは受信機が落下やECN-マークされたパケットが生じたクイックスタート要求からになるだろう利益を減少させます。
B.6. Why Not Include More Functionality?
B.6。なぜ、もっと機能が含まれていませんか？
This proposal for Quick-Start is a rather coarse-grained mechanism that would allow a connection to use a higher sending rate along underutilized paths, but that does not attempt to provide a next-generation transport protocol or congestion control mechanism, and does not attempt the goal of providing very high throughput with very low delay. Appendix A.4 discusses a number of proposals (such as XCP, MaxNet, and AntiECN) that provide more fine-grained per-packet feedback from routers than the current congestion control mechanisms and that attempt these more ambitious goals.
クイックスタートのためのこの提案は、接続が活用されていない経路に沿ってより高い送信速度を使用することができるようになるかなり粗い機構であり、それは次世代のトランスポートプロトコル又は輻輳制御メカニズムを提供しようとしない、と試みません非常に低遅延で非常に高いスループットを提供することを目標。付録A.4は、現在の輻輳制御機構よりもルータからよりきめ細かいパケットごとのフィードバックを提供する（例えば、XCP、MAXNET、及びAntiECNなど）提案の数について説明し、それは、これらのより野心的な目標を試みます。
Compared to proposals such as XCP and AntiECN, Quick-Start offers much less control. Quick-Start does not attempt to provide a new congestion control mechanism, but simply to get permission from routers for a higher sending rate at start-up, or after an idle period. Quick-Start can be thought of as an "anti-congestion-control" mechanism that is only of any use when all the routers along the path are significantly underutilized. Thus, Quick-Start is of no use towards a target of high link utilization, or fairness in a high-utilization scenario, or controlling queueing delay during high utilization, or anything of the like.
このようXCPやAntiECNなどの提案と比較すると、クイックスタートはあまりコントロールを提供しています。クイックスタートは、新たな輻輳制御メカニズムを提供しようとしませんが、単に起動時、またはアイドル期間の後に、より高い送信レートのためのルータからの許可を取得します。クイックスタートは、パス上のすべてのルータが大幅に十分に活用されている場合のみ、任意の使用である「抗輻輳制御」メカニズムとして考えることができます。このように、クイックスタートではありません高いリンク利用率の目標に向けた使用、または高使用率のシナリオでは、公平性のある、または使用率が高い、などの何時にキューイング遅延を制御します。
At the same time, Quick-Start would allow larger initial windows than would proposals such as AntiECN, requires less input to routers than XCP (e.g., XCP's cwnd and RTT fields), and would require less frequent feedback from routers than any new congestion control mechanism. Thus, Quick-Start is significantly less powerful than proposals for new congestion control mechanisms, such as XCP and AntiECN, but as powerful or more powerful in terms of the specific issue of allowing larger initial windows. Also, (we think) it is more amenable to incremental deployment in the current Internet.
同時に、クイックスタートは、AntiECNなど希望の提案よりも大きな初期ウィンドウを可能にする、XCPよりルータに少ない入力（例えば、XCPのCWNDとRTTフィールド）を必要とし、新たな輻輳制御よりもルータからあまり頻繁なフィードバックを必要とします機構。このように、クイックスタートは、より大きな初期ウィンドウを可能にする特定の問題の観点から、このようなXCPやAntiECNなどの新しい輻輳制御メカニズムのための提案よりも大幅に少ない強力ではなく、などの強力なまたはより強力です。また、（私たちは思う）、それは現在のインターネットでの増分の展開に、より適しています。
We do not discuss proposals such as XCP in detail, but simply note that there are a number of open questions. One question concerns whether there is a pressing need for more sophisticated congestion control mechanisms, such as XCP, in the Internet. Quick-Start is inherently a rather crude tool that does not deliver assurances about maintaining high link utilization and low queueing delay; Quick-Start is designed for use in environments that are significantly underutilized, and addresses the single question of whether a higher sending rate is allowed. New congestion control mechanisms with more fine-grained feedback from routers could allow faster start-ups even in environments with rather high link utilization. Is this a pressing requirement? Are the other benefits of more fine-grained congestion control feedback from routers a pressing requirement?
私たちは、このような詳細にXCPとしての提案を議論し、単にオープン質問の数があることに注意しません。インターネットでこのようなXCPのようなより洗練された輻輳制御メカニズムのための差し迫った必要性があるかどうかを一つの質問の懸念。クイックスタートは、本質的に高いリンク利用率と低いキューイング遅延を維持することについての保証を配信しません、むしろ、粗ツールです。クイックスタートが大幅に十分に活用されている環境での使用のために設計されており、高い送信レートが許可されているかどうかの単一の質問に対処しています。ルータから、よりきめの細かいフィードバックを持つ新しい輻輳制御メカニズムは、より高速でもかなり高いリンク利用率を持つ環境でのアップを開始する可能性があります。これは押すな要件ですか？ルータから、よりきめの細かい輻輳制御フィードバックの他の利点は、緊急の要件はありますか？
We would argue that even if more fine-grained per-packet feedback from routers was implemented, it is reasonable to have a separate mechanism, such as Quick-Start, for indicating an allowed initial sending rate, or an allowed total sending rate after an idle or underutilized period.
私たちは、許可された初期送信レート、または後に許可され、総送信レートを示すために、ルータから、よりきめ細かいパケットごとのフィードバックが実施された場合でも、そのようなクイックスタートとして、別のメカニズムを有することが合理的であると主張しますアイドルまたは十分に利用されていない期間。
One difference between Quick-Start and current proposals for fine-grained per-packet feedback, such as XCP, is that XCP is designed to give robust performance even in the case where different packets within a connection routinely follow different paths. XCP achieves relatively robust performance in the presence of multipath routing by using per-packet feedback, where the feedback carried in a single packet is about the relative increase or decrease in the rate or window to take effect when that particular packet is acknowledged, not about the allowed sending rate for the connection as a whole.
例えばXCPとしてきめ細かいパケットごとのフィードバックのためのクイックスタートと現在の提案との間の一つの違いは、XCPをも接続内の異なるパケットが日常的に異なる経路をたどる場合にロバストな性能を与えるように設計されていることです。単一のパケットで運ばれるフィードバックは約、その特定のパケットが確認されたときに有効にするレートまたはウィンドウの相対的な増加または減少についてない場合XCPは、パケットごとのフィードバックを使用して、マルチパスルーティングの存在下で比較的堅牢な性能を達成します全体として接続するための許可送信レート。
In contrast, Quick-Start sends a single Quick-Start Request, and the answer to that request gives the allowed sending rate for an entire window of data. As a result, Quick-Start could be problematic in an environment where some fraction of the packets in a window of data take path A, and the rest of the packets take path B; for example, the Quick-Start Request could have traveled on path A, while half the Quick-Start packets sent in the succeeding round-trip time are routed on path B. We note that [ZDPS01] shows Internet paths to be stable on the order of RTTs.
これとは対照的に、クイックスタートは、単一のクイックスタート要求を送信し、その要求に対する答えは、データのウィンドウ全体に許可された送信レートを提供します。結果として、クイックスタートは、データのウィンドウ内のパケットのいくつかの画分がパスAを取る環境において問題となる可能性があり、パケットの残りの部分は、パスBを取ります。後続のラウンドトリップ時間に送ら半分クイックスタートパケットがパスBにルーティングされながら、例えば、クイックスタート要求は我々が[ZDPS01]インターネットパスは上の安定であることを示していることに注意してください、パスAに旅している可能性がRTTの順。
There are also differences between Quick-Start and some of the proposals for per-packet feedback in terms of the number of bits of feedback required from the routers to the end-nodes. Quick-Start uses four bits of feedback in the rate request field to indicate the allowed sending rate. XCP allocates a byte for per-packet feedback, though there has been discussion of variants of XCP with less per-packet feedback. This would be more like other proposals, such as anti-ECN, that use a single bit of feedback from routers to indicate that the sender can increase as fast as slow-starting, in response to this particular packet acknowledgement. In general, there is probably considerable power in fine-grained proposals with only two bits of feedback, indicating that the sender should decrease, maintain, or increase the sending rate or window when this packet is acknowledged. However, the power of Quick-Start would be considerably limited if it was restricted to only two bits of feedback; it seems likely that determining the initial sending rate fundamentally requires more bits of feedback from routers than does the steady-state, per-packet feedback to increase or decrease the sending rate.
クイックスタートとエンドノードへのルータから必要なフィードバックのビット数の点では、パケットごとのフィードバックのための提案の一部との違いもあります。クイックスタートが許可され、送信レートを示すために、レート要求フィールドにフィードバックの4ビットを使用しています。少ないパケットごとのフィードバックを持つXCPの変異体の議論があったもののXCPは、パケットごとのフィードバックのためにバイトを割り当てます。これは、より多くの送信者は、この特定のパケットの確認応答に応じて、早くとしてスロースタートを増大させることができることを示すために、ルータからのフィードバックの単一ビットを使用して、このような抗ECNなどの他の提案、のようになります。一般的には、送信者は、減少維持する、またはこのパケットが確認されたときに送信レートまたはウィンドウを増やす必要があることを示す、おそらくフィードバックの2ビットだけできめ細かな提案にはかなりの力があります。それはフィードバックの2つだけビットに制限されていた場合は、クイックスタートのパワーが大幅に制限されます。最初の送信レートを決定することは基本的に、送信速度を増加または減少させる定常状態、パケットごとのフィードバックを行うよりも、ルータからのフィードバックの多くのビットを必要とする可能性が高いようです。
On a more practical level, one difference between Quick-Start and proposals for per-packet feedback is that there are fewer open issues with Quick-Start than there would be with a new congestion control mechanism. Because Quick-Start is a mechanism for requesting an initial sending rate in an underutilized environment, its fairness issues are less severe than those of a general congestion control mechanism. With Quick-Start, there is no need for the end nodes to tell the routers the round-trip time and congestion window, as is done in XCP; all that is needed is for the end nodes to report the requested sending rate.
より実用的なレベルでは、パケットごとのフィードバックのためのクイックスタート・提案の違いの1つは、新たな輻輳制御機構が存在することになるよりも、クイックスタートと少ない未解決の問題があるということです。クイックスタートが活用されていない環境で、初期送信レートを要求するための仕組みであるため、その公正性の問題は、一般的な輻輳制御機構のものよりも深刻です。クイックスタートでは、XCPに行われているように、エンド・ノードは、ルータに往復時間と輻輳ウィンドウを指示するために必要はありません。エンド・ノードは、要求された送信レートを報告するために必要なすべてのことです。
Table 3 provides a summary of the differences between Quick-Start and proposals for per-packet congestion control feedback.
表3は、クイックスタートおよびパケットごとの輻輳制御フィードバックの提案との違いをまとめたもの。
Proposals for
Quick-Start Per-Packet Feedback
+------------------+----------------------+----------------------+
Semantics: | Allowed sending rate | Change in rate/window,
| per connection. | per-packet.
+------------------+----------------------+----------------------+
Relationship to | In addition. | Replacement.
congestion ctrl: | |
+------------------+----------------------+----------------------+
Frequency: | Start-up, or after | Every packet.
| an idle period. |
+------------------+----------------------+----------------------+
Limitations: | Only useful on | General congestion
| underutilized paths.| control mechanism.
+------------------+----------------------+----------------------+
Input to routers: | Rate request. |RTT, cwnd, request (XCP)
| | None (Anti-ECN).
+------------------+----------------------+----------------------+
Bits of feedback: | Four bits for | A few bits would
| rate request. | suffice?
+------------------+----------------------+----------------------+
Table 3: Differences between Quick-Start and Proposals for
Fine-Grained Per-Packet Feedback.
A separate question concerns whether mechanisms, such as Quick-Start, in combination with HighSpeed TCP and other changes in progress, would make a significant contribution towards meeting some of these needs for new congestion control mechanisms. This could be viewed as a positive step towards meeting some of the more pressing current needs with a simple and reasonably deployable mechanism, or alternately, as a negative step of unnecessarily delaying more fundamental changes. Without answering this question, we would note that our own approach tends to favor the incremental deployment of relatively simple mechanisms, as long as the simple mechanisms are not short-term hacks, but mechanisms that lead the overall architecture in the fundamentally correct direction.
別の質問の懸念は、このようなクイックスタートなどのメカニズム、かどうか、高速TCPおよび進行中の他の変更と組み合わせて、新たな輻輳制御メカニズムのためのこれらのニーズの一部を満たすことに向けて大きく貢献するでしょう。これは、不必要に、より根本的な変化を遅延させる負のステップとして、交互に簡単かつ合理的に展開可能な機構を備えた複数の押圧現在のニーズの一部を満たす、または向かって正のステップとして見ることができます。この質問に答えるなければ、私たちは、単純なメカニズムは基本的に正しい方向に全体的なアーキテクチャを導くメカニズムは短期的なハックではなく、限り、私たち自身のアプローチは比較的単純なメカニズムの増分展開を好む傾向があることに注意します。
B.7. Alternate Implementations for a Quick-Start Nonce
B.7。クイックスタートナンスのための代替実装
B.7.1. An Alternate Proposal for the Quick-Start Nonce
B.7.1。クイックスタートナンスのための代替案
An alternate proposal for the Quick-Start Nonce from [B05] would be for an n-bit field for the QS Nonce, with the sender generating a random nonce when it generates a Quick-Start Request. Each router that reduces the Rate Request by r would hash the QS nonce r times, using a one-way hash function such as MD5 [RFC1321] or the secure hash 1 [SHA1]. The receiver returns the QS nonce to the sender. Because the sender knows the original value for the nonce, and the original rate request, the sender knows the total number of steps s that the rate has been reduced. The sender then hashes the original nonce s times to check whether the result is the same as the nonce returned by the receiver.
[B05]からクイックスタートノンスの代替案は、クイックスタート要求を生成するとき、送信者は、ランダムなノンスを生成して、QSノンスためのnビットのフィールドであろう。 rでレート要求を低減する各ルータは、MD5 [RFC1321]またはセキュアハッシュ1 [SHA1]として一方向ハッシュ関数を使用して、QSのノンスr回ハッシュだろう。受信側は送信側にQS nonceを返します。送信者が一回だけの元の値、および元のレート要求を知っているので、送信者は、速度が低減されたことをステップの総数を知っています。送信者は、結果は受信側によって返さノンスと同一であるかどうかを確認するために、元のノンスS回ハッシュ。
This alternate proposal for the nonce would be considerably more powerful than the QS nonce described in Section 3.4, but it would also require more CPU cycles from the routers when they reduce a Quick-Start Request, and from the sender in verifying the nonce returned by the receiver. As reported in [B05], routers could protect themselves from processor exhaustion attacks by limiting the rate at which they will approve reductions of Quick-Start Requests.
ナンスのためのこの代替案は、3.4節で説明したQSナンスよりもかなり強力になりますが、彼らはクイックスタート要求を削減する場合、それはまた、ルータからのより多くのCPUサイクルを必要とする、送信者からで返さnonceを検証中受信機。 [B05]で報告されているように、ルータは、彼らがクイックスタート要求の削減を承認する速度を制限することにより、プロセッサの枯渇攻撃から身を守ることができます。
Both the Function field and the Reserved field in the Quick-Start Option would allow the extension of Quick-Start to use Quick-Start requests with the alternate proposal for the Quick-Start Nonce, if it was ever desired.
機能分野と予約フィールドの両方のクイック・スタート・オプションは、クイックスタートの延長はクイックスタートを使用することができるようになるには、それが今までに希望された場合は、クイックスタートナンスのための代替案を要求します。
B.7.2. The Earlier Request-Approved Quick-Start Nonce
B.7.2。以前のRequest-承認クイックスタートナンス
An earlier version of this document included a Request-Approved Quick-Start Nonce (QS Nonce) that was initialized by the sender to a non-zero, `random' eight-bit number, along with a QS TTL that was initialized to the same value as the TTL in the IP header. The Request-Approved Quick-Start Nonce would have been returned by the transport receiver to the transport sender in the Quick-Start Response. A router could deny the Quick-Start Request by failing to decrement the QS TTL field, by zeroing the QS Nonce field, or by deleting the Quick-Start Request from the packet header. The QS Nonce was included to provide some protection against broken downstream routers, or against misbehaving TCP receivers that might be inclined to lie about whether the Rate Request was approved. This protection is now provided by the QS Nonce, by the use of a random initial value for the QS TTL field, and by Quick-Start-capable routers hopefully either deleting the Quick-Start Option or zeroing the QS TTL and QS Nonce fields when they deny a request.
このドキュメントの以前のバージョンは含まリクエスト・承認・クイックスタート同じに初期化されたQS TTLと一緒に、非ゼロ、 `ランダム」8ビット番号に送信者によって初期化されたナンス（QSナンス） IPヘッダ内のTTL値として。リクエスト・承認クイックスタートナンスは、クイックスタートレスポンスにトランスポート送信者に転送受信側によって返されたであろう。ルータは、QS TTLフィールドをデクリメントすることができないことにより、QSノンスフィールドをゼロにすることによって、またはパケットヘッダからクイックスタート要求を削除することにより、クイックスタート要求を拒否することができました。 QSナンスが壊れてダウンストリームルータに対して、あるいはレート要求が承認されたかどうかを偽るために傾斜するかもしれない誤動作のTCP受信機に対してある程度の保護を提供するために含めました。この保護は今うまくいけば、クイックスタートオプションを削除するのいずれかの場合、またはQS TTLおよびQS NonceのフィールドをゼロにQS TTLフィールドのランダムな初期値を使用することにより、およびクイックスタート対応ルータで、QSナンスによって提供され彼らは要求を拒否します。
With the old Request-Approved Quick-Start Nonce, along with the QS TTL field set to the same value as the TTL field in the IP header, the Quick-Start Request mechanism would have been self-terminating; the Quick-Start Request would terminate at the first participating router after a non-participating router had been encountered on the path. This minimizes unnecessary overhead incurred by routers because of option processing for the Quick-Start Request. In the current specification, this "self-terminating" property is provided by Quick-Start-capable routers hopefully either deleting the Quick-Start Option or zeroing the Rate Request field when they deny a request. Because the current specification uses a random initial value for the QS TTL, Quick-Start-capable routers can't tell if the Quick-Start Request is invalid because of non-Quick-Start-capable routers upstream. This is the cost of using a design that makes it difficult for the receiver to cheat about the value of the QS TTL.
古いリクエスト-承認クイックスタートナンスでは、IPヘッダーのTTLフィールドと同じ値に設定QS TTLフィールドと一緒に、クイック・スタート・リクエスト・メカニズムは、自己終端されているだろう。非参加ルータがパスに遭遇した後クイックスタート要求は、最初の参加ルータで終端します。これは、クイックスタート要求のためのオプション処理のルータによって生じた不要なオーバーヘッドを最小限に抑えます。現在の仕様では、この「自己終端」プロパティがうまくいけば、クイックスタートが可能なルータによって提供されるか、クイックスタートオプションを削除するか、彼らが要求を拒否したときにレート要求フィールドをゼロに。現在の仕様では、QS TTLのためのランダムな初期値を使用しているため、クイックスタートが可能なルータは、クイックスタート要求があるため、上流非クイックスタート対応ルータの無効な場合伝えることはできません。これは、それが困難な受信機はQS TTLの値についてカンニングすることを可能にする設計を使用してのコストです。
Appendix C. Quick-Start with DCCP
付録C. DCCPとクイックスタート
DCCP is a new transport protocol for congestion-controlled, unreliable datagrams, intended for applications such as streaming media, Internet telephony, and online games. In DCCP, the application has a choice of congestion control mechanisms, with the currently-specified Congestion Control Identifiers (CCIDs) being CCID 2 for TCP-like congestion control, and CCID 3 for TCP Friendly Rate Control (TFRC), an equation-based form of congestion control. We refer the reader to [RFC4340] for a more detailed description of DCCP and congestion control mechanisms.
DCCPは、ストリーミングメディア、インターネット電話、およびオンラインゲームなどのアプリケーションを対象とし輻輳制御、信頼性のないデータグラムのための新しいトランスポートプロトコルです。 DCCPでは、アプリケーションは、現在指定された輻輳制御識別子（のCCIDs）がTCPのような輻輳制御のためにCCID 2であると、輻輳制御機構の選択を有し、TCPフレンドリーレート制御（TFRC）、方程式系のためのCCID 3輻輳制御の形式。我々は、DCCP輻輳制御メカニズムのより詳細な説明については、[RFC4340]を読者に参照します。
Because CCID 3 uses a rate-based congestion control mechanism, it raises some new issues about the use of Quick-Start with transport protocols. In this document, we don't attempt to specify the use of Quick-Start with DCCP. However, we do discuss some of the issues that might arise.
CCID 3は、レートベースの輻輳制御メカニズムを使用しているので、それはトランスポートプロトコルとクイックスタートの使用に関するいくつかの新たな問題を提起します。この文書では、我々はDCCPとクイックスタートの使用を指定しないでください。しかし、我々が発生する可能性のある問題のいくつかを説明します。
In considering the use of Quick-Start with CCID 3 for requesting a higher initial sending rate, the following questions arise: (1) How does the sender respond if a Quick-Start packet is dropped?
高い初期送信レートを要求するためのCCID 3とクイックスタートの使用を考慮して、以下の質問が発生：クイックスタートパケットがドロップされた場合は（1）どのように送信者が応答しませんか？
As in TCP, if an initial Quick-Start packet is dropped, the CCID
3 sender should revert to the congestion control mechanisms it
would have used if the Quick-Start Request had not been approved.
(2) When does the sender decide there has been no feedback from the receiver?
（2）する場合、送信側は受信側からのフィードバックがなかったかを決定しますか？
Unlike TCP, CCID 3 does not use acknowledgements for every
packet, or for every other packet. In contrast, the CCID 3
receiver sends feedback to the sender roughly once per round-trip
time. In CCID 3, the allowed sending rate is halved if no
feedback is received from the receiver in at least four round-
trip times (when the sender is sending at least one packet every
two round-trip times). When a Quick-Start Request is used, it
would seem necessary to use a smaller time interval, e.g., to
reduce the sending rate if no feedback arrives from the receiver
in at least two round-trip times.
The question also arises of how the sending rate should be reduced after a period of no feedback from the receiver. As with TCP, the default CCID 3 response of halving the sending rate is not necessarily a sufficient response to the absence of feedback; an alternative is to reduce the sending rate to the sending rate that would have been used if no Quick-Start Request had been approved. That is, if a CCID 3 sender uses a Quick-Start Request, special rules might be required to handle the sender's response to a period of no feedback from the receiver regarding the Quick-Start packets.
質問はまた、送信速度は受信機からのフィードバック無しの期間の後に減少する方法で発生します。 TCPと同様に、送信レートを半分のデフォルトCCID 3応答は、フィードバックの欠如に十分な応答は、必ずしもではありません。代替にはクイックスタート要求が承認されなかった場合に使用されていた送信レートに送信レートを削減することです。 CCID 3送信者がクイックスタート要求を使用している場合つまり、特別なルールがクイックスタートパケットに関する受信機からのフィードバック無しの期間に、送信者の応答を処理する必要がある場合があります。
Similarly, in considering the use of Quick-Start with CCID 3 for requesting a higher sending rate after an idle period, the following questions arise:
同様に、アイドル期間の後に、より高い送信レートを要求するCCID 3とクイックスタートの使用を考慮して、以下の質問が発生します：
(1) What rate does the sender request?
（1）どのような割合は、送信者の要求していますか？
As in TCP, there is a straightforward answer to the rate request
that the CCID 3 sender should use in requesting a higher sending
rate after an idle period. The sender knows the current loss
event rate, either from its own calculations or from feedback
from the receiver, and can determine the sending rate allowed by
that loss event rate. This is the upper bound on the sending
rate that should be requested by the CCID 3 sender. A Quick-
Start Request is useful with CCID 3 when the sender is coming out
of an idle or underutilized period, because in standard
operation, CCID 3 does not allow the sender to send more than
twice as fast as the receiver has reported received in the most
recent feedback message.
(2) What is the response to loss?
（2）損失に対する応答は何ですか？
The response to the loss of Quick-Start packets should be to
return to the sending rate that would have been used if Quick-
Start had not been requested.
(3) When does the sender decide there has been no feedback from the receiver?
（3）場合には、送信者が受信機からのフィードバックがなかったかを決定しますか？
As in the case of the initial sending rate, it would seem prudent
to reduce the sending rate if no feedback is received from the
receiver in at least two round-trip times. It seems likely that,
in this case, the sending rate should be reduced to the sending
rate that would have been used if no Quick-Start Request had been
approved.
Appendix D. Possible Router Algorithm
付録D.可能なルータのアルゴリズム
This specification does not tightly define the algorithm a router uses when deciding whether to approve a Quick-Start Rate Request or whether and how to reduce a Rate Request. A range of algorithms is likely useful in this space and we consider the algorithm a particular router uses to be a local policy decision. In addition, we believe that additional experimentation with router algorithms is necessary to have a solid understanding of the dynamics various algorithms impose. However, we provide one particular algorithm in this appendix as an example and as a framework for thinking about additional mechanisms.
この仕様はしっかりとクイックスタートレート要求かどうか、どのようにレート要求を減らすために承認するかどうかを決定する際に、ルータが使用するアルゴリズムを定義していません。アルゴリズムの範囲は、この空間での可能性に有用であり、我々は特定のルータは、ローカルの政策決定であることを使用するアルゴリズムを検討します。また、当社は、ルータのアルゴリズムでの追加実験は、様々なアルゴリズムが課す力学をしっかりと理解を持っていることが必要であると考えています。しかし、私たちは、一例として、この付録では、追加のメカニズムを考えるための枠組みとして、ある特定のアルゴリズムを提供しています。
[SAF06] provides several algorithms routers can use to consider incoming Rate Requests. The decision process involves two algorithms. First, the router needs to track the link utilization over the recent past. Second, this utilization needs to be updated by the potential new bandwidth from recent Quick-Start approvals, and then compared with the router's notion of when it is underutilized enough to approve Quick-Start Requests (of some size).
[SAF06]ルータは、着信料金の要求を考慮するために使用できるいくつかのアルゴリズムを提供します。決定プロセスは、2つのアルゴリズムを必要とします。まず、ルータは、最近の過去の上にリンク使用率を追跡する必要があります。第二に、この使用率は、最近のクイックスタートの承認から潜在的な新しい帯域幅によって更新され、その後、それは（いくつかのサイズの）クイックスタート要求を承認するのに十分な十分に活用されていないときのルータの概念と比較する必要があります。
First, we define the "peak utilization" estimation technique (from [SAF06]). This mechanism records the utilization of the link every S seconds and stores the most recent N of these measurements. The utilization is then taken as the highest utilization of the N samples. This method, therefore, keeps N*S seconds of history. This algorithm reacts rapidly to increases in the link utilization. In [SAF06], S is set to 0.15 seconds, and experiments use values for N ranging from 3 to 20.
まず、我々は（[SAF06]から）「ピーク使用率」推定技術を定義します。このメカニズムは、すべてのS秒リンクの利用率を記録し、これらの測定値の最も最近のNを格納します。利用は、N個のサンプルの最高の利用としています。この方法は、それゆえ、歴史のN * S秒を保持します。このアルゴリズムは、リンク使用率の増加に迅速に反応します。 【SAF06]において、Sは0.15秒に設定され、実験は3から20までの範囲のNの値を使用することです。
Second, we define the "target" algorithm for processing incoming Quick-Start Rate Requests (also from [SAF06]). The algorithm relies
第二に、我々は（[SAF06]からも）入ってくるクイックスタートレート要求を処理するための「ターゲット」のアルゴリズムを定義します。アルゴリズムは、依存しています
on knowing the bandwidth of the outgoing link (which, in many cases, can be easily configured), the utilization of the outgoing link (from an estimation technique such as given above), and an estimate of the potential bandwidth from recent Quick-Start approvals.
最近クイックスタートから（多くの場合、容易に構成することができる）送信リンクの帯域幅は、（例えば、上記のような推定手法から）発信リンクの利用、および潜在的な帯域幅の推定値を知ることに承認。
Tracking the potential bandwidth from recent Quick-Start approvals is another case where local policy dictates how it should be done. The simplest method, outlined in Section 8.2, is for the router to keep track of the aggregate Quick-Start rate requests approved in the most recent two or more time intervals, including the current time interval, and to use the sum of the aggregate rate requests over these time intervals as the estimate of the approved Rate Requests. The experiments in [SAF06] keep track of the aggregate approved Rate Requests over the most recent two time intervals, for intervals of 150 msec.
最近のクイックスタートの承認から潜在的な帯域幅を追跡するローカルポリシーは、それが行われるべきかを指示別のケースです。 8.2節で概説した最も簡単な方法は、ルータの現在の時間間隔を含む、最新の2回の以上の時間間隔で承認集約クイック・スタート・レート要求を追跡すると、集約レートの合計を使用するためのものです承認されたレート要求の推定値としてこれらの時間間隔にわたり要求。 [SAF06]での実験は、150ミリ秒の間隔で、最新の2つの時間間隔にわたり総額承認された料金の要求を追跡します。
The target algorithm also depends on a threshold (qs_thresh) that is the fraction of the outgoing link bandwidth that represents the router's notion of "significantly underutilized". If the utilization, augmented by the potential bandwidth from recent Quick-Start approvals, is above this threshold, then no Quick-Start Rate Requests will be approved. If the utilization, again augmented by the potential bandwidth from recent Quick-Start approvals, is less than the threshold, then Rate Requests can be approved. The Rate Requests will be reduced such that the bandwidth allocated would not drive the utilization to more than the given threshold. The algorithm is:
対象アルゴリズムは、「大幅に活用されていない」のルータの概念を表し発信リンクの帯域幅の一部であるしきい値（qs_thresh）に依存します。利用率は、最近のクイックスタートの承認からの潜在的な帯域幅によって拡張、この閾値を超えている場合には、何のクイックスタートレート要求は承認されません。利用率は、再び最近のクイックスタートの承認からの潜在的な帯域幅によって増大、閾値未満である場合には、料金のリクエストは承認することができます。レート要求は、割り当てられた帯域幅が与えられた閾値以上に利用を運転しないような低減されます。アルゴリズムは次のとおりです。
util_bw = bandwidth * utilization;
util_bw = util_bw + recent_qs_approvals;
if (util_bw < (qs_thresh * bandwidth))
{
approved = (qs_thresh * bandwidth) - util_bw;
if (rate_request < approved)
approved = rate_request;
approved = round_down (approved);
recent_qs_approvals += approved;
}
Also note that, given that Rate Requests are fairly coarse, the approved rate should be rounded down when it does not fall exactly on one of the rates allowed by the encoding scheme.
また、レート要求はかなり粗いことを考えると、あることに注意してください、それは符号化方式によって許可されたレートの1つに正確に該当しない場合は、承認率は切り捨てされなければなりません。
Routers that wish to keep close track of the allocated Quick-Start bandwidth could use Approved Rate reports to learn when rate requests had been decremented downstream in the network, and also to learn when a sender begins to use the approved Quick-Start Request.
割り当てられたクイックスタート帯域幅は、レート要求は、ネットワーク内の下流にデクリメントされていたとき、学ぶために承認された料金のレポートを使用することができ、また、送信者が承認されたクイック・スタート・リクエストを使用し始めたときに学ぶことの近くにトラックを保持したいルータ。
Appendix E. Possible Additional Uses for the Quick-Start Option
クイック・スタート・オプションについては、付録E.可能性のあるその他の使用
The Quick-Start Option contains a four-bit Function field in the third byte, enabling additional uses to be defined for the Quick-Start Option. In this section, we discuss some of the possible additional uses that have been discussed for Quick-Start. The Function field makes it easy to add new functions for the Quick-Start Option.
クイックスタートオプションは、クイック・スタート・オプションのために定義される追加の使用を可能にする、3番目のバイトに4ビットのファンクション・フィールドが含まれています。このセクションでは、クイックスタートのために議論されている可能な追加の用途のいくつかを議論します。機能フィールドは、クイック・スタート・オプションのための新機能を追加することが容易になります。
Report of Current Sending Rate: A Quick-Start Request with the `Report of Current Sending Rate' codepoint set in the Function field would be using the Rate Request field to report the current estimated sending rate for that connection. This could accompany a second Quick-Start Request in the same packet containing a standard rate request, for a connection that is using Quick-Start to increase its current sending rate.
現在の送信レートのレポート：関数のフィールドに設定された現在の送信レート」コードポイントは、その接続の現在の推定送信レートを報告するためにレート要求フィールドを使用してしまうの `レポートとクイックスタート要求。これは、現在の送信レートを高めるためにクイックスタートを使用している接続するための標準レート要求を含む同じパケットにおける第二クイックスタート要求を伴う可能性があります。
Request to Increase Sending Rate: A codepoint for `Request to Increase Sending Rate' in the Function field would indicate that the connection is not idle or just starting up, but is attempting to use Quick-Start to increase its current sending rate. This codepoint would not change the semantics of the Rate Request field.
接続がアイドル状態か、単に起動ではないことを示すことになる機能フィールドに「レートを送信高めるために `要求のためのコードポイントを、その現在の送信レートを高めるためにクイックスタートを使用しようとしている：リクエストが送信速度を増加させます。このコードポイントは、レート要求フィールドのセマンティクスを変更しないでしょう。
RTT Estimate: If a codepoint for `RTT Estimate' was used, a field for the RTT Estimate would contain one or more bits giving the sender's rough estimate of the round-trip time, if known. E.g., the sender could estimate whether the RTT was greater or less than 200 ms. Alternately, if the sender had an estimate of the RTT when it sends the Rate Request, the two-bit Reserved field at the end of the Quick-Start Option could be used for a coarse-grained encoding of the RTT.
RTT推定： `RTT推定」のコードポイントを使用した場合は、RTT推定のためのフィールドが既知の場合、往復時間の送信者の概算を与える1つ以上のビットが含まれています。例えば、送信者は、RTTが大きいか200ミリ秒未満であったかどうかを見積もることができます。それがレート要求を送信すると、送信者は、RTTの見積もりを持っていた場合は代わりに、クイック・スタート・オプションの最後に2ビットの予約フィールドは、RTTの粗粒度のエンコーディングを使用することができます。
Informational Request: An Informational Request codepoint in the Function field would indicate that a request is purely informational, for the sender to find out if a rate request would be approved, and what size rate request would be approved when the Informational Request is sent. For example, an Informational Request could be followed one round-trip time later by a standard Quick-Start Request. A router approving an Informational Request would not consider this as an approval for Quick-Start bandwidth to be used, and would not be under any obligation to approve a similar standard Quick-Start Request one round-trip time later. An Informational Request with a rate request of zero could be used by the sender to find out if all of the routers along the path supported Quick-Start.
情報のリクエスト：機能分野における情報要求のコードポイントは、レートリクエストが承認されるだろう、との情報要求が送信されたときにどのようなサイズのレート要求が承認されるかどう送信者が見つけることの要求は、純粋に情報であることを示すことになります。たとえば、情報の要求は、1往復時間後に標準のクイックスタート要求が続くことができます。情報のリクエストを承認するルータは、クイックスタートの帯域幅を使用するための承認として、これを考慮していないだろう、と1往復時間後に類似した標準のクイック・スタート・リクエストを承認する義務はないだろう。ゼロのレート要求と情報要求は、パスに沿ってすべてのルータは、クイックスタートをサポートするかどうかを調べるために、送信者によって使用することができます。
Use Format X for the Rate Request Field: A Quick-Start codepoint for `Use Format X for the Rate Request Field' would indicate that an alternate format was being used for the Rate Request field.
レート要求フィールドの形式のXを使用します。レート要求フィールドのための `書式を使用X」のためのクイックスタートコードポイントは、代替フォーマットはレート要求フィールドのために使用されていたことを示します。
Do Not Decrement: A Do Not Decrement codepoint could be used for a Quick-Start Request where the sender would rather have the request denied than to have the rate request decremented in the network. This could be used if the sender was only interested in using Quick-Start if the original rate request was approved.
減少しません。：コードポイントをデクリメントしないAは、送信側ではなくネットワークに減らさレート要求を持っているよりも、拒否された要求を持っているでしょうクイックスタート要求を使用することができます。元のレート要求が承認された場合、送信者は、クイックスタートを使用することにのみ興味があった場合、これを使用することができます。
Temporary Bandwidth Use: A Temporary codepoint has been proposed to indicate that a connection would only use the requested bandwidth for a single time interval.
一時的な帯域幅の使用：一時的なコードポイントは、接続は単一の時間間隔で要求された帯域幅を使用することを指示することが提案されています。
Normative References
引用規格
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]ムガール人、J.とS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]オールマン、M.、パクソン、V.、およびW.スティーブンス、 "TCP輻輳制御"、RFC 2581、1999年4月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
"IPに明示的輻輳通知の添加（ECN）" [RFC3168]ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、RFC 3168、2001年9月。
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, October 2002.
[RFC3390]オールマン、M.、フロイド、S.、およびC.ヤマウズラ、 "増加するTCPの初期ウィンドウ"、RFC 3390、2002年10月。
[RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large Congestion Windows", RFC 3742, March 2004.
[RFC3742]フロイド、S.、 "大混雑のWindowsとのTCPのための限定スロースタート"、RFC 3742、2004年3月。
Informative References
参考文献
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC792]ポステル、J.、 "インターネット制御メッセージプロトコル"、STD 5、RFC 792、1981年9月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]のRivest、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]ベイカー、F.、エド。、 "IPバージョン4つのルータのための要件"、RFC 1812、1995年6月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]パーキンス、C.、 "IP内IPカプセル化"、RFC 2003、1996年10月。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113]カッツ、D.、 "IPルータアラートオプション"、RFC 2113、1997年2月。
[RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, April 1997.
[RFC2140]タッチ、J.、 "TCP制御ブロック相互依存"、RFC 2140、1997年4月。
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"、RFC 2205、1997年9月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[RFC2415] Poduri, K. and K. Nichols, "Simulation Studies of Increased Initial TCP Window Size", RFC 2415, September 1998.
[RFC2415] Poduri、K.とK.ニコルズ、 "増加した初期のTCPウィンドウサイズのシミュレーション研究"、RFC 2415、1998年9月。
[RFC2488] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP Over Satellite Channels using Standard Mechanisms", BCP 28, RFC 2488, January 1999.
[RFC2488]オールマン、M.、グローバー、D.、およびL.サンチェス、BCP 28、RFC 2488、1999年1月、 "標準的なメカニズムを使用して強化TCP上の衛星テレビ"。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol 'L2TP'", RFC 2661, August 1999.
[RFC2661] Townsley、W.、バレンシア、A.、ルーベンス、A.、ポール、G.、ツォルン、G.、およびB. Palter、 "レイヤ2トンネリングプロトコル 'L2TP'"、RFC 2661、1999年8月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]ファリナッチ、D.、李、T.、ハンクス、S.、マイヤー、D.、およびP. Trainaの、 "総称ルーティングカプセル化（GRE）"、RFC 2784、2000年3月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960]スチュワート、R.、謝、Q.、Morneault、K.、シャープ、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カラ、M.、チャン、L.、およびV 。パクソン、 "ストリーム制御伝送プロトコル"、RFC 2960、2000年10月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC 3124, June 2001.
[RFC3124]バラクリシュナン、H.とS. Seshan、 "輻輳管理"、RFC 3124、2001年6月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]大工、B.とS.つば、 "のMiddleboxes：分類と課題"、RFC 3234、2002年2月。
[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]パーキンス、C.、エド。、 "IPv4のIPモビリティサポート"、RFC 3344、2002年8月。
[RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", BCP 60, RFC 3360, August 2002.
[RFC3360]フロイド、S.、 "有害考慮不適切なTCPリセット"、BCP 60、RFC 3360、2002年8月。
[RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", RFC 3649, December 2003.
[RFC3649]フロイド、S.、 "大混雑Windows用の高速TCP"、RFC 3649、2003年12月。
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", RFC 3662, December 2003.
[RFC3662]祝福、R.、ニコルズ、K.、およびK. Wehrleの、 "低級努力ドメイン単位の行動差別化サービスのための（PDB）"、RFC 3662、2003年12月。
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004.
[RFC3697] Rajahalme、J.、コンタ、A.、大工、B.、およびS.デアリング、 "IPv6のフローラベル仕様"、RFC 3697、2004年3月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004.
[RFC3819]カーン、P.、ボルマン、C.、Fairhurst、G.、グロスマン、D.、ルートヴィヒ、R.、Mahdavi、J.、モンテネグロ、G.、タッチ、J.、およびL.ウッド、「アドバイスインターネットサブネットワークデザイナー」、BCP 89、RFC 3819、2004年7月のため。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
[RFC3948] Huttunen、A.、Swander、B.、ボルペ、V.、DiBurro、L.、及びM.ステンバーグ、 "IPsecのESPパケットのUDPカプセル化"、RFC 3948、2005年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]コーラー、E.、ハンドリー、M.、およびS.フロイド、 "データグラム輻輳制御プロトコル（DCCP）"、RFC 4340、2006年3月。
[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）輻輳制御ID 2用のプロフィール：TCPのような輻輳制御"、RFC 4341、2006年3月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]コンタ、A.、デアリング、S.、およびM.グプタ、 "インターネットプロトコルバージョン6（IPv6）の仕様のためのインターネット制御メッセージプロトコル（ICMPv6の）"、RFC 4443、2006年3月。
[AHO98] M. Allman, C. Hayes and S. Ostermann. An evaluation of TCP with Larger Initial Windows. ACM Computer Communication Review, July 1998.
【AHO98] M.オールマン、C.ヘイズ及びS. Ostermann。大きな初期のWindowsでのTCPの評価。 ACMコンピュータコミュニケーションレビュー、1998年7月。
[B05] Briscoe, B., "Review: Quick-Start for TCP and IP", <http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html>, November 2005.
[B05]ブリスコー、B.、 "レビュー：TCPとIPのためのクイックスタート"、<http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html>、2005年11月。
[BW97] G. Brasche and B. Walke. Concepts, Services and Protocols of the new GSM Phase 2+ General Packet Radio Service. IEEE Communications Magazine, pages 94--104, August 1997.
[BW97] G. Brasche及びB. Walke。新しいGSMフェーズ2+汎用パケット無線サービスのコンセプト、サービスおよびプロトコル。 IEEEコミュニケーションズマガジン、ページ94--104、1997年8月。
[GPAR02] A. Gurtov, M. Passoja, O. Aalto, and M. Raitola. Multi-Layer Protocol Tracing in a GPRS Network. In Proceedings of the IEEE Vehicular Technology Conference (Fall VTC2002), Vancouver, Canada, September 2002.
【GPAR02] A. Gurtov、M. Passoja、O.アールト、およびM. Raitola。 GPRSネットワークでのトレースマルチレイヤプロトコル。 IEEE車両用技術会議の議事録（VTC2002秋）、バンクーバー、カナダ、2002年9月。
[H05] P. Hoffman, email, October 2005. Citation for acknowledgement purposes only.
[H05] P.ホフマン、電子メール、確認のみを目的とした2005年10月の引用。
[HKP01] M. Handley, C. Kreibich and V. Paxson, Network Intrusion Detection: Evasion, Traffic Normalization, and End-to-End Protocol Semantics, Proc. USENIX Security Symposium 2001.
[HKP01] M.ハンドリー、C. KreibichおよびV.パクソン、ネットワーク侵入検知：回避、トラフィック正規化、およびエンドツーエンドのプロトコルセマンティクス、PROC。 USENIXセキュリティシンポジウム2001。
[Jac88] V. Jacobson, Congestion Avoidance and Control, ACM SIGCOMM.
【Jac88】V. Jacobsonの、輻輳回避とコントロール、ACM SIGCOMM。
[JD02] Manish Jain, Constantinos Dovrolis, End-to-End Available Bandwidth: Measurement Methodology, Dynamics, and Relation with TCP Throughput, SIGCOMM 2002.
[JD02]マニッシュ・ジャイン、コンスタンDovrolis、エンド・ツー・エンドの利用可能帯域幅：測定方法、ダイナミクス、およびTCPスループット、SIGCOMM 2002との関係。
[K03] S. Kunniyur, "AntiECN Marking: A Marking Scheme for High Bandwidth Delay Connections", Proceedings, IEEE ICC '03, May 2003. <http://www.seas.upenn.edu/~kunniyur/>.
[K03] S. Kunniyur、 "マーキングAntiECN：マーキングスキームを高帯域幅遅延接続のために"、議事録、IEEE ICC '03、2003年5月<http://www.seas.upenn.edu/~kunniyur/>。
[KAPS02] Rajesh Krishnan, Mark Allman, Craig Partridge, James P.G. Sterbenz. Explicit Transport Error Notification (ETEN) for Error-Prone Wireless and Satellite Networks. Technical Report No. 8333, BBN Technologies, March 2002. <http://www.icir.org/mallman/papers/>.
[KAPS02]ラジェス・クリシュナン、マーク・オールマン、クレイグ・パートリッジ、ジェームズ・P。G. Sterbenz。エラーが発生しやすい無線および衛星ネットワークのための明示的な輸送エラー通知（ETEN）。技術レポートNo. 8333、BBN Technologies社、2002年3月<http://www.icir.org/mallman/papers/>。
[KHR02] Dina Katabi, Mark Handley, and Charles Rohrs, Internet Congestion Control for Future High Bandwidth-Delay Product Environments. ACM Sigcomm 2002, August 2002. <http://ana.lcs.mit.edu/dina/XCP/>.
[KHR02]ダイナ・カタビ、マーク・ハンドリー、チャールズRohrs、将来の高帯域遅延製品の環境のためのインターネットの輻輳制御。 ACM SIGCOMM 2002、2002年8月<http://ana.lcs.mit.edu/dina/XCP/>。
[KK03] A. Kuzmanovic and E. W. Knightly. TCP-LP: A Distributed Algorithm for Low Priority Data Transfer. INFOCOM 2003, April 2003.
[KK03] A. Kuzmanovic及びE. W.騎士。 TCP-LP：低優先度のデータ転送のための分散アルゴリズム。インフォコム2003年、2003年4月。
[KSEPA04] Rajesh Krishnan, James Sterbenz, Wesley Eddy, Craig Partridge, Mark Allman. Explicit Transport Error Notification (ETEN) for Error-Prone Wireless and Satellite Networks. Computer Networks, 46(3), October 2004.
[KSEPA04]ラジェス・クリシュナン、ジェームズSterbenz、ウェズリーエディ、クレイグ・パートリッジ、マーク・オールマン。エラーが発生しやすい無線および衛星ネットワークのための明示的な輸送エラー通知（ETEN）。コンピュータネットワーク、46（3）、2004年10月。
[L05] Guohan Lu, Nonce in TCP Quick Start, September 2005. <http://www.net-glyph.org/~lgh/nonce-usage.pdf>.
[L05] Guohan呂、TCPクイックスタートでナンス、2005年9月<http://www.net-glyph.org/~lgh/nonce-usage.pdf>。
[MH06] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", Work in Progress, December 2006.
[MH06]マシス、M.とJ. Heffnerは、 "パケット化レイヤのパスMTUディスカバリ"、進歩、2006年12月に作業します。
[MAF04] Alberto Medina, Mark Allman, and Sally Floyd, Measuring Interactions Between Transport Protocols and Middleboxes, Internet Measurement Conference 2004, August 2004. <http://www.icir.org/tbit/".
[MAF04]アルベルト・メディナ、マーク・オールマン、サリーフロイド、トランスポートプロトコルとのMiddleboxes間の相互作用を測定する、インターネット測定コンファレンス2004、2004年8月<http://www.icir.org/tbit/」。
[MAF05] Alberto Medina, Mark Allman, and Sally Floyd. Measuring the Evolution of Transport Protocols in the Internet. Computer Communications Review, April 2005.
[MAF05]アルベルト・メディナ、マーク・オールマン、とサリーフロイド。インターネットにおけるトランスポートプロトコルの進化を測定します。コンピュータコミュニケーションレビュー、2005年4月。
[MaxNet] MaxNet Home Page, <http://netlab.caltech.edu/~bartek/maxnet.htm>.
[MAXNET] MAXNETホームページ、<http://netlab.caltech.edu/~bartek/maxnet.htm>。
[P00] Joon-Sang Park, Bandwidth Discovery of a TCP Connection, report to John Heidemann, 2000, private communication. Citation for acknowledgement purposes only.
[P00]パーク、TCP接続の帯域幅発見、ジョンHeidemann、2000年、民間の通信にレポートをジュンサンウ。唯一の確認の目的のために引用。
[PABL+05] Ruoming Pang, Mark Allman, Mike Bennett, Jason Lee, Vern Paxson, Brian Tierney. A First Look at Modern Enterprise Traffic. ACM SIGCOMM/USENIX Internet Measurement Conference, October 2005.
[PABL + 05] Ruomingパン、マーク・オールマン、マイク・ベネット、ジェイソン・リー、バーン・パクソン、ブライアン・ティアニー。現代の企業トラフィックで初見。 ACM SIGCOMM / USENIXインターネット測定コンファレンス、2005年10月。
[PRAKS02] Craig Partridge, Dennis Rockwell, Mark Allman, Rajesh Krishnan, James P.G. Sterbenz. A Swifter Start for TCP. Technical Report No. 8339, BBN Technologies, March 2002. <http://www.icir.org/mallman/papers/>.
[PRAKS02]クレイグ・パートリッジ、デニス・ロックウェル、マーク・オールマン、ラジェッシュクリシュナン、ジェームズ・P。G. Sterbenz。 TCPのための迅速確実スタート。技術レポートNo. 8339、BBN Technologies社、2002年3月<http://www.icir.org/mallman/papers/>。
[RW03] Mattia Rossi and Michael Welzl, On the Impact of IP Option Processing, Preprint-Reihe des Fachbereichs Mathematik - Informatik, No. 15, Institute of Computer Science, University of Innsbruck, Austria, October 2003.
[RW03] IPオプション処理の影響に関するマティア・ロッシとマイケルWelzl、数学科のプレプリントシリーズ - コンピュータサイエンス号15、コンピュータサイエンス、インスブルック、オーストリアの大学、2003年の10月の研究所。
[RW04] Mattia Rossi and Michael Welzl, On the Impact of IP Option Processing - Part 2, Preprint-Reihe des Fachbereichs Mathematik - Informatik, No. 26, Institute of Computer Science, University of Innsbruck, Austria, July 2004.
[RW04]マティア・ロッシとマイケルWelzl、IPオプションの処理の影響について - パート2、数学科のプレプリントシリーズ - コンピュータサイエンス号26、コンピュータサイエンス、インスブルック、オーストリアの大学、2004年7月の研究所。
[S02] Ion Stoica, private communication, 2002. Citation for acknowledgement purposes only.
[S02]イオン・ストイカ、民間の通信、確認のみを目的として2002年引用。
[SAF06] Pasi Sarolahti, Mark Allman, and Sally Floyd. Determining an Appropriate Sending Rate Over an Underutilized Network Path. February 2006. <http://www.icir.org/floyd/quickstart.html>.
【SAF06】パシSarolahti、マークオールマン、及びサリーフロイド。遊休ネットワーク経路上で適切な送信レートを決定します。 2006年2月<http://www.icir.org/floyd/quickstart.html>。
[SGF05] Singh, M., Guha, S., and P. Francis, "Utilizing spare network bandwidth to improve TCP performance", ACM SIGCOMM 2005 Work in Progress session, August 2005, <https://www.guha.cc/saikat/pub/sigcomm05-lowtcp.pdf>.
[SGF05]シン、M.、グハ、S.、およびP.フランシス、進行中のセッションでACM SIGCOMM 2005作品 "TCP性能を向上させるために予備のネットワーク帯域幅を利用"、2005年8月、<https://www.guha.cc /saikat/pub/sigcomm05-lowtcp.pdf>。
[SHA1] "Secure Hash Standard", FIPS, U.S. Department of Commerce, Washington, D.C., publication 180-1, April 1995.
[SHA1]、FIPS、米国商務省が、ワシントンD.C.、出版180-1、1995年4月 "ハッシュ標準セキュア"。
[SH02] Srikanth Sundarrajan and John Heidemann. Study of TCP Quick Start with NS-2. Class Project, December 2002. Not publicly available; citation for acknowledgement purposes only.
[SH02]スリカンスSundarrajanとジョンHeidemann。 NS-2とのTCPクイックスタートの研究。クラスプロジェクト、2002年12月公に利用できるわけではありません。唯一の確認の目的のために引用。
[V02] A. Venkataramani, R. Kokku, and M. Dahlin. TCP Nice: A Mechanism for Background Transfers. OSDI 2002.
[V02] A. Venkataramani、R. Kokku、およびM.ダーリン。 TCPニース：バックグラウンド転送のためのメカニズム。 OSDI 2002。
[VH97] V. Visweswaraiah and J. Heidemann, Improving Restart of Idle TCP Connections, Technical Report 97-661, University of Southern California, November 1997.
[VH97] V. VisweswaraiahとJ. Heidemann、アイドルTCPコネクションの再起動、テクニカルレポート97から661、南カリフォルニア、1997年11月の大学の改善。
[W00] Michael Welzl: PTP: Better Feedback for Adaptive Distributed Multimedia Applications on the Internet, IPCCC 2000 (19th IEEE International Performance, Computing, And Communications Conference), Phoenix, Arizona, USA, 20-22 February 2000. <http://www.welzl.at/research/publications/>.
[W00]マイケルWelzl：PTP：インターネット上で適応分散型マルチメディアアプリケーションのためのより良いフィードバック、IPCCC 2000（第19回IEEE国際パフォーマンス、コンピューティング、通信会議）、フェニックス、アリゾナ州、アメリカ、2000年2月20-22 <のhttp：/ /www.welzl.at/research/publications/>。
[ZDPS01] Y. Zhang, N. Duffield, V. Paxson, and S. Shenker, On the Constancy of Internet Path Properties, Proc. ACM SIGCOMM Internet Measurement Workshop, November 2001.
【ZDPS01] Y.チャン、N.ダフィールド、V.パクソン、およびS. Shenker、インターネット路特性の不変に、PROC。 ACM SIGCOMMインターネット測定ワークショップ、2001年11月。
[ZQK00] Y. Zhang, L. Qiu, and S. Keshav, Speeding Up Short Data Transfers: Theory, Architectural Support, and Simulation Results, NOSSDAV 2000, June 2000.
[ZQK00] Y.チャン、L.秋、およびS. Keshav、ショート・データ転送の高速化：理論、建築のサポート、およびシミュレーション結果、NOSSDAV 2000、2000年6月を。
Authors' Addresses
著者のアドレス
Sally Floyd Phone: +1 (510) 666-2989 ICIR (ICSI Center for Internet Research) EMail: floyd@icir.org URL: http://www.icir.org/floyd/
サリーフロイド電話：+1（510）666-2989 ICIR（インターネットリサーチのためのICSIセンター）メール：floyd@icir.org URL：http://www.icir.org/floyd/
Mark Allman ICSI Center for Internet Research 1947 Center Street, Suite 600 Berkeley, CA 94704-1198 Phone: (440) 235-1792 EMail: mallman@icir.org URL: http://www.icir.org/mallman/
インターネットリサーチのためのマーク・オールマンICSIセンター1947センターストリート、スイート600バークレー、CA 94704から1198電話：（440）235から1792 Eメール：mallman@icir.org URL：http://www.icir.org/mallman/
Amit Jain F5 Networks EMail: a.jain@f5.com
アミットジャイナF5ネットワークスEメール：a.jain@f5.com
Pasi Sarolahti Nokia Research Center P.O. Box 407 FI-00045 NOKIA GROUP Finland Phone: +358 50 4876607 EMail: pasi.sarolahti@iki.fi
パシSarolahtiノキア・リサーチセンター私書箱ボックス407 FI-00045 NOKIA GROUPフィンランド電話番号：+358 50 4876607 Eメール：pasi.sarolahti@iki.fi
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書およびここに含まれる情報は、上に提供される基礎とCONTRIBUTOR、ORGANIZATION彼/彼女が表すOR（もしあれば）後援が「そのまま」、インターネット学会、IETFトラスト、インターネットエンジニアリングタスクフォース放棄情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されないすべての保証、明示または黙示、。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。