ECNについて：より速く、スムーズなデータ配信のための輻輳回避

スムーズなネットワークエクスペリエンスのためには？

2024年9月13日
著者: Akshita Agarwal
翻訳: 逆井 晶子

この記事は米Catchpoint Systems社のブログ記事「ECN explained: Navigate congestion for faster, smoother data delivery」の翻訳です。
Spelldataは、Catchpointの日本代理店です。
この記事は、Catchpoint Systemsの許可を得て、翻訳しています。

事実: 誰も交通渋滞が好きではありません。

そのため、Googleマップがなかった時代を懐かしむ人はいません。

携帯や車のナビゲーションアプリのおかげで、ラッシュアワーの輻輳した道を避け、目的地により速く到達できる交通情報を確認できます。

同じ論理が、インターネット上で配信されるコンテンツにも当てはまります。

ウェブ上の輻輳は、データパケットがネットワークを氾濫し、遅延やパケットロスを引き起こすときに発生します。
輻輳した経路を通知したり、経路全体のトラフィックを減らしたりする方法があれば、エンドユーザーの体験を大幅に改善し、より高速でスムーズで信頼性の高いデータ配信を実現することができます。

解決策に進む前に、まずは輻輳管理の従来の方法を見てみましょう。

従来のTCPによる輻輳管理

TCP（Transmission Control Protocol）は、すべてのメッセージが正しい順序で、紛失や破損なしに目的地に届くようにする「スマートな郵便サービス」のようなものです。これにより、インターネット上の通信は信頼性と正確性が確保されます。

しかし、従来のTCPには問題があります。
皮肉なことに、輻輳を検出してデータの流れを制御するためには、輻輳そのものに依存しています。

仕組みを以下に説明します。

• 輻輳ウィンドウサイズ: 従来のTCPは、輻輳ウィンドウサイズ（送信するデータ量）を増やし、輻輳を検出するまで続けます。
• パケットロスによる検出: 輻輳が検出されるのは、パケットが失われたときです。
  つまり、ネットワークはすでに輻輳しています。
• 回復メカニズム: 輻輳が検出されると、TCPはスロースタートなどのメカニズムを使用して回復し、データ転送速度を低下させます。

この問題は、TCPが輻輳を引き起こしてパケットロスを検出し、送信速度を調整する点にあります。
これはうまく機能しますが、低レイテンシー、低損失、スケーラブルなスループットを持つ優れたネットワーク（L4S）を構築するためには、輻輳そのものを回避した方が良いでしょう。

Explicit Congestion Notification（ECN）の登場

ECNは、ネットワーク輻輳を管理するためのより洗練されたアプローチを導入します。

RFC 3168で定義されているインターネットプロトコル（IP）および伝送制御プロトコルの拡張です。
ECNは、パスのコンポーネントがECNをサポートし、ネットワークインフラストラクチャが互換性がある限り、デバイスがパケットを失うことなくネットワーク輻輳について通信できるようにします。

ECNの仕組みを詳しく説明する前に、TCPとIP内の動作を理解しましょう。

TCPおよびIPにおけるECNの動作

IPにおけるECN

ECNは、IPv4またはIPv6ヘッダーのトラフィッククラスフィールドにある2つの予約ビットを使用します。
これらのビットは、4つの異なるコードポイントを表すために異なる組み合わせで設定されます。

• 00 – ECN 非対応の伝送、（Not-ECT）
• 01 – ECN 対応の伝送(1)、ECT(1)
• 10 – ECN 対応の伝送(0)、ECT(0)
• 11 – 輻輳検出済み（CE）

これらの組み合わせは、データがECN対応であるか、輻輳が発生しているかを示します。

TCPにおけるECN

TCPは、そのヘッダーに2つのフラグを使用してECNを実装します。

1つ目のフラグであるECN-Echo（ECE）は、送信者に対して輻輳の通知をエコーし、送信速度を遅くするように信号を送ります。

2つ目のフラグであるCongestion Window Reduced（CWR）は、送信者が輻輳の通知を受信したことを確認します。

ECNのステップごとの流れ

ステップ1: ネゴシエーション

送信者と受信者は、TCPの初期ハンドシェイク時にECNを使用することに合意します。

送信者はデータパケットを送信する際、IPヘッダのECT（ECN-Capable Transport）コードを設定して、ルーターに送信者と受信者の両方がECNをサポートしており、ECNを使用することに同意していることを知らせます。
ECT値はECT(0)またはECT(1)のいずれかで、どちらも輻輳が発生した場合にルーターがパケットを破棄するのではなく、マークすることを示します。
ECNネゴシエーションが失敗した場合、送信者はパケットにNon-ECTコードポイントを設定します。

ステップ2: 輻輳の検出

