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
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）IETF信托基金（2007年）。
Abstract
摘要
This document specifies an optional Quick-Start mechanism for transport protocols, in cooperation with routers, to determine an allowed sending rate at the start and, at times, in the middle of a data transfer (e.g., after an idle period). While Quick-Start is designed to be used by a range of transport protocols, in this document we only specify its use with TCP. Quick-Start is designed to allow connections to use higher sending rates when there is significant unused bandwidth along the path, and the sender and all of the routers along the path approve the Quick-Start Request.
该文档指定了与路由器协作的传输协议的可选快速启动机制，以确定在开始和有时在数据传输的中间（例如，在空闲周期之后）允许的发送速率。虽然Quick Start设计用于一系列传输协议，但在本文档中，我们仅指定它与TCP的配合使用。“快速启动”旨在允许连接在路径上有大量未使用的带宽时使用更高的发送速率，并且发送方和路径上的所有路由器都批准“快速启动”请求。
This document describes many paths where Quick-Start Requests would not be approved. These paths include all paths containing routers, IP tunnels, MPLS paths, and the like that do not support Quick-Start. These paths also include paths with routers or middleboxes that drop packets containing IP options. Quick-Start Requests could be difficult to approve over paths that include multi-access layer-two networks. This document also describes environments where the Quick-Start process could fail with false positives, with the sender incorrectly assuming that the Quick-Start Request had been approved by all of the routers along the path. As a result of these concerns, and as a result of the difficulties and seeming absence of motivation for routers, such as core routers to deploy Quick-Start, Quick-Start is being proposed as a mechanism that could be of use in controlled
本文档描述了许多无法批准快速启动请求的路径。这些路径包括包含不支持快速启动的路由器、IP隧道、MPLS路径等的所有路径。这些路径还包括带有路由器或中间盒的路径，这些路由器或中间盒丢弃包含IP选项的数据包。快速启动请求可能难以通过包含多访问层二网络的路径进行批准。本文档还描述了快速启动过程可能因误报而失败的环境，发送方错误地认为快速启动请求已被路径上的所有路由器批准。由于这些担忧，以及路由器（如核心路由器）部署快速启动的困难和缺乏动机，快速启动被提议作为一种机制，可用于受控环境
environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet.
环境，而不是作为一种机制，旨在或适合在全球互联网上无处不在的部署。
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
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
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）的一到四个段之间（[RFC2581]，[RFC3390]）。然后，TCP连接使用慢启动过程（[Jac88]，[RFC2581]）探测网络的可用带宽，在每个无拥塞往返时间（RTT）期间将cwnd加倍。
The slow-start algorithm can be time-consuming --- especially over
networks with large bandwidth or long delays. It may take a number
of RTTs in slow-start before the TCP connection begins to fully use
the available bandwidth of the network. For instance, it takes
log_2(N) - 2 round-trip times to build cwnd up to N segments,
assuming an initial congestion window of 4 segments. This time in
slow-start is not a problem for large file transfers, where the
slow-start stage is only a fraction of the total transfer time.
However, in the case of moderate-sized transfers, the connection
might carry out its entire transfer in the slow-start phase, taking
many round-trip times, where one or two RTTs might have been
sufficient when using the currently available bandwidth along the
path.
The slow-start algorithm can be time-consuming --- especially over
networks with large bandwidth or long delays. It may take a number
of RTTs in slow-start before the TCP connection begins to fully use
the available bandwidth of the network. For instance, it takes
log_2(N) - 2 round-trip times to build cwnd up to N segments,
assuming an initial congestion window of 4 segments. This time in
slow-start is not a problem for large file transfers, where the
slow-start stage is only a fraction of the total transfer time.
However, in the case of moderate-sized transfers, the connection
might carry out its entire transfer in the slow-start phase, taking
many round-trip times, where one or two RTTs might have been
sufficient when using the currently available bandwidth along the
path.
A fair amount of work has already been done to address the issue of choosing the initial congestion window for TCP, with RFC 3390 allowing an initial window of up to four segments based on the MSS used by the connection [RFC3390]. Our underlying premise is that explicit feedback from all the routers along the path would be required, in the current architecture, for best-effort connections to use initial windows significantly larger than those allowed by [RFC3390], in the absence of other information about the path.
已经做了大量工作来解决选择TCP初始拥塞窗口的问题，RFC 3390允许基于连接使用的MSS的最多四个段的初始窗口[RFC3390]。我们的基本前提是，在当前的体系结构中，在没有关于路径的其他信息的情况下，需要路径上所有路由器的明确反馈，以便尽最大努力连接使用比[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
在使用快速启动时，TCP主机（例如主机a）将使用TCP数据包IP报头中的快速启动选项，以字节/秒为单位指示其所需的发送速率。路径上的每个路由器可以依次批准请求的速率、降低请求的速率或指示快速启动请求未被批准。（我们注意到，本文件中提到的“路由器”还包括在发送方对快速启动请求的IP层处理。）在批准快速启动请求时，路由器不会优先处理来自该连接的后续数据包；路由器只是声称它目前未被充分利用，并且认为有足够的可用带宽来容纳发送者的请求
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主机B在应答TCP数据包的传输级快速启动响应中将最终速率请求传送给TCP主机A。
If the Quick-Start Request is approved by all routers along the path, then the TCP host can send at up to the approved rate for a window of data. Subsequent transmissions will be governed by the default TCP congestion control mechanisms of that connection. If the Quick-Start Request is not approved, then the sender would use the default congestion control mechanisms.
如果路径上的所有路由器都批准了快速启动请求，则TCP主机可以按照批准的速率发送数据窗口。后续传输将由该连接的默认TCP拥塞控制机制控制。如果快速启动请求未被批准，则发送方将使用默认的拥塞控制机制。
Quick-Start would not be the first mechanism for explicit communication from routers to transport protocols about sending rates. Explicit Congestion Notification (ECN) gives explicit congestion control feedback from routers to transport protocols, based on the router detecting congestion before buffer overflow [RFC3168]. In contrast, routers would not use Quick-Start to give congestion information, but instead would use Quick-Start as an optional mechanism to give permission to transport protocols to use higher sending rates, based on the ability of all the routers along the path to determine if their respective output links are significantly underutilized.
快速启动并不是路由器与传输协议之间关于发送速率的显式通信的第一种机制。显式拥塞通知（ECN）根据路由器在缓冲区溢出之前检测到的拥塞，给出从路由器到传输协议的显式拥塞控制反馈[RFC3168]。相反，路由器不会使用快速启动来提供拥塞信息，而是将快速启动作为一种可选机制，根据路径上所有路由器确定其各自的输出链路是否明显未充分利用的能力，允许传输协议使用更高的发送速率。
Section 2 gives an overview of Quick-Start. The formal specifications for Quick-Start are contained in Sections 3, 4, 6.1.1, and 6.3. In particular, Quick-Start is specified for IPv4 and for IPv6 in Section 3, and is specified for TCP in Section 4. Section 6 consists mostly of a non-normative discussion of interactions of Quick-Start with IP tunnels and MPLS; however, Section 6.1.1 and 6.3 specify behavior for IP tunnels that are aware of Quick-Start.
第2节概述了快速入门。快速启动的正式规范包含在第3、4、6.1.1和6.3节中。特别是，第3节为IPv4和IPv6指定了快速启动，第4节为TCP指定了快速启动。第6节主要讨论了快速启动与IP隧道和MPLS之间的交互作用；但是，第6.1.1和6.3节规定了了解快速启动的IP隧道的行为。
The rest of the document is non-normative, as follows. Section 5 shows that Quick-Start is compatible with IPsec AH (Authentication Header). Section 7 gives a non-normative set of guidelines for specifying Quick-Start in other transport protocols, and Section 8 discusses using Quick-Start in transport end-nodes and routers. Section 9 gives an evaluation of the costs and benefits of Quick-Start, and Section 10 discusses implementation and deployment issues. The appendices discuss related work, Quick-Start design decisions, and possible router algorithms.
本文件其余部分为非规范性文件，如下所示。第5节说明了Quick Start与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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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.
* 连接的两个方向上的数据传输穿过不同的队列，甚至可能是不同的路由器。因此，任何用于确定允许发送速率的机制都必须针对每个方向单独使用。
* 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.
* 两个端点之间的路径相对稳定，因此快速启动请求使用的路径通常与一次往返后快速启动数据包使用的路径相同。[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报头中的快速启动响应选项向发送方发送反馈。此外，Quick Start采用单播、拥塞控制传输协议；我们不考虑使用快速启动多播流量。
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.
当作为请求发送时，快速启动选项包括一个以比特/秒为单位的发送速率的请求，以及一个快速启动生存时间（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发送方。在本例中，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. -->
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显示了快速启动的不成功使用，路径上的一个路由器没有批准快速启动请求。如果快速启动请求未被批准，则发送方使用该传输协议的默认拥塞控制机制，包括默认初始拥塞窗口、对空闲时间的响应等。
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. -->
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
第一个字节包含选项字段，其中包括一位复制标志、2位类字段和5位选项号。
The second byte contains the length field, indicating an option length of eight bytes.
第二个字节包含长度字段，表示八个字节的选项长度。
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.
第三个字节包括一个四位函数字段。如果功能字段设置为“0000”，则快速启动选项为费率请求。在这种情况下，第三个字节的后半部分是一个四位速率请求字段。
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.
对于速率请求，第四个字节包含快速启动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差异、IP TTL值和QS TTL值之间的差异，如下所示：
TTL Diff = ( IP TTL - QS TTL ) mod 256 (1)
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.
对于速率请求，字节5-8包含第3.4节中讨论的30位QS Nonce和两位保留字段。发送方应将保留字段设置为零，路由器和接收方应忽略保留字段。发送方应将30位QS Nonce设置为随机值。
The sender initializes the Rate Request to the desired sending rate, including an estimate of the transport and IP header overhead. The encoding function for the Rate Request sets the request rate to K*2^N bps (bits per second), for N the value in the Rate Request field, and for K set to 40,000. For N=0, the rate request would be set to zero, regardless of the encoding function. This is illustrated in Table 1 below. For the four-bit Rate Request field, the request range is from 80 Kbps to 1.3 Gbps. Alternate encodings that were considered for the Rate Request are given in Appendix B.2.
发送方将速率请求初始化为所需的发送速率，包括对传输和IP报头开销的估计。速率请求的编码功能将请求速率设置为K*2^N bps（比特/秒），速率请求字段中的值为N，K设置为40000。对于N=0，无论编码函数如何，速率请求都将设置为零。下文表1对此进行了说明。对于四位速率请求字段，请求范围为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
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
如果快速启动选项第三个字节中的功能字段设置为“1000”，则快速启动选项为批准费率的报告。在这种情况下，第三字节中的第二个四位是速率报告字段，格式与速率请求中的速率请求字段完全相同。对于批准速率的报告，不使用快速启动选项的第四个字节。字节5-8包含30位QS Nonce和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当前值。或者，一些使用核准速率报告的路由器可以选择将被核准速率掩盖的QS Nonce与原始请求中看到的QS Nonce相匹配。
If the Rate Request is denied, the sender MUST send a Report of Approved Rate with the Rate Report field set to zero.
如果费率请求被拒绝，发件人必须发送一份费率报告字段设置为零的已批准费率报告。
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格式相同，但长度字段应排除选项格式中的常见类型和长度字段，并设置为6字节而不是8字节。
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差异（IPv6中的跃点限制相当于IPv4中的TTL）。也就是说，必须按如下方式计算和存储TTL差异：
TTL Diff = ( IPv6 Hop Limit - QS TTL ) mod 256 (2)
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不同，修改或删除快速启动IPv6选项不需要重新计算校验和，因为IPv6标头没有校验和字段，并且修改IPv6逐跳选项标头中的快速启动请求不会影响上层校验和计算中使用的IPv6伪标头校验和。
Appendix A of RFC 2460 requires that all packets with the same flow label must be originated with the same hop-by-hop header contents, which would be incompatible with Quick-Start. However, a later IPv6 flow label specification [RFC3697] updates the use of flow labels in IPv6 and removes this restriction. Therefore, Quick-Start is compatible with the current IPv6 specifications.
RFC 2460的附录A要求具有相同流标签的所有数据包必须使用相同的逐跳标头内容发起，这与快速启动不兼容。但是，更高版本的IPv6流标签规范[RFC3697]更新了IPv6中流标签的使用，并删除了此限制。因此，Quick Start与当前的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类似，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和Rate请求字段归零。“删除速率”选项可以节省更多的资源，因为“删除速率”选项可以使路由器在执行“快速启动”过程时不会节省更多的资源。如[B05]中所述，快速启动的未来添加内容可能会定义路由器的错误代码，以插入QS Nonce字段，向发送方报告快速启动请求被拒绝的原因，例如，路由器此时拒绝所有快速启动请求，或者根据策略，此路由器，不允许快速启动请求。不了解快速启动选项的路由器只需在快速启动请求不变的情况下转发数据包（确保TTL差异不匹配且不使用快速启动）。
If the participating router has decided to approve the Quick-Start Request, it does the following:
如果参与路由器已决定批准快速启动请求，它将执行以下操作：
* The router MUST decrement the QS TTL by the amount the IP TTL is decremented (usually one).
* 路由器必须将QS TTL减少IP 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.
对于速率请求，路由器还必须修改QS Nonce，如第3.4节所述。
* 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
如果快速启动选项的功能字段设置为“1000”，则这是已批准费率的报告，而不是费率请求。路由器可以忽略该选项，并且在任何情况下，不得修改批准费率报告的选项内容。但是，路由器可以使用批准的费率报告来检查发送方是否对批准的费率撒谎。如果报告的批准速率高于路由器在前一个往返时间内实际批准此连接的速率，则路由器可能会针对作弊者实施某些策略。例如，路由器可决定拒绝来自该发送者的未来快速启动请求，包括，如果需要，从来自该发送者的未来分组中删除快速启动请求。第9.4.1节讨论了不当行为
senders in more detail. From the Report of Approved Rate, the router can also learn if some of the downstream routers have approved the Quick-Start Request for a smaller rate or denied the use of Quick-Start, and adjust its bandwidth allocations accordingly.
更详细地介绍发件人。从已批准速率的报告中，路由器还可以了解一些下游路由器是否已批准较小速率的快速启动请求或拒绝使用快速启动，并相应地调整其带宽分配。
The QS Nonce gives the Quick-Start sender some protection against receivers lying about the value of the received Rate Request. This is particularly important if the receiver knows the original value of the Rate Request (e.g., when the sender always requests the same value, and the receiver has a long history of communication with that sender). Without the QS Nonce, there is nothing to prevent the receiver from reporting back to the sender a Rate Request of K, when the received Rate Request was, in fact, less than K.
QS 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
Bits Purpose
--------- ------------------
Bits 0-1: Rate 15 -> Rate 14
Bits 2-3: Rate 14 -> Rate 13
Bits 4-5: Rate 13 -> Rate 12
Bits 6-7: Rate 12 -> Rate 11
Bits 8-9: Rate 11 -> Rate 10
Bits 10-11: Rate 10 -> Rate 9
Bits 12-13: Rate 9 -> Rate 8
Bits 14-15: Rate 8 -> Rate 7
Bits 16-17: Rate 7 -> Rate 6
Bits 18-19: Rate 6 -> Rate 5
Bits 20-21: Rate 5 -> Rate 4
Bits 22-23: Rate 4 -> Rate 3
Bits 24-25: Rate 3 -> Rate 2
Bits 26-27: Rate 2 -> Rate 1
Bits 28-29: Rate 1 -> Rate 0
Table 2: The QS Nonce.
表2:QS当前值。
The transport sender MUST initialize the QS Nonce to a random value. If the router reduces the Rate Request from rate K to rate K-1, then the router MUST set the field in the QS Nonce for "Rate K -> Rate K-1" to a new random value. Similarly, if the router reduces the Rate Request by N steps, the router MUST set the 2N bits in the relevant fields in the QS Nonce to a new random value. The receiver MUST report the QS Nonce back to the sender.
传输发送方必须将QS Nonce初始化为随机值。如果路由器将速率请求从速率K降低到速率K-1，那么路由器必须将QS Nonce中“速率K->速率K-1”的字段设置为新的随机值。类似地，如果路由器将速率请求减少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的几率在速率请求的每一步变化上作弊。因此，如果速率请求在网络中减少两个步骤，则接收器有1/16的机会成功报告原始请求已被批准，因为这需要报告QS nonce的原始值。类似地，如果速率请求在网络中减少了许多步骤，并且接收机接收到速率请求为K的QS选项，则接收机有1/16的机会猜测QS当前“速率K+2->速率K+1”和“速率K+1->速率K”字段的原始值。因此，接收器有1/16的机会成功说谎并说接收到的速率请求是K+2而不是K。
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提供的保护都是相同的。
The requirements for randomization for the sender and routers in setting `random' values in the QS Nonce are not stringent -- almost any form of pseudo-random numbers will do. The requirement is that the original value for the QS Nonce is not easily predictable by the receiver, and in particular, the nonce MUST NOT be easily determined from inspection of the rest of the packet or from previous packets. In particular, the nonce MUST NOT be based only on a combination of specific packet header fields. Thus, if two bits of the QS Nonce are changed by a router along the path, the receiver should not be able to guess those two bits from the other 28 bits in the QS Nonce.
发送方和路由器在QS时刻设置“随机”值时的随机化要求并不严格——几乎任何形式的伪随机数都可以。要求是接收机不容易预测QS Nonce的原始值，特别是，不容易通过检查数据包的其余部分或以前的数据包来确定Nonce。特别地，nonce不能仅基于特定分组报头字段的组合。因此，如果路由器沿路径改变QS Nonce的两位，则接收机不应该能够从QS Nonce中的其他28位猜出这两位。
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发送方会将请求的发送速率（以位/秒为单位）放入TCP数据包（称为快速启动请求数据包）IP报头的快速启动选项中，并进行适当的格式化。（我们在本节中对“数据包”和“段”的使用会有些松散。）当用于初始启动时，快速启动请求数据包可以是SYN或SYN/ACK数据包，如图1所示。请求的速率包括对传输和IP报头开销的估计。TCP接收器（例如，主机B）返回TCP报头中响应SYN/ACK数据包或ACK数据包（称为快速启动响应数据包）中的快速启动响应选项，通知主机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使用响应中的信息及其对往返时间的测量来确定快速启动拥塞窗口（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.
两个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) 主机接收到其中一个端点已移动其网络连接点的明确指示后。这可能是由于某些底层移动机制（如移动IP）（[RFC3344]、[RFC3775]）造成的。一些传输，如蒸汽控制传输协议（SCTP）[RFC2960]，可能与多个IP地址关联，并且可以在中间连接中切换地址（因此网络路径）。如果传输对不断变化的网络路径有具体的了解，那么当前的发送速率可能不合适，传输发送方可以使用快速启动来探测网络，看看它是否可以以更高的速率发送。（或者，在没有快速启动的情况下，应使用传统的慢速启动。）
(4) After an application-limited period, when the sender has been using only a small amount of its appropriate share of the network capacity and has no valid estimate for its fair share. In this case, Quick-Start may be an appropriate mechanism to determine if the sender can send at a higher rate. For instance, consider an application that steadily exchanges low- rate control messages and suddenly needs to transmit a large amount of data.
(4) 在应用程序限制期后，发送方仅使用了其适当的网络容量份额中的一小部分，并且对其公平份额没有有效的估计。在这种情况下，快速启动可能是一种适当的机制，用于确定发送方是否可以以更高的速率发送。例如，考虑一个稳定地交换低速率控制消息并突然需要传输大量数据的应用程序。
Of the above, this document recommends that a TCP sender MAY attempt to use Quick-Start in cases (1) and (2). It is NOT RECOMMENDED that a TCP sender use Quick-Start for case (3) at the current time. Case (3) requires external notifications not presently defined for TCP or other transport protocols. Finally, a TCP SHOULD NOT use Quick-Start for case (4) at the current time. Case (4) requires further thought and investigation with regard to how the transport protocol could determine it was in a situation that would warrant transmitting a Quick-Start Request.
在上述情况中，本文档建议TCP发送方可以尝试在情况（1）和（2）中使用快速启动。不建议TCP发送方在当前时间使用案例（3）的快速启动。情况（3）需要目前尚未为TCP或其他传输协议定义的外部通知。最后，TCP目前不应使用案例（4）的快速启动。案例（4）需要进一步思考和调查，以确定传输协议如何确定其处于需要传输快速启动请求的情况。
As a general guideline, a TCP sender SHOULD NOT request a sending rate larger than it is able to use over the next round-trip time of the connection (or over 100 ms, if the round-trip time is not known), except as required to round up the desired sending rate to the next-highest allowable request.
作为一般准则，TCP发送方不应请求大于其在连接的下一个往返时间内所能使用的发送速率（或超过100 ms，如果往返时间未知），除非需要将所需发送速率四舍五入到下一个允许的最高请求。
In any circumstances, the sender MUST NOT make a QS request if it has made a QS request within the most recent round-trip time.
在任何情况下，如果发送方在最近的往返时间内提出了QS请求，则发送方不得提出QS请求。
Section 4.7 discusses some of the issues of using Quick-Start at connection initiation, and Section 4.8 discusses issues that arise when Quick-Start is used to request a larger sending rate after an idle period.
第4.7节讨论了在连接启动时使用快速启动的一些问题，第4.8节讨论了在空闲期后使用快速启动请求更大发送速率时出现的问题。
In order to approve the use of Quick-Start, the TCP receiver responds to the receipt of a Quick-Start Request with a Quick-Start Response, using the Quick-Start Response Option in the TCP header. TCP's Quick-Start Response option is defined as follows:
为了批准快速启动的使用，TCP接收方使用TCP标头中的快速启动响应选项，通过快速启动响应响应快速启动请求的接收。TCP的快速启动响应选项定义如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length=8 | Resv. | Rate | TTL Diff |
| | | |Request| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QS Nonce | R |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
快速启动响应选项的第二个字节包含以字节为单位的选项长度。长度字段必须设置为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.
快速启动响应选项的第三个字节包含一个四位保留字段和四位允许的速率请求，格式与快速启动速率请求选项相同。
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选项的第四个字节包含TTL差异。TTL差异包含接收到的快速启动请求数据包中IP TTL和QS TTL字段之间的差异，如等式（1）或（2）中所计算（取决于使用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和一个两位保留字段。
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选项包括最大段大小（四个字节）、时间戳（十个字节）、窗口比例（三个字节）和允许的选择性确认（两个字节）。
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
如果TCP主机愿意允许快速启动请求，则在相应确认数据包的TCP报头中包含快速启动响应选项。快速启动响应选项中的速率请求设置为快速启动选项中速率请求的接收值，如果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.
接收方只愿意允许较低速率的请求。快速启动响应中的TTL Diff设置为IP TTL值和QS TTL值之间的差值，如等式（1）或（2）所示（取决于使用的是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.
如果快速启动响应在网络中丢失，则不得重新发送。数据包丢失可能是返回路径拥塞的一个指示，在这种情况下，最好不要批准快速启动请求。
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 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和Rate请求的检查成功，并且TCP主机将使用快速启动请求，则必须在收到快速启动响应后的一个往返时间内或在三秒内（以较小者为准）开始使用该请求。要使用快速启动请求，主机将其快速启动拥塞窗口（以MSS大小的段为单位）QS cwnd设置如下：
QS-cwnd = (R * T) / (MSS + H) (3)
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).
其中R是以字节/秒为单位的速率请求，T是以秒为单位的测量往返时间，H是以字节为单位的估计TCP/IP报头大小（例如，40字节）。
Derivation: the sender is allowed to transmit at R bytes per second including packet headers, but only R*MSS/(MSS+H) bytes per second, or equivalently R*T*MSS/(MSS+H) bytes per round-trip time, of application data.
派生：允许发送方以每秒R字节的速度传输应用程序数据，包括数据包头，但每秒仅传输R*MSS/（MSS+H）字节，或相当于每往返时间传输R*T*MSS/（MSS+H）字节。
The TCP host SHOULD set its congestion window cwnd to QS-cwnd only if QS-cwnd is greater than cwnd; otherwise, QS-cwnd is ignored. If QS-cwnd is used, the TCP host sets a flag that it is in Quick-Start mode, and while in Quick-Start mode, the TCP sender MUST use rate-based pacing to pace out Quick-Start packets at the approved rate. If, during Quick-Start mode, the TCP sender receives ACKs for packets sent before this Quick-Start mode was entered, these ACKs are processed as usual, following the default congestion control mechanisms. Quick-Start mode ends when the TCP host receives an ACK for one of the Quick-Start packets.
只有当QS cwnd大于cwnd时，TCP主机才应将其拥塞窗口cwnd设置为QS cwnd；否则，将忽略QS cwnd。如果使用QS cwnd，TCP主机将设置一个标志，表明它处于快速启动模式，并且在快速启动模式下，TCP发送方必须使用基于速率的速度调整，以批准的速率调整快速启动数据包的速度。如果在快速启动模式期间，TCP发送方收到在进入该快速启动模式之前发送的数据包的ACK，则这些ACK将按照默认的拥塞控制机制正常处理。当TCP主机收到其中一个快速启动数据包的ACK时，快速启动模式结束。
If the congestion window has not been fully used when the first ack arrives ending the Quick-Start mode, then the congestion window is decreased to the amount that has actually been used so far. This is necessary because when the Quick-Start Response is received, the TCP sender's round-trip-time estimate might be longer than for succeeding round-trip times, e.g., because of delays at routers processing the IP Quick-Start Option, or because of delays at the receiver in responding to the Quick-Start Request packet. In this case, an overly large round-trip-time estimate could have caused the TCP sender to translate the approved Quick-Start sending rate in bytes per second into a congestion window that is larger than needed, with the TCP sender receiving an ACK for the first Quick- Start packet before the entire congestion window has been used. Thus, when the TCP sender receives the first ACK for a Quick-Start packet, the sender MUST reduce the congestion window to the amount that has actually been used.
如果在结束快速启动模式的第一个ack到达时拥塞窗口未被完全使用，则拥塞窗口将减少到目前为止实际使用的数量。这是必要的，因为当接收到快速启动响应时，TCP发送方的往返时间估计可能比后续往返时间长，例如，由于路由器处理IP快速启动选项的延迟，或者由于接收器响应快速启动请求包的延迟。在这种情况下，过大的往返时间估计可能导致TCP发送方将批准的快速启动发送速率（以字节/秒为单位）转换为大于需要的拥塞窗口，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
例如，具有R KBps的批准快速启动请求、包括报头的B字节数据包和T秒的RTT估计的TCP发送方将R KBps的速率请求转换为R*T/B数据包的拥塞窗口。TCP发送方将以R KBps的速率发送快速启动数据包。但是，如果实际的当前往返时间是T/2秒而不是T秒，那么发送方将在T/2秒后开始接收快速启动数据包的确认。按照上面的段落，TCP发送方随后将其拥塞窗口从R*T/B减少到大约R*T/（B*2）个数据包，即以R KBps的发送速率填充管道所需的实际数据包数。（注意：这只是一个例子。）
illustration; the congestion window is actually set to the amount of data sent before the ACK arrives and not based on equations above.)
插图拥塞窗口实际上设置为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发送方限制在慢启动期间为一个数据窗口增加拥塞窗口的数据包数量。
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快速启动请求，如果TCP发送方具有1500字节的数据包，而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].
在有大量快速启动请求的情况下，一种可能性是TCP接收器发送快速启动请求，以请求反向路径上确认流量的带宽。然而，在我们看来，更好的方法是TCP接收器简单地控制发送确认流量的速率。未来的最佳解决方案将涉及对TCP确认流量的显式使用拥塞控制，就像现在对DCCP的CCID2[RFC4341]中的确认流量所做的那样。
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.
* 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在初始三方握手期间播发MSS；因此，接收方应该了解发送方将使用的数据包大小。如果接收机没有这样的理解或希望确认协商的ms，则可以使用第一数据分组的大小。
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/（100*8*MSS）的ACK比率K为每K个数据分组发送最多一个ACK，将其纯确认通信的发送速率限制为每RTT最多100个纯ACK分组。接收器将确认第一个快速启动数据包和每个后续的K个数据包。因此，对于R＝1.3 Gbps、RTT＝0.2秒和MSS＝1500字节的某种极端情况，K将被设置为216，并且接收器将每216个数据分组确认一次。根据[RFC2581]，ACK比率K的最小值应为2。当ACK比率大于2，并且TCP发送方接收到每个确认两个以上数据包的确认时，TCP发送方可能希望使用基于速率的调整来控制其传出数据流量的突发性。
In the absence of explicit congestion control mechanisms, the TCP end nodes cannot determine the packet drop rate for pure acknowledgement traffic. This is true with or without Quick-Start. However, the TCP receiver could limit its increase in the sending rate for pure ACK packets by at most doubling the sending rate for pure ACK packets from one round-trip time to the next. The TCP receiver would do this by halving the ACK Ratio each round-trip time.
在没有明确的拥塞控制机制的情况下，TCP端节点无法确定纯确认流量的丢包率。无论是否有快速启动，都是如此。然而，TCP接收器可以通过将纯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流的一种特定机制。鼓励今后对该计划和其他详细计划进行调查。
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，我们将“快速启动数据包”定义为在快速启动请求成功后立即在窗口中发送的数据包之一。在检测到快速启动数据包的丢失或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）与路径MTU发现（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:
使用Quick Start请求较大初始窗口时的一个问题涉及较大初始窗口与路径MTU发现之间的交互。RFC 3390中讨论了一些问题：
"When larger initial windows are implemented along with Path MTU Discovery [RFC1191], alternatives are to set the `Don't Fragment' (DF) bit in all segments in the initial window, or to set the `Don't Fragment' (DF) bit in one of the segments. It is an open question as to which of these two alternatives is best."
“当较大的初始窗口与路径MTU发现[RFC1191]一起实施时，备选方案是在初始窗口的所有段中设置‘不分段’（DF）位，或在其中一段中设置‘不分段’（DF）位。这两个备选方案中的哪一个是最好的，这是一个悬而未决的问题。”
If the sender knows the Path MTU when the initial window is sent (e.g., from a PMTUD cache or from some other IETF-approved method), then the sender SHOULD use that MTU for segments in the initial window. Unfortunately, the sender doesn't necessarily know the Path MTU when it sends packets in the initial window. In this case, the sender should be conservative in the packet size used. Sending a large number of overly large packets with the DF bit set is not desirable, but sending a large number of packets that are fragmented in the network can be equally undesirable.
如果发送初始窗口时发送方知道路径MTU（例如，从PMTUD缓存或其他IETF批准的方法），则发送方应将该MTU用于初始窗口中的段。不幸的是，发送方在初始窗口中发送数据包时不一定知道路径MTU。在这种情况下，发送方应保守使用的数据包大小。使用DF比特集发送大量超大数据包是不可取的，但是发送大量在网络中被分段的数据包也是同样不可取的。
If the sender doesn't know the Path MTU when the initial window is sent, the sender SHOULD send one large packet in the initial window with the DF bit set, and send the remaining packets in the initial window with a smaller MTU of 576 bytes (or 1280 bytes with IPv6).
如果发送方在发送初始窗口时不知道路径MTU，则发送方应在初始窗口中发送一个设置了DF位的大数据包，并在初始窗口中以576字节（或1280字节，IPv6）的较小MTU发送其余数据包。
A second possibility would be for the sender to delay sending the Quick-Start Request for one round-trip time by sending the Quick-Start Request with the first window of data, while also doing Path MTU Discovery.
第二种可能性是，发送方通过发送带有第一个数据窗口的快速启动请求，同时进行路径MTU发现，将发送快速启动请求延迟一个往返时间。
The sender may be using an iterative approach such as Packetization Layer Path MTU Discovery (PLPMTUD) [MH06] for Path MTU Discovery, where the sender tests successively larger MTUs. If a probe is successfully delivered, then the MTU can be raised to reflect the value used in that probe. We would note that PLPMTUD does not allow the sender to determine the Path MTU before sending the initial window of data.
发送方可以使用迭代方法，例如用于路径MTU发现的分组层路径MTU发现（PLPMTUD）[MH06]，其中发送方连续测试较大的MTU。如果探测成功交付，则可以提升MTU以反映该探测中使用的值。我们注意到，PLPMTUD不允许发送方在发送初始数据窗口之前确定路径MTU。
4.7.2. Quick-Start Request Packets that are Discarded by Routers or Middleboxes
4.7.2. 路由器或中间盒丢弃的快速启动请求数据包
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数据包总是可能由于拥塞而在网络中被丢弃，或者由于与路由器或中间盒的交互而被阻塞，其中，中间盒被定义为除正常情况外执行功能的任何中间盒，源主机和目标主机之间数据路径上IP路由器的标准功能[RFC3234]。传输协议和中间盒之间交互的测量研究[MAF04]表明，对于70%的受调查Web服务器，如果TCP SYN数据包包含未知IP选项，则不会建立连接（对于43%的Web服务器，如果TCP SYN数据包包含IP时间戳选项，则不会建立连接）。在这两种情况下，这可能是由于该路径上的路由器或中间盒造成的。
If the TCP sender doesn't receive a response to the SYN or SYN/ACK packet containing the Quick-Start Request, then the TCP sender SHOULD resend the SYN or SYN/ACK packet without the Quick-Start Request.
如果TCP发送方没有收到对包含快速启动请求的SYN或SYN/ACK数据包的响应，则TCP发送方应在没有快速启动请求的情况下重新发送SYN或SYN/ACK数据包。
Similarly, if the TCP sender receives a TCP reset in response to the SYN or SYN/ACK packet containing the Quick-Start Request, then the TCP sender SHOULD resend the SYN or SYN/ACK packet without the Quick-Start Request [RFC3360].
类似地，如果TCP发送方收到TCP重置，以响应包含快速启动请求的SYN或SYN/ACK数据包，则TCP发送方应在没有快速启动请求的情况下重新发送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.
RFC 1122和2988指定发送方应将初始RTO（重传超时）设置为三秒，尽管许多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请求的情况下重新发送丢弃的数据包。或者，发送方可以在TCP报头中仅使用ECN请求重新发送丢弃的数据包，如果第二个TCP SYN数据包被丢弃，则在不使用快速启动或ECN请求的情况下重新发送TCP SYN数据包。第二种选择似乎是合理的，因为与丢弃TCP报头中带有ECN请求的数据包的策略相比，丢弃带有IP选项的数据包的策略更有可能阻止当前的TCP SYN数据包[MAF04]。
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
要在已经历拥塞事件且最近未发生移动事件的连接中使用快速启动请求，TCP发送方可以确定自上次数据包丢弃以来TCP连接实现的最大拥塞窗口，并将其转换为发送速率以获得
maximum allowed request rate. If the request is granted, then the sender essentially restarts with its old congestion window from before it was reduced, for example, during an idle period.
允许的最大请求速率。如果请求被允许，那么发送方基本上会从减少拥塞窗口之前（例如，在空闲期间）重新启动它的旧拥塞窗口。
A Quick-Start Request sent in the middle of a TCP connection SHOULD be sent on a data packet.
在TCP连接的中间发送的快速启动请求应该在数据分组上发送。
(2) When to make a request: A TCP connection MAY make a Quick-Start Request before the connection has experienced a congestion event, or after an idle period of at least one RTO.
(2) 当RTO在一个事件之前或之后至少有一个空闲时间段发出连接请求时，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) 如果快速启动分组被丢弃：如果快速启动分组在连接的中间被丢弃，那么发送方必须回复到快速启动窗口的一半，或者如果快速启动请求未被批准，则发送方将使用的拥塞窗口，无论哪个较小。
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差异。如果主机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的有效性。如果它们有效，则主机A将适当地设置其初始拥塞窗口，并设置基于速率的起搏以用于初始窗口。如果快速启动响应无效，则主机A使用TCP的默认初始窗口。在任何一种情况下，主机A都会发送一份已批准费率的报告。
Host A also calculates the TTL Diff for the Quick-Start Request in the incoming SYN/ACK packet, and sends a Quick-Start Response in the TCP header of the ACK packet.
主机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.
本节说明Quick Start与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要求为AH ICV计算目的将无法识别的IPv4选项归零，因此在路由中更改快速启动IP选项数据不会导致IPv4的现有IPsec AH实现出现问题。如果识别出快速启动选项，则必须将其视为可变IPv4选项，因此为了AH ICV计算目的，必须将其完全归零。IPv6选项编号明确表示该选项是否可变；IANA分配选项类型中第三高阶位的值为1，表示快速启动选项数据可以在途中更改。RFC 4302要求将任何此类期权的期权数据归零，以用于AH ICV计算。因此，对IP报头中快速启动选项的更改不会影响AH ICV的计算。
This section considers interactions between Quick-Start and IP tunnels, including IPsec ([RFC4301]), IP in IP [RFC2003], GRE [RFC2784], and others. This section also considers interactions between Quick-Start and MPLS [RFC3031].
本节考虑快速启动和IP隧道之间的交互，包括IPsec（[RFC4301]）、IP中的IP[RFC2003]、GRE[RFC2784]和其他。本节还考虑了快速启动和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之间的差异，mod 256。回想一下，只有当进入网络的数据包的TTL Diff值与离开网络的数据包的TTL Diff值相同时，发送方才认为快速启动请求已批准。
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 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?
__ Tunnels Supporting Quick-Start
/
/
Non-Simple Tunnels __/_____ Tunnels Compatible with Quick-Start,
\ but Not Supporting Quick-Start
\
\__ Tunnels Not Compatible with Quick-Start?
Figure 6: Categories of Tunnels.
图6：隧道类别。
Tunnels that are compatible with Quick-Start: We say that an IP tunnel `is not compatible with Quick-Start' if the use of a Quick-Start Request over such a tunnel allows false positives, where the TCP sender incorrectly believes that the Quick-Start Request was approved by all routers along the path. If the use of Quick-Start over the tunnel does not cause false positives, we say that the IP tunnel `is compatible with Quick-Start'.
与快速启动兼容的隧道：如果在此类隧道上使用快速启动请求允许误报，即TCP发送方错误地认为快速启动请求已被路径上的所有路由器批准，则我们称IP隧道“与快速启动不兼容”。如果在隧道上使用快速启动不会导致误报，我们称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.
我们未来的任务之一是调查与快速启动不兼容的隧道的发生情况，并跟踪此类隧道随时间变化的程度。对与快速启动不兼容的隧道误报问题的评估将影响快速启动从试验到拟定标准的进展，并将影响处于试验模式时快速启动的部署程度。
Tunnels that support Quick-Start: We say that an IP tunnel `supports Quick-Start' if it allows routers along the tunnel path to process the Quick-Start Request and give feedback, resulting in the appropriate possible acceptance of the Quick-Start Request. Some tunnels that are compatible with Quick-Start support Quick-Start, while others do not. We note that a simple tunnel is not able to support Quick-Start.
支持快速启动的隧道：如果IP隧道允许隧道路径上的路由器处理快速启动请求并提供反馈，从而适当地接受快速启动请求，那么我们就说它“支持快速启动”。与快速启动兼容的一些隧道支持快速启动，而其他隧道则不支持。我们注意到，简单的隧道无法支持快速启动。
From a security point of view, the use of Quick-Start in the outer header of an IP tunnel might raise security concerns because an adversary could tamper with the Quick-Start information that propagates beyond the tunnel endpoint, or because the Quick-Start Option exposes information to network scanners. Our approach is to make supporting Quick-Start an option for IP tunnels. That is, in environments or tunneling protocols where the risks of using Quick-Start are judged to outweigh its benefits, the tunnel can simply delete the Quick-Start Option or zero the Quick-Start rate request and QS TTL fields before encapsulation. The result is that there are two viable options for IP tunnels to be compatible with Quick-Start. The first option is the simple tunnel described above and in Section 6.1, where the tunnel is compatible with Quick-Start but does not
从安全角度来看，在IP隧道的外部报头中使用快速启动可能会引起安全问题，因为对手可能会篡改传播到隧道端点之外的快速启动信息，或者因为快速启动选项将信息暴露给网络扫描程序。我们的方法是使支持快速启动成为IP隧道的一个选项。也就是说，在判断使用快速启动的风险大于其好处的环境或隧道协议中，隧道可以简单地删除快速启动选项或在封装之前将快速启动速率请求和QS TTL字段归零。结果是，IP隧道有两个可行的选项与快速启动兼容。第一种选择是上文和第6.1节中所述的简单隧道，其中隧道与快速启动兼容，但不兼容
support Quick-Start, where all Quick-Start Requests along the path will be rejected. The second approach is a Quick-Start-capable mode, described in Section 6.3, where the tunnel actively supports Quick-Start.
支持快速启动，路径上的所有快速启动请求都将被拒绝。第二种方法是第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 Diff值保持不变。例如，这种情况可能发生在堆栈（BITS）中的凹凸，这是一种IPsec加密实现，其中数据加密发生在网络驱动程序和TCP/IP协议堆栈之间[RFC4301]。
As one example, if a remote access VPN client uses a BITS structure, then Quick-Start obstacles between the client and the VPN gateway won't be seen. This is a particular problem because the path between the client and the VPN gateway is likely to contain the most congested part of the path. Because most VPN clients are reported to use BITS [H05], we will explore this in more detail.
例如，如果远程访问VPN客户端使用BITS结构，则不会看到客户端和VPN网关之间的快速启动障碍。这是一个特殊的问题，因为客户端和VPN网关之间的路径可能包含路径中最拥挤的部分。由于大多数VPN客户端都使用BITS[H05]，我们将对此进行更详细的探讨。
A Bump-In-The-Wire (BITW) is an IPsec encryption implementation where the encryption occurs on an outboard processor, offloading the encryption processing overhead from the host or router [RFC4301]. The BITW device is usually IP addressable, which means that the IP TTL is decremented before the packet is passed to the BITW. If the QS TTL is not decremented, then the value of TTL Diff is changed, and the Quick-Start Request will be denied. However, if the BITW supports a host and does not have its own IP address, then the IP TTL is not decremented before the packet is passed from the host to the BITW, and a false positive could occur.
线路中的凹凸（BITW）是一种IPsec加密实现，其中加密发生在外侧处理器上，从而从主机或路由器上卸载加密处理开销[RFC4301]。BITW设备通常是IP可寻址的，这意味着在将数据包传递给BITW之前，IP TTL会减小。如果QS TTL未递减，则TTL Diff的值将更改，快速启动请求将被拒绝。但是，如果BITW支持主机并且没有自己的IP地址，则在数据包从主机传递到BITW之前，IP TTL不会减小，并且可能发生误报。
Other tunnels that need to be looked at are IP tunnels over non-network protocols, such as IP over TCP and IP over UDP [RFC3948], and tunnels using the Layer Two Tunneling Protocol [RFC2661].
需要研究的其他隧道包括非网络协议上的IP隧道，如TCP上的IP和UDP上的IP[RFC3948]，以及使用第二层隧道协议[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节讨论了非IP队列的相关问题，例如第二层以太网或ATM（异步传输模式）网络，作为不参与快速启动反馈的可能瓶颈的另一个实例。
This section discusses tunnels configured to support Quick-Start.
本节讨论配置为支持快速启动的隧道。
If the tunnel ingress node chooses to locally approve the Quick-Start Request, then the ingress node MUST decrement the Quick-Start TTL at the same time it decrements the IP TTL, and MUST copy IP TTL and the Quick-Start Option from the inner IP header to the outer header. During encapsulation, the tunnel ingress MUST zero the Quick-Start rate request field in the inner header to ensure that the Quick-Start Request will be rejected if the tunnel egress does not support Quick-Start.
如果隧道入口节点选择本地批准快速启动请求，则入口节点必须在减少IP TTL的同时减少快速启动TTL，并且必须将IP TTL和快速启动选项从内部IP报头复制到外部报头。封装期间，隧道入口必须将内部报头中的快速启动速率请求字段归零，以确保如果隧道出口不支持快速启动，则快速启动请求将被拒绝。
If the tunnel ingress node does not choose to locally approve the Quick-Start Request, then it MUST either delete the Quick-Start option from the inner header before encapsulation, or zero the QS TTL and the Rate Request fields before encapsulation.
如果隧道入口节点未选择本地批准快速启动请求，则必须在封装之前从内部标头中删除快速启动选项，或者在封装之前将QS TTL和速率请求字段归零。
Upon decapsulation, if the outer header contains a Quick-Start option, the tunnel egress MUST copy the IP TTL and the Quick-Start option from the outer IP header to the inner header.
解除封装后，如果外部标头包含快速启动选项，则隧道出口必须将IP 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（Internet密钥交换）协议进行安全关联。在本文中，我们不考虑快速启动和IPSec与IKEv1 [RFC2409]之间的相互作用。现在IKEv2[RFC4306]的RFC已经发布，我们计划指定对IPsec的修改，以允许协商对快速启动的支持；此修改将指定隧道端点之间的协商，以允许或禁止在隧道内支持快速启动。这是针对IPsec隧道的ECN，使用IKEv1完成的[RFC3168，第9.2节]。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-
MPLS快速启动的行为类似于IP隧道快速启动的行为。对于IP TTL作为MPLS路径遍历的一部分而递减的MPLS路径，这些路径与快速启动兼容，但不支持快速启动；快的-
Start Requests that are traversing these paths will be correctly understood by the transport sender as having been denied. Any MPLS paths where the IP TTL is not decremented as part of traversing the MPLS path would be not compatible with Quick-Start; such paths would result in false positives, where the TCP sender incorrectly believes that the Quick-Start Request was approved by all routers along the path.
通过这些路径的启动请求将被传输发送方正确理解为已被拒绝。IP TTL未作为穿越MPLS路径的一部分而递减的任何MPLS路径将与快速启动不兼容；这样的路径会导致误报，TCP发送方错误地认为快速启动请求已被路径上的所有路由器批准。
For cases where the ingress node to the MPLS path is aware of Quick-Start, this node should either zero the Quick-Start rate request, QS TTL, and QS Nonce fields, or remove the Quick-Start Option from the IP header.
对于MPLS路径的入口节点知道快速启动的情况，该节点应将快速启动速率请求、QS TTL和QS 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.
* 仅为具有适当拥塞控制机制的单播传输协议指定快速启动。注：快速启动不是标准拥塞控制技术的替代品，而是为了增强其运行。
* 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).
* 如果其中一个快速启动数据包丢失，则发送方将恢复到该协议的标准拥塞控制方法，该方法在快速启动请求未被批准的情况下本应使用。此外，发送方还考虑了快速启动拥塞窗口过大的信息（例如，通过减少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，因为Quick Start对它们没有什么好处。
Quick-Start will be more effective if Quick-Start Requests are not larger than necessary; every Quick-Start Request that is approved but not used (or not fully used) takes away from the bandwidth pool available for granting successive Quick-Start Requests.
如果快速启动请求不超过需要，则快速启动将更加有效；每个已批准但未使用（或未完全使用）的快速启动请求都会从可用于授予连续快速启动请求的带宽池中扣除。
In this section, we briefly outline how a router might decide whether or not to approve a Quick-Start Request. The router should ask the following questions:
在本节中，我们简要介绍路由器如何决定是否批准快速启动请求。路由器应询问以下问题：
* Has the router's output link been underutilized for some time (e.g., several seconds)?
* 路由器的输出链路是否有一段时间（如几秒钟）未充分利用？
* Would the output link remain underutilized if the arrival rate were to increase by the aggregate rate requests that the router has approved over the last fraction of a second?
* 如果到达率增加路由器在最后几秒钟内批准的总速率请求，那么输出链路是否仍然未得到充分利用？
In order to answer the last question, the router must have some knowledge of the available bandwidth on the output link and of the Quick-Start bandwidth that could arrive due to recently approved Quick-Start Requests. In this way, if an underutilized router experiences a flood of Quick-Start Requests, the router can begin to deny Quick-Start Requests while the output link is still underutilized.
为了回答最后一个问题，路由器必须了解输出链路上的可用带宽以及由于最近批准的快速启动请求而可能到达的快速启动带宽。这样，如果未充分利用的路由器遇到大量快速启动请求，路由器可以在输出链路仍然未充分利用时开始拒绝快速启动请求。
A simple way for the router to keep track of the potential bandwidth from recently approved requests is to maintain two counters: one for the total aggregate Rate Requests that have been approved in the current time interval [T1, T2], and one for the total aggregate Rate Requests approved over a previous time interval [T0, T1]. However, this document doesn't specify router algorithms for approving Quick-Start Requests, or make requirements for the appropriate time intervals for remembering the aggregate approved Quick-Start bandwidth. A possible router algorithm is given in Appendix E, and more discussion of these issues is available in [SAF06].
路由器跟踪最近批准的请求的潜在带宽的一种简单方法是维护两个计数器：一个用于当前时间间隔[T1，T2]内批准的总聚合速率请求，另一个用于前一时间间隔[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
快速启动的主要好处是可以更快地启动传输连接本身。对于一到五个数据包的小型TCP传输，快速启动可能没有什么好处；充其量，它可能会将连接寿命从三次往返时间缩短到两次（包括建立连接的往返时间）。类似地，对于非常大的传输，慢启动阶段只占连接寿命的一小部分，快速启动的好处有限。快速启动不会显著缩短连接寿命，但它可能会消除或至少缩短启动阶段。但是，对于配置良好的环境中的中等大小的连接，“快速启动”可能允许M数据包的整个传输在短时间内完成
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).
一次往返时间（在SYN交换的初始往返时间之后），而不是数据传输通常需要的log_2（M）-2次往返时间，在非压缩环境中（假设初始窗口为四个数据包）。
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数据包将被丢弃。因此，对于发送方来说，使用快速启动的一个风险是，携带快速启动请求的数据包可能在网络中被丢弃。当TCP SYN数据包被丢弃时，发送方的成本尤其高昂，因为在这种情况下，发送方应在重新发送SYN数据包之前等待3秒钟的RTO，如第4.7.2节所述。
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.)
丢弃快速启动数据包的成本：发送方在使用快速启动时的另一个风险在于可能遭受与拥塞相关的快速启动数据包丢失。这种情况不太可能发生，因为只有在快速启动请求的利用率明显不足时，路由器才会批准快速启动请求。然而，其中一个路由器中的交叉通信量的瞬时增加、一个链路上的可用带宽的突然减少或非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.
路由器中的慢路径：快速启动的另一个缺点是，包含快速启动请求消息的数据包可能不会在路由器中采用快速路径，特别是在快速启动部署到Internet的开始阶段。这将意味着终端主机的额外延迟，以及路由器的额外处理负担。但是，如第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.
快速启动的一个限制是，它假定连接的数据包将遵循与快速启动请求包相同的路径。如果情况并非如此，则连接可能会以批准的速率沿着已经拥塞的路径发送快速启动数据包，或者由于此连接而变得拥塞。因此，当快速启动请求被批准后立即发生路由更改，并且快速启动数据包遵循与原始快速启动请求不同的路径时，快速启动可能会产生较差的性能。然而，如果连接的路径在连接的中间已经改变了，那么已经建立了允许的初始速率，那么这将类似于具有足够数据的连接所发生的情况。
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节所述，对单个连接内的数据包使用多路径路由的路由器不得批准快速启动请求。Quick Start在具有多路径路由的环境中执行不稳定，因为连接中的不同数据包通常遵循不同的路径。在这样的环境中，快速启动请求和连接中的部分数据包可能采用未充分利用的路径，而其余数据包采用备用的拥塞路径。
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网络中的队列。一种可能性是，在适当的情况下，与此类非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.
在上述三段中提到的任何情况下（即，批准的费率报告大于先前快速启动请求中的费率请求，批准的费率报告没有之前的费率请求，或者费率请求没有批准的费率报告），交通警察可能会假设快速启动未被适当使用，或在不合适的环境中使用（例如，有多条路径），并采取相应的措施。
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).
一种形式的不当行为是接收方通过虚假报告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.
但是，如果快速启动请求仅被不具备快速启动功能的路由器拒绝，或者被无法将QS TTL和QS Nonce字段归零的路由器拒绝，则接收器可能会通过在从同一主机接收的连续请求中修改QS TTL来谎报快速启动请求是否得到批准。特别是，如果发送方未对快速启动请求采取行动，则接收方可在计算TTL差异之前，在从该主机接收的下一个请求中，将QS TTL减小1，并在随后接收的请求中，将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
第二种形式的接收者不当行为是，接收者通过增加Rate Request字段的值，就批准的快速启动请求的费率请求向发送者撒谎。但是，接收方不一定知道发送方发送的原始快速启动请求中的速率请求，接收方报告的更高速率请求只有在不高于最初请求的速率请求时，发送方才会认为其有效
by the sender. For example, if the sender sends a Quick-Start Request with a Rate Request of X, and the receiver reports receiving a Quick-Start Request with a Rate Request of Y > X, then the sender knows that either some router along the path malfunctioned (increasing the Rate Request inappropriately), or the receiver is lying about the Rate Request in the received packet.
寄件人寄来的。例如，如果发送方发送速率请求为X的快速启动请求，而接收方报告接收速率请求为Y>X的快速启动请求，则发送方知道路径上的某个路由器出现故障（不适当地增加速率请求），或者，接收方对接收到的数据包中的速率请求撒谎。
If the sender sends a Quick-Start Request with a Rate Request of Z, the receiver receives the Quick-Start Request with an approved Rate Request of X, and reports a Rate Request of Y, for X < Y <= Z, then the receiver only succeeds in lying to the sender about the approved rate if the receiver successfully reports the rightmost 2Y bits in the QS nonce.
如果发送方发送速率请求为Z的快速启动请求，则接收方接收速率请求为X的快速启动请求，并报告速率请求为Y，对于X<Y<=Z，然后，只有在接收方成功报告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.
有几种可能的额外形式的保护，防止接收者谎报费率请求的值。一种可能的额外保护是路由器在快速启动请求中降低速率请求，以便直接向发送方报告降低的速率。但是，这可能会导致针对单个请求向发送方返回许多报告，也可能用于地址欺骗攻击。
A second limited form of protection would be for senders to use some degree of randomization in the requested Rate Request, so that it is difficult for receivers to guess the original value for the Rate Request. However, this is difficult because there is a fairly coarse granularity in the set of rate requests available to the sender, and randomizing the initial request only offers limited protection, in any case.
第二种有限的保护形式是发送方在请求的速率请求中使用某种程度的随机化，因此接收方很难猜测速率请求的原始值。然而，这是很困难的，因为发送方可用的速率请求集合的粒度相当粗，并且在任何情况下，随机化初始请求只能提供有限的保护。
In addition to protecting against misbehaving receivers, it is necessary to protect against misbehaving routers. Consider collusion between an ingress router and an egress router belonging to the same intranet. The ingress router could decrement the Rate Request at the ingress, with the egress router increasing it again at the egress. The routers between the ingress and egress that approved the
除了防止接收器行为不端之外，还必须防止路由器行为不端。考虑入口路由器和属于同一Intranet的出口路由器之间的合谋。入口路由器可以在入口处降低速率请求，而出口路由器在出口处再次增加速率请求。批准的入口和出口之间的路由器
decremented rate request might not have been willing to approve the larger, original request.
递减率请求可能不愿意批准较大的原始请求。
Another form of collusion would be for the ingress router to inform the egress router out-of-band of the TTL Diff and QS Nonce for the request packet at the ingress. This would enable the egress router to modify the QS TTL and QS Nonce so that it appeared that all the routers along the path had approved the request. There does not appear to be any protection against a colluding ingress and egress router. Even if an intermediate router had deleted the Quick-Start Option from the packet, the ingress router could have sent the Quick-Start Option to the egress router out-of-band, with the egress router inserting the Quick-Start Option, with a modified QS TTL field, back in the packet.
另一种形式的共谋将是入口路由器将入口处的请求分组的TTL Diff和QS 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.
与此相反，对于快速启动，入口和出口路由器的共谋使快速启动请求被批准的假象有时会给该共谋所覆盖的流量带来优势，有时会带来劣势，具体取决于场景的细节。如果路径上的某些路由器确实没有足够的可用带宽来批准快速启动请求，那么由于错误批准的请求而发送的快速启动数据包可能会在网络中丢弃，这可能会对连接造成不利影响。因此，尽管入口路由器和出口路由器可以串通以防止中间路由器拒绝快速启动请求，但发生这种情况并不总是对连接有利。针对这种共谋的一种防御措施是，入口和出口节点之间的某些路由器拒绝了监控连接性能的请求，惩罚了在快速启动请求被拒绝后似乎正在使用快速启动的连接，或者报告的批准速率高于该路由器实际批准的速率的连接。
If the congested router is ECN-capable, and the colluding ingress and egress routers are lying about ECN-capability as well as about Quick-Start, then the result could be that the Quick-Start Request falsely appears to the sender to have been approved, and the Quick-
如果拥塞路由器具有ECN能力，并且共谋的入口和出口路由器对ECN能力以及快速启动撒谎，那么结果可能是快速启动请求错误地向发送方显示已被批准，并且快速启动请求被拒绝-
Start packets falsely appear to the congested router to be ECN-capable. In this case, the colluding routers might succeed in giving a competitive advantage to the traffic protected by their collusion (if no intermediate router is monitoring to catch such misbehavior).
在拥塞路由器看来，启动数据包错误地显示为支持ECN。在这种情况下，共谋路由器可能成功地为受其共谋保护的流量提供竞争优势（如果没有中间路由器进行监控以捕获此类不当行为）。
One possible difficulty is that of traffic normalizers [HKP01], or other middleboxes along that path, that rewrite IP TTLs in order to foil other kinds of attacks in the network. If such a traffic normalizer rewrote the IP TTL, but did not adjust the Quick-Start TTL by the same amount, then the sender's mechanism for determining if the request was approved by all routers along the path would no longer be reliable. Rewriting the IP TTL could result in false positives (with the sender incorrectly believing that the Quick-Start Request was approved) as well as false negatives (with the sender incorrectly believing that the Quick-Start Request was denied).
一个可能的困难是流量规范化器[HKP01]或该路径上的其他中间盒重写IP TTL以抵御网络中的其他类型的攻击。如果这样的流量规范化器重写了IP TTL，但没有将快速启动TTL调整相同的量，那么发送方确定请求是否被路径上的所有路由器批准的机制将不再可靠。重写IP TTL可能会导致误报（发送方错误地认为快速启动请求已被批准）以及误报（发送方错误地认为快速启动请求已被拒绝）。
As discussed in [SAF06], Quick-Start is vulnerable to two kinds of attacks: (1) attacks to increase the routers' processing and state load and (2) attacks with bogus Quick-Start Requests to temporarily tie up available Quick-Start bandwidth, preventing routers from approving Quick-Start Requests from other connections. Routers can protect against the first kind of attack by applying a simple limit on the rate at which Quick-Start Requests will be considered by the router.
从“快速启动”到“快速启动”，从“快速启动”到“攻击”，从“快速启动”到“攻击”，从“快速启动”到“攻击”，从“快速启动”到“攻击”，从“快速启动”到“攻击”，从“快速启动”到“连接”到“攻击”，从“快速启动”到“攻击”，从“快速启动”到“攻击”，从“快速启动”到“攻击，从”到“连接”到“攻击，从”到“临时启动”。路由器可以通过对路由器考虑快速启动请求的速率施加一个简单的限制来防止第一类攻击。
The second kind of attack, to tie up the available Quick-Start bandwidth, is more difficult to defend against. As discussed in [SAF06], Quick-Start Requests that are not going to be used, either because they are from malicious attackers or because they are denied by routers downstream, can result in short-term `wasting' of potential Quick-Start bandwidth, resulting in routers denying subsequent Quick-Start Requests that, if approved, would in fact have been used.
第二种攻击，即占用可用的快速启动带宽，更难防御。如[SAF06]中所述，由于恶意攻击者或下游路由器拒绝而不使用的快速启动请求可能会导致潜在快速启动带宽的短期“浪费”，从而导致路由器拒绝后续快速启动请求，如果获得批准，事实上会被使用。
We note that the likelihood of malicious attacks would be minimized significantly when Quick-Start was deployed in a controlled environment such as an intranet, where there was some form of centralized control over the users in the system. We also note that this form of attack could potentially make Quick-Start unusable, but it would not do any further damage; in the worst case, the network would function as a network without Quick-Start.
我们注意到，当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”目录中的“test all quickstart”。[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.
本节讨论Quick Start的一些实现问题。本节还讨论了一些关键的部署问题，例如必须在路由器和终端节点中部署才能工作的机制的鸡和蛋部署问题，以及今天广泛部署的中间包所带来的问题，这些中间包阻碍了已知或未知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
一种可能性是，协议实现可以为应用程序提供一个API，以指示他们希望何时请求快速启动，以及他们希望请求的速率。在传统的套接字API中，这可能是在建立连接之前设置的套接字选项。有些应用程序，例如那些使用TCP进行批量传输的应用程序，对传输速率不感兴趣，但它们可能知道可以发送的数据量
immediately. Based on this, the sender implementation could decide whether Quick-Start would be useful, and what rate should be requested.
立即基于此，发送方实现可以决定快速启动是否有用，以及应请求的速率。
We note that when Quick-Start is used, the TCP sender is required to save the QS Nonce and the TTL Diff when the Quick-Start Request is sent, and to implement an additional timer for the paced transmission of Quick-Start packets.
我们注意到，当使用快速启动时，TCP发送方需要在发送快速启动请求时保存QS Nonce和TTL Diff，并为快速启动数据包的有节奏传输实现额外的计时器。
A router or other network host must be able to determine the approximate bandwidth of its outbound network interfaces in order to process incoming Quick-Start rate requests, including those that originate from the host itself. One possibility would be for hosts to rely on configuration information to determine link bandwidths; this has the drawback of not being robust to errors in configuration. Another possibility would be for network device drivers to infer the bandwidth for the interface and to communicate this to the IP layer.
路由器或其他网络主机必须能够确定其出站网络接口的近似带宽，以便处理传入的快速启动速率请求，包括来自主机本身的请求。一种可能性是主机依赖配置信息来确定链路带宽；这样做的缺点是对配置中的错误不可靠。另一种可能性是网络设备驱动程序推断接口的带宽，并将其传送到IP层。
Particular issues will arise for wireless links with variable bandwidth, where decisions will have to be made about how frequently the host gets updates of the changing bandwidth. It seems appropriate that Quick-Start Requests would be handled particularly conservatively for links with variable bandwidth; to avoid cases where Quick-Start Requests are approved, the link bandwidth is reduced, and the data packets that are sent end up being dropped.
对于具有可变带宽的无线链路，将出现特定的问题，其中必须决定主机获得变化带宽更新的频率。对于带宽可变的链路，快速启动请求的处理似乎特别保守；为了避免快速启动请求被批准的情况，链路带宽会减少，发送的数据包最终会被丢弃。
Difficult issues also arise for paths with multi-access links (e.g., Ethernet). Routers or end-nodes with multi-access links should be particularly conservative in granting Quick-Start Requests. In particular, for some multi-access links, there may be no procedure for an attached node to use to determine whether all parts of the multi-access link have been underutilized in the recent past.
对于具有多接入链路（例如以太网）的路径，也会出现困难的问题。具有多访问链路的路由器或终端节点在授予快速启动请求时应特别保守。具体地，对于一些多址链路，可能没有用于连接节点的过程来确定多址链路的所有部分在最近的过去是否都未得到充分利用。
Because of possible problems discussed above concerning using Quick-Start over some network paths and the security issues discussed in Section 11, the most realistic initial deployment of Quick-Start would most likely take place in intranets and other controlled environments. Quick-Start is most useful on high bandwidth-delay paths that are significantly underutilized. The primary initial users of Quick-Start would likely be in organizations that provide network services to their users and also have control over a large portion of the network path.
由于上文讨论了在某些网络路径上使用快速启动可能存在的问题以及第11节讨论的安全问题，最现实的快速启动初始部署最有可能发生在内部网和其他受控环境中。快速启动在严重未充分利用的高带宽延迟路径上最有用。Quick Start的主要初始用户可能在为其用户提供网络服务并控制大部分网络路径的组织中。
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.
快速入门目前并不适用于全球互联网中的普遍部署。特别是，在终端节点或路由器中，默认情况下不应启用快速启动；相反，当使用Quick Start时，用户或系统管理员应该显式启用它。
Below are a few examples of networking environments where Quick-Start would potentially be useful. These are the environments that might consider an initial deployment of Quick-Start in the routers and end-nodes, where the incentives for routers to deploy Quick-Start might be the most clear.
下面是一些网络环境的示例，在这些环境中，“快速入门”可能很有用。这些环境可能考虑路由器和端节点中的快速启动的初始部署，其中路由器部署快速启动的激励可能是最清楚的。
* Centrally administrated organizational intranets: These intranets often have large network capacity, with networks that are underutilized for much of the time [PABL+05]. Such intranets might also include high-bandwidth and high-delay paths to remote sites. In such an environment, Quick-Start would be of benefit to users, and there would be a clear incentive for the deployment of Quick-Start in routers. For example, Quick-Start could be quite useful in high-bandwidth networks used for scientific computing.
* 集中管理的组织内部网：这些内部网通常具有较大的网络容量，网络在大部分时间内未得到充分利用[PABL+05]。这种内部网还可能包括到远程站点的高带宽和高延迟路径。在这样的环境中，“快速启动”将对用户有利，并且在路由器中部署“快速启动”将有明显的激励。例如，快速启动在用于科学计算的高带宽网络中可能非常有用。
* Wireless networks: Quick-Start could also be useful in high-delay environments of Cellular Wide-Area Wireless Networks, such as the GPRS [BW97] and their enhancements and next generations. For example, GPRS EDGE (Enhanced Data for GSM Evolution) is expected to provide wireless bandwidth of up to 384 Kbps (roughly 32 1500-byte packets per second) while the GPRS round-trip times range typically from a few hundred milliseconds to over a second, excluding any possible queueing delays in the network [GPAR02]. In addition, these networks sometimes have variable additional delays due to resource allocation that could be avoided by keeping the connection path constantly utilized, starting from initial slow-start. Thus, Quick-Start could be of significant benefit to users in these environments.
* 无线网络：快速入门在蜂窝广域无线网络的高延迟环境中也很有用，例如GPRS[BW97]及其增强功能和下一代。例如，GPRS EDGE（用于GSM演进的增强型数据）预计将提供高达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毫秒，而带宽可以以每秒兆比特数测量[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
* 单跳路径：快速启动应在点对点单跳路径上运行良好，例如，从主机到相邻服务器。只有当主机能够确定到下一个IP跃点的路径在整个过程中是否明显未充分利用时，“快速启动”才能在由多址链路组成的单跳IP路径上工作
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.
最近的过去。如果多址链路包括第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不同，ECN即使只在端到端路径上的一个路由器上部署也会有好处，连接使用快速启动需要在端到端路径上的所有路由器上部署快速启动。其次，与在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大得多。Quick Start能够显著提高未充分利用环境中连接的吞吐量，而不是简单地用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的流量规范化程序的潜在问题。所有这些问题都可能导致发送方使用不适当大的速率请求，或者认为请求已被批准，而实际上该请求已被路径上的至少一个路由器拒绝。这种对快速启动的不当使用可能会导致拥塞和路径上不可接受的丢包水平。这种拥塞也可能是拒绝服务攻击的一部分。
Section 9.6 discusses a potential attack on the routers' processing and state load from an attack of Quick-Start Requests. Section 9.6 also discusses a potential attack on the available Quick-Start bandwidth by sending bogus Quick-Start Requests for bandwidth that will not, in fact, be used. While this impacts the global usability of Quick-Start, it does not endanger the network as a whole since TCP uses standard congestion control if Quick-Start is not available.
第9.6节讨论了快速启动请求攻击对路由器处理和状态负载的潜在攻击。第9.6节还讨论了对可用快速启动带宽的潜在攻击，该攻击通过发送虚假的快速启动请求来获取实际上不会使用的带宽。虽然这会影响快速启动的全局可用性，但不会危及整个网络，因为如果快速启动不可用，TCP将使用标准的拥塞控制。
Section 4.7.2 discusses the potential problem of packets with Quick-Start Requests dropped by middleboxes along the path.
第4.7.2节讨论了中间盒沿路径丢弃具有快速启动请求的数据包的潜在问题。
As discussed in Section 5, for IPv4 IPsec Authentication Header Integrity Check Value (AH ICV) calculation, the Quick-Start Option is a mutable IPv4 option and hence completely zeroed for AH ICV calculation purposes. This is also the treatment required by RFC 4302 for unrecognized IPv4 options. The IPv6 Quick-Start Option's IANA-allocated option type indicates that it is a mutable option; hence, according to RFC 4302, its option data is required to be zeroed for AH ICV computation purposes. See RFC 4302 for further explanation.
如第5节所述，对于IPv4 IPsec身份验证标头完整性检查值（AH ICV）计算，快速启动选项是一个可变的IPv4选项，因此在AH ICV计算中完全归零。这也是RFC 4302对无法识别的IPv4选项所要求的处理方法。IPv6快速启动选项的IANA分配选项类型表明它是一个可变选项；因此，根据RFC 4302，出于AH ICV计算目的，其期权数据需要归零。更多解释请参见RFC 4302。
Section 6.2 discusses possible problems of Quick-Start used by connections carried over simple tunnels that are not compatible with Quick-Start. In this case, it is possible that a Quick-Start Request is erroneously considered approved by the sender without the routers in the tunnel having individually approved the request, causing a false positive.
第6.2节讨论了通过与快速启动不兼容的简单隧道进行连接时可能出现的快速启动问题。在这种情况下，可能在隧道中的路由器没有单独批准请求的情况下，快速启动请求被错误地认为已被发送方批准，从而导致误报。
We note two high-order points here. First, the Quick-Start Nonce goes a long way towards preventing large-scale cheating. Second, even if a host occasionally uses Quick-Start when it is not approved by the entire network path, the network will not collapse. Quick-Start does not remove TCP's basic congestion control mechanisms; these will kick in when the network is heavily loaded, relegating any Quick-Start mistake to a transient.
我们在这里注意到两个高阶点。首先，快速启动的临时措施对防止大规模作弊大有帮助。其次，即使主机在未获得整个网络路径的批准时偶尔使用快速启动，网络也不会崩溃。快速启动并没有消除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
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
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选项编号，前两位表示IPv6节点可能跳过此选项，并在无法识别选项类型时继续处理标头，第三位表示选项数据可能在路由过程中发生更改。
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
Kind Length Meaning
---- ------ ------------------------------
27 8 Quick-Start Response
This document should be listed as the reference document.
本文件应列为参考文件。
We are presenting the Quick-Start mechanism as a simple, understandable, and incrementally deployable mechanism that would be sufficient to allow some connections to start up with large initial rates, or large initial congestion windows, in over-provisioned, high-bandwidth environments. We expect there will be an increasing number of over-provisioned, high-bandwidth environments where the Quick-Start mechanism, or another mechanism of similar power, could be of significant benefit to a wide range of traffic. We are presenting the Quick-Start mechanism as a request for the community to provide feedback and experimentation on issues relating to Quick-Start.
我们将快速启动机制介绍为一种简单、可理解且可增量部署的机制，它足以允许某些连接在过度配置的高带宽环境中以较大的初始速率或较大的初始拥塞窗口启动。我们预计，将有越来越多的过度配置的高带宽环境，其中快速启动机制或其他类似功能的机制可能会对广泛的流量产生显著的好处。我们提出“快速启动”机制，要求社区就与“快速启动”相关的问题提供反馈和试验。
The authors wish to thank Mark Handley for discussions of these issues. The authors also thank the End-to-End Research Group, the Transport Services Working Group, and members of IPAM's program on Large-Scale Communication Networks for both positive and negative feedback on this proposal. We thank Srikanth Sundarrajan for the initial implementation of Quick-Start in the NS simulator, and for the initial simulation study. Many thanks to David Black and Joe Touch for extensive feedback on Quick-Start and IP tunnels. We also thank Mohammed Ashraf, John Border, Bob Briscoe, Martin Duke, Tom Dunigan, Mitchell Erblich, Gorry Fairhurst, John Heidemann, Paul Hyder, Dina Katabi, and Vern Paxson for feedback. Thanks also to Gorry Fairhurst for the suggestion of adding the QS Nonce to the Report of Approved Rate.
作者希望感谢马克·汉德利对这些问题的讨论。作者还感谢端到端研究小组、交通服务工作组以及IPAM大型通信网络项目的成员对该提案的正面和负面反馈。我们感谢Srikanth Sundarrajan在NS模拟器中初步实现了快速启动，并进行了初步模拟研究。非常感谢David Black和Joe Touch对快速入门和IP隧道的广泛反馈。我们还感谢穆罕默德·阿什拉夫、约翰·博德、鲍勃·布里斯科、马丁·杜克、汤姆·杜尼根、米切尔·埃尔布里奇、戈里·费尔赫斯特、约翰·海德曼、保罗·海德尔、迪娜·卡塔比和弗恩·帕克森的反馈。还感谢Gorry Fairhurst建议将QS Nonce添加到批准费率报告中。
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版本基于路国汉[L05]的提案。本文档的早期版本包含八位QS Nonce，后续版本讨论了四位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]中描述的概念为基础。关于隧道快速启动的一些文本直接从RFC3168中借用。
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]或其他用于高带宽传输的传输协议结合在一起，可以大大扩展Internet上尽力而为流量的性能范围。然而，有许多事情是快速启动提案无法完成的。快速启动不是一种拥塞控制机制，也无助于更精确地利用可用带宽，即以低延迟和低丢包率实现高吞吐量的目标。快速启动不会让路由器对活动连接的减少率有更多的控制。
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.
一种可能是发送方使用来自分组流的信息来了解可用带宽，而不使用来自路由器的明确信息。这些技术不允许在未充分利用的环境中以快启动的速度启动；为了使用数据包流了解可用带宽，必须发送一些数据包。然而，这些技术可以使启动比当前的慢速启动快得多。虽然似乎很清楚，没有路由器的显式反馈的方法将严格低于有显式反馈的方法，但也有可能比慢启动更具攻击性的方法在没有从路由器获得显式反馈所涉及的复杂性的情况下是可行的。
Periodic packet streams: [JD02] explores the use of periodic packet streams to estimate the available bandwidth along a path. The idea is that the one-way delays of a periodic packet stream show an increasing trend when the stream's rate is higher than the available bandwidth (due to an increasing queue). While [JD02] states that the proposed mechanism does not cause significant increases in network utilization, losses, or delays when done by one flow at a time, the approach could be problematic if conducted concurrently by a number of flows. [JD02] also gives an overview of some of the earlier work on inferring the available bandwidth from packet trains.
周期性数据包流：[JD02]探索使用周期性数据包流来估计路径上的可用带宽。其思想是，当周期性分组流的速率高于可用带宽时（由于队列增加），其单向延迟呈现增加趋势。虽然[JD02]指出，当一次由一个流执行时，提议的机制不会导致网络利用率、损失或延迟的显著增加，但如果同时由多个流执行，该方法可能会出现问题。[JD02]还概述了先前关于从数据包序列推断可用带宽的一些工作。
Swift-Start: The Swift Start proposal from [PRAKS02] combines packet-pair and packet-pacing techniques. An initial congestion window of four segments is used to estimate the available bandwidth along the path. This estimate is then used to dramatically increase the congestion window during the second RTT of data transmission.
快速启动：来自[PRAKS02]的快速启动方案结合了数据包对和数据包调整技术。使用四段的初始拥塞窗口来估计路径上的可用带宽。然后，在数据传输的第二个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连接与已获得高拥塞窗口的同一目的地的预先存在的TCP连接共享路径和cwnd，则新的TCP连接可以从高初始cwnd开始。RFC 2140讨论了集成共享，其中已建立连接的拥塞窗口可以“分割”，以便与同一主机的新连接共享。但是，这两种方法都不能解决连接到新目的地的情况，即没有到该目的地的现有或最近的连接（因此也没有拥塞控制状态）。
While continued research on the limits of the ability of TCP and other transport protocols to learn of available bandwidth without explicit feedback from the router seems useful, we note that there are several fundamental advantages of explicit feedback from routers.
虽然继续研究TCP和其他传输协议在没有来自路由器的显式反馈的情况下学习可用带宽的能力限制似乎很有用，但我们注意到，来自路由器的显式反馈有几个基本优势。
(1) Explicit feedback is faster than implicit feedback: One advantage of explicit feedback from the routers is that it allows the transport sender to reliably learn of available bandwidth in one round-trip time.
(1) 显式反馈比隐式反馈快：路由器的显式反馈的一个优点是，它允许传输发送者在一次往返时间内可靠地学习可用带宽。
(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]是发送方在没有路由器的明确许可和没有带宽估计技术的情况下从大的初始窗口开始，并且初始窗口的第一分组包含信息，例如初始窗口的大小或发送速率。建议是拥塞的路由器将在第一个数据包中使用该信息来丢弃或延迟来自该初始窗口的许多或所有数据包。这样，流的乐观的大初始窗口将不会迫使路由器从网络中的竞争流丢弃数据包。这种方法似乎需要发送方的某种机制来确保路径上的路由器理解标记大初始窗口的第一个包的机制。
Obviously, there would be a number of questions to consider about an approach of optimistic sending.
显然，对于乐观的发送方式，会有许多问题需要考虑。
(1) Incremental deployment: One question would be the potential complications of incremental deployment, where some of the routers along the path might not understand the packet information describing the initial window.
(1) 增量部署：一个问题是增量部署的潜在复杂性，路径上的一些路由器可能不理解描述初始窗口的数据包信息。
(2) Congestion collapse: There could also be concerns about congestion collapse if many flows used large initial windows, many packets were dropped from optimistic initial windows, and many congested links ended up carrying packets that are only going to be dropped downstream.
(2) 拥塞崩溃：如果许多流使用较大的初始窗口，许多数据包从乐观的初始窗口丢弃，并且许多拥塞的链路最终携带的数据包只会在下游丢弃，那么也可能会担心拥塞崩溃。
(3) Distributed Denial of Service attacks: A third question would be the potential role of optimistic senders in amplifying the damage done by a Distributed Denial of Service (DDoS) attack (assuming attackers use compliant congestion control in the hopes of "flying under the radar").
(3) 分布式拒绝服务攻击：第三个问题是乐观派发送者在放大分布式拒绝服务（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) 如果数据包被丢弃，性能会受到影响：第四个问题是当数据包从初始窗口之一丢弃时，对连接的性能影响进行量化。
There have been several proposals somewhat similar to Quick-Start, where the transport protocol collects explicit information from the routers along the path.
有几个建议与Quick Start有些类似，其中传输协议从路径上的路由器收集显式信息。
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选项将查询路径上的路由器关于最小可用缓冲区大小的信息。此外，IP选项将在初始SYN交换之后发送，此时TCP发送方已经估计了往返时间。
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.
性能透明协议（Performance Transparency Protocol）：性能透明协议（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）的一种变体，该变体包括一种累积机制，用于通知端点沿路径的聚合拥塞统计信息[KAPS02]。（[KSEPA04]中的第二个变量不依赖于网络的累积拥塞统计数据。）
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的一位拥塞反馈相比，它向终端节点提供更细粒度的反馈。来自XCP的每个数据包反馈可以是正反馈或负反馈，并指定在确认该数据包时发送方拥塞窗口的增加或减少。XCP是一种成熟的拥塞控制方案，而Quick Start代表一种快速检查，以确定网络路径是否明显未充分利用，从而使连接可以更快地启动，然后返回到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的建议是在包头中设置一个位，路由器可以设置该位以指示它们未充分利用。对于到达发送方的每个TCP ACK，表明已接收到设置了反ECN位的数据包，发送方将能够将其拥塞窗口增加一个数据包，就像在慢启动期间一样。
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和其他流量未使用的带宽。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.
我们注意到，Quick Start与较低努力程度的服务或低于最佳努力程度的TCP变体有很大不同。与这些建议不同，Quick Start旨在为希望获得至少与竞争的尽力而为连接相同带宽的尽力而为流量提供帮助。
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（[RCF792]，[RCF443]）或RSVP[RCF2205]协议是否可以用于传递快速启动请求。
Being a control protocol used between Internet nodes, one could argue that ICMP is the ideal method for requesting permission for faster start-up from routers. The ICMP header is above the IP header. Quick-Start could be accomplished with ICMP as follows: If the ICMP protocol is used to implement Quick-Start, the equivalent of the Quick-Start IP option would be carried in the ICMP header of the ICMP Quick-Start Request. The ICMP Quick-Start Request would have to pass by the routers on the path to the receiver, possibly using the IP Router Alert option [RFC2113]. A router that approves the Quick-Start Request would take the same actions as in the case with the Quick-Start IP Option, and forward the packet to the next router along the path. A router that does not approve the Quick-Start Request, even with a decreased value for the Requested Rate, would delete the ICMP Quick-Start Request, and send an ICMP Reply to the sender that the request was not approved. If the ICMP Reply was dropped in the network, and did not reach the receiver, the sender would still know that the request was not approved from the absence of feedback from the receiver. If the ICMP Quick-Start Request was dropped in the network due to congestion, the sender would assume that the request was not approved. The ICMP message would need the source and destination port numbers for demultiplexing at the end nodes. If the ICMP Quick-Start Request reached the receiver, the receiver would use transport-level or application-level mechanisms to send a response to the sender, exactly as with the IP Option.
作为互联网节点之间使用的控制协议，人们可能会认为ICMP是从路由器请求更快启动许可的理想方法。ICMP标头位于IP标头之上。使用ICMP可以按如下方式实现快速启动：如果使用ICMP协议实现快速启动，则ICMP快速启动请求的ICMP标头中将携带与快速启动IP选项等效的内容。ICMP快速启动请求必须通过到接收器路径上的路由器，可能使用IP路由器警报选项[RFC2113]。批准快速启动请求的路由器将采取与快速启动IP选项相同的操作，并沿路径将数据包转发给下一个路由器。不批准快速启动请求的路由器，即使请求速率的值降低，也会删除ICMP快速启动请求，并向发送方发送ICMP回复，告知请求未被批准。如果ICMP回复在网络中被丢弃，并且没有到达接收方，则由于接收方没有反馈，发送方仍会知道请求未被批准。如果ICMP快速启动请求由于拥塞而在网络中被丢弃，发送方将认为该请求未被批准。ICMP消息需要源端口号和目标端口号，以便在终端节点进行解复用。如果ICMP快速启动请求到达接收方，接收方将使用传输级或应用程序级机制向发送方发送响应，与IP选项完全相同。
One benefit of using ICMP would be that the delivery of the TCP SYN packet or other initial packet would not be delayed by IP option processing at routers. A greater advantage is that if middleboxes were blocking packets with Quick-Start Requests, using the Quick-Start Request in a separate ICMP packet would mean that the middlebox behavior would not affect the connection as a whole. (To get this robustness to middleboxes with TCP using an IP Quick-Start Option, one would have to have a TCP-level Quick-Start Request packet that could be sent concurrently with, but separately from, the TCP SYN packet.)
使用ICMP的一个好处是，TCP SYN数据包或其他初始数据包的交付不会因路由器上的IP选项处理而延迟。更大的优势是，如果中间盒使用快速启动请求阻塞数据包，则在单独的ICMP数据包中使用快速启动请求将意味着中间盒行为不会影响整个连接。（要使用IP快速启动选项获得对具有TCP的中间盒的健壮性，必须具有TCP级别的快速启动请求数据包，该数据包可以与TCP SYN数据包同时发送，但与TCP SYN数据包分开发送。）
However, there are a number of disadvantages to using ICMP. Some firewalls and middleboxes may not forward the ICMP Quick-Start Request packets. (If an ICMP Reply packet from a router to the sender is dropped in the network, the sender would still know that the request was not approved, as stated earlier, so this would not be as serious of a problem.) In addition, it would be difficult, if not impossible, for a router in the middle of an IP tunnel to deliver an ICMP Reply packet to the actual source, for example, when the inner IP header is encrypted, as in IPsec ESP tunnel mode [RFC4301]. Again, however, the ICMP Reply packet would not be essential to the correct operation of ICMP Quick-Start.
然而，使用ICMP有许多缺点。某些防火墙和中间件可能不会转发ICMP快速启动请求数据包。（如果从路由器到发送方的ICMP应答数据包在网络中被丢弃，发送方仍会知道请求未被批准，如前所述，因此问题不会那么严重。）此外，如果不是不可能的话，也会很困难，对于IP隧道中间的路由器，将ICMP应答包传送到实际源，例如，当内部IP报头被加密时，如在IPSec ESP隧道模式[RCF4301]中那样。然而，ICMP回复数据包对于ICMP快速启动的正确操作也不是必需的。
Unauthenticated out-of-band ICMP messages could enable some types of attacks by third-party malicious hosts that are not possible when the control information is carried in-band with the IP packets that can only be altered by the routers on the connection path. Finally, as a minor concern, using ICMP would cause a small amount of additional traffic in the network, which is not the case when using IP options.
未经验证的带外ICMP消息可能会导致第三方恶意主机发起某些类型的攻击，而当控制信息与IP数据包一起在带内传输时，这些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]可以用作承载快速启动请求的承载协议。由于预期路由器处理RSVP数据包的范围比普通传输协议IP数据包更广，因此使用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
如果RSVP用于承载快速启动请求，则从发送方发送到接收方的RSVP路径消息中将包含一个新的“快速启动请求”类对象。除了常见的长度和类型字段外，该对象还将包含速率请求字段。RSVP公共头中的Send_TTL字段可以用作QS TTL字段的等效项。路径上支持快速启动的路由器将检查RSVP path消息中的快速启动请求对象，减少发送TTL，并根据需要调整速率请求字段。如果RSVP路由器不理解快速启动请求对象，它将拒绝整个RSVP消息，并将RSVP PathErr消息发送回发送方。当带有快速启动请求对象的RSVP消息到达接收方时
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.
接收方在相应的传输协议报头中以与前面的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）之间的映射的表。在本节中，我们考虑不同大小的速率请求字段的可能的编码方法，包括四位、八位和更大的速率请求字段。
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.
线性函数：一个可能的建议是，速率请求字段的格式为每秒比特数，按比例缩放，使一个单位等于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.
二次幂：如果两个因子的粒度足以满足速率请求，则具有最大范围的编码函数将使请求的速率为K*2^N；对于N，速率请求字段中的值；对于K，一些常数。对于N=0，无论编码函数如何，速率请求都将设置为零。例如，对于K=40000和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.
对于四位速率请求字段，速率请求的上限为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.
对于往返时间为1秒或更长的流量，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 ms最多发送一个小数据包。80 Kbps的速率请求将转换为每秒100字节的速率（包括数据包头）。虽然一些具有较大往返时间的小数据包流可能会发现40 Kbps的较小速率请求是有用的，但我们的假设是，速率请求的下限为80 Kbps通常就足够了。同样，如果80 kbps的下限不可接受，那么额外的比特可以用于速率请求字段。
If the granularity of factors of two was too coarse, then the encoding function could use a base less than two. An alternate form for the encoding function would be to use a hybrid of linear and exponential functions.
如果因子2的粒度太粗，则编码函数可以使用小于2的基。编码函数的另一种形式是使用线性函数和指数函数的混合。
A mantissa and exponent representation: Section 4.4 of [B05] suggests a mantissa and exponent representation for the Quick-Start encoding function. With e and f as the binary numbers in the exponent and mantissa fields, and with 0 <= f < 1, this would represent the rate (1+f)*2^e. [B05] suggests a mantissa field for f of 8, 16, or 24 bits, with an exponent field for e of 8 bits. This representation would allow larger rate requests, with an encoding that is less coarse than the powers-of-two encoding used in this document.
尾数和指数表示法：[B05]第4.4节建议快速启动编码函数的尾数和指数表示法。指数和尾数字段中的二进制数为e和f，0<=f<1，表示速率（1+f）*2^e。[B05]建议f的尾数字段为8、16或24位，e的指数字段为8位。这种表示将允许更大速率的请求，其编码比本文档中使用的两种编码的幂次粗。
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.
设计问题之一是速率请求字段是以字节/秒还是以数据包/秒为单位。我们分别从传输和路由器的角度对此进行讨论。
For TCP, the results from the Quick-Start Request are translated into a congestion window in bytes, using the measured round-trip time and the MSS. This window applies only to the bytes of data payload, and does not include the bytes in the TCP or IP packet headers. Other transport protocols would conceivably use the Quick-Start Request directly in packets per second, or could translate the Quick-Start Request to a congestion window in packets.
对于TCP，使用测量的往返时间和MSS，将快速启动请求的结果转换为以字节为单位的拥塞窗口。此窗口仅适用于数据有效负载的字节，不包括TCP或IP数据包头中的字节。其他传输协议可以设想以每秒分组的形式直接使用快速启动请求，或者可以将快速启动请求转换为分组中的拥塞窗口。
The assumption of this document is that the router only approves the Quick-Start Request when the output link is significantly underutilized. For this, the router could measure the available bandwidth in bytes per second, or could convert between packets and bytes by some mechanism.
本文档的假设是，路由器仅在输出链路严重未充分利用时批准快速启动请求。为此，路由器可以测量可用带宽（字节/秒），或者通过某种机制在数据包和字节之间进行转换。
If the Quick-Start Request was in bytes per second, and applied only to the data payload, then the router would have to convert from bytes per second of data payload, to bytes per second of packets on the wire. If the Rate Request field was in bytes per second, and the sender ended up using very small packets, this could translate to a significantly larger number in terms of bytes per second on the wire. Therefore, for a Quick-Start Request in bytes per second, it makes most sense for this to include the transport and IP headers as well as the data payload. Of course, this will be, at best, a rough approximation on the part of the sender; the transport-level sender might not know the size of the transport and IP headers in bytes, and might know nothing at all about the separate headers added in IP tunnels downstream. This rough estimate seems sufficient, however, given the overall lack of fine precision in Quick-Start functionality.
如果快速启动请求以字节/秒为单位，并且仅应用于数据有效负载，那么路由器必须将数据有效负载的字节/秒转换为有线数据包的字节/秒。如果速率请求字段是以字节/秒为单位的，并且发送方最终使用的数据包非常小，那么这可能会转化为更大的数据量（以字节/秒为单位）。因此，对于以字节/秒为单位的快速启动请求，最有意义的是包括传输和IP头以及数据负载。当然，这充其量只是发送方的一个粗略近似值；传输级发送方可能不知道传输和IP报头的大小（以字节为单位），并且可能根本不知道在IP隧道下游添加的单独报头。然而，鉴于快速启动功能总体上缺乏精确性，这种粗略估计似乎足够了。
It has been suggested that the router could possibly use information from the MSS option in the TCP packet header of the SYN packet to convert the Quick-Start Request from packets per second to bytes per second, or vice versa. This would be problematic for several reasons. First, if IPsec is used, the TCP header will be encrypted. Second, the MSS option is defined as the maximum MSS that the TCP sender expects to receive, not the maximum MSS that the TCP sender plans to send [RFC793]. However, it is probably often the case that this MSS also applies as an upper bound on the MSS used by the TCP sender in sending.
有人建议路由器可能使用SYN数据包的TCP数据包报头中来自MSS选项的信息将快速启动请求从每秒数据包转换为每秒字节数，反之亦然。这将是有问题的，原因有几个。首先，如果使用IPsec，TCP头将被加密。其次，MSS选项被定义为TCP发送方期望接收的最大MSS，而不是TCP发送方计划发送的最大MSS[RFC793]。然而，通常情况下，此MSS也适用于TCP发送方在发送时使用的MSS的上限。
We note that the sender does not necessarily know the Path MTU when the Quick-Start Request is sent, or when the initial window of data is sent. Thus, with IPv4, packets from the initial window could end up being fragmented in the network if the "Don't Fragment" (DF) bit is not set [RFC1191]. A Rate Request in bytes per second is reasonably robust to fragmentation. Clearly, a Rate Request in packets per second is less robust in the presence of fragmentation. Interactions between larger initial windows and Path MTU Discovery are discussed in more detail in RFC 3390 [RFC3390].
我们注意到，发送快速启动请求或发送初始数据窗口时，发送方不一定知道路径MTU。因此，对于IPv4，如果未设置“不分段”（DF）位，则来自初始窗口的数据包可能最终在网络中被分段[RFC1191]。以字节/秒为单位的速率请求对碎片具有相当强的鲁棒性。显然，在存在碎片的情况下，以每秒数据包为单位的速率请求不太可靠。RFC 3390[RFC3390]更详细地讨论了较大初始窗口和路径MTU发现之间的相互作用。
For a Quick-Start Request in bytes per second, the transport senders would have the additional complication of estimating the bandwidth usage added by the packet headers.
对于以字节/秒为单位的快速启动请求，传输发送方将有额外的复杂性，需要估计数据包头增加的带宽使用量。
We have chosen a Rate Request field in bytes per second rather than in packets per second because it seems somewhat more robust, particularly to routers.
我们选择了以字节/秒为单位的速率请求字段，而不是以数据包/秒为单位的速率请求字段，因为它似乎更加健壮，尤其是对于路由器。
For a Quick-Start Request sent in the middle of a connection, there are two possible semantics for the Rate Request field, as follows:
对于在连接中间发送的快速启动请求，速率请求字段有两种可能的语义，如下：
(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）之间可能存在显著差异。在这一节中，我们简要地考虑这两个选项之间的权衡，并解释为什么我们选择了“总速率”语义。
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
总速率语义使路由器更容易将相同的速率“分配”给所有连接。这有助于公平，并缩短新旧连接之间的收敛时间。使用附加速率语义，路由器不一定知道请求附加速率的流的当前发送速率，因此将没有足够的信息将公平性用作授予速率请求的度量。使用Total Rate语义
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讨论了作为快速启动选项中一个可能功能的当前发送速率报告。然而，目前我们还没有将这种可能的使用标准化。
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.
在从初始窗口丢失快速启动数据包后恢复默认慢速启动的一种可能的替代方法是将拥塞窗口减半，并继续避免拥塞。然而，我们注意到，这对于连接或整个网络来说都不是一个理想的响应。初始窗口中的数据包丢失表明Quick Start未能找到合适的拥塞窗口，这意味着减半后的拥塞窗口也很容易出错。
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.
当初始窗口中的快速启动数据包被丢弃时，这种方法不会恢复为慢速启动的另一个缺点是，这种方法可能会给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和AntiECN），这些建议提供了比当前拥塞控制机制更细粒度的路由器每包反馈，并尝试实现这些更宏伟的目标。
Compared to proposals such as XCP and AntiECN, Quick-Start offers much less control. Quick-Start does not attempt to provide a new congestion control mechanism, but simply to get permission from routers for a higher sending rate at start-up, or after an idle period. Quick-Start can be thought of as an "anti-congestion-control" mechanism that is only of any use when all the routers along the path are significantly underutilized. Thus, Quick-Start is of no use towards a target of high link utilization, or fairness in a high-utilization scenario, or controlling queueing delay during high utilization, or anything of the like.
与XCP和AntiECN等方案相比，Quick Start提供的控制要少得多。快速启动并不试图提供一种新的拥塞控制机制，只是为了在启动时或空闲时间后从路由器获得更高发送速率的许可。快速启动可以被认为是一种“反拥塞控制”机制，只有当路径上的所有路由器都严重利用不足时，它才有任何用处。因此，快速启动对于高链路利用率、高利用率场景中的公平性、或在高利用率期间控制排队延迟等目标没有用处。
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
我们没有详细讨论诸如XCP之类的提案，只是注意到有一些悬而未决的问题。一个问题是，互联网是否迫切需要更复杂的拥塞控制机制，如XCP。Quick Start本质上是一个相当粗糙的工具，不能保证保持高链路利用率和低排队延迟；Quick Start专为在环境中使用而设计
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?
未充分利用，解决了是否允许更高的发送速率这一单一问题。新的拥塞控制机制具有更细粒度的路由器反馈，即使在链路利用率相当高的环境中，也可以实现更快的启动。这是否一项迫切的要求？来自路由器的更细粒度拥塞控制反馈的其他好处是否迫切需要？
We would argue that even if more fine-grained per-packet feedback from routers was implemented, it is reasonable to have a separate mechanism, such as Quick-Start, for indicating an allowed initial sending rate, or an allowed total sending rate after an idle or underutilized period.
我们认为，即使实现了来自路由器的更细粒度的每个数据包反馈，也可以使用单独的机制（例如快速启动）来指示允许的初始发送速率，或者在空闲或未充分利用的时间段后指示允许的总发送速率。
One difference between Quick-Start and current proposals for fine-grained per-packet feedback, such as XCP, is that XCP is designed to give robust performance even in the case where different packets within a connection routinely follow different paths. XCP achieves relatively robust performance in the presence of multipath routing by using per-packet feedback, where the feedback carried in a single packet is about the relative increase or decrease in the rate or window to take effect when that particular packet is acknowledged, not about the allowed sending rate for the connection as a whole.
快速启动和当前针对细粒度每数据包反馈（如XCP）的建议之间的一个区别是，即使在连接中的不同数据包通常遵循不同路径的情况下，XCP也能提供强健的性能。XCP通过使用每包反馈在存在多路径路由的情况下实现相对稳健的性能，其中单个包中携带的反馈是关于在确认特定包时生效的速率或窗口的相对增加或减少，而不是关于整个连接的允许发送速率。
In contrast, Quick-Start sends a single Quick-Start Request, and the answer to that request gives the allowed sending rate for an entire window of data. As a result, Quick-Start could be problematic in an environment where some fraction of the packets in a window of data take path A, and the rest of the packets take path B; for example, the Quick-Start Request could have traveled on path A, while half the Quick-Start packets sent in the succeeding round-trip time are routed on path B. We note that [ZDPS01] shows Internet paths to be stable on the order of RTTs.
相比之下，“快速启动”只发送一个“快速启动”请求，该请求的响应给出了整个数据窗口的允许发送速率。结果，在数据窗口中的一部分分组采用路径a，而其余分组采用路径B的环境中，快速启动可能存在问题；例如，快速启动请求可能在路径A上运行，而在随后的往返时间内发送的一半快速启动数据包在路径B上路由。我们注意到[ZDPS01]显示Internet路径在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
在从路由器到终端节点所需的反馈比特数方面，“快速启动”和一些针对每包反馈的建议之间也存在差异。快速启动使用速率请求字段中的四位反馈来指示允许的发送速率。XCP为每个数据包的反馈分配一个字节，尽管已经讨论过XCP的变体，每个数据包的反馈较少。这将更像其他建议，例如反ECN，使用来自路由器的单个比特的反馈来指示发送方可以响应此特定分组确认以与慢速启动一样快的速度增加。一般来说，只有两位反馈的细粒度建议可能具有相当大的威力，这表明发送方应该在确认此数据包时降低、保持或增加发送速率或窗口。然而，如果快速启动仅限于两个字节，则其功率将受到相当大的限制
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.
反馈似乎确定初始发送速率基本上需要路由器的反馈比特数比增加或降低发送速率的稳态每包反馈比特数更多。
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.
在更实际的层面上，快速启动和每包反馈建议之间的一个区别是，与新的拥塞控制机制相比，快速启动的开放问题更少。由于快速启动是一种在未充分利用的环境中请求初始发送速率的机制，因此其公平性问题不如一般拥塞控制机制严重。通过快速启动，终端节点不需要像在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?
+------------------+----------------------+----------------------+
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
另一个问题是，快速启动等机制与高速TCP和其他正在进行的变革相结合，是否会对满足新拥塞控制机制的某些需求做出重大贡献。这可以被视为
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.
通过一个简单且合理部署的机制，朝着满足某些更紧迫的当前需求迈出了积极的一步，或者，作为一个消极的一步，不必要地拖延更根本的变革。在不回答这个问题的情况下，我们会注意到，我们自己的方法倾向于增量部署相对简单的机制，只要简单的机制不是短期的黑客行为，而是引导整个架构朝着基本正确的方向发展的机制。
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]中快速启动Nonce的另一个建议是为QS Nonce提供一个n位字段，发送方在生成快速启动请求时生成一个随机Nonce。每个将速率请求减少r的路由器将使用单向散列函数（如MD5[RFC1321]或安全散列1[SHA1]）散列QS nonce r次。接收方将QS nonce返回给发送方。因为发送方知道nonce的原始值和原始速率请求，所以发送方知道速率已降低的步骤总数。然后发送方散列原始nonce的次数，以检查结果是否与接收方返回的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.
与第3.4节中所述的QS nonce相比，此nonce替代方案的功能要强大得多，但当路由器减少快速启动请求时，它还需要更多的CPU周期，并需要发送方验证接收方返回的nonce。如[B05]中所述，路由器可以通过限制批准减少快速启动请求的速率来保护自己免受处理器耗尽攻击。
Both the Function field and the Reserved field in the Quick-Start Option would allow the extension of Quick-Start to use Quick-Start requests with the alternate proposal for the Quick-Start Nonce, if it was ever desired.
“快速启动”选项中的“功能”字段和“保留”字段都将允许“快速启动”的扩展，以便在需要的情况下，将“快速启动”请求与“快速启动当前”的备选方案一起使用。
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
本文档的早期版本包括一个请求批准的快速启动Nonce（QS Nonce），该Nonce由发送方初始化为非零的“随机”八位数字，以及一个QS TTL，该QS TTL被初始化为与IP头中的TTL相同的值。在快速启动响应中，传输接收方会将请求批准的快速启动Nonce返回给传输发送方。路由器可以通过不减少QS TTL字段、将QS Nonce字段归零或
deleting the Quick-Start Request from the packet header. The QS Nonce was included to provide some protection against broken downstream routers, or against misbehaving TCP receivers that might be inclined to lie about whether the Rate Request was approved. This protection is now provided by the QS Nonce, by the use of a random initial value for the QS TTL field, and by Quick-Start-capable routers hopefully either deleting the Quick-Start Option or zeroing the QS TTL and QS Nonce fields when they deny a request.
从数据包头中删除快速启动请求。包括QS Nonce是为了提供一些保护，防止下游路由器损坏，或防止行为不端的TCP接收器（可能倾向于谎报速率请求是否被批准）。这种保护现在由QS Nonce提供，通过使用QS TTL字段的随机初始值，并通过具有快速启动功能的路由器提供，当它们拒绝请求时，可能会删除快速启动选项或将QS TTL和QS Nonce字段归零。
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，以及将QS TTL字段设置为与IP报头中的TTL字段相同的值，快速启动请求机制将自动终止；在路径上遇到非参与路由器后，快速启动请求将在第一个参与路由器处终止。由于快速启动请求的选项处理，这可以最大限度地减少路由器产生的不必要开销。在当前规范中，这种“自终止”属性是由具有快速启动功能的路由器提供的，可能是删除快速启动选项，或者在拒绝请求时将速率请求字段归零。由于当前规范使用QS TTL的随机初始值，因此支持快速启动的路由器无法判断快速启动请求是否无效，因为上游没有支持快速启动的路由器。这是使用一种设计的成本，这种设计使得接收器很难欺骗QS TTL的值。
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，TFRC是一种基于等式的拥塞控制形式。有关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.
由于CCID3使用基于速率的拥塞控制机制，因此它提出了一些关于使用快速启动传输协议的新问题。在本文档中，我们不尝试指定使用DCCP快速启动。然而，我们确实讨论了可能出现的一些问题。
In considering the use of Quick-Start with CCID 3 for requesting a higher initial sending rate, the following questions arise:
在考虑使用CCID 3快速启动以请求更高的初始发送速率时，会出现以下问题：
(1) How does the sender respond if a Quick-Start packet is dropped?
(1) 如果快速启动数据包被丢弃，发送方如何响应？
As in TCP, if an initial Quick-Start packet is dropped, the CCID 3 sender should revert to the congestion control mechanisms it would have used if the Quick-Start Request had not been approved.
与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不同，CCID3不会对每个数据包或其他数据包使用确认。相比之下，CCID3接收器大约每往返一次就向发送者发送一次反馈。在CCID 3中，如果在至少四次往返时间内（当发送方每两次往返时间至少发送一个数据包时）未收到来自接收方的反馈，则允许的发送速率减半。当使用快速启动请求时，似乎有必要使用较小的时间间隔，例如，如果在至少两个往返时间内没有来自接收器的反馈到达，则降低发送速率。
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非常有用，因为在标准操作中，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.
与初始发送速率的情况一样，如果在至少两个往返时间内没有从接收器接收到反馈，则降低发送速率似乎是谨慎的。在这种情况下，似乎应该将发送速率降低到在没有批准快速启动请求的情况下使用的发送速率。
This specification does not tightly define the algorithm a router uses when deciding whether to approve a Quick-Start Rate Request or whether and how to reduce a Rate Request. A range of algorithms is likely useful in this space and we consider the algorithm a particular router uses to be a local policy decision. In addition, we believe that additional experimentation with router algorithms is necessary to have a solid understanding of the dynamics various algorithms impose. However, we provide one particular algorithm in this appendix as an example and as a framework for thinking about additional mechanisms.
该规范没有严格定义路由器在决定是否批准快速启动速率请求或是否以及如何降低速率请求时使用的算法。一系列算法在这个空间中可能是有用的，并且我们考虑特定路由器使用的算法是本地策略决策。此外，我们认为，需要对路由器算法进行额外的实验，以便对各种算法所施加的动态有一个坚实的理解。然而，我们在本附录中提供了一个特定的算法作为示例，并作为思考其他机制的框架。
[SAF06] provides several algorithms routers can use to consider incoming Rate Requests. The decision process involves two algorithms. First, the router needs to track the link utilization over the recent past. Second, this utilization needs to be updated by the potential new bandwidth from recent Quick-Start approvals, and then compared with the router's notion of when it is underutilized enough to approve Quick-Start Requests (of some size).
[SAF06]提供了路由器可以用来考虑传入速率请求的几种算法。决策过程涉及两种算法。首先，路由器需要跟踪最近的链路利用率。其次，这种利用率需要通过最近快速启动批准的潜在新带宽进行更新，然后与路由器的概念进行比较，即当它的利用率不足到足以批准快速启动请求（某种大小）时。
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秒，实验使用的N值范围为3到20。
Second, we define the "target" algorithm for processing incoming Quick-Start Rate Requests (also from [SAF06]). The algorithm relies
其次，我们定义了“目标”算法，用于处理传入的快速启动速率请求（也来自[SAF06]）。算法依赖于
on knowing the bandwidth of the outgoing link (which, in many cases, can be easily configured), the utilization of the outgoing link (from an estimation technique such as given above), and an estimate of the potential bandwidth from recent Quick-Start approvals.
了解传出链路的带宽（在许多情况下，可以很容易地进行配置）、传出链路的利用率（来自如上所述的估计技术）以及来自最近快速启动批准的潜在带宽估计。
Tracking the potential bandwidth from recent Quick-Start approvals is another case where local policy dictates how it should be done. The simplest method, outlined in Section 8.2, is for the router to keep track of the aggregate Quick-Start rate requests approved in the most recent two or more time intervals, including the current time interval, and to use the sum of the aggregate rate requests over these time intervals as the estimate of the approved Rate Requests. The experiments in [SAF06] keep track of the aggregate approved Rate Requests over the most recent two time intervals, for intervals of 150 msec.
从最近的快速启动批准中跟踪潜在带宽是另一种情况，当地政策规定了应如何进行。第8.2节中概述的最简单的方法是，路由器跟踪最近两个或更多时间间隔（包括当前时间间隔）内批准的聚合快速启动速率请求，并使用这些时间间隔内的聚合速率请求之和作为批准速率请求的估计值。[SAF06]中的实验记录了最近两个时间间隔（150毫秒）内的聚合批准速率请求。
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;
}
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.
还请注意，鉴于费率请求相当粗略，当批准的费率不完全符合编码方案允许的费率之一时，应将其向下舍入。
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.
快速启动选项在第三个字节中包含一个四位功能字段，允许为快速启动选项定义其他用途。在本节中，我们将讨论一些可能的附加用途，这些用途已在快速入门中讨论过。“功能”字段可方便地为“快速启动”选项添加新功能。
Report of Current Sending Rate: A Quick-Start Request with the `Report of Current Sending Rate' codepoint set in the Function field would be using the Rate Request field to report the current estimated sending rate for that connection. This could accompany a second Quick-Start Request in the same packet containing a standard rate request, for a connection that is using Quick-Start to increase its current sending rate.
当前发送速率报告：功能字段中设置了“当前发送速率报告”代码点的快速启动请求将使用速率请求字段报告该连接的当前估计发送速率。对于使用快速启动来增加其当前发送速率的连接，这可能伴随着包含标准速率请求的同一数据包中的第二个快速启动请求。
Request to Increase Sending Rate: A codepoint for `Request to Increase Sending Rate' in the Function field would indicate that the connection is not idle or just starting up, but is attempting to use Quick-Start to increase its current sending rate. This codepoint would not change the semantics of the Rate Request field.
请求增加发送速率：函数字段中“请求增加发送速率”的代码点表示连接未空闲或刚启动，但正在尝试使用快速启动来增加其当前发送速率。此代码点不会更改速率请求字段的语义。
RTT Estimate: If a codepoint for `RTT Estimate' was used, a field for the RTT Estimate would contain one or more bits giving the sender's rough estimate of the round-trip time, if known. E.g., the sender could estimate whether the RTT was greater or less than 200 ms. Alternately, if the sender had an estimate of the RTT when it sends the Rate Request, the two-bit Reserved field at the end of the Quick-Start Option could be used for a coarse-grained encoding of the RTT.
RTT估计：如果使用了“RTT估计”的码点，RTT估计的字段将包含一个或多个位，给出发送方对往返时间的粗略估计（如果已知）。例如，发送方可以估计RTT是大于还是小于200ms。或者，如果发送方在发送速率请求时对RTT有估计，则快速启动选项末尾的两位保留字段可以用于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.
信息性请求：函数字段中的信息性请求代码点将指示请求纯粹是信息性的，以便发送方确定是否批准费率请求，以及发送信息性请求时批准的费率请求的大小。例如，一个信息请求可以在一个往返时间后由一个标准的快速启动请求跟进。批准信息请求的路由器不会认为这是对使用的快速启动带宽的批准，并且不会有任何义务批准一个类似的标准快速启动请求一次往返时间。发送方可以使用速率请求为零的信息请求来确定路径上的所有路由器是否支持快速启动。
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.
请勿递减：请勿递减代码点可用于快速启动请求，其中发送方宁愿拒绝请求，也不愿在网络中递减速率请求。如果发送方仅在原始费率请求获得批准的情况下才有兴趣使用Quick Start，则可以使用此选项。
Temporary Bandwidth Use: A Temporary codepoint has been proposed to indicate that a connection would only use the requested bandwidth for a single time interval.
临时带宽使用：提出了一个临时代码点，用于指示连接仅在单个时间间隔内使用请求的带宽。
Normative References
规范性引用文件
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，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 25811999年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]奥尔曼，M.，弗洛伊德，S.，和C.帕特里奇，“增加TCP的初始窗口”，RFC3390，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消息摘要算法”，RFC13211992年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 21131997年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 22052997年9月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（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]汤斯利，W.，瓦伦西亚，A.，鲁本斯，A.，帕尔，G.，佐恩，G.，和B.帕尔特，“第二层隧道协议‘L2TP’”，RFC 26611999年8月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.，和P.Traina，“通用路由封装（GRE）”，RFC 27842000年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，“流控制传输协议”，RFC 29602000年10月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC 3124, June 2001.
[RFC3124]Balakrishnan，H.和S.Seshan，“拥堵管理者”，RFC31242001年6月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]Carpenter，B.和S.Brim，“中间盒：分类和问题”，RFC 32342002年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]Floyd，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 36622003年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 36972004年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 37752004年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.，路德维希，R.，Mahdavi，J.，黑山，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 43012005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC43062005年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，“数据报拥塞控制协议（DCCP）”，RFC 43402006年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 43412006年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.奥尔曼、C.海斯和S.奥斯特曼。具有较大初始窗口的TCP评估。ACM计算机通信评论，1998年7月。
[B05] Briscoe, B., "Review: Quick-Start for TCP and IP", <http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html>, November 2005.
[B05]布里斯科，B.，“回顾：TCP和IP的快速启动”<http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html>，2005年11月。
[BW97] G. Brasche and B. Walke. Concepts, Services and Protocols of the new GSM Phase 2+ General Packet Radio Service. IEEE Communications Magazine, pages 94--104, August 1997.
[BW97]G.布拉什和B.沃克。新GSM第2阶段+通用分组无线业务的概念、服务和协议。IEEE通信杂志，第94-104页，1997年8月。
[GPAR02] A. Gurtov, M. Passoja, O. Aalto, and M. Raitola. Multi-Layer Protocol Tracing in a GPRS Network. In Proceedings of the IEEE Vehicular Technology Conference (Fall VTC2002), Vancouver, Canada, September 2002.
[GPAR02]A.古尔托夫、M.帕索哈、O.阿尔托和M.雷托拉。GPRS网络中的多层协议跟踪。2002年9月，加拿大温哥华，IEEE车辆技术会议记录（秋季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。2001年USENIX安全研讨会。
[Jac88] V. Jacobson, Congestion Avoidance and Control, ACM SIGCOMM.
[Jac88]V.Jacobson，拥塞避免和控制，ACM SIGCOMM。
[JD02] Manish Jain, Constantinos Dovrolis, End-to-End Available Bandwidth: Measurement Methodology, Dynamics, and Relation with TCP Throughput, SIGCOMM 2002.
[JD02]Manish Jain，Constantinos Dovrolis，端到端可用带宽：测量方法、动力学以及与TCP吞吐量的关系，SIGCOMM 2002。
[K03] S. Kunniyur, "AntiECN Marking: A Marking Scheme for High Bandwidth Delay Connections", Proceedings, IEEE ICC '03, May 2003. <http://www.seas.upenn.edu/~kunniyur/>.
[K03]S.Kunniyur，“反ECN标记：高带宽延迟连接的标记方案”，会议记录，IEEE ICC'03，2003年5月<http://www.seas.upenn.edu/~kunniyur/>。
[KAPS02] Rajesh Krishnan, Mark Allman, Craig Partridge, James P.G. Sterbenz. Explicit Transport Error Notification (ETEN) for Error-Prone Wireless and Satellite Networks. Technical Report No. 8333, BBN Technologies, March 2002. <http://www.icir.org/mallman/papers/>.
[KAPS02]拉杰什·克里希南、马克·奥尔曼、克雷格·帕特里奇、詹姆斯·P·G·斯特本斯。易出错无线和卫星网络的显式传输错误通知（ETEN）。第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.库兹马诺维奇和E.W.奈特利。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]拉杰什·克里希南、詹姆斯·斯特本茨、韦斯利·艾迪、克雷格·帕特里奇、马克·奥尔曼。易出错无线和卫星网络的显式传输错误通知（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]卢国汉，TCP快速启动中的一段时间，2005年9月<http://www.net-glyph.org/~lgh/nonce usage.pdf>。
[MH06] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", Work in Progress, December 2006.
[MH06]Mathis，M.和J.Heffner，“打包层路径MTU发现”，正在进行的工作，2006年12月。
[MAF04] Alberto Medina, Mark Allman, and Sally Floyd, Measuring Interactions Between Transport Protocols and Middleboxes, Internet Measurement Conference 2004, August 2004. <http://www.icir.org/tbit/".
[MAF04]Alberto Medina，Mark Allman和Sally Floyd，测量传输协议和中间盒之间的相互作用，2004年互联网测量会议，2004年8月<http://www.icir.org/tbit/".
[MAF05] Alberto Medina, Mark Allman, and Sally Floyd. Measuring the Evolution of Transport Protocols in the Internet. Computer Communications Review, April 2005.
阿尔贝托·梅迪纳、马克·奥尔曼和萨利·弗洛伊德。测量互联网中传输协议的演变。《计算机通信评论》，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]Joon Sang Park，《TCP连接的带宽发现》，向John Heidemann报告，2000年，私人通信。引文仅供确认之用。
[PABL+05] Ruoming Pang, Mark Allman, Mike Bennett, Jason Lee, Vern Paxson, Brian Tierney. A First Look at Modern Enterprise Traffic. ACM SIGCOMM/USENIX Internet Measurement Conference, October 2005.
[PABL+05]彭若明、马克·奥尔曼、迈克·贝内特、杰森·李、弗恩·帕克森、布赖恩·蒂尔尼。首先看一下现代企业流量。ACM SIGCOMM/USENIX互联网测量会议，2005年10月。
[PRAKS02] Craig Partridge, Dennis Rockwell, Mark Allman, Rajesh Krishnan, James P.G. Sterbenz. A Swifter Start for TCP. Technical Report No. 8339, BBN Technologies, March 2002. <http://www.icir.org/mallman/papers/>.
克雷格·帕特里奇，丹尼斯·罗克韦尔，马克·奥尔曼，拉杰什·克里希南，詹姆斯·P·G·斯特本斯。TCP的更快启动。BBN第8339号技术报告，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 ]马蒂亚罗西和Michael Welzl，对IP选项处理的影响，预印记ReHe des FakBeeleCs数学软件-IndIntuk，第15号，计算机科学研究所，因斯布鲁克大学，奥地利，2003年10月。
[RW04] Mattia Rossi and Michael Welzl, On the Impact of IP Option Processing - Part 2, Preprint-Reihe des Fachbereichs Mathematik - Informatik, No. 26, Institute of Computer Science, University of Innsbruck, Austria, July 2004.
[RW04]马蒂亚罗西和Michael Welzl，IP选项处理的影响-第2部分，预印记ReHe des FakBeeleCs数学软件-IndIntuk，第26号，计算机科学研究所，因斯布鲁克大学，奥地利，2004年7月。
[S02] Ion Stoica, private communication, 2002. Citation for acknowledgement purposes only.
[S02]Ion Stoica，私人通信，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>.
帕西·萨罗拉蒂、马克·奥尔曼和萨利·弗洛伊德。在未充分利用的网络路径上确定适当的发送速率。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年工作进展会议，2005年8月<https://www.guha.cc/saikat/pub/sigcomm05-lowtcp.pdf>.
[SHA1] "Secure Hash Standard", FIPS, U.S. Department of Commerce, Washington, D.C., publication 180-1, April 1995.
[SHA1]“安全哈希标准”，FIPS，美国商务部，华盛顿特区，出版物180-11995年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.
VVWESWAIAH和J. Heidemann，改善闲置TCP连接的重新启动，技术报告97661，南加州大学，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：互联网上自适应分布式多媒体应用的更好反馈，IPCC2000（第19届IEEE国际性能、计算和通信会议），美国亚利桑那州凤凰城，2000年2月20日至22日<http://www.welzl.at/research/publications/>.
[ZDPS01] Y. Zhang, N. Duffield, V. Paxson, and S. Shenker, On the Constancy of Internet Path Properties, Proc. ACM SIGCOMM Internet Measurement Workshop, November 2001.
[ZDPS01]Y.Zhang，N.Duffield，V.Paxson和S.Shenker，关于互联网路径属性的恒常性，Proc。ACM SIGCOMM互联网测量研讨会，2001年11月。
[ZQK00] Y. Zhang, L. Qiu, and S. Keshav, Speeding Up Short Data Transfers: Theory, Architectural Support, and Simulation Results, NOSSDAV 2000, June 2000.
[ZQK00]Y.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)
EMail: 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/
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/
Amit Jain F5 Networks EMail: a.jain@f5.com
Amit Jain F5网络电子邮件：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诺基亚研究中心邮政信箱407 FI-00045诺基亚集团芬兰电话：+358 50 4876607电子邮件：Pasi。sarolahti@iki.fi
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。