メインコンテンツまでスキップ

5. Explicit Congestion Notification in IP (IP における明示的輻輳通知)

5. Explicit Congestion Notification in IP (IP における明示的輻輳通知)​

本文書は、インターネットが早期輻輳 (incipient congestion) に対する輻輳表示 (RED およびそれ以前の研究 [RJ90] で示されたような) を提供することを規定しています。通知は、パケットを破棄する代わりにマーキングすることで実現される場合があります。これは IP ヘッダー内の ECN フィールドを使用し、このフィールドは 2 ビットで構成され、'00' から '11' までの 4 つの ECN コードポイントを形成します。ECN-Capable Transport (ECN 対応トランスポート、ECT) コードポイント '10' および '01' は、トランスポートプロトコルのエンドポイントが ECN をサポートしていることを示すためにデータ送信者によって設定されます。これらをそれぞれ ECT(0) および ECT(1) と呼びます。本文書での「the ECT codepoint (ECT コードポイント)」という表現は、2 つの ECT コードポイントのいずれかを指します。ルーターは ECT(0) および ECT(1) コードポイントを同等に扱います。送信者は、ECT を示すために ECT(0) または ECT(1) コードポイントをパケット単位 (packet-by-packet) で自由に使用できます。

ECT(0) および ECT(1) の両方の ECT コードポイントを使用する主な動機は、ネットワーク要素が CE コードポイントをクリアしておらず、データ受信者がトランスポートプロトコルの要求に従って CE コードポイントが設定されたデータパケットの受信を送信者に正しく報告していることをデータ送信者が検証できるようにすることです。送信者と受信者が ECT(0) および ECT(1) コードポイントを区別する方法に関するガイダンスは、各トランスポートプロトコルに対して別の文書で説明されます。特に、本文書は TCP エンドノードが ECT(0) および ECT(1) コードポイントを区別するメカニズムには触れません。単一の ECT コードポイントのみを必要とするプロトコルおよび送信者は ECT(0) を使用すべきです。

not-ECT コードポイント '00' は、ECN を使用しないパケットを示します。CE コードポイント '11' は、エンドノードに輻輳を示すためにルーターによって設定されます。満杯のキューに到着したパケットは、ECN がない場合と同様にルーターによって破棄されます。

+-----+-----+
| ECN FIELD |
+-----+-----+
  ECT   CE         [Obsolete] RFC 2481 names for the ECN bits.
   0     0         Not-ECT
   0     1         ECT(1)
   1     0         ECT(0)
   1     1         CE

図 1: IP における ECN フィールド

2 つの ECT コードポイントを使用することで、本質的にパケットヘッダーに 1 ビットの ECN nonce が提供され、ルーターが CE コードポイントを設定するとき、必然的に nonce を「クリア」することになります [SCWA99]。たとえば、CE コードポイントをクリアするルーターは、元の nonce を再構築する際にさらなる困難に直面するため、CE コードポイントの繰り返しのクリアはエンドノードによって検出される可能性が高くなります。ECN nonce は、トランスポート受信者がパケットに CE コードポイントが設定されていたかどうかについてトランスポート送信者に虚偽の報告をする不正行為にも対処できます。2 つの ECT コードポイントを使用する動機については、第 20 章でより詳細に議論されており、4 番目の ECT コードポイント (つまりコードポイント '01') のいくつかの代替可能性についても議論されています。ECT(1) コードポイントを理解しない初期の ECN 実装との後方互換性については、第 11 章で議論されています。

RFC 2481 [RFC2481] では、ECN フィールドは ECN-Capable Transport (ECT) ビットと CE ビットに分割されていました。RFC 2481 で ECN-Capable Transport (ECT) ビットのみが設定されている ECN フィールドは、本文書の ECT(0) コードポイントに対応し、RFC 2481 で ECT および CE ビットの両方が設定されている ECN フィールドは、本文書の CE コードポイントに対応します。'01' コードポイントは RFC 2481 では定義されていませんでした。これが、単一の ECT コードポイントのみが必要な場合に ECT(0) を使用することが推奨される理由です。

      0     1     2     3     4     5     6     7
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |          DS FIELD, DSCP           | ECN FIELD |
   +-----+-----+-----+-----+-----+-----+-----+-----+

     DSCP: differentiated services codepoint
     ECN:  Explicit Congestion Notification

図 2: IP における Differentiated Services および ECN フィールド

IPv4 TOS バイトのビット 6 および 7 が ECN フィールドとして指定されています。IPv4 TOS バイトは IPv6 のトラフィッククラス (Traffic Class) バイトに対応し、ECN フィールドの定義は両方の場合で同じです。IPv4 TOS バイト [RFC791] および IPv6 トラフィッククラスバイトの定義は、6 ビットの DS (Differentiated Services、差別化サービス) フィールド [RFC2474, RFC2780] に置き換えられました。ビット 6 および 7 は [RFC2474] で現在未使用 (Currently Unused) としてリストされ、RFC 2780 で ECN の実験的使用のために承認されるように指定されました。第 22 章では TOS バイトの歴史を簡単に紹介しています。