インターネットルーターは、通常、インターフェースごとに1つ以上のキューを管理し、送信待ちのパケットを格納します。
これらのキューは通常、ドロップテイル方式に従い、キューの最大長に達していない場合はパケットを追加し、そうでない場合はパケットをドロップします。
しかし、この場合、IPヘッダーにECTビットが設定されているため、ルーターはパケットをドロップすることができません。

代わりに、ECT [0 1]をCE [1 1]に変更し、この変更されたパケットを受信者に送信します。
この変更はルーターのみが行うことができ、他のエンティティは行うことができません。
パケットはECTで到着し、CEとして送信され、IPヘッダーに変更が生じたことが示されます。

ステップ3: 送信者への通知

受信者は、IPヘッダーにCEマークがあることを検出し、それが輻輳を示していることを認識します。
受信者は、送信者にこの輻輳を通知しなければなりません。
このため、受信者はIPヘッダーではなくTCPヘッダーのECE（ECN-Echo）ビットをマークし、中間デバイスによってこの情報が変更されないようにします。

ECEビットには2つの目的があります。
初期のハンドシェイク中（SYN/ACKビットが設定されているとき）は、ECNネゴシエーションを示し、ACKパケットに設定されている場合は、ルーターが輻輳していることを送信者に知らせます。

ステップ4: 輻輳ウィンドウの削減

送信者がECEマークを受け取ると、輻輳ウィンドウ（cwnd）を50%削減します。
輻輳のためにECE情報を含むACKパケットがドロップされた場合、受信者は送信者が確認するまで、後続のパケットにECEフラグを設定し続けます。

受信者は、送信者から確認が届くまでECEマークを継続して送信するようにプログラムされています。
これにより、少なくとも1つのACKが送信側に到達し、輻輳が発生していることを確実に通知することができます。

ステップ5: 削減の確認

送信者は、その後、TCPヘッダーにCWR（Congestion Window Reduced）フラグを設定して、輻輳ウィンドウを削減したことを受信者に通知します。
再度輻輳が発生した場合、ルーターはECTをCEに変更することができます。
送信者がCWRフラグの付いたパケットを受信すると、受信者は後続のACKパケットでCEフラグを送信することを停止します。

送信者は、ECEマークごとに輻輳ウィンドウを1回だけ半減させます。
ECEが現在の輻輳ウィンドウに関連しているか確認し、新たなECEであれば、cwndを再び削減します。
このアプローチは、NewRenoの高速回復フェーズでのcwnd削減に似ています。CWRを受信した後、受信者は後続のACKパケットでECEを送るのを停止します。

ECNを実装するべき理由

ECNを使用すると、ネットワーク性能やユーザーエクスペリエンスの向上に次のような重要な利点があります。

#1-スループットの改善

ECNは、すでにネットワークの一部を通過したデータを廃棄する無駄を防ぐことで、アプリケーションのスループットを向上させます。

#2-パケットの再送が不要

UDPベースのVoIP、インタラクティブビデオ、リアルタイムデータなどのレイテンシに敏感なアプリケーションは、失われたパケットを再送せず、輻輳に応じて送信レートを調整することができます。
これらのアプリケーションは、パケットロスによって大幅に劣化し、誤り訂正、データ複製、コーデック誤り隠蔽などの手法を使用して輻輳の影響を打ち消します。
しかし、これらの手法は複雑さを増し、余分なネットワーク容量を消費し、輻輳時にパスのレイテンシを増加させます。

ECNは、輻輳制御とパケットロスを分離することで、アプリケーションがロスに直面する前に送信レートを低下させます。
これにより、ロス緩和によるネガティブな影響を最小化し、ユーザーエクスペリエンスを向上させます。

#3-再送タイムアウト（RTO）の低減

パケットロスの可能性を低減することは、セグメントのバースト送信後にアイドル状態になるアプリケーションにとって、信頼性の高い伝送を確保するために重要です。
これは、データの送信が終了するか、フロー制御や輻輳制御などのネットワーク制約によるものです。

標準的な伝送の回復方法（高速回復など）は、バーストの最後のセグメントが失われた場合、いわゆる「テールロス」をうまく処理できません。
受信者は欠けたセグメントに気づかず、フィードバックを提供しないため、再送は伝送再送タイマーに依存します。
このタイマーの期限が切れると、ネットワークパスの状態が失われ、RTT（ラウンドトリップタイム）などのパス推定値がリセットされ、輻輳ウィンドウが再初期化されます。
これにより、パスに再適応するまでの間、伝送の性能が低下します。

バーストの終わりに輻輳が発生した場合、ECN対応のネットワークデバイスは、パケットをドロップする代わりにCEマークを付けることができます。
これにより、再送タイムアウトが発生せず、アプリケーションの遅延が低減され、間欠的にバーストを送信するアプリケーションのスループットが向上します。

#4-ヘッドオブラインブロッキングの最小化

ECNを使用すると、アプリケーションは初期輻輳中にデータを受信し続けることができ、信頼性の高い伝送での再順序付け遅延を回避できます。
伝送がCEマーク付きのパケットを受信すると、送信者に将来のトラフィックの最大送信レートを適切に減らすよう促します。

ネットワーク診断を進化させるCatchpointの高度なTraceroute機能

AR/VR、ストリーミング、ゲーム、メタバース、自動運転車のような遅延に敏感なアプリケーションが普及するにつれ、シームレスなパフォーマンスの需要が高まっています。
優れたネットワーク体験をエンドユーザーに提供するために、CatchpointのNetwork Experienceソリューションは、ECN設定を追跡できるTraceroute機能を備えています。

ネットワーク上のルータが輻輳時にECNをブリーチすると、レイテンシが増加する可能性があります。
インターネットサービスプロバイダまたはそのパートナーとして、インフラストラクチャを監視し、ECNブリーチの原因を追跡することができます。
これにより、ECN tracerouteを活用して L4S 対応状況をテストすることができます。
さらに、より広いコミュニティをサポートするために、この機能をオープンソース化し、GitHubで公開しました。

CatchpointのTraceroute ECNの違いとは？

多くのネットワーク監視ソリューションが類似の分野に焦点を当てていますが、特にワイヤレスのラストマイル負荷など、いくつかの限界があります。
たとえば、ECNに関連する包括的なオブザーバビリティが欠けているため、ECN関連の重要な洞察を見逃す可能性があります。
完全なECNデータがないと、干し草の山から針を探すように、トラブルシューティングが困難になります。
これらのソリューションを使用するネットワークエンジニアは、輻輳が発生したときに目隠しされているような感覚になり、ネットワークの交差点を効果的に管理するために必要な重要な情報を逃してしまう可能性があります。

Catchpointを使用すると、Tracerouteテストを実行し、プローブがソースから宛先までどの経路を特定することができます。
この監視タイプは、各ホップごとの詳細な洞察を提供し、レイテンシ、パケットロス率、IPアドレス、ホスト名（利用可能な場合）、ASN、国などを確認することができます。
ECNが有効になっている場合、Tracerouteテストで各ホップにおけるECNステータスを追跡することができます。
ソースと宛先の両方がECN対応である場合、テストはホップごとのECNフラグ（ECT(0)またはECT(1)）の設定状況を特定します。
さらに、ECNをサポートせず、フラグをNon-ECTにリセットするホップを検出することも可能です。

以下の例は、単一のTraceroute実行とECNがブリーチされた（ECNのマーキングがドロップされた）正確なホップを示しています。

さらに、Catchpointでは、個別の実行だけでなく、時間経過に伴う傾向を分析し、さまざまなフィルターや分類に基づいてデータをグループ化することができます。

以下の例では、1時間のサンプリングで、約32%のTraceroute要求がブリーチされた ECNパスを持っていました。

次の例では、ECNサポートがある場合とない場合のシナリオでTracerouteのトレンドが記録されています。
示されているように、ECNがサポートされていない場合とサポートされている場合と比較して、全体のpingラウンドトリップタイムが長くなっています。
ECNサポートなしの場合、輻輳によりパケットがドロップされ、再送信されるため、レイテンシが潜在的に増加します。
ECNが導入されている場合、パケットはドロップされるのではなく、CEフラグでマークされます。
このアプローチは、パケットロスなしで輻輳ウィンドウを減らし、ネットワーク内の輻輳の正確な場所を特定することに役立ちます。

このデータセットでは、ECNがエンドツーエンドでサポートされている場合、全体のラウンドトリップタイムが約47%高速になることが観察されています。

ネットワークパフォーマンスの最適化：リアルタイムアプリケーションに対するECNと強化された可視性の影響

AR/VR、ストリーミング、ゲーム、自動運転車などのアプリケーションにおいて、低レイテンシと高い信頼性が不可欠な時代において、ネットワーク輻輳を効率的に管理することはこれまで以上に重要です。
ECNは、パケットをドロップせずに輻輳を通知する高度な方法を提供し、スループットを向上させ、レイテンシを削減し、全体的なユーザーエクスペリエンスを強化します。
CatchpointのNetwork Experienceソリューションは、ネットワーク輻輳の周りのトラフィックルーティングの決定を完全に可視化することで、さらに一歩進んでいます。
高度なTraceroute機能により、ネットワーク管理者は輻輳ポイントを特定して解決し、よりスムーズで高速なデータ配信を確保することができます。
これらのツールを活用することで、組織は卓越したリアルタイムアプリケーションを提供し、優れたネットワークエクスペリエンスを維持することができます。

世界的なECNブリーチング率がネットワークに与える影響に関するレポートをご覧ください。