Статья основана на материалах 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 дает лучший результат из всех комбинаций

BBR+CoDel vs BBR+PLC+CoDel Latency Graph

Рис. 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

Proactive Latency Control — как упреждающее управление задержкой делает LEO-сети стабильнее