Facebook опубликовал результаты экспериментов с новым алгоритмом контроля перегрузки (congestion control) - COPA, оптимизированным для передачи видеоконтента. Алгоритм предложен исследователями из Массачусетского технологического института. Предложенный для тестирования прототип COPA написан на С++, открыт под лицензией MIT и включён в состав mvfst - развиваемой в Facebook реализации протокола QUIC.

Алгоритм 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%.