摘要

  • Padhye、Firoiu、Towsley 与 Kurose 的模型预测大批量、持续有数据可发的 TCP Reno 流在稳态下的发送吞吐量。
  • 论文所说的吞吐量统计单位时间内发出的分组，不论分组最终命运；它不是有效载荷交付，更不是链路容量、可用带宽或配额。
  • 可信的结果必须连同观测窗口、丢包事件分组、RTT、超时、接收窗口、确认策略、TCP 变体、验证范围和误差一起保存。

指针指向的究竟是什么

假设屏幕显示“预计 80 Mbps”。指针的位置很清楚，单位也与线路速率相同。接下来，名称开始膨胀：预计吞吐量被称为可用带宽，可用带宽又被称为容量，最后成为发送方“本应获得”的份额。

方程没有完成这些推导。

SIGCOMM 1998 论文 Modeling TCP Throughput: A Simple Model and its Empirical Validation 研究的是一个特定控制过程。发送方采用 TCP Reno，处在拥塞避免阶段，而且数据源饱和——应用永远有下一批字节。拥塞窗口随确认增长，遇到丢包指示后缩小；快速重传和重传超时产生不同的恢复路径。模型回答的是：在给定观测与假设下，这个发送方长期会发出多少分组。

链路容量是资源属性，需要独立测量方法。可用带宽还受同时使用者和时间窗口影响。有效吞吐量取决于接收方真正得到多少新的有用数据。配额则来自运营者、合同或制度。它们可能彼此相关，却不能因为单位相同就共享一张凭证。

“总有数据”是一条关键假设

饱和源让研究者能够把应用停顿从运输控制里剥离。若真实程序正等待磁盘、用户、数据库或编码器，即便路径很空，它也不会达到模型给出的发送率。

把这种差距解释为“网络少给了容量”，等于拿无限数据源的反事实要求现实应用。仪表并没有测量需求，只计算了在需求不枯竭时 Reno 的行为。

论文还明确区分吞吐量和 goodput。它统计发出的分组，不问分组随后是否丢失，也不扣除重传。同一批有效载荷被重发，会再次增加发送吞吐量，却不会给应用增加一份新数据。

这条定义很窄，也很有用。问题出在后来系统只保留数值，丢掉“发送”“饱和”“Reno”和“稳态”四个限定词。

丢包率之前先有丢包事件

Reno 对丢包指示作出窗口反应。一轮内丢掉多个分组，可能只触发一次拥塞控制事件。因此，模型输入并非没有上下文的“丢了百分之几”。

论文假设轮次之间的丢包相互独立，而一轮之内相关，并把这种结构与 drop-tail 队列联系起来。分组如何合并为事件，直接改变输入值。

同一条抓包记录可以产生多种“丢包率”。一套算法逐个计算缺失序号；另一套按一个 RTT 聚合；接收方报告还可能以不同方式处理乱序。若不保留时钟、窗口和聚合规则，两个小数没有可比性。

因此，审计材料至少应包含原始丢包或 ECN 标记、乱序处理、事件定义、观测区间和观测位置。只保存最终百分比，相当于保存答案却销毁题目。

超时让模型没有假装整洁

只考虑三个重复确认后的快速重传，方程会更漂亮。但论文的轨迹不支持这种简化：几乎所有轨迹中，重传超时事件都比快速重传事件更多。

完整模型把两种恢复路径都纳入。熟知的近似式继续反映丢包事件率、RTT、重传超时、分组大小、每次确认覆盖的分组数以及最大接收窗口。它之所以能压缩，是因为详细模型先说明了被压缩的机制。

仍有假设存在：一轮等于一个 RTT，当前窗口能在这一轮内发完；稳态分析里慢启动可以忽略；快速恢复的一些细节未被刻画。

所以，部署者必须记录实际运输实现与确认策略。一个写着“TCP”的字段不足以说明 Reno、SACK、延迟确认和超时计算都满足同一关系。模型版本本身也是证据。

三十七条连接的边界

