RFC 3133：漂亮交付率为何掩盖糟糕应用表现

摘要

RFC 3133 为一条 Frame Relay 虚电路的单一方向定义了有效载荷字节交付率和帧交付率，并把承诺负载与超额负载分别计算。
它同时警告：一条很小的确认帧若被丢弃，可能引发大量数据帧重传；比率在自身边界内依旧正确，却不能证明应用或用户获得了良好结果。

最轻的一帧，可能握着最重的权力

想象一笔传输。大批数据帧沿一个方向通过 Frame Relay 虚电路；反方向只回来一条很短的确认。几乎所有数据都到了，唯独确认没有到。按字节算，缺口小得几乎看不见；按帧算，它也只是众多帧中的一个。但发送方迟迟收不到推进状态的证据，可能等待超时，再把先前的数据重新发送。

这不是后人对旧指标的挑剔。RFC 3133 在解释 Data Delivery Ratio 与 Frame Delivery Ratio 时，就主动给出了这类反例：交付率未必能代表某个应用实际获得的交付效果。一条小确认消息的损失，可能造成大量数据帧重传，于是网络报出好看的比率，用户却感到性能很差。

公式并没有撒谎。它精确回答了自己被要求回答的问题：在声明的测量边界内，多少有效载荷字节或多少帧成功抵达。应用关心的则是另一件事：那条能推动状态机前进的控制消息是否及时抵达。前者不能自动取得后者的证明权。

端口速度不是服务承诺

Frame Relay 的一组速率名词，很容易在汇报中被压缩成“带宽”。RFC 3133 把它们重新拆开。

接入信道是用户设备注入数据的物理通道，Access Rate 表示注入的最高速度。可是一条 T1、E1 或分数速率信道能跑多快，并不等于服务协议承诺为用户运送多少。

Committed Information Rate（CIR）才是网络在两处服务地点之间维持的承诺传输速率。Bc 是在测量区间 Tc 内正常条件下承诺传送的比特量；Be 是 Bc 之外、网络可以尝试运送但成功概率更低的超额突发。

Tc 也不是周期性打开的固定时间盒。RFC 3133 将它描述为由入站数据触发的滑动测量区间，并以 Bc/CIR 计算。要判断一批流量属于承诺量还是超额量，需要保留到达时序和合同参数，而不是只看接口铭牌。

Discard Eligible（DE）位表达的是拥塞时的丢弃偏好，不是一张“已经丢弃”的收据。RFC 3133 明确区分 discardable 与 discarded：前者是可被丢的候选，后者是设备确实丢掉的帧。拥塞在评估前消退时，标记了 DE 的帧仍可能通过；运营者也可能按 PVC、IP 地址或端口等规则选择未标记的帧；格式或 FCS 错误则会产生另一类丢弃。

因此，承诺、分类、资格与动作是四件事。把它们压成一个“丢包”字段，责任边界便消失了。

指标有方向，也有住址

RFC 3133 延续 RFC 1242 的定义格式，并再次区分术语文档与方法文档：前者定义要测什么，后者说明如何采集。一个指标名称和公式，不等于一次已经完成的基准测试。

Data Delivery Ratio（DDR）用成功交付的有效载荷字节除以尝试发送的有效载荷字节；地址字段与 FCS 不在有效载荷内。Frame Delivery Ratio 则以成功接收的帧数对尝试发送的帧数。两者都只描述一条虚电路的一个方向。

这个边界非常关键。全双工连接的两个方向各有一套比率。正向数据路径很好，不能证明反向确认路径也很好。一条 DLCI 的结果不能代表同一端口上的所有虚电路。两个测量点之间的成功，也不能代替进入前或离开后的结果。

RFC 还允许把总体比率拆开：DDR_c 对应 CIR 内的承诺负载，DDR_e 对应超额负载；帧比率也可同样分层。总数在算术上完全正确，仍可能掩盖承诺部分与机会性部分之间的巨大差异。

所以，一个百分比取得解释权之前，必须先回答：哪条虚电路、哪个方向、哪个区间、哪一类负载、怎样定义有效载荷、从哪里开始观察、在哪里结束。没有这些坐标，精确到小数点后的数字也无法复核其权限。

字节数看不见控制作用

按字节计算时，大数据帧权重大，小确认帧权重小。按帧计算时，两者各算一帧。可这两种计数都不记录确认帧在状态机中的作用。

确认可能释放发送窗口、承认累计进度、避免计时器到期，或允许发送方删除待重传状态。它的系统价值不是由长度决定的，而是由它能授权什么状态迁移决定的。失去它，少量统计损失可以扩散成大量重复工作。

我们当然可以虚构一个“1000 帧只丢 1 帧”的示例，得到 99.9%。但 RFC 3133 没有发表这样的实测，本文也不应把方便的算术包装成历史事实。它真正建立的是可能性边界：小确认的丢失可能造成许多数据帧重传，具体数量由传输协议、窗口、定时器、后续累计确认和实现决定。

