1. Introduction (はじめに)
1. Introduction (はじめに)
まず、TCP がパケット破棄を輻輳の指標として使用するメカニズムについて説明します。次に、インターネットインフラストラクチャにアクティブキュー管理 (Active Queue Management, AQM、例: RED) を追加することで、ルーターがキューオーバーフロー前に輻輳を検出できるようになり、ルーターがパケット破棄だけを輻輳指標として使用する必要がなくなることを説明します。代わりに、ルーターは ECN 対応トランスポートプロトコルからのパケットの IP ヘッダーに Congestion Experienced (輻輳経験、CE) コードポイントを設定できます。ルーターで CE コードポイントをいつ設定するかを説明し、TCP を ECN 対応にするために必要な変更について説明します。他のトランスポートプロトコル (例: 信頼性のないユニキャストまたはマルチキャスト、信頼性のあるマルチキャスト、その他の信頼性のあるユニキャストトランスポートプロトコル) への変更は、これらのプロトコルが開発され標準化プロセスを経るときに検討できます。また、本文書では IP トンネル内での ECN の使用、特に IPsec トンネル内での使用に関する問題についても説明します。
本文書の指針となる原則の一つは、ここで規定されるメカニズムが可能な限り段階的に展開できることです。段階的展開の原則が直面する課題の一つは、以前から存在する一部の IP トンネルが ECN の使用と互換性がないことです。ECN の展開に伴い、互換性のない IP トンネルは本文書の規定に準拠するようにアップグレードする必要があります。
本文書は RFC 2481 "A Proposal to add Explicit Congestion Notification (ECN) to IP" を廃止します。これは ECN をインターネットコミュニティの実験的プロトコル (Experimental Protocol) として定義したものでした。本文書はまた、RFC 2474 "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers" を IP ヘッダーの ECN フィールドの定義に関して更新し、RFC 2401 "Security Architecture for the Internet Protocol" をトンネルモードヘッダー構築における IPv4 TOS バイトと IPv6 トラフィッククラスバイトの処理を ECN の使用と互換性を持つように変更し、RFC 793 "Transmission Control Protocol" を TCP ヘッダーの 2 つの新しいフラグの定義に関して更新します。
TCP の輻輳制御および回避アルゴリズムは、ネットワークをブラックボックスと見なす概念に基づいています [Jacobson88, Jacobson90]。ネットワークの輻輳やその他の状態は、エンドシステムがネットワーク状態をプローブすることによって決定されます。つまり、ネットワーク上の負荷を段階的に増加させ (ネットワーク内の未完了パケットのウィンドウを増やすことによって)、ネットワークが輻輳してパケットを失うまで続けます。ネットワークを「ブラックボックス」として扱い、損失をネットワーク輻輳の指標として扱うことは、TCP によって運ばれる純粋なベストエフォートデータに適しており、これらのデータは個々のパケットの遅延や損失にほとんどまたは全く敏感ではありません。さらに、TCP の輻輳管理アルゴリズムには、高速再送信 (Fast Retransmit) や高速回復 (Fast Recovery) などのテクニックが組み込まれており、スループットの観点から損失の影響を最小限に抑えます。しかし、これらのメカニズムは、実際に 1 つまたは複数の個々のパケットの遅延や損失に敏感なアプリケーションを支援するようには設計されていません。インタラクティブトラフィック (telnet、ウェブブラウジング、オーディオおよびビデオデータ転送など) は、パケット損失に敏感である可能性があります (特に UDP などの信頼性のないデータ転送プロトコルを使用する場合)、または損失後にパケットを再送信する必要があるために生じるパケット遅延の増加に敏感である可能性があります (TCP が提供する信頼性のあるデータ転送セマンティクスの下で)。
TCP は、失われたパケットに遭遇するまでウィンドウサイズを徐々に増やすことによって適切な輻輳ウィンドウを決定するため、これによりボトルネックルーターでのキューの蓄積が発生します。ルーター内のほとんどのパケット破棄ポリシーでは、個々のフローが課す負荷に敏感ではないため (例: キューオーバーフロー時のテール破棄 (tail-drop))、これは一部の遅延に敏感なフローのパケットが破棄される可能性があることを意味します。さらに、このような破棄ポリシーは、複数のフロー間での損失同期を引き起こします。
アクティブキュー管理メカニズムは、キューオーバーフロー前に輻輳を検出し、エンドノードにこの輻輳の指示を提供します。したがって、アクティブキュー管理は、そのキューを共有するすべてのトラフィックの不必要なキューイング遅延を削減できます。アクティブキュー管理の利点は RFC 2309 [RFC2309] で議論されています。アクティブキュー管理は、キューオーバーフロー時の破棄の望ましくない特性のいくつかを回避します。これには、複数のフロー間の望ましくない損失同期が含まれます。さらに重要なことに、アクティブキュー管理は、輻輳制御メカニズムを持つトランスポートプロトコル (例: TCP) がバッファオーバーフローだけを輻輳の唯一の指標として依存する必要がないことを意味します。
アクティブキュー管理メカニズムは、いくつかの方法のいずれかを使用してエンドノードに輻輳を指示できます。一つの方法はパケット破棄を使用することであり、これが現在の慣行です。しかし、アクティブキュー管理により、ルーターはパケットをキューイングまたは破棄するポリシーと輻輳を指示するポリシーを分離できます。したがって、アクティブキュー管理により、ルーターはパケット破棄だけに依存するのではなく、パケットヘッダーの Congestion Experienced (輻輳経験、CE) コードポイントを輻輳指示として使用できます。これにより、遅延に敏感なフローへの損失の影響を減らす可能性があります。
インターネットには、ECN をネゴシエートするように設定された TCP SYN パケットを破棄するか、RST で応答する一部のミドルボックス (ファイアウォール、ロードバランサー、侵入検知システムなど) が存在します。本文書は、このようなデバイスが存在する場合でも、TCP 実装が堅牢な接続性を提供するために使用できる手順を規定しています。