本备忘录的状态
本文档讲述了一种Internet社区的Internet最优通用的实例，它需要进一步进行讨论和建议以得到改进。本备忘录的发布不受任何限制。
版权声明
Copyright(C)TheInternetSociety(2000).AllRightsReserved.
摘要
本文档的目的是解释Internet中的拥塞控制的必要性和讨论什么构成了正确的拥塞控制。目标之一是阐释忽视运用合适的拥塞控制的危险，目标之二是讨论IETF（InternetEngineeringTaskForce,Internet工程任务组）在新的拥塞控制协议标准化方面的作用。
1.介绍
本文档很大程度上采纳了早期RFCs文档，在某些地方对早期的文档[RFC2309,RFC2357]从整体上作了重新改写.我们还借助了旨于端到端的拥塞控制需求[参见FF99]的参考资料.
2.拥塞控制的当前标准
端到端拥塞控制的IETF标准关注的方面包括集中在特定的协议（例如TCP协议[RFC2581],可靠的多点传送协议[RFC2357])；终端节点和路由器之间的拥塞信息(例如明确的拥塞通告[RFC2481])交换的句法和语义；不同服务的服务质量的期望值。端到端的拥塞控制的作用也在一个关于“Internet中的队列治理和避免拥塞的建议”[参见RFC2309]的RFC报告中进行了讨论。RFC2309提出了在路由器中活跃的队列治理机制的配置和对路由器机制设计的延续来处理对拥塞通告无回应的流。我们能够轻松地从RFC2309中借用一些端到端的拥塞控制的概括性的讨论。
与上面提到的RFCs资料相比，本文档对拥塞控制的原理进行更一般性的讨论。Internet成功的一个要害因素就是TCP协议的避免拥塞机制。当前TCP协议在Internet中仍然是占主导地位的传输协议，但它不是适用于任何地方，有越来越多的应用由于某种原因没有选择使用TCP协议。通信不仅包括多点传送通信，而且包括单点传送通信，诸如不需要可靠性的流化的多媒体，以及包括象DNS(DomainNameServer域名服务器)或路由信息的通信，它们带有被认为对网络运行至关重要的短信息。许多通信并不使用任何形式的预留带宽或端到端拥塞控制。为了保持最优传输量，端到端的拥塞控制的继续使用对保持Internet的稳定至关重要。
本文档也讨论IETF在新的拥塞控制协议标准化中的一般作用。对于区别性服务和集成性服务的拥塞控制的讨论在本文档中不涉及。集成性或区别性服务能够保证端到端的网络带宽，所以不需要端到端的拥塞控制机制。

