QOS概述（四）拥塞管理和拥塞避免

当网络中刚出现间歇性拥塞，且关键报文要求更优先的转发时，此时就需要进行拥塞管理。通过采用队列技术及不同的调度算法来发送队列中的报文流。如果某些突发的、非关键的报文装满队列，而后发往该队列的报文都被全部丢弃，那么拥塞管理也就未取得理想效果，此时就需要配合使用拥塞避免技术。

1、拥塞管理

1.1 拥塞现象的产生与改善

1.2 常见的队列调度算法

1.3 队列调度算法的比较

1.4 拥塞管理的配置

2、拥塞避免

2.1 传统处理方法：尾丢弃

2.2 WRED的配置

1、拥塞管理

1.1 拥塞现象的产生与改善

拥塞现象主要发生的场景：

速率不匹配：报文从高速链路进入设备，再由低速链路转发出去。
汇聚问题：报文从多个接口同时进入设备，有一个没有足够带宽的接口转发出去。

拥塞引发的负面影响：

增加了报文的时延和抖动。
过高的延时会引起报文的重传。
使网络的有效吞吐率降低，造成网络资源的损害。
加剧耗费大量的网络资源（特别是存储资源），不合理的资源分配甚至可能导致系统陷入资源死锁而崩溃。

由上可知，拥塞使流量不能及时的获得资源，是造成服务性能下降的源头。然而在报文交换以及多用户业务并存的复杂环境下，拥塞又是常见的。因此采取有效的避免拥塞以及防止拥塞加剧的方法是必须的。

拥塞管理通过队列机制来实现：

第一步：将准备从一个接口发出的所有报文放入不同的缓存队列中；

优先级映射实现了从数据原始携带的QOS优先级到内部优先级或从内部优先级到QOS优先级的映射。优先级映射：https://blog.csdn.net/weixin_43997530/article/details/109686933

对于进入设备的报文，设备将报文携带的优先级或者端口优先级映射为内部优先级，然后根据内部优先级与队列之间的对应关系确定报文进入的队列。

第二步：根据各队列间的调度机制实现不同报文的差分转发。

提供差分服务的核心就是当拥塞发生时如何决定不同队列报文的转发次序，这就用到了队列的调度机制。常见的调度算法包括：FIFO、PQ、WRR、WFQ、CBQ等等。

1.2 常见的队列调度算法

1. FIFO（First In First Out）

FIFO队列不对报文进行分类，当报文进入接口的速度大于出接口能发送的速度时，FIFO按报文到达接口的先后顺序让报文进入队列，同时，FIFO在队列的出口让报文按进队的顺序出队，先进的报文将先出队，后进的报文将后出队。

FIFO队列具有处理简单，开销小的优点。但FIFO不区分报文类型，采用尽力而为的服务模型，使得对时延敏感的实时应用的延迟得不到保证，关键业务的带宽也不能得到保证。

优点：实现机制简单且处理速度快。
缺点：不能有差别的对待优先级不同的报文。

2. PQ（Priority Queuing）

PQ队列是对关键业务应用设计的，且关键业务有一个重要的特点，就是需要在发生拥塞的时候要求优先保障关键的业务流量。

PQ调度机制：分为4个队列，分别为高优先级队列、中优先级队列、正常优先级队列和低优先级队列，它们的优先级依次降低。在报文出队的时候，PQ会首先让高优先级队列中的报文出队并发送，直到高优先级队列中的报文发送完，然后发送中优先级队列中的报文，同样直到发送完，正常和低优先级队列同理。如此，我们可以将关键业务的报文放入较高优先级的队列，将非关键业务流量（如E-mail）放入低优先级队列中。这样在网络出现拥塞时，可以保证关键业务报文优先传送，非关键业务的报文在处理关键业务的间隙传送。

如果高优先级队列中持续有报文等待被发送，那么后面较低优先级队列中的报文就迟迟不能得到发送，出现“饿死”现象。避免队列饿死需要上游设备精心规定数据流的业务特性以确保映射到高优先级队列的业务流不超出输出链路容量的一定比例，这样可以使高优先级队列常常为空，允许调度器为低优先级队列服务

优点：对高优先级报文提供了优先转发。
缺点：对低优先级队列可能出现“饿死”现象。

3. WRR（Weighted Round Robin）

WRR（Weight Round Robin）加权循环调度在RR（Round Robin）调度的基础上演变而来，根据每个队列的权重来轮流调度各队列中的报文流。实际上，RR调度相当于权值为1的WRR调度。

在进行 WRR 调度时，AR2200 根据每个队列的权值进行轮循调度。调度一轮权值减一，权值减到零的队列不参加调度,当所有队列的权限减到 0 时，开始下一轮的调度。从统计上看，各队列中的报文流被调度的次数与该队列的权值成正比，权值越大被调度的次数相对越多。由于 WRR 调度的以报文为单位，因此每个队列没有固定的带宽，同等调度机会下大尺寸报文获得的实际带宽要大于小尺寸报文获得的带宽。

WRR 调度避免了采用 PQ 调度时低优先级队列中的报文可能长时间得不到服务的缺点。WRR 队列还有一个优点是，虽然多个队列的调度是轮询进行的，但对每个队列不是固定地分配服务时间片——如果某个队列为空，那么马上换到下一个队列调度，这样带宽资源可以得到充分的利用。但 WRR 调度无法使低延时需求业务得到及时调度。

优点：避免了低优先级队列出现“饿死”现象。

缺点：基于报文个数来调度，容易出现包长尺寸不同的报文出现不平等调度；低时延业务得不到及时调度。

4. WFQ（Weighted Fair Queuing）

公平队列的目的是尽可能公平的分享网络资源网络资源，使所有的延迟和抖动达到最优：

不同的队列获得公平的调度机会，从整体上均衡各个流的延迟。
短报文和长报文获得公平的调度：如果不同队列间同时存在多个长报文和短报文等待发送，让短报文优先获得调度，从而在总体上减少各个流的报文间的抖动。

与 FQ 相比，WFQ（Weighted Fair Queue）在计算报文调度次序时增加了优先权方面的考虑。从统计上，WFQ 使高优先权的报文获得优先调度的机会多于低优先权的报文。WFQ调度在报文进入队列之前，先对流量进行分类，有两种分类方式：

按流的“会话”信息分类

根据报文的协议类型、源和目的TCP 或UDP 端口号、源和目的 IP 地址、ToS 域中的优先级位等自动进行流分类，并且尽可能多地提供队列，以将每个流均匀地放入不同队列中，从而在总体上均衡各个流的延迟。在出队的时候，WFQ按流的优先级（precedence）来分配每个流应占有带宽。优先级的数值越小，所得的带宽越少。优先级的数值越大，所得的带宽越多。这种方式只有CBQ的default-class支持。

按优先级分类

通过优先级映射把流量标记为本地优先级，每个本地优先级对应一个队列号。每个接口预分配8个队列，报文根据队列号进入队列。默认情况，队列的 WFQ 权重相同，流量平均分配接口带宽。用户可以通过配置修改权重，高优先权和低优先权按权重比例分配带宽。

WFQ优点在于配置简单，但由于流是自动分类，无法手工干预，故缺乏一定的灵活性；且受资源限制，当多个流进入同一个队列时无法提供精确服务，无法保证每个流获得的实际资源量。WFQ均衡各个流的延迟与抖动，同样也不适合延迟敏感的业务应用。

优点：可以完全按照权重分配带宽；自动分类，配置简单。
缺点：低时延业务扔得不到及时调度；无法实现用户自定义分类规则。

5. PQ+WFQ

