irtt-rs/docs/protocol/test-vectors/SERVER_BEHAVIORAL_VECTORS.md

IRTT Server Behavioral Vectors

Source: Black-box observation of an upstream IRTT 0.9.1 release server on macOS Darwin 25.5.0 arm64, driven by a raw UDP harness. Date: 2026-08-12 Companion to: ../IRTT_SERVER_PROTOCOL_SPEC.md

These vectors are stated as input → observed output. They describe what a server was seen to emit for a given request sequence. They do not describe how any implementation produces those bytes.

Unless a row says otherwise, the server under test is the unmodified upstream 0.9.1 release. Two other builds appear where they are named explicitly: the 0.9.0 release, and a build of the upstream development tree six upstream commits past the 0.9.1 tag. Results from those builds never stand in for 0.9.1. Section 5.2.3 is a version comparison, where the three builds differ; elsewhere the other two builds are named only to record that a 0.9.1 result reproduced on them unchanged (Sections 3.2, 4.7, 8.1, 8.2).

Addresses in the accompanying captures are loopback only. Session tokens are server-assigned random values and differ per run; where a token appears below it is the value from that specific run and carries no meaning.

---

1. Received Window and Received Count

All vectors in this section were produced on a single session negotiated with ReceivedStats = both (3), StampAt = none (0). Each row is one echo request and the reply it produced. count is the 32-bit received count field; window is the 64-bit received window field.

1.1 Sequential, no loss

#	request seq	reply count	reply window
1	0	1	0x0000000000000001
2	1	2	0x0000000000000003
3	2	3	0x0000000000000007
4	3	4	0x000000000000000f
5	4	5	0x000000000000001f
6	5	6	0x000000000000003f

1.2 One gap

#	request seq	reply count	reply window	note
1	0	1	0x0000000000000001
2	1	2	0x0000000000000003
3	3	3	0x000000000000000d	bit 1 clear — sequence 2 missing
4	4	4	0x000000000000001b	bit 2 clear — sequence 2 missing

1.3 Multiple gaps

#	request seq	reply count	reply window
1	0	1	0x0000000000000001
2	3	2	0x0000000000000009
3	7	3	0x0000000000000091
4	8	4	0x0000000000000123

1.4 Later gap fill — window collapses

#	request seq	reply count	reply window	note
1	0	1	0x0000000000000001
2	1	2	0x0000000000000003
3	5	3	0x0000000000000031	gap over 2, 3, 4
4	3	4	0x0000000000000001	filling the gap discards history

A late arrival does not set the corresponding historical bit. The window is reset to "only the current packet is known".

1.5 Duplicate sequence number

#	request seq	reply count	reply window	note
1	0	1	0x0000000000000001
2	1	2	0x0000000000000003
3	1	3	0x0000000000000003	count advances, window unchanged
4	2	4	0x0000000000000007

1.6 Reordering

#	request seq	reply count	reply window	note
1	0	1	0x0000000000000001
2	1	2	0x0000000000000003
3	2	3	0x0000000000000007
4	1	4	0x0000000000000001	out-of-order arrival resets the window
5	3	5	0x0000000000000005	rebuilds from the reset state

Note row 5: the window says sequence 1 was received (bit 2) and sequence 3 was received (bit 0), but bit 1 is clear even though sequence 2 was received earlier. History before the reset is unrecoverable.

1.7 Strictly descending sequence numbers

#	request seq	reply count	reply window
1	5	1	0x0000000000000001
2	4	2	0x0000000000000001
3	3	3	0x0000000000000001
4	2	4	0x0000000000000001
5	1	5	0x0000000000000001
6	0	6	0x0000000000000001

Every reply is answered; only the count carries information.

1.8 Gap at and beyond the representable window

first seq	second seq	gap	second reply window
0	63	63	0x8000000000000001 — highest bit set
0	64	64	0x0000000000000001
0	65	65	0x0000000000000001
0	1000	1000	0x0000000000000001

The window represents the current packet plus 63 predecessors. A gap of exactly 63 still records the older packet in the top bit; a gap of 64 or more discards all history.

1.9 Non-zero starting sequence number

#	request seq	reply count	reply window
1	100	1	0x0000000000000001
2	101	2	0x0000000000000003
3	102	3	0x0000000000000007

The first request of a session always yields window 0x1, whatever its sequence number.

1.10 32-bit sequence wraparound

#	request seq	reply count	reply window
1	4294967293	1	0x0000000000000001
2	4294967294	2	0x0000000000000003
3	4294967295	3	0x0000000000000007
4	0	4	0x000000000000000f
5	1	5	0x000000000000001f

Wraparound is handled as ordinary modular arithmetic: crossing 2^32 − 1 → 0 is treated as a step of one, not as a gap of 2^32 − 1 and not as reordering.

Starting a session at 4294967295 and following with 0 gives 0x1 then 0x3.

1.11 Randomized cross-check

The window and count rules in ../IRTT_SERVER_PROTOCOL_SPEC.md Section 10 were checked against a live server over 12 sessions of 40 requests each — 480 replies in total — with sequence numbers drawn from a mix of in-order steps, duplicates, forward gaps of 2 to 80, and backward steps of 1 to 5, and with starting sequence numbers of 0, 1, 7, 100 and 4294967294.

