TCP Laminar

Laminar とは

Laminar は、データ送信タイミングを正確に決定する送信スケジューリングを、各 RTT 中に送信されるデータの合計量を決定する純粋な輻輳制御から分離する、TCP 輻輳制御の新しいフレームワークです。

送信スケジューリングのデフォルト アルゴリズムは、Van Jacobson のパケット保存原則 [Jacobson88] の厳密な実装です。データがレシーバーに届くと ACK が発生し、センダーが同等の量のデータをネットワークに送り返します。プライマリ状態変数は、ネットワーク内を循環するデータと ACK の量に暗黙的に含まれています。この状態は、改善された tcp_packets_in_flight() Estimator(total_pipe)によって確認されています。total_pipe は、RFC 3517 で説明されている「pipe」に基づいていますが、現在の ACK によって報告されるデータ量と、輻輳制御に合格したが TSO などの他のイベントを待機している保留中の送信も含まれます。

新しい変数 CCwin が、プライマリ輻輳制御状態変数です。輻輳制御アルゴリズムは、CCwin を調整して、パスに沿った全体的な輻輳レベルを制御します。CCwin は cwnd に似ていますが、cwnd は過負荷になっており、異なる目標や競合する目標がある複数のアルゴリズム(バースト抑制など)で使用されます。

total_pipe が CCwin と異なるときは、送信スケジューリング アルゴリズムが各 ACK に応答して送信されるセグメント数をわずかに調整します。スロースタートと Proportional Rate Reduction [PRR](レート半減の代替)は、どちらも送信スケジューリング アルゴリズムに埋め込まれています。

ラミナ フレームワークの主な利点は、輻輳制御と送信スケジューリングを別々のサブシステムにパーティショニングすることで、それぞれがはるかにシンプルな設計制約の対象になり、以前のコード構成では実現できなかった多くの新しいアルゴリズムを簡単に開発できることです。

Laminar フレームワークは、TCP 輻輳制御の基礎となる設計理念を変更し、パッチ自体だけでなく、幅広い影響を及ぼす可能性があります。このパッチの目的は、コードを試したり、コメントを投稿したり、見落とされていた可能性のある特殊なケースを発見したりできるようにすることです。さらに、CUBIC と Reno 以外の輻輳制御アルゴリズム、cwnd 検証、宛先指標など、多くのアルゴリズムがまだ欠けているという意味ではパッチは不完全です。こうした他のアルゴリズムのリファクタリングに協力してもらえると非常に助かります。

Laminar フレームワークとその動機については、インターネットドラフト draft-mathis-tcpm-tcp-laminar で詳しく説明しています。

ご意見やご提案は、mattmathis@google.com までお寄せください。

このプロジェクトは、プロトコルの改善による Make the Web Faster への Google の取り組みの一環です。

実装上の注意

Laminar は主に 3 つの関数(tcp_input.c)で実装されています。

Tcp_cong_avoid() と tcp_mult_decr() は、CCwin の状態変数を使用して AIMD の輻輳制御を実行します。CCwin が変更されるのは、元に戻すことを除き、この 2 つの関数のみです。(どちらの関数も、輻輳モジュール固有のハンドラを呼び出します)。

Tcp_laminar_schedule() は、各 ACK に応答して送信するデータの量を決定します。これは、Van Jacobson パケット保存を実装し、tcp_packets_in_flight() を CCwin に収束させるために、わずかに上下に調整します。

ほとんどのプロトコル イベントで不変になるように、tcp_packets_in_flight() 見積もりツールに重要な変更があります。アプリケーションが停止し、tcp_laminar_schedule() の調整、実際のパケットロスによって、必要に応じて tcp_packets_in_flight() が変化します。ACK 処理、TSO、その他のほとんどのイベントはサポートしません。損失があると、送信中のパケットの実際の数はすぐに変化しますが、再送信機構が損失としてマークして lost_out をインクリメントするまで、tcp_packets_in_flight() 推定量には反映されません。

パッチを入手する

このパッチは Dave Miller の net-next に対するものであり、3.5-rc2 にクリーンに適用されます。
注: Reno と CUBIC 以外の輻輳制御モジュールは更新されておらず、コンパイルされません。他の輻輳制御モジュール(vegas、scalable、highspeed など)をビルドする構成では、最初に無効にする必要があります。