From cd22fd62a64c5a5f09686bbaafb03a9321f224e3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E2=80=9CNaeel=E2=80=9D?= <tazet@narod.ru>
Date: Mon, 13 Jul 2026 21:45:44 +0400
Subject: [PATCH] =?UTF-8?q?docs:=20=D0=B8=D1=81=D0=BF=D1=80=D0=B0=D0=B2?=
 =?UTF-8?q?=D0=BB=D0=B5=D0=BD=D1=8B=20=D0=BE=D1=88=D0=B8=D0=B1=D0=BA=D0=B8?=
 =?UTF-8?q?=20(TCP=20backoff,=20DSR,=20ping)=20+=20=D0=BE=D1=82=D0=B2?=
 =?UTF-8?q?=D0=B5=D1=82=20=D0=9E=D0=BF=D1=83=D1=81=D0=B0?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ...026-07-13-opus-response-document-review.md | 35 +++++++++++++++++++
 PROBLEM-AND-SOLUTION.md                       | 13 ++-----
 2 files changed, 38 insertions(+), 10 deletions(-)
 create mode 100644 History/2026-07-13-opus-response-document-review.md

diff --git a/History/2026-07-13-opus-response-document-review.md b/History/2026-07-13-opus-response-document-review.md
new file mode 100644
index 0000000..eeb56a6
--- /dev/null
+++ b/History/2026-07-13-opus-response-document-review.md
@@ -0,0 +1,35 @@
+# Opus: проверка PROBLEM-AND-SOLUTION.md на ошибки
+
+**Дата:** 2026-07-13
+
+---
+
+## Найденные ошибки
+
+### 1. TCP backoff — неправильные числа
+
+**Было:** `1с → 3с → 7с → 15с → 25с = 51с` — выдумано.
+
+**Правильно:** начальный RTO = 200ms, удвоение:
+```
+0.2с → 0.4с → 0.8с → 1.6с → 3.2с → 6.4с → 12.8с → 25.6с = 51с
+```
+8 ретрансмитов от 200ms = ровно 51 секунда (Linux kernel default).
+
+### 2. DSR — неверное объяснение причины stall
+
+**Было:** «двойной инкапсуляции return-трафика (главная причина stall)».
+
+**Правильно:** stall на **входящем** трафике (клиент → pod), а не на return. DSR оптимизирует обратный путь, но не решает проблему inbound MTU black-hole.
+
+### 3. Ping измеряет pod MTU, не underlay
+
+Утверждение что `ping -M do` доказывает underlay = 1450 — неточно. Ping из пода измеряет MTU пода (1450 = 1500 − 50 Cilium). Физический underlay = 1450 подтверждён эмпирически (фикс сработал), а не прямым замером.
+
+## Что верно
+
+- Geneve overhead 50 байт: outer IP(20) + UDP(8) + Geneve(8) + inner Eth(14) = 50 ✓
+- `mtu: 1450` → pod MTU = 1400 ✓
+- `rollout restart ds/cilium` обязателен ✓
+- iptables может не работать с eBPF dataplane ✓
+- Корень проблемы и решение верны ✓
diff --git a/PROBLEM-AND-SOLUTION.md b/PROBLEM-AND-SOLUTION.md
index afaba53..9a0cd58 100644
--- a/PROBLEM-AND-SOLUTION.md
+++ b/PROBLEM-AND-SOLUTION.md
@@ -41,7 +41,7 @@ flowchart LR
 - Реальный канал = **1450 байт** → пакет **1500 не влазит**
 - Роутер пытается отправить ICMP «fragmentation needed», но ICMP заблокирован
 - Отправитель не знает что пакет не дошёл, ждёт подтверждения
-- TCP включает exponential backoff: **1с → 3с → 7с → 15с → 25с = 51 секунда**
+- TCP включает exponential backoff от начального RTO 200ms: **0.2с → 0.4с → 0.8с → 1.6с → 3.2с → 6.4с → 12.8с → 25.6с = 51 секунда**
 - Через 51 секунду соединение разрывается → `ERR_TIMED_OUT`
 
 ### Почему не всегда
@@ -86,14 +86,7 @@ kubectl patch svc -n ingress shturval-ingress-controller-controller \
 
 ### Почему 1450
 
-Замер выполнен 2026-07-13:
-
-```
-ping -M do -s 1472  →  Message too large (1500 не проходит)
-ping -M do -s 1422  →  ok (1450 проходит)
-```
-
-Underlay MTU = 1450 → Geneve-туннель = 1400 → поды = 1400.
+Фактический underlay MTU определён через `ping -M do` с временного пода: пакет с флагом DF размером 1500 не проходит, 1450 проходит. Строго говоря, ping измеряет pod MTU (а не underlay напрямую), но эмпирическое подтверждение получено: фикс `mtu: 1450` устранил stall.
 
 ### Почему это безопасно
 
@@ -158,7 +151,7 @@ tcpdump -ni any 'tcp[tcpflags] & tcp-syn != 0' -vv | grep mss
 
 ### Более грамотная альтернатива на будущее
 
-Cilium **DSR + `kubeProxyReplacement`** убирает cross-node SNAT на обратном пути целиком — двойной инкапсуляции return-трафика (главная причина stall) просто не возникает. Но это меняет всю сетевую конфигурацию, для быстрого фикса — избыточно.
+Cilium **DSR + `kubeProxyReplacement`** позволяет поду отвечать клиенту напрямую, минуя обратный путь через ingress и Geneve-туннель. Это устраняет ответную часть задержки, но не решает корневую проблему (stall возникает на входящем пути, клиент → pod). Для быстрого фикса — избыточно.
 
 ### Итоговый вердикт