Result: 480 replies checked, 0 mismatches in either the window value or the count value.

1.12 Count excludes dropped requests

Server configured with a minimum interval of 100 ms and a burst allowance of 5. Twelve requests sent back to back, then three more after a 600 ms pause.

requests sent	replies received	counts in replies
12 back to back	5	1, 2, 3, 4, 5
3 after a pause	3	6, 7, 8

Rate-limited requests produce no reply and do not advance the count.

---

2. Session Identity

Capture: ../captures/server-session-identity.pcapng.

Session opened from source port A; token 88a76d2fd0cd5f32.

#	source	packet	observed
1	A	open request	open reply, token assigned
2	A	echo seq 0	reply, count 1, window 0x1
3	B	echo seq 1, correct token	no reply
4	B	close, correct token	no reply, session not closed
5	A	echo seq 2	reply, count 2, window 0x5
6	C	echo seq 0, token 1111111111111111	no reply
7	A	close	no reply, session removed

Row 5 is the important one: the count advanced from 1 to 2, not to 3 — the foreign-endpoint request in row 3 was not counted. The window 0x5 reflects sequence 2 (bit 0) and sequence 0 (bit 2), with bit 1 clear because sequence 1 never reached the session.

Row 4 confirms that a close from a foreign endpoint does not tear down the session.

Additional cases from the same class of experiment:

Case	Result
Two opens from the same source port	Two distinct tokens, both simultaneously usable
Same token replayed to the other address family's listener on the same port	No reply
Echo with an all-zero token	No reply
Echo with the token of an already-closed session	No reply
Repeated close with the same token	No reply
1000 opens from one source endpoint	1000 distinct tokens, all usable

---

3. Close Lifecycle

3.1 Client-initiated close

Capture: ../captures/server-close-lifecycle.pcapng. Session token eef1e3fb1ab2eb66, negotiated ReceivedStats = both, StampAt = none.

frame	direction	bytes
1	C → S	14a75b01 01020280e0ba84bf030380a8d6b9070506
2	S → C	14a75b03 eef1e3fb1ab2eb66 01020280e0ba84bf030380a8d6b9070506
3	C → S	14a75b00 eef1e3fb1ab2eb66 00000000 00000000 0000000000000000
4	S → C	14a75b02 eef1e3fb1ab2eb66 00000000 01000000 0100000000000000
5	C → S	14a75b00 eef1e3fb1ab2eb66 01000000 00000000 0000000000000000
6	S → C	14a75b02 eef1e3fb1ab2eb66 01000000 02000000 0300000000000000
7	C → S	14a75b00 eef1e3fb1ab2eb66 02000000 00000000 0000000000000000
8	S → C	14a75b02 eef1e3fb1ab2eb66 02000000 03000000 0700000000000000
9	C → S	14a75b04 eef1e3fb1ab2eb66 — close request
10	C → S	14a75b04 eef1e3fb1ab2eb66 — repeated close
11	C → S	14a75b00 eef1e3fb1ab2eb66 09000000 … — echo after close

Frames 9, 10 and 11 receive no response. Frame 9 removes the session; 10 and 11 are dropped as unknown-token packets. The capture ends with three unanswered client packets, which is the complete and correct close exchange for protocol version 1.

Close request layout: magic (3) + flags 0x04 (1) + token (8) = 12 bytes. With authentication: magic (3) + flags 0x0c (1) + MAC (16) + token (8) = 28 bytes.

3.2 Server-initiated close

Capture: ../captures/server-close.pcapng. Server configured with a maximum test duration of 2 s; client requested 600 s and was restricted to 2 s. Requests sent every ~250 ms.

frame	direction	bytes (abridged)	note
2	S → C	14a75b03 f0592d9fb129558c 010202 80d0acf30e 03…	duration restricted to 2 s
34	S → C	14a75b02 … 0f000000 10000000 ffff000000000000	ordinary reply, seq 15
35	C → S	14a75b00 … 10000000 …	echo seq 16
36	S → C	14a75b06 f0592d9fb129558c 10000000 11000000 ffff010000000000	flags 0x06 = Reply|Close
37	C → S	14a75b00 … 63000000 …	echo seq 99 — no reply

Frame 36 is a complete, ordinary echo reply — correct sequence number (16), correct token, count 17, window 0x1ffff — with the Close flag additionally set. The session is gone from that moment; frame 37 is unanswered.

Timing measurements of the deadline, from the first echo request of the session:

configured maximum duration	close flag observed at
1 s	3.01 s
2 s	4.06 s
2 s (second run)	4.10 s

The deadline is the configured maximum duration plus a 2-second grace period.

Boundary sweep, probes spaced 50 ms, offsets measured from the first served echo of the session:

configured maximum duration	last offset answered normally	first offset carrying Close
500 ms	2.45 s	2.50 s
1 s	2.95 s	3.00 s
3 s	4.95 s	5.00 s

The 2-second margin is additive across the configured maximum, not proportional to it. Reproduced on the 0.9.0 release, the 0.9.1 release and the tested post-0.9.1 development build.

