要約

  • 1994年11月の実験的なRFC 1693は、順序と信頼性を部分的に指定する運送サービスを検討した。四件のデータベース検索を例に、条件次第で許される結果の並びを一、二、四、24通りと数えた。
  • 文頭のIESG注記は、提案されたTCPの変更を実装するよう勧めていない。一方で、順番が乱れたデータや欠けたデータを扱う分析はTCPの外でも有用だと認めた。

番号を呼ぶ係が、到着済みの客を止める

TCPは信頼できる順序付きのバイト列をアプリケーションへ渡す。RFC 793の約束に従えば、手前が抜けている間、その後ろは受信側に到着していても上には出せない。ひとつのファイルを組み立てるなら頼もしい。互いに入れ替えてよい検索結果を読むときには、受付が書類を持ったまま「前の番号の方がまだです」と言うようなものだ。

T. Connolly、P. Amer、P. ConradはRFC 1693で四件の架空のレコードを並べた。営業担当者の異なる名前で並べると、正しい順は一つ。同じ都市のレコードが二件ある所在地順なら二つ。説明文が二組でそれぞれ一致する場合は四つ。ORDER BYがなければ4!、24通りすべてが条件を満たす。これは作例の順列を数えた数字で、通信の速度を計測した数字ではない。検索が指定する先後関係の強さが変わっている。

その関係を「部分順序」として運送サービスに示せないか。あるレコードには先行する相手がいるが、独立したレコードは先後を問わない。送受信の両者が許容する関係を伝え合い、受信側が到着のたびに先行条件を満たしたか判断する。列を完全になくす話ではなく、必要な列だけ残す話である。

信頼性は別の軸になる。データベースは全件の到着を求めても、その順番には幅があるかもしれない。映像では、あるチャネルの順序が大切でも、すでに古くなったフレームは失ってよい場合がある。文書は動画、二つの音声チャネル、テキスト、手話の映像、ウィンドウの再描画を例に挙げる。何が後続の材料となり、何が古くなるかは用途によって違う。

著者らはTCPを変更して部分順序の接続を設ける案を検討し、普通の相手との接続開始も設計課題に置いた。待ち行列の奥にある独立したデータを早く渡せる可能性を論じている。ただし四件の組合せから性能改善値は計算できない。提案はTCPの標準的な機能として採用されたという記録でもない。

その線引きは文頭にある。IESGはTransport分野の責任者と担当者らがTCP改変の実装を推奨しないと明記し、乱れや欠落を含むデータの分析にはTCP以外で価値があると評価した。実験的RFCの面白さは、魅力的な問題設定と実装への慎重な判断が同じ紙面に載っていることだ。二番目の結果は届いている。それを待たせる理由は検索条件にあるのか、運送の約束にあるのか。