3.端到端拥塞控制的发展
3.1防止网络因拥塞而崩溃
Internet协议体系是基于使用IP协议实现无连接的端到端的包交换服务。无连接设计的优势灵活和健壮已经被充分的证实了。然而这些优势并不是没有代价的：在高负载情况下提供优质服务需要更仔细的设计。实际上，不重视动态包交换会导致严重的服务降级或“Internet熔化“。这个现象首先被观察到是在1980年中叶网络的早期发展阶段[参见RFC896]，在技术上称之为”拥塞崩溃“。TCP的最初说明[参见RFC793]包括基于窗口的流控制，它作为接受方治理发送方发送数据的方式。流控制被用来防止接受方可用的数据缓冲空间的溢出。[RFC793]报告指出由于错误或网络拥塞，响应拥塞的流控制窗口不进行动态的调整，数据段可能丢失。
VanJacobson提出了对“Internet熔化”的初始修补。1986年初，Jacobson开发了现在在TCP应用[参见Jacobson88,RFC2581]中的避免拥塞机制。运行在主机中的这些机制使得TCP连接在拥塞时回退，象我们所说的TCP流对网络中的拥塞信号进行响应（例如“丢弃包”）。正是这些TCP避免拥塞算法防止了今天网络的拥塞崩溃。
然而，故事还没有结束。自从1988年以来对动态网络进行了大量的研究工作，Internet也迅猛发展。TCP协议避免拥塞的机制[参见RFC2581],虽然十分必要和功能强大，但是要在所有情况下提供优质服务还显得不足。另外，在新的拥塞控制机制[参见RFC2357]的发展中，基于路由器的机制正在终端节点的避免拥塞机制的应用中发展。
由于流不使用端到端的拥塞控制，需要提出来的一个重要问题，就是未来网络拥塞崩溃的
潜力问题。1984年，RFC896建议网关应该监测和压制主机的错误行为：对错误响应ICMP源结束信息，而这个信息应该被认为是一个网关断开与主机连接的行为。检测这些错误不是毫无价值的，对未来的研究是一个很有价值的领域。当前的论文仍然建议正在应用的路由器检测和处罚流对于端到端的拥塞控制[参见FF99]是可以接受的。
3.2公平性
在关注拥塞崩溃之外，我们可以再看看尽最大努力通信的公平性。因为在拥塞时TCP回退，在同样状况的流之间带宽合理公正的共享，大量的TCP连接能够共享一个单独的拥塞连接。流之间带宽公正的共享依靠所有的流都运行兼容的拥塞控制算法。对于TCP协议，这意味着拥塞控制算法构成了当前TCP的说明[参见RFC793,RFC1122,RFC2581].
在相互竞争的流之间的公平问题变得越来越重要由于下面几个原因：第一，由于使用窗口缩放[参见RFC1323]单个的TCPs即使在高传输延迟的通路上都能使用高带宽。第二，随着网络的发展，网络用户希望高带宽和低延迟的通信，而不是在后台的一个大文件的传输。不使用TCP的尽最大努力通信的发展强调拥塞时通信竞争时的公平性。
Internet的普及带来了TCP应用的增长，其中有一些因为缺少工具[参见RFC2525]而不能正确的应用TCP避免拥塞机制。其它一些可能特意应用避免拥塞算法，它们在带宽的使用方面比TCP应用更有利。这使得开发商能够提出一个“快速TCP”。这个应用的逻辑结果将是TCP应用的盘旋上升或者传输协议的增加，回到没有有效的避免拥塞和网络持续的拥塞的状况。
有一个闻名的方法，不改变传输协议，改变粒度的层次而达到更有效的性能。如同过去对一些WEB浏览器的做法，对同一个地方开放多个连接。这样，有效传输协议不是盘旋上升，相反，带来的是有效的WEB浏览器的盘旋上升或者有效的应用的增加。
这使得合适的“流”的粒度的问题的出现，我们定义‘流’为对于兼顾公平和拥塞控制的应用比较适合的粒度的层次。RFC2309的有一些自然的回答：（1）一个TCP或UDP连接（源地址/端口，目的地址/端口）；（2）一个源/目的主机对；（3）一个给定的源主机或一个给定的目的主机。我们认为源/目的主机对提供了在许多情况下最合适的粒度。拥塞控制的流的粒度，至少部分上，是需要被更广泛的IETF社团接受的政策问题。
再回到RFC2309，我们使用术语“TCP兼容”描述在拥塞情况下行动的流如同产生于确认TCP的流。一个TCP兼容的流响应拥塞通告，并且能够在可比的条件下（丢弃率，RTT,MTU等），稳定地使用和确认的TCP相同的带宽。
很方便的把流分为三类：（1）TCP兼容流，（2）无响应流，例如当拥塞发生时不减慢的流，（3）响应但不是TCP兼容的流。后面两类包含对网络性能极其重要的更有效的流，我们下面将要讨论。
除了稳定状态的公平性，初始的慢启动的公平性也是一个关注点，还有一个很有效的慢启动过程的流对其它流的短暂影响，慢启动的性能对于许多短期只有少量数据传输的流非凡重要。
3．3关于吞吐量，延迟，丢失的性能优化
除了防止拥塞崩溃和关注公平性，使用端到端拥塞控制的流的第三个理由是它自身的吞吐量，延迟和丢失的性能优化。在某些情况下，例如在高统计的多路技术的环境下，一个流的延迟和丢失大部分独立于自身的发送速率。然而，在低统计多路技术或单个流调度的环境下，一个流的延迟和丢失部分上与流自身的发送速率有关。因此，一个流能使用端到端拥塞控制来限制自身的包的延迟和丢失。然而我们注重到，在象当前的尽最大努力通信的网络环境下，关于拥塞崩溃和流之间竞争的公平性的关注限制了对流来说有用的拥塞控制行为的范围。
4．标准处理的作用
传输协议的标准化不仅包括能够影响互操作性（例如终节点的信息交换）的协议的标准化，而且包括对性能（例如在TCP中，由于包的丢失而减少拥塞窗口）至关重要的机制的标准化。同时，特定应用的细节和传输协议的其它方面，不影响互操作，也不影响性能，就不需要标准化。TCP不需要标准化的区域包括快速重传[参见RFC2582]之后TCP的快速修复过程的细节。附录使用TCP的实例来更具体的讨论在拥塞控制发展中的标准进程的作用。
4.1新的传输协议的发展
除了关注拥塞崩溃的危险，新的传输协议的标准化进程注重在竞争协议中避免拥塞控制的‘军备竞赛’。举个例子，在RFC2357中，TSV区域指挥者和高级职员勾划出了关于可靠的多路传输协议的网络草案的RFC资料的准则。从[RFC2357]看到：“一个IETF的非凡关注是在网络拥塞时可靠多路的通信对其它通信的影响，尤其是在TCP通信的竞争中可靠多路通信的影响...IETF面临的挑战是鼓励可靠多路技术的研究和应用，使得可靠多路技术的应用需求能尽可能快的被满足，同时保护网络免于由于不正确的可靠多路机制的广泛应用带来的拥塞灾难或崩溃。“
关于新的可靠多路传输协议的RFC资料的技术准则包括：“是否有拥塞控制机制？它是如何执行的？它何时无效？注重网络中比TCP更有效的拥塞控制机制面临并不威胁网络稳定的许多负担。
期望在通信竞争中的新的传输协议的效果将不仅应用于可靠的多路协议，而且同样应用于不可靠的单路、可靠的单路和不可靠的多路通信量中。这是很合理的。
4.2影响拥塞控制的应用层问题
一个浏览器对相同的目的地址打开多个连接的问题可以在RFC2626中找到，RFC2616在8.1.4节中说明“使用不间断的连接的客户机应该限制它们同时保持与给定的服务器连接的数量。单用户客户机不应该保持多于2个与任何服务器或代理的连接。”
4.3标准化进程的新发展
IETF能够影响拥塞控制的进展，其最明显的发展集成和区分服务[参见RFC2212,RFC2475]和明确的拥塞通告[参见RFC2481]。然而，其它戏剧性的发展同样可能影响拥塞控制。
已经在努力构建终节点拥塞治理[参见BS00]来使得一个发送方的多个并发流到达相同的接受方来共享拥塞控制状态。通过答应对同一个目的多个连接在端到端的拥塞控制过程中作为一个流，拥塞治理者能够答应单个慢启动的连接利用先前端到端路径的拥塞状态信息。进一步，拥塞治理者能够去除在相同源/目的对中打开的多个流的拥塞控制危险，能够用来答应一个浏览器同时开放对同一个目的的多个连接。
5.拥塞崩溃的描述
这部分讨论非传递的包的拥塞崩溃的某些细节，并且说明非响应流如何有助于网络拥塞崩溃。这部分采用了[FF99]的资料。
一般说，拥塞崩溃发生在网络负载的增加导致网络效率的降低的时候。第三部分已经讨论过，拥塞崩溃最先在1980年中叶[RFC896]提出，主要由于TCP连接的不必要的重传那些正在传送或已经被接收方接收了的数据包。我们称不必要的重传数据包而引起的拥塞崩溃为典型的拥塞崩溃。典型的拥塞崩溃是导致吞吐量只是正常情况下的一小部分的稳定状况[参见RFC896].典型的拥塞崩溃的问题已经通过定时器和在现代TCP[参见Jacobson88]的应用中的拥塞控制机制的改进基本得到解决。
第二种形式潜在的拥塞崩溃由于非传递的数据包而发生。当网络传送的数据包在到达最终目的地之前被丢弃而导致带宽被浪费的时候就会出现由于非传递的数据包而发生拥塞崩溃。由于拥塞连接的部分带宽用来可再生性的工作，不同的设定可能有不同程度的拥塞崩溃。非传递数据包的拥塞崩溃的危险基本上是由于开路循环应用的增加的配置没有使用端到端拥塞控制。甚至更多的破坏将是尽最大努力通信的应用通过增加发送率来增加包的丢弃率（例如自动使用FEC增加的层次）。
表1给出了在数据包未到达目的地却很少带宽浪费情况下非传送数据包的拥塞崩溃的在某个设定下的结果。这个模拟设定在三个TCP流和一个UDP流在一个1.5Mbps的链路上竞争。所有节点的存取连接是10Mbps而UDP流的接收方的存取连接是128Kbps，只有共享带宽的9%。当UDP源速率超过128Kbps，大多数UDP包将在最终连接的输出端口丢弃。
到达UDPTCP总计
比率正常输出正常输出正常输出
---------------------------------------------------------
0.70.798.599.2
1.81.797.399.1
2.62.696.098.6
5.35.292.797.9
8.88.487.195.5
10.58.484.893.2（续）
（续）
13.18.481.489.8
17.58.477.385.7
26.38.464.572.8
52.68.438.146.4
58.48.432.841.2
65.78.428.536.8
75.18.419.728.1
87.68.411.319.7
105.28.43.411.8
131.58.42.410.7
表1三个TCP流和一个UDP流的模拟
表1显示在拥塞的1，5Mbps链路上发送方的UDP的到达率，UDP的正常输出（定义为传输到接收方的带宽），TCP正常输出（定义为传输到TCP接收方的带宽），和总计正常输出。每个比率作为拥塞链路的带宽的一部分。随着UDP源比率的增加，TCP的正常输出直线下降，UDP的正常输出几乎保持不变。因此，随着UDP数据流增加它的负载，只是影响TCP和总计的正常输出。在拥塞链路上，UDP流极其浪费本应属于TCP流的带宽，从整体上使得网络的正常输出降低到拥塞链路的带宽的一小部分。
表1的模拟阐释了不公平性和拥塞崩溃。[FF99]中谈到兼容拥塞控制不是提供公平性的唯一方法，在拥塞的路由器中单流调度也是保证公平性的可选机制。然而，[FF99]谈到单流调度不能防止拥塞崩溃。
消除非传递数据包的拥塞崩溃的危险有两个可选的方法。第一个方法是终端节点使用有效的端到端的拥塞控制。更为非凡的是，需要一个流避免在路径的第一个拥塞连接的下端出现严重的丢失现象。（这里，我们将考虑一个拥塞链路，链路上的任何流正在被链路上其它通信使用的带宽。）假定一个终端节点不能区别一个拥塞链路的路径和一个多个拥塞链路的路径，对于一个流避免在路径的拥塞连接的下端出现严重的丢失现象，最可靠的方法是使用端到端的拥塞控制，减少发送方现在丢失的发送比率。
第二个方法是保证网络中拥塞链路上的数据包将被传送到接收方[参见RFC2212,RFC2475]。我们注重到在第一个端到端的拥塞控制方法和第二个端到端的带宽保证方法之间选择不是一个或者这个或者那个的问题，一些通信使用端到端的拥塞控制和其余通信使用端到端的带宽保证能够防止拥塞崩溃。
6.端到端的拥塞控制的构成
本文档已经讨论了拥塞控制新的构成中拥塞崩溃和TCP公平性。然而，这不意味着拥塞崩溃和TCP的公平性对所有的在基于TCP通过折半减少发送速率来响应每个包的丢失的“加法增加乘法递减算法”的情况下尽最大努力的通信配置拥塞控制都有必要。这部分单独讨论拥塞崩溃和TCP公平性两个方面的关联。
6.1避免拥塞崩溃的端到端的拥塞控制
非传递数据包的拥塞崩溃的避免需要流避免在链路的下端设定高的发送率，多拥塞链路和持续的高包丢弃率。因为引起拥塞崩溃的由浪费带宽的数据包组成的非传递数据包只在链路下端被丢弃，所以这种拥塞崩溃不可能在每个流只在一个拥塞连接上通过或者只有一小部分数据包在第一个拥塞链路的下端被丢弃的环境下出现。因此，任何形式的拥塞控制成功地在现存的对于避免非传递数据包的拥塞崩溃应该有足够的包丢弃率的情况下避免高的发送速率。
我们将注重到附加的对IP体系结构的明确拥塞通告不会去除尽最大可能的通信的拥塞崩溃危险。明确拥塞通告答应路由器在包的头部设置一位作为终节点的拥塞的标记，不强制性的依靠于以包的丢弃来标记拥塞。然而，通过明确拥塞通告，包的标记将在适中的拥塞中取代包的丢弃。非凡情况下，当拥塞非常严重，并且路由器的缓存溢出时路由器只有丢弃达到的包。
6.2为了TCP公平性的端到端的拥塞控制
在[RFC2357]中，TCP的公平性对可行的在尽可能传送的通信中的端到端的拥塞控制机制的范围有重要但不削弱的局限。在所有拥塞链路上的单流调度环境将使流彼此孤立，并且消除拥塞控制机制成为TCP兼容的需要。在区别性的服务的环境下，流标记为某一特定服务类别，答应在拥塞控制不需要成为TCP兼容的通信中一个完整的服务类别的出现。
类似的，一个有价格限制的环境，或者一个有价格范例的不同的服务类别能够替代对TCP的公平性的关注。然而，对于当前的网络环境，其它的尽最大努力传输的通信能够在先进先出的队列中与TCP通信相竞争，TCP由于没有公平性会导致在高拥塞的情况下一个流会‘饿死’另外一个流，这个问题已经在表1中阐述了。
然而TCP兼容拥塞控制过程的列表不局限于使用与TCP相同的增加/减少参数的“加法式增加/乘法式减少“算法。其它的TCP兼容拥塞控制过程包括基于速率的“加法式增加/乘法式减少“变量；有不同但却保证同样稳定状态的增加/减少参数的“加法式增加/乘法式减少“算法；基于平衡的拥塞控制，发送方通过调整发送速率来响应长期的包丢失的信息；接收方从分层多路技术组提交和不提交的分层多路技术；还有可能我们没有考虑的其它形式。
7.致谢
本文档的许多资料直接取自RFC关于端到端拥塞控制。这里试图对这些年来许多人讨论出来的思想作个总结。尤其感谢“终端到终端研究"工作组，“可靠多路研究“工作组和传输领域指导委员会的成员。本文档也受益于传输领域工作组的讨论和反馈。非凡感谢MarkAllman对本文档的早期版本的意见。
8.参考资料
[BS00]BalakrishnanH.andS.Seshan,"拥塞治理",
WorkinProgress.
[DMKM00]Dawkins,S.,Montenegro,G.,Kojo,M.andV.Magret,
"慢速链路的端到端的性能关联",
WorkinProgress.
[FF99]Floyd,S.andK.Fall,"在网络中促进使用端到端的拥塞控制",IEEE/ACM
ransactionsonNetworking,August1999.URL
http://www.aciri.org/floyd/end2end-paper.Html
[HPF00]Handley,M.,Padhye,J.andS.Floyd,"TCP拥塞的窗口有效性",RFC2861,June2000.
[Jacobson88]V.Jacobson,拥塞的避免和控制,ACMSIGCOMM"88,August1988.
[RFC793]Postel,J.,"传输控制协议",STD7,RFC793,September1981.
[RFC896]Nagle,J.,"在IP/TCP中的拥塞控制",RFC896,January1984.
[RFC1122]Braden,R.,Ed.,"网络主机的需求-通信层",STD3,RFC1122,October1989.
[RFC1323]Jacobson,V.,Braden,R.andD.Borman,"TCP高性能的扩展",RFC1323,May1992.
[RFC2119]Bradner,S.,"在RFCs中标志需求层次的要害字",BCP14,RFC2119,March1997.
[RFC2212]Shenker,S.,Partridge,C.andR.Guerin,"保证服务质量的说明",RFC2212,September1997.
[RFC2309]Braden,R.,Clark,D.,Crowcroft,J.,Davie,B.,
Deering,S.,Estrin,D.,Floyd,S.,Jacobson,V.,
Minshall,G.,Partridge,C.,Peterson,L.,Ramakrishnan,
K.K.,Shenker,S.,Wroclawski,J.,andL.Zhang,
"网络中队列治理和避免拥塞的建议",RFC2309,April1998.
[RFC2357]Mankin,A.,Romanow,A.,Bradner,S.andV.Paxson,
"评估可靠的多路传输和应用协议的IETF准则",RFC2357,June
1998.
[RFC2414]Allman,M.,Floyd,S.andC.Partridge,"增加中的TCP的初始化窗口",RFC2414,September1998.
[RFC2475]Blake,S.,Black,D.,Carlson,M.,Davies,E.,Wang,Z.
andW.Weiss,"区分服务的体系结构",RFC2475,December1998.
[RFC2481]RamakrishnanK.andS.Floyd,"添加明确拥塞通告到IP的建议",RFC2481,
January1999.

