摘要

  • RFC 1363 为多媒体会议等应用提出单向流的服务请求格式；双向通话需要两份请求。延迟字段告诉网络何时继续提速已无明显收益，并非统一的最迟到达期限。
  • 请求还要说明持续与峰值流量、突发、延迟波动、丢包容忍度和保证等级。最后一跳若是可能拥塞的以太网，网络就得把“通常可用”与“每跳保证”分开说。

“保证 100 毫秒”听起来像一份干脆的合同，直到有人问这 100 毫秒从哪儿到哪儿。Craig Partridge 在 1992 年 9 月的 RFC 1363 中拿美国到日本和同城通信作比较：前者若只用 100 毫秒，用户可能满意；后者花同样时间，用户可能失望。这是规范中的推理例子，不是两条线路的实测成绩。它戳破了一个便利的念头：应用填上一个上限，网络便能在任何地理条件下盖章。

当时研究者想为视频会议、可视化等分布式应用争取可预期的服务。应用可以在发送之前、建立连接时，甚至发送开始后与网络协商。RFC 没有规定协商仪式，而是先规定一张“需求单”应该写什么。需求单只描述一个方向：两人互相说话，去程和回程都要分别交代。把双向交谈压成一项指标，会把其中一边的排队和拥塞藏起来。

名为 Minimum Delay Noticed 的字段尤其诚实。它告诉网络：延迟降到某个程度后，再降的好处已经不明显。它不承诺所有包都必须在某个最大时限内到达。网络未必掌握端点的地理位置，移动终端又让距离更难预测；应用也未必知道用户此刻愿意忍受多少等待。Partridge 反驳“超过约 100 毫秒就无法交谈”的说法：几秒延迟会难受，但急事当前，人可能宁愿慢慢说，也不愿电话被拒绝。

需求单接着要求发送方交出流量形状：令牌桶的持续速率、最大传输速率和大致突发量。这不是漂亮的统计装饰。RFC 举的例子很硬：超过每秒 10 兆比特的流，不该经由每秒 1.5 兆比特的 T1 链路。再动听的延迟要求，也没法给一条窄链路变出容量。

接收端还有自己的账。发送方按固定节奏发出的语音采样，过了路由队列后可能忽快忽慢。接收方用缓冲把节奏重新排齐，能承受的延迟波动便与缓冲规模相连。规范把一段时间内丢了多少包、以及连续丢了多少包分开问：相同的总丢包数，集中在一阵里会造成不同的影响。网络若只汇报平均速度，应用仍不知道自己要准备多大缓冲。

最昂贵的一栏叫 Quality of Guarantee。它把纯粹的愿望、存在不确定段的保证、负载下可小幅退让的预测服务和逐跳可支持的坚定保证分开。Partridge 提到 IETF 的会议实验：以太网最后一跳经常能给出可接受的效果，却可能在通话期间饱和。这样的路径仍有用，但保证的边界就在最后一跳。预测服务需要路由器与链路合作，在拥塞时按可预期方式略降表现；不合作的链路则可能把“非完美保证”彻底打断。

要求坚定保证时，设计预期网络回答“是”或“否”。应用提出自己真正能接受的最低服务，网络寻找符合条件的路径，找不到就拒绝。Partridge 不想让每次开机拨通前都经历漫长议价。拒绝时可回传一份调整后的需求单作线索，但线索不是已预留的资源。

这份 RFC 只定义如何提要求，没有宣布一套已在全网运行的预约系统。它留下一个更耐用的审问方式：通话送来多少流量、终端能缓冲多久、路径哪一段只会“通常还行”、运营者究竟答应了哪一级保证？100 毫秒在这些问题之前只是一个好卖的数字。

来源：RFC 1363《A Proposed Flow Specification》；RFC Editor 的 RFC 1363 记录。