คู่มือเกมแลค › ต้นเหตุของการส่งซ้ำใน TCP
คิวคอขวดล้น (แพ็กเก็ตหายจากความแออัด) Tail drop at a congested bottleneck
ID สาเหตุ rt-queue-drop · ผู้รับผิดชอบหลัก อินฟราเครือข่าย (ทีมอินฟรา) · ร่วมกับ ภายนอก (ภายนอก), พัฒนาไคลเอนต์ (ทีมพัฒนาเกม)
เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →
จุดที่แคบที่สุดบนเส้นทาง เช่น เราเตอร์, ลิงก์เชื่อมระหว่าง ISP หรือลิงก์ของดาต้าเซ็นเตอร์ เมื่อคิวตรงนั้นเต็ม แพ็กเก็ตที่มาใหม่จะถูกทิ้ง
ทำไม วิดีโอ, การดาวน์โหลด และทราฟฟิกของผู้ใช้คนอื่นทำให้ช่วงคอขวดเต็ม → ผลคือ ระหว่างที่คิวเต็ม แพ็กเก็ตที่มาใหม่ถูกทิ้งติดต่อกัน (tail drop) แพ็กเก็ตที่ไม่ถูกทิ้งก็ต้องรออยู่ท้ายคิวที่เต็มแน่น → บนหน้าจอ แพ็กเก็ตหายหลายตัวพร้อมกัน จึงค้างนานแล้วตามด้วยอาการกรอเร็ว เป็นบ่อยช่วงหัวค่ำ
- อาการ
- ค้าง, กรอเร็ว, ดีดกลับ
- ปัจจัย
- แพ็กเก็ตหาย, ความหน่วง
- ใครเจอ
- คนในบ้านเดียวกัน, บางพื้นที่/บาง ISP, ทั้งเซิร์ฟเวอร์
- เกิดเมื่อไร
- ช่วงพีคหัวค่ำ, ตอนคนแห่มารวมกัน
- ผู้รับผิดชอบ
- ผู้รับผิดชอบหลัก อินฟราเครือข่าย (ทีมอินฟรา) · ร่วมกับ ภายนอก (ภายนอก), พัฒนาไคลเอนต์ (ทีมพัฒนาเกม)
- งานฝั่งทีมพัฒนาเกม
- แสดงสถานะเครือข่ายบนจอเมื่อแพ็กเก็ตหายติด ๆ กันหรือปิงพุ่ง (แจ้งว่าอาจมีการส่งข้อมูลปริมาณมากบนเน็ตเดียวกัน)
- งานฝั่งทีมอินฟรา
- เผื่อแบนด์วิดท์ของลิงก์ดาต้าเซ็นเตอร์ให้พอ, ตรวจตัวนับการทิ้งจากคิว (output drops) ของลิงก์และพอร์ตสวิตช์ของเรา, ถ้าช่วงของ ISP ตันให้อ้อมไปใช้ลิงก์หรือ peering อื่น
- งานฝั่งภายนอก
- แนะนำให้ผู้เล่นเปิด SQM (fq_codel, CAKE) และ ECN บนเราเตอร์ (ให้ลดความเร็วก่อนที่คิวจะล้น), ขอให้ ISP ขยายช่วงที่เป็นคอขวด
- ตัวเลขที่ควรรู้
- ช่วงที่คิวล้น แพ็กเก็ตจำนวนมากที่เข้ามาในช่วงหลายสิบ ms นั้นจะหายไปพร้อมกัน แพ็กเก็ตมักหายติดกันและตัวที่ส่งซ้ำก็มักหายอีก จึงมักลากยาวไปจนถึง RTO
- บนกราฟ
- สูงเฉพาะบางช่วงเวลา · อัตราการส่งซ้ำ, RTT (ปิง)
- จุดที่ต้องดู
- อัตราการส่งซ้ำของเซิร์ฟเวอร์ (ค่าที่เพิ่มขึ้นของ TcpRetransSegs ÷ TcpOutSegs จากการรัน nstat ทุก 1 นาที) และ RTT ต่อการเชื่อมต่อ แยกตามพื้นที่, ISP และช่วงเวลา ดูคู่กับการทิ้งขาออก (ifOutDiscards) ของลิงก์และพอร์ตสวิตช์ของเรา รัน mtr ไปยังพื้นที่ที่มีปัญหาทั้งช่วงพีคและช่วงที่คนน้อยแล้วเทียบกัน
- สัญญาณว่าใช่
- อัตราการส่งซ้ำขึ้นเฉพาะช่วงพีคหัวค่ำ และ RTT ขึ้นก่อนแพ็กเก็ตจะหาย (คิวกำลังเต็ม) ใน mtr แพ็กเก็ตหายและความหน่วงเพิ่มพร้อมกันตั้งแต่ hop หนึ่งไปจนสุดทาง เฉพาะช่วงพีค
- สัญญาณว่าไม่ใช่
- RTT ไม่ขึ้นก่อนแพ็กเก็ตหาย: น่าจะเป็น “policer ทิ้งส่วนที่เกิน” ถ้าหายในระดับใกล้เคียงกันตลอดไม่ว่าช่วงเวลาไหน น่าจะเป็น “ข้อผิดพลาดทางกายภาพ” หรือ “เส้นทางเปลี่ยน/เส้นทาง ECMP ที่เสีย”
- วิธีตรวจ
- ใช้เครื่องมือฝั่งอินฟรา (ไม่ต้องใช้โค้ดเกม)
- กรณีจริง
- Riot Games 2015: ทราฟฟิก League of Legends ที่วิ่งอ้อมไปไกล และ Riot Direct
แหล่งอ้างอิง
- RFC 7567: IETF Recommendations Regarding Active Queue Management IETF
คำอธิบายว่า tail drop ทำให้คิวเต็มอยู่นาน ความหน่วงจึงเพิ่มและแพ็กเก็ตหายเป็นกลุ่ม พร้อมคำแนะนำให้ใช้ AQM - RFC 8290: The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm IETF
fq_codel: ใช้คิวแยกตาม flow และ AQM รักษาคิวให้สั้นเพื่อลด bufferbloat - RFC 3168: The Addition of Explicit Congestion Notification (ECN) to IP IETF
ECN: แจ้งความแออัดด้วยการทำเครื่องหมายใน IP header แทนการทิ้งแพ็กเก็ต - Smart Queue Management Bufferbloat.net
SQM: วิธีที่ใช้ scheduling แยกตาม flow, การจัดการความยาวคิว (AQM) และ shaping ร่วมกัน - Cake Bufferbloat.net
CAKE: SQM สำหรับเราเตอร์ที่รวม shaper กับการจัดการคิวตระกูล fq_codel ไว้ด้วยกัน - net/ipv4/proc.c Linux kernel
TcpRetransSegs และ TcpOutSegs ที่แสดงใน nstat (RetransSegs และ OutSegs ในหมวด Tcp) - nstat(8) — Linux manual page iproute2
โดยค่าเริ่มต้น nstat แสดงค่าที่เพิ่มขึ้นนับจากการรันครั้งก่อน - RFC 2863: The Interfaces Group MIB IETF
ifOutDiscards: จำนวนแพ็กเก็ตที่ถูกทิ้งโดยไม่ได้ส่งออกทั้งที่ไม่มี error ด้วยเหตุผล เช่น เพื่อคืนพื้นที่บัฟเฟอร์ - An Internet-Wide Analysis of Traffic Policing Google
การแยกแยะว่าคิวล้นจะทำให้เวลารอและ RTT ขึ้นก่อนแพ็กเก็ตหาย ส่วน policing ทิ้งส่วนที่เกินโดยที่ RTT ไม่เพิ่ม (SIGCOMM 2016)
สาเหตุที่ควรดูประกอบ
ชั้นเดียวกัน: ต้นเหตุของการส่งซ้ำใน TCP
สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (ค้าง)
ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง