引言

BBN 把他们对 NWG/RFC 33 的评论交给了我们, 但不愿发表, 怕让我们难堪。尽管难堪, 我们还是觉得这些评论特别有用, 决定与朋友们分享。作者是 Bill Crowther。

我发现 Host Protocol Paper 里有两处实质性错误, 除此之外这是一篇出色的论文。两处都涉及对 IMP 作为通信设备的性质的理解, 尤其是对 IMP 必须做的缓冲这一性质的理解。作者把网络看成这样一种设备: 把一条报文推进去, 它在里面转上一阵, 在缓冲区里等待相当长的时间, 然后在目的地冒出来。事实上, 更好的模型是报文在插入之后的一瞬间就冒出来了。虽说确实存在时延, 但这时延多半是电话线硬件造成的。IMP 的缓冲极少, 只用于差错控制和瞬时的流量高峰。

由于我们无法强迫主机接收报文, 我们建立了一套精细的 RFNM 机制, 在主机接收之前暂停新的输入。这套机制是解决一个极为困难的通信问题的不完美尝试。我们的愿望是把流量调节成: 主机从 IMP 取走报文的同时, 下一条报文正好到达电话线上, 这样完全不需要缓冲。

事实上我们做不到这一点, 因此加入了缓冲以应对流量高峰。这些缓冲区若不是空的, 就无法发挥其预期作用。只有空的缓冲区才能用来吸收流量高峰。

那两处具体错误出现在第 5 页和第 23 页。在第 5 页, 作者说 "这一目的隐含的假设是, 用户不会用多条链路来获得宽频带。" 事实上, 链路的主要目的之一正是获得更宽的频带。

我们希望尽可能放宽容许的带宽。我们的麻烦不出在宽频带, 而出在输入与输出的不平衡。作者正确地注意到多条链路会破坏 RFNM 机制, 使我们更难办, 但却把问题的性质说错了。

又在第 5 页: "还有一个更基本的假设, 当然, 网络的负载来自某些用户发送报文序列, 而不是许多用户碰巧各发一条报文。" 当单条报文用户的报文彼此之间随机无关时, 我们应对得很好。统计规律对我们有利, 而且我们为 (罕见的) 巧合准备了专门的处理流程。我们的问题出在非随机的巧合上, 我们已经采取了特别的防范措施来对付发送突发 (序列) 报文的用户。我们假定用户形形色色, 并据此保护自己。

在第 23 页和第 24 页有 4 句关键的话, 暗示系统设计本可以改进, 让主机指定它愿意接收若干等待输入中的哪一个。我们承认主机需要为它的用户缓冲这些报文, 但我们强烈不同意 IMP 有能力做这种缓冲。

如果工作在理想模式下, 我们在任何时刻最多只会有一条给主机的报文。如果多于一条, 我们就迫切需要主机接收这些报文, 因为此时我们应对流量高峰的能力已经低于标准。目前我们允许 IMP 为其主机保留三条完整长度的报文, 超过之后就开始让流量在网络中回积。"三条" 不足以既帮助主机、又为流量高峰留出储备。

但既然需要缓冲, 为什么不弄到更多的内存, 在 IMP 里做呢? 因为缓冲是主机的功能, 在每个分时系统里都不同, 在繁忙的串行信道上很难控制, 在某些地方可能根本不需要, 而且放在主机操作系统能高效共享额外内存的地方去做更合适。

我再重复一遍: IMP 的缓冲区必须是空的, 否则它们就没有发挥自己的通信作用。

有问题的句子如下:

     Paragraph 2 sentence 3
           "   3 all
           "   4 sentences 1 and 2 (80ms is hardware screw adjustable)
           "   4 sentence last

---

注: 这份 RFC 由 Jeff & Christy McClellan 2/98 转成机器可读形式, 以便录入在线 RFC 档案馆。