What starts and what carries the deadline:

case	result
Session opened 5 s before its first echo	deadline unchanged — the open does not start it
First request oversized (dropped by the maximum-length policy)	clock not started; a later served echo starts it
First request from a foreign source endpoint (dropped)	clock not started; a later served echo starts it
Echo that crosses the deadline	full normal reply with Close set; counted in the received count and window it reports
Echo that crosses the deadline but is itself rate-limited	dropped, no reply; the next served echo carries the Close flag
Client's next echo after the close-flagged reply	no reply — token released
Client's close request after the close-flagged reply	no reply — token released

Two drop classes were tested as the session's first request — an oversized request and one from a foreign source endpoint — and neither started the deadline; a later served echo became the origin instead. The other drop classes of Section 9 were not tested in that position, and this vector makes no claim about them. The rate-limit row above concerns a request that crosses an already-running deadline, not one that would start it.

3.3 Observed upstream client reaction to a close-flagged reply

Driving an upstream 0.9.1 client against a server that sets the Close flag from sequence 2 onward:

seq=0  recorded
seq=1  recorded
seq=2  reply carries Close  -> run terminates

The client reports a "server closed connection" condition, prints the statistics for sequences 0 and 1 only — the close-flagged reply is not recorded — and exits with a success status.

---

4. Open Negotiation

4.1 Protocol version is not rejected

Server default configuration. Each row is an open request carrying only the listed ProtocolVersion value.

requested ProtocolVersion	server response	reply parameter payload
1	open reply, session created	0102 (version 1)
0	open reply, session created	0102 (version 1)
2	open reply, session created	0102 (version 1)
−1	open reply, session created	0102 (version 1)
tag absent entirely	open reply, session created	0102 (version 1)

In every case the reply flags were 0x03 (Open|Reply) with the Close flag clear and a non-zero token. Reply length 14 bytes: magic (3) + flags (1) + token (8) + 0102.

4.2 Parameter payload acceptance

open request parameter payload	response
empty	open reply, 14 bytes
tag 2 only, no value bytes	no reply
tag 2 with an incomplete multi-byte varint	no reply
version 1 + duration 0	no reply
version 1 + duration −1	no reply
version 1 + interval −5	no reply
version 1 + ReceivedStats 4	no reply
version 1 + ReceivedStats −1	no reply
version 1 + StampAt 5	no reply
version 1 + StampAt 4 + Clock 3	open reply
version 1 + Clock 0	no reply
version 1 + Clock 4	no reply
version 1 + unknown tag 42	open reply, tag ignored
version 1 + unknown tag 200	open reply, tag ignored
version 1 + 80 repetitions of unknown tag 42 (~200 bytes)	open reply, all ignored
version 1 + ServerFill declared 40 bytes	no reply
version 1 + ServerFill declaring 10 bytes with only 2 present	no reply
50 bytes of arbitrary data	no reply

4.3 No-test open

direction	bytes
C → S	14a75b05 + parameter payload — flags Open|Close
S → C	14a75b07 0000000000000000 + restricted parameters — flags Open|Reply|Close, zero token

With authentication the reply flags are 0x0f and the reply carries a valid MAC. The zero token is not usable: subsequent echo and close requests bearing it get no reply.

4.4 Interval restriction against the idle timeout

Client requests an interval of one hour; server has no configured minimum interval.

server idle timeout	negotiated interval
4 s	1 s
8 s	2 s
20 s	5 s
40 s	10 s
60 s	15 s

Client-side floor, measured with an upstream 0.9.1 client requesting a 1 s interval:

server idle timeout	server-returned interval	client outcome
2 s	500 ms	aborts — reduction below 1 s, in strict and loose mode
3 s	750 ms	aborts — reduction below 1 s, in strict and loose mode
4 s	1 s (no reduction)	proceeds

Requesting a 2 s interval against a 4 s idle timeout produces a reduction to exactly 1 s: rejected in strict mode as an ordinary restriction, accepted in loose mode.

Boundary rows with a configured minimum interval as well. The requested interval is raised to the minimum first and capped to (idle timeout ÷ 4) afterwards, so the returned value can end up below the configured minimum:

server minimum interval	server idle timeout	requested	negotiated
100 ms	1 min	10 ms	100 ms — raised to the minimum
100 ms	1 min	100 ms	100 ms — unchanged
100 ms	1 min	60 s	15 s — capped at timeout ÷ 4
5 s	4 s	10 ms	1 s — the cap wins, below the configured minimum
5 s	0 (disabled)	10 ms	5 s — no cap applies
0	4 ns	10 ms	1 ns
0	1 ns	10 ms	absent from the reply — the cap is 0, and a restricted value of zero is omitted

4.5 Timestamp allowance

Requested StampAt → negotiated StampAt, by server timestamp allowance:

requested	dual	single	none
0 (none)	0	0	0
1 (send)	1	1	0
2 (receive)	2	2	0
3 (both)	3	4	0
4 (midpoint)	4	4	0

4.6 Repeated occurrences of a known tag

