另外 ， 假如在一个RTT内 ， 源端同时收到ECN和丢包传达的拥塞指示 ， 则只对其中之一作出拥塞反应 。假如拥塞反应已经开始 ， 则必须等到所有正在传送的数据都被确认后才能开始新的拥塞反应 。
3.4 RED和ECN地结合
将RED和ECN结合起来 ， 假如拥塞是在队列满之前检测到的 ， 那么除了用丢包作为拥塞通知外 ， 对支持ECN的源端和目的端 ， 还可以采在IP包头设置CE位的方法 。这样就避免了不必要的丢包 ， 非凡是对短的TCP连接和对时延敏感的TCP连接而言；另外也避免了不必要的TCP超时重传 。在下面的内容中 ， 我们统一将上述两种方法称为"标记"（mark） 。
3.5 RED的优点和存在地问题
RED在平均队长超过了最大阈值后就丢包 ， 而不是采用诸如设置CE位之类的标记包的方法 ， 从而有效地控制了平均队长 ， 限制了平均时延地大小 。在发生拥塞时 ， RED标记某个流的数据包的概率基本上和该流在路由器中得的带宽成比例 。这是因为发送速度更快的流 ， 其供随机标记的包也更多 。从而消除了对突发流的偏见 。RED标记包的概率依靠于拥塞水平 ， 并且均匀地间隔丢包 ， 避免了由于连续丢包导致地全局同步现象 。总而言之 ， RED是IETF推荐的一种基于路由器的有效的拥塞避免机制 ， 其和传输协议的合作能有效地控制网络上发生的拥塞 。
尽管和"去尾"算法相比 ， RED是一种更为有效的拥塞控制机制 ， 但其仍然有许多问题：
（1） 参数设置问题：RED工作性能的优劣很大长度上是由其预先设置的参数w_Q、min_th和max_th决定的 。一组RED参数也许是给定业务吞吐量的最优化参数 ， 但对于连续丢包、延迟等就未必是最优参数了 。因此如何权衡它们（吞吐量、延迟等）之间的关系 ， 从而找到一组最优的参数仍然是有待进一步研究的问题 。另外 ， RED参数的微小的变化会给总体性能带来很大的影响 。一组RED参数也许在特定的业务环境下表现非常好 ， 但由于Internet 是动态变化的 ， 当流的数量及负荷的改变导致业务环境的变化时 ， 则该组RED参数也会就会给拥塞治理带来非常不利的影响 。
（2） 不能有效估计拥塞的严重性：
图3 一个RED队列治理的例子
图4 理想的队列治理算法工作情况
基于"去尾"机制的TCP拥塞控制的一个很大问题就是从路由器丢包开始 ， 到源端检测到丢包 ， 需相当长时间 。在这段时间里 ， 源端继续以原速或更高的速度发送数据 ， 从而导致更多的包被丢弃 。RED通过检测早期的拥塞从而减轻了这个问题 。但RED必须配置足够的缓冲区来容纳从检测到拥塞到瓶颈链路负荷开始下降这段时间到达的数据包 。RED还要确保送出的拥塞通知信息的速度充分降低了源端的发送速度而不是降低了链路利用率 。但当有大量的活跃的TCP（active TCP connections）连接时 ， 总的流量往往突发性非常高 ， 队长的增减非常迅速 ， 而RED还没有来得及作出很好的行动 。图3显示了在这种情况下RED是如何工作的 。在从t=1开始发生拥塞 ， 直到t=7负荷才小于链路容量 ， 在这之间由于总的流量的突发性 ， 就会有大量包被丢弃或被ECN标记 ， 从而降低了链路使用率 。图4显示了理想的队列治理算法是如何工作的 ， 其传递拥塞指示的速度刚好使得总的源端的发送速度等于或略小于瓶颈带宽 。
要解决这个问题 ， RED不仅需要正确的参数配置 ， 还需要足够大的缓冲区 ， 比如缓冲区是带宽延迟积的两倍 。但假如带宽延迟积很大 ， 又会大大增加端到端的延迟 。而且对那些已经在使用的 ， 存储器不是很大的路由器也无法用此方法解决 。
推荐阅读
- 下 在CISCO路由器上配置NAT功能
- 4 Internet路由器主动式队列管理机制综述
- 3 Internet路由器主动式队列管理机制综述
- 关于路由器cpu利用率过高的解决
- 通过SSH实现Cisco路由器登录
- 无线路由器的设置步骤 新的无线路由器如何设置
- 解决路由器水晶头不亮的方法 路由器水晶头不亮
- 看宽带路由器的市场要点
- Cisco路由器上实现VoIP
- 过滤功能对路由器性能的影响