摘要

  • XCP 把“希望增加或减少多少吞吐量”拆到每个包的拥塞首部中。沿途路由器只能保留或压低这个数，接收端看到的因而是当次控制回路中最紧瓶颈留下的分配。
  • 返回值会改变发送端下一步允许使用的速率，却不预留未来容量，也不证明实际交付了多少流量。请求、分配与结果之间的边界，正是 Dina Katabi 这项工作的长久价值。

一条流当前以某个速率发送，希望下一轮再增加一截。XCP 发送端先估算一个往返时间内会发出多少包，再把所需变化摊进这些包。每枚包携带的不是总带宽，而是它所承担的一小份速率调整请求。

包到达路由器时，路由器依据本地出口的负载和队列算出自己能接受的调整。若包里的请求更保守，它不必加码；若请求过大，它就把字段改成较小的数。后面的路由器无法恢复已被删去的愿望。到了接收端，字段已经浓缩成整条参与路径上最严格的判断。

这套机制来自 Dina Katabi、Mark Handley 与 Charlie Rohrs 在 2002 年 SIGCOMM 发表的 XCP 论文。文章讨论的是高带宽、长时延路径上的拥塞控制：链路越快，一个往返时间内可在途的数据越多，传统依靠窗口缓慢增长、再从丢包推断拥塞的办法就越容易出现长队列、震荡或利用不足。

Katabi 是本文的人物主角，但 XCP 不是单人发明叙事。原始论文有三位作者；后来最完整的互联网草案由 Aaron Falk、Yuri Pryadkin 与 Katabi 共同署名，并吸收了 USC/ISI 的实现经验。准确分配署名，与准确解释反馈字段，是同一种证据纪律。

一枚包把愿望带过瓶颈

2007 年的 XCP 草案列出四个关键量。发送端提供 RTT 估计和表示包间隔的 X，在 Delta_Throughput 中写入希望改变的吞吐量；接收端则用 Reverse_Feedback 把到达的结果带回去。这个变化量有正有负，以每秒字节数表达。

正数并不是“这条流现在拥有这么多带宽”。它的语法是“相对于当前速率，可以再增加这么多”。负数也不是一次丢包报告，而是参与的某个队列要求发送端减速。发送端拿到返回值后，可以调整拥塞窗口或其他发送上限。

这里有三份容易被混为一谈的事实。第一份是应用或发送端的需求；第二份是路径当下允许的变化；第三份是调整之后真正实现的吞吐量。应用可能没有足够数据用完窗口，路由可能变化，反向反馈可能延迟，新的竞争流也会进入。XCP 首部只直接承载中间那一份。

草案把接收端拿到的数称为瓶颈分配，是因为每台 XCP 路由器都会将请求与自己的逐包计算比较，过大的部分被删去。若前一跳已经写得更小，后一跳通常只更新自己的反馈池而不把字段抬高。最小值因而穿过整条正向路径。

接收端在回包中复制或汇总这个数，发送端一个往返时间后得知结果。它像一次短效的控制决定：有效范围是特定路径、特定状态与下一轮动作。它没有发行者、期限和违约条件等长期凭证要素，也不会为未来包保留队列位置。

效率与公平不是同一道题

XCP 更有影响力的设计，不只是让路由器写一个多比特反馈。它把效率控制器与公平控制器分开。前者观察到达速率和持续队列，决定整个出口链路应释放多少正反馈或负反馈，目标是让链路有用而又不靠长队列维持满载。

后者负责把这份总量分给不同流。原论文选择的办法让正反馈推动流量向公平份额靠拢，让负反馈与已经使用的带宽相关。效率控制器回答“总共该加还是该减”，公平控制器回答“这些变化应落到谁身上”。

这种分工使控制理论分析更清楚，也允许公平政策在不重写全部稳定性逻辑的情况下改变。但它同时提醒分析者：一个返回数字背后至少有两层判断。若链路采用加权份额，同样的队列状态会产生不同的逐流结果；若效率参数改变，同一种公平规则也会收到不同的总反馈池。