集合了PQ调度和WFQ调度各自的优缺点。单纯采用PQ调度时，低优先级队列中的报文流可能会长期得不到带宽，而单纯采用WFQ调度时，低延时需求业务可能得不到及时调度，而如果将两种调度方式结合起来形成PQ+WFQ调度方式，其不仅能发挥两种调度的优势，而且能互补一些各自特有的缺点。

调度过程：接口上的 8 个队列被分为两组，用户可以指定其中的某几组队列进行 PQ 调度，其他队列进行 WFQ 调度。如图，在进行调度时，首先按照PQ方式优先调度Queue7、Queue6和Queue5队列中的报文流，只有这些队列中的报文流全部调度完毕后，才开始以WFQ方式调度Queue4、Queue3、Queue2、Queue1和Queue0队列中的报文流。其中，Queue4、Queue3、Queue2、Queue1和Queue0队列包含自己的权值。

重要的协议报文以及有低时延需求的业务报文放入PQ调度队列中，得到优先调度的机会，其他报文则放入以WFQ方式调度的各队列中。

6. CBQ（Class-based Queuing）

CBQ（Class-based Queueing）是基于类的加权公平队列是对WFQ功能的扩展，为用户提供了自定义类的支持。CBQ首先根据IP优先级或者DSCP优先级、入接口、IP报文的五元组等规则来对报文进行分类，然后让不同类别的报文进入不同的队列。对于不匹配任何类别的报文，会送入系统定义的缺省类。

CBQ提供三类队列：

1. EF队列：满足低时延业务。

EF队列拥有绝对优先级，仅当EF队列中的报文调度完毕后，或者超过为 EF 队列配置的最大预留带宽时，才调度发送其他队列中的报文。
进入 EF 队列的报文在接口发生拥塞时（队列中有报文时）会被限速，超出规定流量的报文将被丢弃。这样，属于 EF 队列的报文既可以获得空闲的带宽，又不会占用超出规定的带宽，保护了其他报文的应得带宽。此外，由于只要 EF 队列中有报文，系统就会发送 EF 队列中的报文，所以 EF 队列中的报文被发送的延迟最多是接口发送一个最大长度报文的时间，无论是时延还是时延抖动，EF 队列都可以将之降低为最低限度。这为对时延敏感的应用（如 VoIP 业务）提供了良好的服务质量保证。

2. AF队列：满足需要带宽保证的关键数据业务。

每个AF队列分别对应一类报文，用户可以设定每类报文占用的带宽。当系统调度报文出队的时候，会按用户为各类报文设定的带宽将报文进行出队发送，可实现各个类的队列的公平调度。当接口有剩余带宽时，AF 队列按照权重分享剩余带宽。同时，在接口拥塞的时候，仍然能保证各类报文得到用户设定的最小带宽。244对于 AF 队列，当队列的长度达到队列的最大长度时，缺省采用尾丢弃的策略，但用户还可以选择用 WRED 丢弃策略。

3. BE队列：满足不需要严格QoS保证的尽力发送业务。

当报文不匹配用户设定的所有类别时，报文会被送入系统定义的缺省BE（Best Effort，尽力传送）类。BE队列使用接口剩余带宽和WFQ调度方式进行发送。对于 BE 队列，当队列的长度达到队列的最大长度时，缺省采用尾丢弃的策略，但用户还可以选择用 WRED 丢弃策略。

优点：提供了自定义类的支持；可为不同的业务定义不同的调度策略。
缺点：由于涉及复杂的流分类，故启用CBQ会耗费一定的系统资源。

1.3 队列调度算法的比较

类型	优点	缺点
FIFO	实现简单，处理速度快	不能有差别的对待优先级不同的报文
PQ	低时延业务能得到保证	低优先级队列业务可能出现“饿死”现象
WRR	避免了低时延业务的“饿死”现象	不平等调度，低时延业务得不到保障
WFQ	按权重实现公平调度；自动分类，配置简单	低时延业务得不到保障，无法支持自定义类
PQ+WFQ	低时延业务得到保障；按权重实现公平调度	无法支持自定义类
CBQ	支持自定义类	耗费较多的系统资源

