The OpenNET Project / Index page

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

Google опубликовал BBR, новый алгоритм контроля перегрузки TCP

17.09.2016 22:52

Компания Google опубликовала патчи для сетевой подсистемы ядра Linux с реализацией нового алгоритма контроля перегрузки TCP (congestion control) - BBR (Bottleneck Bandwidth and RTT). Внедрение BBR во внутренней сети Google позволило значительно увеличить пропускную способность и сократить задержки передачи данных для трафика с google.com и YouTube. BBR требует внесения изменений только на стороне отправителя, программное обеспечение сетевой инфраструктуры и принимающей стороны остаётся без изменений.

В отличие от классических алгоритмов Reno и CUBIC, использующих потерю пакетов в качестве индикатора перегрузки, в BBR применяются методы моделирования канала связи, прогнозирующие имеющуюся пропускную способность через последовательные проверки и оценку времени приема-передачи (RTT), но не доводя до потери пакетов или задержек в передаче. На начальной стадии соединения BBR оценивает потолок пропускной способности канала, затем снижает интенсивность отправки для разгрузки очереди и переходит в режим корректировки, то повышая, то снижая интенсивность отправки, балансируя между максимальной пропускной способностью и незаполненностью очереди пакетов (борьба с промежуточной буферизацией).

  1. Главная ссылка к новости (https://patchwork.ozlabs.org/p...)
  2. OpenNews: Открыт код Remy, системы динамической генерации алгоритмов контроля перегрузки TCP
  3. OpenNews: Доступна тестовая версия CeroWrt, ответвления от проекта OpenWRT
  4. OpenNews: Проект по избавлению Linux-ядра от излишней сетевой буферизации
  5. OpenNews: FreeBSD Foundation профинансирует создание 5 модулей контроля перегрузки TCP
  6. OpenNews: Google исправил ошибку, около 10 лет присутствующую в TCP-стеке ядра Linux
Лицензия: CC-BY
Тип: Программы
Ключевые слова: tcp, bufferbloat
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (20) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, Аноним (-), 23:42, 17/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Чем лучше Remy? https://www.opennet.ru/opennews/art.shtml?num=37482

    Локальная сеть google это вам не WAN с кучей вредителей которые только и ждут использовать больно умные алгоритмы для повышения аттаки.

     
     
  • 2.2, Специалист по всему (?), 00:28, 18/09/2016 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Тем что BBR это патч для линукса, который можно скомпилить и включить, а Remy это исследовательский прототип, который полюбому тормозит или вообще работает не в реалтайме, а в симуляторе.
     
  • 2.3, kleemhead (?), 03:03, 18/09/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >Локальная сеть google это вам не WAN

    Вот вот. Взять их оптику в нищих районах пендосии, кэш-серверы ютьюба у ВСЕХ крупных провайдеров, слегка принять во внимание инфраструктуру дата-центров и возвести в квадрат. Как-то так можно оценить их WAN. А в остальном, прекрасная маркиза, все хорошо, все хорошо.

     
  • 2.7, Аноним (-), 18:05, 18/09/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Локальная сеть google это вам не WAN с кучей вредителей

    У гугля локальной сетью с их ютубом - вся планета. И тут то как раз оказывается что существующие существующие алгоритмы работают с всякими wi-fi и 4G просто никак.

    Например в беспроводных сетях некоторое выпадение пакеров - обычное явление и может быть следствием помех, движения или просто попыткой прокачать больше чем физический уровень может обеспечить, от чего все эти рено и кубики плющит. Они начинают осциллировать (!!!) и постепенно загоняют себя в режим когда данные почти не идут вообще. Скорость прокачки становится спасибо если треть возможностей канала.

    > больно умные алгоритмы для повышения аттаки.

    Кубики и рено в беспроводных сетях сами себя DoS'ят. Что гуглу не нравится - у пользователей ютуб икает. Единственный кто всерьез это учитывает из существующих - CDG (caia delay gradient) который использует чем-то похожие подходы и с недавних пор включен в ядро Linux. С ним по беспроводке скорость может быть куда лучше. Но гугл видимо нашел фатальный недостаток: cdg придумали не они.

     

  • 1.4, rm_ (ok), 12:25, 18/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Им стоило бы начать с объяснения чем не устроил Illinois, кроме того что НеизобретёнЗдесь. Или их хрень лучше только древних рено и кубика?
     
     
  • 2.8, Аноним (-), 18:17, 18/09/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Им стоило бы начать с объяснения чем не устроил Illinois, кроме того
    > что НеизобретёнЗдесь. Или их хрень лучше только древних рено и кубика?

    По беспроводным сетям из того что в Linux есть сколь-нибудь вменяемо работает разве что cdg. Который есть только в паре свежих версий ядер Linux.

    Упомянутый алгоритм чем-то напоминает подходы cdg, но немного с другой стороны.

     

  • 1.5, Baz (?), 12:31, 18/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Бибер?
     
  • 1.6, Ivan_83 (ok), 14:51, 18/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Кубик и рено не лучшие, оно и не удивительно.
    Но есть htcp, hybla которые в локалках весьма работают, да и в диком инете тоже.
    Тестов что то не видать.
     
     
  • 2.9, iZEN (ok), 00:37, 19/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >Кубик и рено не лучшие, оно и не удивительно.

    Неудивительно. Ведь они придуманы в эпоху проводных сетей с последующей адаптацией к реалиям.

    https://habrahabr.ru/post/168407/
    ///---
    К сожалению, CUBIC, который используется по умолчанию во всех дистрибутивах, совершенно не подходит, например, для 3G-соединений.
    <...>
    Как видите, CUBIC в отстающих. Он значительно повысил RTT на полной утилизации 3G канала, в то время как Westwood+ и NewReno более-менее справляются с этой проблемой.
    <...>
    Как видно из графика, у CUBIC относительно большое количество ретрансмиссий
    <...>
    В то же время, он лидирует в скорости передачи данных за единицу времени.

    Что это значит? Это значит, что с использованием Westwood+ или NewReno вы сможете комфортней серфить интернет, пока у вас скачивается большой файл.
    ---///

     
     
  • 3.13, Аноним (-), 20:13, 19/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Поэтому в Linux рулит CDG. А что рулит в bsd? Или их еще не отпустило?
     
     
  • 4.16, iZEN (ok), 20:52, 19/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Поэтому в Linux рулит CDG. А что рулит в bsd?

    Во Фре NewReno по умолчанию.

    А так:
    /boot/kernel/cc_cdg.ko
    /boot/kernel/cc_chd.ko
    /boot/kernel/cc_hd.ko
    /boot/kernel/cc_htcp.ko
    /boot/kernel/cc_cubic.ko
    /boot/kernel/cc_dctcp.ko
    /boot/kernel/cc_vegas.ko
    Что загрузишь - то и будет.

    > Или их еще не отпустило?

    В смысле?

     
     
  • 5.17, Аноним (-), 19:41, 20/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Этот NewReno - как и в линуксах докостыленный вариант reno? :) Хз как в бсд но в линуксах тамошний пиленый-перепиленый рено не сильно дружит с беспроводкой. CDG интересен тем что рассматривает delay gradient как критерий перегрузки. Потери пакетов его не очень смущают, ему рост RTT важенее и это куда более удачный критерий на беспроводке. На неидеальном беспроводном канале это работает лучше. На остальных каналах это тоже вполне адекватный критерий как правило. Сабж судя по описанию чем-то похож, он тоже не считает потери пакетов главным критерием для понижения скорости. А всякие reno/vegas и подобные по смыслу из-за излишнего упования на потери пакетов как критерий душат скорость соединения на ровном месте, а то и вовсе коллапсируют.
     
  • 3.19, Ivan_83 (ok), 20:15, 20/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Болт на них - ламеры :)
    Я сам для себя тестил в немного других условиях:
    RTT > 70
    потери пакетов
    При этом мне нужен был поток стабильный в 4-10 мегабит - смотрел IPTV через пол страны: Иркутск-Москва.

    Короче: всё говно кроме hybla и htcp, притом последний тоже не очень то работал.
    hybla - единственно с чем поток был стабильный и просмотр без залипаний.
    htcp - он лучше hybla когда RTT по меньше и потерь меньше, особенно это заметно в локалках.

    И вывод них тоже идиотский, ведь важно какой СС на сервере а не у тебя, потому что сёрфинг+скачивание - это всё получение данных с сервера.

     

  • 1.10, iZEN (ok), 00:57, 19/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Как включить нужный алгоритм Congestion Control TCP во FreeBSD

    1. Что имеем в текущий момент:

    % sysctl net.inet.tcp.cc.algorithm
    net.inet.tcp.cc.algorithm: newreno

    % sysctl net.inet.tcp.cc.available
    net.inet.tcp.cc.available: newreno

    2. Смотрим, какие модули нам доступны:

    % ls /boot/kernel/cc_*
    /boot/kernel/cc_cdg.ko /boot/kernel/cc_hd.ko
    /boot/kernel/cc_chd.ko /boot/kernel/cc_htcp.ko
    /boot/kernel/cc_cubic.ko /boot/kernel/cc_vegas.ko
    /boot/kernel/cc_dctcp.ko

    (FreeBSD 11.0-PRERELEASE)

    3. Выбираем алгоритм, например, Vegas.

    3.1. Загружаем нужный модуль:

    % kldload cc_vegas

    Проверяем:

    % sysctl net.inet.tcp.cc.available
    net.inet.tcp.cc.available: newreno, vegas

    3.2. Переключаемся на него:

    % sysctl net.inet.tcp.cc.algorithm=vegas
    net.inet.tcp.cc.algorithm: newreno -> vegas

    Проверяем:

    % sysctl net.inet.tcp.cc.algorithm
    net.inet.tcp.cc.algorithm: vegas

    Испытываем радость или печаль - в зависимости от предъявляемых требований и удовлетворения ожиданий.

     
     
  • 2.20, Ivan_83 (ok), 20:20, 20/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Это ты мне рассказываешь?)))

    У меня мой msd/msd_lite умеет выставлять алгоритмы на сокеты.
    Те можно на соединения принимаемые с биндиного сокета на 192.168.0.1 выставлять htcp,
    а на соединения принимаемые с сокета прибинденого на 172.16.0.1 ставить скажем vegas (чтобы они страдали :) ).

    И потом у меня лежит hybla для фри, сам портировал...
    Но у фри там что то сломано относительно линуха, потому что я тестил htcp который есть и там и там и фря у меня сливала 3-5 раз по скорости.

     
     
  • 3.21, iZEN (ok), 20:10, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    А CDG не пробовали на FreeBSD 11.1-BETA2?
     

  • 1.11, AS (??), 18:41, 19/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >>> BBR оценивает потолок пропускной способности канала

    непонял я что эти горбы под 1000Мгб/s в Заббиксе наблюдать должен ?

     
     
  • 2.12, Аноним (-), 19:03, 19/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    10G 40G 100G
     
  • 2.14, mumu (??), 20:29, 19/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Эта технология хороша только для 100% загруженных каналов, где ориентироваться постоянно только на потери, это значит иметь постоянно проблемы с потерями. Там эта технология выглядит логичной и полезной.
     
     
  • 3.18, Аноним (-), 19:43, 20/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Если канал не имеет потерь и не загружен на 100% то и планировщик ему не требуется по большому счету - что так пакеты можно немедленно слать что эдак. Проблемы начинаются когда эта идилия нарушается. И совсем не круто если то RTT уходит в небеса, то кач со скоростью 30% канала.
     
  • 2.15, mumu (??), 20:31, 19/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    В таких 100% загруженных сетях вы будете на графиках видеть только "горбы" пропавших пакетов. А с этой технологией как-раз всё будет тихо-мирно ;)
     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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