Network Working Group S. Floyd
Request for Comments: 4336 ICIR
Category: Informational M. Handley
UCL
E. Kohler
UCLA
March 2006
Network Working Group S. Floyd
Request for Comments: 4336 ICIR
Category: Informational M. Handley
UCL
E. Kohler
UCLA
March 2006
Problem Statement for the Datagram Congestion Control Protocol (DCCP)
数据报拥塞控制协议（DCCP）的问题陈述
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document describes for the historical record the motivation behind the Datagram Congestion Control Protocol (DCCP), an unreliable transport protocol incorporating end-to-end congestion control. DCCP implements a congestion-controlled, unreliable flow of datagrams for use by applications such as streaming media or on-line games.
本文档为历史记录描述了数据报拥塞控制协议（DCCP）背后的动机，DCCP是一种包含端到端拥塞控制的不可靠传输协议。DCCP实现了拥塞控制、不可靠的数据报流，供流媒体或在线游戏等应用程序使用。
Table of Contents
目录
1. Introduction ....................................................2
2. Problem Space ...................................................3
2.1. Congestion Control for Unreliable Transfer .................4
2.2. Overhead ...................................................6
2.3. Firewall Traversal .........................................6
2.4. Parameter Negotiation ......................................7
3. Solution Space for Congestion Control of Unreliable Flows .......7
3.1. Providing Congestion Control Above UDP .....................8
3.1.1. The Burden on the Application Designer ..............8
3.1.2. Difficulties with ECN ...............................8
3.1.3. The Evasion of Congestion Control ..................10
3.2. Providing Congestion Control Below UDP ....................10
3.2.1. Case 1: Congestion Feedback at the Application .....11
3.2.2. Case 2: Congestion Feedback at a Layer Below UDP ...11
3.3. Providing Congestion Control at the Transport Layer .......12
3.3.1. Modifying TCP? .....................................12
3.3.2. Unreliable Variants of SCTP? .......................13
3.3.3. Modifying RTP? .....................................14
3.3.4. Designing a New Transport Protocol .................14
4. Selling Congestion Control to Reluctant Applications ...........15
5. Additional Design Considerations ...............................15
6. Transport Requirements of Request/Response Applications ........16
7. Summary of Recommendations .....................................17
8. Security Considerations ........................................18
9. Acknowledgements ...............................................18
Informative References ............................................19
1. Introduction ....................................................2
2. Problem Space ...................................................3
2.1. Congestion Control for Unreliable Transfer .................4
2.2. Overhead ...................................................6
2.3. Firewall Traversal .........................................6
2.4. Parameter Negotiation ......................................7
3. Solution Space for Congestion Control of Unreliable Flows .......7
3.1. Providing Congestion Control Above UDP .....................8
3.1.1. The Burden on the Application Designer ..............8
3.1.2. Difficulties with ECN ...............................8
3.1.3. The Evasion of Congestion Control ..................10
3.2. Providing Congestion Control Below UDP ....................10
3.2.1. Case 1: Congestion Feedback at the Application .....11
3.2.2. Case 2: Congestion Feedback at a Layer Below UDP ...11
3.3. Providing Congestion Control at the Transport Layer .......12
3.3.1. Modifying TCP? .....................................12
3.3.2. Unreliable Variants of SCTP? .......................13
3.3.3. Modifying RTP? .....................................14
3.3.4. Designing a New Transport Protocol .................14
4. Selling Congestion Control to Reluctant Applications ...........15
5. Additional Design Considerations ...............................15
6. Transport Requirements of Request/Response Applications ........16
7. Summary of Recommendations .....................................17
8. Security Considerations ........................................18
9. Acknowledgements ...............................................18
Informative References ............................................19
Historically, the great majority of Internet unicast traffic has used congestion-controlled TCP, with UDP making up most of the remainder. UDP has mainly been used for short, request-response transfers, like DNS and SNMP, that wish to avoid TCP's three-way handshake, retransmission, and/or stateful connections. UDP also avoids TCP's built-in end-to-end congestion control, and UDP applications tended not to implement their own congestion control. However, since UDP traffic volume was small relative to congestion-controlled TCP flows, the network didn't collapse.
从历史上看，绝大多数Internet单播流量都使用了拥塞控制TCP，其余的大部分由UDP组成。UDP主要用于简短的请求-响应传输，如DNS和SNMP，以避免TCP的三方握手、重传和/或有状态连接。UDP还避免了TCP内置的端到端拥塞控制，UDP应用程序往往不实现自己的拥塞控制。然而，由于UDP通信量相对于拥塞控制的TCP流来说很小，所以网络没有崩溃。
Recent years have seen the growth of applications that use UDP in a different way. These applications, including streaming audio, Internet telephony, and multiplayer and massively multiplayer on-line games, share a preference for timeliness over reliability. TCP can introduce arbitrary delay because of its reliability and in-order delivery requirements; thus, the applications use UDP instead. This growth of long-lived non-congestion-controlled traffic, relative to
近年来，以不同方式使用UDP的应用程序不断增长。这些应用程序，包括流媒体音频、互联网电话、多人在线游戏和大规模多人在线游戏，都偏爱及时性而不是可靠性。TCP可以引入任意延迟，因为其可靠性和顺序交付要求；因此，应用程序改用UDP。这种长寿命的非拥塞控制流量的增长，相对于
congestion-controlled traffic, poses a real threat to the overall health of the Internet [RFC2914, RFC3714].
拥塞控制流量对互联网的整体健康构成了真正的威胁[RFC2914，RFC3714]。
Applications could implement their own congestion control mechanisms on a case-by-case basis, with encouragement from the IETF. Some already do this. However, experience shows that congestion control is difficult to get right, and many application writers would like to avoid reinventing this particular wheel. We believe that a new protocol is needed, one that combines unreliable datagram delivery with built-in congestion control. This protocol will act as an enabling technology: existing and new applications could easily use it to transfer timely data without destabilizing the Internet.
在IETF的鼓励下，应用程序可以根据具体情况实施自己的拥塞控制机制。有些人已经这样做了。然而，经验表明，拥塞控制很难做到正确，许多应用程序编写人员希望避免重新发明这种特殊的轮子。我们认为需要一种新的协议，它将不可靠的数据报传递与内置的拥塞控制相结合。该协议将作为一种使能技术：现有和新的应用程序可以轻松地使用它及时传输数据，而不会破坏互联网的稳定。
This document provides a problem statement for such a protocol. We list the properties the protocol should have, then explain why those properties are necessary. We describe why a new protocol is the best solution for the more general problem of bringing congestion control to unreliable flows of unicast datagrams, and discuss briefly subsidiary requirements for mobility, defense against Denial of Service (DoS) attacks and spoofing, interoperation with RTP, and interactions with Network Address Translators (NATs) and firewalls.
本文件提供了此类协议的问题说明。我们列出协议应该具有的属性，然后解释为什么需要这些属性。我们描述了为什么新协议是解决更一般的问题的最佳解决方案，即对不可靠的单播数据流进行拥塞控制，并简要讨论了移动性、拒绝服务（DoS）攻击和欺骗防御、与RTP的互操作以及与网络地址转换器的交互等辅助要求（NAT）和防火墙。
One of the design preferences that we bring to this question is a preference for a clean, understandable, low-overhead, and minimal protocol. As described later in this document, this results in the design decision to leave functionality such as reliability or Forward Error Correction (FEC) to be layered on top, rather than provided in the transport protocol itself.
我们为这个问题带来的一个设计偏好是对干净、可理解、低开销和最小协议的偏好。如本文档后面所述，这导致设计决策将可靠性或前向纠错（FEC）等功能保留在顶层，而不是在传输协议本身中提供。
This document began in 2002 as a formalization of the goals of DCCP, the Datagram Congestion Control Protocol [RFC4340]. We intended DCCP to satisfy this problem statement, and thus the original reasoning behind many of DCCP's design choices can be found here. However, we believed, and continue to believe, that the problem should be solved whether or not DCCP is the chosen solution.
本文件始于2002年，作为DCCP（数据报拥塞控制协议[RFC4340]）目标的形式化。我们打算让DCCP满足这个问题陈述，因此可以在这里找到许多DCCP设计选择背后的原始推理。然而，我们相信，并继续相信，无论DCCP是否是所选择的解决方案，问题都应该得到解决。
We perceive a number of problems related to the use of unreliable data flows in the Internet. The major issues are the following:
我们发现了一些与在互联网上使用不可靠数据流有关的问题。主要问题如下：
o The potential for non-congestion-controlled datagram flows to cause congestion collapse of the network. (See Section 5 of [RFC2914] and Section 2 of [RFC3714].)
o 非拥塞控制数据报流可能导致网络拥塞崩溃。（参见[RFC2914]第5节和[RFC3714]第2节。）
o The difficulty of correctly implementing effective congestion control mechanisms for unreliable datagram flows.
o 对于不可靠的数据报流，正确实施有效拥塞控制机制的困难。
o The lack of a standard solution for reliably transmitting congestion feedback for an unreliable data flow.
o 对于不可靠的数据流，缺乏可靠传输拥塞反馈的标准解决方案。
o The lack of a standard solution for negotiating Explicit Congestion Notification (ECN) [RFC3168] usage for unreliable flows.
o 缺乏协商不可靠流的显式拥塞通知（ECN）[RFC3168]使用的标准解决方案。
o The lack of a choice of TCP-friendly congestion control mechanisms.
o 缺乏对TCP友好的拥塞控制机制的选择。
We assume that most application writers would use congestion control for long-lived unreliable flows if it were available in a standard, easy-to-use form.
我们假设大多数应用程序编写者都会对长期不可靠的流使用拥塞控制，如果它以标准、易于使用的形式提供的话。
More minor issues include the following:
更多的次要问题包括：
o The difficulty of deploying applications using UDP-based flows in the presence of firewalls.
o 在存在防火墙的情况下使用基于UDP的流部署应用程序的困难。
o The desire to have a single way to negotiate congestion control parameters for unreliable flows, independently of the signalling protocol used to set up the flow.
o 希望有一种单一的方式来协商不可靠流的拥塞控制参数，独立于用于设置流的信令协议。
o The desire for low per-packet byte overhead.
o 对低每包字节开销的需求。
The subsections below discuss these problems of providing congestion control, traversing firewalls, and negotiating parameters in more detail. A separate subsection also discusses the problem of minimizing the overhead of packet headers.
下面的小节将更详细地讨论提供拥塞控制、穿越防火墙和协商参数等问题。另一小节还讨论了最小化数据包报头开销的问题。
We aim to bring easy-to-use congestion control mechanisms to applications that generate large or long-lived flows of unreliable datagrams, such as RealAudio, Internet telephony, and multiplayer games. Our motivation is to avoid congestion collapse. (The short flows generated by request-response applications, such as DNS and SNMP, don't cause congestion in practice, and any congestion control mechanism would take effect between flows, not within a single end-to-end transfer of information.) However, before designing a congestion control mechanism for these applications, we must understand why they use unreliable datagrams in the first place, lest we destroy the very properties they require.
我们的目标是将易于使用的拥塞控制机制应用于生成大量或长期不可靠数据流的应用程序，如RealAudio、Internet电话和多人游戏。我们的动机是避免拥堵崩溃。（请求-响应应用程序（如DNS和SNMP）生成的短流实际上不会造成拥塞，任何拥塞控制机制都会在流之间生效，而不是在单个端到端的信息传输中生效。）但是，在为这些应用程序设计拥塞控制机制之前，我们必须首先理解他们为什么使用不可靠的数据报，以免我们破坏他们所需要的特性。
There are several reasons why protocols currently use UDP instead of TCP, among them:
目前协议使用UDP而不是TCP的原因有很多，其中包括：
o Startup Delay: they wish to avoid the delay of a three-way handshake before initiating data transfer.
o 启动延迟：他们希望在启动数据传输之前避免三方握手的延迟。
o Statelessness: they wish to avoid holding connection state, and the potential state-holding attacks that come with this.
o 无状态：他们希望避免持有连接状态，以及随之而来的潜在状态持有攻击。
o Trading of Reliability against Timing: the data being sent is timely in the sense that if it is not delivered by some deadline (typically a small number of RTTs), then the data will not be useful at the receiver.
o 可靠性与时间的交易：发送的数据是及时的，因为如果在某个截止日期（通常是少量RTT）之前没有交付，那么数据在接收方将没有用处。
Of these issues, applications that generate large or long-lived flows of datagrams, such as media transfer and games, mostly care about controlling the trade-off between timing and reliability. Such applications use UDP because when they send a datagram, they wish to send the most appropriate data in that datagram. If the datagram is lost, they may or may not resend the same data, depending on whether the data will still be useful at the receiver. Data may no longer be useful for many reasons:
在这些问题中，生成大型或长寿命数据报流的应用程序（如媒体传输和游戏）主要关心控制定时和可靠性之间的权衡。此类应用程序使用UDP，因为当它们发送数据报时，希望发送该数据报中最合适的数据。如果数据报丢失，它们可能重新发送相同的数据，也可能不重新发送相同的数据，这取决于数据在接收器是否仍然有用。由于许多原因，数据可能不再有用：
o In a telephony or streaming video session, data in a packet comprises a timeslice of a continuous stream. Once a timeslice has been played out, the next timeslice is required immediately. If the data comprising that timeslice arrives at some later time, then it is no longer useful. Such applications can cope with masking the effects of missing packets to some extent, so when the sender transmits its next packet, it is important for it to only send data that has a good chance of arriving in time for its playout.
o 在电话或流式视频会话中，分组中的数据包括连续流的时间片。播放完一个时间片后，立即需要下一个时间片。如果包含该时间片的数据稍后到达，则它不再有用。这类应用程序可以在一定程度上屏蔽丢失数据包的影响，因此，当发送方传输其下一个数据包时，重要的是它只发送有机会及时到达播放的数据。
o In an interactive game or virtual-reality session, position information is transient. If a datagram containing position information is lost, resending the old position does not usually make sense -- rather, every position information datagram should contain the latest position information.
o 在交互式游戏或虚拟现实会话中，位置信息是暂时的。如果包含位置信息的数据报丢失，重新发送旧位置通常没有意义——相反，每个位置信息数据报都应该包含最新的位置信息。
In a congestion-controlled flow, the allowed packet sending rate depends on measured network congestion. Thus, some control is given up to the congestion control mechanism, which determines precisely when packets can be sent. However, applications could still decide, at transmission time, which information to put in a packet. TCP doesn't allow control over this; these applications demand it.
在拥塞控制流中，允许的数据包发送速率取决于测量的网络拥塞。因此，一些控制权交给了拥塞控制机制，该机制精确地确定了何时可以发送数据包。然而，应用程序仍然可以在传输时决定将哪些信息放入数据包中。TCP不允许对此进行控制；这些应用程序需要它。
Often, these applications (especially games and telephony applications) work on very short playout timescales. Whilst they are
通常，这些应用程序（尤其是游戏和电话应用程序）的播放时间非常短。当他们在
usually able to adjust their transmission rate based on congestion feedback, they do have constraints on how this adaptation can be performed so that it has minimal impact on the quality of the session. Thus, they tend to need some control over the short-term dynamics of the congestion control algorithm, whilst being fair to other traffic on medium timescales. This control includes, but is not limited to, some influence on which congestion control algorithm should be used -- for example, TCP-Friendly Rate Control (TFRC) [RFC3448] rather than strict TCP-like congestion control. (TFRC has been standardized in the IETF as a congestion control mechanism that adjusts its sending rate more smoothly than TCP does, while maintaining long-term fair bandwidth sharing with TCP [RFC3448].)
通常能够根据拥塞反馈调整传输速率，但它们对如何执行这种自适应有限制，因此对会话质量的影响最小。因此，它们往往需要对拥塞控制算法的短期动态进行某种控制，同时在中期时间尺度上对其他流量公平。此控制包括但不限于对应使用的拥塞控制算法的一些影响，例如，TCP友好速率控制（TFRC）[RFC3448]而不是严格的TCP类拥塞控制。（TFRC已在IETF中标准化，作为一种拥塞控制机制，它比TCP更平滑地调整发送速率，同时保持与TCP的长期公平带宽共享[RFC3448]。）
The applications we are concerned with often send compressed data, or send frequent small packets. For example, when Internet telephony or streaming media are used over low-bandwidth modem links, highly compressing the payload data is essential. For Internet telephony applications and for games, the requirement is for low delay, and hence small packets are sent frequently.
我们所关注的应用程序通常发送压缩数据，或频繁发送小数据包。例如，当通过低带宽调制解调器链路使用Internet电话或流媒体时，高度压缩有效负载数据至关重要。对于互联网电话应用和游戏，要求低延迟，因此经常发送小数据包。
For example, a telephony application sending a 5.6 Kbps data stream but wanting moderately low delay may send a packet every 20 ms, sending only 14 data bytes in each packet. In addition, 20 bytes is taken up by the IP header, with additional bytes for transport and/or application headers. Clearly, it is desirable for such an application to have a low-overhead transport protocol header.
例如，发送5.6kbps数据流但需要适度低延迟的电话应用程序可以每20ms发送一个分组，每个分组中仅发送14个数据字节。此外，IP报头占用20个字节，另外还有用于传输和/或应用程序报头的字节。显然，希望这样的应用程序具有低开销的传输协议报头。
In some cases, the correct solution would be to use link-based packet header compression to compress the packet headers, although we cannot guarantee the availability of such compression schemes on any particular link.
在某些情况下，正确的解决方案是使用基于链路的数据包报头压缩来压缩数据包报头，尽管我们不能保证在任何特定链路上使用这种压缩方案。
The delay of data until after the completion of a handshake also represents potentially unnecessary overhead. A new protocol might therefore allow senders to include some data on their initial datagrams.
在握手完成之前的数据延迟也表示可能不必要的开销。因此，一个新的协议可能允许发送方在其初始数据报中包含一些数据。
Applications requiring a flow of unreliable datagrams currently tend to use signalling protocols such as the Real Time Streaming Protocol (RTSP) [RFC2326], SIP [RFC3261], and H.323 in conjunction with UDP for the data flow. The initial setup request uses a signalling protocol to locate the correct remote end-system for the data flow, sometimes after being redirected or relayed to other machines.
需要不可靠数据报流的应用程序目前倾向于将诸如实时流协议（RTSP）[RFC2326]、SIP[RFC3261]和H.323等信令协议与UDP一起用于数据流。初始设置请求使用信令协议为数据流定位正确的远程终端系统，有时在重定向或中继到其他机器之后。
As UDP flows contain no explicit setup and teardown, it is hard for firewalls to handle them correctly. Typically, the firewall needs to parse RTSP, SIP, and H.323 to obtain the information necessary to open a hole in the firewall. Although, for bi-directional flows, the firewall can open a bi-directional hole if it receives a UDP packet from inside the firewall, in this case the firewall can't easily know when to close the hole again.
由于UDP流不包含显式设置和拆卸，防火墙很难正确处理它们。通常，防火墙需要解析RTSP、SIP和H.323，以获得在防火墙中打开漏洞所需的信息。尽管对于双向流，如果防火墙从防火墙内部接收到UDP数据包，防火墙可以打开一个双向孔，但在这种情况下，防火墙无法轻松知道何时再次关闭该孔。
While we do not consider these to be major problems, they are nonetheless issues that application designers face. Currently, streaming media players attempt UDP first, and then switch to TCP if UDP is not successful. Streaming media over TCP is undesirable and can result in the receiver needing to temporarily halt playout while it "rebuffers" data. Telephony applications don't even have this option.
虽然我们不认为这些是主要的问题，但它们仍然是应用设计者面临的问题。当前，流媒体播放器首先尝试UDP，如果UDP不成功，则切换到TCP。TCP上的流媒体是不可取的，可能会导致接收器在“拒绝”数据时需要暂时停止播放。电话应用程序甚至没有这个选项。
Different applications have different requirements for congestion control, which may map into different congestion feedback. Examples include ECN capability and desired congestion control dynamics (the choice of congestion control algorithm and, therefore, the form of feedback information required). Such parameters need to be reliably negotiated before congestion control can function correctly.
不同的应用对拥塞控制有不同的要求，这可能映射到不同的拥塞反馈。示例包括ECN能力和期望的拥塞控制动态（拥塞控制算法的选择，因此，需要反馈信息的形式）。在拥塞控制能够正常工作之前，需要可靠地协商这些参数。
While this negotiation could be performed using signalling protocols such as SIP, RTSP, and H.323, it would be desirable to have a single standard way of negotiating these transport parameters. This is of particular importance with ECN, where sending ECN-marked packets to a non-ECN-capable receiver can cause significant congestion problems to other flows. We discuss the ECN issue in more detail below.
虽然可以使用SIP、RTSP和H.323等信令协议来执行该协商，但是希望有一种协商这些传输参数的单一标准方法。这对于ECN特别重要，在ECN中，向不支持ECN的接收器发送带有ECN标记的数据包可能会对其他流造成严重的拥塞问题。下面我们将更详细地讨论ECN问题。
We thus want to provide congestion control for unreliable flows, providing both ECN and the choice of different forms of congestion control, and providing moderate overhead in terms of packet size, state, and CPU processing. There are a number of options for providing end-to-end congestion control for the unicast traffic that currently uses UDP, in terms of the layer that provides the congestion control mechanism:
因此，我们希望为不可靠流提供拥塞控制，提供ECN和不同形式的拥塞控制选择，并在数据包大小、状态和CPU处理方面提供适度的开销。就提供拥塞控制机制的层而言，有许多选项可用于为当前使用UDP的单播流量提供端到端拥塞控制：
o Congestion control above UDP.
o UDP之上的拥塞控制。
o Congestion control below UDP.
o UDP下的拥塞控制。
o Congestion control at the transport layer in an alternative to UDP.
o 作为UDP的替代方案，在传输层进行拥塞控制。
We explore these alternatives in the sections below. The concerns from the discussions below have convinced us that the best way to provide congestion control for unreliable flows is to provide congestion control at the transport layer, as an alternative to the use of UDP and TCP.
我们将在下面的章节中探讨这些备选方案。下面讨论的问题使我们确信，为不可靠流提供拥塞控制的最佳方法是在传输层提供拥塞控制，作为UDP和TCP使用的替代方案。
One possibility would be to provide congestion control at the application layer, or at some other layer above UDP. This would allow the congestion control mechanism to be closely integrated with the application itself.
一种可能是在应用层或UDP之上的其他层提供拥塞控制。这将允许拥塞控制机制与应用程序本身紧密集成。
A key disadvantage of providing congestion control above UDP is that it places an unnecessary burden on the application-level designer, who might be just as happy to use the congestion control provided by a lower layer. If the application can rely on a lower layer that gives a choice between TCP-like or TFRC-like congestion control, and that offers ECN, then this might be highly satisfactory to many application designers.
在UDP之上提供拥塞控制的一个关键缺点是，它给应用程序级设计人员带来了不必要的负担，他们可能同样乐意使用较低层提供的拥塞控制。如果应用程序可以依赖一个较低的层，该层提供类似TCP或TFRC的拥塞控制，并提供ECN，那么这可能会让许多应用程序设计者非常满意。
The long history of debugging TCP implementations [RFC2525, PF01] makes the difficulties in implementing end-to-end congestion control abundantly clear. It is clearly more robust for congestion control to be provided for the application by a lower layer. In rare cases, there might be compelling reasons for the congestion control mechanism to be implemented in the application itself, but we do not expect this to be the general case. For example, applications that use RTP over UDP might be just as happy if RTP itself implemented end-to-end congestion control. (See Section 3.3.3 for more discussion of RTP.)
调试TCP实现的漫长历史[RFC2525，PF01]使得实现端到端拥塞控制的困难非常明显。对于由较低层为应用程序提供的拥塞控制，它显然更加健壮。在极少数情况下，可能有令人信服的理由在应用程序本身中实现拥塞控制机制，但我们不认为这是一般情况。例如，如果RTP本身实现了端到端的拥塞控制，那么通过UDP使用RTP的应用程序可能也会很高兴。（有关RTP的更多讨论，请参见第3.3.3节。）
In addition to congestion control issues, we also note the problems with firewall traversal and parameter negotiation discussed in Sections 2.3 and 2.4. Implementing on top of UDP requires that the application designer also address these issues.
除了拥塞控制问题外，我们还注意到第2.3节和第2.4节中讨论的防火墙遍历和参数协商问题。在UDP之上实现需要应用程序设计器也解决这些问题。
There is a second problem with providing congestion control above UDP: it would require either giving up the use of ECN or giving the application direct control over setting and reading the ECN field in the IP header. Giving up the use of ECN would be problematic, since ECN can be particularly useful for unreliable flows, where a dropped packet will not be retransmitted by the data sender.
在UDP之上提供拥塞控制还有第二个问题：它需要放弃使用ECN，或者让应用程序直接控制设置和读取IP报头中的ECN字段。放弃使用ECN会有问题，因为ECN对于不可靠的流特别有用，在不可靠的流中，数据发送方不会重新传输丢弃的数据包。
With the development of the ECN nonce, ECN can be useful even in the absence of network support. The data sender can use the ECN nonce, along with feedback from the data receiver, to verify that the data receiver is correctly reporting all lost packets. This use of ECN can be particularly useful for an application using unreliable delivery, where the receiver might otherwise have little incentive to report lost packets.
随着ECN技术的发展，即使在没有网络支持的情况下，ECN也可以发挥作用。数据发送方可以使用ECN nonce以及来自数据接收方的反馈来验证数据接收方是否正确报告了所有丢失的数据包。ECN的这种使用对于使用不可靠传递的应用程序特别有用，否则接收器可能没有动力报告丢失的数据包。
In order to allow the use of ECN by a layer above UDP, the UDP socket would have to allow the application to control the ECN field in the IP header. In particular, the UDP socket would have to allow the application to specify whether or not the ECN-Capable Transport (ECT) codepoints should be set in the ECN field of the IP header.
为了允许UDP上面的层使用ECN，UDP套接字必须允许应用程序控制IP报头中的ECN字段。特别是，UDP套接字必须允许应用程序指定是否应在IP报头的ECN字段中设置支持ECN的传输（ECT）代码点。
The ECN contract is that senders who set the ECT codepoint must respond to Congestion Experienced (CE) codepoints by reducing their sending rates. Therefore, the ECT codepoint can only safely be set in the packet header of a UDP packet if the following is guaranteed:
ECN合同规定，设置ECT码点的发送方必须通过降低发送速率来响应拥塞体验（CE）码点。因此，只有在保证以下条件的情况下，才可以在UDP数据包的数据包头中安全地设置ECT码点：
o if the CE codepoint is set by a router, the receiving IP layer will pass the CE status to the UDP layer, which will pass it to the receiving application at the data receiver; and
o 如果CE码点由路由器设置，则接收IP层将CE状态传递给UDP层，UDP层将其传递给数据接收器处的接收应用程序；和
o upon receiving a packet that had the CE codepoint set, the receiving application will take the appropriate congestion control action, such as informing the data sender.
o 接收到设置了CE码点的数据包后，接收应用程序将采取适当的拥塞控制措施，例如通知数据发送方。
However, the UDP implementation at the data sender has no way of knowing if the UDP implementation at the data receiver has been upgraded to pass a CE status up to the receiving application, let alone whether or not the application will use the conformant end-to-end congestion control that goes along with use of ECN.
但是，数据发送方的UDP实现无法知道数据接收方的UDP实现是否已升级，以将CE状态传递给接收应用程序，更不用说应用程序是否将使用与ECN一起使用的一致的端到端拥塞控制。
In the absence of the widespread deployment of mechanisms in routers to detect flows that are not using conformant congestion control, allowing applications arbitrary control of the ECT codepoints for UDP packets would seem like an unnecessary opportunity for applications to use ECN while evading the use of end-to-end congestion control. Thus, there is an inherent "chicken-and-egg" problem of whether first to deploy policing mechanisms in routers, or first to enable the use of ECN by UDP flows. Without the policing mechanisms in routers, we would not advise adding ECN-capability to UDP sockets at this time.
在路由器中没有广泛部署机制来检测未使用一致拥塞控制的流的情况下，允许应用程序任意控制UDP数据包的ECT代码点似乎是应用程序使用ECN的不必要机会，同时避免使用端到端拥塞控制。因此，存在一个固有的“鸡和蛋”问题，即是首先在路由器中部署策略机制，还是首先通过UDP流启用ECN。如果没有路由器中的监控机制，我们不建议在此时向UDP套接字添加ECN功能。
In the absence of more fine-grained mechanisms for dealing with a period of sustained congestion, one possibility would be for routers to discontinue using ECN with UDP packets during the congested period, and to use ECN only with TCP or DCCP packets. This would be a reasonable response, for example, if TCP or DCCP flows were found
在缺乏更细粒度的机制来处理持续拥塞期间的情况下，一种可能性是路由器在拥塞期间停止对UDP数据包使用ECN，而仅对TCP或DCCP数据包使用ECN。例如，如果发现TCP或DCCP流，这将是一个合理的响应
to be more likely to be using conformant end-to-end congestion control than were UDP flows. If routers were to adopt such a policy, then DCCP flows could be more likely to receive the benefits of ECN in times of congestion than would UDP flows.
比UDP流更有可能使用一致的端到端拥塞控制。如果路由器采用这种策略，那么DCCP流在拥塞时比UDP流更有可能获得ECN的好处。
A third problem of providing congestion control above UDP is that relying on congestion control at the application level makes it somewhat easier for some users to evade end-to-end congestion control. We do not claim that a transport protocol such as DCCP would always be implemented in the kernel, and do not attempt to evaluate the relative difficulty of modifying code inside the kernel vs. outside the kernel in any case. However, we believe that putting the congestion control at the transport level rather than at the application level makes it just slightly less likely that users will go to the trouble of modifying the code in order to avoid using end-to-end congestion control.
在UDP之上提供拥塞控制的第三个问题是，依赖于应用程序级别的拥塞控制使得一些用户更容易逃避端到端的拥塞控制。我们不主张像DCCP这样的传输协议总是在内核中实现，也不试图评估在任何情况下修改内核内部代码与内核外部代码的相对难度。但是，我们认为，将拥塞控制放在传输级别而不是应用程序级别，这样用户就不太可能为了避免使用端到端拥塞控制而费事修改代码。
Instead of providing congestion control above UDP, a second possibility would be to provide congestion control for unreliable applications at a layer below UDP, with applications using UDP as their transport protocol. Given that UDP does not itself provide sequence numbers or congestion feedback, there are two possible forms for this congestion feedback:
第二种可能不是在UDP之上提供拥塞控制，而是在UDP之下的一层为不可靠的应用程序提供拥塞控制，应用程序使用UDP作为其传输协议。鉴于UDP本身不提供序列号或拥塞反馈，此拥塞反馈有两种可能的形式：
1) Feedback at the application: The application above UDP could provide sequence numbers and feedback to the sender, which would then communicate loss information to the congestion control mechanism. This is the approach currently standardized by the Congestion Manager (CM) [RFC3124].
1) 应用程序反馈：UDP上面的应用程序可以向发送方提供序列号和反馈，然后发送方将丢失信息传递给拥塞控制机制。这是目前由拥塞管理器（CM）[RFC3124]标准化的方法。
2) Feedback at the layer below UDP: The application could use UDP, and a protocol could be implemented using a shim header between IP and UDP to provide sequence number information for data packets and return feedback to the data sender. The original proposal for the Congestion Manager [BRS99] suggested providing this layer for applications that did not have their own feedback about dropped packets.
2) UDP下一层的反馈：应用程序可以使用UDP，协议可以使用IP和UDP之间的垫片头来实现，以提供数据包的序列号信息，并将反馈返回给数据发送方。拥塞管理器[BRS99]的最初提案建议为没有自己对丢弃数据包的反馈的应用程序提供该层。
We discuss these two cases separately below.
下面我们将分别讨论这两种情况。
In this case, the application provides sequence numbers and congestion feedback above UDP, but communicates that feedback to a congestion manager below UDP, which regulates when packets can be sent. This approach suffers from most of the problems described in Section 3.1, namely, forcing the application designer to reinvent the wheel each time for packet formats and parameter negotiation, and problems with ECN usage, firewalls, and evasion.
在这种情况下，应用程序在UDP之上提供序列号和拥塞反馈，但将该反馈传递给UDP之下的拥塞管理器，该管理器控制何时可以发送数据包。这种方法存在第3.1节中描述的大多数问题，即每次都迫使应用程序设计者重新设计包格式和参数协商，以及ECN使用、防火墙和规避问题。
It would avoid the application writer needing to implement the control part of the congestion control mechanism, but it is unclear how easily multiple congestion control algorithms (such as receiver-based TFRC) can be supported, given that the form of congestion feedback usually needs to be closely coupled to the congestion control algorithm being used. Thus, this design limits the choice of congestion control mechanisms available to applications while simultaneously burdening the applications with implementations of congestion feedback.
这将避免应用程序编写者需要实现拥塞控制机制的控制部分，但不清楚支持多个拥塞控制算法（如基于接收器的TFRC）的容易程度，考虑到拥塞反馈的形式通常需要与所使用的拥塞控制算法紧密耦合。因此，这种设计限制了对应用程序可用的拥塞控制机制的选择，同时使应用程序承担了拥塞反馈实现的负担。
Providing feedback at a layer below UDP would require an additional packet header below UDP to carry sequence numbers in addition to the 8-byte header for UDP itself. Unless this header were an IP option (which is likely to cause problems for many IPv4 routers), its presence would need to be indicated using a different IP protocol value from UDP. Thus, the packets would no longer look like UDP on the wire, and the modified protocol would face deployment challenges similar to those of an entirely new protocol.
在UDP下面的层提供反馈将需要UDP下面的额外数据包报头来携带序列号，除了UDP本身的8字节报头之外。除非此报头是IP选项（这可能会导致许多IPv4路由器出现问题），否则需要使用不同于UDP的IP协议值来指示其存在。因此，数据包将不再像有线UDP，修改后的协议将面临与全新协议类似的部署挑战。
To use congestion feedback at a layer below UDP most effectively, the semantics of the UDP socket Application Programming Interface (API) would also need changing, both to support a late decision on what to send and to provide access to sequence numbers (so that the application wouldn't need to duplicate them for its own purposes). Thus, the socket API would no longer look like UDP to end hosts. This would effectively be a new transport protocol.
为了最有效地在UDP下面的一层使用拥塞反馈，UDP套接字应用程序编程接口（API）的语义也需要更改，以支持对发送内容的延迟决策，并提供对序列号的访问（这样应用程序就不需要为其自身目的复制序列号）。因此，套接字API在终端主机上不再像UDP。这实际上是一种新的传输协议。
Given these complications, it seems cleaner to actually design a new transport protocol, which also allows us to address the issues of firewall traversal, flow setup, and parameter negotiation. We note that any new transport protocol could also use a Congestion Manager approach to share congestion state between flows using the same congestion control algorithm, if this were deemed to be desirable.
考虑到这些复杂性，实际上设计一个新的传输协议似乎更为简洁，它还允许我们解决防火墙遍历、流设置和参数协商等问题。我们注意到，如果认为需要，任何新的传输协议也可以使用拥塞管理器方法在使用相同拥塞控制算法的流之间共享拥塞状态。
The concerns from the discussions above have convinced us that the best way to provide congestion control to applications that currently use UDP is to provide congestion control at the transport layer, in a transport protocol used as an alternative to UDP. One advantage of providing end-to-end congestion control in an unreliable transport protocol is that it could be used easily by a wide range of the applications that currently use UDP, with minimal changes to the application itself. The application itself would not have to provide the congestion control mechanism, or even the feedback from the data receiver to the data sender about lost or marked packets.
上述讨论引起的担忧使我们确信，为当前使用UDP的应用程序提供拥塞控制的最佳方法是在传输层提供拥塞控制，使用传输协议作为UDP的替代方案。在不可靠的传输协议中提供端到端拥塞控制的一个优点是，当前使用UDP的各种应用程序都可以轻松地使用该协议，而对应用程序本身的更改最少。应用程序本身不必提供拥塞控制机制，甚至不必提供从数据接收方到数据发送方关于丢失或标记的数据包的反馈。
The question then arises of whether to adapt TCP for use by unreliable applications, to use an unreliable variant of the Stream Control Transmission Protocol (SCTP) or a version of RTP with built-in congestion control, or to design a new transport protocol.
接下来的问题是，是否调整TCP以供不可靠的应用程序使用，是否使用流控制传输协议（SCTP）的不可靠变体或具有内置拥塞控制的RTP版本，或者是否设计新的传输协议。
As we argue below, the desire for minimal overhead results in the design decision to use a transport protocol containing only the minimal necessary functionality, and to leave other functionality such as reliability, semi-reliability, or Forward Error Correction (FEC) to be layered on top.
正如我们在下面所讨论的，对最小开销的渴望导致设计决策使用只包含最小必要功能的传输协议，并将其他功能（如可靠性、半可靠性或前向纠错（FEC））保留在顶层。
One alternative might be to create an unreliable variant of TCP, with reliability layered on top for applications desiring reliable delivery. However, our requirement is not simply for TCP minus in-order reliable delivery, but also for the application to be able to choose congestion control algorithms. TCP's feedback mechanism works well for TCP-like congestion control, but is inappropriate (or at the very least, inefficient) for TFRC. In addition, TCP sequence numbers are in bytes, not datagrams. This would complicate both congestion feedback and any attempt to allow the application to decide, at transmission time, what information should go into a packet. Finally, there is the issue of whether a modified TCP would require a new IP protocol number as well; a significantly modified TCP using the same IP protocol number could have unwanted interactions with some of the middleboxes already deployed in the network.
另一种选择可能是创建一种不可靠的TCP变体，对于希望可靠交付的应用程序，可靠性是分层的。然而，我们的要求不仅仅是为了保证TCP的可靠传输，还要求应用程序能够选择拥塞控制算法。TCP的反馈机制适用于类似TCP的拥塞控制，但不适用于TFRC（或者至少是低效的）。此外，TCP序列号以字节为单位，而不是数据报。这将使拥塞反馈和任何允许应用程序在传输时决定哪些信息应该进入数据包的尝试变得复杂。最后，还有一个问题，修改后的TCP是否也需要一个新的IP协议号；使用相同IP协议号的大幅修改的TCP可能会与网络中已部署的某些中间盒产生不必要的交互。
It seems best simply to leave TCP as it is, and to create a new congestion control protocol for unreliable transfer. This is especially true since any change to TCP, no matter how small, takes an inordinate amount of time to standardize and deploy, given TCP's importance in the current Internet and the historical difficulty of getting TCP implementations right.
看起来最好的办法是保持TCP的现状，并为不可靠的传输创建一个新的拥塞控制协议。考虑到TCP在当前互联网中的重要性以及正确实现TCP的历史困难，对TCP的任何更改（无论多么小）都需要花费大量的时间进行标准化和部署，这一点尤其正确。
SCTP, the Stream Control Transmission Protocol [RFC2960], was in part designed to accommodate multiple streams within a single end-to-end connection, modifying TCP's semantics of reliable, in-order delivery to allow out-of-order delivery. However, explicit support for multiple streams over a single flow at the transport layer is not necessary for an unreliable transport protocol such as DCCP, which of necessity allows out-of-order delivery. Because an unreliable transport does not need streams support, applications should not have to pay the penalties in terms of increased header size that accompany the use of streams in SCTP.
SCTP，即流控制传输协议[RFC2960]，部分设计用于在单个端到端连接中容纳多个流，修改TCP的可靠顺序交付语义，以允许无序交付。然而，对于不可靠的传输协议（如DCCP），在传输层对单个流上的多个流的显式支持不是必需的，DCCP必然允许无序交付。因为不可靠的传输不需要流支持，所以应用程序不必为SCTP中使用流而增加的报头大小支付罚金。
The basic underlying structure of the SCTP packet, of a common SCTP header followed by chunks for data, SACK information, and so on, is motivated by SCTP's goal of accommodating multiple streams. However, this use of chunks comes at the cost of an increased header size for packets, as each chunk must be aligned on 32-bit boundaries, and therefore requires a fixed-size 4-byte chunk header. For example, for a connection using ECN, SCTP includes separate control chunks for the Explicit Congestion Notification Echo (ECNE) and Congestion Window Reduced (CWR) functions, with the ECNE and CWR chunks each requiring 8 bytes. As another example, the common header includes a 4-byte verification tag to validate the sender.
SCTP数据包的基本底层结构是一个公共SCTP头，后面是数据块、SACK信息等，其动机是SCTP适应多个流的目标。然而，使用块的代价是增加数据包的头大小，因为每个块必须在32位边界上对齐，因此需要固定大小的4字节块头。例如，对于使用ECN的连接，SCTP包括用于显式拥塞通知回显（ECNE）和拥塞窗口缩减（CWR）功能的单独控制块，ECNE和CWR块各需要8个字节。作为另一个示例，公共报头包括一个4字节的验证标签，用于验证发送方。
As a second concern, SCTP as currently specified uses TCP-like congestion control, and does not provide support for alternative congestion control algorithms such as TFRC that would be more attractive to some of the applications currently using UDP flows. Thus, the current version of SCTP would not meet the requirements for a choice between forms of end-to-end congestion control.
第二个问题是，目前指定的SCTP使用类似TCP的拥塞控制，并且不支持替代拥塞控制算法，如TFRC，该算法对当前使用UDP流的一些应用程序更具吸引力。因此，当前版本的SCTP无法满足在端到端拥塞控制形式之间进行选择的要求。
Finally, the SCTP Partial Reliability extension [RFC3758] allows a sender to selectively abandon outstanding messages, which ceases retransmissions and allows the receiver to deliver any queued messages on the affected streams. This service model, although well-suited for some applications, differs from, and provides the application somewhat less flexibility than, UDP's fully unreliable service.
最后，SCTP部分可靠性扩展[RFC3758]允许发送方有选择地放弃未完成的消息，从而停止重传，并允许接收方在受影响的流上传递任何排队的消息。此服务模型虽然非常适合于某些应用程序，但与UDP的完全不可靠服务不同，并且为应用程序提供的灵活性略低于UDP的完全不可靠服务。
One could suggest adding support for alternative congestion control mechanisms as an option to SCTP, and adding a fully-unreliable variant that does not include the mechanisms for multiple streams. We would argue against this. SCTP is well-suited for applications that desire limited retransmission with multistream or multihoming support. Adding support for fully-unreliable variants, multiple congestion control profiles, and reduced single-stream headers would risk introducing unforeseen interactions and make further
有人可能建议添加对替代拥塞控制机制的支持，作为SCTP的一个选项，并添加一个完全不可靠的变体，该变体不包括多个流的机制。我们会反对这一点。SCTP非常适合于需要多流或多主支持的有限重传的应用。增加对完全不可靠的变体、多个拥塞控制配置文件和减少的单流报头的支持将有可能引入不可预见的交互，并导致进一步的错误
modifications ever more difficult. We have chosen instead to implement a minimal protocol, designed for fully-unreliable datagram service, that provides only end-to-end congestion control and any other mechanisms that cannot be provided in a higher layer.
修改变得越来越困难。相反，我们选择实现一个最小协议，该协议是为完全不可靠的数据报服务设计的，它只提供端到端的拥塞控制和在更高层中无法提供的任何其他机制。
Several of our target applications currently use RTP layered above UDP to transfer their data. Why not modify RTP to provide end-to-end congestion control?
我们的几个目标应用程序目前使用UDP上分层的RTP传输数据。为什么不修改RTP以提供端到端拥塞控制？
When RTP lives above UDP, modifying it to support congestion control might create some of the problems described in Section 3.1. In particular, user-level RTP implementations would want access to ECN bits in UDP datagrams. It might be difficult or undesirable to allow that access for RTP, but not for other user-level programs.
当RTP位于UDP之上时，修改它以支持拥塞控制可能会产生第3.1节中描述的一些问题。特别是，用户级RTP实现需要访问UDP数据报中的ECN位。可能很难或不希望允许RTP访问，但不允许其他用户级程序访问。
Kernel implementations of RTP would not suffer from this problem. In the end, the argument against modifying RTP is the same as that against modifying SCTP: Some applications, such as the export of flow information from routers, need congestion control but don't need much of RTP's functionality. From these applications' point of view, RTP would induce unnecessary overhead. Again, we would argue for a clean and minimal protocol focused on end-to-end congestion control.
RTP的内核实现不会遇到这个问题。最后，反对修改RTP的理由与反对修改SCTP的理由是一样的：一些应用程序，例如从路由器导出流信息，需要拥塞控制，但不需要太多RTP的功能。从这些应用程序的角度来看，RTP将导致不必要的开销。同样，我们会主张建立一个干净且最小的协议，重点关注端到端的拥塞控制。
RTP would commonly be used as a layer above any new transport protocol, however. The design of that new transport protocol should take this into account, either by avoiding undue duplication of information available in the RTP header, or by suggesting modifications to RTP, such as a reduced RTP header that removes any fields redundant with the new protocol's headers.
然而，RTP通常被用作任何新传输协议之上的一层。新传输协议的设计应考虑到这一点，或者通过避免RTP报头中可用信息的过度重复，或者通过建议对RTP进行修改，例如减少RTP报头，删除与新协议报头冗余的任何字段。
In the first half of this document, we have argued for providing congestion control at the transport layer as an alternative to UDP, instead of relying on congestion control supplied only above or below UDP. In this section, we have examined the possibilities of modifying SCTP, modifying TCP, and designing a new transport protocol. In large part because of the requirement for unreliable transport, and for accommodating TFRC as well as TCP-like congestion control, we have concluded that modifications of SCTP or TCP are not the best answer and that a new transport protocol is needed. Thus, we have argued for the need for a new transport protocol that offers unreliable delivery, accommodates TFRC as well as TCP-like congestion control, accommodates the use of ECN, and requires minimal overhead in packet size and in the state and CPU processing required at the data receiver.
在本文档的前半部分中，我们主张在传输层提供拥塞控制，作为UDP的替代方案，而不是依赖仅在UDP之上或之下提供的拥塞控制。在本节中，我们研究了修改SCTP、修改TCP和设计新传输协议的可能性。在很大程度上，由于对不可靠传输的要求，以及为了适应TFRC以及类似TCP的拥塞控制，我们得出结论，修改SCTP或TCP不是最佳答案，需要一种新的传输协议。因此，我们主张需要一种新的传输协议，该协议提供不可靠的传输，适应TFRC以及类似TCP的拥塞控制，适应ECN的使用，并且在数据接收器所需的数据包大小、状态和CPU处理方面需要最小的开销。
The goal of this work is to provide general congestion control mechanisms that will actually be used by many of the applications that currently use UDP. This may include applications that are perfectly happy without end-to-end congestion control. Several of our design requirements follow from a desire to design and deploy a congestion-controlled protocol that is actually attractive to these "reluctant" applications. These design requirements include a choice between different forms of congestion control, moderate overhead in the size of the packet header, and the use of Explicit Congestion Notification (ECN) and the ECN nonce [RFC3540], which provide positive benefit to the application itself.
这项工作的目标是提供通用的拥塞控制机制，这些机制将被当前使用UDP的许多应用程序实际使用。这可能包括没有端到端拥塞控制的应用程序。我们的一些设计需求源于设计和部署拥塞控制协议的愿望，该协议实际上对这些“不情愿”的应用程序具有吸引力。这些设计要求包括选择不同形式的拥塞控制、数据包报头大小的适度开销以及使用显式拥塞通知（ECN）和ECN nonce[RFC3540]，这为应用程序本身提供了积极的好处。
There will always be a few flows that are resistant to the use of end-to-end congestion control, preferring an environment where end-to-end congestion control is used by everyone else, but not by themselves. There has been substantial agreement [RFC2309, FF99] that in order to maintain the continued use of end-to-end congestion control, router mechanisms are needed to detect and penalize uncontrolled high-bandwidth flows in times of high congestion; these router mechanisms are colloquially known as "penalty boxes". However, before undertaking a concerted effort toward the deployment of penalty boxes in the Internet, it seems reasonable, and more effective, to first make a concerted effort to make end-to-end congestion control easily available to applications currently using UDP.
总会有一些流抵制端到端拥塞控制的使用，更喜欢端到端拥塞控制由其他所有人使用，而不是由他们自己使用的环境。已经达成了实质性协议[RFC2309，FF99]，即为了保持端到端拥塞控制的持续使用，需要路由器机制在高拥塞时检测和惩罚不受控制的高带宽流；这些路由器机制通俗地称为“惩罚盒”。然而，在采取协调一致的措施在互联网上部署惩罚箱之前，首先采取协调一致的措施，使当前使用UDP的应用程序能够轻松地使用端到端拥塞控制，这似乎是合理的，也是更有效的。
This section mentions some additional design considerations that should be considered in designing a new transport protocol.
本节提到了在设计新的传输协议时应考虑的一些其他设计注意事项。
o Mobility: Mechanisms for multihoming and mobility are one area of additional functionality that cannot necessarily be layered cleanly and effectively on top of a transport protocol. Thus, one outstanding design decision with any new transport protocol concerns whether to incorporate mechanisms for multihoming and mobility into the protocol itself. The current version of DCCP [RFC4340] includes no multihoming or mobility support.
o 移动性：多归属和移动性机制是附加功能的一个领域，不一定要在传输协议之上清晰有效地分层。因此，任何新传输协议的一个突出设计决策涉及是否将多归属和移动性机制纳入协议本身。当前版本的DCCP[RFC4340]不包括多主或移动支持。
o Defense against DoS attacks and spoofing: A reliable handshake for connection setup and teardown offers protection against DoS and spoofing attacks. Mechanisms allowing a server to avoid holding any state for unacknowledged connection attempts or already-finished connections offer additional protection against DoS attacks. Thus, in designing a new transport protocol, even one designed to provide minimal functionality, the requirements for
o 防御DoS攻击和欺骗：连接设置和断开的可靠握手可防止DoS攻击和欺骗攻击。允许服务器避免为未确认的连接尝试或已完成的连接保留任何状态的机制为DoS攻击提供了额外的保护。因此，在设计新的传输协议时，即使是设计为提供最小功能的传输协议，也要满足以下要求：
providing defense against DoS attacks and spoofing need to be considered.
需要考虑防御DoS攻击和欺骗。
o Interoperation with RTP: As Section 3.3.3 describes, attention should be paid to any necessary or desirable changes in RTP when it is used over the new protocol, such as reduced RTP headers.
o 与RTP的互操作：如第3.3.3节所述，在新协议上使用RTP时，应注意RTP中任何必要或可取的更改，例如减少RTP头。
o API: Some functionality required by the protocol, or useful for applications using the protocol, may require the definition of new API mechanisms. Examples include allowing applications to decide what information to put in a packet at transmission time, and providing applications with some information about packet sequence numbers.
o API：协议要求的某些功能，或对使用协议的应用程序有用的功能，可能需要定义新的API机制。示例包括允许应用程序决定在传输时将哪些信息放入数据包，以及向应用程序提供有关数据包序列号的一些信息。
o Interactions with NATs and firewalls: NATs and firewalls don't interact well with UDP, with its lack of explicit flow setup and teardown and, in practice, the lack of well-known ports for many UDP applications. Some of these issues are application specific; others should be addressed by the transport protocol itself.
o 与NAT和防火墙的交互：NAT和防火墙与UDP的交互不好，因为它缺乏显式的流设置和拆卸，并且在实践中，许多UDP应用程序缺少众所周知的端口。其中一些问题是特定于应用程序的；其他问题应由传输协议本身解决。
o Consider general experiences with unicast transport: A Requirements for Unicast Transport/Sessions (RUTS) BOF was held at the IETF meeting in December 1998, with the goal of understanding the requirements of applications whose needs were not met by TCP [RUTS]. Not all of those unmet needs are relevant to or appropriate for a unicast, congestion-controlled, unreliable flow of datagrams designed for long-lived transfers. Some are, however, and any new protocol should address those needs and other requirements derived from the community's experience. We believe that this document addresses the requirements relevant to our problem area that were brought up at the RUTS BOF.
o 考虑单播传输的一般经验：单播传输/会话（RUTS）BOF的要求在1998年12月的IETF会议上举行，目的是了解TCP [RUTS]不满足需求的应用的要求。并非所有这些未满足的需求都与设计用于长期传输的单播、拥塞控制、不可靠的数据报流相关或适用。然而，有些是，任何新的协议都应满足这些需求和从社区经验中得出的其他要求。我们认为，本文件阐述了在RUTS转炉上提出的与我们的问题领域相关的要求。
Up until now, this document has discussed the transport and congestion control requirements of applications that generate long-lived, large flows of unreliable datagrams. This section discusses briefly the transport needs of another class of applications, those of request/response transfers where the response might be a small number of packets, with preferences that include both reliable delivery and a minimum of state maintained at the ends. The reliable delivery could be accomplished, for example, by having the receiver re-query when one or more of the packets in the response is lost. This is a class of applications whose needs are not well-met by either UDP or by TCP.
到目前为止，本文档讨论了生成长期、大量不可靠数据报的应用程序的传输和拥塞控制要求。本节简要讨论了另一类应用程序的传输需求，即请求/响应传输的传输需求，其中响应可能是少量的数据包，首选项包括可靠传输和端部保持的最低状态。例如，当响应中的一个或多个分组丢失时，可通过使接收器重新查询来实现可靠传递。这是一类应用程序，UDP或TCP都不能很好地满足其需求。
Although there is a legitimate need for a transport protocol for such short-lived reliable flows of such request/response applications, we believe that the overlap with the requirements of DCCP is almost non-existent and that DCCP should not be designed to meet the needs of these request/response applications. Areas of non-compatible requirements include the following:
尽管对于此类请求/响应应用程序的这种短期可靠流，有合理的传输协议需求，但我们认为与DCCP要求的重叠几乎不存在，DCCP的设计不应满足这些请求/响应应用程序的需求。不兼容要求的领域包括：
o Reliability: DCCP applications don't need reliability (and long-lived applications that do require reliability are well-suited to TCP or SCTP). In contrast, these short-lived request/response applications do require reliability (possibly client-driven reliability in the form of requesting missing segments of a response).
o 可靠性：DCCP应用程序不需要可靠性（确实需要可靠性的长寿命应用程序非常适合TCP或SCTP）。相比之下，这些短期请求/响应应用程序确实需要可靠性（可能是请求响应缺失部分的形式的客户机驱动的可靠性）。
o Connection setup and teardown: Because DCCP is aimed at flows whose duration is often unknown in advance, it addresses interactions with NATs and firewalls by having explicit handshakes for setup and teardown. In contrast, the short-lived request/response applications know the transfer length in advance, but cannot tolerate the additional delay of a handshake for flow setup. Thus, mechanisms for interacting with NATs and firewalls are likely to be completely different for the two sets of applications.
o 连接设置和拆卸：因为DCCP针对的是持续时间通常事先未知的流，所以它通过为设置和拆卸进行显式握手来解决与NAT和防火墙的交互。相反，短期请求/响应应用程序提前知道传输长度，但不能容忍流设置握手的额外延迟。因此，对于这两组应用程序，与NAT和防火墙交互的机制可能完全不同。
o Congestion control mechanisms: The styles of congestion control mechanisms and negotiations of congestion control features are heavily dependent on the flow duration. In addition, the preference of the request/response applications for a stateless server strongly impacts the congestion control choices. Thus, DCCP and the short-lived request/response applications have rather different requirements both for congestion control mechanisms and for negotiation procedures.
o 拥塞控制机制：拥塞控制机制的样式和拥塞控制特性的协商在很大程度上取决于流持续时间。此外，请求/响应应用程序对无状态服务器的偏好严重影响拥塞控制选择。因此，DCCP和短期请求/响应应用程序对拥塞控制机制和协商过程都有相当不同的要求。
Our problem statement has discussed the need for implementing congestion control for unreliable flows. Additional problems concern the need for low overhead, the problems of firewall traversal, and the need for reliable parameter negotiation. Our consideration of the problem statement has resulted in the following general recommendations:
我们的问题陈述讨论了对不可靠流实施拥塞控制的必要性。其他问题涉及低开销的需要、防火墙穿越的问题以及可靠参数协商的需要。我们对问题陈述的审议产生了以下一般性建议：
o A unicast transport protocol for unreliable datagrams should be developed, including mandatory, built-in congestion control, explicit connection setup and teardown, reliable feature negotiation, and reliable congestion feedback.
o 应为不可靠数据报开发单播传输协议，包括强制、内置拥塞控制、显式连接设置和断开、可靠的功能协商和可靠的拥塞反馈。
o The protocol must provide a set of congestion control mechanisms from which the application may choose. These mechanisms should include, at minimum, TCP-like congestion control and a more slowly-responding congestion control such as TFRC.
o 协议必须提供一组拥塞控制机制，应用程序可以从中进行选择。这些机制至少应包括类似TCP的拥塞控制和响应较慢的拥塞控制，如TFRC。
o Important features of the connection, such as the congestion control mechanism in use, should be reliably negotiated by both endpoints.
o 连接的重要特性，如使用中的拥塞控制机制，应由两个端点可靠地协商。
o Support for ECN should be included. (Applications could still make the decision not to use ECN for a particular session.)
o 应包括对ECN的支持。（应用程序仍然可以决定在特定会话中不使用ECN。）
o The overhead must be low, in terms of both packet size and protocol complexity.
o 就数据包大小和协议复杂性而言，开销必须很低。
o Some DoS protection for servers must be included. In particular, servers can make themselves resistant to spoofed connection attacks ("SYN floods").
o 必须包括一些服务器的DoS保护。特别是，服务器可以使自己抵御伪造的连接攻击（“SYN洪水”）。
o Connection setup and teardown must use explicit handshakes, facilitating transmission through stateful firewalls.
o 连接设置和断开必须使用显式握手，以便通过有状态防火墙进行传输。
In 2002, there was judged to be a consensus about the need for a new unicast transport protocol for unreliable datagrams, and the next step was then the consideration of more detailed architectural issues.
在2002年，对于不可靠数据报是否需要一个新的单播传输协议，人们达成了共识，下一步是考虑更详细的体系结构问题。
There are no security considerations for this document. It does discuss a number of security issues in the course of problem analysis, such as DoS resistance and firewall traversal. The security considerations for DCCP are discussed separately in [RFC4340].
此文档没有安全注意事项。在问题分析过程中，它确实讨论了一些安全问题，例如拒绝服务和防火墙穿越。[RFC4340]中分别讨论了DCCP的安全注意事项。
We would like to thank Spencer Dawkins, Jiten Goel, Jeff Hammond, Lars-Erik Jonsson, John Loughney, Michael Mealling, and Rik Wade for feedback on earlier versions of this document. We would also like to thank members of the Transport Area Working Group and of the DCCP Working Group for discussions of these issues.
我们要感谢斯宾塞·道金斯、吉顿·戈尔、杰夫·哈蒙德、拉尔斯·埃里克·琼森、约翰·拉夫尼、迈克尔·米林和里克·韦德对本文件早期版本的反馈。我们还要感谢运输区工作组和DCCP工作组成员对这些问题的讨论。
Informative References
资料性引用
[BRS99] Balakrishnan, H., Rahul, H., and S. Seshan, "An Integrated Congestion Management Architecture for Internet Hosts", SIGCOMM, Sept. 1999.
[BRS99]Balakrishnan，H.，Rahul，H.，和S.Seshan，“互联网主机的集成拥塞管理架构”，SIGCOMM，1999年9月。
[FF99] Floyd, S. and K. Fall, "Promoting the Use of End-to-End Congestion Control in the Internet", IEEE/ACM Transactions on Networking, August 1999.
[FF99]Floyd，S.和K.Fall，“促进互联网中端到端拥塞控制的使用”，IEEE/ACM网络交易，1999年8月。
[PF01] Padhye, J. and S. Floyd, "Identifying the TCP Behavior of Web Servers", SIGCOMM 2001.
[PF01]Padhye，J.和S.Floyd，“识别Web服务器的TCP行为”，SIGCOMM 2001。
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
[RFC2309]Braden，B.，Clark，D.，Crowcroft，J.，Davie，B.，Deering，S.，Estrin，D.，Floyd，S.，Jacobson，V.，Minshall，G.，Partridge，C.，Peterson，L.，Ramakrishnan，K.，Shenker，S.，Wroclawski，J.，和L.Zhang，“关于互联网中队列管理和拥塞避免的建议”，RFC 2309，1998年4月。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2326]Schulzrinne，H.，Rao，A.，和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
[RFC2525] Paxson, V., Allman, M., Dawson, S., Fenner, W., Griner, J., Heavens, I., Lahey, K., Semke, J., and B. Volz, "Known TCP Implementation Problems", RFC 2525, March 1999.
[RFC2525]Paxson，V.，Allman，M.，Dawson，S.，Fenner，W.，Griner，J.，Skys，I.，Lahey，K.，Semke，J.，和B.Volz，“已知的TCP实施问题”，RFC 25251999年3月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，2000年9月。
[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月。
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC 3124, June 2001.
[RFC3124]Balakrishnan，H.和S.Seshan，“拥堵管理者”，RFC31242001年6月。
[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月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[RFC3448]Handley，M.，Floyd，S.，Padhye，J.，和J.Widmer，“TCP友好速率控制（TFRC）：协议规范”，RFC 3448，2003年1月。
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003.
[RFC3540]Spring，N.，Weterral，D.，和D.Ely，“带有nonce的鲁棒显式拥塞通知（ECN）信令”，RFC 35402003年6月。
[RFC3714] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet", RFC 3714, March 2004.
[RFC3714]Floyd，S.和J.Kempf，“IAB对互联网语音流量拥塞控制的关注”，RFC 3714，2004年3月。
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
[RFC3758]Stewart，R.，Ramalho，M.，Xie，Q.，Tuexen，M.，和P.Conrad，“流控制传输协议（SCTP）部分可靠性扩展”，RFC 3758，2004年5月。
[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月。
[RUTS] Requirements for Unicast Transport/Sessions (RUTS) BOF, Dec. 7, 1998. URL "http://www.ietf.org/proceedings/98dec/43rd-ietf-98dec-142.html".
[RUTS]单播传输/会话（RUTS）BOF的要求，1998年12月7日。URL“http://www.ietf.org/proceedings/98dec/43rd-ietf-98dec-142.html".
Authors' Addresses
作者地址
Sally Floyd ICSI Center for Internet Research (ICIR), International Computer Science Institute, 1947 Center Street, Suite 600 Berkeley, CA 94704 USA
Sally Floyd ICSI互联网研究中心（ICIR），国际计算机科学研究所，美国加利福尼亚州伯克利中心街1947号600室，邮编94704
EMail: floyd@icir.org
EMail: floyd@icir.org
Mark Handley Department of Computer Science University College London Gower Street London WC1E 6BT UK
马克·汉德利英国伦敦高尔街大学学院计算机科学系伦敦WC1E 6BT
EMail: M.Handley@cs.ucl.ac.uk
EMail: M.Handley@cs.ucl.ac.uk
Eddie Kohler 4531C Boelter Hall UCLA Computer Science Department Los Angeles, CA 90095 USA
Eddie Kohler 4531C Boelter Hall加州大学洛杉矶分校计算机科学系美国加利福尼亚州洛杉矶90095
EMail: kohler@cs.ucla.edu
EMail: kohler@cs.ucla.edu
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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 provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。