RED队列管理的基本思想是提前检测到最初的拥塞，并把拥塞通知告知端主机，让它们在网络的队列溢出和分组丢弃之前减小传输速率。虽然RED算法在一定程度上改进了传统的尾丢弃排队，但也有一些缺点：RED及其他主动队列算法技术中一个最根本的问题是用队列长度作为检测拥塞的参数。队列的持续增加意着拥塞，但却不能给出关于严重拥塞的任何信息，即有多少链接共享带宽。在链路忙的时刻，一个源如果以超过瓶颈链路容量的速度传输分组同大量源同时传输一样都容易产生拥塞。由著名的排队论可知，只有当分组的到达间隔符合泊松分布时，队列长度才直接和活动源的数目相关，并由此产生真正意义的拥塞。然而，通过网络不同链路的分组的到达间隔时间由TCP动态决定，并非泊松分布。这就使把队列长度放在主动队列管理核心的方案值得怀疑。由于RED算法依赖队列长度，所以在决定是否发生严重拥塞时本身存在着固有问题。RED又要求在不同的拥塞情景下的参数变化范围比较大，因而只有当队列空间足够大和参数正确时RED才能达到理想情况。虽然RED可以减少Internet上的分组丢失，但并不能从根本上防止分组丢失[22]。
基于尾丢弃的TCP拥塞控制算法一个最大的问题就是源仅仅检测到由于队列溢出产生分组丢失后才减少其发送速率。从路由器上分组被丢弃到源检测再到拥塞之间己经耗费了大量时间，在这期间由于发送方一直以网络不能支持的速率发送而又会导致大量分组丢失。为使RED算法更为有效，从队列长度触发的拥塞被检测到开始，到源对拥塞通知做出反应从而减少瓶颈链路载荷的那一刻结束，在这一段时间内必须有足够的大量缓冲空间用来存放在这段时间内产生的比链路容量更多的载荷。同时，RED也必须保证拥塞通知以一定的速率发送出去，这个速率足以能够抑制传输源，同时又没有占用多余的链路。然而，当大量的TCP源被激活时，产生的聚集流是具有很大的突发性。突发的流量会造成队列长度变化太快，因而经常使采用RED的主动队列管理技术在RED做出反应之前失效。
4    BLUE在NS平台上的仿真研究
4.1  在NS中添加BLUE算法
NS2.34已经实现了许多队列管理算法，如Drop Tail、RED、REM、FQ等,但在现有版本中，NS2并没有实现BLUE算法，因此，为了对BLUE算法进行验证，需要在NS2仿真器中加入这种算法，通过扩展NS2的队列管理算法功能实现对算法的验证平台。
具体扩展过程如下： 主动队列管理算法BLUE的仿真研究(8):http://www.youerw.com/tongxin/lunwen_9187.html