輻輳（ふくそう）制御

輻輳制御は、ネットワークへ処理能力を超えるトラフィックが流入して待ち行列、遅延、パケット損失及び再送が増幅する状態を防止・緩和する制御です。TCPでは送信側がネットワークから推定した混雑状況に応じて輻輳ウィンドウを調整します。

■ 試験で押さえるポイント

• 輻輳は、入力トラフィックが回線帯域、ルータの転送能力又はバッファ容量を継続的に上回ると発生します。待ち行列が伸びて遅延とジッタが増え、満杯になると損失し、再送がさらに負荷を増やすと輻輳崩壊に至り得ます。

• フロー制御は主に受信端末の処理・バッファを超えないよう送信量を抑え、TCPの受信ウィンドウ$rwnd$を使います。輻輳制御は経路上のネットワークを守り、輻輳ウィンドウ$cwnd$を使います。実際に未確認で送れる量は両者の小さい方に制約されます。

• TCPのスロースタートは小さい$cwnd$からACKに応じて急速に増やし、利用可能な容量を探ります。しきい値以降の輻輳回避では増加を緩やかにし、損失、タイムアウト又はECNによる明示通知を混雑の信号として$cwnd$を減らします。

• 重複ACK等から損失を推定する高速再送はタイムアウトを待たずに欠落セグメントを再送し、高速回復は送信を完全に初期状態へ戻さず回復させます。具体的な増減方法はTCP輻輳制御アルゴリズムによって異なります。

• UDP自体にはTCP型の輻輳制御がないため、リアルタイム通信等のアプリケーションは送信レート、品質、再送又はFECを自ら調整する必要があります。UDPだから混雑時も一定速度で送ってよいわけではありません。

• ネットワーク側ではキューイング、AQM、ECN、トラフィックシェーピング、ポリシング、QoS及び容量増強を用います。大容量バッファだけでは損失を遅らせる一方で遅延が極端に増えるbufferbloatを招く場合があります。

• QoSは重要通信へ優先度や帯域を配分しますが、総容量そのものを増やしません。監視では帯域使用率だけでなく、キュー長、損失、RTT、再送、ECNマーク及びアプリケーション応答を併せて見ます。

■ 過去問での着眼点

フロー制御は受信側の許容量、輻輳制御はネットワーク経路の混雑に合わせ、TCPの送信量は$rwnd$と$cwnd$の小さい方に制約されます。スロースタートは名称に反してウィンドウを指数的に増やし、輻輳回避では緩やかに増やします。損失又はECNを検知したら送信を抑えます。受信側はrwnd、ネットワーク輻輳はcwndという制御対象を区別します。

例: 受信ウィンドウが64Kバイトでも、輻輳ウィンドウが16Kバイトなら未確認で送れる量は最大16Kバイトです。ACKが順調なら$cwnd$を増やし、損失が続けば減らして経路へ流す量を抑えます。