[要約] RFC 4782は、TCPとIPのためのクイックスタートメカニズムについての要約と目的を提供しています。このRFCの目的は、ネットワークの遅延を最小限に抑え、TCP接続の確立を迅速化することです。
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
TCPおよび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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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での使用のみを指定します。Quick-Startは、パスに沿って大幅に使用されていない帯域幅がある場合、接続がより高い送信レートを使用できるように設計されており、パスに沿った送信者とすべてのルーターがクイックスタートリクエストを承認します。
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を2倍にします。
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.
スロースタートアルゴリズムは、特に大きな帯域幅または長い遅延を持つネットワーク上で時間がかかる場合があります。TCP接続がネットワークの利用可能な帯域幅を完全に使用し始める前に、スロースタートで多数のRTTが必要になる場合があります。たとえば、Log_2（n）-2ラウンドトリップ時間がかかり、4つのセグメントの初期輻輳ウィンドウを想定して、nセグメントまでCWNDを構築します。今回はスロースタートでは、スロースタートステージが総転送時間のほんの一部にすぎない大きなファイル転送の問題ではありません。ただし、中程度のサイズの転送の場合、接続はスロースタートフェーズでの転送全体を実行する可能性があり、多くの往復時間をとることができます。道。
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.
TCPの初期輻輳ウィンドウを選択する問題に対処するためにかなりの量の作業が行われています。RFC3390により、接続で使用されるMSS [RFC3390]に基づいて最大4つのセグメントの初期ウィンドウが可能になります。根本的な前提は、現在のアーキテクチャでは、パスに沿ったすべてのルーターからの明示的なフィードバックが必要になることです。最良の接続が[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ヘッダーでクイックスタートオプションを使用して、1秒あたりのバイトでその目的の送信率を示します。パスに沿った各ルーターは、要求されたレートを承認するか、要求された料金を下げるか、クイックスタート要求が承認されていないことを示します。（このドキュメントで言及されている「ルーター」には、送信者でのクイックスタートリクエストの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に含まれています。特に、クイックスタートはIPv4およびセクション3のIPv6に指定され、セクション4のTCPに指定されています。セクション6は、主にIPトンネルおよびMPLとのクイックスタートの相互作用に関する非規範的な議論で構成されています。ただし、セクション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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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でクイックスタートを使用して、より高い輻輳ウィンドウを要求する概要を説明します。このセクションの説明は非規範的です。IPおよびTCPを使用したクイックスタートの規範的な説明は、セクション3および4に続きます。クイックスタートは、接続の途中で、たとえばアイドルまたは十分に活用されていない期間の後、および初期送信率について使用できます。これらのクイックスタートの使用については、後でドキュメントで説明します。
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.
リクエストとして送信される場合、クイックスタートオプションには、1秒あたりのビットでの送信レートのリクエストと、オプションを理解し承認するパスに沿ってすべてのルーターによって減少するためのクイックスタート時間（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は、送信者の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.
図3：IPv4のクイックスタートオプション。クイックスタートリクエスト。
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フィールドをランダム値に設定する必要があります。クイックスタートリクエストを承認するルーターは、QS TTL（MOD 256）をIP TTLを減少させるのと同じ量だけ減少させます。（このドキュメントの他の場所と同様に、「ルーター」という用語を不正確に使用して、送信者の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 DIFF、IP TTL値の差、およびクイックスタートリクエストパケットのQS TTL値の差を計算して保存する必要があります。
TTL Diff = ( 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.
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のレート要求フィールドの値、および40,000に設定します。n = 0の場合、エンコード関数に関係なく、レート要求がゼロに設定されます。これを以下の表1に示します。4ビットレート要求フィールドの場合、要求範囲は80 kbpsから1.3 Gbpsです。レートリクエストに対して考慮された代替エンコーディングは、付録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.
図4：IPv4のクイックスタートオプション。承認された料金のレポート。
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番目のバイトの2番目の4ビットは、レートリクエストのレートリクエストフィールドとまったく同じフォーマットされたレートレポートフィールドです。承認された料金のレポートの場合、クイックスタートオプションの4番目のバイトは使用されません。バイト5-8には、30ビットQSノンセと2ビット予約フィールドが含まれています。
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.
承認された料金要求の後、送信者は、承認された料金のレポートとして設定されたクイックスタートオプションを承認されたレートに設定し、QS NonCEがQS NonCEに送信されたQS NonCEに設定された承認された料金を使用して、承認された料金を報告する必要があります。クイックスタートリクエスト。承認されたレートのレポートを含むパケットは、最初のクイックスタートデータパケットの前に送信されるコントロールパケット、または最初のデータパケット自体のクイックスタートオプションのいずれかでなければなりません。承認された料金のレポートは、確実に送信する必要はありません。たとえば、承認されたレートが別のコントロールパケットで報告されている場合、送信者は、コントロールパケットがネットワークで削除されたかどうかを必ずしも知りません。クイックスタートリクエストを含むパケットが承認されているが、承認パケットにクイックスタート応答が含まれていない場合、送信者はクイックスタートリクエストが拒否されたと想定し、承認されたレートのレポートを設定する必要があります。ゼロ。ルーターは、承認された料金のレポートを無視するか、承認された料金のレポートを使用するが、QS NonCEを無視することを選択する場合があります。あるいは、承認されたレートのレポートを使用する一部のルーターは、承認されたレートでマスクされたQSノンセと一致することを選択できます。
If the Rate Request is denied, the sender MUST send a Report of Approved Rate with the Rate Report field set to zero.
レート要求が拒否された場合、送信者は、レートレポートフィールドがゼロに設定された承認されたレートのレポートを送信する必要があります。
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]。一般的なホップバイホップオプションヘッダーに続くオプション形式は、IPv4形式と同じですが、長さフィールドはオプション形式で共通のタイプと長さのフィールドを除外し、8バイトではなく6バイトに設定する必要があります。
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ホップ制限フィールドと比較して、TTL DIFFを計算します。（IPv6のホップ制限は、IPv4のTTLに相当します。）つまり、TTL DIFFは次のように計算および保存する必要があります。
TTL Diff = ( IPv6 Hop Limit - 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とは異なり、Quick-Start 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.
上記の段落では、クイックスタートリクエストを承認する *セマンティクス *を定義していますが、このドキュメントでは、クイックスタートリクエストまたはレポートの処理でルーターが使用する特定のアルゴリズムを指定していません。これはRFC 3168に似ています。これは、IPヘッダーのECNコードポイントのセマンティクスを詳細に説明していますが、バッファオーバーフローの前にパケットをドロップまたはマークするタイミングを決定する際に使用するために使用する特定のアルゴリズムを指定していません。
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 NonCE、およびレートリクエストフィールドをゼロする必要があります。Quick-Startリクエストの削除は、下流のルーターに処理するオプションがないため、リソースを節約できますが、ルーターのゼロをゼロにすることは、ルーターが実装する方が効率的になる場合があります。[B05]で提案されているように、クイックスタートへの将来の追加は、ルーターのエラーコードを定義してQS NonCEフィールドに挿入して、クイックスタート要求が拒否された理由を送信者に報告することができます。現時点でのすべてのクイックスタートリクエスト、またはこのルーターは、ポリシーの問題として、クイックスタートリクエストを付与しないことです。クイックスタートオプションを理解していないルーターは、クイックスタートリクエストが変更されていないパケットを単純に転送します（TTL DIFFが一致しないようにし、クイックスタートは使用されません）。
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 NonCEも変更する必要があります。
* 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を減らすことなく、不参加のルーターがクイックスタートリクエストを変更せずに転送します。非参加ルーターは、すべてのルーターに必要なように、IPヘッダーのTTLフィールドを引き続き減少させます[RFC1812]。その結果、送信者は、パスに沿ったすべてのルーターによってクイックスタートリクエストが理解または承認されていないことを検出できます。
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 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.
クイックスタートオプションに関数フィールドが「1000」に設定されている場合、これはレートリクエストではなく、承認されたレートのレポートです。ルーターはそのようなオプションを無視する場合があり、いずれにしても、承認された料金のレポートのオプションの内容を変更してはなりません。ただし、ルーターは承認された料金レポートを使用して、送信者が承認された料金について嘘をついていないことを確認する場合があります。報告された承認されたレートが、前の往復時間にルーターがこの接続に対して実際に承認したレートよりも高い場合、ルーターは詐欺師のポリシーを実装する場合があります。たとえば、ルーターは、この送信者からの将来のパケットからのクイックスタートリクエストを削除するなど、この送信者からの将来のクイックスタートリクエストを拒否することを決定する場合があります。セクション9.4.1では、誤動作の送信者についてさらに詳しく説明します。承認されたレートのレポートから、ルーターは、下流のルーターの一部がより少ないレートのクイックスタート要求を承認したか、クイックスタートの使用を拒否したかどうかを学ぶことができ、それに応じて帯域幅の割り当てを調整することもできます。
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 NONCEは、受信レートリクエストの値について嘘をついているレシーバーに対するクイックスタート送信者にいくらかの保護を与えます。これは、受信者がレートリクエストの元の値を知っている場合に特に重要です（たとえば、送信者が常に同じ値を要求し、受信者がその送信者との通信の長い履歴を持っている場合）。QS nonceがなければ、受信レート要求が実際にKよりも少ない場合、受信者がKのレート要求を送信者に報告することを妨げるものはありません。
Table 2 gives the format for the 30-bit QS Nonce.
表2に、30ビットQS Nonceの形式を示します。
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 nonce。
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-> rate k-1」のqs nonceのフィールドを新しいランダム値に設定する必要があります。同様に、ルーターがnステップでレート要求を削減する場合、ルーターはQS NonCeの関連するフィールドの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 nonceの最後の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 nonceを使用すると、受信者はレートリクエストの各ステップ変更について1/4の不正行為をする可能性があります。したがって、ネットワーク内の2つのステップでレート要求が削減された場合、受信者は、QS NonCEの元の値を報告する必要があるため、元のリクエストが承認されたことを正常に報告する1/16のチャンスがあります。同様に、レート要求がネットワーク内の多くのステップを削減し、レシーバーがKのレートリクエストでQSオプションを受信すると、受信者はQS NonCEのフィールドの元の値を推測する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 NonCeによって提供される保護は、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 NonCeに「ランダム」値を設定する際の送信者とルーターのランダム化の要件は厳格ではありません。要件は、QS Nonceの元の値が受信機によって簡単に予測できないこと、特にノンセは、残りのパケットまたは以前のパケットの検査から簡単に決定する必要がないことです。特に、NonCeは、特定のパケットヘッダーフィールドの組み合わせにのみ基づいてはなりません。したがって、QS NonCeの2ビットがパスに沿ったルーターによって変更された場合、レシーバーはQS NonCeの他の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 NonCe自体から受信機が伝えることができないことです。これは、QS NonCeの数値が送信者によって生成され、パスに沿ったルーターによって生成されたことです。これにより、受信者が元のレートリクエストの値を推測することが難しくなり、受信者がチートするのが一歩難しくなります。
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送信者は、要求された送信レートを1秒あたりのビットで適切にフォーマットします。クイックスタートリクエストパケット。（このセクションでは、「パケット」と「セグメント」を使用するのはやや緩んでいます。）最初の起動に使用すると、クイックスタートリクエストパケットは、図に示すように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 DIFFまたはQS NonCEの値が間違っているクイックスタート応答が含まれている場合、ホスト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 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.
接続が確立されたときにクイックスタートの使用に加えて、トランスポートプロトコルがレートリクエストを発行する場合がある場合、接続にいくつかの追加ポイントがあります。最初に、クイックスタートは粗いメカニズムであるという概念を繰り返します。つまり、Quick-Startのレートリクエストは、輸送の送信率の細粒制御に使用することを意図したものではありません。むしろ、適切な送信率に関する情報が利用できない場合、輸送は料金要求を発行する場合があり、デフォルトの輻輳制御メカニズムは、適切な送信率を大幅に過小評価している可能性があります。
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) 上記のように、接続の開始時または直後に、トランスポートがネットワークパスの容量を知らない場合。（TCPコントロールブロック共有[RFC2140]、混雑マネージャー[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ミリ秒以上）に使用できるよりも大きい送信率を要求してはなりません。目的の送信率を次の最も高い許容要求にまとめるために必要です。
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 DIFFが含まれています。TTL DIFFには、式（1）または（2）で計算されるように、受信したクイックスタートリクエストパケットのIP TTLフィールドとQS TTLフィールドの差が含まれます（IPv4またはIPv6が使用されるかどうかに応じて）。
Bytes 5-8 of the TCP option contain the 30-bit QS Nonce and a two-bit Reserved field.
TCPオプションのバイト5-8には、30ビットQS NonCEと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.
クイックスタートリクエストを含むIPパケットを受信するエンドホスト（ホストB）は、IP TTLフィールドの値とともに、TCPレイヤーを受信します。
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差分は、式（1）または（2）に示されているように、IP TTL値とQS TTL値の差に設定されます（IPv4またはIPv6が使用されるかどうかに応じて）。応答のQS NonCEは、クイックスタートオプションでQS NonCEの受信値に設定されています。
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.
ネットワークで失われた場合、クイックスタートの応答はresしてはなりません。パケットの損失は、リターンパスでの混雑の兆候である可能性があります。その場合、クイックスタートリクエストを承認しない方が良いでしょう。
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 DIFFの正しい値と、クイックスタートリクエストで送信されたものよりもレートリクエストの等しい値または低い値が含まれている場合に有効です。さらに、受信レート要求がKの場合、QS NonCEの右端の2Kビットは、クイックスタートリクエストで送信されたQS NonCEのビットと一致する必要があります。これらのチェックが成功しない場合、クイックスタートリクエストは失敗し、TCPホストはクイックスタートなしで使用したデフォルトのTCP混雑ウィンドウを使用する必要があります。QS Nonceの右端の2Kビットが、QSのQS NonCEのビットがクイックスタートリクエストで送信され、Kの受信レートリクエストのためにこれらのビットと一致しない場合、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 = (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).
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.
導出：送信者は、パケットヘッダーを含む1秒あたりの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よりも大きい場合にのみ、混雑ウィンドウCWNDをQS-CWNDに設定する必要があります。それ以外の場合、QS-CWNDは無視されます。QS-CWNDを使用する場合、TCPホストはクイックスタートモードであるフラグを設定し、クイックスタートモードでは、TCP送信者はレートベースのペーシングを使用して、承認されたレートでクイックスタートパケットをペースアウトする必要があります。。クイックスタートモード中に、このクイックスタートモードが入力される前に送信されたパケットのTCP送信者がACKを受信した場合、これらのACKはデフォルトの輻輳制御メカニズムに従って通常どおり処理されます。クイックスタートモードは、TCPホストがクイックスタートパケットの1つの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送信者の往復時間の見積もりは、ラウンドトリップ時間の後続時間よりも長くなる可能性があるためです。クイックスタートリクエストパケットに応答する際のレシーバーでの遅延の。この場合、非常に大きな往復時間の推定では、TCP送信者が承認されたクイックスタート送信率を1秒あたりのバイトで翻訳して、必要以上の渋滞ウィンドウに変換され、TCP送信者はACKを受け取っています。輻輳ウィンドウ全体が使用される前の最初のクイックスタートパケットが使用されます。したがって、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の承認されたクイックスタートリクエスト、ヘッダーを含むBバイトパケット、およびT秒のRTT推定値を持つTCP送信者は、R KBPのレート要求をR*T/のうっ血ウィンドウに変換します。Bパケット。TCP送信者は、R KBPSでレートペースのクイックスタートパケットを送信します。ただし、実際の現在の往復時間がT秒ではなくT/2秒だった場合、送信者はT/2秒後にクイックスタートパケットの謝辞を受け取り始めます。上記の段落に続いて、TCP送信者は、輻輳ウィンドウをr*t/bからr*t/（b*2）パケットに減らします。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.
クイックスタートモードが終了し、必要に応じて輻輳ウィンドウが調整された後、TCP送信者はデフォルトの混雑制御メカニズムを使用して戻り、それらの輻輳制御メカニズムで指定されたようにさらに着信ACKパケットを処理します。たとえば、クイックスタートリクエストの前にTCP送信者がスロースタートで、その間からパケットが失われたりマークされたりしなかった場合、SSThreshが許可されているように、クイックスタートモードを終了した後、送信者はスロースタートで継続します。
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送信者は、スロースタート中に1つのデータウィンドウの輻輳ウィンドウが増加するパケットの数を制限します。
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パケットのトラフィックが突然増加する可能性があります。たとえば、1.3 Gbpsの最大のクイックスタートリクエストの場合、1500バイトのパケットを備えたTCP送信者と、他のすべてのパケットをアクセスする遅延承認を備えたTCPレシーバーを与えられた場合、これにより、逆パスで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].
大規模なクイックスタートリクエストがある場合の1つの可能性は、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*rtt/に設定されたACK比kの場合、すべてのKデータパケットに最大1つのACKを送信することにより、RTTごとに最大100個の純粋なACKパケットの送信率を制限できます。（100*8*MSS）。受信者は、最初のクイックスタートデータパケットと、後続のすべてのKデータパケットを認めます。したがって、r = 1.3 gbps、rtt = 0.2秒、およびMSS = 1500バイトのやや極端なケースでは、kが216に設定され、受信者は216個のデータパケットごとに認められます。[RFC2581]から、ACK比kの最小値は2でなければなりません。ACK比が2を超え、TCP送信者がそれぞれ2つ以上のデータパケットを認めていることを認めている場合、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レシーバーは、純粋なACKパケットの送信レートの増加を、純粋な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ストリームの制御に使用できる特定のメカニズムの1つであることに注意してください。このスキームと他のスキームを詳細に調査する将来の仕事が奨励されています。
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がクイックスタートを使用してより大きな初期ウィンドウを要求するときに発生する次の問題について説明します。（1）PATH MTU Discovery（PMTUD）との相互作用。（2）ミドルボックスによって破棄されるクイックスタートリクエストパケット。
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つの問題は、大きな初期ウィンドウとPATH 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." 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.
「Path MTU Discovery [RFC1191]とともに、より大きな初期ウィンドウが実装されている場合、代替案は、最初のウィンドウのすべてのセグメントに「Do n't Fragment」（DF）ビットを設定するか、「Do n't Fragment」（df）セグメントの1つにビット。これは、これら2つの選択肢のどれが最適かについての未解決の問題です。」最初のウィンドウが送信されたときに送信者がパス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).
送信者が最初のウィンドウが送信されたときにパスMTUを知らない場合、送信者はDFビットセットで最初のウィンドウに1つの大きなパケットを送信し、576バイトの小さい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.
2番目の可能性は、送信者がデータの最初のウィンドウでクイックスタートリクエストを送信することにより、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.
送信者は、Path MTU DiscoveryにPathetization Layer Path MTU Discovery（PLPMTUD）[MH06]などの反復アプローチを使用している場合があります。プローブが正常に配信された場合、MTUを上げて、そのプローブで使用される値を反映することができます。PLPMTUDでは、データの最初のウィンドウを送信する前に、送信者がパスMTUを決定することを許可しないことに注意してください。
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 Senderはクイックスタートリクエストなしで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 SenderはクイックスタートリクエストなしでSynまたはSyn/ACKパケットを再送信する必要があります[RFC3360]。
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.
RFCS 1122および2988は、送信者が初期RTO（再送信タイムアウト）を3秒に設定する必要があることを指定しますが、多くのTCP実装は初期RTOを1秒に設定します。クイックスタートリクエストで送信された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ヘッダーのビットを使用して、反対側のTCPホストとのECNキャピールを交渉し、ドロップすることにも注意してください。TCP synパケットの場合、IPオプションのために混雑、ルーターまたはパケットをドロップするルーターまたはミドルボックスが、TCPヘッダー交渉ECNの情報のためにパケットをドロップするルーターまたはミドルボックスが原因である可能性があります。この場合、送信者は、クイックスタートまたはECNリクエストなしでドロップされたパケットを再送信できます。あるいは、送信者は、TCPヘッダーのECN要求のみを使用してドロップされたパケットを再送信し、2番目のTCP Synパケットが削除された場合、クイックスタートまたはECN要求なしにTCP Synパケットを復活させることができます。TCPヘッダー[MAF04]のECNリクエストでパケットを破棄するポリシーよりも、IPオプションでパケットを破棄するポリシーのために、今日のTCP SynパケットがIPオプションを廃棄するポリシーによりブロックされる可能性が高いことを考えると、2番目の選択肢は合理的と思われます。
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.
すでに混雑イベントを経験しており、最近のモビリティイベントを持っていない接続でクイックスタートリクエストを使用するために、TCP送信者は、TCP接続が最後のパケットドロップ以降に達成した最大の混雑ウィンドウを決定し、これを翻訳することができます。最大許可リクエストレートを取得するための送信レートへ。リクエストが許可されている場合、送信者は、たとえばアイドル期間中に削減される前に、古い輻輳ウィンドウで基本的に再起動します。
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) リクエストを行う時期：TCP接続は、接続が渋滞イベントを経験する前、または少なくとも1つのRTOのアイドル期間の後にクイックスタートリクエストを行う場合があります。
(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) 応答クイックスタートパケットがドロップされている場合：クイックスタートパケットが接続の途中でドロップされた場合、送信者はクイックスタートウィンドウの半分、またはクイックがQuick-が使用された場合に送信者が使用していた輻輳ウィンドウに戻る必要があります。スタートリクエストは承認されていませんでした。
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.
以下は、両方のホストが最初のウィンドウを設定するためにクイックスタートを要求する場合の例のシナリオです。これは、セクション2.1の図1および2に似ています。ただし、クイックスタートリクエストを送信するTCPホストとのTCP接続を示しています。
* 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 DIFFを計算します。ホスト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 DIFF、レートリクエスト、およびQS NonCEを有効性のためにチェックします。それらが有効な場合は、最初の輻輳ウィンドウを適切にセットし、最初のウィンドウで使用するレートベースのペーシングをセットアップします。クイックスタート応答が有効でない場合は、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.
また、ホストAは、着信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 DIFF、レートリクエスト、および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は、IPSEC認証ヘッダーの整合性チェック値（ICV）を使用して、メッセージ認証と整合性の両方を検証します[RFC4302]。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オプションをAH ICV計算目的でゼロにする必要があるため、途中でクイックスタートIPオプションデータを変更しても、IPv4の既存のIPSEC AH実装に問題が発生しません。クイックスタートオプションが認識されている場合、可変IPv4オプションとして扱う必要があるため、AH ICVの計算目的で完全にゼロになります。IPv6オプション番号は、オプションが可変であるかどうかを明示的に示します。IANA-Allocatedオプションタイプの3番目に高い注文ビットには、クイックスタートオプションデータが途中で変更できることを示す値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 [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.
ディスカッションでは、先に定義されたTTL DIFFを使用して、IP TTLとクイックスタートTTL、MOD256の違いとして定義されています。ネットワークは、ネットワークを終了するパケットの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ヘッダーがパスに沿って中間点で追加および削除される場合があり、エンドポイントの参加を必要とせずにネットワークがトンネルを確立できるようにします。外側のヘッダーがトンネルエッセージで「単純なトンネル」として破棄されることを指定するトンネルを示し、「非シンプルなトンネル」として廃棄する前に出口が外側ヘッダーから情報を保存して使用するトンネルを示します。「非シンプルトンネル」の例は、ECNをサポートするように構成されたトンネルであり、出力ルーターは外側ヘッダーのECNコードポイントを内側ヘッダーにコピーしてから、外側ヘッダー[RFC3168]を破棄します。
__ 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'.
クイックスタートと互換性のあるトンネル：IPトンネル「クイックスタートと互換性がない」と言います。そのようなトンネルを介したクイックスタート要求を使用すると、TCP送信者がクイックが誤って信じていると誤っていると信じています。 - スタート要求は、パスに沿ったすべてのルーターによって承認されました。トンネル上でクイックスタートを使用しても、誤検知を引き起こさない場合、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つは、クイックスタートと互換性がないトンネルの発生を調査し、そのようなトンネルが時間の経過とともに変更される程度を追跡することです。クイックスタートと互換性がないトンネルからの誤検知の問題の評価は、実験的な標準から提案された標準へのクイックスタートの進行に影響し、実験モード中のクイックスタートの展開の程度に影響します。
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 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.
セキュリティの観点から、IPトンネルの外側ヘッダーでクイックスタートを使用すると、敵がトンネルエンドポイントを越えて伝播するクイックスタート情報を改ざんする可能性があるため、またはクイックスタートオプションのためにセキュリティ上の懸念が生じる可能性があります。情報をネットワークスキャナーに公開します。私たちのアプローチは、サポートクイックスタートをIPトンネルのオプションにすることです。つまり、クイックスタートを使用するリスクがその利点を上回ると判断される環境またはトンネリングプロトコルでは、トンネルは単にクイックスタートオプションを削除するか、カプセル化する前にクイックスタートレートリクエストとQS TTLフィールドをゼロにすることができます。その結果、IPトンネルがクイックスタートと互換性がある2つの実行可能なオプションがあります。最初のオプションは、上記の単純なトンネルとセクション6.1で、トンネルはクイックスタートと互換性がありますが、クイックスタートをサポートしていません。パスに沿ったクイックスタート要求はすべて拒否されます。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 DIFFが変更され、クイックスタートリクエストが拒否されます。単純なトンネルの場合、クイックスタートリクエストが外側のヘッダーにコピーされない場合が望ましいため、トンネル内のルーターがクイックスタートリクエストの不必要に処理されないようにします。ただし、クイックスタートリクエストは、クイックスタートリクエストが外側のヘッダーにコピーされるかどうかにかかわらず、この場合に正しく拒否されます。
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の値が拡張されたため、クイックスタートリクエストが誤って承認される可能性があります。送信者は変更されていません。たとえば、このようなシナリオは、スタックの衝突（ビット）、ネットワークドライバーと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クライアントがビット構造を使用している場合、クライアントとVPNゲートウェイの間のクイックスタート障害物はわかりません。クライアントとVPNゲートウェイの間のパスには、パスの最も混雑した部分が含まれている可能性が高いため、これは特定の問題です。ほとんどのVPNクライアントはビットを使用していると報告されているため[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.
Bump-in-the-Wire（BITW）は、暗号化が船外プロセッサで発生するIPSEC暗号化の実装で、ホストまたはルーター[RFC4301]からオーバーヘッドをオフロードします。BITWデバイスは通常、IPアドレス指定可能です。つまり、パケットがBITWに渡される前にIP TTLが減少します。QS TTLが減少しない場合、TTL DIFFの値が変更され、クイックスタートリクエストは拒否されます。ただし、BITWがホストをサポートし、独自のIPアドレスを持っていない場合、IP TTLはパケットがホストからBITWに渡される前に減少せず、偽陽性が発生する可能性があります。
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].
見る必要がある他のトンネルは、UDP上のIP上のIPやIPなどの非ネットワークプロトコル上のIPトンネル[RFC3948]、およびレイヤー2トンネリングプロトコル[RFC2661]を使用してトンネルです。
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.
トンネルイングレスノードがクイックスタートリクエストをローカルに承認することを選択した場合、イングレスノードは同時にクイックスタートTTLを減少させる必要があり、IP 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 TTLとクイックスタートオプションを外側のIPヘッダーから内側のヘッダーにコピーする必要があります。
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（インターネットキーエクスチェンジ）プロトコルを使用します。このドキュメントでは、クイックスタートとIPSECとIKEV1 [RFC2409]との相互作用を考慮しません。IKEV2 [RFC4306]のRFCが公開されたので、Quick-Startのサポートを交渉できるようにIPSECの変更を指定する予定です。この変更により、トンネルエンドポイント間の交渉が指定され、トンネル内でのクイックスタートのサポートを許可または禁止します。これは、IKEV1 [RFC3168、セクション9.2]を使用して、IPSECトンネルのECNに対して行われました。IPSECトンネルでのクイックスタート機能のこの交渉は、別のIPSECドキュメントで指定されます。このドキュメントには、クイックスタートフィールド（RFC 3168のセクション18および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- 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.
MPLSによるクイックスタートの動作は、IPトンネルでのクイックスタートの動作に似ています。IP TTLがMPLSパスを横断する一部として減少するMPLSパスの場合、これらのパスはクイックスタートと互換性がありますが、クイックスタートをサポートしていません。これらのパスを通過しているクイックスタートリクエストは、輸送送信者が拒否されたと正しく理解されます。MPLSパスのトラバースの一部としてIP TTLが減少しない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 NonCEフィールドをゼロにするか、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.
* クイックスタートは、適切な輻輳制御メカニズムを備えたユニキャスト輸送プロトコルにのみ指定されています。注：Quick-Startは、標準的な混雑制御手法の代替品ではなく、動作を強化することを目的としています。
* 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 DIFF、および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].
ルーターが最近承認されたリクエストから潜在的な帯域幅を追跡する簡単な方法は、2つのカウンターを維持することです。前の時間間隔[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つの往復時間（接続確立の往復時間を含む）を短縮する可能性があります。同様に、スロースタートフェーズが接続寿命のごく一部に過ぎなかった非常に大きな転送の場合、クイックスタートは限られた利点になります。クイックスタートは接続の寿命を大幅に短縮することはありませんが、起動フェーズを排除または短縮する可能性があります。ただし、十分にプロビジョニングされた環境で中程度のサイズの接続の場合、クイックスタートは、syn Exchangeの最初の往復時間の後）にMパケットの転送全体を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.
クイックスタートリクエストパケットを削除するコスト：以前に引用された測定研究[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つのリスクがあります。ルーターは、クイックスタートリクエストが大幅に十分に活用されていない場合にのみクイックスタートリクエストを承認することが期待されるため、これはありそうもない状況になるはずです。ただし、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.
ルーターのスローパス：クイックスタートのもう1つの欠点は、クイックスタートリクエストメッセージを含むパケットがルーターの高速パス、特にインターネットでのクイックスタートの展開の開始時には速いパスをとらない可能性があることです。これは、エンドホストの余分な遅延と、ルーターの追加の処理負担を意味します。ただし、セクション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レベルのルーターにないエンドツーエンドパスにキューとボトルネックが存在する可能性があることです。例として、これらにはレイヤーツーイーサネットまたはATMネットワークのキューが含まれます。1つの可能性は、このような非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.
クイックスタートリクエストの後、送信者がオーバーディングしてチートするインセンティブは何ですか？送信者の利益は、接続の完了時間などのパフォーマンスメトリックによって測定されていると仮定すると、時にはチートするために送信者の利益にある場合があります。場合によっては、送信者がチートすることが利益になるかどうかを判断することは難しいかもしれません。クイックスタートリクエストの後、送信者がオーバーシングしてチートするインセンティブは、クイックスタートがなければオーバーディングしてチートするインセンティブとそれほど違いはありません。 - スタートは、送信者がネットワーク内のポリシーからポリシングアクションを回避するのに役立ちます。承認された料金のレポートは、これに対処し、送信者がクイックスタートを使用して不正行為を「カバー」することを難しくするように設計されています。
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).
不正行為の1つの形式は、TTL DIFFとQS NonCEを誤って報告することにより、クイックスタート要求が承認されたかどうかについて、受信者が送信者にうそをつくことです。クイックスタートリクエストを理解しているルーターが要求を削除するか、QS TTLとQS nonCEをゼロにすることでリクエストを拒否した場合、レシーバーは、TTL diffの値を正常に推測することによってのみリクエストが承認されたかどうかについて「嘘をつく」ことができます。および報告するQs nonce。受信者がTTL DIFFの正しい値を正常に推測する可能性は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.
ただし、クイックスタートリクエストが非Quick-Start対応のルーター、またはQS TTLおよびQS NonCeフィールドをゼロにすることができないルーターによってのみ拒否された場合、レシーバーはクイックスタートのかどうかについて嘘をつくことができますリクエストは、同じホストから受け取った連続したリクエストでQS TTLを変更することにより承認されました。特に、送信者がクイックスタート要求に基づいて行動しない場合、TTL DIFFを計算する前にそのホストから受信した次のリクエストでQS TTLを1つずつ減らすことができ、次の2つでQS TTLを2つ減らすことができます送信者がクイックスタートリクエストのいずれかで動作するまで、リクエストを受信しました。
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 NonCeなどのメカニズムがない場合、レシーバーがクイックスタートリクエストでレポートする際にチートするインセンティブは何でしょうか？場合によっては、不正行為は受信者にとって明確な利益であり、その結果、転送の完了時間が短縮されます。他のケースでは、不正行為がネットワーク内でクイックスタートパケットがドロップされると、その特定のシナリオの詳細に応じて、不正行為が受信者のパフォーマンスメトリックを改善する場合と改善しない場合があります。
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.
受信者の不正行為の2番目の形式は、レートリクエストフィールドの値を増やすことにより、承認されたクイックスタート要求のレート要求について、受信者が送信者に嘘をつくことです。ただし、受信者は、送信者から送信された元のクイックスタートリクエストのレートリクエストを必ずしも知っているわけではなく、レシーバーによって報告されたより高いレートリクエストは、レートリクエストよりも高い場合にのみ送信者によって有効と見なされます元々送信者から要求されました。たとえば、送信者が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のレート要求を使用してクイックスタートリクエストを送信した場合、受信者はXの承認されたレートリクエストでクイックスタート要求を受信し、X <Y <= ZのYのレート要求を報告します。受信者は、QS Nonceの右端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.
レートリクエストの価値について嘘をついているレシーバーに対する保護の追加の可能な追加の形式があります。可能な追加の保護の1つは、クイックスタートリクエストでレートリクエストを減少させるルーターの場合、送信者に減少を直接報告します。ただし、これにより、単一のリクエストのために多くのレポートが送信者に戻る可能性があり、アドレススプーフィング攻撃でも使用できます。
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.
2番目の限られた形式の保護は、送信者が要求されたレートリクエストである程度のランダム化を使用することです。そのため、受信者はレートリクエストの元の値を推測することが困難です。ただし、これは困難です。これは、送信者が利用できるレートリクエストのセットにはかなり粗い粒度があり、初期リクエストをランダム化すると、いずれにせよ、限られた保護のみが提供されるためです。
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.
誤動作の受信機から保護することに加えて、不正行為のルーターから保護する必要があります。イングレスルーターと同じイントラネットに属する出口ルーターとの共謀を検討してください。Ingressルーターは、侵入時のレート要求を減らすことができ、出口ルーターは出口で再び増加します。減少したレートリクエストを承認した侵入と出口の間のルーターは、より大きな元の要求を承認する意思がなかったかもしれません。
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 NonCEの出力ルーターに通知することです。これにより、出力ルーターは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.
対照的に、クイックスタートとは、入り込みと出口ルーターの共謀が誤って承認されたと誤って見えるようにして、その共謀の対象となるトラフィックに有利になることがあり、時には不利な点を与えることがあります。シナリオの詳細について。パスに沿った一部のルーターにクイックスタートリクエストを承認するのに十分な利用可能な帯域幅が実際にない場合、ネットワークで誤って承認されたリクエストの結果として送信されたクイックスタートパケットは、接続の可能性のある不利な点に削除される可能性があります。したがって、イングレスと出口のルーターは、中間ルーターがクイックスタートリクエストを否定するのを防ぐために共謀することができますが、これが起こることは常に接続の利点になるとは限りません。このような共謀に対する1つの防御は、接続パフォーマンスを監視するリクエストを拒否したイングレスノードと出口ノードの間のルーター、クイックスタートリクエストが拒否された後にクイックスタートを使用していると思われる接続を罰する、またはそのルーターによって実際に承認されたものよりも高い承認率。
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- 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対応であり、共謀するイングレスと出口ルーターがECNキャピールやクイックスタートについて嘘をついている場合、その結果、クイックスタート要求が承認されたQuick-Startリクエストが誤って承認されたように見えます。、そしてクイックスタートパケットは、混雑したルーターに誤って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).
考えられる困難の1つは、ネットワーク内の他の種類の攻撃を阻止するためにIP TTLを書き直すトラフィックノーマイザー[HKP01]またはそのパスに沿った他のミドルボックスの難しさです。このようなトラフィックノーマライザーがIP TTLを書き直したが、クイックスタートTTLを同じ量だけ調整しなかった場合、パスに沿ったすべてのルーターによって要求が承認されたかどうかを判断するための送信者のメカニズムは、もはや信頼できなくなります。IP TTLを書き換えると、誤検知が誤って（クイックスタートリクエストが承認されたと誤って信じている）、誤ったネガ（Quick-Startリクエストが拒否されたと誤って信じている）が誤っている可能性があります。
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.
[SAF06]で説明したように、クイックスタートは2種類の攻撃に対して脆弱です：（1）ルーターの処理と状態負荷を増やすための攻撃、（2）偽のクイックスタートリクエストでの攻撃は、利用可能なクイックスタートを一時的に結び付けるためのクイックスタートリクエスト帯域幅、ルーターが他の接続からクイックスタート要求を承認するのを防ぎます。ルーターは、ルーターによってクイックスタートリクエストが考慮されるレートに単純な制限を適用することにより、最初の種類の攻撃から保護できます。
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.
利用可能なクイックスタート帯域幅を縛るための2番目の攻撃は、防御するのがより困難です。[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.
クイックスタートは、Srikanth SundarrajanによってNSシミュレーター[SH02]に追加され、Pasi Sarolahtiによって追加の機能が追加されました。検証テストは、NSの「TCL/TEST」ディレクトリの「すべてのキックスタート」にあります。[SH02]からの初期シミュレーション研究は、十分に活用されていない環境で中程度のサイズのフロー（4 kb〜128 kb）にクイックスタートを使用した大幅なパフォーマンス改善を示しています。これらの研究はファイル転送であり、改善はファイル転送の全体的なスループットの相対的な増加として測定されます。この研究は、クイックスタートからの潜在的な改善が、パスの遅延帯域幅積に比例することを示しています。
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.
1つの可能性は、プロトコルの実装により、アプリケーションがクイックスタートを要求する時期とリクエストを要求する時期を示す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.
クイックスタートを使用する場合、QS NonCEとTTL Diffをクイックスタートリクエストが送信したときにTTL DIFFを保存し、クイックスタートパケットのペース送信のための追加のタイマーを実装するためにTCP送信者が必要であることに注意してください。
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.
ルーターまたはその他のネットワークホストは、ホスト自体から発生したものを含む、入ってくるクイックスタートレート要求を処理するために、アウトバウンドネットワークインターフェイスの近似帯域幅を決定できる必要があります。1つの可能性は、ホストが構成情報に依存してリンク帯域幅を決定することです。これには、構成のエラーに堅牢ではないという欠点があります。もう1つの可能性は、ネットワークデバイスドライバーがインターフェイスの帯域幅を推測し、これを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.
* 中央に管理された組織イントラネット：これらのイントラネットは、多くの場合、ネットワークが多くの場合、ほとんどの間十分に活用されているネットワークを備えています[Pable 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]やその機能強化や次世代など、セルラーワイドアリアワイヤレスネットワークの高遅延環境でも役立ちます。たとえば、GPRS Edge（GSM Evolutionの拡張データ）は、最大384 kbpsのワイヤレス帯域幅（約32 1500バイトパケットあたりのパケット）を提供すると予想されますが、GPRSの往復時間は通常数百ミリ秒から数百ミリ秒まで範囲です。第二に、ネットワーク内の可能なキューイングの遅延を除外します[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.
* 衛星リンク上のパス：地球軌道（GEO）衛星リンクには、250 msのオーダーに一元配置伝播遅延があり、帯域幅は1秒あたりのメガビットで測定できます[RFC2488]。リンク上のかなりの帯域幅遅延製品のため、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パスで動作します。マルチアクセスリンクにlayer-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].
これまでのインターネットでのECNの展開率が氷河的に遅い[MAF05]を考えると、クイックスタートの展開問題の一部はECNの展開の問題よりもさらに大きいことに注意することは当惑しています。まず、ECNとは異なり、エンドツーエンドパスに沿ってルーターの1つにのみ展開されている場合でも有益になります。 - エンドのパス。第二に、IPヘッダーに割り当てられたフィールドを使用するECNとは異なり、クイックスタートにはIPオプションの余分な合併症が必要であり、現在のインターネットを通過するのが難しい場合があります[MAF05]。
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.
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-Routeが変更される可能性があることを示します。
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.
著者は、これらの問題の議論についてマーク・ハンドリーに感謝したいと考えています。著者はまた、この提案に関する肯定的および否定的なフィードバックの両方について、エンドツーエンドの研究グループ、Transport Services Working Group、およびIPAMの大規模通信ネットワークに関するプログラムのメンバーに感謝します。Srikanth Sundarrajanは、NSシミュレーターでのクイックスタートの最初の実装と初期シミュレーション調査について感謝します。クイックスタートとIPトンネルに関する広範なフィードバックをしてくれたDavid BlackとJoe Touchに感謝します。また、モハメッド・アシュラフ、ジョン・ボーダー、ボブ・ブリスコ、マーティン・デューク、トム・ダニガン、ミッチェル・エルブリッヒ、ゴーリー・フェアハースト、ジョン・ハイデマン、ポール・ハイダー、ディナ・カタビ、ヴァーン・パクソンにフィードバックに感謝します。承認された料金のレポートに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 Nonceのバージョンは、Guohan Lu [L05]の提案に基づいています。このドキュメントの以前のバージョンには、8ビットQs Nonceが含まれており、その後のバージョンでは、4ビットQs Nonceの可能性について説明しました。
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.
この文書は、[RFC3390]、[Aho98]、[RFC2415]、および[RFC3168]で説明されている概念に基づいています。トンネルのクイックスタートに関するテキストの一部は、RFC 3168から直接借用されました。
This document is the development of a proposal originally by Amit Jain for Initial Window Discovery.
このドキュメントは、最初にAmit Jainによる最初の窓発見のための提案の開発です。
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.
さらに、クイックスタートの評価には、ルーターからの明示的な情報を使用しないアプローチの相対的な利点、およびより大きな輻輳制御メカニズムの一部としてルーターからより微調整されたフィードバックを使用するアプローチの相対的な利点の議論を含める必要があります。以下のセクションで、いくつかのクラスの提案について説明します。
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]は、提案されたメカニズムは、一度に1つのフローによって行われた場合、ネットワーク利用、損失、または遅延の大幅な増加を引き起こさないと述べていますが、多くのフローによって同時に行われた場合、アプローチは問題になる可能性があります。[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.
Swift-Start：[Praks02]からのSwift Start Proposalは、パケットペアとパケットペースのテクニックを組み合わせています。4つのセグメントの初期輻輳ウィンドウを使用して、パスに沿って利用可能な帯域幅を推定します。次に、この推定値を使用して、データ送信の2番目の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で始まる可能性があります。パスとCWNDが既存のTCP接続を共有している場合、すでに高い輻輳ウィンドウを取得していた同じ宛先に存在します。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つは、トランスポート送信者が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) 明示的なフィードバックは、暗黙のフィードバックよりも信頼性が高くなります。暗黙の手法を使用して接続スタートアップで利用可能な帯域幅を評価しようとする手法は、ネットワークパスのすべての要素を含む手法よりもエラーが発生しやすいです。ネットワークからの明示的な情報は間違っている可能性がありますが、パス全体の「ブロックボックス」プロービング手法を使用して適切な送信レートを *推定 *しようとするエンドホストよりも、適切である可能性がはるかに高くなります。
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]が提案されているもう1つの可能性は、送信者がルーターからの明示的な許可なしで、帯域幅推定技術なしで大きな初期ウィンドウから開始することであり、サイズや送信などの情報を含む初期ウィンドウの最初のパケットが初期ウィンドウのレート。提案は、混雑したルーターが最初のデータパケットでこの情報を使用して、その最初のウィンドウから多くのパケットまたはすべてをドロップまたは遅延させるということです。このようにして、フローの楽観的に大きな初期ウィンドウでは、ルーターがネットワーク内の競合フローからパケットをドロップするように強制されません。このようなアプローチは、パスに沿ったルーターが大きな初期ウィンドウの最初のパケットをマークするメカニズムを理解するために、送信者に何らかのメカニズムを必要とするように思われます。
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) 増分展開：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) パケットがドロップされた場合、パフォーマンスがヒットします。4番目の問題は、最初のウィンドウの1つからパケットがドロップされたときに接続にヒットするパフォーマンスを定量化することです。
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オプション：関連作業では、[P00]は、TCP接続にわずかに異なるIPオプションの使用を調査して、パスに沿った利用可能な帯域幅を発見します。その提案では、IPオプションは、利用可能な最小のフリーバッファサイズについてパスに沿ったルーターをクエリします。また、TCP送信者がすでに往復時間の推定値を持っていた最初のSyn Exchangeの後にIPオプションが送信されていました。
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）には、送信者から受信機へのパスに沿ったルーターから情報を収集する単一のPTPパケットの提案が含まれています[W00]。たとえば、単一の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：ルーターから明示的な情報を収集するためのエンドノードの追加提案には、パスに沿った凝集渋滞統計のエンドポイントを通知する累積メカニズムを含む明示的な輸送エラー通知（ETEN）の1つのバリアントが含まれます[Kaps02]。（[KSEPA04]の2番目のバリアントは、ネットワークからの累積輻輳統計に依存しません。）
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からのパケットごとのフィードバックは正または負である可能性があり、このパケットが認められたときに送信者の輻輳ウィンドウの増加または減少を指定します。XCPはフルレッジの混雑制御スキームですが、クイックスタートは、ネットワークパスが大幅に十分に活用されているかどうかを判断するためのクイックチェックを表して、接続がより速く開始できるかどうかを判断し、TCPの標準輻輳制御アルゴリズムに戻ることができます。
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の提案は、パケットヘッダーの1つのビットで、ルーターが十分に活用されていないことを示すように設定できます。ANTI-ECNビットセットでパケットが受信されたことを示す送信者に到着する各TCP ACKについて、送信者はスロースタート中と同じように、1つのパケットで輻輳ウィンドウを増やすことができます。
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 NICE [V02]およびTCP低優先度（TCP-LP）[KK03]は、TCP接続がTCPおよびその他のトラフィックで使用されていない帯域幅を使用できるようにする目的で、ベスト以下のエフォルトTCPの2つの提案です。邪魔なファッション。TCP NICEと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のベスト以下のバリアントのいずれかとはまったく異なることに注意してください。これらの提案とは異なり、クイックスタートは、競合するベストエフォートのつながりと少なくとも帯域幅を受け取ることを望んでいる最高のエフォルトトラフィックに役立つことを目的としています。
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]、[RFC443]）またはRSVP [RFC2205]プロトコルを使用してクイックスタートリクエストの配信に使用できるかどうかを検討します。
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ヘッダーの上にあります。Quick-startは次のようにICMPで達成できます。ICMPプロトコルを使用してクイックスタートを実装する場合、Quick-Start IPオプションに相当するものがICMPクイックスタートリクエストのICMPヘッダーに掲載されます。ICMPクイックスタート要求は、おそらくIPルーターアラートオプション[RFC2113]を使用して、受信機へのパス上のルーターを通過する必要があります。クイックスタートリクエストを承認するルーターは、クイックスタートIPオプションの場合と同じアクションを実行し、パスをパスに沿って次のルーターに転送します。要求されたレートの値が減少しても、クイックスタートリクエストを承認しないルーターは、ICMPクイックスタートリクエストを削除し、リクエストが承認されていないことを送信者に送信者に送信します。ICMPの返信がネットワークで削除され、受信機に届かなかった場合、送信者は、レシーバーからのフィードバックがないことからリクエストが承認されていないことをまだ知っているでしょう。輻輳のためにネットワークでICMPのクイックスタート要求がドロップされた場合、送信者はリクエストが承認されていないと想定します。ICMPメッセージには、最後のノードで非gultiplexをするためのソースと宛先ポート番号が必要です。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.) 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を使用する利点の1つは、TCP Synパケットまたはその他の初期パケットの配信がルーターでのIPオプション処理によって遅延しないことです。より大きな利点は、ミドルボックスがクイックスタートリクエストでパケットをブロックしていた場合、別のICMPパケットでクイックスタート要求を使用すると、ミドルボックスの動作が接続全体に影響を与えないことを意味します。（IPクイックスタートオプションを使用してTCPを使用してMiddleboxにこの堅牢性を取得するには、TCP synパケットと同時に送信できるTCPレベルのクイックスタートリクエストパケットが必要です。）ICMPを使用するには、多くの欠点があります。一部のファイアウォールとミドルボックスは、ICMPクイックスタートリクエストパケットを転送しない場合があります。（ルーターから送信者へのICMP返信パケットがネットワークにドロップされた場合、送信者はリクエストが前述のように承認されていないことを依然として知っているので、これは問題のそれほど深刻ではありません。）IPトンネルの中央にあるルーターが、IPSEC ESPトンネルモード[RFC4301]のように、IPMPヘッダーが暗号化されている場合、ICMP応答パケットを実際のソースに配信するのが難しいでしょう。繰り返しになりますが、ICMPのReply Packetは、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オプションを使用する場合はそうではありません。
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]は、クイックスタートリクエストを実行するためのベアラープロトコルとして使用できます。ルーターは、通常のトランスポートプロトコルIPパケットよりもRSVPパケットをより広範囲に処理することが期待されるため、RSVPパケットを使用してクイックスタートレートリクエストを提供することは魅力的な選択のように思えます。ただし、RSVPを使用したクイックスタートには、RSVPの従来の使用といくつかの違いが必要です。クイックスタートは、クイックスタートではルーターの接続ごとの状態を必要としないため、定期的なソフト状態のリフレッシュを必要としません。クイックスタートリクエストは、RSVPパスメッセージの送信者からレシーバーに下流に送信されます。これは、予約がレシーバーから発生する従来のRSVPモデルとは異なります。さらに、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パスメッセージに新しい「クイックスタートリクエスト」クラスオブジェクトが含まれます。オブジェクトには、共通の長さと型フィールドに加えて、レート要求フィールドが含まれます。RSVP共通ヘッダーのSEND_TTLフィールドは、QS TTLフィールドに相当するものとして使用できます。パスに沿ったクイックスタート対応ルーターは、RSVPパスメッセージのクイックスタートリクエストオブジェクトを検査し、send_ttlを減少させ、必要に応じてレート要求フィールドを調整します。RSVPルーターがクイックスタートリクエストオブジェクトを理解していない場合、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トンネルはクイックスタートリクエストの処理に問題を引き起こす可能性があります。
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.
線形関数：可能な提案の1つは、レートリクエストフィールドを1秒あたりビットでフォーマットすることです。1つのユニットがM KBPSに等しく、Mの固定値がある場合、レート要求フィールドの値nについては、要求された料金は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の下限は、小さなパケットを送信する一部の非TCPフローにも役立ちます。最大で10ミリ秒ごとに1つの小さなパケットがあります。80 kbpsのレート要求は、1秒あたり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つの因子の粒度が粗すぎる場合、エンコード関数は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は、指数およびMantissaフィールドのバイナリ番号として、および0 <= F <1の場合、これはレート（1 f）*2^eを表します。[B05]は、8、16、または24ビットのFのMantissaフィールドを示唆しており、Eの指数フィールドは8ビットの指数フィールドです。この表現により、より大きなレートリクエストが可能になり、このドキュメントで使用されている2つのパワーエンコードよりも粗いエンコードが可能になります。
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になります。
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.
設計の質問の1つは、レートリクエストフィールドが1秒あたりのバイトであるか、1秒あたりのパケットであるかです。これについては、輸送の観点とルーターの観点からは別に説明します。
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パケットヘッダーのバイトは含まれません。他のトランスポートプロトコルは、1秒あたりパケットでクイックスタート要求を直接使用するか、クイックスタートリクエストをパケットの輻輳ウィンドウに変換する可能性があります。
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.
このドキュメントの仮定は、ルーターが出力リンクが大幅に活用されていない場合にのみクイックスタート要求を承認することです。このため、ルーターは、使用可能な帯域幅を1秒あたりバイトで測定したり、パケットとバイト間で何らかのメカニズムによって変換することもできます。
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.
クイックスタートリクエストが毎秒バイトで、データペイロードにのみ適用された場合、ルーターはデータペイロードの1秒あたりのバイトから、ワイヤ上のパケットの1秒あたりのバイトに変換する必要があります。レートリクエストフィールドが毎秒バイトで、送信者が非常に小さなパケットを使用している場合、これはワイヤ上の1秒あたりのバイトに関してかなり大きな数に変換される可能性があります。したがって、1秒あたりのバイトでのクイックスタートリクエストの場合、これがトランスポートヘッダーと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.
Routerは、SynパケットのTCPパケットヘッダーのMSSオプションからの情報を使用して、1秒あたりのパケットからのクイックスタートリクエストを1秒あたりのバイト、またはその逆に変換できることが示唆されています。これはいくつかの理由で問題があります。まず、IPSECを使用する場合、TCPヘッダーが暗号化されます。第二に、MSSオプションは、TCP送信者が受信すると予想する最大MSSとして定義されます。TCP送信者が[RFC793]を送信することを計画している最大MSSではなく、最大MSSではありません。ただし、この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]。毎秒バイトでのレート要求は、断片化に対してかなり堅牢です。明らかに、断片化の存在下では、1秒あたりのパケットのレート要求が堅牢性が低くなります。より大きな初期ウィンドウとパス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.
1秒あたりのバイトでのクイックスタートリクエストの場合、トランスポート送信者は、パケットヘッダーによって追加された帯域幅の使用を推定するための追加の合併症を抱えています。
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.
特にルーターに対してやや堅牢に思えるため、1秒あたりのパケットではなく、毎秒バイトでレートリクエストフィールドを選択しました。
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つの可能な関数として現在の送信率のレポートについて説明します。ただし、現時点ではこの可能性のある使用を標準化していません。
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では、初期ウィンドウでのクイックスタートパケットの喪失に対する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）/2のウィンドウからの混雑回避を継続することです。ここで、Wはクイックスタート輻輳ウィンドウであり、Dはそのウィンドウからドロップまたはマークされたパケットの数です。ただし、このようなアプローチは、そのウィンドウから他のパケットがネットワークにドロップされていても、配信されるクイックスタートパケットの数がそのフローに適切に利用可能な帯域幅を適切に示していることを暗黙的に想定します。さらに、正常に送信されたセグメントの半分を使用することは、不正確な輻輳ウィンドウの表示を説明するのに十分なほど保守的です。この時点で、特にルーターでさまざまなパケットドロップメカニズムを備えたネットワークでは、この時点でより多くの分析が必要になると考えており、現時点では推奨することはできません。
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.
最初のウィンドウのクイックスタートパケットがドロップされたときにスロースタートに戻らないアプローチのもう1つの欠点は、そのようなアプローチがTCPレシーバーにクイックスタートリクエストについて嘘をつくためのより大きなインセンティブを与える可能性があることです。最初のウィンドウでクイックスタートパケットが削除されたときに送信者がスロースタートに戻ると、これにより、レシーバーがクイックスタートリクエストから得られる利点が減少し、その結果、ドロップまたはECNマークのパケットが生じます。
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、AntECNなど）について説明します。
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などの提案については詳細に説明していませんが、多くの未解決の質問があることに注意してください。1つの質問は、インターネットでXCPなどのより洗練された混雑制御メカニズムの差し迫った必要性があるかどうかに関するものです。クイックスタートは、本質的に、高いリンク利用と低キューイング遅延を維持することに関する保証を提供しないかなり粗いツールです。Quick-Startは、かなり十分に活用されていない環境で使用するように設計されており、より高い送信率が許可されているかどうかの単一の質問に対処します。ルーターからのより細かいフィードバックを備えた新しい混雑制御メカニズムは、リンクの利用率がかなり高い環境でも、より速いスタートアップを可能にする可能性があります。これは差し迫った要件ですか？ルーターからのより微細に粒度の混雑制御フィードバックの他の利点は、差し迫った要件ですか？
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などのファイングレインパケットごとのフィードバックのクイックスタートと現在の提案の1つの違いは、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を取得する環境では、クイックスタートが問題になる可能性があります。たとえば、クイックスタートリクエストはパスAで移動している可能性があり、その後の往復時間で送信されたクイックスタートパケットの半分はパスBでルーティングされます。[ZDPS01]はインターネットパスが安定していることを示しています。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のバリアントについて説明しています。これは、この特定のパケット承認に応じて、送信者がスロースタートと同じくらい速く増加できることを示すために、ルーターからの単一のフィードバックを使用するANTI-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.
表3：クイックスタートと、微調整されたパケットごとのフィードバックの提案の違い。
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やその他の進行状況と組み合わせて、クイックスタートなどのメカニズムが、新しい混雑制御メカニズムのこれらのニーズのいくつかを満たすことに大きく貢献するかどうかに関係しています。これは、シンプルで合理的に展開可能なメカニズムで、より差し迫った現在のニーズのいくつかを満たすための肯定的なステップと見なすことができます。または、より根本的な変化を不必要に遅らせるという否定的なステップとして、交互に交互に見ることができます。この質問に答えることなく、私たち自身のアプローチは、単純なメカニズムが短期のハックではなく、全体的なアーキテクチャを根本的に正しい方向に導くメカニズムである限り、比較的単純なメカニズムの増分展開を支持する傾向があることに注意してください。
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 NonCEのNビットフィールドであり、送信者はクイックスタートリクエストを生成するときにランダムなNonCEを生成します。Rによるレート要求を減らす各ルーターは、MD5 [RFC1321]または安全なハッシュ1 [SHA1]などの一元配置ハッシュ関数を使用して、QS NonCe R Timesをハッシュします。受信者は、QS Nonceを送信者に返します。送信者は、NonCEの元の値と元のレートリクエストを知っているため、送信者はレートが低下したステップの総数を知っています。次に、送信者は元のNonCe s時間をハッシュして、結果が受信機によって返されたNonCEと同じかどうかを確認します。
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.
NonCEのこの代替提案は、セクション3.4で説明したQS NonCEよりもかなり強力ですが、クイックスタート要求を削減するときにルーターからより多くのCPUサイクルを必要とします。受信機。[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.
クイックスタートオプションの関数フィールドと予約済みフィールドの両方により、クイックスタートの拡張により、クイックスタート要求が必要に応じてクイックスタートのノンセの代替提案を使用できます。
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.
このドキュメントの以前のバージョンには、送信者が非ゼロの「ランダム」8ビット番号に初期化したリクエスト承認のクイックスタートNonCE（QS NonCE）と、同じに初期化されたQS TTLが含まれていました。IPヘッダーのTTLとしての値。リクエストが承認したクイックスタートのノンセは、クイックスタート応答でトランスポートレシーバーによって輸送送信者に返されていました。ルーターは、QS TTLフィールドの削減、QS NonCeフィールドのゼロ、またはパケットヘッダーからクイックスタートリクエストを削除することにより、QS TTLフィールドの削減に失敗することにより、クイックスタートリクエストを拒否できます。QS NonCeは、壊れたダウンストリームルーター、またはレートリクエストが承認されたかどうかについて嘘をつく可能性のあるTCPレシーバーの誤動作に対する保護を提供するために含まれていました。この保護は現在、QS NonCeによって、QS TTLフィールドのランダムな初期値の使用、およびクイックスタート対応のルーターによって提供されます。彼らは要求を否定します。
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.
古いリクエストが承認したクイックスタートNONCEと、IPヘッダーのTTLフィールドと同じ値に設定されたQS TTLフィールドにより、クイックスタートリクエストメカニズムは自己終了していたでしょう。クイックスタートリクエストは、パスで参加していないルーターが遭遇した後、最初の参加ルーターで終了します。これにより、クイックスタートリクエストのオプション処理により、ルーターが発生する不必要なオーバーヘッドが最小限に抑えられます。現在の仕様では、この「自己終了」プロパティは、クイックスタート対象ルーターによって提供されます。現在の仕様ではQS TTLのランダムな初期値を使用するため、クイックスタートリクエストが上流ではないため、クイックスタートリクエストが無効であるかどうかはわかりません。これは、レシーバーがQS TTLの値についてcheteするのを難しくするデザインを使用するコストです。
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では、アプリケーションには輻輳制御メカニズムの選択肢があり、現在指定されている混雑制御識別子（CCID）は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を使用してクイックスタートを使用することを検討する際に、次の質問が生じます。
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.
TCPと同様に、最初のクイックスタートパケットが削除された場合、CCID 3送信者は、クイックスタートリクエストが承認されていない場合に使用していた混雑制御メカニズムに戻す必要があります。
(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.
TCPとは異なり、CCID 3は、すべてのパケットまたは他のすべてのパケットに謝辞を使用しません。対照的に、CCID 3レシーバーは、ラウンドトリップ時間ごとにほぼ1回送信者にフィードバックを送信します。CCID 3では、少なくとも4回の往復時間でレシーバーからフィードバックが受信されない場合（送信者が2回の往復時間ごとに少なくとも1つのパケットを送信している場合）、許可された送信率は半分になります。クイックスタートリクエストが使用される場合、少なくとも2回の往復時間に受信機からフィードバックが届かない場合、送信率を下げるために、時間間隔を短縮する必要があるように思われます。
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.
TCPと同様に、CCID 3送信者がアイドル期間後に高い送信率を要求する際に使用すべきレート要求に対する簡単な回答があります。送信者は、独自の計算または受信機からのフィードバックから、現在の損失イベント率を知っており、その損失イベント率で許可された送信率を決定できます。これは、CCID 3送信者が要求する必要がある送信率の上限です。クイックスタートリクエストは、標準操作では、CCID 3が受信者が受信した報告の2倍以上の速度で送信することを許可しないため、送信者がアイドルまたは十分に活用されていない期間から出てくる場合にCCID 3で役立ちます。最新のフィードバックメッセージ。
(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.
初期送信率の場合と同様に、少なくとも2回の往復時間に受信機からフィードバックが受信されない場合、送信率を下げることは慎重に思えます。この場合、クイックスタートリクエストが承認されていなかった場合に使用される送信率に送信率を減らす必要があるようです。
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).
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 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.
次に、着信クイックスタートレートリクエストを処理するための「ターゲット」アルゴリズムを定義します（[SAF06]からも）。アルゴリズムは、発信リンクの帯域幅（多くの場合、簡単に構成できます）、発信リンク（上記のような推定手法から）の使用率、および最近の潜在的な帯域幅の推定を知ることに依存しています。クイックスタートの承認。
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.
割り当てられたクイックスタート帯域幅を緊密に追跡したいルーターは、承認されたレートレポートを使用して、ネットワーク内でレートリクエストが下流に減少したときに学習することができます。
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.
現在の送信レートのレポート：関数フィールドの「電流送信レートのレポート」コードポイントセットを使用したクイックスタートリクエストは、レート要求フィールドを使用して、その接続の現在の推定送信レートを報告します。これは、クイックスタートを使用して現在の送信率を上げる接続に対して、標準レートリクエストを含む同じパケットで2回目のクイックスタートリクエストに付随する可能性があります。
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をレートリクエストを送信したときに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.
情報リクエスト：関数フィールドの情報リクエストCodePointは、リクエストが純粋に情報提供であることを示しています。たとえば、情報リクエストは、標準のクイックスタートリクエストを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 Do Do De Do Do De Do Do De Do Do CodePointは、ネットワークでレートリクエストを減少させるよりも、送信者がリクエストを拒否するクイックスタートリクエストに使用できます。これは、送信者が元のレートリクエストが承認された場合にのみクイックスタートの使用に関心がある場合に使用できます。
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.
一時的な帯域幅の使用：接続が要求された帯域幅を1回の時間間隔でのみ使用することを示すために、一時的なコードポイントが提案されています。
Normative References
引用文献
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、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] Allman、M.、Paxson、V。、およびW. Stevens、「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.
[RFC3168] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, October 2002.
[RFC3390] Allman、M.、Floyd、S。、およびC. Partridge、「TCPの初期ウィンドウの増加」、RFC 3390、2002年10月。
[RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large Congestion Windows", RFC 3742, March 2004.
[RFC3742] Floyd、S。、「大規模な輻輳窓を備えたTCPの限定スロースタート」、RFC 3742、2004年3月。
Informative References
参考引用
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC792] Postel、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] Baker、F.、ed。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003] Perkins、C。、「IP内のIPカプセル化」、RFC 2003、1996年10月。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113] Katz、D。、「IPルーターアラートオプション」、RFC 2113、1997年2月。
[RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, April 1997.
[RFC2140] Touch、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] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins、D。およびD. Carrel、「The Internet Key Exchange（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. Nichols、「初期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] Allman、M.、Glover、D。、およびL. Sanchez、「標準メカニズムを使用した衛星チャネル上のTCPの強化」、BCP 28、RFC 2488、1999年1月。
[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.、Valencia、A.、Rubens、A.、Pall、G.、Zorn、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] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「Generic Routing Cancapstulation（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] Stewart、R.、Xie、Q.、Morneault、K.、Sharp、C.、Schwarzbauer、H.、Taylor、T.、Rytina、I.、Kalla、M.、Zhang、L。、およびV。Paxson、「Stream Control Transmission Protocol」、RFC 2960、2000年10月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC 3124, June 2001.
[RFC3124] Balakrishnan、H。およびS. Seshan、「ザ・ミッシェンマネージャー」、RFC 3124、2001年6月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]大工、B。およびS.ブリム、「ミドルボックス：分類法と問題」、RFC 3234、2002年2月。
[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344] Perkins、C.、ed。、「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] Floyd、S。、「大渋滞窓用の高速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] Bless、R.、Nichols、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.、Conta、A.、Carpenter、B。、およびS. Deering、「IPv6フローラベル仕様」、RFC 3697、2004年3月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、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] Karn、P.、Bormann、C.、Fairhurst、G.、Grossman、D.、Ludwig、R.、Mahdavi、J.、Montenegro、G.、Touch、J.、およびL. Wood、「アドバイス」アドバイスインターネットサブネットワークデザイナー向け」、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.、Volpe、V.、Diburro、L。、およびM. Stenberg、「IPSEC ESPパケットのUDPカプセル化」、RFC 3948、2005年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagramうっ血制御プロトコル（DCCP）」、RFC 4340、2006年3月。
[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] Floyd、S。およびE. Kohler、「データグラムの混雑制御プロトコルのプロファイル（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] Conta、A.、Deering、S。、およびM. Gupta、「インターネットプロトコルバージョン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. Allman、C。HayesおよびS. Ostermann。より大きな初期ウィンドウを持つ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] Briscoe、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. BrasheおよびB. Walke。新しいGSMフェーズ2一般パケットラジオサービスの概念、サービス、およびプロトコル。IEEE Communications Magazine、ページ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。Aalto、およびM. Raitola。GPRSネットワークでのマルチレイヤープロトコルトレース。2002年9月、カナダ、バンクーバーのIEEE車両技術会議（Fall VTC2002）の議事録。
[H05] P. Hoffman, email, October 2005. Citation for acknowledgement purposes only.
[H05] P. Hoffman、電子メール、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. Handley、C。KreibichおよびV. Paxson、ネットワーク侵入検出：回避、トラフィック正規化、およびエンドツーエンドプロトコルセマンティクス、Proc。Usenix Security Symposium 2001。
[Jac88] V. Jacobson, Congestion Avoidance and Control, ACM SIGCOMM.
[Jac88] V.ジェイコブソン、混雑回避と制御、ACM Sigcomm。
[JD02] Manish Jain, Constantinos Dovrolis, End-to-End Available Bandwidth: Measurement Methodology, Dynamics, and Relation with TCP Throughput, SIGCOMM 2002.
[JD02]マニッシュ・ジャイン、コンスタンティノス・ドヴロリス、エンドツーエンド利用可能帯域幅：測定方法、ダイナミクス、および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 Marking：高帯域幅遅延接続のためのマーキングスキーム」、Proceedings、IEEE ICC '03、2003年5月。
[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] Rajesh Krishnan、Mark Allman、Craig Partridge、James P.G.ステルベンツ。エラーが発生しやすいワイヤレスおよび衛星ネットワークの明示的な輸送エラー通知（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] Dina Katabi、Mark Handley、およびCharles 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. Knightly。TCP-LP：優先度の低いデータ転送のための分散アルゴリズム。Infocom 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] Rajesh Krishnan、James Sterbenz、Wesley Eddy、Craig Partridge、Mark Allman。エラーが発生しやすいワイヤレスおよび衛星ネットワークの明示的な輸送エラー通知（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 Lu、TCPクイックスタートのNonce、2005年9月。
[MH06] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", Work in Progress, December 2006.
[MH06] Mathis、M。およびJ. Heffner、「Packetization Layer Path MTU Discovery」、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] Alberto Medina、Mark Allman、およびSally Floyd、輸送プロトコルとミドルボックス間の相互作用の測定、2004年8月、インターネット測定会議2004年。<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接続の帯域幅の発見、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.
[Pable 05] Ruoming Pang、Mark Allman、Mike Bennett、Jason Lee、Vern Paxson、Brian Tierney。現代のエンタープライズトラフィックの最初の外観。ACM Sigcomm/Usenix Internet Measurement Conference、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] Craig Partridge、Dennis Rockwell、Mark Allman、Rajesh Krishnan、James P.G.ステルベンツ。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] Mattia RossiとMichael Welzlは、IPオプション処理の影響に関する、Preprint -reihe des Fachbereichs Mathematik、No。15、Institute of Computer Science、Institute of Computer Science、University of Innsbruck、オーストリア、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] Mattia RossiとMichael Welzl、IPオプション処理の影響 - パート2、Preprint -reihe des Fachbereichs Mathematik -No. 26、Institute of Computer Science、Institute of Innsbruck、オーストリア、2004年7月。
[S02] Ion Stoica, private communication, 2002. Citation for acknowledgement purposes only.
[S02] Ion Stoica、Private Communication、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] Pasi Sarolahti、Mark Allman、およびSally Floyd。十分に活用されていないネットワークパスで適切な送信率を決定します。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] Singh、M.、Guha、S。、およびP. Francis、「スペアネットワーク帯域幅を利用してTCPパフォーマンスを向上させる」、ACM Sigcomm 2005 Proguntion in Proguntion Session、<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]「Secure Hash Standard」、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] Srikanth SundarrajanとJohn 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. Dahlin。TCP NICE：バックグラウンド転送のメカニズム。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、IDLE 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] Michael Welzl：PTP：インターネット上の適応分散マルチメディアアプリケーションのためのより良いフィードバック、IPCCC 2000（19th IEEE International Performance、Computing、およびCommunications Conference）、フェニックス、アリゾナ、2000年2月。/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. Zhang、N。Duffield、V。Paxson、およびS. Shenker、インターネットパスプロパティの恒常性について、Proc。ACM Sigcomm Internet Measurement Workshop、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. Zhang、L。Qiu、および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/
Sally Floyd Phone：1（510）666-2989 ICIR（ICSI Center for Internet Research）メール：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バークレー、カリフォルニア州94704-1198電話：（440）235-1792メール：mallman@icir.org url：http：//www.icir.org/mallman/
Amit Jain F5 Networks EMail: a.jain@f5.com
Amit Jain F5 Networks Email：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
Pasi Sarolahti Nokia Research Center P.O.Box 407 FI-00045 Nokia Group Finland電話：358 50 4876607メール：pasi.sarolahti@iki.fi
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。