1. 网络服务质量QoS的核心价值与挑战在网络工程师的日常工作中最头疼的莫过于当视频会议卡顿、语音通话断续、关键业务数据延迟时用户打来的投诉电话。所有流量在网络上“平等”地挤占带宽其结果就是关键应用体验的灾难。网络服务质量QoS技术就是为了解决这个“平等”带来的不平等问题而生的。它本质上是一套流量管理规则通过识别、标记、监管和调度网络中的数据包为不同优先级的业务提供差异化的传输保障。简单来说它就像交通管理系统让救护车实时音视频、消防车金融交易拥有优先通行权而普通货车文件下载则在非高峰时段通行从而确保整条道路网络的通行效率和安全。当前主流的QoS技术体系主要分为两大类IP网络领域的区分服务DiffServ和传统电信领域的异步传输模式ATM流量管理。DiffServ架构灵活部署在IP层适用于现代数据中心和互联网而ATM则提供严格的、面向连接的信元级服务质量保证常见于早期的骨干网和专线。理解这两者的原理不仅是应对厂商设备配置的需求更是深入理解流量整形、队列调度、拥塞避免这些底层机制的钥匙。无论你是运维工程师需要排查视频会议卡顿还是开发者在设计低延迟的实时通信系统掌握QoS的核心思想都至关重要。本文将深入拆解DiffServ和ATM流量管理的技术细节从报文分类到队列调度并结合实际芯片实现逻辑让你不仅知道怎么配更明白为什么这么配。2. DiffServ架构深度解析从分类到调度DiffServ模型的核心思想是将复杂的服务质量保证简化在网络边缘完成核心网络设备只根据简单的标记执行相应的转发行为PHB每跳行为。这种“边缘复杂核心简单”的设计使其具备了良好的可扩展性。2.1 多字段MF分类与流标识流量管理的首要步骤是分类。在芯片实现中如Freescale现NXP的某些网络处理器DiffServ组件会为每个出口端口设置一个输入队列。Ingress入口处理单元以严格的轮询方式从这些队列中取出IP报文描述符。关键点在于它并非处理整个数据包而是通过DMA将包含IP、TCP/UDP头部的前64字节预取到芯片的本地内存DMEM中以提升处理效率。分类的依据是一个称为多字段MF位掩码的配置。这个掩码决定了使用哪些头部字段来构成一个流的识别键Key。常见的字段包括源/目的IP地址区分不同主机或网段。协议号区分TCP、UDP、ICMP等。源/目的TCP/UDP端口区分不同应用如HTTP80、DNS53、RTP动态端口。这些被选中的字段值会被拼接起来形成一个最长14字节的查找键。芯片内部维护一个最长前缀匹配表通常由三态内容寻址存储器TCAM或软件实现将此键映射到一个流ID和一个DiffServ PHB。最长前缀匹配支持通配符例如可以将10.1.0.0/16网段的所有流量定义为同一个流这提供了极大的灵活性。实操心得在设计MF分类规则时应遵循从精确到宽泛的原则。优先使用“目的IP目的端口”来匹配关键服务器应用再使用“源IP网段”来匹配部门或用户组。避免创建大量过于精细的规则这会增加TCAM的负担和查找延迟。在实际芯片中规则表大小是有限资源。2.2 令牌桶算法与三色标记器分类并确定PHB后下一步是对流量进行测量和标记这就是计量器Meter的工作。DiffServ常用的是基于RFC 2697的单速率三色标记器srTCM。其核心是维护两个令牌桶C桶承诺突发桶和E桶超额突发桶。每个流在表中都有对应的配置参数CIR承诺信息速率承诺长期平均速率。CBS承诺突发尺寸在短时间内允许超过CIR的突发流量上限。EBS超额突发尺寸在CBS基础上进一步允许的突发量通常标记为更低优先级。算法原理如下令牌生成系统以一个固定的时间间隔Tick如512个核心时钟周期为周期向C桶和E桶中分别添加令牌。每次添加的令牌数Increment CIR / (每Tick对应的秒数)。这模拟了速率的平均化。令牌累积上限C桶的令牌数不能超过CBSE桶的令牌数不能超过EBS。多余的令牌被丢弃。报文着色当一个大小为P的报文到达时如果C桶令牌数 P报文标记为绿色并从C桶中扣除P个令牌。否则如果E桶令牌数 P报文标记为黄色并从E桶中扣除P个令牌。否则报文标记为红色。在芯片实现中需要高效地处理时间更新。通常维护一个lastUpdateTime记录上次处理的时间戳单位是Tick。当新报文到达时计算当前时间与lastUpdateTime的差值并一次性为两个桶补充差值 * Increment个令牌同时不超过各自的上限然后再进行着色判断。这种方式避免了频繁的定时器中断计算效率高。注意事项CBS和EBS的设置需要根据实际业务突发特性谨慎调整。CBS设置过小会扼杀业务的正常突发如HTTP请求导致绿色报文少设置过大则失去了流量监管的意义。一个经验法则是CBS至少应容纳一个典型业务交互如一个视频关键帧的数据量。EBS通常设置为CBS的1.5到2倍用于容纳非预期的、可容忍延迟的突发。2.3 确保转发与确保转发PHB处理标记后的报文会根据其PHB进入不同的处理路径EF加速转发PHB用于极低延迟、低抖动的业务如语音。在实现中任何被标记为红色的EF流量通常会被直接丢弃因为不符合严格的服务合同。绿色和黄色的报文则被标记为EF的DSCP值通常为46二进制101110并立即送入对应出口CPRC的QMU队列享受绝对优先调度几乎不经过队列缓存。AF确保转发PHBRFC 2597定义了4个AF类AF1x, AF2x, AF3x, AF4x每类有3个丢弃优先级低、中、高。绿色报文对应低丢弃优先级黄色对应中红色对应高。芯片会根据颜色将报文DSCP字段改写为对应的AF编码如AF11, AF12, AF13。随后报文被送入对应AF类和出口端口的整形器Shaper软队列。BE尽力而为PHB标准IP流量不进行特殊标记直接进入BE队列等待调度。这里有一个精妙的设计对于AF PHB标准要求为每个丢弃优先级维护独立的队列。但在芯片资源受限时可以采用单队列模拟三队列的策略。即只维护一个物理软队列但通过令牌桶着色和调度算法保证在逻辑上绿色报文队首先于黄色被服务黄色先于红色。这是通过将不同颜色的报文在入队时按顺序排列并结合后续的调度算法实现的。2.4 随机早期检测RED与拥塞避免报文进入AF或BE的软队列后并非简单地等待。如果队列满了再丢包对于TCP流而言会导致所有连接同时进入拥塞避免阶段降低窗口然后同时恢复引发全局同步使链路利用率大幅波动。随机早期检测RED算法就是为了平滑地、随机地提前丢包避免这种情况。RED的核心是监控队的平均深度而非瞬时深度。平均深度avg通过一个指数加权移动平均EWMA公式计算avg (1 - wq) * old_avg wq * current_queue_depth。其中wq是一个很小的权重如2^-9使得平均深度对瞬时波动不敏感能反映较长时间的拥塞趋势。RED算法流程如下设置两个阈值min_th最小阈值如128个报文和max_th最大阈值如256个报文。当avg min_th不丢包。当min_th avg max_th以概率Pb丢弃新到达的报文。Pb从0线性增长到max_p最大丢包概率如2^-7。Pb max_p * (avg - min_th) / (max_th - min_th)当avg max_th丢弃所有新到达报文。在定点数处理器如很多网络处理器内核上实现浮点运算的Pb和随机数比较是昂贵的。因此芯片实现中常采用优化定点数表示使用32位整数高8位表示整数部分低24位表示小数部分。这样数字1表示为0x010000007.5表示为0x078000007 * 2^24 0.5 * 2^24。乘除2的幂次运算可以通过左右移位高效完成。概率计算优化预计算C1 max_p / (max_th - min_th)和C2 (max_p * min_th) / (max_th - min_th)。由于max_p、min_th、max_th常配置为2的幂C1和C2也是2的幂或简单分数计算Pb avg * C1 C2可以转化为移位和加法。随机丢包判定预生成一个256个随机数的表范围0-1用上述定点格式表示。当需要丢包时取出一个随机数R计算R / Pb。由于除法昂贵可通过计算Pb小数部分的前导零个数来近似-log2(Pb)然后将R左移相应的位数来近似R / Pb再与一个计数变量比较来决定是否丢包。这种方式在保证随机性的同时性能极高。踩坑记录RED参数wq、min_th、max_th需要根据实际链路带宽和流量模型调整。wq太大平均深度对瞬时突发敏感可能导致不必要的丢包太小则反应迟钝。max_th不应超过队列总深度。在实际部署中往往需要开启RED的“自适应”变种或者根据实时监控动态调整阈值这在固定功能的芯片中可能难以实现需要更灵活的软件方案。2.5 加权公平队列WFQ调度与出口处理经过计量、标记、整形和RED管理后报文在各自的AF PHB软队列中等待被调度发送。调度由WFQ出口模块执行其目标是按照预先为每个AF PHB分配的最小保证带宽比例来分配出口链路资源。芯片中常用赤字轮询Deficit Round Robin, DRR算法来实现WFQ因为它计算简单适合硬件实现。每个AF PHB软队列关联两个变量量子Quantum根据该PHB分配的带宽比例计算得出例如Quantum (PHB带宽 / 总带宽) * 平均报文大小。这是一个可动态配置的字节数。赤字计数器Deficit Counter初始为0。DRR调度每一轮Round的步骤如下为当前队列的赤字计数器增加其Quantum值。检查队列头部的报文大小P。如果赤字计数器 P则发送该报文并将赤字计数器减去P。重复步骤2直到队列空或赤字不足以发送下一个报文。如果赤字计数器 P则本轮跳过此队列转向下一个队列。赤字计数器保留到下一轮。这种机制保证了每个队列在长期内获得的带宽与其Quantum成正比同时允许短期的突发积累多轮的赤字一次性发送。对于EF流量通常采用严格的优先级队列PQ只要EF队列有报文就优先发送。BE队列则在所有AF队列空闲时才被服务。此外出口模块还维护一个next_service_time变量记录端口下一次可服务的时间基于端口线速和上一个发送报文的大小计算。这防止了DiffServ CPRC过快地向下游QMU队列倾倒数据而是利用自身的RED软队列来缓冲流量峰值实现更平滑的整形。3. ATM流量管理面向连接的信元级控制与IP网络基于无连接、统计复用的DiffServ不同ATM是面向连接的采用固定长度53字节信元的技术。其流量管理TM更为严格和精细在VC虚电路或VP虚通道级别提供服务质量保证。3.1 业务类别与流量合同ATM定义了多种业务类别每种都有严格的流量参数合同CBR恒定比特率像租用专线提供固定的峰值信元速率PCR。对时延和抖动极其敏感有最大信元传输时延maxCTD要求。rt-VBR实时可变比特率适用于压缩的实时视频、语音。有PCR、可持续信元速率SCR和突发容限BT。也有严格的maxCTD。nrt-VBR非实时可变比特率适用于有突发性但对时延要求稍宽的交易数据。参数同rt-VBR但maxCTD较长。UBR未指定比特率尽力而为服务无保证。无参数。UBR和GFR通用帧速率在UBR基础上提供了最小信元速率MCR保证。GFR专为AAL5适配层5用于封装IP包设计要求TM能识别AAL5的帧边界。3.2 通用信元速率算法GCRA原理ATM流量合约符合性的核心判定算法是GCRA也称为“漏桶算法”。它用两个参数定义增量I和极限L。I 1 / SCR或1 / PCR表示信元到达的理论间隔。L与突发容限BT相关表示允许提前到达的信元数量限度。算法维护一个理论到达时间TAT。初始化时TAT 0或一个过去的时间。当一个信元在时间t到达时如果t TAT - L则该信元是符合Conforming的。然后更新TAT max(t, TAT) I。如果t TAT - L则该信元是不符合Non-conforming的。TAT不变。对于CBR只用PCR参数运行一个GCRA实例。对于VBR需要运行两个GCRA实例一个用PCR参数作为“峰值信元速率漏桶”另一个用SCR和BT参数作为“可持续信元速率漏桶”。信元必须同时通过两个漏桶的检查才算完全符合。在芯片实现中时间t由一个以最快端口信元周期为单位的“墙钟”计数器提供。每个VC在表中存有它的TAT、I、L和maxCTD。处理信元时计算当前时间与TAT的差值判断符合性。不符合的信元可能被标记用于流量整形或直接丢弃严重不符合。3.3 针对AAL5的增强F-GCRA与部分分组丢弃对于GFR业务ATM TM需要感知AAL5的帧称为SDU边界。因此采用了帧级GCRAF-GCRA。其特殊规则是只在每个AAL5 SDU的第一个信元到达时进行GCRA符合性检查。如果第一个信元符合则整个SDU的所有后续信元都被视为“符合”尽管可能被标记为非符合用于整形。如果第一个信元严重不符合t TAT - L - maxCTD则整个SDU的所有信元直到帧尾都被丢弃。这被称为部分分组丢弃PPD。如果第一个信元不符合但非严重则它被标记SDU后续信元正常处理。PPD是一种重要的优化。既然AAL5 SDU的尾部有CRC校验丢失任何一个信元都会导致整个上层IP包被丢弃重传。那么在拥塞时主动丢弃一个SDU中剩余的信元可以立即释放缓冲区资源避免浪费带宽传输注定无效的数据。这与TCP的“快速重传”有异曲同工之妙。3.4 流量整形与调度实现被GCRA判定为“符合”的信元可以立即发送。而被判定为“不符合”的信元则需要被缓存起来延迟到其TAT时刻再发送这个过程就是流量整形。ATM TM组件通常由监管器Policer和整形器Shaper两个子组件协同完成。1. 基于软队列的调度早期方案芯片为每个业务类别CBR rt-VBR nrt-VBR在每个端口维护一组例如30个软队列。其中一个队列被标记为“当前队列”。GCRA判定为“当前”周期即TAT与当前墙钟差值在一个信元周期内可发送的信元放入当前队列。 调度器每个信元周期工作一次以严格优先级轮询方式检查各业务类别的当前队列先检查CBR当前队列若非空则发送一个信元若空则检查rt-VBR当前队列若空则检查nrt-VBR当前队列若全空则发送UBR队列的信元。 每隔max_queue_depth个信元周期“当前队列”的指针会移动到下一个软队列。这样一个“不符合”的信元其目标队列索引可通过(TAT - wall_clock) / max_queue_depth计算得出。信元在队列中的等待时间即传输时延可以预估如果超过该VC的maxCTD则信元在入队前就会被丢弃。2. 基于日历的调度优化方案为了获得更精确的时延控制和更低的抖动更先进的方案使用日历数组。将时间轴划分为离散的信元时隙每个时隙对应数组中的一个槽位。一个指针指向“当前时隙”。符合的信元插入当前时隙的槽位。需要在n个周期后发送的信元则插入当前指针后第n个槽位。如果目标槽位已被占用则顺延到下一个空闲槽位。 每个业务类别有自己的日历。调度器每个信元周期移动一次当前指针并以严格优先级CBR rt-VBR nrt-VBR UBR/GFR检查各日历的当前槽位取出信元发送。 日历方案避免了软队列方案中因队列深度估算带来的时延不确定性尤其有利于CBR和rt-VBR这类对抖动敏感的业务。4. 常见问题、调试技巧与方案选型在实际部署和调试QoS时会遇到各种问题。以下是一些常见场景和排查思路。4.1 DiffServ相关典型问题问题1关键业务如语音仍然有卡顿但设备显示EF队列并未拥塞。排查首先检查分类是否正确。使用抓包工具确认语音流如RTP的DSCP字段是否被正确标记为EF46/0x2E。其次检查路径上所有设备不仅是本设备的端口是否都启用了信任DSCPtrust dscp或正确的CoS到DSCP的映射。中间可能有无视QoS标记的设备将DSCP重置为0。最后检查出口物理端口是否有拥塞。EF队列不拥塞但出口链路被大量AF或BE流量占满时EF流量依然会被延迟发送。确保为EF流量配置了严格的优先级队列LLQ并限制其带宽避免饿死其他队列。问题2AF业务带宽分配不均某个类的流量远低于其配置的权重。排查检查WFQ/DRR的配置。确认每个AF类的“带宽百分比”或“最小保证带宽”配置是否正确。更重要的是检查该AF类的实际流量是否达到了保证速率。WFQ是“加权公平”队列如果某个队列空闲其未使用的带宽会立即分配给其他有需求的队列。因此低流量可能只是因为源端没有发送那么多数据。可以使用show policy-map interface以思科为例查看每个类的“队列深度”、“发送包数”、“丢弃包数”来辅助判断。问题3开启RED后TCP吞吐量波动剧烈甚至下降。排查RED参数配置不当。min_th设置过低会导致过早丢包浪费带宽max_th设置过高或max_p设置过低会导致RED反应迟钝最终演变为尾丢弃Tail-drop。建议初始设置min_th设为队列最大深度的1/3max_th设为2/3max_p设为0.1-0.2。对于高速链路需要增大wq如从2^-9调到2^-7让平均深度对拥塞反应更快。许多设备支持基于ECN显式拥塞通知的RED它通过标记而非丢弃报文来通知TCP减速对吞吐量更友好应优先考虑。4.2 ATM流量管理相关典型问题问题1CBR业务出现信元丢失但链路利用率不高。排查重点检查maxCTD参数。CBR对时延极其敏感。如果信元在TM的软队列或日历中等待时间超过了配置的maxCTDTM会主动丢弃它。使用网管或诊断命令查看CBR VC的队列深度和信元丢弃计数。可能需要调整调度优先级确保CBR队列被绝对优先服务或者检查是否有更高优先级的流量如rt-VBR配置不当占用了过多资源。问题2GFR业务性能差上层TCP吞吐量低。排查首先确认PPD功能是否已启用。如果没有启用PPD那么一个AAL5帧中只要丢失一个信元整个帧都会因CRC错误被丢弃导致大量无效传输和TCP超时重传。其次检查MCR最小信元速率的配置是否合理是否被其他更高优先级的业务完全挤占。使用show atm vc命令查看GFR VC的“符合信元数”、“不符合信元数”和“PPD丢弃数”。4.3 DiffServ与ATM的融合与选型思考在现代网络纯粹的ATM网络已不多见但ATM流量管理的理念如基于合同的监管、严格的优先级调度在MPLS-TE、SD-WAN等场景中仍有体现。而DiffServ是当前IP网络QoS的绝对主流。选型考量部署场景DiffServ适用于基于IP的局域网、数据中心、互联网边缘。ATM或类ATM机制可能存在于某些遗留的传输网络或移动回传网络中。控制粒度ATM提供VC/VP级别的精细控制但配置和管理复杂。DiffServ控制粒度较粗基于DSCP或流但易于部署和管理。资源开销ATM 53字节信元有近10%的信元头开销5字节头/53字节。IP/以太网帧的头部开销相对较低。但ATM固定长度信元便于硬件交换和调度。发展趋势随着网络带宽的极大丰富“过度配置”Over-Provisioning成为最简单粗暴的QoS方案。但对于广域网链路、无线接入、云数据中心东西向流量等稀缺资源场景精细的QoS仍然是必需品。同时结合SDN和遥测技术实现动态的、基于应用的QoS策略下发和调整是未来的方向。我个人在多年的网络运维和设计中发现理解QoS的底层算法比记住命令行更重要。当出现问题时能够从令牌桶、RED、WFQ、GCRA的原理出发分析计数器、查看队列状态才能定位到根本原因。例如看到AF队列持续有RED丢包就知道该业务的速率超过了承诺速率需要调整CIR或检查是否有“流量错位”非关键业务被错误标记为AF。QoS不是配置完就一劳永逸的它需要基于业务监控持续调优。最后一个小技巧在测试QoS策略时不要只用ping和iperf它们无法模拟真实的业务流量突发。使用ostinato、TRex这类流量生成器模拟出符合特定分布的混合流量才能验证策略在真实压力下的效果。
网络QoS技术深度解析：DiffServ与ATM流量管理原理与实践
1. 网络服务质量QoS的核心价值与挑战在网络工程师的日常工作中最头疼的莫过于当视频会议卡顿、语音通话断续、关键业务数据延迟时用户打来的投诉电话。所有流量在网络上“平等”地挤占带宽其结果就是关键应用体验的灾难。网络服务质量QoS技术就是为了解决这个“平等”带来的不平等问题而生的。它本质上是一套流量管理规则通过识别、标记、监管和调度网络中的数据包为不同优先级的业务提供差异化的传输保障。简单来说它就像交通管理系统让救护车实时音视频、消防车金融交易拥有优先通行权而普通货车文件下载则在非高峰时段通行从而确保整条道路网络的通行效率和安全。当前主流的QoS技术体系主要分为两大类IP网络领域的区分服务DiffServ和传统电信领域的异步传输模式ATM流量管理。DiffServ架构灵活部署在IP层适用于现代数据中心和互联网而ATM则提供严格的、面向连接的信元级服务质量保证常见于早期的骨干网和专线。理解这两者的原理不仅是应对厂商设备配置的需求更是深入理解流量整形、队列调度、拥塞避免这些底层机制的钥匙。无论你是运维工程师需要排查视频会议卡顿还是开发者在设计低延迟的实时通信系统掌握QoS的核心思想都至关重要。本文将深入拆解DiffServ和ATM流量管理的技术细节从报文分类到队列调度并结合实际芯片实现逻辑让你不仅知道怎么配更明白为什么这么配。2. DiffServ架构深度解析从分类到调度DiffServ模型的核心思想是将复杂的服务质量保证简化在网络边缘完成核心网络设备只根据简单的标记执行相应的转发行为PHB每跳行为。这种“边缘复杂核心简单”的设计使其具备了良好的可扩展性。2.1 多字段MF分类与流标识流量管理的首要步骤是分类。在芯片实现中如Freescale现NXP的某些网络处理器DiffServ组件会为每个出口端口设置一个输入队列。Ingress入口处理单元以严格的轮询方式从这些队列中取出IP报文描述符。关键点在于它并非处理整个数据包而是通过DMA将包含IP、TCP/UDP头部的前64字节预取到芯片的本地内存DMEM中以提升处理效率。分类的依据是一个称为多字段MF位掩码的配置。这个掩码决定了使用哪些头部字段来构成一个流的识别键Key。常见的字段包括源/目的IP地址区分不同主机或网段。协议号区分TCP、UDP、ICMP等。源/目的TCP/UDP端口区分不同应用如HTTP80、DNS53、RTP动态端口。这些被选中的字段值会被拼接起来形成一个最长14字节的查找键。芯片内部维护一个最长前缀匹配表通常由三态内容寻址存储器TCAM或软件实现将此键映射到一个流ID和一个DiffServ PHB。最长前缀匹配支持通配符例如可以将10.1.0.0/16网段的所有流量定义为同一个流这提供了极大的灵活性。实操心得在设计MF分类规则时应遵循从精确到宽泛的原则。优先使用“目的IP目的端口”来匹配关键服务器应用再使用“源IP网段”来匹配部门或用户组。避免创建大量过于精细的规则这会增加TCAM的负担和查找延迟。在实际芯片中规则表大小是有限资源。2.2 令牌桶算法与三色标记器分类并确定PHB后下一步是对流量进行测量和标记这就是计量器Meter的工作。DiffServ常用的是基于RFC 2697的单速率三色标记器srTCM。其核心是维护两个令牌桶C桶承诺突发桶和E桶超额突发桶。每个流在表中都有对应的配置参数CIR承诺信息速率承诺长期平均速率。CBS承诺突发尺寸在短时间内允许超过CIR的突发流量上限。EBS超额突发尺寸在CBS基础上进一步允许的突发量通常标记为更低优先级。算法原理如下令牌生成系统以一个固定的时间间隔Tick如512个核心时钟周期为周期向C桶和E桶中分别添加令牌。每次添加的令牌数Increment CIR / (每Tick对应的秒数)。这模拟了速率的平均化。令牌累积上限C桶的令牌数不能超过CBSE桶的令牌数不能超过EBS。多余的令牌被丢弃。报文着色当一个大小为P的报文到达时如果C桶令牌数 P报文标记为绿色并从C桶中扣除P个令牌。否则如果E桶令牌数 P报文标记为黄色并从E桶中扣除P个令牌。否则报文标记为红色。在芯片实现中需要高效地处理时间更新。通常维护一个lastUpdateTime记录上次处理的时间戳单位是Tick。当新报文到达时计算当前时间与lastUpdateTime的差值并一次性为两个桶补充差值 * Increment个令牌同时不超过各自的上限然后再进行着色判断。这种方式避免了频繁的定时器中断计算效率高。注意事项CBS和EBS的设置需要根据实际业务突发特性谨慎调整。CBS设置过小会扼杀业务的正常突发如HTTP请求导致绿色报文少设置过大则失去了流量监管的意义。一个经验法则是CBS至少应容纳一个典型业务交互如一个视频关键帧的数据量。EBS通常设置为CBS的1.5到2倍用于容纳非预期的、可容忍延迟的突发。2.3 确保转发与确保转发PHB处理标记后的报文会根据其PHB进入不同的处理路径EF加速转发PHB用于极低延迟、低抖动的业务如语音。在实现中任何被标记为红色的EF流量通常会被直接丢弃因为不符合严格的服务合同。绿色和黄色的报文则被标记为EF的DSCP值通常为46二进制101110并立即送入对应出口CPRC的QMU队列享受绝对优先调度几乎不经过队列缓存。AF确保转发PHBRFC 2597定义了4个AF类AF1x, AF2x, AF3x, AF4x每类有3个丢弃优先级低、中、高。绿色报文对应低丢弃优先级黄色对应中红色对应高。芯片会根据颜色将报文DSCP字段改写为对应的AF编码如AF11, AF12, AF13。随后报文被送入对应AF类和出口端口的整形器Shaper软队列。BE尽力而为PHB标准IP流量不进行特殊标记直接进入BE队列等待调度。这里有一个精妙的设计对于AF PHB标准要求为每个丢弃优先级维护独立的队列。但在芯片资源受限时可以采用单队列模拟三队列的策略。即只维护一个物理软队列但通过令牌桶着色和调度算法保证在逻辑上绿色报文队首先于黄色被服务黄色先于红色。这是通过将不同颜色的报文在入队时按顺序排列并结合后续的调度算法实现的。2.4 随机早期检测RED与拥塞避免报文进入AF或BE的软队列后并非简单地等待。如果队列满了再丢包对于TCP流而言会导致所有连接同时进入拥塞避免阶段降低窗口然后同时恢复引发全局同步使链路利用率大幅波动。随机早期检测RED算法就是为了平滑地、随机地提前丢包避免这种情况。RED的核心是监控队的平均深度而非瞬时深度。平均深度avg通过一个指数加权移动平均EWMA公式计算avg (1 - wq) * old_avg wq * current_queue_depth。其中wq是一个很小的权重如2^-9使得平均深度对瞬时波动不敏感能反映较长时间的拥塞趋势。RED算法流程如下设置两个阈值min_th最小阈值如128个报文和max_th最大阈值如256个报文。当avg min_th不丢包。当min_th avg max_th以概率Pb丢弃新到达的报文。Pb从0线性增长到max_p最大丢包概率如2^-7。Pb max_p * (avg - min_th) / (max_th - min_th)当avg max_th丢弃所有新到达报文。在定点数处理器如很多网络处理器内核上实现浮点运算的Pb和随机数比较是昂贵的。因此芯片实现中常采用优化定点数表示使用32位整数高8位表示整数部分低24位表示小数部分。这样数字1表示为0x010000007.5表示为0x078000007 * 2^24 0.5 * 2^24。乘除2的幂次运算可以通过左右移位高效完成。概率计算优化预计算C1 max_p / (max_th - min_th)和C2 (max_p * min_th) / (max_th - min_th)。由于max_p、min_th、max_th常配置为2的幂C1和C2也是2的幂或简单分数计算Pb avg * C1 C2可以转化为移位和加法。随机丢包判定预生成一个256个随机数的表范围0-1用上述定点格式表示。当需要丢包时取出一个随机数R计算R / Pb。由于除法昂贵可通过计算Pb小数部分的前导零个数来近似-log2(Pb)然后将R左移相应的位数来近似R / Pb再与一个计数变量比较来决定是否丢包。这种方式在保证随机性的同时性能极高。踩坑记录RED参数wq、min_th、max_th需要根据实际链路带宽和流量模型调整。wq太大平均深度对瞬时突发敏感可能导致不必要的丢包太小则反应迟钝。max_th不应超过队列总深度。在实际部署中往往需要开启RED的“自适应”变种或者根据实时监控动态调整阈值这在固定功能的芯片中可能难以实现需要更灵活的软件方案。2.5 加权公平队列WFQ调度与出口处理经过计量、标记、整形和RED管理后报文在各自的AF PHB软队列中等待被调度发送。调度由WFQ出口模块执行其目标是按照预先为每个AF PHB分配的最小保证带宽比例来分配出口链路资源。芯片中常用赤字轮询Deficit Round Robin, DRR算法来实现WFQ因为它计算简单适合硬件实现。每个AF PHB软队列关联两个变量量子Quantum根据该PHB分配的带宽比例计算得出例如Quantum (PHB带宽 / 总带宽) * 平均报文大小。这是一个可动态配置的字节数。赤字计数器Deficit Counter初始为0。DRR调度每一轮Round的步骤如下为当前队列的赤字计数器增加其Quantum值。检查队列头部的报文大小P。如果赤字计数器 P则发送该报文并将赤字计数器减去P。重复步骤2直到队列空或赤字不足以发送下一个报文。如果赤字计数器 P则本轮跳过此队列转向下一个队列。赤字计数器保留到下一轮。这种机制保证了每个队列在长期内获得的带宽与其Quantum成正比同时允许短期的突发积累多轮的赤字一次性发送。对于EF流量通常采用严格的优先级队列PQ只要EF队列有报文就优先发送。BE队列则在所有AF队列空闲时才被服务。此外出口模块还维护一个next_service_time变量记录端口下一次可服务的时间基于端口线速和上一个发送报文的大小计算。这防止了DiffServ CPRC过快地向下游QMU队列倾倒数据而是利用自身的RED软队列来缓冲流量峰值实现更平滑的整形。3. ATM流量管理面向连接的信元级控制与IP网络基于无连接、统计复用的DiffServ不同ATM是面向连接的采用固定长度53字节信元的技术。其流量管理TM更为严格和精细在VC虚电路或VP虚通道级别提供服务质量保证。3.1 业务类别与流量合同ATM定义了多种业务类别每种都有严格的流量参数合同CBR恒定比特率像租用专线提供固定的峰值信元速率PCR。对时延和抖动极其敏感有最大信元传输时延maxCTD要求。rt-VBR实时可变比特率适用于压缩的实时视频、语音。有PCR、可持续信元速率SCR和突发容限BT。也有严格的maxCTD。nrt-VBR非实时可变比特率适用于有突发性但对时延要求稍宽的交易数据。参数同rt-VBR但maxCTD较长。UBR未指定比特率尽力而为服务无保证。无参数。UBR和GFR通用帧速率在UBR基础上提供了最小信元速率MCR保证。GFR专为AAL5适配层5用于封装IP包设计要求TM能识别AAL5的帧边界。3.2 通用信元速率算法GCRA原理ATM流量合约符合性的核心判定算法是GCRA也称为“漏桶算法”。它用两个参数定义增量I和极限L。I 1 / SCR或1 / PCR表示信元到达的理论间隔。L与突发容限BT相关表示允许提前到达的信元数量限度。算法维护一个理论到达时间TAT。初始化时TAT 0或一个过去的时间。当一个信元在时间t到达时如果t TAT - L则该信元是符合Conforming的。然后更新TAT max(t, TAT) I。如果t TAT - L则该信元是不符合Non-conforming的。TAT不变。对于CBR只用PCR参数运行一个GCRA实例。对于VBR需要运行两个GCRA实例一个用PCR参数作为“峰值信元速率漏桶”另一个用SCR和BT参数作为“可持续信元速率漏桶”。信元必须同时通过两个漏桶的检查才算完全符合。在芯片实现中时间t由一个以最快端口信元周期为单位的“墙钟”计数器提供。每个VC在表中存有它的TAT、I、L和maxCTD。处理信元时计算当前时间与TAT的差值判断符合性。不符合的信元可能被标记用于流量整形或直接丢弃严重不符合。3.3 针对AAL5的增强F-GCRA与部分分组丢弃对于GFR业务ATM TM需要感知AAL5的帧称为SDU边界。因此采用了帧级GCRAF-GCRA。其特殊规则是只在每个AAL5 SDU的第一个信元到达时进行GCRA符合性检查。如果第一个信元符合则整个SDU的所有后续信元都被视为“符合”尽管可能被标记为非符合用于整形。如果第一个信元严重不符合t TAT - L - maxCTD则整个SDU的所有信元直到帧尾都被丢弃。这被称为部分分组丢弃PPD。如果第一个信元不符合但非严重则它被标记SDU后续信元正常处理。PPD是一种重要的优化。既然AAL5 SDU的尾部有CRC校验丢失任何一个信元都会导致整个上层IP包被丢弃重传。那么在拥塞时主动丢弃一个SDU中剩余的信元可以立即释放缓冲区资源避免浪费带宽传输注定无效的数据。这与TCP的“快速重传”有异曲同工之妙。3.4 流量整形与调度实现被GCRA判定为“符合”的信元可以立即发送。而被判定为“不符合”的信元则需要被缓存起来延迟到其TAT时刻再发送这个过程就是流量整形。ATM TM组件通常由监管器Policer和整形器Shaper两个子组件协同完成。1. 基于软队列的调度早期方案芯片为每个业务类别CBR rt-VBR nrt-VBR在每个端口维护一组例如30个软队列。其中一个队列被标记为“当前队列”。GCRA判定为“当前”周期即TAT与当前墙钟差值在一个信元周期内可发送的信元放入当前队列。 调度器每个信元周期工作一次以严格优先级轮询方式检查各业务类别的当前队列先检查CBR当前队列若非空则发送一个信元若空则检查rt-VBR当前队列若空则检查nrt-VBR当前队列若全空则发送UBR队列的信元。 每隔max_queue_depth个信元周期“当前队列”的指针会移动到下一个软队列。这样一个“不符合”的信元其目标队列索引可通过(TAT - wall_clock) / max_queue_depth计算得出。信元在队列中的等待时间即传输时延可以预估如果超过该VC的maxCTD则信元在入队前就会被丢弃。2. 基于日历的调度优化方案为了获得更精确的时延控制和更低的抖动更先进的方案使用日历数组。将时间轴划分为离散的信元时隙每个时隙对应数组中的一个槽位。一个指针指向“当前时隙”。符合的信元插入当前时隙的槽位。需要在n个周期后发送的信元则插入当前指针后第n个槽位。如果目标槽位已被占用则顺延到下一个空闲槽位。 每个业务类别有自己的日历。调度器每个信元周期移动一次当前指针并以严格优先级CBR rt-VBR nrt-VBR UBR/GFR检查各日历的当前槽位取出信元发送。 日历方案避免了软队列方案中因队列深度估算带来的时延不确定性尤其有利于CBR和rt-VBR这类对抖动敏感的业务。4. 常见问题、调试技巧与方案选型在实际部署和调试QoS时会遇到各种问题。以下是一些常见场景和排查思路。4.1 DiffServ相关典型问题问题1关键业务如语音仍然有卡顿但设备显示EF队列并未拥塞。排查首先检查分类是否正确。使用抓包工具确认语音流如RTP的DSCP字段是否被正确标记为EF46/0x2E。其次检查路径上所有设备不仅是本设备的端口是否都启用了信任DSCPtrust dscp或正确的CoS到DSCP的映射。中间可能有无视QoS标记的设备将DSCP重置为0。最后检查出口物理端口是否有拥塞。EF队列不拥塞但出口链路被大量AF或BE流量占满时EF流量依然会被延迟发送。确保为EF流量配置了严格的优先级队列LLQ并限制其带宽避免饿死其他队列。问题2AF业务带宽分配不均某个类的流量远低于其配置的权重。排查检查WFQ/DRR的配置。确认每个AF类的“带宽百分比”或“最小保证带宽”配置是否正确。更重要的是检查该AF类的实际流量是否达到了保证速率。WFQ是“加权公平”队列如果某个队列空闲其未使用的带宽会立即分配给其他有需求的队列。因此低流量可能只是因为源端没有发送那么多数据。可以使用show policy-map interface以思科为例查看每个类的“队列深度”、“发送包数”、“丢弃包数”来辅助判断。问题3开启RED后TCP吞吐量波动剧烈甚至下降。排查RED参数配置不当。min_th设置过低会导致过早丢包浪费带宽max_th设置过高或max_p设置过低会导致RED反应迟钝最终演变为尾丢弃Tail-drop。建议初始设置min_th设为队列最大深度的1/3max_th设为2/3max_p设为0.1-0.2。对于高速链路需要增大wq如从2^-9调到2^-7让平均深度对拥塞反应更快。许多设备支持基于ECN显式拥塞通知的RED它通过标记而非丢弃报文来通知TCP减速对吞吐量更友好应优先考虑。4.2 ATM流量管理相关典型问题问题1CBR业务出现信元丢失但链路利用率不高。排查重点检查maxCTD参数。CBR对时延极其敏感。如果信元在TM的软队列或日历中等待时间超过了配置的maxCTDTM会主动丢弃它。使用网管或诊断命令查看CBR VC的队列深度和信元丢弃计数。可能需要调整调度优先级确保CBR队列被绝对优先服务或者检查是否有更高优先级的流量如rt-VBR配置不当占用了过多资源。问题2GFR业务性能差上层TCP吞吐量低。排查首先确认PPD功能是否已启用。如果没有启用PPD那么一个AAL5帧中只要丢失一个信元整个帧都会因CRC错误被丢弃导致大量无效传输和TCP超时重传。其次检查MCR最小信元速率的配置是否合理是否被其他更高优先级的业务完全挤占。使用show atm vc命令查看GFR VC的“符合信元数”、“不符合信元数”和“PPD丢弃数”。4.3 DiffServ与ATM的融合与选型思考在现代网络纯粹的ATM网络已不多见但ATM流量管理的理念如基于合同的监管、严格的优先级调度在MPLS-TE、SD-WAN等场景中仍有体现。而DiffServ是当前IP网络QoS的绝对主流。选型考量部署场景DiffServ适用于基于IP的局域网、数据中心、互联网边缘。ATM或类ATM机制可能存在于某些遗留的传输网络或移动回传网络中。控制粒度ATM提供VC/VP级别的精细控制但配置和管理复杂。DiffServ控制粒度较粗基于DSCP或流但易于部署和管理。资源开销ATM 53字节信元有近10%的信元头开销5字节头/53字节。IP/以太网帧的头部开销相对较低。但ATM固定长度信元便于硬件交换和调度。发展趋势随着网络带宽的极大丰富“过度配置”Over-Provisioning成为最简单粗暴的QoS方案。但对于广域网链路、无线接入、云数据中心东西向流量等稀缺资源场景精细的QoS仍然是必需品。同时结合SDN和遥测技术实现动态的、基于应用的QoS策略下发和调整是未来的方向。我个人在多年的网络运维和设计中发现理解QoS的底层算法比记住命令行更重要。当出现问题时能够从令牌桶、RED、WFQ、GCRA的原理出发分析计数器、查看队列状态才能定位到根本原因。例如看到AF队列持续有RED丢包就知道该业务的速率超过了承诺速率需要调整CIR或检查是否有“流量错位”非关键业务被错误标记为AF。QoS不是配置完就一劳永逸的它需要基于业务监控持续调优。最后一个小技巧在测试QoS策略时不要只用ping和iperf它们无法模拟真实的业务流量突发。使用ostinato、TRex这类流量生成器模拟出符合特定分布的混合流量才能验证策略在真实压力下的效果。
