Flow and Retransmission Control Protocol - Revision history

Dimitri: /* 8. Retransmission */

2026-05-18T16:11:20Z

8. Retransmission

← Older revision		Revision as of 16:11, 18 May 2026
Line 770:		Line 770:
	[[#15. Heritage and adopted techniques\|Section 15]]):		[[#15. Heritage and adopted techniques\|Section 15]]):

	* <code>t_a</code> (a-timer): upper bound on ACK delay. An ACK for a received DATA packet MUST be emitted ~~within~~ <code>t_a</code> of receipt; an attempt to send an ACK after the a-timer has expired is suppressed ~~(the sender's RTO is already in motion)~~.		* <code>t_a</code> (a-timer): upper bound on ACK delay. An ACK for a received DATA packet MUST NOT be emitted after <code>t_a</code> of receipt; an attempt to send an ACK after the a-timer has expired is suppressed.
	* <code>t_r</code> (r-timer): upper bound on retransmission. A given DATA packet MUST NOT be retransmitted after <code>t_r</code> has elapsed since its first send (<code>t0</code>); when the bound is hit, the flow is declared down (raising the Ouroboros asynchronous flow condition <code>ACL_FLOWDOWN</code>, which marks the flow dead to both endpoints) rather than retransmitted again.		* <code>t_r</code> (r-timer): upper bound on retransmission. A given DATA packet MUST NOT be retransmitted after <code>t_r</code> has elapsed since its first send (<code>t0</code>); when the bound is hit, the flow is declared down (raising the Ouroboros asynchronous flow condition <code>ACL_FLOWDOWN</code>, which marks the flow dead to both endpoints) rather than retransmitted again.

Line 792:		Line 792:
	;NewReno		;NewReno
	:On entry, <code>recovery_high = snd_cr.seqno + RTT_QUARANTINE</code>. Exit when <code>ackno >= recovery_high</code> or <code>ackno == snd_cr.seqno</code> (the latter means everything sent has been acknowledged). <code>seqno_rotate</code> also clears recovery.		:On entry, <code>recovery_high = snd_cr.seqno + RTT_QUARANTINE</code>. Exit when <code>ackno >= recovery_high</code> or <code>ackno == snd_cr.seqno</code> (the latter means everything sent has been acknowledged). <code>seqno_rotate</code> also clears recovery.


	== 9. Pre-DRF NACK ==		== 9. Pre-DRF NACK ==

Dimitri: /* 4. Sequence-number rotation (DRF) */

2026-05-18T16:06:09Z

4. Sequence-number rotation (DRF)

← Older revision		Revision as of 16:06, 18 May 2026
Line 549:		Line 549:
	(<code>now - rcv_cr.act > rcv_cr.inact</code>), requires a DRF on the next		(<code>now - rcv_cr.act > rcv_cr.inact</code>), requires a DRF on the next
	DATA packet; otherwise it replies with a rate-limited NACK (see		DATA packet; otherwise it replies with a rate-limited NACK (see
	below). Non-DATA control packets pass through without the DRF		below). Non-DATA control packets pass through without the DRF
	requirement. On DRF the receiver releases the <code>rq[]</code> slots and		requirement (no impact on receiver state). On DRF the receiver releases the <code>rq[]</code> slots and
	rebases		rebases

Line 562:		Line 562:
	fired back to the sender (cooldown per [[#3. Protocol parameters\|Section 3]]); non-DATA stale		fired back to the sender (cooldown per [[#3. Protocol parameters\|Section 3]]); non-DATA stale
	arrivals fall through to normal processing (no NACK, no drop).		arrivals fall through to normal processing (no NACK, no drop).


	== 5. Send path ==		== 5. Send path ==

Dimitri: /* 1.1. PCI header */

2026-05-18T01:06:47Z

1.1. PCI header

← Older revision		Revision as of 01:06, 18 May 2026
Line 125:		Line 125:

	* HCS in the PCI covers the header fields on every packet and is verified before any flag-driven dispatch.		* HCS in the PCI covers the header fields on every packet and is verified before any flag-driven dispatch.
	* The CRC-32 trailer (IEEE 802.3 / zlib reflected polynomial <code>0xEDB88320</code>, init <code>0xFFFFFFFF</code>, xor-out <code>0xFFFFFFFF</code>) covers the body on DATA when <code>qs.ber == 0</code> and on every SACK packet~~; the trailer is written as a raw <code>uint32_t</code> (the same convention as <code>hcs</code>: opaque on the wire as long as both peers run compatible builds)~~. The PCI is not under the CRC (Cyclic Redundancy Check) because the HCS already protects it. It is appended before AEAD encryption and therefore rides inside the AEAD wrap when both are active; the AEAD tag (~2^-128 forgery probability) dominates the CRC (~2^-32) for integrity in that mode but the CRC trailer is currently retained.		* The CRC-32 trailer (IEEE 802.3 / zlib reflected polynomial <code>0xEDB88320</code>, init <code>0xFFFFFFFF</code>, xor-out <code>0xFFFFFFFF</code>) covers the body on DATA when <code>qs.ber == 0</code> and on every SACK packet. The PCI is not under the CRC (Cyclic Redundancy Check) because the HCS already protects it. It is appended before AEAD encryption and therefore rides inside the AEAD wrap when both are active; the AEAD tag (~2^-128 forgery probability) dominates the CRC (~2^-32) for integrity in that mode but the CRC trailer is currently retained.
	* When encryption is enabled, the entire (possibly-CRC'd) FRCP packet is wrapped with AEAD inside the shared-memory packet buffer (<code>spb</code>, <code>struct ssm_pk_buff</code>); the packet grows by the AEAD overhead, namely a leading nonce / Initialization Vector (IV) of <code>headsz</code> bytes (<code>crypt_get_ivsz</code>) and a trailing authentication tag of <code>tailsz</code> bytes (<code>crypt_get_tagsz</code>).		* When encryption is enabled, the entire (possibly-CRC'd) FRCP packet is wrapped with AEAD inside the shared-memory packet buffer (<code>spb</code>, <code>struct ssm_pk_buff</code>); the packet grows by the AEAD overhead, namely a leading nonce / Initialization Vector (IV) of <code>headsz</code> bytes (<code>crypt_get_ivsz</code>) and a trailing authentication tag of <code>tailsz</code> bytes (<code>crypt_get_tagsz</code>).

Dimitri: /* 1.1. PCI header */

2026-05-18T01:04:52Z

1.1. PCI header

← Older revision		Revision as of 01:04, 18 May 2026
Line 67:		Line 67:
	Fixed 16-octet base Protocol-Control Information (PCI) header		Fixed 16-octet base Protocol-Control Information (PCI) header
	prefixed to every FRCP packet (RFC convention: bit 0 leftmost,		prefixed to every FRCP packet (RFC convention: bit 0 leftmost,
	most-significant bit first). All multi-byte fields ~~except <code>hcs</code>~~		most-significant bit first). All multi-byte fields are in network byte order. DATA packets on
	are in network byte order~~; <code>hcs</code> is an opaque 16-bit value that~~
	~~the receiver recomputes from the wire bytes and compares to the~~
	~~in-place <code>pci->hcs</code> read, so its on-wire byte order need only~~
	~~match between peers running compatible builds~~. DATA packets on
	stream-mode flows carry an additional 8-octet extension (see		stream-mode flows carry an additional 8-octet extension (see
	[[#1.5. Stream PCI extension\|Section 1.5]]); SACK and RTTP carry their own payloads after the		[[#1.5. Stream PCI extension\|Section 1.5]]); SACK and RTTP carry their own payloads after the
Line 133:		Line 129:

	Both CRC and AEAD are layered around the FRCP wire format and are not visible to the FRCP machinery itself.		Both CRC and AEAD are layered around the FRCP wire format and are not visible to the FRCP machinery itself.


	=== 1.2. Flag bits ===		=== 1.2. Flag bits ===

Dimitri: /* 1.3. SACK payload */

2026-05-17T15:24:25Z

1.3. SACK payload

← Older revision		Revision as of 15:24, 17 May 2026
Line 249:		Line 249:
	bit, no extra framing. Modular seqno arithmetic uses the		bit, no extra framing. Modular seqno arithmetic uses the
	<code>before()</code> / <code>after()</code> comparators defined in the Notation block.		<code>before()</code> / <code>after()</code> comparators defined in the Notation block.
	<code>~~Block~~[0]</code> ~~carries~~ a D-~~SACK report when either~~:
			Encoding. When a duplicate is observed the receiver arms a
			single-slot pending report (<code>dsack_seqno</code> + <code>dsack_valid</code>,
			latest-wins across multiple arms before the next emit). On the
			next outbound SACK the receiver prepends <code>block[0] = [dsack_seqno,
			dsack_seqno + 1)</code> - always a one-<code>seqno</code> range - and clears the
			flag. The three arm sites are listed in [[#10. Cumulative + selective ACK\|Section 10]]; case-1 sites
			yield <code>dsack_seqno < rcv_cr.lwe</code> (the next <code>pci.ackno</code>), and the
			case-2 site (<code>rq_accept</code> conflict) yields <code>dsack_seqno</code> in
			<code>[rcv_cr.lwe, rcv_cr.rwe)</code>.

			Detection. The sender classifies <code>block[0]</code> by its relation to
			<code>pci.ackno</code>:

	;case 1 (RFC 2883 sec. 4.1.1, full duplicate)		;case 1 (RFC 2883 sec. 4.1.1, full duplicate)
	:<code>before(blocks[0].start, ackno)</code> ~~and~~ <code>ackno - blocks[0].start~~</code> is within <code>~~MAX_DSACK_LAG</code> (<code>== RQ_SIZE</code>). ~~A single duplicate <code>seqno</code> observed below the cumulative ACK~~.		:<code>before(blocks[0].start, pci.ackno)</code> AND <code>pci.ackno - blocks[0].start <= MAX_DSACK_LAG</code> (<code>== RQ_SIZE</code>). The lag bound rejects stale or spoofed reports beyond one receive window.
	;case 2 (RFC 2883 sec. 4.1.2, partial duplicate)		;case 2 (RFC 2883 sec. 4.1.2, partial duplicate)
	:<code>blocks[0]</code> is a sub-range of some <code>blocks[i>0]</code> (~~not exactly equal~~). ~~Reports a duplicate of an in~~-~~window~~ <code>~~seqno~~</code> ~~that~~ the ~~same packet's remaining~~ SACK blocks ~~already describe~~ as ~~received~~.		:<code>blocks[0]</code> is a sub-range (with at least one endpoint differing) of some <code>blocks[i>0]</code> - i.e. the same packet's remaining SACK blocks already describe the duplicated <code>seqno</code> as received.

			On detect, the sender:

			* bumps <code>reo_wnd_mult</code> by 1, capped at <code>REO_WND_MULT_MAX</code> (= 20), per RFC 8985 sec. 6.2 step 4;
			* snapshots <code>dsack_lwe_snap = snd_cr.lwe</code>, resetting the 16-cum-ACK halving counter so the multiplier doesn't decay while D-SACK evidence is still arriving;
			* excludes <code>block[0]</code> from the gap-marking loop (<code>n_real = n - 1</code>), so a D-SACK alone never enters NewReno-careful recovery (see [[#8. Retransmission\|Section 8]]); only non-D-SACK blocks count as gaps.

	~~On receipt the sender feeds <code>block[0]</code> into the RACK~~		The <code>reo_wnd_mult</code> halving cadence (once per 16 cumulatively-ACK'd
	<code>reo_wnd_mult</code> ~~scaler~~ (~~RFC 8985 sec. 6.2 step 4): bump on receipt~~		seqnos since the most-recent D-SACK arrival or halve event) and
	~~(cap 20), halve~~ once per 16 cumulatively-ACK'd seqnos since the		the reset-to-1 on a HoL RTO fire are both per the same RFC 8985
	most recent D-SACK arrival or halve event, reset to 1 on an RTO		clause. The clamp-and-skip path in the regular SACK-mark loop is
	~~timer~~ fire at the ~~head-of-line. D-SACK alone never enters~~		incidentally idempotent on any leftover case-1 or case-2 block
	~~NewReno-careful recovery (see [[#8. Retransmission\|Section 8]]); only non-D-SACK blocks~~		(<code>start < snd_cr.lwe</code> clamps to <code>snd_cr.lwe</code> and the inner loop
	~~count as gaps~~. The ~~normal SACK-mark loop processes <code>block[0]</code>~~		skips <code>k == snd_cr.lwe</code>; case-2 re-NULLs slots already marked
	~~idempotently regardless: the existing~~ clamp-and-skip path ~~makes~~		received by later blocks), so block[0] is harmless even when fed
	case-1 ~~a no~~-op (<code>start < snd_cr.lwe</code> clamps to <code>snd_cr.lwe</code>, the		to the loop.
	inner loop ~~then~~ skips <code>k == snd_cr.lwe</code>~~) and~~ case-2 a re-~~NULL of~~
	slots already marked received by later blocks.

	=== 1.4. RTTP payload ===		=== 1.4. RTTP payload ===

Dimitri: /* 1.3. SACK payload */

2026-05-17T15:17:17Z

1.3. SACK payload

← Older revision		Revision as of 15:17, 17 May 2026
Line 256:		Line 256:
	:<code>blocks[0]</code> is a sub-range of some <code>blocks[i>0]</code> (not exactly equal). Reports a duplicate of an in-window <code>seqno</code> that the same packet's remaining SACK blocks already describe as received.		:<code>blocks[0]</code> is a sub-range of some <code>blocks[i>0]</code> (not exactly equal). Reports a duplicate of an in-window <code>seqno</code> that the same packet's remaining SACK blocks already describe as received.

	~~Senders that do not implement D-SACK process~~ <code>block[0]</code> ~~through the~~		On receipt the sender feeds <code>block[0]</code> into the RACK
	~~normal SACK-mark loop and the existing clamp-and-skip path makes~~
	~~case-1 a no-op (<code>start < snd_cr.lwe</code> clamps to <code>snd_cr.lwe</code>, the inner~~
	~~loop then skips <code>k == snd_cr.lwe</code>) and case-2 idempotent (same slots~~
	~~NULL'd twice). D-SACK-aware senders feed the report~~ into the RACK
	<code>reo_wnd_mult</code> scaler (RFC 8985 sec. 6.2 step 4): bump on receipt		<code>reo_wnd_mult</code> scaler (RFC 8985 sec. 6.2 step 4): bump on receipt
	(cap 20), halve once per 16 cumulatively-ACK'd seqnos since the		(cap 20), halve once per 16 cumulatively-ACK'd seqnos since the
Line 266:		Line 262:
	timer fire at the head-of-line. D-SACK alone never enters		timer fire at the head-of-line. D-SACK alone never enters
	NewReno-careful recovery (see [[#8. Retransmission\|Section 8]]); only non-D-SACK blocks		NewReno-careful recovery (see [[#8. Retransmission\|Section 8]]); only non-D-SACK blocks
	count as gaps.		count as gaps. The normal SACK-mark loop processes <code>block[0]</code>
			idempotently regardless: the existing clamp-and-skip path makes
			case-1 a no-op (<code>start < snd_cr.lwe</code> clamps to <code>snd_cr.lwe</code>, the
			inner loop then skips <code>k == snd_cr.lwe</code>) and case-2 a re-NULL of
			slots already marked received by later blocks.

	=== 1.4. RTTP payload ===		=== 1.4. RTTP payload ===

Dimitri: /* 16.5. Security considerations */

2026-05-17T15:12:21Z

16.5. Security considerations

← Older revision		Revision as of 15:12, 17 May 2026
Line 1,173:		Line 1,173:
	DATA after the AEAD strips the wrap, because the AEAD authenticates the <code>seqno</code> and a replay re-presents an old <code>seqno</code> that is then discarded either as a duplicate (still inside the receive window or as outside the receive window, depending on how far <code>lwe</code> has advanced since the original packet was delivered. RAW (<code>qos.service == SVC_RAW</code>) flows have no FRCP layer and therefore no replay protection at the AEAD layer either; deployments that need replay rejection on RAW flows SHOULD use SVC_MESSAGE.		DATA after the AEAD strips the wrap, because the AEAD authenticates the <code>seqno</code> and a replay re-presents an old <code>seqno</code> that is then discarded either as a duplicate (still inside the receive window or as outside the receive window, depending on how far <code>lwe</code> has advanced since the original packet was delivered. RAW (<code>qos.service == SVC_RAW</code>) flows have no FRCP layer and therefore no replay protection at the AEAD layer either; deployments that need replay rejection on RAW flows SHOULD use SVC_MESSAGE.

	Layering. The AEAD wrap sits below FRCP on the data path, so RAW best-effort flows (<code>qos.service == SVC_RAW</code>, the UDP-equivalent service of [[#2.2. Service modes (orthogonal axes)\|Section 2.2]]) inherit the same per-flow integrity + confidentiality scope as FRCP-engaged flows - whatever the ~~IPCP~~ and FRCP (if any) put on the wire is what the AEAD authenticates. No DTLS-equivalent layering is required for confidentiality and integrity; replay protection above AEAD is a separate concern as noted above.		Layering. The AEAD wrap sits below FRCP on the data path, so RAW best-effort flows (<code>qos.service == SVC_RAW</code>, the UDP-equivalent service of [[#2.2. Service modes (orthogonal axes)\|Section 2.2]]) inherit the same per-flow integrity + confidentiality scope as FRCP-engaged flows - whatever the process and FRCP (if any) put on the wire is what the AEAD authenticates. No DTLS-equivalent layering is required for confidentiality and integrity; replay protection above AEAD is a separate concern as noted above.

	== 17. References ==		== 17. References ==

Dimitri: /* 16.5. Security considerations */

2026-05-17T15:11:27Z

16.5. Security considerations

@@ Line 1,168: / Line 1,168: @@
 * Comparable to IPsec ESP transport mode (RFC 4303), which similarly authenticates and encrypts the upper-layer header plus payload, and to QUIC packet protection (RFC 9001 sec. 5), with the difference that QUIC must leave the destination connection ID in the clear for routing whereas FRCP relies on the IPCP below for delivery and can therefore encrypt its entire PCI.
-Keying granularity.  FRCP runs key exchange (<code>kex</code>) per flow, so
+Keying granularity. Ouroboros flow allocation runs key exchange (<code>kex</code>) per flow, so each <code>flow_alloc</code> yields independent symmetric keys. This is finer-grained than QUIC (per-connection, RFC 9001, where one handshake covers all multiplexed streams) and finer-grained than typical IPsec deployment (per-host-pair Security Associations, SAs). Forward secrecy follows from the <code>kex</code> when an ephemeral Diffie-Hellman exchange (DHE), or a hybrid mode (classical DH + post-quantum Key Encapsulation Mechanism / KEM), is selected.
-Replay protection.  The AEAD layer itself does NOT carry an
+Replay protection. The AEAD layer itself does NOT carry an explicit anti-replay window (unlike IPsec ESP, RFC 4303 sec. 3.4.3, or DTLS, RFC 9147 sec. 4.5.1).  For FRCP-engaged flows the <code>seqno</code>-space duplicate-suppression in [[#6.2. Locked main path|Section 6.2]] rejects replayed
-explicit anti-replay window (unlike IPsec ESP, RFC 4303 sec.
+DATA after the AEAD strips the wrap, because the AEAD authenticates the <code>seqno</code> and a replay re-presents an old <code>seqno</code> that is then discarded either as a duplicate (still inside the receive window or as outside the receive window, depending on how far <code>lwe</code> has advanced since the original packet was delivered. RAW (<code>qos.service == SVC_RAW</code>) flows have no FRCP layer and therefore no replay protection at the AEAD layer either; deployments that need replay rejection on RAW flows SHOULD use SVC_MESSAGE.
 == 17. References ==

Dimitri: /* 15. Heritage and adopted techniques */

2026-05-17T14:59:41Z

15. Heritage and adopted techniques

← Older revision		Revision as of 14:59, 17 May 2026
Line 990:		Line 990:
	\| Karn's algorithm: no RTT sample on retransmits, RTO-collapse freeze \|\| TCP \|\| Karn & Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", SIGCOMM 1987; RFC 6298 sec. 3.		\| Karn's algorithm: no RTT sample on retransmits, RTO-collapse freeze \|\| TCP \|\| Karn & Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", SIGCOMM 1987; RFC 6298 sec. 3.
	\|-		\|-
	\| RTO formula <code>RTO = max(RTO_MIN, srtt + (mdev << MDEV_MUL))</code> \|\| TCP \|\| RFC 6298 (Paxson et al., 2011). <code>RTO_MIN</code> = ~~5 ms~~ is below RFC 6298 sec. 2.4's 1 s SHOULD-floor - a recursive-layer choice.		\| RTO formula <code>RTO = max(RTO_MIN, srtt + (mdev << MDEV_MUL))</code> \|\| TCP \|\| RFC 6298 (Paxson et al., 2011). <code>RTO_MIN</code> = 250 us is below RFC 6298 sec. 2.4's 1 s SHOULD-floor - a recursive-layer choice.
	\|-		\|-
	\| Linux asymmetric <code>mdev</code> estimator (default) \|\| Linux kernel \|\| <code>tcp_rtt_estimator()</code> in <code>net/ipv4/tcp_input.c</code>; the <code>if(delta<0) m>>=3</code> dampening is a kernel divergence from RFC 6298. RFC 6298 EWMA available behind a compile flag.		\| Linux asymmetric <code>mdev</code> estimator (default) \|\| Linux kernel \|\| <code>tcp_rtt_estimator()</code> in <code>net/ipv4/tcp_input.c</code>; the <code>if(delta<0) m>>=3</code> dampening is a kernel divergence from RFC 6298. RFC 6298 EWMA available behind a compile flag.
Line 1,045:		Line 1,045:
	* IP-style fragment-offset reassembly (RFC 791 sec. 3.2; RFC 8200 sec. 4.5). Message-mode FRCP relies on the FRCT <code>rq[]</code> reorder ring keyed by <code>seqno</code> (shared by FRTX and best-effort flows) to put fragments back in order; no separate offset field is needed and no IP-style hole-list reassembly buffer is kept. Stream-mode FRCP does carry <code>[start, end)</code> byte offsets ([[#1.5. Stream PCI extension\|Section 1.5]]) for direct ring placement on receive.		* IP-style fragment-offset reassembly (RFC 791 sec. 3.2; RFC 8200 sec. 4.5). Message-mode FRCP relies on the FRCT <code>rq[]</code> reorder ring keyed by <code>seqno</code> (shared by FRTX and best-effort flows) to put fragments back in order; no separate offset field is needed and no IP-style hole-list reassembly buffer is kept. Stream-mode FRCP does carry <code>[start, end)</code> byte offsets ([[#1.5. Stream PCI extension\|Section 1.5]]) for direct ring placement on receive.
	* QUIC STREAM offset+length framing on ''every'' flow (RFC 9000 sec. 19.8). Message-mode FRCP uses the SCTP-style B/E flag-bit encoding (<code>FFGM</code>/<code>LFGM</code>) and skips the offsets; stream-mode FRCP adopts the QUIC offset model (heritage table above).		* QUIC STREAM offset+length framing on ''every'' flow (RFC 9000 sec. 19.8). Message-mode FRCP uses the SCTP-style B/E flag-bit encoding (<code>FFGM</code>/<code>LFGM</code>) and skips the offsets; stream-mode FRCP adopts the QUIC offset model (heritage table above).


	== 16. Stream-mode flows ==		== 16. Stream-mode flows ==

Dimitri: /* 9. Pre-DRF NACK */

2026-05-17T14:47:17Z

9. Pre-DRF NACK

← Older revision		Revision as of 14:47, 17 May 2026
Line 787:		Line 787:
	== 9. Pre-DRF NACK ==		== 9. Pre-DRF NACK ==

	The two sides have different inactivity thresholds		The two sides have different inactivity thresholds (<code>snd_cr.inact > rcv_cr.inact</code>), so a receiver can detect "stale data run" before the sender's own DRF logic kicks in. NACK is the receiver-driven nudge that asks the sender to re-transmit the head of the run.
	(<code>snd_cr.inact > rcv_cr.inact</code>), so a receiver can detect "stale data
	run" before the sender's own DRF logic kicks in. NACK is the
	receiver-driven nudge that asks the sender to re-transmit the head
	of the run.

	;Send (<code>frcti_nack_snd</code>, called by <code>frcti_rcv</code> when <code>rcv_inact_check</code> returns <code>FRCT_INACT_NEED_NACK</code>)		;Send (<code>frcti_nack_snd</code>, called by <code>frcti_rcv</code> when <code>rcv_inact_check</code> returns <code>FRCT_INACT_NEED_NACK</code>)
Line 799:		Line 795:
	:Dispatched in the early-exit branch ([[#6.1. Early-exit dispatch\|Section 6.1]]), before <code>rcv_inact_check</code>. The sender copies the head-of-line (HoL) <code>rxm</code> packet, marks the slot <code>SND_RTX \| SND_FAST_RXM</code> (Karn-suppress next ACK, one-shot fast-rxm gate), sets <code>rtt_lwe = snd_cr.lwe + 1</code>, and re-emits via <code>fast_rxm_send</code> with <code>FRCT_RXM</code> and a refreshed <code>ackno</code>. The original <code>rxm_entry</code> and its RTO timer are left armed - the NACK emit is additive to the normal retransmit machinery, not a replacement. No-op if nothing is in flight, the HoL slot has aged past <code>t_r</code>, or the HoL <code>rxm</code> pointer has been cleared by SACK or RACK.		:Dispatched in the early-exit branch ([[#6.1. Early-exit dispatch\|Section 6.1]]), before <code>rcv_inact_check</code>. The sender copies the head-of-line (HoL) <code>rxm</code> packet, marks the slot <code>SND_RTX \| SND_FAST_RXM</code> (Karn-suppress next ACK, one-shot fast-rxm gate), sets <code>rtt_lwe = snd_cr.lwe + 1</code>, and re-emits via <code>fast_rxm_send</code> with <code>FRCT_RXM</code> and a refreshed <code>ackno</code>. The original <code>rxm_entry</code> and its RTO timer are left armed - the NACK emit is additive to the normal retransmit machinery, not a replacement. No-op if nothing is in flight, the HoL slot has aged past <code>t_r</code>, or the HoL <code>rxm</code> pointer has been cleared by SACK or RACK.

	NACK ~~serves two roles~~:		NACK has exactly one role: lost first-of-run (DRF) packet recovery. Until the DRF packet arrives, the receiver cannot rebase its window, so any subsequent in-flight packets look stale to the receiver. The NACK fires the moment a stale receiver sees DATA without DRF, telling the sender to re-emit the head-of-line (DRF) packet at NACK-cooldown latency rather than waiting for the initial RTO (which is the configured default until <code>srtt</code> is seeded by the first probe round-trip). Mid-stream loss is NOT NACK-driven; it is recovered by the sender's RTO, fast retransmit, and SACK-driven retransmit paths ([[#8. Retransmission\|Section 8]]) only.

	~~# Lost~~ first-of-run (DRF) packet recovery. ~~Required.~~ Until the DRF packet arrives, the receiver cannot rebase its window, so any subsequent in-flight packets look stale to the receiver. The NACK fires the moment ~~the second packet arrives at~~ a stale receiver, telling the sender to re-emit the ~~HoL~~ (DRF) packet at NACK-cooldown latency rather than waiting for the initial RTO (which is the configured default until <code>srtt</code> is seeded by the first probe round-trip).
	~~# General loss~~-~~recovery accelerator. When~~ loss is ~~detected receiver~~-~~first, the NACK skips one RTO of latency relative to waiting for~~ the sender's RTO ~~to fire~~.

	~~In both cases the existing <code>rxm_entry</code> and its RTO timer are left~~
	~~armed, so the RTO path remains the eventual fallback~~.

			The existing <code>rxm_entry</code> and its RTO timer are left armed on a NACK re-emit, so the RTO path remains the eventual fallback.

	== 10. Cumulative + selective ACK ==		== 10. Cumulative + selective ACK ==