III. 結論
プロトコルの拡張
現行のプロトコルでは十分に扱われていない問題がいくつかある。以下の項目について、より徹底的に検討し、場合によっては実験してみたいと考えている。
-
より高度なフロー制御
前述のとおり、フロー制御の他の方式は現在も検討中である。何らかの形でフロー制御を提供する必要があること以外、この問題の性質についてはまったく見当がついていない。現在の方式で十分だと判明するかもしれないし、はるかに複雑な方式が必要になるかもしれない。
-
エラーの検出と回復
ネットワークでの経験を積むにつれ、どのようなエラーが起こりうるか、そしておそらくより重要なこととして、それらのエラーにどう対処すべきかについて理解が深まるだろう。エラー制御への理解が進むにつれ、プロトコルも変わっていくと考えている。
-
起動と停止の手順
ネットワークに一時的にのみ参加するホスト、通常のネットワーク運用を停止しつつも特別な目的でネットワークにとどまるホスト、あるいはシステム障害から回復するホストの問題については、まだ十分に検討できていない。これらの問題は堅牢なネットワーク運用にとって決定的に重要であり、おそらく最優先の課題である。
-
問い合わせと応答
ホスト間の状態テストは有用な手段となるだろうが、何を提供するのが適切かはまだ明らかではない。
ネットワークへの参加
ホストは慎重にネットワークに参加することを勧める。まず、各ホストは自分自身への接続を十分に試験すべきである。次に、すでに稼働している他のホストと実験を計画する。最後に、他のホストの機能を利用し始めてよい。現時点では、どのホストが最初に他のホストを支援するのに最も適した立場にあるかは明らかではないが、UCLA がこの役割を担うよう努める。
プライベートなネットワーク
よく用いられる手法として、IMP を使って複数のローカルコンピュータを接続し、そのうち1台以上をネットワーク全体には公開しないというものがある。たとえば Harvard は PDP-1 と PDP-10 を IMP 経由で接続しており、Lincoln Laboratories（リンカーン研究所）は TSP を 360/67 および TX2 と IMP 経由で接続している。UCLA も同様に XDS 920 を Sigma-7 に接続している。いずれの場合も、小型機は当初ネットワークにサービスを提供しない。
こうした追加のホストへの不要なトラフィックはないはずだが、それらが最低限ネットワークプロトコルに準拠していることが望ましい。接続を自ら開始したり不正な制御コマンドを送出したりしない限り、ホストは CLS コマンドに対して確認の CLS コマンドを返し、ECO コマンドに対して ERP コマンドを返せば十分である。