[RFC2525]Paxson,V.,Allman,M.,Dawson,S.,Fenner,W.,Griner,
J.,Heavens,I.,Lahey,K.,Semke,J.andB.Volz,
"有名的TCP应用问题",RFC2525,March
1999.
[RFC2581]Allman,M.,Paxson,V.andW.Stevens,"TCP拥塞控制",RFC2581,April1999.
[RFC2582]Floyd,S.andT.Henderson,"TCP的快速修复算法的新的修改",RFC2582,April1999.
[RFC2616]Fielding,R.,Gettys,J.,Mogul,J.,Frystyk,H.,
Masinter,L.,Leach,P.andT.Berners-Lee,"超文本传输协议--HTTP/1.1",RFC2616,June1999.
[SCWA99]S.Savage,N.Cardwell,D.Wetherall,andT.Anderson,
一个错误行动的接收方的TCP拥塞控制,ACM
ComputerCommunicationsReview,October1999.
[TCPB98]HariBalakrishnan,VenkataN.Padmanabhan,Srinivasan
Seshan,MarkStemm,andRandyH.Katz,一个繁忙的网络服务器的TCP行为:分析和改进,IEEEInfocom,March1998.Availablefrom:
"http://www.cs.berkeley.edu/~hari/papers/infocom98.ps.gz".
[TCPF98]DongLinandH.T.Kung,TCP快速修复策略:分析和改进,IEEEInfocom,March1998.Availablefrom:
"http://www.eecs.harvard.edu/networking/papers/infocom-tcp-final-198.pdf".
9.TCP要说明的问题
在这部分我们将讨论TCP拥塞的非凡情况，来阐释拥塞控制原理的实现，包括加入到传输协议产品的一些细节。
9.1慢启动
TCP发送方不能通过一次性发送一个很大的数据（例如接收方建议的窗口）来打开一个新的连接。TCP发送方对拥塞窗口的初始值有限制。在慢启动过程中TCP发送方能通过在一个循环周期把两个因素并为一个来提高发送速率。当监测到拥塞或发送方的拥塞窗口比慢启动的临界值大的时候慢启动就结束了。
全局拥塞控制的潜在影响的问题已经被标准化进程鲜明的提出来了，其中包括初始窗口值的增加[参见RFC2414,RFC2581]。
标准化进程提出的问题一般被认为不需要标准化，包括基于速率的步进方式的使用与否，在拥塞窗口到达临界值之前提早结束慢启动的机制。这个机制使得慢启动或多或少比标准的TCP显得保守。
9.2加法式的增加，乘法式的降低
没有拥塞时TCP发送方通过每个循环周期加一个包来增加拥塞窗口。出现拥塞现象时，TCP发送方折半减少拥塞窗口。（更准确地说，新的拥塞窗口是拥塞窗口最小值和接收方建议的窗口的一半）。
全局拥塞控制的潜在影响的问题已经被标准化进程鲜明的提出来了，其中包括对‘纯响应‘的流的返回进行拥塞控制的额外的建议。
一个标准化进程没有提出一般被认为不需要标准化的问题，包括拥塞窗口的改变应用在字节数的上界继续在管道中的情况下，而不是应用在确认后滑动窗口启动的情况下。（很明显，接收方推荐的窗口应用在确认后滑动窗口启动。因为从确认方接收的包被放置在TCP接收方的缓存中，还没有传给应用程序。然而，拥塞窗口随管道中的包的数量而变化，不需要包括被TCP接收方在无序方式下接收的包。）
9.3重传定时器
TCP发送方设置一个重传定时器来告知网络中一个包已被丢弃。当重传定时器到时了，发送方得知已经有包丢失，把当前的窗口设为原先的一半，开始慢启动，重传丢失的包。假如重传定时器因为重传的包没有被接收到的确认而到时，重传定时器也‘回退‘，把下次重传的时间间隔加倍。
标准化进程很有可能鲜明提出这么一个问题，它潜在的影响全局的拥塞控制，它包括当发送方没有受到确认而事实上并没有包被丢弃时，如何使得重传定时器增加重传时间间隔的修正机制。因为重传定时器到时会导致增加数据包在拥塞链路上不必要的传送，所以网络标准化进程对此非常关注。
9.4快速重传和快速修复
当看到三个重复的确认，TCP发送方知道有包丢失。接着TCP发送方把临界值设为当前窗口的一半，减少拥塞窗口到先前的一半，并重传丢失的包。
标准化进程很有可能鲜明提出这么一个问题，它潜在的影响全局的拥塞控制，它包括当只有一两个重复确认就告知有包丢失的建议。假如设计不好的话，这个建议可能导致增加包在拥塞路径上不必要的传输。
一个标准化进程没有提出，一般被认为不需要标准化的问题，是建议假如拥塞窗口答应的话，发送一个‘新‘的或丢失的包来响应重复确认。举个例子，假如只有一个重复确认，没有更多的确认到达，则发送一个新的包响应，来保持‘响应时钟‘运转。这个建议是一个有益的改变，它不涉及到互操作，也不影响全局拥塞控制，因此不需要IETF标准化进程的介入，就被开发商们所应用。（这个问题事实上已经在[DMKM00]中提过，[DMKM00]建议“研究人员试图收到重复确认后在网络中插入新的通信，[TCPB98]和[TCPF98]都讲述过。）
9.5TCP拥塞控制的其它方面
TCP拥塞控制的其它方面在上面的章节中都没有提到，其中包括空闲或有限制的应用的时期的TCP修复[参见HPF00].
10.安全考虑
本文档已经讨论了拥塞控制的危险和拥塞控制的缺乏。章节3.2讨论了假如相互竞争的流不使用兼容的拥塞控制机制而潜在的不公平性，章节5考虑了假如流不使用端到端的拥塞控制而出现拥塞崩溃的危险。
因为本文档没有提出任何非凡的拥塞控制机制，所以也不需要提供拥塞控制相应的安全措施。然而，我们将注重针对拥塞控制的安全性考虑，IETF文档还有很广阔的范围。例如，单独拥塞控制机制试图解决单独的终节点之间的端到端拥塞控制很有活力[参见SCWA99]。要非凡关注多路拥塞控制，因为通信的分布很难把握，并且单个接收方出现错误后报告拥塞的几率很高。
RFC2309也讨论了网络中无响应的流的潜在威胁，就是流在出现拥塞时不减少发送速率，并且描述了网络需要用来处理流对拥塞通告无响应的机制。我们将注重到这些领域在研究，工程，方法，配置的需要。因为网络有数量众多的流，一些单个流的拥塞控制的危险有一定的限度。相反，分散的危险来自许多终端节点的端到端的拥塞控制的广泛的配置。