rfc896.txt

中文RFC 384 篇

用户每200ms向TCP输出一个新的字符，并且这个连接要经过以太网，此以太网
的往返时间包括了50ms的软件处理时间。如果没有任何机制来防止短数据报的
拥塞，与 每个字符对应的数据包将被送出，响应是最佳的。开销将是4000%，
但在以太网上可以接受的。而典型的定时器方案，每秒两个数据包的限制，将使
两个或三个字符在一个数据包中被传送。响应性能将降低，即使在高带宽的以太
网上也是没有用的。开销降到1500%，但在以太网上这是个不太好的替换方案。
而我们的方案，用户所敲击的每个字符将找到一条空闲的TCP连接，字符将立刻
被传送，正如在无控制的情况一样。用户将不会感觉到延迟。这样，我们的方案
既可作为无控制的方案运行又可以提供比定时器方案更好的响应。

    第二个测试的情况是同样的Telnet测试，但是测试是在有5秒往返时间的
长距离连接上。如果没有任何机制防止短数据包拥塞，25个数据包将在5秒内
被送出。这儿开销是4000% 。用典型的定时器方案且同样是每秒2个数据包的限
制，将仍有10 个数据包不能处理并引起拥塞。当然往返时间将不会因传送很多
的数据包而得到改善；通常，它会因数据包竞争行时间而变得更糟。这时开销降
到了1500%。然而，用我们的方案，来自用户的第一个字符将发现空闲的TCP连
接且立即传送。接下来的24个字符，以200ms的间隔从用户端到来，将等待远
端主机来的报文。当一个对第一个数据报的确认ACK在5秒末到来时，这24个
等待的字符封装到数据包中被传送出去。这样，我们的方案导致了在没有损失响
应时间的情况下开销减少到320%。用我们的方案响应时间通常因为数据包开销
减少而得到改善。拥塞将减少且往返时间延迟将显著下降。在这个情况中，我们
的方案明显优于其他方法。

    我们对所有的TCP连接使用我们的方案，不仅仅是Telnet连接。让我们看
看用我们的方法为文件传输建立数据连接时将会发生什么。我们将再一次考虑到
这两个极端的情况。

    象前面所提的一样，我们首先考虑以太网的情况。用户现在以512字节块的
大小按TCP所能接受的速度向TCP写数据。用户第一次向TCP写的数据启动传输；
我们的第一个数据报的大小将是512+40字节或552字节。用户的第二次写数据
不会引起传送但会使这个块被缓冲。设想用户在第一个确认到来之前填充TCP的
输出缓冲区。然后，当ACK到来时，满足窗口大小的所有排队数据将被送出，从
那时起，窗口保持为满，每个ACK开始一个传送循环，等待的数据被送出。这样,
在一个往返时间初始周期以后，只有一个块要传送时，我们的方案解决了最大吞
吐量的情况。由于启动延迟在以太网上只有50ms，因此，启动的瞬时延迟是无
关重要的。三种方案都对这种情况提供了等价的性能。

    最后，让我们看看在有5秒往返时间的连接上的文件传输。在第一个确认回
来之前只有一个数据包被发送；窗口将被填充并填满。因为往返时间是5秒，只
有512字节的数据在第一个5秒被发送。假定有一个2k的窗口，一旦第一个确
认来到，2K的数据将被发送，之后，将保持每5秒2K的稳定速率。只有在这种
情况下我们的方案才比定时器方案差，差别只在启动瞬时。稳定状态下的吞吐量
是相同的。朴素的方案和定时器方案在上面所提的情况下都要花250秒来传输
100K字节的文件，我们的方案将花254秒，1.6%的差别。
     			
带ICMP的拥塞控制

    解决了短数据报问题以及在我们自己网络中的极端的短数据报拥塞问题，我
们把注意力转向通常的拥塞控制。既然我们的网络是没有点对点流量控制的纯数
据报网络，对我们而言，在IP标准下可获得的唯一机制是ICMP源抑制报文。在
精心的控制下，我们发现这足以防止严重的拥塞问题。我们发现留心主机或交换
节点对源抑制报文的行为是必要的。
何时发ICMP源抑制报文    
    当前的ICMP标准 规定，无论何时包丢失，ICMP源抑制报文就应该被发送，
此外，当网关发现自己资源不足时也应发送源抑制报文。这里有些二义性，但很
明显,没有送ICMP报文而丢弃数据包违背了的标准。

    我们的基本假设是，在网络正常运行时数据包不应该被丢弃。因此我们想在
发送方使交换节点和网关超负荷之前抑制发送方重发。我们的交换节点在缓冲区
耗尽之前能很好地发送ICMP源抑制报文；直到它们在发送ICMP源抑制报文之前
必须丢弃报文时才等待。正如我们在短数据报问题的分析中演示的，仅仅提供大
量的缓冲是不能解决问题的。通常，我们的经验是，当用了缓冲区的一半左右，
源抑制报文就应该发送了；这不是基于广泛的实验，但似乎是个合理的技术决定。
可以讨论一个自适应方案，这个方案可以调整基于近期经验的抑制产生边界；到
目前为止我们还没有发现这个必要性。

    还有其他的网关实现算法，仅在不只一个包被丢弃之后才产生源抑制报文。
