Facebook результати експериментів з новим алгоритмом контролю навантаження (congestion control) , оптимізованим для передачі відеоконтенту Алгоритм запропоновано дослідниками з Массачусетського технологічного інституту. Запропонований для тестування прототип COPA написаний на С++, під ліцензією MIT та включений до складу - Реалізація протоколу QUIC, що розвивається у Facebook.
Алгоритм COPA орієнтований вирішення проблем, що виникають під час передачі відео мережі. Залежно від типу відео до алгоритмів контролю навантаження пред'являються практично протилежні вимоги — для інтерактивного відео потрібно забезпечити мінімальні затримки, навіть на шкоду якості, а при трансляції заздалегідь підготовленого високоякісного відео пріоритет надається збереженню якості. Раніше розробники додатків були обмежені можливістю застосовувати різні алгоритми залежно від вимог до якості або затримок. Дослідники, які розробили COPA, спробували створити універсальний алгоритм для управління перевантаженням TCP під час передачі відео, який може налаштовуватися залежно від вимог, що висуваються до відео.
Робота алгоритму контролю перевантаження полягає у визначенні оптимального балансу при відправленні пакетів - відправлення занадто великого обсягу пакетів може призвести до втрати пакетів і просідання продуктивності через необхідність їх повторного відправлення, а надто повільне відправлення призводить до затримок, які також негативно позначаються на продуктивності. Для експериментів обраний протокол QUIC, оскільки він дозволяє реалізувати роботу алгоритмів контролю навантаження у просторі користувача, не втручаючись у ядро.
Для запобігання навантаженню каналу зв'язку в COPA застосовується моделювання характеристик каналу на основі аналізу зміни затримок при доставці пакетів (COPA зменшує розмір вікна перевантаження при збільшенні затримок, маніпулюючи тим, що затримки починають збільшуватися ще на стадії до втрати пакетів). Баланс між затримками та пропускною здатністю регулюються за допомогою спеціального параметра delta. Збільшення delta призводить до підвищення чутливості до затримок, але знижує пропускну здатність, а зменшення дозволяє досягти більш високої пропускної здатності за рахунок збільшення затримок. Значення 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 показав найкращі результати – затримки виявилися на 27% нижчими, ніж при використанні CUBIC та BBR.
При цьому на поганому каналі зв'язку COPA і BBR дозволили досягти значно більш високої пропускної здатності, порівняно з CUBIC. Виграш BBR, порівняно з CUBIC, становив – 4.8% та 5.5%, а COPA – 6.2% та 16.3%.
Джерело: opennet.ru