摘要

  • RFC 3006 不改写发送者原始 TSpec，而是在其中加入可压缩性提示；只有确实具备相应链路压缩能力的路由器，才可以在本地生成更小的压缩后 TSpec。
  • 节点一旦依靠提示少留资源，就必须像网络边界一样按这个较小预算监管流量，把压缩不及预期的代价留给获得折扣的流，而不是转嫁给其他预留。

RFC 3006 用一个很具体的差值揭示了信息与权力的边界。发送者声明一条 48 kbit/s 的流，每个分组 120 字节。某个低速接口可以把 40 字节的 IP、UDP、RTP 报头压缩成 4 字节，于是这条流在该链路上的开销只有原来的 70%，也就是 33.6 kbit/s。可是其他跳点未必具备同样能力。

如果发送者直接把 TSpec 写成 33.6，它会向不能压缩的链路少报资源；如果始终写 48，能够压缩的路由器又可能拒绝一条实际装得下的预留。RFC 没有让任何一方替全路径作决定。按照 RFC 2210 的结构，原始 Sender TSpec 在传输中保持不变，只增加一种“提示”：说明可用的压缩类型，并可附带估算因子。

“提示”不是修辞。发送者知道数据大致长什么样，却不知道每个接口运行什么代码；路由器知道本地压缩器和容量，却不能替发送者重写全程需求。RFC 2205 负责让信息抵达，接纳控制与流量控制才决定是否采用。公共对象携带可能性，本地运行代码赋予它实际效力。

算式也拒绝偷懒。原始速率 r 为 48 kbit/s，桶深 b、最大分组 M 都是 120 字节，最小监管单元 m 是 64。70% 因子把 r 降到 33.6，把 b 与 M 降到 84；但 m 要减掉 36 字节固定报头节省，得到 28，而不是机械乘以 0.7。

一般情况下，如果压缩固定省去 N 字节，r 与 b 乘以 f/100，峰值速率不变，M 与 m 减去 N。RFC 同时指出，这只适用于相应算法。UDP 校验和、RTP 时间戳是否线性、分组大小分布都会影响真实节省。路由器可以自己做保守估算。因子为零表示把计算留给路由器，100 则表示不期待任何压缩收益。

多发送者预留让责任更复杂。每个 Sender TSpec 必须先按各自因子折算，再组合成有效需求。对于 RFC 2212 的保证服务，接收端速率要使用按突发大小加权的平均压缩因子。与此同时，本跳还要反向放大误差项 C，避免较小的 R 无声增加 C/R 延迟。节省带宽不能偷偷改掉接收者选择的时延目标。

真正的治理问题出现在压缩结果不如预期时。路由器按 33.6 kbit/s 接纳，实际却需要 35，那么多出的 1.4 从未被预留，只能依照相应服务规则作为超额流量处理。折扣是一个有条件的资源判断，不是事后向其他流追索容量的权利。

发送者还可能故意夸大可压缩性，使本该被拒绝的流通过接纳，并挤占诚实预留的资源。RFC 3006 因而规定：任何使用提示作接纳决策的路由器，都应当在监管意义上把自己视为网络边界。真正的入口或许已经按 48 kbit/s 检查过发送者，但它无法证明后续某条链路上的压缩输出不超过 33.6。

这是一条重要的责任迁移。谁把信息转换成资源折扣，谁就成为验证折扣的节点。监管最大分组时仍使用未压缩的 M，因为某些分组可能无法成功压缩。平均收益与单包最坏情况被保留为两张不同凭证。

向后兼容也遵循同一逻辑。不了解新参数的旧路由器，理想行为是在本地忽略、转发时保留，并按原始 TSpec 分配资源。这样，下游懂得提示的节点仍可使用，而无知不会自动产生折扣。部分旧实现可能把 PATH 当成格式错误；发送者收到 PathErr 后可以去掉提示重试。安全退化回到的是成本更高但已理解的合同。

相邻文献划清了本文范围。RFC 2508 定义 IP/UDP/RTP 报头压缩；RFC 2688 计算 PPP 分片、成帧与填充之后的线路成本；RFC 2689 讨论低比特率链路的整体协同。RFC 3006 独有的是“主张—折扣—监管”闭环。

后来 RFC 3241 为 PPP 上的 ROHC 复用了这套提示编号框架。这能证明扩展面存在，不能证明普遍部署或商业成功。可确认的历史意义是：压缩只有在本地节点能够执行、计算并承担偏差后果时，才有资格改变接纳边界。

用 Lu Heng 的方法看，强制共同层只需要传递最小事实，本地未来决定留给各跳，采用是自愿而可验证的。所谓稳定，也不能只看预留对象仍然存在；它必须看产生容量折扣的压缩条件是否仍然成立。字段、能力、计算、观测与后果彼此分开，才不会让一个乐观提示变成他人的隐形风险。

来源