1.4 拥塞管理的配置

我们可以将语言等低时延需求业务流量放入队列5的PQ中，可以将其他普通流量放在队列1~3的WFQ中

[RTA]qos queue-profile qos-Huawei      //为每个队列定义不同的调度算法schedule pq 5 wfq 1 to 3           //队列5为pq，可以传输低时延业务；1~3为普通业务int g0/0/0qos queue-profile qos-Huawei       //在接口上应用[RTA]dis qos queue-profile qos-Huawei
Queue-profile: qos-Huawei
Queue Schedule Weight Length GTS1     WFQ     10      -/- -/-2     WFQ     10      -/- -/-3     WFQ     10      -/- -/-5     PQ      -       -/- -/-

2、拥塞避免

2.1 传统处理方法：尾丢弃

每个队列的长度有限，当某一队列已被装满时，传统的处理方法会将后续向该队列发送的报文全部丢弃，直至拥塞解除，这种方式称为尾丢弃。

缺点：

（一）引发全局TCP同步现象：发生拥塞，队列排满进行尾丢行为，大量的TCP连接包被丢弃。进而引发TCP全局同步现象

TCP全局同步：对于TCP来说，如果大量报文被丢弃，将造成TCP超时，从而引发TCP慢启动，使得TCP减少报文的发送。当队列同时丢弃多个TCP连接的报文时，将造成多个TCP连接同时进入拥塞避免和慢启动状态已调整并降低流量，这就被称为TCP全局同步现象。这样多个TCP连接发往队列的报文同时减少，而后又在某个时间同时出现高峰，如此反复，使网络的利用率降低

【解决】：RED

为了避免TCP全局同步，可在队列未装满时随机丢弃一部分报文，通过预先降低一部分TCP连接的传输速率来尽可能的延缓TCP全局的到来。这种预先随机丢弃报文的行为被成为早起随机检测（RED）。RED通过随机地丢弃数据报文，让多个TCP连接不同时降低发送速度，从而避免了TCP的全局同步现象。使TCP速率及网络流量都趋于稳定。

RED为每个对类的长度都设定了阈值门限，并规定：

当队列小于低门限时，不丢弃报文。
当队列大于高门限时，丢弃所有报文。
当队列在低门限和高门限之间时，开始随机丢弃到来的报文。方法是为每个到来的报文赋一个随机数，并用随机数与当前队列的丢弃概率比较，如果大于丢弃概率则报文被丢弃。队列越长，报文被丢弃的概率越高。

（二）引起TCP饿死现象/无差别的丢弃

导致原因：尾丢弃无法对流量进行区分丢弃。

【解决】：WRED

基于RED技术，又实现了WRED（Weighted Random Early Detection）技术，可实现每一种优先级都能独立设置报文的丢包的高门限、低门限及丢包率，报文到达低门限时，开始丢包，到达高门限时丢弃所有的报文，随着门限的增高，丢包率不断增加，最高丢包率不超过设置的最大丢包率，直至到达高门限，报文全部丢弃。这样按照一定的丢弃概率主动丢弃队列中的报文，从一定程度上避免了尾丢弃带来的所有缺点。

WRED技术可以通过对不同优先级数据包或队列设置相应的丢弃策略，以实现对不同流量进行区分丢弃。

2.2 WRED的配置

要求：

[RTA]drop-profile manager
wred dscp
dscp 8 low-limit 50 high-limit 70 discard-percentage 10drop-profile ftp
wred dscp
dscp 16 low-limit 70 high-limit 90 discard-percentage 10drop-profile video
wred dscp
dscp 24 low-limit 60 high-limit 80 discard-percentage 20qos queue-profile qos-Huawei
queue 1 drop-profile manager
queue 2 drop-profile ftp
queue 3 drop-profile videointerface E1
qos queue-profile qos-Huawei