Статья основана на материалах preprint-а Jin-Hyeong Lee (TechRxiv, 2025), а также содержит авторский анализ и интерпретации результатов.
LEO-сети вроде Starlink - это удивительный гибрид предсказуемости и хаоса. Handover между спутниками происходит строго по расписанию, каждые 5–16 секунд, но последствия этих переходов до сих пор ломают протоколы управления перегрузкой.
-
BBR принимает рост RTT за перегрузку.
-
GCC реагирует слишком поздно.
-
Активные очереди (CoDel/PIE) спасают ситуацию частично.
Недавно вышла интересная работа на TechRxiv - "Proactive Latency Control: Robust Dual-Loop Adaptation for Predictably Uncertain LEO Networks", которая предлагает крайне практичную идею:
Если handover предсказуем, почему бы не управлять скоростью передачи заранее, до того, как очередь «взорвется»?
В статье ниже, краткий, но технически точный разбор этого подхода и его результатов.
Проблема: LEO-handover - это «ложное» событие перегрузки
Спутники LEO (Starlink, OneWeb, Kuiper) летают на высоте ~550 км, обеспечивая RTT порядка 50–70 мс. Но есть нюанс:
каждые 5–16 секунд происходит handover и RTT делает скачок на 100–500 мс, зачастую сопровождаясь burst losses.
Из-за этого:
-
BBR (bandwidth-based) видит рост RTT → решает, что это congestion → снижает скорость → потом долго восстанавливается.
-
GCC (delay-based) реагирует на рост задержки через несколько десятков миллисекунд → но это уже поздно.
-
Модели, где все события реактивные (CoDel, PIE), не успевают отреагировать до возникновения проблемы.
Идея PLC (Proactive Latency Control) простая: если мы знаем, что handover предсказуем, значит, можно вмешаться заранее, не дожидаясь переполнения очереди.
Архитектура PLC: два контура, которые работают «вперед по времени»
Рис. 1. Архитектура Proactive Latency Control (Dual-Loop).
PLC - это надстройка над BBR v1, не требующая его изменения. Ее можно встроить в QUIC/WebRTC как отдельный модуль.
1) Быстрый контур (Fast Loop)
Отклик ≤ 1 RTT (≈ 50 мс).
Он:
-
отслеживает два RTT-EMA: RTT_short и RTT_long
-
вычисляет отношение ρ = RTT_short / RTT_long
-
если ρ > 1.2 → handover через 1–2 секунды
После этого фиксируется «предупредительная зона»:
45–60 ms (до порога ΔT_th)
и контроллер плавно снижает скорость (не резко, как BBR). Математика: линейная функция g(ΔT), растущая от 0 до 1 - смягчает падение скорости.
2) Медленный контур (Self-Damping Loop)
Отклик: 200–400 мс.
Задача: гасить колебания и не давать системе «раскачиваться».
Контур адаптирует коэффициент Kₚ:
-
повышает его при низкой задержке (увеличивает чувствительность)
-
снижает при высокой (гасит перерегулирование)
Обновление Kₚ делается в логарифмической форме, с ограничением ±2% за цикл - это обеспечивает численную стабильность (формулы (10)–(12) в секции II.E) .
Эксперимент: 500 секунд симуляции Starlink-подобного канала
В работе использовалась Starlink-подобная модель:
-
RTT ≈ 50–70 ms
-
heavy-tailed jitter
-
переменная пропускная способность (±300 kbps)
-
25–75 handover за 500 секунд (3 сценария: Normal → Degraded → Heavy Load)
BBR и GCC использовались как базовые контроллеры (без модификаций).
Что дает PLC поверх BBR?
И вот здесь, самое интересное.
▶ Без PLC: BBR показывает осцилляции 700–1200 мс
(все из-за handover + PROBE_BW циклов)
▶ С PLC: латентность стабилизируется в 100–150 мс
Данные из Таблицы IV:
|
Метрика |
BBR only |
BBR+PLC |
Улучшение |
|---|---|---|---|
|
Средняя задержка |
~844 ms |
~517 ms |
−327 ms |
|
p99 |
1,068 ms |
1,047 ms |
−21 ms |
|
Compliance ≤100 ms |
0% |
9% |
+9 pp |
А в Degraded & Heavy Load:
-
улучшение p99 до −44.96 ms
-
снижение осцилляций очереди в 7–10 раз
На графике из статьи видно, что PLC буквально «срезает пики».
Рис. 2. PLC радикально снижает колебания задержки: вместо 700–1200 мс пики падают до 100–150 мс.
⚠ Но есть нюанс: PLC работает только в PROBE_BW (а в STARTUP может «сломать» BBR) Это главное открытие статьи.
В фазе PROBE_BW:
PLC дает 8.8× снижение handover-задержки (72 ms против 637 ms).
В фазе STARTUP:
PLC конфликтует с экспоненциальным probing BBR и может вызвать катастрофическое нарастание задержки → до 31 секунд.
Это - одна из самых важных частей исследования. Источник: результаты многофлоу анализа в Section V.
Решение: использовать CoDel (или любой AQM)
При добавлении CoDel:
-
задержка 31,541 ms → 119 ms
-
PLC + BBR + CoDel дает лучший результат из всех комбинаций
Рис. 3. CoDel исключает катастрофическую задержку в STARTUP: PLC становится безопасным и значительно более эффективным.
Таблица V показывает:
|
Сценарий |
BBR+CoDel |
BBR+CoDel+PLC |
|---|---|---|
|
Heavy Load, mean |
464 ms |
109 ms |
|
Heavy Load, p99 |
1050 ms |
412 ms |
|
Compliance ≤100 ms |
0% |
55% |
Короткие выводы исследования
-
LEO-handover можно предсказывать и это работает лучше любого реактивного метода.
-
PLC - это легкий (36 мкс) dual-loop контроллер, который можно встроить в QUIC/WebRTC.
-
PLC драматически улучшает задержку поверх BBR, но почти не помогает GCC (тот и так режет скорость).
-
Без CoDel PLC опасен в фазе STARTUP.
-
Лучший стек для LEO в реальном мире выглядит так:
BBR + PLC + CoDel
(идеальное сочетание стабильности и проактивности)
-
Пока это симуляция, но архитектура практична и может быть реализована на Starlink/OneWeb/Kuiper.
Заключение
Работа интересна тем, что:
-
не предлагает новый алгоритм вместо BBR,
-
а дополняет его маленьким контроллером-надстройкой,
-
который использует предсказуемую природу орбитальной механики.
Подход напоминает «сетевой кардиостимулятор» (как пишет сам автор) -
не заменяет сердце, но стабилизирует его работу.
Источник
Jin-Hyeong Lee. "Proactive Latency Control: Robust Dual-Loop Adaptation for Predictably Uncertain LEO Networks".
TechRxiv Preprint, December 2025.
DOI: 10.36227/techrxiv.176281113.30584908/v2
https://www.techrxiv.org/users/985845/articles/1357489-proactive-latency-control-robust-dual-loop-adaptation-for-predictably-uncertain-leo-networks
Автор: maxorik
