55. 三级降档不是链路丢包，也不是控制命令
当 AF_XDP fabric 报告本地出端当前可用速率下降时，节点可对符合业务契约的 SPP 图像执行自主降档。它不是控制器命令，也不是前端控制。
这里的Degradation（降档）是业务表示变换：同一 Tile 从信息更多的 RGB 变成 Gray 或 Edge，以减少后续链路字节。它不同于：
- connectivity drop：链路不通，包根本不能进入该边；
- congestion drop：有限出口队列已满；
- token wait：链路连通但包等待令牌；
- BNN DROP：模型判断该 Tile 不是火焰候选；
- 控制器重路由：控制面传播事实后节点重新计算 FIB。
规则只读取包当前格式和即将使用的有向链路速率比例，不读取任务最终是否成功，也不等待某个验收时刻。不同方向可以有不同队列和统计，因此 A -> B 的降档判断不能偷用B -> A 状态。
55.1 三种格式为什么恰好形成三级
一个 16×16 Tile 的当前 payload 大小为：
| 等级 | 格式 | 每像素信息 | Payload 大小 |
|---|---|---|---|
| 0 | RGB24 | R、G、B 各 8 bit | 768 byte |
| 1 | GRAY8 | 一个 8-bit 亮度 | 256 byte |
| 2 | EDGE1 | 一个二值边缘 bit | 32 byte |
RGB 到 Gray 把 payload 缩小为三分之一；RGB 到 Edge 缩小为二十四分之一。体积减少不是免费收益：Gray 丢失颜色，Edge 只保留二值结构。系统必须同时记录网络收益和业务信息损失。
55.2 当前阈值规则
当前阈值规则是：
图 1 按 current_rate / design_rate 选择格式，等级只能单调下降（16×16 Tile 的 payload 大小）
current_rate/design_rate（当前速率/设计速率） | 目标格式 |
|---|---|
> 80% | RGB24 |
> 40% 且 <= 80% | GRAY8 |
<= 40% | EDGE1 |
边界必须精确：等于 80% 进入 Gray，等于 40% 进入 Edge。若包已经是更低格式，只能保持或继续下降，不能升级。
这里的 current_rate 是当前环境作用后的速率，design_rate 是链路基线。假设设计速率1 Mbit/s：
900 kbit/s -> 90% -> 保持RGB
800 kbit/s -> 80% -> 降为Gray
400 kbit/s -> 40% -> 降为Edge
格式等级只能单调增加，即信息只能保持或继续减少：
RGB -> Gray -> Edge
RGB -------> Edge
Gray ------> Edge
已经成为 Gray 的包后来走到高速链路也不会恢复 RGB，因为丢失的颜色信息已经不存在。fabric更不能凭空“升档”制造原始像素。
55.3 为什么 XDP 程序本身仍然不做降档
挂在宿主 veth 上的 XDP/eBPF 程序仍然只验证 Ethernet 目的 MAC 并 redirect 到按 source 索引的AF_XDP socket。它不解析 IPv6、SRH 或 SPP，也不运行 Gray/Edge 算法。
唯一受限例外位于AF_XDP 用户态 fabric。link worker 已经拥有当前 source -> destination链路的 rate 与 design rate，因而可以在发送边界：
- 验证 Ethernet、outer IPv6、SRH、inner IPv6、UDP 和 SPP 边界；
- 读取当前 SPP format，计算是否需要更低等级；
- 只构造一次本地 SRv6 detour（绕行）；
- 把包回注 source 节点，让 Linux 和真实算子完成变换。
把最小解析放在用户态，不等于允许 fabric 直接处理图片。链路 worker 只决定“需要哪一级”，实际 pixel 算法仍属于算子 namespace。
55.4 本地算子 detour 怎样保持原路径
假设一个包正在节点 17 准备发往节点 18，outer IPv6 的当前 active segment 是 S。链路要求Gray 时，fabric 构造的逻辑执行顺序是：
Gray@node-17具体SID -> resume segment S -> 原有其余segment
实现必须保存当时真正的 outer Destination Address，并在需要时移动当前 uSID 指令，形成单调前进的 SRH；不能回到最初静态列表猜当前位置。包被回注 lfc017 以后：
节点17 Linux命中本地Gray SID
→ End.X交给Gray namespace
→ Gray AF_XDP worker执行真实RGB24到GRAY8变换
→ 更新SPP format、payload length和UDP checksum
→ 回注并恢复resume segment S
→ 沿原物理路径继续到节点18
Edge 同理。detour 不改变原 source、destination、task、object 或 Tile 身份，也不保存另一套全网路由；它只在当前节点插入一个已经存在的具体算子 SID。
55.5 为什么每个网络节点都部署 Gray 和 Edge
链路变差可能发生在任意一条有向边的 source 节点。如果只有少数节点具备 Gray/Edge，其他节点检测到降档需求时无法形成本地闭环。因此启用三级降档的场景把“每个网络节点都有本地Gray 和 Edge”作为部署前提。
这是一条普适能力规则，不是按业务路径预先挑出几个正确节点。算子仍常驻运行，不能等包到来再临时启动；其他五类算子继续按异构 profile 分布。
55.6 怎样证明一次降档真的完成
一次完整证据链至少包括：
AF_XDP观察到有向链路比例并决定target format
→ detour被构造并回注source节点
→ 本地Gray或Edge具体SID被执行
→ 算子记录输入/输出格式和同一task/object/tile
→ 包恢复原SRv6路径
→ 目的端收到相同身份且格式已降低的Tile
仅有前端显示 Gray 图、仅有 fabric detour 计数，或者仅有目的端某个 GRAY8 包，都不能单独证明这条闭环。分析器必须按 task 身份区分三级降档业务与其他同样经过 Gray/Edge 的 HEFT 或 Anycast业务，避免把全局算子计数错误配对。
前端从真实事件显示 RGB、Gray、Edge 数量以及原图、中间图、目的图。它不能点击按钮触发降档，也不能因为观察器失败而停止链路、算子或业务。
降档是业务行为。它可以降低带宽和增加信息损失，成功与否应由 Tile 格式、算子事件、目的端接收和报告共同证明。
56. 第五至八编阶段自测
- 算子类型与实例有什么区别？
fd42:3:14::100和fd42:7::100各表示什么？- 为什么有状态算子的缓存键必须包含 task、object 和 epoch？
- Morton 码为 6 的示例坐标是什么？
- 100 个 Tile 到达 90 个时，为什么不是任务 0%？
- Anycast 为什么可能让网络无丢包却产生不完整窗口？
- 三级降档为什么不能从 EDGE1 恢复到 RGB24？