One open request per row, carrying the listed occurrences of a single tag.

parameter payload	result
Duration 1 s, then Duration 2 s	open reply, Duration 2 s
Duration 2 s, then Duration 1 s	open reply, Duration 1 s
Clock 1, then Clock 3	open reply, Clock 3
Clock 3, then Clock 4 (out of range)	no reply
Duration 1 s, then Duration 0 (invalid)	no reply
Duration 0 (invalid), then Duration 1 s	no reply
ServerFill rand, then a 33-character string (invalid)	no reply

Among valid duplicates, the last occurrence wins for every known tag tested: ProtocolVersion, Duration, Interval, Length, ReceivedStats, StampAt, Clock, DSCP and ServerFill. Duration was additionally tested with an invalid occurrence in both orders, and both requests were dropped. Clock and ServerFill were tested with an invalid second occurrence, which was also dropped. The untested invalid orders and parameters are not generalized here.

4.7 Absent Clock with a non-none restricted StampAt — upstream-defect vector

Capture: ../captures/server-clock-absent.pcapng. Default-configuration server. This vector records an upstream robustness defect (server specification Section 22.5) when timestamp restriction leaves the requested non-none StampAt non-none. It is a must-not-crash recommendation for a clean implementation, not a behavior to reproduce.

frame	direction	bytes	note
1	C → S	14a75b01 05 06 06 06 04 00	open; ReceivedStats = 3, StampAt = 3 (both), Length = 0, no Clock tag
2	S → C	14a75b03 7ca44127b2cd7eab 01 02 05 06 06 06	open reply, non-zero token, ProtocolVersion 1, ReceivedStats 3, StampAt 3 — no Clock parameter
3	C → S	14a75b00 7ca44127b2cd7eab 00000000	first echo, sequence 0

Frame 3 is the last packet in the capture. It receives no reply, and the server process terminates; every other session on that process, on either address family, stops being served at the same moment.

variation	result
Requested StampAt 1 (send), no Clock; restricted StampAt non-none	open accepted, first echo fatal
Requested StampAt 2 (receive), no Clock; restricted StampAt non-none	open accepted, first echo fatal
Requested StampAt 3 (both), no Clock; restricted StampAt non-none	open accepted, first echo fatal
Requested StampAt 4 (midpoint), no Clock; restricted StampAt non-none	open accepted, first echo fatal
Requested StampAt 0 (none), no Clock	open accepted, session serves normally with no timestamps
StampAt 3, explicit Clock = 0	open dropped, no reply, no session — see Section 4.2
Requested StampAt 1 / 2 / 3 / 4, no Clock; no-timestamp policy restricts StampAt to none	open accepted, session serves normally with no timestamps
Requested StampAt 1 / 2 / 3 / 4, no Clock; single-timestamp policy leaves restricted StampAt non-none	open accepted, first echo fatal

The last two rows are scoped to requested non-none, absent-Clock cases only: fatality depends on the server's restricted (effective) StampAt remaining non-none. The StampAt 0 row is served normally whatever the server's timestamp policy, and the explicit Clock = 0 row is rejected during negotiation before any policy applies; neither becomes fatal under either configuration.

Reproduced on the 0.9.0 release, the 0.9.1 release and the tested post-0.9.1 development build.

The last four rows are the point of the vector: an omitted Clock and an explicit Clock = 0 are different inputs with opposite upstream outcomes.

---

5. Reply Length

5.1 Length as a function of negotiated fields

Reply lengths, unauthenticated, measured across every combination. S is ReceivedStats, A is StampAt, C is Clock.

S	A	C	reply length
0	0	any	16
1	0	any	20
2	0	any	24
3	0	any	28
3	1 or 2	1 or 2	36
3	1 or 2	3	44
3	3	1 or 2	44
3	3	3	60
3	4	1 or 2	44 — see below
3	4	3	44

Add 16 bytes to every figure when authentication is in use.

5.2 Dual-field midpoint wire representation

For StampAt = 4 (midpoint), upstream 0.9.1 emits two 8-byte timestamp fields — the midpoint wall field followed by the midpoint monotonic field, in that order — for every negotiated Clock, occupying a fixed 16-byte region. With a single negotiated clock this is one field more than the negotiated parameters imply. These rows record bytes observed on the wire and nothing else. All vectors below at negotiated length 0.

S	A	C	expected from negotiation	observed
0	4	1	24	32
0	4	2	24	32
0	4	3	32	32
1	4	1	28	36
1	4	2	28	36
2	4	1	32	40
2	4	2	32	40
3	4	1	36	44
3	4	2	36	44
3	4	3	44	44

Raw reply for S=0, A=4, C=1 (wall only), 32 bytes:

14 a7 5b 02  <token 8>  00 00 00 00
a4 c1 74 90 47 83 ca 18      <- midpoint wall,      1786384545595310500
da 45 a2 3b 00 00 00 00      <- midpoint monotonic, 1000490458

The second field was not negotiated. An upstream 0.9.1 client run in this configuration reports "packet length: 36 bytes" while receiving 44-byte datagrams, and completes normally.

