Say what adopting the link took, and how it fares against ngtcp2 (102)

102: the spec (012) and a receiver written from it alone; the four holes
writing it found (REFUSED, the record's size, a peer's run places, the
memo's places beside) and the credit M6 showed fixed at 1,024 records;
M6 with ngtcp2 as a third, two rounds. Under reordering Pure carries the
most (45 Mbit/s; ngtcp2 29-47, quinn 1-2), under random loss the three
are the same, on a clean bottleneck Pure carries 3-5 % less (its framing,
some 112 B a packet to QUIC's 41), and where loss and reordering meet
ngtcp2 carries 1.3-3.6 times as much: undoing a loss it took for
reordering, it restores the window a real loss had cut too (its log: 22
of 34 undos past the window before the last cut; none without
reordering). Shares beside TCP stay within 25 %.

011 and the status table say so; 012 also says that a receiver answers
within 25 ms (a sender's PTO counts on it), that a shape and a record's
bytes are the app's, and why a packet of the past does no harm.

1 files changed, 17 insertions, 10 deletions

diff --git a/docs/design/011-pure-transport.md b/docs/design/011-pure-transport.md
index 5513476..392210c 100644
--- a/docs/design/011-pure-transport.md
+++ b/docs/design/011-pure-transport.md
@@ -56,18 +56,25 @@ M3(저장소 옮기기, H3)는 [100](../research/100-moved-receiver.md)에 있�
 - 잃음·겹침 검사, 논스 검사, 보안 검사를 모두 통과한다.
 - 전달당 CPU는 1 KiB 이상에서 두 QUIC보다 25 % 넘게 가볍다. 61 B에서는 ngtcp2의 1.04배로 10 % 안이다.
 - TCP와의 몫은 ±25 % 안이다.
-- 전송 코드는 C 3,097줄이다.
+- 전송 코드는 C 3,146줄이다.
 
 그래서 연결 없는 링크를 노드 사이 전달의 기본으로 삼는다(`--send OUTPUT=pure://host:port/INPUT`). HTTP 전달은 제3자와
-브라우저를 잇는 경계로 남고, 중계를 지나는 봉인한 전달([088](../research/088-sealed-sessions.md))도 그대로다. M6를 ngtcp2와
-재지는 않았다. 가드레일은 quinn과 TCP로 쟀다.
-
-명세 [012](012-link-protocol.md)를 쓰면서 구현의 구멍 셋을 찾아 고쳤다.
-- 받는 쪽이 받지 않는 스트림을 보내는 쪽은 아무 말도 듣지 못해 매초 다시 보냈다. 이제 REFUSED로 이유를 듣고 드물게 다시 시도한다.
-- 받는 쪽이 쥘 수 없는 16–64 MiB 기록이 영원히 다시 갔다.
-- 한 노드의 출력 셋 이상이 같은 노드로 가면 run들이 받는 쪽의 두 자리를 서로 밀어냈다.
-
-명세만 보고 파이썬으로 따로 쓴 받는 쪽이 `pure-serve` 노드와 에폭 바꿈까지 맞붙는다.
+브라우저를 잇는 경계로 남고, 중계를 지나는 봉인한 전달([088](../research/088-sealed-sessions.md))도 그대로다.
+
+채택과 함께 한 일은 [102](../research/102-adoption-and-spec.md)에 있다.
+- 명세 [012](012-link-protocol.md)를 쓰면서 구현의 구멍 넷을 찾아 고쳤다.
+  - 받는 쪽이 받지 않는 스트림을 보내는 쪽은 아무 말도 듣지 못해, 90초에 패킷 2만 2천여 개를 다시 보냈다. 이제 REFUSED로
+    이유를 듣고 드물게 다시 시도한다(같은 90초에 9개).
+  - 받는 쪽이 쥘 수 없는 16–64 MiB 기록이 영원히 다시 갔다.
+  - 한 노드의 출력 셋 이상이 같은 노드로 가면 run들이 받는 쪽의 두 자리를 서로 밀어냈다.
+  - 메모가 피어마다 run 하나의 에폭만 들어, 다시 뜬 받는 쪽이 나머지 run에 LOST를 보냈다.
+- 명세만 보고 파이썬으로 따로 쓴 받는 쪽이 `pure-serve` 노드와 에폭 바꿈까지 맞붙는다.
+- 허가가 기록 1,024건으로 고정되어, 100 ms 경로에서 61 B 기록은 초당 1만 건이 끝이었다. 이제 받는 쪽 메모리에 맞추어 5만
+  6천 건이다.
+- M6를 ngtcp2와도 쟀다.
+  - 재정렬만 있을 때 Pure가 가장 많이 나르고, 손실만 있을 때 셋이 같다.
+  - 깨끗한 병목에서는 틀의 바이트로 3–5 % 뒤진다.
+  - 손실과 재정렬이 겹칠 때 ngtcp2가 1.3–3.6배 나르는 것은, 잘못 본 손실을 되돌리며 진짜 손실의 감소까지 지우기 때문이다.
 
 2026-09-29에 링크를 `link/`로 뗐다([009](009-layout.md)). 프로토콜은 이제 소켓, 스레드, 시계가 없는 상태이고
 (`link/link-protocol.h`), UDP와 스레드는 그 위의 층이다. 그래서 한 스레드가 링크 여럿을 들 수 있다. M2를 이 보내는 쪽으로