我们认为这种方法是不好的，因为任何基于包丢弃的拥塞控制系统浪费带宽，且
可能在负荷重时容易受拥塞崩溃的影响。我们理解的是，被动地产生源抑制报文
的方案基于这样的担心，害怕确认传输将被抑制以及这将导致连接失败。正如下
面将要展示的，在主机实现中的恰当的源抑制控制排除了这种可能性。


在收到ICMP源抑制报文时做什么
  
     当ICMP收到一个源抑制报文时我们通知TCP或者该层上的任意其他协议。
我们的TCP具体实现的基本行为是减少与源抑制报文中所指出的主机的连接上
未处理的数据的数量。使发送端TCP的反应就象远端主机窗口大小已经减少,从
而实施这个控制。我们的第一个实现过于简单化但却有效；一旦收到源抑制报文，
只要窗口不为空，我们的TCP就认为窗口大小为0并做相应处理。这个行为将持
续到收到一定数量（现在是10）的ACK为止，到那时，TCP回到正常的运行状态
 。Linkabit公司的David Mills 在他的DCN系统中实现了一个类似的但更详细
的对未处理的数据包的节流控制。这个附加的复杂性好象提供了一个获得吞吐量
的方式，但我们没有做过正式的测试。两个实现都有效地防止了交换节点的拥塞
崩溃。

    这样，源抑制方法有效地限制了到有限数量（可能为1）的未处理报文的连
接。因此，通信能继续但是速率降低，那正是期望的效果。

    这个方案有个重要的性质，源抑制不能禁止确认和重传的发送。源抑制在
IP层上的完全实现通常是不成功的，因为IP缺少足够的信息来正确地控制一个
连接的流量。抑制确认信息往往产生重传和不必要的传输。抑制重传可能因重传
超时而使连接丢失。我们的方案将在服务器超负荷下保持活动连接但减少每个连
接的带宽。

    在同一层与TCP一样的其他协议也应该响应源抑制。在每种情况下，我们建
议应该控制新的传输流量但正常对待确认。唯一严重的问题来自于用户数据报协
议，而通常不的主要传输发生器。我们仍未在这些协议中实现任何流量控制。
网关的自防御
    正如我们已经显示的，网关易受拥塞管理不善的主机的攻击。由于产生过多
通信量而引起的主机错误行为不仅防止了主机自身的传输而且能影响了其他不
相关的传输。这个问题可以在主机级处理，但既然一台有故障的主机能影响其他
主机，将来的网关应该有防御能力使它们自己不被那些可恶可憎的主机的这种行
为所影响。我们提供了一些基本的自防御技术。

    曾经在1983年下半年，一个在ARPANT主机中的TCP故障使主机以ARPANET
所能接受的速度疯狂地产生相同数据报的重发报文。通过ARPANET连接到我们网
络的网关饱和，既然这个网关到ARPANET的带宽比到我们网络的要宽，少量有用
的传输能通过。网关忙于发送源抑制报文但故障主机忽略它们。这持续了几个小
时，直到故障主机崩溃。在这期间，我们的网络有效地从ARPANET上断开。

    当网关被迫丢弃一个数据包时，网关慎重地选择要丢弃的数据包。做这个决
定的典型技术是丢弃最近收到的数据包，或者数据包在最长的输出队列的末端。
我们提出一个值得的实用方法是，丢弃在网关中产生最多数据包的队列的对应主
机所产生的最近的数据包，这种策略有助于平衡使用这个网关的各主机间的吞吐
量。我们还没有尝试过这个策略，但它似乎是网关自保护的一个合理开始点。

    另一个策略是丢弃新到来的数据包，如果这个数据包已经在队列中做了一个
拷贝。如果使用哈希技术，为实现这一检查的计算负荷就不是问题。这个检查不
能防止恶毒主机的攻击，但提供了一些保护措施来防止带低劣重传控制的TCP实
现。如果本地主机与本地网络很好地协调工作，那么在快速本地网与慢速长距离
网络之间的网关可以发现这个检查是有价值的。

    理想的情况是网关应该检测出故障主机并抑制它们；这样的检测在纯数据报
系统中是困难的。虽然，对ICMP源抑制报文的响应失败应该被认为是网关与主
机断开的依据。检测这样的失效是重不寻常的但它是一个值得进一步研究的领
域。
 
结论
     
    与纯数据报网络相关的拥塞控制问题是困难的，但有效的解决办法是存在
的。如果TCP/IP在重负荷下运行，TCP实现算法必须以至少和这里描述过的解
决方法一样有效的方式来解决这几个关键的问题。
   在纯ARPANET网中没有这个问题，因为当没有处理的数据包过多时，IMP机制将封锁主
机，但在这种情况下，涉及到纯数据报本地网（比如以太网）或者一个纯数据报网关（比如
ARPANET/MILNET 网关），有大量的小数据报未处理是有可能的。
  ARPANET RFC 792 是当前的标准。国防通讯部门通告我们，在MIL-STD-1777
中的ICMP描述是不完全的，且在这个标准将来的修订版中将被删除。
  这点遵从控制学的观点“不要受比例控制的干扰除非它不工作了。”

RFC896——Congestion Control in IP/TCP Internetworks        TCP/IP互联网上的拥塞控制


1
RFC文档中文翻译计划