No other StampAt value deviates. Measured at negotiated length 0, S=3: A=1 and A=2 give 36 bytes for C=1 or C=2 and 44 for C=3; A=3 gives 44 for C=1 or C=2 and 60 for C=3 — all exactly as the negotiated layout implies.

5.2.1 The excess is bounded by the negotiated length

The extra field enlarges the field block, not every reply. Reply length remains the larger of the negotiated length and the field block (Section 5.3):

normal_header   = negotiated field block
upstream_header = normal_header + one 8-byte timestamp field

compatible_reply_len     = max(negotiated_length, normal_header)
upstream_0_9_1_reply_len = max(negotiated_length, upstream_header)

Sweep for S=3, A=4, C=1 — normal_header 36, upstream_header 44:

negotiated length	0	16	32	36	37	40	43	44	45	48	64	128	1024	4096
reply datagram	44	44	44	44	44	44	44	44	45	48	64	128	1024	4096
excess	+8	+8	+8	+8	+7	+4	+1	0	0	0	0	0	0	0

Same pattern for the other received-stats settings, with the two minima at 24/32 (S=0), 28/36 (S=1) and 32/40 (S=2). The C=3 control case shows zero excess at every negotiated length.

At negotiated length 4096 the midpoint region still holds both fields, followed by fill — the extra field displaces payload rather than extending the datagram. The excess is therefore +8, then +7…+1, then 0, depending on the negotiated length. There is no negotiated length at which the reply is universally "negotiated length + 8".

Read that row across columns, not within a column. Each column is a separate negotiation whose upstream reply has exactly one length, upstream_0_9_1_reply_len. The +8 / +7…+1 / 0 figures are the values the difference takes across different negotiations; no single negotiation produces a range of lengths, and nothing here says an intermediate length between compatible_reply_len and upstream_0_9_1_reply_len was ever emitted or should be accepted.

Consequence for decoding. In the zero-excess regime (upstream_0_9_1_reply_len == compatible_reply_len) the upstream form [wall][mono][payload…] and a conforming single-clock form [mono][payload…] produce datagrams of identical length, and the vectors above provide no way to tell them apart. That ambiguity is recorded, not resolved.

5.2.2 Reached without requesting midpoint

Server restricted to a single timestamp, S=3, negotiated length 0:

requested A/C	negotiated A/C	expected from negotiation	observed
3 / 1	4 / 1	36	44
3 / 2	4 / 2	36	44
3 / 3	4 / 3	44	44
4 / 1	4 / 1	36	44

5.2.3 Version comparison

Negotiated length 0, S=3:

build	A=4, C=1	A=4, C=2	A=4, C=3
0.9.0 release	36, one field	36, one field (process-relative value)	44, two fields
0.9.1 release	44, two fields	44, two fields	44, two fields
tested post-0.9.1 tree (six upstream commits past the 0.9.1 tag)	44, two fields	44, two fields	44, two fields

The 0.9.0 release emits exactly the negotiated fields; 0.9.1 emits the dual-field form; the tested post-0.9.1 tree behaves like 0.9.1. The six post-0.9.1 commits are post-release work and are not part of the 0.9.1 release.

A contaminated-side server emitting only the negotiated midpoint field was driven by an upstream 0.9.1 client for wall-only, monotonic-only and dual-clock midpoint configurations, and the client completed every run cleanly. This is contaminated-side consistency validation; the black-box part of it is the client's acceptance of the conforming form.

5.3 Negotiated length versus actual reply length

Server bound to an interface with a 1500-byte MTU, ReceivedStats = none, StampAt = none (16-byte field block).

requested length	negotiated length returned	reply datagram
0	0	16
10	10	16
16	16	16
17	17	17
1000	1000	1000
1400	1400	1400
1500	1500	1500
1501	1501	1500
2000	2000	1500
3000	3000	1500
8000	8000	1500

The negotiated value returned to the client is not clamped; the datagram is.

A session negotiating a length of 0 or 20 with full statistics and dual timestamps on both clocks produced 60-byte replies — the field block wins when it is larger than the negotiated length.

5.4 Request length versus reply length

negotiated length	request datagram	reply datagram
16	216 (200 trailing bytes)	16
64	16	64
64	32	64
64	64	64

The reply length depends only on the negotiation, never on the request.

5.5 Maximum request length policy

Server configured with a maximum packet length of 64; client requested 200 and was restricted to 64.

request datagram	result
16	reply, 64 bytes
32	reply, 64 bytes
64	reply, 64 bytes
65	no reply
100	no reply
open request larger than 64	accepted, open reply sent

Server configured with a maximum packet length of 10 (below the minimum field block): the session opens and negotiates a length of 10, and every 16-byte echo request is dropped.

---

6. Server Fill

6.1 Default fill bytes and pattern phase

Default-configuration server, ReceivedStats = none, StampAt = none, so the payload begins at offset 16.

negotiated length	reply payload
17	69
20	72 74 74 69
24	72 74 74 69 72 74 74 69
48	72 74 74 69 repeated 8 times

Four consecutive replies on one session with a 7-byte payload:

seq 0: 72 74 74 69 72 74 74
seq 1: 69 72 74 74 69 72 74
seq 2: 74 69 72 74 74 69 72
seq 3: 74 74 69 72 74 74 69

The four-byte pattern 69 72 74 74 is emitted as a continuous stream; its phase is not reset per packet, and it carries over between sessions on the same listener.

6.2 Fill descriptor negotiation

Default allow-list (random fills only), negotiated length 32 so the payload is 16 bytes:

requested descriptor	negotiated descriptor returned	payload
rand	rand	random, differs per packet
none	pattern:69727474	72747469…
pattern:aabb	pattern:69727474	72747469…
pattern:69727474	pattern:69727474	72747469…
bogus	pattern:69727474	72747469…
32-character string	pattern:69727474	72747469…
33-character string	—	open dropped

Permissive allow-list:

requested descriptor	negotiated descriptor returned	payload
rand	rand	random
pattern:aabb	pattern:aabb	aabbaabbaabbaabb…
pattern:00	pattern:00	0000000000000000…
pattern:ff00	pattern:ff00	ff00ff00ff00ff00…
pattern:zz	pattern:69727474	69727474… (invalid hex, falls back)
none	none	unspecified residual bytes
pattern:	—	server terminated

Empty allow-list: every requested descriptor, including rand, is answered with pattern:69727474.

6.3 The refused descriptor does not describe the payload

Two servers with different configured fills, default allow-list (rand only), negotiated length 32 so the payload is 16 bytes:

Server fill	Requested descriptor	Negotiated descriptor returned	Payload
random	none	absent	25ae387a787d641d82eb514f2bfca15f (random)
random	pattern:aabb	pattern:69727474	29ce866b6d192c74376e7161dd71975d (random)
random	rand	rand	random
pattern:abcd	none	absent	abcdabcdabcdabcdabcdabcdabcdabcd
pattern:abcd	pattern:aabb	pattern:69727474	abcdabcdabcdabcdabcdabcdabcdabcd
pattern:abcd	rand	rand	random

On refusal, the descriptor returned to the client is a fixed default string, not a description of the bytes the server actually sends. A client must not predict payload content from it.

6.4 No-fill payload content

Server configured with no fill and a permissive allow-list, negotiated length 32 (16-byte payload):

request payload	reply payload
000102…0f (16 bytes)	000102…0f — the request's own bytes
none (16-byte request)	000102…0f — residue from the previous packet

On a none fill negotiated through the descriptor, one observed 16-byte payload was c0cbacf6220380897a044009 046e6f6e, whose trailing bytes are a fragment of the preceding open reply's parameter payload. Payload content under no-fill is unspecified and may contain data from unrelated traffic.

---

7. Authentication

Server configured with key correctkey.

request	result
Open, flags 0x09, valid MAC	Open reply, flags 0x0b, valid MAC, 43 bytes
Echo, flags 0x08, valid MAC	Echo reply, flags 0x0a, valid MAC, 44 bytes
Close, flags 0x0c, valid MAC	Session removed, no reply
No-test open, flags 0x0d, valid MAC	Reply flags 0x0f, zero token, valid MAC
Open with no HMAC flag and no MAC field	no reply
Echo with no HMAC flag and no MAC field	no reply
Close with no HMAC flag and no MAC field	no reply, session survives
Open with MAC computed under a different key	no reply
Echo with MAC computed under a different key	no reply
Echo with one bit flipped in the MAC	no reply
Echo with the MAC field all zeros	no reply
Echo with the MAC field truncated to 8 bytes	no reply
19-byte datagram (too short for the MAC field)	no reply
20-byte datagram, flags 0x08, valid MAC, nothing else	no reply
Valid MAC but the HMAC flag cleared in flags	no reply
MAC recomputed with the flag cleared, flag cleared	no reply

Against a server with no key, any request with the HMAC flag set gets no reply.

Session integrity across failures. After the eight failing cases above were sent to a live session, the next correctly authenticated echo was served normally and the received count had advanced only for the accepted packets.

Reply authentication is mandatory. A contaminated-side server that authenticated its open reply correctly but omitted the HMAC flag from echo replies caused an upstream 0.9.1 client to discard every echo reply and terminate abnormally with zero packets received. The observation that matters is the client's reaction, which is black-box; the server was only the stimulus.

---

8. Idle Expiry

Server configured with a 2-second idle timeout. Each trial: open, one echo to start the idle clock, wait, then two echoes back to back.

gap after the last accepted echo	first request after the gap	the request after that
5.0 s	answered	answered
6.5 s	answered	answered
6.9 s	answered	answered
7.1 s	answered	dropped
7.5 s	answered	dropped
9.0 s	answered	dropped

Observed session-release boundary = idle timeout + 5 s. The first otherwise-serviceable request past that boundary is still answered once by upstream, and the immediate follow-up is dropped. Section 8.3 shows what happens when a packet that would be dropped anyway touches the token first.

A session that has never carried an echo request does not expire. With the same 2-second timeout, a session left completely idle for 9 seconds after open was served normally on its first echo request.

With the idle timeout disabled, a session idle for 9 seconds was served normally and remained usable.

8.1 The grace is additive across configured timeouts

