两种传统的包的调度策略

在介绍Drop Tail之前,我们先介绍两种传统的包的调度策略-决定包的传送顺序。

FIFO (First In First  Out,先进先出)

是一种经典的包调度策略,它的最大优点在于实施起来简单。FIFO又叫“先到先服务”(FCFS),即第一个到达路由器的数据包首先被传输。FIFO的问题在于在排队的时候没有考虑包的重要程度,对FIFO排队的一个简单改进是优先级排队。基本思想是给每个数据包分配一个优先级标志。这个优先级标志可以放在IP数据包内。路由器则执行多个FIFO排队。一个队列对应一个优先级。路由器在排队的时候总是给优先级高的队列先排队。在同一优先级队列中,数据包仍按FIFO排队。

公平排队算法(Fair Queue,FQ)

是FIFO的一种改进。FIFO排队的主要问题是无法区分不同的数据流。由于整个TCP的拥塞控制是在源端执行,而FIFO排队不提供约束所有数据源遵守拥塞控制的机制,这就有可能让行为不良的数据流强占大量带宽。在Internet环境中,某个应用不使用TCP协议是完全可能的。结果,它可以绕开端到端的拥塞控制机制,向路由器任意发送自己的数据包,从而引起其它应用的包被丢弃。FQ算法则解决了这个问题。在FQ算法中,路由器对每个输出线路有一个排队队列。路由器按“轮询”方式处理包。当一条线路闲时,路由器就来回扫描所有队列,依次将每队每一个包发出。当某个流的数据包到达过快时,其队列就会很快占满,属于这个流的新到的数据包就会被丢弃。采用这种方式,每个数据流就不可能牺牲其它数据流而多占资源。另外,FQ算法并没有告知源端路由器状态的机制,也就是说,FQ仍然要依赖于端到端的拥塞控制机制。它只是将数据流分隔,使不遵守拥塞控制机制的数据流不至于影响其它流。所以它在没有牺牲统计复用的情况下提供了公平性,与端到端的拥塞控制机制也可以较好地协同。

传统的队列长度管理机制是“去尾”( Drop Tail  )。它有点类似于FIFO(先入先出)的存储方式。Drop  Tail最大的优点是原理简单。当路由器队列长度达到最大值时,通过丢包来指示拥塞,先到达路由器的分组首先被传输。由于路由器缓存有限,如果包到达时缓存已满,那么路由器就丢弃该分组。一旦发生丢包,发送端立即被告知网络拥塞,从而调整发送速率。这种做法不考虑被丢弃包的重要程度。

Drop  Tail仍是目前Internet使用最为广泛的分组排队、丢弃的方式。这种方式将拥塞控制的责任都推给网络边缘。所以TCP假定网络中的路由器对拥塞控制不起任何作用,而独自承担检测和响应拥塞的全部责任。

基于Drop  Tail的一种改进算法是优先级排队。它的基本思路是将每个分组分配一个优先级标志。路由器则执行多个队列排队。一个队列对应一个优先级。路由器总是优先传输非空的最高优先级队列。在同一优先级队列中,分组仍按Drop Tail方式管理。

优先级排队的主要问题是最高优先级队列能“抢占”其它所有的队列。只要高优先级队列非空,低优先级队列就得不到服务。所以,不能允许用户不受控地指定高优先级。同时,Drop Tail无法“识别”面向连接的TCP流,所以对它们的公平性较差,对上层TCP快速恢复的效率也很低。

除了这些,它在具体实施过程中也存在着很多其它的弊端。如:若缓冲器很长,则每个分组所经历的延迟就会增大;而若缓冲器很短的话,又不能够适应突发性数据流;另外,全局同步的发生又将直接导致吞吐率的减小,等等。所有这些都可能引起网络崩溃。

常见的队列调度算法

先到先服务(First Come First  Served)

