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