要約

  • RFC 1016が提案したSQuIDでは、送信元IPが宛先ごとの待ち時間Dを持ち、同じ宛先に送るデータグラムの間を空ける。通常のDはゼロで、遅延が必要な宛先だけ状態を残す。
  • 例の値では、警告後のDは最低75ミリ秒、次の警告イベントで20ミリ秒増える。二秒間の複数警告は一回にまとめ、送るデータがある状態で条件を満たす一秒ごとに1ミリ秒減らす。著者らはCで作ったネットワーク模型で動きを観察した。

速い構内網が遅い回線へ次々とデータグラムを押し込むと、出口の行列はあっという間に長くなる。W. PrueとJon PostelのRFC 1016には、1メガバイトが56 kb/s回線への送信待ちに積まれると、最後の一個は出発まで二分以上待つという計算がある。ゲートウェイは場所が足りなくなれば破棄し、送信元にICMP Source Quenchを送れる。「この宛先へは少し抑えてくれ」という知らせだ。しかし「少し」の長さは包みの中に入っていない。

そこで著者らは、送信元IPモジュールに時計を持たせる案を出した。名前はSource Quench Introduced Delay、略してSQuID。ある宛先へ送るデータグラムの間にDという待ち時間を置く。通常はDがゼロ。遅延がゼロでない宛先だけを最近の相手のキャッシュに記録する。ある宛先が順番待ちしている間にも、別の宛先へのデータは出せる。一つの出口から苦情が来たからといって、全部の行き先に同じ列を作らせない。

Dの上げ下げは非対称だった。Source Quenchのイベントを受けると、Dは「今の値に20ミリ秒を足した値」と「75ミリ秒」の大きい方になる。二秒間に何通届いても、一度の増加として数える。ゲートウェイが短時間に何度も知らせを送ったとき、送信元が毎回大げさにブレーキを踏まないためだ。緩めるときは、前の減少から条件を満たす一秒が過ぎ、送るデータがある場合に1ミリ秒だけ下げる。何も送らず眠っていた宛先のDは、時計の針だけで勝手に消えない。

一回75ミリ秒は日常の感覚では瞬間だ。同じ宛先へのデータグラム一個ごとに挟めば、速い構内網の突進を細かい出発に分けられる。ゲートウェイの曖昧な苦情を、送信元が実行できる間隔に直す。著者らは冒頭でこの文書を大胆な発想の議論用文書と呼んだが、Dの式は実装者が手を動かせる形まで降りてきている。

ゲートウェイ側にも段階があった。例では送信待ち行列が70%になると、まず警告を返しながら該当データグラムを転送する。95%になるとデータの破棄を始める。警告は行列が50%の低水位を下回るまで続ける。早めの知らせなら、送信元が次の出発を変える余地がある。行列を知る者が知らせ、送る時刻を変えられる者が待つという分担だ。

PrueとPostelはCのプログラムでインターネット模型も作った。10 Mb/sの構内網の間に56 kb/sの広域回線を挟み、512バイトのデータグラムや待ち行列を動かした。経路は固定で、分割やTTLは模型に入れなかった。比較したアルゴリズムはいずれも振動した。Dを小刻みに上げてすぐ下げると、送信元は回線に対して強すぎる流量を長く保ち、損失が増えた。増加を大きく、回復をゆっくりにし、短時間の複数警告をまとめる方が模型では有利に見えた。

二十個のデータグラムが一気に来る場面は、行列の事情をよく見せる。RFCの設定では、その一団が81ミリ秒でゲートウェイに届く一方、次の区間では約73ミリ秒で一個しか進まない。選んだ行列容量の下では、17個目から20個目までが失われる。TCPの送信窓は一団を出せても、細い回線はその勢いに付き合えない。SQuIDは狭い出口の手前で出発時刻を散らそうとした。

当時のTCP実装の多くがIPやICMPからSource Quenchを明確なイベントとして受け取っていない、と文書は指摘する。送信元IPに待ち時間を置けば、その警告を次のデータグラムの間隔に反映できる。模型では破棄前の早い警告が有効な通信量を改善しそうだった。実際のネットワークで同じ効果を測るには、固定経路と単純化した通信から先へ進む記録が必要だ。RFC 1016の魅力は、警告を聞いた機械が「何ミリ秒？」と問い返し、行き先ごとに答えを持てるようにしたところにある。