Summary

  • RFC 970は、無限の保存容量、先入れ先出し、有限のパケット寿命、少なくとも二つの交換機という条件で、持続的な過負荷が全パケットの破棄につながると論じた。
  • 実験ではEthernetから9600ボーの回線へ向かう経路にIPデータグラムが最大916個たまった。ただしTCPが先にタイムアウトし、理論上の全破棄状態は直接観測されなかった。

倉庫を無限に広げても、搬出口の速度は上がらない。John Nagleが1985年12月の原文で描いた交換機では、入ってくるパケットが出ていくより多い。待つ間に寿命が減り、最初の交換機を出る頃には残り一単位。次の交換機でそれがゼロになり、捨てられる。容量不足の警報は鳴らない。それでも荷物は届かない。

当時の議論はバッファの枯渇に偏りがちだった。Nagleはそこを無限にして、先入れ先出しの列、有限の寿命、二つ以上の交換機、継続的な過負荷だけを残した。全破棄はこの組み合わせから導く結論であり、1985年のインターネット全体で起きた障害の報告ではない。記憶装置を増やしても、古くなったパケットに時間を返すことはできない。

数字も例として限定されている。56キロビット毎秒の回線が四本、寿命の上限が15秒なら、必要なバッファは最大420キロバイトという計算だ。この構成では容量不足による破棄を防げる。しかし次の交換機まで生き残る保証にはならない。原文は当時のTTLを残り秒数として扱う。現代のホップ数の説明をそのまま当てると、この計算の意味が変わる。

実機試験の到達点は別に読まなければならない。数メガバイトのメモリーを持つ交換機を、Ethernetと9600ボーの回線の間に置いた。待機したIPデータグラムは最大916個。寿命で決まる定常状態に至る前に、往復遅延の増大でTCP接続がタイムアウトした。実測されたのは長い列と接続の失敗であり、「全部が次で捨てられた」という最終局面ではない。

そこでNagleは列の順番を変える。単一のFIFOでは、たくさん送り込むホストが多くの場所を占め、回線の取り分も増やせる。代案は送信元ホストごとの列を作り、空でない列から一個ずつ順番に取り出すこと。自分の列に余計なパケットを積んでも、増えるのは自分の待ち時間だけだ。個別の列が約二個を超えたらSource Quenchを送る案も書いた。これは当時の提案であり、現在の普及状況の説明ではない。

送信元を偽って多数のアドレスを使えば、取り分を水増しできる。Nagle自身がこの抜け道と、交換機一台の公平性だけでは網全体を公平にできない点を認めた。高速なLANから細い広域回線へ入る場所が、この仕組みの働きどころだった。公式記録にあるこの文書は討議用のメモで、提案を標準として扱っていない。残る問いは単純だ。限られた出口を次に使う権利を、誰がどう配るのか。

Sources