Network Working Group G. Fairhurst
Request for Comments: 5634 A. Sathiaseelan
Category: Experimental University of Aberdeen
August 2009
Network Working Group G. Fairhurst
Request for Comments: 5634 A. Sathiaseelan
Category: Experimental University of Aberdeen
August 2009
Quick-Start for the Datagram Congestion Control Protocol (DCCP)
数据报拥塞控制协议（DCCP）的快速启动
Abstract
摘要
This document specifies the use of the Quick-Start mechanism by the Datagram Congestion Control Protocol (DCCP). DCCP is a transport protocol that allows the transmission of congestion-controlled, unreliable datagrams. DCCP is intended for applications such as streaming media, Internet telephony, and online games. In DCCP, an application has a choice of congestion control mechanisms, each specified by a Congestion Control Identifier (CCID). This document specifies general procedures applicable to all DCCP CCIDs and specific procedures for the use of Quick-Start with DCCP CCID 2, CCID 3, and CCID 4. Quick-Start enables a DCCP sender to cooperate with Quick-Start routers along the end-to-end path to determine an allowed sending rate at the start of a connection and, at times, in the middle of a DCCP connection (e.g., after an idle or application-limited period). The present specification is provided for use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet.
本文件规定了数据报拥塞控制协议（DCCP）对快速启动机制的使用。DCCP是一种传输协议，允许传输拥塞控制的、不可靠的数据报。DCCP适用于流媒体、互联网电话和在线游戏等应用。在DCCP中，应用程序可以选择拥塞控制机制，每个机制由拥塞控制标识符（CCID）指定。本文件规定了适用于所有DCCP CCID的一般程序以及使用DCCP CCID 2、CCID 3和CCID 4快速启动的具体程序。快速启动允许DCCP发送器沿着端到端路径与快速启动路由器合作，以确定在连接开始时允许的发送速率，并且有时在DCCP连接的中间（例如，在空闲或应用受限的时间之后）。本规范提供用于受控环境，而不是作为一种机制，旨在或适用于全球互联网中的普遍部署。
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................4
2. Quick-Start for DCCP ............................................5
2.1. Sending a Quick-Start Request for a DCCP Flow ..............5
2.1.1. The Quick-Start Interval ............................5
2.2. Receiving a Quick-Start Request for a DCCP Flow ............6
2.2.1. The Quick-Start Response Option .....................7
2.3. Receiving a Quick-Start Response ...........................8
2.3.1. The Quick-Start Mode ................................8
2.3.2. The Quick-Start Validation Phase ....................9
2.4. Procedure When No Response to a Quick-Start Request .......10
2.5. Procedure When a Packet Is Dropped While Using
Quick-Start ...............................................11
2.6. Interactions with Mobility and Signaled Path Changes ......11
2.7. Interactions with Path MTU Discovery ......................12
2.8. Interactions with Middleboxes .............................12
3. Mechanisms for Specific CCIDs ..................................13
3.1. Quick-Start for CCID 2 ....................................13
3.1.1. The Quick-Start Request for CCID 2 .................13
3.1.2. Sending a Quick-Start Response with CCID 2 .........13
3.1.3. Using the Quick-Start Response with CCID 2 .........13
3.1.4. Quick-Start Validation Phase for CCID 2 ............14
3.1.5. Reported Loss or Congestion While Using
Quick-Start ........................................14
3.1.6. CCID 2 Feedback Traffic on the Reverse Path ........15
3.2. Quick-Start for CCID 3 ....................................15
3.2.1. The Quick-Start Request for CCID 3 .................15
3.2.2. Sending a Quick-Start Response with CCID 3 .........15
3.2.3. Using the Quick-Start Response with CCID 3 .........16
3.2.4. Quick-Start Validation Phase for CCID 3 ............17
3.2.5. Reported Loss or Congestion during the
Quick-Start Mode or Validation Phase ...............17
3.2.6. CCID 3 Feedback Traffic on the Reverse Path ........18
1. Introduction ....................................................3
1.1. Terminology ................................................4
2. Quick-Start for DCCP ............................................5
2.1. Sending a Quick-Start Request for a DCCP Flow ..............5
2.1.1. The Quick-Start Interval ............................5
2.2. Receiving a Quick-Start Request for a DCCP Flow ............6
2.2.1. The Quick-Start Response Option .....................7
2.3. Receiving a Quick-Start Response ...........................8
2.3.1. The Quick-Start Mode ................................8
2.3.2. The Quick-Start Validation Phase ....................9
2.4. Procedure When No Response to a Quick-Start Request .......10
2.5. Procedure When a Packet Is Dropped While Using
Quick-Start ...............................................11
2.6. Interactions with Mobility and Signaled Path Changes ......11
2.7. Interactions with Path MTU Discovery ......................12
2.8. Interactions with Middleboxes .............................12
3. Mechanisms for Specific CCIDs ..................................13
3.1. Quick-Start for CCID 2 ....................................13
3.1.1. The Quick-Start Request for CCID 2 .................13
3.1.2. Sending a Quick-Start Response with CCID 2 .........13
3.1.3. Using the Quick-Start Response with CCID 2 .........13
3.1.4. Quick-Start Validation Phase for CCID 2 ............14
3.1.5. Reported Loss or Congestion While Using
Quick-Start ........................................14
3.1.6. CCID 2 Feedback Traffic on the Reverse Path ........15
3.2. Quick-Start for CCID 3 ....................................15
3.2.1. The Quick-Start Request for CCID 3 .................15
3.2.2. Sending a Quick-Start Response with CCID 3 .........15
3.2.3. Using the Quick-Start Response with CCID 3 .........16
3.2.4. Quick-Start Validation Phase for CCID 3 ............17
3.2.5. Reported Loss or Congestion during the
Quick-Start Mode or Validation Phase ...............17
3.2.6. CCID 3 Feedback Traffic on the Reverse Path ........18
3.3. Quick-Start for CCID 4 ....................................18
3.3.1. The Quick-Start Request for CCID 4 .................18
3.3.2. Sending a Quick-Start Response with CCID 4 .........18
3.3.3. Using the Quick-Start Response with CCID 4 .........18
3.3.4. Reported Loss or Congestion While Using
Quick-Start ........................................19
3.3.5. CCID 4 Feedback Traffic on the Reverse Path ........19
4. Discussion of Issues ...........................................19
4.1. Overrun and the Quick-Start Validation Phase ..............19
4.2. Experimental Status .......................................19
5. IANA Considerations ............................................20
6. Acknowledgments ................................................20
7. Security Considerations ........................................20
8. References .....................................................21
8.1. Normative References ......................................21
8.2. Informative References ....................................21
3.3. Quick-Start for CCID 4 ....................................18
3.3.1. The Quick-Start Request for CCID 4 .................18
3.3.2. Sending a Quick-Start Response with CCID 4 .........18
3.3.3. Using the Quick-Start Response with CCID 4 .........18
3.3.4. Reported Loss or Congestion While Using
Quick-Start ........................................19
3.3.5. CCID 4 Feedback Traffic on the Reverse Path ........19
4. Discussion of Issues ...........................................19
4.1. Overrun and the Quick-Start Validation Phase ..............19
4.2. Experimental Status .......................................19
5. IANA Considerations ............................................20
6. Acknowledgments ................................................20
7. Security Considerations ........................................20
8. References .....................................................21
8.1. Normative References ......................................21
8.2. Informative References ....................................21
The Datagram Congestion Control Protocol (DCCP) [RFC4340] is a transport protocol for congestion-controlled, unreliable datagrams, intended for applications such as streaming media, Internet telephony, and online games.
数据报拥塞控制协议（DCCP）[RFC4340]是用于拥塞控制、不可靠数据报的传输协议，用于流媒体、互联网电话和在线游戏等应用。
In DCCP, an application has a choice of congestion control mechanisms, each specified by a Congestion Control Identifier (CCID) [RFC4340]. There are general procedures applicable to all DCCP CCIDs that are described in Section 2, and details that relate to how individual CCIDs should operate, which are described in Section 3. This separation of CCID-specific and DCCP general functions is in the spirit of the modular approach adopted by DCCP.
在DCCP中，应用程序可以选择拥塞控制机制，每个机制由拥塞控制标识符（CCID）[RFC4340]指定。第2节描述了适用于所有DCCP CCID的一般程序，第3节描述了与单个CCID应如何运行相关的细节。CCID特定功能和DCCP一般功能的分离符合DCCP采用的模块化方法的精神。
Quick-Start [RFC4782] is an experimental mechanism for transport protocols specified for use in controlled environments. The current specification of this mechanism is not intended or appropriate for ubiquitous deployment in the global Internet.
快速启动[RFC4782]是一种实验机制，用于指定在受控环境中使用的传输协议。此机制的当前规范不适用于全球互联网中的普遍部署。
Quick-Start is designed for use between end hosts within the same network or on Internet paths that include IP routers. It works in cooperation with routers, allowing a sender to determine an allowed sending rate at the start and at times in the middle of a data transfer (e.g., after an idle or application-limited period).
Quick Start设计用于同一网络内的终端主机之间或包含IP路由器的Internet路径上。它与路由器协同工作，允许发送者在数据传输的开始和中间时确定允许的发送速率（例如，在空闲或应用受限的时间之后）。
This document assumes the reader is familiar with RFC 4782 [RFC4782], which specifies the use of Quick-Start with IP and with TCP. Section 7 of RFC 4782 also provides guidelines for the use of Quick-Start
本文档假设读者熟悉RFC 4782[RFC4782]，其中规定了IP和TCP快速启动的使用。RFC 4782第7节还提供了使用快速启动的指南
with other transport protocols, including DCCP. This document provides answers to some of the issues that were raised by RFC 4782 and provides a definition of how Quick-Start must be used with DCCP.
与其他传输协议，包括DCCP。本文件回答了RFC 4782提出的一些问题，并定义了如何将快速启动与DCCP结合使用。
In using Quick-Start, the sending DCCP end host indicates the desired sending rate in bytes per second, using a Quick-Start option in the IP header of a DCCP packet. Each Quick-Start-capable 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.
在使用快速启动时，发送DCCP的终端主机使用DCCP数据包的IP报头中的快速启动选项以字节/秒为单位指示所需的发送速率。路径上的每个具有快速启动功能的路由器可以依次批准请求的速率、降低请求的速率或指示快速启动请求未被批准。
If the Quick-Start Request is approved (possibly with a reduced rate) by all the routers along the path, then the DCCP receiver returns an appropriate Quick-Start Response. On receipt of this, the sending end host can send at up to the approved rate for a period determined by the method specified for each DCCP CCID, and not exceeding three round-trip times. Subsequent transmissions will be governed by the default CCID congestion control mechanisms for the connection. If the Quick-Start Request is not approved, then the sender must use the default congestion control mechanisms.
如果路径上的所有路由器都批准了快速启动请求（可能会降低速率），则DCCP接收器将返回相应的快速启动响应。收到此信息后，发送端主机可在每个DCCP CCID指定的方法确定的时间段内，以批准的速率发送，但不超过三次往返时间。后续传输将由连接的默认CCID拥塞控制机制控制。如果快速启动请求未被批准，则发送方必须使用默认的拥塞控制机制。
DCCP receivers are not required to acknowledge individual packets (or pairs of segments) as in TCP. CCID 2 [RFC4341] allows much less frequent feedback. Rate-based protocols (e.g., TCP-Friendly Rate Control (TFRC) [RFC5348], CCID 3 [RFC4342]) have a different feedback mechanism than that of TCP. With rate-based protocols, feedback may be sent less frequently (e.g., once per Round-Trip Time (RTT)). In such cases, a sender using Quick-Start needs to implement a different mechanism to determine whether the Quick-Start sending rate has been sustained by the network. This introduces a new mechanism called the Quick-Start Validation Phase (Section 2.3).
DCCP接收器不需要像TCP中那样确认单个数据包（或段对）。CCID2[RFC4341]允许更少频率的反馈。基于速率的协议（例如，TCP友好速率控制（TFRC）[RFC5348]，CCID 3[RFC4342]）具有与TCP不同的反馈机制。使用基于速率的协议，反馈发送的频率可能会降低（例如，每往返时间（RTT）发送一次）。在这种情况下，使用快速启动的发送方需要实现不同的机制，以确定网络是否维持了快速启动发送速率。这引入了一种称为快速启动验证阶段的新机制（第2.3节）。
In addition, this document defines two more general enhancements that refine the use of Quick-Start after a flow has started (expected to be more common in applications using DCCP). These are the Quick-Start Interval (Section 2.1.2), and the reaction to mobility triggers (Section 2.6).
此外，本文档还定义了两个更通用的增强功能，它们改进了流启动后快速启动的使用（预计在使用DCCP的应用程序中会更常见）。这些是快速启动间隔（第2.1.2节）和对移动性触发器的反应（第2.6节）。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Unless otherwise specified, DCCP end hosts follow the procedures specified in Section 4 of [RFC4782], following the use specified for Quick-Start with TCP.
除非另有规定，否则DCCP终端主机遵循[RFC4782]第4节中规定的程序，使用TCP快速启动。
A DCCP sender MAY use a Quick-Start Request during the start of a connection, when the sender would prefer to have a larger initial rate than allowed by standard mechanisms (e.g., [RFC5348] or [RFC3390]).
当DCCP发送方希望初始速率大于标准机制（例如[RFC5348]或[RFC3390]）所允许的速率时，DCCP发送方可在连接启动期间使用快速启动请求。
A Quick-Start Request MAY also be used once a DCCP flow is connected (i.e., in the middle of a DCCP flow). In standard operation, DCCP CCIDs can constrain the sending rate (or window) to less than that desired (e.g., when an application increases the rate at which it wishes to send). A DCCP sender that has data to send after an idle period or application-limited period (i.e., where the sender has transmitted at less than the allowed sending rate) can send a Quick-Start Request using the procedures defined in Section 3.
一旦连接DCCP流（即，在DCCP流的中间），也可以使用快速启动请求。在标准操作中，DCCP CCID可以将发送速率（或窗口）限制为低于所需的速率（例如，当应用程序增加其希望发送的速率时）。DCCP发送方在空闲期或应用程序限制期（即，发送方以低于允许的发送速率发送数据）后，可以使用第3节中定义的程序发送快速启动请求。
Quick-Start Requests will be more effective if the Quick-Start Rate is not larger than necessary. Each requested Quick-Start Rate that has been approved, but was not fully utilized, takes away from the bandwidth pool maintained by Quick-Start routers that would be otherwise available for granting successive requests [RFC4782].
如果快速启动率不超过必要值，则快速启动请求将更加有效。已批准但未充分利用的每个请求的快速启动速率都会从快速启动路由器维护的带宽池中扣除，否则该带宽池将可用于授予连续请求[RFC4782]。
In contrast to most TCP applications, many DCCP applications have the notion of a natural media rate that they wish to achieve. For example, during the initial connection, a host may request a Quick-Start Rate equal to the media rate of the application, appropriately increased to account for the size of packet headers. (Note that Quick-Start only provides a course-grain indication of the desired rate that is expected to be sent in the next RTT.)
与大多数TCP应用程序相比，许多DCCP应用程序都有他们希望实现的自然媒体速率的概念。例如，在初始连接期间，主机可以请求等于应用程序的媒体速率的快速启动速率，该速率适当增加以考虑分组报头的大小。（请注意，“快速启动”仅提供预期在下一次RTT中发送的所需速率的课程粒度指示。）
When sending a Quick-Start Request, the DCCP sender SHOULD send the Quick-Start Request using a packet that requires an acknowledgement, such as a DCCP-Request, DCCP-Response, or DCCP-Data.
发送快速启动请求时，DCCP发送方应使用需要确认的数据包（如DCCP请求、DCCP响应或DCCP数据）发送快速启动请求。
Excessive use of the Quick-Start mechanism is undesirable. This document defines an enhancement to RFC 4782 to update the use of Quick-Start after a DCCP flow has started, by introducing the concept of the Quick-Start Interval. The Quick-Start Interval specifies a period of time during which a Quick-Start Request SHOULD NOT be sent. The Quick-Start Interval is measured from the time of transmission of
过度使用快速启动机构是不可取的。本文档通过引入快速启动间隔的概念，定义了对RFC 4782的增强，以更新DCCP流启动后快速启动的使用。快速启动间隔指定一段时间，在此期间不应发送快速启动请求。快速启动间隔从车辆的传输时间开始测量
the previous Quick-Start Request (Section 2.1). The Quick-Start Interval MAY be overridden as a result of a network path change (Section 2.6).
上一个快速启动请求（第2.1节）。快速启动间隔可能因网络路径更改而被覆盖（第2.6节）。
When a connection is established, the Quick-Start Interval is initialized to the Initial_QSI. The Initial_QSI MUST be at least 6 seconds (larger values are permitted). This value was chosen so that it is sufficiently large to prevent excessive router processing over typical Internet paths. Quick-Start routers that track per-flow state MAY penalize senders by suspending Quick-Start processing of flows that make Quick-Start Requests for the same flow with an interval less than 6 seconds.
建立连接后，快速启动间隔将初始化为初始_QSI。初始_QSI必须至少为6秒（允许较大值）。选择此值是为了使其足够大，以防止在典型的Internet路径上进行过多的路由器处理。跟踪每个流状态的快速启动路由器可能会通过暂停对相同流发出快速启动请求的流的快速启动处理（间隔小于6秒）来惩罚发送者。
When the first Quick-Start Request is sent, the Quick-Start Interval is set to:
发送第一个快速启动请求时，快速启动间隔设置为：
Quick-Start Interval = Initial_QSI;
快速启动间隔=初始_QSI；
After sending each subsequent Quick-Start Request, the Quick-Start Interval is then recalculated as:
发送每个后续快速启动请求后，快速启动间隔将重新计算为：
Quick-Start Interval = max(Quick-Start Interval * 2, 4 * RTT);
Quick-Start Interval = max(Quick-Start Interval * 2, 4 * RTT);
Each unsuccessful Quick-Start Request therefore results in the Quick-Start Interval being doubled (resulting in an exponential back-off). The maximum time the sender can back off is 64 seconds. When the back-off calculation results in a larger value, the sender MUST NOT send any further Quick-Start Requests for the remainder of the DCCP connection (i.e., the sender ceases to use Quick-Start).
因此，每个不成功的快速启动请求都会导致快速启动间隔加倍（导致指数级后退）。发送方可以后退的最长时间为64秒。当退避计算结果为较大值时，发送方不得为DCCP连接的其余部分发送任何进一步的快速启动请求（即，发送方停止使用快速启动）。
Whenever a Quick-Start Request is approved (at any rate), the Quick-Start Interval is reset to the Initial_QSI.
无论何时（无论如何）批准快速启动请求，快速启动间隔都会重置为初始的QSI。
The procedure for processing a received Quick-Start Request is normatively defined in [RFC4782] and summarized in this paragraph. An end host that receives an IP packet containing a Quick-Start Request passes the Quick-Start Request, along with the value in the IP Time to Live (TTL) field, to the receiving DCCP layer. If the receiving host is willing to permit the Quick-Start Request, it SHOULD respond immediately by sending a packet that carries the Quick-Start Response option in the DCCP header of the corresponding feedback packet (e.g., using a DCCP-Ack packet or in a DCCP-DataAck packet).
[RFC4782]对接收到的快速启动请求的处理程序进行了规范性定义，并在本段中进行了总结。接收包含快速启动请求的IP数据包的终端主机将快速启动请求连同IP生存时间（TTL）字段中的值一起传递给接收DCCP层。如果接收主机愿意允许快速启动请求，则应通过发送在相应反馈数据包的DCCP报头中携带快速启动响应选项的数据包（例如，使用DCCP Ack数据包或DCCP DATACK数据包）立即响应。
The Rate Request field 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 DCCP receiver is only willing to allow a lower Rate Request. Where information is available (e.g., knowledge of the local Layer 2 interface speed), a Quick-Start receiver SHOULD verify that the received rate does not exceed its expected receive link capacity. The TTL Diff field in the Quick-Start Response is set to the difference between the received IP TTL value (Hop Limit field in IPv6) and the Quick-Start TTL value. The Quick-Start Nonce in the Response is set to the received value of the Quick-Start Nonce in the Quick-Start option (or IPv6 Header Extension).
快速启动响应选项中的速率请求字段设置为快速启动选项中速率请求的接收值，或者如果DCCP接收器仅愿意允许较低速率请求，则设置为较低值。在信息可用的情况下（例如，了解本地第2层接口速度），快速启动接收器应验证接收速率未超过其预期接收链路容量。快速启动响应中的TTL Diff字段设置为接收到的IP TTL值（IPv6中的跃点限制字段）与快速启动TTL值之间的差值。响应中的快速启动Nonce设置为快速启动选项（或IPv6标头扩展）中快速启动Nonce的接收值。
The Quick-Start Response MUST NOT be resent if it is lost in the network [RFC4782]. 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.
如果快速启动响应在网络中丢失，则不得重新发送[RFC4782]。数据包丢失可能是返回路径上拥塞的指示；在这种情况下，最好不要批准快速启动请求。
If an end host receives an IP packet with a Quick-Start Request with a requested rate of zero, then this host SHOULD NOT send a Quick-Start Response [RFC4782].
如果终端主机接收到具有请求速率为零的快速启动请求的IP数据包，则该主机不应发送快速启动响应[RFC4782]。
The Quick-Start Response message must be carried by the transport protocol using Quick-Start. This section defines a DCCP Header option used to carry the Quick-Start Response. This header option is REQUIRED for end hosts to utilize the Quick-Start mechanism with DCCP flows. The format resembles that defined for TCP [RFC4782].
快速启动响应消息必须由使用快速启动的传输协议承载。本节定义了用于承载快速启动响应的DCCP标头选项。终端主机需要此标头选项才能利用DCCP流的快速启动机制。该格式类似于为TCP定义的格式[RFC4782]。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=45 | Length=8 | Resv. | Rate | TTL Diff |
| | | |Request| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Quick-Start 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=45 | Length=8 | Resv. | Rate | TTL Diff |
| | | |Request| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Quick-Start Nonce | R |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. The Quick-Start Response Option
图1。快速启动响应选项
The first byte of the Quick-Start Response option contains the option kind, identifying the DCCP option (45).
快速启动响应选项的第一个字节包含选项种类，标识DCCP选项（45）。
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 IP Quick-Start Rate Request option [RFC4782].
快速启动响应选项的第三个字节包含一个四位保留字段和四位允许速率请求，格式与IP快速启动速率请求选项[RFC4782]相同。
The fourth byte of the DCCP Quick-Start Response option contains the TTL Diff. The TTL Diff contains the difference between the IP TTL and Quick-Start TTL fields in the received Quick-Start Request packet, as calculated in [RFC4782].
DCCP快速启动响应选项的第四个字节包含TTL差异。TTL差异包含接收到的快速启动请求数据包中IP TTL和快速启动TTL字段之间的差异，如[RFC4782]中所计算。
Bytes 5-8 of the DCCP option contain the 30-bit Quick-Start Nonce and a 2-bit Reserved field [RFC4782].
DCCP选项的字节5-8包含30位快速启动Nonce和2位保留字段[RFC4782]。
On reception of a Quick-Start Response packet, the sender MUST report the approved rate, by sending a Quick-Start Report of Approved Rate [RFC4782]. This report includes the Rate Report field set to the Approved Rate, and the QS Nonce set to the QS Nonce value sent in the Quick-Start Request.
在接收到快速启动响应数据包时，发送方必须通过发送批准速率的快速启动报告来报告批准速率[RFC4782]。此报告包括设置为核准费率的费率报告字段，以及设置为快速启动请求中发送的QS Nonce值的QS Nonce。
The Quick-Start Report of Approved Rate is sent as an IPv4 option or IPv6 header extension using the first Quick-Start Packet or sent as an option using a DCCP control packet if there are no DCCP-Data packets pending transmission.
批准速率的快速启动报告使用第一个快速启动数据包作为IPv4选项或IPv6报头扩展发送，或者如果没有等待传输的DCCP数据包，则使用DCCP控制数据包作为选项发送。
The Quick-Start Interval is also reset (as described in Section 2.1.1).
快速启动间隔也被重置（如第2.1.1节所述）。
Reception of a Quick-Start Response packet that approves a rate higher than the current rate results in the sender entering the Quick-Start Mode.
接收到批准高于当前速率的速率的快速启动响应数据包会导致发送方进入快速启动模式。
While a sender is in the Quick-Start Mode, all sent packets are known as Quick-Start Packets [RFC4782]. The Quick-Start Packets MUST be sent at a rate not greater than the rate specified in the Quick-Start Response. The Quick-Start Mode continues for a period up to one RTT (shorter, if a feedback message arrives acknowledging the receipt of one or more Quick-Start Packets).
当发送方处于快速启动模式时，所有发送的数据包称为快速启动数据包[RFC4782]。必须以不大于快速启动响应中指定的速率发送快速启动数据包。快速启动模式持续时间长达一个RTT（如果收到一条或多条确认收到快速启动数据包的反馈消息，则时间更短）。
The procedure following exit of the Quick-Start Mode is specified in the following paragraphs. Note that this behavior is CCID-specific and the details for each current CCID are described in Section 3.
以下段落规定了快速启动模式退出后的程序。请注意，此行为是CCID特定的，每个当前CCID的详细信息在第3节中描述。
After transmitting a set of Quick-Start Packets in the Quick-Start Mode (and providing that no loss or congestion is reported), the sender enters the Quick-Start Validation Phase. This phase persists for a period during which the sender seeks to affirm that the capacity used by the Quick-Start Packets did not introduce congestion. This phase is introduced, because unlike TCP, DCCP senders do not necessarily receive frequent feedback that would indicate the congestion state of the forward path.
在快速启动模式下发送一组快速启动数据包后（并提供无丢失或拥塞报告），发送方进入快速启动验证阶段。此阶段持续一段时间，在此期间，发送方试图确认快速启动数据包使用的容量没有引起拥塞。引入此阶段是因为与TCP不同，DCCP发送方不一定会收到指示前向路径拥塞状态的频繁反馈。
While in the Quick-Start Validation Phase, the sender is tentatively permitted to continue sending using the Quick-Start rate. This phase normally concludes when the sender receives feedback that includes an acknowledgment that all Quick-Start Packets were received.
在快速启动验证阶段，暂时允许发送方使用快速启动速率继续发送。该阶段通常在发送方收到反馈时结束，该反馈包括所有快速启动数据包均已收到的确认。
However, the duration of the Quick-Start Validation Phase MUST NOT exceed the Quick-Start Validation Time (a maximum of 2 RTTs). Implementations may set a timer (initialized to the Quick-Start Validation Time) to detect the end of this phase. There may be scope for optimization of timer resources in an implementation, since the Quick-Start Validation period temporarily enforces more strict monitoring of acknowledgements than normally used in a CCID (e.g., an implementation may consider using a common timer resource for Quick-Start Validation and a nofeedback timer).
但是，快速启动验证阶段的持续时间不得超过快速启动验证时间（最多2个RTT）。实施可能会设置一个计时器（初始化为快速启动验证时间）来检测此阶段的结束。在实现中可能有优化定时器资源的范围，因为快速启动验证周期临时执行比通常在CCID中使用的确认更严格的监视（例如，实现可以考虑使用公共定时器资源来进行快速启动验证和NFF反馈定时器）。
An example sequence of packet exchanges showing Quick-Start with DCCP is shown in Figure 2.
图2显示了使用DCCP快速启动的数据包交换的示例序列。
DCCP Sender DCCP Receiver
Quick-Start +----------------------------------------------+
Request/Response | Quick-Start Request --> |
| <-- Quick-Start Response |
| Quick-Start Approve --> |
+----------------------------------------------+
+----------------------------------------------+
Quick-Start | Quick-Start Packets --> |
Mode | Quick-Start Packets --> |
| <-- Feedback A from Receiver|
| (acknowledging first QS Packet)|
+----------------------------------------------+
+----------------------------------------------
Quick-Start | Packets --> |
Validation Phase | <-- Feedback B from Receiver|
| (acknowledging all QS Packets)|
+----------------------------------------------
+----------------------------------------------+
DCCP | Packets --> |
Congestion | <-- Feedback C from Receiver|
Control | |
DCCP Sender DCCP Receiver
Quick-Start +----------------------------------------------+
Request/Response | Quick-Start Request --> |
| <-- Quick-Start Response |
| Quick-Start Approve --> |
+----------------------------------------------+
+----------------------------------------------+
Quick-Start | Quick-Start Packets --> |
Mode | Quick-Start Packets --> |
| <-- Feedback A from Receiver|
| (acknowledging first QS Packet)|
+----------------------------------------------+
+----------------------------------------------
Quick-Start | Packets --> |
Validation Phase | <-- Feedback B from Receiver|
| (acknowledging all QS Packets)|
+----------------------------------------------
+----------------------------------------------+
DCCP | Packets --> |
Congestion | <-- Feedback C from Receiver|
Control | |
Figure 2. The Quick-Start Mode and Validation Phase
图2。快速启动模式和验证阶段
On conclusion of the Validation Phase (Feedback B in the above figure), the sender expects to receive assurance that it may safely use the current rate. A sender that completes the Quick-Start Validation Phase with no reported packet loss or congestion stops using the Quick-Start rate and continues to adjust its rate using the standard congestion control mechanisms. For example, if the DCCP sender was in slow-start prior to the Quick-Start Request, and no packets were lost or ECN-marked (Explicit Congestion Notification) since that time, then the sender continues in slow-start after exiting Quick-Start Mode until the sender sees a packet loss, or congestion is reported.
在验证阶段结束时（上图中的反馈B），发送方希望收到可以安全使用当前费率的保证。完成快速启动验证阶段且未报告数据包丢失或拥塞的发送方将使用快速启动速率停止，并继续使用标准拥塞控制机制调整其速率。例如，如果DCCP发送方在快速启动请求之前处于慢速启动状态，并且自那时起没有数据包丢失或ECN标记（显式拥塞通知），则发送方在退出快速启动模式后继续慢速启动，直到发送方看到数据包丢失或报告拥塞。
As in TCP, if a Quick-Start Request is dropped (i.e., the Request or Response is not delivered by the network) the DCCP sender MUST revert to the congestion control mechanisms it would have used if the Quick-Start Request had not been approved. The connection is not permitted to send a subsequent Quick-Start Request before expiry of the current Quick-Start Interval (Section 2.1.1).
与TCP中一样，如果快速启动请求被丢弃（即，请求或响应未由网络传递），DCCP发送方必须恢复到在快速启动请求未被批准时将使用的拥塞控制机制。在当前快速启动间隔（第2.1.1节）到期之前，不允许连接发送后续快速启动请求。
A lost or ECN-marked packet is an indication of potential network congestion. The behavior of a DCCP sender following a lost or ECN-marked Quick-Start Packet or a lost feedback packet is specific to a particular CCID (see Section 3).
丢失或带有ECN标记的数据包表示潜在的网络拥塞。DCCP发送方在丢失或ECN标记的快速启动数据包或丢失反馈数据包后的行为特定于特定CCID（见第3节）。
The use of Quick-Start may assist end hosts in determining when it is appropriate to increase their rate following an explicitly signaled change of the network path.
快速启动的使用可以帮助终端主机确定在网络路径发生明确的信号变化后何时适合提高其速率。
When an end host receives a signal from an upstream link/network notifying it of a path change, the change could simultaneously impact more than one flow, and may affect flows between multiple endpoints. Senders should avoid responding immediately, since this could result in unwanted synchronization of signaling messages, and control loops (e.g., a synchronized attempt to probe for a larger congestion window), which may negatively impact the performance of the network and transport sessions. In Quick-Start, this could increase the rate of Quick-Start Requests, possibly incurring additional router load, and may result in some requests not being granted. A sender must ensure this does not generate an excessive rate of Quick-Start Requests by using the method below:
当终端主机从上游链路/网络接收到通知其路径更改的信号时，该更改可能同时影响多个流，并且可能影响多个端点之间的流。发送方应避免立即响应，因为这可能导致信令消息和控制环路的不必要同步（例如，同步尝试探测更大的拥塞窗口），这可能会对网络和传输会话的性能产生负面影响。在快速启动中，这可能会增加快速启动请求的速率，可能会导致额外的路由器负载，并可能导致某些请求无法获得授权。发送方必须使用以下方法确保不会产生过多的快速启动请求：
A sender that has explicit information that the network path has changed (e.g., a mobile IP binding update [RFC3344], [RFC3775]) SHOULD reset the Quick-Start Interval to its initial value (specified in Section 2.1.1).
具有网络路径已更改的明确信息（例如，移动IP绑定更新[RFC3344]、[RFC3775]）的发送方应将快速启动间隔重置为其初始值（在第2.1.1节中规定）。
The sender MAY also send a Quick-Start Request to determine a new safe transmission rate, but must observe the following rules:
发送方也可以发送快速启动请求以确定新的安全传输速率，但必须遵守以下规则：
- It MUST NOT send a Quick-Start Request within a period less than the initial Quick-Start Interval (Initial_QSI) since it previously sent a Quick-Start Request. That is, it must wait for at least a period of Initial_QSI after the previous request, before sending a new Quick-Start Request.
- 由于其之前发送了快速启动请求，因此不得在小于初始快速启动间隔（初始QSI）的时间段内发送快速启动请求。也就是说，在发送新的快速启动请求之前，它必须在上一个请求之后等待至少一段时间的初始_QSI。
- If it has not sent a Quick-Start Request within the previous Initial_QSI period, it SHOULD defer sending a Quick-Start Request for a randomly chosen period between 0 and the Initial_QSI value in seconds. The random period should be statistically independent between different hosts and between different connections on the same host. This delay is to mitigate the effect on router load of synchronized responses by multiple connections in response to a path change that affects multiple connections.
- 如果在前一个初始_QSI期间内未发送快速启动请求，则应将发送快速启动请求的时间延迟到0和初始_QSI值（以秒为单位）之间随机选择的时间段。不同主机之间以及同一主机上的不同连接之间的随机周期在统计上应该是独立的。此延迟是为了减轻多个连接响应影响多个连接的路径更改时对路由器负载的同步响应的影响。
Hosts do not generally have sufficient information to choose an appropriate randomization interval. This value was selected to ensure randomization of requests over the Quick-Start Interval. In networks where a large number of senders may potentially be impacted by the same signal, a larger value may be desirable (or methods may be used to control this effect in the path change signaling).
宿主通常没有足够的信息来选择适当的随机化间隔。选择此值是为了确保请求在快速启动间隔内随机化。在大量发送方可能受到相同信号影响的网络中，可能需要更大的值（或者可以使用方法来控制路径改变信令中的这种影响）。
DCCP implementations are encouraged to support Path MTU Discovery (PMTUD) when applications are able to use a DCCP packet size that exceeds the default Path MTU [RFC4340], [RFC4821]. Quick-Start Requests SHOULD NOT be sent with packets that are used as a PMTUD Probe Packet, since these packets could be lost in the network increasing the probability of loss of the request. It may therefore be preferable to separately negotiate the PMTU and the use of Quick-Start.
当应用程序能够使用超过默认路径MTU[RFC4340]、[RFC4821]的DCCP数据包大小时，鼓励DCCP实现支持路径MTU发现（PMTUD）。快速启动请求不应与用作PMTUD探测数据包的数据包一起发送，因为这些数据包可能在网络中丢失，从而增加请求丢失的概率。因此，最好单独协商PMTU和快速启动的使用。
The DCCP protocol is datagram-based and therefore the size of the segments that are sent is a function of application behavior as well as being constrained by the largest supported Path MTU.
DCCP协议基于数据报，因此发送的段的大小是应用程序行为的函数，并且受最大支持路径MTU的约束。
A Quick-Start Request is carried in an IPv4 packet option or IPv6 extension header [RFC4782]. Interactions with network devices (middleboxes) that inspect or modify IP options could therefore lead to discard, ICMP error, or DCCP-Reset when attempting to forward packets carrying a Quick-Start Request.
快速启动请求在IPv4数据包选项或IPv6扩展头[RFC4782]中进行。因此，当尝试转发携带快速启动请求的数据包时，与检查或修改IP选项的网络设备（中间盒）的交互可能导致丢弃、ICMP错误或DCCP重置。
If a DCCP sender sends a DCCP-Request that also carries a Quick-Start Request, and does not receive a DCCP-Response to the packet, the DCCP sender SHOULD resend the DCCP-Request packet without including a Quick-Start Request.
如果DCCP发送方发送的DCCP请求也包含快速启动请求，且未收到对数据包的DCCP响应，则DCCP发送方应在不包含快速启动请求的情况下重新发送DCCP请求数据包。
Similarly, if a DCCP sender receives a DCCP-Reset in response to a DCCP-Request packet that also carries a Quick-Start Request, then the DCCP sender SHOULD resend the DCCP-Request packet without the Quick-Start Request. The DCCP sender then ceases to use the Quick-Start Mechanism for the remainder of the connection.
类似地，如果DCCP发送方收到DCCP重置，以响应也携带快速启动请求的DCCP请求数据包，则DCCP发送方应在没有快速启动请求的情况下重新发送DCCP请求数据包。然后，DCCP发送器将停止对其余连接使用快速启动机制。
A DCCP sender that uses a Quick-Start Request within an established connection and does not receive a response will treat this as non-approval of the request. Successive unsuccessful attempts will result in an exponential increase in the Quick-Start Interval (Section 2.1.1). If this grows to a value exceeding 64 seconds, the DCCP sender ceases to use the Quick-Start Mechanism for the remainder of the connection.
在已建立的连接中使用快速启动请求但未收到响应的DCCP发送方将视为未批准该请求。连续不成功的尝试将导致快速启动间隔指数增加（第2.1.1节）。如果该值增长到超过64秒，DCCP发送方将停止对其余连接使用快速启动机制。
The following sections specify the use of Quick-Start with DCCP CCID 2, CCID 3, and for DCCP with TFRC-SP as specified in CCID 4.
以下章节规定了DCCP CCID 2、CCID 3和CCID 4中规定的TFRC-SP的DCCP快速启动的使用。
This section describes the Quick-Start mechanism to be used with DCCP CCID 2 [RFC4341]. CCID 2 uses a TCP-like congestion control mechanism.
本节介绍与DCCP CCID 2[RFC4341]一起使用的快速启动机制。CCID2使用类似TCP的拥塞控制机制。
A Quick-Start Request MAY be sent to allow the sender to determine if it is safe to use a larger initial cwnd. This permits a faster start-up of a new CCID 2 flow.
可以发送快速启动请求，以允许发送方确定使用较大的初始cwnd是否安全。这允许更快地启动新的CCID 2流。
A Quick-Start Request MAY also be sent for an established connection to request a higher sending rate after an idle period or application-limited period (described in Section 2.1). This allows a receiver to use a larger cwnd than allowed with standard operation.
还可以为已建立的连接发送快速启动请求，以在空闲期或应用限制期（如第2.1节所述）后请求更高的发送速率。这允许接收器使用比标准操作允许的更大的cwnd。
A Quick-Start Request that follows a reported loss or congestion event MUST NOT request a Quick-Start rate that exceeds the largest congestion window achieved by the CCID 2 connection since the last packet drop (translated to a sending rate).
报告的丢失或拥塞事件之后的快速启动请求不得请求超过自上次丢包（转换为发送速率）以来CCID 2连接实现的最大拥塞窗口的快速启动速率。
A receiver processing a Quick-Start Request uses the method described in Section 2.3. On receipt of a Quick-Start Request, the receiver MUST send a Quick-Start Response (even if a receiver is constrained by the ACK Ratio).
处理快速启动请求的接收器使用第2.3节中描述的方法。在收到快速启动请求时，接收器必须发送快速启动响应（即使接收器受到ACK比率的限制）。
On receipt of a valid Quick-Start Response option, the sender MUST send a Quick-Start Approved option [RFC4782] (see Section 2.3).
收到有效的快速启动响应选项后，发送方必须发送快速启动批准选项[RFC4782]（见第2.3节）。
If the approved Quick-Start rate is less than current sending rate, the sender does not enter the Quick-Start Mode, and continues using the procedure defined in CCID 2.
如果批准的快速启动速率小于当前发送速率，则发送方不会进入快速启动模式，并继续使用CCID 2中定义的程序。
If the approved Quick-Start rate at the sender exceeds the current sending rate, the sender enters the Quick-Start Mode and continues in the Quick-Start Mode for a maximum period of one RTT.
如果发送方批准的快速启动速率超过当前发送速率，发送方将进入快速启动模式，并在快速启动模式下持续最长一个RTT。
The sender sets its Quick-Start cwnd (QS_cwnd) as follows:
发送方将其快速启动cwnd（QS_cwnd）设置如下：
QS_cwnd = (R * T) / (s + H) (1)
QS_cwnd = (R * T) / (s + H) (1)
where R is the Rate Request in bytes per second, T is the measured round-trip path delay (RTT), s is the packet size, and H is the estimated DCCP/IP header size in bytes (e.g., 32 bytes for DCCP layered directly over IPv4, but larger when using IPsec or IPv6).
其中R是以字节/秒为单位的速率请求，T是测量的往返路径延迟（RTT），s是数据包大小，H是以字节为单位的估计DCCP/IP报头大小（例如，直接通过IPv4分层的DCCP为32字节，但在使用IPsec或IPv6时更大）。
A CCID 2 sender MAY then increase its cwnd to the QS_cwnd. The cwnd should not be reduced (i.e., a QS_cwnd lower than cwnd should be ignored, since the CCID 2 congestion control method already permits this rate). CCID 2 is not a rate-paced protocol. Therefore, if the QS_cwnd is used, the sending host MUST implement a suitable method to pace the rate at which the Quick-Start Packets are sent until it receives a DCCP-ACK for a packet sent during the Quick-Start Mode [RFC4782]. The sending host SHOULD also record the previous cwnd and note that the new cwnd has been determined by Quick-Start, rather by other means (e.g., by setting a flag to indicate that it is in Quick-Start Mode).
CCID 2发送方随后可以将其cwnd增加到QS_cwnd。不应减少cwnd（即，应忽略低于cwnd的QS_cwnd，因为CCID 2拥塞控制方法已经允许此速率）。CCID2不是一种速率控制协议。因此，如果使用QS_cwnd，发送主机必须实施适当的方法来调整快速启动数据包的发送速率，直到接收到在快速启动模式下发送的数据包的DCCP-ACK[RFC4782]。发送主机还应记录以前的cwnd，并注意新cwnd是通过快速启动而不是通过其他方式确定的（例如，通过设置标志指示其处于快速启动模式）。
When the sender receives the first DCCP-ACK to a packet sent in the Quick-Start Mode, it leaves the Quick-Start Mode and enters the Validation Phase.
当发送方收到以快速启动模式发送的数据包的第一个DCCP-ACK时，它将离开快速启动模式并进入验证阶段。
A CCID 2 sender MAY continue to send at the paced Quick-Start Rate while in the Validation Phase. It leaves the Validation Phase on receipt of an ACK that acknowledges the last Quick-Start Packet, or if the validation phase persists for a period that exceeds the Quick-Start Validation Time of 1 RTT. It MUST then reduce the cwnd to the actual flight size (the current amount of unacknowledged data sent) [RFC4782] and uses the congestion control methods specified for CCID 2.
CCID 2发送方在验证阶段可能会继续以有节奏的快速启动速率发送。它在收到确认最后一个快速启动数据包的ACK时离开验证阶段，或者如果验证阶段持续时间超过快速启动验证时间1 RTT，则离开验证阶段。然后必须将cwnd减小到实际航班大小（当前发送的未确认数据量）[RFC4782]，并使用CCID 2指定的拥塞控制方法。
A sender in the Quick-Start Mode (or Validation Phase) that detects congestion (e.g., receives a feedback packet that reports new packet loss or a packet with a congestion marking), MUST immediately leave the Quick-Start Mode (or Validation Phase). It then resets the cwnd to half the recorded previous cwnd and enters the congestion avoidance phase described in [RFC4341].
处于快速启动模式（或验证阶段）且检测到拥塞的发送方（例如，接收到报告新数据包丢失的反馈数据包或带有拥塞标记的数据包）必须立即离开快速启动模式（或验证阶段）。然后，它将cwnd重置为之前记录的cwnd的一半，并进入[RFC4341]中所述的拥塞避免阶段。
In the absence of any feedback at the end of the Validation period, the sender resets the cwnd to half the recorded previous cwnd and enters the congestion avoidance phase.
在验证期结束时没有任何反馈的情况下，发送方将cwnd重置为之前记录的cwnd的一半，并进入拥塞避免阶段。
A CCID 2 receiver sends feedback for groups of received packets [RFC4341]. Approval of a higher transmission rate using Quick-Start will increase control traffic on the reverse path. A return path that becomes congested could have a transient negative impact on other traffic flows sharing the return link. The lower rate of feedback will then limit the achievable rate in the forward direction.
CCID 2接收器发送接收分组的反馈[RFC4341]。使用快速启动批准更高的传输速率将增加反向路径上的控制流量。阻塞的返回路径可能会对共享返回链路的其他交通流产生短暂的负面影响。较低的反馈率将限制前进方向上的可实现速率。
This section describes the Quick-Start mechanism to be used with DCCP CCID 3 [RFC4342]. The rate-based congestion control mechanism used by CCID 3 leads to specific issues that are addressed by Quick-Start in this section.
本节介绍与DCCP CCID 3[RFC4342]一起使用的快速启动机制。CCID 3使用的基于速率的拥塞控制机制导致了本节中Quick Start解决的具体问题。
A Quick-Start Request MAY be sent to allow the sender to determine if it is safe to use a larger initial sending rate. This permits a faster start-up of a new CCID 3 flow.
可以发送快速启动请求，以允许发送方确定使用较大的初始发送速率是否安全。这允许更快地启动新的CCID 3流。
A Quick-Start Request MAY also be sent to request a higher sending rate after an idle period (in which the nofeedback timer expires [RFC5348]) or an application-limited period (described in Section 2.1). This allows a receiver to increase the sending rate faster than allowed with standard operation (i.e., faster than twice the rate reported by a CCID 3 receiver in the most recent feedback message).
也可以发送快速启动请求，以在空闲期（无反馈定时器到期[RFC5348]）或应用限制期（如第2.1节所述）后请求更高的发送速率。这允许接收机以高于标准操作允许的速度增加发送速率（即，快于CCID 3接收机在最新反馈消息中报告的速率的两倍）。
The requested rate specified in a Quick-Start Request MUST NOT exceed the TFRC-controlled sending rate [RFC4342] when this is bounded by the current loss event rate (if any), either from calculation at the sender or from feedback received from the receiver. CCID 3 considers this rate is a safe response in the presence of expected congestion.
快速启动请求中指定的请求速率不得超过TFRC控制的发送速率[RFC4342]，前提是该速率受当前丢失事件速率（如果有）的限制，无论是从发送方的计算还是从接收方收到的反馈。CCID 3认为该速率是在存在预期拥塞时的安全响应。
When processing a received Quick-Start Request, the receiver uses the method described in Section 2.3. In addition, if a CCID 3 receiver uses the window counter to send periodic feedback messages, then the receiver sets its local variable last_counter to the value of the window counter reported by the segment containing the Quick-Start Request. The next feedback message would then be sent when the window_counter is greater or equal to last_counter + 4. If the CCID 3 receiver uses a feedback timer to send period feedback messages, then the receiver MUST reset the CCID 3 feedback timer, causing the
当处理收到的快速启动请求时，接收器使用第2.3节中描述的方法。此外，如果CCID 3接收器使用窗口计数器发送周期性反馈消息，则接收器将其局部变量last_计数器设置为包含快速启动请求的段报告的窗口计数器的值。当窗口计数器大于或等于最后一个计数器+4时，将发送下一条反馈消息。如果CCID 3接收器使用反馈定时器发送周期反馈消息，则接收器必须重置CCID 3反馈定时器，从而导致
feedback to be sent as soon as possible. This helps to align the timing of feedback to the start and end of the period in which Quick-Start Packets are sent, and will normally result in feedback at a time that is approximately the end of the period when Quick-Start Packets are received.
尽快发送反馈。这有助于将反馈的定时与发送快速启动数据包的时间段的开始和结束对齐，并且通常会在接收到快速启动数据包的时间段结束时产生反馈。
On receipt of a valid Quick-Start Response option, the sender MUST send a Quick-Start Approved option [RFC4782] (see Section 2.3). The sender then uses one of three procedures:
收到有效的快速启动响应选项后，发送方必须发送快速启动批准选项[RFC4782]（见第2.3节）。然后，发送方使用以下三个过程之一：
* If the approved Quick-Start rate is less than the current sending rate, the sender does not enter the Quick-Start Mode and continues using the procedure defined in CCID 3.
* 如果批准的快速启动速率小于当前发送速率，则发送方不会进入快速启动模式，并继续使用CCID 3中定义的程序。
* If loss or congestion is reported after sending the Quick-Start Request, the sender also does not enter the Quick-Start Mode and continues using the procedure defined in CCID 3.
* 如果发送快速启动请求后报告丢失或拥塞，发送方也不会进入快速启动模式，并继续使用CCID 3中定义的程序。
* If the approved Quick-Start rate exceeds the current sending rate, the sender enters the Quick-Start Mode and continues in the Quick-Start Mode for a maximum period of 1 RTT. The sender sets its Quick-Start sending rate (QS_sendrate) as follows:
* 如果批准的快速启动速率超过当前发送速率，发送方将进入快速启动模式，并在快速启动模式下持续最长时间1 RTT。发送方将其快速启动发送速率（QS_sendrate）设置如下：
QS_sendrate = R * s/(s + H); (2)
QS_sendrate = R * s/(s + H); (2)
where R the Rate Request in bytes per second, s is the packet size [RFC4342], and H the estimated DCCP/IP header size in bytes (e.g., 32 bytes for IPv4). A CCID 3 host MAY then increase its sending rate to the QS_sendrate. The rate should not be reduced.
其中，R是以字节/秒为单位的速率请求，s是数据包大小[RFC4342]，H是以字节为单位的估计DCCP/IP报头大小（例如，IPv4为32字节）。然后，CCID 3主机可以提高其发送至QS_发送速率。这一比率不应降低。
CCID 3 is a rate-paced protocol. Therefore, if the QS_sendrate is used, the sending host MUST pace the rate at which the Quick-Start Packets are sent over the next RTT. The sending host SHOULD also record the previous congestion-controlled rate and note that the new rate has been determined by Quick-Start rather by other means (e.g., by setting a flag to indicate that it is in the Quick-Start Mode).
CCID3是一种速率控制协议。因此，如果使用QS_sendrate，发送主机必须调整通过下一RTT发送快速启动数据包的速率。发送主机还应记录以前的拥塞控制速率，并注意新速率是通过快速启动而不是通过其他方式确定的（例如，通过设置标志指示其处于快速启动模式）。
The sender exits the Quick-Start Mode after either:
发送器在以下任一情况下退出快速启动模式：
* Receipt of a feedback packet acknowledging one or more Quick-Start Packets,
* 接收确认一个或多个快速启动数据包的反馈数据包，
* A period of 1 RTT after receipt of a Quick-Start Response, or
* 收到快速启动响应后1 RTT的时间段，或
* Detection of a loss or congestion event (see Section 3.2.5).
* 检测丢失或拥塞事件（见第3.2.5节）。
After transmitting a set of Quick-Start Packets in the Quick Start Mode (and providing that no loss or congestion marking is reported), the sender enters the Quick-Start Validation Phase. A sender that receives feedback that reports a loss or congestion event MUST follow the procedures described in Section 3.2.5.
在快速启动模式下发送一组快速启动数据包后（并且假设未报告丢失或拥塞标记），发送方进入快速启动验证阶段。收到报告丢失或拥塞事件的反馈的发送方必须遵循第3.2.5节所述的程序。
The sender MUST exit the Quick-Start Validation Phase on receipt of feedback that acknowledges all packets sent in the Quick-Start Mode (i.e., all Quick-Start Packets) or if the Validation Phase persists for a period that exceeds the Quick-Start Validation Time of two RTTs.
发送方必须在收到确认以快速启动模式发送的所有数据包（即所有快速启动数据包）的反馈后退出快速启动验证阶段，或者验证阶段持续时间超过两个RTT的快速启动验证时间。
A sender that completes the Quick-Start Validation Phase with no reported packet loss or congestion stops using the QS_sendrate and MUST recalculate a suitable sending rate using the standard congestion control mechanisms [RFC4342].
完成快速启动验证阶段且未报告数据包丢失或拥塞的发送方将使用QS_sendrate停止，并且必须使用标准拥塞控制机制重新计算合适的发送速率[RFC4342]。
If no feedback is received within the Quick-Start Validation Phase, the sender MUST return to the minimum of the recorded original rate (at the start of the Quick-Start Mode) and one half of the QS_sendrate. The nofeedback timer is also reset.
如果在快速启动验证阶段未收到反馈，发送方必须返回记录的原始速率（在快速启动模式开始时）和QS_sendrate的一半。nofeedback定时器也会重置。
3.2.5. Reported Loss or Congestion during the Quick-Start Mode or Validation Phase
3.2.5. 在快速启动模式或验证阶段报告的丢失或拥塞
A sender in the Quick-Start Mode or Validation Phase that detects congestion (e.g., receives a feedback packet that reports new packet loss or a packet with a congestion marking) MUST immediately leave the Quick-Start Mode or Validation Phase and enter the congestion avoidance phase [RFC4342]. This implies re-calculating the sending rate, X, as required by RFC 4342:
处于快速启动模式或验证阶段且检测到拥塞的发送方（例如，接收报告新数据包丢失的反馈数据包或带有拥塞标记的数据包）必须立即离开快速启动模式或验证阶段并进入拥塞避免阶段[RFC4342]。这意味着按照RFC 4342的要求重新计算发送速率X：
X = max(min(X_calc, 2*X_recv), s/t_mbi);
X = max(min(X_calc, 2*X_recv), s/t_mbi);
where X_calc is the transmit rate calculated by the throughput equation, X_recv is the reported receiver rate, s is the packet size and t_mbi is the maximum back-off interval of 64 seconds.
其中X_calc是通过吞吐量方程计算的传输速率，X_recv是报告的接收速率，s是数据包大小，t_mbi是64秒的最大退避间隔。
The current specification of TFRC [RFC5348], which obsoletes RFC 3448, uses a set of X_recv values and uses the maximum of the set during application-limited intervals. This calculates the sending rate, X as:
淘汰RFC 3448的TFRC[RFC5348]当前规范使用一组X_recv值，并在应用限制间隔期间使用最大值。这会将发送速率X计算为：
X = max(min(X_calc, recv_limit),s/t_mbi);
X = max(min(X_calc, recv_limit),s/t_mbi);
where recv_limit could be max(X_recv_set) or 2*max(X_recv_set) depending on whether there was a new loss event during a data-limited interval, or no loss event during an application-limited interval respectively. When the sender is not application-limited, the recv_limit is set to 2*max(X_recv_set).
其中，recv_limit可以是max（X_recv_set）或2*max（X_recv_set），具体取决于在数据限制间隔期间是否存在新的丢失事件，或者在应用程序限制间隔期间是否没有丢失事件。当发送方不受应用程序限制时，recv_limit设置为2*max（X_recv_set）。
A sender using RFC 4342 updated by [RFC5348], calculates the sending rate, X, using the above formula normatively defined in [RFC5348].
发送方使用[RFC5348]更新的RFC 4342，使用[RFC5348]中标准定义的上述公式计算发送速率X。
A CCID 3 receiver sends feedback at least once each RTT [RFC4342]. Use of Quick-Start is therefore not expected to significantly increase control traffic on the reverse path.
CCID 3接收器在每个RTT[RFC4342]中至少发送一次反馈。因此，使用快速启动预计不会显著增加反向路径上的控制流量。
This section describes the Quick-Start mechanism to be used when DCCP uses TFRC-SP [RFC4828] in place of TFRC [RFC5348], as specified in CCID 4 [RFC5622]. CCID 4 is similar to CCID 3 except that a sender using CCID 4 is limited to a maximum of 100 packets/second.
本节描述了当DCCP使用TFRC-SP[RFC4828]代替CCID 4[RFC5622]中规定的TFRC[RFC5348]时使用的快速启动机制。CCID 4与CCID 3类似，不同之处在于使用CCID 4的发送方最多限制为100个数据包/秒。
The Quick-Start procedure defined below therefore resembles that for CCID 3.
因此，下文定义的快速启动程序与CCID 3类似。
The procedure for sending a Quick-Start Request using CCID 4 is the same as for CCID 3, defined in Section 3.2.1. In addition, the requested rate MUST be less than or equal to the equivalent of a sending rate of 100 packets per second [RFC4828]. CCID 4 [RFC4828] specifies that the allowed sending rate derived from the TCP throughput equation is reduced by a factor that accounts for packet header size.
使用CCID 4发送快速启动请求的程序与第3.2.1节中定义的CCID 3相同。此外，请求的速率必须小于或等于每秒100个数据包的发送速率[RFC4828]。CCID 4[RFC4828]规定，从TCP吞吐量方程导出的允许发送速率将减少一个因子，该因子考虑了数据包头的大小。
This procedure is the same as for CCID 3, defined in Section 3.2.2.
本程序与第3.2.2节中定义的CCID 3相同。
This procedure is the same as for CCID 3, defined in Sections 3.2.3, 3.2.4, and 3.2.5, except that the congestion control procedures is updated to use TFRC-SP [RFC4828].
该程序与第3.2.3节、第3.2.4节和第3.2.5节中定义的CCID 3相同，只是拥塞控制程序更新为使用TFRC-SP[RFC4828]。
A CCID 4 sender does not need to account for headers a second time when translating the approved Quick-Start rate into an allowed sending rate (as described in Section 5 of [RFC5622].
当将批准的快速启动速率转换为允许的发送速率时（如[RFC5622]第5节所述），CCID 4发送方无需第二次说明报头。
This procedure is the same as for CCID 3, defined in Section 3.2.5, except that the congestion control procedures is updated to use TFRC-SP [RFC4828].
该程序与第3.2.5节中定义的CCID 3相同，只是拥塞控制程序更新为使用TFRC-SP[RFC4828]。
A CCID 4 receiver sends feedback at least once each RTT. Use of Quick-Start is therefore not expected to significantly increase control traffic on the reverse path.
CCID4接收器在每个RTT中至少发送一次反馈。因此，使用快速启动预计不会显著增加反向路径上的控制流量。
The considerations for using Quick-Start with DCCP are not significantly different to those for Quick-Start with TCP. The document does not modify the router behavior specified for Quick-Start.
使用DCCP快速启动的注意事项与使用TCP快速启动的注意事项没有显著差异。文档不会修改为快速启动指定的路由器行为。
The less frequent feedback of DCCP raises an issue in that a sender using Quick-Start may continue to use the rate specified by a Quick-Start Response for a period that exceeds one path round trip time (i.e., that which TCP would have used). This overrun is a result of the less frequent feedback interval used by DCCP (i.e., CCID 2 may delay feedback by at most one half cwnd and CCID 3 and CCID 4 provide feedback at least once per RTT). In the method specified by this document, the Quick-Start Validation Phase bounds this overrun to be not more than an additional two RTTs.
DCCP不太频繁的反馈引发了一个问题，即使用快速启动的发送方可能会在超过一条路径往返时间（即TCP本应使用的时间）的一段时间内继续使用快速启动响应指定的速率。这种超限是由于DCCP使用的反馈间隔频率较低（即，CCID 2可将反馈延迟至多一半cwnd，CCID 3和CCID 4在每个RTT至少提供一次反馈）。在本文档指定的方法中，快速启动验证阶段将此溢出限制为不超过额外的两个RTT。
The selected method was chosen as a compromise that reflects the need to terminate quickly following the loss of a feedback packet, and the need to allow sufficient time for end host and router processing, as well as the different perceptions of the path RTT held at the sender and receiver. Any reported loss or congestion results in immediate action without waiting for completion of the Quick-Start Validation period.
选择所选方法作为折衷方案，以反映在反馈数据包丢失后快速终止的需要，以及为终端主机和路由器处理留出足够时间的需要，以及发送方和接收方对路径RTT的不同看法。任何报告的丢失或拥塞都会导致立即采取行动，而无需等待快速启动验证期的完成。
There are many cases in which Quick-Start Requests would not be approved [RFC4782]. These include communication over paths containing routers, IP tunnels, MPLS paths, and the like, that do not support Quick-Start. These cases also include paths with routers or middleboxes that drop packets containing IP options (or IPv6 extensions). Quick-Start Requests could be difficult to approve over paths that include multi-access Layer-2 networks.
在许多情况下，快速启动请求不会得到批准[RFC4782]。这些包括通过包含不支持快速启动的路由器、IP隧道、MPLS路径等的路径进行的通信。这些情况还包括带有路由器或中间盒的路径，这些路由器或中间盒丢弃包含IP选项（或IPv6扩展）的数据包。快速启动请求可能很难通过包含多访问层2网络的路径进行批准。
Transient effects could arise when the transport protocol packets associated with a connection are multiplexed over multiple parallel (sometimes known as alternative) links or network-layer paths, and Quick-Start is used, since it will be effective on only one of the paths, but could lead to increased traffic on all paths.
当与连接相关联的传输协议数据包在多个并行（有时称为备用）链路或网络层路径上多路复用，并且使用快速启动时，可能会产生瞬态效应，因为快速启动仅对其中一条路径有效，但可能会导致所有路径上的流量增加。
A CCID 2 sender using Quick-Start can increase the control traffic on the reverse path, which could have a transient negative impact on other traffic flows sharing the return link (Section 3.1.6). The lower rate of feedback will then limit the achievable rate in the forward direction.
使用快速启动的CCID 2发送器会增加反向路径上的控制流量，这可能会对共享返回链路的其他流量产生短暂的负面影响（第3.1.6节）。较低的反馈率将限制前进方向上的可实现速率。
[RFC4782] also describes environments where the Quick-Start mechanism 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 the seeming absence of motivation for routers, such as core routers, to deploy Quick-Start, Quick-Start has been proposed as a mechanism that could be of use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet.
[RFC4782]还描述了快速启动机制可能因误报而失败的环境，发送方错误地认为快速启动请求已被路径上的所有路由器批准。由于这些问题，以及由于路由器（如核心路由器）部署快速启动的困难和缺乏动机，快速启动被提议作为一种可在受控环境中使用的机制，而不是作为一种旨在或适合在全球互联网上普遍部署的机制。
Further experimentation would be required to confirm the deployment of Quick-Start and to investigate performance issues that may arise, prior to any recommendation for use over the general Internet.
在建议在通用互联网上使用之前，需要进一步的实验来确认快速启动的部署，并调查可能出现的性能问题。
IANA has assigned a DCCP Option Type (45) from the DCCP Option Types Registry. This Option is applicable to all CCIDs and is known as the "Quick-Start Response" Option and is defined in Section 2.2.1. It specifies a length value in the format used for options numbered 32-128.
IANA已从DCCP选项类型注册表中分配了DCCP选项类型（45）。该选项适用于所有CCID，称为“快速启动响应”选项，定义见第2.2.1节。它以用于编号为32-128的选项的格式指定长度值。
The author gratefully acknowledges the previous work by Sally Floyd to identify issues that impact Quick-Start for DCCP, and her comments to improve this document. We also acknowledge comments and corrections from Pasi Sarolahti, Vincent Roca, Mark Allman, Michael Scharf, and others in the IETF DCCP Working Group (WG).
作者非常感谢Sally Floyd之前为确定影响DCCP快速启动的问题所做的工作，以及她为改进本文档所做的评论。我们还感谢Pasi Sarolahti、Vincent Roca、Mark Allman、Michael Scharf和IETF DCCP工作组（WG）其他人的评论和更正。
Security issues are discussed in [RFC4782]. Middlebox deployment issues are also highlighted in Section 2.8. No new security issues are raised within this document.
[RFC4782]中讨论了安全问题。第2.8节还强调了中间盒部署问题。本文档中未提出任何新的安全问题。
[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月。
[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月。
[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, March 2006.
[RFC4342]Floyd，S.，Kohler，E.，和J.Padhye，“数据报拥塞控制协议（DCCP）拥塞控制ID 3的配置文件：TCP友好速率控制（TFRC）”，RFC 43422006年3月。
[RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-Start for TCP and IP", RFC 4782, January 2007.
[RFC4782]Floyd，S.，Allman，M.，Jain，A.，和P.Sarolahti，“TCP和IP的快速启动”，RFC 4782，2007年1月。
[RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant", RFC 4828, April 2007.
[RFC4828]Floyd，S.和E.Kohler，“TCP友好速率控制（TFRC）：小数据包（SP）变体”，RFC 48282007年4月。
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008.
[RFC5348]Floyd，S.，Handley，M.，Padhye，J.，和J.Widmer，“TCP友好速率控制（TFRC）：协议规范”，RFC 5348，2008年9月。
[RFC5622] Floyd, S., and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)", RFC 5622, August 2009.
[RFC5622]Floyd，S.和E.Kohler，“数据报拥塞控制协议（DCCP）拥塞ID 4的配置文件：小数据包的TCP友好速率控制（TFRC-SP）”，RFC 5622，2009年8月。
[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]Perkins，C.，Ed.，“IPv4的IP移动支持”，RFC 3344，2002年8月。
[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月。
[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月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 48212007年3月。
Authors' Addresses
作者地址
Godred Fairhurst School of Engineering University of Aberdeen Aberdeen, AB24 3UE Scotland, UK
阿伯丁大学GoRead FelHurt工程学院阿伯丁，苏格兰AB24 3UE，英国
EMail: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk/users/gorry
EMail: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk/users/gorry
Arjuna Sathiaseelan School of Engineering University of Aberdeen Aberdeen, AB24 3UE Scotland, UK
阿朱那SaTiaSeeleAn阿伯丁大学工程学院阿伯丁，AB24 3UE苏格兰，英国
EMail: arjuna@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk/users/arjuna
EMail: arjuna@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk/users/arjuna