FIFO队列实现的FCFS是Internet使用最多的一种方式,它的最大优点在于实施简单。FIFO本质上是一种“去尾”(Drop-tail)的算法,不需要选择丢弃的分组,只是在系统中没有空闲缓冲资源时丢弃到达的分组。虽然这种算法已经在Internet上成功工作了 许多年,但它有三个严重的缺陷:①持续的满队列状态;②业务流对缓存的死锁;③业务流的全局同步。而队列管理最重要的目标之一就是降低稳定状态下队列的长度,因为端到端时延主要就是由于在队列中排队等待造成的。
        另外,DropTail容易造成TCP全局同步(TCP Global Synchronization)问题,由于Internet上的数据流都具有突发本质(Burstiness),到达路由器的封包也往往是突发的。如果队列是满的或者几乎是满的,就会导致在短时间内连续大量的丢包。而TCP数据流具有自适应特性(Adaptive),来源端发现封包丢失就急剧地把传送速率降低,于是网络拥塞情况得以解除,但来源端在得知网络不再拥塞后又开始增加发送速度,最终又造成网络拥塞。这种现象常常会周而复始地进行下去,因此网络常处于链路利用率很低的状态,降低了整体吞吐量,这就是所谓的TCP全局同步现象。

随机早期检测算法(Random Early  Detection)

RED配置在路由器监视网络流量以便避免拥塞,当即将拥塞发生时,它随机丢弃进来的分组,而不是等到队列缓冲区满时才开始丢弃所有进来的分组,这样可以最少化全局同步的发生。当拥塞发生时,RED丢弃每个连接分组的概率与该连接占用的带宽成比例,它监视每个输出队列的平均队列长度, 随机选择分组丢弃。虽然RED通过随机早期检测和丢包,从而有效地在TCP流之间分配带宽,但混合TCP和非TCP数据流时,RED不能有效地保护TCP 流,没有拥塞控制或采用比TCP更贪婪的非TCP流将比TCP流攫取更多的网络带宽,这种不公平性的主要原因是在拥塞发生时非TCP流不降低发送速率或降低的程度比TCP少,而RED对所有的流都采用同样的丢包比率。
        RED算法相比DropTail的两个好处是:首先,队列缓冲总是预留了一定的缓冲空间,这样可以更好地处理突发性。其次,保持较短的队列长度,可以更好地支持实时应用。

分组公平队列(Packet Fair Queuing)

PFQ算法是基于GPS(Generalized Processor  Sharing)的算法。从80年代末以来,国际上对PFQ进行了大量的研究。PFQ能够保证连接的预约带宽、最大端到端时延以及时延抖动,是实现QoS 的关键技术。目前已有WFQ(Weighted Fair Queuing)、WFQ(Worst-case Fair  Weighted Fair Queuing)、WF2Q+、SPFQ(Start-Potential Fair  Queuing)、SCFQ(Self-Clocked Fair Queuing)等多种PFQ方案。

基于轮循的调度算法(Round  Robin)

传统的RR算法对不同队列(业务流)进行无区别的循环调度服务。这样,如果不同的队列具有不同的分组长度,则分组长度大的队列可能会比分组长度小的队列接受更多的服务,使队列之间产生不公平的现象;而且,这种算法不能对业务提供时延保证。为了改进RR算法的时延特性和其在变长分组环境下的不公平性,出现了一些改进型的算法,如加权轮循WRR(Weighted Round Robin)、差额轮循DRR(Deficit Round  Robin)、紧急轮循URR(Urgency-based Round  Robin)。这些算法力求在尽量保持RR算法实现简单性的同时,从不同的方面改进RR算法的时延特性和其在可变长分组环境下的不公平性。

NS2集成了多种网络协议(如TCP、UDP),业务类型(如FTP、Telnet、Web等),路由队列调度算法(如Drop  Tail、RED、FQ等),路由算法(如Dijkstra等)。可参看DropTail、RED、SFQ(Stochastic Fair Queuing)和DRR四种队列调度算法。

被动式队列管理机制和主动式队列管理机制

(1)被动式队列管理机制——DropTail,Random Drop 和 Drop Front。Random Drop是指当队列满时,从队列中随机找一个包丢弃,让新来的包进入队列。Drop Front 是指当队列满时,从队列前端把封包丢弃,以便新包进入队列。由于这几种方法都是在队列满了时被迫丢包,因此称为被动式队列管理。

