BBR рулит, но есть нюанс, когда алгоритмы из нулевых понимают ваш Wi-Fi лучше

В сфере искусственного интеллекта произошло заметное событие. poige 19 минут назад BBR рулит, но есть нюанс, когда алгоритмы из нулевых понимают ваш Wi-Fi лучше Простой 5 мин 840 Сетевые технологии * Linux * BBR принято считать современным стандартом TCP congestion control. Google разработал его в 2016 году, он работает в production крупнейших CDN, его хвалят в каждой второй статье о сетевой оптимизации. И всё это заслуженно — но с существенной оговоркой, о которой обычно не пишут.

Почему BBR хорош — и где именноBBR (Bottleneck Bandwidth and Round-trip propagation time) отказывается от базового принципа большинства предшественников — считать потерю пакета признаком перегрузки. Вместо этого он строит модель пути — измеряет максимальную достигнутую полосу и минимальный RTT, и держит окно отправки соответствующим этой модели. На WAN-линках с высоким BDP (bandwidth-delay product) это работает блестяще — по двум причинам.

Технические детали

Во-первых, CUBIC (по-умолчанию в Linux с 2006 года) после потери пакета снижает окно на 30 % и восстанавливает его по кубической функции от времени: на линке 10 Gbps с RTT 100 мс возврат к полной полосе занимает секунды. BBR не снижает pacing rate из-за единичного дропа — он продолжает слать на измеренной скорости. Во-вторых, CUBIC для полной утилизации полосы на высоком BDP требует больших буферов на транзитных узлах — и, не найдя их, быстро ловит tail-drop и проваливается.

BBR опирается на RTprop, не пытается заполнить транзитные буферы и держит их почти пустыми. Но дома у вас, скорее всего, не WAN-линк до ноута и смартфона. Wi-Fi — другая среда802.

11 устроен иначе, чем проводной Ethernet. У него есть собственный механизм ретрансмиссии на канальном уровне: когда фрейм не доходит, точка доступа повторяет его до 4–7 раз, прежде чем сообщить об ошибке выше. Но большинство TCP-потерь при работе BBRv1 на Wi-Fi происходят не от того, что кадр «не пробился через помехи после 7 попыток».

Отраслевые последствия

Чаще причина другая: BBRv1 рассчитывает pacing rate по пиковой полосе, и когда Wi-Fi линк кратковременно деградирует (скажем, из-за интерференции MCS падает с 12 до 8), BBRv1 продолжает заливать буфер точки доступа на прежней скорости. Буфер AP переполняется, и роутер дропает IP-пакеты ещё до того, как они попадут в эфир. Проблема BBRv1 в том, что он игнорирует эти потери как сигнал.

Его модель говорит: «полоса есть, RTT_min не вырос — продолжаем». И он продолжает, генерируя TCP-ретрансмиты поверх уже случившихся потерь. На shared medium это двойная нагрузка на эфир.

Вот как это выглядит на реальном железе — передача по iperf3 через Wi-Fi (TX 2. 4 Gbps) с BBRv1 на ядре 6. 17: Interval Transfer Bitrate Retr 0.

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