Next Previous Contents

15. 流量控管之 backbone 程序 (Backbone applications of traffic control)

本章仅作为 backbone routing 的浅介﹐通常用在 >100 megabit 频宽上﹐而且它所需的技术和您家中的 ADSL 大相径庭。

15.1 路由器伫列 (Router queues)

在 Internet 上面﹐router queue 的正常行为特性称为 tail-drop。Tail-drop 就是当伫列达到一定数量之后﹐就开始将所有 '溢出' 的流量丢弃掉。这其实很不公平﹐而且也会导致同步重传(retransmit synchronisation)。当同步重传发生之后﹐已经满载的路由所丢弃的瞬间流量﹐会导致另一波延迟的瞬间流量重传﹐这样又会重新填满已经拥塞的 router。

为了妥善处理线路的瞬间拥塞﹐backbone routers 通常会装备较大的伫列。然不幸的是﹐这些伫列虽然可改善吞吐量(throughput)﹐但却大大的加重延迟﹐且导致 TCP 连线在拥塞的时候变得经常性的流量瞬增。

这些伴随著 tail-drop 而来的弊端﹐已在 Internet 上不断的造成困扰﹐这是由于一些不十分友善(unfriendly)的网路程序使用量不断增加之故。有见及此﹐Linux 核心向我们提供所谓的 RED (Random Early Detect) 机制。

RED 事实上也不是什么万灵药﹐不慎沦为实作指数倒退(implement exponential backoff)的程序﹐依然引起频宽的分配不公﹐然而﹐有了 RED﹐可让他们不至对其它连线的吞吐量和延迟造成太大伤害。

统计上﹐ RED 在它达到硬界限(hard limit)之前﹐就会从流程(flows)上丢弃封包。这会让已拥塞的骨干线路温和地放慢﹐并防止同步重传。这也有助于 TCP 更迅速的丢弃部份封包﹐以保持伫列体积于较低值﹐及有效控制延迟﹐从而更快的找出其 '公平' 速度。封包从特定连线上被丢弃的机率﹐也成比例的相应于其频宽使用量﹐而非封包的传送数量。

关于 backbone﹐光是公平性伫列所需的 per-session 状态追踪之复杂性﹐就令您敬而远之﹐就这点而言﹐ RED 无疑是非常优秀的伫列技术。

如要使用 RED﹐您必须决定好三个参数﹕Min﹑Max﹑及 burst。Min 用来设定开始丢弃流量之前的最小伫列体积﹐以 byte 为单位﹔Max 则是此演算法所能保持的软性(soft)最大值﹔而 burst 则设定 '瞬增吞吐流量' 的最大封包数目。

您要根据预计的伫列延迟﹐再乘以您的频宽﹐来计算出 min 的设定值。比方说﹐在我的 64kbit/s 的 ISDN 线路上﹐我想要伫列的基本延迟为 200ms﹐那我就将 min 设为 1600 bytes。如果 min 设得太小﹐会降低吞吐量﹔如太大﹐则加重延迟。在一条低速线路上﹐以降低 MTU 来改进互动回应(interactive response)的办法﹐并不能靠降低 min 设定来作为替代方案。

您最好将 max 设为 min 的起码两倍以上﹐以预防同步。在较低的 min 值的低速线路上﹐将 max 设为 min 的四倍或更多﹐应是明智之举。

至于 burst﹐则是用来控制 RED 演算法如何对瞬增流量做出反应。Busrt 必须设定为大于 min/avpkt。实验上﹐我发现 (min+min+max)/(3*avpkt) 也行得通。

另外﹐您还要设定 limit 和 avpkt 。Limit 是一个安全值﹐当伫列到达 limit bytes 之后﹐RED 就会 '变成' tail-drop 模式。我通常将 limit 设为 max 的 8 倍数。而 avpkt 就是平均封包体积。在 1500byte MTU 的高速 Internet 线路上设为 1000 是可以接受的。

相关技术资料﹐请参考 Sally Floyd 和 Van Jacobson 的 the paper on RED queueing

FIXME: 多多益善。没错﹐就是 greg 兄 *您* 啦 :-) - 哈


Next Previous Contents