要約

  • RFC 792は、トラフィックを吸収できないゲートウェイや宛先にICMPタイプ4を与えた。メッセージは原因となったパケットを引用し、特定の宛先への送信を減らすよう求めた。
  • 命令は発信者を認証せず、キュー量、公平な速度、継続時間も示さない。過負荷時の追加パケットは容量を使い、偽造すれば他者のスループットを落とせた。
  • 持続的な制御は端点のトランスポート状態へ移り、ECNは明示信号を実際のパケット内に置いた。RFC 6633はSource Quenchを無視し、捨てて記録することを定めた。

満杯のキューから生まれた命令

1981年の RFC 792 では、次の回線へ出すバッファがないゲートウェイはデータグラムを捨て、ICMPタイプ4、コード0を送信元へ返せた。処理しきれない宛先ホストも同じことができた。Source Quenchは指定宛先への速度を下げ、警告が止まれば徐々に上げるよう求めた。

発想には根拠がある。中継点は送信元から見えないキューを観測し、送信元は今後の送出を制御する。ただしICMPは信頼性のないフィードバックである。報告は失われ、遅れ、到着時には状態が変わり得る。帯域予約ではなかった。

メッセージは元のIPヘッダーと先頭64ビットを引用した。それにより会話を探せても、キュー深度、競合フロー、減らす量、期限は分からない。発信アドレスの機器が本当に引用パケットを見たという暗号学的証明もない。

1989年の RFC 1122 は旧契約を残した。資源枯渇に近いホストはSource Quenchを送れ、受信したIP層はトランスポートへ通知する。TCPは対応する接続を遅くし、通常slow startへ戻る。狭い証拠が大きな結果を起こした。

フィードバックが負荷を増やすとき

RFC 896 は輻輳崩壊を説明した。キューが埋まり、遅延が伸び、ホストは遅いだけのパケットを再送する。ネットワークは複製で忙しいまま、有効配送が落ちる。メモリ追加は発生を遅らせても制御ループを直さない。

Source Quenchは一つの破棄ごとに一つの制御パケットを作り得た。rate limitしても、飽和経路に飽和報告を運ばせる。複数ルーターが同じフローへ共通会計なしに命令し、従うフローだけが不利になる可能性もあった。

1995年の RFC 1812 は、非効率で不公平という研究を受け、ルーターはSource Quenchを生成すべきでないとした。残る生成にはrate limitが必要だった。満杯のキューを見ることと遠隔トランスポートを命令する資格が分離された。

送信元は結果から学んだ

TCPはフロー状態を持つ場所へ反応を置いた。RFC 5681 はSource Quenchなしにcongestion window、slow start、回避、回復を定義する。ACKはデータが経路を離れて受信された証拠になる。lossやtimeoutは不完全でも、端点が追跡するsequenceに結び付く。

ルーターの仕事は残った。RFC 2309 は、あふれる前に輻輳を知らせるactive queue managementを勧め、queue、scheduling、公平性を別の面として扱った。ルーターは観測できるキューを管理し、トランスポートは特定できるフローを変える。

パケットの中の印

RFC 3168 のECNは明示信号を残しつつ文法を変えた。端点がECN対応を宣言したパケットに、ルーターは破棄の代わりにCongestion Experiencedを記せる。受信側がトランスポート状態で返し、送信側はlossとほぼ同様に反応する。

印は実際にキューを通ったパケットに付く。過去のパケットを引用する孤立命令ではない。ECNは完全な認証でも普遍的な配備でもないが、証拠を能力交渉と識別可能な会話へ結ぶ。

服従も廃止する

生成を控えるだけでは、ホストが従う限り古い装置や攻撃者にレバーが残る。RFC 6633 は2012年に閉じた。ホストは送ってはならず、TCP、UDP、他のトランスポートとルーターは無視し、firewallは捨ててsecurity faultとして記録すべきである。

偽造Source Quenchは、実際のボトルネックなしにblind throughput-reduction攻撃を可能にした。広いICMPフィルタリングも配送依存を不可能にした。ICMPv6には最初からこの種別がない。

8つのRFCが示すのは段階的な規範変更で、世界同時の停止日ではない。全ルーターが送り、全ホストが従ったとは証明しない。lossの全てが輻輳とも、ECNが操作不能とも言わない。結論は、認識可能な番号から実行権限を取り除けるということだ。