(2)主动式队列管理机制——RED。主动式队列管理机制会在队列满之前就开始把封包丢弃,这样可以对具有拥塞控制的传送端做流量速度管制,以避免满队列状态所带来的较长端到端时延或链路利用率很低的负面效应。

NS2仿真程序示例分析

# 设置源节点和目的节点
set src($i) [$ns node]      #s($i)
set dst($i) [$ns node]       #d($i)
# 仅用一句话便完成TCP联机的建立
for {set i 0} {$i<$par2} {incr i} {set tcp($i) [$ns  create-connection TCP/Reno $src($i) TCPSink $dst($i) 0]$tcp($i)  set fid_ $i
}
# 在TCP联机之上建立FTP应用程序
for {set i 0} {$i<$par2} {incr i} {set ftp($i) [$tcp($i)  attach-app FTP]$ns at $startT($i) "$ftp($i) start"
}

该实验的目的是将被动队列管理机制DropTail和主动队列管理机制RED在吞吐量、延时、队列长度方面做比较。实验中并没有直接采用 DropTail,而是将链路类型定义为myfifo,同时选择用如下代码将队列长度记录下来:

set q_ [[$ns link $r1 $r2] queue]
set queuechan [open  q-$par1-$par2.tr w]
$q_ trace curq_
if {$par1=="RED"} {$q_ set bytes_ false$q_ set  queue_in_bytes_ false
}
$q_ attach $queuechan

我在实验中尝试将链路参数直接设定为DropTail(而非myfifo),结果提示"$q_ attach  $queuechan”处有错误,遂尝试其它链路类型,FQ等,均不对。查阅其它参考书,将这段代码替换为:

$ns monitor-queue $r1 $r2 [open q-$par1-$par2.tr w] 0.3
        [$ns link  $r1 $r2] queue-sample-timeout

至此,可以在运行时将参数给定为正常的链路类型,DropTail,FQ,RED,等,myfifo仍然可以使用。但后面用gnuplot画图 时,需要使用

plot "q-myfifo-10.tr" using 1:5 with linespoints 1, "q-RED-10.tr"  using 1:5 with linespoints 2

  而不是原来的

plot "q-myfifo-10.tr" using 2:3 with linespoints 1, "q-RED-10.tr"  using 2:3 with linespoints 2

因为新的输出文件的第1列和第5列才是所需数据。(顺便强调一下,plot命令中,using  2:3的意思是用第2列数据作为横坐标,用第3列数据作为纵坐标。  )同时,原来产生的队列长度记录文件中有一些数据的第3列是相同的,但第2列不同,不明白是怎么回事,但在我改变后的新的输出文件中就没有这种现象。

Q

0.0342079 1
Q 0.118126 2
Q 0.206406 3
Q 0.314605 4
Q 0.354894 2
Q  0.354977 3
Q 0.372965 4
Q 0.440528 5
Q 0.440612 6
Q  0.481177 7
Q 0.486243 8
Q 0.486326 9
Q 0.514977 10
Q  0.565884 11
Q  0.663466 10
Q 0.663549 11
Q 0.728868 12
Q 0.817834 13
Q  0.849159 14
Q 0.886479 15
Q 0.966323 14
Q 0.966406 15
Q 0.9891 16
Q  0.989183 17
Q 1.20069 18
Q 1.21196 19
Q 1.21204 20
Q 1.34918 19
Q 1.34926  20

