learn
严格优先级与饥饿：局部保护为什么会伤到其他流
理解 strict priority 如何优先服务关键队列，以及它为什么可能让低优先级流量饥饿，促使 TSN 继续引入整形和调度。
第四章：队列与整形资源隔离IEEE 802.1Q15 分钟
本节学习目标
- 理解严格优先级为什么能降低关键队列等待。
- 知道高优先级流量过多时会让低优先级队列饥饿。
- 能解释优先级调度为什么仍然是局部机制。
建议先读
核心概念
strict prioritystarvationlocal schedulingtraffic isolation
本章目录
- 01流量分类与队列：关键帧先要进对队列理解 traffic class、VLAN PCP、队列映射和本地调度之间的关系，避免把优先级当成魔法。
- 02Credit-Based Shaper：用 credit 把突发压成节奏理解 CBS 如何通过 credit 增减控制发送机会，以及它为什么适合平滑而不是严格定时。
- 03严格优先级与饥饿：局部保护为什么会伤到其他流理解 strict priority 如何优先服务关键队列，以及它为什么可能让低优先级流量饥饿，促使 TSN 继续引入整形和调度。
- 04整形的边界：平滑流量不等于安排时间窗口理解 CBS 等整形机制能减少突发和保护带宽，但不能像 Qbv 一样指定某个队列在某个时间发送。
- 05入口约束与 policing：坏输入不能交给队列背锅理解 TSN 里分类和整形之前还要约束输入流量，防止错误 talker、突发或超规格帧破坏队列和调度假设。
- 06ATS 与 CQF 放在哪里：先建立位置感，不急着深挖把 Asynchronous Traffic Shaping 和 Cyclic Queuing and Forwarding 放进 TSN 能力地图，理解它们和 CBS、Qbv 的关系。
解决什么问题
把关键流量分进队列以后，交换机还要决定哪个队列先发。严格优先级的直觉很直接：只要高优先级队列非空，就先服务它。这样关键帧通常能更快离开端口。
问题在于，这只是本地端口上的服务顺序。它不能约束关键流什么时候到达，也不能保证其他端口和后续交换机同步配合，更不能让低优先级流量完全没有生存空间。
背景与直觉
严格优先级像急诊分诊。重症病人优先处理是合理的，但如果所有人都被标成重症，分诊就失效；如果重症源源不断，普通病人会一直等。
网络里也是一样。关键流量少且受控时，优先级很有用；关键流量过多或配置泛滥时，高优先级队列本身也会排队，低优先级队列还可能长期得不到发送机会。
怎么解决
使用严格优先级时要配合流量边界。关键队列的输入速率、最大帧长和突发量必须受控，否则“高优先级”只是把拥塞搬到关键队列内部。
| 情况 | strict priority 的效果 | 后续需要什么 |
|---|---|---|
| 少量关键流，背景流多 | 明显减少关键流等待 | 验证尾延迟 |
| 高优先级流过多 | 高优先级内部也排队 | 整形或准入控制 |
| 低优先级需要最低服务 | 可能被长期压制 | CBS/带宽限制 |
| 多跳端到端 deadline | 单跳改善不够 | Qbv/Qcc |
所以严格优先级通常是基础能力，而不是完整方案。它让分类有意义，但还需要 CBS 控制节奏，Qbv 控制时间窗口，Qcc 控制路径资源。
带来了什么新问题
严格优先级会带来配置治理问题。谁有资格进入最高优先级？高优先级流量是否被限制？低优先级业务是否有最低服务要求？这些问题如果不回答，网络会逐渐变成“所有人都最高优先级”。
另一个问题是验证困难。平均延迟改善很容易看到，但低优先级饥饿、极端突发下的关键队列排队、跨多跳的累积等待，都需要更细的测试。
检查点
- 为什么严格优先级能改善关键帧等待，却仍然不能证明 deadline？
- 如果一个网络里大量流都被配置成最高优先级，会发生什么？
掌握检查
读完本节后，先用下面这些问题校准自己，而不是只确认“看过了”。
- 1能说明 strict priority 什么时候有效，什么时候会变成新问题。
- 2能解释为什么队列优先级不能替代端到端调度。