摘要

  • IntServ 用逐流状态换取精确准入，DiffServ 用聚合换取核心扩展性；两者付出的成本不同。
  • RFC 2990 点出了两条没有定义的信号：核心资源状态到边界，以及边界准入结果到应用。
  • 只有发现、准入、交付测量和用量归属各自留下证据，优先级服务才可能成为可核验的承诺。

请求发出去了，回答没有回来

服务质量最容易被画成一条快车道：数据包带着颜色进入网络，路由器给它更好的排队待遇。但 RFC 2990 的出发点不是颜色，而是负载。有限资源要产生差异化响应，既要有处理行为，也要有限制进入该行为的规则。若任何负载都能宣布自己优先，优先级只会重新分配拥塞。

Integrated Services 把负载控制同应用请求直接连接。应用描述预计流量，RSVP 沿路径传递预留请求，节点为被接受的流保留资源和状态。这个模型知道某项请求是否经过准入，也能够返回错误。

精确并不免费。每个预约都意味着路径状态、分类器、计量器和调度工作。流的数量增长，核心路由器的计算和内存负担也增长。对边缘可承受的粒度，在大型运营商核心里可能变成瓶颈。

Differentiated Services 选择压缩信息。边界负责分类和整形，内部节点只识别少量行为聚合。数据包上的代码触发一种逐跳行为，而不是要求每个核心节点重放应用的谈判。它之所以可扩展，正是因为核心不再记住每项请求。

但当资源不足时，网络可以不兑现请求，却没有义务把“不”送回应用。应用只能从延迟、丢包或吞吐量下降中猜测发生了什么。没有收到服务与收到拒绝并不是同一件事：前者含糊，后者才可供程序采取行动。

边界看得见策略，看不见完整的核心

RFC 2990 把 DiffServ 称为“以边界为中心”的运行模型。边界掌握策略入口，可以检查、标记、限速并把流量放入聚合；核心则用简化状态高效转发。

问题在两者之间。规范没有定义核心如何把实时资源可用性告诉边界流量调节器。边界可能依据静态配置或过期假设继续接纳。它也没有定义边界如何把准入结果告诉终端应用。

因此缺口其实有两段：

  1. 核心到边界：当前还能承担什么；
  2. 边界到应用：这次请求究竟被接受、降级还是拒绝。

把二者压成一个“成功”会掩盖权力边界。容量测量可以支持决策，却不是准入决定；准入决定可以允许一个流进入，却不是实际交付证明。每一段都应当有自己的身份、时间和有效期。

最短路径未必是服务路径

在准入之前，还存在发现问题。IntServ 与 DiffServ 通常沿最佳努力路由选出的路径工作。在分阶段部署中，有的路径具备差异化服务，有的没有。最低路由度量并不必然等于最适合某项服务的路径。

RFC 2990 指出，当时没有稳健机制让应用询问多个候选路径，找出能够支持指定服务轮廓的那一条。给包加标记不会发现新路径；在既定路径上请求预留，也不能证明别处不存在更可行的路线。

它还提出一种更微妙的路径质量含义：不是简单测量闲置资源，而是测量在某种质量水平下承载新增流量的潜力，其中可能包含把低优先级流量移往别处的能力。这个指标不是纯技术库存，它隐含谁应当让路的政策。

路径发现、路径选择和资源准入是三个动作。一个代码点不能替它们全部作证。

TCP 把另一半证据放在反向路径

TCP 让单向的服务图景很快失效。发送方根据返回的确认来安排后续数据。如果正向数据获得较好待遇，反向确认却进入普通或拥塞的队列，应用看到的吞吐量由两条路径共同决定。

确认路径上的抖动可能造成确认压缩，随后发送方集中发出一批数据，再次冲击正向服务容量。给两个方向对称待遇或许有帮助，但随之而来的问题是：两方向由谁提出请求，资源怎样归属，又如何避免为一次应用体验重复计费。

队列计数器能说明某个方向发生了什么，不能独自说明完整的应用结果。

先证明交付，再解释费用

RFC 2990 把资源测量与交付测量分开。前者回答准入系统“还能接多少”；后者回答运营商和客户“实际交付是否符合规格”。

运营商需要客观测量来支撑自己的服务声明。客户则需要知道额外费用是否换来了更好的应用表现。配置了一条高级队列、看到一个标记或完成一次预留，都处在结果之前。

文件预见优质服务可能带来增量资费。价格可以把额外资源成本交给提出额外需求的人，也可以抑制需求。但它同时承认：尚未定义把优质服务使用量绑定到特定客户的 QoS 计费模型，也未定义应收集哪些数据。

身份、资格、请求、准入、资源分配、交付观测、用量归属、费率和账单构成一条证据链。若直接从标记跳到账单，技术计数也许准确，经济含义却没有被证明。

混合架构是一份翻译责任

RFC 2998 描述了 IntServ 如何跨越 DiffServ 区域。RFC 2990 借此提出一种分工：边缘保留逐流精度，核心使用聚合状态。

应用可以通过 RSVP 请求服务。边界把流量轮廓映射到兼容的 DiffServ 聚合。核心避免逐流状态，路径的其他部分仍能保持应用可见的预留对话。

这要求边界成为两种事实模型之间的翻译者。一边是具体应用的请求，另一边是共享聚合的容量。若容量静态不变，可以预先配置；若容量动态变化，就需要实时信号。若 DiffServ 区域内发生准入失败，还必须通过 RSVP 把结果返回应用，让它降低要求或停止。

正向映射只是翻译的一半。把失败翻成可执行的回答，才使端到端精度没有在聚合处消失。

多样性不是沉默的许可证

RFC 2990 并不期待全网采用一种服务技术。它预见小范围部署、不同机制以及并不完美的桥接。发现能力、调用服务和测量结果因而同样重要。

结论也没有宣布赢家：需要扩展性的核心使用聚合，需要精确性的边缘在可承受范围内使用逐流元素。共同架构的任务，是定义这些机制如何稳定配合，而不是把所有运营商变成同一个控制系统。

以 Lu Heng 的“最小初始规范”视角看，共同层应只规定足以互操作的请求、容量、决定和结果接口，未来的资源政策仍由本地运营者承担。可本地决定并不等于可以不让依赖者知道其结果。

“现实层”则要求把证据放回正确位置：标记是请求，准入是决定，容量是条件，队列处理是动作，应用表现是结果，测量是证词，用量记录是归属，账单是商业主张。运行中的代码必须把它们连接起来。

网络可以拒绝。RFC 2990 发现的危险，是它可以拒绝而不必说“不”。

来源