要約

  • 1990年4月の RFC 1152 は、超高速ネットワークについての研究会を記録した。David Clark は、目的が毎秒1ギガビットだけなら既存プロトコルでも到達可能と見たが、遠距離、多数の利用者、新サービスを含む設計には別の要件整理が必要だと論じた。
  • Keith Lantz はマルチメディアの低遅延と同期を、Craig Partridge は遠隔呼び出しの待ちを議論した。Nectar の初期測定は、通信基板の速度がそのままホスト上のプログラムへ届くわけではないことを示した。

「速い」で済む仕事は少ない

この研究会を後援した Internet Research Steering Group は、IRTF の運営に関わる組織だ。Craig Partridge がまとめた報告は、各セッションの記録を参加者が確認している。一つの結論へ向かう議事録というより、速さを巡る要求を机に並べた記録である。

プロトコル実装のセッションで、David Clark は数字をいったん脇へ置いた。毎秒1ギガビットという速度だけを求めるなら、既存プロトコルにも可能性があるという。実際の提案は、長い距離、多くの利用者、帯域の予約といった新しいサービスを同時に扱おうとしていた。問題を詳しく定義して初めて、専用の処理装置を置くのか、既存の実装を磨くのか、機能の配置を変えるのかを比べられる。速度目標は設計の入口だった。

Keith Lantz が持ち込んだのは「持ち運べるオフィス」という利用者側の絵だ。機械を軽くする話ではない。自宅でも職場でも離れた場所でも、同じ人とサービスにアクセスできる状態を指した。デスクトップの会議には文字、図、音声、映像が同時に流れる。必要な帯域は流れごとに異なり、全般に低遅延が要る。一部は遅延の揺れも小さくなければならず、複数の流れは互いに同期する。映像が立派でも、口の動きと声が別々に到着したら会話はたちまちぎこちない。

Lantz は、混雑や低速の区間に合わせて品質を変えられる仕組みも求めた。映像の解像度を調整する余地は、利用者が会議を続けられるかに関わる。経路の一部だけが高速でも、作業全体の条件はその先まで続く。

計算機が速くなるほど、返事待ちが高くつく

分散システムのセッションで Partridge が注目したのは遠隔手続き呼び出しだった。計算機が速くなる一方、離れた相手への往復には距離と光速が残る。返事を待つ間に実行できたはずの命令は増えていく。独立した呼び出しを並行させても、前の答えを受けて次を決める作業は順番待ちのままだ。

キャッシュを増やせば問い合わせを減らせる。ただし複数のキャッシュを一致させる通信が必要になる。通常の呼び出しを避けるために同期の呼び出しを増やす、という冗談めいた行き止まりも報告にある。Partridge は同じ相手への仕事を大きな操作にまとめる案を示した。別の発言者は先読みや非同期のプログラミングを挙げた。方向は分かれたが、問題は回線の外へ広がっていた。

ホストの入口にも列ができた。Carnegie Mellon の Nectar について報告された初期結果では、通信基板上のプロセス同士は 70 Mbps で通信できた一方、ホスト上のプロセスは VME インターフェースに制約され約 25 Mbps だった。これはその試作機での観察だ。Jeff Mogul はさらに、パケットを CPU のキャッシュに入れ、利用者プロセスへ到着を知らせる費用に目を向けた。ネットワークを抜けたデータにも、まだ家の中の廊下が残っていた。

RFC 1152 は万能の新プロトコルを発表する文書ではない。アプリが仕事を終えるまでの時間を、往復、同期、遅い区間、ホスト内部の受け渡しに分解した記録だ。ギガビットという数字が輝くほど、その数字が測っていない待ち時間が目立ち始めた。