ゲームラグ白書 › TCP再送の根本原因

ボトルネックでのキューあふれ（輻輳によるロス） Tail drop at a congested bottleneck

原因ID rt-queue-drop · 主担当 インフラチーム・ネットワークインフラ · 副担当 外部・外部, ゲーム開発チーム・クライアント開発

図と実験のあるメインページでこのカードを開く →

ルーター、通信事業者どうしの接続区間、データセンターの回線のように、最も細い箇所のキューが満杯になると、新しく届くパケットを破棄します。

なぜ 動画・ダウンロード・他のユーザーのトラフィックでボトルネック区間が満杯 → すると キューが満杯の間、新しく到着するパケットが続けて破棄される（tail drop）。破棄されなかったパケットも満杯のキューの末尾で待たされる → 画面では 複数のパケットが一度に消え、長く止まった後に早送り、夜の時間帯に多い

症状

フリーズ, 早送り, 引き戻し

要因

パケットロス, 遅延

誰に起きるか

同じ家, 特定の地域・ISP, サーバー全体

いつ

夜のピーク時間帯, 人が集中したとき

担当

主担当 インフラチーム・ネットワークインフラ · 副担当 外部・外部, ゲーム開発チーム・クライアント開発

ゲーム開発チームの対応

パケットロスが集中したりPingが急上昇したりしたら画面にネットワーク状態を表示（同じ回線で大容量の転送が行われている可能性を案内）。

インフラチームの対応

データセンター回線の余裕を確保、自社の回線・スイッチポートのキューでの破棄（output drops）カウンターを確認、通信事業者の区間が詰まっていれば別の回線・ピアリングに迂回。

外部の対応

ユーザーにルーターのSQM（fq_codel、CAKE）とECNの利用を案内（キューがあふれる前に速度を落とさせる）、通信事業者にボトルネック区間の増強を依頼。

数値の目安

キューがあふれる瞬間には、数十msの間に入ってくるパケットのかなりの部分が一度に消えます。続けて失ったうえに送り直したパケットまで失いやすいため、RTOに至ることが多くなります。

グラフでは

特定の時間帯だけ高い · 再送率、RTT（Ping）

確認箇所

サーバーの再送率（nstatを1分間隔で実行して得たTcpRetransSegs ÷ TcpOutSegsの増分）と接続ごとのRTTを地域・通信事業者・時間帯別に分けて確認し、自社の回線・スイッチポートの出力破棄（ifOutDiscards）もあわせて確認。問題の地域に向けて、ピーク時間帯と空いている時間帯にmtrを取って比較

該当する場合

夜のピークにだけ再送率が上がり、パケットロスの直前にRTTが先に上がる（キューが埋まっていく様子）。mtrではピーク時間帯にだけ、ある区間から終点までパケットロスと遅延がそろって増える

該当しない場合

パケットロスの直前にRTTが上がらなければ「ポリサーによる超過分の破棄」。時間帯に関係なく常に同じようにパケットを失うなら「物理エラー」か「経路変更・ECMPの不良経路」

確認手段

インフラのツールで確認（ゲームコード不要）

実際の事例

Riot Games 2015: 遠回りしていたLeague of LegendsのトラフィックとRiot Direct

出典

1. RFC 7567: IETF Recommendations Regarding Active Queue Management IETF
   tail dropはキューを長く満杯のままにして遅延を増やし、集中したパケットロスを生むという説明と、AQMの推奨
2. RFC 8290: The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm IETF
   fq_codel：フローごとのキューとAQMでキューを短く保ち、バッファブロートを減らす
3. RFC 3168: The Addition of Explicit Congestion Notification (ECN) to IP IETF
   ECN：パケットを破棄する代わりに、IPヘッダーの印で輻輳を知らせる
4. Smart Queue Management Bufferbloat.net
   SQM：フローごとのスケジューリング、キュー長の管理（AQM）、シェーピングを組み合わせる方式
5. Cake Bufferbloat.net
   CAKE：シェーパーとfq_codel系のキュー管理を一つにまとめた、ルーター向けのSQM
6. net/ipv4/proc.c Linux kernel
   nstatに表示されるTcpRetransSegs・TcpOutSegs（Tcp項目のRetransSegs・OutSegs）
7. nstat(8) — Linux manual page iproute2
   nstatはデフォルトで、前回の実行以降の増分を表示
8. RFC 2863: The Interfaces Group MIB IETF
   ifOutDiscards：エラーがないのに、バッファ領域の確保などの理由で送出せずに破棄したパケット数
9. An Internet-Wide Analysis of Traffic Policing Google
   キューあふれではパケットロスの前に待ち時間とRTTが先に上がり、ポリシングはRTTを増やさずに超過分を破棄するという区別（SIGCOMM 2016）

あわせて読みたい原因

同じ層：TCP再送の根本原因

• 無線区間のパケットロス
• 送信バーストによる浅いバッファのあふれ
• ポリサーによる超過分の破棄
• 物理エラー（不良ケーブル・光モジュール・コネクター）
• デュプレックスの不一致
• 受信サーバーのホストでのパケット破棄
• ファイアウォール・接続追跡による破棄
• 中間機器の処理上限超過（ファイアウォール・IPS・DDoS対策）
• MTUブラックホール（大きいパケットだけ繰り返し失われる）
• 接続中のNAT・ロードバランサーのマッピング期限切れ
• 経路変更・ECMPの不良経路
• 遅延の急上昇による不要な再送
• 順序の入れ替わりによる不要な高速再送
• ACKの遅れ・消失（上り回線の飽和）
• RTOの設定が環境に合っていない
• thin streamの遅い回復
• 中間機器によるTCPオプションの除去
• ゼロウィンドウ（再送のように見える停止）
• 接続要求（SYN）の再送

同じ症状（フリーズ）を起こすほかの層の原因

• フレームタイムのスパイク L1 クライアントのゲームプロセス
• クライアントのガベージコレクション L1 クライアントのゲームプロセス
• メインスレッドでの同期ロード・シェーダーコンパイル L1 クライアントのゲームプロセス
• ストレージが遅くアセットストリーミングが間に合わない L1 クライアントのゲームプロセス
• ゲームのセキュリティモジュール（アンチチート）の検査 L1 クライアントのゲームプロセス
• Wi-Fi ↔ LTE・5Gの切り替え L2 クライアントのOS・端末
• クライアントのメモリ不足・スワップ L2 クライアントのOS・端末
• ビデオメモリ（VRAM）不足 L2 クライアントのOS・端末

図と実験のあるメインページでこのカードを見る