Facebook ผลการทดลองด้วยอัลกอริธึมควบคุมความแออัดแบบใหม่ - ปรับให้เหมาะสมสำหรับการส่งเนื้อหาวิดีโอ อัลกอริธึมนี้เสนอโดยนักวิจัยจากสถาบันเทคโนโลยีแมสซาชูเซตส์ ต้นแบบ COPA ที่เสนอสำหรับการทดสอบเขียนด้วยภาษา C++ ได้รับอนุญาตภายใต้ MIT และรวมอยู่ใน — การใช้งานโปรโตคอล QUIC ที่ได้รับการพัฒนาบน Facebook
อัลกอริทึม COPA มุ่งเน้นไปที่การแก้ปัญหาที่เกิดขึ้นเมื่อส่งสัญญาณวิดีโอผ่านเครือข่าย ข้อกำหนดที่เกือบจะตรงกันข้ามนั้นขึ้นอยู่กับประเภทของวิดีโอในอัลกอริธึมการควบคุมความแออัด - สำหรับวิดีโอเชิงโต้ตอบนั้นจำเป็นเพื่อให้แน่ใจว่ามีความล่าช้าน้อยที่สุดแม้จะต้องสูญเสียคุณภาพก็ตาม และเมื่อออกอากาศวิดีโอคุณภาพสูงที่เตรียมไว้ล่วงหน้า จะมีการให้ความสำคัญเป็นอันดับแรก เพื่อรักษาคุณภาพ ก่อนหน้านี้ นักพัฒนาแอปพลิเคชันถูกจำกัดความสามารถในการใช้อัลกอริธึมที่แตกต่างกัน ขึ้นอยู่กับคุณภาพหรือข้อกำหนดด้านเวลาแฝง นักวิจัยที่พัฒนา COPA พยายามสร้างอัลกอริธึมสากลสำหรับจัดการความแออัดของวิดีโอ TCP ที่สามารถปรับแต่งตามความต้องการของวิดีโอ
งานของอัลกอริธึมควบคุมความแออัดคือการกำหนดสมดุลที่เหมาะสมที่สุดเมื่อส่งแพ็กเก็ต - การส่งแพ็กเก็ตมากเกินไปอาจทำให้แพ็กเก็ตสูญหายและประสิทธิภาพลดลงเนื่องจากจำเป็นต้องส่งอีกครั้ง และการส่งช้าเกินไปทำให้เกิดความล่าช้า ซึ่งส่งผลเสียต่อประสิทธิภาพด้วย . โปรโตคอล QUIC ได้รับเลือกสำหรับการทดลอง เนื่องจากอนุญาตให้ใช้อัลกอริธึมควบคุมความแออัดในพื้นที่ผู้ใช้โดยไม่รบกวนเคอร์เนล
เพื่อป้องกันความแออัดของช่องการสื่อสาร COPA ใช้การสร้างแบบจำลองลักษณะของช่องสัญญาณโดยอิงจากการวิเคราะห์การเปลี่ยนแปลงในความล่าช้าระหว่างการจัดส่งแพ็คเก็ต (COPA จะลดขนาดของหน้าต่างความแออัดเมื่อความล่าช้าเพิ่มขึ้น โดยจัดการกับความล่าช้าที่เริ่มเพิ่มขึ้นแม้ในขั้นตอนก่อนที่แพ็กเก็ตจะสูญหาย) . ความสมดุลระหว่างความล่าช้าและปริมาณงานจะถูกปรับโดยใช้พารามิเตอร์เดลต้าพิเศษ การเพิ่มเดลต้าจะเพิ่มความไวต่อความล่าช้าแต่จะลดปริมาณงานลง ในขณะที่การลดเดลต้าจะทำให้ปริมาณงานสูงขึ้นโดยมีต้นทุนของเวลาแฝงที่เพิ่มขึ้น Delta=0.04 ถูกกำหนดให้เป็นสมดุลที่เหมาะสมที่สุดระหว่างคุณภาพและเวลาแฝง
จากบริการสตรีมมิ่ง Facebook Live นั้น COPA ได้รับการทดสอบโดยเปรียบเทียบกับอัลกอริธึม CUBIC และ BBR ยอดนิยม อัลกอริธึม CUBIC เริ่มต้นบน Linux คือการค่อยๆ เพิ่มขนาดของหน้าต่างความแออัดจนกระทั่งการสูญเสียแพ็กเก็ตเกิดขึ้น หลังจากนั้นขนาดหน้าต่างจะถูกย้อนกลับเป็นค่าก่อนที่การสูญเสียจะเริ่มขึ้น
CUBIC ปล่อยให้แพ็กเก็ตบัฟเฟอร์บนอุปกรณ์เครือข่ายสมัยใหม่เป็นที่ต้องการอย่างมาก ซึ่งจะทำให้แพ็กเก็ตลดลงช้าลง อัลกอริธึมควบคุมความแออัดไม่ทราบถึงการบัฟเฟอร์ และยังคงเพิ่มความเร็วอย่างต่อเนื่อง แม้ว่าช่องสัญญาณจะมีความแออัดทางกายภาพอยู่แล้วก็ตาม แพ็กเก็ตที่ยังไม่ได้ส่งจะถูกบัฟเฟอร์แทนที่จะทิ้งไป และอัลกอริธึมควบคุมความแออัดของ TCP จะเริ่มทำงานเมื่อบัฟเฟอร์เต็มเท่านั้น และไม่สามารถรักษาสมดุลของอัตราการไหลกับความเร็วของลิงก์ทางกายภาพได้ เพื่อแก้ไขปัญหานี้ Google ได้เสนออัลกอริทึม BBR ที่ปรับปรุงใหม่ ซึ่งจะคาดการณ์แบนด์วิดท์ที่มีอยู่ผ่านการตรวจสอบตามลำดับและการประมาณเวลาไปกลับ (RTT)
ด้วย delta=0.04 ตัวชี้วัด COPA ปรากฏว่าใกล้เคียงกับ CUBIC และ BBR ในการทดสอบที่ดำเนินการผ่านการเชื่อมต่อเครือข่ายความเร็วสูงที่มีความล่าช้าในการส่งแพ็กเก็ตต่ำ COPA มีความหน่วงต่ำกว่า (479 ms) เมื่อเทียบกับ CUBIC (499 ms) แต่ช้ากว่า BBR (462 ms) เล็กน้อย เมื่อคุณภาพการเชื่อมต่อลดลง COPA แสดงผลลัพธ์ที่ดีที่สุด - ความล่าช้าต่ำกว่าเมื่อใช้ CUBIC และ BBR ถึง 27%
ในเวลาเดียวกัน บนช่องทางการสื่อสารที่ไม่ดี COPA และ BBR ทำให้สามารถบรรลุปริมาณงานที่สูงขึ้นอย่างมากเมื่อเทียบกับ CUBIC การเพิ่มขึ้นของ BBR เมื่อเทียบกับ CUBIC คือ 4.8% และ 5.5% และ COPA - 6.2% และ 16.3%
ที่มา: opennet.ru