Session-release boundary sweep, probes spaced 50 ms, three repetitions per row, gaps measured from the last accepted echo. Each probe used a first otherwise-serviceable echo after the gap and an immediate follow-up; the boundary is inferred from whether that follow-up was dropped:

configured idle timeout	longest gap with follow-up served	shortest gap with follow-up dropped
500 ms	5.45 s	5.50 s
2 s	6.95 s	7.00 s
4 s	8.95 s	9.00 s

Every row sits at timeout + 5 s to within the probe spacing. At and beyond the observed release boundary, the first otherwise-serviceable post-gap echo may still receive a final lazy-release reply; the immediate follow-up is then dropped. The margin is the same five seconds at each timeout, so it is additive rather than proportional, and the boundary did not move with when the session was opened. Reproduced on the 0.9.0 release, the 0.9.1 release and the tested post-0.9.1 development build.

8.2 Which drop classes keep a session alive

Per row: open a session, send one echo (count 1), inject the listed packet, then send another echo. The second echo's count shows whether the injected packet was counted; separate timing trials show whether it moved the expiry boundary.

injected packet	counted / window advanced	extends the idle lifetime
bad magic	no	no
invalid flag bits	no	no
Reply or Open flag on a data packet	no	no
unknown token, or a zero token	no	no
valid token from a foreign source endpoint	no	no — but see 8.3
echo truncated before the sequence number	no	no
request over the configured maximum length	no	no
bad, missing or zeroed MAC	no	no
request with no rate allowance left	no	yes

The rate-limit row was separated from the alternatives three ways: a session fed only too-fast requests outlived its idle deadline; the same cadence of oversized requests did not; and a silent session expired on schedule. Reproduced on all three builds. It is the only tested drop class that keeps a session alive.

8.3 The first packet to release an expired session determines whether a final reply is emitted

Capture: ../captures/server-expiry-consumption.pcapng. Server idle timeout 3 s, so the effective boundary is 8 s after the last accepted echo. Both trials are in the one capture, which is why it is worth keeping: the control and the test differ by a single injected packet.

Control — session on port 49865, token fff56ec42eb8caaa:

frame	t	direction	packet	observed
3	0.00 s	C → S	echo seq 0	reply, count 1
5	8.00 s	C → S	echo seq 1 — first past the deadline	reply, count 2
7	8.00 s	C → S	echo seq 2	no reply — session released

Test — session on port 53237, token 9e27590dbb016eb9, opened at 8.70 s:

frame	t	direction	packet	observed
10	8.70 s	C → S	echo seq 0	reply, count 1
12	16.71 s	X → S	echo seq 9, correct token, foreign source port 64688	no reply — foreign endpoint, as at any time
13	17.02 s	C → S	echo seq 1 — the client's first past the deadline	no reply
14	17.72 s	C → S	echo seq 2	no reply

Frame 13 is the result. In the control the equivalent request was answered; here the foreign-endpoint packet at frame 12 arrived 0.3 s earlier, just past the same deadline, and the session was already gone. The foreign packet was itself dropped and released the session without receiving a reply, so no later request received a final reply. Whether it advanced the received count first cannot be read from this trial — the session emitted no further reply, so no statistic reports it. The not-counted result of Section 2 was measured on a live session, where a later reply exposed the count, and does not carry over to this path.

The same effect was produced by a truncated echo, an oversized echo, a close request from a foreign endpoint, and a burst of unrelated ordinary opens arriving before the legitimate client's post-deadline request. These are the classes that were tested; the effect is not claimed for every possible packet.

injected before the client's post-deadline request	client's post-deadline request
nothing (control)	answered, then the next one dropped
echo from a foreign source endpoint	unanswered
truncated echo	unanswered
oversized echo	unanswered
close from a foreign source endpoint	unanswered
burst of unrelated ordinary opens	unanswered
burst of unrelated no-test opens	answered — no-test opens create no session and reclaim none

---

9. Malformed Packet Admission

Session established; probes sent on the same socket. Prefix used: 14a75b00 + token + 00000000.

probe	result
0–3 byte datagram	no reply
4–11 byte datagram (flags 0x00)	no reply
12–15 byte datagram (flags 0x00)	no reply
16-byte datagram (flags 0x00)	reply, 28 bytes
magic 15a75b	no reply
magic 000000	no reply
flags 0x10, 0x20, 0x40, 0x80, 0xf0, 0xff, 0x1f	no reply
flags 0x02, 0x03, 0x06, 0x07, 0x0a (Reply set)	no reply
flags 0x09 (Open|HMAC) to a non-authenticating server	no reply
flags 0x01 (Open)	open reply, new session
flags 0x05 (Open|Close)	open reply, zero token
echo-shaped datagram with flags 0x01	treated as an open; the token bytes are parsed as parameters
close with 20 trailing bytes	no reply, session removed

A 12-byte datagram with flags 0x04 is a valid close request; a 12-byte datagram with flags 0x00 is too short to be an echo request and is dropped.

