摘要

  • RFC 2212 以理想流体服务器为参照，要求每个服务节点用 C/R + D 覆盖自身实现偏离理想模型的最大误差。
  • 各节点的 C 和 D 沿路径累加为 Ctot 与 Dtot，再与 TSpec 和预留速率 R 共同形成最大排队时延上界。
  • 这个上界只对满足流量、包长、准入、资源和路径前提的报文有效；它不等于零抖动，也不证明身份、交付或应用结果。

先承认路由器不是一根专线

RFC 2212 先设定了一个干净的参照物：速率为 R 的专用线路，连续、逐比特地服务一个流，不受其他流影响。对于令牌桶 (r,b) 描述的流量，只要 R >= r，这个“流体模型”的排队时延就受 b/R 约束。

真实网络按报文工作。它要串行化一个包，要等调度时隙，也可能因处理路由更新而短暂停顿。规范没有把这些偏差藏进“实现细节”，而是要求节点用两个最大误差量为它们定价。

C 是随速率变化的误差。它在时延公式里除以预留速率，成为 C/R；报文化造成的积压就是典型例子。D 是与速率无关的最坏局部时间差，例如已经可以发送却仍需等待一个时隙。

因此，一个节点提供的服务不能差于：

b/R + C/R + D

C 和 D 不是平均值，也不是某个包的测量结果。它们是实现必须兜住的上限。节点可以做得更好，却不能一边公布较小误差，一边让最坏服务越界。

“这个流”必须先被五个参数描述

TSpec 不是一个优先级标签。它包含令牌速率 r、桶深 b、峰值速率 p、最小计费单元 m 和最大报文大小 M。

在任意时间区间 T 内，符合流量不能超过：

M + min[pT, rT + b - M]

m 防止大量小包在计量中被低估；M 则划出保障覆盖的最大包长。如果请求的 M 大于某条链路的 MTU，请求必须被拒绝。一个更大的包不能仅凭流标识就自动继承同一保障。

RSpec 再加入预留速率 R 和松弛量 S。R 不得小于 r。增大 R 通常可以降低排队时延。S 表示接收方在按该速率计算出的时延之外，还愿意接受多少额外时延。

这使保障成为一份可核查的条件组合：发送方描述流量，接收方提出资源与时延要求，网络逐点决定是否接纳。它仍然不是已经送达的数据面记录。

路径把局部误差相加，而不是抹平

C 和 D 采用加法合成。建立预留的机制可以把沿途节点的值组成 Ctot 与 Dtot，交给端点计算整条路径的最大排队时延。

当 p > R >= r 时，上界为：

[(b-M)/R × (p-R)/(p-r)] + (M+Ctot)/R + Dtot

当 r <= p <= R 时，上界为：

(M+Ctot)/R + Dtot

如果峰值速率未知或被忽略，还可以使用保守形式：

b/R + Ctot/R + Dtot

这个结构解释了为什么同样的预留带宽并不必然带来同样的时延承诺。更大的 R 能压低突发项和 Ctot/R，却不会让 Dtot 消失。不同节点、不同调度器和不同路径可以拥有不同误差债务。

固定时延属于另一张账

公式约束的是排队时延。传播、传输和固定处理时延仍需另外确定，再加到排队上界上，才能得到端到端最大时延。

RFC 2212 也不选择路由。路径由建立预留或路由机制决定。带宽和排队上界只在端到端路径不变时保持稳定。一旦路由变化，旧的 Ctot、Dtot 和固定时延即使仍被数据库完整保存，也可能不再描述当前数据流。

所以，路径身份不是可选元数据。把毫秒数抄进仪表盘、却不保存它对应的路径与时刻，会把一个精确的历史计算变成没有当前授权的数字。

松弛量可以换资源，不能重复花费

中间节点可以使用一部分 S，降低本地预留速率或增加本地可接受时延。但它必须满足：

Sout + b/Rout + Ctoti/Rout <= Sin + b/Rin + Ctoti/Rin

同时满足 r <= Rout <= Rin。

这不是随意降级。节点消耗 Sin - Sout 的松弛量，必须把新的 Rout 和剩余 Sout 向后传递。后续刷新仍要记住已经使用的份额，不能再次计算、再次占用。

接收方较宽松的时延目标，的确可能让原本会被拒绝的流获得接纳；代价则被明确记为额外时延，而不是凭空消失。

Csum 与 Dsum 只从最近一次整形点开始

端到端计算使用 Ctot/Dtot。整形节点还需要另一对部分和 Csum/Dsum，表示自最近一次整形以来累积的偏差。

在不利用峰值速率优化时，保守缓冲需求是 b + Csum + Dsum × R。这让整形器能够把仍然符合 TSpec 的流量恢复到原有形状，而不改变已承诺的上界。

如果 TSpec 小于实际流量，整形点可能形成长队列，并把一部分报文判为不符合。网络边缘通常应将这些报文降为尽力而为。已经存在预留，不代表流量可以无限越过自己的描述。

最大时延从来不等于零抖动

RFC 2212 明确说明，它不试图最小化 jitter，也就是最小与最大时延之间的差。它只控制最大排队时延。大多数报文完全可能早于最坏期限到达，再由接收端缓冲到播放时刻。

“有保障”因此不表示等间隔、不表示平均时延低，也不表示每个包都经历了上界。无排队溢出丢包的承诺同样有条件：流量必须符合，准入必须成功，沿途元素必须支持或充分模拟该服务，带宽和缓冲必须足够，包长必须在范围内，而且组件不能失效、路径不能中途改变。

公式没有失败；失去前提之后仍把它当成当前事实，才是失败。

每一份收据都有自己的终点

RFC 2212 没有规定只能使用某一种建立机制。RSVP、手工配置或网络管理协议都可以建立预留。RFC 2210 另行规定 RSVP 如何携带 FLOWSPEC、SENDER_TSPEC 和 ADSPEC；认证、计费与策略又是不同对象。

因此，证据链应被拆开：

  1. TSpec 是发送方的流量描述；
  2. RSpec 是接收方的请求；
  3. C/D 是服务元素的误差刻画；
  4. 准入是资源决定；
  5. 合成值和公式产生条件上界；
  6. 报文观测说明某个时刻实际发生了什么；
  7. 应用自己定义并证明成功。

一个获准的 FLOWSPEC 不证明发送方持续符合。一个正确计算的上界不证明某个包已经到达。一个到达的包不证明身份、授权、解码、呈现或用户结果。

RFC 2212 真正建立的是其中一层的确定性，而不是一张替所有层签字的总收据。

来源与证据边界

这些来源证明规范所定义的机制与边界，不证明任何具名网络或设备的部署、当前采用率、实测性能，也不证明它与后来 QoS 系统之间存在直接谱系。