データ センター伝送制御プロトコル (DCTCP)

データ センターはさまざまなアプリケーションをホストし、同じネットワーク上に、待機時間が小さくて予測可能であることを必要とする多様なワークフローを混在させます。同時に、他のアプリケーションは、継続的で高いスループットを必要とします。このような環境で、今日の最新の伝送制御プロトコル (TCP) 輻輳制御メカニズムは、十分に詳細な輻輳制御設定を備えていません。そのため、ネットワーク スイッチでのキューの形成により、遅延、待機時間の変動、およびタイムアウトが生じます。

この問題を緩和するために、Windows Server 2012 では DCTCP を導入しました。DCTCP は、明示的輻輳通知 (ECN) を使って、送信元での輻輳の程度を見積もり、それに合うように送信速度を低下させます。これによって、ネットワーク トラフィックのより詳細な制御が可能になり、DCTCP は非常に低いバッファー占有率で動作しつつ、高いスループットを実現できます。

次の図は、従来の TCP と比較して、イーサネット スイッチ パケット バッファーでごくわずかな場所を占めるだけで十分なスループットを達成できる、DCTCP の有効性を示しています。グラフに示されているのは、DCTCP と TCP を使った場合のネットワーク スイッチでのキューの長さです。2 つの個別の 1 Gbps (ギガビット/秒) TCP/IP ストリームが 2 つの個別のスイッチ ポートに転送され、1 つの送信 1 Gbps ポートに結合されます。

従来の TCP では、長期間維持される大量の TCP フローによって、ボトルネックのキューの長さはパケットが破棄されるまで増加するため、TCP トラフィックのパターンは鋸の歯のようになります。長いフローと短いフローが同じキューを走査した場合、2 つの問題が発生します。1 つの問題は、上で説明したように、短いフローでのパケット損失が発生する場合があることです。2 つ目の問題は、パケットの損失がない場合でも、キューが増大することです。短いフローは、大きなフローのパケットの後でキューに追加されるため、待機時間が増加します。

しかし、DCTCP では、輻輳に対してより速くて詳細な対応が可能です。スイッチで構築されるメッセージ キューを大幅に小さくして動作できるように、各送信元で効果的に送信速度を調整しつつ、同じ集約スループットを維持します。DCTCP ではキューの長さが大幅に短くなるため、TCP で発生するような待機時間や待機時間の変動を避けることができます。

一般的な浅いバッファーのスイッチで DCTCP を使う場合、スループットは TCP と同じか、TCP より高くなりますが、ネットワーク インフラストラクチャで使うバッファー領域は 90% 削減できます。TCP とは異なり、バースト トレランスが高く、短いフローでの待機時間が短くなります。現在では TCP の限界によって、送信されるトラフィックの誤送信が起きていますが、DCTCP ではアプリケーションが現在の 10 倍のバックグラウンド トラフィックを処理でき、フォアグラウンド トラフィックへの影響はありません。また、フォアグラウンド トラフィックが 10 倍に増加してもタイムアウトが発生しないので、コンピューターが前のタイムアウトの結果としてメッセージを再送信する場合に発生する多くの問題を回避できます。