摘要

  • RFC 1008 讨论了 ISO 传输协议中可选的流控确认机制。重新打开关闭窗口的 AK 消息若可能丢失，接收端可短间隔重发，并请求发送端以带 FCC 参数的 AK 回答。
  • Wayne McCoy 在 1987 年 6 月明确写道，当时没有可报告的 FCC 使用经验来证明收益。若等不到回答，快速重发到上限即停止，普通窗口定时器重新接管。

两端的处境都不复杂。接收端一度没有空间，收紧信用额度，发送端按规矩停下。后来缓冲区腾出来，接收端发出一条 AK，宣布可以再送数据。偏偏这条 AK 消失了。发送端记得的仍是“停”；接收端掌握的却是“可以走”。两个状态各自正确，合在一起就把连接冻住。空闲容量摆在眼前，许可证不在发送端手里。

Wayne McCoy 在 1987 年 6 月的 RFC 1008 中把这种尴尬拆给实现者看。这是一份征求实现意见的 ISO 传输协议指南，谈的是缓冲区、窗口和定时器如何配合。AK 消息除了确认收到数据，还可能携带关键的流控信息。尤其是把已经关闭的窗口重新打开，或在某些信用缩减之后调整状态的 AK，小小一条消息决定对方能否重新开工。

AK 丢掉，接收端腾出的空间并不会跟着丢。丢的是发送端对空间的认识。普通窗口定时器最终可能让两端重新同步，但 McCoy 说它通常相对较长。等它响，链路就可能在有空间可用时安静地耗时间。FCC，即流控确认，试图缩短这段空等：接收端短间隔重复发送关键 AK，同时请求对方确认流控状态；发送端若回一条带 FCC 参数的 AK，接收端便停止快速重发。

这套做法带刹车。等不到 FCC 回答，重发到预设上限就停，随后由普通窗口定时器继续处理。FCC 本身是可选项，数据发送端也没有必须回答的义务。McCoy 建议快速重发期间复用窗口定时器，因为原来的窗口计时在这时被停用；形式化描述为了清楚，才把两只时钟分开写。他还在定时器章节把快速间隔放在大致等于双向网络延迟 Erl + Elr 的位置。重寄消息需要有节奏，不能靠敲桌子解决。

要不要增加这套手续，指南没有替实现者拍板。它列出五个取舍点：信用缩减发生多频繁，TPDU 多容易丢，窗口定时器要等多久，窗口有多大，现有确认策略是什么。多发控制消息要花处理与带宽；长时间干等也有成本。McCoy 明说没有 FCC 与快速 AK 重发的使用经验，因而无法拿实测收益为它背书。

流控常被画成红绿灯：红灯停，绿灯走。这里灯已变绿，司机却没看到。接收端可以再亮一次灯，并听对方回一句“我看见了”。这不是给每个字节都发感谢信，而是给改变发送权的那条消息找一条确认路径。1987 年的这段协议讨论提醒人们：缓冲区有空间，并不等于发送端知道自己有权使用它。