TOS バイトの不安定な歴史のため、本文書で規定されている ECN フィールドの使用は、ECN 以前のこれら 2 ビットの過去の使用との後方互換性を保証できません。この後方互換性の欠如による潜在的な危険については、第 22 章で議論されています。

ECN 対応トランスポートが単一の CE パケットを受信した後、エンドシステムが従う輻輳制御アルゴリズムは、単一の失われたパケットに対する輻輳制御応答と本質的に同じでなければなりません。たとえば、ECN 対応 TCP の場合、送信元 TCP は、パケット損失または ECN 表示を含む任意のデータウィンドウに対して輻輳ウィンドウを半分に減らさなければなりません。

CE パケットに対する輻輳制御応答が失われたパケットに対する応答と本質的に同じであることを要求する理由の 1 つは、エンドシステムおよびルーターでの ECN の段階的展開に対応するためです。一部のルーターは ECN 対応パケットを破棄する場合があり (たとえば、輻輳検出に同じ AQM ポリシーを使用)、他のルーターは同等の輻輳レベルで CE コードポイントを設定します。同様に、ルーターは ECN 非対応パケットを破棄する場合がありますが、同等の輻輳レベルで ECN 対応パケットに CE コードポイントを設定します。CE コードポイントに対する輻輳制御応答がパケット損失に対する応答と異なる場合、これは異なるフローに対する不公平な扱いにつながる可能性があります。

もう 1 つの目標は、エンドシステムが各データウィンドウで最大 1 回 (つまり各往復時間で最大 1 回) 輻輳に応答して、1 つの往復時間内の複数の輻輳表示に対して複数回反応することを避けることです。

ルーターの場合、ルーターがパケットを破棄してエンドノードに輻輳を示すべき場合にのみ、ECN 対応パケットの CE コードポイントを設定すべきです。ルーターのバッファがまだ満杯でなく、ルーターがエンドノードに早期輻輳を通知するためにパケットを破棄する準備ができている場合、ルーターはまずそのパケットの IP ヘッダーに ECT コードポイントが設定されているかどうかを確認すべきです。設定されている場合、ルーターはパケットを破棄する代わりに IP ヘッダーに CE コードポイントを設定できます。

すべてのエンドノードが ECN をサポートする環境では、CE コードポイントを設定するための新しい標準、およびエンドノードが CE パケットに反応するための新しい輻輳制御メカニズムの開発が可能になる場合があります。ただし、これは研究課題であるため、本文書では議論しません。

ルーターが CE パケット (つまり、CE コードポイントが設定されたパケット) を受信すると、CE コードポイントは変更されずに維持され、パケットは通常の方法で転送されます。深刻な輻輳が発生し、ルーターのキューが満杯になった場合、ルーターは新しいパケットが到着したときに一部のパケットを破棄する以外に選択肢がありません。私たちは、ほとんどのエンドシステムが ECN をサポートし、TCP またはその他の互換性のある輻輳制御メカニズムに参加する場合、このようなパケット損失は比較的まれになると予想しています。適切に設定された ECN 対応環境では、パケット損失は主に一時的な期間または非協力的なソースが存在する状況で発生するはずです。

CE を設定してパケットを破棄しない場合についての上記の議論は、デフォルトですべての Differentiated Services Per-Hop Behaviors (PHBs) [RFC 2475] に適用されます。PHB の仕様は、CE の設定とパケットの破棄との間で互換性のある実装がどのように選択するかについてより詳細を提供できますが、これは必須ではありません。発生する破棄が輻輳以外の理由によるものである場合、またはエンドノードに早期輻輳を示すことが望まれる場合 (たとえば、diffserv エッジノードは、特定のクラスのトラフィックが diffserv ドメインに入るのを防ぐために無条件に破棄するように構成されている場合があります)、ルーターはパケットを破棄する代わりに CE を設定してはなりません。

私たちは、ルーターが平均キューサイズによって示される早期輻輳に基づいて CE コードポイントを設定し、[FJ93, RFC2309] で提案されている RED アルゴリズムを使用することを期待しています。私たちの知る限り、これは現在 IETF で議論されている、バッファオーバーフロー前にルーターがパケットを積極的に破棄することに関する唯一の提案です。ただし、本文書は特定のアクティブキュー管理メカニズムを規定しようとするものではなく、必要に応じてその作業を IETF の他の領域に委ねます。ECN はルーターでの合理的なアクティブキュー管理メカニズムと密接に関連していますが、その逆は成立しません。アクティブキュー管理メカニズムの開発と展開は ECN とは独立しており、IP アーキテクチャに ECN がない場合、輻輳表示としてパケット破棄を使用します。

に最終更新