NS2 队列管理机制相关推荐

  1. NS 2.35 柯志亨书-实验9笔记-队列管理机制

    当时记得笔记: 目前,实现了RED的实时和平均队列长度的显示,但是显示的图形与wpi.edu中的走势有点区别??? 但是柯志亨用的是myfifo,应该是自己写的队列 当改为droptail时,与tr文 ...

  2. RFC7567-IETF关于主动队列管理(AQM)的建议

    摘要 本备忘录向互联网社区提出了有关改进和保持互联网性能的措施的建议.它强烈建议在网络设备中测试.标准化和广泛部署主动队列管理(AQM),以提高当今互联网的性能.它还敦促各方共同努力,研究.测量和最终 ...

  3. 什么是 Python 的 「内存管理机制」?

    什么是内存管理器(what) Python作为一个高层次的结合了解释性.编译性.互动性和面向对象的脚本语言,与大多数编程语言不同,Python中的变量无需事先申明,变量无需指定类型,程序员无需关心内存 ...

  4. Libc堆管理机制及漏洞利用技术 (一)

    0×01 Libc堆浅析 1.1 堆管理结构 struct malloc_state {mutex_t mutex; /* Serialize access. */int flags; /* Flag ...

  5. JVM内存管理机制线上问题排查

    本文主要基于"深入java虚拟机"这本书总结JVM的内存管理机制,并总结了常见的线上问题分析思路.文章最后面是我对线上故障思考的ppt总结. Java内存区域 虚拟机运行时数据区如 ...

  6. 浅析java内存管理机制

    内存管理是计算机编程中的一个重要问题,一般来说,内存管理主要包括内存分配和内存回收两个部分.不同的编程语言有不同的内存管理机制,本文在对比C++和java语言内存管理机制的不同的基础上,浅析java中 ...

  7. tensorflow随笔-队列管理器QueueRunner-生产者与消费者

    # -*- coding: utf-8 -*- """ Spyder EditorThis is a temporary script file. "" ...

  8. 【Python基础】什么是Python的 “内存管理机制”

    什么是内存管理器(what) Python作为一个高层次的结合了解释性.编译性.互动性和面向对象的脚本语言,与大多数编程语言不同,Python中的变量无需事先申明,变量无需指定类型,程序员无需关心内存 ...

  9. 深入了解C#系列:谈谈C#中垃圾回收与内存管理机制

    今天抽空来讨论一下.Net的垃圾回收与内存管理机制,也算是完成上个<WCF分布式开发必备知识>系列后的一次休息吧.以前被别人面试的时候问过我GC工作原理的问题,我现在面试新人的时候偶尔也会 ...

最新文章

  1. Android 国际化问题
  2. 实施TDD时的常见问题
  3. 预览文章: c++ primer学习笔记,二:标准库类型
  4. 【转】OpenGL随笔(1)—— mipmap 详解
  5. 安装hadoop2.6.0伪分布式环境
  6. MySQL 表和列的注释
  7. DB2 9 使用开辟(733 测验)认证指南,第 3 局部: XML 数据独霸(2)
  8. 怀旧服最新服务器塞卡尔,魔兽世界怀旧服:10个至今未开门的服务器!圣光服进度刚到20%!...
  9. postgre查询表最后更新日期_Power BI 10月份功能更新浅译
  10. 组件中使用_尚德高效组件全线投入壳牌首个光伏项目中使用
  11. [译] APT分析报告:05.Turla新型水坑攻击后门(NetFlash和PyFlash)
  12. 计算机统计硕士排名,卡内基梅隆大学硕士统计学专业排名务必稳重的去看
  13. 一篇文章搞定支付宝网页支付!
  14. C#VS2019中ReportViewer控件和报表设计器 RDLC使用方法总结
  15. 会员付费超前点播模式争议背后,我们该怎么看待在线视频的未来?
  16. 小程序中将lees转成wxss
  17. 【axios源码】- 取消请求cancel模块研读解析
  18. 测量学—数字测图原理与方法
  19. 杭州电子科技大学保研计算机,杭州电子科技大学2021年推免保研情况
  20. Excel基础操作1

热门文章

  1. 视听说教程(第三版)4 quiz 8
  2. 网络安全专业术语对照
  3. windows创建软链接和删除软链接
  4. RGB和HSV颜色空间
  5. 企业为什么要大力推进OA办公?
  6. 【BBED】使用bbed 修改data block Block Misplaced
  7. 梯度,散度,拉普拉斯算子
  8. H5托盘通知(带声音提醒)
  9. php添加学生信息,PHP开发 学生管理系统之添加信息PHP页面
  10. ByteV打造3D海上风电监控平台 ——助力风电能源可持续发展