The Open flag decides interpretation, not admission. For an otherwise admissible datagram it wins over Close (0x05 is the no-test open form) and over an echo-shaped body (the token/sequence bytes are read as Open parameter data). It does not rescue a datagram from an independent rejection: 0x03 (Open|Reply) is dropped for the Reply flag, 0x09 (Open|HMAC) to a non-authenticating server is dropped for the authentication mismatch, 0x1f is dropped for the undefined flag bits, and an Open whose parameter payload is malformed or out of range is dropped as well (Section 4.2).

---

10. DSCP Negotiation and Application

The values below are raw IP TOS / Traffic Class byte values, which is what the wire parameter carries — not 6-bit codepoints. Expedited Forwarding is therefore 184 (0xb8) in this table, not 46.

requested DSCP	negotiated value returned	echo replies
0	absent (0)	delivered
46	46	delivered
184	184	delivered
255	255	delivered
256	256	no ECHO reply observed
300	300	no ECHO reply observed
−5	−5	delivered

With DSCP disallowed by server policy, every requested value is returned as absent (0) and replies are delivered normally.

An out-of-range value is still accepted during negotiation; for values of 256 or above the session opens successfully but no ECHO reply was observed. Only that session is affected — the server kept serving its other sessions throughout.

10.1 Interleaved sessions do not leak marks

Capture: ../captures/server-dscp-interleaved.pcapng. Four sessions opened back to back on one listener, then driven in three interleaved rounds of one echo each. The TOS byte column is the value read from the reply's IP header.

session (source port)	requested DSCP	open reply TOS	echo reply TOS, rounds 1–3
62913	46	0x00	0x2e, 0x2e, 0x2e
52559	8	0x00	0x08, 0x08, 0x08
57975	not requested	0x00	0x00, 0x00, 0x00
64688	184	0x00	0xb8, 0xb8, 0xb8

For each session in this capture, whose negotiated value is in 0..=255, every echo reply carries its own session's value verbatim; no reply carried another session's value in any round. All four open replies are unmarked.

Note what this capture does not show: its four open exchanges are frames 1–8 and its first marked echo reply is frame 10, so no open reply here follows a marked reply. For that ordering see Section 10.2.

10.2 Marking of the other packet kinds

packet	marking
open reply	always TOS 0, whatever the session negotiated
echo reply	the session's negotiated value, verbatim for values in 0..=255 (see Section 10.3 for other values)
server-initiated close reply (Section 3.2)	measured to carry the same session marking for values in 0..=255; no capture in this set shows it — the close-flagged reply in ../captures/server-close.pcapng is from a session that negotiated no DSCP, and is TOS 0
client-initiated close	no reply is sent at all

An open reply is unmarked even on a listener that has already sent marked replies. From ../captures/dscp-values.pcapng, one listener serving two sessions in sequence:

frame	packet	TOS
3	echo request, session 1 (DSCP 8)	0x08
4	echo reply, session 1	0x08
5	close, session 1	0x00
6	open request, session 2	0x00
7	open reply, session 2	0x00
8	echo request, session 2 (DSCP 32)	0x20
9	echo reply, session 2	0x20

Frame 7 is the point: it follows the marked reply of frame 4 on the same listener and is still unmarked.

10.3 Observed handling of negative and out-of-range DSCP values

requested DSCP	address family	observed
−1	IPv4	wire TOS 255 — the only negative value whose emitted marking was recorded; the transformation is not identified
−1	IPv6	traffic class 0
256 and above	either	negotiated and echoed back; no ECHO reply observed for that session

The v4/v6 difference was observed on the tested host, not established as a wire rule, and a compatible server is under no obligation to reproduce it.

---

11. Captures

File	Contents
../captures/server-recv-window.pcapng	One session exercising sequential, gap, duplicate, reorder and far-gap sequence numbers
../captures/server-close-lifecycle.pcapng	Client-initiated close, repeated close, and an echo after close — none answered
../captures/server-close.pcapng	Server-initiated close via the maximum-duration limit; frame 36 carries flags 0x06
../captures/server-session-identity.pcapng	Foreign-source-port echo and close, unknown token, and the original endpoint continuing to be served
../captures/server-clock-absent.pcapng	An open selecting timestamps but omitting the Clock tag is answered with a token and no Clock parameter; the first echo is the last packet in the exchange (Section 4.7)
../captures/server-expiry-consumption.pcapng	Control versus foreign-endpoint-first: whether the packet that releases an expired session emits a final reply (Section 8.3)
../captures/server-dscp-interleaved.pcapng	Four interleaved sessions with distinct DSCP values, three rounds each, no cross-session leakage, unmarked open replies (Section 10.1)

All captures are loopback traffic with the server on a fixed port and the client on an ephemeral port.

Capture container metadata. Every .pcapng under ../captures/ was reviewed and its container rewritten so that it carries no capture comment, no section/interface description, no host, user or capture-machine identification, no capture filter string, and no filesystem path — only the packet records and the rewriting tool's own version string. Packet bytes and timestamps were not altered: for each file, the full frame hexdump and the per-frame epoch timestamps were verified byte-identical before and after the rewrite.

The three captures added on 2026-08-12 were rewritten and verified the same way, and their packet counts are 3, 14 and 32 respectively, unchanged from the originals.