ชุมชนเครือข่ายกำลังถกเถียงกันว่าถึงเวลาแล้วหรือไม่ที่จะเพิ่มหน้าต่างการแออัดเริ่มต้นของ TCP อีกครั้ง หลังจากที่ Google ผลักดันให้เพิ่มจาก 1 เป็น 10 แพ็กเก็ตเมื่อปี 2011 เนื่องจากหน้าเว็บมีขนาดใหญ่ขึ้นอย่างมากในช่วงทศวรรษที่ผ่านมา มาตรฐานปัจจุบันอาจไม่เพียงพอสำหรับประสิทธิภาพที่เหมาะสมแล้ว
วิวัฒนาการของ TCP Initial Congestion Window
- ก่อนปี 2010: 1-3 แพ็กเก็ต (1.5-4.5 KB)
- 2011-ปัจจุบัน: 10 แพ็กเก็ต (~15 KB)
- ข้อเสนอ: 20-40 แพ็กเก็ต (30-60 KB)
- ความครอบคลุมที่ 10 แพ็กเก็ต: ~85% ของ assets ในการเดินทางไปกลับครั้งเดียว (ข้อมูลปี 2011)
ความท้าทายทางเทคนิคของการใช้งานปัจจุบัน
ข้อเสนอให้เพิ่มหน้าต่างการแออัดเริ่มต้นจาก 10 เป็นประมาณ 20 ถึง 40 แพ็กเก็ต เผชิญกับอุปสรรคทางเทคนิคที่สำคัญ วิศวกรเครือข่ายชี้ให้เห็นว่าการเพิ่มค่านี้อย่างง่ายๆ อาจส่งผลเสียอย่างรุนแรง ความกังวลหลักเกี่ยวข้องกับการสูญเสียแพ็กเก็ตปลายทาง - เมื่อแพ็กเก็ตที่ส่วนท้ายของการส่งข้อมูลถูกทิ้ง ทำให้การเชื่อมต่อทั้งหมดต้องชะลอตัวลงและกู้คืน
การสูญเสียแพ็กเก็ตปลายทาง: เมื่อแพ็กเก็ตสุดท้ายในการส่งข้อมูลสูญหาย ทำให้เกิดการลดประสิทธิภาพประเภทที่แย่ที่สุดสำหรับโปรโตคอลหน้าต่างเลื่อนอย่าง TCP
ผู้เชี่ยวชาญในชุมชนเน้นย้ำว่าหน้าต่างการแออัดเริ่มต้นทำงานก่อนที่อัลกอริทึมควบคุมการแออัดใดๆ จะมีเวลาเรียนรู้เกี่ยวกับสภาพเครือข่าย สิ่งนี้ทำให้การตัดสินใจมีความเสี่ยงเป็นพิเศษ เนื่องจากไม่มีกลไกป้อนกลับที่จะแนะนำการเลือกในช่วงเวลาสำคัญแรกๆ ของการเชื่อมต่อ
ข้อจำกัดของอัลกอริทึม BBR
แม้ว่าบทความต้นฉบับจะแนะนำให้ใช้อัลกอริทึมควบคุมการแออัด BBR ของ Google ร่วมกับหน้าต่างเริ่มต้นที่สูงขึ้น แต่ผู้เชี่ยวชาญด้านเครือข่ายแสดงความสงสัยเกี่ยวกับแนวทางนี้ BBR ใช้เวลามากในการวนซ้ำผ่านขั้นตอนการเรียนรู้ หมายความว่าให้ประโยชน์น้อยในช่วงแรกๆ ของการเชื่อมต่อเมื่อหน้าต่างเริ่มต้นมีความสำคัญมากที่สุด
การที่อัลกอริทึมมุ่งเน้นไปที่การตรวจสอบความแปรปรวนของเวลาไปกลับเพื่อตรวจจับการแออัด แทนที่จะพึ่งพาการสูญเสียแพ็กเก็ตเพียงอย่างเดียว ไม่ได้แก้ไขความท้าทายพื้นฐานของการเลือกจุดเริ่มต้นที่เหมาะสมโดยไม่มีความรู้เกี่ยวกับเครือข่าย
อัลกอริทึมควบคุมความแออัดที่กล่าวถึง
- TCP New Reno: อัลกอริทึมแบบดั้งเดิมที่อิงตามการสูญเสียข้อมูล
- CUBIC: ค่าเริ่มต้นปัจจุบันในระบบส่วนใหญ่
- BBR: อัลกอริทึมของ Google ที่อิงตามความล่าช้าและเน้นการประเมินแบนด์วิดท์
- TCP Vegas, Reno, TCTP: ทางเลือกต่างๆ ที่มีแนวทางแตกต่างกัน
ความเข้าใจผิดเกี่ยวกับโปรโตคอล QUIC
การแก้ไขทางเทคนิคที่สำคัญเกิดขึ้นเกี่ยวกับพฤติกรรมของโปรโตคอล QUIC ตรงข้ามกับการอ้างว่า QUIC กำจัดหน้าต่างการแออัดทั้งหมด โปรโตคอลนี้ใช้อัลกอริทึมควบคุมการแออัดเดียวกันกับ TCP รวมทั้ง CUBIC และ BBR QUIC ไม่ได้แก้ปัญหาการจัดการแบนด์วิดธ์อย่างมหัศจรรย์ - ยังคงต้องเคารพข้อจำกัดความจุของเครือข่าย
การใช้งาน QUIC โดยทั่วไปใช้อัลกอริทึมควบคุมการแออัดเดียวกัน รวมทั้ง CUBIC และ BBR อย่างน้อยก็ในนาม
นี่หมายความว่าแม้ขณะที่ Google และผู้เล่นรายใหญ่อื่นๆ ย้ายไปใช้ QUIC ความท้าทายในการควบคุมการแออัดพื้นฐานยังคงมีความเกี่ยวข้องสำหรับทั้งสองโปรโตคอล
Bufferbloat ยังคงเป็นปัญหาจริง
การอภิปรายเผยให้เห็นความไม่เห็นด้วยที่ยังคงมีอยู่เกี่ยวกับผลกระทบปัจจุบันของ bufferbloat ต่อประสิทธิภาพอินเทอร์เน็ต ในขณะที่บางคนโต้แย้งว่าเป็นปัญหาที่ถูกพูดเกินจริงจากช่วงปี 2010 คนอื่นๆ ให้ตัวอย่างที่เป็นรูปธรรมของผลกระทบที่ยังคงมีอยู่ เครือข่ายมือถือ โดยเฉพาะบริการอินเทอร์เน็ตบ้าน 5G ยังคงแสดงปัญหา bufferbloat ที่สำคัญ ซึ่งเวลา ping เพิ่มขึ้นอย่างมากระหว่างการถ่ายโอนข้อมูล
ผู้ให้บริการเครือข่ายรายงานความสำเร็จในการใช้เทคนิคการจัดการคิวแบบแอคทีฟอย่าง fq_codel และ CAKE เพื่อแก้ไขปัญหาเหล่านี้ แสดงให้เห็นว่าปัญหาไม่ได้หายไป แต่ต้องการความสนใจอย่างต่อเนื่อง
Bufferbloat: เมื่ออุปกรณ์เครือข่ายใช้บัฟเฟอร์ที่มีขนาดใหญ่เกินไป ทำให้แพ็กเก็ตต้องรอนานเกินไปในคิวแทนที่จะถูกทิ้ง ส่งผลให้เกิดความล่าช้าที่เพิ่มขึ้น
โซลูชันการจัดการคิวแบบแอคทีฟ
- fq_codel: การจัดคิวแบบยุติธรรมพร้อมการควบคุมความล่าช้า
- CAKE: Common Applications Kept Enhanced
- L4S: Low Latency, Low Loss, Scalable Throughput
- ใช้เพื่อต่อสู้กับปัญหา bufferbloat ในอุปกรณ์เครือข่ายสมัยใหม่
ความท้าทายในการนำไปใช้ในองค์กร
ความเป็นจริงของการจัดการเครือข่ายองค์กรเพิ่มความซับซ้อนอีกชั้นหนึ่ง องค์กรหลายแห่งปิดการใช้งาน QUIC ทั้งหมด บังคับให้ย้อนกลับไปใช้การเชื่อมต่อ TCP สิ่งนี้เกิดขึ้นเพราะผู้จำหน่ายไฟร์วอลล์ส่วนใหญ่ไม่สามารถตรวจสอบทราฟฟิก QUIC ได้ ทำให้เกิดความกังวลด้านความปลอดภัยสำหรับผู้ดูแลเครือข่าย
พฤติกรรมขององค์กรที่แพร่หลายนี้หมายความว่าการเพิ่มประสิทธิภาพ TCP ยังคงมีความสำคัญสำหรับส่วนสำคัญของทราฟฟิกอินเทอร์เน็ต แม้ว่าโปรโตคอลใหม่จะได้รับการนำไปใช้ในสภาพแวดล้อมผู้บริโภค
ชุมชนเครือข่ายยังคงชั่งน้ำหนักประโยชน์ที่อาจเกิดขึ้นจากหน้าต่างการแออัดเริ่มต้นที่สูงขึ้นเทียบกับความเสี่ยงของการแออัดของเครือข่ายที่เพิ่มขึ้น ในขณะที่แอปพลิเคชันเว็บสมัยใหม่จะได้รับประโยชน์จากการส่งข้อมูลเริ่มต้นที่เร็วขึ้น แต่การแก้ปัญหาต้องการการพิจารณาอย่างรอบคอบเกี่ยวกับความเสถียรของเครือข่ายและความเป็นธรรมสำหรับผู้ใช้ทุกคน
อ้างอิง: An Argument for Increasing TCP's Initial Congestion Window... Again