I. 引言

如 NWG/RFC #53 所预告, 我们在此提交本协议, 征求批评与意见等。我们希望本协议成为最初的官方协议, 因此, 如果没有人提出严重异议, 我们将最为高兴。尽管如此, 在 1970 年 7 月 13 日之前, 我们欢迎各种形式的批评, 这些批评应以 NWG/RFC 的形式发表, 或直接寄给第一作者。

7 月 13 日之后, 将决定是采纳本协议（或其细微变体）, 还是重新设计后再次提交以征求批评。

仅限协议本身

在此前关于协议的讨论中, 全网性规范与本地策略之间一直没有明确区分。我们在此声明: 全网性问题仅限于消息格式以及对消息内容的限制。网络控制程序（NCP）的实现和系统调用的选择严格属于本地问题。

本文档仅限于讨论全网性问题, 因此不涉及系统调用或 NCP 表；然而, 没有 NCP 和一组系统调用, 协议就毫无用处, 所以我们投入了大量精力来推导一个原型 NCP。这项工作记载于 NWG/RFC #55, 读者应将此处给出的协议与该文中关于如何使用它的建议对照阅读。但需要记住的是, NWG/RFC #55 的内容仅供参考, 在选定实现方案之前, 应当考察其他竞争性提案。

流量控制

在设计当前协议的过程中, 我们逐渐认识到流量控制比我们想象的更为复杂。我们现在认为, 随着网络流量的增长, 流量控制技术将成为人们积极关注的领域之一。因此, 我们从 Richard Kaline 和 Anatol Holt 启发的一些想法中获益, 并修改了流量控制流程。（我们方案中的缺陷当然完全归咎于我们自己。）这一新流程有明显的局限, 但其优点是实现起来更为简洁, 并且能够支持网络的初期使用。这是相对于已达成一致的协议所做的唯一实质性改动。

新的流量控制机制要求接收主机为每个连接分配缓冲区空间, 并通知发送主机可用空间有多少位。发送主机跟踪可用空间的大小, 发送的文本绝不超过它认为接收主机能够接受的量。

为实现这一机制, 发送主机为每个连接维护一个计数器。计数器初始化为零, 随接收主机发来的控制命令而增加, 并在通过该连接发送任何消息时按其文本长度递减。发送主机不得发送长于计数器值的文本, 因此计数器永远不会低于零。

理想情况下, 接收主机会在连接一建立时就分配一些缓冲区空间。分配的数量绝不能超过接收方能够保证接受的量。文本到达后, 便占用已分配的缓冲区空间。当接收进程从缓冲区取走等待中的文本时, NCP 会为该连接发回新的空间分配。即使接收进程尚未取走等待中的文本, 只要 NCP 认为额外的缓冲区空间是合适的, 也可以分配空间。同样, 在接收进程腾出缓冲区空间之后, NCP 也可以决定不再重新分配。

用于分配空间的控制命令是

ALL <link> <space>

该命令仅由接收主机发往发送主机。

这种流量控制方案使 NWG/RFC #36 中的 RSM 和 SPD 命令, 以及 BBN Report 1822 当前修订版中的主机至 IMP 消息类型 10 和 IMP 至主机消息类型 10 与 11 不再必要。

该方案的明显局限在于, 接收主机不能依赖平均缓冲区使用量——总是按最坏情况考虑。如果只打开了少数几个连接, 节省的空间不大可能很多。但当连接数较多时, 平均缓冲区使用量将远小于已分配的缓冲区空间。我们已研究过包含自适应分配的协议扩展, 并认为这是可行的。就目前而言, 这一有限的方案似乎最好, 我们期待日后讨论更复杂的方案。旧的特殊 RFNM 等方案也仍在讨论之中。

为了解答问题并讨论细节, 我们将召开两次网络会议。第一次于 6 月 29 日在 Harvard（哈佛大学）举行, 第二次于 7 月 1 日在 UCLA（加州大学洛杉矶分校）举行。我们要求每台主机仅派一名程序员出席会议, 且每台主机只在其中一次会议上派代表。我们中的两人（J.N. 和 S.C.）将出席这两次会议。

如需预约参加 Harvard 会议, 请联系

   Mrs. Margi Robison
   (617) 495-3989
      or 495-3991

如需预约参加 UCLA 会议, 请联系 Mrs. Benita Kirstel, 电话 (213) 825-2368。