Retransmisi yang tidak perlu akibat lonjakan latensi Spurious RTO from delay spikes

ID penyebab rt-spurious-delay · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pengembangan klien (Tim Pengembang Game)

Buka kartu interaktif dengan gambar dan simulasi →

Paket sebenarnya tidak hilang dan hanya sesaat datang sangat terlambat, tetapi jika keterlambatan itu lebih lama dari RTO, pengirim menganggap paket hilang lalu mengirimnya ulang.

Mengapa Bufferbloat, mode hemat daya Wi-Fi, transisi state radio seluler, atau virtual machine yang dijeda sesaat menimbulkan keterlambatan sesaat ratusan ms → Akibatnya RTO habis lebih dulu sehingga paket dikirim ulang, lalu paket aslinya pun segera tiba (penerima menerima duplikat) → Di layar Freeze dan fast forward disebabkan oleh lonjakan latensi itu sendiri. Retransmisi yang tidak perlu hampir tidak menambah lama freeze, tetapi menaikkan metrik retransmisi sehingga disangka packet loss

Gejala: Freeze, Fast forward, Input lag
Faktor: Latensi, Jitter
Siapa yang mengalami: Hanya saya, Seluruh server
Kapan: Sesekali secara acak, Setelah lama diam
Penanggung jawab: Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Di klien Android 10 ke atas, minta mode Wi-Fi latensi rendah selama bermain (Wi-Fi lock WIFI_MODE_FULL_LOW_LATENCY, hanya berlaku saat layar menyala dan game berada di latar depan) untuk mengurangi lonjakan latensi akibat mode hemat daya.
Tugas Tim Infrastruktur: Hindari instance tipe burstable, jangan menurunkan nilai minimum RTO terlalu rendah, pertahankan F-RTO dan timestamp (tcp_frto, tcp_timestamps), baca metrik retransmisi bersama TCPSpuriousRTOs dan TCPDSACKRecv di nstat agar tidak disangka packet loss.
Tugas Pihak Eksternal: Imbau pemain untuk memakai SQM di router dan mematikan mode hemat daya Wi-Fi agar lonjakan latensinya sendiri berkurang.
Kisaran angka: Linux bisa mendeteksi RTO yang tidak perlu dengan F-RTO dan membatalkan penurunan laju kirim. Periksa dengan TCPSpuriousRTOs di nstat (berapa kali RTO dinilai tidak perlu) dan TCPDSACKRecv (berapa kali penerima memberi tahu “sudah pernah diterima”).
Di grafik: Melonjak acak sesekali · RTT (ping), jumlah RTO yang tidak perlu
Yang diperiksa: Jalankan nstat setiap 1 menit dan periksa kenaikan TcpExtTCPTimeouts (RTO habis), TcpExtTCPSpuriousRTOs, TcpExtTCPDSACKRecv, dan TcpExtTCPLostRetransmit secara bersamaan. Jika ada packet capture, pakai filter Wireshark tcp.analysis.spurious_retransmission
Cocok jika: Saat RTO bertambah, TcpExtTCPSpuriousRTOs atau TcpExtTCPDSACKRecv ikut naik, dan pada saat yang sama RTT melonjak ke ratusan ms. Di capture sisi penerima, paket asli dan paket retransmisi sama-sama tiba
Tidak cocok jika: TcpExtTCPSpuriousRTOs dan DSACK tidak berubah, tetapi TcpExtTCPLostRetransmit (paket yang dikirim ulang pun hilang lagi) naik: packet loss sungguhan. RTT tidak melonjak, tetapi DSACK terus banyak: lebih mungkin “Fast retransmit yang tidak perlu akibat urutan paket tertukar”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

Sumber

RFC 5682: Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP IETF
F-RTO: memakai ACK yang datang setelah RTO untuk menentukan apakah RTO itu tidak perlu
RFC 3481: TCP over Second (2.5G) and Third (3G) Generation Wireless Networks IETF
Lonjakan latensi di jaringan seluler (handover, pemulihan di lapisan link, dan lainnya) menimbulkan timeout dan retransmisi TCP yang tidak perlu serta mengecilkan congestion window
RFC 2883: An Extension to the Selective Acknowledgement (SACK) Option for TCP IETF
DSACK: penerima memberi tahu adanya duplikat sehingga pengirim tahu retransmisinya tidak perlu
SNMP counter Linux kernel
TcpExtTCPSpuriousRTOs (RTO tidak perlu yang dideteksi F-RTO), TcpExtTCPDSACKRecv (jumlah DSACK yang diterima), TcpExtTCPLostRetransmit (jumlah laporan SACK bahwa paket yang dikirim ulang hilang lagi)
IP Sysctl Linux kernel
tcp_frto aktif secara default (menguntungkan di jaringan nirkabel yang RTT-nya naik turun), default tcp_timestamps 1
RFC 6298: Computing TCP's Retransmission Timer IETF
Dasar bahwa RTO minimum yang besar diperlukan untuk mencegah retransmisi yang tidak perlu (rekomendasi minimal 1 detik)
WifiManager Android (Google)
WIFI_MODE_FULL_LOW_LATENCY (API 29, Android 10): Wi-Fi lock latensi rendah yang hanya berlaku saat terhubung ke AP, layar menyala, dan aplikasi berada di latar depan
net/ipv4/proc.c Linux kernel
Nama counter yang ditampilkan nstat: TCPTimeouts, TCPSpuriousRTOs, TCPDSACKRecv, TCPLostRetransmit
net/ipv4/tcp_timer.c Linux kernel
TCPTimeouts naik saat timer retransmisi (RTO) habis
nstat(8) — Linux manual page iproute2
Secara default, nstat menampilkan kenaikan sejak eksekusi sebelumnya
Display Filter Reference: Transmission Control Protocol Wireshark
Filter tampilan tcp.analysis.spurious_retransmission

Lihat juga

Lapisan yang sama: Akar penyebab retransmisi TCP

Penyebab di lapisan lain dengan gejala yang sama (Freeze)

Lonjakan frame time L1 Proses game di klien
Garbage collection di klien L1 Proses game di klien
Pemuatan sinkron dan kompilasi shader di main thread L1 Proses game di klien
Streaming aset tertinggal akibat storage lambat L1 Proses game di klien
Pemindaian oleh modul keamanan game (anti-cheat) L1 Proses game di klien
Perpindahan Wi-Fi ↔ LTE/5G L2 OS dan perangkat klien
Kekurangan memori dan swap di klien L2 OS dan perangkat klien
Kekurangan memori grafis (VRAM) L2 OS dan perangkat klien

Lihat kartu interaktif dengan gambar dan simulasi