验证使用了美国和欧洲 18 台主机之间的 37 条 TCP 连接。24 条轨迹各持续一小时，另外 13 组数据由连续的 100 秒连接组成。流量都是单向、大批量、无限数据源。

多数情况下，该模型比只考虑重复确认的版本更好地解释观测，近似式也能很好地追随完整模型。ACM SIGCOMM 的官方列表把这篇论文列为 2008 年 Test of Time Award 获奖作品。

但一条调制解调器路径暴露了不匹配：专用缓冲区使窗口与 RTT 发生模型未能正确表达的相关。Linux、Irix 与 SunOS 的 TCP 实现也有差异，论文没有把每套实现分别调参。

这不是应从历史里删掉的瑕疵，而是仪器刻度的边缘。作者还把快速恢复、窗口随机过程、丢包分布、慢速链路和实现细节列为后续问题。经验验证的价值，恰恰包括告诉使用者何时应停止套公式。

容量并未藏在时延里

拥塞、竞争流和物理速率当然会影响排队、RTT 与丢包。但从这些症状得出一个唯一容量，需要更多可识别条件。

RTT 可能因传播、路由、排队、调度或测量方法变化。丢包可能来自拥塞、误码或策略。接收窗口可能限制发送者，而不改变链路本身。不同原因组合可以产生相似输入。

PFTK 模型在输入已知时预测控制器行为；它没有反向求解整条网络并宣布某个物理上限。把输出改名为容量，是额外添加了一项没有被估计的结论。

“公平份额”也一样。Reno 会对竞争作出响应，但一个稳定速率不是资源分配文件。谁有权使用多少，必须由控制资源的角色留下凭据。

TFRC 把估计值放进另一条回路

Sally Floyd、Mark Handley、J. Padhye 与 J. Widmer 署名的 RFC 5348 规定了 TFRC。接收方测量丢包事件率，发送方测量 RTT，再用略微简化的 Reno 方程计算发送率。

协议没有把计算结果当作链路宣告。它还依据接收速率设置上限，并持续调整。RFC 所说的 TCP 友好，是在相同条件下通常落在合规 TCP 速率的两倍范围内，而不是逐点相等或准确性担保。

TFRC 用更平滑的速率换取对可用带宽变化较慢的响应，而且它不是可靠传输协议。遵守方程不能证明分组已经交付。

这种后来应用说明了模型应如何工作：在定义明确的控制回路中承担一个受限任务。它约束发送者，却没有获得测量容量、证明收货或授予资源的权限。

一个以四个姓氏构成的模型

Microsoft Research 页面把第一作者写作 “Jitu Padhye”，并列出 Firoiu、Towsley 与 Kurose；原论文使用 Jitendra Padhye。微软 2010 年的一篇官方文章在合照中将他标为从左第三人，并描述当时的职位。它们提供身份与有日期的背景，不足以推断今天的职务。

本文以 Padhye 为人物中心，但常用缩写 PFTK 保留四位作者的首字母是有意义的。建模、推导、实验验证与公开限制属于共同成果，不应被改写成单人发明。

准确署名也服务于技术问责。知道模型来自哪篇论文，才能找回版本、假设、样本和异常。若只称“TCP 公式”，它很容易被移植到并不相同的运输协议或指标上。

让预测值携带自己的账本

每个结果都应能回答：原始丢包标记在哪里？如何组成事件？观测了多久？RTT 是分布还是单值？超时如何计算？分组、确认与接收窗口是什么？发送方是否真的饱和？使用了哪一个公式和上限？

还要把预测发送率、实际发出字节、重传量和新交付有效载荷分成不同序列。误差不是应自动抹平的噪声；持续误差说明观测、运输实现或工作状态发生了变化。

Heng Lu 的“运行代码优先”可作为当代分析视角：配置中的模型不能压过实际运输行为，而实际观测也只能在自身位置和方法范围内作证。这是后来的编辑比较，不是说 1998 年或 2008 年作者受其影响。

最稳妥的做法不是放弃方程，而是保留它完整的名词：在有据可查的条件下，预测特定运输的长期发送吞吐量。容量另测，交付另证，权利另记。边界越清楚，模型越能长期使用。

来源