rfc2914.txt

RFC文档

潜力问题。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包将在最终连接的输出端口丢弃。
         到达      UDP     TCP      总计
         比率    正常输出  正常输出  正常输出
---------------------------------------------------------
         0.7       0.7      98.5      99.2
         1.8       1.7      97.3      99.1
         2.6       2.6      96.0      98.6
         5.3       5.2      92.7      97.9
         8.8       8.4      87.1      95.5
        10.5       8.4      84.8      93.2  （续）
       （续）
13.1       8.4      81.4      89.8
        17.5       8.4      77.3      85.7
        26.3       8.4      64.5      72.8
        52.6       8.4      38.1      46.4
        58.4       8.4      32.8      41.2
        65.7       8.4      28.5      36.8
        75.1       8.4      19.7      28.1
        87.6       8.4      11.3      19.7
       105.2       8.4       3.4      11.8
       131.5       8.4       2.4      10.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关于端到端拥塞控制。这里试图对这些年来许多人讨论出来的思想作个总结。尤其感谢“终端到终端研究"工作组，“可靠多路研究“工作组和传输领域指导委员会的成员。本文档也受益于传输领域工作组的讨论和反馈。特别感谢Mark Allman对本文档的早期版本的意见。

8.参考资料
[BS00]      Balakrishnan H. and S. Seshan, "拥塞管理",
                Work in Progress.

[DMKM00]  Dawkins, S., Montenegro, G., Kojo, M. and V. Magret,
                "慢速链路的端到端的性能关联",
                Work in Progress.
    
[FF99]      Floyd, S. and K. Fall, "在网络中促进使用端到端的拥塞控制", IEEE/ACM
                ransactions on Networking, August 1999.  URL
                http://www.aciri.org/floyd/end2end-paper.html

[HPF00]      Handley, M., Padhye, J. and S. Floyd, "TCP拥塞的窗口有效性", RFC 2861,         June 2000.

[Jacobson88]  V. Jacobson, 拥塞的避免和控制, ACM SIGCOMM '88, August 1988.