所以，观测一个 Delta_Throughput 不能只记大小。应同时知道是哪一个出口实例、何种控制间隔、怎样的平均 RTT、什么公平政策，以及此前是否已有别的路由器写下更低值。最终字段保留了结论，却擦除了沿途被覆盖的过程。

没有逐流表，不等于没有状态

XCP 的路由器不必为每条流维护拥塞表。流自身的 RTT 与速率线索随包抵达，路由器按照逐包规则分摊总体反馈。这避免了核心设备中随短流频繁建立和销毁的逐流记录，也是后来研究重视它的原因之一。

然而，“不保存逐流状态”很容易被误写成“路由器无状态”。XCP 仍然测量到达负载和队列，估计经过出口的平均 RTT，按控制间隔运行两台控制器，并维护尚未分配完的正负反馈池。状态没有消失，而是从以流为键的长期条目转成出口级聚合状态，再与包里自报的信息组合。

这项交换把信任放到新的位置。发送端自报的 RTT、包间隔或吞吐线索可能不准确，发送端也可能不执行返回的减速命令。原始设计假设大多数端点合作，并考虑在边缘监测。Katabi 后续关于恶意流的研究把说谎者与不服从者分开，展示虚报吞吐、虚报 RTT 和忽略反馈会以不同方式损害公平或效率。

这不是一句“协议安全”或“协议不安全”可以概括的结论。它说明控制器的输入有来源。来自受益方的声明应被视为声明，来自路由器的分配应被视为算法输出，线上实测速率才是结果证据。把三者存进同一字段，会让任何异常解释都失去抓手。

固定点数值也留下实际边界。字段可表达的 RTT 和速率变化有限，小于量化步长的调整会变成零，逐包舍入还可能在一个控制间隔内累积。草案没有把这些问题包装成已解决事实，而是明确留给实验检验。

获奖论文不是部署回执

原论文以控制模型和大量包级仿真论证 XCP，在所测的高带宽时延积环境中展示较高利用率、较小队列和稳定收敛。后来出现实现、教程和互联网草案。ACM SIGCOMM 又以 Test of Time 奖肯定其对新一代显式拥塞控制的影响。

这些记录证明思想重要，却不能证明 XCP 已成为公共互联网的通用协议。最后一版草案直接写明，它尚未准备好大规模部署，文件的用途是支持进一步实验。端系统与路由器都要改变；可能成为瓶颈的队列都参与，纯粹模型才成立；非 XCP 队列和其他拥塞控制机制如何共存，仍是难题。

部署边界尤其重要，因为反馈字段看上去非常确定。数字精确到固定点格式，并不等于路径具备同等精确的实施条件。某一台路由器不理解首部、隧道隐藏拥塞点、IPsec 认证范围发生冲突，或端点不诚实，都会改变这条证据链的含义。

更稳妥的历史说法是：XCP 证明了一种架构可能性。网络可以显式告诉发送者“改变多少”，可以把链路利用与份额分配拆开，也可以让包携带逐流线索而不要求核心建逐流表。这些思想可以影响后续方案，即使原格式没有成为普遍部署的标准。

读数之前先找动词

XCP 的字段值得今天重读，因为它迫使人先问一个数在做什么。它起初是请求，经过瓶颈后成为分配，返回发送端时变成控制输入。它从未自动变成容量、实绩或合同。

若只保存最终值，就看不见谁改过它，也不知道被删去的请求是多少。一次可复核实验还应保存原始愿望、各可观测跳点的改写、路由与出口身份、控制器配置、回传值以及实际速率。这样才能区分低需求、严格瓶颈、路径混合、量化误差与端点作弊。

Katabi 与合作者留下的并非一张带宽支票，而是一条短促、可执行的反馈链。它的精确之处正在于没有许诺更多。网络证据的通则也由此显现：解释字段之前，先找出谁能改它、它在多长时间内有效，以及它最终授权的是哪一个动作。

来源