解決策
1986年10月、負荷が増えるにつれてインターネットのスループットは容量の約1000分の1まで崩壊したが、単一のリンクが壊れていたわけではなかった。ヴァン・ジェイコブソンは原因を突き止めた。送信側は可能な限り速く送信し、損失が起きると全速力で再送したため、ネットワークは再び破棄されるだけのパケットの再送に容量を費やしていた。
彼の1988年の論文はスロースタートと輻輳回避を提案した。送信側は1セグメントから始め、損失を検出するまで各確認応答ごとにウィンドウを倍にし、その後ウィンドウを半減してゆっくり増加させる。経路の容量を仮定するのではなく、各送信側がフィードバックを通じてそれを測定し適応する。
この設計は開始時に意図的に保守的である。利用可能な帯域を知る唯一の方法はそれを探ることであり、探る唯一の安全な方法は穏やかに行うことだからだ。その結果生まれる挙動、すなわち加法的増加・乗法的減少により、何千もの接続が中央のスケジューラなしで1つの経路を共有できる。
達成したこと
容量を穏やかに探り、損失時には半減する
うまくいった理由
損失はエラーではなくシグナルとして扱われるため、送信側はネットワークがあふれる前に反応する。
指数的増加は容量を素早く見つけ、損失時の半減は回復を安全に保つ。
アルゴリズムは局所的である。各送信側が自身のフィードバックから適応するため、システムは数百万の接続にスケールする。
新しいハードウェアではなく、1つのプロトコルの挙動の変更によってシステム的な障害を修正した。
応用できること
システムの容量が不明で共有されている場合、各参加者に保守的に探らせ、フィードバックに応じて後退させる。そうすれば全体が自己調整する。
その後
スロースタートと輻輳回避はTCPの輻輳制御の中核となり、1997年にRFC 2001で成文化された。その後の変種(NewReno、CUBIC、BBR)は探査の規則を洗練させたが、探って後退するという原則は今もインターネットの大半が帯域を共有する仕組みを支配している。
出典をたどる
出典
- Congestion Avoidance and Control ACM SIGCOMM 1988 (via Lawrence Berkeley National Laboratory) · ee.lbl.gov ·
- RFC 2001 — TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms IETF / RFC Editor · rfc-editor.org