From 1c6a7e7bf9e4547337d4bcff87506372d9661633 Mon Sep 17 00:00:00 2001 From: evgeny Date: Sat, 24 Oct 2026 09:56:54 +0200 Subject: [PATCH] Remove speculative early retries from the ETCP plan --- doc/etcp_multipath_plan.txt | 42 ++++++++++++++++++++----------------- doc/tasks.md | 13 +++++++----- 2 files changed, 31 insertions(+), 24 deletions(-) diff --git a/doc/etcp_multipath_plan.txt b/doc/etcp_multipath_plan.txt index 837a5eda..67eab97c 100644 --- a/doc/etcp_multipath_plan.txt +++ b/doc/etcp_multipath_plan.txt @@ -49,16 +49,19 @@ latency380.177мс. Это4 нарушения порогов; доставка/ Диагностические исходники/сборка: /tmp/etcp-recovery-probe.c/.mk; логи /tmp/etcp-recovery-{trace,priority,exclude}-.log. -Следующий отдельный шаг по отказам — ранний повтор до RTO, с сохранением окна -и метаданных исходной физической попытки до её ACK/RTO/close. Ротация уже не -возвращается в прежний путь при занятой альтернативе, но первый таймер не ускоряет. -Ранние копии должны иметь ограниченный бюджет и приоритет восстановления пропуска; -перед production нужно измерить цену дубликатов на исправных RTT20/200 каналах. -Нельзя автоматически считать раннюю копию потерей для BBR, обнулить чужой flight -или сократить штатный RTO медленного пути до100мс. Пауза<=100мс физически зависит -от готовности и задержки оставшегося пути; постоянная задержка100мс в одну сторону -уже не оставляет запаса на отправку и обработку. Эти ограничения требуют отдельного -проверенного правила срока/бюджета ранних копий; оно здесь не реализовано. +Решение пользователя,24.10.2026: ранние копии до RTO исключены из плана. +Пока путь UP, срок повтора определяется его RTO; закрытие линка по-прежнему +снимает его попытки и возвращает недоставленные DATA без ожидания этого срока. +Ротация ждёт готовности другого initialized+UP пути, не возвращаясь в прежний, +пока такая альтернатива существует. Формула RTO остаётся согласованной: +clamp(ceil(1.2*RTT+1.5*jitter+3мс),10мс,1с), с округлением до микросекунды. +При RTT200мс и нулевом jitter RTO уже243мс; фиксированный порог паузы100мс +не учитывает это обязательное ожидание. Текущие пороги тестов не менялись, +приведённые выше FAIL сохранены. Следует отдельно оценивать ожидание RTO, +задержку готового повтора и доставку через выбранную альтернативу. +Дальнейшие механизмы здоровья каналов и STCP backpressure не предполагают +спекулятивного дублирования DATA до RTO. Прежние предложения ранних копий +в исторических результатах ниже отменены этим решением. Состояние после исправления pacer, до уточнения правила ретрансмита: @@ -518,7 +521,7 @@ load8/8 с 134217728 проверенными байтами за13.03с. Сет её удаление из протокола сломало бы ограничение окна приёмника. Прототип не проверяет новый wire-формат, владение попытками или отказоустойчивость. -Контракт (базовый учёт реализован; ранний повтор и STCP-очередь остаются открытыми) +Контракт (базовый учёт реализован; STCP-очередь остаётся открытой; ранние копии исключены) Разделить логическую доставку фрагмента и физическую попытку передачи. @@ -610,14 +613,14 @@ uint8: хранить факт состоявшейся отправки отд Курсор меняется после принятия новой попытки транспортом. Ошибка подготовки/OOM или отказ отправки не должны создавать фиктивный flight и ждать сетевого RTO. -Повтор и объявление потери — разные события. При ранней отправке второй копии -первая ещё может быть в пути: её окно и метаданные остаются до собственного ACK, -срока потери или закрытия. Сам по себе повтор не является loss sample для BBR. -Дополнительные копии ограничены общим бюджетом памяти и окнами их каналов. +Повтор планируется после RTO либо снятия попытки при закрытии линка; ранних +спекулятивных копий нет. После RTO исходная DATA ещё может прийти из сети: +поздний ACK подтверждает логический seq, но не создаёт sample удалённой попытки. +Потеря для BBR учитывается при RTO, не при постановке или отправке повтора. +Все попытки ограничены общим бюджетом памяти и окнами своих каналов. Ротация сокращает число попыток через зависший путь, но не сокращает ожидание первого таймера. Нельзя обещать паузу <=100мс только сменой канала при RTO>100мс. -Срок ранней повторной отправки и допустимую цену дубликатов проверять отдельно; -сохранять физически достижимые требования конкретных профилей, не обещать один +Сохранять физически достижимые требования конкретных профилей, не обещать один предел задержки для произвольных RTT, нагрузки и потерь. Почему не общий самый быстрый обратный канал @@ -673,8 +676,9 @@ uint8: хранить факт состоявшейся отправки отд Очистка не выделяет память, старые callbacks/ожидания отменяются; активные обработчики удерживают teardown и проверяют reset_count/close после callbacks. Проверены OOM на первой/следующей кодограмме и восстановление новой эпохи. - Собственный RTT/RTO и ротация уже обязательны в этапе 2. Проверить срок первой - повторной отправки, отдельно от объявления потери/снятия окна старой попытки. + Собственный RTT/RTO и ротация уже обязательны в этапе 2. Проверять ожидание + RTO отдельно от задержки готового повтора и доставки альтернативным путём. + Ранние копии до RTO исключены по решению пользователя от24.10.2026. При потере ограничить новые DATA на проблемном пути, пробовать восстановление ограниченными probe, повторять недоставленные DATA через рабочие каналы. Не отправлять следующий bulk вслепую в тот же застрявший путь. diff --git a/doc/tasks.md b/doc/tasks.md index a2c2305d..bf06bec0 100644 --- a/doc/tasks.md +++ b/doc/tasks.md @@ -17,8 +17,11 @@ В них4 нарушения порогов; доставка/порядок/ресурсы проходят. Полная скоростная матрица не повторялась. Трейс показал ожидание первого RTO на медленном пути и повторный выбор прежнего пути под нагрузкой; ожидание в хвосте send_q в этих опытах не объясняет основную паузу (максимум2.6/3.5мс). - Следующий отдельный шаг по отказам — ограниченные ранние копии до RTO с сохранением старого flight; - срок/бюджет и цену дубликатов на исправных каналах нужно проверить до переноса. Дуплекс остаётся отдельным. + Ранние копии до RTO исключены пользователем24.10.2026. При UP повтор ждёт RTO своего пути; + закрытие линка по-прежнему возвращает недоставленные DATA без ожидания RTO. + При RTT200мс RTO уже243мс без jitter: порог паузы100мс этого ожидания не учитывает. + Пороги тестов не менялись; дальше отдельно оценивать ожидание RTO, готовность повтора и доставку. + Остаются здоровье/пробы каналов, STCP backpressure и дуплекс; спекулятивных ранних копий в плане нет. Логи: /tmp/etcp-retry-alternative-*.log/.csv; диагностический observer — /tmp/etcp-recovery-probe.c/.mk. Предыдущий контроль после исправления pacer: таймер ждёт первого разрешённого TB, а не погашения всего долга; кредит1мс, BBR/cwnd/min_rtt, RTO и wire-формат сохранены. Нового состояния и ресурсов нет. @@ -34,7 +37,7 @@ Паузы slow-drop/two-stuck/load-drop/load-hold:239.421/201.381/213.644/208.899мс; задержки slow-drop/two-stuck:264.044/482.693мс. Доставка, порядок и контроль ресурсов проходят. Это один прогон; сравнение с исходными15 нарушениями не доказывает устойчивое улучшение всей матрицы. - Далее отдельно разбирать ограничения BBR/cwnd и PROBE_RTT, затем ранние копии/здоровье линков и STCP backpressure. + Далее отдельно разбирать ограничения BBR/cwnd и PROBE_RTT, здоровье линков и STCP backpressure. Результаты/план: doc/etcp_multipath_plan.txt; /tmp/etcp-pacer-ready-matrix.log/.csv, /tmp/etcp-pacer-ready-{windows-final,real-time,full-check}.log и /tmp/etcp-pacer-ready-asan-test_*.log. Реализованы начальный pacing от 4*MSS/RTT, точные DATA B/s и ограниченный кредит shaper, @@ -85,13 +88,13 @@ One-way->duplex->one-way:3/3 PASS; ASAN/UBSan не нашли ошибок/утечек, скоростной профиль остаётся FAIL. Подробности/уточнённый план: doc/etcp_multipath_plan.txt; результаты: /tmp/etcp-duplex-native/results.json, /tmp/etcp-duplex-native/summary.csv и ack_bandwidth.csv. Политика окна прототипов в репозиторий не переносилась. - Ранние копии до RTO, здоровье/пробы каналов и STCP backpressure пока не реализованы; пороги тестов сохранены. + Здоровье/пробы каналов и STCP backpressure пока не реализованы; ранние копии исключены, пороги тестов сохранены. OOM после принятия данных исправлен аварийной сменой эпохи с сохранением физических линков. Старый поток отбрасывается без воспроизведения; после согласования владельцы получают REINIT. Очистка reset не выделяет память; убрана реконструкция inflight, новых OOM-очередей/таймеров нет. Проверены отказы RX/TX, flush/waiter/session-таймеров, RNG, reset/close из callback и ноль выделений при reset. windows31 сценарий, queue_regressions77/77 и шифрованное восстановление обеих сторон PASS; - десять тестов ASAN/UBSan с detect_leaks=1 PASS. Далее — ранние повторы и здоровье каналов. + десять тестов ASAN/UBSan с detect_leaks=1 PASS. Далее — здоровье каналов; ранние повторы исключены. После OOM-правок полный check.sh: 181/183; FAIL BGP route exchange и encrypted attachment. BGP отдельно с диагностикой PASS; encrypted attachment повторно FAIL из-за удаления активного temp кешем (задача ниже). Отдельно proxy9/9, burst1/1 и load8/8 PASS (134217728 проверенных байт); /tmp/etcp-oom-reinit-proxy-check.log.