The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Facebook протестировал новый алгоритм контроля перегрузки COPA в сравнении с BBR и CUBIC

19.11.2019 11:55

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%.



  1. Главная ссылка к новости (https://engineering.fb.com/vid...)
  2. OpenNews: Компания Google представила рекомендации по ускорению работы TCP
  3. OpenNews: Google опубликовал BBR, новый алгоритм контроля перегрузки TCP
  4. OpenNews: Представлен SRT, открытый протокол для потоковой передачи видео
  5. OpenNews: Открыт код Remy, системы динамической генерации алгоритмов контроля перегрузки TCP
  6. OpenNews: Google исправил ошибку, около 10 лет присутствующую в TCP-стеке ядра Linux
Лицензия: CC-BY
Тип: К сведению
Ключевые слова: copa, cubic, bbr, quic
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (13) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.6, Ivan_83 (ok), 15:52, 19/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Почти всё что угодно работает лучше чем CUBIC или newreno - дефолты линуха и фряхи, просто потому что они для средней температуры по больнице.

    Для потокового видео на всяких линках с большим RTT (50+мс) и потерями у меня очень хорошо работали hybla и htcp.
    Притом на момент тестов htcp в линухе работал сильно лучше чем во фряхе (при максимально одинаковых настройках стёков), тогда она кажется была ещё 10.х.
    До гуглового у меня руки не дошли попробовать.


    Ещё забавно, но они видимо не в курсе, что приложение может для каждого отдельного сокета выставлять свой СС, те можно в одном приложении юзать CUBIC, newreno, htcp, hybla и что угодно ещё на разных сокетах, разом.
    Те если видим что нужны малые задержки - ставим один СС, если гоним потокове видео или файл - другой СС и нет проблем.
    Не обязательно извращатся и делать мегаумный и мегасложный СС который сам эвристиками будет разруливать.

     
  • 1.1, Аноним (1), 12:50, 19/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    Я перешёл с yeah на htcp. Разницы не заметил, поскольку потери нездоровая тема. Ну т.е. между westwood и htcp разницы точно 0 было, а вот насчёт cubic не уверен. Для bbr нужно включать QoS, я ещё подумаю об этом.
     
     
  • 2.7, Ivan_83 (ok), 15:58, 19/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ох, дай угадаю: ты тестировал westwood и htcp скачивая файлик к себе?)
    Тогда у меня интересная инфа: СС отрабатывает только на передачу.

    westwood и элинойс и ещё что то из старья - вообще полный мусор, у меня они в локалке даже 100м не могли заполнить в один конект.

    htcp - очень быстро разгоняется, он сразу линк в полку забивает и старается так держать, но в случае потерь восстанавливает скорость несколько хуже, чем hybla.

    hybla тоже не плохо рагоняется на старте, но всё же у неё плавный старт а не взрывообразный, но фишка в том, что она очень корректно держит скорость при потерях и rtt от 50 ей не мешает.

    кубик, ньюрено и кто то там ещё - так, середнячки, не полный мусор но и толку с них мало.

    Ещё когда то на швабре была статья с тестированием разных СС, у них результаты не релевантные моим получились.

     
     
  • 3.10, Аноним (1), 16:20, 19/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не, раздавал файлы для китайского ботнета. На кубике передача падала до нуля каждые несколько секунд, была такая лесенка. Когда поменял, до нуля больше не провисало. А вествуд на файфае лучше был емнип, так что не так уж и плох он.
     

  • 1.2, Аноним (2), 13:15, 19/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    Они ошибочно считают, что всё видео должно быть потоковым.
     
     
  • 2.4, Andrey Mitrofanov_N0 (??), 14:06, 19/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Они ошибочно считают, что

    ...у них есть свой интернет, как у гугля.

    >всё видео должно быть потоковым.

     
     
  • 3.11, Имя (?), 17:06, 19/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >свой интернет

    https://en.wikipedia.org/wiki/Internet.org
    не взлетел

     

  • 1.3, Аноним (3), 13:43, 19/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    На первый взгляд отдает чем-то похожим на ledbat
     
  • 1.5, little Bobby tables (?), 14:10, 19/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Здесь интересно совместное проживание устройств с разными алгоритмами в одной сетке. Ведь вроде как BBR душит CUBIC  - соединения с BBR забирают полосу у кубиковских.  
     
     
  • 2.8, Ivan_83 (ok), 16:00, 19/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну забирают, и фиг с ними.
    Кубик вообще фуфел.

    У меня msd умеет в рамках одного приложения на разные биндинги вешать разные СС :)
    Те СС можно задавать для конкретного сокета, а не только для всей системы разом. Это работает на фре и линухах.

     
     
  • 3.12, little Bobby tables (?), 17:56, 19/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Если новый алгоритм вытесняет и кубик и ббр, то и вашему фуфелу на всех биндингах, сокетах, фряхах и линухах  не поздоровится. ну и фиг с ним. продолжайте наблюдение.
     

  • 1.9, Иван (??), 16:07, 19/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Крутота, спасибо Facebook, ушел делать убийцу YouTube
     
  • 1.14, Michael Shigorin (ok), 22:55, 21/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Да уж, пейсбук и перегрузка сора -- прям символично.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру