要約

  • RFC 1986は多数のpacketをbufferとburstにまとめ、1回の高価な回線アクセスでまとまったデータを送り、受信側はbufferごとに欠落番号だけを返した。
  • CONTROL_OK、CONTROL_RESEND、連続CONTROL番号、NULL-ACKはいずれも限定された受領証であり、ファイル全体の完了、相手の身元、安全性、損失原因を単独では証明しない。
  • 1993年の結果は16 kbpsの点対点実験に限られる。RFCはパスワード検証がなく、セキュリティを見落としたとも明記した。

返信するたびに同期を買い直す

RFC 1986が扱った戦術衛星経路では、無線と暗号装置の同期に送信前およそ1.25秒を要し、衛星伝搬が往復に約500ミリ秒を加えた。半二重なので、データと確認は同時に流れない。受信側が答えるには方向を反転し、次のデータ方向でも再び同期が必要になる。

ETFTPは、この反転回数を節約した。ファイルをbufferへ読み込み、bufferをblockへ分け、各blockをDATA packetにし、複数packetをburstとして流す。bufferの最後はLDATAで示す。受信側は個々のpacketに応答せず、bufferが揃えばCONTROL_OK、穴があればbuffer番号と欠落packet番号を含むCONTROL_RESENDを返す。

ここで証拠の粒度が決まる。RESENDリストは、受信側がその時点で一つのbufferに見つけた穴である。OKはそのbufferを受け入れた記録にすぎない。転送全体の終端には、送信側のQUITと受信側のDONEが別に必要だった。

大きさを変える対象は一つではない

bufferを大きくすれば確認境界が減り、回線反転も減るが、メモリを消費する。burstを大きくすれば送信機を長くキーしたままにできるが、中継装置の待ち行列を圧迫し得る。packetを大きくすればオーバーヘッド比は下がる一方、高いBERでは破損時の損失が増える。

ETFTPはこれらを再調整した。自動適応が有効で、buffer内のblockの半数以上が再送対象になると、まずpacket sizeを半分にし、次にburstsizeを一つ減らし、最後にburstrateを観測されたtight timerへ近づける。再送なしで99%が届けばpacket sizeを上げられる。新しい値はCONTROL_OKで提案され、有効なら送信側がNULL-ACKで確認した。

Lu HengのMinimum Initial Specificationの観点では、buffer番号、欠落番号、合意値、切替境界が最小の共有面である。しかし受諾と実行は別だ。NULL-ACKは提案を受け入れた証拠であり、次のpacket列だけが同じ境界で新値を適用したことを示せる。

連続番号が覆うのは制御履歴の前半だけ

DATAとLDATAには、受信済みCONTROLメッセージの最高連続番号が入った。これは先頭からその番号までの制御メッセージが連続して見えたことを示す。後続メッセージ、buffer内データ、ディスク上のファイル、最終終了については何も保証しない。

CONTROL_RESENDも原因を説明しない。列挙されたpacketが受信状態にないことは示すが、送信されなかったとは限らない。誤り率、競合、キューあふれ、タイマー推定、実装遅延は似た穴を作る。radiodelayやbaudrateには利用者設定も入り、連続タイムアウトは待ち時間を5秒ずつ増やす。タイムアウトは期待時刻を外した記録であって、輻輳の証明ではない。

数表は一つの実験装置に属する

性能表は101,306バイトのファイル、暗号化された16 kbps経路、2秒のradiodelay、複数のbuffer・packet・burst設定から得られた。無線機は同軸ケーブルで接続され、10e-5 BERの「clean」リンクとされた。最大の表値は、131,072バイトbuffer、2,048バイトpacket、16 packet/burstで10,432 bpsだった。測定には接続、回復、切断も含まれた。

これは限定条件での実測であり、普及、マルチキャスト、共有回線の公平性、現代無線との優劣を示さない。RFC自身も、点対点で最大にしたp-persistenceは複数利用者には使わないとした。また調整可能なpacket rangeを16–1,448バイトと書く一方、表では2,048バイトを試している。この差は資料の境界として残すべきで、推測で整合させるべきではない。

セキュリティについてはさらに明快だ。ETFTPにはuser/password validationがなく、TFTPの問題を繰り返し、実験serverはroot所有かつsetuid rootを必要とし、設計時に安全性を見落としたとRFCは述べる。connection ID、port、checksum、sequenceは状態の照合に使えても、本人確認や認可にはならない。

RFC 1986が残した核心は、物理的な方向反転を明示的な制御予算へ変えた点にある。長い送信と短い欠落リストは効率を上げた。同時に、各受領証の意味を狭く読む必要も示した。buffer OKはbuffer OKであり、完了、原因、身元、安全性は別の証拠を要する。

情報源