Record duplex plan trials and measured ACK bandwidth costs

doc/etcp_multipath_plan.txt

@@ -115,6 +115,88 @@ BGP route exchange: 100/100 PASS (A<B:48, A>B:52; последние пять с
 Все замеры: /tmp/etcp-multilink-quality-20261023.csv/.txt.
 Логи повторов: /tmp/etcp-quality-r{2,3}-{profile}.log/.csv; первый — /tmp/etcp-rto-margin-matrix.log/.csv.
 
+Проверка плана исправления дуплекса, 23.10.2026
+
+Пакетный трейс нашёл ACK compression при осушении обратной очереди: для DATA
+seq257..413 принято 170502 байта за186359мкс, а max(send_elapsed,ack_elapsed)
+составил150732мкс. BBR получил1.131MB/s вместо фактических0.915MB/s.
+В одном устойчивом участке DATA-pacing A=1.104MB/s при BWlim=8Mbit/s;
+очередь A->B держится около40мс и задерживает ACK обратных DATA.
+RTT приходит в BBR на каждом ACK (около124мс), причина не в устаревшем RTT.
+Полный трейс500мс: /tmp/etcp-duplex-packets.log/.csv; история разгона:
+/tmp/etcp-duplex-overload-start-v2.log, /tmp/etcp-duplex-overload-history-v2.csv.
+
+Прототипы остаются только в /tmp/etcp-duplex-native/. Исходники проекта
+не менялись. Реальный wire ACK расширен с8 до24 байт парой rx_bytes:u64
+и rx_time_us:u64; это одна согласованная точка физического приёма DATA пути.
+Счётчик включает допустимые физические копии DATA; это не логический till.
+Попытка хранит последнюю известную точку при отправке. Дополнительная граница
+rate sample: interval >= ceil(delivered * delta_rx_time / delta_rx_bytes).
+Это сохраняет прежние границы send/ACK и не увеличивает оценку полосы.
+В отличие от первого опыта с восстановлением времени из16-битного timestamp,
+согласованная пара счётчик/время не использует агрессивную инвалидацию samples
+при обратном ходе восстановленного timestamp. Первый опыт ухудшал результат
+и не предлагается для внедрения.
+
+В header проверен флаг DATA-backlog + недавней передачи своего пути.
+В окне применяется отдельное T_effective=k*min_rtt+delta; min_rtt не меняется.
+Для опыта TTL=20мс, проверяется при расчёте политики на ACK. Это ещё не полный
+контракт затухания при молчании: свежесть нужно проверять и при выборе DATA,
+чтобы не ждать следующего ACK для снятия дополнительного запаса.
+
+Пять вариантов, по три последовательных запуска штатного bidirectional:
+по3с прогрев +4с измерение, solo каждого канала и агрегат2+8Mbit/s RTT20/80мс.
+Ниже min..max goodput A->B / B->A агрегата и максимальная очередь всех повторов:
+  штатный wire:                 7.930..8.610 / 8.309..8.503Mbit/s; 52.9мс;
+  ACK+16 байт, без новой границы:8.113..8.189 / 8.032..8.320Mbit/s; 53.7мс;
+  новая граница BW:             8.095..8.236 / 8.154..8.396Mbit/s; 23.1мс;
+  граница + k=282/256, delta=3мс:8.179..8.404 / 8.142..8.171Mbit/s; 35.5мс;
+  граница + k=1, delta=10мс:     8.146..8.234 / 8.133..8.142Mbit/s; 33.7мс.
+В измеряемых интервалах DATA retries=0. Все15 запусков не проходят весь
+исходный скоростной профиль; пороги не менялись. Увеличение окна не дало
+устойчивого выигрыша и увеличило очереди: выбирать коэффициент пока рано.
+
+Ещё3 опыта one-way -> duplex -> one-way на том же соединении PASS:
+флаг/поправка не активны у отправителя в односторонних измеряемых фазах,
+включаются при встречной загрузке и отключаются после её завершения.
+Полная доставка, порядок, состояние сессии, попытки/очереди и память проверены.
+ASAN/UBSan с detect_leaks=1: phases PASS; bidirectional FAIL по скоростным
+порогам, отчётов sanitizer/утечек и нарушения полной доставки нет.
+
+ACK учтены по принятым пакетам: ACK-only — вся UDP-кодограмма с шифрованием
+и служебными полями; piggyback — только ACK-секция внутри DATA, без повторного
+начисления общих заголовков DATA. Единицы BWlim — UDP-байты без IP/UDP headers.
+Для штатного агрегата ACK=0.515..0.559Mbit/s на направление, 5.15..5.59%
+суммарного BWlim и5.50..5.93% фактического UDP-трафика. В среднем ACK-only:
+0.445..0.455Mbit/s, ACK внутри DATA:0.088..0.090Mbit/s.
+По отдельным каналам ACK занимают0.121..0.131 из2Mbit/s и0.384..0.431 из8Mbit/s.
+При безусловном добавлении16 байт телеметрии ACK расходует0.707..0.743Mbit/s;
+с новой границей BW —0.745..0.763Mbit/s. Накладные расходы реальны и учтены.
+
+План требует уточнения до переноса в основную реализацию:
+1. Сохранить измеренный min_rtt и отдельные send/ACK/receiver интервалы.
+   Точку счётчик/время передавать только с положительными ACK, которые её
+   используют; не раздувать каждый DATA с пустой ACK-секцией. Изменение
+   формата выполнить целиком для TX/RX/dump/MTU и тестов.
+2. Испытать объединение ACK: piggyback на готовом DATA — сразу; ACK-only
+   по существующему дедлайну2мс. Запрос границы окна/срочный ответ не задерживать.
+   Один таймер должен обслуживать ближайший deadline очередей путей, включая
+   повторное планирование после частичного piggyback/раннего пробуждения.
+   Сейчас посторонний wake sender может отправить ACK-only до этого срока.
+3. Сначала повторить скорости/очереди с корректной оценкой BW и экономной
+   упаковкой ACK. Дуплексный коэффициент не вводить как обязательную часть
+   фикса без устойчивого выигрыша в дополнительных RTT/BW/асимметричных профилях.
+4. До внедрения проверить reordering/loss/duplicate ACK, поздние попытки,
+   reset/recreate пути и простой; валидировать пару counter/time. Если новая
+   граница не представима в uint32 interval, пропустить оценку BW, а не
+   насыщать интервал с нарушением верхней границы скорости. TTL флага
+   определить для редких DATA/jitter/standby и проверить молчание без ACK.
+
+Результаты всех18 запусков: /tmp/etcp-duplex-native/results.json,
+/tmp/etcp-duplex-native/summary.csv, /tmp/etcp-duplex-native/ack_bandwidth.csv.
+Сборка: /tmp/etcp-duplex-native/experiment.mk; код/логи сохранены рядом.
+Sanitizer: /tmp/etcp-duplex-native-asan/{bidirectional,phases}.log.
+
 OOM следующей ступени приёма исправлен аварийным перезапуском сессии.
 До сохранения RX DATA в recv_q отказ остаётся обычной потерей без ACK.
 После принятия данных OOM в packer/unpacker или TX inflight запускает новую

doc/tasks.md

@@ -29,6 +29,16 @@
     2+8+2 RTT20/80/200 — 10.566..10.749 из12; 2+8 одновременно в обе стороны — 8.080..8.379 из10 на направление.
     DATA-повторов в измеряемых исправных интервалах нет. Подробные результаты: /tmp/etcp-multilink-quality-20261023.csv/.txt.
     BGP-падение из-за INIT/remote_keepalive исправлено; отдельная задача ниже содержит итог проверки.
+    Дуплекс проверен18 последовательными опытами в /tmp/etcp-duplex-native/, исходники проекта не менялись.
+    ACK compression завышает BW:170502 байта приняты за186.36мс, sender sample использует150.73мс.
+    Нативный прототип counter/time в ACK сокращает пики очереди до23.1мс вместо52.9мс, но все скоростные пороги не проходит.
+    Коэффициент282/256+3мс и запас10мс при busy-флаге не дали устойчивого выигрыша, пики очереди выросли до35.5/33.7мс.
+    В штатном агрегате ACK занимает0.515..0.559Мбит/с на направление (5.15..5.59% полосы), большая часть — ACK-only.
+    Безусловные16 байт новой телеметрии увеличивают расход; нужен опыт с передачей точки только при положительном ACK
+    и объединением ACK в пределах прежнего дедлайна2мс. Дуплексный запас пока не считать подтверждённым исправлением.
+    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 пока не реализованы; пороги тестов сохранены.
     OOM после принятия данных исправлен аварийной сменой эпохи с сохранением физических линков.
     Старый поток отбрасывается без воспроизведения; после согласования владельцы получают REINIT.