メインコンテンツまでスキップ

I. はじめに

NEW/RFC #53 で予告したとおり、ここに本プロトコルを提出し、批判やコメントなどを募る。我々はこのプロトコルを最初の公式プロトコルとすることを意図しており、したがって重大な異論が出なければ何よりである。とはいえ、1970年7月13日まではあらゆる批判を受け付ける。批判は NWG/RFC として公開するか、筆頭著者宛てに送ってほしい。

7月13日以降、このプロトコル（またはわずかな変更を加えたもの）を採用するか、あるいは再設計して再び批判を仰ぐかを決定する。

プロトコルのみを扱う​

これまでのプロトコルに関する議論では、ネットワーク全体にわたる仕様とローカルな方策とが明確に区別されてこなかった。ここで明言しておくと、ネットワーク全体に関わる事項はメッセージ形式とメッセージ内容に関する制約だけである。ネットワーク制御プログラム（NCP）の実装とシステムコールの選択は、純粋にローカルな問題である。

本文書はネットワーク全体に関わる事項のみを扱うよう範囲を限定しており、システムコールや NCP のテーブルは扱わない。とはいえ、NCP と一連のシステムコールがなければプロトコルは役に立たないため、我々は典型となる NCP の導出に多大な労力を注いだ。その成果は NWG/RFC #55 で報告しており、読者はここで示すプロトコルを、同文書で示したその利用方法に関する提案と照らし合わせてほしい。ただし、NWG/RFC #55 の内容はあくまで示唆にすぎず、実装を選ぶ前に競合する提案も検討すべきであることを忘れてはならない。

フロー制御​

今回のプロトコルを設計する過程で、フロー制御が想像していたよりも複雑であることがわかってきた。現在では、ネットワークのトラフィックが増えるにつれ、フロー制御の技法が活発に議論される分野の一つになると考えている。そこで、Richard Kaline と Anatol Holt から触発されたいくつかのアイデアを取り入れ、フロー制御の手順を修正した（我々の方式の欠陥は、言うまでもなく我々だけの責任である）。この新しい手順には明白な限界があるものの、よりすっきりと実装でき、ネットワークの初期利用を支えられるという利点がある。これが、すでに合意済みのプロトコルからの唯一の実質的な変更点である。

新しいフロー制御の仕組みでは、受信ホストが接続ごとにバッファ領域を割り当て、利用可能な領域がビット単位でどれだけあるかを送信ホストに通知する必要がある。送信ホストは利用可能な領域の量を把握し、受信ホストが受け入れられると判断した量を超えるテキストを決して送信しない。

この仕組みを実装するため、送信ホストは接続ごとにカウンタを保持する。カウンタは0に初期化され、受信ホストから送られる制御コマンドによって増加し、その接続で送信されたメッセージのテキスト長だけ減少する。送信ホストはカウンタの値より長いテキストを送信することを禁じられているため、カウンタが0を下回ることはない。

理想的には、受信ホストは接続が確立されるとすぐにいくらかのバッファ領域を割り当てる。割り当てる量は、受信側が受け入れを保証できる量を決して超えてはならない。テキストが到着すると、割り当てられたバッファ領域を占有する。受信プロセスが待機中のテキストをバッファから取り込むと、NCP はその接続に対する新たな領域の割り当てを返送する。NCP は、追加のバッファ領域が適切だと判断すれば、受信プロセスが待機中のテキストを取り込んでいなくても領域を割り当ててよい。同様に、受信プロセスが領域を空けた後でも、NCP がバッファ領域を再割り当てしないと決めることもある。

領域を割り当てる制御コマンドは次のとおりである

ALL <link> <space>

このコマンドは受信ホストから送信ホストへのみ送られる。

このフロー制御の定式化により、NWG/RFC #36 の RSM コマンドと SPD コマンド、および BBN Report 1822 の現行版にあるホストから IMP へのメッセージタイプ 10 と、IMP からホストへのメッセージタイプ 10 および 11 は不要になる。

この方式の明らかな限界は、受信ホストが平均的なバッファ使用量をあてにできず、常に最悪の場合を想定しなければならない点である。開いている接続がわずかであれば、大きな節約になることはまずない。しかし接続が多くなると、平均的なバッファ使用量は割り当てたバッファ領域よりもはるかに少なくなる。我々は適応的な割り当てを含むこのプロトコルの拡張を検討しており、それは実現可能だと考えている。当面はこの限定的な方式が最善と思われ、より高度な方式については今後議論したい。特殊な RFNM などを用いる旧方式も、引き続き議論の対象である。

質問に答え、詳細を議論するため、ネットワーク会合を2回開催する。1回目は6月29日に Harvard（ハーバード大学）で、2回目は7月1日に UCLA（カリフォルニア大学ロサンゼルス校）で行う。会合への参加は各ホストにつきプログラマー1名のみとし、各ホストはいずれか一方の会合にのみ代表を出すようお願いしたい。我々のうち2名（J.N. と S.C.）は両方の会合に出席する。

Harvard の会合への参加予約は、次の連絡先まで

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

UCLA の会合への参加予約は、Mrs. Benita Kirstel (213) 825-2368 まで。