従来、UDP ベース・アプリケーションの制御はアプリケーション優先順位管理および TCP/IP プロファイル・パラメーターの UDPQueueLimit ON | OFF によって構成されます。バインド済み UDP ポートのインバウンド・データグラムは受け入れられ、キューの限界に達するかバッファー・メモリーがいっぱいになるまでキューに入れられます。UDPQueueLimit を OFF に設定すると、フラッディング・アタックの対象になったりアプリケーションの停止が発生している単一のバインド済みポートで、使用可能なバッファー・ストレージがすべて消費されてしまうことがあります。UDPQueueLimit は常に ON に設定することをお勧めします。これは、単一のバインド済みポートへのインバウンド・データグラムによって消費されるストレージの量を制限します。Pascal API を使用するソケットには、データグラムの数に 160 KB という制限があります。他の API を使用するソケットには、2000 データグラムまたは 2880 KB という制限があります。
UDP ポートの IDS トラフィック調整 (TR) ポリシーは、指定するバインド済み IP アドレスおよびポートについて、4 つの要約キュー・サイズのうちの 1 つを指定します。4 つの要約サイズは、VERY_SHORT、SHORT、LONG、VERY_LONG です。これらの要約値に関連する実際のキュー・サイズは、内部値で、変動します。ほとんどの UDP アプリケーションには、応答時間の認識に応じたタイムアウト値があります。システムの処理速度やネットワークの送達速度が急速に速まっているのに対し、これらの値は変わらない傾向があります。このため、これらの要約値に関連するキュー・サイズは時代に合わせた変更を求められることがあります。初期の実装では、データグラムの数に 16、256、2048、8192 の値を使用し、平均データグラム・サイズに 2 KB を使用してバイト・サイズを計算します (32 KB、512 KB、4 MB、16 MB)。パフォーマンス上の理由から、Pascal API を使用するソケットはバイトの制限のみを強制します。その他の API を使用するソケットは、両方の制限を強制しています。ポートにポリシーが指定されていないソケットは、既存の UDPQueueLimit の機構を使用します。
平均到着速度より高速でデータグラムを処理できるアプリケーションでは、キューは速度調整バッファーの役割を果たし、一時的なピーク・ワークロードをその後の減少時にシフトします。アプリケーションの処理速度が平均到着速度を超えれば超えるほど、キューは大きくなり、作業を失敗せずに吸収できる到着速度の変動幅は大きくなります。極めて変化の大きい (「バースト性の」) トラフィック・パターンを持つ超高速アプリケーションでは、LONG または VERY_LONG のキュー・サイズが適切な場合があります。
処理可能な速度より高速でデータグラムを常時受信するアプリケーションでは、キューは過剰なデータグラムを廃棄することによって、実質的な到着速度をその処理速度に制限します。この場合、キュー・サイズはキューの中のデータグラムの平均待ち時間に影響を与えるだけで、作業失敗のパーセントには影響しません。実際には、待ち時間が長くなりすぎるとピア・アプリケーションが処理を放棄するか、データグラムを再送して処理を待ちます。常に高いトラフィック速度を持つ低速アプリケーションでは、SHORT のキュー・サイズが適切な場合があります。
一般に、クライアント側のアプリケーションのほうがシステム優先順位が低く、データグラム処理速度が低くなる傾向があります。また、データグラム到着速度はずっと低い傾向もあります。キュー・サイズに SHORT または VERY_SHORT を指定すると、ランダムにポート・フラッディングのアタックを受けるシステム・バッファー・ストレージのリスクを軽減し、失われるデータグラムのパーセントへの影響もほとんどありません。
TR UDP は、ポートがキュー限界のおよそ 90% に達すると、抑制イベントを生成します。ポートが限界のおよそ 88% 以下になると、非抑制イベントが生成されます。各抑制状態になっているその期間は、IDS 相関係数が割り当てられます。ポリシーでトレースが要求されると、各抑制状態で限界を超えている最初の 100 個のパケットが、相関係数とともにトレースされます。
UDP トラフィック調整ポリシーは IPv4 および IPv6 に適用されます。