Commit Graph
5 Commits
Author SHA1 Message Date
Nils Andreas Svee a50edff624 docs(server): record upstream client interop
Run the released upstream IRTT 0.9.1 client as a black box against the
Tokio server over explicit loopback listeners, and record the result.

Twelve of thirteen matrix rows pass and one is skipped for a client-side
CLI reason: IPv4 and IPv6 ordinary sessions, HMAC with a wrong-key
negative control, packet-length and interval restrictions both strictly
and with --loose, maximum-duration restriction, no-test, and midpoint
timestamps on each clock selection. No incompatibility was found, so
nothing in the implementation changed.

Two results are worth keeping. The single-field midpoint reply this
server deliberately emits instead of upstream 0.9.1's dual-field form is
accepted by the released client, which derives RTT and IPDV from it. And
the maximum-duration close is unreachable by a conforming client: the
deadline is the configured maximum plus two seconds while negotiation
caps the session Duration at that same maximum, so a client honoring the
Duration it was given always stops early. The two-second grace is the
measured margin already recorded in the protocol evidence, so this is
the implementation matching that evidence rather than a defect, and the
close path stays covered by the lifecycle tests.

Upstream source, tests and history were not inspected; only the
executable's version, help, exit status and normal output were observed.
No test in this repository depends on the upstream binary.
2026-08-13 16:47:09 +07:00
Nils Andreas Svee 58472dbf7b docs(protocol): airlock server black-box findings
Transfer independently black-box-verified server behavior from a source-assisted
research phase conducted outside this repository. Only a sanitizer-candidate
report of black-box findings and the packet captures it referenced were admitted;
no upstream source, tests, history, harnesses, build trees, result files or
source-assisted analysis crossed the boundary. Provenance and the boundary
discipline are recorded in docs/clean-room/CLEANROOM_NOTES.md.

New upstream robustness defect (Section 22.5). An open selecting timestamps while
omitting the Clock parameter is accepted with a valid token and no Clock echoed,
and the first echo on that session is fatal to the server process, taking
unrelated sessions on the same process with it. An explicit Clock=0 is instead
rejected at open, so parameter presence is externally meaningful. Recorded as an
observed defect with a must-not-crash recommendation; the clean server's
resolution is deliberately left to the implementation work.

Also established or strengthened:

- the idle grace and maximum-duration grace are fixed additive margins across the
  settings swept, and the maximum-duration clock starts at the first echo that is
  actually served;
- a rate-limited request is the only tested drop class that keeps a session
  alive, and in one documented configuration a conforming client can observe the
  difference;
- a post-deadline packet of several tested classes consumes an expired session's
  one remaining reply, including packets that are themselves dropped;
- the reply-length cap is the bind interface's MTU on the interfaces where it was
  reachable, and a length the host cannot transmit ends the process;
- DSCP marking follows the session, with unmarked open replies and no
  cross-session leakage across interleaved sessions;
- repeated tags are last-valid-wins, with invalid-duplicate handling scoped to
  the orders actually tested, and unknown tag values are consumed as varints.

Three captures were admitted, each rewritten to the container convention already
used here and verified byte-identical in packet data and timestamps:
server-clock-absent (3 packets), server-expiry-consumption (14) and
server-dscp-interleaved (32). Two further captures were reviewed and rejected as
redundant or unsupporting; their textual results were kept instead.

Host-specific figures are labelled as such throughout, upstream defects are not
promoted to protocol requirements, observations are separated from inferences and
from recommendations, and no implementation policy is chosen here. The client
specification gains matching refinements where the two compatibility baselines
would otherwise state a lifecycle or marking rule differently.

Documentation and evidence only; no production code changed.
2026-08-12 16:24:57 +07:00
Nils Andreas Svee 454bbc2378 docs(protocol): add sanitized server compatibility research 2026-08-11 18:25:31 +07:00
Nils Andreas Svee 186c6eba97 docs: add clean-room docs/specs and agent guidance 2026-08-10 18:54:22 +07:00
Nils Andreas Svee b8b0425c4e test(ci): add deterministic Linux netem interop testing 2026-06-03 14:48:51 +07:00