反过来，也不能说每次确认丢失都会严重伤害应用。后来的累计确认可能补上证据，恢复机制可能在超时前工作。RFC 的反例打破的是“高交付率必然等于好应用表现”这一等式，而不是建立另一个绝对命题。

时延平均值只认识幸存者

Frame Transfer Delay 也有同样的样本边界。RFC 3133 精确定义了帧离开测量点一的事件和进入测量点二的事件，然后对成功收到的帧计算平均时延。测量期间发出却没有收到的帧，不进入平均值。

这在数学上没有问题，却要求读者把时延与丢失一起阅读。平均时延很低，可能只是幸存帧很快；那些永远没有进入终点的帧恰好承载了最坏结果。若不保留缺失总体，平均值会因为最糟的样本被排除而显得更好。

Frame Transfer Delay Variation 使用观察到的最大时延减去最小时延。RFC 指出，大幅变化可能影响 TCP 往返时间估算与吞吐，过高时延也会伤害 IP 语音等应用。这是机制关系，不是某个运营网络的实测结果。

有些丢弃是在阻止错误扩散

RFC 3133 罗列了多种错误帧：长度过长或过短、比特数不合规则、DLCI 无效、带有 abort 序列、旗标分隔错误、FCS 校验失败。对于这些帧，丢弃可能比继续转发更有利，因为错误内容不会进入更高层，重传可以提供干净副本。

这意味着，一个“discard”计数器可能把动机完全不同的动作装进同一格。流量整形或 policing 在维护合同；DE 偏好在分配拥塞损失；FCS 检验在保护数据完整性。它们都可能触发上层恢复，却不能互相代替为故障原因。

调查必须保留事件谱系：帧是否在入口被看到？它被归为承诺还是超额？是否具备丢弃资格？哪条规则做出选择？是否存在完整性错误？反向确认在哪里消失？传输层随后重传了什么？应用最终有没有完成？只留下最终百分比，这些问题都无法回答。

这是一份术语表，不是产品成绩单

RFC 3133 于 2001 年 6 月作为 IETF Benchmarking Methodology Working Group 的 Informational 文档发布。它扩展 RFC 1242、RFC 1944 和 RFC 2285 的基准测试词汇，并引用 Frame Relay Forum 与 Frame Relay 服务 MIB 的定义。

它没有测试一个具名产品，没有证明某家运营者实现了这些计数器，也没有证明某份 SLA 正确使用比率，更没有记录用户获得了多少吞吐或满意度。工作组最后一版 Internet-Draft 证明的是文本演进，不是部署历史。

相邻 RFC 各司其职。RFC 1944、RFC 2544 与 RFC 2889 讨论测试方法；RFC 2761 提供 ATM 基准语境；RFC 2954 定义 Frame Relay 服务的管理对象；后来发布的 RFC 6349 处理 TCP 吞吐测试框架。它们都不能把 RFC 3133 的术语自动变成生产证据。

这份文档真正留下的，是一种诚实的测量观：指标可以精确，却必须明确停止说话的地方。

从一个绿灯回到三套收据

第一套收据属于网络。它应保存接入信道、DLCI、方向、测量区间、CIR、Bc、Be、Tc，保存承诺与超额的 offered/delivered 字节与帧，保存 DE、policing、FECN/BECN、错误原因、丢弃原因和测量边界。

第二套属于传输层：哪条确认没有到，哪个序列状态依赖它，计时器何时触发，重传了多少帧和字节，恢复何时结束。第三套属于应用：操作标识、完成条件、时延预算、重试次数、最终状态与用户看到的结果。

后两套不能从第一套里自动补齐。DDR 证明其范围内的有效载荷字节交付比例；帧比率证明帧的交付比例。它们不是应用完成、合同满足或人的体验收据。

Frame Relay 已不再是互联网接入的主角，但这种治理错误仍很现代：机构选择最便宜、最容易聚合的可观测量，然后慢慢忘记它只是投影。RFC 3133 留下的办法，是保留数字，也保留数字的管辖范围；在宣布系统成功之前，要求它拿出自己那一层的证据。

那条确认帧很小。它提醒我们的事情很大：后果不会按字节数等比例增长，可信指标的标志也不是覆盖一切，而是清楚承认自己不能证明什么。

交付率很好，应用表现却很差：RFC 3133

为何重要

摘要

最轻的一帧，可能握着最重的权力

端口速度不是服务承诺

指标有方向，也有住址

字节数看不见控制作用

时延平均值只认识幸存者

有些丢弃是在阻止错误扩散

这是一份术语表，不是产品成绩单

从一个绿灯回到三套收据

来源

档案背景详情

Strategic Circle

Leadership Alliance

Strategic Circle 专属简报

Leadership Alliance 简报