Ouroboros - User contributions [en]

Congestion avoidance

2026-07-12T09:13:06Z

Dimitri: Blanked the page

Congestion avoidance

2026-07-11T22:23:01Z

Dimitri:

{{DISPLAYTITLE:mb-ecn - Multi-bit ECN Congestion Avoidance}}

mb-ecn is a congestion-avoidance (CA) policy for the Ouroboros unicast
IPCP. Reliability, ordering and flow control are FRCP's job, end-to-end
and per flow; congestion avoidance is a separate concern, and it runs
in the IPCP, once per layer. Within a layer the IPCP controls
'''aggregates''': one control loop per (destination address, QoS cube),
shared by every flow to that destination.

This document is about the algorithm: what it does and why. The
code follows it; the [[#References|reference section]] maps the pieces
to source files. It doesn't oversell: the [[#Limitations|limitations]]
section says plainly what it can't do.

"MUST", "SHOULD", "MAY" and friends mean what BCP 14 (RFC 2119,
RFC 8174) says, but only where they appear in capitals.

Note: Co-authered by Anthropic Claude Fable 5.

== Notation ==

{| class="wikitable"
! Symbol !! Units !! Meaning
|-
| <code>r</code> || B/s || Paced send rate
|-
| <code>C</code> || B/s || Bottleneck capacity
|-
| <code>S</code> || bytes || Packet size
|-
| <code>q</code> || packets || Standing queue occupancy at the bottleneck
|-
| <code>Q</code> || packets || Marking quantum: packets per mark unit (4)
|-
| <code>ecn</code> || 8-bit code || Per-packet congestion mark set by a forwarder
|-
| <code>ece</code> || 1/32 <code>ecn</code> || Receiver-side congestion estimate: 32 × time-mean <code>ecn</code>
|-
| <code>cap8</code> || 8-bit code || Path capacity, quarter-log2: <code>C ≈ 2^(cap8 / 4)</code> B/s, 0 = unknown
|-
| <code>W</code> || ns || Receiver averaging window
|-
| <code>a</code> || B/s^2 || Additive-increase slope
|-
| <code>M</code> || <code>ece</code> units || Full-congestion reference level (512)
|-
| <code>Δt</code> || ns || Elapsed wall-clock time between two events
|-
| <code>τ</code> || n/a || Path round-trip time (feedback delay); the controller does not measure it
|}

Rate is the control variable throughout.

Every concrete figure in this document (window bounds, horizons,
rate thresholds) is just an instance of the parameter values in the
[[#Parameters|parameters table]]. What the algorithm fixes is the
mechanisms and the relations between parameters; retune the parameters
and the figures move together.

__TOC__

== Overview ==

mb-ecn is a rate-based, ECN-driven controller with three moving parts,
one at each point of the loop:

<pre>
sender forwarder
+--------------------------------+ +--------------------------+
| SFQ virtual-clock pacer | | ecn = MAX(ecn, queue/Q) |
| rate r, paced per packet | data | (deepest queue wins) |
| AIMD + PD control on r |------>| cap8 = MIN(cap8, link) |
+--------------------------------+ +--------------------------+
^ |
| ece + cap8 feedback | marked data
| v
+--------------------------------+ +--------------------------+
| reads downstream ece, |<------| receiver |
| updates the rate on feedback, | ece | time-mean of ecn over |
| scales floor/slope to cap8 | cap8 | an adaptive window |
+--------------------------------+ +--------------------------+
</pre>

# The '''forwarder''' marks each packet with a ''multi-bit'' magnitude proportional to its standing queue, and MIN-stamps its measured outgoing-link capacity into the same PCI.
# The '''receiver''' turns the stream of marks into a time-averaged congestion estimate <code>ece</code> and feeds it back to the sender, together with the window minimum of the path-capacity codes.
# The '''sender''' paces its rate with a start-time fair-queuing (SFQ) virtual clock, and adjusts that rate with additive-increase / multiplicative-decrease (AIMD) driven by <code>ece</code>; the rate floor and the additive slope derive from the fed-back path capacity.

There's no timer thread: the controller runs when a packet goes out or
feedback comes back. Every step is scaled by elapsed wall-clock time,
and that is what makes the ''allocation'' independent of RTT (see
[[#RTT behaviour|RTT behaviour]]).

The unit of control is the '''aggregate''': one per
<code>(destination address, QoS cube)</code>, shared by every flow to
that destination at that QoS. They share one controller and one rate.
A new flow joins at whatever rate the aggregate is already running; when
a flow leaves, its share goes to the others. The pacer (SFQ) splits
that rate fairly across the member flows, so per-flow fairness is the
scheduler's doing, not the rate law's.

== Forwarder marking ==

A forwarder marks a packet based on how many packets are already queued
on the outgoing link:

mark = queued / Q (Q = 4 packets)
ecn = MAX(ecn, mark) (saturating, 8-bit field)

<code>Q</code> is fixed for the whole layer, not tuned per hop: the marks
get MAX-combined across hops, so every forwarder MUST use the same
quantum or the numbers don't compare.

Two things worth noting:

* '''It's a magnitude, not a bit.''' The mark is an integer that tracks queue depth, in steps of <code>Q</code> packets: a coarse read of the standing queue.
* '''MAX along the path.''' Cross several forwarders and the packet carries the largest mark, i.e. the deepest queue it passed. Taking the MAX (not a sum) keeps the number bounded and monotone across hops.

There's a '''dead zone''': below <code>Q</code> queued packets the mark is 0.

=== Capacity stamping ===

Each forwarder also measures its outgoing link's capacity and stamps it
into the packet. The measurement is a busy-period drain rate: look at
the queue at most once a millisecond, and keep a window open until 16
packets have drained. So the window '''sizes itself to the link''':
the once-a-millisecond cadence caps it on fast links, the 16-packet
drain time on slow ones (~19 ms at 10 Mbit/s). If more than 1/8 of the
arrivals hit an empty queue, throw the window out: the link
wasn't saturated. The odd empty sample (a token-bucket shaper grazing
zero) is fine. A saturated queue drains at the link rate, so a max
filter that decays slowly (1/16 per window) creeps up to it from below.
A window that started or ended on an empty queue might have drained
into buffers downstream faster than the wire, so it may pull the
estimate down but never up. On the wire the code is quarter-log2
(<code>cap8 = 4 log2 C</code>, ~19% a step, 0 = unknown), and each hop
MIN-combines its own into the byte, so the packet arrives carrying the
slowest hop's rate. A hop that has never backed up stamps nothing,
which is fine, since only backed-up hops matter.

== Receiver estimate ==

The receiver turns the marks into a smoothed estimate <code>ece</code>,
averaged over a window <code>W</code> that '''tracks the incoming byte rate'''.
It's a plain time-average over that window (a box-car, not an EWMA).
Per packet, with <code>Δt</code> the gap since the last one:

A += ecn * MIN(Δt, W) dwell-weighted; one packet
weighs at most one window
B += S accumulate bytes this window
...
at window close (elapsed >= W, or B >= 2 * B_target with at
least the window floor elapsed):
ece = 32 * A / elapsed mean over the actual window
W += (B_target * elapsed / B - W) / 4 nudge toward the size
that holds the target
W = clamp(W, ~1.05 ms, ~4.3 s)
A = 0 ; B = 0 hard reset

When a window closes, the next one is nudged (a quarter-weight
moving average) toward the size that would hold about 16 packets
at the current byte rate, starting from ~67 ms. The target is in bytes
(<code>B_target</code> = 16,000), so "16 packets" is only exact at
~1000-byte packets, and it takes a few closes to settle. The mean
always divides by the window that '''actually''' elapsed, so a change
in rate leaves the current estimate correct and only resizes the
''next'' one. Net effect: a roughly constant ~16 samples a window from
about 30 kbit/s to 122 Mbit/s. Above that the window bottoms out at
~1 ms (still thousands of samples a window at 10–100 GbE); below
~30 kbit/s it hits the ~4.3 s ceiling. The averaging clock stretches
with the flow, the way TCP's ACK clock stretches with the RTT. A
sudden speed-up doesn't wait out a stretched window: once twice the
target bytes have arrived it closes anyway (the ~1 ms floor keeps that
from running away at high rate). So the <code>ece</code> the sender sees
is a staircase: one step per window, steps getting shorter as
the rate climbs. Two edge cases:

* '''Onset.''' The first mark after an idle stretch is passed through as-is, so a queue that's just starting to build shows up without waiting out a whole window.
* '''Gap.''' A silence longer than 4 windows resets and sends the raw sample. "Long" is '''measured in the flow's own windows''', so a slow flow's normal spacing never reads as idle; and the dwell clamp above limits what a real pause can add to the mean before the reset fires.

Alongside the marks, the receiver keeps the smallest non-zero capacity
code it saw this window and ships it with each <code>ece</code> (on an
onset/gap restart, just the current packet's code). Then it resets, so
if the path reroutes onto something faster the fed-back capacity can
climb within one window.

The estimate rides back to the sender on the reverse flow.

== Sender pacer ==

The sender paces off an SFQ virtual clock. The aggregate keeps a
virtual time <code>V</code>; each flow keeps a finish tag <code>F</code>:

V += r * Δt virtual time advances by bytes served
s = MAX(F, V) a packet behind the clock starts now
F = s + S the one after it queues behind
wait = (s - V) / r time until this packet may go

That <code>wait</code> is the flow's scheduling deadline. A packet
that's behind the virtual clock goes out now (<code>wait = 0</code>);
one that's ahead waits, and only that flow waits, nobody else.
Across an idle gap longer than 50 ms the clock credits at most the
flow's own owed lead plus one burst (50 ms of service, at least one
packet). So a flow paced slower than a packet per 50 ms still gets its
'''real''' elapsed service (capping the credit by time would
starve it) while an idle flow still can't bank an unbounded
burst.

<code>V</code> is shared by every flow in the aggregate; the finish
tags are not. Since every flow measures its start tag <code>s</code>
against the same <code>V</code>, a flow that just sent is now ahead of
<code>V</code> and has to wait, while an idle one (tag at or behind
<code>V</code>) goes right away. That is what splits the aggregate rate
<code>r</code> fairly among them.

== Rate control (AIMD + PD) ==

The rate law runs on packet sends, at most once a millisecond, and
also when feedback arrives, so a sender with no traffic of its
own still reacts. The increase terms and the proportional decrease are
each scaled by elapsed time, but not by the same clock: the increases
use banked time '''capped''' at 50 ms (an idle gap shouldn't buy an
unbounded ramp), while the decrease uses the '''uncapped''' elapsed
time (a starved sender still cuts by the right amount). The one-sided
derivative (see the
[[#Multiplicative decrease (proportional + derivative)|decrease]]) is
not scaled by time at all; it is per-step.

=== Slow start ===

Before the first congestion signal, the rate ramps up exponentially
with a 20 ms time constant:

r += r * Δt / T_ss (T_ss = 20 ms)

Slow start ends the first time a congestion signal shows up, whether
fed back from the receiver or seen at the sender's own first hop, and
it never comes back.

Slow start belongs to the aggregate, so it happens
'''once per (destination, QoS cube)''', on the first flow. A flow that
shows up later, at an aggregate that's already running, rides the
existing
estimate: it starts at the current rate and takes its share through
the [[#Sender pacer|pacer]], without probing of its own.

=== Increase: additive plus proportional probe (always on) ===

Past slow start, two increase terms run every step, congested or not:

r += a * Δt additive; a defaults to 2^16 B/s^2
r += r * Δt / T_probe proportional; T_probe = 8 s

The additive term is a fixed slope (bytes/s per second), sized to the
path capacity (see
[[#Capacity-derived floor and slope|the capacity floor]]). The
proportional probe adds a fixed fraction of the rate per unit time (it
e-folds over <code>T_probe</code>): that is what lets a flow recover in
the same number of steps whatever the link rate; a fixed additive step
is negligible next to a fast link. Together they are the
upward pressure the multiplicative decrease balances at equilibrium.
The probe is not free: it costs a standing queue that does not shrink
with rate (see [[#Fairness|fairness]]).

=== Multiplicative decrease (proportional + derivative) ===

With congestion level <code>m</code> (the fed-back <code>ece</code>, or
the local first-hop mark if there's no feedback yet), the cut is a
proportional term plus a one-sided derivative term, a PD controller on
the congestion signal:

mark = MIN(m, M) M = 512
rise = MAX(m - m_prev, 0), capped at M one-sided derivative

cut = r * rise / (4 * M) derivative, gain 1/4
cut += r * mark * Δt_ms / (1000 * M) proportional
cut = MIN(cut, r / 2) at most a halving

r -= cut
m_prev = m

* The '''proportional''' term uses the real elapsed milliseconds, so a starved sender that hasn't run the controller in a while still cuts by the right amount.
* The '''derivative''' term (<code>rise</code>) only fires when the congestion level ''goes up'' between samples: one-sided, per-step. It sharpens the response right as congestion starts.
* The cut is capped at <code>r/2</code>, so one step can at most halve the rate.

<code>M = 512 = 32 × 16</code> pins "full congestion" at a mean
<code>ecn</code> of 16, i.e. a mean queue of <code>16 × Q = 64</code>
packets.

=== Staleness ===

Feedback comes once per receiver window, and that window stretches with
the flow's byte rate (see
[[#Receiver estimate|the receiver estimate]]), so the staleness horizon
has to stretch with it too, or a slow flow's mark would expire
''between'' feedbacks and the rate would ramp straight into a congested
path. The sender mirrors the receiver: the horizon is four target
windows' worth of bytes at the current rate, floored at ~268 ms so fast
flows keep a fixed one; at the default rate floor it's ~8 s. Once a
signal is older than that it's dropped (both the fed-back estimate and
the local mark), which frees the rate to climb again after congestion
clears. Every step clamps the rate to <code>[r_min, r_max]</code>.

=== Capacity-derived floor and slope ===

The fed-back capacity code sets the controller's two rate-scale
constants, per aggregate:

target = decode(cap8) / 32 clamped to [2^13, 2^32] B/s
r_min += (target - r_min) / 2 per feedback (moving average)
a = r_min

On a path that never reports a capacity, both fall back to fixed
defaults (<code>r_min = 2^13 B/s</code>, <code>a = 2^16 B/s^2</code>).
When the estimator is live, the fairness floor and the post-cut
recovery slope scale with the bottleneck instead, and capacity kicks in
wherever <code>C/32</code> beats the default floor, roughly above
2 Mbit/s. A capacity older than 16 staleness horizons (~4.3 s for fast
flows) reverts both to the defaults. That horizon is deliberately
longer than the feedback horizon: feedback stops the instant the marks
clear, which is exactly when you need the recovery slope, and the
onset-fresh capacity (see
[[#Receiver estimate|the receiver estimate]]) re-seeds it on the first
mark of the next episode anyway.

=== Ramp and recovery ===

Three mechanisms set how fast an aggregate reaches a fast link's
rate, each owning one regime:

* '''From scratch: slow start.''' The exponential ramp hits any real link rate in well under a second (~200 ms from the seed to 10 Gbit/s; every further doubling of link speed adds one ~14 ms doubling). Nothing marks on an uncongested path, so slow start just runs until the aggregate reaches its bottleneck.
* '''After a cut: the probe.''' A cut is at most a halving, and the mark expires on the rate-relative horizon once congestion clears (see [[#Staleness|staleness]]); the probe then climbs back from a halving in <code>T_probe · ln 2 ≈ 5.5 s</code>, whatever the link rate.
* '''At the bottom: the capacity floor.''' The rate never sits more than 32× below a measured bottleneck, and the additive slope refills <code>C/32</code> a second, so the worst hole is bounded: floor to full capacity in tens of seconds, a halving in seconds.

These fit together because a deep cut needs sustained congestion,
sustained congestion backs up the bottleneck queue, and a backed-up
queue is exactly when its capacity gets measured and stamped (see
[[#Forwarder marking|forwarder marking]]). So whenever the controller
has been cut deep, the scaled floor is already live. The default floor
only ever applies to paths that never congested the sender in the first
place, where there's nothing to recover from. That's why slow start can
quit for good: the floor and the probe handle every recovery after it.

=== Regimes ===

<pre>
+-------------+ first mark seen +----------------+
| slow start |--------------------->| congestion |
| r *= e^(t/T)| | avoidance |
+-------------+ | |
| m == 0 ---> additive increase
| m > 0 ---> AI + PD decrease
+----------------+
m = fed-back ece, or the local first-hop mark when ece == 0
</pre>

== RTT behaviour ==

Because every increase and decrease is scaled by wall-clock time, two
flows with different RTTs sharing a bottleneck follow the ''same'' rate
law and settle at the ''same'' rate. So the steady-state
'''allocation is RTT-independent'''.

That is a property of the equilibrium, not the dynamics. The feedback
delay in the loop ''is'' the path RTT <code>τ</code>, and the
controller neither measures nor compensates for it. At low rate the
receiver window (up to its ~4.3 s ceiling) is the biggest lag: the loop
is slow there in proportion to how slow the flow is, just like a
long-RTT TCP. As the rate climbs the window shrinks toward its ~1 ms
floor, so its share of the loop delay ''falls'' with capacity and the
path RTT <code>τ</code> becomes the irreducible part. Two things keep
the loop damped: the adaptive window takes out the delay-dominated
corner at low <code>τ</code>, and a bucketed
'''rate-velocity damping''' (the washout: each ~31 ms bucket pulls the
rate a quarter of the way back toward its value at the previous bucket)
supplies the damping this otherwise near-double-integrator loop lacks,
which is what holds it together at high capacity and moderate
<code>τ</code>. What is left is the loop gain
<code>√G &prop; √C</code>: at very high capacity ''and''
large <code>τ</code> the <code>√G · τ</code> phase
budget is the binding constraint, and no amount of windowing or damping
removes it (see [[#Limitations|Limitations]]). So, precisely:
'''RTT-fair in equilibrium, and dynamically stable up to a'''
'''capacity-dependent RTT limit set by <code>√G · τ</code>.'''

== Fairness ==

At equilibrium the two increase terms balance the proportional
decrease, <code>a + r/T_probe = r · m*/M</code>, which pins the
congestion level at <code>m* = M · (a/r + 1/T_probe)</code>. Since
<code>ece = 8q</code> (one mark unit per <code>Q = 4</code> packets, 32
fixed-point steps per unit), that is a standing queue of

q* = 64 * a / r + 64 / T_probe (packets, r in bytes/s)

The additive part (<code>64 · a / r</code>) fades to nothing with
rate under the default slope; with the capacity-derived slope
(<code>a = C/32</code>; see
[[#Capacity-derived floor and slope|the capacity floor]]) it settles at
<code>2 C / r</code>, about two packets per competing flow, whatever the
rate. The probe part (<code>64 / T_probe</code>) is a floor that does
not move with rate (~8 packets at 8 s). That floor is what
rate-independent convergence costs you, and it is what keeps
<code>q*</code> above the marking threshold at high rate.

Two flows at the same bottleneck see the same <code>m*</code>, so each
solves <code>r_i = a / (m*/M - 1/T_probe)</code> to the same rate. In
network-utility-maximization terms that is '''proportional fairness'''
with equal weights, which at a single bottleneck is just max-min fair.

Getting a good measurement at low rate is the estimator's job, not the
floor's: the averaging window stretches with the flow (see
[[#Receiver estimate|the receiver estimate]]), so a CA-limited flow
still keeps ~16 packets a window down to ~30 kbit/s, and the
rate-relative gap threshold keeps its normal spacing from reading as
idle. The default floor (<code>2^13 B/s</code>) only bounds the extremes
(window ceiling, staleness horizon, pacer arithmetic). The floor itself
scales with the fed-back path capacity (<code>r_min = C/32</code>; see
[[#Capacity-derived floor and slope|the capacity floor]]), so about 32
CA-limited flows fit above it on any class of link. Flows whose
bottlenecks are in different classes get different slopes, so fairness
between them is capacity-weighted, not equal; see
[[#Limitations|Limitations]].

== Limitations ==

Things the algorithm '''doesn't''' do. Listed here so nobody credits it
with more than it manages.

* '''Queue-only signal, no rate term.''' <code>M</code> is a queue level, so mb-ecn is a standing-queue controller: it has to build a queue (<code>q* = 64 · a / r + 64 / T_probe</code>) to get any signal at all, and can't sit at full utilisation on an empty queue the way a controller with a rate estimate can. The probe floor (~8 packets) keeps <code>q*</code> above the marking threshold at every rate, but you pay for it with a permanent standing queue.
* '''Aggregation is per destination, per QoS cube.''' The aggregate is a stand-in for the path: flows to the same destination are assumed to share a bottleneck, and flows to different destinations run separate loops even when they pile up at the same hop. Each loop still converges to its own fair share (see [[#Fairness|fairness]]), so the cost is duplicated state and probing at that shared queue, not unfairness. One day we could tag the queue in the packet: if a forwarder stamped a queue id next to its mark, senders could key their aggregates on the real bottleneck instead of the destination, and pool the estimate and the probing across everything sharing it.
* '''Capacity is learned, and there are gaps.''' The floor and slope ride on an in-band path-capacity estimate (see [[#Forwarder marking|forwarder marking]] and [[#Capacity-derived floor and slope|the capacity floor]]), and that estimate has its own limits. A hop only learns its rate while its queue is backed up, so a rerouted or brand-new bottleneck reads ''unknown'' at first and the path MIN can briefly come from faster hops (the sender's smoothing and the next feedback bound the overshoot). The measurement is order-of-magnitude on purpose: quarter-log2 code (~19% a step), burst noise held down by a 16-packet minimum window and a max filter, and nothing learned below ~120 packets a second of busy drain (16 packets inside the ~134 ms staleness cap; at MTU that's ~1.4 Mbit/s, below which capacity/32 sits under the default floor anyway). The derived floor clamps to <code>[2^13, 2^32]</code> B/s, and flows with bottlenecks in different classes get capacity-weighted, not equal, shares at a common queue (see [[#Fairness|fairness]]).
* '''The low end trades speed, not correctness.''' Below ~30 kbit/s the averaging window hits its ~4.3 s ceiling and holds fewer samples; below ~64 kbit/s of offered load an ''app-limited'' flow spaces its packets past the gap threshold and rides the raw onset branch, as it always did. At the floor, feedback and the staleness horizon are both measured in seconds, so a slow flow converges slowly, TCP-style. Nothing blows up; nothing's quick either.
* '''No loss response.''' The controller only reacts to ECN marks. Loss is FRCP's problem, handled by retransmission, out of the CA's sight. At a bottleneck that drops instead of marking (say a plain drop-tail queue at the Ethernet or UDP shim), mb-ecn sees nothing and additive increase just keeps ramping. It's built for Ouroboros-native bottlenecks where the forwarder marks; there's no classic-bottleneck fallback.
* '''Dynamic stability has a capacity-dependent RTT limit.''' As covered under [[#RTT behaviour|RTT behaviour]], the allocation is RTT-independent but the dynamics aren't: the binding constraint is <code>√G · τ</code> with <code>√G &prop; √C</code>. The adaptive window and the washout push that limit out a long way (a single flow at 10 GbE stays stable to ~50 ms RTT in the fluid model), but the far corner (100 GbE at ≥ 50 ms) is out of reach for a window/damping controller and would need explicit-rate signalling.

== Architectural fit ==

Each of these properties falls out of something structural in the
recursive architecture. Here's the mapping.

* '''CA is fully separate from ARQ and flow control.''' Three concerns, three mechanisms, two scopes: FRCP does retransmission (ARQ) and flow control (the peer pacing the sender), end-to-end and per flow; CA runs in the IPCP, per aggregate. Each signal says one thing. A loss just means retransmit: a lossy link reads as lossy, and the congestion call is left to the marks (the [[#Limitations|limitations]] section's "no loss response" is this same separation from the other side). The peer's flow-control window just paces the endpoint: back-pressure from a slow receiver stays separate from congestion in the network. A retransmitted packet is ordinary traffic as far as the pacer cares. TCP jams all three into one window machine, where the receive window caps the congestion window and loss is both the reliability trigger and the congestion signal; here you can reason about, test, and change each one on its own.
* '''CA sits below what the application picks.''' Every flow in the layer runs under the same rate law, whatever its QoS: a greedy raw sender shares a bottleneck fairly with a reliable stream because the control belongs to the layer, on the aggregate, not to the endpoint transport's good manners.
* '''A layer owns its PCI, so the signal can be rich.''' Everyone in a layer enrolled into it, so the layer is one administrative domain by construction, at whatever scope it covers, and the header is the layer's own. That's why forwarders can write a multi-bit queue magnitude and a capacity byte straight into the packet. The datacenter schemes in [[#Heritage and positioning|heritage and positioning]] need exactly that kind of domain and only get it inside one operator's fabric; a recursive layer has it everywhere.
* '''Layer-internal addressing makes the aggregate well-defined.''' Flows in a layer run between layer addresses, so the (destination, QoS cube) aggregate, which is RFC 3124's macroflow, drops straight out of the naming. Controller state scales with the number of destinations, and each QoS cube keeps its own loop, so service classes don't share a fate.
* '''Flows are allocated, so feedback already has a channel.''' Every flow has state at both ends and a reverse direction, so the receiver's <code>ece</code> and the path capacity just ride the flow allocator's existing exchange.
* '''There's no transport ack clock, and nothing leans on one.''' The layer has to handle raw flows, which carry no acknowledgements at all, so the controller paces on wall-clock time, and that constraint is exactly what buys the RTT-independent allocation under [[#RTT behaviour|RTT behaviour]]. A restriction turned into the feature.
* '''Recursion scales it.''' Each layer handles congestion over its own scope and timescale; many N-flows ride one N-1 flow, so aggregation compounds down the stack. The capacity a layer sees at its egress queue is whatever the layer below is actually giving it (a paced, shared lower flow, not some nominal wire speed), so the signal means something at every level and back-pressure cascades down layer by layer.

There's a boundary: at a shim over legacy media the layer below neither
enrolls nor marks, which is the deployment edge behind the
[[#Limitations|limitations]] section's no-loss-response point.

== Heritage and positioning ==

mb-ecn is basically a rate-based ECN controller in the DECbit / QCN
line, adapted to a recursive layer with no acknowledgements.

The core goes back to the first Ouroboros CA policy (2020): a multi-bit
queue-depth mark relayed by forwarders to the receiver, a smoothed
multi-bit <code>ece</code> fed back on the reverse flow at the same 1/32
fixed point used today, and a sender that paced packets from a time
budget and ran slow start, additive increase and multiplicative
decrease on wall-clock time slots. Rate-based and acknowledgement-free
from the start, with RTT-independent allocation already the goal. The
present algorithm keeps that skeleton and reworks every estimator
around it: per-path aggregation with SFQ pacing, the rate-adaptive
box-car receiver, elapsed-time-scaled AIMD with a derivative term and
rate-velocity damping, and the in-band capacity signal.

* '''DECbit''' (Ramakrishnan & Jain, 1988; ToCS 1990) established binary congestion feedback set by the switch on queue occupancy. mb-ecn keeps the switch-sets-on-queue idea and carries a ''magnitude''.
* '''The Congestion Manager''' (Balakrishnan et al., SIGCOMM 1999; RFC 3124, 2001) aggregates congestion state at the end host: one controller per macroflow, a scheduler apportioning its rate across the member streams, and new streams joining at the ensemble's current state instead of probing from scratch. mb-ecn's (destination, QoS cube) aggregate is the same idea placed inside the IPCP: every layer manages its own macroflows, recursively, the SFQ pacer plays the CM scheduler's role (see [[#Sender pacer|the pacer]]), and a joining flow rides the aggregate's estimates (see [[#Slow start|slow start]]). The CM gathers its signal from transport feedback at the edge; mb-ecn reads it off the wire from the forwarders.
* '''DCTCP''' (Alizadeh et al., SIGCOMM 2010) recovers a queue magnitude at the endpoint by averaging a single threshold bit. mb-ecn instead reads the magnitude off the wire, then time-averages it at the receiver. The additive-increase / proportional-decrease structure is shared.
* '''QCN''' (IEEE 802.1Qau, 2010) and '''DCQCN''' (Zhu et al., SIGCOMM 2015) contribute the rate-based (not window-based) ECN control skeleton. mb-ecn's proportional decrease plus a probing increase mirrors that skeleton; the increase here is wall-clock scaled rather than byte-counter/timer based.
* '''HPCC''' (Li et al., SIGCOMM 2019) and '''PowerTCP''' (Addanki et al., NSDI 2022) combine a queue term ''and'' a rate term (via in-band telemetry or delay). mb-ecn now carries a coarse in-band rate (the quarter-log2 path MIN; see [[#Forwarder marking|forwarder marking]]) but uses it only to scale the controller's gains; the congestion ''signal'' remains queue-only, which is still the main functional difference (see [[#Limitations|Limitations]]).
* '''L4S / TCP Prague''' (RFC 9330–9332, 2023) make RTT-independence a requirement and use a high-frequency single-bit signal. mb-ecn shares the RTT-independent ''allocation'' goal but reaches it by wall-clock-scaled rate control, with a low-frequency multi-bit signal.

What's new is the pairing: a multi-bit magnitude on the wire with a
wall-clock-scaled rate pacer, in a setting with no per-flow ack clock.
The trade-off, spelled out above, is a queue-only signal and a
reactivity capped by the averaging window.

== Parameters ==

These are the values behind every figure in this document. They're
'''coupled''': the mechanisms only fit together while a few relations
hold. The gap-restart horizon at the rate floor has to exceed a
packet's service time (or a floor-rate flow loops at onset); a
floor-rate flow's target window has to fit under the window ceiling;
the control interval has to sit under the damping bucket, which sits
under the idle credit cap; the rate floor mustn't exceed the slow-start
seed; and the derived-floor ceiling has to stay under the rate ceiling.
Retune them as a set, against those constraints.

{| class="wikitable"
! Parameter !! Value !! Meaning
|-
| Marking quantum <code>Q</code> || 4 packets || Mark onset and step; layer-wide
|-
| Feedback resolution || 1/32 <code>ecn</code> unit || Fixed-point LSB of <code>ece</code>
|-
| Full-congestion reference <code>M</code> || 512 || Mean queue of 64 packets
|-
| Receiver window target || 16 packets (16,000 bytes) || Samples per window
|-
| Initial receiver window || ~67 ms || Before rate is known
|-
| Receiver window bounds || ~1.05 ms – ~4.3 s || Clamp on <code>W</code>
|-
| Window resize weight || 1/4 || Moving average toward target
|-
| Early window close || 2 × target bytes || Speed-up escape
|-
| Gap restart || 4 windows || Idle horizon (rate-relative)
|-
| Additive slope <code>a</code> (default) || 2^16 B/s^2 || Lower clamp of derived slope
|-
| Probe time constant <code>T_probe</code> || 8 s || Rate-proportional recovery
|-
| Derivative gain || 1/4 || Onset sharpening
|-
| Rate floor <code>r_min</code> (default) || 2^13 B/s || Lower clamp of derived floor
|-
| Slow-start seed rate || 2^16 B/s || Initial rate
|-
| Slow-start time constant || 20 ms || Exponential ramp
|-
| Rate ceiling <code>r_max</code> || 2^37 B/s || Upper clamp
|-
| Capacity scale || <code>C</code> / 32 || Floor and slope from bottleneck
|-
| Capacity smoothing || 1/2 || Moving average per feedback
|-
| Capacity staleness || 16 × feedback horizon || Revert to defaults
|-
| Derived floor ceiling || 2^32 B/s || Upper clamp on derived floor
|-
| Control interval || 1 ms || Minimum spacing of rate updates
|-
| Idle credit cap || 50 ms || Burst allowance / increase banking
|-
| Feedback staleness floor || ~268 ms || Floor of rate-relative horizon
|-
| Damping bucket || ~31 ms || Rate-velocity washout cadence
|-
| Damping fraction || 1/4 || Pullback per bucket
|-
| Estimator fold spacing || 1 ms || Minimum measurement cadence
|-
| Estimator window closure || 16 packets drained || Self-scaling window
|-
| Estimator window staleness || ~134 ms || Discard across traffic gaps
|-
| Estimator idle tolerance || 1/8 of arrivals || Unsaturated-window rejection
|-
| Estimator decay || 1/16 per window || Max-filter convergence from below
|}

== References ==

=== Source ===

The implementation follows the algorithm above:

* <code>src/ipcpd/unicast/ca/mb-ecn.c</code>, <code>mb-ecn.h</code>: receiver estimator, pacer and rate control.
* <code>src/ipcpd/unicast/ca/ops.h</code>: CA policy interface.
* <code>src/ipcpd/unicast/cap.c</code>, <code>cap.h</code>: link-capacity estimator and quarter-log2 codec.
* <code>src/ipcpd/unicast/dt.c</code>, <code>fa.c</code>: per-hop marking and stamping, and the feedback carrying <code>ece</code> + <code>cap8</code>.
* <code>src/ipcpd/unicast/psched.c</code>: consumes the pacing deadline.

=== Literature ===

* K. K. Ramakrishnan, R. Jain, "A Binary Feedback Scheme for Congestion Avoidance in Computer Networks" (DECbit), ACM ToCS, 1990.
* H. Balakrishnan, H. S. Rahul, S. Seshan, "An Integrated Congestion Management Architecture for Internet Hosts", SIGCOMM 1999; H. Balakrishnan, S. Seshan, "The Congestion Manager", RFC 3124, 2001.
* M. Alizadeh et al., "Data Center TCP (DCTCP)", SIGCOMM 2010.
* Y. Zhu et al., "Congestion Control for Large-Scale RDMA Deployments" (DCQCN), SIGCOMM 2015.
* R. Mittal et al., "TIMELY: RTT-based Congestion Control", SIGCOMM 2015.
* Y. Li et al., "HPCC: High Precision Congestion Control", SIGCOMM 2019.
* V. Addanki et al., "PowerTCP", NSDI 2022.
* K. De Schepper, B. Briscoe (eds.), "Low Latency, Low Loss, and Scalable Throughput (L4S)", RFC 9330/9331/9332.
* F. Kelly, "Charging and Rate Control for Elastic Traffic", 1997; R. Srikant, "The Mathematics of Internet Congestion Control", 2004.

Congestion avoidance

2026-07-11T22:22:48Z

Dimitri:

{{DISPLAYTITLE:mb-ecn - Multi-bit ECN Congestion Avoidance}}

mb-ecn is a congestion-avoidance (CA) policy for the Ouroboros unicast
IPCP. Reliability, ordering and flow control are FRCP's job, end-to-end
and per flow; congestion avoidance is a separate concern, and it runs
in the IPCP, once per layer. Within a layer the IPCP controls
'''aggregates''': one control loop per (destination address, QoS cube),
shared by every flow to that destination.

This document is about the algorithm: what it does and why. The
code follows it; the [[#References|reference section]] maps the pieces
to source files. It doesn't oversell: the [[#Limitations|limitations]]
section says plainly what it can't do.

"MUST", "SHOULD", "MAY" and friends mean what BCP 14 (RFC 2119,
RFC 8174) says, but only where they appear in capitals.

Note: Co-authered by Claude Fable 5.

== Notation ==

{| class="wikitable"
! Symbol !! Units !! Meaning
|-
| <code>r</code> || B/s || Paced send rate
|-
| <code>C</code> || B/s || Bottleneck capacity
|-
| <code>S</code> || bytes || Packet size
|-
| <code>q</code> || packets || Standing queue occupancy at the bottleneck
|-
| <code>Q</code> || packets || Marking quantum: packets per mark unit (4)
|-
| <code>ecn</code> || 8-bit code || Per-packet congestion mark set by a forwarder
|-
| <code>ece</code> || 1/32 <code>ecn</code> || Receiver-side congestion estimate: 32 × time-mean <code>ecn</code>
|-
| <code>cap8</code> || 8-bit code || Path capacity, quarter-log2: <code>C ≈ 2^(cap8 / 4)</code> B/s, 0 = unknown
|-
| <code>W</code> || ns || Receiver averaging window
|-
| <code>a</code> || B/s^2 || Additive-increase slope
|-
| <code>M</code> || <code>ece</code> units || Full-congestion reference level (512)
|-
| <code>Δt</code> || ns || Elapsed wall-clock time between two events
|-
| <code>τ</code> || n/a || Path round-trip time (feedback delay); the controller does not measure it
|}

Rate is the control variable throughout.

Every concrete figure in this document (window bounds, horizons,
rate thresholds) is just an instance of the parameter values in the
[[#Parameters|parameters table]]. What the algorithm fixes is the
mechanisms and the relations between parameters; retune the parameters
and the figures move together.

__TOC__

== Overview ==

mb-ecn is a rate-based, ECN-driven controller with three moving parts,
one at each point of the loop:

<pre>
sender forwarder
+--------------------------------+ +--------------------------+
| SFQ virtual-clock pacer | | ecn = MAX(ecn, queue/Q) |
| rate r, paced per packet | data | (deepest queue wins) |
| AIMD + PD control on r |------>| cap8 = MIN(cap8, link) |
+--------------------------------+ +--------------------------+
^ |
| ece + cap8 feedback | marked data
| v
+--------------------------------+ +--------------------------+
| reads downstream ece, |<------| receiver |
| updates the rate on feedback, | ece | time-mean of ecn over |
| scales floor/slope to cap8 | cap8 | an adaptive window |
+--------------------------------+ +--------------------------+
</pre>

# The '''forwarder''' marks each packet with a ''multi-bit'' magnitude proportional to its standing queue, and MIN-stamps its measured outgoing-link capacity into the same PCI.
# The '''receiver''' turns the stream of marks into a time-averaged congestion estimate <code>ece</code> and feeds it back to the sender, together with the window minimum of the path-capacity codes.
# The '''sender''' paces its rate with a start-time fair-queuing (SFQ) virtual clock, and adjusts that rate with additive-increase / multiplicative-decrease (AIMD) driven by <code>ece</code>; the rate floor and the additive slope derive from the fed-back path capacity.

There's no timer thread: the controller runs when a packet goes out or
feedback comes back. Every step is scaled by elapsed wall-clock time,
and that is what makes the ''allocation'' independent of RTT (see
[[#RTT behaviour|RTT behaviour]]).

The unit of control is the '''aggregate''': one per
<code>(destination address, QoS cube)</code>, shared by every flow to
that destination at that QoS. They share one controller and one rate.
A new flow joins at whatever rate the aggregate is already running; when
a flow leaves, its share goes to the others. The pacer (SFQ) splits
that rate fairly across the member flows, so per-flow fairness is the
scheduler's doing, not the rate law's.

== Forwarder marking ==

A forwarder marks a packet based on how many packets are already queued
on the outgoing link:

mark = queued / Q (Q = 4 packets)
ecn = MAX(ecn, mark) (saturating, 8-bit field)

<code>Q</code> is fixed for the whole layer, not tuned per hop: the marks
get MAX-combined across hops, so every forwarder MUST use the same
quantum or the numbers don't compare.

Two things worth noting:

* '''It's a magnitude, not a bit.''' The mark is an integer that tracks queue depth, in steps of <code>Q</code> packets: a coarse read of the standing queue.
* '''MAX along the path.''' Cross several forwarders and the packet carries the largest mark, i.e. the deepest queue it passed. Taking the MAX (not a sum) keeps the number bounded and monotone across hops.

There's a '''dead zone''': below <code>Q</code> queued packets the mark is 0.

=== Capacity stamping ===

Each forwarder also measures its outgoing link's capacity and stamps it
into the packet. The measurement is a busy-period drain rate: look at
the queue at most once a millisecond, and keep a window open until 16
packets have drained. So the window '''sizes itself to the link''':
the once-a-millisecond cadence caps it on fast links, the 16-packet
drain time on slow ones (~19 ms at 10 Mbit/s). If more than 1/8 of the
arrivals hit an empty queue, throw the window out: the link
wasn't saturated. The odd empty sample (a token-bucket shaper grazing
zero) is fine. A saturated queue drains at the link rate, so a max
filter that decays slowly (1/16 per window) creeps up to it from below.
A window that started or ended on an empty queue might have drained
into buffers downstream faster than the wire, so it may pull the
estimate down but never up. On the wire the code is quarter-log2
(<code>cap8 = 4 log2 C</code>, ~19% a step, 0 = unknown), and each hop
MIN-combines its own into the byte, so the packet arrives carrying the
slowest hop's rate. A hop that has never backed up stamps nothing,
which is fine, since only backed-up hops matter.

== Receiver estimate ==

The receiver turns the marks into a smoothed estimate <code>ece</code>,
averaged over a window <code>W</code> that '''tracks the incoming byte rate'''.
It's a plain time-average over that window (a box-car, not an EWMA).
Per packet, with <code>Δt</code> the gap since the last one:

A += ecn * MIN(Δt, W) dwell-weighted; one packet
weighs at most one window
B += S accumulate bytes this window
...
at window close (elapsed >= W, or B >= 2 * B_target with at
least the window floor elapsed):
ece = 32 * A / elapsed mean over the actual window
W += (B_target * elapsed / B - W) / 4 nudge toward the size
that holds the target
W = clamp(W, ~1.05 ms, ~4.3 s)
A = 0 ; B = 0 hard reset

When a window closes, the next one is nudged (a quarter-weight
moving average) toward the size that would hold about 16 packets
at the current byte rate, starting from ~67 ms. The target is in bytes
(<code>B_target</code> = 16,000), so "16 packets" is only exact at
~1000-byte packets, and it takes a few closes to settle. The mean
always divides by the window that '''actually''' elapsed, so a change
in rate leaves the current estimate correct and only resizes the
''next'' one. Net effect: a roughly constant ~16 samples a window from
about 30 kbit/s to 122 Mbit/s. Above that the window bottoms out at
~1 ms (still thousands of samples a window at 10–100 GbE); below
~30 kbit/s it hits the ~4.3 s ceiling. The averaging clock stretches
with the flow, the way TCP's ACK clock stretches with the RTT. A
sudden speed-up doesn't wait out a stretched window: once twice the
target bytes have arrived it closes anyway (the ~1 ms floor keeps that
from running away at high rate). So the <code>ece</code> the sender sees
is a staircase: one step per window, steps getting shorter as
the rate climbs. Two edge cases:

* '''Onset.''' The first mark after an idle stretch is passed through as-is, so a queue that's just starting to build shows up without waiting out a whole window.
* '''Gap.''' A silence longer than 4 windows resets and sends the raw sample. "Long" is '''measured in the flow's own windows''', so a slow flow's normal spacing never reads as idle; and the dwell clamp above limits what a real pause can add to the mean before the reset fires.

Alongside the marks, the receiver keeps the smallest non-zero capacity
code it saw this window and ships it with each <code>ece</code> (on an
onset/gap restart, just the current packet's code). Then it resets, so
if the path reroutes onto something faster the fed-back capacity can
climb within one window.

The estimate rides back to the sender on the reverse flow.

== Sender pacer ==

The sender paces off an SFQ virtual clock. The aggregate keeps a
virtual time <code>V</code>; each flow keeps a finish tag <code>F</code>:

V += r * Δt virtual time advances by bytes served
s = MAX(F, V) a packet behind the clock starts now
F = s + S the one after it queues behind
wait = (s - V) / r time until this packet may go

That <code>wait</code> is the flow's scheduling deadline. A packet
that's behind the virtual clock goes out now (<code>wait = 0</code>);
one that's ahead waits, and only that flow waits, nobody else.
Across an idle gap longer than 50 ms the clock credits at most the
flow's own owed lead plus one burst (50 ms of service, at least one
packet). So a flow paced slower than a packet per 50 ms still gets its
'''real''' elapsed service (capping the credit by time would
starve it) while an idle flow still can't bank an unbounded
burst.

<code>V</code> is shared by every flow in the aggregate; the finish
tags are not. Since every flow measures its start tag <code>s</code>
against the same <code>V</code>, a flow that just sent is now ahead of
<code>V</code> and has to wait, while an idle one (tag at or behind
<code>V</code>) goes right away. That is what splits the aggregate rate
<code>r</code> fairly among them.

== Rate control (AIMD + PD) ==

The rate law runs on packet sends, at most once a millisecond, and
also when feedback arrives, so a sender with no traffic of its
own still reacts. The increase terms and the proportional decrease are
each scaled by elapsed time, but not by the same clock: the increases
use banked time '''capped''' at 50 ms (an idle gap shouldn't buy an
unbounded ramp), while the decrease uses the '''uncapped''' elapsed
time (a starved sender still cuts by the right amount). The one-sided
derivative (see the
[[#Multiplicative decrease (proportional + derivative)|decrease]]) is
not scaled by time at all; it is per-step.

=== Slow start ===

Before the first congestion signal, the rate ramps up exponentially
with a 20 ms time constant:

r += r * Δt / T_ss (T_ss = 20 ms)

Slow start ends the first time a congestion signal shows up, whether
fed back from the receiver or seen at the sender's own first hop, and
it never comes back.

Slow start belongs to the aggregate, so it happens
'''once per (destination, QoS cube)''', on the first flow. A flow that
shows up later, at an aggregate that's already running, rides the
existing
estimate: it starts at the current rate and takes its share through
the [[#Sender pacer|pacer]], without probing of its own.

=== Increase: additive plus proportional probe (always on) ===

Past slow start, two increase terms run every step, congested or not:

r += a * Δt additive; a defaults to 2^16 B/s^2
r += r * Δt / T_probe proportional; T_probe = 8 s

The additive term is a fixed slope (bytes/s per second), sized to the
path capacity (see
[[#Capacity-derived floor and slope|the capacity floor]]). The
proportional probe adds a fixed fraction of the rate per unit time (it
e-folds over <code>T_probe</code>): that is what lets a flow recover in
the same number of steps whatever the link rate; a fixed additive step
is negligible next to a fast link. Together they are the
upward pressure the multiplicative decrease balances at equilibrium.
The probe is not free: it costs a standing queue that does not shrink
with rate (see [[#Fairness|fairness]]).

=== Multiplicative decrease (proportional + derivative) ===

With congestion level <code>m</code> (the fed-back <code>ece</code>, or
the local first-hop mark if there's no feedback yet), the cut is a
proportional term plus a one-sided derivative term, a PD controller on
the congestion signal:

mark = MIN(m, M) M = 512
rise = MAX(m - m_prev, 0), capped at M one-sided derivative

cut = r * rise / (4 * M) derivative, gain 1/4
cut += r * mark * Δt_ms / (1000 * M) proportional
cut = MIN(cut, r / 2) at most a halving

r -= cut
m_prev = m

* The '''proportional''' term uses the real elapsed milliseconds, so a starved sender that hasn't run the controller in a while still cuts by the right amount.
* The '''derivative''' term (<code>rise</code>) only fires when the congestion level ''goes up'' between samples: one-sided, per-step. It sharpens the response right as congestion starts.
* The cut is capped at <code>r/2</code>, so one step can at most halve the rate.

<code>M = 512 = 32 × 16</code> pins "full congestion" at a mean
<code>ecn</code> of 16, i.e. a mean queue of <code>16 × Q = 64</code>
packets.

=== Staleness ===

Feedback comes once per receiver window, and that window stretches with
the flow's byte rate (see
[[#Receiver estimate|the receiver estimate]]), so the staleness horizon
has to stretch with it too, or a slow flow's mark would expire
''between'' feedbacks and the rate would ramp straight into a congested
path. The sender mirrors the receiver: the horizon is four target
windows' worth of bytes at the current rate, floored at ~268 ms so fast
flows keep a fixed one; at the default rate floor it's ~8 s. Once a
signal is older than that it's dropped (both the fed-back estimate and
the local mark), which frees the rate to climb again after congestion
clears. Every step clamps the rate to <code>[r_min, r_max]</code>.

=== Capacity-derived floor and slope ===

The fed-back capacity code sets the controller's two rate-scale
constants, per aggregate:

target = decode(cap8) / 32 clamped to [2^13, 2^32] B/s
r_min += (target - r_min) / 2 per feedback (moving average)
a = r_min

On a path that never reports a capacity, both fall back to fixed
defaults (<code>r_min = 2^13 B/s</code>, <code>a = 2^16 B/s^2</code>).
When the estimator is live, the fairness floor and the post-cut
recovery slope scale with the bottleneck instead, and capacity kicks in
wherever <code>C/32</code> beats the default floor, roughly above
2 Mbit/s. A capacity older than 16 staleness horizons (~4.3 s for fast
flows) reverts both to the defaults. That horizon is deliberately
longer than the feedback horizon: feedback stops the instant the marks
clear, which is exactly when you need the recovery slope, and the
onset-fresh capacity (see
[[#Receiver estimate|the receiver estimate]]) re-seeds it on the first
mark of the next episode anyway.

=== Ramp and recovery ===

Three mechanisms set how fast an aggregate reaches a fast link's
rate, each owning one regime:

* '''From scratch: slow start.''' The exponential ramp hits any real link rate in well under a second (~200 ms from the seed to 10 Gbit/s; every further doubling of link speed adds one ~14 ms doubling). Nothing marks on an uncongested path, so slow start just runs until the aggregate reaches its bottleneck.
* '''After a cut: the probe.''' A cut is at most a halving, and the mark expires on the rate-relative horizon once congestion clears (see [[#Staleness|staleness]]); the probe then climbs back from a halving in <code>T_probe · ln 2 ≈ 5.5 s</code>, whatever the link rate.
* '''At the bottom: the capacity floor.''' The rate never sits more than 32× below a measured bottleneck, and the additive slope refills <code>C/32</code> a second, so the worst hole is bounded: floor to full capacity in tens of seconds, a halving in seconds.

These fit together because a deep cut needs sustained congestion,
sustained congestion backs up the bottleneck queue, and a backed-up
queue is exactly when its capacity gets measured and stamped (see
[[#Forwarder marking|forwarder marking]]). So whenever the controller
has been cut deep, the scaled floor is already live. The default floor
only ever applies to paths that never congested the sender in the first
place, where there's nothing to recover from. That's why slow start can
quit for good: the floor and the probe handle every recovery after it.

=== Regimes ===

<pre>
+-------------+ first mark seen +----------------+
| slow start |--------------------->| congestion |
| r *= e^(t/T)| | avoidance |
+-------------+ | |
| m == 0 ---> additive increase
| m > 0 ---> AI + PD decrease
+----------------+
m = fed-back ece, or the local first-hop mark when ece == 0
</pre>

== RTT behaviour ==

Because every increase and decrease is scaled by wall-clock time, two
flows with different RTTs sharing a bottleneck follow the ''same'' rate
law and settle at the ''same'' rate. So the steady-state
'''allocation is RTT-independent'''.

That is a property of the equilibrium, not the dynamics. The feedback
delay in the loop ''is'' the path RTT <code>τ</code>, and the
controller neither measures nor compensates for it. At low rate the
receiver window (up to its ~4.3 s ceiling) is the biggest lag: the loop
is slow there in proportion to how slow the flow is, just like a
long-RTT TCP. As the rate climbs the window shrinks toward its ~1 ms
floor, so its share of the loop delay ''falls'' with capacity and the
path RTT <code>τ</code> becomes the irreducible part. Two things keep
the loop damped: the adaptive window takes out the delay-dominated
corner at low <code>τ</code>, and a bucketed
'''rate-velocity damping''' (the washout: each ~31 ms bucket pulls the
rate a quarter of the way back toward its value at the previous bucket)
supplies the damping this otherwise near-double-integrator loop lacks,
which is what holds it together at high capacity and moderate
<code>τ</code>. What is left is the loop gain
<code>√G &prop; √C</code>: at very high capacity ''and''
large <code>τ</code> the <code>√G · τ</code> phase
budget is the binding constraint, and no amount of windowing or damping
removes it (see [[#Limitations|Limitations]]). So, precisely:
'''RTT-fair in equilibrium, and dynamically stable up to a'''
'''capacity-dependent RTT limit set by <code>√G · τ</code>.'''

== Fairness ==

At equilibrium the two increase terms balance the proportional
decrease, <code>a + r/T_probe = r · m*/M</code>, which pins the
congestion level at <code>m* = M · (a/r + 1/T_probe)</code>. Since
<code>ece = 8q</code> (one mark unit per <code>Q = 4</code> packets, 32
fixed-point steps per unit), that is a standing queue of

q* = 64 * a / r + 64 / T_probe (packets, r in bytes/s)

The additive part (<code>64 · a / r</code>) fades to nothing with
rate under the default slope; with the capacity-derived slope
(<code>a = C/32</code>; see
[[#Capacity-derived floor and slope|the capacity floor]]) it settles at
<code>2 C / r</code>, about two packets per competing flow, whatever the
rate. The probe part (<code>64 / T_probe</code>) is a floor that does
not move with rate (~8 packets at 8 s). That floor is what
rate-independent convergence costs you, and it is what keeps
<code>q*</code> above the marking threshold at high rate.

Two flows at the same bottleneck see the same <code>m*</code>, so each
solves <code>r_i = a / (m*/M - 1/T_probe)</code> to the same rate. In
network-utility-maximization terms that is '''proportional fairness'''
with equal weights, which at a single bottleneck is just max-min fair.

Getting a good measurement at low rate is the estimator's job, not the
floor's: the averaging window stretches with the flow (see
[[#Receiver estimate|the receiver estimate]]), so a CA-limited flow
still keeps ~16 packets a window down to ~30 kbit/s, and the
rate-relative gap threshold keeps its normal spacing from reading as
idle. The default floor (<code>2^13 B/s</code>) only bounds the extremes
(window ceiling, staleness horizon, pacer arithmetic). The floor itself
scales with the fed-back path capacity (<code>r_min = C/32</code>; see
[[#Capacity-derived floor and slope|the capacity floor]]), so about 32
CA-limited flows fit above it on any class of link. Flows whose
bottlenecks are in different classes get different slopes, so fairness
between them is capacity-weighted, not equal; see
[[#Limitations|Limitations]].

== Limitations ==

Things the algorithm '''doesn't''' do. Listed here so nobody credits it
with more than it manages.

* '''Queue-only signal, no rate term.''' <code>M</code> is a queue level, so mb-ecn is a standing-queue controller: it has to build a queue (<code>q* = 64 · a / r + 64 / T_probe</code>) to get any signal at all, and can't sit at full utilisation on an empty queue the way a controller with a rate estimate can. The probe floor (~8 packets) keeps <code>q*</code> above the marking threshold at every rate, but you pay for it with a permanent standing queue.
* '''Aggregation is per destination, per QoS cube.''' The aggregate is a stand-in for the path: flows to the same destination are assumed to share a bottleneck, and flows to different destinations run separate loops even when they pile up at the same hop. Each loop still converges to its own fair share (see [[#Fairness|fairness]]), so the cost is duplicated state and probing at that shared queue, not unfairness. One day we could tag the queue in the packet: if a forwarder stamped a queue id next to its mark, senders could key their aggregates on the real bottleneck instead of the destination, and pool the estimate and the probing across everything sharing it.
* '''Capacity is learned, and there are gaps.''' The floor and slope ride on an in-band path-capacity estimate (see [[#Forwarder marking|forwarder marking]] and [[#Capacity-derived floor and slope|the capacity floor]]), and that estimate has its own limits. A hop only learns its rate while its queue is backed up, so a rerouted or brand-new bottleneck reads ''unknown'' at first and the path MIN can briefly come from faster hops (the sender's smoothing and the next feedback bound the overshoot). The measurement is order-of-magnitude on purpose: quarter-log2 code (~19% a step), burst noise held down by a 16-packet minimum window and a max filter, and nothing learned below ~120 packets a second of busy drain (16 packets inside the ~134 ms staleness cap; at MTU that's ~1.4 Mbit/s, below which capacity/32 sits under the default floor anyway). The derived floor clamps to <code>[2^13, 2^32]</code> B/s, and flows with bottlenecks in different classes get capacity-weighted, not equal, shares at a common queue (see [[#Fairness|fairness]]).
* '''The low end trades speed, not correctness.''' Below ~30 kbit/s the averaging window hits its ~4.3 s ceiling and holds fewer samples; below ~64 kbit/s of offered load an ''app-limited'' flow spaces its packets past the gap threshold and rides the raw onset branch, as it always did. At the floor, feedback and the staleness horizon are both measured in seconds, so a slow flow converges slowly, TCP-style. Nothing blows up; nothing's quick either.
* '''No loss response.''' The controller only reacts to ECN marks. Loss is FRCP's problem, handled by retransmission, out of the CA's sight. At a bottleneck that drops instead of marking (say a plain drop-tail queue at the Ethernet or UDP shim), mb-ecn sees nothing and additive increase just keeps ramping. It's built for Ouroboros-native bottlenecks where the forwarder marks; there's no classic-bottleneck fallback.
* '''Dynamic stability has a capacity-dependent RTT limit.''' As covered under [[#RTT behaviour|RTT behaviour]], the allocation is RTT-independent but the dynamics aren't: the binding constraint is <code>√G · τ</code> with <code>√G &prop; √C</code>. The adaptive window and the washout push that limit out a long way (a single flow at 10 GbE stays stable to ~50 ms RTT in the fluid model), but the far corner (100 GbE at ≥ 50 ms) is out of reach for a window/damping controller and would need explicit-rate signalling.

== Architectural fit ==

Each of these properties falls out of something structural in the
recursive architecture. Here's the mapping.

* '''CA is fully separate from ARQ and flow control.''' Three concerns, three mechanisms, two scopes: FRCP does retransmission (ARQ) and flow control (the peer pacing the sender), end-to-end and per flow; CA runs in the IPCP, per aggregate. Each signal says one thing. A loss just means retransmit: a lossy link reads as lossy, and the congestion call is left to the marks (the [[#Limitations|limitations]] section's "no loss response" is this same separation from the other side). The peer's flow-control window just paces the endpoint: back-pressure from a slow receiver stays separate from congestion in the network. A retransmitted packet is ordinary traffic as far as the pacer cares. TCP jams all three into one window machine, where the receive window caps the congestion window and loss is both the reliability trigger and the congestion signal; here you can reason about, test, and change each one on its own.
* '''CA sits below what the application picks.''' Every flow in the layer runs under the same rate law, whatever its QoS: a greedy raw sender shares a bottleneck fairly with a reliable stream because the control belongs to the layer, on the aggregate, not to the endpoint transport's good manners.
* '''A layer owns its PCI, so the signal can be rich.''' Everyone in a layer enrolled into it, so the layer is one administrative domain by construction, at whatever scope it covers, and the header is the layer's own. That's why forwarders can write a multi-bit queue magnitude and a capacity byte straight into the packet. The datacenter schemes in [[#Heritage and positioning|heritage and positioning]] need exactly that kind of domain and only get it inside one operator's fabric; a recursive layer has it everywhere.
* '''Layer-internal addressing makes the aggregate well-defined.''' Flows in a layer run between layer addresses, so the (destination, QoS cube) aggregate, which is RFC 3124's macroflow, drops straight out of the naming. Controller state scales with the number of destinations, and each QoS cube keeps its own loop, so service classes don't share a fate.
* '''Flows are allocated, so feedback already has a channel.''' Every flow has state at both ends and a reverse direction, so the receiver's <code>ece</code> and the path capacity just ride the flow allocator's existing exchange.
* '''There's no transport ack clock, and nothing leans on one.''' The layer has to handle raw flows, which carry no acknowledgements at all, so the controller paces on wall-clock time, and that constraint is exactly what buys the RTT-independent allocation under [[#RTT behaviour|RTT behaviour]]. A restriction turned into the feature.
* '''Recursion scales it.''' Each layer handles congestion over its own scope and timescale; many N-flows ride one N-1 flow, so aggregation compounds down the stack. The capacity a layer sees at its egress queue is whatever the layer below is actually giving it (a paced, shared lower flow, not some nominal wire speed), so the signal means something at every level and back-pressure cascades down layer by layer.

There's a boundary: at a shim over legacy media the layer below neither
enrolls nor marks, which is the deployment edge behind the
[[#Limitations|limitations]] section's no-loss-response point.

== Heritage and positioning ==

mb-ecn is basically a rate-based ECN controller in the DECbit / QCN
line, adapted to a recursive layer with no acknowledgements.

The core goes back to the first Ouroboros CA policy (2020): a multi-bit
queue-depth mark relayed by forwarders to the receiver, a smoothed
multi-bit <code>ece</code> fed back on the reverse flow at the same 1/32
fixed point used today, and a sender that paced packets from a time
budget and ran slow start, additive increase and multiplicative
decrease on wall-clock time slots. Rate-based and acknowledgement-free
from the start, with RTT-independent allocation already the goal. The
present algorithm keeps that skeleton and reworks every estimator
around it: per-path aggregation with SFQ pacing, the rate-adaptive
box-car receiver, elapsed-time-scaled AIMD with a derivative term and
rate-velocity damping, and the in-band capacity signal.

* '''DECbit''' (Ramakrishnan & Jain, 1988; ToCS 1990) established binary congestion feedback set by the switch on queue occupancy. mb-ecn keeps the switch-sets-on-queue idea and carries a ''magnitude''.
* '''The Congestion Manager''' (Balakrishnan et al., SIGCOMM 1999; RFC 3124, 2001) aggregates congestion state at the end host: one controller per macroflow, a scheduler apportioning its rate across the member streams, and new streams joining at the ensemble's current state instead of probing from scratch. mb-ecn's (destination, QoS cube) aggregate is the same idea placed inside the IPCP: every layer manages its own macroflows, recursively, the SFQ pacer plays the CM scheduler's role (see [[#Sender pacer|the pacer]]), and a joining flow rides the aggregate's estimates (see [[#Slow start|slow start]]). The CM gathers its signal from transport feedback at the edge; mb-ecn reads it off the wire from the forwarders.
* '''DCTCP''' (Alizadeh et al., SIGCOMM 2010) recovers a queue magnitude at the endpoint by averaging a single threshold bit. mb-ecn instead reads the magnitude off the wire, then time-averages it at the receiver. The additive-increase / proportional-decrease structure is shared.
* '''QCN''' (IEEE 802.1Qau, 2010) and '''DCQCN''' (Zhu et al., SIGCOMM 2015) contribute the rate-based (not window-based) ECN control skeleton. mb-ecn's proportional decrease plus a probing increase mirrors that skeleton; the increase here is wall-clock scaled rather than byte-counter/timer based.
* '''HPCC''' (Li et al., SIGCOMM 2019) and '''PowerTCP''' (Addanki et al., NSDI 2022) combine a queue term ''and'' a rate term (via in-band telemetry or delay). mb-ecn now carries a coarse in-band rate (the quarter-log2 path MIN; see [[#Forwarder marking|forwarder marking]]) but uses it only to scale the controller's gains; the congestion ''signal'' remains queue-only, which is still the main functional difference (see [[#Limitations|Limitations]]).
* '''L4S / TCP Prague''' (RFC 9330–9332, 2023) make RTT-independence a requirement and use a high-frequency single-bit signal. mb-ecn shares the RTT-independent ''allocation'' goal but reaches it by wall-clock-scaled rate control, with a low-frequency multi-bit signal.

What's new is the pairing: a multi-bit magnitude on the wire with a
wall-clock-scaled rate pacer, in a setting with no per-flow ack clock.
The trade-off, spelled out above, is a queue-only signal and a
reactivity capped by the averaging window.

== Parameters ==

These are the values behind every figure in this document. They're
'''coupled''': the mechanisms only fit together while a few relations
hold. The gap-restart horizon at the rate floor has to exceed a
packet's service time (or a floor-rate flow loops at onset); a
floor-rate flow's target window has to fit under the window ceiling;
the control interval has to sit under the damping bucket, which sits
under the idle credit cap; the rate floor mustn't exceed the slow-start
seed; and the derived-floor ceiling has to stay under the rate ceiling.
Retune them as a set, against those constraints.

{| class="wikitable"
! Parameter !! Value !! Meaning
|-
| Marking quantum <code>Q</code> || 4 packets || Mark onset and step; layer-wide
|-
| Feedback resolution || 1/32 <code>ecn</code> unit || Fixed-point LSB of <code>ece</code>
|-
| Full-congestion reference <code>M</code> || 512 || Mean queue of 64 packets
|-
| Receiver window target || 16 packets (16,000 bytes) || Samples per window
|-
| Initial receiver window || ~67 ms || Before rate is known
|-
| Receiver window bounds || ~1.05 ms – ~4.3 s || Clamp on <code>W</code>
|-
| Window resize weight || 1/4 || Moving average toward target
|-
| Early window close || 2 × target bytes || Speed-up escape
|-
| Gap restart || 4 windows || Idle horizon (rate-relative)
|-
| Additive slope <code>a</code> (default) || 2^16 B/s^2 || Lower clamp of derived slope
|-
| Probe time constant <code>T_probe</code> || 8 s || Rate-proportional recovery
|-
| Derivative gain || 1/4 || Onset sharpening
|-
| Rate floor <code>r_min</code> (default) || 2^13 B/s || Lower clamp of derived floor
|-
| Slow-start seed rate || 2^16 B/s || Initial rate
|-
| Slow-start time constant || 20 ms || Exponential ramp
|-
| Rate ceiling <code>r_max</code> || 2^37 B/s || Upper clamp
|-
| Capacity scale || <code>C</code> / 32 || Floor and slope from bottleneck
|-
| Capacity smoothing || 1/2 || Moving average per feedback
|-
| Capacity staleness || 16 × feedback horizon || Revert to defaults
|-
| Derived floor ceiling || 2^32 B/s || Upper clamp on derived floor
|-
| Control interval || 1 ms || Minimum spacing of rate updates
|-
| Idle credit cap || 50 ms || Burst allowance / increase banking
|-
| Feedback staleness floor || ~268 ms || Floor of rate-relative horizon
|-
| Damping bucket || ~31 ms || Rate-velocity washout cadence
|-
| Damping fraction || 1/4 || Pullback per bucket
|-
| Estimator fold spacing || 1 ms || Minimum measurement cadence
|-
| Estimator window closure || 16 packets drained || Self-scaling window
|-
| Estimator window staleness || ~134 ms || Discard across traffic gaps
|-
| Estimator idle tolerance || 1/8 of arrivals || Unsaturated-window rejection
|-
| Estimator decay || 1/16 per window || Max-filter convergence from below
|}

== References ==

=== Source ===

The implementation follows the algorithm above:

* <code>src/ipcpd/unicast/ca/mb-ecn.c</code>, <code>mb-ecn.h</code>: receiver estimator, pacer and rate control.
* <code>src/ipcpd/unicast/ca/ops.h</code>: CA policy interface.
* <code>src/ipcpd/unicast/cap.c</code>, <code>cap.h</code>: link-capacity estimator and quarter-log2 codec.
* <code>src/ipcpd/unicast/dt.c</code>, <code>fa.c</code>: per-hop marking and stamping, and the feedback carrying <code>ece</code> + <code>cap8</code>.
* <code>src/ipcpd/unicast/psched.c</code>: consumes the pacing deadline.

=== Literature ===

* K. K. Ramakrishnan, R. Jain, "A Binary Feedback Scheme for Congestion Avoidance in Computer Networks" (DECbit), ACM ToCS, 1990.
* H. Balakrishnan, H. S. Rahul, S. Seshan, "An Integrated Congestion Management Architecture for Internet Hosts", SIGCOMM 1999; H. Balakrishnan, S. Seshan, "The Congestion Manager", RFC 3124, 2001.
* M. Alizadeh et al., "Data Center TCP (DCTCP)", SIGCOMM 2010.
* Y. Zhu et al., "Congestion Control for Large-Scale RDMA Deployments" (DCQCN), SIGCOMM 2015.
* R. Mittal et al., "TIMELY: RTT-based Congestion Control", SIGCOMM 2015.
* Y. Li et al., "HPCC: High Precision Congestion Control", SIGCOMM 2019.
* V. Addanki et al., "PowerTCP", NSDI 2022.
* K. De Schepper, B. Briscoe (eds.), "Low Latency, Low Loss, and Scalable Throughput (L4S)", RFC 9330/9331/9332.
* F. Kelly, "Charging and Rate Control for Elastic Traffic", 1997; R. Srikant, "The Mathematics of Internet Congestion Control", 2004.

Congestion avoidance

2026-07-11T22:14:31Z

Dimitri:

{{DISPLAYTITLE:mb-ecn - Multi-bit ECN Congestion Avoidance}}

mb-ecn is a congestion-avoidance (CA) policy for the Ouroboros unicast
IPCP. Reliability, ordering and flow control are FRCP's job, end-to-end
and per flow; congestion avoidance is a separate concern, and it runs
in the IPCP, once per layer. Within a layer the IPCP controls
'''aggregates''': one control loop per (destination address, QoS cube),
shared by every flow to that destination.

This document is about the algorithm: what it does and why. The
code follows it; the [[#References|reference section]] maps the pieces
to source files. It doesn't oversell: the [[#Limitations|limitations]]
section says plainly what it can't do.

"MUST", "SHOULD", "MAY" and friends mean what BCP 14 (RFC 2119,
RFC 8174) says, but only where they appear in capitals.

== Notation ==

{| class="wikitable"
! Symbol !! Units !! Meaning
|-
| <code>r</code> || B/s || Paced send rate
|-
| <code>C</code> || B/s || Bottleneck capacity
|-
| <code>S</code> || bytes || Packet size
|-
| <code>q</code> || packets || Standing queue occupancy at the bottleneck
|-
| <code>Q</code> || packets || Marking quantum: packets per mark unit (4)
|-
| <code>ecn</code> || 8-bit code || Per-packet congestion mark set by a forwarder
|-
| <code>ece</code> || 1/32 <code>ecn</code> || Receiver-side congestion estimate: 32 × time-mean <code>ecn</code>
|-
| <code>cap8</code> || 8-bit code || Path capacity, quarter-log2: <code>C ≈ 2^(cap8 / 4)</code> B/s, 0 = unknown
|-
| <code>W</code> || ns || Receiver averaging window
|-
| <code>a</code> || B/s^2 || Additive-increase slope
|-
| <code>M</code> || <code>ece</code> units || Full-congestion reference level (512)
|-
| <code>Δt</code> || ns || Elapsed wall-clock time between two events
|-
| <code>τ</code> || n/a || Path round-trip time (feedback delay); the controller does not measure it
|}

Rate is the control variable throughout.

Every concrete figure in this document (window bounds, horizons,
rate thresholds) is just an instance of the parameter values in the
[[#Parameters|parameters table]]. What the algorithm fixes is the
mechanisms and the relations between parameters; retune the parameters
and the figures move together.

__TOC__

== Overview ==

mb-ecn is a rate-based, ECN-driven controller with three moving parts,
one at each point of the loop:

<pre>
sender forwarder
+--------------------------------+ +--------------------------+
| SFQ virtual-clock pacer | | ecn = MAX(ecn, queue/Q) |
| rate r, paced per packet | data | (deepest queue wins) |
| AIMD + PD control on r |------>| cap8 = MIN(cap8, link) |
+--------------------------------+ +--------------------------+
^ |
| ece + cap8 feedback | marked data
| v
+--------------------------------+ +--------------------------+
| reads downstream ece, |<------| receiver |
| updates the rate on feedback, | ece | time-mean of ecn over |
| scales floor/slope to cap8 | cap8 | an adaptive window |
+--------------------------------+ +--------------------------+
</pre>

# The '''forwarder''' marks each packet with a ''multi-bit'' magnitude proportional to its standing queue, and MIN-stamps its measured outgoing-link capacity into the same PCI.
# The '''receiver''' turns the stream of marks into a time-averaged congestion estimate <code>ece</code> and feeds it back to the sender, together with the window minimum of the path-capacity codes.
# The '''sender''' paces its rate with a start-time fair-queuing (SFQ) virtual clock, and adjusts that rate with additive-increase / multiplicative-decrease (AIMD) driven by <code>ece</code>; the rate floor and the additive slope derive from the fed-back path capacity.

There's no timer thread: the controller runs when a packet goes out or
feedback comes back. Every step is scaled by elapsed wall-clock time,
and that is what makes the ''allocation'' independent of RTT (see
[[#RTT behaviour|RTT behaviour]]).

The unit of control is the '''aggregate''': one per
<code>(destination address, QoS cube)</code>, shared by every flow to
that destination at that QoS. They share one controller and one rate.
A new flow joins at whatever rate the aggregate is already running; when
a flow leaves, its share goes to the others. The pacer (SFQ) splits
that rate fairly across the member flows, so per-flow fairness is the
scheduler's doing, not the rate law's.

== Forwarder marking ==

A forwarder marks a packet based on how many packets are already queued
on the outgoing link:

mark = queued / Q (Q = 4 packets)
ecn = MAX(ecn, mark) (saturating, 8-bit field)

<code>Q</code> is fixed for the whole layer, not tuned per hop: the marks
get MAX-combined across hops, so every forwarder MUST use the same
quantum or the numbers don't compare.

Two things worth noting:

* '''It's a magnitude, not a bit.''' The mark is an integer that tracks queue depth, in steps of <code>Q</code> packets: a coarse read of the standing queue.
* '''MAX along the path.''' Cross several forwarders and the packet carries the largest mark, i.e. the deepest queue it passed. Taking the MAX (not a sum) keeps the number bounded and monotone across hops.

There's a '''dead zone''': below <code>Q</code> queued packets the mark is 0.

=== Capacity stamping ===

Each forwarder also measures its outgoing link's capacity and stamps it
into the packet. The measurement is a busy-period drain rate: look at
the queue at most once a millisecond, and keep a window open until 16
packets have drained. So the window '''sizes itself to the link''':
the once-a-millisecond cadence caps it on fast links, the 16-packet
drain time on slow ones (~19 ms at 10 Mbit/s). If more than 1/8 of the
arrivals hit an empty queue, throw the window out: the link
wasn't saturated. The odd empty sample (a token-bucket shaper grazing
zero) is fine. A saturated queue drains at the link rate, so a max
filter that decays slowly (1/16 per window) creeps up to it from below.
A window that started or ended on an empty queue might have drained
into buffers downstream faster than the wire, so it may pull the
estimate down but never up. On the wire the code is quarter-log2
(<code>cap8 = 4 log2 C</code>, ~19% a step, 0 = unknown), and each hop
MIN-combines its own into the byte, so the packet arrives carrying the
slowest hop's rate. A hop that has never backed up stamps nothing,
which is fine, since only backed-up hops matter.

== Receiver estimate ==

The receiver turns the marks into a smoothed estimate <code>ece</code>,
averaged over a window <code>W</code> that '''tracks the incoming byte rate'''.
It's a plain time-average over that window (a box-car, not an EWMA).
Per packet, with <code>Δt</code> the gap since the last one:

A += ecn * MIN(Δt, W) dwell-weighted; one packet
weighs at most one window
B += S accumulate bytes this window
...
at window close (elapsed >= W, or B >= 2 * B_target with at
least the window floor elapsed):
ece = 32 * A / elapsed mean over the actual window
W += (B_target * elapsed / B - W) / 4 nudge toward the size
that holds the target
W = clamp(W, ~1.05 ms, ~4.3 s)
A = 0 ; B = 0 hard reset

When a window closes, the next one is nudged (a quarter-weight
moving average) toward the size that would hold about 16 packets
at the current byte rate, starting from ~67 ms. The target is in bytes
(<code>B_target</code> = 16,000), so "16 packets" is only exact at
~1000-byte packets, and it takes a few closes to settle. The mean
always divides by the window that '''actually''' elapsed, so a change
in rate leaves the current estimate correct and only resizes the
''next'' one. Net effect: a roughly constant ~16 samples a window from
about 30 kbit/s to 122 Mbit/s. Above that the window bottoms out at
~1 ms (still thousands of samples a window at 10–100 GbE); below
~30 kbit/s it hits the ~4.3 s ceiling. The averaging clock stretches
with the flow, the way TCP's ACK clock stretches with the RTT. A
sudden speed-up doesn't wait out a stretched window: once twice the
target bytes have arrived it closes anyway (the ~1 ms floor keeps that
from running away at high rate). So the <code>ece</code> the sender sees
is a staircase: one step per window, steps getting shorter as
the rate climbs. Two edge cases:

* '''Onset.''' The first mark after an idle stretch is passed through as-is, so a queue that's just starting to build shows up without waiting out a whole window.
* '''Gap.''' A silence longer than 4 windows resets and sends the raw sample. "Long" is '''measured in the flow's own windows''', so a slow flow's normal spacing never reads as idle; and the dwell clamp above limits what a real pause can add to the mean before the reset fires.

Alongside the marks, the receiver keeps the smallest non-zero capacity
code it saw this window and ships it with each <code>ece</code> (on an
onset/gap restart, just the current packet's code). Then it resets, so
if the path reroutes onto something faster the fed-back capacity can
climb within one window.

The estimate rides back to the sender on the reverse flow.

== Sender pacer ==

The sender paces off an SFQ virtual clock. The aggregate keeps a
virtual time <code>V</code>; each flow keeps a finish tag <code>F</code>:

V += r * Δt virtual time advances by bytes served
s = MAX(F, V) a packet behind the clock starts now
F = s + S the one after it queues behind
wait = (s - V) / r time until this packet may go

That <code>wait</code> is the flow's scheduling deadline. A packet
that's behind the virtual clock goes out now (<code>wait = 0</code>);
one that's ahead waits, and only that flow waits, nobody else.
Across an idle gap longer than 50 ms the clock credits at most the
flow's own owed lead plus one burst (50 ms of service, at least one
packet). So a flow paced slower than a packet per 50 ms still gets its
'''real''' elapsed service (capping the credit by time would
starve it) while an idle flow still can't bank an unbounded
burst.

<code>V</code> is shared by every flow in the aggregate; the finish
tags are not. Since every flow measures its start tag <code>s</code>
against the same <code>V</code>, a flow that just sent is now ahead of
<code>V</code> and has to wait, while an idle one (tag at or behind
<code>V</code>) goes right away. That is what splits the aggregate rate
<code>r</code> fairly among them.

== Rate control (AIMD + PD) ==

The rate law runs on packet sends, at most once a millisecond, and
also when feedback arrives, so a sender with no traffic of its
own still reacts. The increase terms and the proportional decrease are
each scaled by elapsed time, but not by the same clock: the increases
use banked time '''capped''' at 50 ms (an idle gap shouldn't buy an
unbounded ramp), while the decrease uses the '''uncapped''' elapsed
time (a starved sender still cuts by the right amount). The one-sided
derivative (see the
[[#Multiplicative decrease (proportional + derivative)|decrease]]) is
not scaled by time at all; it is per-step.

=== Slow start ===

Before the first congestion signal, the rate ramps up exponentially
with a 20 ms time constant:

r += r * Δt / T_ss (T_ss = 20 ms)

Slow start ends the first time a congestion signal shows up, whether
fed back from the receiver or seen at the sender's own first hop, and
it never comes back.

Slow start belongs to the aggregate, so it happens
'''once per (destination, QoS cube)''', on the first flow. A flow that
shows up later, at an aggregate that's already running, rides the
existing
estimate: it starts at the current rate and takes its share through
the [[#Sender pacer|pacer]], without probing of its own.

=== Increase: additive plus proportional probe (always on) ===

Past slow start, two increase terms run every step, congested or not:

r += a * Δt additive; a defaults to 2^16 B/s^2
r += r * Δt / T_probe proportional; T_probe = 8 s

The additive term is a fixed slope (bytes/s per second), sized to the
path capacity (see
[[#Capacity-derived floor and slope|the capacity floor]]). The
proportional probe adds a fixed fraction of the rate per unit time (it
e-folds over <code>T_probe</code>): that is what lets a flow recover in
the same number of steps whatever the link rate; a fixed additive step
is negligible next to a fast link. Together they are the
upward pressure the multiplicative decrease balances at equilibrium.
The probe is not free: it costs a standing queue that does not shrink
with rate (see [[#Fairness|fairness]]).

=== Multiplicative decrease (proportional + derivative) ===

With congestion level <code>m</code> (the fed-back <code>ece</code>, or
the local first-hop mark if there's no feedback yet), the cut is a
proportional term plus a one-sided derivative term, a PD controller on
the congestion signal:

mark = MIN(m, M) M = 512
rise = MAX(m - m_prev, 0), capped at M one-sided derivative

cut = r * rise / (4 * M) derivative, gain 1/4
cut += r * mark * Δt_ms / (1000 * M) proportional
cut = MIN(cut, r / 2) at most a halving

r -= cut
m_prev = m

* The '''proportional''' term uses the real elapsed milliseconds, so a starved sender that hasn't run the controller in a while still cuts by the right amount.
* The '''derivative''' term (<code>rise</code>) only fires when the congestion level ''goes up'' between samples: one-sided, per-step. It sharpens the response right as congestion starts.
* The cut is capped at <code>r/2</code>, so one step can at most halve the rate.

<code>M = 512 = 32 × 16</code> pins "full congestion" at a mean
<code>ecn</code> of 16, i.e. a mean queue of <code>16 × Q = 64</code>
packets.

=== Staleness ===

Feedback comes once per receiver window, and that window stretches with
the flow's byte rate (see
[[#Receiver estimate|the receiver estimate]]), so the staleness horizon
has to stretch with it too, or a slow flow's mark would expire
''between'' feedbacks and the rate would ramp straight into a congested
path. The sender mirrors the receiver: the horizon is four target
windows' worth of bytes at the current rate, floored at ~268 ms so fast
flows keep a fixed one; at the default rate floor it's ~8 s. Once a
signal is older than that it's dropped (both the fed-back estimate and
the local mark), which frees the rate to climb again after congestion
clears. Every step clamps the rate to <code>[r_min, r_max]</code>.

=== Capacity-derived floor and slope ===

The fed-back capacity code sets the controller's two rate-scale
constants, per aggregate:

target = decode(cap8) / 32 clamped to [2^13, 2^32] B/s
r_min += (target - r_min) / 2 per feedback (moving average)
a = r_min

On a path that never reports a capacity, both fall back to fixed
defaults (<code>r_min = 2^13 B/s</code>, <code>a = 2^16 B/s^2</code>).
When the estimator is live, the fairness floor and the post-cut
recovery slope scale with the bottleneck instead, and capacity kicks in
wherever <code>C/32</code> beats the default floor, roughly above
2 Mbit/s. A capacity older than 16 staleness horizons (~4.3 s for fast
flows) reverts both to the defaults. That horizon is deliberately
longer than the feedback horizon: feedback stops the instant the marks
clear, which is exactly when you need the recovery slope, and the
onset-fresh capacity (see
[[#Receiver estimate|the receiver estimate]]) re-seeds it on the first
mark of the next episode anyway.

=== Ramp and recovery ===

Three mechanisms set how fast an aggregate reaches a fast link's
rate, each owning one regime:

* '''From scratch: slow start.''' The exponential ramp hits any real link rate in well under a second (~200 ms from the seed to 10 Gbit/s; every further doubling of link speed adds one ~14 ms doubling). Nothing marks on an uncongested path, so slow start just runs until the aggregate reaches its bottleneck.
* '''After a cut: the probe.''' A cut is at most a halving, and the mark expires on the rate-relative horizon once congestion clears (see [[#Staleness|staleness]]); the probe then climbs back from a halving in <code>T_probe · ln 2 ≈ 5.5 s</code>, whatever the link rate.
* '''At the bottom: the capacity floor.''' The rate never sits more than 32× below a measured bottleneck, and the additive slope refills <code>C/32</code> a second, so the worst hole is bounded: floor to full capacity in tens of seconds, a halving in seconds.

These fit together because a deep cut needs sustained congestion,
sustained congestion backs up the bottleneck queue, and a backed-up
queue is exactly when its capacity gets measured and stamped (see
[[#Forwarder marking|forwarder marking]]). So whenever the controller
has been cut deep, the scaled floor is already live. The default floor
only ever applies to paths that never congested the sender in the first
place, where there's nothing to recover from. That's why slow start can
quit for good: the floor and the probe handle every recovery after it.

=== Regimes ===

<pre>
+-------------+ first mark seen +----------------+
| slow start |--------------------->| congestion |
| r *= e^(t/T)| | avoidance |
+-------------+ | |
| m == 0 ---> additive increase
| m > 0 ---> AI + PD decrease
+----------------+
m = fed-back ece, or the local first-hop mark when ece == 0
</pre>

== RTT behaviour ==

Because every increase and decrease is scaled by wall-clock time, two
flows with different RTTs sharing a bottleneck follow the ''same'' rate
law and settle at the ''same'' rate. So the steady-state
'''allocation is RTT-independent'''.

That is a property of the equilibrium, not the dynamics. The feedback
delay in the loop ''is'' the path RTT <code>τ</code>, and the
controller neither measures nor compensates for it. At low rate the
receiver window (up to its ~4.3 s ceiling) is the biggest lag: the loop
is slow there in proportion to how slow the flow is, just like a
long-RTT TCP. As the rate climbs the window shrinks toward its ~1 ms
floor, so its share of the loop delay ''falls'' with capacity and the
path RTT <code>τ</code> becomes the irreducible part. Two things keep
the loop damped: the adaptive window takes out the delay-dominated
corner at low <code>τ</code>, and a bucketed
'''rate-velocity damping''' (the washout: each ~31 ms bucket pulls the
rate a quarter of the way back toward its value at the previous bucket)
supplies the damping this otherwise near-double-integrator loop lacks,
which is what holds it together at high capacity and moderate
<code>τ</code>. What is left is the loop gain
<code>√G &prop; √C</code>: at very high capacity ''and''
large <code>τ</code> the <code>√G · τ</code> phase
budget is the binding constraint, and no amount of windowing or damping
removes it (see [[#Limitations|Limitations]]). So, precisely:
'''RTT-fair in equilibrium, and dynamically stable up to a'''
'''capacity-dependent RTT limit set by <code>√G · τ</code>.'''

== Fairness ==

At equilibrium the two increase terms balance the proportional
decrease, <code>a + r/T_probe = r · m*/M</code>, which pins the
congestion level at <code>m* = M · (a/r + 1/T_probe)</code>. Since
<code>ece = 8q</code> (one mark unit per <code>Q = 4</code> packets, 32
fixed-point steps per unit), that is a standing queue of

q* = 64 * a / r + 64 / T_probe (packets, r in bytes/s)

The additive part (<code>64 · a / r</code>) fades to nothing with
rate under the default slope; with the capacity-derived slope
(<code>a = C/32</code>; see
[[#Capacity-derived floor and slope|the capacity floor]]) it settles at
<code>2 C / r</code>, about two packets per competing flow, whatever the
rate. The probe part (<code>64 / T_probe</code>) is a floor that does
not move with rate (~8 packets at 8 s). That floor is what
rate-independent convergence costs you, and it is what keeps
<code>q*</code> above the marking threshold at high rate.

Two flows at the same bottleneck see the same <code>m*</code>, so each
solves <code>r_i = a / (m*/M - 1/T_probe)</code> to the same rate. In
network-utility-maximization terms that is '''proportional fairness'''
with equal weights, which at a single bottleneck is just max-min fair.

Getting a good measurement at low rate is the estimator's job, not the
floor's: the averaging window stretches with the flow (see
[[#Receiver estimate|the receiver estimate]]), so a CA-limited flow
still keeps ~16 packets a window down to ~30 kbit/s, and the
rate-relative gap threshold keeps its normal spacing from reading as
idle. The default floor (<code>2^13 B/s</code>) only bounds the extremes
(window ceiling, staleness horizon, pacer arithmetic). The floor itself
scales with the fed-back path capacity (<code>r_min = C/32</code>; see
[[#Capacity-derived floor and slope|the capacity floor]]), so about 32
CA-limited flows fit above it on any class of link. Flows whose
bottlenecks are in different classes get different slopes, so fairness
between them is capacity-weighted, not equal; see
[[#Limitations|Limitations]].

== Limitations ==

Things the algorithm '''doesn't''' do. Listed here so nobody credits it
with more than it manages.

* '''Queue-only signal, no rate term.''' <code>M</code> is a queue level, so mb-ecn is a standing-queue controller: it has to build a queue (<code>q* = 64 · a / r + 64 / T_probe</code>) to get any signal at all, and can't sit at full utilisation on an empty queue the way a controller with a rate estimate can. The probe floor (~8 packets) keeps <code>q*</code> above the marking threshold at every rate, but you pay for it with a permanent standing queue.
* '''Aggregation is per destination, per QoS cube.''' The aggregate is a stand-in for the path: flows to the same destination are assumed to share a bottleneck, and flows to different destinations run separate loops even when they pile up at the same hop. Each loop still converges to its own fair share (see [[#Fairness|fairness]]), so the cost is duplicated state and probing at that shared queue, not unfairness. One day we could tag the queue in the packet: if a forwarder stamped a queue id next to its mark, senders could key their aggregates on the real bottleneck instead of the destination, and pool the estimate and the probing across everything sharing it.
* '''Capacity is learned, and there are gaps.''' The floor and slope ride on an in-band path-capacity estimate (see [[#Forwarder marking|forwarder marking]] and [[#Capacity-derived floor and slope|the capacity floor]]), and that estimate has its own limits. A hop only learns its rate while its queue is backed up, so a rerouted or brand-new bottleneck reads ''unknown'' at first and the path MIN can briefly come from faster hops (the sender's smoothing and the next feedback bound the overshoot). The measurement is order-of-magnitude on purpose: quarter-log2 code (~19% a step), burst noise held down by a 16-packet minimum window and a max filter, and nothing learned below ~120 packets a second of busy drain (16 packets inside the ~134 ms staleness cap; at MTU that's ~1.4 Mbit/s, below which capacity/32 sits under the default floor anyway). The derived floor clamps to <code>[2^13, 2^32]</code> B/s, and flows with bottlenecks in different classes get capacity-weighted, not equal, shares at a common queue (see [[#Fairness|fairness]]).
* '''The low end trades speed, not correctness.''' Below ~30 kbit/s the averaging window hits its ~4.3 s ceiling and holds fewer samples; below ~64 kbit/s of offered load an ''app-limited'' flow spaces its packets past the gap threshold and rides the raw onset branch, as it always did. At the floor, feedback and the staleness horizon are both measured in seconds, so a slow flow converges slowly, TCP-style. Nothing blows up; nothing's quick either.
* '''No loss response.''' The controller only reacts to ECN marks. Loss is FRCP's problem, handled by retransmission, out of the CA's sight. At a bottleneck that drops instead of marking (say a plain drop-tail queue at the Ethernet or UDP shim), mb-ecn sees nothing and additive increase just keeps ramping. It's built for Ouroboros-native bottlenecks where the forwarder marks; there's no classic-bottleneck fallback.
* '''Dynamic stability has a capacity-dependent RTT limit.''' As covered under [[#RTT behaviour|RTT behaviour]], the allocation is RTT-independent but the dynamics aren't: the binding constraint is <code>√G · τ</code> with <code>√G &prop; √C</code>. The adaptive window and the washout push that limit out a long way (a single flow at 10 GbE stays stable to ~50 ms RTT in the fluid model), but the far corner (100 GbE at ≥ 50 ms) is out of reach for a window/damping controller and would need explicit-rate signalling.

== Architectural fit ==

Each of these properties falls out of something structural in the
recursive architecture. Here's the mapping.

* '''CA is fully separate from ARQ and flow control.''' Three concerns, three mechanisms, two scopes: FRCP does retransmission (ARQ) and flow control (the peer pacing the sender), end-to-end and per flow; CA runs in the IPCP, per aggregate. Each signal says one thing. A loss just means retransmit: a lossy link reads as lossy, and the congestion call is left to the marks (the [[#Limitations|limitations]] section's "no loss response" is this same separation from the other side). The peer's flow-control window just paces the endpoint: back-pressure from a slow receiver stays separate from congestion in the network. A retransmitted packet is ordinary traffic as far as the pacer cares. TCP jams all three into one window machine, where the receive window caps the congestion window and loss is both the reliability trigger and the congestion signal; here you can reason about, test, and change each one on its own.
* '''CA sits below what the application picks.''' Every flow in the layer runs under the same rate law, whatever its QoS: a greedy raw sender shares a bottleneck fairly with a reliable stream because the control belongs to the layer, on the aggregate, not to the endpoint transport's good manners.
* '''A layer owns its PCI, so the signal can be rich.''' Everyone in a layer enrolled into it, so the layer is one administrative domain by construction, at whatever scope it covers, and the header is the layer's own. That's why forwarders can write a multi-bit queue magnitude and a capacity byte straight into the packet. The datacenter schemes in [[#Heritage and positioning|heritage and positioning]] need exactly that kind of domain and only get it inside one operator's fabric; a recursive layer has it everywhere.
* '''Layer-internal addressing makes the aggregate well-defined.''' Flows in a layer run between layer addresses, so the (destination, QoS cube) aggregate, which is RFC 3124's macroflow, drops straight out of the naming. Controller state scales with the number of destinations, and each QoS cube keeps its own loop, so service classes don't share a fate.
* '''Flows are allocated, so feedback already has a channel.''' Every flow has state at both ends and a reverse direction, so the receiver's <code>ece</code> and the path capacity just ride the flow allocator's existing exchange.
* '''There's no transport ack clock, and nothing leans on one.''' The layer has to handle raw flows, which carry no acknowledgements at all, so the controller paces on wall-clock time, and that constraint is exactly what buys the RTT-independent allocation under [[#RTT behaviour|RTT behaviour]]. A restriction turned into the feature.
* '''Recursion scales it.''' Each layer handles congestion over its own scope and timescale; many N-flows ride one N-1 flow, so aggregation compounds down the stack. The capacity a layer sees at its egress queue is whatever the layer below is actually giving it (a paced, shared lower flow, not some nominal wire speed), so the signal means something at every level and back-pressure cascades down layer by layer.

There's a boundary: at a shim over legacy media the layer below neither
enrolls nor marks, which is the deployment edge behind the
[[#Limitations|limitations]] section's no-loss-response point.

== Heritage and positioning ==

mb-ecn is basically a rate-based ECN controller in the DECbit / QCN
line, adapted to a recursive layer with no acknowledgements.

The core goes back to the first Ouroboros CA policy (2020): a multi-bit
queue-depth mark relayed by forwarders to the receiver, a smoothed
multi-bit <code>ece</code> fed back on the reverse flow at the same 1/32
fixed point used today, and a sender that paced packets from a time
budget and ran slow start, additive increase and multiplicative
decrease on wall-clock time slots. Rate-based and acknowledgement-free
from the start, with RTT-independent allocation already the goal. The
present algorithm keeps that skeleton and reworks every estimator
around it: per-path aggregation with SFQ pacing, the rate-adaptive
box-car receiver, elapsed-time-scaled AIMD with a derivative term and
rate-velocity damping, and the in-band capacity signal.

* '''DECbit''' (Ramakrishnan & Jain, 1988; ToCS 1990) established binary congestion feedback set by the switch on queue occupancy. mb-ecn keeps the switch-sets-on-queue idea and carries a ''magnitude''.
* '''The Congestion Manager''' (Balakrishnan et al., SIGCOMM 1999; RFC 3124, 2001) aggregates congestion state at the end host: one controller per macroflow, a scheduler apportioning its rate across the member streams, and new streams joining at the ensemble's current state instead of probing from scratch. mb-ecn's (destination, QoS cube) aggregate is the same idea placed inside the IPCP: every layer manages its own macroflows, recursively, the SFQ pacer plays the CM scheduler's role (see [[#Sender pacer|the pacer]]), and a joining flow rides the aggregate's estimates (see [[#Slow start|slow start]]). The CM gathers its signal from transport feedback at the edge; mb-ecn reads it off the wire from the forwarders.
* '''DCTCP''' (Alizadeh et al., SIGCOMM 2010) recovers a queue magnitude at the endpoint by averaging a single threshold bit. mb-ecn instead reads the magnitude off the wire, then time-averages it at the receiver. The additive-increase / proportional-decrease structure is shared.
* '''QCN''' (IEEE 802.1Qau, 2010) and '''DCQCN''' (Zhu et al., SIGCOMM 2015) contribute the rate-based (not window-based) ECN control skeleton. mb-ecn's proportional decrease plus a probing increase mirrors that skeleton; the increase here is wall-clock scaled rather than byte-counter/timer based.
* '''HPCC''' (Li et al., SIGCOMM 2019) and '''PowerTCP''' (Addanki et al., NSDI 2022) combine a queue term ''and'' a rate term (via in-band telemetry or delay). mb-ecn now carries a coarse in-band rate (the quarter-log2 path MIN; see [[#Forwarder marking|forwarder marking]]) but uses it only to scale the controller's gains; the congestion ''signal'' remains queue-only, which is still the main functional difference (see [[#Limitations|Limitations]]).
* '''L4S / TCP Prague''' (RFC 9330–9332, 2023) make RTT-independence a requirement and use a high-frequency single-bit signal. mb-ecn shares the RTT-independent ''allocation'' goal but reaches it by wall-clock-scaled rate control, with a low-frequency multi-bit signal.

What's new is the pairing: a multi-bit magnitude on the wire with a
wall-clock-scaled rate pacer, in a setting with no per-flow ack clock.
The trade-off, spelled out above, is a queue-only signal and a
reactivity capped by the averaging window.

== Parameters ==

These are the values behind every figure in this document. They're
'''coupled''': the mechanisms only fit together while a few relations
hold. The gap-restart horizon at the rate floor has to exceed a
packet's service time (or a floor-rate flow loops at onset); a
floor-rate flow's target window has to fit under the window ceiling;
the control interval has to sit under the damping bucket, which sits
under the idle credit cap; the rate floor mustn't exceed the slow-start
seed; and the derived-floor ceiling has to stay under the rate ceiling.
Retune them as a set, against those constraints.

{| class="wikitable"
! Parameter !! Value !! Meaning
|-
| Marking quantum <code>Q</code> || 4 packets || Mark onset and step; layer-wide
|-
| Feedback resolution || 1/32 <code>ecn</code> unit || Fixed-point LSB of <code>ece</code>
|-
| Full-congestion reference <code>M</code> || 512 || Mean queue of 64 packets
|-
| Receiver window target || 16 packets (16,000 bytes) || Samples per window
|-
| Initial receiver window || ~67 ms || Before rate is known
|-
| Receiver window bounds || ~1.05 ms – ~4.3 s || Clamp on <code>W</code>
|-
| Window resize weight || 1/4 || Moving average toward target
|-
| Early window close || 2 × target bytes || Speed-up escape
|-
| Gap restart || 4 windows || Idle horizon (rate-relative)
|-
| Additive slope <code>a</code> (default) || 2^16 B/s^2 || Lower clamp of derived slope
|-
| Probe time constant <code>T_probe</code> || 8 s || Rate-proportional recovery
|-
| Derivative gain || 1/4 || Onset sharpening
|-
| Rate floor <code>r_min</code> (default) || 2^13 B/s || Lower clamp of derived floor
|-
| Slow-start seed rate || 2^16 B/s || Initial rate
|-
| Slow-start time constant || 20 ms || Exponential ramp
|-
| Rate ceiling <code>r_max</code> || 2^37 B/s || Upper clamp
|-
| Capacity scale || <code>C</code> / 32 || Floor and slope from bottleneck
|-
| Capacity smoothing || 1/2 || Moving average per feedback
|-
| Capacity staleness || 16 × feedback horizon || Revert to defaults
|-
| Derived floor ceiling || 2^32 B/s || Upper clamp on derived floor
|-
| Control interval || 1 ms || Minimum spacing of rate updates
|-
| Idle credit cap || 50 ms || Burst allowance / increase banking
|-
| Feedback staleness floor || ~268 ms || Floor of rate-relative horizon
|-
| Damping bucket || ~31 ms || Rate-velocity washout cadence
|-
| Damping fraction || 1/4 || Pullback per bucket
|-
| Estimator fold spacing || 1 ms || Minimum measurement cadence
|-
| Estimator window closure || 16 packets drained || Self-scaling window
|-
| Estimator window staleness || ~134 ms || Discard across traffic gaps
|-
| Estimator idle tolerance || 1/8 of arrivals || Unsaturated-window rejection
|-
| Estimator decay || 1/16 per window || Max-filter convergence from below
|}

== References ==

=== Source ===

The implementation follows the algorithm above:

* <code>src/ipcpd/unicast/ca/mb-ecn.c</code>, <code>mb-ecn.h</code>: receiver estimator, pacer and rate control.
* <code>src/ipcpd/unicast/ca/ops.h</code>: CA policy interface.
* <code>src/ipcpd/unicast/cap.c</code>, <code>cap.h</code>: link-capacity estimator and quarter-log2 codec.
* <code>src/ipcpd/unicast/dt.c</code>, <code>fa.c</code>: per-hop marking and stamping, and the feedback carrying <code>ece</code> + <code>cap8</code>.
* <code>src/ipcpd/unicast/psched.c</code>: consumes the pacing deadline.

=== Literature ===

* K. K. Ramakrishnan, R. Jain, "A Binary Feedback Scheme for Congestion Avoidance in Computer Networks" (DECbit), ACM ToCS, 1990.
* H. Balakrishnan, H. S. Rahul, S. Seshan, "An Integrated Congestion Management Architecture for Internet Hosts", SIGCOMM 1999; H. Balakrishnan, S. Seshan, "The Congestion Manager", RFC 3124, 2001.
* M. Alizadeh et al., "Data Center TCP (DCTCP)", SIGCOMM 2010.
* Y. Zhu et al., "Congestion Control for Large-Scale RDMA Deployments" (DCQCN), SIGCOMM 2015.
* R. Mittal et al., "TIMELY: RTT-based Congestion Control", SIGCOMM 2015.
* Y. Li et al., "HPCC: High Precision Congestion Control", SIGCOMM 2019.
* V. Addanki et al., "PowerTCP", NSDI 2022.
* K. De Schepper, B. Briscoe (eds.), "Low Latency, Low Loss, and Scalable Throughput (L4S)", RFC 9330/9331/9332.
* F. Kelly, "Charging and Rate Control for Elastic Traffic", 1997; R. Srikant, "The Mathematics of Internet Congestion Control", 2004.

Congestion avoidance

2026-07-11T22:13:43Z

Dimitri:

{{DISPLAYTITLE:mb-ecn - Multi-bit ECN Congestion Avoidance}}

mb-ecn is a congestion-avoidance (CA) policy for the Ouroboros unicast
IPCP. Reliability, ordering and flow control are FRCP's job, end-to-end
and per flow; congestion avoidance is a separate concern, and it runs
in the IPCP, once per layer. Within a layer the IPCP controls
'''aggregates''': one control loop per (destination address, QoS cube),
shared by every flow to that destination. The other policy is
<code>nop</code>, which does nothing.

This document is about the algorithm: what it does and why. The
code follows it; the [[#References|reference section]] maps the pieces
to source files. It doesn't oversell: the [[#Limitations|limitations]]
section says plainly what it can't do.

"MUST", "SHOULD", "MAY" and friends mean what BCP 14 (RFC 2119,
RFC 8174) says, but only where they appear in capitals.

== Notation ==

{| class="wikitable"
! Symbol !! Units !! Meaning
|-
| <code>r</code> || B/s || Paced send rate
|-
| <code>C</code> || B/s || Bottleneck capacity
|-
| <code>S</code> || bytes || Packet size
|-
| <code>q</code> || packets || Standing queue occupancy at the bottleneck
|-
| <code>Q</code> || packets || Marking quantum: packets per mark unit (4)
|-
| <code>ecn</code> || 8-bit code || Per-packet congestion mark set by a forwarder
|-
| <code>ece</code> || 1/32 <code>ecn</code> || Receiver-side congestion estimate: 32 × time-mean <code>ecn</code>
|-
| <code>cap8</code> || 8-bit code || Path capacity, quarter-log2: <code>C ≈ 2^(cap8 / 4)</code> B/s, 0 = unknown
|-
| <code>W</code> || ns || Receiver averaging window
|-
| <code>a</code> || B/s^2 || Additive-increase slope
|-
| <code>M</code> || <code>ece</code> units || Full-congestion reference level (512)
|-
| <code>Δt</code> || ns || Elapsed wall-clock time between two events
|-
| <code>τ</code> || n/a || Path round-trip time (feedback delay); the controller does not measure it
|}

Rate is the control variable throughout.

Every concrete figure in this document (window bounds, horizons,
rate thresholds) is just an instance of the parameter values in the
[[#Parameters|parameters table]]. What the algorithm fixes is the
mechanisms and the relations between parameters; retune the parameters
and the figures move together.

__TOC__

== Overview ==

mb-ecn is a rate-based, ECN-driven controller with three moving parts,
one at each point of the loop:

<pre>
sender forwarder
+--------------------------------+ +--------------------------+
| SFQ virtual-clock pacer | | ecn = MAX(ecn, queue/Q) |
| rate r, paced per packet | data | (deepest queue wins) |
| AIMD + PD control on r |------>| cap8 = MIN(cap8, link) |
+--------------------------------+ +--------------------------+
^ |
| ece + cap8 feedback | marked data
| v
+--------------------------------+ +--------------------------+
| reads downstream ece, |<------| receiver |
| updates the rate on feedback, | ece | time-mean of ecn over |
| scales floor/slope to cap8 | cap8 | an adaptive window |
+--------------------------------+ +--------------------------+
</pre>

# The '''forwarder''' marks each packet with a ''multi-bit'' magnitude proportional to its standing queue, and MIN-stamps its measured outgoing-link capacity into the same PCI.
# The '''receiver''' turns the stream of marks into a time-averaged congestion estimate <code>ece</code> and feeds it back to the sender, together with the window minimum of the path-capacity codes.
# The '''sender''' paces its rate with a start-time fair-queuing (SFQ) virtual clock, and adjusts that rate with additive-increase / multiplicative-decrease (AIMD) driven by <code>ece</code>; the rate floor and the additive slope derive from the fed-back path capacity.

There's no timer thread: the controller runs when a packet goes out or
feedback comes back. Every step is scaled by elapsed wall-clock time,
and that is what makes the ''allocation'' independent of RTT (see
[[#RTT behaviour|RTT behaviour]]).

The unit of control is the '''aggregate''': one per
<code>(destination address, QoS cube)</code>, shared by every flow to
that destination at that QoS. They share one controller and one rate.
A new flow joins at whatever rate the aggregate is already running; when
a flow leaves, its share goes to the others. The pacer (SFQ) splits
that rate fairly across the member flows, so per-flow fairness is the
scheduler's doing, not the rate law's.

== Forwarder marking ==

A forwarder marks a packet based on how many packets are already queued
on the outgoing link:

mark = queued / Q (Q = 4 packets)
ecn = MAX(ecn, mark) (saturating, 8-bit field)

<code>Q</code> is fixed for the whole layer, not tuned per hop: the marks
get MAX-combined across hops, so every forwarder MUST use the same
quantum or the numbers don't compare.

Two things worth noting:

* '''It's a magnitude, not a bit.''' The mark is an integer that tracks queue depth, in steps of <code>Q</code> packets: a coarse read of the standing queue.
* '''MAX along the path.''' Cross several forwarders and the packet carries the largest mark, i.e. the deepest queue it passed. Taking the MAX (not a sum) keeps the number bounded and monotone across hops.

There's a '''dead zone''': below <code>Q</code> queued packets the mark is 0.

=== Capacity stamping ===

Each forwarder also measures its outgoing link's capacity and stamps it
into the packet. The measurement is a busy-period drain rate: look at
the queue at most once a millisecond, and keep a window open until 16
packets have drained. So the window '''sizes itself to the link''':
the once-a-millisecond cadence caps it on fast links, the 16-packet
drain time on slow ones (~19 ms at 10 Mbit/s). If more than 1/8 of the
arrivals hit an empty queue, throw the window out: the link
wasn't saturated. The odd empty sample (a token-bucket shaper grazing
zero) is fine. A saturated queue drains at the link rate, so a max
filter that decays slowly (1/16 per window) creeps up to it from below.
A window that started or ended on an empty queue might have drained
into buffers downstream faster than the wire, so it may pull the
estimate down but never up. On the wire the code is quarter-log2
(<code>cap8 = 4 log2 C</code>, ~19% a step, 0 = unknown), and each hop
MIN-combines its own into the byte, so the packet arrives carrying the
slowest hop's rate. A hop that has never backed up stamps nothing,
which is fine, since only backed-up hops matter.

== Receiver estimate ==

The receiver turns the marks into a smoothed estimate <code>ece</code>,
averaged over a window <code>W</code> that '''tracks the incoming byte rate'''.
It's a plain time-average over that window (a box-car, not an EWMA).
Per packet, with <code>Δt</code> the gap since the last one:

A += ecn * MIN(Δt, W) dwell-weighted; one packet
weighs at most one window
B += S accumulate bytes this window
...
at window close (elapsed >= W, or B >= 2 * B_target with at
least the window floor elapsed):
ece = 32 * A / elapsed mean over the actual window
W += (B_target * elapsed / B - W) / 4 nudge toward the size
that holds the target
W = clamp(W, ~1.05 ms, ~4.3 s)
A = 0 ; B = 0 hard reset

When a window closes, the next one is nudged (a quarter-weight
moving average) toward the size that would hold about 16 packets
at the current byte rate, starting from ~67 ms. The target is in bytes
(<code>B_target</code> = 16,000), so "16 packets" is only exact at
~1000-byte packets, and it takes a few closes to settle. The mean
always divides by the window that '''actually''' elapsed, so a change
in rate leaves the current estimate correct and only resizes the
''next'' one. Net effect: a roughly constant ~16 samples a window from
about 30 kbit/s to 122 Mbit/s. Above that the window bottoms out at
~1 ms (still thousands of samples a window at 10–100 GbE); below
~30 kbit/s it hits the ~4.3 s ceiling. The averaging clock stretches
with the flow, the way TCP's ACK clock stretches with the RTT. A
sudden speed-up doesn't wait out a stretched window: once twice the
target bytes have arrived it closes anyway (the ~1 ms floor keeps that
from running away at high rate). So the <code>ece</code> the sender sees
is a staircase: one step per window, steps getting shorter as
the rate climbs. Two edge cases:

* '''Onset.''' The first mark after an idle stretch is passed through as-is, so a queue that's just starting to build shows up without waiting out a whole window.
* '''Gap.''' A silence longer than 4 windows resets and sends the raw sample. "Long" is '''measured in the flow's own windows''', so a slow flow's normal spacing never reads as idle; and the dwell clamp above limits what a real pause can add to the mean before the reset fires.

Alongside the marks, the receiver keeps the smallest non-zero capacity
code it saw this window and ships it with each <code>ece</code> (on an
onset/gap restart, just the current packet's code). Then it resets, so
if the path reroutes onto something faster the fed-back capacity can
climb within one window.

The estimate rides back to the sender on the reverse flow.

== Sender pacer ==

The sender paces off an SFQ virtual clock. The aggregate keeps a
virtual time <code>V</code>; each flow keeps a finish tag <code>F</code>:

V += r * Δt virtual time advances by bytes served
s = MAX(F, V) a packet behind the clock starts now
F = s + S the one after it queues behind
wait = (s - V) / r time until this packet may go

That <code>wait</code> is the flow's scheduling deadline. A packet
that's behind the virtual clock goes out now (<code>wait = 0</code>);
one that's ahead waits, and only that flow waits, nobody else.
Across an idle gap longer than 50 ms the clock credits at most the
flow's own owed lead plus one burst (50 ms of service, at least one
packet). So a flow paced slower than a packet per 50 ms still gets its
'''real''' elapsed service (capping the credit by time would
starve it) while an idle flow still can't bank an unbounded
burst.

<code>V</code> is shared by every flow in the aggregate; the finish
tags are not. Since every flow measures its start tag <code>s</code>
against the same <code>V</code>, a flow that just sent is now ahead of
<code>V</code> and has to wait, while an idle one (tag at or behind
<code>V</code>) goes right away. That is what splits the aggregate rate
<code>r</code> fairly among them.

== Rate control (AIMD + PD) ==

The rate law runs on packet sends, at most once a millisecond, and
also when feedback arrives, so a sender with no traffic of its
own still reacts. The increase terms and the proportional decrease are
each scaled by elapsed time, but not by the same clock: the increases
use banked time '''capped''' at 50 ms (an idle gap shouldn't buy an
unbounded ramp), while the decrease uses the '''uncapped''' elapsed
time (a starved sender still cuts by the right amount). The one-sided
derivative (see the
[[#Multiplicative decrease (proportional + derivative)|decrease]]) is
not scaled by time at all; it is per-step.

=== Slow start ===

Before the first congestion signal, the rate ramps up exponentially
with a 20 ms time constant:

r += r * Δt / T_ss (T_ss = 20 ms)

Slow start ends the first time a congestion signal shows up, whether
fed back from the receiver or seen at the sender's own first hop, and
it never comes back.

Slow start belongs to the aggregate, so it happens
'''once per (destination, QoS cube)''', on the first flow. A flow that
shows up later, at an aggregate that's already running, rides the
existing
estimate: it starts at the current rate and takes its share through
the [[#Sender pacer|pacer]], without probing of its own.

=== Increase: additive plus proportional probe (always on) ===

Past slow start, two increase terms run every step, congested or not:

r += a * Δt additive; a defaults to 2^16 B/s^2
r += r * Δt / T_probe proportional; T_probe = 8 s

The additive term is a fixed slope (bytes/s per second), sized to the
path capacity (see
[[#Capacity-derived floor and slope|the capacity floor]]). The
proportional probe adds a fixed fraction of the rate per unit time (it
e-folds over <code>T_probe</code>): that is what lets a flow recover in
the same number of steps whatever the link rate; a fixed additive step
is negligible next to a fast link. Together they are the
upward pressure the multiplicative decrease balances at equilibrium.
The probe is not free: it costs a standing queue that does not shrink
with rate (see [[#Fairness|fairness]]).

=== Multiplicative decrease (proportional + derivative) ===

With congestion level <code>m</code> (the fed-back <code>ece</code>, or
the local first-hop mark if there's no feedback yet), the cut is a
proportional term plus a one-sided derivative term, a PD controller on
the congestion signal:

mark = MIN(m, M) M = 512
rise = MAX(m - m_prev, 0), capped at M one-sided derivative

cut = r * rise / (4 * M) derivative, gain 1/4
cut += r * mark * Δt_ms / (1000 * M) proportional
cut = MIN(cut, r / 2) at most a halving

r -= cut
m_prev = m

* The '''proportional''' term uses the real elapsed milliseconds, so a starved sender that hasn't run the controller in a while still cuts by the right amount.
* The '''derivative''' term (<code>rise</code>) only fires when the congestion level ''goes up'' between samples: one-sided, per-step. It sharpens the response right as congestion starts.
* The cut is capped at <code>r/2</code>, so one step can at most halve the rate.

<code>M = 512 = 32 × 16</code> pins "full congestion" at a mean
<code>ecn</code> of 16, i.e. a mean queue of <code>16 × Q = 64</code>
packets.

=== Staleness ===

Feedback comes once per receiver window, and that window stretches with
the flow's byte rate (see
[[#Receiver estimate|the receiver estimate]]), so the staleness horizon
has to stretch with it too, or a slow flow's mark would expire
''between'' feedbacks and the rate would ramp straight into a congested
path. The sender mirrors the receiver: the horizon is four target
windows' worth of bytes at the current rate, floored at ~268 ms so fast
flows keep a fixed one; at the default rate floor it's ~8 s. Once a
signal is older than that it's dropped (both the fed-back estimate and
the local mark), which frees the rate to climb again after congestion
clears. Every step clamps the rate to <code>[r_min, r_max]</code>.

=== Capacity-derived floor and slope ===

The fed-back capacity code sets the controller's two rate-scale
constants, per aggregate:

target = decode(cap8) / 32 clamped to [2^13, 2^32] B/s
r_min += (target - r_min) / 2 per feedback (moving average)
a = r_min

On a path that never reports a capacity, both fall back to fixed
defaults (<code>r_min = 2^13 B/s</code>, <code>a = 2^16 B/s^2</code>).
When the estimator is live, the fairness floor and the post-cut
recovery slope scale with the bottleneck instead, and capacity kicks in
wherever <code>C/32</code> beats the default floor, roughly above
2 Mbit/s. A capacity older than 16 staleness horizons (~4.3 s for fast
flows) reverts both to the defaults. That horizon is deliberately
longer than the feedback horizon: feedback stops the instant the marks
clear, which is exactly when you need the recovery slope, and the
onset-fresh capacity (see
[[#Receiver estimate|the receiver estimate]]) re-seeds it on the first
mark of the next episode anyway.

=== Ramp and recovery ===

Three mechanisms set how fast an aggregate reaches a fast link's
rate, each owning one regime:

* '''From scratch: slow start.''' The exponential ramp hits any real link rate in well under a second (~200 ms from the seed to 10 Gbit/s; every further doubling of link speed adds one ~14 ms doubling). Nothing marks on an uncongested path, so slow start just runs until the aggregate reaches its bottleneck.
* '''After a cut: the probe.''' A cut is at most a halving, and the mark expires on the rate-relative horizon once congestion clears (see [[#Staleness|staleness]]); the probe then climbs back from a halving in <code>T_probe · ln 2 ≈ 5.5 s</code>, whatever the link rate.
* '''At the bottom: the capacity floor.''' The rate never sits more than 32× below a measured bottleneck, and the additive slope refills <code>C/32</code> a second, so the worst hole is bounded: floor to full capacity in tens of seconds, a halving in seconds.

These fit together because a deep cut needs sustained congestion,
sustained congestion backs up the bottleneck queue, and a backed-up
queue is exactly when its capacity gets measured and stamped (see
[[#Forwarder marking|forwarder marking]]). So whenever the controller
has been cut deep, the scaled floor is already live. The default floor
only ever applies to paths that never congested the sender in the first
place, where there's nothing to recover from. That's why slow start can
quit for good: the floor and the probe handle every recovery after it.

=== Regimes ===

<pre>
+-------------+ first mark seen +----------------+
| slow start |--------------------->| congestion |
| r *= e^(t/T)| | avoidance |
+-------------+ | |
| m == 0 ---> additive increase
| m > 0 ---> AI + PD decrease
+----------------+
m = fed-back ece, or the local first-hop mark when ece == 0
</pre>

== RTT behaviour ==

Because every increase and decrease is scaled by wall-clock time, two
flows with different RTTs sharing a bottleneck follow the ''same'' rate
law and settle at the ''same'' rate. So the steady-state
'''allocation is RTT-independent'''.

That is a property of the equilibrium, not the dynamics. The feedback
delay in the loop ''is'' the path RTT <code>τ</code>, and the
controller neither measures nor compensates for it. At low rate the
receiver window (up to its ~4.3 s ceiling) is the biggest lag: the loop
is slow there in proportion to how slow the flow is, just like a
long-RTT TCP. As the rate climbs the window shrinks toward its ~1 ms
floor, so its share of the loop delay ''falls'' with capacity and the
path RTT <code>τ</code> becomes the irreducible part. Two things keep
the loop damped: the adaptive window takes out the delay-dominated
corner at low <code>τ</code>, and a bucketed
'''rate-velocity damping''' (the washout: each ~31 ms bucket pulls the
rate a quarter of the way back toward its value at the previous bucket)
supplies the damping this otherwise near-double-integrator loop lacks,
which is what holds it together at high capacity and moderate
<code>τ</code>. What is left is the loop gain
<code>√G &prop; √C</code>: at very high capacity ''and''
large <code>τ</code> the <code>√G · τ</code> phase
budget is the binding constraint, and no amount of windowing or damping
removes it (see [[#Limitations|Limitations]]). So, precisely:
'''RTT-fair in equilibrium, and dynamically stable up to a'''
'''capacity-dependent RTT limit set by <code>√G · τ</code>.'''

== Fairness ==

At equilibrium the two increase terms balance the proportional
decrease, <code>a + r/T_probe = r · m*/M</code>, which pins the
congestion level at <code>m* = M · (a/r + 1/T_probe)</code>. Since
<code>ece = 8q</code> (one mark unit per <code>Q = 4</code> packets, 32
fixed-point steps per unit), that is a standing queue of

q* = 64 * a / r + 64 / T_probe (packets, r in bytes/s)

The additive part (<code>64 · a / r</code>) fades to nothing with
rate under the default slope; with the capacity-derived slope
(<code>a = C/32</code>; see
[[#Capacity-derived floor and slope|the capacity floor]]) it settles at
<code>2 C / r</code>, about two packets per competing flow, whatever the
rate. The probe part (<code>64 / T_probe</code>) is a floor that does
not move with rate (~8 packets at 8 s). That floor is what
rate-independent convergence costs you, and it is what keeps
<code>q*</code> above the marking threshold at high rate.

Two flows at the same bottleneck see the same <code>m*</code>, so each
solves <code>r_i = a / (m*/M - 1/T_probe)</code> to the same rate. In
network-utility-maximization terms that is '''proportional fairness'''
with equal weights, which at a single bottleneck is just max-min fair.

Getting a good measurement at low rate is the estimator's job, not the
floor's: the averaging window stretches with the flow (see
[[#Receiver estimate|the receiver estimate]]), so a CA-limited flow
still keeps ~16 packets a window down to ~30 kbit/s, and the
rate-relative gap threshold keeps its normal spacing from reading as
idle. The default floor (<code>2^13 B/s</code>) only bounds the extremes
(window ceiling, staleness horizon, pacer arithmetic). The floor itself
scales with the fed-back path capacity (<code>r_min = C/32</code>; see
[[#Capacity-derived floor and slope|the capacity floor]]), so about 32
CA-limited flows fit above it on any class of link. Flows whose
bottlenecks are in different classes get different slopes, so fairness
between them is capacity-weighted, not equal; see
[[#Limitations|Limitations]].

== Limitations ==

Things the algorithm '''doesn't''' do. Listed here so nobody credits it
with more than it manages.

* '''Queue-only signal, no rate term.''' <code>M</code> is a queue level, so mb-ecn is a standing-queue controller: it has to build a queue (<code>q* = 64 · a / r + 64 / T_probe</code>) to get any signal at all, and can't sit at full utilisation on an empty queue the way a controller with a rate estimate can. The probe floor (~8 packets) keeps <code>q*</code> above the marking threshold at every rate, but you pay for it with a permanent standing queue.
* '''Aggregation is per destination, per QoS cube.''' The aggregate is a stand-in for the path: flows to the same destination are assumed to share a bottleneck, and flows to different destinations run separate loops even when they pile up at the same hop. Each loop still converges to its own fair share (see [[#Fairness|fairness]]), so the cost is duplicated state and probing at that shared queue, not unfairness. One day we could tag the queue in the packet: if a forwarder stamped a queue id next to its mark, senders could key their aggregates on the real bottleneck instead of the destination, and pool the estimate and the probing across everything sharing it.
* '''Capacity is learned, and there are gaps.''' The floor and slope ride on an in-band path-capacity estimate (see [[#Forwarder marking|forwarder marking]] and [[#Capacity-derived floor and slope|the capacity floor]]), and that estimate has its own limits. A hop only learns its rate while its queue is backed up, so a rerouted or brand-new bottleneck reads ''unknown'' at first and the path MIN can briefly come from faster hops (the sender's smoothing and the next feedback bound the overshoot). The measurement is order-of-magnitude on purpose: quarter-log2 code (~19% a step), burst noise held down by a 16-packet minimum window and a max filter, and nothing learned below ~120 packets a second of busy drain (16 packets inside the ~134 ms staleness cap; at MTU that's ~1.4 Mbit/s, below which capacity/32 sits under the default floor anyway). The derived floor clamps to <code>[2^13, 2^32]</code> B/s, and flows with bottlenecks in different classes get capacity-weighted, not equal, shares at a common queue (see [[#Fairness|fairness]]).
* '''The low end trades speed, not correctness.''' Below ~30 kbit/s the averaging window hits its ~4.3 s ceiling and holds fewer samples; below ~64 kbit/s of offered load an ''app-limited'' flow spaces its packets past the gap threshold and rides the raw onset branch, as it always did. At the floor, feedback and the staleness horizon are both measured in seconds, so a slow flow converges slowly, TCP-style. Nothing blows up; nothing's quick either.
* '''No loss response.''' The controller only reacts to ECN marks. Loss is FRCP's problem, handled by retransmission, out of the CA's sight. At a bottleneck that drops instead of marking (say a plain drop-tail queue at the Ethernet or UDP shim), mb-ecn sees nothing and additive increase just keeps ramping. It's built for Ouroboros-native bottlenecks where the forwarder marks; there's no classic-bottleneck fallback.
* '''Dynamic stability has a capacity-dependent RTT limit.''' As covered under [[#RTT behaviour|RTT behaviour]], the allocation is RTT-independent but the dynamics aren't: the binding constraint is <code>√G · τ</code> with <code>√G &prop; √C</code>. The adaptive window and the washout push that limit out a long way (a single flow at 10 GbE stays stable to ~50 ms RTT in the fluid model), but the far corner (100 GbE at ≥ 50 ms) is out of reach for a window/damping controller and would need explicit-rate signalling.

== Architectural fit ==

Each of these properties falls out of something structural in the
recursive architecture. Here's the mapping.

* '''CA is fully separate from ARQ and flow control.''' Three concerns, three mechanisms, two scopes: FRCP does retransmission (ARQ) and flow control (the peer pacing the sender), end-to-end and per flow; CA runs in the IPCP, per aggregate. Each signal says one thing. A loss just means retransmit: a lossy link reads as lossy, and the congestion call is left to the marks (the [[#Limitations|limitations]] section's "no loss response" is this same separation from the other side). The peer's flow-control window just paces the endpoint: back-pressure from a slow receiver stays separate from congestion in the network. A retransmitted packet is ordinary traffic as far as the pacer cares. TCP jams all three into one window machine, where the receive window caps the congestion window and loss is both the reliability trigger and the congestion signal; here you can reason about, test, and change each one on its own.
* '''CA sits below what the application picks.''' Every flow in the layer runs under the same rate law, whatever its QoS: a greedy raw sender shares a bottleneck fairly with a reliable stream because the control belongs to the layer, on the aggregate, not to the endpoint transport's good manners.
* '''A layer owns its PCI, so the signal can be rich.''' Everyone in a layer enrolled into it, so the layer is one administrative domain by construction, at whatever scope it covers, and the header is the layer's own. That's why forwarders can write a multi-bit queue magnitude and a capacity byte straight into the packet. The datacenter schemes in [[#Heritage and positioning|heritage and positioning]] need exactly that kind of domain and only get it inside one operator's fabric; a recursive layer has it everywhere.
* '''Layer-internal addressing makes the aggregate well-defined.''' Flows in a layer run between layer addresses, so the (destination, QoS cube) aggregate, which is RFC 3124's macroflow, drops straight out of the naming. Controller state scales with the number of destinations, and each QoS cube keeps its own loop, so service classes don't share a fate.
* '''Flows are allocated, so feedback already has a channel.''' Every flow has state at both ends and a reverse direction, so the receiver's <code>ece</code> and the path capacity just ride the flow allocator's existing exchange.
* '''There's no transport ack clock, and nothing leans on one.''' The layer has to handle raw flows, which carry no acknowledgements at all, so the controller paces on wall-clock time, and that constraint is exactly what buys the RTT-independent allocation under [[#RTT behaviour|RTT behaviour]]. A restriction turned into the feature.
* '''Recursion scales it.''' Each layer handles congestion over its own scope and timescale; many N-flows ride one N-1 flow, so aggregation compounds down the stack. The capacity a layer sees at its egress queue is whatever the layer below is actually giving it (a paced, shared lower flow, not some nominal wire speed), so the signal means something at every level and back-pressure cascades down layer by layer.

There's a boundary: at a shim over legacy media the layer below neither
enrolls nor marks, which is the deployment edge behind the
[[#Limitations|limitations]] section's no-loss-response point.

== Heritage and positioning ==

mb-ecn is basically a rate-based ECN controller in the DECbit / QCN
line, adapted to a recursive layer with no acknowledgements.

The core goes back to the first Ouroboros CA policy (2020): a multi-bit
queue-depth mark relayed by forwarders to the receiver, a smoothed
multi-bit <code>ece</code> fed back on the reverse flow at the same 1/32
fixed point used today, and a sender that paced packets from a time
budget and ran slow start, additive increase and multiplicative
decrease on wall-clock time slots. Rate-based and acknowledgement-free
from the start, with RTT-independent allocation already the goal. The
present algorithm keeps that skeleton and reworks every estimator
around it: per-path aggregation with SFQ pacing, the rate-adaptive
box-car receiver, elapsed-time-scaled AIMD with a derivative term and
rate-velocity damping, and the in-band capacity signal.

* '''DECbit''' (Ramakrishnan & Jain, 1988; ToCS 1990) established binary congestion feedback set by the switch on queue occupancy. mb-ecn keeps the switch-sets-on-queue idea and carries a ''magnitude''.
* '''The Congestion Manager''' (Balakrishnan et al., SIGCOMM 1999; RFC 3124, 2001) aggregates congestion state at the end host: one controller per macroflow, a scheduler apportioning its rate across the member streams, and new streams joining at the ensemble's current state instead of probing from scratch. mb-ecn's (destination, QoS cube) aggregate is the same idea placed inside the IPCP: every layer manages its own macroflows, recursively, the SFQ pacer plays the CM scheduler's role (see [[#Sender pacer|the pacer]]), and a joining flow rides the aggregate's estimates (see [[#Slow start|slow start]]). The CM gathers its signal from transport feedback at the edge; mb-ecn reads it off the wire from the forwarders.
* '''DCTCP''' (Alizadeh et al., SIGCOMM 2010) recovers a queue magnitude at the endpoint by averaging a single threshold bit. mb-ecn instead reads the magnitude off the wire, then time-averages it at the receiver. The additive-increase / proportional-decrease structure is shared.
* '''QCN''' (IEEE 802.1Qau, 2010) and '''DCQCN''' (Zhu et al., SIGCOMM 2015) contribute the rate-based (not window-based) ECN control skeleton. mb-ecn's proportional decrease plus a probing increase mirrors that skeleton; the increase here is wall-clock scaled rather than byte-counter/timer based.
* '''HPCC''' (Li et al., SIGCOMM 2019) and '''PowerTCP''' (Addanki et al., NSDI 2022) combine a queue term ''and'' a rate term (via in-band telemetry or delay). mb-ecn now carries a coarse in-band rate (the quarter-log2 path MIN; see [[#Forwarder marking|forwarder marking]]) but uses it only to scale the controller's gains; the congestion ''signal'' remains queue-only, which is still the main functional difference (see [[#Limitations|Limitations]]).
* '''L4S / TCP Prague''' (RFC 9330–9332, 2023) make RTT-independence a requirement and use a high-frequency single-bit signal. mb-ecn shares the RTT-independent ''allocation'' goal but reaches it by wall-clock-scaled rate control, with a low-frequency multi-bit signal.

What's new is the pairing: a multi-bit magnitude on the wire with a
wall-clock-scaled rate pacer, in a setting with no per-flow ack clock.
The trade-off, spelled out above, is a queue-only signal and a
reactivity capped by the averaging window.

== Parameters ==

These are the values behind every figure in this document. They're
'''coupled''': the mechanisms only fit together while a few relations
hold. The gap-restart horizon at the rate floor has to exceed a
packet's service time (or a floor-rate flow loops at onset); a
floor-rate flow's target window has to fit under the window ceiling;
the control interval has to sit under the damping bucket, which sits
under the idle credit cap; the rate floor mustn't exceed the slow-start
seed; and the derived-floor ceiling has to stay under the rate ceiling.
Retune them as a set, against those constraints.

{| class="wikitable"
! Parameter !! Value !! Meaning
|-
| Marking quantum <code>Q</code> || 4 packets || Mark onset and step; layer-wide
|-
| Feedback resolution || 1/32 <code>ecn</code> unit || Fixed-point LSB of <code>ece</code>
|-
| Full-congestion reference <code>M</code> || 512 || Mean queue of 64 packets
|-
| Receiver window target || 16 packets (16,000 bytes) || Samples per window
|-
| Initial receiver window || ~67 ms || Before rate is known
|-
| Receiver window bounds || ~1.05 ms – ~4.3 s || Clamp on <code>W</code>
|-
| Window resize weight || 1/4 || Moving average toward target
|-
| Early window close || 2 × target bytes || Speed-up escape
|-
| Gap restart || 4 windows || Idle horizon (rate-relative)
|-
| Additive slope <code>a</code> (default) || 2^16 B/s^2 || Lower clamp of derived slope
|-
| Probe time constant <code>T_probe</code> || 8 s || Rate-proportional recovery
|-
| Derivative gain || 1/4 || Onset sharpening
|-
| Rate floor <code>r_min</code> (default) || 2^13 B/s || Lower clamp of derived floor
|-
| Slow-start seed rate || 2^16 B/s || Initial rate
|-
| Slow-start time constant || 20 ms || Exponential ramp
|-
| Rate ceiling <code>r_max</code> || 2^37 B/s || Upper clamp
|-
| Capacity scale || <code>C</code> / 32 || Floor and slope from bottleneck
|-
| Capacity smoothing || 1/2 || Moving average per feedback
|-
| Capacity staleness || 16 × feedback horizon || Revert to defaults
|-
| Derived floor ceiling || 2^32 B/s || Upper clamp on derived floor
|-
| Control interval || 1 ms || Minimum spacing of rate updates
|-
| Idle credit cap || 50 ms || Burst allowance / increase banking
|-
| Feedback staleness floor || ~268 ms || Floor of rate-relative horizon
|-
| Damping bucket || ~31 ms || Rate-velocity washout cadence
|-
| Damping fraction || 1/4 || Pullback per bucket
|-
| Estimator fold spacing || 1 ms || Minimum measurement cadence
|-
| Estimator window closure || 16 packets drained || Self-scaling window
|-
| Estimator window staleness || ~134 ms || Discard across traffic gaps
|-
| Estimator idle tolerance || 1/8 of arrivals || Unsaturated-window rejection
|-
| Estimator decay || 1/16 per window || Max-filter convergence from below
|}

== References ==

=== Source ===

The implementation follows the algorithm above:

* <code>src/ipcpd/unicast/ca/mb-ecn.c</code>, <code>mb-ecn.h</code>: receiver estimator, pacer and rate control.
* <code>src/ipcpd/unicast/ca/ops.h</code>: CA policy interface.
* <code>src/ipcpd/unicast/cap.c</code>, <code>cap.h</code>: link-capacity estimator and quarter-log2 codec.
* <code>src/ipcpd/unicast/dt.c</code>, <code>fa.c</code>: per-hop marking and stamping, and the feedback carrying <code>ece</code> + <code>cap8</code>.
* <code>src/ipcpd/unicast/psched.c</code>: consumes the pacing deadline.

=== Literature ===

* K. K. Ramakrishnan, R. Jain, "A Binary Feedback Scheme for Congestion Avoidance in Computer Networks" (DECbit), ACM ToCS, 1990.
* H. Balakrishnan, H. S. Rahul, S. Seshan, "An Integrated Congestion Management Architecture for Internet Hosts", SIGCOMM 1999; H. Balakrishnan, S. Seshan, "The Congestion Manager", RFC 3124, 2001.
* M. Alizadeh et al., "Data Center TCP (DCTCP)", SIGCOMM 2010.
* Y. Zhu et al., "Congestion Control for Large-Scale RDMA Deployments" (DCQCN), SIGCOMM 2015.
* R. Mittal et al., "TIMELY: RTT-based Congestion Control", SIGCOMM 2015.
* Y. Li et al., "HPCC: High Precision Congestion Control", SIGCOMM 2019.
* V. Addanki et al., "PowerTCP", NSDI 2022.
* K. De Schepper, B. Briscoe (eds.), "Low Latency, Low Loss, and Scalable Throughput (L4S)", RFC 9330/9331/9332.
* F. Kelly, "Charging and Rate Control for Elastic Traffic", 1997; R. Srikant, "The Mathematics of Internet Congestion Control", 2004.

Congestion avoidance

2026-07-11T21:25:12Z

Dimitri:

{{DISPLAYTITLE:mb-ecn - Multi-bit ECN Congestion Avoidance}}

mb-ecn is a congestion-avoidance (CA) policy for the Ouroboros unicast
IPCP. It lives in the IPC Process: the flow-and-retransmission task
(FRCP) provides reliability, in-order delivery and flow control
end-to-end; congestion avoidance is orthogonal and runs per IPCP
layer. Within a layer, the IPCP controls '''aggregates''', one loop
per (destination address, QoS cube), shared by every flow toward that
destination. The alternative policy is <code>nop</code> (no congestion
avoidance).

This document describes the algorithm: what the policy does and why.
The implementation follows it ([[#12. References|Section 12]] maps the
pieces to source files). It does not claim properties the algorithm
does not have; [[#8. Limitations|Section 8]] states the known gaps
explicitly.

The keywords "MUST", "SHOULD", "MAY" etc. are used only where they
appear in all capitals, per BCP 14 (RFC 2119, RFC 8174).

== Notation ==

{| class="wikitable"
! Symbol !! Units !! Meaning
|-
| <code>r</code> || B/s || Paced send rate
|-
| <code>C</code> || B/s || Bottleneck capacity
|-
| <code>S</code> || bytes || Packet size
|-
| <code>q</code> || packets || Standing queue occupancy at the bottleneck
|-
| <code>Q</code> || packets || Marking quantum: packets per mark unit (4)
|-
| <code>ecn</code> || 8-bit code || Per-packet congestion mark set by a forwarder
|-
| <code>ece</code> || 32 × ecn || Receiver-side congestion estimate (time-mean of <code>ecn</code>)
|-
| <code>cap8</code> || 8-bit code || Path capacity, quarter-log2: <code>C ≈ 2^(cap8 / 4)</code> B/s, 0 = unknown
|-
| <code>W</code> || ns || Receiver averaging window
|-
| <code>a</code> || B/s^2 || Additive-increase slope
|-
| <code>M</code> || <code>ece</code> || Full-congestion reference level (512)
|-
| <code>Δt</code> || ns || Elapsed wall-clock time between two events
|-
| <code>τ</code> || — || Path round-trip time (feedback delay); the controller does not measure it
|}

Rate is the control variable throughout.

All concrete figures in this document — window bounds, horizons,
rate thresholds — are instances of the parameter values in
[[#11. Parameters|Section 11]]. The mechanisms and the relations
between parameters are what the algorithm fixes; retuning the
parameters moves the figures together.

__TOC__

== Overview ==

mb-ecn is a rate-based, ECN-driven controller with three moving parts,
one at each point of the loop:

<pre>
sender forwarder
+--------------------------------+ +--------------------------+
| SFQ virtual-clock pacer | | ecn = MAX(ecn, queue/Q) |
| rate r, paced per packet | data | (deepest queue wins) |
| AIMD + PD control on r |------>| cap8 = MIN(cap8, link) |
+--------------------------------+ +--------------------------+
^ |
| ece + cap8 feedback | marked data
| v
+--------------------------------+ +--------------------------+
| reads downstream ece, |<------| receiver |
| updates the rate on feedback, | ece | time-mean of ecn over |
| scales floor/slope to cap8 | cap8 | an adaptive window |
+--------------------------------+ +--------------------------+
</pre>

# The '''forwarder''' marks each packet with a ''multi-bit'' magnitude
proportional to its standing queue, and MIN-stamps its measured
outgoing-link capacity into the same PCI.
# The '''receiver''' turns the stream of marks into a time-averaged
congestion estimate <code>ece</code> and feeds it back to the sender,
together with the window minimum of the path-capacity codes.
# The '''sender''' paces its rate with a start-time fair-queuing (SFQ)
virtual clock, and adjusts that rate with additive-increase /
multiplicative-decrease (AIMD) driven by <code>ece</code>; the rate floor
and the additive slope derive from the fed-back path capacity.

The controller runs on packet sends and on feedback arrivals. All
increase/decrease steps are scaled by elapsed
wall-clock time, which is what makes the ''allocation'' independent of
RTT (see [[#6. RTT behaviour|Section 6]]).

The unit of control is the '''aggregate''', kept in the IPCP per
<code>(destination address, QoS cube)</code>. Every flow toward that
destination at that QoS shares one controller and one rate: a new
flow joins the aggregate at its current rate, and a departing flow
leaves the rate to the others. The pacer divides the aggregate rate
fairly across the member flows (SFQ), so per-flow fairness within an
aggregate is a scheduler property, distinct from the rate law
described here.

== Forwarder marking ==

A forwarder marks a packet as a function of the packets already queued
on the outgoing link:

mark = queued / Q (Q = 4 packets)
ecn = MAX(ecn, mark) (saturating, 8-bit field)

The quantum <code>Q</code> is a layer-wide constant: the marks it
quantizes are combined by MAX across hops, so all forwarders in a
layer MUST use the same quantum for the signal to be comparable.

Two properties:

* '''Multi-bit magnitude.''' The mark is an integer proportional to
queue depth, quantized in steps of <code>Q</code> packets: a coarse
readout of the standing queue.
* '''MAX along the path.''' A packet crossing several forwarders carries
the maximum mark, i.e. the deepest queue on its path. MAX keeps the
signal range-stable and monotone across hops.

There is a '''dead zone''': for <code>queued < Q</code> the mark is 0.

=== Capacity stamping ===

Each forwarder also measures the capacity of its outgoing link and
stamps it into the packet. The estimate is a busy-period drain rate:
the queue is observed at most once per millisecond, and a measurement
window stays open until 16 packets have drained, so its length
'''self-scales with the link rate''' — the millisecond cadence
bounds it on fast links, the 16-packet drain time on slow ones
(~19 ms at 10 Mbit/s). A window in which more than 1/8 of
the arrivals found the queue empty is discarded as unsaturated;
occasional empty observations (token-bucket shapers grazing zero) are
tolerated. The drain rate of a saturated queue is the link rate; a max
filter with slow decay (1/16 per window) converges on it from below. A
window that opened or closed on an empty queue may have drained into
buffers below at above-wire rate, so it may lower the estimate but
never raise it. The code on the wire is quarter-log2
(<code>cap8 = 4 log2 C</code>, ~19% per step, 0 = unknown) and each hop
MIN-combines its own code into the byte, so a packet arrives carrying
the bottleneck's rate. A hop that has never been backlogged stamps
nothing; since only backlogged hops matter, the signal exists exactly
when it is needed.

== 3. Receiver estimate ==

The receiver converts marks into a smoothed estimate <code>ece</code> over a
time window <code>W</code> that '''adapts to the incoming byte rate'''. It is
a '''boxcar (rectangular) time-integral mean'''. Per packet, with
<code>Δt</code> the gap since the previous packet:

A += ecn * MIN(Δt, W) dwell-weighted; one packet
weighs at most one window
B += S accumulate bytes this window
...
at window close (elapsed >= W, or B >= 2 * B_target with at
least the window floor elapsed):
ece = 32 * A / elapsed mean over the actual window
W += (B_target * elapsed / B - W) / 4 nudge toward the size
that holds the target
W = clamp(W, ~1.05 ms, ~4.3 s)
A = 0 ; B = 0 hard reset

At each close the next window is nudged by a quarter-weight moving
average toward the size that would hold about 16 packets at the
measured byte rate, from an initial ~67 ms. The target is byte-based (<code>B_target</code> = 16,000 bytes), so
"16 packets" is exact only at ~1000-byte packets, and the window
converges to it over several closes. The mean always divides by the
'''actual''' elapsed window, so a rate step leaves the current
estimate exact and only re-sizes the ''next'' window. The effect is a roughly constant sample
count — ~16 packets — from about 30 kbit/s to 122 Mbit/s;
above that the window floors at ~1 ms (a cadence still carrying
thousands of samples at 10–100 GbE), and below ~30 kbit/s it
saturates at the ~4.3 s ceiling. The averaging clock stretches with
the flow the way TCP's ACK clock stretches with the RTT. A speed-up
escapes a stretched window early: once twice the target bytes arrive
the window closes anyway (the window floor keeps that cadence bounded
at high rate). The fed-back <code>ece</code> is thus a piecewise-constant
staircase whose step period tracks the rate. Two edge cases:

* '''Onset''' (first mark after an idle estimate) emits the
instantaneous mark undiluted, so a starting queue is reported without
a full window of delay.
* '''Gap''' longer than 4 windows resets the window and emits the raw
sample. The threshold is '''rate-relative''': idle means a few
''current'' windows of silence, so a slow flow's normal inter-packet
gap never reads as idle, while the in-window dwell clamp above bounds
what a genuine pause can add to the mean before the restart fires.

Alongside the mark integral, the receiver keeps the MIN of the nonzero
capacity codes seen in the current window; each emitted <code>ece</code>
carries that minimum (the raw packet's code on onset/gap restarts) and
the fold then resets, so a reroute to a faster path can raise the
fed-back capacity within one window.

The estimate is fed back to the sender on the reverse flow.

== 4. Sender pacer ==

The sender paces with an SFQ virtual clock. The context keeps a
virtual time <code>V</code>; each flow keeps a finish tag <code>F</code>:

V += r * Δt virtual time advances by bytes served
s = MAX(F, V) a packet behind the clock starts now
F = s + S the one after it queues behind
wait = (s - V) / r time until this packet may go

The <code>wait</code> becomes the flow's scheduling deadline: a packet
already behind the virtual clock is sent immediately
(<code>wait = 0</code>); one ahead waits, deferring only its own flow.
A clock advance across an idle gap longer than 50 ms credits at most
the calling flow's owed lead plus one burst (50 ms of service, at
least one packet): a paced flow slower than one packet per 50 ms
receives its '''true''' elapsed service — a time-capped credit
would decay such a flow without bound — while an idle flow still
cannot bank an unbounded burst.

The virtual time <code>V</code> is shared by every flow in the context;
the finish tags are per flow. Because every flow computes its start
tag <code>s</code> against the same <code>V</code>, a flow that has just sent
carries a finish tag ahead of <code>V</code> and waits, while an idle flow
(finish tag at or behind <code>V</code>) starts immediately — this is
what fairly divides the aggregate rate <code>r</code> across them.

== 5. Rate control (AIMD + PD) ==

The rate law runs on packet sends, at most once per millisecond, and
also on feedback arrivals so that a sender with no traffic of its own
still reacts. Each increase term and the proportional decrease are
scaled by elapsed wall-clock time, each by its own clock: the
increase terms use time banked and '''capped''' at 50 ms (an idle gap
cannot bank an unbounded ramp), while the proportional decrease uses
the '''uncapped''' elapsed time (a starved sender still cuts by the
right amount). The one-sided derivative (Section 5.3) is a per-delta
term.

=== 5.1. Slow start ===

Before the first congestion signal the rate ramps exponentially with a
20 ms time constant:

r += r * Δt / T_ss (T_ss = 20 ms)

Slow start ends the first time a congestion signal arrives —
fed back from the receiver or observed at the sender's own first hop
— and never resumes.

Slow start belongs to the aggregate, so it runs '''once per
(destination, QoS cube)''', on the first flow. A flow arriving at an
established aggregate rides the existing estimates: it enters at the
aggregate's current rate and receives its fair share of it through
the pacer (Section 4), with no probing of its own.

=== 5.2. Increase: additive plus proportional probe (always on) ===

Past slow start, two increase terms are applied every step, both
regardless of congestion:

r += a * Δt additive; a defaults to 2^16 B/s^2
r += r * Δt / T_probe proportional; T_probe = 8 s

The additive term is a fixed per-context slope (bytes/s per second),
scaled to the path capacity (Section 5.5). The proportional probe
grows the rate by a fixed fraction per unit time (e-folds over
<code>T_probe</code>): a flow recovers in the same number of steps at any
link rate; the fixed additive term's effect vanishes relative to a
fast link. Both are the "probing"
pressure the multiplicative decrease balances at equilibrium; the
probe's cost is a rate-independent standing-queue floor (Section 7).

=== 5.3. Multiplicative decrease (proportional + derivative) ===

With congestion level <code>m</code> (the fed-back <code>ece</code>, or a local
first-hop mark as fallback), the decrease is the sum of a proportional
term and a one-sided derivative term — a PD controller on the
congestion signal:

mark = MIN(m, M) M = 512
rise = MAX(m - m_prev, 0), capped at M one-sided derivative

cut = r * rise / (4 * M) derivative, gain 1/4
cut += r * mark * Δt_ms / (1000 * M) proportional
cut = MIN(cut, r / 2) at most a halving

r -= cut
m_prev = m

* The '''proportional''' term is scaled by honest elapsed time in
milliseconds, so a starved sender that has not run the controller
for a while still cuts by the right amount.
* The '''derivative''' term (<code>rise</code>) reacts to an ''increase'' in
the congestion level between samples; it is one-sided and per-delta.
It sharpens the reaction at the onset of congestion.
* The cut is clamped to <code>r/2</code> per step, bounding the decrease to
a halving.

<code>M = 512 = 32 × 16</code> defines "full congestion" as a mean
<code>ecn</code> of 16, i.e. a mean queue of <code>16 × Q = 64</code> packets.

=== 5.4. Staleness ===

Feedback arrives once per receiver window, and the window stretches
with the flow's byte rate (Section 3) — so the staleness horizon
must stretch with it, or a slow flow's mark would age out ''between''
feedbacks and the rate would ramp against a congested path. The
sender mirrors the receiver: the horizon is four target windows of
bytes at the current rate, floored at ~268 ms so fast flows keep a
fixed horizon; at the default rate floor it is ~8 s. A signal older
than the horizon is aged out (both the fed-back estimate and the
local mark), freeing the rate to ramp once congestion clears. The
rate is clamped to
<code>[r_min, r_max]</code> on every step.

=== 5.5. Capacity-derived floor and slope ===

The fed-back capacity code sets the two rate-scale constants of the
controller, per context:

target = decode(cap8) / 32 clamped to [2^13, 2^32] B/s
r_min += (target - r_min) / 2 per feedback (moving average)
a = r_min

The defaults are fixed constants (<code>r_min = 2^13 B/s</code>,
<code>a = 2^16 B/s^2</code>), used on paths that never report a capacity;
with the estimator live the fairness floor and the post-cut recovery
slope scale with the bottleneck, and capacity engages wherever
<code>C/32</code> clears the default floor, i.e. above ~2 Mbit/s. A
capacity older than 16 staleness horizons (~4.3 s for fast flows)
reverts both to the defaults. That horizon deliberately outlives the
feedback horizon: feedback stops the moment the marks clear, which is
exactly when the recovery slope is needed; the onset-fresh capacity
(Section 3) re-seeds it on the first mark of the next episode either
way.

=== 5.6. Ramp and recovery ===

Three mechanisms set how fast an aggregate reaches a fast link's
rate, each owning one regime:

* '''From scratch: slow start.''' The exponential ramp reaches any
physical link rate in well under a second (~200 ms from the seed to
10 Gbit/s; each further doubling of link speed costs one more
~14 ms doubling time). On an uncongested path nothing marks, so
slow start runs until the aggregate arrives at its bottleneck.
* '''After a cut: the probe.''' A decrease is at most a halving per
step, and the mark ages out on the rate-relative horizon once
congestion clears (Section 5.4); the proportional probe then heals
a halving in <code>T_probe · ln 2 ≈ 5.5 s</code> at any
link rate.
* '''At the bottom: the capacity floor.''' The rate sits at most a
factor 32 below a measured bottleneck, and the additive slope
refills <code>C/32</code> per second, so the deepest hole is bounded:
floor to full capacity in tens of seconds, a halving in seconds.

These compose because a deep cut requires sustained congestion,
sustained congestion backlogs the bottleneck queue, and a backlogged
queue is exactly when its capacity is measured and stamped
(Section 2): whenever the controller is cut deep, the scaled floor is
live. The default floor only governs paths that never congested the
sender — where there is nothing to recover from. This is why
slow start can end for good: the floor and the probe cover every
later recovery.

=== 5.7. Regimes ===

<pre>
+-------------+ first mark seen +----------------+
| slow start |--------------------->| congestion |
| r *= e^(t/T)| | avoidance |
+-------------+ | |
| m == 0 -> AI |
| m > 0 -> AIPD |
+----------------+
m = fed-back ece, or the local first-hop mark when ece == 0
</pre>

== 6. RTT behaviour ==

Because every increase and decrease is scaled by wall-clock time,
two flows of different RTT that share a bottleneck obey the ''same''
rate law and converge to the ''same'' rate. The steady-state
'''allocation is RTT-independent'''.

This is a property of the equilibrium, not of the dynamics. The
feedback delay in the loop ''is'' the path RTT <code>τ</code>, and the
controller does not measure or compensate for it. At low rate the
receiver window (up to its ~4.3 s ceiling) is the dominant lag —
the loop is slow there in proportion to how slow the flow is, exactly
as a long-RTT TCP is — while as the rate rises the window shrinks
toward its ~1 ms floor, so the window's contribution to the loop delay
''falls'' with capacity and the path RTT <code>τ</code> becomes the
irreducible term. Two mechanisms keep the loop damped: the adaptive
window removes the delay-dominated corner at low <code>τ</code>, and a
bucketed '''rate-velocity damping''' (a washout: each ~31 ms bucket
pulls the rate a quarter of the way back toward its value at the
previous bucket) supplies the damping the otherwise
near-double-integrator lacks, which is what holds the loop together at
high capacity and moderate <code>τ</code>. What remains is the loop gain
<code>√G &prop; √C</code>: at very high capacity ''and'' large
<code>τ</code> the <code>√G · τ</code> phase budget is the
binding constraint, and no window or damping trick removes it (see
[[#8. Limitations|Section 8]]). A precise statement is therefore:
'''RTT-fair in equilibrium, and dynamically stable up to a
capacity-dependent RTT limit set by <code>√G · τ</code>.'''

== 7. Fairness ==

At equilibrium the two increase terms balance the proportional
decrease, <code>a + r/T_probe = r · m*/M</code>, which pins the
congestion level to <code>m* = M · (a/r + 1/T_probe)</code> and, since
<code>ece = 8q</code> (one mark unit per <code>Q = 4</code> packets, 32 fixed-point
steps per unit), a standing queue of

q* = 64 * a / r + 64 / T_probe (packets, r in bytes/s)

The additive part (<code>64 · a / r</code>) vanishes with rate under
the default slope; with the capacity-derived slope (<code>a = C/32</code>,
Section 5.5) it becomes <code>2 C / r</code> — about two packets per
competing flow, rate-independent. The proportional-probe part
(<code>64 / T_probe</code>) is a rate-independent floor (~8 packets at
8 s). That floor is the cost of rate-independent convergence, and it
keeps <code>q*</code> above the marking threshold at high rate.

Two flows at the same bottleneck see the same <code>m*</code>, so each
solves <code>r_i = a / (m*/M - 1/T_probe)</code> to the same rate. Under
the network-utility-maximization view this corresponds to
'''proportional fairness''' (equal weights), which is max-min fair at
a single bottleneck.

Measurement fidelity at low rate comes from the estimator itself:
the averaging window stretches with the flow
(Section 3), so a CA-limited flow keeps ~16 packets per window at any
rate down to ~30 kbit/s, and the rate-relative gap threshold keeps its
inter-packet spacing from reading as idle. The default floor
(<code>2^13</code> B/s) only bounds the extremes (window ceiling,
staleness horizon, pacer arithmetic). The floor scales with the
fed-back path capacity (<code>r_min = C/32</code>, Section 5.5), so
roughly 32 CA-limited flows fit above it at any link class. Flows
whose paths differ in bottleneck class derive different slopes, so
fairness across them is capacity-weighted; see
[[#8. Limitations|Section 8]].

== 9. Architectural fit ==

Each property the preceding sections build toward attaches to a
structural feature of the recursive architecture. This section makes
the mapping explicit.

* '''Congestion avoidance is fully orthogonal to ARQ and to flow
control.''' Three concerns, three mechanisms, two scopes: FRCP
provides retransmission (ARQ) and flow control (the peer pacing the
sender) end-to-end, per flow; congestion avoidance runs in the
IPCP, per aggregate. Each signal means one thing. A loss triggers
a retransmission and nothing else — a lossy link reads as
lossy, with the congestion verdict left to the marks (Section 8's
"no loss response" is this orthogonality stated from the other
side). The peer's flow-control window paces the endpoint and
nothing else — back-pressure from a slow receiver stays
distinct from congestion in the network. A retransmitted packet is
ordinary traffic to the pacer. TCP folds all three into one window
machine, where the receive window bounds the congestion window and
loss serves as both reliability trigger and congestion signal;
here each mechanism can be reasoned about, tested and evolved
alone.
* '''Congestion avoidance sits below application choice.''' Every
flow in the layer is paced by the same rate law, whatever its QoS:
a greedy raw sender shares a bottleneck fairly with a reliable
stream because the control is a property of the layer, on the
aggregate, rather than a courtesy of the endpoint transport.
* '''A layer defines its own PCI, so the signal can be rich.'''
Every member of a layer is enrolled into it: the layer is a single
administrative domain by construction, at whatever scope it spans,
and its header is layer-internal. Forwarders therefore write a
multi-bit queue magnitude and a capacity byte directly into the
packet. The datacenter schemes of
[[#10. Heritage and positioning|Section 10]] require exactly such a
domain and find it only inside one operator's fabric; a recursive
layer supplies it everywhere.
* '''Layer-internal addressing makes the aggregate well-defined.'''
Flows in a layer run between layer addresses, so the
(destination, QoS cube) aggregate — RFC 3124's macroflow
— falls out of the naming structure. Controller state scales
with destinations, and each QoS cube keeps its own loop, so
service classes keep separate fates.
* '''Flows are allocated, so feedback has a channel.''' Every flow
has state at both ends and a reverse direction; the receiver's
<code>ece</code> and the path capacity ride the flow allocator's
existing exchange.
* '''There is no transport ack clock, and none is relied on.''' The
layer must control raw flows, which carry no acknowledgements at
all, so the controller paces on wall-clock time — and that
constraint yields the RTT-independent allocation of Section 6. An
architectural restriction becomes the controller's distinguishing
property.
* '''Recursion scales the scheme.''' Each layer controls congestion
over its own scope and timescale; many N-flows ride one N-1 flow,
so aggregation compounds down the stack. The capacity a layer
measures at its egress queue is the rate the layer below actually
provides — a paced, shared lower flow rather than a nominal
wire speed — so the signal stays meaningful at every level,
and pushback cascades layer by layer.

The fit has a boundary: at a shim over legacy media the layer below
neither enrolls nor marks, which is the deployment edge behind
Section 8's no-loss-response limitation.

== 10. Heritage and positioning ==

mb-ecn is best understood as a rate-based ECN controller in the DECbit /
QCN line, adapted to an acknowledgement-less recursive layer.

The core of the scheme dates to the first Ouroboros
congestion-avoidance policy (2020): a multi-bit queue-depth mark
relayed by forwarders to the receiver, a smoothed multi-bit
<code>ece</code> fed back on the reverse flow at the same 1/32 fixed
point used today, and a sender that paced packets from a time budget
and ran slow start, additive increase and multiplicative decrease on
wall-clock time slots — rate-based and acknowledgement-free from
the start, with RTT-independent allocation already an objective. The
present algorithm keeps that skeleton and reworks every estimator
around it: per-path aggregation with SFQ pacing, the rate-adaptive
boxcar receiver, elapsed-time-scaled AIMD with a derivative term and
rate-velocity damping, and the in-band capacity signal.

* '''DECbit''' (Ramakrishnan & Jain, 1988; ToCS 1990) established
binary congestion feedback set by the switch on queue occupancy.
mb-ecn keeps the switch-sets-on-queue idea and carries a
''magnitude''.
* '''The Congestion Manager''' (Balakrishnan et al., SIGCOMM 1999;
RFC 3124, 2001) aggregates congestion state at the end host: one
controller per macroflow, a scheduler apportioning its rate across
the member streams, and new streams joining at the ensemble's
current state instead of probing from scratch. mb-ecn's
(destination, QoS cube) aggregate is the same idea placed inside
the IPCP: every layer manages its own macroflows, recursively, the
SFQ pacer plays the CM scheduler's role (Section 4), and a joining
flow rides the aggregate's estimates (Section 5.1). The CM gathers
its signal from transport feedback at the edge; mb-ecn reads it
off the wire from the forwarders.
* '''DCTCP''' (Alizadeh et al., SIGCOMM 2010) recovers a queue
magnitude at the endpoint by averaging a single threshold bit. mb-ecn
instead reads the magnitude off the wire, then time-averages it at
the receiver. The additive-increase / proportional-decrease structure
is shared.
* '''QCN''' (IEEE 802.1Qau, 2010) and '''DCQCN''' (Zhu et al., SIGCOMM
2015) contribute the rate-based (not window-based) ECN control
skeleton. mb-ecn's proportional decrease plus a probing increase
mirrors that skeleton; the increase here is wall-clock scaled rather
than byte-counter/timer based.
* '''HPCC''' (Li et al., SIGCOMM 2019) and '''PowerTCP''' (Addanki et
al., NSDI 2022) combine a queue term ''and'' a rate term (via in-band
telemetry or delay). mb-ecn now carries a coarse in-band rate (the
quarter-log2 path MIN, Section 2) but uses it only to scale the
controller's gains; the congestion ''signal'' remains queue-only,
which is still the main functional difference (Section 8).
* '''L4S / TCP Prague''' (RFC 9330–9332, 2023) make
RTT-independence a requirement and use a high-frequency single-bit
signal. mb-ecn shares the RTT-independent ''allocation'' goal but
reaches it by wall-clock-scaled rate control, with a low-frequency
multi-bit signal.

The novel combination is the multi-bit magnitude on the wire fused with
a wall-clock-scaled rate pacer in a setting with no per-flow ack clock.
The trade-off, made explicit above, is a queue-only signal and a
reactivity capped by the averaging window.

== 11. Parameters ==

These are the values every figure in this document instantiates. They
are '''coupled''': the mechanisms compose only while certain relations
hold — the gap-restart horizon at the rate floor must exceed a
packet's service time (or a floor-rate flow restart-loops at onset),
a floor-rate flow's target window must fit under the window ceiling,
the control interval must sit under the damping bucket under the idle
credit cap, the rate floor must not exceed the slow-start seed, and
the derived-floor ceiling must stay under the rate ceiling. Retune
them as a set, against those invariants.

{| class="wikitable"
! Parameter !! Value !! Meaning
|-
| Marking quantum <code>Q</code> || 4 packets || Mark onset and step; layer-wide
|-
| Feedback resolution || 1/32 <code>ecn</code> unit || Fixed-point LSB of <code>ece</code>
|-
| Full-congestion reference <code>M</code> || 512 || Mean queue of 64 packets
|-
| Receiver window target || 16 packets (16,000 bytes) || Samples per window
|-
| Initial receiver window || ~67 ms || Before rate is known
|-
| Receiver window bounds || ~1.05 ms – ~4.3 s || Clamp on <code>W</code>
|-
| Window resize weight || 1/4 || Moving average toward target
|-
| Early window close || 2 × target bytes || Speed-up escape
|-
| Gap restart || 4 windows || Idle horizon (rate-relative)
|-
| Additive slope <code>a</code> (default) || 2^16 B/s^2 || Lower clamp of derived slope
|-
| Probe time constant <code>T_probe</code> || 8 s || Rate-proportional recovery
|-
| Derivative gain || 1/4 || Onset sharpening
|-
| Rate floor <code>r_min</code> (default) || 2^13 B/s || Lower clamp of derived floor
|-
| Slow-start seed rate || 2^16 B/s || Initial rate
|-
| Slow-start time constant || 20 ms || Exponential ramp
|-
| Rate ceiling <code>r_max</code> || 2^37 B/s || Upper clamp
|-
| Capacity scale || <code>C</code> / 32 || Floor and slope from bottleneck
|-
| Capacity smoothing || 1/2 || Moving average per feedback
|-
| Capacity staleness || 16 × feedback horizon || Revert to defaults
|-
| Derived floor ceiling || 2^32 B/s || Upper clamp on derived floor
|-
| Control interval || 1 ms || Minimum spacing of rate updates
|-
| Idle credit cap || 50 ms || Burst allowance / increase banking
|-
| Feedback staleness floor || ~268 ms || Floor of rate-relative horizon
|-
| Damping bucket || ~31 ms || Rate-velocity washout cadence
|-
| Damping fraction || 1/4 || Pullback per bucket
|-
| Estimator fold spacing || 1 ms || Minimum measurement cadence
|-
| Estimator window closure || 16 packets drained || Self-scaling window
|-
| Estimator window staleness || ~134 ms || Discard across traffic gaps
|-
| Estimator idle tolerance || 1/8 of arrivals || Unsaturated-window rejection
|-
| Estimator decay || 1/16 per window || Max-filter convergence from below
|}

== 12. References ==

=== 12.1. Source ===

The implementation follows the algorithm above:

* <code>src/ipcpd/unicast/ca/mb-ecn.c</code>, <code>mb-ecn.h</code> —
receiver estimator, pacer and rate control.
* <code>src/ipcpd/unicast/ca/ops.h</code> — CA policy interface.
* <code>src/ipcpd/unicast/cap.c</code>, <code>cap.h</code> — link-capacity
estimator and quarter-log2 codec.
* <code>src/ipcpd/unicast/dt.c</code>, <code>fa.c</code> — per-hop marking
and stamping, and the feedback carrying <code>ece</code> + <code>cap8</code>.
* <code>src/ipcpd/unicast/psched.c</code> — consumes the pacing deadline.

=== 12.2. Literature ===

* K. K. Ramakrishnan, R. Jain, "A Binary Feedback Scheme for Congestion
Avoidance in Computer Networks" (DECbit), ACM ToCS, 1990.
* H. Balakrishnan, H. S. Rahul, S. Seshan, "An Integrated Congestion
Management Architecture for Internet Hosts", SIGCOMM 1999;
H. Balakrishnan, S. Seshan, "The Congestion Manager", RFC 3124, 2001.
* M. Alizadeh et al., "Data Center TCP (DCTCP)", SIGCOMM 2010.
* Y. Zhu et al., "Congestion Control for Large-Scale RDMA Deployments"
(DCQCN), SIGCOMM 2015.
* R. Mittal et al., "TIMELY: RTT-based Congestion Control", SIGCOMM 2015.
* Y. Li et al., "HPCC: High Precision Congestion Control", SIGCOMM 2019.
* V. Addanki et al., "PowerTCP", NSDI 2022.
* K. De Schepper, B. Briscoe (eds.), "Low Latency, Low Loss, and
Scalable Throughput (L4S)", RFC 9330/9331/9332.
* F. Kelly, "Charging and Rate Control for Elastic Traffic", 1997;
R. Srikant, "The Mathematics of Internet Congestion Control", 2004.

Congestion avoidance

2026-07-11T20:46:46Z

Dimitri: /* 2. Forwarder marking */

{{DISPLAYTITLE:mb-ecn - Multi-bit ECN Congestion Avoidance}}

mb-ecn is a congestion-avoidance (CA) policy for the Ouroboros unicast
IPCP. It lives in the IPC Process: the flow-and-retransmission task
(FRCP) provides reliability, in-order delivery and flow control
end-to-end; congestion avoidance is orthogonal and runs per IPCP
layer. Within a layer, the IPCP controls '''aggregates''', one loop
per (destination address, QoS cube), shared by every flow toward that
destination. The alternative policy is <code>nop</code> (no congestion
avoidance).

This document describes the algorithm: what the policy does and why.
The implementation follows it ([[#12. References|Section 12]] maps the
pieces to source files). It does not claim properties the algorithm
does not have; [[#8. Limitations|Section 8]] states the known gaps
explicitly.

The keywords "MUST", "SHOULD", "MAY" etc. are used only where they
appear in all capitals, per BCP 14 (RFC 2119, RFC 8174).

== Notation ==

;<code>r</code>
:Paced send rate, bytes per second.
;<code>C</code>
:Bottleneck capacity, bytes per second.
;<code>S</code>
:Packet size in bytes.
;<code>q</code>
:Standing queue occupancy at the bottleneck, in packets.
;<code>Q</code>
:Marking quantum, packets per mark unit (4).
;<code>ecn</code>
:Per-packet congestion mark set by a forwarder, an unsigned integer
(on-wire field is 8-bit).
;<code>ece</code>
:Receiver-side congestion estimate, fixed point with LSB = 1/32 of an
<code>ecn</code> unit, i.e. <code>ece = 32 × (time-mean ecn)</code>.
;<code>cap8</code>
:Path-capacity code carried per packet, quarter-log2:
<code>C ≈ 2^(cap8 / 4)</code> bytes/s, 0 = unknown.
;<code>W</code>
:Receiver averaging window, nanoseconds.
;<code>a</code>
:Additive-increase slope, bytes/s per second.
;<code>M</code>
:Full-congestion reference level of <code>ece</code> (512).
;<code>Δt</code>
:Elapsed wall-clock time between two events, nanoseconds.
;<code>τ</code>
:Path round-trip time (feedback delay). The controller does not
measure it.

Rate is the control variable throughout.

All concrete figures in this document — window bounds, horizons,
rate thresholds — are instances of the parameter values in
[[#11. Parameters|Section 11]]. The mechanisms and the relations
between parameters are what the algorithm fixes; retuning the
parameters moves the figures together.

__TOC__

== Overview ==

mb-ecn is a rate-based, ECN-driven controller with three moving parts,
one at each point of the loop:

<pre>
sender forwarder
+--------------------------------+ +--------------------------+
| SFQ virtual-clock pacer | | ecn = MAX(ecn, queue/Q) |
| rate r, paced per packet | data | (deepest queue wins) |
| AIMD + PD control on r |------>| cap8 = MIN(cap8, link) |
+--------------------------------+ +--------------------------+
^ |
| ece + cap8 feedback | marked data
| v
+--------------------------------+ +--------------------------+
| reads downstream ece, |<------| receiver |
| updates the rate on feedback, | ece | time-mean of ecn over |
| scales floor/slope to cap8 | cap8 | an adaptive window |
+--------------------------------+ +--------------------------+
</pre>

# The '''forwarder''' marks each packet with a ''multi-bit'' magnitude
proportional to its standing queue, and MIN-stamps its measured
outgoing-link capacity into the same PCI.
# The '''receiver''' turns the stream of marks into a time-averaged
congestion estimate <code>ece</code> and feeds it back to the sender,
together with the window minimum of the path-capacity codes.
# The '''sender''' paces its rate with a start-time fair-queuing (SFQ)
virtual clock, and adjusts that rate with additive-increase /
multiplicative-decrease (AIMD) driven by <code>ece</code>; the rate floor
and the additive slope derive from the fed-back path capacity.

The controller runs on packet sends and on feedback arrivals. All
increase/decrease steps are scaled by elapsed
wall-clock time, which is what makes the ''allocation'' independent of
RTT (see [[#6. RTT behaviour|Section 6]]).

The unit of control is the '''aggregate''', kept in the IPCP per
<code>(destination address, QoS cube)</code>. Every flow toward that
destination at that QoS shares one controller and one rate: a new
flow joins the aggregate at its current rate, and a departing flow
leaves the rate to the others. The pacer divides the aggregate rate
fairly across the member flows (SFQ), so per-flow fairness within an
aggregate is a scheduler property, distinct from the rate law
described here.

== Forwarder marking ==

A forwarder marks a packet as a function of the packets already queued
on the outgoing link:

mark = queued / Q (Q = 4 packets)
ecn = MAX(ecn, mark) (saturating, 8-bit field)

The quantum <code>Q</code> is a layer-wide constant: the marks it
quantizes are combined by MAX across hops, so all forwarders in a
layer MUST use the same quantum for the signal to be comparable.

Two properties:

* '''Multi-bit magnitude.''' The mark is an integer proportional to
queue depth, quantized in steps of <code>Q</code> packets: a coarse
readout of the standing queue.
* '''MAX along the path.''' A packet crossing several forwarders carries
the maximum mark, i.e. the deepest queue on its path. MAX keeps the
signal range-stable and monotone across hops.

There is a '''dead zone''': for <code>queued < Q</code> the mark is 0.

=== Capacity stamping ===

Each forwarder also measures the capacity of its outgoing link and
stamps it into the packet. The estimate is a busy-period drain rate:
the queue is observed at most once per millisecond, and a measurement
window stays open until 16 packets have drained, so its length
'''self-scales with the link rate''' — the millisecond cadence
bounds it on fast links, the 16-packet drain time on slow ones
(~19 ms at 10 Mbit/s). A window in which more than 1/8 of
the arrivals found the queue empty is discarded as unsaturated;
occasional empty observations (token-bucket shapers grazing zero) are
tolerated. The drain rate of a saturated queue is the link rate; a max
filter with slow decay (1/16 per window) converges on it from below. A
window that opened or closed on an empty queue may have drained into
buffers below at above-wire rate, so it may lower the estimate but
never raise it. The code on the wire is quarter-log2
(<code>cap8 = 4 log2 C</code>, ~19% per step, 0 = unknown) and each hop
MIN-combines its own code into the byte, so a packet arrives carrying
the bottleneck's rate. A hop that has never been backlogged stamps
nothing; since only backlogged hops matter, the signal exists exactly
when it is needed.

== 3. Receiver estimate ==

The receiver converts marks into a smoothed estimate <code>ece</code> over a
time window <code>W</code> that '''adapts to the incoming byte rate'''. It is
a '''boxcar (rectangular) time-integral mean'''. Per packet, with
<code>Δt</code> the gap since the previous packet:

A += ecn * MIN(Δt, W) dwell-weighted; one packet
weighs at most one window
B += S accumulate bytes this window
...
at window close (elapsed >= W, or B >= 2 * B_target with at
least the window floor elapsed):
ece = 32 * A / elapsed mean over the actual window
W += (B_target * elapsed / B - W) / 4 nudge toward the size
that holds the target
W = clamp(W, ~1.05 ms, ~4.3 s)
A = 0 ; B = 0 hard reset

At each close the next window is nudged by a quarter-weight moving
average toward the size that would hold about 16 packets at the
measured byte rate, from an initial ~67 ms. The target is byte-based (<code>B_target</code> = 16,000 bytes), so
"16 packets" is exact only at ~1000-byte packets, and the window
converges to it over several closes. The mean always divides by the
'''actual''' elapsed window, so a rate step leaves the current
estimate exact and only re-sizes the ''next'' window. The effect is a roughly constant sample
count — ~16 packets — from about 30 kbit/s to 122 Mbit/s;
above that the window floors at ~1 ms (a cadence still carrying
thousands of samples at 10–100 GbE), and below ~30 kbit/s it
saturates at the ~4.3 s ceiling. The averaging clock stretches with
the flow the way TCP's ACK clock stretches with the RTT. A speed-up
escapes a stretched window early: once twice the target bytes arrive
the window closes anyway (the window floor keeps that cadence bounded
at high rate). The fed-back <code>ece</code> is thus a piecewise-constant
staircase whose step period tracks the rate. Two edge cases:

* '''Onset''' (first mark after an idle estimate) emits the
instantaneous mark undiluted, so a starting queue is reported without
a full window of delay.
* '''Gap''' longer than 4 windows resets the window and emits the raw
sample. The threshold is '''rate-relative''': idle means a few
''current'' windows of silence, so a slow flow's normal inter-packet
gap never reads as idle, while the in-window dwell clamp above bounds
what a genuine pause can add to the mean before the restart fires.

Alongside the mark integral, the receiver keeps the MIN of the nonzero
capacity codes seen in the current window; each emitted <code>ece</code>
carries that minimum (the raw packet's code on onset/gap restarts) and
the fold then resets, so a reroute to a faster path can raise the
fed-back capacity within one window.

The estimate is fed back to the sender on the reverse flow.

== 4. Sender pacer ==

The sender paces with an SFQ virtual clock. The context keeps a
virtual time <code>V</code>; each flow keeps a finish tag <code>F</code>:

V += r * Δt virtual time advances by bytes served
s = MAX(F, V) a packet behind the clock starts now
F = s + S the one after it queues behind
wait = (s - V) / r time until this packet may go

The <code>wait</code> becomes the flow's scheduling deadline: a packet
already behind the virtual clock is sent immediately
(<code>wait = 0</code>); one ahead waits, deferring only its own flow.
A clock advance across an idle gap longer than 50 ms credits at most
the calling flow's owed lead plus one burst (50 ms of service, at
least one packet): a paced flow slower than one packet per 50 ms
receives its '''true''' elapsed service — a time-capped credit
would decay such a flow without bound — while an idle flow still
cannot bank an unbounded burst.

The virtual time <code>V</code> is shared by every flow in the context;
the finish tags are per flow. Because every flow computes its start
tag <code>s</code> against the same <code>V</code>, a flow that has just sent
carries a finish tag ahead of <code>V</code> and waits, while an idle flow
(finish tag at or behind <code>V</code>) starts immediately — this is
what fairly divides the aggregate rate <code>r</code> across them.

== 5. Rate control (AIMD + PD) ==

The rate law runs on packet sends, at most once per millisecond, and
also on feedback arrivals so that a sender with no traffic of its own
still reacts. Each increase term and the proportional decrease are
scaled by elapsed wall-clock time, each by its own clock: the
increase terms use time banked and '''capped''' at 50 ms (an idle gap
cannot bank an unbounded ramp), while the proportional decrease uses
the '''uncapped''' elapsed time (a starved sender still cuts by the
right amount). The one-sided derivative (Section 5.3) is a per-delta
term.

=== 5.1. Slow start ===

Before the first congestion signal the rate ramps exponentially with a
20 ms time constant:

r += r * Δt / T_ss (T_ss = 20 ms)

Slow start ends the first time a congestion signal arrives —
fed back from the receiver or observed at the sender's own first hop
— and never resumes.

Slow start belongs to the aggregate, so it runs '''once per
(destination, QoS cube)''', on the first flow. A flow arriving at an
established aggregate rides the existing estimates: it enters at the
aggregate's current rate and receives its fair share of it through
the pacer (Section 4), with no probing of its own.

=== 5.2. Increase: additive plus proportional probe (always on) ===

Past slow start, two increase terms are applied every step, both
regardless of congestion:

r += a * Δt additive; a defaults to 2^16 B/s^2
r += r * Δt / T_probe proportional; T_probe = 8 s

The additive term is a fixed per-context slope (bytes/s per second),
scaled to the path capacity (Section 5.5). The proportional probe
grows the rate by a fixed fraction per unit time (e-folds over
<code>T_probe</code>): a flow recovers in the same number of steps at any
link rate; the fixed additive term's effect vanishes relative to a
fast link. Both are the "probing"
pressure the multiplicative decrease balances at equilibrium; the
probe's cost is a rate-independent standing-queue floor (Section 7).

=== 5.3. Multiplicative decrease (proportional + derivative) ===

With congestion level <code>m</code> (the fed-back <code>ece</code>, or a local
first-hop mark as fallback), the decrease is the sum of a proportional
term and a one-sided derivative term — a PD controller on the
congestion signal:

mark = MIN(m, M) M = 512
rise = MAX(m - m_prev, 0), capped at M one-sided derivative

cut = r * rise / (4 * M) derivative, gain 1/4
cut += r * mark * Δt_ms / (1000 * M) proportional
cut = MIN(cut, r / 2) at most a halving

r -= cut
m_prev = m

* The '''proportional''' term is scaled by honest elapsed time in
milliseconds, so a starved sender that has not run the controller
for a while still cuts by the right amount.
* The '''derivative''' term (<code>rise</code>) reacts to an ''increase'' in
the congestion level between samples; it is one-sided and per-delta.
It sharpens the reaction at the onset of congestion.
* The cut is clamped to <code>r/2</code> per step, bounding the decrease to
a halving.

<code>M = 512 = 32 × 16</code> defines "full congestion" as a mean
<code>ecn</code> of 16, i.e. a mean queue of <code>16 × Q = 64</code> packets.

=== 5.4. Staleness ===

Feedback arrives once per receiver window, and the window stretches
with the flow's byte rate (Section 3) — so the staleness horizon
must stretch with it, or a slow flow's mark would age out ''between''
feedbacks and the rate would ramp against a congested path. The
sender mirrors the receiver: the horizon is four target windows of
bytes at the current rate, floored at ~268 ms so fast flows keep a
fixed horizon; at the default rate floor it is ~8 s. A signal older
than the horizon is aged out (both the fed-back estimate and the
local mark), freeing the rate to ramp once congestion clears. The
rate is clamped to
<code>[r_min, r_max]</code> on every step.

=== 5.5. Capacity-derived floor and slope ===

The fed-back capacity code sets the two rate-scale constants of the
controller, per context:

target = decode(cap8) / 32 clamped to [2^13, 2^32] B/s
r_min += (target - r_min) / 2 per feedback (moving average)
a = r_min

The defaults are fixed constants (<code>r_min = 2^13 B/s</code>,
<code>a = 2^16 B/s^2</code>), used on paths that never report a capacity;
with the estimator live the fairness floor and the post-cut recovery
slope scale with the bottleneck, and capacity engages wherever
<code>C/32</code> clears the default floor, i.e. above ~2 Mbit/s. A
capacity older than 16 staleness horizons (~4.3 s for fast flows)
reverts both to the defaults. That horizon deliberately outlives the
feedback horizon: feedback stops the moment the marks clear, which is
exactly when the recovery slope is needed; the onset-fresh capacity
(Section 3) re-seeds it on the first mark of the next episode either
way.

=== 5.6. Ramp and recovery ===

Three mechanisms set how fast an aggregate reaches a fast link's
rate, each owning one regime:

* '''From scratch: slow start.''' The exponential ramp reaches any
physical link rate in well under a second (~200 ms from the seed to
10 Gbit/s; each further doubling of link speed costs one more
~14 ms doubling time). On an uncongested path nothing marks, so
slow start runs until the aggregate arrives at its bottleneck.
* '''After a cut: the probe.''' A decrease is at most a halving per
step, and the mark ages out on the rate-relative horizon once
congestion clears (Section 5.4); the proportional probe then heals
a halving in <code>T_probe · ln 2 ≈ 5.5 s</code> at any
link rate.
* '''At the bottom: the capacity floor.''' The rate sits at most a
factor 32 below a measured bottleneck, and the additive slope
refills <code>C/32</code> per second, so the deepest hole is bounded:
floor to full capacity in tens of seconds, a halving in seconds.

These compose because a deep cut requires sustained congestion,
sustained congestion backlogs the bottleneck queue, and a backlogged
queue is exactly when its capacity is measured and stamped
(Section 2): whenever the controller is cut deep, the scaled floor is
live. The default floor only governs paths that never congested the
sender — where there is nothing to recover from. This is why
slow start can end for good: the floor and the probe cover every
later recovery.

=== 5.7. Regimes ===

<pre>
+-------------+ first mark seen +----------------+
| slow start |--------------------->| congestion |
| r *= e^(t/T)| | avoidance |
+-------------+ | |
| m == 0 -> AI |
| m > 0 -> AIPD |
+----------------+
m = fed-back ece, or the local first-hop mark when ece == 0
</pre>

== 6. RTT behaviour ==

Because every increase and decrease is scaled by wall-clock time,
two flows of different RTT that share a bottleneck obey the ''same''
rate law and converge to the ''same'' rate. The steady-state
'''allocation is RTT-independent'''.

This is a property of the equilibrium, not of the dynamics. The
feedback delay in the loop ''is'' the path RTT <code>τ</code>, and the
controller does not measure or compensate for it. At low rate the
receiver window (up to its ~4.3 s ceiling) is the dominant lag —
the loop is slow there in proportion to how slow the flow is, exactly
as a long-RTT TCP is — while as the rate rises the window shrinks
toward its ~1 ms floor, so the window's contribution to the loop delay
''falls'' with capacity and the path RTT <code>τ</code> becomes the
irreducible term. Two mechanisms keep the loop damped: the adaptive
window removes the delay-dominated corner at low <code>τ</code>, and a
bucketed '''rate-velocity damping''' (a washout: each ~31 ms bucket
pulls the rate a quarter of the way back toward its value at the
previous bucket) supplies the damping the otherwise
near-double-integrator lacks, which is what holds the loop together at
high capacity and moderate <code>τ</code>. What remains is the loop gain
<code>√G &prop; √C</code>: at very high capacity ''and'' large
<code>τ</code> the <code>√G · τ</code> phase budget is the
binding constraint, and no window or damping trick removes it (see
[[#8. Limitations|Section 8]]). A precise statement is therefore:
'''RTT-fair in equilibrium, and dynamically stable up to a
capacity-dependent RTT limit set by <code>√G · τ</code>.'''

== 7. Fairness ==

At equilibrium the two increase terms balance the proportional
decrease, <code>a + r/T_probe = r · m*/M</code>, which pins the
congestion level to <code>m* = M · (a/r + 1/T_probe)</code> and, since
<code>ece = 8q</code> (one mark unit per <code>Q = 4</code> packets, 32 fixed-point
steps per unit), a standing queue of

q* = 64 * a / r + 64 / T_probe (packets, r in bytes/s)

The additive part (<code>64 · a / r</code>) vanishes with rate under
the default slope; with the capacity-derived slope (<code>a = C/32</code>,
Section 5.5) it becomes <code>2 C / r</code> — about two packets per
competing flow, rate-independent. The proportional-probe part
(<code>64 / T_probe</code>) is a rate-independent floor (~8 packets at
8 s). That floor is the cost of rate-independent convergence, and it
keeps <code>q*</code> above the marking threshold at high rate.

Two flows at the same bottleneck see the same <code>m*</code>, so each
solves <code>r_i = a / (m*/M - 1/T_probe)</code> to the same rate. Under
the network-utility-maximization view this corresponds to
'''proportional fairness''' (equal weights), which is max-min fair at
a single bottleneck.

Measurement fidelity at low rate comes from the estimator itself:
the averaging window stretches with the flow
(Section 3), so a CA-limited flow keeps ~16 packets per window at any
rate down to ~30 kbit/s, and the rate-relative gap threshold keeps its
inter-packet spacing from reading as idle. The default floor
(<code>2^13</code> B/s) only bounds the extremes (window ceiling,
staleness horizon, pacer arithmetic). The floor scales with the
fed-back path capacity (<code>r_min = C/32</code>, Section 5.5), so
roughly 32 CA-limited flows fit above it at any link class. Flows
whose paths differ in bottleneck class derive different slopes, so
fairness across them is capacity-weighted; see
[[#8. Limitations|Section 8]].

== 9. Architectural fit ==

Each property the preceding sections build toward attaches to a
structural feature of the recursive architecture. This section makes
the mapping explicit.

* '''Congestion avoidance is fully orthogonal to ARQ and to flow
control.''' Three concerns, three mechanisms, two scopes: FRCP
provides retransmission (ARQ) and flow control (the peer pacing the
sender) end-to-end, per flow; congestion avoidance runs in the
IPCP, per aggregate. Each signal means one thing. A loss triggers
a retransmission and nothing else — a lossy link reads as
lossy, with the congestion verdict left to the marks (Section 8's
"no loss response" is this orthogonality stated from the other
side). The peer's flow-control window paces the endpoint and
nothing else — back-pressure from a slow receiver stays
distinct from congestion in the network. A retransmitted packet is
ordinary traffic to the pacer. TCP folds all three into one window
machine, where the receive window bounds the congestion window and
loss serves as both reliability trigger and congestion signal;
here each mechanism can be reasoned about, tested and evolved
alone.
* '''Congestion avoidance sits below application choice.''' Every
flow in the layer is paced by the same rate law, whatever its QoS:
a greedy raw sender shares a bottleneck fairly with a reliable
stream because the control is a property of the layer, on the
aggregate, rather than a courtesy of the endpoint transport.
* '''A layer defines its own PCI, so the signal can be rich.'''
Every member of a layer is enrolled into it: the layer is a single
administrative domain by construction, at whatever scope it spans,
and its header is layer-internal. Forwarders therefore write a
multi-bit queue magnitude and a capacity byte directly into the
packet. The datacenter schemes of
[[#10. Heritage and positioning|Section 10]] require exactly such a
domain and find it only inside one operator's fabric; a recursive
layer supplies it everywhere.
* '''Layer-internal addressing makes the aggregate well-defined.'''
Flows in a layer run between layer addresses, so the
(destination, QoS cube) aggregate — RFC 3124's macroflow
— falls out of the naming structure. Controller state scales
with destinations, and each QoS cube keeps its own loop, so
service classes keep separate fates.
* '''Flows are allocated, so feedback has a channel.''' Every flow
has state at both ends and a reverse direction; the receiver's
<code>ece</code> and the path capacity ride the flow allocator's
existing exchange.
* '''There is no transport ack clock, and none is relied on.''' The
layer must control raw flows, which carry no acknowledgements at
all, so the controller paces on wall-clock time — and that
constraint yields the RTT-independent allocation of Section 6. An
architectural restriction becomes the controller's distinguishing
property.
* '''Recursion scales the scheme.''' Each layer controls congestion
over its own scope and timescale; many N-flows ride one N-1 flow,
so aggregation compounds down the stack. The capacity a layer
measures at its egress queue is the rate the layer below actually
provides — a paced, shared lower flow rather than a nominal
wire speed — so the signal stays meaningful at every level,
and pushback cascades layer by layer.

The fit has a boundary: at a shim over legacy media the layer below
neither enrolls nor marks, which is the deployment edge behind
Section 8's no-loss-response limitation.

== 10. Heritage and positioning ==

mb-ecn is best understood as a rate-based ECN controller in the DECbit /
QCN line, adapted to an acknowledgement-less recursive layer.

The core of the scheme dates to the first Ouroboros
congestion-avoidance policy (2020): a multi-bit queue-depth mark
relayed by forwarders to the receiver, a smoothed multi-bit
<code>ece</code> fed back on the reverse flow at the same 1/32 fixed
point used today, and a sender that paced packets from a time budget
and ran slow start, additive increase and multiplicative decrease on
wall-clock time slots — rate-based and acknowledgement-free from
the start, with RTT-independent allocation already an objective. The
present algorithm keeps that skeleton and reworks every estimator
around it: per-path aggregation with SFQ pacing, the rate-adaptive
boxcar receiver, elapsed-time-scaled AIMD with a derivative term and
rate-velocity damping, and the in-band capacity signal.

* '''DECbit''' (Ramakrishnan & Jain, 1988; ToCS 1990) established
binary congestion feedback set by the switch on queue occupancy.
mb-ecn keeps the switch-sets-on-queue idea and carries a
''magnitude''.
* '''The Congestion Manager''' (Balakrishnan et al., SIGCOMM 1999;
RFC 3124, 2001) aggregates congestion state at the end host: one
controller per macroflow, a scheduler apportioning its rate across
the member streams, and new streams joining at the ensemble's
current state instead of probing from scratch. mb-ecn's
(destination, QoS cube) aggregate is the same idea placed inside
the IPCP: every layer manages its own macroflows, recursively, the
SFQ pacer plays the CM scheduler's role (Section 4), and a joining
flow rides the aggregate's estimates (Section 5.1). The CM gathers
its signal from transport feedback at the edge; mb-ecn reads it
off the wire from the forwarders.
* '''DCTCP''' (Alizadeh et al., SIGCOMM 2010) recovers a queue
magnitude at the endpoint by averaging a single threshold bit. mb-ecn
instead reads the magnitude off the wire, then time-averages it at
the receiver. The additive-increase / proportional-decrease structure
is shared.
* '''QCN''' (IEEE 802.1Qau, 2010) and '''DCQCN''' (Zhu et al., SIGCOMM
2015) contribute the rate-based (not window-based) ECN control
skeleton. mb-ecn's proportional decrease plus a probing increase
mirrors that skeleton; the increase here is wall-clock scaled rather
than byte-counter/timer based.
* '''HPCC''' (Li et al., SIGCOMM 2019) and '''PowerTCP''' (Addanki et
al., NSDI 2022) combine a queue term ''and'' a rate term (via in-band
telemetry or delay). mb-ecn now carries a coarse in-band rate (the
quarter-log2 path MIN, Section 2) but uses it only to scale the
controller's gains; the congestion ''signal'' remains queue-only,
which is still the main functional difference (Section 8).
* '''L4S / TCP Prague''' (RFC 9330–9332, 2023) make
RTT-independence a requirement and use a high-frequency single-bit
signal. mb-ecn shares the RTT-independent ''allocation'' goal but
reaches it by wall-clock-scaled rate control, with a low-frequency
multi-bit signal.

The novel combination is the multi-bit magnitude on the wire fused with
a wall-clock-scaled rate pacer in a setting with no per-flow ack clock.
The trade-off, made explicit above, is a queue-only signal and a
reactivity capped by the averaging window.

== 11. Parameters ==

These are the values every figure in this document instantiates. They
are '''coupled''': the mechanisms compose only while certain relations
hold — the gap-restart horizon at the rate floor must exceed a
packet's service time (or a floor-rate flow restart-loops at onset),
a floor-rate flow's target window must fit under the window ceiling,
the control interval must sit under the damping bucket under the idle
credit cap, the rate floor must not exceed the slow-start seed, and
the derived-floor ceiling must stay under the rate ceiling. Retune
them as a set, against those invariants.

{| class="wikitable"
! Parameter !! Value !! Meaning
|-
| Marking quantum <code>Q</code> || 4 packets || Mark onset and step; layer-wide
|-
| Feedback resolution || 1/32 <code>ecn</code> unit || Fixed-point LSB of <code>ece</code>
|-
| Full-congestion reference <code>M</code> || 512 || Mean queue of 64 packets
|-
| Receiver window target || 16 packets (16,000 bytes) || Samples per window
|-
| Initial receiver window || ~67 ms || Before rate is known
|-
| Receiver window bounds || ~1.05 ms – ~4.3 s || Clamp on <code>W</code>
|-
| Window resize weight || 1/4 || Moving average toward target
|-
| Early window close || 2 × target bytes || Speed-up escape
|-
| Gap restart || 4 windows || Idle horizon (rate-relative)
|-
| Additive slope <code>a</code> (default) || 2^16 B/s^2 || Lower clamp of derived slope
|-
| Probe time constant <code>T_probe</code> || 8 s || Rate-proportional recovery
|-
| Derivative gain || 1/4 || Onset sharpening
|-
| Rate floor <code>r_min</code> (default) || 2^13 B/s || Lower clamp of derived floor
|-
| Slow-start seed rate || 2^16 B/s || Initial rate
|-
| Slow-start time constant || 20 ms || Exponential ramp
|-
| Rate ceiling <code>r_max</code> || 2^37 B/s || Upper clamp
|-
| Capacity scale || <code>C</code> / 32 || Floor and slope from bottleneck
|-
| Capacity smoothing || 1/2 || Moving average per feedback
|-
| Capacity staleness || 16 × feedback horizon || Revert to defaults
|-
| Derived floor ceiling || 2^32 B/s || Upper clamp on derived floor
|-
| Control interval || 1 ms || Minimum spacing of rate updates
|-
| Idle credit cap || 50 ms || Burst allowance / increase banking
|-
| Feedback staleness floor || ~268 ms || Floor of rate-relative horizon
|-
| Damping bucket || ~31 ms || Rate-velocity washout cadence
|-
| Damping fraction || 1/4 || Pullback per bucket
|-
| Estimator fold spacing || 1 ms || Minimum measurement cadence
|-
| Estimator window closure || 16 packets drained || Self-scaling window
|-
| Estimator window staleness || ~134 ms || Discard across traffic gaps
|-
| Estimator idle tolerance || 1/8 of arrivals || Unsaturated-window rejection
|-
| Estimator decay || 1/16 per window || Max-filter convergence from below
|}

== 12. References ==

=== 12.1. Source ===

The implementation follows the algorithm above:

* <code>src/ipcpd/unicast/ca/mb-ecn.c</code>, <code>mb-ecn.h</code> —
receiver estimator, pacer and rate control.
* <code>src/ipcpd/unicast/ca/ops.h</code> — CA policy interface.
* <code>src/ipcpd/unicast/cap.c</code>, <code>cap.h</code> — link-capacity
estimator and quarter-log2 codec.
* <code>src/ipcpd/unicast/dt.c</code>, <code>fa.c</code> — per-hop marking
and stamping, and the feedback carrying <code>ece</code> + <code>cap8</code>.
* <code>src/ipcpd/unicast/psched.c</code> — consumes the pacing deadline.

=== 12.2. Literature ===

* K. K. Ramakrishnan, R. Jain, "A Binary Feedback Scheme for Congestion
Avoidance in Computer Networks" (DECbit), ACM ToCS, 1990.
* H. Balakrishnan, H. S. Rahul, S. Seshan, "An Integrated Congestion
Management Architecture for Internet Hosts", SIGCOMM 1999;
H. Balakrishnan, S. Seshan, "The Congestion Manager", RFC 3124, 2001.
* M. Alizadeh et al., "Data Center TCP (DCTCP)", SIGCOMM 2010.
* Y. Zhu et al., "Congestion Control for Large-Scale RDMA Deployments"
(DCQCN), SIGCOMM 2015.
* R. Mittal et al., "TIMELY: RTT-based Congestion Control", SIGCOMM 2015.
* Y. Li et al., "HPCC: High Precision Congestion Control", SIGCOMM 2019.
* V. Addanki et al., "PowerTCP", NSDI 2022.
* K. De Schepper, B. Briscoe (eds.), "Low Latency, Low Loss, and
Scalable Throughput (L4S)", RFC 9330/9331/9332.
* F. Kelly, "Charging and Rate Control for Elastic Traffic", 1997;
R. Srikant, "The Mathematics of Internet Congestion Control", 2004.

Congestion avoidance

2026-07-11T20:46:34Z

Dimitri: /* 1. Overview */

{{DISPLAYTITLE:mb-ecn - Multi-bit ECN Congestion Avoidance}}

mb-ecn is a congestion-avoidance (CA) policy for the Ouroboros unicast
IPCP. It lives in the IPC Process: the flow-and-retransmission task
(FRCP) provides reliability, in-order delivery and flow control
end-to-end; congestion avoidance is orthogonal and runs per IPCP
layer. Within a layer, the IPCP controls '''aggregates''', one loop
per (destination address, QoS cube), shared by every flow toward that
destination. The alternative policy is <code>nop</code> (no congestion
avoidance).

This document describes the algorithm: what the policy does and why.
The implementation follows it ([[#12. References|Section 12]] maps the
pieces to source files). It does not claim properties the algorithm
does not have; [[#8. Limitations|Section 8]] states the known gaps
explicitly.

The keywords "MUST", "SHOULD", "MAY" etc. are used only where they
appear in all capitals, per BCP 14 (RFC 2119, RFC 8174).

== Notation ==

;<code>r</code>
:Paced send rate, bytes per second.
;<code>C</code>
:Bottleneck capacity, bytes per second.
;<code>S</code>
:Packet size in bytes.
;<code>q</code>
:Standing queue occupancy at the bottleneck, in packets.
;<code>Q</code>
:Marking quantum, packets per mark unit (4).
;<code>ecn</code>
:Per-packet congestion mark set by a forwarder, an unsigned integer
(on-wire field is 8-bit).
;<code>ece</code>
:Receiver-side congestion estimate, fixed point with LSB = 1/32 of an
<code>ecn</code> unit, i.e. <code>ece = 32 × (time-mean ecn)</code>.
;<code>cap8</code>
:Path-capacity code carried per packet, quarter-log2:
<code>C ≈ 2^(cap8 / 4)</code> bytes/s, 0 = unknown.
;<code>W</code>
:Receiver averaging window, nanoseconds.
;<code>a</code>
:Additive-increase slope, bytes/s per second.
;<code>M</code>
:Full-congestion reference level of <code>ece</code> (512).
;<code>Δt</code>
:Elapsed wall-clock time between two events, nanoseconds.
;<code>τ</code>
:Path round-trip time (feedback delay). The controller does not
measure it.

Rate is the control variable throughout.

All concrete figures in this document — window bounds, horizons,
rate thresholds — are instances of the parameter values in
[[#11. Parameters|Section 11]]. The mechanisms and the relations
between parameters are what the algorithm fixes; retuning the
parameters moves the figures together.

__TOC__

== Overview ==

mb-ecn is a rate-based, ECN-driven controller with three moving parts,
one at each point of the loop:

<pre>
sender forwarder
+--------------------------------+ +--------------------------+
| SFQ virtual-clock pacer | | ecn = MAX(ecn, queue/Q) |
| rate r, paced per packet | data | (deepest queue wins) |
| AIMD + PD control on r |------>| cap8 = MIN(cap8, link) |
+--------------------------------+ +--------------------------+
^ |
| ece + cap8 feedback | marked data
| v
+--------------------------------+ +--------------------------+
| reads downstream ece, |<------| receiver |
| updates the rate on feedback, | ece | time-mean of ecn over |
| scales floor/slope to cap8 | cap8 | an adaptive window |
+--------------------------------+ +--------------------------+
</pre>

# The '''forwarder''' marks each packet with a ''multi-bit'' magnitude
proportional to its standing queue, and MIN-stamps its measured
outgoing-link capacity into the same PCI.
# The '''receiver''' turns the stream of marks into a time-averaged
congestion estimate <code>ece</code> and feeds it back to the sender,
together with the window minimum of the path-capacity codes.
# The '''sender''' paces its rate with a start-time fair-queuing (SFQ)
virtual clock, and adjusts that rate with additive-increase /
multiplicative-decrease (AIMD) driven by <code>ece</code>; the rate floor
and the additive slope derive from the fed-back path capacity.

The controller runs on packet sends and on feedback arrivals. All
increase/decrease steps are scaled by elapsed
wall-clock time, which is what makes the ''allocation'' independent of
RTT (see [[#6. RTT behaviour|Section 6]]).

The unit of control is the '''aggregate''', kept in the IPCP per
<code>(destination address, QoS cube)</code>. Every flow toward that
destination at that QoS shares one controller and one rate: a new
flow joins the aggregate at its current rate, and a departing flow
leaves the rate to the others. The pacer divides the aggregate rate
fairly across the member flows (SFQ), so per-flow fairness within an
aggregate is a scheduler property, distinct from the rate law
described here.

== 2. Forwarder marking ==

A forwarder marks a packet as a function of the packets already queued
on the outgoing link:

mark = queued / Q (Q = 4 packets)
ecn = MAX(ecn, mark) (saturating, 8-bit field)

The quantum <code>Q</code> is a layer-wide constant: the marks it
quantizes are combined by MAX across hops, so all forwarders in a
layer MUST use the same quantum for the signal to be comparable.

Two properties:

* '''Multi-bit magnitude.''' The mark is an integer proportional to
queue depth, quantized in steps of <code>Q</code> packets: a coarse
readout of the standing queue.
* '''MAX along the path.''' A packet crossing several forwarders carries
the maximum mark, i.e. the deepest queue on its path. MAX keeps the
signal range-stable and monotone across hops.

There is a '''dead zone''': for <code>queued < Q</code> the mark is 0.

=== Capacity stamping ===

Each forwarder also measures the capacity of its outgoing link and
stamps it into the packet. The estimate is a busy-period drain rate:
the queue is observed at most once per millisecond, and a measurement
window stays open until 16 packets have drained, so its length
'''self-scales with the link rate''' — the millisecond cadence
bounds it on fast links, the 16-packet drain time on slow ones
(~19 ms at 10 Mbit/s). A window in which more than 1/8 of
the arrivals found the queue empty is discarded as unsaturated;
occasional empty observations (token-bucket shapers grazing zero) are
tolerated. The drain rate of a saturated queue is the link rate; a max
filter with slow decay (1/16 per window) converges on it from below. A
window that opened or closed on an empty queue may have drained into
buffers below at above-wire rate, so it may lower the estimate but
never raise it. The code on the wire is quarter-log2
(<code>cap8 = 4 log2 C</code>, ~19% per step, 0 = unknown) and each hop
MIN-combines its own code into the byte, so a packet arrives carrying
the bottleneck's rate. A hop that has never been backlogged stamps
nothing; since only backlogged hops matter, the signal exists exactly
when it is needed.

== 3. Receiver estimate ==

The receiver converts marks into a smoothed estimate <code>ece</code> over a
time window <code>W</code> that '''adapts to the incoming byte rate'''. It is
a '''boxcar (rectangular) time-integral mean'''. Per packet, with
<code>Δt</code> the gap since the previous packet:

A += ecn * MIN(Δt, W) dwell-weighted; one packet
weighs at most one window
B += S accumulate bytes this window
...
at window close (elapsed >= W, or B >= 2 * B_target with at
least the window floor elapsed):
ece = 32 * A / elapsed mean over the actual window
W += (B_target * elapsed / B - W) / 4 nudge toward the size
that holds the target
W = clamp(W, ~1.05 ms, ~4.3 s)
A = 0 ; B = 0 hard reset

At each close the next window is nudged by a quarter-weight moving
average toward the size that would hold about 16 packets at the
measured byte rate, from an initial ~67 ms. The target is byte-based (<code>B_target</code> = 16,000 bytes), so
"16 packets" is exact only at ~1000-byte packets, and the window
converges to it over several closes. The mean always divides by the
'''actual''' elapsed window, so a rate step leaves the current
estimate exact and only re-sizes the ''next'' window. The effect is a roughly constant sample
count — ~16 packets — from about 30 kbit/s to 122 Mbit/s;
above that the window floors at ~1 ms (a cadence still carrying
thousands of samples at 10–100 GbE), and below ~30 kbit/s it
saturates at the ~4.3 s ceiling. The averaging clock stretches with
the flow the way TCP's ACK clock stretches with the RTT. A speed-up
escapes a stretched window early: once twice the target bytes arrive
the window closes anyway (the window floor keeps that cadence bounded
at high rate). The fed-back <code>ece</code> is thus a piecewise-constant
staircase whose step period tracks the rate. Two edge cases:

* '''Onset''' (first mark after an idle estimate) emits the
instantaneous mark undiluted, so a starting queue is reported without
a full window of delay.
* '''Gap''' longer than 4 windows resets the window and emits the raw
sample. The threshold is '''rate-relative''': idle means a few
''current'' windows of silence, so a slow flow's normal inter-packet
gap never reads as idle, while the in-window dwell clamp above bounds
what a genuine pause can add to the mean before the restart fires.

Alongside the mark integral, the receiver keeps the MIN of the nonzero
capacity codes seen in the current window; each emitted <code>ece</code>
carries that minimum (the raw packet's code on onset/gap restarts) and
the fold then resets, so a reroute to a faster path can raise the
fed-back capacity within one window.

The estimate is fed back to the sender on the reverse flow.

== 4. Sender pacer ==

The sender paces with an SFQ virtual clock. The context keeps a
virtual time <code>V</code>; each flow keeps a finish tag <code>F</code>:

V += r * Δt virtual time advances by bytes served
s = MAX(F, V) a packet behind the clock starts now
F = s + S the one after it queues behind
wait = (s - V) / r time until this packet may go

The <code>wait</code> becomes the flow's scheduling deadline: a packet
already behind the virtual clock is sent immediately
(<code>wait = 0</code>); one ahead waits, deferring only its own flow.
A clock advance across an idle gap longer than 50 ms credits at most
the calling flow's owed lead plus one burst (50 ms of service, at
least one packet): a paced flow slower than one packet per 50 ms
receives its '''true''' elapsed service — a time-capped credit
would decay such a flow without bound — while an idle flow still
cannot bank an unbounded burst.

The virtual time <code>V</code> is shared by every flow in the context;
the finish tags are per flow. Because every flow computes its start
tag <code>s</code> against the same <code>V</code>, a flow that has just sent
carries a finish tag ahead of <code>V</code> and waits, while an idle flow
(finish tag at or behind <code>V</code>) starts immediately — this is
what fairly divides the aggregate rate <code>r</code> across them.

== 5. Rate control (AIMD + PD) ==

The rate law runs on packet sends, at most once per millisecond, and
also on feedback arrivals so that a sender with no traffic of its own
still reacts. Each increase term and the proportional decrease are
scaled by elapsed wall-clock time, each by its own clock: the
increase terms use time banked and '''capped''' at 50 ms (an idle gap
cannot bank an unbounded ramp), while the proportional decrease uses
the '''uncapped''' elapsed time (a starved sender still cuts by the
right amount). The one-sided derivative (Section 5.3) is a per-delta
term.

=== 5.1. Slow start ===

Before the first congestion signal the rate ramps exponentially with a
20 ms time constant:

r += r * Δt / T_ss (T_ss = 20 ms)

Slow start ends the first time a congestion signal arrives —
fed back from the receiver or observed at the sender's own first hop
— and never resumes.

Slow start belongs to the aggregate, so it runs '''once per
(destination, QoS cube)''', on the first flow. A flow arriving at an
established aggregate rides the existing estimates: it enters at the
aggregate's current rate and receives its fair share of it through
the pacer (Section 4), with no probing of its own.

=== 5.2. Increase: additive plus proportional probe (always on) ===

Past slow start, two increase terms are applied every step, both
regardless of congestion:

r += a * Δt additive; a defaults to 2^16 B/s^2
r += r * Δt / T_probe proportional; T_probe = 8 s

The additive term is a fixed per-context slope (bytes/s per second),
scaled to the path capacity (Section 5.5). The proportional probe
grows the rate by a fixed fraction per unit time (e-folds over
<code>T_probe</code>): a flow recovers in the same number of steps at any
link rate; the fixed additive term's effect vanishes relative to a
fast link. Both are the "probing"
pressure the multiplicative decrease balances at equilibrium; the
probe's cost is a rate-independent standing-queue floor (Section 7).

=== 5.3. Multiplicative decrease (proportional + derivative) ===

With congestion level <code>m</code> (the fed-back <code>ece</code>, or a local
first-hop mark as fallback), the decrease is the sum of a proportional
term and a one-sided derivative term — a PD controller on the
congestion signal:

mark = MIN(m, M) M = 512
rise = MAX(m - m_prev, 0), capped at M one-sided derivative

cut = r * rise / (4 * M) derivative, gain 1/4
cut += r * mark * Δt_ms / (1000 * M) proportional
cut = MIN(cut, r / 2) at most a halving

r -= cut
m_prev = m

* The '''proportional''' term is scaled by honest elapsed time in
milliseconds, so a starved sender that has not run the controller
for a while still cuts by the right amount.
* The '''derivative''' term (<code>rise</code>) reacts to an ''increase'' in
the congestion level between samples; it is one-sided and per-delta.
It sharpens the reaction at the onset of congestion.
* The cut is clamped to <code>r/2</code> per step, bounding the decrease to
a halving.

<code>M = 512 = 32 × 16</code> defines "full congestion" as a mean
<code>ecn</code> of 16, i.e. a mean queue of <code>16 × Q = 64</code> packets.

=== 5.4. Staleness ===

Feedback arrives once per receiver window, and the window stretches
with the flow's byte rate (Section 3) — so the staleness horizon
must stretch with it, or a slow flow's mark would age out ''between''
feedbacks and the rate would ramp against a congested path. The
sender mirrors the receiver: the horizon is four target windows of
bytes at the current rate, floored at ~268 ms so fast flows keep a
fixed horizon; at the default rate floor it is ~8 s. A signal older
than the horizon is aged out (both the fed-back estimate and the
local mark), freeing the rate to ramp once congestion clears. The
rate is clamped to
<code>[r_min, r_max]</code> on every step.

=== 5.5. Capacity-derived floor and slope ===

The fed-back capacity code sets the two rate-scale constants of the
controller, per context:

target = decode(cap8) / 32 clamped to [2^13, 2^32] B/s
r_min += (target - r_min) / 2 per feedback (moving average)
a = r_min

The defaults are fixed constants (<code>r_min = 2^13 B/s</code>,
<code>a = 2^16 B/s^2</code>), used on paths that never report a capacity;
with the estimator live the fairness floor and the post-cut recovery
slope scale with the bottleneck, and capacity engages wherever
<code>C/32</code> clears the default floor, i.e. above ~2 Mbit/s. A
capacity older than 16 staleness horizons (~4.3 s for fast flows)
reverts both to the defaults. That horizon deliberately outlives the
feedback horizon: feedback stops the moment the marks clear, which is
exactly when the recovery slope is needed; the onset-fresh capacity
(Section 3) re-seeds it on the first mark of the next episode either
way.

=== 5.6. Ramp and recovery ===

Three mechanisms set how fast an aggregate reaches a fast link's
rate, each owning one regime:

* '''From scratch: slow start.''' The exponential ramp reaches any
physical link rate in well under a second (~200 ms from the seed to
10 Gbit/s; each further doubling of link speed costs one more
~14 ms doubling time). On an uncongested path nothing marks, so
slow start runs until the aggregate arrives at its bottleneck.
* '''After a cut: the probe.''' A decrease is at most a halving per
step, and the mark ages out on the rate-relative horizon once
congestion clears (Section 5.4); the proportional probe then heals
a halving in <code>T_probe · ln 2 ≈ 5.5 s</code> at any
link rate.
* '''At the bottom: the capacity floor.''' The rate sits at most a
factor 32 below a measured bottleneck, and the additive slope
refills <code>C/32</code> per second, so the deepest hole is bounded:
floor to full capacity in tens of seconds, a halving in seconds.

These compose because a deep cut requires sustained congestion,
sustained congestion backlogs the bottleneck queue, and a backlogged
queue is exactly when its capacity is measured and stamped
(Section 2): whenever the controller is cut deep, the scaled floor is
live. The default floor only governs paths that never congested the
sender — where there is nothing to recover from. This is why
slow start can end for good: the floor and the probe cover every
later recovery.

=== 5.7. Regimes ===

<pre>
+-------------+ first mark seen +----------------+
| slow start |--------------------->| congestion |
| r *= e^(t/T)| | avoidance |
+-------------+ | |
| m == 0 -> AI |
| m > 0 -> AIPD |
+----------------+
m = fed-back ece, or the local first-hop mark when ece == 0
</pre>

== 6. RTT behaviour ==

Because every increase and decrease is scaled by wall-clock time,
two flows of different RTT that share a bottleneck obey the ''same''
rate law and converge to the ''same'' rate. The steady-state
'''allocation is RTT-independent'''.

This is a property of the equilibrium, not of the dynamics. The
feedback delay in the loop ''is'' the path RTT <code>τ</code>, and the
controller does not measure or compensate for it. At low rate the
receiver window (up to its ~4.3 s ceiling) is the dominant lag —
the loop is slow there in proportion to how slow the flow is, exactly
as a long-RTT TCP is — while as the rate rises the window shrinks
toward its ~1 ms floor, so the window's contribution to the loop delay
''falls'' with capacity and the path RTT <code>τ</code> becomes the
irreducible term. Two mechanisms keep the loop damped: the adaptive
window removes the delay-dominated corner at low <code>τ</code>, and a
bucketed '''rate-velocity damping''' (a washout: each ~31 ms bucket
pulls the rate a quarter of the way back toward its value at the
previous bucket) supplies the damping the otherwise
near-double-integrator lacks, which is what holds the loop together at
high capacity and moderate <code>τ</code>. What remains is the loop gain
<code>√G &prop; √C</code>: at very high capacity ''and'' large
<code>τ</code> the <code>√G · τ</code> phase budget is the
binding constraint, and no window or damping trick removes it (see
[[#8. Limitations|Section 8]]). A precise statement is therefore:
'''RTT-fair in equilibrium, and dynamically stable up to a
capacity-dependent RTT limit set by <code>√G · τ</code>.'''

== 7. Fairness ==

At equilibrium the two increase terms balance the proportional
decrease, <code>a + r/T_probe = r · m*/M</code>, which pins the
congestion level to <code>m* = M · (a/r + 1/T_probe)</code> and, since
<code>ece = 8q</code> (one mark unit per <code>Q = 4</code> packets, 32 fixed-point
steps per unit), a standing queue of

q* = 64 * a / r + 64 / T_probe (packets, r in bytes/s)

The additive part (<code>64 · a / r</code>) vanishes with rate under
the default slope; with the capacity-derived slope (<code>a = C/32</code>,
Section 5.5) it becomes <code>2 C / r</code> — about two packets per
competing flow, rate-independent. The proportional-probe part
(<code>64 / T_probe</code>) is a rate-independent floor (~8 packets at
8 s). That floor is the cost of rate-independent convergence, and it
keeps <code>q*</code> above the marking threshold at high rate.

Two flows at the same bottleneck see the same <code>m*</code>, so each
solves <code>r_i = a / (m*/M - 1/T_probe)</code> to the same rate. Under
the network-utility-maximization view this corresponds to
'''proportional fairness''' (equal weights), which is max-min fair at
a single bottleneck.

Measurement fidelity at low rate comes from the estimator itself:
the averaging window stretches with the flow
(Section 3), so a CA-limited flow keeps ~16 packets per window at any
rate down to ~30 kbit/s, and the rate-relative gap threshold keeps its
inter-packet spacing from reading as idle. The default floor
(<code>2^13</code> B/s) only bounds the extremes (window ceiling,
staleness horizon, pacer arithmetic). The floor scales with the
fed-back path capacity (<code>r_min = C/32</code>, Section 5.5), so
roughly 32 CA-limited flows fit above it at any link class. Flows
whose paths differ in bottleneck class derive different slopes, so
fairness across them is capacity-weighted; see
[[#8. Limitations|Section 8]].

== 9. Architectural fit ==

Each property the preceding sections build toward attaches to a
structural feature of the recursive architecture. This section makes
the mapping explicit.

* '''Congestion avoidance is fully orthogonal to ARQ and to flow
control.''' Three concerns, three mechanisms, two scopes: FRCP
provides retransmission (ARQ) and flow control (the peer pacing the
sender) end-to-end, per flow; congestion avoidance runs in the
IPCP, per aggregate. Each signal means one thing. A loss triggers
a retransmission and nothing else — a lossy link reads as
lossy, with the congestion verdict left to the marks (Section 8's
"no loss response" is this orthogonality stated from the other
side). The peer's flow-control window paces the endpoint and
nothing else — back-pressure from a slow receiver stays
distinct from congestion in the network. A retransmitted packet is
ordinary traffic to the pacer. TCP folds all three into one window
machine, where the receive window bounds the congestion window and
loss serves as both reliability trigger and congestion signal;
here each mechanism can be reasoned about, tested and evolved
alone.
* '''Congestion avoidance sits below application choice.''' Every
flow in the layer is paced by the same rate law, whatever its QoS:
a greedy raw sender shares a bottleneck fairly with a reliable
stream because the control is a property of the layer, on the
aggregate, rather than a courtesy of the endpoint transport.
* '''A layer defines its own PCI, so the signal can be rich.'''
Every member of a layer is enrolled into it: the layer is a single
administrative domain by construction, at whatever scope it spans,
and its header is layer-internal. Forwarders therefore write a
multi-bit queue magnitude and a capacity byte directly into the
packet. The datacenter schemes of
[[#10. Heritage and positioning|Section 10]] require exactly such a
domain and find it only inside one operator's fabric; a recursive
layer supplies it everywhere.
* '''Layer-internal addressing makes the aggregate well-defined.'''
Flows in a layer run between layer addresses, so the
(destination, QoS cube) aggregate — RFC 3124's macroflow
— falls out of the naming structure. Controller state scales
with destinations, and each QoS cube keeps its own loop, so
service classes keep separate fates.
* '''Flows are allocated, so feedback has a channel.''' Every flow
has state at both ends and a reverse direction; the receiver's
<code>ece</code> and the path capacity ride the flow allocator's
existing exchange.
* '''There is no transport ack clock, and none is relied on.''' The
layer must control raw flows, which carry no acknowledgements at
all, so the controller paces on wall-clock time — and that
constraint yields the RTT-independent allocation of Section 6. An
architectural restriction becomes the controller's distinguishing
property.
* '''Recursion scales the scheme.''' Each layer controls congestion
over its own scope and timescale; many N-flows ride one N-1 flow,
so aggregation compounds down the stack. The capacity a layer
measures at its egress queue is the rate the layer below actually
provides — a paced, shared lower flow rather than a nominal
wire speed — so the signal stays meaningful at every level,
and pushback cascades layer by layer.

The fit has a boundary: at a shim over legacy media the layer below
neither enrolls nor marks, which is the deployment edge behind
Section 8's no-loss-response limitation.

== 10. Heritage and positioning ==

mb-ecn is best understood as a rate-based ECN controller in the DECbit /
QCN line, adapted to an acknowledgement-less recursive layer.

The core of the scheme dates to the first Ouroboros
congestion-avoidance policy (2020): a multi-bit queue-depth mark
relayed by forwarders to the receiver, a smoothed multi-bit
<code>ece</code> fed back on the reverse flow at the same 1/32 fixed
point used today, and a sender that paced packets from a time budget
and ran slow start, additive increase and multiplicative decrease on
wall-clock time slots — rate-based and acknowledgement-free from
the start, with RTT-independent allocation already an objective. The
present algorithm keeps that skeleton and reworks every estimator
around it: per-path aggregation with SFQ pacing, the rate-adaptive
boxcar receiver, elapsed-time-scaled AIMD with a derivative term and
rate-velocity damping, and the in-band capacity signal.

* '''DECbit''' (Ramakrishnan & Jain, 1988; ToCS 1990) established
binary congestion feedback set by the switch on queue occupancy.
mb-ecn keeps the switch-sets-on-queue idea and carries a
''magnitude''.
* '''The Congestion Manager''' (Balakrishnan et al., SIGCOMM 1999;
RFC 3124, 2001) aggregates congestion state at the end host: one
controller per macroflow, a scheduler apportioning its rate across
the member streams, and new streams joining at the ensemble's
current state instead of probing from scratch. mb-ecn's
(destination, QoS cube) aggregate is the same idea placed inside
the IPCP: every layer manages its own macroflows, recursively, the
SFQ pacer plays the CM scheduler's role (Section 4), and a joining
flow rides the aggregate's estimates (Section 5.1). The CM gathers
its signal from transport feedback at the edge; mb-ecn reads it
off the wire from the forwarders.
* '''DCTCP''' (Alizadeh et al., SIGCOMM 2010) recovers a queue
magnitude at the endpoint by averaging a single threshold bit. mb-ecn
instead reads the magnitude off the wire, then time-averages it at
the receiver. The additive-increase / proportional-decrease structure
is shared.
* '''QCN''' (IEEE 802.1Qau, 2010) and '''DCQCN''' (Zhu et al., SIGCOMM
2015) contribute the rate-based (not window-based) ECN control
skeleton. mb-ecn's proportional decrease plus a probing increase
mirrors that skeleton; the increase here is wall-clock scaled rather
than byte-counter/timer based.
* '''HPCC''' (Li et al., SIGCOMM 2019) and '''PowerTCP''' (Addanki et
al., NSDI 2022) combine a queue term ''and'' a rate term (via in-band
telemetry or delay). mb-ecn now carries a coarse in-band rate (the
quarter-log2 path MIN, Section 2) but uses it only to scale the
controller's gains; the congestion ''signal'' remains queue-only,
which is still the main functional difference (Section 8).
* '''L4S / TCP Prague''' (RFC 9330–9332, 2023) make
RTT-independence a requirement and use a high-frequency single-bit
signal. mb-ecn shares the RTT-independent ''allocation'' goal but
reaches it by wall-clock-scaled rate control, with a low-frequency
multi-bit signal.

The novel combination is the multi-bit magnitude on the wire fused with
a wall-clock-scaled rate pacer in a setting with no per-flow ack clock.
The trade-off, made explicit above, is a queue-only signal and a
reactivity capped by the averaging window.

== 11. Parameters ==

These are the values every figure in this document instantiates. They
are '''coupled''': the mechanisms compose only while certain relations
hold — the gap-restart horizon at the rate floor must exceed a
packet's service time (or a floor-rate flow restart-loops at onset),
a floor-rate flow's target window must fit under the window ceiling,
the control interval must sit under the damping bucket under the idle
credit cap, the rate floor must not exceed the slow-start seed, and
the derived-floor ceiling must stay under the rate ceiling. Retune
them as a set, against those invariants.

{| class="wikitable"
! Parameter !! Value !! Meaning
|-
| Marking quantum <code>Q</code> || 4 packets || Mark onset and step; layer-wide
|-
| Feedback resolution || 1/32 <code>ecn</code> unit || Fixed-point LSB of <code>ece</code>
|-
| Full-congestion reference <code>M</code> || 512 || Mean queue of 64 packets
|-
| Receiver window target || 16 packets (16,000 bytes) || Samples per window
|-
| Initial receiver window || ~67 ms || Before rate is known
|-
| Receiver window bounds || ~1.05 ms – ~4.3 s || Clamp on <code>W</code>
|-
| Window resize weight || 1/4 || Moving average toward target
|-
| Early window close || 2 × target bytes || Speed-up escape
|-
| Gap restart || 4 windows || Idle horizon (rate-relative)
|-
| Additive slope <code>a</code> (default) || 2^16 B/s^2 || Lower clamp of derived slope
|-
| Probe time constant <code>T_probe</code> || 8 s || Rate-proportional recovery
|-
| Derivative gain || 1/4 || Onset sharpening
|-
| Rate floor <code>r_min</code> (default) || 2^13 B/s || Lower clamp of derived floor
|-
| Slow-start seed rate || 2^16 B/s || Initial rate
|-
| Slow-start time constant || 20 ms || Exponential ramp
|-
| Rate ceiling <code>r_max</code> || 2^37 B/s || Upper clamp
|-
| Capacity scale || <code>C</code> / 32 || Floor and slope from bottleneck
|-
| Capacity smoothing || 1/2 || Moving average per feedback
|-
| Capacity staleness || 16 × feedback horizon || Revert to defaults
|-
| Derived floor ceiling || 2^32 B/s || Upper clamp on derived floor
|-
| Control interval || 1 ms || Minimum spacing of rate updates
|-
| Idle credit cap || 50 ms || Burst allowance / increase banking
|-
| Feedback staleness floor || ~268 ms || Floor of rate-relative horizon
|-
| Damping bucket || ~31 ms || Rate-velocity washout cadence
|-
| Damping fraction || 1/4 || Pullback per bucket
|-
| Estimator fold spacing || 1 ms || Minimum measurement cadence
|-
| Estimator window closure || 16 packets drained || Self-scaling window
|-
| Estimator window staleness || ~134 ms || Discard across traffic gaps
|-
| Estimator idle tolerance || 1/8 of arrivals || Unsaturated-window rejection
|-
| Estimator decay || 1/16 per window || Max-filter convergence from below
|}

== 12. References ==

=== 12.1. Source ===

The implementation follows the algorithm above:

* <code>src/ipcpd/unicast/ca/mb-ecn.c</code>, <code>mb-ecn.h</code> —
receiver estimator, pacer and rate control.
* <code>src/ipcpd/unicast/ca/ops.h</code> — CA policy interface.
* <code>src/ipcpd/unicast/cap.c</code>, <code>cap.h</code> — link-capacity
estimator and quarter-log2 codec.
* <code>src/ipcpd/unicast/dt.c</code>, <code>fa.c</code> — per-hop marking
and stamping, and the feedback carrying <code>ece</code> + <code>cap8</code>.
* <code>src/ipcpd/unicast/psched.c</code> — consumes the pacing deadline.

=== 12.2. Literature ===

* K. K. Ramakrishnan, R. Jain, "A Binary Feedback Scheme for Congestion
Avoidance in Computer Networks" (DECbit), ACM ToCS, 1990.
* H. Balakrishnan, H. S. Rahul, S. Seshan, "An Integrated Congestion
Management Architecture for Internet Hosts", SIGCOMM 1999;
H. Balakrishnan, S. Seshan, "The Congestion Manager", RFC 3124, 2001.
* M. Alizadeh et al., "Data Center TCP (DCTCP)", SIGCOMM 2010.
* Y. Zhu et al., "Congestion Control for Large-Scale RDMA Deployments"
(DCQCN), SIGCOMM 2015.
* R. Mittal et al., "TIMELY: RTT-based Congestion Control", SIGCOMM 2015.
* Y. Li et al., "HPCC: High Precision Congestion Control", SIGCOMM 2019.
* V. Addanki et al., "PowerTCP", NSDI 2022.
* K. De Schepper, B. Briscoe (eds.), "Low Latency, Low Loss, and
Scalable Throughput (L4S)", RFC 9330/9331/9332.
* F. Kelly, "Charging and Rate Control for Elastic Traffic", 1997;
R. Srikant, "The Mathematics of Internet Congestion Control", 2004.

Congestion avoidance

2026-07-11T20:46:20Z

Dimitri: /* 8. Limitations */

{{DISPLAYTITLE:mb-ecn - Multi-bit ECN Congestion Avoidance}}

mb-ecn is a congestion-avoidance (CA) policy for the Ouroboros unicast
IPCP. It lives in the IPC Process: the flow-and-retransmission task
(FRCP) provides reliability, in-order delivery and flow control
end-to-end; congestion avoidance is orthogonal and runs per IPCP
layer. Within a layer, the IPCP controls '''aggregates''', one loop
per (destination address, QoS cube), shared by every flow toward that
destination. The alternative policy is <code>nop</code> (no congestion
avoidance).

This document describes the algorithm: what the policy does and why.
The implementation follows it ([[#12. References|Section 12]] maps the
pieces to source files). It does not claim properties the algorithm
does not have; [[#8. Limitations|Section 8]] states the known gaps
explicitly.

The keywords "MUST", "SHOULD", "MAY" etc. are used only where they
appear in all capitals, per BCP 14 (RFC 2119, RFC 8174).

== Notation ==

;<code>r</code>
:Paced send rate, bytes per second.
;<code>C</code>
:Bottleneck capacity, bytes per second.
;<code>S</code>
:Packet size in bytes.
;<code>q</code>
:Standing queue occupancy at the bottleneck, in packets.
;<code>Q</code>
:Marking quantum, packets per mark unit (4).
;<code>ecn</code>
:Per-packet congestion mark set by a forwarder, an unsigned integer
(on-wire field is 8-bit).
;<code>ece</code>
:Receiver-side congestion estimate, fixed point with LSB = 1/32 of an
<code>ecn</code> unit, i.e. <code>ece = 32 × (time-mean ecn)</code>.
;<code>cap8</code>
:Path-capacity code carried per packet, quarter-log2:
<code>C ≈ 2^(cap8 / 4)</code> bytes/s, 0 = unknown.
;<code>W</code>
:Receiver averaging window, nanoseconds.
;<code>a</code>
:Additive-increase slope, bytes/s per second.
;<code>M</code>
:Full-congestion reference level of <code>ece</code> (512).
;<code>Δt</code>
:Elapsed wall-clock time between two events, nanoseconds.
;<code>τ</code>
:Path round-trip time (feedback delay). The controller does not
measure it.

Rate is the control variable throughout.

All concrete figures in this document — window bounds, horizons,
rate thresholds — are instances of the parameter values in
[[#11. Parameters|Section 11]]. The mechanisms and the relations
between parameters are what the algorithm fixes; retuning the
parameters moves the figures together.

__TOC__

== 1. Overview ==

mb-ecn is a rate-based, ECN-driven controller with three moving parts,
one at each point of the loop:

<pre>
sender forwarder
+--------------------------------+ +--------------------------+
| SFQ virtual-clock pacer | | ecn = MAX(ecn, queue/Q) |
| rate r, paced per packet | data | (deepest queue wins) |
| AIMD + PD control on r |------>| cap8 = MIN(cap8, link) |
+--------------------------------+ +--------------------------+
^ |
| ece + cap8 feedback | marked data
| v
+--------------------------------+ +--------------------------+
| reads downstream ece, |<------| receiver |
| updates the rate on feedback, | ece | time-mean of ecn over |
| scales floor/slope to cap8 | cap8 | an adaptive window |
+--------------------------------+ +--------------------------+
</pre>

# The '''forwarder''' marks each packet with a ''multi-bit'' magnitude
proportional to its standing queue, and MIN-stamps its measured
outgoing-link capacity into the same PCI.
# The '''receiver''' turns the stream of marks into a time-averaged
congestion estimate <code>ece</code> and feeds it back to the sender,
together with the window minimum of the path-capacity codes.
# The '''sender''' paces its rate with a start-time fair-queuing (SFQ)
virtual clock, and adjusts that rate with additive-increase /
multiplicative-decrease (AIMD) driven by <code>ece</code>; the rate floor
and the additive slope derive from the fed-back path capacity.

The controller runs on packet sends and on feedback arrivals. All
increase/decrease steps are scaled by elapsed
wall-clock time, which is what makes the ''allocation'' independent of
RTT (see [[#6. RTT behaviour|Section 6]]).

The unit of control is the '''aggregate''', kept in the IPCP per
<code>(destination address, QoS cube)</code>. Every flow toward that
destination at that QoS shares one controller and one rate: a new
flow joins the aggregate at its current rate, and a departing flow
leaves the rate to the others. The pacer divides the aggregate rate
fairly across the member flows (SFQ), so per-flow fairness within an
aggregate is a scheduler property, distinct from the rate law
described here.

== 2. Forwarder marking ==

A forwarder marks a packet as a function of the packets already queued
on the outgoing link:

mark = queued / Q (Q = 4 packets)
ecn = MAX(ecn, mark) (saturating, 8-bit field)

The quantum <code>Q</code> is a layer-wide constant: the marks it
quantizes are combined by MAX across hops, so all forwarders in a
layer MUST use the same quantum for the signal to be comparable.

Two properties:

* '''Multi-bit magnitude.''' The mark is an integer proportional to
queue depth, quantized in steps of <code>Q</code> packets: a coarse
readout of the standing queue.
* '''MAX along the path.''' A packet crossing several forwarders carries
the maximum mark, i.e. the deepest queue on its path. MAX keeps the
signal range-stable and monotone across hops.

There is a '''dead zone''': for <code>queued < Q</code> the mark is 0.

=== Capacity stamping ===

Each forwarder also measures the capacity of its outgoing link and
stamps it into the packet. The estimate is a busy-period drain rate:
the queue is observed at most once per millisecond, and a measurement
window stays open until 16 packets have drained, so its length
'''self-scales with the link rate''' — the millisecond cadence
bounds it on fast links, the 16-packet drain time on slow ones
(~19 ms at 10 Mbit/s). A window in which more than 1/8 of
the arrivals found the queue empty is discarded as unsaturated;
occasional empty observations (token-bucket shapers grazing zero) are
tolerated. The drain rate of a saturated queue is the link rate; a max
filter with slow decay (1/16 per window) converges on it from below. A
window that opened or closed on an empty queue may have drained into
buffers below at above-wire rate, so it may lower the estimate but
never raise it. The code on the wire is quarter-log2
(<code>cap8 = 4 log2 C</code>, ~19% per step, 0 = unknown) and each hop
MIN-combines its own code into the byte, so a packet arrives carrying
the bottleneck's rate. A hop that has never been backlogged stamps
nothing; since only backlogged hops matter, the signal exists exactly
when it is needed.

== 3. Receiver estimate ==

The receiver converts marks into a smoothed estimate <code>ece</code> over a
time window <code>W</code> that '''adapts to the incoming byte rate'''. It is
a '''boxcar (rectangular) time-integral mean'''. Per packet, with
<code>Δt</code> the gap since the previous packet:

A += ecn * MIN(Δt, W) dwell-weighted; one packet
weighs at most one window
B += S accumulate bytes this window
...
at window close (elapsed >= W, or B >= 2 * B_target with at
least the window floor elapsed):
ece = 32 * A / elapsed mean over the actual window
W += (B_target * elapsed / B - W) / 4 nudge toward the size
that holds the target
W = clamp(W, ~1.05 ms, ~4.3 s)
A = 0 ; B = 0 hard reset

At each close the next window is nudged by a quarter-weight moving
average toward the size that would hold about 16 packets at the
measured byte rate, from an initial ~67 ms. The target is byte-based (<code>B_target</code> = 16,000 bytes), so
"16 packets" is exact only at ~1000-byte packets, and the window
converges to it over several closes. The mean always divides by the
'''actual''' elapsed window, so a rate step leaves the current
estimate exact and only re-sizes the ''next'' window. The effect is a roughly constant sample
count — ~16 packets — from about 30 kbit/s to 122 Mbit/s;
above that the window floors at ~1 ms (a cadence still carrying
thousands of samples at 10–100 GbE), and below ~30 kbit/s it
saturates at the ~4.3 s ceiling. The averaging clock stretches with
the flow the way TCP's ACK clock stretches with the RTT. A speed-up
escapes a stretched window early: once twice the target bytes arrive
the window closes anyway (the window floor keeps that cadence bounded
at high rate). The fed-back <code>ece</code> is thus a piecewise-constant
staircase whose step period tracks the rate. Two edge cases:

* '''Onset''' (first mark after an idle estimate) emits the
instantaneous mark undiluted, so a starting queue is reported without
a full window of delay.
* '''Gap''' longer than 4 windows resets the window and emits the raw
sample. The threshold is '''rate-relative''': idle means a few
''current'' windows of silence, so a slow flow's normal inter-packet
gap never reads as idle, while the in-window dwell clamp above bounds
what a genuine pause can add to the mean before the restart fires.

Alongside the mark integral, the receiver keeps the MIN of the nonzero
capacity codes seen in the current window; each emitted <code>ece</code>
carries that minimum (the raw packet's code on onset/gap restarts) and
the fold then resets, so a reroute to a faster path can raise the
fed-back capacity within one window.

The estimate is fed back to the sender on the reverse flow.

== 4. Sender pacer ==

The sender paces with an SFQ virtual clock. The context keeps a
virtual time <code>V</code>; each flow keeps a finish tag <code>F</code>:

V += r * Δt virtual time advances by bytes served
s = MAX(F, V) a packet behind the clock starts now
F = s + S the one after it queues behind
wait = (s - V) / r time until this packet may go

The <code>wait</code> becomes the flow's scheduling deadline: a packet
already behind the virtual clock is sent immediately
(<code>wait = 0</code>); one ahead waits, deferring only its own flow.
A clock advance across an idle gap longer than 50 ms credits at most
the calling flow's owed lead plus one burst (50 ms of service, at
least one packet): a paced flow slower than one packet per 50 ms
receives its '''true''' elapsed service — a time-capped credit
would decay such a flow without bound — while an idle flow still
cannot bank an unbounded burst.

The virtual time <code>V</code> is shared by every flow in the context;
the finish tags are per flow. Because every flow computes its start
tag <code>s</code> against the same <code>V</code>, a flow that has just sent
carries a finish tag ahead of <code>V</code> and waits, while an idle flow
(finish tag at or behind <code>V</code>) starts immediately — this is
what fairly divides the aggregate rate <code>r</code> across them.

== 5. Rate control (AIMD + PD) ==

The rate law runs on packet sends, at most once per millisecond, and
also on feedback arrivals so that a sender with no traffic of its own
still reacts. Each increase term and the proportional decrease are
scaled by elapsed wall-clock time, each by its own clock: the
increase terms use time banked and '''capped''' at 50 ms (an idle gap
cannot bank an unbounded ramp), while the proportional decrease uses
the '''uncapped''' elapsed time (a starved sender still cuts by the
right amount). The one-sided derivative (Section 5.3) is a per-delta
term.

=== 5.1. Slow start ===

Before the first congestion signal the rate ramps exponentially with a
20 ms time constant:

r += r * Δt / T_ss (T_ss = 20 ms)

Slow start ends the first time a congestion signal arrives —
fed back from the receiver or observed at the sender's own first hop
— and never resumes.

Slow start belongs to the aggregate, so it runs '''once per
(destination, QoS cube)''', on the first flow. A flow arriving at an
established aggregate rides the existing estimates: it enters at the
aggregate's current rate and receives its fair share of it through
the pacer (Section 4), with no probing of its own.

=== 5.2. Increase: additive plus proportional probe (always on) ===

Past slow start, two increase terms are applied every step, both
regardless of congestion:

r += a * Δt additive; a defaults to 2^16 B/s^2
r += r * Δt / T_probe proportional; T_probe = 8 s

The additive term is a fixed per-context slope (bytes/s per second),
scaled to the path capacity (Section 5.5). The proportional probe
grows the rate by a fixed fraction per unit time (e-folds over
<code>T_probe</code>): a flow recovers in the same number of steps at any
link rate; the fixed additive term's effect vanishes relative to a
fast link. Both are the "probing"
pressure the multiplicative decrease balances at equilibrium; the
probe's cost is a rate-independent standing-queue floor (Section 7).

=== 5.3. Multiplicative decrease (proportional + derivative) ===

With congestion level <code>m</code> (the fed-back <code>ece</code>, or a local
first-hop mark as fallback), the decrease is the sum of a proportional
term and a one-sided derivative term — a PD controller on the
congestion signal:

mark = MIN(m, M) M = 512
rise = MAX(m - m_prev, 0), capped at M one-sided derivative

cut = r * rise / (4 * M) derivative, gain 1/4
cut += r * mark * Δt_ms / (1000 * M) proportional
cut = MIN(cut, r / 2) at most a halving

r -= cut
m_prev = m

* The '''proportional''' term is scaled by honest elapsed time in
milliseconds, so a starved sender that has not run the controller
for a while still cuts by the right amount.
* The '''derivative''' term (<code>rise</code>) reacts to an ''increase'' in
the congestion level between samples; it is one-sided and per-delta.
It sharpens the reaction at the onset of congestion.
* The cut is clamped to <code>r/2</code> per step, bounding the decrease to
a halving.

<code>M = 512 = 32 × 16</code> defines "full congestion" as a mean
<code>ecn</code> of 16, i.e. a mean queue of <code>16 × Q = 64</code> packets.

=== 5.4. Staleness ===

Feedback arrives once per receiver window, and the window stretches
with the flow's byte rate (Section 3) — so the staleness horizon
must stretch with it, or a slow flow's mark would age out ''between''
feedbacks and the rate would ramp against a congested path. The
sender mirrors the receiver: the horizon is four target windows of
bytes at the current rate, floored at ~268 ms so fast flows keep a
fixed horizon; at the default rate floor it is ~8 s. A signal older
than the horizon is aged out (both the fed-back estimate and the
local mark), freeing the rate to ramp once congestion clears. The
rate is clamped to
<code>[r_min, r_max]</code> on every step.

=== 5.5. Capacity-derived floor and slope ===

The fed-back capacity code sets the two rate-scale constants of the
controller, per context:

target = decode(cap8) / 32 clamped to [2^13, 2^32] B/s
r_min += (target - r_min) / 2 per feedback (moving average)
a = r_min

The defaults are fixed constants (<code>r_min = 2^13 B/s</code>,
<code>a = 2^16 B/s^2</code>), used on paths that never report a capacity;
with the estimator live the fairness floor and the post-cut recovery
slope scale with the bottleneck, and capacity engages wherever
<code>C/32</code> clears the default floor, i.e. above ~2 Mbit/s. A
capacity older than 16 staleness horizons (~4.3 s for fast flows)
reverts both to the defaults. That horizon deliberately outlives the
feedback horizon: feedback stops the moment the marks clear, which is
exactly when the recovery slope is needed; the onset-fresh capacity
(Section 3) re-seeds it on the first mark of the next episode either
way.

=== 5.6. Ramp and recovery ===

Three mechanisms set how fast an aggregate reaches a fast link's
rate, each owning one regime:

* '''From scratch: slow start.''' The exponential ramp reaches any
physical link rate in well under a second (~200 ms from the seed to
10 Gbit/s; each further doubling of link speed costs one more
~14 ms doubling time). On an uncongested path nothing marks, so
slow start runs until the aggregate arrives at its bottleneck.
* '''After a cut: the probe.''' A decrease is at most a halving per
step, and the mark ages out on the rate-relative horizon once
congestion clears (Section 5.4); the proportional probe then heals
a halving in <code>T_probe · ln 2 ≈ 5.5 s</code> at any
link rate.
* '''At the bottom: the capacity floor.''' The rate sits at most a
factor 32 below a measured bottleneck, and the additive slope
refills <code>C/32</code> per second, so the deepest hole is bounded:
floor to full capacity in tens of seconds, a halving in seconds.

These compose because a deep cut requires sustained congestion,
sustained congestion backlogs the bottleneck queue, and a backlogged
queue is exactly when its capacity is measured and stamped
(Section 2): whenever the controller is cut deep, the scaled floor is
live. The default floor only governs paths that never congested the
sender — where there is nothing to recover from. This is why
slow start can end for good: the floor and the probe cover every
later recovery.

=== 5.7. Regimes ===

<pre>
+-------------+ first mark seen +----------------+
| slow start |--------------------->| congestion |
| r *= e^(t/T)| | avoidance |
+-------------+ | |
| m == 0 -> AI |
| m > 0 -> AIPD |
+----------------+
m = fed-back ece, or the local first-hop mark when ece == 0
</pre>

== 6. RTT behaviour ==

Because every increase and decrease is scaled by wall-clock time,
two flows of different RTT that share a bottleneck obey the ''same''
rate law and converge to the ''same'' rate. The steady-state
'''allocation is RTT-independent'''.

This is a property of the equilibrium, not of the dynamics. The
feedback delay in the loop ''is'' the path RTT <code>τ</code>, and the
controller does not measure or compensate for it. At low rate the
receiver window (up to its ~4.3 s ceiling) is the dominant lag —
the loop is slow there in proportion to how slow the flow is, exactly
as a long-RTT TCP is — while as the rate rises the window shrinks
toward its ~1 ms floor, so the window's contribution to the loop delay
''falls'' with capacity and the path RTT <code>τ</code> becomes the
irreducible term. Two mechanisms keep the loop damped: the adaptive
window removes the delay-dominated corner at low <code>τ</code>, and a
bucketed '''rate-velocity damping''' (a washout: each ~31 ms bucket
pulls the rate a quarter of the way back toward its value at the
previous bucket) supplies the damping the otherwise
near-double-integrator lacks, which is what holds the loop together at
high capacity and moderate <code>τ</code>. What remains is the loop gain
<code>√G &prop; √C</code>: at very high capacity ''and'' large
<code>τ</code> the <code>√G · τ</code> phase budget is the
binding constraint, and no window or damping trick removes it (see
[[#8. Limitations|Section 8]]). A precise statement is therefore:
'''RTT-fair in equilibrium, and dynamically stable up to a
capacity-dependent RTT limit set by <code>√G · τ</code>.'''

== 7. Fairness ==

At equilibrium the two increase terms balance the proportional
decrease, <code>a + r/T_probe = r · m*/M</code>, which pins the
congestion level to <code>m* = M · (a/r + 1/T_probe)</code> and, since
<code>ece = 8q</code> (one mark unit per <code>Q = 4</code> packets, 32 fixed-point
steps per unit), a standing queue of

q* = 64 * a / r + 64 / T_probe (packets, r in bytes/s)

The additive part (<code>64 · a / r</code>) vanishes with rate under
the default slope; with the capacity-derived slope (<code>a = C/32</code>,
Section 5.5) it becomes <code>2 C / r</code> — about two packets per
competing flow, rate-independent. The proportional-probe part
(<code>64 / T_probe</code>) is a rate-independent floor (~8 packets at
8 s). That floor is the cost of rate-independent convergence, and it
keeps <code>q*</code> above the marking threshold at high rate.

Two flows at the same bottleneck see the same <code>m*</code>, so each
solves <code>r_i = a / (m*/M - 1/T_probe)</code> to the same rate. Under
the network-utility-maximization view this corresponds to
'''proportional fairness''' (equal weights), which is max-min fair at
a single bottleneck.

Measurement fidelity at low rate comes from the estimator itself:
the averaging window stretches with the flow
(Section 3), so a CA-limited flow keeps ~16 packets per window at any
rate down to ~30 kbit/s, and the rate-relative gap threshold keeps its
inter-packet spacing from reading as idle. The default floor
(<code>2^13</code> B/s) only bounds the extremes (window ceiling,
staleness horizon, pacer arithmetic). The floor scales with the
fed-back path capacity (<code>r_min = C/32</code>, Section 5.5), so
roughly 32 CA-limited flows fit above it at any link class. Flows
whose paths differ in bottleneck class derive different slopes, so
fairness across them is capacity-weighted; see
[[#8. Limitations|Section 8]].

== 9. Architectural fit ==

Each property the preceding sections build toward attaches to a
structural feature of the recursive architecture. This section makes
the mapping explicit.

* '''Congestion avoidance is fully orthogonal to ARQ and to flow
control.''' Three concerns, three mechanisms, two scopes: FRCP
provides retransmission (ARQ) and flow control (the peer pacing the
sender) end-to-end, per flow; congestion avoidance runs in the
IPCP, per aggregate. Each signal means one thing. A loss triggers
a retransmission and nothing else — a lossy link reads as
lossy, with the congestion verdict left to the marks (Section 8's
"no loss response" is this orthogonality stated from the other
side). The peer's flow-control window paces the endpoint and
nothing else — back-pressure from a slow receiver stays
distinct from congestion in the network. A retransmitted packet is
ordinary traffic to the pacer. TCP folds all three into one window
machine, where the receive window bounds the congestion window and
loss serves as both reliability trigger and congestion signal;
here each mechanism can be reasoned about, tested and evolved
alone.
* '''Congestion avoidance sits below application choice.''' Every
flow in the layer is paced by the same rate law, whatever its QoS:
a greedy raw sender shares a bottleneck fairly with a reliable
stream because the control is a property of the layer, on the
aggregate, rather than a courtesy of the endpoint transport.
* '''A layer defines its own PCI, so the signal can be rich.'''
Every member of a layer is enrolled into it: the layer is a single
administrative domain by construction, at whatever scope it spans,
and its header is layer-internal. Forwarders therefore write a
multi-bit queue magnitude and a capacity byte directly into the
packet. The datacenter schemes of
[[#10. Heritage and positioning|Section 10]] require exactly such a
domain and find it only inside one operator's fabric; a recursive
layer supplies it everywhere.
* '''Layer-internal addressing makes the aggregate well-defined.'''
Flows in a layer run between layer addresses, so the
(destination, QoS cube) aggregate — RFC 3124's macroflow
— falls out of the naming structure. Controller state scales
with destinations, and each QoS cube keeps its own loop, so
service classes keep separate fates.
* '''Flows are allocated, so feedback has a channel.''' Every flow
has state at both ends and a reverse direction; the receiver's
<code>ece</code> and the path capacity ride the flow allocator's
existing exchange.
* '''There is no transport ack clock, and none is relied on.''' The
layer must control raw flows, which carry no acknowledgements at
all, so the controller paces on wall-clock time — and that
constraint yields the RTT-independent allocation of Section 6. An
architectural restriction becomes the controller's distinguishing
property.
* '''Recursion scales the scheme.''' Each layer controls congestion
over its own scope and timescale; many N-flows ride one N-1 flow,
so aggregation compounds down the stack. The capacity a layer
measures at its egress queue is the rate the layer below actually
provides — a paced, shared lower flow rather than a nominal
wire speed — so the signal stays meaningful at every level,
and pushback cascades layer by layer.

The fit has a boundary: at a shim over legacy media the layer below
neither enrolls nor marks, which is the deployment edge behind
Section 8's no-loss-response limitation.

== 10. Heritage and positioning ==

mb-ecn is best understood as a rate-based ECN controller in the DECbit /
QCN line, adapted to an acknowledgement-less recursive layer.

The core of the scheme dates to the first Ouroboros
congestion-avoidance policy (2020): a multi-bit queue-depth mark
relayed by forwarders to the receiver, a smoothed multi-bit
<code>ece</code> fed back on the reverse flow at the same 1/32 fixed
point used today, and a sender that paced packets from a time budget
and ran slow start, additive increase and multiplicative decrease on
wall-clock time slots — rate-based and acknowledgement-free from
the start, with RTT-independent allocation already an objective. The
present algorithm keeps that skeleton and reworks every estimator
around it: per-path aggregation with SFQ pacing, the rate-adaptive
boxcar receiver, elapsed-time-scaled AIMD with a derivative term and
rate-velocity damping, and the in-band capacity signal.

* '''DECbit''' (Ramakrishnan & Jain, 1988; ToCS 1990) established
binary congestion feedback set by the switch on queue occupancy.
mb-ecn keeps the switch-sets-on-queue idea and carries a
''magnitude''.
* '''The Congestion Manager''' (Balakrishnan et al., SIGCOMM 1999;
RFC 3124, 2001) aggregates congestion state at the end host: one
controller per macroflow, a scheduler apportioning its rate across
the member streams, and new streams joining at the ensemble's
current state instead of probing from scratch. mb-ecn's
(destination, QoS cube) aggregate is the same idea placed inside
the IPCP: every layer manages its own macroflows, recursively, the
SFQ pacer plays the CM scheduler's role (Section 4), and a joining
flow rides the aggregate's estimates (Section 5.1). The CM gathers
its signal from transport feedback at the edge; mb-ecn reads it
off the wire from the forwarders.
* '''DCTCP''' (Alizadeh et al., SIGCOMM 2010) recovers a queue
magnitude at the endpoint by averaging a single threshold bit. mb-ecn
instead reads the magnitude off the wire, then time-averages it at
the receiver. The additive-increase / proportional-decrease structure
is shared.
* '''QCN''' (IEEE 802.1Qau, 2010) and '''DCQCN''' (Zhu et al., SIGCOMM
2015) contribute the rate-based (not window-based) ECN control
skeleton. mb-ecn's proportional decrease plus a probing increase
mirrors that skeleton; the increase here is wall-clock scaled rather
than byte-counter/timer based.
* '''HPCC''' (Li et al., SIGCOMM 2019) and '''PowerTCP''' (Addanki et
al., NSDI 2022) combine a queue term ''and'' a rate term (via in-band
telemetry or delay). mb-ecn now carries a coarse in-band rate (the
quarter-log2 path MIN, Section 2) but uses it only to scale the
controller's gains; the congestion ''signal'' remains queue-only,
which is still the main functional difference (Section 8).
* '''L4S / TCP Prague''' (RFC 9330–9332, 2023) make
RTT-independence a requirement and use a high-frequency single-bit
signal. mb-ecn shares the RTT-independent ''allocation'' goal but
reaches it by wall-clock-scaled rate control, with a low-frequency
multi-bit signal.

The novel combination is the multi-bit magnitude on the wire fused with
a wall-clock-scaled rate pacer in a setting with no per-flow ack clock.
The trade-off, made explicit above, is a queue-only signal and a
reactivity capped by the averaging window.

== 11. Parameters ==

These are the values every figure in this document instantiates. They
are '''coupled''': the mechanisms compose only while certain relations
hold — the gap-restart horizon at the rate floor must exceed a
packet's service time (or a floor-rate flow restart-loops at onset),
a floor-rate flow's target window must fit under the window ceiling,
the control interval must sit under the damping bucket under the idle
credit cap, the rate floor must not exceed the slow-start seed, and
the derived-floor ceiling must stay under the rate ceiling. Retune
them as a set, against those invariants.

{| class="wikitable"
! Parameter !! Value !! Meaning
|-
| Marking quantum <code>Q</code> || 4 packets || Mark onset and step; layer-wide
|-
| Feedback resolution || 1/32 <code>ecn</code> unit || Fixed-point LSB of <code>ece</code>
|-
| Full-congestion reference <code>M</code> || 512 || Mean queue of 64 packets
|-
| Receiver window target || 16 packets (16,000 bytes) || Samples per window
|-
| Initial receiver window || ~67 ms || Before rate is known
|-
| Receiver window bounds || ~1.05 ms – ~4.3 s || Clamp on <code>W</code>
|-
| Window resize weight || 1/4 || Moving average toward target
|-
| Early window close || 2 × target bytes || Speed-up escape
|-
| Gap restart || 4 windows || Idle horizon (rate-relative)
|-
| Additive slope <code>a</code> (default) || 2^16 B/s^2 || Lower clamp of derived slope
|-
| Probe time constant <code>T_probe</code> || 8 s || Rate-proportional recovery
|-
| Derivative gain || 1/4 || Onset sharpening
|-
| Rate floor <code>r_min</code> (default) || 2^13 B/s || Lower clamp of derived floor
|-
| Slow-start seed rate || 2^16 B/s || Initial rate
|-
| Slow-start time constant || 20 ms || Exponential ramp
|-
| Rate ceiling <code>r_max</code> || 2^37 B/s || Upper clamp
|-
| Capacity scale || <code>C</code> / 32 || Floor and slope from bottleneck
|-
| Capacity smoothing || 1/2 || Moving average per feedback
|-
| Capacity staleness || 16 × feedback horizon || Revert to defaults
|-
| Derived floor ceiling || 2^32 B/s || Upper clamp on derived floor
|-
| Control interval || 1 ms || Minimum spacing of rate updates
|-
| Idle credit cap || 50 ms || Burst allowance / increase banking
|-
| Feedback staleness floor || ~268 ms || Floor of rate-relative horizon
|-
| Damping bucket || ~31 ms || Rate-velocity washout cadence
|-
| Damping fraction || 1/4 || Pullback per bucket
|-
| Estimator fold spacing || 1 ms || Minimum measurement cadence
|-
| Estimator window closure || 16 packets drained || Self-scaling window
|-
| Estimator window staleness || ~134 ms || Discard across traffic gaps
|-
| Estimator idle tolerance || 1/8 of arrivals || Unsaturated-window rejection
|-
| Estimator decay || 1/16 per window || Max-filter convergence from below
|}

== 12. References ==

=== 12.1. Source ===

The implementation follows the algorithm above:

* <code>src/ipcpd/unicast/ca/mb-ecn.c</code>, <code>mb-ecn.h</code> —
receiver estimator, pacer and rate control.
* <code>src/ipcpd/unicast/ca/ops.h</code> — CA policy interface.
* <code>src/ipcpd/unicast/cap.c</code>, <code>cap.h</code> — link-capacity
estimator and quarter-log2 codec.
* <code>src/ipcpd/unicast/dt.c</code>, <code>fa.c</code> — per-hop marking
and stamping, and the feedback carrying <code>ece</code> + <code>cap8</code>.
* <code>src/ipcpd/unicast/psched.c</code> — consumes the pacing deadline.

=== 12.2. Literature ===

* K. K. Ramakrishnan, R. Jain, "A Binary Feedback Scheme for Congestion
Avoidance in Computer Networks" (DECbit), ACM ToCS, 1990.
* H. Balakrishnan, H. S. Rahul, S. Seshan, "An Integrated Congestion
Management Architecture for Internet Hosts", SIGCOMM 1999;
H. Balakrishnan, S. Seshan, "The Congestion Manager", RFC 3124, 2001.
* M. Alizadeh et al., "Data Center TCP (DCTCP)", SIGCOMM 2010.
* Y. Zhu et al., "Congestion Control for Large-Scale RDMA Deployments"
(DCQCN), SIGCOMM 2015.
* R. Mittal et al., "TIMELY: RTT-based Congestion Control", SIGCOMM 2015.
* Y. Li et al., "HPCC: High Precision Congestion Control", SIGCOMM 2019.
* V. Addanki et al., "PowerTCP", NSDI 2022.
* K. De Schepper, B. Briscoe (eds.), "Low Latency, Low Loss, and
Scalable Throughput (L4S)", RFC 9330/9331/9332.
* F. Kelly, "Charging and Rate Control for Elastic Traffic", 1997;
R. Srikant, "The Mathematics of Internet Congestion Control", 2004.

Congestion avoidance

2026-07-11T20:45:20Z

Dimitri: /* 5.7. Regimes */

{{DISPLAYTITLE:mb-ecn - Multi-bit ECN Congestion Avoidance}}

mb-ecn is a congestion-avoidance (CA) policy for the Ouroboros unicast
IPCP. It lives in the IPC Process: the flow-and-retransmission task
(FRCP) provides reliability, in-order delivery and flow control
end-to-end; congestion avoidance is orthogonal and runs per IPCP
layer. Within a layer, the IPCP controls '''aggregates''', one loop
per (destination address, QoS cube), shared by every flow toward that
destination. The alternative policy is <code>nop</code> (no congestion
avoidance).

This document describes the algorithm: what the policy does and why.
The implementation follows it ([[#12. References|Section 12]] maps the
pieces to source files). It does not claim properties the algorithm
does not have; [[#8. Limitations|Section 8]] states the known gaps
explicitly.

The keywords "MUST", "SHOULD", "MAY" etc. are used only where they
appear in all capitals, per BCP 14 (RFC 2119, RFC 8174).

== Notation ==

;<code>r</code>
:Paced send rate, bytes per second.
;<code>C</code>
:Bottleneck capacity, bytes per second.
;<code>S</code>
:Packet size in bytes.
;<code>q</code>
:Standing queue occupancy at the bottleneck, in packets.
;<code>Q</code>
:Marking quantum, packets per mark unit (4).
;<code>ecn</code>
:Per-packet congestion mark set by a forwarder, an unsigned integer
(on-wire field is 8-bit).
;<code>ece</code>
:Receiver-side congestion estimate, fixed point with LSB = 1/32 of an
<code>ecn</code> unit, i.e. <code>ece = 32 × (time-mean ecn)</code>.
;<code>cap8</code>
:Path-capacity code carried per packet, quarter-log2:
<code>C ≈ 2^(cap8 / 4)</code> bytes/s, 0 = unknown.
;<code>W</code>
:Receiver averaging window, nanoseconds.
;<code>a</code>
:Additive-increase slope, bytes/s per second.
;<code>M</code>
:Full-congestion reference level of <code>ece</code> (512).
;<code>Δt</code>
:Elapsed wall-clock time between two events, nanoseconds.
;<code>τ</code>
:Path round-trip time (feedback delay). The controller does not
measure it.

Rate is the control variable throughout.

All concrete figures in this document — window bounds, horizons,
rate thresholds — are instances of the parameter values in
[[#11. Parameters|Section 11]]. The mechanisms and the relations
between parameters are what the algorithm fixes; retuning the
parameters moves the figures together.

__TOC__

== 1. Overview ==

mb-ecn is a rate-based, ECN-driven controller with three moving parts,
one at each point of the loop:

<pre>
sender forwarder
+--------------------------------+ +--------------------------+
| SFQ virtual-clock pacer | | ecn = MAX(ecn, queue/Q) |
| rate r, paced per packet | data | (deepest queue wins) |
| AIMD + PD control on r |------>| cap8 = MIN(cap8, link) |
+--------------------------------+ +--------------------------+
^ |
| ece + cap8 feedback | marked data
| v
+--------------------------------+ +--------------------------+
| reads downstream ece, |<------| receiver |
| updates the rate on feedback, | ece | time-mean of ecn over |
| scales floor/slope to cap8 | cap8 | an adaptive window |
+--------------------------------+ +--------------------------+
</pre>

# The '''forwarder''' marks each packet with a ''multi-bit'' magnitude
proportional to its standing queue, and MIN-stamps its measured
outgoing-link capacity into the same PCI.
# The '''receiver''' turns the stream of marks into a time-averaged
congestion estimate <code>ece</code> and feeds it back to the sender,
together with the window minimum of the path-capacity codes.
# The '''sender''' paces its rate with a start-time fair-queuing (SFQ)
virtual clock, and adjusts that rate with additive-increase /
multiplicative-decrease (AIMD) driven by <code>ece</code>; the rate floor
and the additive slope derive from the fed-back path capacity.

The controller runs on packet sends and on feedback arrivals. All
increase/decrease steps are scaled by elapsed
wall-clock time, which is what makes the ''allocation'' independent of
RTT (see [[#6. RTT behaviour|Section 6]]).

The unit of control is the '''aggregate''', kept in the IPCP per
<code>(destination address, QoS cube)</code>. Every flow toward that
destination at that QoS shares one controller and one rate: a new
flow joins the aggregate at its current rate, and a departing flow
leaves the rate to the others. The pacer divides the aggregate rate
fairly across the member flows (SFQ), so per-flow fairness within an
aggregate is a scheduler property, distinct from the rate law
described here.

== 2. Forwarder marking ==

A forwarder marks a packet as a function of the packets already queued
on the outgoing link:

mark = queued / Q (Q = 4 packets)
ecn = MAX(ecn, mark) (saturating, 8-bit field)

The quantum <code>Q</code> is a layer-wide constant: the marks it
quantizes are combined by MAX across hops, so all forwarders in a
layer MUST use the same quantum for the signal to be comparable.

Two properties:

* '''Multi-bit magnitude.''' The mark is an integer proportional to
queue depth, quantized in steps of <code>Q</code> packets: a coarse
readout of the standing queue.
* '''MAX along the path.''' A packet crossing several forwarders carries
the maximum mark, i.e. the deepest queue on its path. MAX keeps the
signal range-stable and monotone across hops.

There is a '''dead zone''': for <code>queued < Q</code> the mark is 0.

=== Capacity stamping ===

Each forwarder also measures the capacity of its outgoing link and
stamps it into the packet. The estimate is a busy-period drain rate:
the queue is observed at most once per millisecond, and a measurement
window stays open until 16 packets have drained, so its length
'''self-scales with the link rate''' — the millisecond cadence
bounds it on fast links, the 16-packet drain time on slow ones
(~19 ms at 10 Mbit/s). A window in which more than 1/8 of
the arrivals found the queue empty is discarded as unsaturated;
occasional empty observations (token-bucket shapers grazing zero) are
tolerated. The drain rate of a saturated queue is the link rate; a max
filter with slow decay (1/16 per window) converges on it from below. A
window that opened or closed on an empty queue may have drained into
buffers below at above-wire rate, so it may lower the estimate but
never raise it. The code on the wire is quarter-log2
(<code>cap8 = 4 log2 C</code>, ~19% per step, 0 = unknown) and each hop
MIN-combines its own code into the byte, so a packet arrives carrying
the bottleneck's rate. A hop that has never been backlogged stamps
nothing; since only backlogged hops matter, the signal exists exactly
when it is needed.

== 3. Receiver estimate ==

The receiver converts marks into a smoothed estimate <code>ece</code> over a
time window <code>W</code> that '''adapts to the incoming byte rate'''. It is
a '''boxcar (rectangular) time-integral mean'''. Per packet, with
<code>Δt</code> the gap since the previous packet:

A += ecn * MIN(Δt, W) dwell-weighted; one packet
weighs at most one window
B += S accumulate bytes this window
...
at window close (elapsed >= W, or B >= 2 * B_target with at
least the window floor elapsed):
ece = 32 * A / elapsed mean over the actual window
W += (B_target * elapsed / B - W) / 4 nudge toward the size
that holds the target
W = clamp(W, ~1.05 ms, ~4.3 s)
A = 0 ; B = 0 hard reset

At each close the next window is nudged by a quarter-weight moving
average toward the size that would hold about 16 packets at the
measured byte rate, from an initial ~67 ms. The target is byte-based (<code>B_target</code> = 16,000 bytes), so
"16 packets" is exact only at ~1000-byte packets, and the window
converges to it over several closes. The mean always divides by the
'''actual''' elapsed window, so a rate step leaves the current
estimate exact and only re-sizes the ''next'' window. The effect is a roughly constant sample
count — ~16 packets — from about 30 kbit/s to 122 Mbit/s;
above that the window floors at ~1 ms (a cadence still carrying
thousands of samples at 10–100 GbE), and below ~30 kbit/s it
saturates at the ~4.3 s ceiling. The averaging clock stretches with
the flow the way TCP's ACK clock stretches with the RTT. A speed-up
escapes a stretched window early: once twice the target bytes arrive
the window closes anyway (the window floor keeps that cadence bounded
at high rate). The fed-back <code>ece</code> is thus a piecewise-constant
staircase whose step period tracks the rate. Two edge cases:

* '''Onset''' (first mark after an idle estimate) emits the
instantaneous mark undiluted, so a starting queue is reported without
a full window of delay.
* '''Gap''' longer than 4 windows resets the window and emits the raw
sample. The threshold is '''rate-relative''': idle means a few
''current'' windows of silence, so a slow flow's normal inter-packet
gap never reads as idle, while the in-window dwell clamp above bounds
what a genuine pause can add to the mean before the restart fires.

Alongside the mark integral, the receiver keeps the MIN of the nonzero
capacity codes seen in the current window; each emitted <code>ece</code>
carries that minimum (the raw packet's code on onset/gap restarts) and
the fold then resets, so a reroute to a faster path can raise the
fed-back capacity within one window.

The estimate is fed back to the sender on the reverse flow.

== 4. Sender pacer ==

The sender paces with an SFQ virtual clock. The context keeps a
virtual time <code>V</code>; each flow keeps a finish tag <code>F</code>:

V += r * Δt virtual time advances by bytes served
s = MAX(F, V) a packet behind the clock starts now
F = s + S the one after it queues behind
wait = (s - V) / r time until this packet may go

The <code>wait</code> becomes the flow's scheduling deadline: a packet
already behind the virtual clock is sent immediately
(<code>wait = 0</code>); one ahead waits, deferring only its own flow.
A clock advance across an idle gap longer than 50 ms credits at most
the calling flow's owed lead plus one burst (50 ms of service, at
least one packet): a paced flow slower than one packet per 50 ms
receives its '''true''' elapsed service — a time-capped credit
would decay such a flow without bound — while an idle flow still
cannot bank an unbounded burst.

The virtual time <code>V</code> is shared by every flow in the context;
the finish tags are per flow. Because every flow computes its start
tag <code>s</code> against the same <code>V</code>, a flow that has just sent
carries a finish tag ahead of <code>V</code> and waits, while an idle flow
(finish tag at or behind <code>V</code>) starts immediately — this is
what fairly divides the aggregate rate <code>r</code> across them.

== 5. Rate control (AIMD + PD) ==

The rate law runs on packet sends, at most once per millisecond, and
also on feedback arrivals so that a sender with no traffic of its own
still reacts. Each increase term and the proportional decrease are
scaled by elapsed wall-clock time, each by its own clock: the
increase terms use time banked and '''capped''' at 50 ms (an idle gap
cannot bank an unbounded ramp), while the proportional decrease uses
the '''uncapped''' elapsed time (a starved sender still cuts by the
right amount). The one-sided derivative (Section 5.3) is a per-delta
term.

=== 5.1. Slow start ===

Before the first congestion signal the rate ramps exponentially with a
20 ms time constant:

r += r * Δt / T_ss (T_ss = 20 ms)

Slow start ends the first time a congestion signal arrives —
fed back from the receiver or observed at the sender's own first hop
— and never resumes.

Slow start belongs to the aggregate, so it runs '''once per
(destination, QoS cube)''', on the first flow. A flow arriving at an
established aggregate rides the existing estimates: it enters at the
aggregate's current rate and receives its fair share of it through
the pacer (Section 4), with no probing of its own.

=== 5.2. Increase: additive plus proportional probe (always on) ===

Past slow start, two increase terms are applied every step, both
regardless of congestion:

r += a * Δt additive; a defaults to 2^16 B/s^2
r += r * Δt / T_probe proportional; T_probe = 8 s

The additive term is a fixed per-context slope (bytes/s per second),
scaled to the path capacity (Section 5.5). The proportional probe
grows the rate by a fixed fraction per unit time (e-folds over
<code>T_probe</code>): a flow recovers in the same number of steps at any
link rate; the fixed additive term's effect vanishes relative to a
fast link. Both are the "probing"
pressure the multiplicative decrease balances at equilibrium; the
probe's cost is a rate-independent standing-queue floor (Section 7).

=== 5.3. Multiplicative decrease (proportional + derivative) ===

With congestion level <code>m</code> (the fed-back <code>ece</code>, or a local
first-hop mark as fallback), the decrease is the sum of a proportional
term and a one-sided derivative term — a PD controller on the
congestion signal:

mark = MIN(m, M) M = 512
rise = MAX(m - m_prev, 0), capped at M one-sided derivative

cut = r * rise / (4 * M) derivative, gain 1/4
cut += r * mark * Δt_ms / (1000 * M) proportional
cut = MIN(cut, r / 2) at most a halving

r -= cut
m_prev = m

* The '''proportional''' term is scaled by honest elapsed time in
milliseconds, so a starved sender that has not run the controller
for a while still cuts by the right amount.
* The '''derivative''' term (<code>rise</code>) reacts to an ''increase'' in
the congestion level between samples; it is one-sided and per-delta.
It sharpens the reaction at the onset of congestion.
* The cut is clamped to <code>r/2</code> per step, bounding the decrease to
a halving.

<code>M = 512 = 32 × 16</code> defines "full congestion" as a mean
<code>ecn</code> of 16, i.e. a mean queue of <code>16 × Q = 64</code> packets.

=== 5.4. Staleness ===

Feedback arrives once per receiver window, and the window stretches
with the flow's byte rate (Section 3) — so the staleness horizon
must stretch with it, or a slow flow's mark would age out ''between''
feedbacks and the rate would ramp against a congested path. The
sender mirrors the receiver: the horizon is four target windows of
bytes at the current rate, floored at ~268 ms so fast flows keep a
fixed horizon; at the default rate floor it is ~8 s. A signal older
than the horizon is aged out (both the fed-back estimate and the
local mark), freeing the rate to ramp once congestion clears. The
rate is clamped to
<code>[r_min, r_max]</code> on every step.

=== 5.5. Capacity-derived floor and slope ===

The fed-back capacity code sets the two rate-scale constants of the
controller, per context:

target = decode(cap8) / 32 clamped to [2^13, 2^32] B/s
r_min += (target - r_min) / 2 per feedback (moving average)
a = r_min

The defaults are fixed constants (<code>r_min = 2^13 B/s</code>,
<code>a = 2^16 B/s^2</code>), used on paths that never report a capacity;
with the estimator live the fairness floor and the post-cut recovery
slope scale with the bottleneck, and capacity engages wherever
<code>C/32</code> clears the default floor, i.e. above ~2 Mbit/s. A
capacity older than 16 staleness horizons (~4.3 s for fast flows)
reverts both to the defaults. That horizon deliberately outlives the
feedback horizon: feedback stops the moment the marks clear, which is
exactly when the recovery slope is needed; the onset-fresh capacity
(Section 3) re-seeds it on the first mark of the next episode either
way.

=== 5.6. Ramp and recovery ===

Three mechanisms set how fast an aggregate reaches a fast link's
rate, each owning one regime:

* '''From scratch: slow start.''' The exponential ramp reaches any
physical link rate in well under a second (~200 ms from the seed to
10 Gbit/s; each further doubling of link speed costs one more
~14 ms doubling time). On an uncongested path nothing marks, so
slow start runs until the aggregate arrives at its bottleneck.
* '''After a cut: the probe.''' A decrease is at most a halving per
step, and the mark ages out on the rate-relative horizon once
congestion clears (Section 5.4); the proportional probe then heals
a halving in <code>T_probe · ln 2 ≈ 5.5 s</code> at any
link rate.
* '''At the bottom: the capacity floor.''' The rate sits at most a
factor 32 below a measured bottleneck, and the additive slope
refills <code>C/32</code> per second, so the deepest hole is bounded:
floor to full capacity in tens of seconds, a halving in seconds.

These compose because a deep cut requires sustained congestion,
sustained congestion backlogs the bottleneck queue, and a backlogged
queue is exactly when its capacity is measured and stamped
(Section 2): whenever the controller is cut deep, the scaled floor is
live. The default floor only governs paths that never congested the
sender — where there is nothing to recover from. This is why
slow start can end for good: the floor and the probe cover every
later recovery.

=== 5.7. Regimes ===

<pre>
+-------------+ first mark seen +----------------+
| slow start |--------------------->| congestion |
| r *= e^(t/T)| | avoidance |
+-------------+ | |
| m == 0 -> AI |
| m > 0 -> AIPD |
+----------------+
m = fed-back ece, or the local first-hop mark when ece == 0
</pre>

== 6. RTT behaviour ==

Because every increase and decrease is scaled by wall-clock time,
two flows of different RTT that share a bottleneck obey the ''same''
rate law and converge to the ''same'' rate. The steady-state
'''allocation is RTT-independent'''.

This is a property of the equilibrium, not of the dynamics. The
feedback delay in the loop ''is'' the path RTT <code>τ</code>, and the
controller does not measure or compensate for it. At low rate the
receiver window (up to its ~4.3 s ceiling) is the dominant lag —
the loop is slow there in proportion to how slow the flow is, exactly
as a long-RTT TCP is — while as the rate rises the window shrinks
toward its ~1 ms floor, so the window's contribution to the loop delay
''falls'' with capacity and the path RTT <code>τ</code> becomes the
irreducible term. Two mechanisms keep the loop damped: the adaptive
window removes the delay-dominated corner at low <code>τ</code>, and a
bucketed '''rate-velocity damping''' (a washout: each ~31 ms bucket
pulls the rate a quarter of the way back toward its value at the
previous bucket) supplies the damping the otherwise
near-double-integrator lacks, which is what holds the loop together at
high capacity and moderate <code>τ</code>. What remains is the loop gain
<code>√G &prop; √C</code>: at very high capacity ''and'' large
<code>τ</code> the <code>√G · τ</code> phase budget is the
binding constraint, and no window or damping trick removes it (see
[[#8. Limitations|Section 8]]). A precise statement is therefore:
'''RTT-fair in equilibrium, and dynamically stable up to a
capacity-dependent RTT limit set by <code>√G · τ</code>.'''

== 7. Fairness ==

At equilibrium the two increase terms balance the proportional
decrease, <code>a + r/T_probe = r · m*/M</code>, which pins the
congestion level to <code>m* = M · (a/r + 1/T_probe)</code> and, since
<code>ece = 8q</code> (one mark unit per <code>Q = 4</code> packets, 32 fixed-point
steps per unit), a standing queue of

q* = 64 * a / r + 64 / T_probe (packets, r in bytes/s)

The additive part (<code>64 · a / r</code>) vanishes with rate under
the default slope; with the capacity-derived slope (<code>a = C/32</code>,
Section 5.5) it becomes <code>2 C / r</code> — about two packets per
competing flow, rate-independent. The proportional-probe part
(<code>64 / T_probe</code>) is a rate-independent floor (~8 packets at
8 s). That floor is the cost of rate-independent convergence, and it
keeps <code>q*</code> above the marking threshold at high rate.

Two flows at the same bottleneck see the same <code>m*</code>, so each
solves <code>r_i = a / (m*/M - 1/T_probe)</code> to the same rate. Under
the network-utility-maximization view this corresponds to
'''proportional fairness''' (equal weights), which is max-min fair at
a single bottleneck.

Measurement fidelity at low rate comes from the estimator itself:
the averaging window stretches with the flow
(Section 3), so a CA-limited flow keeps ~16 packets per window at any
rate down to ~30 kbit/s, and the rate-relative gap threshold keeps its
inter-packet spacing from reading as idle. The default floor
(<code>2^13</code> B/s) only bounds the extremes (window ceiling,
staleness horizon, pacer arithmetic). The floor scales with the
fed-back path capacity (<code>r_min = C/32</code>, Section 5.5), so
roughly 32 CA-limited flows fit above it at any link class. Flows
whose paths differ in bottleneck class derive different slopes, so
fairness across them is capacity-weighted; see
[[#8. Limitations|Section 8]].

== 8. Limitations ==

These are properties the algorithm does '''not''' have. They are
listed so the policy is not credited with more than it does.

* '''Queue-only signal; no bandwidth/rate term.''' The reference
<code>M</code> is a queue level, so mb-ecn is a standing-queue
controller: it must build a queue (<code>q* = 64 · a / r +
64 / T_probe</code>) to see any signal, and cannot hold high utilization
at an empty queue the way a controller with a rate/bandwidth estimate
can. The proportional-probe floor (~8 packets) keeps <code>q*</code>
above the marking threshold at all rates, at the cost of a persistent
standing queue.

* '''Aggregation is per destination, per QoS cube.''' The aggregate
stands in for the path: flows toward the same destination are
assumed to share their bottleneck, and flows toward different
destinations keep independent loops even when they queue at the
same hop. Each such loop converges to its own fair share
(Section 7), so the cost is duplicated state and probing at the
shared queue rather than unfairness. A future option is to identify
the queue in the packet: a forwarder stamping a queue identifier
alongside its mark would let senders key their aggregates on the
actual bottleneck rather than on the destination, pooling the
estimate and the probing across everything that queues there.

* '''Capacity is learned, with gaps.''' The floor and slope scale with
an in-band path-capacity estimate (Sections 2, 5.5), but the estimate
has limits of its own. A hop only learns its link rate while its
queue is backlogged, so a rerouted or freshly established bottleneck
contributes ''unknown'' at first and the path MIN can transiently
come from faster hops (the sender's smoothing and the next feedback
bound the excursion). The drain measurement is order-of-magnitude by
design: quarter-log2 code (~19% per step), burst noise bounded by a
16-packet minimum window and a max filter, nothing learned below
~120 packets per second of busy drain (16 packets inside the
~134 ms staleness cap; at MTU that is ~1.4 Mbit/s, below which
capacity/32 would sit under the default floor anyway). The derived
floor clamps to <code>[2^13, 2^32]</code> B/s, and flows with
different path bottlenecks get capacity-weighted, not equal, shares
at a common queue (Section 7).

* '''The low end trades reactivity, not correctness.''' Below
~30 kbit/s the averaging window clips at its ~4.3 s ceiling and
holds fewer samples; below ~64 kbit/s of offered load an
''app-limited'' flow spaces packets past the gap threshold and rides
the raw onset branch, as it always did. Feedback cadence and the
staleness horizon at the floor are seconds — a slow flow
converges slowly, TCP-style; nothing diverges, but nothing is fast
either.

* '''No loss response.''' The controller reacts only to ECN marks. Loss
is handled by FRCP retransmission, out of the CA's view. At a bottleneck
that drops instead of marking (e.g. a classic drop-tail queue at the
Ethernet/UDP shim), mb-ecn sees no signal and additive increase keeps
ramping. mb-ecn is intended for Ouroboros-native bottlenecks where the
forwarder marks; it does not implement a classic-bottleneck fallback.

* '''Dynamic stability has a capacity-dependent RTT limit.''' As stated
in Section 6, the allocation is RTT-independent but the dynamics are
not: the binding constraint is <code>√G · τ</code> with
<code>√G &prop; √C</code>. The adaptive window and the washout push
this limit out substantially (e.g. a single flow at 10 GbE stays stable
to ~50 ms RTT in the fluid model), but the extreme long-fat-network
corner (100 GbE at ≥ 50 ms) is not reachable by a window/damping
controller and would need explicit-rate signalling.

* '''Fluid-model caveat.''' The offline model in the simulation tooling
captures the aggregate rate law (sawtooth, standing queue) with a
boxcar receiver, but sizes the adaptive window in the rate domain
rather than the byte-folded form of the algorithm above, and treats
all flows identically, so it is a guide to stability ''trends'', not
a fairness or exact-quantitative oracle at high link rate.

== 9. Architectural fit ==

Each property the preceding sections build toward attaches to a
structural feature of the recursive architecture. This section makes
the mapping explicit.

* '''Congestion avoidance is fully orthogonal to ARQ and to flow
control.''' Three concerns, three mechanisms, two scopes: FRCP
provides retransmission (ARQ) and flow control (the peer pacing the
sender) end-to-end, per flow; congestion avoidance runs in the
IPCP, per aggregate. Each signal means one thing. A loss triggers
a retransmission and nothing else — a lossy link reads as
lossy, with the congestion verdict left to the marks (Section 8's
"no loss response" is this orthogonality stated from the other
side). The peer's flow-control window paces the endpoint and
nothing else — back-pressure from a slow receiver stays
distinct from congestion in the network. A retransmitted packet is
ordinary traffic to the pacer. TCP folds all three into one window
machine, where the receive window bounds the congestion window and
loss serves as both reliability trigger and congestion signal;
here each mechanism can be reasoned about, tested and evolved
alone.
* '''Congestion avoidance sits below application choice.''' Every
flow in the layer is paced by the same rate law, whatever its QoS:
a greedy raw sender shares a bottleneck fairly with a reliable
stream because the control is a property of the layer, on the
aggregate, rather than a courtesy of the endpoint transport.
* '''A layer defines its own PCI, so the signal can be rich.'''
Every member of a layer is enrolled into it: the layer is a single
administrative domain by construction, at whatever scope it spans,
and its header is layer-internal. Forwarders therefore write a
multi-bit queue magnitude and a capacity byte directly into the
packet. The datacenter schemes of
[[#10. Heritage and positioning|Section 10]] require exactly such a
domain and find it only inside one operator's fabric; a recursive
layer supplies it everywhere.
* '''Layer-internal addressing makes the aggregate well-defined.'''
Flows in a layer run between layer addresses, so the
(destination, QoS cube) aggregate — RFC 3124's macroflow
— falls out of the naming structure. Controller state scales
with destinations, and each QoS cube keeps its own loop, so
service classes keep separate fates.
* '''Flows are allocated, so feedback has a channel.''' Every flow
has state at both ends and a reverse direction; the receiver's
<code>ece</code> and the path capacity ride the flow allocator's
existing exchange.
* '''There is no transport ack clock, and none is relied on.''' The
layer must control raw flows, which carry no acknowledgements at
all, so the controller paces on wall-clock time — and that
constraint yields the RTT-independent allocation of Section 6. An
architectural restriction becomes the controller's distinguishing
property.
* '''Recursion scales the scheme.''' Each layer controls congestion
over its own scope and timescale; many N-flows ride one N-1 flow,
so aggregation compounds down the stack. The capacity a layer
measures at its egress queue is the rate the layer below actually
provides — a paced, shared lower flow rather than a nominal
wire speed — so the signal stays meaningful at every level,
and pushback cascades layer by layer.

The fit has a boundary: at a shim over legacy media the layer below
neither enrolls nor marks, which is the deployment edge behind
Section 8's no-loss-response limitation.

== 10. Heritage and positioning ==

mb-ecn is best understood as a rate-based ECN controller in the DECbit /
QCN line, adapted to an acknowledgement-less recursive layer.

The core of the scheme dates to the first Ouroboros
congestion-avoidance policy (2020): a multi-bit queue-depth mark
relayed by forwarders to the receiver, a smoothed multi-bit
<code>ece</code> fed back on the reverse flow at the same 1/32 fixed
point used today, and a sender that paced packets from a time budget
and ran slow start, additive increase and multiplicative decrease on
wall-clock time slots — rate-based and acknowledgement-free from
the start, with RTT-independent allocation already an objective. The
present algorithm keeps that skeleton and reworks every estimator
around it: per-path aggregation with SFQ pacing, the rate-adaptive
boxcar receiver, elapsed-time-scaled AIMD with a derivative term and
rate-velocity damping, and the in-band capacity signal.

* '''DECbit''' (Ramakrishnan & Jain, 1988; ToCS 1990) established
binary congestion feedback set by the switch on queue occupancy.
mb-ecn keeps the switch-sets-on-queue idea and carries a
''magnitude''.
* '''The Congestion Manager''' (Balakrishnan et al., SIGCOMM 1999;
RFC 3124, 2001) aggregates congestion state at the end host: one
controller per macroflow, a scheduler apportioning its rate across
the member streams, and new streams joining at the ensemble's
current state instead of probing from scratch. mb-ecn's
(destination, QoS cube) aggregate is the same idea placed inside
the IPCP: every layer manages its own macroflows, recursively, the
SFQ pacer plays the CM scheduler's role (Section 4), and a joining
flow rides the aggregate's estimates (Section 5.1). The CM gathers
its signal from transport feedback at the edge; mb-ecn reads it
off the wire from the forwarders.
* '''DCTCP''' (Alizadeh et al., SIGCOMM 2010) recovers a queue
magnitude at the endpoint by averaging a single threshold bit. mb-ecn
instead reads the magnitude off the wire, then time-averages it at
the receiver. The additive-increase / proportional-decrease structure
is shared.
* '''QCN''' (IEEE 802.1Qau, 2010) and '''DCQCN''' (Zhu et al., SIGCOMM
2015) contribute the rate-based (not window-based) ECN control
skeleton. mb-ecn's proportional decrease plus a probing increase
mirrors that skeleton; the increase here is wall-clock scaled rather
than byte-counter/timer based.
* '''HPCC''' (Li et al., SIGCOMM 2019) and '''PowerTCP''' (Addanki et
al., NSDI 2022) combine a queue term ''and'' a rate term (via in-band
telemetry or delay). mb-ecn now carries a coarse in-band rate (the
quarter-log2 path MIN, Section 2) but uses it only to scale the
controller's gains; the congestion ''signal'' remains queue-only,
which is still the main functional difference (Section 8).
* '''L4S / TCP Prague''' (RFC 9330–9332, 2023) make
RTT-independence a requirement and use a high-frequency single-bit
signal. mb-ecn shares the RTT-independent ''allocation'' goal but
reaches it by wall-clock-scaled rate control, with a low-frequency
multi-bit signal.

The novel combination is the multi-bit magnitude on the wire fused with
a wall-clock-scaled rate pacer in a setting with no per-flow ack clock.
The trade-off, made explicit above, is a queue-only signal and a
reactivity capped by the averaging window.

== 11. Parameters ==

These are the values every figure in this document instantiates. They
are '''coupled''': the mechanisms compose only while certain relations
hold — the gap-restart horizon at the rate floor must exceed a
packet's service time (or a floor-rate flow restart-loops at onset),
a floor-rate flow's target window must fit under the window ceiling,
the control interval must sit under the damping bucket under the idle
credit cap, the rate floor must not exceed the slow-start seed, and
the derived-floor ceiling must stay under the rate ceiling. Retune
them as a set, against those invariants.

{| class="wikitable"
! Parameter !! Value !! Meaning
|-
| Marking quantum <code>Q</code> || 4 packets || Mark onset and step; layer-wide
|-
| Feedback resolution || 1/32 <code>ecn</code> unit || Fixed-point LSB of <code>ece</code>
|-
| Full-congestion reference <code>M</code> || 512 || Mean queue of 64 packets
|-
| Receiver window target || 16 packets (16,000 bytes) || Samples per window
|-
| Initial receiver window || ~67 ms || Before rate is known
|-
| Receiver window bounds || ~1.05 ms – ~4.3 s || Clamp on <code>W</code>
|-
| Window resize weight || 1/4 || Moving average toward target
|-
| Early window close || 2 × target bytes || Speed-up escape
|-
| Gap restart || 4 windows || Idle horizon (rate-relative)
|-
| Additive slope <code>a</code> (default) || 2^16 B/s^2 || Lower clamp of derived slope
|-
| Probe time constant <code>T_probe</code> || 8 s || Rate-proportional recovery
|-
| Derivative gain || 1/4 || Onset sharpening
|-
| Rate floor <code>r_min</code> (default) || 2^13 B/s || Lower clamp of derived floor
|-
| Slow-start seed rate || 2^16 B/s || Initial rate
|-
| Slow-start time constant || 20 ms || Exponential ramp
|-
| Rate ceiling <code>r_max</code> || 2^37 B/s || Upper clamp
|-
| Capacity scale || <code>C</code> / 32 || Floor and slope from bottleneck
|-
| Capacity smoothing || 1/2 || Moving average per feedback
|-
| Capacity staleness || 16 × feedback horizon || Revert to defaults
|-
| Derived floor ceiling || 2^32 B/s || Upper clamp on derived floor
|-
| Control interval || 1 ms || Minimum spacing of rate updates
|-
| Idle credit cap || 50 ms || Burst allowance / increase banking
|-
| Feedback staleness floor || ~268 ms || Floor of rate-relative horizon
|-
| Damping bucket || ~31 ms || Rate-velocity washout cadence
|-
| Damping fraction || 1/4 || Pullback per bucket
|-
| Estimator fold spacing || 1 ms || Minimum measurement cadence
|-
| Estimator window closure || 16 packets drained || Self-scaling window
|-
| Estimator window staleness || ~134 ms || Discard across traffic gaps
|-
| Estimator idle tolerance || 1/8 of arrivals || Unsaturated-window rejection
|-
| Estimator decay || 1/16 per window || Max-filter convergence from below
|}

== 12. References ==

=== 12.1. Source ===

The implementation follows the algorithm above:

* <code>src/ipcpd/unicast/ca/mb-ecn.c</code>, <code>mb-ecn.h</code> —
receiver estimator, pacer and rate control.
* <code>src/ipcpd/unicast/ca/ops.h</code> — CA policy interface.
* <code>src/ipcpd/unicast/cap.c</code>, <code>cap.h</code> — link-capacity
estimator and quarter-log2 codec.
* <code>src/ipcpd/unicast/dt.c</code>, <code>fa.c</code> — per-hop marking
and stamping, and the feedback carrying <code>ece</code> + <code>cap8</code>.
* <code>src/ipcpd/unicast/psched.c</code> — consumes the pacing deadline.

=== 12.2. Literature ===

* K. K. Ramakrishnan, R. Jain, "A Binary Feedback Scheme for Congestion
Avoidance in Computer Networks" (DECbit), ACM ToCS, 1990.
* H. Balakrishnan, H. S. Rahul, S. Seshan, "An Integrated Congestion
Management Architecture for Internet Hosts", SIGCOMM 1999;
H. Balakrishnan, S. Seshan, "The Congestion Manager", RFC 3124, 2001.
* M. Alizadeh et al., "Data Center TCP (DCTCP)", SIGCOMM 2010.
* Y. Zhu et al., "Congestion Control for Large-Scale RDMA Deployments"
(DCQCN), SIGCOMM 2015.
* R. Mittal et al., "TIMELY: RTT-based Congestion Control", SIGCOMM 2015.
* Y. Li et al., "HPCC: High Precision Congestion Control", SIGCOMM 2019.
* V. Addanki et al., "PowerTCP", NSDI 2022.
* K. De Schepper, B. Briscoe (eds.), "Low Latency, Low Loss, and
Scalable Throughput (L4S)", RFC 9330/9331/9332.
* F. Kelly, "Charging and Rate Control for Elastic Traffic", 1997;
R. Srikant, "The Mathematics of Internet Congestion Control", 2004.

Ouroboros Data Transfer Protocol

2026-07-11T20:44:26Z

Dimitri: /* Fields associated with the network end-to-end layer */

The Ouroboros Data Transfer Protocol (ODTP) is the ''hop-by-hop'' protocol that forwards packets to their destination, and is similar to the Internet Protocol, but with further simplifications.

ODTP is internal to the [[Data Transfer Component]] in the unicast IPCP. The details of this protocol do not need to be known outside these modules, not to the other components of a unicast IPCP, not to the IRMd, and definitely not to the upper layer application.

== Protocol Header ==

The field widths are not that important, but an optimized version should take into account memory alignment. The Data Transfer Protocol has 3 fields associated with the Data Transfer Component (the network forwarding layer in the model), and 2 fields associated with the flow allocator (the end-to-end network layer in the model).

<syntaxhighlight>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-to-Live | QoS | ECN | CAP8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ EID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ N + 1 Data +
. .
. .
</syntaxhighlight>

=== Fields associated with the network forwarding layer ===

==== Destination address ====

This specifies the address to forward the packet to. The width of this field is configurable based on various preferences and the size of the envisioned network. The Ouroboros default is 64 bits.

==== Time-to-Live ====

Similar to IPv4 (in IPv6 this field is replaced by the Hop Limit), this is decremented at each hop to ensures that packets don’t get forwarded forever in the network, for instance due to (transient) loops in the forwarding path. The Ouroboros default for the width is one octet (byte), limiting the Maximum Packet Lifetime in the network to 255 seconds. The initial TTL value for a flow can be based on the maximum delay requested by the application.

==== QoS ====

Ouroboros supports Quality of Service via a number of methods, and this field is used to prioritize scheduling of the packets when forwarding. For instance, if the network gets congested and queues start filling up, higher priority packets (e.g. a voice call) get scheduled more often than lower priority packets (e.g. a file download). By default this field is one octet long.

=== Fields associated with the network end-to-end layer ===

==== EID ====

The Endpoint Identifier (EID) field specified the endpoint for which to deliver the packet. This endpoint uniquely identifies an application/service at the destination, so this field is not identical in function to the ''protocol'' or ''next header'' field in IPv4 or IPv6, but rather it more akin to the function of the (ephemeral) ''port'' field in UDP or TCP. Note that

# There is no reason for an N-layer protocol to know anything about the (N + 1)-Layer protocol it is transporting (nor the other way around).
# There are no ''well-known'' Endpoint IDs; every application flow has random EIDs and there is no relation between an EID and an application type.

The width of this field is configurable, but for security, it should be reasonably long to avoid an attacker guessing valid EID values (the figure shows 64 bits, which is the value used in the prototype). For efficiency, it should be easy to map and EID to a flow descriptor at the endpoints. The value of this field is chosen locally by each endpoint IPCP during flow allocation.

While Ouroboros does not have well-known EIDs, it does have a notion of ''reserved EID''s for functions that are ''internal'' to an N-layer, such as the [[Flow Allocator | flow allocator]] and the [[directory]]. These EIDs should not be fixed, unique for the layer and can be communicated during Enrollment.

==== ECN ====

This field specifies Explicit Congestion Notification (ECN), with similar intent as the ECN bits in the Type-of-Service field in IPv4 or Traffic Class field in IPv6. The Ouroboros ECN field is by default one octet wide, and its value can be set to an increasing value as packets are queued deeper and deeper in a congested routers’ forwarding queues. Ouroboros enforces Forward ECN (FECN). See [[Congestion avoidance]].

==== CAP8 ====

This field specifies the capacity of the link that is flagged by Explicit Congestion Notification (ECN). See [[Congestion avoidance]].

=== Notable fields not present in ODTP ===

==== Version ====

There is no need for a version field in the ODTP protocol, even if future changes to the fields are made, or other fields are added. The Data Transfer protocol specification is agreed between IPCPs during [[enrollment]].

==== Source address ====

There is no need for a source address in the header. The source address is exchanged during [[Flow Allocation | flow allocation]], and when sending a packet, the destination can be found in the flow allocator's flow table. This is motivated by the following observations:
# Intermediate forwarding functions do not need to know the source address to forward a packet to the destination
# The rate of change of the source address (if at all) is generally much lower than the packet rate
# Since this field is not needed for forwarding, the source address is rife for abuse

The edge case where an application needs to send a single packet to a destination, or very infrequently, can be covered by piggybacking data on the first flow allocation message.

==== Protocol/Next Header ====
The protocol (IPv4) / Next Header (IPv6) field identifies the protocol on top of the Internet Protocol, which is a clear layer independence violation. ODTP has an Endpoint Identifier field that combines the Protocol and Port functions, and is (nearly) always 'ephemeral'.

==== Length ====

Not needed, because the syntax of the ODTP network forwarding layer protocol is agreed during enrollment.

== Implementation ==

The implementation of this protocol is part of the unicast IPCP, and is complete, pending some optimizations.

Ouroboros Data Transfer Protocol

2026-07-11T20:43:28Z

Dimitri: /* Protocol Header */

The Ouroboros Data Transfer Protocol (ODTP) is the ''hop-by-hop'' protocol that forwards packets to their destination, and is similar to the Internet Protocol, but with further simplifications.

ODTP is internal to the [[Data Transfer Component]] in the unicast IPCP. The details of this protocol do not need to be known outside these modules, not to the other components of a unicast IPCP, not to the IRMd, and definitely not to the upper layer application.

== Protocol Header ==

The field widths are not that important, but an optimized version should take into account memory alignment. The Data Transfer Protocol has 3 fields associated with the Data Transfer Component (the network forwarding layer in the model), and 2 fields associated with the flow allocator (the end-to-end network layer in the model).

<syntaxhighlight>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-to-Live | QoS | ECN | CAP8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ EID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ N + 1 Data +
. .
. .
</syntaxhighlight>

=== Fields associated with the network forwarding layer ===

==== Destination address ====

This specifies the address to forward the packet to. The width of this field is configurable based on various preferences and the size of the envisioned network. The Ouroboros default is 64 bits.

==== Time-to-Live ====

Similar to IPv4 (in IPv6 this field is replaced by the Hop Limit), this is decremented at each hop to ensures that packets don’t get forwarded forever in the network, for instance due to (transient) loops in the forwarding path. The Ouroboros default for the width is one octet (byte), limiting the Maximum Packet Lifetime in the network to 255 seconds. The initial TTL value for a flow can be based on the maximum delay requested by the application.

==== QoS ====

Ouroboros supports Quality of Service via a number of methods, and this field is used to prioritize scheduling of the packets when forwarding. For instance, if the network gets congested and queues start filling up, higher priority packets (e.g. a voice call) get scheduled more often than lower priority packets (e.g. a file download). By default this field is one octet long.

=== Fields associated with the network end-to-end layer ===

==== EID ====

The Endpoint Identifier (EID) field specified the endpoint for which to deliver the packet. This endpoint uniquely identifies an application/service at the destination, so this field is not identical in function to the ''protocol'' or ''next header'' field in IPv4 or IPv6, but rather it more akin to the function of the (ephemeral) ''port'' field in UDP or TCP. Note that

# There is no reason for an N-layer protocol to know anything about the (N + 1)-Layer protocol it is transporting (nor the other way around).
# There are no ''well-known'' Endpoint IDs; every application flow has random EIDs and there is no relation between an EID and an application type.

The width of this field is configurable, but for security, it should be reasonably long to avoid an attacker guessing valid EID values (the figure shows 64 bits, which is the value used in the prototype). For efficiency, it should be easy to map and EID to a flow descriptor at the endpoints. The value of this field is chosen locally by each endpoint IPCP during flow allocation.

While Ouroboros does not have well-known EIDs, it does have a notion of ''reserved EID''s for functions that are ''internal'' to an N-layer, such as the [[Flow Allocator | flow allocator]] and the [[directory]]. These EIDs should not be fixed, unique for the layer and can be communicated during Enrollment.

==== ECN ====

This field specifies Explicit Congestion Notification (ECN), with similar intent as the ECN bits in the Type-of-Service field in IPv4 or Traffic Class field in IPv6. The Ouroboros ECN field is by default one octet wide, and its value can be set to an increasing value as packets are queued deeper and deeper in a congested routers’ forwarding queues. Ouroboros enforces Forward ECN (FECN). See [[Congestion Avoidance]].

==== CAP8 ====

This field specifies the capacity of the link that is flagged by Explicit Congestion Notification (ECN). See [[Congestion Avoidance]].

=== Notable fields not present in ODTP ===

==== Version ====

There is no need for a version field in the ODTP protocol, even if future changes to the fields are made, or other fields are added. The Data Transfer protocol specification is agreed between IPCPs during [[enrollment]].

==== Source address ====

There is no need for a source address in the header. The source address is exchanged during [[Flow Allocation | flow allocation]], and when sending a packet, the destination can be found in the flow allocator's flow table. This is motivated by the following observations:
# Intermediate forwarding functions do not need to know the source address to forward a packet to the destination
# The rate of change of the source address (if at all) is generally much lower than the packet rate
# Since this field is not needed for forwarding, the source address is rife for abuse

The edge case where an application needs to send a single packet to a destination, or very infrequently, can be covered by piggybacking data on the first flow allocation message.

==== Protocol/Next Header ====
The protocol (IPv4) / Next Header (IPv6) field identifies the protocol on top of the Internet Protocol, which is a clear layer independence violation. ODTP has an Endpoint Identifier field that combines the Protocol and Port functions, and is (nearly) always 'ephemeral'.

==== Length ====

Not needed, because the syntax of the ODTP network forwarding layer protocol is agreed during enrollment.

== Implementation ==

The implementation of this protocol is part of the unicast IPCP, and is complete, pending some optimizations.

Ouroboros Protocols

2026-07-11T20:41:40Z

Dimitri: /* Data Transfer Protocol */

{{Under construction}}

The protocols in Ouroboros are designed with strong adherence to the principles of [https://en.wikipedia.org/wiki/Separation_of_concerns separation of concerns] and [https://en.wikipedia.org/wiki/Separation_of_mechanism_and_policy separation of mechanism and policy] in mind to prevent network ossification and protocol ossification from occuring.

There are 5 core protocols in Ouroboros.

== Data Transfer Protocol ==
Main page: [[Ouroboros Data Transfer Protocol]]

The Data Transfer Protocol resides in the [[Ouroboros Functional Layering|network forwarding layer]].

<syntaxhighlight>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-to-Live | QoS | ECN | CAP8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ EID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ N + 1 Data +
. .
. .
</syntaxhighlight>

== Flow encryption header ==

Every encrypted packet is a fixed-size cleartext '''selector''' header,
followed by the AEAD ciphertext of the inner FRCP packet, followed by
the AEAD authentication '''tag'''.

<syntaxhighlight lang="text">
+----------------+------------------------------+--------------+
| selector (6 B) | E(inner FRCP packet) | tag (16 B) |
+----------------+------------------------------+--------------+
\__ cleartext _/ \______ ciphertext __________/ \__ cleartext _/
\________________ authenticated (AAD + AEAD) ________________/
</syntaxhighlight>

;selector
:6-octet cleartext key-selection header. It is read '''before''' decryption to select the key and reconstruct the nonce, and it is bound into the AEAD as Associated Data.
;ciphertext
:AEAD encryption of the inner packet under the selected sub-key and reconstructed nonce.
;tag
:AEAD authentication tag, 16 octets (128 bits) for AEAD ciphers; absent for non-AEAD ciphers.

== Flow and Retransmission Control Protocol ==
Main page: [[Flow and Retransmission Control Protocol]]

The Flow and Retransmission Control Protocol resides in the [[Ouroboros Functional Layering|application end-to-end layer]].

<syntaxhighlight>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | hcs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ackno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload (variable) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

flags - feature/type bitmap (see 1.2).
hcs - CRC-16-CCITT-FALSE Header Check Sequence (HCS) over
flags + window + seqno + ackno (+ stream extension when
present); the two octets of the hcs field itself are
omitted from the CRC input. Verified on receive before
any flag-driven dispatch.
window - receiver-advertised right window edge (valid iff FC).
seqno - per-flow sequence number.
ackno - cumulative Acknowledgement (ACK) (valid iff ACK).
</syntaxhighlight>

== Flow Allocation Protocol ==
Main page: [[Ouroboros Flow Allocation Protocol]]

/*
* 0 1 2 3
* 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
* | | |
* + + |
* | | |
* + id (128 bits) + |
* | Unique flow allocation ID | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | | |
* + timestamp (64 bits) + |
* | UTC nanoseconds since epoch | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | crt_len (16 bits) | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | | |
* + certificate (variable) + |
* | X.509 certificate, DER encoded | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* |F|R| kex_len (14 bits) | | | Signed
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | | | Region
* + kex_data (variable) + |
* | public key (DER/raw) or ciphertext (KEM) | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | cipher_len (16 bits) | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | | |
* + cipher (variable) + |
* | symmetric cipher name (UTF-8) | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | data_len (16 bits) | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | | |
* + data (variable) + |
* | Piggybacked application data | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
* | sig_len (16 bits) | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
* | |
* + signature (variable) +
* | DSA signature over signed region |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*
* kex_len field bit layout:
* F (bit 15): Format - 0 = X.509 DER, 1 = Raw/Hybrid
* R (bit 14): Role - 0 = Server encaps, 1 = Client encaps
* (R is ignored for non-KEM algorithms)
* Bits 0-13: Length (0-16383 bytes)
*/
The Flow Allocation Protocol resides in the [[Ouroboros Functional Layering|network end-to-end layer]].

== Connection Establishment Protocol ==
Main page: [[Ouroboros Connection Establishment Protocol]]

== Enrollment Protocol ==
Main page: [[Ouroboros Enrolment Protocol]]

The Enrollment protocol is best seen as one of the application protocols for IPCPs.

Congestion avoidance

2026-07-11T20:39:27Z

Dimitri: Created page with "{{DISPLAYTITLE:mb-ecn - Multi-bit ECN Congestion Avoidance}} mb-ecn is a congestion-avoidance (CA) policy for the Ouroboros unicast IPCP. It lives in the IPC Process: the flow-and-retransmission task (FRCP) provides reliability, in-order delivery and flow control end-to-end; congestion avoidance is orthogonal and runs per IPCP layer. Within a layer, the IPCP controls '''aggregates''', one loop per (destination address, QoS cube), shared by every flow toward that destina..."

{{DISPLAYTITLE:mb-ecn - Multi-bit ECN Congestion Avoidance}}

mb-ecn is a congestion-avoidance (CA) policy for the Ouroboros unicast
IPCP. It lives in the IPC Process: the flow-and-retransmission task
(FRCP) provides reliability, in-order delivery and flow control
end-to-end; congestion avoidance is orthogonal and runs per IPCP
layer. Within a layer, the IPCP controls '''aggregates''', one loop
per (destination address, QoS cube), shared by every flow toward that
destination. The alternative policy is <code>nop</code> (no congestion
avoidance).

This document describes the algorithm: what the policy does and why.
The implementation follows it ([[#12. References|Section 12]] maps the
pieces to source files). It does not claim properties the algorithm
does not have; [[#8. Limitations|Section 8]] states the known gaps
explicitly.

The keywords "MUST", "SHOULD", "MAY" etc. are used only where they
appear in all capitals, per BCP 14 (RFC 2119, RFC 8174).

== Notation ==

;<code>r</code>
:Paced send rate, bytes per second.
;<code>C</code>
:Bottleneck capacity, bytes per second.
;<code>S</code>
:Packet size in bytes.
;<code>q</code>
:Standing queue occupancy at the bottleneck, in packets.
;<code>Q</code>
:Marking quantum, packets per mark unit (4).
;<code>ecn</code>
:Per-packet congestion mark set by a forwarder, an unsigned integer
(on-wire field is 8-bit).
;<code>ece</code>
:Receiver-side congestion estimate, fixed point with LSB = 1/32 of an
<code>ecn</code> unit, i.e. <code>ece = 32 × (time-mean ecn)</code>.
;<code>cap8</code>
:Path-capacity code carried per packet, quarter-log2:
<code>C ≈ 2^(cap8 / 4)</code> bytes/s, 0 = unknown.
;<code>W</code>
:Receiver averaging window, nanoseconds.
;<code>a</code>
:Additive-increase slope, bytes/s per second.
;<code>M</code>
:Full-congestion reference level of <code>ece</code> (512).
;<code>Δt</code>
:Elapsed wall-clock time between two events, nanoseconds.
;<code>τ</code>
:Path round-trip time (feedback delay). The controller does not
measure it.

Rate is the control variable throughout.

All concrete figures in this document — window bounds, horizons,
rate thresholds — are instances of the parameter values in
[[#11. Parameters|Section 11]]. The mechanisms and the relations
between parameters are what the algorithm fixes; retuning the
parameters moves the figures together.

__TOC__

== 1. Overview ==

mb-ecn is a rate-based, ECN-driven controller with three moving parts,
one at each point of the loop:

<pre>
sender forwarder
+--------------------------------+ +--------------------------+
| SFQ virtual-clock pacer | | ecn = MAX(ecn, queue/Q) |
| rate r, paced per packet | data | (deepest queue wins) |
| AIMD + PD control on r |------>| cap8 = MIN(cap8, link) |
+--------------------------------+ +--------------------------+
^ |
| ece + cap8 feedback | marked data
| v
+--------------------------------+ +--------------------------+
| reads downstream ece, |<------| receiver |
| updates the rate on feedback, | ece | time-mean of ecn over |
| scales floor/slope to cap8 | cap8 | an adaptive window |
+--------------------------------+ +--------------------------+
</pre>

# The '''forwarder''' marks each packet with a ''multi-bit'' magnitude
proportional to its standing queue, and MIN-stamps its measured
outgoing-link capacity into the same PCI.
# The '''receiver''' turns the stream of marks into a time-averaged
congestion estimate <code>ece</code> and feeds it back to the sender,
together with the window minimum of the path-capacity codes.
# The '''sender''' paces its rate with a start-time fair-queuing (SFQ)
virtual clock, and adjusts that rate with additive-increase /
multiplicative-decrease (AIMD) driven by <code>ece</code>; the rate floor
and the additive slope derive from the fed-back path capacity.

The controller runs on packet sends and on feedback arrivals. All
increase/decrease steps are scaled by elapsed
wall-clock time, which is what makes the ''allocation'' independent of
RTT (see [[#6. RTT behaviour|Section 6]]).

The unit of control is the '''aggregate''', kept in the IPCP per
<code>(destination address, QoS cube)</code>. Every flow toward that
destination at that QoS shares one controller and one rate: a new
flow joins the aggregate at its current rate, and a departing flow
leaves the rate to the others. The pacer divides the aggregate rate
fairly across the member flows (SFQ), so per-flow fairness within an
aggregate is a scheduler property, distinct from the rate law
described here.

== 2. Forwarder marking ==

A forwarder marks a packet as a function of the packets already queued
on the outgoing link:

mark = queued / Q (Q = 4 packets)
ecn = MAX(ecn, mark) (saturating, 8-bit field)

The quantum <code>Q</code> is a layer-wide constant: the marks it
quantizes are combined by MAX across hops, so all forwarders in a
layer MUST use the same quantum for the signal to be comparable.

Two properties:

* '''Multi-bit magnitude.''' The mark is an integer proportional to
queue depth, quantized in steps of <code>Q</code> packets: a coarse
readout of the standing queue.
* '''MAX along the path.''' A packet crossing several forwarders carries
the maximum mark, i.e. the deepest queue on its path. MAX keeps the
signal range-stable and monotone across hops.

There is a '''dead zone''': for <code>queued < Q</code> the mark is 0.

=== Capacity stamping ===

Each forwarder also measures the capacity of its outgoing link and
stamps it into the packet. The estimate is a busy-period drain rate:
the queue is observed at most once per millisecond, and a measurement
window stays open until 16 packets have drained, so its length
'''self-scales with the link rate''' — the millisecond cadence
bounds it on fast links, the 16-packet drain time on slow ones
(~19 ms at 10 Mbit/s). A window in which more than 1/8 of
the arrivals found the queue empty is discarded as unsaturated;
occasional empty observations (token-bucket shapers grazing zero) are
tolerated. The drain rate of a saturated queue is the link rate; a max
filter with slow decay (1/16 per window) converges on it from below. A
window that opened or closed on an empty queue may have drained into
buffers below at above-wire rate, so it may lower the estimate but
never raise it. The code on the wire is quarter-log2
(<code>cap8 = 4 log2 C</code>, ~19% per step, 0 = unknown) and each hop
MIN-combines its own code into the byte, so a packet arrives carrying
the bottleneck's rate. A hop that has never been backlogged stamps
nothing; since only backlogged hops matter, the signal exists exactly
when it is needed.

== 3. Receiver estimate ==

The receiver converts marks into a smoothed estimate <code>ece</code> over a
time window <code>W</code> that '''adapts to the incoming byte rate'''. It is
a '''boxcar (rectangular) time-integral mean'''. Per packet, with
<code>Δt</code> the gap since the previous packet:

A += ecn * MIN(Δt, W) dwell-weighted; one packet
weighs at most one window
B += S accumulate bytes this window
...
at window close (elapsed >= W, or B >= 2 * B_target with at
least the window floor elapsed):
ece = 32 * A / elapsed mean over the actual window
W += (B_target * elapsed / B - W) / 4 nudge toward the size
that holds the target
W = clamp(W, ~1.05 ms, ~4.3 s)
A = 0 ; B = 0 hard reset

At each close the next window is nudged by a quarter-weight moving
average toward the size that would hold about 16 packets at the
measured byte rate, from an initial ~67 ms. The target is byte-based (<code>B_target</code> = 16,000 bytes), so
"16 packets" is exact only at ~1000-byte packets, and the window
converges to it over several closes. The mean always divides by the
'''actual''' elapsed window, so a rate step leaves the current
estimate exact and only re-sizes the ''next'' window. The effect is a roughly constant sample
count — ~16 packets — from about 30 kbit/s to 122 Mbit/s;
above that the window floors at ~1 ms (a cadence still carrying
thousands of samples at 10–100 GbE), and below ~30 kbit/s it
saturates at the ~4.3 s ceiling. The averaging clock stretches with
the flow the way TCP's ACK clock stretches with the RTT. A speed-up
escapes a stretched window early: once twice the target bytes arrive
the window closes anyway (the window floor keeps that cadence bounded
at high rate). The fed-back <code>ece</code> is thus a piecewise-constant
staircase whose step period tracks the rate. Two edge cases:

* '''Onset''' (first mark after an idle estimate) emits the
instantaneous mark undiluted, so a starting queue is reported without
a full window of delay.
* '''Gap''' longer than 4 windows resets the window and emits the raw
sample. The threshold is '''rate-relative''': idle means a few
''current'' windows of silence, so a slow flow's normal inter-packet
gap never reads as idle, while the in-window dwell clamp above bounds
what a genuine pause can add to the mean before the restart fires.

Alongside the mark integral, the receiver keeps the MIN of the nonzero
capacity codes seen in the current window; each emitted <code>ece</code>
carries that minimum (the raw packet's code on onset/gap restarts) and
the fold then resets, so a reroute to a faster path can raise the
fed-back capacity within one window.

The estimate is fed back to the sender on the reverse flow.

== 4. Sender pacer ==

The sender paces with an SFQ virtual clock. The context keeps a
virtual time <code>V</code>; each flow keeps a finish tag <code>F</code>:

V += r * Δt virtual time advances by bytes served
s = MAX(F, V) a packet behind the clock starts now
F = s + S the one after it queues behind
wait = (s - V) / r time until this packet may go

The <code>wait</code> becomes the flow's scheduling deadline: a packet
already behind the virtual clock is sent immediately
(<code>wait = 0</code>); one ahead waits, deferring only its own flow.
A clock advance across an idle gap longer than 50 ms credits at most
the calling flow's owed lead plus one burst (50 ms of service, at
least one packet): a paced flow slower than one packet per 50 ms
receives its '''true''' elapsed service — a time-capped credit
would decay such a flow without bound — while an idle flow still
cannot bank an unbounded burst.

The virtual time <code>V</code> is shared by every flow in the context;
the finish tags are per flow. Because every flow computes its start
tag <code>s</code> against the same <code>V</code>, a flow that has just sent
carries a finish tag ahead of <code>V</code> and waits, while an idle flow
(finish tag at or behind <code>V</code>) starts immediately — this is
what fairly divides the aggregate rate <code>r</code> across them.

== 5. Rate control (AIMD + PD) ==

The rate law runs on packet sends, at most once per millisecond, and
also on feedback arrivals so that a sender with no traffic of its own
still reacts. Each increase term and the proportional decrease are
scaled by elapsed wall-clock time, each by its own clock: the
increase terms use time banked and '''capped''' at 50 ms (an idle gap
cannot bank an unbounded ramp), while the proportional decrease uses
the '''uncapped''' elapsed time (a starved sender still cuts by the
right amount). The one-sided derivative (Section 5.3) is a per-delta
term.

=== 5.1. Slow start ===

Before the first congestion signal the rate ramps exponentially with a
20 ms time constant:

r += r * Δt / T_ss (T_ss = 20 ms)

Slow start ends the first time a congestion signal arrives —
fed back from the receiver or observed at the sender's own first hop
— and never resumes.

Slow start belongs to the aggregate, so it runs '''once per
(destination, QoS cube)''', on the first flow. A flow arriving at an
established aggregate rides the existing estimates: it enters at the
aggregate's current rate and receives its fair share of it through
the pacer (Section 4), with no probing of its own.

=== 5.2. Increase: additive plus proportional probe (always on) ===

Past slow start, two increase terms are applied every step, both
regardless of congestion:

r += a * Δt additive; a defaults to 2^16 B/s^2
r += r * Δt / T_probe proportional; T_probe = 8 s

The additive term is a fixed per-context slope (bytes/s per second),
scaled to the path capacity (Section 5.5). The proportional probe
grows the rate by a fixed fraction per unit time (e-folds over
<code>T_probe</code>): a flow recovers in the same number of steps at any
link rate; the fixed additive term's effect vanishes relative to a
fast link. Both are the "probing"
pressure the multiplicative decrease balances at equilibrium; the
probe's cost is a rate-independent standing-queue floor (Section 7).

=== 5.3. Multiplicative decrease (proportional + derivative) ===

With congestion level <code>m</code> (the fed-back <code>ece</code>, or a local
first-hop mark as fallback), the decrease is the sum of a proportional
term and a one-sided derivative term — a PD controller on the
congestion signal:

mark = MIN(m, M) M = 512
rise = MAX(m - m_prev, 0), capped at M one-sided derivative

cut = r * rise / (4 * M) derivative, gain 1/4
cut += r * mark * Δt_ms / (1000 * M) proportional
cut = MIN(cut, r / 2) at most a halving

r -= cut
m_prev = m

* The '''proportional''' term is scaled by honest elapsed time in
milliseconds, so a starved sender that has not run the controller
for a while still cuts by the right amount.
* The '''derivative''' term (<code>rise</code>) reacts to an ''increase'' in
the congestion level between samples; it is one-sided and per-delta.
It sharpens the reaction at the onset of congestion.
* The cut is clamped to <code>r/2</code> per step, bounding the decrease to
a halving.

<code>M = 512 = 32 × 16</code> defines "full congestion" as a mean
<code>ecn</code> of 16, i.e. a mean queue of <code>16 × Q = 64</code> packets.

=== 5.4. Staleness ===

Feedback arrives once per receiver window, and the window stretches
with the flow's byte rate (Section 3) — so the staleness horizon
must stretch with it, or a slow flow's mark would age out ''between''
feedbacks and the rate would ramp against a congested path. The
sender mirrors the receiver: the horizon is four target windows of
bytes at the current rate, floored at ~268 ms so fast flows keep a
fixed horizon; at the default rate floor it is ~8 s. A signal older
than the horizon is aged out (both the fed-back estimate and the
local mark), freeing the rate to ramp once congestion clears. The
rate is clamped to
<code>[r_min, r_max]</code> on every step.

=== 5.5. Capacity-derived floor and slope ===

The fed-back capacity code sets the two rate-scale constants of the
controller, per context:

target = decode(cap8) / 32 clamped to [2^13, 2^32] B/s
r_min += (target - r_min) / 2 per feedback (moving average)
a = r_min

The defaults are fixed constants (<code>r_min = 2^13 B/s</code>,
<code>a = 2^16 B/s^2</code>), used on paths that never report a capacity;
with the estimator live the fairness floor and the post-cut recovery
slope scale with the bottleneck, and capacity engages wherever
<code>C/32</code> clears the default floor, i.e. above ~2 Mbit/s. A
capacity older than 16 staleness horizons (~4.3 s for fast flows)
reverts both to the defaults. That horizon deliberately outlives the
feedback horizon: feedback stops the moment the marks clear, which is
exactly when the recovery slope is needed; the onset-fresh capacity
(Section 3) re-seeds it on the first mark of the next episode either
way.

=== 5.6. Ramp and recovery ===

Three mechanisms set how fast an aggregate reaches a fast link's
rate, each owning one regime:

* '''From scratch: slow start.''' The exponential ramp reaches any
physical link rate in well under a second (~200 ms from the seed to
10 Gbit/s; each further doubling of link speed costs one more
~14 ms doubling time). On an uncongested path nothing marks, so
slow start runs until the aggregate arrives at its bottleneck.
* '''After a cut: the probe.''' A decrease is at most a halving per
step, and the mark ages out on the rate-relative horizon once
congestion clears (Section 5.4); the proportional probe then heals
a halving in <code>T_probe · ln 2 ≈ 5.5 s</code> at any
link rate.
* '''At the bottom: the capacity floor.''' The rate sits at most a
factor 32 below a measured bottleneck, and the additive slope
refills <code>C/32</code> per second, so the deepest hole is bounded:
floor to full capacity in tens of seconds, a halving in seconds.

These compose because a deep cut requires sustained congestion,
sustained congestion backlogs the bottleneck queue, and a backlogged
queue is exactly when its capacity is measured and stamped
(Section 2): whenever the controller is cut deep, the scaled floor is
live. The default floor only governs paths that never congested the
sender — where there is nothing to recover from. This is why
slow start can end for good: the floor and the probe cover every
later recovery.

=== 5.7. Regimes ===

<pre>
+-------------+ first mark seen +----------------+
| slow start |--------------------->| congestion |
| r *= e^(t/T)| | avoidance |
+-------------+ | |
| m == 0 ---> additive increase
| m > 0 ---> AI + PD decrease
+----------------+
m = fed-back ece, or the local first-hop mark when ece == 0
</pre>

== 6. RTT behaviour ==

Because every increase and decrease is scaled by wall-clock time,
two flows of different RTT that share a bottleneck obey the ''same''
rate law and converge to the ''same'' rate. The steady-state
'''allocation is RTT-independent'''.

This is a property of the equilibrium, not of the dynamics. The
feedback delay in the loop ''is'' the path RTT <code>τ</code>, and the
controller does not measure or compensate for it. At low rate the
receiver window (up to its ~4.3 s ceiling) is the dominant lag —
the loop is slow there in proportion to how slow the flow is, exactly
as a long-RTT TCP is — while as the rate rises the window shrinks
toward its ~1 ms floor, so the window's contribution to the loop delay
''falls'' with capacity and the path RTT <code>τ</code> becomes the
irreducible term. Two mechanisms keep the loop damped: the adaptive
window removes the delay-dominated corner at low <code>τ</code>, and a
bucketed '''rate-velocity damping''' (a washout: each ~31 ms bucket
pulls the rate a quarter of the way back toward its value at the
previous bucket) supplies the damping the otherwise
near-double-integrator lacks, which is what holds the loop together at
high capacity and moderate <code>τ</code>. What remains is the loop gain
<code>√G &prop; √C</code>: at very high capacity ''and'' large
<code>τ</code> the <code>√G · τ</code> phase budget is the
binding constraint, and no window or damping trick removes it (see
[[#8. Limitations|Section 8]]). A precise statement is therefore:
'''RTT-fair in equilibrium, and dynamically stable up to a
capacity-dependent RTT limit set by <code>√G · τ</code>.'''

== 7. Fairness ==

At equilibrium the two increase terms balance the proportional
decrease, <code>a + r/T_probe = r · m*/M</code>, which pins the
congestion level to <code>m* = M · (a/r + 1/T_probe)</code> and, since
<code>ece = 8q</code> (one mark unit per <code>Q = 4</code> packets, 32 fixed-point
steps per unit), a standing queue of

q* = 64 * a / r + 64 / T_probe (packets, r in bytes/s)

The additive part (<code>64 · a / r</code>) vanishes with rate under
the default slope; with the capacity-derived slope (<code>a = C/32</code>,
Section 5.5) it becomes <code>2 C / r</code> — about two packets per
competing flow, rate-independent. The proportional-probe part
(<code>64 / T_probe</code>) is a rate-independent floor (~8 packets at
8 s). That floor is the cost of rate-independent convergence, and it
keeps <code>q*</code> above the marking threshold at high rate.

Two flows at the same bottleneck see the same <code>m*</code>, so each
solves <code>r_i = a / (m*/M - 1/T_probe)</code> to the same rate. Under
the network-utility-maximization view this corresponds to
'''proportional fairness''' (equal weights), which is max-min fair at
a single bottleneck.

Measurement fidelity at low rate comes from the estimator itself:
the averaging window stretches with the flow
(Section 3), so a CA-limited flow keeps ~16 packets per window at any
rate down to ~30 kbit/s, and the rate-relative gap threshold keeps its
inter-packet spacing from reading as idle. The default floor
(<code>2^13</code> B/s) only bounds the extremes (window ceiling,
staleness horizon, pacer arithmetic). The floor scales with the
fed-back path capacity (<code>r_min = C/32</code>, Section 5.5), so
roughly 32 CA-limited flows fit above it at any link class. Flows
whose paths differ in bottleneck class derive different slopes, so
fairness across them is capacity-weighted; see
[[#8. Limitations|Section 8]].

== 8. Limitations ==

These are properties the algorithm does '''not''' have. They are
listed so the policy is not credited with more than it does.

* '''Queue-only signal; no bandwidth/rate term.''' The reference
<code>M</code> is a queue level, so mb-ecn is a standing-queue
controller: it must build a queue (<code>q* = 64 · a / r +
64 / T_probe</code>) to see any signal, and cannot hold high utilization
at an empty queue the way a controller with a rate/bandwidth estimate
can. The proportional-probe floor (~8 packets) keeps <code>q*</code>
above the marking threshold at all rates, at the cost of a persistent
standing queue.

* '''Aggregation is per destination, per QoS cube.''' The aggregate
stands in for the path: flows toward the same destination are
assumed to share their bottleneck, and flows toward different
destinations keep independent loops even when they queue at the
same hop. Each such loop converges to its own fair share
(Section 7), so the cost is duplicated state and probing at the
shared queue rather than unfairness. A future option is to identify
the queue in the packet: a forwarder stamping a queue identifier
alongside its mark would let senders key their aggregates on the
actual bottleneck rather than on the destination, pooling the
estimate and the probing across everything that queues there.

* '''Capacity is learned, with gaps.''' The floor and slope scale with
an in-band path-capacity estimate (Sections 2, 5.5), but the estimate
has limits of its own. A hop only learns its link rate while its
queue is backlogged, so a rerouted or freshly established bottleneck
contributes ''unknown'' at first and the path MIN can transiently
come from faster hops (the sender's smoothing and the next feedback
bound the excursion). The drain measurement is order-of-magnitude by
design: quarter-log2 code (~19% per step), burst noise bounded by a
16-packet minimum window and a max filter, nothing learned below
~120 packets per second of busy drain (16 packets inside the
~134 ms staleness cap; at MTU that is ~1.4 Mbit/s, below which
capacity/32 would sit under the default floor anyway). The derived
floor clamps to <code>[2^13, 2^32]</code> B/s, and flows with
different path bottlenecks get capacity-weighted, not equal, shares
at a common queue (Section 7).

* '''The low end trades reactivity, not correctness.''' Below
~30 kbit/s the averaging window clips at its ~4.3 s ceiling and
holds fewer samples; below ~64 kbit/s of offered load an
''app-limited'' flow spaces packets past the gap threshold and rides
the raw onset branch, as it always did. Feedback cadence and the
staleness horizon at the floor are seconds — a slow flow
converges slowly, TCP-style; nothing diverges, but nothing is fast
either.

* '''No loss response.''' The controller reacts only to ECN marks. Loss
is handled by FRCP retransmission, out of the CA's view. At a bottleneck
that drops instead of marking (e.g. a classic drop-tail queue at the
Ethernet/UDP shim), mb-ecn sees no signal and additive increase keeps
ramping. mb-ecn is intended for Ouroboros-native bottlenecks where the
forwarder marks; it does not implement a classic-bottleneck fallback.

* '''Dynamic stability has a capacity-dependent RTT limit.''' As stated
in Section 6, the allocation is RTT-independent but the dynamics are
not: the binding constraint is <code>√G · τ</code> with
<code>√G &prop; √C</code>. The adaptive window and the washout push
this limit out substantially (e.g. a single flow at 10 GbE stays stable
to ~50 ms RTT in the fluid model), but the extreme long-fat-network
corner (100 GbE at ≥ 50 ms) is not reachable by a window/damping
controller and would need explicit-rate signalling.

* '''Fluid-model caveat.''' The offline model in the simulation tooling
captures the aggregate rate law (sawtooth, standing queue) with a
boxcar receiver, but sizes the adaptive window in the rate domain
rather than the byte-folded form of the algorithm above, and treats
all flows identically, so it is a guide to stability ''trends'', not
a fairness or exact-quantitative oracle at high link rate.

== 9. Architectural fit ==

Each property the preceding sections build toward attaches to a
structural feature of the recursive architecture. This section makes
the mapping explicit.

* '''Congestion avoidance is fully orthogonal to ARQ and to flow
control.''' Three concerns, three mechanisms, two scopes: FRCP
provides retransmission (ARQ) and flow control (the peer pacing the
sender) end-to-end, per flow; congestion avoidance runs in the
IPCP, per aggregate. Each signal means one thing. A loss triggers
a retransmission and nothing else — a lossy link reads as
lossy, with the congestion verdict left to the marks (Section 8's
"no loss response" is this orthogonality stated from the other
side). The peer's flow-control window paces the endpoint and
nothing else — back-pressure from a slow receiver stays
distinct from congestion in the network. A retransmitted packet is
ordinary traffic to the pacer. TCP folds all three into one window
machine, where the receive window bounds the congestion window and
loss serves as both reliability trigger and congestion signal;
here each mechanism can be reasoned about, tested and evolved
alone.
* '''Congestion avoidance sits below application choice.''' Every
flow in the layer is paced by the same rate law, whatever its QoS:
a greedy raw sender shares a bottleneck fairly with a reliable
stream because the control is a property of the layer, on the
aggregate, rather than a courtesy of the endpoint transport.
* '''A layer defines its own PCI, so the signal can be rich.'''
Every member of a layer is enrolled into it: the layer is a single
administrative domain by construction, at whatever scope it spans,
and its header is layer-internal. Forwarders therefore write a
multi-bit queue magnitude and a capacity byte directly into the
packet. The datacenter schemes of
[[#10. Heritage and positioning|Section 10]] require exactly such a
domain and find it only inside one operator's fabric; a recursive
layer supplies it everywhere.
* '''Layer-internal addressing makes the aggregate well-defined.'''
Flows in a layer run between layer addresses, so the
(destination, QoS cube) aggregate — RFC 3124's macroflow
— falls out of the naming structure. Controller state scales
with destinations, and each QoS cube keeps its own loop, so
service classes keep separate fates.
* '''Flows are allocated, so feedback has a channel.''' Every flow
has state at both ends and a reverse direction; the receiver's
<code>ece</code> and the path capacity ride the flow allocator's
existing exchange.
* '''There is no transport ack clock, and none is relied on.''' The
layer must control raw flows, which carry no acknowledgements at
all, so the controller paces on wall-clock time — and that
constraint yields the RTT-independent allocation of Section 6. An
architectural restriction becomes the controller's distinguishing
property.
* '''Recursion scales the scheme.''' Each layer controls congestion
over its own scope and timescale; many N-flows ride one N-1 flow,
so aggregation compounds down the stack. The capacity a layer
measures at its egress queue is the rate the layer below actually
provides — a paced, shared lower flow rather than a nominal
wire speed — so the signal stays meaningful at every level,
and pushback cascades layer by layer.

The fit has a boundary: at a shim over legacy media the layer below
neither enrolls nor marks, which is the deployment edge behind
Section 8's no-loss-response limitation.

== 10. Heritage and positioning ==

mb-ecn is best understood as a rate-based ECN controller in the DECbit /
QCN line, adapted to an acknowledgement-less recursive layer.

The core of the scheme dates to the first Ouroboros
congestion-avoidance policy (2020): a multi-bit queue-depth mark
relayed by forwarders to the receiver, a smoothed multi-bit
<code>ece</code> fed back on the reverse flow at the same 1/32 fixed
point used today, and a sender that paced packets from a time budget
and ran slow start, additive increase and multiplicative decrease on
wall-clock time slots — rate-based and acknowledgement-free from
the start, with RTT-independent allocation already an objective. The
present algorithm keeps that skeleton and reworks every estimator
around it: per-path aggregation with SFQ pacing, the rate-adaptive
boxcar receiver, elapsed-time-scaled AIMD with a derivative term and
rate-velocity damping, and the in-band capacity signal.

* '''DECbit''' (Ramakrishnan & Jain, 1988; ToCS 1990) established
binary congestion feedback set by the switch on queue occupancy.
mb-ecn keeps the switch-sets-on-queue idea and carries a
''magnitude''.
* '''The Congestion Manager''' (Balakrishnan et al., SIGCOMM 1999;
RFC 3124, 2001) aggregates congestion state at the end host: one
controller per macroflow, a scheduler apportioning its rate across
the member streams, and new streams joining at the ensemble's
current state instead of probing from scratch. mb-ecn's
(destination, QoS cube) aggregate is the same idea placed inside
the IPCP: every layer manages its own macroflows, recursively, the
SFQ pacer plays the CM scheduler's role (Section 4), and a joining
flow rides the aggregate's estimates (Section 5.1). The CM gathers
its signal from transport feedback at the edge; mb-ecn reads it
off the wire from the forwarders.
* '''DCTCP''' (Alizadeh et al., SIGCOMM 2010) recovers a queue
magnitude at the endpoint by averaging a single threshold bit. mb-ecn
instead reads the magnitude off the wire, then time-averages it at
the receiver. The additive-increase / proportional-decrease structure
is shared.
* '''QCN''' (IEEE 802.1Qau, 2010) and '''DCQCN''' (Zhu et al., SIGCOMM
2015) contribute the rate-based (not window-based) ECN control
skeleton. mb-ecn's proportional decrease plus a probing increase
mirrors that skeleton; the increase here is wall-clock scaled rather
than byte-counter/timer based.
* '''HPCC''' (Li et al., SIGCOMM 2019) and '''PowerTCP''' (Addanki et
al., NSDI 2022) combine a queue term ''and'' a rate term (via in-band
telemetry or delay). mb-ecn now carries a coarse in-band rate (the
quarter-log2 path MIN, Section 2) but uses it only to scale the
controller's gains; the congestion ''signal'' remains queue-only,
which is still the main functional difference (Section 8).
* '''L4S / TCP Prague''' (RFC 9330–9332, 2023) make
RTT-independence a requirement and use a high-frequency single-bit
signal. mb-ecn shares the RTT-independent ''allocation'' goal but
reaches it by wall-clock-scaled rate control, with a low-frequency
multi-bit signal.

The novel combination is the multi-bit magnitude on the wire fused with
a wall-clock-scaled rate pacer in a setting with no per-flow ack clock.
The trade-off, made explicit above, is a queue-only signal and a
reactivity capped by the averaging window.

== 11. Parameters ==

These are the values every figure in this document instantiates. They
are '''coupled''': the mechanisms compose only while certain relations
hold — the gap-restart horizon at the rate floor must exceed a
packet's service time (or a floor-rate flow restart-loops at onset),
a floor-rate flow's target window must fit under the window ceiling,
the control interval must sit under the damping bucket under the idle
credit cap, the rate floor must not exceed the slow-start seed, and
the derived-floor ceiling must stay under the rate ceiling. Retune
them as a set, against those invariants.

{| class="wikitable"
! Parameter !! Value !! Meaning
|-
| Marking quantum <code>Q</code> || 4 packets || Mark onset and step; layer-wide
|-
| Feedback resolution || 1/32 <code>ecn</code> unit || Fixed-point LSB of <code>ece</code>
|-
| Full-congestion reference <code>M</code> || 512 || Mean queue of 64 packets
|-
| Receiver window target || 16 packets (16,000 bytes) || Samples per window
|-
| Initial receiver window || ~67 ms || Before rate is known
|-
| Receiver window bounds || ~1.05 ms – ~4.3 s || Clamp on <code>W</code>
|-
| Window resize weight || 1/4 || Moving average toward target
|-
| Early window close || 2 × target bytes || Speed-up escape
|-
| Gap restart || 4 windows || Idle horizon (rate-relative)
|-
| Additive slope <code>a</code> (default) || 2^16 B/s^2 || Lower clamp of derived slope
|-
| Probe time constant <code>T_probe</code> || 8 s || Rate-proportional recovery
|-
| Derivative gain || 1/4 || Onset sharpening
|-
| Rate floor <code>r_min</code> (default) || 2^13 B/s || Lower clamp of derived floor
|-
| Slow-start seed rate || 2^16 B/s || Initial rate
|-
| Slow-start time constant || 20 ms || Exponential ramp
|-
| Rate ceiling <code>r_max</code> || 2^37 B/s || Upper clamp
|-
| Capacity scale || <code>C</code> / 32 || Floor and slope from bottleneck
|-
| Capacity smoothing || 1/2 || Moving average per feedback
|-
| Capacity staleness || 16 × feedback horizon || Revert to defaults
|-
| Derived floor ceiling || 2^32 B/s || Upper clamp on derived floor
|-
| Control interval || 1 ms || Minimum spacing of rate updates
|-
| Idle credit cap || 50 ms || Burst allowance / increase banking
|-
| Feedback staleness floor || ~268 ms || Floor of rate-relative horizon
|-
| Damping bucket || ~31 ms || Rate-velocity washout cadence
|-
| Damping fraction || 1/4 || Pullback per bucket
|-
| Estimator fold spacing || 1 ms || Minimum measurement cadence
|-
| Estimator window closure || 16 packets drained || Self-scaling window
|-
| Estimator window staleness || ~134 ms || Discard across traffic gaps
|-
| Estimator idle tolerance || 1/8 of arrivals || Unsaturated-window rejection
|-
| Estimator decay || 1/16 per window || Max-filter convergence from below
|}

== 12. References ==

=== 12.1. Source ===

The implementation follows the algorithm above:

* <code>src/ipcpd/unicast/ca/mb-ecn.c</code>, <code>mb-ecn.h</code> —
receiver estimator, pacer and rate control.
* <code>src/ipcpd/unicast/ca/ops.h</code> — CA policy interface.
* <code>src/ipcpd/unicast/cap.c</code>, <code>cap.h</code> — link-capacity
estimator and quarter-log2 codec.
* <code>src/ipcpd/unicast/dt.c</code>, <code>fa.c</code> — per-hop marking
and stamping, and the feedback carrying <code>ece</code> + <code>cap8</code>.
* <code>src/ipcpd/unicast/psched.c</code> — consumes the pacing deadline.

=== 12.2. Literature ===

* K. K. Ramakrishnan, R. Jain, "A Binary Feedback Scheme for Congestion
Avoidance in Computer Networks" (DECbit), ACM ToCS, 1990.
* H. Balakrishnan, H. S. Rahul, S. Seshan, "An Integrated Congestion
Management Architecture for Internet Hosts", SIGCOMM 1999;
H. Balakrishnan, S. Seshan, "The Congestion Manager", RFC 3124, 2001.
* M. Alizadeh et al., "Data Center TCP (DCTCP)", SIGCOMM 2010.
* Y. Zhu et al., "Congestion Control for Large-Scale RDMA Deployments"
(DCQCN), SIGCOMM 2015.
* R. Mittal et al., "TIMELY: RTT-based Congestion Control", SIGCOMM 2015.
* Y. Li et al., "HPCC: High Precision Congestion Control", SIGCOMM 2019.
* V. Addanki et al., "PowerTCP", NSDI 2022.
* K. De Schepper, B. Briscoe (eds.), "Low Latency, Low Loss, and
Scalable Throughput (L4S)", RFC 9330/9331/9332.
* F. Kelly, "Charging and Rate Control for Elastic Traffic", 1997;
R. Srikant, "The Mathematics of Internet Congestion Control", 2004.

Ouroboros Functional Layering

2026-07-11T20:39:15Z

Dimitri: /* Network end-to-end layer / Flow Allocator */

[[File: O7s Model_01.png|border|right|thumb|frame|Ouroboros network model - functional layering]]

The Ouroboros model is the result of countless architectural refinements made during the (still ongoing) implementation of the Ouroboros prototype. The layered model [[Ouroboros multicast conjecture|treats broadcast/multicast as distinct from unicast]]. All layers in the model have a well-defined service API, which allows them to appear as black boxes to one another.

The unicast model has 5 layers: the '''application layer''', the '''application end-to-end layer''', the '''network end-to-end layer''', the '''network forwarding layer''' and the '''transmission layer'''.

Broadcast is implemented by a '''network flooding layer'''.

Applications request network services using the '''Unicast API''' and/or '''Broadcast API'''.

For unicast, the application end-to-end layer interfaces with the network-end-to end layer via the '''Network IPC API''', which is invisible to the application itself. The network IPC API forms the demarcation line between 'the application' and 'the network'.

The Broadcast API interfaces directly with the network flooding layer. Furthermore, a network (both of the unicast and broadcast variant) is seen as a distributed application, so it also inherits the application end-to-end layer, giving rise to a '''repeating network structure'''.

This page provides an overview of this model as it currently stands, and some insights in how it compares to other models such as the TCP/IP Internet, Location/Identifier split and the Recursive InterNetwork Architecture (RINA).

= Unicast model =

[[Image: O7s Model_Unicast.png|border|right|540px|Ouroboros network model - Unicast]]

== Unicast API ==

The [[Unicast API]] provides the interface for an application to create, manage and destroy unicast flows and read and write from and to these flows. The API is network-agnostic and provides application primitives for synchronous and asynchronous Inter-Process Communication. It supports message-based and (byte)stream-based communication.

== Application end-to-end layer ==
The application end-to-end layer provides the functionality to establish flows and make packet transmission on that flow reliable and secure. Unicast flows are initiated by a client process towards a server process, identified by a [[Glossary#Name|service name]]'''.

The application end-to-end layer can provide the following operations:
* Encryption (Symmetric key)
* Reliability, implemented by the [[Flow_and_Retransmission_Control_Protocol|FRCP protocol]]
** Fragmentation
** In order delivery
** Discarding duplicate packets
** Automated-Repeat Request (ARQ)
** Flow control
* Integrity (hash-based checks such as CRC32)
* Liveness monitoring

All the above functionality is optional, and if reliability (FRCP) is disabled, we call the service a '''raw flow'''.

Establishment of the flow, authentication and symmetric key distribution are implemented using a '''2-way handshake''' each. If the MTU allows, the authentication and symmetric key exchanges can be piggybacked onto the flow establishment request/reply in a single combined 2-way exchange, so within a 1 Round-Trip Time. See [[Flow Allocation]] for more details.

The application end-to-end layer uses the network IPC API to interface into the network end-to-end layer below.

== Network end-to-end layer / Flow Allocator ==
The network end-to-end layer is responsible for creating a ''network flow'' in a suitable Unicast Layer between two Unicast IPCPs (designated the source and destination IPCP) that implements a ''client flow'' (between two ''end-user'' processes, designated the ''client process'' and ''server process''). The source and destination IPCP reside in the same systems as the respective client and server end-user processes.

We often refer to the Network End-to-End layer as the [[Flow allocator|flow allocator]] after the core component in the IPCP that implements it.

It provides four core functions:
# Name-to-address resolution: given a service name, find an address for a suitable IPCP that can serve as a destination for the network flow. The '''directory''' service holds this mapping for the layer.
# Flow allocation: create shared state between the source and destination IPCP associated with a flow
## Multiplexing: generate a local Endpoint Identifier for a flow
## Map this local Endpoint Identifier to the peer address
# [[Congestion avoidance]]: Monitor the network flow for congestion and police throughput as needed.

The network-layer flow allocation exchange maps the application-requested QoS to a network traffic class. The application-level request/response is carried over by the network-level request/response handshake to fit the complete flow allocation process (application-level and network-level) within a single round-trip.

The network end-to-end layer provides the interface for the application end-to-end layer on top, so these two layers always go hand-in-hand.

== Network Forwarding layer ==

The network forwarding layer is responsible for forwarding [[Ouroboros Data Transfer Protocol]] packets from the source IPCP to the destination IPCP, based on their addresses and QoS class.

The '''forwarding function''' takes the destination address and decides on which flow(s) to forward the packet, usually implemented as a table (forwarding table).
In order to do this, distance information needs to be available at each IPCP, which we call the routing dissemination function.

== Transmission layer ==

At the bottom we find the 'Transmission layer', which is the abstraction for a point-to-point communications channel whose operation is completely independent to all other components of O7s. This can be the wire protocol over a physical medium (copper wire, wireless broadcast, machine RAM, ...) or a network technology such as Ethernet, IP, UDP, Bluetooth, ... to allow constructions as O7s-over-UDP, O7s-over-Ethernet.

This Transmission layer is best seen as a special case of the network forwarding/flooding layer to build a 0-Layer to stop the recursion. It is coupled to its own specifically tailored network end-to-end layer to interface with the application end-to-end layer above (as these 2 end-to-end layers always go hand-in-hand). This network end-to-end layer at least needs to implement a minimal flow allocator if the tranmssion layer is a dumb link, but when the transmission layer wraps a legacy network technology, it may be beneficial to have all features of a network-end-to-end layer.

= Broadcast model =

[[Image: O7s Model_Broadcast.png|border|right|540px|Ouroboros network model - Broadcast]]

The broadcast model has two main additions to the unicast model, the Broadcast API and the network flooding layer.

== Broadcast API ==

The [[Broadcast API]] provides the interface for an application to join and leave broadcast flows, and read and write from and to such flows. The API is network-agnostic and provides application primitives for synchronous and asynchronous IPC. It supports message-based and (byte)stream-based communication. QoS for Broadcast flows is (inherently) limited when compared to the options available for Unicast Flows. A Broadcast flow maps directly to the concept of a [[Broadcast Layer]] (see below).

== Network Flooding layer ==

The ''network flooding layer'' is responsible for flooding packets from the input data transfer flow to all other data transfer flows. This operation is in essence stateless.

The network flooding layer interfaces with an application end-to-end layer to provide the data-transfer flows that make up the links of the Broadcast Layer, which typically form a tree (but a Directed Acyclic Graph is a sufficient condition).

= Layers and recursive networking =

As an application end-to-end layer pairs with a corresponding network application end-to-layer, and the network flooding and network forwarding layers are part of a ''network application'', it is clear that the Ouroboros Unicast Model gives rise to a 'ham-and-cheese sandwich' structure that can be stacked repeatedly. If the network IPC API between the application and network end-to-end layers is a single universal standard, then all the Layers (capital L) in this sandwich can be moved around at will. This is what is called a '''recursive network'''. The Ouroboros model hints very strongly at recursion, but does not require it.

== Unicast Layer ==

The Unicast Layer consists of a ''three-layer application'' that contains implementations of a network end-to-end layer and a network forwarding layer (and inherits the application end-to-end layer). This (abstract) application is called a [[Unicast IPCP]].
The Unicast IPCPs are equals as defined by mechanism (which functionality to implement, etc), but not identical as each mechanism can be implemented by different policies. As an example, the routing functionality can be link-state in one Layer, but path-vector in another Layer.
Within the same Layer, they are also not identical, but some network-wide policies will need to be the same in all IPCPs in a Layer.

== Broadcast Layer ==

The Broadcast Layer consists of a ''two-layer application'' that contains implementations of a network flooding layer (and inherits the application end-to-end layer). This (abstract) application is called a [[Broadcast IPCP]].

[[Ouroboros Multicast|Multicast]] is not a distinct concept in the O7s model, but rather the combination of 2 processes:
# Enrolling a Broadcast IPCP in a Broadcast Layer that consists of other Broadcast IPCPs in systems that are home to the set of applications that would be designated as a 'multicast group', and
# The application then using that Broadcast Layer.

== 0-Layers ==

A Unicast 0-Layer is a Layer consisting of ''two-layer applications'' that implement a - possibly tailored and limited - network end-to-end layer to interface with applications (using the Unicast API) above. Examples of these are IPCPs to run O7s over UDP, Ethernet, RAM, etc.

A Broadcast 0-Layer is a ''two-layer application'' that implements a - possibly tailored and limited - network flooding layer to interface with broadcast applications (using the Broadcast API) above. This is not shown in the model figures, but it is the trivial case of an O7s application over a 'legacy' broadcast technology. Examples are IPCPs implementing flooding over RAM, or wrapping Ethernet or IP Broadcast.

= Relation to TCP/IP model =

[[Image: O7s Model_vs_TCP.png|border|right|540px|Ouroboros network model vs TCP/IP model]]

Main Page: [[Ouroboros and TCP/IP]]

This section provides a high level architectural overview of the prime differences between the Ouroboros model and the [https://en.wikipedia.org/wiki/Internet_protocol_suite 5-Layer Internet model] associated with the TCP/IP protocol stack.

Some differences are directly apparent:
# The '''Transport Layer''' is replaced with two end-to-end layers, split between the network and the application,
# The '''Network Layer''' has two counterparts: the network forwarding layer for unicast and the network flooding layer for broadcast,
# The '''Data Link Layer''' is missing altogether,
# The '''Physical Layer''' is now called the transmission layer.

== Splitting the Transport Layer ==
The key difference is that functionality that is associated with the Transport Layer (the TCP/UDP protocols) is moved into two independent layers. The application end-to-end layer takes over [[Glossary#Automated_Repeat_reQuest|ARQ]] and flow control, while the network end-to-end layer is in charge of multiplexing, name-to-address resolution and congestion control. This split of the Transport Layer is actually quite similar to the sublayering (Link Logical Control /Media Access Control) of the Data Link Layer in the Internet Model. The name-to-address resolution functionality (roughly equivalent to DNS SRV resolve) is also inside the end-to-end network layer instead of an (essentially optional) function that the application needs to perform. More specifically, the O7s network IPC API requires only a ''service name'' so it can resolve addresses internally, whereas the TCP/IP model Transport Layer needs an IP address and port, leaving it up to the application to resolve the address.

== Untangling the Network Layer ==

The network layer functionality is very similar between O7s and the Internet model. The main difference is that broadcast is split off in the O7s model, and that the network forwarding layer does not hold references to the higher-level layers (so, no 'Protocol' field).

== No Data Link Layer ==

In the Internet model, the Data Link Layer is split up into two sub-layers, called the Link Logical Control (LLC) and Media Access Control (MAC) layers. When looking at the functionality that is associated with these layers, the O7s application end-to-end layer maps directly to link logical control and the O7s network end-to-end layer maps directly to the MAC layer (name-to-address mapping, multiplexing), so there is no need anymore for this layer to be distinct in the O7s model.

== Transmission layer instead of Physical Layer ==

The final change in the model is to abstract the Physical Layer to include (virtual) legacy networks and therefore a more generic 'end of the line' for the model than only a physical medium. The distinct property is that it does not reuse the O7s API and therefore does not interface into the application end-to-end layer. Instead it has functionality that is directly tailored to the specific technology it wraps.

= Relation to Location/Identifier split =

[[Image: O7s Model_vs_LocId.png|border|right|540px|Ouroboros network model vs Loc/Id split]]

Loc/Id split starts from the observation that the application is tightly coupled to network (IP) addresses through the Transport Layer via a certain port. This hampers application mobility, as a change in network (IP) address breaks the TCP connection used by the application. Loc/Id split proposes to semantically break up the network layer address into two separate parts, an ''identifier'' that is location-independent and specifies the ''who'' at the Transport Layer, and a ''locator'' that is location-dependent and specifies the ''where'' at the network layer. An IPv6 address is 128 bits wide, providing ample material to accommodate this split.

Architecturally, this boils down to a name-to-address resolution step - identifier-to-locator - in a ''Sub-Layer''<ref>[https://doi.org/10.1109/COMST.2017.2728478 Locator/Identifier Split Networking: A Promising Future Internet Architecture]</ref> between the Transport Layer (bound to the identifier) and the Network Layer (using the locator). Changing locator during mobility therefore does not break the Transport Layer connection. While the proposed solution works, the core tenet of Loc/Id split that ''IP addresses are semantically overloaded''<ref>[https://www.rfc-editor.org/rfc/rfc4984#section-2.2 rfc4984]</ref> is nonsense. The actual problem is a missing (service) name and DNS providing only synonyms for addresses; DNS SRV is a step towards naming applications/services (L5), but DNS/SRV still directly maps these names to the L3 address and L4 port; the application directly binds to the L3/L4 identifiers instead of the L5 name. Both pieces of the puzzle are known, they just need to be put together.

Taken as a whole, Loc/Id split applications perform two lookups: domain name to identifier, and then identifier to locator. This indirection is needed for Loc/Id split to stay compatible with the TCP/IP protocol stack, but it is redundant from the perspective of O7s. It is more efficient to bind applications to ''service names'', and resolve a ''service name'' to an address in a single lookup.

The O7s model splits the Transport Layer (see above), adding a service name-to-address resolution mechanism to the network end-to-end layer. The big functional differences with the Sub-Layer proposed in Loc/id and the layers in O7s are that the network end-to-end layer also takes over congestion control and multiplexing from the Transport Layer, and that the remaining functionality - the application end-to-end layer - is considered part of the application.

= Relation to Recursive InterNetwork Architecure (RINA) =

[[Image: O7s Model_vs_RINA.png||border|right|540px|Ouroboros network model vs RINA model]]

Main Page: [[Ouroboros and RINA]]

The original objective of the Ouroboros prototype was to build a portable user-space implementation of RINA for POSIX systems that could be tailored to embedded devices. As this prototype started off as an implementation of principles outlined by RINA, the Ouroboros model inherits a lot of concepts and terminology from RINA. As such, that's where the credit for those ideas goes. As the prototype evolved, architectural changes were made that further simplified things.

== Splitting data transfer control from data transfer ==

RINA sees the [[Glossary#IP_fragmentation_problem|IP fragmentation problem]] as evidence that the TCP/IP split was incorrect<ref>[https://ieeexplore.ieee.org/document/6126673 How in the Heck do you lose a layer!?]</ref>. The solution put forward in RINA is to keep the functionality of TCP and IP in a single logical layer and in a single protocol, called the Error and Flow Control Protocol (EFCP). EFCP is still subdivided in two component protocol (called Data Transfer Protocol (DTP) and Data Transfer Control Protocol (DTCP), but these two protocol ''share a state vector'' and are therefore not fully independent.

During the implementation of EFCP in Ouroboros we found that the functionality in EFCP (and thus TCP + IP) could (and therefore should) be split not in 2, but ''3'' independent layers: the application end-to-end layer, the network end-to-end layer and the network forwarding layer. The IP fragmentation problem is solved by putting the fragmentation bits in the [[Flow and Retransmission Control Protocol]] rather than the [[Ouroboros Data Transfer Protocol|Data Transfer Protocol]] and the Flow Allocator reports the path maximum transmission unit (MTU) for a flow as input for the fragmentation function.

== O7s Layers vs RINA DIFs ==

In RINA, DTP and DTCP are in the same Layer. Since end-user programs do not typically perform packet forwarding, there is therefore a hard distinction between 'normal' end-user (distributed) applications and the (distributed) application that is responsible for (reliable) packet transfer. The EFCP protocol provides the necessary functionality for this reliable packet communication between processes, and therefore a process that implements EFCP is called an Inter-Process Communication process (IPCP), a term that originated in Livermore's LINCS network. The distributed application consisting of such IPCPs is called a Distributed IPC Facility (DIF). In contrast, a regular end-user distributed application, consists of distributed application processes (DAPs) and is called a Distributed Application Facility (DAF).

The 3-layer functional split in O7s raised a question for the location of FRCP: should it be part of the DIF, or part of the Application? It was immediately clear that putting it in the application solved some questions that arise with the RINA architecture.
# End-user application multi-homing (i.e. flows over different networks) is still a problem in RINA: only IPCPs can efficiently multi-home. In O7s all processes can effectively multi-home.
# Loss of IPCP state associated with DTCP (sequence numbers, DTCP windows) after crash of an IPCP is not easily recoverable even when the application process survives.
# Reliable flow allocation over a shim-DIF (needed by the IPCP) required a hack for the IPCP to allocate a flows over ''itself''.
# If an IPCP/DIF is needed to provided reliable IPC between two programs, who performs reliable IPC between those programs and the IPCP/DIF? The answer that the OS provides test-and-set is not satisfactory as it requires some (admittedly very reasonable) assumptions outside of the model that are not trivial.

With the application end-to-end layer, the distinction between DIF and DAF is not present in the O7s model. Nevertheless, awaiting more satisfactory terminology O7s still refers to processes making up an O7s Layers as ''IPCPs'', fully aware of the confusion this may cause.

= Notes on Layering in O7s =

The model as explained above shows Broadcast Layers over Unicast Layers, and Unicast over Unicast Layers. What about the other options?

== Unicast over Broadcast ==

From the perspective of the O7s Layers, the ''general case'' of Unicast over Broadcast -- by which we mean that some ''data packets'' will be flooded to multiple next-hop IPCPs -- brings with it that Unicast IPCPs would have to be able to identify whether arriving data packets are for them or not. This problem inherently has limited scalability and its utility within O7s is as of yet unclear and requires some further study. In absence of compelling reasons to add this, we currently haven't added this to the general model. This does not imply that a Unicast Layer can not use ''dedicated'' Broadcast Layers to implement certain functionalities - an example is routing dissemination in the network forwarding layer.

Since Ethernet does implement unicast over a broadcast domain, we have a dedicated page discussing how [[Ouroboros and Ethernet|Ethernet maps to Ouroboros]].

== Broadcast over Broadcast ==

The case where one Broadcast Layer makes use of another Broadcast Layer is also technically feasible. Its utility is also still unclear, which is why it's not currently elaborated on, but allowing this will have little impact on the model.

== Mixed and/or combined implementation ==

Why not merge broadcast and unicast functionality in a single Layer? This is definitely feasible and anyone is free to implement such an IPCP that does both. The net outcome will be a Layer that has a a broadcast network as well as a unicast network at the full scope of that Layer, which may be useful for some particular use cases. However, from a ''model'' perspective, Unicast and Broadcast are always two distinct Layers, and mixing the implementation does not alter this fact.

Similarly, a program can be written that implements multiple IPCP modules internally, instead of starting up a process per 'IPCP'.

= References =

Ouroboros Protocols

2026-06-13T08:23:07Z

Dimitri: /* Flow encryption header */

{{Under construction}}

The protocols in Ouroboros are designed with strong adherence to the principles of [https://en.wikipedia.org/wiki/Separation_of_concerns separation of concerns] and [https://en.wikipedia.org/wiki/Separation_of_mechanism_and_policy separation of mechanism and policy] in mind to prevent network ossification and protocol ossification from occuring.

There are 5 core protocols in Ouroboros.

== Data Transfer Protocol ==
Main page: [[Ouroboros Data Transfer Protocol]]

The Data Transfer Protocol resides in the [[Ouroboros Functional Layering|network forwarding layer]].

<syntaxhighlight>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-to-Live | QoS | ECN | PADDING |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ EID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ N + 1 Data +
. .
. .
</syntaxhighlight>

== Flow encryption header ==

Every encrypted packet is a fixed-size cleartext '''selector''' header,
followed by the AEAD ciphertext of the inner FRCP packet, followed by
the AEAD authentication '''tag'''.

<syntaxhighlight lang="text">
+----------------+------------------------------+--------------+
| selector (6 B) | E(inner FRCP packet) | tag (16 B) |
+----------------+------------------------------+--------------+
\__ cleartext _/ \______ ciphertext __________/ \__ cleartext _/
\________________ authenticated (AAD + AEAD) ________________/
</syntaxhighlight>

;selector
:6-octet cleartext key-selection header. It is read '''before''' decryption to select the key and reconstruct the nonce, and it is bound into the AEAD as Associated Data.
;ciphertext
:AEAD encryption of the inner packet under the selected sub-key and reconstructed nonce.
;tag
:AEAD authentication tag, 16 octets (128 bits) for AEAD ciphers; absent for non-AEAD ciphers.

== Flow and Retransmission Control Protocol ==
Main page: [[Flow and Retransmission Control Protocol]]

The Flow and Retransmission Control Protocol resides in the [[Ouroboros Functional Layering|application end-to-end layer]].

<syntaxhighlight>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | hcs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ackno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload (variable) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

flags - feature/type bitmap (see 1.2).
hcs - CRC-16-CCITT-FALSE Header Check Sequence (HCS) over
flags + window + seqno + ackno (+ stream extension when
present); the two octets of the hcs field itself are
omitted from the CRC input. Verified on receive before
any flag-driven dispatch.
window - receiver-advertised right window edge (valid iff FC).
seqno - per-flow sequence number.
ackno - cumulative Acknowledgement (ACK) (valid iff ACK).
</syntaxhighlight>

== Flow Allocation Protocol ==
Main page: [[Ouroboros Flow Allocation Protocol]]

/*
* 0 1 2 3
* 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
* | | |
* + + |
* | | |
* + id (128 bits) + |
* | Unique flow allocation ID | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | | |
* + timestamp (64 bits) + |
* | UTC nanoseconds since epoch | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | crt_len (16 bits) | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | | |
* + certificate (variable) + |
* | X.509 certificate, DER encoded | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* |F|R| kex_len (14 bits) | | | Signed
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | | | Region
* + kex_data (variable) + |
* | public key (DER/raw) or ciphertext (KEM) | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | cipher_len (16 bits) | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | | |
* + cipher (variable) + |
* | symmetric cipher name (UTF-8) | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | data_len (16 bits) | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | | |
* + data (variable) + |
* | Piggybacked application data | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
* | sig_len (16 bits) | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
* | |
* + signature (variable) +
* | DSA signature over signed region |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*
* kex_len field bit layout:
* F (bit 15): Format - 0 = X.509 DER, 1 = Raw/Hybrid
* R (bit 14): Role - 0 = Server encaps, 1 = Client encaps
* (R is ignored for non-KEM algorithms)
* Bits 0-13: Length (0-16383 bytes)
*/
The Flow Allocation Protocol resides in the [[Ouroboros Functional Layering|network end-to-end layer]].

== Connection Establishment Protocol ==
Main page: [[Ouroboros Connection Establishment Protocol]]

== Enrollment Protocol ==
Main page: [[Ouroboros Enrolment Protocol]]

The Enrollment protocol is best seen as one of the application protocols for IPCPs.

Ouroboros Protocols

2026-06-13T08:21:50Z

Dimitri: /* Flow encryption header */

{{Under construction}}

The protocols in Ouroboros are designed with strong adherence to the principles of [https://en.wikipedia.org/wiki/Separation_of_concerns separation of concerns] and [https://en.wikipedia.org/wiki/Separation_of_mechanism_and_policy separation of mechanism and policy] in mind to prevent network ossification and protocol ossification from occuring.

There are 5 core protocols in Ouroboros.

== Data Transfer Protocol ==
Main page: [[Ouroboros Data Transfer Protocol]]

The Data Transfer Protocol resides in the [[Ouroboros Functional Layering|network forwarding layer]].

<syntaxhighlight>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-to-Live | QoS | ECN | PADDING |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ EID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ N + 1 Data +
. .
. .
</syntaxhighlight>

== Flow encryption header ==

Every encrypted packet is a fixed-size cleartext '''selector''' header,
followed by the AEAD ciphertext of the inner FRCP packet, followed by
the AEAD authentication '''tag'''.

<syntaxhighlight lang="text">
+----------------+------------------------------+--------------+
| selector (6 B) | E(inner FRCP packet) | tag (16 B) |
+----------------+------------------------------+--------------+
\__ cleartext _/ \______ ciphertext __________/ \__ cleartext _/
\________________ authenticated (AAD + AEAD) ________________/
</syntaxhighlight>

;selector
:6-octet cleartext key-selection header (see [[#1.2. Selector|Section 1.2]]). It is read '''before''' decryption to select the key and reconstruct the nonce, and it is bound into the AEAD as Associated Data (see [[#4. AEAD and AAD binding|Section 4]]).
;ciphertext
:AEAD encryption of the inner packet under the selected sub-key and reconstructed nonce. The supported ciphers are stream-mode, so the ciphertext length equals the plaintext length.
;tag
:AEAD authentication tag, 16 octets (128 bits) for AEAD ciphers; absent for non-AEAD ciphers (see [[#4. AEAD and AAD binding|Section 4]]).

== Flow and Retransmission Control Protocol ==
Main page: [[Flow and Retransmission Control Protocol]]

The Flow and Retransmission Control Protocol resides in the [[Ouroboros Functional Layering|application end-to-end layer]].

<syntaxhighlight>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | hcs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ackno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload (variable) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

flags - feature/type bitmap (see 1.2).
hcs - CRC-16-CCITT-FALSE Header Check Sequence (HCS) over
flags + window + seqno + ackno (+ stream extension when
present); the two octets of the hcs field itself are
omitted from the CRC input. Verified on receive before
any flag-driven dispatch.
window - receiver-advertised right window edge (valid iff FC).
seqno - per-flow sequence number.
ackno - cumulative Acknowledgement (ACK) (valid iff ACK).
</syntaxhighlight>

== Flow Allocation Protocol ==
Main page: [[Ouroboros Flow Allocation Protocol]]

/*
* 0 1 2 3
* 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
* | | |
* + + |
* | | |
* + id (128 bits) + |
* | Unique flow allocation ID | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | | |
* + timestamp (64 bits) + |
* | UTC nanoseconds since epoch | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | crt_len (16 bits) | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | | |
* + certificate (variable) + |
* | X.509 certificate, DER encoded | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* |F|R| kex_len (14 bits) | | | Signed
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | | | Region
* + kex_data (variable) + |
* | public key (DER/raw) or ciphertext (KEM) | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | cipher_len (16 bits) | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | | |
* + cipher (variable) + |
* | symmetric cipher name (UTF-8) | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | data_len (16 bits) | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | | |
* + data (variable) + |
* | Piggybacked application data | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
* | sig_len (16 bits) | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
* | |
* + signature (variable) +
* | DSA signature over signed region |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*
* kex_len field bit layout:
* F (bit 15): Format - 0 = X.509 DER, 1 = Raw/Hybrid
* R (bit 14): Role - 0 = Server encaps, 1 = Client encaps
* (R is ignored for non-KEM algorithms)
* Bits 0-13: Length (0-16383 bytes)
*/
The Flow Allocation Protocol resides in the [[Ouroboros Functional Layering|network end-to-end layer]].

== Connection Establishment Protocol ==
Main page: [[Ouroboros Connection Establishment Protocol]]

== Enrollment Protocol ==
Main page: [[Ouroboros Enrolment Protocol]]

The Enrollment protocol is best seen as one of the application protocols for IPCPs.

Ouroboros Protocols

2026-06-13T08:16:10Z

Dimitri: /* Data Transfer Protocol */

{{Under construction}}

The protocols in Ouroboros are designed with strong adherence to the principles of [https://en.wikipedia.org/wiki/Separation_of_concerns separation of concerns] and [https://en.wikipedia.org/wiki/Separation_of_mechanism_and_policy separation of mechanism and policy] in mind to prevent network ossification and protocol ossification from occuring.

There are 5 core protocols in Ouroboros.

== Data Transfer Protocol ==
Main page: [[Ouroboros Data Transfer Protocol]]

The Data Transfer Protocol resides in the [[Ouroboros Functional Layering|network forwarding layer]].

<syntaxhighlight>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-to-Live | QoS | ECN | PADDING |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ EID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ N + 1 Data +
. .
. .
</syntaxhighlight>

== Flow encryption header ==

== Flow and Retransmission Control Protocol ==
Main page: [[Flow and Retransmission Control Protocol]]

The Flow and Retransmission Control Protocol resides in the [[Ouroboros Functional Layering|application end-to-end layer]].

<syntaxhighlight>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | hcs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ackno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload (variable) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

flags - feature/type bitmap (see 1.2).
hcs - CRC-16-CCITT-FALSE Header Check Sequence (HCS) over
flags + window + seqno + ackno (+ stream extension when
present); the two octets of the hcs field itself are
omitted from the CRC input. Verified on receive before
any flag-driven dispatch.
window - receiver-advertised right window edge (valid iff FC).
seqno - per-flow sequence number.
ackno - cumulative Acknowledgement (ACK) (valid iff ACK).
</syntaxhighlight>

== Flow Allocation Protocol ==
Main page: [[Ouroboros Flow Allocation Protocol]]

/*
* 0 1 2 3
* 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
* | | |
* + + |
* | | |
* + id (128 bits) + |
* | Unique flow allocation ID | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | | |
* + timestamp (64 bits) + |
* | UTC nanoseconds since epoch | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | crt_len (16 bits) | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | | |
* + certificate (variable) + |
* | X.509 certificate, DER encoded | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* |F|R| kex_len (14 bits) | | | Signed
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | | | Region
* + kex_data (variable) + |
* | public key (DER/raw) or ciphertext (KEM) | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | cipher_len (16 bits) | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | | |
* + cipher (variable) + |
* | symmetric cipher name (UTF-8) | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | data_len (16 bits) | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | | |
* + data (variable) + |
* | Piggybacked application data | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
* | sig_len (16 bits) | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
* | |
* + signature (variable) +
* | DSA signature over signed region |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*
* kex_len field bit layout:
* F (bit 15): Format - 0 = X.509 DER, 1 = Raw/Hybrid
* R (bit 14): Role - 0 = Server encaps, 1 = Client encaps
* (R is ignored for non-KEM algorithms)
* Bits 0-13: Length (0-16383 bytes)
*/
The Flow Allocation Protocol resides in the [[Ouroboros Functional Layering|network end-to-end layer]].

== Connection Establishment Protocol ==
Main page: [[Ouroboros Connection Establishment Protocol]]

== Enrollment Protocol ==
Main page: [[Ouroboros Enrolment Protocol]]

The Enrollment protocol is best seen as one of the application protocols for IPCPs.

Flow and Retransmission Control Protocol

2026-05-18T16:11:20Z

Dimitri: /* 8. Retransmission */

{{DISPLAYTITLE:FRCP - Flow and Retransmission Control Protocol}}

FRCP runs end-to-end between two peers over a flow. It delivers
reliability, in-order delivery, flow control, and liveness.
Congestion Control (CC) is not in FRCP - that lives in the IPC
Process (IPCP) Congestion Avoidance (CA) policies, orthogonal to
FRCP. Flow allocation, naming, and IPCP lifecycle are handled by
the IPC Resource Manager daemon (IRMd).

FRCT (Flow and Retransmission Control Task) is the libouroboros
implementation of FRCP; the task lives in <code>src/lib/frct.c</code>. The
remainder of this document describes the FRCP wire protocol and the
behaviour FRCT realises. Code symbols retain the <code>FRCT_</code> prefix
(<code>FRCT_DATA</code>, <code>FRCT_RXM</code>, ...) because they belong to the implementing
task; this document references them verbatim.

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in <code>BCP</code> 14 (Best
Current Practice; RFC 2119, RFC 8174) when, and only when, they
appear in all capitals.

== Notation ==

;<code>u32</code>, <code>u8</code>
:Unsigned 32-bit / 8-bit integers (kernel-C style).
;<code>ns</code>
:Nanoseconds.

Modular sequence-number comparators (32-bit, modulo 2^32):

;<code>before(a, b)</code>
:<code>(int32_t)(a - b) < 0</code>
;<code>after(a, b)</code>
:<code>before(b, a)</code>

Used throughout for <code>ackno</code> / <code>seqno</code> ordering checks.

Round-Trip Time (RTT) abbreviations used throughout:

;<code>SRTT</code>
:Smoothed RTT estimate (RFC 6298).
;<code>mdev</code>
:Mean deviation of RTT (Linux variance estimator).
;<code>EWMA</code>
:Exponentially Weighted Moving Average.
;<code>RTO</code>
:Retransmission Timeout, <code>max(RTO_MIN, srtt + (mdev << MDEV_MUL))</code>.

Timer-bound symbols <code>t_a</code> (a-timer, ACK delay) and <code>t_r</code> (r-timer,
retransmission window) are defined in [[#8. Retransmission|Section 8]]; <code>t_mpl</code> (Maximum
Packet Lifetime) is introduced in [[#2.1. Per-flow state|Section 2.1]] (the <code>inact</code> field)
with heritage in [[#15. Heritage and adopted techniques|Section 15]].

Wire-format diagrams follow the IETF convention: bit 0 is the
leftmost (most significant) bit and fields are in network byte
order unless stated otherwise.

__TOC__

== 1. Wire format ==

=== 1.1. PCI header ===

Fixed 16-octet base Protocol-Control Information (PCI) header
prefixed to every FRCP packet (RFC convention: bit 0 leftmost,
most-significant bit first). All multi-byte fields are in network byte order. DATA packets on
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
base PCI.

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | hcs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ackno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload (variable) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>flags</code>
:feature/type bitmap (see [[#1.2. Flag bits|Section 1.2]]).
;<code>hcs</code>
:CRC-16-CCITT-FALSE Header Check Sequence (HCS) over <code>flags</code> + <code>window</code> + <code>seqno</code> + <code>ackno</code> (+ stream extension when present); the two octets of the <code>hcs</code> field itself are omitted from the CRC input. Verified on receive before any flag-driven dispatch.
;<code>window</code>
:receiver-advertised right window edge (valid iff FC).
;<code>seqno</code>
:per-flow sequence number.
;<code>ackno</code>
:cumulative Acknowledgement (ACK) (valid iff ACK).

A single packet can simultaneously carry DATA + ACK + FC (Flow
Control) + RXM (Retransmission) by ORing flag bits; the PCI
multiplexes control on the same wire frame in the spirit of SCTP
chunk bundling (RFC 9260 sec. 6.10) and QUIC frame multiplexing
(RFC 9000 sec. 12.4). DATA-bearing packets carry the caller's
payload after the PCI; SACK (Selective Acknowledgement) and RTTP
(Round-Trip Time Probe) carry their own typed payloads after the
PCI.

Optional framing (per-flow, see [[#2.2. Service modes (orthogonal axes)|Section 2.2]]). On the wire, the
order from inside out is:

{| class="wikitable"
! Layer !! Scope
|-
| <code>[ PCI + body ]</code>
| The FRCP packet.
|-
| <code>[ PCI + body + CRC-32 ]</code>
| CRC-32 covers the body only (PCI is in HCS); appended iff <code>qs.ber == 0</code> on DATA, or on every SACK packet.
|-
| <code>[ AEAD-wrap of above ]</code>
| Iff Authenticated Encryption with Associated Data (AEAD) is enabled.
|}

* 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 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>).

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

=== 1.2. Flag bits ===

Flag bits are numbered most-significant-bit first to match the wire
diagram (bit numbering per [[#1.1. PCI header|Section 1.1]]; bit 0 is the MSB of the
16-bit <code>flags</code> field and lands at wire-position 0 in network byte
order). Bits 13..15 are reserved and MUST be transmitted as zero.

{| class="wikitable"
! Bit !! Mask !! Name !! Meaning
|-
| 0 || <code>0x8000</code> || <code>DATA</code> || Carries caller payload
|-
| 1 || <code>0x4000</code> || <code>DRF</code> || Data Run Flag: start of a fresh run
|-
| 2 || <code>0x2000</code> || <code>ACK</code> || Acknowledgement: <code>ackno</code> field valid
|-
| 3 || <code>0x1000</code> || <code>NACK</code> || Negative ACK; <code>seqno = arrival_seqno-1</code>
|-
| 4 || <code>0x0800</code> || <code>FC</code> || Flow Control: <code>window</code> field valid (<code>rwe</code>)
|-
| 5 || <code>0x0400</code> || <code>RDVS</code> || Rendezvous probe (window-closed)
|-
| 6 || <code>0x0200</code> || <code>FFGM</code> || First Fragment (role bit 0; see below)
|-
| 7 || <code>0x0100</code> || <code>LFGM</code> || Last Fragment (role bit 1; see below)
|-
| 8 || <code>0x0080</code> || <code>RXM</code> || Retransmission
|-
| 9 || <code>0x0040</code> || <code>SACK</code> || Selective ACK block list in payload
|-
| 10 || <code>0x0020</code> || <code>RTTP</code> || RTT Probe / echo (payload follows)
|-
| 11 || <code>0x0010</code> || <code>KA</code> || Keepalive
|-
| 12 || <code>0x0008</code> || <code>FIN</code> || End-of-stream marker (stream mode)
|-
| 13-15 || -- || -- || Reserved (MUST be zero)
|}

The (<code>FFGM</code>, <code>LFGM</code>) pair encodes the fragment role of a DATA-bearing
Service Data Unit (SDU), SCTP-style begin/end flags (RFC 9260
sec. 3.3.1):

{| class="wikitable"
! FFGM !! LFGM !! Role
|-
| 1 || 1 || Sole / un-fragmented SDU (begin AND end)
|-
| 1 || 0 || First fragment of a multi-fragment SDU
|-
| 0 || 0 || Middle fragment
|-
| 0 || 1 || Last fragment
|}

Each fragment is carried in its own FRCP packet with its own <code>seqno</code>;
FRTX (the FRCT Retransmission service mode, see [[#2.2. Service modes (orthogonal axes)|Section 2.2]])
recovers individual fragments via the normal Retransmission Timeout
(RTO) / SACK / Recent Acknowledgement (RACK, RFC 8985) path. The
receiver reassembles the SDU at consume time once the contiguous
[FIRST .. LAST] run has fully arrived. On non-DATA packets the role
bits are unused and MUST be transmitted as zero.

In stream mode (<code>qos.service == SVC_STREAM</code>, see [[#16. Stream-mode flows|Section 16]]) there are
no SDU boundaries to encode, so <code>FFGM</code> and <code>LFGM</code> are unused and MUST
be transmitted as zero. End-of-stream uses a dedicated bit (<code>FIN</code>,
bit 12) carried on a 0-byte DATA packet, emitted at write-half close
(<code>fccntl</code> to <code>FLOWFRDONLY</code>), during linger drain, and at <code>flow_dealloc</code>;
emission is idempotent (first call wins). After contiguous delivery
of the FIN-bearing slot, the receiver latches <code>byte_fin</code> at the FIN's
start offset; <code>flow_read</code> returns 0 (end-of-file, <code>EOF</code>) once buffered
bytes have been drained up to <code>byte_fin</code>. Per-byte position is
carried by the [start, end) extension ([[#1.5. Stream PCI extension|Section 1.5]]).

=== 1.3. SACK payload ===

A SACK packet has the <code>FRCT_ACK | FRCT_FC | FRCT_SACK</code> flag bits set
(bit numbering per [[#1.1. PCI header|Section 1.1]]). Following the 16-octet PCI, the
payload is a 2-octet block count (network byte order), 2 octets of
padding to 4-byte align the block list, then <code>n_blocks</code> pairs of
32-bit start/end seqnos describing ''present'' (received) ranges
above the cumulative ACK.

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_blocks | padding (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start[0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end[0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... n_blocks pairs total ...
</syntaxhighlight>

<code>n_blocks <= SACK_MAX_BLOCKS</code> (2048). The per-flow effective cap is
further bounded by <code>(frag_mtu - PCI - 4) / 8</code> blocks per packet; SACK
packets carry no stream extension, so PCI here is the 16-octet base
header even on stream-mode flows.

Wire invariant: every block produced by the receiver, except an
optional leading Duplicate SACK (D-SACK) block as described below,
describes a range strictly above the cumulative ACK carried in the
PCI <code>ackno</code> field (<code>after(start[i], ackno)</code>). This makes the D-SACK
convention below unambiguous; the receiver-side builder MUST
preserve it.

Duplicate SACK (D-SACK, RFC 2883) is signalled in-band: no flag
bit, no extra framing. Modular seqno arithmetic uses the
<code>before()</code> / <code>after()</code> comparators defined in the Notation block.

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)
:<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)
:<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.

The <code>reo_wnd_mult</code> halving cadence (once per 16 cumulatively-ACK'd
seqnos since the most-recent D-SACK arrival or halve event) and
the reset-to-1 on a HoL RTO fire are both per the same RFC 8985
clause. The clamp-and-skip path in the regular SACK-mark loop is
incidentally idempotent on any leftover case-1 or case-2 block
(<code>start < snd_cr.lwe</code> clamps to <code>snd_cr.lwe</code> and the inner loop
skips <code>k == snd_cr.lwe</code>; case-2 re-NULLs slots already marked
received by later blocks), so block[0] is harmless even when fed
to the loop.

=== 1.4. RTTP payload ===

An RTTP (Round-Trip Time Probe) packet has only the <code>FRCT_RTTP</code> flag
set (bit numbering per [[#1.1. PCI header|Section 1.1]]). Following the 16-octet PCI,
the payload is 24 octets (packed):

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| probe_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| echo_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ nonce (16 octets, echoed verbatim) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>probe_id</code>
:sender counter, 0 on reply, 0 reserved.
;<code>echo_id</code>
:peer's <code>probe_id</code>, 0 on outbound probe.
;<code>nonce</code>
:random, echoed unmodified, memcmp'd to defeat spoof.

=== 1.5. Stream PCI extension ===

A stream-mode flow (<code>qos.service == SVC_STREAM</code>) carries an extra
8-octet extension after the 16-octet base PCI on every DATA packet
(bit numbering per [[#1.1. PCI header|Section 1.1]]):

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>start</code>
:octet offset of the first payload byte in the stream.
;<code>end</code>
:octet offset one past the last payload byte; <code>end - start</code> equals the on-wire payload length.

Total stream-mode PCI for DATA packets is 24 octets (16 base + 8
extension); control packets (SACK, RTTP, bare ACK, KA, etc.) retain
the 16-octet base PCI. Stream mode MUST be negotiated at flow
allocation; the extension is present iff stream mode is in use,
never on a per-packet basis. Both peers MUST treat <code>start</code>/<code>end</code> as
monotonic 32-bit byte offsets; when a slot reaches the head of the
contiguous run with <code>start</code> not equal to the prior packet's <code>end</code> the
slot is silently dropped at delivery time ([[#16. Stream-mode flows|Section 16]]) rather
than rejected at stash.

This is the QUIC STREAM-frame reassembly model (RFC 9000 sec. 19.8):
each packet carries its packet <code>seqno</code> (this PCI's <code>seqno</code> field) and a
separate stream byte position (<code>start</code>/<code>end</code>). Separating the two
avoids TCP's conflation of packet identity with byte position which
forces Karn's algorithm for Round-Trip Time (RTT) sampling (no RTT
sample on retransmits, RFC 6298 sec. 3); FRCP applies the
Karn-equivalent gate via a combination of per-packet <code>FRCT_RXM</code>,
per-slot <code>SND_RTX</code> flags, and a sample-fence <code>rtt_lwe</code> (see [[#2.1. Per-flow state|Section 2.1]]
and [[#12. RTT estimation|Section 12]]). FRCP's fixed-32-bit <code>start</code>/<code>end</code> wrap at 4 GiB of
wire bytes, narrower than QUIC's 62-bit varint offset (cf. RFC 9000
sec. 16); the on-wire wrap is handled by the same modular <code>before()</code>
/ <code>after()</code> comparators ([[#1.3. SACK payload|Section 1.3]]) FRCP uses for seqnos, which
remain unambiguous as long as the in-flight byte window stays
strictly under 2 GiB (the half-range of the signed-int32 difference
in <code>before()</code>). The default per-flow ring is 1 MiB; the
implementation caps <code>ring_sz</code> at 128 MiB (<code>FRCT_STREAM_RING_SZ_MAX</code>),
well below the 2 GiB half-range bound. The runtime byte counters
exposed via FUSE (Filesystem in Userspace) in the Ouroboros
Resource Information Base (RIB, a virtual-filesystem introspection
bridge) are platform <code>size_t</code> and do not wrap on 64-bit hosts.

== 2. Per-flow state and service modes ==

=== 2.1. Per-flow state ===

Each flow keeps a sender control record and a receiver control
record:

;<code>lwe</code> : <code>u32</code>
:snd: oldest unacked <code>seqno</code> (cumulative ACK boundary as seen by sender); rcv: next in-order <code>seqno</code> expected
;<code>rwe</code> : <code>u32</code>
:snd: peer-advertised right window edge; rcv: locally-advertised right window edge
;<code>cflags</code> : <code>u8</code>
:per-direction feature flags: retransmission (<code>FRCTFRTX</code>), receiver flow control (<code>FRCTFRESCNTL</code>), linger-on-close (<code>FRCTFLINGER</code>); see <code><ouroboros/fccntl.h></code>
;<code>seqno</code> : <code>u32</code>
:snd: next <code>seqno</code> to send; rcv: force-ACK trigger - set on a stale or dup DATA so the next <code>ack_snd</code> emits a fresh cumulative ACK
;<code>ackno</code> : <code>u32</code>
:snd: <code>seqno</code> counter for standalone ACK-bearing control packets (delayed ACK, SACK, final ACK on dealloc); not bumped on piggybacked ACK riding a DATA packet (which uses the DATA <code>seqno</code>). Used by wire-dup ACK detection; rcv: incoming-ACK dedup tracker
;<code>act</code> : <code>ns</code>
:last activity (used by inactivity / DRF)
;<code>inact</code> : <code>ns</code>
:inactivity threshold; sender = <code>3*mpl + a + r + 1s</code>, receiver = <code>2*mpl + a + r + 1s</code>. <code>mpl</code> is the Maximum Packet Lifetime (delta-t terminology; see [[#15. Heritage and adopted techniques|Section 15]]); <code>a</code> and <code>r</code> are the FRCT a-timer and r-timer bounds (see [[#8. Retransmission|Section 8]]). The asymmetry is load-bearing for pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]).

The sender holds a per-slot ring <code>snd_slots[RQ_SIZE]</code> keyed by
<code>(seqno mod RQ_SIZE)</code>. Each slot tracks its retransmit entry (<code>rxm</code>),
last-send timestamp, and retransmit flag bits: <code>SND_RTX</code> (a
retransmit is pending or has fired, gates the next RTT sample
under Karn) and <code>SND_FAST_RXM</code> (one-shot fast-retransmit staged for
this loss event).

The receiver holds a parallel reorder ring <code>rcv_slots[RQ_SIZE]</code>
(referred to as <code>rq[]</code> in prose) holding stashed out-of-order
packet-buffer indexes; both FRTX and best-effort flows share this
path. The invariant <code>rwe - lwe <= RQ_SIZE</code> holds: on each consume
the receiver advances <code>rwe</code> by the consumed count, capping the
receive window at <code>RQ_SIZE</code> <code>seqno</code> slots.

A separate fence variable <code>rtt_lwe</code> is bumped on every retransmit
(timer-fire, SACK-driven, fast-rxm, NACK-driven) and on every
<code>seqno_rotate</code> ([[#4. Sequence-number rotation (DRF)|Section 4]]) to mark the <code>seqno</code> range whose RTT samples
MUST be discarded.

=== 2.2. Service modes (orthogonal axes) ===

FRCP exposes its wire features as a vector of independent QoS
axes selected at flow allocation time. All flows go through the
same <code>flow_alloc(name, qos, ...)</code> primitive; the <code>qosspec_t</code> passed
in determines which protocol machinery engages on the wire. This
contrasts with the POSIX BSD socket model where TCP and UDP
require different socket types (<code>SOCK_STREAM</code> / <code>SOCK_DGRAM</code>).

The axes:

;<code>service</code>
:0 = unordered (no FRCP engagement: raw datagrams, no PCI on the wire, UDP-equivalent at this layer); 1 = message-ordered (FRCP engaged; SDU boundaries preserved across fragmentation); 2 = stream (byte-oriented, no SDU boundaries; FRTX required)
;<code>loss</code>
:0 = lossless service requested: FRTX retransmit machinery engages ([[#8. Retransmission|Section 8]]); MUST be 0 for <code>service=2</code>. Non-zero = best-effort, FRTX off.
;<code>ber</code>
:Bit Error Rate tolerance. 0 = error-free service requested: a CRC trailer is appended after the body of DATA packets and verified on receive (added / checked outside the FRCP PCI; see [[#1.1. PCI header|Section 1.1]]). Non-zero = peer accepts errors; trailer omitted. SACK control packets carry a CRC32 trailer regardless of <code>ber</code>; the <code>ber</code> gate applies to DATA only.
;<code>timeout</code>
:Peer-timeout (ms); 0 disables the keepalive timer. Independent of FRCP engagement.

Encryption is a separate per-flow attribute set at flow setup;
when enabled it wraps the FRCP packet (PCI + body, plus the CRC
trailer if any) under AEAD, expanding the <code>spb</code> by <code>headsz</code> + <code>tailsz</code>
octets (nonce / tag). The CRC trailer is currently kept inside
the AEAD wrap (see [[#1.1. PCI header|Section 1.1]]).

Reachable combinations exported by <code>include/ouroboros/qos.h</code>:

{| class="wikitable"
! Cube !! <code>service</code> !! <code>loss</code> !! <code>ber</code> !! Engaged
|-
| <code>qos_raw</code> || 0 || 1 || 1 || Raw passthrough
|-
| <code>qos_raw_safe</code> || 0 || 1 || 0 || Raw + CRC trailer
|-
| <code>qos_rt</code> || 1 || 1 || 1 || FRCP, no FRTX, no CRC
|-
| <code>qos_rt_safe</code> || 1 || 1 || 0 || FRCP, no FRTX, CRC
|-
| <code>qos_msg</code> || 1 || 0 || 0 || FRCP + FRTX
|-
| <code>qos_stream</code> || 2 || 0 || 0 || FRCP + FRTX, stream
|}

Forced couplings actually enforced by the public API:

* <code>service == SVC_STREAM</code> (2) requires <code>loss == 0</code>; <code>flow_alloc</code> / <code>flow_accept</code> reject the pair otherwise with <code>-EINVAL</code>.
* FRTX requires FRCP engagement (<code>service != SVC_RAW</code>); requesting <code>loss = 0</code> with <code>service = SVC_RAW</code> is structurally a no-op because no <code>frcti</code> is created.
* The <code>QOS_DISABLE_CRC</code> build flag globally forces <code>ber = 1</code>. Note: this flag defaults to ON, so default builds ship with CRC disabled until <code>QOS_DISABLE_CRC</code> is set to OFF.

Caveat: the API does NOT force <code>ber = 0</code> when <code>service != SVC_RAW</code>.
<code>qos_rt</code> has <code>service = SVC_MESSAGE</code> with <code>ber = 1</code>, which means the PCI
itself is not CRC-protected on that cube; the HCS ([[#1.1. PCI header|Section 1.1]])
remains the only integrity check on the header.

The FRCP-no-FRTX regime (<code>service = SVC_MESSAGE</code>, <code>loss > 0</code>) is meaningful
and live: sequence numbering, in-order delivery, flow-control
advertisement, KA, DRF rotation, and SDU fragmentation /
reassembly ([[#7.2. Fragmentation and reassembly|Section 7.2]]) all run. Lost packets are dropped
rather than retransmitted; a permanently-lost mid-fragment is
dropped via skip-past-gap once a later SDU is visible in the
reorder ring.

== 3. Protocol parameters ==

{| class="wikitable"
! Parameter !! Value !! Role
|-
| <code>RQ_SIZE</code> || compile-time, power of 2 (default 128) || Slot ring / rcv window width
|-
| <code>START_WINDOW</code> || compile-time, power of 2 (default 128) || Initial <code>rwe-lwe</code> after rotate
|-
| <code>RTO_MIN</code> || <code>MAX(250 us build-tunable, 1<<RXMQ_RES)</code>; per-flow via <code>fccntl</code> (<code>FRCTSRTOMIN</code>). Default ~1 ms with <code>RXMQ_RES=20</code>. || RTO floor; also floored at the retransmit-wheel resolution (~1 ms by default).
|-
| <code>MAX_RTO_MUL</code> || 20 || Backoff shift cap
|-
| RACK window <code>R</code> || <code>MIN(reo_wnd_mult * min_RTT/4, SRTT)</code> with <code>MIN_REORDER_NS = 250 us</code> floor; <code>reo_wnd_mult</code> scales on D-SACK, cap 20 || Reorder window; per RFC 8985 sec. 6.2; <code>reo_wnd_mult</code> per sec. 6.2 step 4
|-
| <code>MIN_RTT_WIN_NS</code> || 300 s (5 min, Linux <code>tcp_min_rtt_wlen</code>) || <code>min_RTT</code> windowed re-anchor
|-
| <code>REO_WND_MULT_MAX</code> || 20 (RFC 8985 sec. 6.2 step 4) || <code>reo_wnd_mult</code> cap
|-
| <code>REO_DECAY_PKTS</code> || 16 (RFC 8985 sec. 6.2 step 4 / <code>RACK.reo_wnd_persist</code>) || Fresh-ACK'd seq count per halving
|-
| <code>MAX_DSACK_LAG</code> || <code>RQ_SIZE</code> || D-SACK sanity cap
|-
| <code>RTT_QUARANTINE</code> || 32 (<code>seqno</code> steps) || NewReno gate pad
|-
| SACK rate-limit || <code>SACK_MIN_GAP_NS</code> (250 us, fixed) || Min SACK gap
|-
| <code>SACK_MAX_BLOCKS</code> || 2048 (wire cap; per-flow capped at <code>(frag_mtu-PCI-4)/8</code>) || Per-SACK block cap
|-
| <code>SACK_RXM_MAX</code> || 32 || Per-pass staged retransmit cap
|-
| <code>DUP_THRESH</code> || 3 (RFC 8985 default) || Hybrid fast-rxm trigger ([[#8. Retransmission|Section 8]])
|-
| <code>MDEV_MUL</code> || 2 (build-tunable via <code>FRCT_RTO_MDEV_MULTIPLIER</code>) || <code>mdev</code> shift in <code>RTO = srtt + (mdev << MDEV_MUL)</code>
|-
| RTTP nonce || 16 octets || Echoed verbatim
|-
| <code>RTTP_RING</code> || 8 || In-flight probes
|-
| RTT clamp || <code>16 * srtt</code> || Probe-sample upper bound (ACK-derived RTT samples gated by Karn / recovery only)
|-
| Cold-probe cadence || 100 ms (rx-driven; see [[#12. RTT estimation|Section 12]]) || Pre-<code>srtt</code> RTTP rate
|-
| <code>DELT_RDV</code> || 100 ms || RDVS emit cadence
|-
| <code>MAX_RDV</code> || 1 s || RDVS give-up
|-
| Delayed-ACK fire || <code>2 * TICTIME</code> (<code>TICTIME</code> = FRCT tick granularity, default 5 ms; <code>2*TICTIME = 10 ms</code> by default) || Fired after the first in-order DATA arrival; tick is build-tunable
|-
| NACK send cooldown || <code>srtt</code> when an <code>srtt</code> sample exists, else 100 ms || Pre-DRF NACK rate-limit
|-
| <code>MAX_SDU</code> || 1 MiB || Max reassembled SDU; configurable per flow
|}

The per-flow fragment Maximum Transmission Unit (MTU) is computed
at flow setup from the lower IPCP's mtu minus encryption
<code>headsz</code> / <code>tailsz</code> and CRC trailer; there is no FRCT-level default or
environment-variable override.

== 4. Sequence-number rotation (DRF) ==

The DRF (Data Run Flag) bit on an outbound packet means "this is
the start of a fresh data run" and is set whenever the sender has
nothing in flight (<code>snd_cr.seqno == snd_cr.lwe</code>).

Independently of that, if the sender has been idle longer than
<code>snd_cr.inact</code> AND the pipe is empty (<code>snd_cr.seqno == snd_cr.lwe</code>),
<code>seqno_rotate()</code> rolls a random new <code>seqno</code> before the send and
resets

<syntaxhighlight lang="text">
snd_cr.seqno = random()
snd_cr.lwe = snd_cr.seqno
snd_cr.rwe = snd_cr.seqno + START_WINDOW
rtt_lwe = snd_cr.seqno
in_recovery = false (recovery state, see Section 8)
recovery_high = snd_cr.seqno
</syntaxhighlight>

The receiver, on observing rcv-side inactivity
(<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
below). Non-DATA control packets pass through without the DRF
requirement (no impact on receiver state). On DRF the receiver releases the <code>rq[]</code> slots and
rebases

<syntaxhighlight lang="text">
rcv_cr.lwe = seqno
rcv_cr.rwe = seqno + RQ_SIZE
rcv_cr.seqno = seqno
</syntaxhighlight>

If the inactive packet has DATA but no DRF, a rate-limited NACK is
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).

== 5. Send path ==

# If the SDU exceeds <code>(frag_mtu - data_hdr_len)</code>, the caller (<code>dev.c</code>) fans it out into <code>ceil(count / (frag_mtu - data_hdr_len))</code> fragments, each emitted via <code>frcti_snd</code> as its own DATA packet with a per-fragment role ([[#7.2. Fragmentation and reassembly|Section 7.2]]); both FRTX and best-effort flows fragment. Raw flows (no FRCP engagement, <code>qos.service == SVC_RAW</code>) carry no PCI and return <code>-EMSGSIZE</code> for any SDU larger than one packet at the layer below. An SDU that fits in a single packet is sent as SOLE. <code>frcti_snd</code> reserves PCI head room; sets DATA, plus DRF when the pipe is empty (<code>snd_cr.seqno == snd_cr.lwe</code>).
# <code>seqno_rotate()</code> if past sender inactivity and the pipe is empty ([[#4. Sequence-number rotation (DRF)|Section 4]]).
# Advertise FC (<code>pci.window = frcti_advert_rwe(frcti)</code>, i.e. <code>rcv_cr.rwe</code> clamped to <code>rcv_cr.lwe + ring_seq_cap</code> in stream mode) when the receiver side is recent: <code>now - rcv_cr.act < rcv_cr.inact</code>.
# Reliable mode (FRTX): leave <code>snd_cr.lwe</code> where it is; reset the slot at <code>RQ_SLOT(seqno)</code> (<code>snd_slots[p].time = now</code>, <code>snd_slots[p].flags = 0</code>); queue an <code>rxm_entry</code> (saves a packet copy, arms a wheel timer at <code>now + (rto << rto_mul)</code>). Piggyback ACK (<code>pci.ackno = rcv_cr.lwe</code>) while the a-timer for the most recent received DATA packet has not yet expired (<code>now - rcv_cr.act <= t_a</code>); on piggyback, set <code>rcv_cr.seqno = rcv_cr.lwe</code> so the next delayed-ACK fire is suppressed. See [[#8. Retransmission|Section 8]] for <code>t_a</code> / <code>t_r</code> semantics.
# Best-effort mode (no FRTX): advance <code>snd_cr.lwe</code> immediately (<code>snd_cr.lwe = snd_cr.lwe + 1</code>, <code>snd_cr.rwe = snd_cr.lwe + RQ_SIZE</code>); no retransmit state. No send-side RTT probe is armed in this mode (<code>rtt_probe_arm</code> requires an in-flight <code>seqno</code>, which best-effort never has); the rx-driven cold seeder in <code>frcti_rcv</code> is the only probe path.
# In reliable mode, optionally arm an RTT probe ([[#12. RTT estimation|Section 12]]).

== 6. Receive path ==

=== 6.1. Early-exit dispatch ===

Keepalive (KA), RTT probe (RTTP), pre-DRF NACK, and rendezvous
(RDVS) packets short-circuit out of <code>frcti_rcv</code> before the locked
main path; each handler takes its own lock internally.

<syntaxhighlight lang="text">
incoming packet
|
v
+---------+
| KA? |---yes--> ka_rcv ; return
+---------+
|no
v
+---------+
| RTTP? |---yes--> rttp_rcv; return
+---------+
|no
v
+---------+
| NACK? |---yes--> nack_rcv; return (see Section 9)
+---------+
|no
v
+---------+
| RDVS? |---yes--> rdv_rcv ; return (reply bare FC, ackno=0)
+---------+
|no
v
acquire wrlock; enter locked main path
</syntaxhighlight>

;<code>KA</code>
:refresh <code>t_ka_rcv</code>, honour piggybacked ACK.
;<code>RTTP</code>
:probe (echo back nonce) or echo (verify nonce, sample RTT).
;<code>NACK</code>
:pre-DRF, sender-side handler. See [[#9. Pre-DRF NACK|Section 9]].
;<code>RDVS</code>
:reply with a bare FC packet (<code>ackno = 0</code>); <code>rdlock</code> only.

=== 6.2. Locked main path ===

Steps below run with the per-flow <code>frcti.lock</code> held for writing
(<code>pthread_rwlock_wrlock</code>) unless noted.

;<code>rcv_inact_check</code>
:Only meaningful when the receive side is stale. On DRF (Data Run Flag): release <code>rq[]</code> slots, rebase <code>rcv_cr</code>, continue. On stale DATA without DRF: fire a pre-DRF NACK if cooldown allows ([[#9. Pre-DRF NACK|Section 9]]), then discard the packet; on cooldown, drop without sending a NACK (a pending cumulative ACK from <code>drop_packet</code> may still go out). Non-DATA, non-DRF arrivals bypass <code>rcv_inact_check</code> entirely; pure-DRF stale arrivals fall through after the DRF rebase branch.

;DATA-only act refresh
:Refresh <code>rcv_cr.act</code> only when <code>FRCT_DATA</code> is set, so that non-DATA packets never block the next DRF rebase.

;Wire-dup gate
:Before flag-driven dispatch, drop wire-duplicate ACKs and wire-duplicate DATA (<code>is_dup_ack</code> / <code>is_dup_data</code>). The DATA check is bypassed for <code>FRCT_RXM</code>-bearing arrivals so the piggybacked ACK / SACK / FC carried on a retransmitted DATA at an already-ACK'd <code>seqno</code> is still applied; the stale-in-window branch below then drops the packet.

;<code>ACK</code>
:Drop ACKs whose <code>ackno</code> falls outside <code>(snd_cr.lwe, snd_cr.seqno]</code>. If <code>ackno == snd_cr.lwe</code> (non-advancing cumulative ACK), drive RACK fast-retransmit consideration ([[#8. Retransmission|Section 8]]). Otherwise advance <code>snd_cr.lwe = ackno</code>, collapse <code>rto_mul</code> to 0 (Karn-gated by <code>SND_RTX</code> on the just-acknowledged slot, the old head-of-line), reset <code>dup_thresh</code> to 0, update <code>t_latest_ack</code> to the send-time of the slot at <code>ackno-1</code> (consumed by RACK and SACK below), decay <code>reo_wnd_mult</code> per RFC 8985 sec. 6.2 step 4, exit NewReno-careful recovery (see [[#8. Retransmission|Section 8]]) on <code>ackno >= recovery_high</code> or <code>ackno == snd_cr.seqno</code>, and feed an RTT sample if eligible ([[#12. RTT estimation|Section 12]]).

;<code>SACK</code>
:Walk the block list. For each block (a present range above <code>lwe</code>) NULL out <code>snd_slots[k].rxm</code>, clear the slot's per-send flags, and advance <code>t_latest_ack</code> to the latest send-time covered (the Forward Acknowledgement / fack equivalent, Mathis & Mahdavi 1996); the first block whose start clamps to <code>snd_cr.lwe</code> skips this fack update so that a head-of-line clamp does not falsely advance fack. For un-SACKed gaps below <code>hi_sacked</code>, stage a retransmit per slot that is (1) still owned (<code>rxm != NULL</code>), (2) not already <code>SND_FAST_RXM</code>, (3) not aged out past <code>t_r</code>, and (4) either outside the RACK reorder window <code>R</code> OR with <code>dup_thresh >= DUP_THRESH</code> (the RFC 8985 sec. 6.2 hybrid trigger). Mark the slot <code>SND_FAST_RXM</code> and NULL the <code>rxm</code> at stage time. Capped at <code>SACK_RXM_MAX</code> staged retransmits per receive pass; what's left rides the next SACK.

;<code>FC</code>
:Bump <code>snd_cr.rwe</code> (clamped to <code>lwe + RQ_SIZE</code>, never shrinks) and mark window open.

;<code>DATA</code>
:Bounds-check <code>seqno</code> against window. On stale-dup (<code>seqno < rcv_cr.lwe</code>), set <code>rcv_cr.seqno = seqno</code> to force a fresh ACK on the next <code>ack_snd</code>, then drop. On accept: both FRTX and best-effort stash the packet-buffer index into <code>rq[seqno mod RQ_SIZE]</code>. Fragments stash unchanged - the role bits are inspected only at consume time ([[#7.2. Fragmentation and reassembly|Section 7.2]]). On out-of-order arrival, build a SACK reply if not rate-limited (per [[#3. Protocol parameters|Section 3]]) and not deduplicated against the previous <code>(rcv_cr.lwe, n_blocks)</code> pair; D-SACK reports always bypass the dedup. If both rate-limit and dedup suppress the reply, neither SACK nor delayed-ACK fires (the sender picks up the gap on its next ACK). On in-order arrival, arm the delayed-ACK timer.

;<code>drop_packet</code> exit
:Releases the per-packet shared-memory buffer (<code>spb</code>), then calls <code>ack_snd</code> synchronously after the <code>spb</code> release to surface any pending cumulative ACK.

== 7. Read path and reassembly ==

=== 7.1. Read path ===

<code>flow_read</code> returns a full reassembled SDU (Service Data Unit) via
<code>frcti_consume</code> on every FRCP SDU-mode flow (FRTX or best-effort);
stream-mode is covered in [[#16. Stream-mode flows|Section 16]]. An incomplete head-of-line
(HoL) run yields <code>-EAGAIN</code>; an oversized run yields <code>-EMSGSIZE</code> (the
run is dropped so the flow does not stall). On best-effort flows,
a permanently-lost mid-fragment is dropped as soon as a later
complete SDU becomes visible in the ring ([[#7.2. Fragmentation and reassembly|Section 7.2]] skip-past-
gap).

Raw flows carry no <code>frcti</code>, so <code>flow_read</code> returns the next pending
packet-buffer index directly, with no role-bit inspection. (Raw
service is selected via <code>qos.service == SVC_RAW</code> at flow allocation,
which suppresses <code>frcti</code> creation.)

<code>frcti_pdu_ready</code> is the no-advance peek used by <code>fevent</code> (the
Ouroboros flow-event multiplexer, the <code>poll(2)</code>-equivalent on
flows). It returns ready only when the head-of-line run is
complete and the lead packet (a Protocol Data Unit, here one FRCP
packet) is present at <code>rcv_cr.rwe - RQ_SIZE</code>; any other state
(including the best-effort skip-past-gap case) returns not ready,
and <code>frcti_consume</code> is left to drop the broken prefix and re-
inspect.

=== 7.2. Fragmentation and reassembly ===

Send side (<code>flow_write_frag</code>). An SDU larger than
<code>(frag_mtu - PCI)</code> is split into <code>ceil(count / (frag_mtu - PCI))</code>
fragments; each fragment is its own FRCP packet with its own
<code>seqno</code> and a per-fragment role flag pair ([[#1.2. Flag bits|Section 1.2]]). Roles are
assigned at emit time:

{| class="wikitable"
! i !! Role
|-
| <code>n=1</code> || <code>SOLE</code>
|-
| <code>i=0</code> || <code>FIRST</code>
|-
| <code>i=n-1</code> || <code>LAST</code>
|-
| else || <code>MID</code>
|}

A mid-loop allocation or transmit failure may yield a partial
write: the call returns the bytes already enqueued (<code>off > 0</code>) or
the underlying error (<code>off == 0</code>). Best-effort flows fragment
identically; on the receiver, a partial run with a permanently-
lost fragment is dropped when a later complete SDU is visible in
the ring (see skip-past-gap below). Raw flows carry no PCI and
refuse anything larger than the layer's user MTU (<code>-EMSGSIZE</code>).

Wire-level recovery is fragment-agnostic on FRTX flows: each
fragment's <code>seqno</code> flows through SACK / RACK / RTO / NACK exactly
as for a SOLE DATA packet, and reassembly does not re-enter the
loss-detection path. Best-effort flows run the same <code>seqno</code>
machinery (DRF, FC, ACK piggyback, pre-DRF NACK emit) but queue
no <code>rxm</code> state at the sender, so a lost MID is unrecoverable;
skip-past-gap handles it (below).

Receive side. Fragments stash into <code>rq[seqno]</code> unchanged; role bits
are read only at consume time. <code>frag_run_inspect</code>, called from
<code>frcti_consume</code>, walks the ring starting at the oldest still-
undelivered <code>seqno</code> <code>base = rcv_cr.rwe - RQ_SIZE</code> (equal to <code>rcv_cr.lwe</code>
only when no partial run is in progress; during a partial run <code>lwe</code>
has already advanced past <code>base</code>). It produces one of three
outcomes:

{| class="wikitable"
! Outcome !! Cause
|-
| <code>DELIVER (n)</code>
| <code>rq[base]=SOLE</code> (<code>n=1</code>), or <code>rq[base]=FIRST</code> and a <code>LAST</code> follows in slots <code>[base+1..base+n-1]</code> with all intermediate roles in <code>{MID,FIRST,LAST}</code> contiguous.
|-
| <code>DROP (n)</code>
| <code>rq[base]</code> is <code>MID</code> or <code>LAST</code> without a preceding <code>FIRST</code> (<code>n=1</code>); a <code>FIRST..[non-LAST]..new-FIRST</code> or new-<code>SOLE</code> mid-run (drop the broken prefix with <code>n</code> = run length minus 1, so the new <code>FIRST</code>/<code>SOLE</code> stays); or, on best-effort flows, a gap at <code>base</code> with a <code>FIRST</code>/<code>SOLE</code> later in the ring (drop up to the new run start).
|-
| <code>NOT_READY</code>
| <code>rq[base]</code> absent or <code>FIRST..[non-LAST]</code> with no later <code>FIRST</code>/<code>SOLE</code> in the ring (FRTX waits for retx; best-effort waits for arrival).
|}

<code>DELIVER</code> triggers <code>frag_gather</code>: a scatter-gather <code>memcpy</code> of the <code>n</code>
consecutive fragments at <code>rq[base..base+n-1]</code> directly into the
caller's buffer; each per-packet shared-memory buffer (<code>spb</code>) is
released and <code>rwe</code> advances by <code>n</code>. <code>lwe</code> was already advanced
incrementally as each contiguous fragment arrived; <code>frag_gather</code>
only restores the fixed-width invariant <code>rwe == lwe + RQ_SIZE</code>.
No intermediate reassembly buffer is allocated.

<code>DROP</code> advances <code>rwe</code> past the broken prefix (releasing the <code>spb</code>s)
and pulls <code>lwe</code> up to the new trailing edge if needed; the next
consume retries from the new <code>base</code>. Oversize or arithmetically
overflowing delivery (sum of fragment lengths > <code>max_rcv_sdu</code>, sum
> caller's buffer, or running-sum overflow) also drops the run
with <code>-EMSGSIZE</code>.

Skip-past-gap (best-effort only). On FRTX, a gap in the run means
"waiting for retransmit" and <code>frag_run_inspect</code> returns <code>NOT_READY</code>.
On best-effort flows the gap is permanent, so <code>frag_run_inspect</code>
scans forward in the ring for the next <code>FIRST</code> or <code>SOLE</code>; if one is
visible within <code>RQ_SIZE</code>, it returns <code>DROP</code> for the broken prefix and
the consume loop retries at the new <code>lwe</code>. Memory hold is bounded
by <code>RQ_SIZE</code>; the partial releases on the next consume call once a
later complete run exists. Voice-like flows (one <code>SOLE</code> per SDU)
see no extra wait: any later <code>SOLE</code> makes the prior gap droppable
immediately.

The choice to defer reassembly to consume time keeps the receive
path zero-copy: fragments stay in the shared-memory ring until
the application pulls, and the SDU lands directly in the caller's
buffer.

== 8. Retransmission ==

FRCP is bounded by two delta-t-derived timers (Watson 1981, see
[[#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 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.

Each in-flight FRTX <code>seqno</code> owns one <code>rxm_entry</code>, armed in a hashed
timing wheel; the wheel deadline is the slot's next eligible
retransmit time.

;RTO timer
:On fire (<code>rxm_due</code>), re-emit with <code>FRCT_RXM</code>, mark <code>SND_RTX</code> (Karn-suppress next ACK's RTT sample), and (for the head-of-line (HoL) slot only) bump <code>rto_mul</code> up to <code>MAX_RTO_MUL</code>. Wheel deadline is <code>t_send + (rto << rto_mul)</code>. Re-armed unless consumed. The RTO timer also clears <code>SND_FAST_RXM</code> (re-arming fast-retransmit eligibility), resets <code>reo_wnd_mult</code> to 1 on a HoL fire (RFC 8985 sec. 6.2 step 4 reset clause), and marks the flow <code>ACL_FLOWDOWN</code> if its <code>frct_tx</code> call fails.

;r-timer guard
:Before any retransmit attempt, check <code>(now - t0)</code> against <code>t_r</code>. If exceeded, the slot is no longer eligible for retransmit. Only the RTO timer (<code>rxm_due</code>) treats r-timer expiry as terminal: it marks the flow <code>ACL_FLOWDOWN</code> (peer unreachable). Fast-retransmit, SACK-driven retransmit, and NACK-driven head-of-line re-emit silently skip aged-out slots and defer the flow-down decision to the next RTO fire.

;Fast retransmit (hybrid trigger, RFC 8985 sec. 6.2)
:On a non-advancing cumulative ACK with the scoreboard advanced, fire one fast retransmit when EITHER (a) the head-of-line slot's latest send is older than the RACK reorder window <code>R</code> ([[#3. Protocol parameters|Section 3]]) and not yet aged out, OR (b) the SACK <code>dup-thresh</code> count above <code>snd_cr.lwe</code> reaches <code>DUP_THRESH</code> (= 3, RFC 8985 sec. 6.2 step 4). Fires at most once per non-advancing cumulative-ACK value, gated by <code>rack_fired_lwe</code> (the <code>snd_cr.lwe</code> at which fast-retransmit last fired). Set <code>SND_FAST_RXM</code> on the slot (one-shot per-slot gate) and enter NewReno-style careful recovery (see NewReno below in this section).
:The RACK reorder window <code>R</code> uses the RFC 8985 sec. 6.2 form <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> with a <code>MIN_REORDER_NS = 250 us</code> floor. Before the first RTT sample seeds <code>min_rtt</code>, <code>R</code> falls back to <code>MIN(reo_wnd_mult * SRTT / 4, SRTT)</code>, still floored at <code>MIN_REORDER_NS</code> (consistent with the windowed-minimum fallback described in [[#12. RTT estimation|Section 12]]). <code>min_rtt</code> is a windowed minimum over the last <code>MIN_RTT_WIN_NS</code> = 5 min of RTT samples (matches the Linux <code>tcp_min_rtt_wlen</code> default) so a route change to a longer path eventually re-anchors the reorder window without relying on <code>reo_wnd_mult</code> growth alone.

;SACK-driven retransmit
:For each gap below <code>hi_sacked</code> whose slot is (1) still owned, (2) not already <code>SND_FAST_RXM</code>, (3) not aged out past <code>t_r</code>, and (4) either outside the RACK window <code>R</code> OR with <code>dup_thresh >= DUP_THRESH</code> (same hybrid as fast-retransmit, see [[#6.2. Locked main path|Section 6.2]]), re-emit. Each SACK-driven retransmit re-arms a fresh <code>rxm</code> so a lost retransmit can still be recovered by its own RTO timer.

;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.

== 9. Pre-DRF NACK ==

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.

;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>)
:When an incoming DATA packet has no DRF and rcv-side activity is older than <code>rcv_cr.inact</code>, the receiver emits a bare packet with <code>flags = FRCT_NACK</code> and <code>seqno = arrival_seqno - 1</code> (informational only, not consulted by the receive handler). The cooldown in [[#3. Protocol parameters|Section 3]] rate-limits the burst. Non-DATA non-DRF arrivals bypass <code>rcv_inact_check</code> entirely; non-DATA DRF still rebases via the DRF branch.

;Receive (<code>frcti_nack_rcv</code>)
: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 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.

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 ==

Cumulative ACK is <code>ackno = rcv_cr.lwe</code>. On out-of-order arrival the
receiver also emits a SACK packet ([[#1.3. SACK payload|Section 1.3]]) whose payload lists
''present'' blocks above <code>lwe</code> (analogous to TCP SACK / QUIC ACK
ranges). SACKs are rate-limited per [[#3. Protocol parameters|Section 3]] and suppressed when
neither <code>lwe</code> nor block count has changed since the last SACK.

D-SACK reports (RFC 2883) are emitted in-band as <code>block[0]</code> of an
otherwise normal SACK frame (see [[#1.3. SACK payload|Section 1.3]] for the encoding).
Two receiver triggers arm a pending D-SACK report (single-slot,
latest-wins):

* DATA arrival with <code>seqno < rcv_cr.lwe</code>, both wire-dup (no RXM, <code>is_dup_data</code> path) and retransmit (RXM, post-FC branch) (RFC 2883 sec. 4.1.1, full duplicate)
* <code>rq_accept</code> conflict, slot already occupied in <code>[lwe, rwe)</code> (RFC 2883 sec. 4.1.2, partial duplicate)

When a D-SACK is pending and the standard scoreboard SACK would be
suppressed by dedup or rate-limit, the report is emitted as a
stand-alone SACK frame through the normal <code>ack_snd</code> path; when a
D-SACK report is pending the path bypasses dedup and the <code>TICTIME</code>
rate-limit, but the a-timer suppression on rcv inactivity still
applies.

Bare ACKs are deferred via a per-flow delayed-ACK timer (one in
flight at a time, atomic test-and-set dedup; fires per [[#3. Protocol parameters|Section 3]]
after the first in-order arrival). Suppressed if (1) no new
<code>seqno</code>, (2) rcv side is inactive (older than <code>t_a</code>), or (3) the
sender just sent within <code>TICTIME</code>. A pending D-SACK ride-through
bypasses (1) and (3); the a-timer gate (2) is unconditional.

== 11. Flow control ==

The receiver advertises <code>rwe</code> in every FC field. The sender treats
its <code>snd_cr.rwe</code> as the absolute right edge: when
<code>snd_cr.seqno >= snd_cr.rwe</code> the window is closed and <code>flow_write</code>
yields. While closed, the sender periodically emits RDVS
(rendezvous) packets (cadence <code>DELT_RDV</code>); the receiver replies with
a bare FC packet (<code>ackno = 0</code>) that reopens the window. Once the
window has been closed for longer than <code>MAX_RDV</code> the sender stops
emitting RDVS but does not tear the flow down - the writer keeps
blocking until either a peer-driven FC arrives or the KA
(keepalive) / r-timer marks the flow.

<code>rwe</code> is clamped to <code>lwe + RQ_SIZE</code> on receipt and MUST NOT shrink:
a backward <code>rwe</code> is silently clamped to the current <code>snd_cr.rwe</code>;
the FC packet still reopens the window.

== 12. RTT estimation ==

Active RTTP probes ([[#1.4. RTTP payload|Section 1.4]]) carry a 32-bit <code>probe_id</code> (0
reserved) and a 16-byte random nonce echoed verbatim - defends
against spoofed replies. A ring of <code>RTTP_RING</code> in-flight probes is
kept; an echo whose <code>(id, nonce)</code> doesn't match the ring slot is
dropped. A single RTTP sample is clamped to <code>RTT_CLAMP_MUL * srtt</code>
(compile-time <code>RTT_CLAMP_MUL = 16</code>) once <code>srtt</code> is seeded; the first
cold-probe sample feeds <code>rtt_update</code> raw.

Probe arming gates:

;Cold (no <code>srtt</code> yet)
:the receive path arms at most one probe per 100 ms via <code>frcti_rcv_probe</code> (<code>PROBE_DUE_COLD</code>); arming requires an incoming packet. Active send-path arming bails while <code>srtt == 0</code>.
;Warm (<code>rtt_probe_arm</code>, called from <code>frcti_snd</code>)
:outstanding data (<code>snd_cr.seqno > snd_cr.lwe</code>), AND at least <code>2 * srtt</code> since <code>t_rcv_rtt</code> (last RTT receive of any kind), AND at least <code>srtt</code> since <code>t_snd_probe</code> (last probe emit).

Sample feeds either Linux's asymmetric <code>mdev</code> estimator
(<code>FRCT_LINUX_RTT_ESTIMATOR</code>, default ON) or RFC 6298 symmetric EWMA
(compile option). <code>srtt</code> is floored at 10 ms when seeded from a
hint, at 1 us after every update (including the first seeding
sample); <code>mdev</code> floored at 100 ns.

:<code>RTO = max(rto_min, 2 * srtt, srtt + (mdev << MDEV_MUL))</code>

(the <code>2 * srtt</code> floor is an FRCT addition not in RFC 6298).
Effective wheel deadline capped per [[#3. Protocol parameters|Section 3]].

ACK-derived samples (<code>frcti_ack_rcv</code> -> <code>rtt_sample_eligible</code>), beyond
the cum-ACK advance gate in <code>frcti_ack_rcv</code> (<code>ackno > lwe</code> and
<code>ackno <= seqno</code>), require all of: not in recovery; ACK packet does
not carry <code>FRCT_RXM</code>; HoL slot's <code>SND_RTX</code> bit clear; slot's <code>rxm</code>
pointer non-NULL (not SACK-consumed); <code>lwe</code> not below the <code>rtt_lwe</code>
fence; <code>srtt</code> already seeded by an RTTP probe. There is no ACK-only
seeding.

Every eligible sample also feeds <code>RACK.min_RTT</code> (RFC 8985 sec. 6.2)
via a windowed minimum: replace whenever the sample is strictly
smaller OR more than <code>MIN_RTT_WIN_NS</code> (5 min, matches Linux
<code>tcp_min_rtt_wlen</code>) has elapsed since the current min was set. The
downward branch is immediate (faster path picked up at once); the
upward branch is gated on the window (a transient queue burst does
not poison the estimate, but a sustained route change to a longer
path re-anchors <code>min_RTT</code> after at most one window). Seeded from
<code>rtt_hint</code> at <code>rtt_init</code>; 0 acts as the unset sentinel and the base
in <code>rack_reorder_window</code> falls back from <code>min_RTT</code> to <code>SRTT</code> (so
<code>R = mult * SRTT/4</code>, capped at <code>SRTT</code>, floored at <code>MIN_REORDER_NS</code>)
until the first sample. See [[#6.2. Locked main path|Section 6.2]].

== 13. Liveness (keepalive) ==

When <code>qs.timeout > 0</code> a per-flow KA (keepalive) timer is armed.
Arming uses <code>rcv_cr.act</code> for the deadline computation:

:<code>deadline = min(snd_act + qs.timeout/4, rcv_act + qs.timeout)</code>

(clamped to <code>now + qs.timeout/4</code> if already past). The timer fires
either on sender idleness (to send a KA) or on receiver idleness
(to declare the peer dead). On fire (<code>ka_snd</code>) the peer-dead test
uses <code>max(rcv_cr.act, t_ka_rcv)</code> so a recent KA reply counts even
when no DATA has arrived:

* If <code>now - max(rcv_cr.act, t_ka_rcv) > qs.timeout</code>, mark the flow <code>ACL_FLOWPEER</code> and notify the per-process flow-event set (<code>proc.fqset</code>) with <code>FLOW_PEER</code>.
* Else if <code>snd_idle > qs.timeout/4</code>, emit a bare <code>KA | ACK</code> (<code>ackno = rcv_cr.lwe</code>) and re-arm.
* Else just re-arm.

Note: <code>rx_rb</code> and <code>tx_rb</code> are the receive and transmit shared-memory
ring buffers. The r-timer raises <code>ACL_FLOWDOWN</code> on both (route is
broken); keepalive raises <code>ACL_FLOWPEER</code> on <code>rx_rb</code> only and notifies
the flow-event set (peer is silent, writer keeps <code>tx_rb</code> usable) -
distinct ACLs. <code>qs.timeout == 0</code> disables keepalive entirely; a
silent peer crash is then undetected.

== 14. Linger / teardown ==

On <code>flow_dealloc</code>, <code>frcti_dealloc</code> computes a grace timeout

:<code>max(rcv_cr.act + rcv_cr.inact, snd_cr.act + snd_cr.inact) - now</code>

(floored at 0 and converted to seconds) and returns it; <code>flow_dealloc</code>
forwards this to the IRMd as the dealloc grace. The IRMd, not FRCT,
performs the wait. Before computing the timeout, FRCT may emit a
final ACK when <code>rcv_cr.lwe != rcv_cr.seqno</code> (the peer has not been
told the most recent cumulative ACK) AND the rcv side has been
active within <code>t_a</code> (a-timer not aged out).

<code>FRCTFLINGER</code> is honoured only when <code>snd_cr.lwe < edge</code>, where <code>edge =
snd_fin_seqno</code> after FIN has been sent in stream mode and
<code>snd_cr.seqno</code> otherwise (data or FIN still in flight). The drain
itself runs in <code>flow_dealloc</code>'s <code>while (FRCTI_LINGERING)</code> loop, not in
<code>frcti_dealloc</code>.

The fd is single-reader / single-writer (documented in the
manpages). <code>flow_write</code> pumps <code>rx_rb</code> on every call (via
<code>flow_wait_window</code> -> <code>flow_drain_rx_nb</code>) and additionally blocks on
<code>rx_rb</code> when the send window is closed. A pure-writer thread thus
consumes ACKs without a dedicated reader.

== 15. Heritage and adopted techniques ==

Delta-t (Watson, 1981) is the primary heritage; FRCP descends from
the delta-t protocol family via the Recursive InterNetwork
Architecture (RINA; Day, "Patterns in Network Architecture", 2008,
ch. 9). Timer-based connection management
(no SYN/FIN handshake, per-flow state born on first DATA and
reclaimed after <code>t_mpl + a + r</code> of silence), the DRF marker, and the
<code>t_mpl</code> / <code>t_a</code> / <code>t_r</code> timers all come from delta-t. See Watson,
"Timer-Based Mechanisms in Reliable Transport Protocol Connection
Management", Computer Networks 5 (1981).

The unified <code>flow_alloc(name, qos, ...)</code> primitive and its
multi-axis QoS-cube argument ([[#2.2. Service modes (orthogonal axes)|Section 2.2]]) also come from RINA
(Day 2008, ch. 6; Grasa et al., "IRATI: investigating RINA as an
alternative to TCP/IP", Computer Networks 92 (2015)) - reliability,
ordering, CRC presence, and encryption are flow attributes, not
separate sockets or protocols.

The table below summarises additional adopted techniques and their
references.

{| class="wikitable"
! FRCP mechanism !! Heritage !! Reference / note
|-
| Random new <code>seqno</code> on <code>seqno_rotate</code> || TCP ISN || RFC 6528 (Gont & Bellovin, 2012). QUIC PN-space reset (RFC 9000 sec. 12.3) is a structural analogue.
|-
| Cumulative ACK, left-window-edge advance || TCP || RFC 793 / RFC 9293
|-
| Receive window with non-shrink rule || TCP || RFC 793 sec. 3.7 / RFC 9293 sec. 3.8.6; RFC 1122 sec. 4.2.2.16 for the explicit non-shrink prohibition
|-
| Modular <code>seqno</code> arithmetic (<code>before</code>/<code>after</code> helpers) || TCP || RFC 793 sec. 3.3 / RFC 9293 sec. 3.4
|-
| Selective ACK block list || TCP || RFC 2018 (Mathis et al., 1996). Encoded as a typed FRCP packet rather than a TCP option, so framing is closer to QUIC ACK frames. D-SACK (RFC 2883) carried in-band as <code>block[0]</code>; see [[#1.3. SACK payload|Section 1.3]].
|-
| NewReno-careful recovery with <code>recovery_high</code> gate || TCP || RFC 6582 (Henderson et al., 2012); QUIC builds on the same model in RFC 9002 sec. 7.3.2. Cwnd half absent (CC in IPCP).
|-
| RACK reordering window for fast retransmit || TCP || RFC 8985 (Cheng et al., 2021). FRCP <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> with a <code>MIN_REORDER_NS = 250 us</code> floor against <code>srtt</code> collapse; matches RFC 8985 sec. 6.2 and Linux <code>tcp_rack_reo_wnd</code>. DSACK-driven <code>reo_wnd_mult</code> (sec. 6.2 step 4) is adopted; see [[#1.3. SACK payload|Section 1.3]] for the wire encoding. The hybrid RACK-or-<code>DUP_THRESH</code> trigger from RFC 8985 sec. 6.2 step 4 is adopted ([[#8. Retransmission|Section 8]]). QUIC's analogue in RFC 9002 sec. 6.1.2 uses <code>max(srtt, latest_rtt)</code> as the base.
|-
| 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> = 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.
|-
| Delayed ACK with rate suppression || TCP || RFC 813 (Clark, 1982); RFC 1122 sec. 4.2.3.2; RFC 5681 sec. 4.2. Single-deadline coalescing rather than "ack-every-other-segment".
|-
| Zero-window-probe / persist-timer analogue (RDVS) || TCP || RFC 1122 sec. 4.2.2.17 / RFC 9293 sec. 3.8.6.1. RDVS solicits an FC reply, distinct from QUIC <code>DATA_BLOCKED</code> (RFC 9000 sec. 19.12), which is one-way notification. <code>MAX_RDV</code> give-up departs from TCP.
|-
| Multiplexed control on a single PCI || SCTP / QUIC || SCTP chunk bundling (RFC 9260 sec. 6.10); QUIC frame multiplexing (RFC 9000 sec. 12.4). Cleaner fit than TCP's separate-flag-bits design.
|-
| ACK ranges as multiple discontiguous acked blocks || QUIC || QUIC ACK frame (RFC 9000 sec. 19.3). FRCP SACK is conceptually QUIC-frame-shaped even though encoded as absolute <code>[start,end]</code> pairs.
|-
| Nonce-authenticated active RTT / liveness probing (RTTP) || QUIC <code>PATH_CHALLENGE</code> || <code>PATH_CHALLENGE</code> / <code>PATH_RESPONSE</code> (RFC 9000 sec. 8.2, sec. 19.17, sec. 19.18). WebRTC ICE consent-freshness (RFC 7675) is the same pattern. QUIC's nonce is 8 octets; FRCP chooses 16.
|-
| Probing distinct from keepalive || QUIC || KA timer answers "peer alive?", RTTP answers "path measurable?", as in QUIC PING (RFC 9000 sec. 19.2) vs <code>PATH_CHALLENGE</code>.
|-
| Bare KA + ACK keepalive packets || QUIC / SCTP || QUIC PING (RFC 9000 sec. 19.2); SCTP HEARTBEAT / HEARTBEAT-ACK (RFC 9260 sec. 8.3). SCTP HEARTBEAT also carries an opaque echoed blob, structurally similar to FRCP RTTP.
|-
| (<code>FFGM</code>, <code>LFGM</code>) fragment-role bits ([[#7.2. Fragmentation and reassembly|Section 7.2]]) || SCTP || RFC 9260 sec. 3.3.1 DATA chunk B/E bits encode the same four states (<code>B+E=SOLE</code>, <code>B-only=FIRST</code>, neither=<code>MID</code>, <code>E-only=LAST</code>). Each fragment carries its own <code>seqno</code>/TSN and is independently retransmitted.
|-
| Stream byte-offset reassembly (Sections [[#1.5. Stream PCI extension|1.5]], [[#16. Stream-mode flows|16]]) || QUIC || QUIC STREAM frame (RFC 9000 sec. 19.8) uses Offset + Length varints; FRCP uses fixed 32-bit <code>start</code> / <code>end</code>. One stream per flow vs QUIC's many streams multiplexed.
|-
| FIN end-of-stream marker (Sections [[#1.2. Flag bits|1.2]], [[#16. Stream-mode flows|16]]) || TCP / QUIC || TCP FIN flag (RFC 9293 sec. 3.1) closes one half of the byte stream; QUIC STREAM frame FIN bit (RFC 9000 sec. 19.8) does the same per stream with an immutable final-size invariance (RFC 9000 sec. 4.5: the final size is fixed once observed). FRCP's FIN consumes one packet <code>seqno</code> (not one byte of stream space) and is idempotent on the sender side.
|-
| Stream byte-credit flow control ([[#16. Stream-mode flows|Section 16]]) || QUIC || <code>MAX_STREAM_DATA</code> (RFC 9000 sec. 4.1, sec. 19.10). FRCP projects a per-flow byte budget onto the <code>seqno</code>-space <code>rwe</code>. Single stream per flow collapses QUIC's <code>MAX_DATA</code> / <code>MAX_STREAM_DATA</code> distinction.
|-
| Header protection (encrypted seqnos) || QUIC || QUIC RFC 9001 sec. 5.4 applies header protection on top of AEAD to mask the packet number. FRCP's per-flow AEAD wrap ([[#16. Stream-mode flows|Section 16]]) is wider: it encrypts the entire PCI including <code>seqno</code> because the IPCP below already routes, so no destination connection-ID needs to stay in clear (cf. RFC 9000 sec. 5.2).
|-
| Two-bit fragment role polarity || SCTP || The (<code>FFGM</code>, <code>LFGM</code>) pair follows SCTP B/E (begin = 1 / end = 1) rather than IPv4 MF (RFC 791 sec. 3.2), which has the inverse polarity (MF = 1 means NOT last).
|-
| Orthogonal reliability / ordering axes ([[#2.2. Service modes (orthogonal axes)|Section 2.2]]) || SCTP || PR-SCTP (RFC 3758, per-message partial reliability) and SCTP DATA U-bit (RFC 9260 sec. 3.3.1, per-message unordered) are the closest precedents for decoupling reliability from ordering; FRCP sets them per-flow rather than per-message.
|-
| Orthogonal CRC (<code>qs.ber == 0</code>) || UDP-Lite || RFC 3828 (Larzon et al., 2004) lets the sender pick a per-packet Checksum Coverage and the receiver enforce a locally configured minimum (no in-band negotiation; sec. 3.1, sec. 3.3). FRCP gates a full CRC trailer on <code>qs.ber == 0</code> at flow setup. Contrast TCP / SCTP (mandatory checksum) and QUIC (AEAD subsumes CRC).
|-
| Setup-time service negotiation || DCCP / SCTP / QUIC || DCCP Service Codes (RFC 4340 sec. 8.1.2, RFC 5595); SCTP INIT parameters (RFC 9260 sec. 3.3.2); QUIC transport parameters (RFC 9000 sec. 7.4). All negotiate service properties at connection setup; only RINA's QoS cube exposes them as an orthogonal vector.
|}

=== 15.1. Original to FRCP (no clean prior art) ===

* Pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]): receiver-driven nudge exploiting <code>snd_cr.inact > rcv_cr.inact</code>. Closest analogues are SCTP Gap Ack Blocks (RFC 9260 sec. 3.3.4) and DCCP Ack Vector (RFC 4340 sec. 11.4) - both let the receiver describe gaps to the sender, but neither targets the cross-epoch / pre-DRF case.
* <code>MAX_RDV</code> window-probe give-up: neither TCP (persist-timer probes until application or R2 abort, RFC 9293 sec. 3.8.6.1) nor QUIC has an explicit FC-give-up counter. A recursive-network choice: outer layers can drop the flow.
* Skip-past-gap reassembly ([[#7.2. Fragmentation and reassembly|Section 7.2]]): SCTP fragments and reassembles every flow regardless of reliability/ordering, using its own per-stream reassembly queue; QUIC fragments via STREAM offsets. FRCP fragments best-effort flows too, but the receiver drops the broken prefix the moment a later run-start (<code>FIRST</code> or <code>SOLE</code> role) is visible inside the <code>RQ_SIZE</code>-wide reorder ring - no IP-frag-style timeout, no SCTP-style explicit abort. If no later run-start arrives within the ring, <code>frag_run_inspect</code> returns <code>NOT_READY</code> and the partial run keeps its slots; the next inspect retries. The trade-off: a permanently-lost <code>MID</code> in a long isolated run holds slots until either a later <code>FIRST</code>/<code>SOLE</code> appears in the ring or the writer stops, at which point the slots are reclaimed on flow teardown.
* Reassembly deferred to consume time ([[#7.2. Fragmentation and reassembly|Section 7.2]]), message mode only (<code>qos.service == SVC_MESSAGE</code>): SCTP (RFC 9260 sec. 6.9), QUIC (RFC 9000 sec. 2.2), and TCP (RFC 9293) all hold reassembly state at the receive boundary. FRCP message-mode leaves fragments in the shared-memory ring until <code>flow_read</code> pulls and lands the SDU directly in the caller's buffer. Stream mode ([[#16. Stream-mode flows|Section 16]]) uses the standard QUIC-style direct ring placement on receive and does not defer. The optimisation is enabled by the Shared-Memory Subsystem (SSM) packet-buffer ring (see <code>struct ssm_pk_buff</code> at [[#1.1. PCI header|Section 1.1]]); the analogue is OS-level scatter-gather I/O (<code>recvmsg+iovec</code>), not a transport-layer prior art.
* TLP-equivalent tail-loss recovery (RFC 8985 sec. 7; RFC 9002 sec. 6.2): FRCP does not emit an explicit Tail Loss Probe packet, but the same goal is met implicitly by RACK loss detection ([[#8. Retransmission|Section 8]]) firing on a non-advancing cumulative ACK once the head-of-line slot ages past the RACK reorder window <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> - well below <code>RTO = max(2 * SRTT, SRTT + (mdev << MDEV_MUL))</code>. A receiver-driven nudge is also available via the pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]).

=== 15.2. Not adopted ===

* Slow start, congestion window (cwnd), Additive Increase / Multiplicative Decrease (AIMD), NewReno cwnd inflation. Congestion control lives in the IPCP CA policies and is driven by Explicit Congestion Notification (ECN, RFC 3168).
* Nagle / silly-window-syndrome (SWS) avoidance (RFC 896, RFC 1122 sec. 4.2.3.4). (Deferred work, not adopted in the current spec.)
* TCP Timestamps (RFC 7323) / Protection Against Wrapped Sequences (PAWS) - RTT measurement uses RTTP, not per-segment timestamps. A peer-supplied timestamp echoed on every ACK lets a malicious peer drive the <code>srtt</code> estimate arbitrarily low, collapsing the RTO and triggering a self-inflicted retransmit storm. RTTP confines RTT measurement to nonce-authenticated probe round-trips, where a forged echo is rejected before it can reach the estimator.
* ECN (Explicit Congestion Notification) response inside FRCP (consumed by IPCP Congestion Avoidance / CA).
* 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).

== 16. Stream-mode flows ==

When a flow is allocated with <code>qos.service == SVC_STREAM</code> both peers
switch to byte-stream semantics, layered on top of the FRTX reorder
machinery already described in Sections [[#6. Receive path|6]]-[[#8. Retransmission|8]].

=== 16.1. Send ===

The sender splits the caller's octets into chunks of at most
<code>(frag_mtu - base PCI - stream PCI extension)</code> octets (Sections [[#1.1. PCI header|1.1]]
and [[#1.5. Stream PCI extension|1.5]]). Each chunk is one DATA packet with its own <code>seqno</code> and a
<code>[start, end)</code> byte range copied from a monotonic stream counter.
In stream mode <code>FFGM</code> and <code>LFGM</code> are unused and MUST be transmitted as
zero; the per-byte position is carried by the <code>[start, end)</code>
extension instead.

End-of-stream is signalled with a 0-byte DATA packet that has <code>FIN</code>
(bit 12) set, emitted on the FIN triggers listed in [[#1.2. Flag bits|Section 1.2]]
(WR-half close, <code>flow_dealloc</code>, and any other path that yields the
final byte). The sender MUST emit at most one FIN per flow; its
<code>[start, end)</code> MUST equal <code>[final-byte, final-byte)</code> (i.e., empty
interval at the final byte position; final-size invariance,
analogous to QUIC RFC 9000 sec. 4.5). Idempotency is enforced by
an <code>snd_fin_sent</code> guard.

=== 16.2. Receive ===

On arrival the receiver places the payload directly into a per-flow
byte-indexed receive ring of width <code>ring_sz</code> (octets) at the position
indicated by <code>start</code>, with a two-segment <code>memcpy</code> across the ring
boundary if needed. Receipt is recorded in the FRTX reorder
machinery ([[#6.2. Locked main path|Section 6.2]]) augmented with the packet's <code>start</code>, <code>end</code>, and
FIN bit per slot. When a packet's <code>[start, end)</code> front-overlaps
bytes already at or below the byte high-water mark, the overlap is
trimmed before placement so the same byte is never written twice.
After stashing, the receiver advances <code>lwe</code> and the byte high-water
mark across any newly-contiguous prefix. Each slot advanced MUST
satisfy <code>start == the last-delivered slot's end</code>; a slot whose
<code>start</code> does not equal that <code>end</code> is silently dropped at delivery time
(the <code>seqno</code> is consumed, no stream bytes contributed) and the high-
water mark does not advance past it. The stream byte-stream
stalls at that point - there is no flow-tear-down on mismatch.
This filters spliced or off-path-injected slots that fall in
window without strong cryptographic authentication.

A FIN slot marks end-of-stream at advance time only if its byte
position equals the last-delivered slot's <code>end</code>; otherwise the FIN
is ignored and the corresponding <code>seqno</code> occupies a slot but
contributes no stream bytes. No packet buffer is held after the
ring copy.

=== 16.3. Read ===

<code>flow_read</code> returns up to <code>count</code> octets from the contiguous prefix
<code>[next, high-water)</code>, where <code>next</code> is the byte the application has
already consumed up to and <code>high-water</code> is the rightmost contiguous
byte received. When the stream is fully drained AND end-of-stream
(EOS) was observed (<code>next == EOS</code> byte position), <code>flow_read</code> returns
0 (<code>EOF</code>) - the same shape POSIX <code>read(2)</code> uses on TCP after a peer
FIN.

=== 16.4. Flow control ===

ACK / SACK / RACK / RTO machinery is unchanged; the FRTX reorder
ring is reused as a per-<code>seqno</code> received-bitmap. Let <code>per_pkt =
(frag_mtu - base PCI - stream PCI extension)</code>, the maximum stream-
byte payload one DATA packet can carry ([[#16.1. Send|Section 16.1]]). The
receive window advertised in FC is clamped so the byte window
(<code>ring_sz</code>) cannot be overrun: the <code>seqno</code>-space <code>rwe</code> is at most
<code>rcv_cr.lwe + ring_sz / per_pkt</code>.

This is the QUIC byte-credit flow-control model
(<code>MAX_STREAM_DATA</code>, RFC 9000 sec. 4.1 and sec. 19.10) projected onto
<code>seqno</code> space. With one stream per flow there is no <code>MAX_DATA</code> /
<code>MAX_STREAM_DATA</code> distinction. Receiver-side silly-window-syndrome
(SWS) avoidance (RFC 9293 sec. 3.8.6.2.2) is achieved by combining
the consume-time <code>rwe</code> bump with the global non-shrink rule from
[[#11. Flow control|Section 11]].

=== 16.5. Security considerations ===

Threat model. An attacker that can observe (on-path passive) or
predict (off-path blind) the flow's seqnos and byte offsets on an
unencrypted stream flow can inject DATA or FIN at any in-window
position. The in-line consistency checks above (<code>start</code> == prior
<code>end</code> on advance; FIN MUST be 0-byte; FIN MUST sit at the final
byte position) realise the spirit of RFC 5961's "sequence-window
plus exact-position match for control bits" without an explicit
challenge-ACK probe; they make a few specific blind attack shapes
harder but are not cryptographic authentication. This is
comparable to TCP without the TCP Authentication Option (TCP-AO,
RFC 5925), tighter than a
pre-RFC-5961 TCP stack, and roughly equivalent to a modern
RFC 5961 stack against blind off-path injection - none of these
help once the attacker can sniff. TLS over TCP (RFC 8446)
encrypts only the TCP payload and leaves TCP seqnos, ACKs, FIN,
and RST in the clear, so TLS does NOT defend against TCP-header-
level injection; QUIC (RFC 9000) hides packet numbers under
header protection (RFC 9001 sec. 5.4), so this specific weakness
does not apply to QUIC.

Mitigation: AEAD. When the flow has encryption enabled the
recommended AEAD ciphers (AES-GCM, RFC 5288; or ChaCha20-Poly1305,
RFC 8439) wrap the entire FRCP packet on the wire - PCI, stream
extension, body, and the CRC trailer when <code>ber == 0</code> - under a
per-flow symmetric key derived from the flow's own key exchange
([[#1.1. PCI header|Section 1.1]]). The AEAD tag (~2^-128 forgery probability)
dominates the CRC (~2^-32) for integrity in this mode but the CRC
trailer is currently retained inside the wrap (see [[#1.1. PCI header|Section 1.1]]).
Implementations MUST NOT rely on the security properties below
when a non-AEAD cipher (e.g. AES-CTR alone) is negotiated; non-
AEAD modes provide confidentiality only and the threat-model
claims do not hold.

With an AEAD cipher in use, seqnos, byte offsets, and the FIN bit
are both authenticated and confidential. Against an off-path or
on-path-passive attacker this is:

* Stronger than TCP+TLS (TCP header in the clear).
* Stronger than TCP+TCP-AO (header authenticated but visible).
* 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. 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 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
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 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 ==

This section lists the IETF documents, published works, and
source-code references cited inline elsewhere in this document.
IETF documents are cited inline as "RFC NNNN sec. X.Y"; books,
journal papers, and source-code references are cited inline by
author and year (or by file and function name) and are listed
here for convenience.

=== 17.1. IETF documents ===

;[RFC 791]
:J. Postel, "Internet Protocol", STD 5, RFC 791, September 1981.
;[RFC 793]
:J. Postel, "Transmission Control Protocol", STD 7, RFC 793, September 1981. Obsoleted by RFC 9293.
;[RFC 813]
:D. D. Clark, "Window and Acknowledgement Strategy in TCP", RFC 813, July 1982.
;[RFC 896]
:J. Nagle, "Congestion Control in IP/TCP Internetworks", RFC 896, January 1984.
;[RFC 1122]
:R. Braden (ed.), "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
;[RFC 2018]
:M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
;[RFC 2119]
:S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
;[RFC 2883]
:S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
;[RFC 3758]
:R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
;[RFC 3828]
:L-A. Larzon, M. Degermark, S. Pink, L-E. Jonsson (ed.), G. Fairhurst (ed.), "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
;[RFC 4303]
:S. Kent, "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
;[RFC 4340]
:E. Kohler, M. Handley, S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
;[RFC 5288]
:J. Salowey, A. Choudhury, D. McGrew, "AES Galois Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, August 2008.
;[RFC 5595]
:G. Fairhurst, "The Datagram Congestion Control Protocol (DCCP) Service Codes", RFC 5595, September 2009.
;[RFC 5681]
:M. Allman, V. Paxson, E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
;[RFC 5925]
:J. Touch, A. Mankin, R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
;[RFC 5961]
:A. Ramaiah, R. Stewart, M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, August 2010.
;[RFC 6298]
:V. Paxson, M. Allman, J. Chu, M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, June 2011.
;[RFC 6528]
:F. Gont, S. Bellovin, "Defending against Sequence Number Attacks", RFC 6528, February 2012. Obsoletes RFC 1948.
;[RFC 6582]
:T. Henderson, S. Floyd, A. Gurtov, Y. Nishida, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 6582, April 2012.
;[RFC 7323]
:D. Borman, B. Braden, V. Jacobson, R. Scheffenegger (ed.), "TCP Extensions for High Performance", RFC 7323, September 2014.
;[RFC 7675]
:M. Perumal, D. Wing, R. Ravindranath, T. Reddy, M. Thomson, "Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness", RFC 7675, October 2015.
;[RFC 8174]
:B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017.
;[RFC 8200]
:S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, July 2017.
;[RFC 8439]
:Y. Nir, A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 8439, June 2018.
;[RFC 8446]
:E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, August 2018.
;[RFC 8985]
:Y. Cheng, N. Cardwell, N. Dukkipati, P. Jha, "The RACK-TLP Loss Detection Algorithm for TCP", RFC 8985, February 2021.
;[RFC 9000]
:J. Iyengar (ed.), M. Thomson (ed.), "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, May 2021.
;[RFC 9001]
:M. Thomson (ed.), S. Turner (ed.), "Using TLS to Secure QUIC", RFC 9001, May 2021.
;[RFC 9002]
:J. Iyengar (ed.), I. Swett (ed.), "QUIC Loss Detection and Congestion Control", RFC 9002, May 2021.
;[RFC 9147]
:E. Rescorla, H. Tschofenig, N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, April 2022.
;[RFC 9260]
:R. Stewart, M. Tuexen, K. Nielsen, "Stream Control Transmission Protocol", RFC 9260, June 2022. Obsoletes RFC 4960.
;[RFC 9293]
:W. Eddy (ed.), "Transmission Control Protocol (TCP)", STD 7, RFC 9293, August 2022. Obsoletes RFC 793 and several follow-ons; updates RFC 1122 and others.

=== 17.2. Books and journal papers ===

;[Day08]
:J. Day, "Patterns in Network Architecture: A Return to Fundamentals", Prentice Hall, 2008.
;[Grasa15]
:E. Grasa et al., "IRATI: investigating RINA as an alternative to TCP/IP", Computer Networks, Vol. 92, December 2015.
;[KP87]
:P. Karn, C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", ACM SIGCOMM, August 1987.
;[Wat81]
:R. W. Watson, "Timer-Based Mechanisms in Reliable Transport Protocol Connection Management", Computer Networks, Vol. 5, 1981.

=== 17.3. Source-code references ===

;[Linux-RTT]
:<code>tcp_rtt_estimator()</code> in <code>net/ipv4/tcp_input.c</code> of the Linux kernel, defining the asymmetric <code>mdev</code> variance update used as FRCP's default RTT estimator ([[#12. RTT estimation|Section 12]]). Line-stable browseable copy at https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_input.c.

[[Category:Protocols]]
[[Category:Ouroboros internals]]

Flow and Retransmission Control Protocol

2026-05-18T16:06:09Z

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

{{DISPLAYTITLE:FRCP - Flow and Retransmission Control Protocol}}

FRCP runs end-to-end between two peers over a flow. It delivers
reliability, in-order delivery, flow control, and liveness.
Congestion Control (CC) is not in FRCP - that lives in the IPC
Process (IPCP) Congestion Avoidance (CA) policies, orthogonal to
FRCP. Flow allocation, naming, and IPCP lifecycle are handled by
the IPC Resource Manager daemon (IRMd).

FRCT (Flow and Retransmission Control Task) is the libouroboros
implementation of FRCP; the task lives in <code>src/lib/frct.c</code>. The
remainder of this document describes the FRCP wire protocol and the
behaviour FRCT realises. Code symbols retain the <code>FRCT_</code> prefix
(<code>FRCT_DATA</code>, <code>FRCT_RXM</code>, ...) because they belong to the implementing
task; this document references them verbatim.

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in <code>BCP</code> 14 (Best
Current Practice; RFC 2119, RFC 8174) when, and only when, they
appear in all capitals.

== Notation ==

;<code>u32</code>, <code>u8</code>
:Unsigned 32-bit / 8-bit integers (kernel-C style).
;<code>ns</code>
:Nanoseconds.

Modular sequence-number comparators (32-bit, modulo 2^32):

;<code>before(a, b)</code>
:<code>(int32_t)(a - b) < 0</code>
;<code>after(a, b)</code>
:<code>before(b, a)</code>

Used throughout for <code>ackno</code> / <code>seqno</code> ordering checks.

Round-Trip Time (RTT) abbreviations used throughout:

;<code>SRTT</code>
:Smoothed RTT estimate (RFC 6298).
;<code>mdev</code>
:Mean deviation of RTT (Linux variance estimator).
;<code>EWMA</code>
:Exponentially Weighted Moving Average.
;<code>RTO</code>
:Retransmission Timeout, <code>max(RTO_MIN, srtt + (mdev << MDEV_MUL))</code>.

Timer-bound symbols <code>t_a</code> (a-timer, ACK delay) and <code>t_r</code> (r-timer,
retransmission window) are defined in [[#8. Retransmission|Section 8]]; <code>t_mpl</code> (Maximum
Packet Lifetime) is introduced in [[#2.1. Per-flow state|Section 2.1]] (the <code>inact</code> field)
with heritage in [[#15. Heritage and adopted techniques|Section 15]].

Wire-format diagrams follow the IETF convention: bit 0 is the
leftmost (most significant) bit and fields are in network byte
order unless stated otherwise.

__TOC__

== 1. Wire format ==

=== 1.1. PCI header ===

Fixed 16-octet base Protocol-Control Information (PCI) header
prefixed to every FRCP packet (RFC convention: bit 0 leftmost,
most-significant bit first). All multi-byte fields are in network byte order. DATA packets on
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
base PCI.

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | hcs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ackno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload (variable) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>flags</code>
:feature/type bitmap (see [[#1.2. Flag bits|Section 1.2]]).
;<code>hcs</code>
:CRC-16-CCITT-FALSE Header Check Sequence (HCS) over <code>flags</code> + <code>window</code> + <code>seqno</code> + <code>ackno</code> (+ stream extension when present); the two octets of the <code>hcs</code> field itself are omitted from the CRC input. Verified on receive before any flag-driven dispatch.
;<code>window</code>
:receiver-advertised right window edge (valid iff FC).
;<code>seqno</code>
:per-flow sequence number.
;<code>ackno</code>
:cumulative Acknowledgement (ACK) (valid iff ACK).

A single packet can simultaneously carry DATA + ACK + FC (Flow
Control) + RXM (Retransmission) by ORing flag bits; the PCI
multiplexes control on the same wire frame in the spirit of SCTP
chunk bundling (RFC 9260 sec. 6.10) and QUIC frame multiplexing
(RFC 9000 sec. 12.4). DATA-bearing packets carry the caller's
payload after the PCI; SACK (Selective Acknowledgement) and RTTP
(Round-Trip Time Probe) carry their own typed payloads after the
PCI.

Optional framing (per-flow, see [[#2.2. Service modes (orthogonal axes)|Section 2.2]]). On the wire, the
order from inside out is:

{| class="wikitable"
! Layer !! Scope
|-
| <code>[ PCI + body ]</code>
| The FRCP packet.
|-
| <code>[ PCI + body + CRC-32 ]</code>
| CRC-32 covers the body only (PCI is in HCS); appended iff <code>qs.ber == 0</code> on DATA, or on every SACK packet.
|-
| <code>[ AEAD-wrap of above ]</code>
| Iff Authenticated Encryption with Associated Data (AEAD) is enabled.
|}

* 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 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>).

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

=== 1.2. Flag bits ===

Flag bits are numbered most-significant-bit first to match the wire
diagram (bit numbering per [[#1.1. PCI header|Section 1.1]]; bit 0 is the MSB of the
16-bit <code>flags</code> field and lands at wire-position 0 in network byte
order). Bits 13..15 are reserved and MUST be transmitted as zero.

{| class="wikitable"
! Bit !! Mask !! Name !! Meaning
|-
| 0 || <code>0x8000</code> || <code>DATA</code> || Carries caller payload
|-
| 1 || <code>0x4000</code> || <code>DRF</code> || Data Run Flag: start of a fresh run
|-
| 2 || <code>0x2000</code> || <code>ACK</code> || Acknowledgement: <code>ackno</code> field valid
|-
| 3 || <code>0x1000</code> || <code>NACK</code> || Negative ACK; <code>seqno = arrival_seqno-1</code>
|-
| 4 || <code>0x0800</code> || <code>FC</code> || Flow Control: <code>window</code> field valid (<code>rwe</code>)
|-
| 5 || <code>0x0400</code> || <code>RDVS</code> || Rendezvous probe (window-closed)
|-
| 6 || <code>0x0200</code> || <code>FFGM</code> || First Fragment (role bit 0; see below)
|-
| 7 || <code>0x0100</code> || <code>LFGM</code> || Last Fragment (role bit 1; see below)
|-
| 8 || <code>0x0080</code> || <code>RXM</code> || Retransmission
|-
| 9 || <code>0x0040</code> || <code>SACK</code> || Selective ACK block list in payload
|-
| 10 || <code>0x0020</code> || <code>RTTP</code> || RTT Probe / echo (payload follows)
|-
| 11 || <code>0x0010</code> || <code>KA</code> || Keepalive
|-
| 12 || <code>0x0008</code> || <code>FIN</code> || End-of-stream marker (stream mode)
|-
| 13-15 || -- || -- || Reserved (MUST be zero)
|}

The (<code>FFGM</code>, <code>LFGM</code>) pair encodes the fragment role of a DATA-bearing
Service Data Unit (SDU), SCTP-style begin/end flags (RFC 9260
sec. 3.3.1):

{| class="wikitable"
! FFGM !! LFGM !! Role
|-
| 1 || 1 || Sole / un-fragmented SDU (begin AND end)
|-
| 1 || 0 || First fragment of a multi-fragment SDU
|-
| 0 || 0 || Middle fragment
|-
| 0 || 1 || Last fragment
|}

Each fragment is carried in its own FRCP packet with its own <code>seqno</code>;
FRTX (the FRCT Retransmission service mode, see [[#2.2. Service modes (orthogonal axes)|Section 2.2]])
recovers individual fragments via the normal Retransmission Timeout
(RTO) / SACK / Recent Acknowledgement (RACK, RFC 8985) path. The
receiver reassembles the SDU at consume time once the contiguous
[FIRST .. LAST] run has fully arrived. On non-DATA packets the role
bits are unused and MUST be transmitted as zero.

In stream mode (<code>qos.service == SVC_STREAM</code>, see [[#16. Stream-mode flows|Section 16]]) there are
no SDU boundaries to encode, so <code>FFGM</code> and <code>LFGM</code> are unused and MUST
be transmitted as zero. End-of-stream uses a dedicated bit (<code>FIN</code>,
bit 12) carried on a 0-byte DATA packet, emitted at write-half close
(<code>fccntl</code> to <code>FLOWFRDONLY</code>), during linger drain, and at <code>flow_dealloc</code>;
emission is idempotent (first call wins). After contiguous delivery
of the FIN-bearing slot, the receiver latches <code>byte_fin</code> at the FIN's
start offset; <code>flow_read</code> returns 0 (end-of-file, <code>EOF</code>) once buffered
bytes have been drained up to <code>byte_fin</code>. Per-byte position is
carried by the [start, end) extension ([[#1.5. Stream PCI extension|Section 1.5]]).

=== 1.3. SACK payload ===

A SACK packet has the <code>FRCT_ACK | FRCT_FC | FRCT_SACK</code> flag bits set
(bit numbering per [[#1.1. PCI header|Section 1.1]]). Following the 16-octet PCI, the
payload is a 2-octet block count (network byte order), 2 octets of
padding to 4-byte align the block list, then <code>n_blocks</code> pairs of
32-bit start/end seqnos describing ''present'' (received) ranges
above the cumulative ACK.

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_blocks | padding (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start[0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end[0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... n_blocks pairs total ...
</syntaxhighlight>

<code>n_blocks <= SACK_MAX_BLOCKS</code> (2048). The per-flow effective cap is
further bounded by <code>(frag_mtu - PCI - 4) / 8</code> blocks per packet; SACK
packets carry no stream extension, so PCI here is the 16-octet base
header even on stream-mode flows.

Wire invariant: every block produced by the receiver, except an
optional leading Duplicate SACK (D-SACK) block as described below,
describes a range strictly above the cumulative ACK carried in the
PCI <code>ackno</code> field (<code>after(start[i], ackno)</code>). This makes the D-SACK
convention below unambiguous; the receiver-side builder MUST
preserve it.

Duplicate SACK (D-SACK, RFC 2883) is signalled in-band: no flag
bit, no extra framing. Modular seqno arithmetic uses the
<code>before()</code> / <code>after()</code> comparators defined in the Notation block.

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)
:<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)
:<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.

The <code>reo_wnd_mult</code> halving cadence (once per 16 cumulatively-ACK'd
seqnos since the most-recent D-SACK arrival or halve event) and
the reset-to-1 on a HoL RTO fire are both per the same RFC 8985
clause. The clamp-and-skip path in the regular SACK-mark loop is
incidentally idempotent on any leftover case-1 or case-2 block
(<code>start < snd_cr.lwe</code> clamps to <code>snd_cr.lwe</code> and the inner loop
skips <code>k == snd_cr.lwe</code>; case-2 re-NULLs slots already marked
received by later blocks), so block[0] is harmless even when fed
to the loop.

=== 1.4. RTTP payload ===

An RTTP (Round-Trip Time Probe) packet has only the <code>FRCT_RTTP</code> flag
set (bit numbering per [[#1.1. PCI header|Section 1.1]]). Following the 16-octet PCI,
the payload is 24 octets (packed):

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| probe_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| echo_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ nonce (16 octets, echoed verbatim) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>probe_id</code>
:sender counter, 0 on reply, 0 reserved.
;<code>echo_id</code>
:peer's <code>probe_id</code>, 0 on outbound probe.
;<code>nonce</code>
:random, echoed unmodified, memcmp'd to defeat spoof.

=== 1.5. Stream PCI extension ===

A stream-mode flow (<code>qos.service == SVC_STREAM</code>) carries an extra
8-octet extension after the 16-octet base PCI on every DATA packet
(bit numbering per [[#1.1. PCI header|Section 1.1]]):

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>start</code>
:octet offset of the first payload byte in the stream.
;<code>end</code>
:octet offset one past the last payload byte; <code>end - start</code> equals the on-wire payload length.

Total stream-mode PCI for DATA packets is 24 octets (16 base + 8
extension); control packets (SACK, RTTP, bare ACK, KA, etc.) retain
the 16-octet base PCI. Stream mode MUST be negotiated at flow
allocation; the extension is present iff stream mode is in use,
never on a per-packet basis. Both peers MUST treat <code>start</code>/<code>end</code> as
monotonic 32-bit byte offsets; when a slot reaches the head of the
contiguous run with <code>start</code> not equal to the prior packet's <code>end</code> the
slot is silently dropped at delivery time ([[#16. Stream-mode flows|Section 16]]) rather
than rejected at stash.

This is the QUIC STREAM-frame reassembly model (RFC 9000 sec. 19.8):
each packet carries its packet <code>seqno</code> (this PCI's <code>seqno</code> field) and a
separate stream byte position (<code>start</code>/<code>end</code>). Separating the two
avoids TCP's conflation of packet identity with byte position which
forces Karn's algorithm for Round-Trip Time (RTT) sampling (no RTT
sample on retransmits, RFC 6298 sec. 3); FRCP applies the
Karn-equivalent gate via a combination of per-packet <code>FRCT_RXM</code>,
per-slot <code>SND_RTX</code> flags, and a sample-fence <code>rtt_lwe</code> (see [[#2.1. Per-flow state|Section 2.1]]
and [[#12. RTT estimation|Section 12]]). FRCP's fixed-32-bit <code>start</code>/<code>end</code> wrap at 4 GiB of
wire bytes, narrower than QUIC's 62-bit varint offset (cf. RFC 9000
sec. 16); the on-wire wrap is handled by the same modular <code>before()</code>
/ <code>after()</code> comparators ([[#1.3. SACK payload|Section 1.3]]) FRCP uses for seqnos, which
remain unambiguous as long as the in-flight byte window stays
strictly under 2 GiB (the half-range of the signed-int32 difference
in <code>before()</code>). The default per-flow ring is 1 MiB; the
implementation caps <code>ring_sz</code> at 128 MiB (<code>FRCT_STREAM_RING_SZ_MAX</code>),
well below the 2 GiB half-range bound. The runtime byte counters
exposed via FUSE (Filesystem in Userspace) in the Ouroboros
Resource Information Base (RIB, a virtual-filesystem introspection
bridge) are platform <code>size_t</code> and do not wrap on 64-bit hosts.

== 2. Per-flow state and service modes ==

=== 2.1. Per-flow state ===

Each flow keeps a sender control record and a receiver control
record:

;<code>lwe</code> : <code>u32</code>
:snd: oldest unacked <code>seqno</code> (cumulative ACK boundary as seen by sender); rcv: next in-order <code>seqno</code> expected
;<code>rwe</code> : <code>u32</code>
:snd: peer-advertised right window edge; rcv: locally-advertised right window edge
;<code>cflags</code> : <code>u8</code>
:per-direction feature flags: retransmission (<code>FRCTFRTX</code>), receiver flow control (<code>FRCTFRESCNTL</code>), linger-on-close (<code>FRCTFLINGER</code>); see <code><ouroboros/fccntl.h></code>
;<code>seqno</code> : <code>u32</code>
:snd: next <code>seqno</code> to send; rcv: force-ACK trigger - set on a stale or dup DATA so the next <code>ack_snd</code> emits a fresh cumulative ACK
;<code>ackno</code> : <code>u32</code>
:snd: <code>seqno</code> counter for standalone ACK-bearing control packets (delayed ACK, SACK, final ACK on dealloc); not bumped on piggybacked ACK riding a DATA packet (which uses the DATA <code>seqno</code>). Used by wire-dup ACK detection; rcv: incoming-ACK dedup tracker
;<code>act</code> : <code>ns</code>
:last activity (used by inactivity / DRF)
;<code>inact</code> : <code>ns</code>
:inactivity threshold; sender = <code>3*mpl + a + r + 1s</code>, receiver = <code>2*mpl + a + r + 1s</code>. <code>mpl</code> is the Maximum Packet Lifetime (delta-t terminology; see [[#15. Heritage and adopted techniques|Section 15]]); <code>a</code> and <code>r</code> are the FRCT a-timer and r-timer bounds (see [[#8. Retransmission|Section 8]]). The asymmetry is load-bearing for pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]).

The sender holds a per-slot ring <code>snd_slots[RQ_SIZE]</code> keyed by
<code>(seqno mod RQ_SIZE)</code>. Each slot tracks its retransmit entry (<code>rxm</code>),
last-send timestamp, and retransmit flag bits: <code>SND_RTX</code> (a
retransmit is pending or has fired, gates the next RTT sample
under Karn) and <code>SND_FAST_RXM</code> (one-shot fast-retransmit staged for
this loss event).

The receiver holds a parallel reorder ring <code>rcv_slots[RQ_SIZE]</code>
(referred to as <code>rq[]</code> in prose) holding stashed out-of-order
packet-buffer indexes; both FRTX and best-effort flows share this
path. The invariant <code>rwe - lwe <= RQ_SIZE</code> holds: on each consume
the receiver advances <code>rwe</code> by the consumed count, capping the
receive window at <code>RQ_SIZE</code> <code>seqno</code> slots.

A separate fence variable <code>rtt_lwe</code> is bumped on every retransmit
(timer-fire, SACK-driven, fast-rxm, NACK-driven) and on every
<code>seqno_rotate</code> ([[#4. Sequence-number rotation (DRF)|Section 4]]) to mark the <code>seqno</code> range whose RTT samples
MUST be discarded.

=== 2.2. Service modes (orthogonal axes) ===

FRCP exposes its wire features as a vector of independent QoS
axes selected at flow allocation time. All flows go through the
same <code>flow_alloc(name, qos, ...)</code> primitive; the <code>qosspec_t</code> passed
in determines which protocol machinery engages on the wire. This
contrasts with the POSIX BSD socket model where TCP and UDP
require different socket types (<code>SOCK_STREAM</code> / <code>SOCK_DGRAM</code>).

The axes:

;<code>service</code>
:0 = unordered (no FRCP engagement: raw datagrams, no PCI on the wire, UDP-equivalent at this layer); 1 = message-ordered (FRCP engaged; SDU boundaries preserved across fragmentation); 2 = stream (byte-oriented, no SDU boundaries; FRTX required)
;<code>loss</code>
:0 = lossless service requested: FRTX retransmit machinery engages ([[#8. Retransmission|Section 8]]); MUST be 0 for <code>service=2</code>. Non-zero = best-effort, FRTX off.
;<code>ber</code>
:Bit Error Rate tolerance. 0 = error-free service requested: a CRC trailer is appended after the body of DATA packets and verified on receive (added / checked outside the FRCP PCI; see [[#1.1. PCI header|Section 1.1]]). Non-zero = peer accepts errors; trailer omitted. SACK control packets carry a CRC32 trailer regardless of <code>ber</code>; the <code>ber</code> gate applies to DATA only.
;<code>timeout</code>
:Peer-timeout (ms); 0 disables the keepalive timer. Independent of FRCP engagement.

Encryption is a separate per-flow attribute set at flow setup;
when enabled it wraps the FRCP packet (PCI + body, plus the CRC
trailer if any) under AEAD, expanding the <code>spb</code> by <code>headsz</code> + <code>tailsz</code>
octets (nonce / tag). The CRC trailer is currently kept inside
the AEAD wrap (see [[#1.1. PCI header|Section 1.1]]).

Reachable combinations exported by <code>include/ouroboros/qos.h</code>:

{| class="wikitable"
! Cube !! <code>service</code> !! <code>loss</code> !! <code>ber</code> !! Engaged
|-
| <code>qos_raw</code> || 0 || 1 || 1 || Raw passthrough
|-
| <code>qos_raw_safe</code> || 0 || 1 || 0 || Raw + CRC trailer
|-
| <code>qos_rt</code> || 1 || 1 || 1 || FRCP, no FRTX, no CRC
|-
| <code>qos_rt_safe</code> || 1 || 1 || 0 || FRCP, no FRTX, CRC
|-
| <code>qos_msg</code> || 1 || 0 || 0 || FRCP + FRTX
|-
| <code>qos_stream</code> || 2 || 0 || 0 || FRCP + FRTX, stream
|}

Forced couplings actually enforced by the public API:

* <code>service == SVC_STREAM</code> (2) requires <code>loss == 0</code>; <code>flow_alloc</code> / <code>flow_accept</code> reject the pair otherwise with <code>-EINVAL</code>.
* FRTX requires FRCP engagement (<code>service != SVC_RAW</code>); requesting <code>loss = 0</code> with <code>service = SVC_RAW</code> is structurally a no-op because no <code>frcti</code> is created.
* The <code>QOS_DISABLE_CRC</code> build flag globally forces <code>ber = 1</code>. Note: this flag defaults to ON, so default builds ship with CRC disabled until <code>QOS_DISABLE_CRC</code> is set to OFF.

Caveat: the API does NOT force <code>ber = 0</code> when <code>service != SVC_RAW</code>.
<code>qos_rt</code> has <code>service = SVC_MESSAGE</code> with <code>ber = 1</code>, which means the PCI
itself is not CRC-protected on that cube; the HCS ([[#1.1. PCI header|Section 1.1]])
remains the only integrity check on the header.

The FRCP-no-FRTX regime (<code>service = SVC_MESSAGE</code>, <code>loss > 0</code>) is meaningful
and live: sequence numbering, in-order delivery, flow-control
advertisement, KA, DRF rotation, and SDU fragmentation /
reassembly ([[#7.2. Fragmentation and reassembly|Section 7.2]]) all run. Lost packets are dropped
rather than retransmitted; a permanently-lost mid-fragment is
dropped via skip-past-gap once a later SDU is visible in the
reorder ring.

== 3. Protocol parameters ==

{| class="wikitable"
! Parameter !! Value !! Role
|-
| <code>RQ_SIZE</code> || compile-time, power of 2 (default 128) || Slot ring / rcv window width
|-
| <code>START_WINDOW</code> || compile-time, power of 2 (default 128) || Initial <code>rwe-lwe</code> after rotate
|-
| <code>RTO_MIN</code> || <code>MAX(250 us build-tunable, 1<<RXMQ_RES)</code>; per-flow via <code>fccntl</code> (<code>FRCTSRTOMIN</code>). Default ~1 ms with <code>RXMQ_RES=20</code>. || RTO floor; also floored at the retransmit-wheel resolution (~1 ms by default).
|-
| <code>MAX_RTO_MUL</code> || 20 || Backoff shift cap
|-
| RACK window <code>R</code> || <code>MIN(reo_wnd_mult * min_RTT/4, SRTT)</code> with <code>MIN_REORDER_NS = 250 us</code> floor; <code>reo_wnd_mult</code> scales on D-SACK, cap 20 || Reorder window; per RFC 8985 sec. 6.2; <code>reo_wnd_mult</code> per sec. 6.2 step 4
|-
| <code>MIN_RTT_WIN_NS</code> || 300 s (5 min, Linux <code>tcp_min_rtt_wlen</code>) || <code>min_RTT</code> windowed re-anchor
|-
| <code>REO_WND_MULT_MAX</code> || 20 (RFC 8985 sec. 6.2 step 4) || <code>reo_wnd_mult</code> cap
|-
| <code>REO_DECAY_PKTS</code> || 16 (RFC 8985 sec. 6.2 step 4 / <code>RACK.reo_wnd_persist</code>) || Fresh-ACK'd seq count per halving
|-
| <code>MAX_DSACK_LAG</code> || <code>RQ_SIZE</code> || D-SACK sanity cap
|-
| <code>RTT_QUARANTINE</code> || 32 (<code>seqno</code> steps) || NewReno gate pad
|-
| SACK rate-limit || <code>SACK_MIN_GAP_NS</code> (250 us, fixed) || Min SACK gap
|-
| <code>SACK_MAX_BLOCKS</code> || 2048 (wire cap; per-flow capped at <code>(frag_mtu-PCI-4)/8</code>) || Per-SACK block cap
|-
| <code>SACK_RXM_MAX</code> || 32 || Per-pass staged retransmit cap
|-
| <code>DUP_THRESH</code> || 3 (RFC 8985 default) || Hybrid fast-rxm trigger ([[#8. Retransmission|Section 8]])
|-
| <code>MDEV_MUL</code> || 2 (build-tunable via <code>FRCT_RTO_MDEV_MULTIPLIER</code>) || <code>mdev</code> shift in <code>RTO = srtt + (mdev << MDEV_MUL)</code>
|-
| RTTP nonce || 16 octets || Echoed verbatim
|-
| <code>RTTP_RING</code> || 8 || In-flight probes
|-
| RTT clamp || <code>16 * srtt</code> || Probe-sample upper bound (ACK-derived RTT samples gated by Karn / recovery only)
|-
| Cold-probe cadence || 100 ms (rx-driven; see [[#12. RTT estimation|Section 12]]) || Pre-<code>srtt</code> RTTP rate
|-
| <code>DELT_RDV</code> || 100 ms || RDVS emit cadence
|-
| <code>MAX_RDV</code> || 1 s || RDVS give-up
|-
| Delayed-ACK fire || <code>2 * TICTIME</code> (<code>TICTIME</code> = FRCT tick granularity, default 5 ms; <code>2*TICTIME = 10 ms</code> by default) || Fired after the first in-order DATA arrival; tick is build-tunable
|-
| NACK send cooldown || <code>srtt</code> when an <code>srtt</code> sample exists, else 100 ms || Pre-DRF NACK rate-limit
|-
| <code>MAX_SDU</code> || 1 MiB || Max reassembled SDU; configurable per flow
|}

The per-flow fragment Maximum Transmission Unit (MTU) is computed
at flow setup from the lower IPCP's mtu minus encryption
<code>headsz</code> / <code>tailsz</code> and CRC trailer; there is no FRCT-level default or
environment-variable override.

== 4. Sequence-number rotation (DRF) ==

The DRF (Data Run Flag) bit on an outbound packet means "this is
the start of a fresh data run" and is set whenever the sender has
nothing in flight (<code>snd_cr.seqno == snd_cr.lwe</code>).

Independently of that, if the sender has been idle longer than
<code>snd_cr.inact</code> AND the pipe is empty (<code>snd_cr.seqno == snd_cr.lwe</code>),
<code>seqno_rotate()</code> rolls a random new <code>seqno</code> before the send and
resets

<syntaxhighlight lang="text">
snd_cr.seqno = random()
snd_cr.lwe = snd_cr.seqno
snd_cr.rwe = snd_cr.seqno + START_WINDOW
rtt_lwe = snd_cr.seqno
in_recovery = false (recovery state, see Section 8)
recovery_high = snd_cr.seqno
</syntaxhighlight>

The receiver, on observing rcv-side inactivity
(<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
below). Non-DATA control packets pass through without the DRF
requirement (no impact on receiver state). On DRF the receiver releases the <code>rq[]</code> slots and
rebases

<syntaxhighlight lang="text">
rcv_cr.lwe = seqno
rcv_cr.rwe = seqno + RQ_SIZE
rcv_cr.seqno = seqno
</syntaxhighlight>

If the inactive packet has DATA but no DRF, a rate-limited NACK is
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).

== 5. Send path ==

# If the SDU exceeds <code>(frag_mtu - data_hdr_len)</code>, the caller (<code>dev.c</code>) fans it out into <code>ceil(count / (frag_mtu - data_hdr_len))</code> fragments, each emitted via <code>frcti_snd</code> as its own DATA packet with a per-fragment role ([[#7.2. Fragmentation and reassembly|Section 7.2]]); both FRTX and best-effort flows fragment. Raw flows (no FRCP engagement, <code>qos.service == SVC_RAW</code>) carry no PCI and return <code>-EMSGSIZE</code> for any SDU larger than one packet at the layer below. An SDU that fits in a single packet is sent as SOLE. <code>frcti_snd</code> reserves PCI head room; sets DATA, plus DRF when the pipe is empty (<code>snd_cr.seqno == snd_cr.lwe</code>).
# <code>seqno_rotate()</code> if past sender inactivity and the pipe is empty ([[#4. Sequence-number rotation (DRF)|Section 4]]).
# Advertise FC (<code>pci.window = frcti_advert_rwe(frcti)</code>, i.e. <code>rcv_cr.rwe</code> clamped to <code>rcv_cr.lwe + ring_seq_cap</code> in stream mode) when the receiver side is recent: <code>now - rcv_cr.act < rcv_cr.inact</code>.
# Reliable mode (FRTX): leave <code>snd_cr.lwe</code> where it is; reset the slot at <code>RQ_SLOT(seqno)</code> (<code>snd_slots[p].time = now</code>, <code>snd_slots[p].flags = 0</code>); queue an <code>rxm_entry</code> (saves a packet copy, arms a wheel timer at <code>now + (rto << rto_mul)</code>). Piggyback ACK (<code>pci.ackno = rcv_cr.lwe</code>) while the a-timer for the most recent received DATA packet has not yet expired (<code>now - rcv_cr.act <= t_a</code>); on piggyback, set <code>rcv_cr.seqno = rcv_cr.lwe</code> so the next delayed-ACK fire is suppressed. See [[#8. Retransmission|Section 8]] for <code>t_a</code> / <code>t_r</code> semantics.
# Best-effort mode (no FRTX): advance <code>snd_cr.lwe</code> immediately (<code>snd_cr.lwe = snd_cr.lwe + 1</code>, <code>snd_cr.rwe = snd_cr.lwe + RQ_SIZE</code>); no retransmit state. No send-side RTT probe is armed in this mode (<code>rtt_probe_arm</code> requires an in-flight <code>seqno</code>, which best-effort never has); the rx-driven cold seeder in <code>frcti_rcv</code> is the only probe path.
# In reliable mode, optionally arm an RTT probe ([[#12. RTT estimation|Section 12]]).

== 6. Receive path ==

=== 6.1. Early-exit dispatch ===

Keepalive (KA), RTT probe (RTTP), pre-DRF NACK, and rendezvous
(RDVS) packets short-circuit out of <code>frcti_rcv</code> before the locked
main path; each handler takes its own lock internally.

<syntaxhighlight lang="text">
incoming packet
|
v
+---------+
| KA? |---yes--> ka_rcv ; return
+---------+
|no
v
+---------+
| RTTP? |---yes--> rttp_rcv; return
+---------+
|no
v
+---------+
| NACK? |---yes--> nack_rcv; return (see Section 9)
+---------+
|no
v
+---------+
| RDVS? |---yes--> rdv_rcv ; return (reply bare FC, ackno=0)
+---------+
|no
v
acquire wrlock; enter locked main path
</syntaxhighlight>

;<code>KA</code>
:refresh <code>t_ka_rcv</code>, honour piggybacked ACK.
;<code>RTTP</code>
:probe (echo back nonce) or echo (verify nonce, sample RTT).
;<code>NACK</code>
:pre-DRF, sender-side handler. See [[#9. Pre-DRF NACK|Section 9]].
;<code>RDVS</code>
:reply with a bare FC packet (<code>ackno = 0</code>); <code>rdlock</code> only.

=== 6.2. Locked main path ===

Steps below run with the per-flow <code>frcti.lock</code> held for writing
(<code>pthread_rwlock_wrlock</code>) unless noted.

;<code>rcv_inact_check</code>
:Only meaningful when the receive side is stale. On DRF (Data Run Flag): release <code>rq[]</code> slots, rebase <code>rcv_cr</code>, continue. On stale DATA without DRF: fire a pre-DRF NACK if cooldown allows ([[#9. Pre-DRF NACK|Section 9]]), then discard the packet; on cooldown, drop without sending a NACK (a pending cumulative ACK from <code>drop_packet</code> may still go out). Non-DATA, non-DRF arrivals bypass <code>rcv_inact_check</code> entirely; pure-DRF stale arrivals fall through after the DRF rebase branch.

;DATA-only act refresh
:Refresh <code>rcv_cr.act</code> only when <code>FRCT_DATA</code> is set, so that non-DATA packets never block the next DRF rebase.

;Wire-dup gate
:Before flag-driven dispatch, drop wire-duplicate ACKs and wire-duplicate DATA (<code>is_dup_ack</code> / <code>is_dup_data</code>). The DATA check is bypassed for <code>FRCT_RXM</code>-bearing arrivals so the piggybacked ACK / SACK / FC carried on a retransmitted DATA at an already-ACK'd <code>seqno</code> is still applied; the stale-in-window branch below then drops the packet.

;<code>ACK</code>
:Drop ACKs whose <code>ackno</code> falls outside <code>(snd_cr.lwe, snd_cr.seqno]</code>. If <code>ackno == snd_cr.lwe</code> (non-advancing cumulative ACK), drive RACK fast-retransmit consideration ([[#8. Retransmission|Section 8]]). Otherwise advance <code>snd_cr.lwe = ackno</code>, collapse <code>rto_mul</code> to 0 (Karn-gated by <code>SND_RTX</code> on the just-acknowledged slot, the old head-of-line), reset <code>dup_thresh</code> to 0, update <code>t_latest_ack</code> to the send-time of the slot at <code>ackno-1</code> (consumed by RACK and SACK below), decay <code>reo_wnd_mult</code> per RFC 8985 sec. 6.2 step 4, exit NewReno-careful recovery (see [[#8. Retransmission|Section 8]]) on <code>ackno >= recovery_high</code> or <code>ackno == snd_cr.seqno</code>, and feed an RTT sample if eligible ([[#12. RTT estimation|Section 12]]).

;<code>SACK</code>
:Walk the block list. For each block (a present range above <code>lwe</code>) NULL out <code>snd_slots[k].rxm</code>, clear the slot's per-send flags, and advance <code>t_latest_ack</code> to the latest send-time covered (the Forward Acknowledgement / fack equivalent, Mathis & Mahdavi 1996); the first block whose start clamps to <code>snd_cr.lwe</code> skips this fack update so that a head-of-line clamp does not falsely advance fack. For un-SACKed gaps below <code>hi_sacked</code>, stage a retransmit per slot that is (1) still owned (<code>rxm != NULL</code>), (2) not already <code>SND_FAST_RXM</code>, (3) not aged out past <code>t_r</code>, and (4) either outside the RACK reorder window <code>R</code> OR with <code>dup_thresh >= DUP_THRESH</code> (the RFC 8985 sec. 6.2 hybrid trigger). Mark the slot <code>SND_FAST_RXM</code> and NULL the <code>rxm</code> at stage time. Capped at <code>SACK_RXM_MAX</code> staged retransmits per receive pass; what's left rides the next SACK.

;<code>FC</code>
:Bump <code>snd_cr.rwe</code> (clamped to <code>lwe + RQ_SIZE</code>, never shrinks) and mark window open.

;<code>DATA</code>
:Bounds-check <code>seqno</code> against window. On stale-dup (<code>seqno < rcv_cr.lwe</code>), set <code>rcv_cr.seqno = seqno</code> to force a fresh ACK on the next <code>ack_snd</code>, then drop. On accept: both FRTX and best-effort stash the packet-buffer index into <code>rq[seqno mod RQ_SIZE]</code>. Fragments stash unchanged - the role bits are inspected only at consume time ([[#7.2. Fragmentation and reassembly|Section 7.2]]). On out-of-order arrival, build a SACK reply if not rate-limited (per [[#3. Protocol parameters|Section 3]]) and not deduplicated against the previous <code>(rcv_cr.lwe, n_blocks)</code> pair; D-SACK reports always bypass the dedup. If both rate-limit and dedup suppress the reply, neither SACK nor delayed-ACK fires (the sender picks up the gap on its next ACK). On in-order arrival, arm the delayed-ACK timer.

;<code>drop_packet</code> exit
:Releases the per-packet shared-memory buffer (<code>spb</code>), then calls <code>ack_snd</code> synchronously after the <code>spb</code> release to surface any pending cumulative ACK.

== 7. Read path and reassembly ==

=== 7.1. Read path ===

<code>flow_read</code> returns a full reassembled SDU (Service Data Unit) via
<code>frcti_consume</code> on every FRCP SDU-mode flow (FRTX or best-effort);
stream-mode is covered in [[#16. Stream-mode flows|Section 16]]. An incomplete head-of-line
(HoL) run yields <code>-EAGAIN</code>; an oversized run yields <code>-EMSGSIZE</code> (the
run is dropped so the flow does not stall). On best-effort flows,
a permanently-lost mid-fragment is dropped as soon as a later
complete SDU becomes visible in the ring ([[#7.2. Fragmentation and reassembly|Section 7.2]] skip-past-
gap).

Raw flows carry no <code>frcti</code>, so <code>flow_read</code> returns the next pending
packet-buffer index directly, with no role-bit inspection. (Raw
service is selected via <code>qos.service == SVC_RAW</code> at flow allocation,
which suppresses <code>frcti</code> creation.)

<code>frcti_pdu_ready</code> is the no-advance peek used by <code>fevent</code> (the
Ouroboros flow-event multiplexer, the <code>poll(2)</code>-equivalent on
flows). It returns ready only when the head-of-line run is
complete and the lead packet (a Protocol Data Unit, here one FRCP
packet) is present at <code>rcv_cr.rwe - RQ_SIZE</code>; any other state
(including the best-effort skip-past-gap case) returns not ready,
and <code>frcti_consume</code> is left to drop the broken prefix and re-
inspect.

=== 7.2. Fragmentation and reassembly ===

Send side (<code>flow_write_frag</code>). An SDU larger than
<code>(frag_mtu - PCI)</code> is split into <code>ceil(count / (frag_mtu - PCI))</code>
fragments; each fragment is its own FRCP packet with its own
<code>seqno</code> and a per-fragment role flag pair ([[#1.2. Flag bits|Section 1.2]]). Roles are
assigned at emit time:

{| class="wikitable"
! i !! Role
|-
| <code>n=1</code> || <code>SOLE</code>
|-
| <code>i=0</code> || <code>FIRST</code>
|-
| <code>i=n-1</code> || <code>LAST</code>
|-
| else || <code>MID</code>
|}

A mid-loop allocation or transmit failure may yield a partial
write: the call returns the bytes already enqueued (<code>off > 0</code>) or
the underlying error (<code>off == 0</code>). Best-effort flows fragment
identically; on the receiver, a partial run with a permanently-
lost fragment is dropped when a later complete SDU is visible in
the ring (see skip-past-gap below). Raw flows carry no PCI and
refuse anything larger than the layer's user MTU (<code>-EMSGSIZE</code>).

Wire-level recovery is fragment-agnostic on FRTX flows: each
fragment's <code>seqno</code> flows through SACK / RACK / RTO / NACK exactly
as for a SOLE DATA packet, and reassembly does not re-enter the
loss-detection path. Best-effort flows run the same <code>seqno</code>
machinery (DRF, FC, ACK piggyback, pre-DRF NACK emit) but queue
no <code>rxm</code> state at the sender, so a lost MID is unrecoverable;
skip-past-gap handles it (below).

Receive side. Fragments stash into <code>rq[seqno]</code> unchanged; role bits
are read only at consume time. <code>frag_run_inspect</code>, called from
<code>frcti_consume</code>, walks the ring starting at the oldest still-
undelivered <code>seqno</code> <code>base = rcv_cr.rwe - RQ_SIZE</code> (equal to <code>rcv_cr.lwe</code>
only when no partial run is in progress; during a partial run <code>lwe</code>
has already advanced past <code>base</code>). It produces one of three
outcomes:

{| class="wikitable"
! Outcome !! Cause
|-
| <code>DELIVER (n)</code>
| <code>rq[base]=SOLE</code> (<code>n=1</code>), or <code>rq[base]=FIRST</code> and a <code>LAST</code> follows in slots <code>[base+1..base+n-1]</code> with all intermediate roles in <code>{MID,FIRST,LAST}</code> contiguous.
|-
| <code>DROP (n)</code>
| <code>rq[base]</code> is <code>MID</code> or <code>LAST</code> without a preceding <code>FIRST</code> (<code>n=1</code>); a <code>FIRST..[non-LAST]..new-FIRST</code> or new-<code>SOLE</code> mid-run (drop the broken prefix with <code>n</code> = run length minus 1, so the new <code>FIRST</code>/<code>SOLE</code> stays); or, on best-effort flows, a gap at <code>base</code> with a <code>FIRST</code>/<code>SOLE</code> later in the ring (drop up to the new run start).
|-
| <code>NOT_READY</code>
| <code>rq[base]</code> absent or <code>FIRST..[non-LAST]</code> with no later <code>FIRST</code>/<code>SOLE</code> in the ring (FRTX waits for retx; best-effort waits for arrival).
|}

<code>DELIVER</code> triggers <code>frag_gather</code>: a scatter-gather <code>memcpy</code> of the <code>n</code>
consecutive fragments at <code>rq[base..base+n-1]</code> directly into the
caller's buffer; each per-packet shared-memory buffer (<code>spb</code>) is
released and <code>rwe</code> advances by <code>n</code>. <code>lwe</code> was already advanced
incrementally as each contiguous fragment arrived; <code>frag_gather</code>
only restores the fixed-width invariant <code>rwe == lwe + RQ_SIZE</code>.
No intermediate reassembly buffer is allocated.

<code>DROP</code> advances <code>rwe</code> past the broken prefix (releasing the <code>spb</code>s)
and pulls <code>lwe</code> up to the new trailing edge if needed; the next
consume retries from the new <code>base</code>. Oversize or arithmetically
overflowing delivery (sum of fragment lengths > <code>max_rcv_sdu</code>, sum
> caller's buffer, or running-sum overflow) also drops the run
with <code>-EMSGSIZE</code>.

Skip-past-gap (best-effort only). On FRTX, a gap in the run means
"waiting for retransmit" and <code>frag_run_inspect</code> returns <code>NOT_READY</code>.
On best-effort flows the gap is permanent, so <code>frag_run_inspect</code>
scans forward in the ring for the next <code>FIRST</code> or <code>SOLE</code>; if one is
visible within <code>RQ_SIZE</code>, it returns <code>DROP</code> for the broken prefix and
the consume loop retries at the new <code>lwe</code>. Memory hold is bounded
by <code>RQ_SIZE</code>; the partial releases on the next consume call once a
later complete run exists. Voice-like flows (one <code>SOLE</code> per SDU)
see no extra wait: any later <code>SOLE</code> makes the prior gap droppable
immediately.

The choice to defer reassembly to consume time keeps the receive
path zero-copy: fragments stay in the shared-memory ring until
the application pulls, and the SDU lands directly in the caller's
buffer.

== 8. Retransmission ==

FRCP is bounded by two delta-t-derived timers (Watson 1981, see
[[#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_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.

Each in-flight FRTX <code>seqno</code> owns one <code>rxm_entry</code>, armed in a hashed
timing wheel; the wheel deadline is the slot's next eligible
retransmit time.

;RTO timer
:On fire (<code>rxm_due</code>), re-emit with <code>FRCT_RXM</code>, mark <code>SND_RTX</code> (Karn-suppress next ACK's RTT sample), and (for the head-of-line (HoL) slot only) bump <code>rto_mul</code> up to <code>MAX_RTO_MUL</code>. Wheel deadline is <code>t_send + (rto << rto_mul)</code>. Re-armed unless consumed. The RTO timer also clears <code>SND_FAST_RXM</code> (re-arming fast-retransmit eligibility), resets <code>reo_wnd_mult</code> to 1 on a HoL fire (RFC 8985 sec. 6.2 step 4 reset clause), and marks the flow <code>ACL_FLOWDOWN</code> if its <code>frct_tx</code> call fails.

;r-timer guard
:Before any retransmit attempt, check <code>(now - t0)</code> against <code>t_r</code>. If exceeded, the slot is no longer eligible for retransmit. Only the RTO timer (<code>rxm_due</code>) treats r-timer expiry as terminal: it marks the flow <code>ACL_FLOWDOWN</code> (peer unreachable). Fast-retransmit, SACK-driven retransmit, and NACK-driven head-of-line re-emit silently skip aged-out slots and defer the flow-down decision to the next RTO fire.

;Fast retransmit (hybrid trigger, RFC 8985 sec. 6.2)
:On a non-advancing cumulative ACK with the scoreboard advanced, fire one fast retransmit when EITHER (a) the head-of-line slot's latest send is older than the RACK reorder window <code>R</code> ([[#3. Protocol parameters|Section 3]]) and not yet aged out, OR (b) the SACK <code>dup-thresh</code> count above <code>snd_cr.lwe</code> reaches <code>DUP_THRESH</code> (= 3, RFC 8985 sec. 6.2 step 4). Fires at most once per non-advancing cumulative-ACK value, gated by <code>rack_fired_lwe</code> (the <code>snd_cr.lwe</code> at which fast-retransmit last fired). Set <code>SND_FAST_RXM</code> on the slot (one-shot per-slot gate) and enter NewReno-style careful recovery (see NewReno below in this section).
:The RACK reorder window <code>R</code> uses the RFC 8985 sec. 6.2 form <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> with a <code>MIN_REORDER_NS = 250 us</code> floor. Before the first RTT sample seeds <code>min_rtt</code>, <code>R</code> falls back to <code>MIN(reo_wnd_mult * SRTT / 4, SRTT)</code>, still floored at <code>MIN_REORDER_NS</code> (consistent with the windowed-minimum fallback described in [[#12. RTT estimation|Section 12]]). <code>min_rtt</code> is a windowed minimum over the last <code>MIN_RTT_WIN_NS</code> = 5 min of RTT samples (matches the Linux <code>tcp_min_rtt_wlen</code> default) so a route change to a longer path eventually re-anchors the reorder window without relying on <code>reo_wnd_mult</code> growth alone.

;SACK-driven retransmit
:For each gap below <code>hi_sacked</code> whose slot is (1) still owned, (2) not already <code>SND_FAST_RXM</code>, (3) not aged out past <code>t_r</code>, and (4) either outside the RACK window <code>R</code> OR with <code>dup_thresh >= DUP_THRESH</code> (same hybrid as fast-retransmit, see [[#6.2. Locked main path|Section 6.2]]), re-emit. Each SACK-driven retransmit re-arms a fresh <code>rxm</code> so a lost retransmit can still be recovered by its own RTO timer.

;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.

== 9. Pre-DRF NACK ==

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.

;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>)
:When an incoming DATA packet has no DRF and rcv-side activity is older than <code>rcv_cr.inact</code>, the receiver emits a bare packet with <code>flags = FRCT_NACK</code> and <code>seqno = arrival_seqno - 1</code> (informational only, not consulted by the receive handler). The cooldown in [[#3. Protocol parameters|Section 3]] rate-limits the burst. Non-DATA non-DRF arrivals bypass <code>rcv_inact_check</code> entirely; non-DATA DRF still rebases via the DRF branch.

;Receive (<code>frcti_nack_rcv</code>)
: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 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.

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 ==

Cumulative ACK is <code>ackno = rcv_cr.lwe</code>. On out-of-order arrival the
receiver also emits a SACK packet ([[#1.3. SACK payload|Section 1.3]]) whose payload lists
''present'' blocks above <code>lwe</code> (analogous to TCP SACK / QUIC ACK
ranges). SACKs are rate-limited per [[#3. Protocol parameters|Section 3]] and suppressed when
neither <code>lwe</code> nor block count has changed since the last SACK.

D-SACK reports (RFC 2883) are emitted in-band as <code>block[0]</code> of an
otherwise normal SACK frame (see [[#1.3. SACK payload|Section 1.3]] for the encoding).
Two receiver triggers arm a pending D-SACK report (single-slot,
latest-wins):

* DATA arrival with <code>seqno < rcv_cr.lwe</code>, both wire-dup (no RXM, <code>is_dup_data</code> path) and retransmit (RXM, post-FC branch) (RFC 2883 sec. 4.1.1, full duplicate)
* <code>rq_accept</code> conflict, slot already occupied in <code>[lwe, rwe)</code> (RFC 2883 sec. 4.1.2, partial duplicate)

When a D-SACK is pending and the standard scoreboard SACK would be
suppressed by dedup or rate-limit, the report is emitted as a
stand-alone SACK frame through the normal <code>ack_snd</code> path; when a
D-SACK report is pending the path bypasses dedup and the <code>TICTIME</code>
rate-limit, but the a-timer suppression on rcv inactivity still
applies.

Bare ACKs are deferred via a per-flow delayed-ACK timer (one in
flight at a time, atomic test-and-set dedup; fires per [[#3. Protocol parameters|Section 3]]
after the first in-order arrival). Suppressed if (1) no new
<code>seqno</code>, (2) rcv side is inactive (older than <code>t_a</code>), or (3) the
sender just sent within <code>TICTIME</code>. A pending D-SACK ride-through
bypasses (1) and (3); the a-timer gate (2) is unconditional.

== 11. Flow control ==

The receiver advertises <code>rwe</code> in every FC field. The sender treats
its <code>snd_cr.rwe</code> as the absolute right edge: when
<code>snd_cr.seqno >= snd_cr.rwe</code> the window is closed and <code>flow_write</code>
yields. While closed, the sender periodically emits RDVS
(rendezvous) packets (cadence <code>DELT_RDV</code>); the receiver replies with
a bare FC packet (<code>ackno = 0</code>) that reopens the window. Once the
window has been closed for longer than <code>MAX_RDV</code> the sender stops
emitting RDVS but does not tear the flow down - the writer keeps
blocking until either a peer-driven FC arrives or the KA
(keepalive) / r-timer marks the flow.

<code>rwe</code> is clamped to <code>lwe + RQ_SIZE</code> on receipt and MUST NOT shrink:
a backward <code>rwe</code> is silently clamped to the current <code>snd_cr.rwe</code>;
the FC packet still reopens the window.

== 12. RTT estimation ==

Active RTTP probes ([[#1.4. RTTP payload|Section 1.4]]) carry a 32-bit <code>probe_id</code> (0
reserved) and a 16-byte random nonce echoed verbatim - defends
against spoofed replies. A ring of <code>RTTP_RING</code> in-flight probes is
kept; an echo whose <code>(id, nonce)</code> doesn't match the ring slot is
dropped. A single RTTP sample is clamped to <code>RTT_CLAMP_MUL * srtt</code>
(compile-time <code>RTT_CLAMP_MUL = 16</code>) once <code>srtt</code> is seeded; the first
cold-probe sample feeds <code>rtt_update</code> raw.

Probe arming gates:

;Cold (no <code>srtt</code> yet)
:the receive path arms at most one probe per 100 ms via <code>frcti_rcv_probe</code> (<code>PROBE_DUE_COLD</code>); arming requires an incoming packet. Active send-path arming bails while <code>srtt == 0</code>.
;Warm (<code>rtt_probe_arm</code>, called from <code>frcti_snd</code>)
:outstanding data (<code>snd_cr.seqno > snd_cr.lwe</code>), AND at least <code>2 * srtt</code> since <code>t_rcv_rtt</code> (last RTT receive of any kind), AND at least <code>srtt</code> since <code>t_snd_probe</code> (last probe emit).

Sample feeds either Linux's asymmetric <code>mdev</code> estimator
(<code>FRCT_LINUX_RTT_ESTIMATOR</code>, default ON) or RFC 6298 symmetric EWMA
(compile option). <code>srtt</code> is floored at 10 ms when seeded from a
hint, at 1 us after every update (including the first seeding
sample); <code>mdev</code> floored at 100 ns.

:<code>RTO = max(rto_min, 2 * srtt, srtt + (mdev << MDEV_MUL))</code>

(the <code>2 * srtt</code> floor is an FRCT addition not in RFC 6298).
Effective wheel deadline capped per [[#3. Protocol parameters|Section 3]].

ACK-derived samples (<code>frcti_ack_rcv</code> -> <code>rtt_sample_eligible</code>), beyond
the cum-ACK advance gate in <code>frcti_ack_rcv</code> (<code>ackno > lwe</code> and
<code>ackno <= seqno</code>), require all of: not in recovery; ACK packet does
not carry <code>FRCT_RXM</code>; HoL slot's <code>SND_RTX</code> bit clear; slot's <code>rxm</code>
pointer non-NULL (not SACK-consumed); <code>lwe</code> not below the <code>rtt_lwe</code>
fence; <code>srtt</code> already seeded by an RTTP probe. There is no ACK-only
seeding.

Every eligible sample also feeds <code>RACK.min_RTT</code> (RFC 8985 sec. 6.2)
via a windowed minimum: replace whenever the sample is strictly
smaller OR more than <code>MIN_RTT_WIN_NS</code> (5 min, matches Linux
<code>tcp_min_rtt_wlen</code>) has elapsed since the current min was set. The
downward branch is immediate (faster path picked up at once); the
upward branch is gated on the window (a transient queue burst does
not poison the estimate, but a sustained route change to a longer
path re-anchors <code>min_RTT</code> after at most one window). Seeded from
<code>rtt_hint</code> at <code>rtt_init</code>; 0 acts as the unset sentinel and the base
in <code>rack_reorder_window</code> falls back from <code>min_RTT</code> to <code>SRTT</code> (so
<code>R = mult * SRTT/4</code>, capped at <code>SRTT</code>, floored at <code>MIN_REORDER_NS</code>)
until the first sample. See [[#6.2. Locked main path|Section 6.2]].

== 13. Liveness (keepalive) ==

When <code>qs.timeout > 0</code> a per-flow KA (keepalive) timer is armed.
Arming uses <code>rcv_cr.act</code> for the deadline computation:

:<code>deadline = min(snd_act + qs.timeout/4, rcv_act + qs.timeout)</code>

(clamped to <code>now + qs.timeout/4</code> if already past). The timer fires
either on sender idleness (to send a KA) or on receiver idleness
(to declare the peer dead). On fire (<code>ka_snd</code>) the peer-dead test
uses <code>max(rcv_cr.act, t_ka_rcv)</code> so a recent KA reply counts even
when no DATA has arrived:

* If <code>now - max(rcv_cr.act, t_ka_rcv) > qs.timeout</code>, mark the flow <code>ACL_FLOWPEER</code> and notify the per-process flow-event set (<code>proc.fqset</code>) with <code>FLOW_PEER</code>.
* Else if <code>snd_idle > qs.timeout/4</code>, emit a bare <code>KA | ACK</code> (<code>ackno = rcv_cr.lwe</code>) and re-arm.
* Else just re-arm.

Note: <code>rx_rb</code> and <code>tx_rb</code> are the receive and transmit shared-memory
ring buffers. The r-timer raises <code>ACL_FLOWDOWN</code> on both (route is
broken); keepalive raises <code>ACL_FLOWPEER</code> on <code>rx_rb</code> only and notifies
the flow-event set (peer is silent, writer keeps <code>tx_rb</code> usable) -
distinct ACLs. <code>qs.timeout == 0</code> disables keepalive entirely; a
silent peer crash is then undetected.

== 14. Linger / teardown ==

On <code>flow_dealloc</code>, <code>frcti_dealloc</code> computes a grace timeout

:<code>max(rcv_cr.act + rcv_cr.inact, snd_cr.act + snd_cr.inact) - now</code>

(floored at 0 and converted to seconds) and returns it; <code>flow_dealloc</code>
forwards this to the IRMd as the dealloc grace. The IRMd, not FRCT,
performs the wait. Before computing the timeout, FRCT may emit a
final ACK when <code>rcv_cr.lwe != rcv_cr.seqno</code> (the peer has not been
told the most recent cumulative ACK) AND the rcv side has been
active within <code>t_a</code> (a-timer not aged out).

<code>FRCTFLINGER</code> is honoured only when <code>snd_cr.lwe < edge</code>, where <code>edge =
snd_fin_seqno</code> after FIN has been sent in stream mode and
<code>snd_cr.seqno</code> otherwise (data or FIN still in flight). The drain
itself runs in <code>flow_dealloc</code>'s <code>while (FRCTI_LINGERING)</code> loop, not in
<code>frcti_dealloc</code>.

The fd is single-reader / single-writer (documented in the
manpages). <code>flow_write</code> pumps <code>rx_rb</code> on every call (via
<code>flow_wait_window</code> -> <code>flow_drain_rx_nb</code>) and additionally blocks on
<code>rx_rb</code> when the send window is closed. A pure-writer thread thus
consumes ACKs without a dedicated reader.

== 15. Heritage and adopted techniques ==

Delta-t (Watson, 1981) is the primary heritage; FRCP descends from
the delta-t protocol family via the Recursive InterNetwork
Architecture (RINA; Day, "Patterns in Network Architecture", 2008,
ch. 9). Timer-based connection management
(no SYN/FIN handshake, per-flow state born on first DATA and
reclaimed after <code>t_mpl + a + r</code> of silence), the DRF marker, and the
<code>t_mpl</code> / <code>t_a</code> / <code>t_r</code> timers all come from delta-t. See Watson,
"Timer-Based Mechanisms in Reliable Transport Protocol Connection
Management", Computer Networks 5 (1981).

The unified <code>flow_alloc(name, qos, ...)</code> primitive and its
multi-axis QoS-cube argument ([[#2.2. Service modes (orthogonal axes)|Section 2.2]]) also come from RINA
(Day 2008, ch. 6; Grasa et al., "IRATI: investigating RINA as an
alternative to TCP/IP", Computer Networks 92 (2015)) - reliability,
ordering, CRC presence, and encryption are flow attributes, not
separate sockets or protocols.

The table below summarises additional adopted techniques and their
references.

{| class="wikitable"
! FRCP mechanism !! Heritage !! Reference / note
|-
| Random new <code>seqno</code> on <code>seqno_rotate</code> || TCP ISN || RFC 6528 (Gont & Bellovin, 2012). QUIC PN-space reset (RFC 9000 sec. 12.3) is a structural analogue.
|-
| Cumulative ACK, left-window-edge advance || TCP || RFC 793 / RFC 9293
|-
| Receive window with non-shrink rule || TCP || RFC 793 sec. 3.7 / RFC 9293 sec. 3.8.6; RFC 1122 sec. 4.2.2.16 for the explicit non-shrink prohibition
|-
| Modular <code>seqno</code> arithmetic (<code>before</code>/<code>after</code> helpers) || TCP || RFC 793 sec. 3.3 / RFC 9293 sec. 3.4
|-
| Selective ACK block list || TCP || RFC 2018 (Mathis et al., 1996). Encoded as a typed FRCP packet rather than a TCP option, so framing is closer to QUIC ACK frames. D-SACK (RFC 2883) carried in-band as <code>block[0]</code>; see [[#1.3. SACK payload|Section 1.3]].
|-
| NewReno-careful recovery with <code>recovery_high</code> gate || TCP || RFC 6582 (Henderson et al., 2012); QUIC builds on the same model in RFC 9002 sec. 7.3.2. Cwnd half absent (CC in IPCP).
|-
| RACK reordering window for fast retransmit || TCP || RFC 8985 (Cheng et al., 2021). FRCP <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> with a <code>MIN_REORDER_NS = 250 us</code> floor against <code>srtt</code> collapse; matches RFC 8985 sec. 6.2 and Linux <code>tcp_rack_reo_wnd</code>. DSACK-driven <code>reo_wnd_mult</code> (sec. 6.2 step 4) is adopted; see [[#1.3. SACK payload|Section 1.3]] for the wire encoding. The hybrid RACK-or-<code>DUP_THRESH</code> trigger from RFC 8985 sec. 6.2 step 4 is adopted ([[#8. Retransmission|Section 8]]). QUIC's analogue in RFC 9002 sec. 6.1.2 uses <code>max(srtt, latest_rtt)</code> as the base.
|-
| 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> = 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.
|-
| Delayed ACK with rate suppression || TCP || RFC 813 (Clark, 1982); RFC 1122 sec. 4.2.3.2; RFC 5681 sec. 4.2. Single-deadline coalescing rather than "ack-every-other-segment".
|-
| Zero-window-probe / persist-timer analogue (RDVS) || TCP || RFC 1122 sec. 4.2.2.17 / RFC 9293 sec. 3.8.6.1. RDVS solicits an FC reply, distinct from QUIC <code>DATA_BLOCKED</code> (RFC 9000 sec. 19.12), which is one-way notification. <code>MAX_RDV</code> give-up departs from TCP.
|-
| Multiplexed control on a single PCI || SCTP / QUIC || SCTP chunk bundling (RFC 9260 sec. 6.10); QUIC frame multiplexing (RFC 9000 sec. 12.4). Cleaner fit than TCP's separate-flag-bits design.
|-
| ACK ranges as multiple discontiguous acked blocks || QUIC || QUIC ACK frame (RFC 9000 sec. 19.3). FRCP SACK is conceptually QUIC-frame-shaped even though encoded as absolute <code>[start,end]</code> pairs.
|-
| Nonce-authenticated active RTT / liveness probing (RTTP) || QUIC <code>PATH_CHALLENGE</code> || <code>PATH_CHALLENGE</code> / <code>PATH_RESPONSE</code> (RFC 9000 sec. 8.2, sec. 19.17, sec. 19.18). WebRTC ICE consent-freshness (RFC 7675) is the same pattern. QUIC's nonce is 8 octets; FRCP chooses 16.
|-
| Probing distinct from keepalive || QUIC || KA timer answers "peer alive?", RTTP answers "path measurable?", as in QUIC PING (RFC 9000 sec. 19.2) vs <code>PATH_CHALLENGE</code>.
|-
| Bare KA + ACK keepalive packets || QUIC / SCTP || QUIC PING (RFC 9000 sec. 19.2); SCTP HEARTBEAT / HEARTBEAT-ACK (RFC 9260 sec. 8.3). SCTP HEARTBEAT also carries an opaque echoed blob, structurally similar to FRCP RTTP.
|-
| (<code>FFGM</code>, <code>LFGM</code>) fragment-role bits ([[#7.2. Fragmentation and reassembly|Section 7.2]]) || SCTP || RFC 9260 sec. 3.3.1 DATA chunk B/E bits encode the same four states (<code>B+E=SOLE</code>, <code>B-only=FIRST</code>, neither=<code>MID</code>, <code>E-only=LAST</code>). Each fragment carries its own <code>seqno</code>/TSN and is independently retransmitted.
|-
| Stream byte-offset reassembly (Sections [[#1.5. Stream PCI extension|1.5]], [[#16. Stream-mode flows|16]]) || QUIC || QUIC STREAM frame (RFC 9000 sec. 19.8) uses Offset + Length varints; FRCP uses fixed 32-bit <code>start</code> / <code>end</code>. One stream per flow vs QUIC's many streams multiplexed.
|-
| FIN end-of-stream marker (Sections [[#1.2. Flag bits|1.2]], [[#16. Stream-mode flows|16]]) || TCP / QUIC || TCP FIN flag (RFC 9293 sec. 3.1) closes one half of the byte stream; QUIC STREAM frame FIN bit (RFC 9000 sec. 19.8) does the same per stream with an immutable final-size invariance (RFC 9000 sec. 4.5: the final size is fixed once observed). FRCP's FIN consumes one packet <code>seqno</code> (not one byte of stream space) and is idempotent on the sender side.
|-
| Stream byte-credit flow control ([[#16. Stream-mode flows|Section 16]]) || QUIC || <code>MAX_STREAM_DATA</code> (RFC 9000 sec. 4.1, sec. 19.10). FRCP projects a per-flow byte budget onto the <code>seqno</code>-space <code>rwe</code>. Single stream per flow collapses QUIC's <code>MAX_DATA</code> / <code>MAX_STREAM_DATA</code> distinction.
|-
| Header protection (encrypted seqnos) || QUIC || QUIC RFC 9001 sec. 5.4 applies header protection on top of AEAD to mask the packet number. FRCP's per-flow AEAD wrap ([[#16. Stream-mode flows|Section 16]]) is wider: it encrypts the entire PCI including <code>seqno</code> because the IPCP below already routes, so no destination connection-ID needs to stay in clear (cf. RFC 9000 sec. 5.2).
|-
| Two-bit fragment role polarity || SCTP || The (<code>FFGM</code>, <code>LFGM</code>) pair follows SCTP B/E (begin = 1 / end = 1) rather than IPv4 MF (RFC 791 sec. 3.2), which has the inverse polarity (MF = 1 means NOT last).
|-
| Orthogonal reliability / ordering axes ([[#2.2. Service modes (orthogonal axes)|Section 2.2]]) || SCTP || PR-SCTP (RFC 3758, per-message partial reliability) and SCTP DATA U-bit (RFC 9260 sec. 3.3.1, per-message unordered) are the closest precedents for decoupling reliability from ordering; FRCP sets them per-flow rather than per-message.
|-
| Orthogonal CRC (<code>qs.ber == 0</code>) || UDP-Lite || RFC 3828 (Larzon et al., 2004) lets the sender pick a per-packet Checksum Coverage and the receiver enforce a locally configured minimum (no in-band negotiation; sec. 3.1, sec. 3.3). FRCP gates a full CRC trailer on <code>qs.ber == 0</code> at flow setup. Contrast TCP / SCTP (mandatory checksum) and QUIC (AEAD subsumes CRC).
|-
| Setup-time service negotiation || DCCP / SCTP / QUIC || DCCP Service Codes (RFC 4340 sec. 8.1.2, RFC 5595); SCTP INIT parameters (RFC 9260 sec. 3.3.2); QUIC transport parameters (RFC 9000 sec. 7.4). All negotiate service properties at connection setup; only RINA's QoS cube exposes them as an orthogonal vector.
|}

=== 15.1. Original to FRCP (no clean prior art) ===

* Pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]): receiver-driven nudge exploiting <code>snd_cr.inact > rcv_cr.inact</code>. Closest analogues are SCTP Gap Ack Blocks (RFC 9260 sec. 3.3.4) and DCCP Ack Vector (RFC 4340 sec. 11.4) - both let the receiver describe gaps to the sender, but neither targets the cross-epoch / pre-DRF case.
* <code>MAX_RDV</code> window-probe give-up: neither TCP (persist-timer probes until application or R2 abort, RFC 9293 sec. 3.8.6.1) nor QUIC has an explicit FC-give-up counter. A recursive-network choice: outer layers can drop the flow.
* Skip-past-gap reassembly ([[#7.2. Fragmentation and reassembly|Section 7.2]]): SCTP fragments and reassembles every flow regardless of reliability/ordering, using its own per-stream reassembly queue; QUIC fragments via STREAM offsets. FRCP fragments best-effort flows too, but the receiver drops the broken prefix the moment a later run-start (<code>FIRST</code> or <code>SOLE</code> role) is visible inside the <code>RQ_SIZE</code>-wide reorder ring - no IP-frag-style timeout, no SCTP-style explicit abort. If no later run-start arrives within the ring, <code>frag_run_inspect</code> returns <code>NOT_READY</code> and the partial run keeps its slots; the next inspect retries. The trade-off: a permanently-lost <code>MID</code> in a long isolated run holds slots until either a later <code>FIRST</code>/<code>SOLE</code> appears in the ring or the writer stops, at which point the slots are reclaimed on flow teardown.
* Reassembly deferred to consume time ([[#7.2. Fragmentation and reassembly|Section 7.2]]), message mode only (<code>qos.service == SVC_MESSAGE</code>): SCTP (RFC 9260 sec. 6.9), QUIC (RFC 9000 sec. 2.2), and TCP (RFC 9293) all hold reassembly state at the receive boundary. FRCP message-mode leaves fragments in the shared-memory ring until <code>flow_read</code> pulls and lands the SDU directly in the caller's buffer. Stream mode ([[#16. Stream-mode flows|Section 16]]) uses the standard QUIC-style direct ring placement on receive and does not defer. The optimisation is enabled by the Shared-Memory Subsystem (SSM) packet-buffer ring (see <code>struct ssm_pk_buff</code> at [[#1.1. PCI header|Section 1.1]]); the analogue is OS-level scatter-gather I/O (<code>recvmsg+iovec</code>), not a transport-layer prior art.
* TLP-equivalent tail-loss recovery (RFC 8985 sec. 7; RFC 9002 sec. 6.2): FRCP does not emit an explicit Tail Loss Probe packet, but the same goal is met implicitly by RACK loss detection ([[#8. Retransmission|Section 8]]) firing on a non-advancing cumulative ACK once the head-of-line slot ages past the RACK reorder window <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> - well below <code>RTO = max(2 * SRTT, SRTT + (mdev << MDEV_MUL))</code>. A receiver-driven nudge is also available via the pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]).

=== 15.2. Not adopted ===

* Slow start, congestion window (cwnd), Additive Increase / Multiplicative Decrease (AIMD), NewReno cwnd inflation. Congestion control lives in the IPCP CA policies and is driven by Explicit Congestion Notification (ECN, RFC 3168).
* Nagle / silly-window-syndrome (SWS) avoidance (RFC 896, RFC 1122 sec. 4.2.3.4). (Deferred work, not adopted in the current spec.)
* TCP Timestamps (RFC 7323) / Protection Against Wrapped Sequences (PAWS) - RTT measurement uses RTTP, not per-segment timestamps. A peer-supplied timestamp echoed on every ACK lets a malicious peer drive the <code>srtt</code> estimate arbitrarily low, collapsing the RTO and triggering a self-inflicted retransmit storm. RTTP confines RTT measurement to nonce-authenticated probe round-trips, where a forged echo is rejected before it can reach the estimator.
* ECN (Explicit Congestion Notification) response inside FRCP (consumed by IPCP Congestion Avoidance / CA).
* 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).

== 16. Stream-mode flows ==

When a flow is allocated with <code>qos.service == SVC_STREAM</code> both peers
switch to byte-stream semantics, layered on top of the FRTX reorder
machinery already described in Sections [[#6. Receive path|6]]-[[#8. Retransmission|8]].

=== 16.1. Send ===

The sender splits the caller's octets into chunks of at most
<code>(frag_mtu - base PCI - stream PCI extension)</code> octets (Sections [[#1.1. PCI header|1.1]]
and [[#1.5. Stream PCI extension|1.5]]). Each chunk is one DATA packet with its own <code>seqno</code> and a
<code>[start, end)</code> byte range copied from a monotonic stream counter.
In stream mode <code>FFGM</code> and <code>LFGM</code> are unused and MUST be transmitted as
zero; the per-byte position is carried by the <code>[start, end)</code>
extension instead.

End-of-stream is signalled with a 0-byte DATA packet that has <code>FIN</code>
(bit 12) set, emitted on the FIN triggers listed in [[#1.2. Flag bits|Section 1.2]]
(WR-half close, <code>flow_dealloc</code>, and any other path that yields the
final byte). The sender MUST emit at most one FIN per flow; its
<code>[start, end)</code> MUST equal <code>[final-byte, final-byte)</code> (i.e., empty
interval at the final byte position; final-size invariance,
analogous to QUIC RFC 9000 sec. 4.5). Idempotency is enforced by
an <code>snd_fin_sent</code> guard.

=== 16.2. Receive ===

On arrival the receiver places the payload directly into a per-flow
byte-indexed receive ring of width <code>ring_sz</code> (octets) at the position
indicated by <code>start</code>, with a two-segment <code>memcpy</code> across the ring
boundary if needed. Receipt is recorded in the FRTX reorder
machinery ([[#6.2. Locked main path|Section 6.2]]) augmented with the packet's <code>start</code>, <code>end</code>, and
FIN bit per slot. When a packet's <code>[start, end)</code> front-overlaps
bytes already at or below the byte high-water mark, the overlap is
trimmed before placement so the same byte is never written twice.
After stashing, the receiver advances <code>lwe</code> and the byte high-water
mark across any newly-contiguous prefix. Each slot advanced MUST
satisfy <code>start == the last-delivered slot's end</code>; a slot whose
<code>start</code> does not equal that <code>end</code> is silently dropped at delivery time
(the <code>seqno</code> is consumed, no stream bytes contributed) and the high-
water mark does not advance past it. The stream byte-stream
stalls at that point - there is no flow-tear-down on mismatch.
This filters spliced or off-path-injected slots that fall in
window without strong cryptographic authentication.

A FIN slot marks end-of-stream at advance time only if its byte
position equals the last-delivered slot's <code>end</code>; otherwise the FIN
is ignored and the corresponding <code>seqno</code> occupies a slot but
contributes no stream bytes. No packet buffer is held after the
ring copy.

=== 16.3. Read ===

<code>flow_read</code> returns up to <code>count</code> octets from the contiguous prefix
<code>[next, high-water)</code>, where <code>next</code> is the byte the application has
already consumed up to and <code>high-water</code> is the rightmost contiguous
byte received. When the stream is fully drained AND end-of-stream
(EOS) was observed (<code>next == EOS</code> byte position), <code>flow_read</code> returns
0 (<code>EOF</code>) - the same shape POSIX <code>read(2)</code> uses on TCP after a peer
FIN.

=== 16.4. Flow control ===

ACK / SACK / RACK / RTO machinery is unchanged; the FRTX reorder
ring is reused as a per-<code>seqno</code> received-bitmap. Let <code>per_pkt =
(frag_mtu - base PCI - stream PCI extension)</code>, the maximum stream-
byte payload one DATA packet can carry ([[#16.1. Send|Section 16.1]]). The
receive window advertised in FC is clamped so the byte window
(<code>ring_sz</code>) cannot be overrun: the <code>seqno</code>-space <code>rwe</code> is at most
<code>rcv_cr.lwe + ring_sz / per_pkt</code>.

This is the QUIC byte-credit flow-control model
(<code>MAX_STREAM_DATA</code>, RFC 9000 sec. 4.1 and sec. 19.10) projected onto
<code>seqno</code> space. With one stream per flow there is no <code>MAX_DATA</code> /
<code>MAX_STREAM_DATA</code> distinction. Receiver-side silly-window-syndrome
(SWS) avoidance (RFC 9293 sec. 3.8.6.2.2) is achieved by combining
the consume-time <code>rwe</code> bump with the global non-shrink rule from
[[#11. Flow control|Section 11]].

=== 16.5. Security considerations ===

Threat model. An attacker that can observe (on-path passive) or
predict (off-path blind) the flow's seqnos and byte offsets on an
unencrypted stream flow can inject DATA or FIN at any in-window
position. The in-line consistency checks above (<code>start</code> == prior
<code>end</code> on advance; FIN MUST be 0-byte; FIN MUST sit at the final
byte position) realise the spirit of RFC 5961's "sequence-window
plus exact-position match for control bits" without an explicit
challenge-ACK probe; they make a few specific blind attack shapes
harder but are not cryptographic authentication. This is
comparable to TCP without the TCP Authentication Option (TCP-AO,
RFC 5925), tighter than a
pre-RFC-5961 TCP stack, and roughly equivalent to a modern
RFC 5961 stack against blind off-path injection - none of these
help once the attacker can sniff. TLS over TCP (RFC 8446)
encrypts only the TCP payload and leaves TCP seqnos, ACKs, FIN,
and RST in the clear, so TLS does NOT defend against TCP-header-
level injection; QUIC (RFC 9000) hides packet numbers under
header protection (RFC 9001 sec. 5.4), so this specific weakness
does not apply to QUIC.

Mitigation: AEAD. When the flow has encryption enabled the
recommended AEAD ciphers (AES-GCM, RFC 5288; or ChaCha20-Poly1305,
RFC 8439) wrap the entire FRCP packet on the wire - PCI, stream
extension, body, and the CRC trailer when <code>ber == 0</code> - under a
per-flow symmetric key derived from the flow's own key exchange
([[#1.1. PCI header|Section 1.1]]). The AEAD tag (~2^-128 forgery probability)
dominates the CRC (~2^-32) for integrity in this mode but the CRC
trailer is currently retained inside the wrap (see [[#1.1. PCI header|Section 1.1]]).
Implementations MUST NOT rely on the security properties below
when a non-AEAD cipher (e.g. AES-CTR alone) is negotiated; non-
AEAD modes provide confidentiality only and the threat-model
claims do not hold.

With an AEAD cipher in use, seqnos, byte offsets, and the FIN bit
are both authenticated and confidential. Against an off-path or
on-path-passive attacker this is:

* Stronger than TCP+TLS (TCP header in the clear).
* Stronger than TCP+TCP-AO (header authenticated but visible).
* 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. 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 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
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 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 ==

This section lists the IETF documents, published works, and
source-code references cited inline elsewhere in this document.
IETF documents are cited inline as "RFC NNNN sec. X.Y"; books,
journal papers, and source-code references are cited inline by
author and year (or by file and function name) and are listed
here for convenience.

=== 17.1. IETF documents ===

;[RFC 791]
:J. Postel, "Internet Protocol", STD 5, RFC 791, September 1981.
;[RFC 793]
:J. Postel, "Transmission Control Protocol", STD 7, RFC 793, September 1981. Obsoleted by RFC 9293.
;[RFC 813]
:D. D. Clark, "Window and Acknowledgement Strategy in TCP", RFC 813, July 1982.
;[RFC 896]
:J. Nagle, "Congestion Control in IP/TCP Internetworks", RFC 896, January 1984.
;[RFC 1122]
:R. Braden (ed.), "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
;[RFC 2018]
:M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
;[RFC 2119]
:S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
;[RFC 2883]
:S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
;[RFC 3758]
:R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
;[RFC 3828]
:L-A. Larzon, M. Degermark, S. Pink, L-E. Jonsson (ed.), G. Fairhurst (ed.), "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
;[RFC 4303]
:S. Kent, "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
;[RFC 4340]
:E. Kohler, M. Handley, S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
;[RFC 5288]
:J. Salowey, A. Choudhury, D. McGrew, "AES Galois Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, August 2008.
;[RFC 5595]
:G. Fairhurst, "The Datagram Congestion Control Protocol (DCCP) Service Codes", RFC 5595, September 2009.
;[RFC 5681]
:M. Allman, V. Paxson, E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
;[RFC 5925]
:J. Touch, A. Mankin, R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
;[RFC 5961]
:A. Ramaiah, R. Stewart, M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, August 2010.
;[RFC 6298]
:V. Paxson, M. Allman, J. Chu, M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, June 2011.
;[RFC 6528]
:F. Gont, S. Bellovin, "Defending against Sequence Number Attacks", RFC 6528, February 2012. Obsoletes RFC 1948.
;[RFC 6582]
:T. Henderson, S. Floyd, A. Gurtov, Y. Nishida, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 6582, April 2012.
;[RFC 7323]
:D. Borman, B. Braden, V. Jacobson, R. Scheffenegger (ed.), "TCP Extensions for High Performance", RFC 7323, September 2014.
;[RFC 7675]
:M. Perumal, D. Wing, R. Ravindranath, T. Reddy, M. Thomson, "Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness", RFC 7675, October 2015.
;[RFC 8174]
:B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017.
;[RFC 8200]
:S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, July 2017.
;[RFC 8439]
:Y. Nir, A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 8439, June 2018.
;[RFC 8446]
:E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, August 2018.
;[RFC 8985]
:Y. Cheng, N. Cardwell, N. Dukkipati, P. Jha, "The RACK-TLP Loss Detection Algorithm for TCP", RFC 8985, February 2021.
;[RFC 9000]
:J. Iyengar (ed.), M. Thomson (ed.), "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, May 2021.
;[RFC 9001]
:M. Thomson (ed.), S. Turner (ed.), "Using TLS to Secure QUIC", RFC 9001, May 2021.
;[RFC 9002]
:J. Iyengar (ed.), I. Swett (ed.), "QUIC Loss Detection and Congestion Control", RFC 9002, May 2021.
;[RFC 9147]
:E. Rescorla, H. Tschofenig, N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, April 2022.
;[RFC 9260]
:R. Stewart, M. Tuexen, K. Nielsen, "Stream Control Transmission Protocol", RFC 9260, June 2022. Obsoletes RFC 4960.
;[RFC 9293]
:W. Eddy (ed.), "Transmission Control Protocol (TCP)", STD 7, RFC 9293, August 2022. Obsoletes RFC 793 and several follow-ons; updates RFC 1122 and others.

=== 17.2. Books and journal papers ===

;[Day08]
:J. Day, "Patterns in Network Architecture: A Return to Fundamentals", Prentice Hall, 2008.
;[Grasa15]
:E. Grasa et al., "IRATI: investigating RINA as an alternative to TCP/IP", Computer Networks, Vol. 92, December 2015.
;[KP87]
:P. Karn, C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", ACM SIGCOMM, August 1987.
;[Wat81]
:R. W. Watson, "Timer-Based Mechanisms in Reliable Transport Protocol Connection Management", Computer Networks, Vol. 5, 1981.

=== 17.3. Source-code references ===

;[Linux-RTT]
:<code>tcp_rtt_estimator()</code> in <code>net/ipv4/tcp_input.c</code> of the Linux kernel, defining the asymmetric <code>mdev</code> variance update used as FRCP's default RTT estimator ([[#12. RTT estimation|Section 12]]). Line-stable browseable copy at https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_input.c.

[[Category:Protocols]]
[[Category:Ouroboros internals]]

Flow and Retransmission Control Protocol

2026-05-18T01:06:47Z

Dimitri: /* 1.1. PCI header */

{{DISPLAYTITLE:FRCP - Flow and Retransmission Control Protocol}}

FRCP runs end-to-end between two peers over a flow. It delivers
reliability, in-order delivery, flow control, and liveness.
Congestion Control (CC) is not in FRCP - that lives in the IPC
Process (IPCP) Congestion Avoidance (CA) policies, orthogonal to
FRCP. Flow allocation, naming, and IPCP lifecycle are handled by
the IPC Resource Manager daemon (IRMd).

FRCT (Flow and Retransmission Control Task) is the libouroboros
implementation of FRCP; the task lives in <code>src/lib/frct.c</code>. The
remainder of this document describes the FRCP wire protocol and the
behaviour FRCT realises. Code symbols retain the <code>FRCT_</code> prefix
(<code>FRCT_DATA</code>, <code>FRCT_RXM</code>, ...) because they belong to the implementing
task; this document references them verbatim.

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in <code>BCP</code> 14 (Best
Current Practice; RFC 2119, RFC 8174) when, and only when, they
appear in all capitals.

== Notation ==

;<code>u32</code>, <code>u8</code>
:Unsigned 32-bit / 8-bit integers (kernel-C style).
;<code>ns</code>
:Nanoseconds.

Modular sequence-number comparators (32-bit, modulo 2^32):

;<code>before(a, b)</code>
:<code>(int32_t)(a - b) < 0</code>
;<code>after(a, b)</code>
:<code>before(b, a)</code>

Used throughout for <code>ackno</code> / <code>seqno</code> ordering checks.

Round-Trip Time (RTT) abbreviations used throughout:

;<code>SRTT</code>
:Smoothed RTT estimate (RFC 6298).
;<code>mdev</code>
:Mean deviation of RTT (Linux variance estimator).
;<code>EWMA</code>
:Exponentially Weighted Moving Average.
;<code>RTO</code>
:Retransmission Timeout, <code>max(RTO_MIN, srtt + (mdev << MDEV_MUL))</code>.

Timer-bound symbols <code>t_a</code> (a-timer, ACK delay) and <code>t_r</code> (r-timer,
retransmission window) are defined in [[#8. Retransmission|Section 8]]; <code>t_mpl</code> (Maximum
Packet Lifetime) is introduced in [[#2.1. Per-flow state|Section 2.1]] (the <code>inact</code> field)
with heritage in [[#15. Heritage and adopted techniques|Section 15]].

Wire-format diagrams follow the IETF convention: bit 0 is the
leftmost (most significant) bit and fields are in network byte
order unless stated otherwise.

__TOC__

== 1. Wire format ==

=== 1.1. PCI header ===

Fixed 16-octet base Protocol-Control Information (PCI) header
prefixed to every FRCP packet (RFC convention: bit 0 leftmost,
most-significant bit first). All multi-byte fields are in network byte order. DATA packets on
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
base PCI.

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | hcs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ackno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload (variable) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>flags</code>
:feature/type bitmap (see [[#1.2. Flag bits|Section 1.2]]).
;<code>hcs</code>
:CRC-16-CCITT-FALSE Header Check Sequence (HCS) over <code>flags</code> + <code>window</code> + <code>seqno</code> + <code>ackno</code> (+ stream extension when present); the two octets of the <code>hcs</code> field itself are omitted from the CRC input. Verified on receive before any flag-driven dispatch.
;<code>window</code>
:receiver-advertised right window edge (valid iff FC).
;<code>seqno</code>
:per-flow sequence number.
;<code>ackno</code>
:cumulative Acknowledgement (ACK) (valid iff ACK).

A single packet can simultaneously carry DATA + ACK + FC (Flow
Control) + RXM (Retransmission) by ORing flag bits; the PCI
multiplexes control on the same wire frame in the spirit of SCTP
chunk bundling (RFC 9260 sec. 6.10) and QUIC frame multiplexing
(RFC 9000 sec. 12.4). DATA-bearing packets carry the caller's
payload after the PCI; SACK (Selective Acknowledgement) and RTTP
(Round-Trip Time Probe) carry their own typed payloads after the
PCI.

Optional framing (per-flow, see [[#2.2. Service modes (orthogonal axes)|Section 2.2]]). On the wire, the
order from inside out is:

{| class="wikitable"
! Layer !! Scope
|-
| <code>[ PCI + body ]</code>
| The FRCP packet.
|-
| <code>[ PCI + body + CRC-32 ]</code>
| CRC-32 covers the body only (PCI is in HCS); appended iff <code>qs.ber == 0</code> on DATA, or on every SACK packet.
|-
| <code>[ AEAD-wrap of above ]</code>
| Iff Authenticated Encryption with Associated Data (AEAD) is enabled.
|}

* 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 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>).

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

=== 1.2. Flag bits ===

Flag bits are numbered most-significant-bit first to match the wire
diagram (bit numbering per [[#1.1. PCI header|Section 1.1]]; bit 0 is the MSB of the
16-bit <code>flags</code> field and lands at wire-position 0 in network byte
order). Bits 13..15 are reserved and MUST be transmitted as zero.

{| class="wikitable"
! Bit !! Mask !! Name !! Meaning
|-
| 0 || <code>0x8000</code> || <code>DATA</code> || Carries caller payload
|-
| 1 || <code>0x4000</code> || <code>DRF</code> || Data Run Flag: start of a fresh run
|-
| 2 || <code>0x2000</code> || <code>ACK</code> || Acknowledgement: <code>ackno</code> field valid
|-
| 3 || <code>0x1000</code> || <code>NACK</code> || Negative ACK; <code>seqno = arrival_seqno-1</code>
|-
| 4 || <code>0x0800</code> || <code>FC</code> || Flow Control: <code>window</code> field valid (<code>rwe</code>)
|-
| 5 || <code>0x0400</code> || <code>RDVS</code> || Rendezvous probe (window-closed)
|-
| 6 || <code>0x0200</code> || <code>FFGM</code> || First Fragment (role bit 0; see below)
|-
| 7 || <code>0x0100</code> || <code>LFGM</code> || Last Fragment (role bit 1; see below)
|-
| 8 || <code>0x0080</code> || <code>RXM</code> || Retransmission
|-
| 9 || <code>0x0040</code> || <code>SACK</code> || Selective ACK block list in payload
|-
| 10 || <code>0x0020</code> || <code>RTTP</code> || RTT Probe / echo (payload follows)
|-
| 11 || <code>0x0010</code> || <code>KA</code> || Keepalive
|-
| 12 || <code>0x0008</code> || <code>FIN</code> || End-of-stream marker (stream mode)
|-
| 13-15 || -- || -- || Reserved (MUST be zero)
|}

The (<code>FFGM</code>, <code>LFGM</code>) pair encodes the fragment role of a DATA-bearing
Service Data Unit (SDU), SCTP-style begin/end flags (RFC 9260
sec. 3.3.1):

{| class="wikitable"
! FFGM !! LFGM !! Role
|-
| 1 || 1 || Sole / un-fragmented SDU (begin AND end)
|-
| 1 || 0 || First fragment of a multi-fragment SDU
|-
| 0 || 0 || Middle fragment
|-
| 0 || 1 || Last fragment
|}

Each fragment is carried in its own FRCP packet with its own <code>seqno</code>;
FRTX (the FRCT Retransmission service mode, see [[#2.2. Service modes (orthogonal axes)|Section 2.2]])
recovers individual fragments via the normal Retransmission Timeout
(RTO) / SACK / Recent Acknowledgement (RACK, RFC 8985) path. The
receiver reassembles the SDU at consume time once the contiguous
[FIRST .. LAST] run has fully arrived. On non-DATA packets the role
bits are unused and MUST be transmitted as zero.

In stream mode (<code>qos.service == SVC_STREAM</code>, see [[#16. Stream-mode flows|Section 16]]) there are
no SDU boundaries to encode, so <code>FFGM</code> and <code>LFGM</code> are unused and MUST
be transmitted as zero. End-of-stream uses a dedicated bit (<code>FIN</code>,
bit 12) carried on a 0-byte DATA packet, emitted at write-half close
(<code>fccntl</code> to <code>FLOWFRDONLY</code>), during linger drain, and at <code>flow_dealloc</code>;
emission is idempotent (first call wins). After contiguous delivery
of the FIN-bearing slot, the receiver latches <code>byte_fin</code> at the FIN's
start offset; <code>flow_read</code> returns 0 (end-of-file, <code>EOF</code>) once buffered
bytes have been drained up to <code>byte_fin</code>. Per-byte position is
carried by the [start, end) extension ([[#1.5. Stream PCI extension|Section 1.5]]).

=== 1.3. SACK payload ===

A SACK packet has the <code>FRCT_ACK | FRCT_FC | FRCT_SACK</code> flag bits set
(bit numbering per [[#1.1. PCI header|Section 1.1]]). Following the 16-octet PCI, the
payload is a 2-octet block count (network byte order), 2 octets of
padding to 4-byte align the block list, then <code>n_blocks</code> pairs of
32-bit start/end seqnos describing ''present'' (received) ranges
above the cumulative ACK.

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_blocks | padding (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start[0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end[0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... n_blocks pairs total ...
</syntaxhighlight>

<code>n_blocks <= SACK_MAX_BLOCKS</code> (2048). The per-flow effective cap is
further bounded by <code>(frag_mtu - PCI - 4) / 8</code> blocks per packet; SACK
packets carry no stream extension, so PCI here is the 16-octet base
header even on stream-mode flows.

Wire invariant: every block produced by the receiver, except an
optional leading Duplicate SACK (D-SACK) block as described below,
describes a range strictly above the cumulative ACK carried in the
PCI <code>ackno</code> field (<code>after(start[i], ackno)</code>). This makes the D-SACK
convention below unambiguous; the receiver-side builder MUST
preserve it.

Duplicate SACK (D-SACK, RFC 2883) is signalled in-band: no flag
bit, no extra framing. Modular seqno arithmetic uses the
<code>before()</code> / <code>after()</code> comparators defined in the Notation block.

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)
:<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)
:<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.

The <code>reo_wnd_mult</code> halving cadence (once per 16 cumulatively-ACK'd
seqnos since the most-recent D-SACK arrival or halve event) and
the reset-to-1 on a HoL RTO fire are both per the same RFC 8985
clause. The clamp-and-skip path in the regular SACK-mark loop is
incidentally idempotent on any leftover case-1 or case-2 block
(<code>start < snd_cr.lwe</code> clamps to <code>snd_cr.lwe</code> and the inner loop
skips <code>k == snd_cr.lwe</code>; case-2 re-NULLs slots already marked
received by later blocks), so block[0] is harmless even when fed
to the loop.

=== 1.4. RTTP payload ===

An RTTP (Round-Trip Time Probe) packet has only the <code>FRCT_RTTP</code> flag
set (bit numbering per [[#1.1. PCI header|Section 1.1]]). Following the 16-octet PCI,
the payload is 24 octets (packed):

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| probe_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| echo_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ nonce (16 octets, echoed verbatim) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>probe_id</code>
:sender counter, 0 on reply, 0 reserved.
;<code>echo_id</code>
:peer's <code>probe_id</code>, 0 on outbound probe.
;<code>nonce</code>
:random, echoed unmodified, memcmp'd to defeat spoof.

=== 1.5. Stream PCI extension ===

A stream-mode flow (<code>qos.service == SVC_STREAM</code>) carries an extra
8-octet extension after the 16-octet base PCI on every DATA packet
(bit numbering per [[#1.1. PCI header|Section 1.1]]):

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>start</code>
:octet offset of the first payload byte in the stream.
;<code>end</code>
:octet offset one past the last payload byte; <code>end - start</code> equals the on-wire payload length.

Total stream-mode PCI for DATA packets is 24 octets (16 base + 8
extension); control packets (SACK, RTTP, bare ACK, KA, etc.) retain
the 16-octet base PCI. Stream mode MUST be negotiated at flow
allocation; the extension is present iff stream mode is in use,
never on a per-packet basis. Both peers MUST treat <code>start</code>/<code>end</code> as
monotonic 32-bit byte offsets; when a slot reaches the head of the
contiguous run with <code>start</code> not equal to the prior packet's <code>end</code> the
slot is silently dropped at delivery time ([[#16. Stream-mode flows|Section 16]]) rather
than rejected at stash.

This is the QUIC STREAM-frame reassembly model (RFC 9000 sec. 19.8):
each packet carries its packet <code>seqno</code> (this PCI's <code>seqno</code> field) and a
separate stream byte position (<code>start</code>/<code>end</code>). Separating the two
avoids TCP's conflation of packet identity with byte position which
forces Karn's algorithm for Round-Trip Time (RTT) sampling (no RTT
sample on retransmits, RFC 6298 sec. 3); FRCP applies the
Karn-equivalent gate via a combination of per-packet <code>FRCT_RXM</code>,
per-slot <code>SND_RTX</code> flags, and a sample-fence <code>rtt_lwe</code> (see [[#2.1. Per-flow state|Section 2.1]]
and [[#12. RTT estimation|Section 12]]). FRCP's fixed-32-bit <code>start</code>/<code>end</code> wrap at 4 GiB of
wire bytes, narrower than QUIC's 62-bit varint offset (cf. RFC 9000
sec. 16); the on-wire wrap is handled by the same modular <code>before()</code>
/ <code>after()</code> comparators ([[#1.3. SACK payload|Section 1.3]]) FRCP uses for seqnos, which
remain unambiguous as long as the in-flight byte window stays
strictly under 2 GiB (the half-range of the signed-int32 difference
in <code>before()</code>). The default per-flow ring is 1 MiB; the
implementation caps <code>ring_sz</code> at 128 MiB (<code>FRCT_STREAM_RING_SZ_MAX</code>),
well below the 2 GiB half-range bound. The runtime byte counters
exposed via FUSE (Filesystem in Userspace) in the Ouroboros
Resource Information Base (RIB, a virtual-filesystem introspection
bridge) are platform <code>size_t</code> and do not wrap on 64-bit hosts.

== 2. Per-flow state and service modes ==

=== 2.1. Per-flow state ===

Each flow keeps a sender control record and a receiver control
record:

;<code>lwe</code> : <code>u32</code>
:snd: oldest unacked <code>seqno</code> (cumulative ACK boundary as seen by sender); rcv: next in-order <code>seqno</code> expected
;<code>rwe</code> : <code>u32</code>
:snd: peer-advertised right window edge; rcv: locally-advertised right window edge
;<code>cflags</code> : <code>u8</code>
:per-direction feature flags: retransmission (<code>FRCTFRTX</code>), receiver flow control (<code>FRCTFRESCNTL</code>), linger-on-close (<code>FRCTFLINGER</code>); see <code><ouroboros/fccntl.h></code>
;<code>seqno</code> : <code>u32</code>
:snd: next <code>seqno</code> to send; rcv: force-ACK trigger - set on a stale or dup DATA so the next <code>ack_snd</code> emits a fresh cumulative ACK
;<code>ackno</code> : <code>u32</code>
:snd: <code>seqno</code> counter for standalone ACK-bearing control packets (delayed ACK, SACK, final ACK on dealloc); not bumped on piggybacked ACK riding a DATA packet (which uses the DATA <code>seqno</code>). Used by wire-dup ACK detection; rcv: incoming-ACK dedup tracker
;<code>act</code> : <code>ns</code>
:last activity (used by inactivity / DRF)
;<code>inact</code> : <code>ns</code>
:inactivity threshold; sender = <code>3*mpl + a + r + 1s</code>, receiver = <code>2*mpl + a + r + 1s</code>. <code>mpl</code> is the Maximum Packet Lifetime (delta-t terminology; see [[#15. Heritage and adopted techniques|Section 15]]); <code>a</code> and <code>r</code> are the FRCT a-timer and r-timer bounds (see [[#8. Retransmission|Section 8]]). The asymmetry is load-bearing for pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]).

The sender holds a per-slot ring <code>snd_slots[RQ_SIZE]</code> keyed by
<code>(seqno mod RQ_SIZE)</code>. Each slot tracks its retransmit entry (<code>rxm</code>),
last-send timestamp, and retransmit flag bits: <code>SND_RTX</code> (a
retransmit is pending or has fired, gates the next RTT sample
under Karn) and <code>SND_FAST_RXM</code> (one-shot fast-retransmit staged for
this loss event).

The receiver holds a parallel reorder ring <code>rcv_slots[RQ_SIZE]</code>
(referred to as <code>rq[]</code> in prose) holding stashed out-of-order
packet-buffer indexes; both FRTX and best-effort flows share this
path. The invariant <code>rwe - lwe <= RQ_SIZE</code> holds: on each consume
the receiver advances <code>rwe</code> by the consumed count, capping the
receive window at <code>RQ_SIZE</code> <code>seqno</code> slots.

A separate fence variable <code>rtt_lwe</code> is bumped on every retransmit
(timer-fire, SACK-driven, fast-rxm, NACK-driven) and on every
<code>seqno_rotate</code> ([[#4. Sequence-number rotation (DRF)|Section 4]]) to mark the <code>seqno</code> range whose RTT samples
MUST be discarded.

=== 2.2. Service modes (orthogonal axes) ===

FRCP exposes its wire features as a vector of independent QoS
axes selected at flow allocation time. All flows go through the
same <code>flow_alloc(name, qos, ...)</code> primitive; the <code>qosspec_t</code> passed
in determines which protocol machinery engages on the wire. This
contrasts with the POSIX BSD socket model where TCP and UDP
require different socket types (<code>SOCK_STREAM</code> / <code>SOCK_DGRAM</code>).

The axes:

;<code>service</code>
:0 = unordered (no FRCP engagement: raw datagrams, no PCI on the wire, UDP-equivalent at this layer); 1 = message-ordered (FRCP engaged; SDU boundaries preserved across fragmentation); 2 = stream (byte-oriented, no SDU boundaries; FRTX required)
;<code>loss</code>
:0 = lossless service requested: FRTX retransmit machinery engages ([[#8. Retransmission|Section 8]]); MUST be 0 for <code>service=2</code>. Non-zero = best-effort, FRTX off.
;<code>ber</code>
:Bit Error Rate tolerance. 0 = error-free service requested: a CRC trailer is appended after the body of DATA packets and verified on receive (added / checked outside the FRCP PCI; see [[#1.1. PCI header|Section 1.1]]). Non-zero = peer accepts errors; trailer omitted. SACK control packets carry a CRC32 trailer regardless of <code>ber</code>; the <code>ber</code> gate applies to DATA only.
;<code>timeout</code>
:Peer-timeout (ms); 0 disables the keepalive timer. Independent of FRCP engagement.

Encryption is a separate per-flow attribute set at flow setup;
when enabled it wraps the FRCP packet (PCI + body, plus the CRC
trailer if any) under AEAD, expanding the <code>spb</code> by <code>headsz</code> + <code>tailsz</code>
octets (nonce / tag). The CRC trailer is currently kept inside
the AEAD wrap (see [[#1.1. PCI header|Section 1.1]]).

Reachable combinations exported by <code>include/ouroboros/qos.h</code>:

{| class="wikitable"
! Cube !! <code>service</code> !! <code>loss</code> !! <code>ber</code> !! Engaged
|-
| <code>qos_raw</code> || 0 || 1 || 1 || Raw passthrough
|-
| <code>qos_raw_safe</code> || 0 || 1 || 0 || Raw + CRC trailer
|-
| <code>qos_rt</code> || 1 || 1 || 1 || FRCP, no FRTX, no CRC
|-
| <code>qos_rt_safe</code> || 1 || 1 || 0 || FRCP, no FRTX, CRC
|-
| <code>qos_msg</code> || 1 || 0 || 0 || FRCP + FRTX
|-
| <code>qos_stream</code> || 2 || 0 || 0 || FRCP + FRTX, stream
|}

Forced couplings actually enforced by the public API:

* <code>service == SVC_STREAM</code> (2) requires <code>loss == 0</code>; <code>flow_alloc</code> / <code>flow_accept</code> reject the pair otherwise with <code>-EINVAL</code>.
* FRTX requires FRCP engagement (<code>service != SVC_RAW</code>); requesting <code>loss = 0</code> with <code>service = SVC_RAW</code> is structurally a no-op because no <code>frcti</code> is created.
* The <code>QOS_DISABLE_CRC</code> build flag globally forces <code>ber = 1</code>. Note: this flag defaults to ON, so default builds ship with CRC disabled until <code>QOS_DISABLE_CRC</code> is set to OFF.

Caveat: the API does NOT force <code>ber = 0</code> when <code>service != SVC_RAW</code>.
<code>qos_rt</code> has <code>service = SVC_MESSAGE</code> with <code>ber = 1</code>, which means the PCI
itself is not CRC-protected on that cube; the HCS ([[#1.1. PCI header|Section 1.1]])
remains the only integrity check on the header.

The FRCP-no-FRTX regime (<code>service = SVC_MESSAGE</code>, <code>loss > 0</code>) is meaningful
and live: sequence numbering, in-order delivery, flow-control
advertisement, KA, DRF rotation, and SDU fragmentation /
reassembly ([[#7.2. Fragmentation and reassembly|Section 7.2]]) all run. Lost packets are dropped
rather than retransmitted; a permanently-lost mid-fragment is
dropped via skip-past-gap once a later SDU is visible in the
reorder ring.

== 3. Protocol parameters ==

{| class="wikitable"
! Parameter !! Value !! Role
|-
| <code>RQ_SIZE</code> || compile-time, power of 2 (default 128) || Slot ring / rcv window width
|-
| <code>START_WINDOW</code> || compile-time, power of 2 (default 128) || Initial <code>rwe-lwe</code> after rotate
|-
| <code>RTO_MIN</code> || <code>MAX(250 us build-tunable, 1<<RXMQ_RES)</code>; per-flow via <code>fccntl</code> (<code>FRCTSRTOMIN</code>). Default ~1 ms with <code>RXMQ_RES=20</code>. || RTO floor; also floored at the retransmit-wheel resolution (~1 ms by default).
|-
| <code>MAX_RTO_MUL</code> || 20 || Backoff shift cap
|-
| RACK window <code>R</code> || <code>MIN(reo_wnd_mult * min_RTT/4, SRTT)</code> with <code>MIN_REORDER_NS = 250 us</code> floor; <code>reo_wnd_mult</code> scales on D-SACK, cap 20 || Reorder window; per RFC 8985 sec. 6.2; <code>reo_wnd_mult</code> per sec. 6.2 step 4
|-
| <code>MIN_RTT_WIN_NS</code> || 300 s (5 min, Linux <code>tcp_min_rtt_wlen</code>) || <code>min_RTT</code> windowed re-anchor
|-
| <code>REO_WND_MULT_MAX</code> || 20 (RFC 8985 sec. 6.2 step 4) || <code>reo_wnd_mult</code> cap
|-
| <code>REO_DECAY_PKTS</code> || 16 (RFC 8985 sec. 6.2 step 4 / <code>RACK.reo_wnd_persist</code>) || Fresh-ACK'd seq count per halving
|-
| <code>MAX_DSACK_LAG</code> || <code>RQ_SIZE</code> || D-SACK sanity cap
|-
| <code>RTT_QUARANTINE</code> || 32 (<code>seqno</code> steps) || NewReno gate pad
|-
| SACK rate-limit || <code>SACK_MIN_GAP_NS</code> (250 us, fixed) || Min SACK gap
|-
| <code>SACK_MAX_BLOCKS</code> || 2048 (wire cap; per-flow capped at <code>(frag_mtu-PCI-4)/8</code>) || Per-SACK block cap
|-
| <code>SACK_RXM_MAX</code> || 32 || Per-pass staged retransmit cap
|-
| <code>DUP_THRESH</code> || 3 (RFC 8985 default) || Hybrid fast-rxm trigger ([[#8. Retransmission|Section 8]])
|-
| <code>MDEV_MUL</code> || 2 (build-tunable via <code>FRCT_RTO_MDEV_MULTIPLIER</code>) || <code>mdev</code> shift in <code>RTO = srtt + (mdev << MDEV_MUL)</code>
|-
| RTTP nonce || 16 octets || Echoed verbatim
|-
| <code>RTTP_RING</code> || 8 || In-flight probes
|-
| RTT clamp || <code>16 * srtt</code> || Probe-sample upper bound (ACK-derived RTT samples gated by Karn / recovery only)
|-
| Cold-probe cadence || 100 ms (rx-driven; see [[#12. RTT estimation|Section 12]]) || Pre-<code>srtt</code> RTTP rate
|-
| <code>DELT_RDV</code> || 100 ms || RDVS emit cadence
|-
| <code>MAX_RDV</code> || 1 s || RDVS give-up
|-
| Delayed-ACK fire || <code>2 * TICTIME</code> (<code>TICTIME</code> = FRCT tick granularity, default 5 ms; <code>2*TICTIME = 10 ms</code> by default) || Fired after the first in-order DATA arrival; tick is build-tunable
|-
| NACK send cooldown || <code>srtt</code> when an <code>srtt</code> sample exists, else 100 ms || Pre-DRF NACK rate-limit
|-
| <code>MAX_SDU</code> || 1 MiB || Max reassembled SDU; configurable per flow
|}

The per-flow fragment Maximum Transmission Unit (MTU) is computed
at flow setup from the lower IPCP's mtu minus encryption
<code>headsz</code> / <code>tailsz</code> and CRC trailer; there is no FRCT-level default or
environment-variable override.

== 4. Sequence-number rotation (DRF) ==

The DRF (Data Run Flag) bit on an outbound packet means "this is
the start of a fresh data run" and is set whenever the sender has
nothing in flight (<code>snd_cr.seqno == snd_cr.lwe</code>).

Independently of that, if the sender has been idle longer than
<code>snd_cr.inact</code> AND the pipe is empty (<code>snd_cr.seqno == snd_cr.lwe</code>),
<code>seqno_rotate()</code> rolls a random new <code>seqno</code> before the send and
resets

<syntaxhighlight lang="text">
snd_cr.seqno = random()
snd_cr.lwe = snd_cr.seqno
snd_cr.rwe = snd_cr.seqno + START_WINDOW
rtt_lwe = snd_cr.seqno
in_recovery = false (recovery state, see Section 8)
recovery_high = snd_cr.seqno
</syntaxhighlight>

The receiver, on observing rcv-side inactivity
(<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
below). Non-DATA control packets pass through without the DRF
requirement. On DRF the receiver releases the <code>rq[]</code> slots and
rebases

<syntaxhighlight lang="text">
rcv_cr.lwe = seqno
rcv_cr.rwe = seqno + RQ_SIZE
rcv_cr.seqno = seqno
</syntaxhighlight>

If the inactive packet has DATA but no DRF, a rate-limited NACK is
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).

== 5. Send path ==

# If the SDU exceeds <code>(frag_mtu - data_hdr_len)</code>, the caller (<code>dev.c</code>) fans it out into <code>ceil(count / (frag_mtu - data_hdr_len))</code> fragments, each emitted via <code>frcti_snd</code> as its own DATA packet with a per-fragment role ([[#7.2. Fragmentation and reassembly|Section 7.2]]); both FRTX and best-effort flows fragment. Raw flows (no FRCP engagement, <code>qos.service == SVC_RAW</code>) carry no PCI and return <code>-EMSGSIZE</code> for any SDU larger than one packet at the layer below. An SDU that fits in a single packet is sent as SOLE. <code>frcti_snd</code> reserves PCI head room; sets DATA, plus DRF when the pipe is empty (<code>snd_cr.seqno == snd_cr.lwe</code>).
# <code>seqno_rotate()</code> if past sender inactivity and the pipe is empty ([[#4. Sequence-number rotation (DRF)|Section 4]]).
# Advertise FC (<code>pci.window = frcti_advert_rwe(frcti)</code>, i.e. <code>rcv_cr.rwe</code> clamped to <code>rcv_cr.lwe + ring_seq_cap</code> in stream mode) when the receiver side is recent: <code>now - rcv_cr.act < rcv_cr.inact</code>.
# Reliable mode (FRTX): leave <code>snd_cr.lwe</code> where it is; reset the slot at <code>RQ_SLOT(seqno)</code> (<code>snd_slots[p].time = now</code>, <code>snd_slots[p].flags = 0</code>); queue an <code>rxm_entry</code> (saves a packet copy, arms a wheel timer at <code>now + (rto << rto_mul)</code>). Piggyback ACK (<code>pci.ackno = rcv_cr.lwe</code>) while the a-timer for the most recent received DATA packet has not yet expired (<code>now - rcv_cr.act <= t_a</code>); on piggyback, set <code>rcv_cr.seqno = rcv_cr.lwe</code> so the next delayed-ACK fire is suppressed. See [[#8. Retransmission|Section 8]] for <code>t_a</code> / <code>t_r</code> semantics.
# Best-effort mode (no FRTX): advance <code>snd_cr.lwe</code> immediately (<code>snd_cr.lwe = snd_cr.lwe + 1</code>, <code>snd_cr.rwe = snd_cr.lwe + RQ_SIZE</code>); no retransmit state. No send-side RTT probe is armed in this mode (<code>rtt_probe_arm</code> requires an in-flight <code>seqno</code>, which best-effort never has); the rx-driven cold seeder in <code>frcti_rcv</code> is the only probe path.
# In reliable mode, optionally arm an RTT probe ([[#12. RTT estimation|Section 12]]).

== 6. Receive path ==

=== 6.1. Early-exit dispatch ===

Keepalive (KA), RTT probe (RTTP), pre-DRF NACK, and rendezvous
(RDVS) packets short-circuit out of <code>frcti_rcv</code> before the locked
main path; each handler takes its own lock internally.

<syntaxhighlight lang="text">
incoming packet
|
v
+---------+
| KA? |---yes--> ka_rcv ; return
+---------+
|no
v
+---------+
| RTTP? |---yes--> rttp_rcv; return
+---------+
|no
v
+---------+
| NACK? |---yes--> nack_rcv; return (see Section 9)
+---------+
|no
v
+---------+
| RDVS? |---yes--> rdv_rcv ; return (reply bare FC, ackno=0)
+---------+
|no
v
acquire wrlock; enter locked main path
</syntaxhighlight>

;<code>KA</code>
:refresh <code>t_ka_rcv</code>, honour piggybacked ACK.
;<code>RTTP</code>
:probe (echo back nonce) or echo (verify nonce, sample RTT).
;<code>NACK</code>
:pre-DRF, sender-side handler. See [[#9. Pre-DRF NACK|Section 9]].
;<code>RDVS</code>
:reply with a bare FC packet (<code>ackno = 0</code>); <code>rdlock</code> only.

=== 6.2. Locked main path ===

Steps below run with the per-flow <code>frcti.lock</code> held for writing
(<code>pthread_rwlock_wrlock</code>) unless noted.

;<code>rcv_inact_check</code>
:Only meaningful when the receive side is stale. On DRF (Data Run Flag): release <code>rq[]</code> slots, rebase <code>rcv_cr</code>, continue. On stale DATA without DRF: fire a pre-DRF NACK if cooldown allows ([[#9. Pre-DRF NACK|Section 9]]), then discard the packet; on cooldown, drop without sending a NACK (a pending cumulative ACK from <code>drop_packet</code> may still go out). Non-DATA, non-DRF arrivals bypass <code>rcv_inact_check</code> entirely; pure-DRF stale arrivals fall through after the DRF rebase branch.

;DATA-only act refresh
:Refresh <code>rcv_cr.act</code> only when <code>FRCT_DATA</code> is set, so that non-DATA packets never block the next DRF rebase.

;Wire-dup gate
:Before flag-driven dispatch, drop wire-duplicate ACKs and wire-duplicate DATA (<code>is_dup_ack</code> / <code>is_dup_data</code>). The DATA check is bypassed for <code>FRCT_RXM</code>-bearing arrivals so the piggybacked ACK / SACK / FC carried on a retransmitted DATA at an already-ACK'd <code>seqno</code> is still applied; the stale-in-window branch below then drops the packet.

;<code>ACK</code>
:Drop ACKs whose <code>ackno</code> falls outside <code>(snd_cr.lwe, snd_cr.seqno]</code>. If <code>ackno == snd_cr.lwe</code> (non-advancing cumulative ACK), drive RACK fast-retransmit consideration ([[#8. Retransmission|Section 8]]). Otherwise advance <code>snd_cr.lwe = ackno</code>, collapse <code>rto_mul</code> to 0 (Karn-gated by <code>SND_RTX</code> on the just-acknowledged slot, the old head-of-line), reset <code>dup_thresh</code> to 0, update <code>t_latest_ack</code> to the send-time of the slot at <code>ackno-1</code> (consumed by RACK and SACK below), decay <code>reo_wnd_mult</code> per RFC 8985 sec. 6.2 step 4, exit NewReno-careful recovery (see [[#8. Retransmission|Section 8]]) on <code>ackno >= recovery_high</code> or <code>ackno == snd_cr.seqno</code>, and feed an RTT sample if eligible ([[#12. RTT estimation|Section 12]]).

;<code>SACK</code>
:Walk the block list. For each block (a present range above <code>lwe</code>) NULL out <code>snd_slots[k].rxm</code>, clear the slot's per-send flags, and advance <code>t_latest_ack</code> to the latest send-time covered (the Forward Acknowledgement / fack equivalent, Mathis & Mahdavi 1996); the first block whose start clamps to <code>snd_cr.lwe</code> skips this fack update so that a head-of-line clamp does not falsely advance fack. For un-SACKed gaps below <code>hi_sacked</code>, stage a retransmit per slot that is (1) still owned (<code>rxm != NULL</code>), (2) not already <code>SND_FAST_RXM</code>, (3) not aged out past <code>t_r</code>, and (4) either outside the RACK reorder window <code>R</code> OR with <code>dup_thresh >= DUP_THRESH</code> (the RFC 8985 sec. 6.2 hybrid trigger). Mark the slot <code>SND_FAST_RXM</code> and NULL the <code>rxm</code> at stage time. Capped at <code>SACK_RXM_MAX</code> staged retransmits per receive pass; what's left rides the next SACK.

;<code>FC</code>
:Bump <code>snd_cr.rwe</code> (clamped to <code>lwe + RQ_SIZE</code>, never shrinks) and mark window open.

;<code>DATA</code>
:Bounds-check <code>seqno</code> against window. On stale-dup (<code>seqno < rcv_cr.lwe</code>), set <code>rcv_cr.seqno = seqno</code> to force a fresh ACK on the next <code>ack_snd</code>, then drop. On accept: both FRTX and best-effort stash the packet-buffer index into <code>rq[seqno mod RQ_SIZE]</code>. Fragments stash unchanged - the role bits are inspected only at consume time ([[#7.2. Fragmentation and reassembly|Section 7.2]]). On out-of-order arrival, build a SACK reply if not rate-limited (per [[#3. Protocol parameters|Section 3]]) and not deduplicated against the previous <code>(rcv_cr.lwe, n_blocks)</code> pair; D-SACK reports always bypass the dedup. If both rate-limit and dedup suppress the reply, neither SACK nor delayed-ACK fires (the sender picks up the gap on its next ACK). On in-order arrival, arm the delayed-ACK timer.

;<code>drop_packet</code> exit
:Releases the per-packet shared-memory buffer (<code>spb</code>), then calls <code>ack_snd</code> synchronously after the <code>spb</code> release to surface any pending cumulative ACK.

== 7. Read path and reassembly ==

=== 7.1. Read path ===

<code>flow_read</code> returns a full reassembled SDU (Service Data Unit) via
<code>frcti_consume</code> on every FRCP SDU-mode flow (FRTX or best-effort);
stream-mode is covered in [[#16. Stream-mode flows|Section 16]]. An incomplete head-of-line
(HoL) run yields <code>-EAGAIN</code>; an oversized run yields <code>-EMSGSIZE</code> (the
run is dropped so the flow does not stall). On best-effort flows,
a permanently-lost mid-fragment is dropped as soon as a later
complete SDU becomes visible in the ring ([[#7.2. Fragmentation and reassembly|Section 7.2]] skip-past-
gap).

Raw flows carry no <code>frcti</code>, so <code>flow_read</code> returns the next pending
packet-buffer index directly, with no role-bit inspection. (Raw
service is selected via <code>qos.service == SVC_RAW</code> at flow allocation,
which suppresses <code>frcti</code> creation.)

<code>frcti_pdu_ready</code> is the no-advance peek used by <code>fevent</code> (the
Ouroboros flow-event multiplexer, the <code>poll(2)</code>-equivalent on
flows). It returns ready only when the head-of-line run is
complete and the lead packet (a Protocol Data Unit, here one FRCP
packet) is present at <code>rcv_cr.rwe - RQ_SIZE</code>; any other state
(including the best-effort skip-past-gap case) returns not ready,
and <code>frcti_consume</code> is left to drop the broken prefix and re-
inspect.

=== 7.2. Fragmentation and reassembly ===

Send side (<code>flow_write_frag</code>). An SDU larger than
<code>(frag_mtu - PCI)</code> is split into <code>ceil(count / (frag_mtu - PCI))</code>
fragments; each fragment is its own FRCP packet with its own
<code>seqno</code> and a per-fragment role flag pair ([[#1.2. Flag bits|Section 1.2]]). Roles are
assigned at emit time:

{| class="wikitable"
! i !! Role
|-
| <code>n=1</code> || <code>SOLE</code>
|-
| <code>i=0</code> || <code>FIRST</code>
|-
| <code>i=n-1</code> || <code>LAST</code>
|-
| else || <code>MID</code>
|}

A mid-loop allocation or transmit failure may yield a partial
write: the call returns the bytes already enqueued (<code>off > 0</code>) or
the underlying error (<code>off == 0</code>). Best-effort flows fragment
identically; on the receiver, a partial run with a permanently-
lost fragment is dropped when a later complete SDU is visible in
the ring (see skip-past-gap below). Raw flows carry no PCI and
refuse anything larger than the layer's user MTU (<code>-EMSGSIZE</code>).

Wire-level recovery is fragment-agnostic on FRTX flows: each
fragment's <code>seqno</code> flows through SACK / RACK / RTO / NACK exactly
as for a SOLE DATA packet, and reassembly does not re-enter the
loss-detection path. Best-effort flows run the same <code>seqno</code>
machinery (DRF, FC, ACK piggyback, pre-DRF NACK emit) but queue
no <code>rxm</code> state at the sender, so a lost MID is unrecoverable;
skip-past-gap handles it (below).

Receive side. Fragments stash into <code>rq[seqno]</code> unchanged; role bits
are read only at consume time. <code>frag_run_inspect</code>, called from
<code>frcti_consume</code>, walks the ring starting at the oldest still-
undelivered <code>seqno</code> <code>base = rcv_cr.rwe - RQ_SIZE</code> (equal to <code>rcv_cr.lwe</code>
only when no partial run is in progress; during a partial run <code>lwe</code>
has already advanced past <code>base</code>). It produces one of three
outcomes:

{| class="wikitable"
! Outcome !! Cause
|-
| <code>DELIVER (n)</code>
| <code>rq[base]=SOLE</code> (<code>n=1</code>), or <code>rq[base]=FIRST</code> and a <code>LAST</code> follows in slots <code>[base+1..base+n-1]</code> with all intermediate roles in <code>{MID,FIRST,LAST}</code> contiguous.
|-
| <code>DROP (n)</code>
| <code>rq[base]</code> is <code>MID</code> or <code>LAST</code> without a preceding <code>FIRST</code> (<code>n=1</code>); a <code>FIRST..[non-LAST]..new-FIRST</code> or new-<code>SOLE</code> mid-run (drop the broken prefix with <code>n</code> = run length minus 1, so the new <code>FIRST</code>/<code>SOLE</code> stays); or, on best-effort flows, a gap at <code>base</code> with a <code>FIRST</code>/<code>SOLE</code> later in the ring (drop up to the new run start).
|-
| <code>NOT_READY</code>
| <code>rq[base]</code> absent or <code>FIRST..[non-LAST]</code> with no later <code>FIRST</code>/<code>SOLE</code> in the ring (FRTX waits for retx; best-effort waits for arrival).
|}

<code>DELIVER</code> triggers <code>frag_gather</code>: a scatter-gather <code>memcpy</code> of the <code>n</code>
consecutive fragments at <code>rq[base..base+n-1]</code> directly into the
caller's buffer; each per-packet shared-memory buffer (<code>spb</code>) is
released and <code>rwe</code> advances by <code>n</code>. <code>lwe</code> was already advanced
incrementally as each contiguous fragment arrived; <code>frag_gather</code>
only restores the fixed-width invariant <code>rwe == lwe + RQ_SIZE</code>.
No intermediate reassembly buffer is allocated.

<code>DROP</code> advances <code>rwe</code> past the broken prefix (releasing the <code>spb</code>s)
and pulls <code>lwe</code> up to the new trailing edge if needed; the next
consume retries from the new <code>base</code>. Oversize or arithmetically
overflowing delivery (sum of fragment lengths > <code>max_rcv_sdu</code>, sum
> caller's buffer, or running-sum overflow) also drops the run
with <code>-EMSGSIZE</code>.

Skip-past-gap (best-effort only). On FRTX, a gap in the run means
"waiting for retransmit" and <code>frag_run_inspect</code> returns <code>NOT_READY</code>.
On best-effort flows the gap is permanent, so <code>frag_run_inspect</code>
scans forward in the ring for the next <code>FIRST</code> or <code>SOLE</code>; if one is
visible within <code>RQ_SIZE</code>, it returns <code>DROP</code> for the broken prefix and
the consume loop retries at the new <code>lwe</code>. Memory hold is bounded
by <code>RQ_SIZE</code>; the partial releases on the next consume call once a
later complete run exists. Voice-like flows (one <code>SOLE</code> per SDU)
see no extra wait: any later <code>SOLE</code> makes the prior gap droppable
immediately.

The choice to defer reassembly to consume time keeps the receive
path zero-copy: fragments stay in the shared-memory ring until
the application pulls, and the SDU lands directly in the caller's
buffer.

== 8. Retransmission ==

FRCP is bounded by two delta-t-derived timers (Watson 1981, see
[[#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_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.

Each in-flight FRTX <code>seqno</code> owns one <code>rxm_entry</code>, armed in a hashed
timing wheel; the wheel deadline is the slot's next eligible
retransmit time.

;RTO timer
:On fire (<code>rxm_due</code>), re-emit with <code>FRCT_RXM</code>, mark <code>SND_RTX</code> (Karn-suppress next ACK's RTT sample), and (for the head-of-line (HoL) slot only) bump <code>rto_mul</code> up to <code>MAX_RTO_MUL</code>. Wheel deadline is <code>t_send + (rto << rto_mul)</code>. Re-armed unless consumed. The RTO timer also clears <code>SND_FAST_RXM</code> (re-arming fast-retransmit eligibility), resets <code>reo_wnd_mult</code> to 1 on a HoL fire (RFC 8985 sec. 6.2 step 4 reset clause), and marks the flow <code>ACL_FLOWDOWN</code> if its <code>frct_tx</code> call fails.

;r-timer guard
:Before any retransmit attempt, check <code>(now - t0)</code> against <code>t_r</code>. If exceeded, the slot is no longer eligible for retransmit. Only the RTO timer (<code>rxm_due</code>) treats r-timer expiry as terminal: it marks the flow <code>ACL_FLOWDOWN</code> (peer unreachable). Fast-retransmit, SACK-driven retransmit, and NACK-driven head-of-line re-emit silently skip aged-out slots and defer the flow-down decision to the next RTO fire.

;Fast retransmit (hybrid trigger, RFC 8985 sec. 6.2)
:On a non-advancing cumulative ACK with the scoreboard advanced, fire one fast retransmit when EITHER (a) the head-of-line slot's latest send is older than the RACK reorder window <code>R</code> ([[#3. Protocol parameters|Section 3]]) and not yet aged out, OR (b) the SACK <code>dup-thresh</code> count above <code>snd_cr.lwe</code> reaches <code>DUP_THRESH</code> (= 3, RFC 8985 sec. 6.2 step 4). Fires at most once per non-advancing cumulative-ACK value, gated by <code>rack_fired_lwe</code> (the <code>snd_cr.lwe</code> at which fast-retransmit last fired). Set <code>SND_FAST_RXM</code> on the slot (one-shot per-slot gate) and enter NewReno-style careful recovery (see NewReno below in this section).
:The RACK reorder window <code>R</code> uses the RFC 8985 sec. 6.2 form <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> with a <code>MIN_REORDER_NS = 250 us</code> floor. Before the first RTT sample seeds <code>min_rtt</code>, <code>R</code> falls back to <code>MIN(reo_wnd_mult * SRTT / 4, SRTT)</code>, still floored at <code>MIN_REORDER_NS</code> (consistent with the windowed-minimum fallback described in [[#12. RTT estimation|Section 12]]). <code>min_rtt</code> is a windowed minimum over the last <code>MIN_RTT_WIN_NS</code> = 5 min of RTT samples (matches the Linux <code>tcp_min_rtt_wlen</code> default) so a route change to a longer path eventually re-anchors the reorder window without relying on <code>reo_wnd_mult</code> growth alone.

;SACK-driven retransmit
:For each gap below <code>hi_sacked</code> whose slot is (1) still owned, (2) not already <code>SND_FAST_RXM</code>, (3) not aged out past <code>t_r</code>, and (4) either outside the RACK window <code>R</code> OR with <code>dup_thresh >= DUP_THRESH</code> (same hybrid as fast-retransmit, see [[#6.2. Locked main path|Section 6.2]]), re-emit. Each SACK-driven retransmit re-arms a fresh <code>rxm</code> so a lost retransmit can still be recovered by its own RTO timer.

;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.

== 9. Pre-DRF NACK ==

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.

;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>)
:When an incoming DATA packet has no DRF and rcv-side activity is older than <code>rcv_cr.inact</code>, the receiver emits a bare packet with <code>flags = FRCT_NACK</code> and <code>seqno = arrival_seqno - 1</code> (informational only, not consulted by the receive handler). The cooldown in [[#3. Protocol parameters|Section 3]] rate-limits the burst. Non-DATA non-DRF arrivals bypass <code>rcv_inact_check</code> entirely; non-DATA DRF still rebases via the DRF branch.

;Receive (<code>frcti_nack_rcv</code>)
: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 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.

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 ==

Cumulative ACK is <code>ackno = rcv_cr.lwe</code>. On out-of-order arrival the
receiver also emits a SACK packet ([[#1.3. SACK payload|Section 1.3]]) whose payload lists
''present'' blocks above <code>lwe</code> (analogous to TCP SACK / QUIC ACK
ranges). SACKs are rate-limited per [[#3. Protocol parameters|Section 3]] and suppressed when
neither <code>lwe</code> nor block count has changed since the last SACK.

D-SACK reports (RFC 2883) are emitted in-band as <code>block[0]</code> of an
otherwise normal SACK frame (see [[#1.3. SACK payload|Section 1.3]] for the encoding).
Two receiver triggers arm a pending D-SACK report (single-slot,
latest-wins):

* DATA arrival with <code>seqno < rcv_cr.lwe</code>, both wire-dup (no RXM, <code>is_dup_data</code> path) and retransmit (RXM, post-FC branch) (RFC 2883 sec. 4.1.1, full duplicate)
* <code>rq_accept</code> conflict, slot already occupied in <code>[lwe, rwe)</code> (RFC 2883 sec. 4.1.2, partial duplicate)

When a D-SACK is pending and the standard scoreboard SACK would be
suppressed by dedup or rate-limit, the report is emitted as a
stand-alone SACK frame through the normal <code>ack_snd</code> path; when a
D-SACK report is pending the path bypasses dedup and the <code>TICTIME</code>
rate-limit, but the a-timer suppression on rcv inactivity still
applies.

Bare ACKs are deferred via a per-flow delayed-ACK timer (one in
flight at a time, atomic test-and-set dedup; fires per [[#3. Protocol parameters|Section 3]]
after the first in-order arrival). Suppressed if (1) no new
<code>seqno</code>, (2) rcv side is inactive (older than <code>t_a</code>), or (3) the
sender just sent within <code>TICTIME</code>. A pending D-SACK ride-through
bypasses (1) and (3); the a-timer gate (2) is unconditional.

== 11. Flow control ==

The receiver advertises <code>rwe</code> in every FC field. The sender treats
its <code>snd_cr.rwe</code> as the absolute right edge: when
<code>snd_cr.seqno >= snd_cr.rwe</code> the window is closed and <code>flow_write</code>
yields. While closed, the sender periodically emits RDVS
(rendezvous) packets (cadence <code>DELT_RDV</code>); the receiver replies with
a bare FC packet (<code>ackno = 0</code>) that reopens the window. Once the
window has been closed for longer than <code>MAX_RDV</code> the sender stops
emitting RDVS but does not tear the flow down - the writer keeps
blocking until either a peer-driven FC arrives or the KA
(keepalive) / r-timer marks the flow.

<code>rwe</code> is clamped to <code>lwe + RQ_SIZE</code> on receipt and MUST NOT shrink:
a backward <code>rwe</code> is silently clamped to the current <code>snd_cr.rwe</code>;
the FC packet still reopens the window.

== 12. RTT estimation ==

Active RTTP probes ([[#1.4. RTTP payload|Section 1.4]]) carry a 32-bit <code>probe_id</code> (0
reserved) and a 16-byte random nonce echoed verbatim - defends
against spoofed replies. A ring of <code>RTTP_RING</code> in-flight probes is
kept; an echo whose <code>(id, nonce)</code> doesn't match the ring slot is
dropped. A single RTTP sample is clamped to <code>RTT_CLAMP_MUL * srtt</code>
(compile-time <code>RTT_CLAMP_MUL = 16</code>) once <code>srtt</code> is seeded; the first
cold-probe sample feeds <code>rtt_update</code> raw.

Probe arming gates:

;Cold (no <code>srtt</code> yet)
:the receive path arms at most one probe per 100 ms via <code>frcti_rcv_probe</code> (<code>PROBE_DUE_COLD</code>); arming requires an incoming packet. Active send-path arming bails while <code>srtt == 0</code>.
;Warm (<code>rtt_probe_arm</code>, called from <code>frcti_snd</code>)
:outstanding data (<code>snd_cr.seqno > snd_cr.lwe</code>), AND at least <code>2 * srtt</code> since <code>t_rcv_rtt</code> (last RTT receive of any kind), AND at least <code>srtt</code> since <code>t_snd_probe</code> (last probe emit).

Sample feeds either Linux's asymmetric <code>mdev</code> estimator
(<code>FRCT_LINUX_RTT_ESTIMATOR</code>, default ON) or RFC 6298 symmetric EWMA
(compile option). <code>srtt</code> is floored at 10 ms when seeded from a
hint, at 1 us after every update (including the first seeding
sample); <code>mdev</code> floored at 100 ns.

:<code>RTO = max(rto_min, 2 * srtt, srtt + (mdev << MDEV_MUL))</code>

(the <code>2 * srtt</code> floor is an FRCT addition not in RFC 6298).
Effective wheel deadline capped per [[#3. Protocol parameters|Section 3]].

ACK-derived samples (<code>frcti_ack_rcv</code> -> <code>rtt_sample_eligible</code>), beyond
the cum-ACK advance gate in <code>frcti_ack_rcv</code> (<code>ackno > lwe</code> and
<code>ackno <= seqno</code>), require all of: not in recovery; ACK packet does
not carry <code>FRCT_RXM</code>; HoL slot's <code>SND_RTX</code> bit clear; slot's <code>rxm</code>
pointer non-NULL (not SACK-consumed); <code>lwe</code> not below the <code>rtt_lwe</code>
fence; <code>srtt</code> already seeded by an RTTP probe. There is no ACK-only
seeding.

Every eligible sample also feeds <code>RACK.min_RTT</code> (RFC 8985 sec. 6.2)
via a windowed minimum: replace whenever the sample is strictly
smaller OR more than <code>MIN_RTT_WIN_NS</code> (5 min, matches Linux
<code>tcp_min_rtt_wlen</code>) has elapsed since the current min was set. The
downward branch is immediate (faster path picked up at once); the
upward branch is gated on the window (a transient queue burst does
not poison the estimate, but a sustained route change to a longer
path re-anchors <code>min_RTT</code> after at most one window). Seeded from
<code>rtt_hint</code> at <code>rtt_init</code>; 0 acts as the unset sentinel and the base
in <code>rack_reorder_window</code> falls back from <code>min_RTT</code> to <code>SRTT</code> (so
<code>R = mult * SRTT/4</code>, capped at <code>SRTT</code>, floored at <code>MIN_REORDER_NS</code>)
until the first sample. See [[#6.2. Locked main path|Section 6.2]].

== 13. Liveness (keepalive) ==

When <code>qs.timeout > 0</code> a per-flow KA (keepalive) timer is armed.
Arming uses <code>rcv_cr.act</code> for the deadline computation:

:<code>deadline = min(snd_act + qs.timeout/4, rcv_act + qs.timeout)</code>

(clamped to <code>now + qs.timeout/4</code> if already past). The timer fires
either on sender idleness (to send a KA) or on receiver idleness
(to declare the peer dead). On fire (<code>ka_snd</code>) the peer-dead test
uses <code>max(rcv_cr.act, t_ka_rcv)</code> so a recent KA reply counts even
when no DATA has arrived:

* If <code>now - max(rcv_cr.act, t_ka_rcv) > qs.timeout</code>, mark the flow <code>ACL_FLOWPEER</code> and notify the per-process flow-event set (<code>proc.fqset</code>) with <code>FLOW_PEER</code>.
* Else if <code>snd_idle > qs.timeout/4</code>, emit a bare <code>KA | ACK</code> (<code>ackno = rcv_cr.lwe</code>) and re-arm.
* Else just re-arm.

Note: <code>rx_rb</code> and <code>tx_rb</code> are the receive and transmit shared-memory
ring buffers. The r-timer raises <code>ACL_FLOWDOWN</code> on both (route is
broken); keepalive raises <code>ACL_FLOWPEER</code> on <code>rx_rb</code> only and notifies
the flow-event set (peer is silent, writer keeps <code>tx_rb</code> usable) -
distinct ACLs. <code>qs.timeout == 0</code> disables keepalive entirely; a
silent peer crash is then undetected.

== 14. Linger / teardown ==

On <code>flow_dealloc</code>, <code>frcti_dealloc</code> computes a grace timeout

:<code>max(rcv_cr.act + rcv_cr.inact, snd_cr.act + snd_cr.inact) - now</code>

(floored at 0 and converted to seconds) and returns it; <code>flow_dealloc</code>
forwards this to the IRMd as the dealloc grace. The IRMd, not FRCT,
performs the wait. Before computing the timeout, FRCT may emit a
final ACK when <code>rcv_cr.lwe != rcv_cr.seqno</code> (the peer has not been
told the most recent cumulative ACK) AND the rcv side has been
active within <code>t_a</code> (a-timer not aged out).

<code>FRCTFLINGER</code> is honoured only when <code>snd_cr.lwe < edge</code>, where <code>edge =
snd_fin_seqno</code> after FIN has been sent in stream mode and
<code>snd_cr.seqno</code> otherwise (data or FIN still in flight). The drain
itself runs in <code>flow_dealloc</code>'s <code>while (FRCTI_LINGERING)</code> loop, not in
<code>frcti_dealloc</code>.

The fd is single-reader / single-writer (documented in the
manpages). <code>flow_write</code> pumps <code>rx_rb</code> on every call (via
<code>flow_wait_window</code> -> <code>flow_drain_rx_nb</code>) and additionally blocks on
<code>rx_rb</code> when the send window is closed. A pure-writer thread thus
consumes ACKs without a dedicated reader.

== 15. Heritage and adopted techniques ==

Delta-t (Watson, 1981) is the primary heritage; FRCP descends from
the delta-t protocol family via the Recursive InterNetwork
Architecture (RINA; Day, "Patterns in Network Architecture", 2008,
ch. 9). Timer-based connection management
(no SYN/FIN handshake, per-flow state born on first DATA and
reclaimed after <code>t_mpl + a + r</code> of silence), the DRF marker, and the
<code>t_mpl</code> / <code>t_a</code> / <code>t_r</code> timers all come from delta-t. See Watson,
"Timer-Based Mechanisms in Reliable Transport Protocol Connection
Management", Computer Networks 5 (1981).

The unified <code>flow_alloc(name, qos, ...)</code> primitive and its
multi-axis QoS-cube argument ([[#2.2. Service modes (orthogonal axes)|Section 2.2]]) also come from RINA
(Day 2008, ch. 6; Grasa et al., "IRATI: investigating RINA as an
alternative to TCP/IP", Computer Networks 92 (2015)) - reliability,
ordering, CRC presence, and encryption are flow attributes, not
separate sockets or protocols.

The table below summarises additional adopted techniques and their
references.

{| class="wikitable"
! FRCP mechanism !! Heritage !! Reference / note
|-
| Random new <code>seqno</code> on <code>seqno_rotate</code> || TCP ISN || RFC 6528 (Gont & Bellovin, 2012). QUIC PN-space reset (RFC 9000 sec. 12.3) is a structural analogue.
|-
| Cumulative ACK, left-window-edge advance || TCP || RFC 793 / RFC 9293
|-
| Receive window with non-shrink rule || TCP || RFC 793 sec. 3.7 / RFC 9293 sec. 3.8.6; RFC 1122 sec. 4.2.2.16 for the explicit non-shrink prohibition
|-
| Modular <code>seqno</code> arithmetic (<code>before</code>/<code>after</code> helpers) || TCP || RFC 793 sec. 3.3 / RFC 9293 sec. 3.4
|-
| Selective ACK block list || TCP || RFC 2018 (Mathis et al., 1996). Encoded as a typed FRCP packet rather than a TCP option, so framing is closer to QUIC ACK frames. D-SACK (RFC 2883) carried in-band as <code>block[0]</code>; see [[#1.3. SACK payload|Section 1.3]].
|-
| NewReno-careful recovery with <code>recovery_high</code> gate || TCP || RFC 6582 (Henderson et al., 2012); QUIC builds on the same model in RFC 9002 sec. 7.3.2. Cwnd half absent (CC in IPCP).
|-
| RACK reordering window for fast retransmit || TCP || RFC 8985 (Cheng et al., 2021). FRCP <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> with a <code>MIN_REORDER_NS = 250 us</code> floor against <code>srtt</code> collapse; matches RFC 8985 sec. 6.2 and Linux <code>tcp_rack_reo_wnd</code>. DSACK-driven <code>reo_wnd_mult</code> (sec. 6.2 step 4) is adopted; see [[#1.3. SACK payload|Section 1.3]] for the wire encoding. The hybrid RACK-or-<code>DUP_THRESH</code> trigger from RFC 8985 sec. 6.2 step 4 is adopted ([[#8. Retransmission|Section 8]]). QUIC's analogue in RFC 9002 sec. 6.1.2 uses <code>max(srtt, latest_rtt)</code> as the base.
|-
| 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> = 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.
|-
| Delayed ACK with rate suppression || TCP || RFC 813 (Clark, 1982); RFC 1122 sec. 4.2.3.2; RFC 5681 sec. 4.2. Single-deadline coalescing rather than "ack-every-other-segment".
|-
| Zero-window-probe / persist-timer analogue (RDVS) || TCP || RFC 1122 sec. 4.2.2.17 / RFC 9293 sec. 3.8.6.1. RDVS solicits an FC reply, distinct from QUIC <code>DATA_BLOCKED</code> (RFC 9000 sec. 19.12), which is one-way notification. <code>MAX_RDV</code> give-up departs from TCP.
|-
| Multiplexed control on a single PCI || SCTP / QUIC || SCTP chunk bundling (RFC 9260 sec. 6.10); QUIC frame multiplexing (RFC 9000 sec. 12.4). Cleaner fit than TCP's separate-flag-bits design.
|-
| ACK ranges as multiple discontiguous acked blocks || QUIC || QUIC ACK frame (RFC 9000 sec. 19.3). FRCP SACK is conceptually QUIC-frame-shaped even though encoded as absolute <code>[start,end]</code> pairs.
|-
| Nonce-authenticated active RTT / liveness probing (RTTP) || QUIC <code>PATH_CHALLENGE</code> || <code>PATH_CHALLENGE</code> / <code>PATH_RESPONSE</code> (RFC 9000 sec. 8.2, sec. 19.17, sec. 19.18). WebRTC ICE consent-freshness (RFC 7675) is the same pattern. QUIC's nonce is 8 octets; FRCP chooses 16.
|-
| Probing distinct from keepalive || QUIC || KA timer answers "peer alive?", RTTP answers "path measurable?", as in QUIC PING (RFC 9000 sec. 19.2) vs <code>PATH_CHALLENGE</code>.
|-
| Bare KA + ACK keepalive packets || QUIC / SCTP || QUIC PING (RFC 9000 sec. 19.2); SCTP HEARTBEAT / HEARTBEAT-ACK (RFC 9260 sec. 8.3). SCTP HEARTBEAT also carries an opaque echoed blob, structurally similar to FRCP RTTP.
|-
| (<code>FFGM</code>, <code>LFGM</code>) fragment-role bits ([[#7.2. Fragmentation and reassembly|Section 7.2]]) || SCTP || RFC 9260 sec. 3.3.1 DATA chunk B/E bits encode the same four states (<code>B+E=SOLE</code>, <code>B-only=FIRST</code>, neither=<code>MID</code>, <code>E-only=LAST</code>). Each fragment carries its own <code>seqno</code>/TSN and is independently retransmitted.
|-
| Stream byte-offset reassembly (Sections [[#1.5. Stream PCI extension|1.5]], [[#16. Stream-mode flows|16]]) || QUIC || QUIC STREAM frame (RFC 9000 sec. 19.8) uses Offset + Length varints; FRCP uses fixed 32-bit <code>start</code> / <code>end</code>. One stream per flow vs QUIC's many streams multiplexed.
|-
| FIN end-of-stream marker (Sections [[#1.2. Flag bits|1.2]], [[#16. Stream-mode flows|16]]) || TCP / QUIC || TCP FIN flag (RFC 9293 sec. 3.1) closes one half of the byte stream; QUIC STREAM frame FIN bit (RFC 9000 sec. 19.8) does the same per stream with an immutable final-size invariance (RFC 9000 sec. 4.5: the final size is fixed once observed). FRCP's FIN consumes one packet <code>seqno</code> (not one byte of stream space) and is idempotent on the sender side.
|-
| Stream byte-credit flow control ([[#16. Stream-mode flows|Section 16]]) || QUIC || <code>MAX_STREAM_DATA</code> (RFC 9000 sec. 4.1, sec. 19.10). FRCP projects a per-flow byte budget onto the <code>seqno</code>-space <code>rwe</code>. Single stream per flow collapses QUIC's <code>MAX_DATA</code> / <code>MAX_STREAM_DATA</code> distinction.
|-
| Header protection (encrypted seqnos) || QUIC || QUIC RFC 9001 sec. 5.4 applies header protection on top of AEAD to mask the packet number. FRCP's per-flow AEAD wrap ([[#16. Stream-mode flows|Section 16]]) is wider: it encrypts the entire PCI including <code>seqno</code> because the IPCP below already routes, so no destination connection-ID needs to stay in clear (cf. RFC 9000 sec. 5.2).
|-
| Two-bit fragment role polarity || SCTP || The (<code>FFGM</code>, <code>LFGM</code>) pair follows SCTP B/E (begin = 1 / end = 1) rather than IPv4 MF (RFC 791 sec. 3.2), which has the inverse polarity (MF = 1 means NOT last).
|-
| Orthogonal reliability / ordering axes ([[#2.2. Service modes (orthogonal axes)|Section 2.2]]) || SCTP || PR-SCTP (RFC 3758, per-message partial reliability) and SCTP DATA U-bit (RFC 9260 sec. 3.3.1, per-message unordered) are the closest precedents for decoupling reliability from ordering; FRCP sets them per-flow rather than per-message.
|-
| Orthogonal CRC (<code>qs.ber == 0</code>) || UDP-Lite || RFC 3828 (Larzon et al., 2004) lets the sender pick a per-packet Checksum Coverage and the receiver enforce a locally configured minimum (no in-band negotiation; sec. 3.1, sec. 3.3). FRCP gates a full CRC trailer on <code>qs.ber == 0</code> at flow setup. Contrast TCP / SCTP (mandatory checksum) and QUIC (AEAD subsumes CRC).
|-
| Setup-time service negotiation || DCCP / SCTP / QUIC || DCCP Service Codes (RFC 4340 sec. 8.1.2, RFC 5595); SCTP INIT parameters (RFC 9260 sec. 3.3.2); QUIC transport parameters (RFC 9000 sec. 7.4). All negotiate service properties at connection setup; only RINA's QoS cube exposes them as an orthogonal vector.
|}

=== 15.1. Original to FRCP (no clean prior art) ===

* Pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]): receiver-driven nudge exploiting <code>snd_cr.inact > rcv_cr.inact</code>. Closest analogues are SCTP Gap Ack Blocks (RFC 9260 sec. 3.3.4) and DCCP Ack Vector (RFC 4340 sec. 11.4) - both let the receiver describe gaps to the sender, but neither targets the cross-epoch / pre-DRF case.
* <code>MAX_RDV</code> window-probe give-up: neither TCP (persist-timer probes until application or R2 abort, RFC 9293 sec. 3.8.6.1) nor QUIC has an explicit FC-give-up counter. A recursive-network choice: outer layers can drop the flow.
* Skip-past-gap reassembly ([[#7.2. Fragmentation and reassembly|Section 7.2]]): SCTP fragments and reassembles every flow regardless of reliability/ordering, using its own per-stream reassembly queue; QUIC fragments via STREAM offsets. FRCP fragments best-effort flows too, but the receiver drops the broken prefix the moment a later run-start (<code>FIRST</code> or <code>SOLE</code> role) is visible inside the <code>RQ_SIZE</code>-wide reorder ring - no IP-frag-style timeout, no SCTP-style explicit abort. If no later run-start arrives within the ring, <code>frag_run_inspect</code> returns <code>NOT_READY</code> and the partial run keeps its slots; the next inspect retries. The trade-off: a permanently-lost <code>MID</code> in a long isolated run holds slots until either a later <code>FIRST</code>/<code>SOLE</code> appears in the ring or the writer stops, at which point the slots are reclaimed on flow teardown.
* Reassembly deferred to consume time ([[#7.2. Fragmentation and reassembly|Section 7.2]]), message mode only (<code>qos.service == SVC_MESSAGE</code>): SCTP (RFC 9260 sec. 6.9), QUIC (RFC 9000 sec. 2.2), and TCP (RFC 9293) all hold reassembly state at the receive boundary. FRCP message-mode leaves fragments in the shared-memory ring until <code>flow_read</code> pulls and lands the SDU directly in the caller's buffer. Stream mode ([[#16. Stream-mode flows|Section 16]]) uses the standard QUIC-style direct ring placement on receive and does not defer. The optimisation is enabled by the Shared-Memory Subsystem (SSM) packet-buffer ring (see <code>struct ssm_pk_buff</code> at [[#1.1. PCI header|Section 1.1]]); the analogue is OS-level scatter-gather I/O (<code>recvmsg+iovec</code>), not a transport-layer prior art.
* TLP-equivalent tail-loss recovery (RFC 8985 sec. 7; RFC 9002 sec. 6.2): FRCP does not emit an explicit Tail Loss Probe packet, but the same goal is met implicitly by RACK loss detection ([[#8. Retransmission|Section 8]]) firing on a non-advancing cumulative ACK once the head-of-line slot ages past the RACK reorder window <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> - well below <code>RTO = max(2 * SRTT, SRTT + (mdev << MDEV_MUL))</code>. A receiver-driven nudge is also available via the pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]).

=== 15.2. Not adopted ===

* Slow start, congestion window (cwnd), Additive Increase / Multiplicative Decrease (AIMD), NewReno cwnd inflation. Congestion control lives in the IPCP CA policies and is driven by Explicit Congestion Notification (ECN, RFC 3168).
* Nagle / silly-window-syndrome (SWS) avoidance (RFC 896, RFC 1122 sec. 4.2.3.4). (Deferred work, not adopted in the current spec.)
* TCP Timestamps (RFC 7323) / Protection Against Wrapped Sequences (PAWS) - RTT measurement uses RTTP, not per-segment timestamps. A peer-supplied timestamp echoed on every ACK lets a malicious peer drive the <code>srtt</code> estimate arbitrarily low, collapsing the RTO and triggering a self-inflicted retransmit storm. RTTP confines RTT measurement to nonce-authenticated probe round-trips, where a forged echo is rejected before it can reach the estimator.
* ECN (Explicit Congestion Notification) response inside FRCP (consumed by IPCP Congestion Avoidance / CA).
* 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).

== 16. Stream-mode flows ==

When a flow is allocated with <code>qos.service == SVC_STREAM</code> both peers
switch to byte-stream semantics, layered on top of the FRTX reorder
machinery already described in Sections [[#6. Receive path|6]]-[[#8. Retransmission|8]].

=== 16.1. Send ===

The sender splits the caller's octets into chunks of at most
<code>(frag_mtu - base PCI - stream PCI extension)</code> octets (Sections [[#1.1. PCI header|1.1]]
and [[#1.5. Stream PCI extension|1.5]]). Each chunk is one DATA packet with its own <code>seqno</code> and a
<code>[start, end)</code> byte range copied from a monotonic stream counter.
In stream mode <code>FFGM</code> and <code>LFGM</code> are unused and MUST be transmitted as
zero; the per-byte position is carried by the <code>[start, end)</code>
extension instead.

End-of-stream is signalled with a 0-byte DATA packet that has <code>FIN</code>
(bit 12) set, emitted on the FIN triggers listed in [[#1.2. Flag bits|Section 1.2]]
(WR-half close, <code>flow_dealloc</code>, and any other path that yields the
final byte). The sender MUST emit at most one FIN per flow; its
<code>[start, end)</code> MUST equal <code>[final-byte, final-byte)</code> (i.e., empty
interval at the final byte position; final-size invariance,
analogous to QUIC RFC 9000 sec. 4.5). Idempotency is enforced by
an <code>snd_fin_sent</code> guard.

=== 16.2. Receive ===

On arrival the receiver places the payload directly into a per-flow
byte-indexed receive ring of width <code>ring_sz</code> (octets) at the position
indicated by <code>start</code>, with a two-segment <code>memcpy</code> across the ring
boundary if needed. Receipt is recorded in the FRTX reorder
machinery ([[#6.2. Locked main path|Section 6.2]]) augmented with the packet's <code>start</code>, <code>end</code>, and
FIN bit per slot. When a packet's <code>[start, end)</code> front-overlaps
bytes already at or below the byte high-water mark, the overlap is
trimmed before placement so the same byte is never written twice.
After stashing, the receiver advances <code>lwe</code> and the byte high-water
mark across any newly-contiguous prefix. Each slot advanced MUST
satisfy <code>start == the last-delivered slot's end</code>; a slot whose
<code>start</code> does not equal that <code>end</code> is silently dropped at delivery time
(the <code>seqno</code> is consumed, no stream bytes contributed) and the high-
water mark does not advance past it. The stream byte-stream
stalls at that point - there is no flow-tear-down on mismatch.
This filters spliced or off-path-injected slots that fall in
window without strong cryptographic authentication.

A FIN slot marks end-of-stream at advance time only if its byte
position equals the last-delivered slot's <code>end</code>; otherwise the FIN
is ignored and the corresponding <code>seqno</code> occupies a slot but
contributes no stream bytes. No packet buffer is held after the
ring copy.

=== 16.3. Read ===

<code>flow_read</code> returns up to <code>count</code> octets from the contiguous prefix
<code>[next, high-water)</code>, where <code>next</code> is the byte the application has
already consumed up to and <code>high-water</code> is the rightmost contiguous
byte received. When the stream is fully drained AND end-of-stream
(EOS) was observed (<code>next == EOS</code> byte position), <code>flow_read</code> returns
0 (<code>EOF</code>) - the same shape POSIX <code>read(2)</code> uses on TCP after a peer
FIN.

=== 16.4. Flow control ===

ACK / SACK / RACK / RTO machinery is unchanged; the FRTX reorder
ring is reused as a per-<code>seqno</code> received-bitmap. Let <code>per_pkt =
(frag_mtu - base PCI - stream PCI extension)</code>, the maximum stream-
byte payload one DATA packet can carry ([[#16.1. Send|Section 16.1]]). The
receive window advertised in FC is clamped so the byte window
(<code>ring_sz</code>) cannot be overrun: the <code>seqno</code>-space <code>rwe</code> is at most
<code>rcv_cr.lwe + ring_sz / per_pkt</code>.

This is the QUIC byte-credit flow-control model
(<code>MAX_STREAM_DATA</code>, RFC 9000 sec. 4.1 and sec. 19.10) projected onto
<code>seqno</code> space. With one stream per flow there is no <code>MAX_DATA</code> /
<code>MAX_STREAM_DATA</code> distinction. Receiver-side silly-window-syndrome
(SWS) avoidance (RFC 9293 sec. 3.8.6.2.2) is achieved by combining
the consume-time <code>rwe</code> bump with the global non-shrink rule from
[[#11. Flow control|Section 11]].

=== 16.5. Security considerations ===

Threat model. An attacker that can observe (on-path passive) or
predict (off-path blind) the flow's seqnos and byte offsets on an
unencrypted stream flow can inject DATA or FIN at any in-window
position. The in-line consistency checks above (<code>start</code> == prior
<code>end</code> on advance; FIN MUST be 0-byte; FIN MUST sit at the final
byte position) realise the spirit of RFC 5961's "sequence-window
plus exact-position match for control bits" without an explicit
challenge-ACK probe; they make a few specific blind attack shapes
harder but are not cryptographic authentication. This is
comparable to TCP without the TCP Authentication Option (TCP-AO,
RFC 5925), tighter than a
pre-RFC-5961 TCP stack, and roughly equivalent to a modern
RFC 5961 stack against blind off-path injection - none of these
help once the attacker can sniff. TLS over TCP (RFC 8446)
encrypts only the TCP payload and leaves TCP seqnos, ACKs, FIN,
and RST in the clear, so TLS does NOT defend against TCP-header-
level injection; QUIC (RFC 9000) hides packet numbers under
header protection (RFC 9001 sec. 5.4), so this specific weakness
does not apply to QUIC.

Mitigation: AEAD. When the flow has encryption enabled the
recommended AEAD ciphers (AES-GCM, RFC 5288; or ChaCha20-Poly1305,
RFC 8439) wrap the entire FRCP packet on the wire - PCI, stream
extension, body, and the CRC trailer when <code>ber == 0</code> - under a
per-flow symmetric key derived from the flow's own key exchange
([[#1.1. PCI header|Section 1.1]]). The AEAD tag (~2^-128 forgery probability)
dominates the CRC (~2^-32) for integrity in this mode but the CRC
trailer is currently retained inside the wrap (see [[#1.1. PCI header|Section 1.1]]).
Implementations MUST NOT rely on the security properties below
when a non-AEAD cipher (e.g. AES-CTR alone) is negotiated; non-
AEAD modes provide confidentiality only and the threat-model
claims do not hold.

With an AEAD cipher in use, seqnos, byte offsets, and the FIN bit
are both authenticated and confidential. Against an off-path or
on-path-passive attacker this is:

* Stronger than TCP+TLS (TCP header in the clear).
* Stronger than TCP+TCP-AO (header authenticated but visible).
* 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. 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 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
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 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 ==

This section lists the IETF documents, published works, and
source-code references cited inline elsewhere in this document.
IETF documents are cited inline as "RFC NNNN sec. X.Y"; books,
journal papers, and source-code references are cited inline by
author and year (or by file and function name) and are listed
here for convenience.

=== 17.1. IETF documents ===

;[RFC 791]
:J. Postel, "Internet Protocol", STD 5, RFC 791, September 1981.
;[RFC 793]
:J. Postel, "Transmission Control Protocol", STD 7, RFC 793, September 1981. Obsoleted by RFC 9293.
;[RFC 813]
:D. D. Clark, "Window and Acknowledgement Strategy in TCP", RFC 813, July 1982.
;[RFC 896]
:J. Nagle, "Congestion Control in IP/TCP Internetworks", RFC 896, January 1984.
;[RFC 1122]
:R. Braden (ed.), "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
;[RFC 2018]
:M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
;[RFC 2119]
:S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
;[RFC 2883]
:S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
;[RFC 3758]
:R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
;[RFC 3828]
:L-A. Larzon, M. Degermark, S. Pink, L-E. Jonsson (ed.), G. Fairhurst (ed.), "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
;[RFC 4303]
:S. Kent, "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
;[RFC 4340]
:E. Kohler, M. Handley, S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
;[RFC 5288]
:J. Salowey, A. Choudhury, D. McGrew, "AES Galois Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, August 2008.
;[RFC 5595]
:G. Fairhurst, "The Datagram Congestion Control Protocol (DCCP) Service Codes", RFC 5595, September 2009.
;[RFC 5681]
:M. Allman, V. Paxson, E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
;[RFC 5925]
:J. Touch, A. Mankin, R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
;[RFC 5961]
:A. Ramaiah, R. Stewart, M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, August 2010.
;[RFC 6298]
:V. Paxson, M. Allman, J. Chu, M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, June 2011.
;[RFC 6528]
:F. Gont, S. Bellovin, "Defending against Sequence Number Attacks", RFC 6528, February 2012. Obsoletes RFC 1948.
;[RFC 6582]
:T. Henderson, S. Floyd, A. Gurtov, Y. Nishida, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 6582, April 2012.
;[RFC 7323]
:D. Borman, B. Braden, V. Jacobson, R. Scheffenegger (ed.), "TCP Extensions for High Performance", RFC 7323, September 2014.
;[RFC 7675]
:M. Perumal, D. Wing, R. Ravindranath, T. Reddy, M. Thomson, "Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness", RFC 7675, October 2015.
;[RFC 8174]
:B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017.
;[RFC 8200]
:S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, July 2017.
;[RFC 8439]
:Y. Nir, A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 8439, June 2018.
;[RFC 8446]
:E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, August 2018.
;[RFC 8985]
:Y. Cheng, N. Cardwell, N. Dukkipati, P. Jha, "The RACK-TLP Loss Detection Algorithm for TCP", RFC 8985, February 2021.
;[RFC 9000]
:J. Iyengar (ed.), M. Thomson (ed.), "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, May 2021.
;[RFC 9001]
:M. Thomson (ed.), S. Turner (ed.), "Using TLS to Secure QUIC", RFC 9001, May 2021.
;[RFC 9002]
:J. Iyengar (ed.), I. Swett (ed.), "QUIC Loss Detection and Congestion Control", RFC 9002, May 2021.
;[RFC 9147]
:E. Rescorla, H. Tschofenig, N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, April 2022.
;[RFC 9260]
:R. Stewart, M. Tuexen, K. Nielsen, "Stream Control Transmission Protocol", RFC 9260, June 2022. Obsoletes RFC 4960.
;[RFC 9293]
:W. Eddy (ed.), "Transmission Control Protocol (TCP)", STD 7, RFC 9293, August 2022. Obsoletes RFC 793 and several follow-ons; updates RFC 1122 and others.

=== 17.2. Books and journal papers ===

;[Day08]
:J. Day, "Patterns in Network Architecture: A Return to Fundamentals", Prentice Hall, 2008.
;[Grasa15]
:E. Grasa et al., "IRATI: investigating RINA as an alternative to TCP/IP", Computer Networks, Vol. 92, December 2015.
;[KP87]
:P. Karn, C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", ACM SIGCOMM, August 1987.
;[Wat81]
:R. W. Watson, "Timer-Based Mechanisms in Reliable Transport Protocol Connection Management", Computer Networks, Vol. 5, 1981.

=== 17.3. Source-code references ===

;[Linux-RTT]
:<code>tcp_rtt_estimator()</code> in <code>net/ipv4/tcp_input.c</code> of the Linux kernel, defining the asymmetric <code>mdev</code> variance update used as FRCP's default RTT estimator ([[#12. RTT estimation|Section 12]]). Line-stable browseable copy at https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_input.c.

[[Category:Protocols]]
[[Category:Ouroboros internals]]

Flow and Retransmission Control Protocol

2026-05-18T01:04:52Z

Dimitri: /* 1.1. PCI header */

{{DISPLAYTITLE:FRCP - Flow and Retransmission Control Protocol}}

FRCP runs end-to-end between two peers over a flow. It delivers
reliability, in-order delivery, flow control, and liveness.
Congestion Control (CC) is not in FRCP - that lives in the IPC
Process (IPCP) Congestion Avoidance (CA) policies, orthogonal to
FRCP. Flow allocation, naming, and IPCP lifecycle are handled by
the IPC Resource Manager daemon (IRMd).

FRCT (Flow and Retransmission Control Task) is the libouroboros
implementation of FRCP; the task lives in <code>src/lib/frct.c</code>. The
remainder of this document describes the FRCP wire protocol and the
behaviour FRCT realises. Code symbols retain the <code>FRCT_</code> prefix
(<code>FRCT_DATA</code>, <code>FRCT_RXM</code>, ...) because they belong to the implementing
task; this document references them verbatim.

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in <code>BCP</code> 14 (Best
Current Practice; RFC 2119, RFC 8174) when, and only when, they
appear in all capitals.

== Notation ==

;<code>u32</code>, <code>u8</code>
:Unsigned 32-bit / 8-bit integers (kernel-C style).
;<code>ns</code>
:Nanoseconds.

Modular sequence-number comparators (32-bit, modulo 2^32):

;<code>before(a, b)</code>
:<code>(int32_t)(a - b) < 0</code>
;<code>after(a, b)</code>
:<code>before(b, a)</code>

Used throughout for <code>ackno</code> / <code>seqno</code> ordering checks.

Round-Trip Time (RTT) abbreviations used throughout:

;<code>SRTT</code>
:Smoothed RTT estimate (RFC 6298).
;<code>mdev</code>
:Mean deviation of RTT (Linux variance estimator).
;<code>EWMA</code>
:Exponentially Weighted Moving Average.
;<code>RTO</code>
:Retransmission Timeout, <code>max(RTO_MIN, srtt + (mdev << MDEV_MUL))</code>.

Timer-bound symbols <code>t_a</code> (a-timer, ACK delay) and <code>t_r</code> (r-timer,
retransmission window) are defined in [[#8. Retransmission|Section 8]]; <code>t_mpl</code> (Maximum
Packet Lifetime) is introduced in [[#2.1. Per-flow state|Section 2.1]] (the <code>inact</code> field)
with heritage in [[#15. Heritage and adopted techniques|Section 15]].

Wire-format diagrams follow the IETF convention: bit 0 is the
leftmost (most significant) bit and fields are in network byte
order unless stated otherwise.

__TOC__

== 1. Wire format ==

=== 1.1. PCI header ===

Fixed 16-octet base Protocol-Control Information (PCI) header
prefixed to every FRCP packet (RFC convention: bit 0 leftmost,
most-significant bit first). All multi-byte fields are in network byte order. DATA packets on
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
base PCI.

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | hcs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ackno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload (variable) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>flags</code>
:feature/type bitmap (see [[#1.2. Flag bits|Section 1.2]]).
;<code>hcs</code>
:CRC-16-CCITT-FALSE Header Check Sequence (HCS) over <code>flags</code> + <code>window</code> + <code>seqno</code> + <code>ackno</code> (+ stream extension when present); the two octets of the <code>hcs</code> field itself are omitted from the CRC input. Verified on receive before any flag-driven dispatch.
;<code>window</code>
:receiver-advertised right window edge (valid iff FC).
;<code>seqno</code>
:per-flow sequence number.
;<code>ackno</code>
:cumulative Acknowledgement (ACK) (valid iff ACK).

A single packet can simultaneously carry DATA + ACK + FC (Flow
Control) + RXM (Retransmission) by ORing flag bits; the PCI
multiplexes control on the same wire frame in the spirit of SCTP
chunk bundling (RFC 9260 sec. 6.10) and QUIC frame multiplexing
(RFC 9000 sec. 12.4). DATA-bearing packets carry the caller's
payload after the PCI; SACK (Selective Acknowledgement) and RTTP
(Round-Trip Time Probe) carry their own typed payloads after the
PCI.

Optional framing (per-flow, see [[#2.2. Service modes (orthogonal axes)|Section 2.2]]). On the wire, the
order from inside out is:

{| class="wikitable"
! Layer !! Scope
|-
| <code>[ PCI + body ]</code>
| The FRCP packet.
|-
| <code>[ PCI + body + CRC-32 ]</code>
| CRC-32 covers the body only (PCI is in HCS); appended iff <code>qs.ber == 0</code> on DATA, or on every SACK packet.
|-
| <code>[ AEAD-wrap of above ]</code>
| Iff Authenticated Encryption with Associated Data (AEAD) is enabled.
|}

* 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.
* 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>).

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

=== 1.2. Flag bits ===

Flag bits are numbered most-significant-bit first to match the wire
diagram (bit numbering per [[#1.1. PCI header|Section 1.1]]; bit 0 is the MSB of the
16-bit <code>flags</code> field and lands at wire-position 0 in network byte
order). Bits 13..15 are reserved and MUST be transmitted as zero.

{| class="wikitable"
! Bit !! Mask !! Name !! Meaning
|-
| 0 || <code>0x8000</code> || <code>DATA</code> || Carries caller payload
|-
| 1 || <code>0x4000</code> || <code>DRF</code> || Data Run Flag: start of a fresh run
|-
| 2 || <code>0x2000</code> || <code>ACK</code> || Acknowledgement: <code>ackno</code> field valid
|-
| 3 || <code>0x1000</code> || <code>NACK</code> || Negative ACK; <code>seqno = arrival_seqno-1</code>
|-
| 4 || <code>0x0800</code> || <code>FC</code> || Flow Control: <code>window</code> field valid (<code>rwe</code>)
|-
| 5 || <code>0x0400</code> || <code>RDVS</code> || Rendezvous probe (window-closed)
|-
| 6 || <code>0x0200</code> || <code>FFGM</code> || First Fragment (role bit 0; see below)
|-
| 7 || <code>0x0100</code> || <code>LFGM</code> || Last Fragment (role bit 1; see below)
|-
| 8 || <code>0x0080</code> || <code>RXM</code> || Retransmission
|-
| 9 || <code>0x0040</code> || <code>SACK</code> || Selective ACK block list in payload
|-
| 10 || <code>0x0020</code> || <code>RTTP</code> || RTT Probe / echo (payload follows)
|-
| 11 || <code>0x0010</code> || <code>KA</code> || Keepalive
|-
| 12 || <code>0x0008</code> || <code>FIN</code> || End-of-stream marker (stream mode)
|-
| 13-15 || -- || -- || Reserved (MUST be zero)
|}

The (<code>FFGM</code>, <code>LFGM</code>) pair encodes the fragment role of a DATA-bearing
Service Data Unit (SDU), SCTP-style begin/end flags (RFC 9260
sec. 3.3.1):

{| class="wikitable"
! FFGM !! LFGM !! Role
|-
| 1 || 1 || Sole / un-fragmented SDU (begin AND end)
|-
| 1 || 0 || First fragment of a multi-fragment SDU
|-
| 0 || 0 || Middle fragment
|-
| 0 || 1 || Last fragment
|}

Each fragment is carried in its own FRCP packet with its own <code>seqno</code>;
FRTX (the FRCT Retransmission service mode, see [[#2.2. Service modes (orthogonal axes)|Section 2.2]])
recovers individual fragments via the normal Retransmission Timeout
(RTO) / SACK / Recent Acknowledgement (RACK, RFC 8985) path. The
receiver reassembles the SDU at consume time once the contiguous
[FIRST .. LAST] run has fully arrived. On non-DATA packets the role
bits are unused and MUST be transmitted as zero.

In stream mode (<code>qos.service == SVC_STREAM</code>, see [[#16. Stream-mode flows|Section 16]]) there are
no SDU boundaries to encode, so <code>FFGM</code> and <code>LFGM</code> are unused and MUST
be transmitted as zero. End-of-stream uses a dedicated bit (<code>FIN</code>,
bit 12) carried on a 0-byte DATA packet, emitted at write-half close
(<code>fccntl</code> to <code>FLOWFRDONLY</code>), during linger drain, and at <code>flow_dealloc</code>;
emission is idempotent (first call wins). After contiguous delivery
of the FIN-bearing slot, the receiver latches <code>byte_fin</code> at the FIN's
start offset; <code>flow_read</code> returns 0 (end-of-file, <code>EOF</code>) once buffered
bytes have been drained up to <code>byte_fin</code>. Per-byte position is
carried by the [start, end) extension ([[#1.5. Stream PCI extension|Section 1.5]]).

=== 1.3. SACK payload ===

A SACK packet has the <code>FRCT_ACK | FRCT_FC | FRCT_SACK</code> flag bits set
(bit numbering per [[#1.1. PCI header|Section 1.1]]). Following the 16-octet PCI, the
payload is a 2-octet block count (network byte order), 2 octets of
padding to 4-byte align the block list, then <code>n_blocks</code> pairs of
32-bit start/end seqnos describing ''present'' (received) ranges
above the cumulative ACK.

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_blocks | padding (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start[0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end[0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... n_blocks pairs total ...
</syntaxhighlight>

<code>n_blocks <= SACK_MAX_BLOCKS</code> (2048). The per-flow effective cap is
further bounded by <code>(frag_mtu - PCI - 4) / 8</code> blocks per packet; SACK
packets carry no stream extension, so PCI here is the 16-octet base
header even on stream-mode flows.

Wire invariant: every block produced by the receiver, except an
optional leading Duplicate SACK (D-SACK) block as described below,
describes a range strictly above the cumulative ACK carried in the
PCI <code>ackno</code> field (<code>after(start[i], ackno)</code>). This makes the D-SACK
convention below unambiguous; the receiver-side builder MUST
preserve it.

Duplicate SACK (D-SACK, RFC 2883) is signalled in-band: no flag
bit, no extra framing. Modular seqno arithmetic uses the
<code>before()</code> / <code>after()</code> comparators defined in the Notation block.

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)
:<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)
:<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.

The <code>reo_wnd_mult</code> halving cadence (once per 16 cumulatively-ACK'd
seqnos since the most-recent D-SACK arrival or halve event) and
the reset-to-1 on a HoL RTO fire are both per the same RFC 8985
clause. The clamp-and-skip path in the regular SACK-mark loop is
incidentally idempotent on any leftover case-1 or case-2 block
(<code>start < snd_cr.lwe</code> clamps to <code>snd_cr.lwe</code> and the inner loop
skips <code>k == snd_cr.lwe</code>; case-2 re-NULLs slots already marked
received by later blocks), so block[0] is harmless even when fed
to the loop.

=== 1.4. RTTP payload ===

An RTTP (Round-Trip Time Probe) packet has only the <code>FRCT_RTTP</code> flag
set (bit numbering per [[#1.1. PCI header|Section 1.1]]). Following the 16-octet PCI,
the payload is 24 octets (packed):

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| probe_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| echo_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ nonce (16 octets, echoed verbatim) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>probe_id</code>
:sender counter, 0 on reply, 0 reserved.
;<code>echo_id</code>
:peer's <code>probe_id</code>, 0 on outbound probe.
;<code>nonce</code>
:random, echoed unmodified, memcmp'd to defeat spoof.

=== 1.5. Stream PCI extension ===

A stream-mode flow (<code>qos.service == SVC_STREAM</code>) carries an extra
8-octet extension after the 16-octet base PCI on every DATA packet
(bit numbering per [[#1.1. PCI header|Section 1.1]]):

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>start</code>
:octet offset of the first payload byte in the stream.
;<code>end</code>
:octet offset one past the last payload byte; <code>end - start</code> equals the on-wire payload length.

Total stream-mode PCI for DATA packets is 24 octets (16 base + 8
extension); control packets (SACK, RTTP, bare ACK, KA, etc.) retain
the 16-octet base PCI. Stream mode MUST be negotiated at flow
allocation; the extension is present iff stream mode is in use,
never on a per-packet basis. Both peers MUST treat <code>start</code>/<code>end</code> as
monotonic 32-bit byte offsets; when a slot reaches the head of the
contiguous run with <code>start</code> not equal to the prior packet's <code>end</code> the
slot is silently dropped at delivery time ([[#16. Stream-mode flows|Section 16]]) rather
than rejected at stash.

This is the QUIC STREAM-frame reassembly model (RFC 9000 sec. 19.8):
each packet carries its packet <code>seqno</code> (this PCI's <code>seqno</code> field) and a
separate stream byte position (<code>start</code>/<code>end</code>). Separating the two
avoids TCP's conflation of packet identity with byte position which
forces Karn's algorithm for Round-Trip Time (RTT) sampling (no RTT
sample on retransmits, RFC 6298 sec. 3); FRCP applies the
Karn-equivalent gate via a combination of per-packet <code>FRCT_RXM</code>,
per-slot <code>SND_RTX</code> flags, and a sample-fence <code>rtt_lwe</code> (see [[#2.1. Per-flow state|Section 2.1]]
and [[#12. RTT estimation|Section 12]]). FRCP's fixed-32-bit <code>start</code>/<code>end</code> wrap at 4 GiB of
wire bytes, narrower than QUIC's 62-bit varint offset (cf. RFC 9000
sec. 16); the on-wire wrap is handled by the same modular <code>before()</code>
/ <code>after()</code> comparators ([[#1.3. SACK payload|Section 1.3]]) FRCP uses for seqnos, which
remain unambiguous as long as the in-flight byte window stays
strictly under 2 GiB (the half-range of the signed-int32 difference
in <code>before()</code>). The default per-flow ring is 1 MiB; the
implementation caps <code>ring_sz</code> at 128 MiB (<code>FRCT_STREAM_RING_SZ_MAX</code>),
well below the 2 GiB half-range bound. The runtime byte counters
exposed via FUSE (Filesystem in Userspace) in the Ouroboros
Resource Information Base (RIB, a virtual-filesystem introspection
bridge) are platform <code>size_t</code> and do not wrap on 64-bit hosts.

== 2. Per-flow state and service modes ==

=== 2.1. Per-flow state ===

Each flow keeps a sender control record and a receiver control
record:

;<code>lwe</code> : <code>u32</code>
:snd: oldest unacked <code>seqno</code> (cumulative ACK boundary as seen by sender); rcv: next in-order <code>seqno</code> expected
;<code>rwe</code> : <code>u32</code>
:snd: peer-advertised right window edge; rcv: locally-advertised right window edge
;<code>cflags</code> : <code>u8</code>
:per-direction feature flags: retransmission (<code>FRCTFRTX</code>), receiver flow control (<code>FRCTFRESCNTL</code>), linger-on-close (<code>FRCTFLINGER</code>); see <code><ouroboros/fccntl.h></code>
;<code>seqno</code> : <code>u32</code>
:snd: next <code>seqno</code> to send; rcv: force-ACK trigger - set on a stale or dup DATA so the next <code>ack_snd</code> emits a fresh cumulative ACK
;<code>ackno</code> : <code>u32</code>
:snd: <code>seqno</code> counter for standalone ACK-bearing control packets (delayed ACK, SACK, final ACK on dealloc); not bumped on piggybacked ACK riding a DATA packet (which uses the DATA <code>seqno</code>). Used by wire-dup ACK detection; rcv: incoming-ACK dedup tracker
;<code>act</code> : <code>ns</code>
:last activity (used by inactivity / DRF)
;<code>inact</code> : <code>ns</code>
:inactivity threshold; sender = <code>3*mpl + a + r + 1s</code>, receiver = <code>2*mpl + a + r + 1s</code>. <code>mpl</code> is the Maximum Packet Lifetime (delta-t terminology; see [[#15. Heritage and adopted techniques|Section 15]]); <code>a</code> and <code>r</code> are the FRCT a-timer and r-timer bounds (see [[#8. Retransmission|Section 8]]). The asymmetry is load-bearing for pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]).

The sender holds a per-slot ring <code>snd_slots[RQ_SIZE]</code> keyed by
<code>(seqno mod RQ_SIZE)</code>. Each slot tracks its retransmit entry (<code>rxm</code>),
last-send timestamp, and retransmit flag bits: <code>SND_RTX</code> (a
retransmit is pending or has fired, gates the next RTT sample
under Karn) and <code>SND_FAST_RXM</code> (one-shot fast-retransmit staged for
this loss event).

The receiver holds a parallel reorder ring <code>rcv_slots[RQ_SIZE]</code>
(referred to as <code>rq[]</code> in prose) holding stashed out-of-order
packet-buffer indexes; both FRTX and best-effort flows share this
path. The invariant <code>rwe - lwe <= RQ_SIZE</code> holds: on each consume
the receiver advances <code>rwe</code> by the consumed count, capping the
receive window at <code>RQ_SIZE</code> <code>seqno</code> slots.

A separate fence variable <code>rtt_lwe</code> is bumped on every retransmit
(timer-fire, SACK-driven, fast-rxm, NACK-driven) and on every
<code>seqno_rotate</code> ([[#4. Sequence-number rotation (DRF)|Section 4]]) to mark the <code>seqno</code> range whose RTT samples
MUST be discarded.

=== 2.2. Service modes (orthogonal axes) ===

FRCP exposes its wire features as a vector of independent QoS
axes selected at flow allocation time. All flows go through the
same <code>flow_alloc(name, qos, ...)</code> primitive; the <code>qosspec_t</code> passed
in determines which protocol machinery engages on the wire. This
contrasts with the POSIX BSD socket model where TCP and UDP
require different socket types (<code>SOCK_STREAM</code> / <code>SOCK_DGRAM</code>).

The axes:

;<code>service</code>
:0 = unordered (no FRCP engagement: raw datagrams, no PCI on the wire, UDP-equivalent at this layer); 1 = message-ordered (FRCP engaged; SDU boundaries preserved across fragmentation); 2 = stream (byte-oriented, no SDU boundaries; FRTX required)
;<code>loss</code>
:0 = lossless service requested: FRTX retransmit machinery engages ([[#8. Retransmission|Section 8]]); MUST be 0 for <code>service=2</code>. Non-zero = best-effort, FRTX off.
;<code>ber</code>
:Bit Error Rate tolerance. 0 = error-free service requested: a CRC trailer is appended after the body of DATA packets and verified on receive (added / checked outside the FRCP PCI; see [[#1.1. PCI header|Section 1.1]]). Non-zero = peer accepts errors; trailer omitted. SACK control packets carry a CRC32 trailer regardless of <code>ber</code>; the <code>ber</code> gate applies to DATA only.
;<code>timeout</code>
:Peer-timeout (ms); 0 disables the keepalive timer. Independent of FRCP engagement.

Encryption is a separate per-flow attribute set at flow setup;
when enabled it wraps the FRCP packet (PCI + body, plus the CRC
trailer if any) under AEAD, expanding the <code>spb</code> by <code>headsz</code> + <code>tailsz</code>
octets (nonce / tag). The CRC trailer is currently kept inside
the AEAD wrap (see [[#1.1. PCI header|Section 1.1]]).

Reachable combinations exported by <code>include/ouroboros/qos.h</code>:

{| class="wikitable"
! Cube !! <code>service</code> !! <code>loss</code> !! <code>ber</code> !! Engaged
|-
| <code>qos_raw</code> || 0 || 1 || 1 || Raw passthrough
|-
| <code>qos_raw_safe</code> || 0 || 1 || 0 || Raw + CRC trailer
|-
| <code>qos_rt</code> || 1 || 1 || 1 || FRCP, no FRTX, no CRC
|-
| <code>qos_rt_safe</code> || 1 || 1 || 0 || FRCP, no FRTX, CRC
|-
| <code>qos_msg</code> || 1 || 0 || 0 || FRCP + FRTX
|-
| <code>qos_stream</code> || 2 || 0 || 0 || FRCP + FRTX, stream
|}

Forced couplings actually enforced by the public API:

* <code>service == SVC_STREAM</code> (2) requires <code>loss == 0</code>; <code>flow_alloc</code> / <code>flow_accept</code> reject the pair otherwise with <code>-EINVAL</code>.
* FRTX requires FRCP engagement (<code>service != SVC_RAW</code>); requesting <code>loss = 0</code> with <code>service = SVC_RAW</code> is structurally a no-op because no <code>frcti</code> is created.
* The <code>QOS_DISABLE_CRC</code> build flag globally forces <code>ber = 1</code>. Note: this flag defaults to ON, so default builds ship with CRC disabled until <code>QOS_DISABLE_CRC</code> is set to OFF.

Caveat: the API does NOT force <code>ber = 0</code> when <code>service != SVC_RAW</code>.
<code>qos_rt</code> has <code>service = SVC_MESSAGE</code> with <code>ber = 1</code>, which means the PCI
itself is not CRC-protected on that cube; the HCS ([[#1.1. PCI header|Section 1.1]])
remains the only integrity check on the header.

The FRCP-no-FRTX regime (<code>service = SVC_MESSAGE</code>, <code>loss > 0</code>) is meaningful
and live: sequence numbering, in-order delivery, flow-control
advertisement, KA, DRF rotation, and SDU fragmentation /
reassembly ([[#7.2. Fragmentation and reassembly|Section 7.2]]) all run. Lost packets are dropped
rather than retransmitted; a permanently-lost mid-fragment is
dropped via skip-past-gap once a later SDU is visible in the
reorder ring.

== 3. Protocol parameters ==

{| class="wikitable"
! Parameter !! Value !! Role
|-
| <code>RQ_SIZE</code> || compile-time, power of 2 (default 128) || Slot ring / rcv window width
|-
| <code>START_WINDOW</code> || compile-time, power of 2 (default 128) || Initial <code>rwe-lwe</code> after rotate
|-
| <code>RTO_MIN</code> || <code>MAX(250 us build-tunable, 1<<RXMQ_RES)</code>; per-flow via <code>fccntl</code> (<code>FRCTSRTOMIN</code>). Default ~1 ms with <code>RXMQ_RES=20</code>. || RTO floor; also floored at the retransmit-wheel resolution (~1 ms by default).
|-
| <code>MAX_RTO_MUL</code> || 20 || Backoff shift cap
|-
| RACK window <code>R</code> || <code>MIN(reo_wnd_mult * min_RTT/4, SRTT)</code> with <code>MIN_REORDER_NS = 250 us</code> floor; <code>reo_wnd_mult</code> scales on D-SACK, cap 20 || Reorder window; per RFC 8985 sec. 6.2; <code>reo_wnd_mult</code> per sec. 6.2 step 4
|-
| <code>MIN_RTT_WIN_NS</code> || 300 s (5 min, Linux <code>tcp_min_rtt_wlen</code>) || <code>min_RTT</code> windowed re-anchor
|-
| <code>REO_WND_MULT_MAX</code> || 20 (RFC 8985 sec. 6.2 step 4) || <code>reo_wnd_mult</code> cap
|-
| <code>REO_DECAY_PKTS</code> || 16 (RFC 8985 sec. 6.2 step 4 / <code>RACK.reo_wnd_persist</code>) || Fresh-ACK'd seq count per halving
|-
| <code>MAX_DSACK_LAG</code> || <code>RQ_SIZE</code> || D-SACK sanity cap
|-
| <code>RTT_QUARANTINE</code> || 32 (<code>seqno</code> steps) || NewReno gate pad
|-
| SACK rate-limit || <code>SACK_MIN_GAP_NS</code> (250 us, fixed) || Min SACK gap
|-
| <code>SACK_MAX_BLOCKS</code> || 2048 (wire cap; per-flow capped at <code>(frag_mtu-PCI-4)/8</code>) || Per-SACK block cap
|-
| <code>SACK_RXM_MAX</code> || 32 || Per-pass staged retransmit cap
|-
| <code>DUP_THRESH</code> || 3 (RFC 8985 default) || Hybrid fast-rxm trigger ([[#8. Retransmission|Section 8]])
|-
| <code>MDEV_MUL</code> || 2 (build-tunable via <code>FRCT_RTO_MDEV_MULTIPLIER</code>) || <code>mdev</code> shift in <code>RTO = srtt + (mdev << MDEV_MUL)</code>
|-
| RTTP nonce || 16 octets || Echoed verbatim
|-
| <code>RTTP_RING</code> || 8 || In-flight probes
|-
| RTT clamp || <code>16 * srtt</code> || Probe-sample upper bound (ACK-derived RTT samples gated by Karn / recovery only)
|-
| Cold-probe cadence || 100 ms (rx-driven; see [[#12. RTT estimation|Section 12]]) || Pre-<code>srtt</code> RTTP rate
|-
| <code>DELT_RDV</code> || 100 ms || RDVS emit cadence
|-
| <code>MAX_RDV</code> || 1 s || RDVS give-up
|-
| Delayed-ACK fire || <code>2 * TICTIME</code> (<code>TICTIME</code> = FRCT tick granularity, default 5 ms; <code>2*TICTIME = 10 ms</code> by default) || Fired after the first in-order DATA arrival; tick is build-tunable
|-
| NACK send cooldown || <code>srtt</code> when an <code>srtt</code> sample exists, else 100 ms || Pre-DRF NACK rate-limit
|-
| <code>MAX_SDU</code> || 1 MiB || Max reassembled SDU; configurable per flow
|}

The per-flow fragment Maximum Transmission Unit (MTU) is computed
at flow setup from the lower IPCP's mtu minus encryption
<code>headsz</code> / <code>tailsz</code> and CRC trailer; there is no FRCT-level default or
environment-variable override.

== 4. Sequence-number rotation (DRF) ==

The DRF (Data Run Flag) bit on an outbound packet means "this is
the start of a fresh data run" and is set whenever the sender has
nothing in flight (<code>snd_cr.seqno == snd_cr.lwe</code>).

Independently of that, if the sender has been idle longer than
<code>snd_cr.inact</code> AND the pipe is empty (<code>snd_cr.seqno == snd_cr.lwe</code>),
<code>seqno_rotate()</code> rolls a random new <code>seqno</code> before the send and
resets

<syntaxhighlight lang="text">
snd_cr.seqno = random()
snd_cr.lwe = snd_cr.seqno
snd_cr.rwe = snd_cr.seqno + START_WINDOW
rtt_lwe = snd_cr.seqno
in_recovery = false (recovery state, see Section 8)
recovery_high = snd_cr.seqno
</syntaxhighlight>

The receiver, on observing rcv-side inactivity
(<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
below). Non-DATA control packets pass through without the DRF
requirement. On DRF the receiver releases the <code>rq[]</code> slots and
rebases

<syntaxhighlight lang="text">
rcv_cr.lwe = seqno
rcv_cr.rwe = seqno + RQ_SIZE
rcv_cr.seqno = seqno
</syntaxhighlight>

If the inactive packet has DATA but no DRF, a rate-limited NACK is
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).

== 5. Send path ==

# If the SDU exceeds <code>(frag_mtu - data_hdr_len)</code>, the caller (<code>dev.c</code>) fans it out into <code>ceil(count / (frag_mtu - data_hdr_len))</code> fragments, each emitted via <code>frcti_snd</code> as its own DATA packet with a per-fragment role ([[#7.2. Fragmentation and reassembly|Section 7.2]]); both FRTX and best-effort flows fragment. Raw flows (no FRCP engagement, <code>qos.service == SVC_RAW</code>) carry no PCI and return <code>-EMSGSIZE</code> for any SDU larger than one packet at the layer below. An SDU that fits in a single packet is sent as SOLE. <code>frcti_snd</code> reserves PCI head room; sets DATA, plus DRF when the pipe is empty (<code>snd_cr.seqno == snd_cr.lwe</code>).
# <code>seqno_rotate()</code> if past sender inactivity and the pipe is empty ([[#4. Sequence-number rotation (DRF)|Section 4]]).
# Advertise FC (<code>pci.window = frcti_advert_rwe(frcti)</code>, i.e. <code>rcv_cr.rwe</code> clamped to <code>rcv_cr.lwe + ring_seq_cap</code> in stream mode) when the receiver side is recent: <code>now - rcv_cr.act < rcv_cr.inact</code>.
# Reliable mode (FRTX): leave <code>snd_cr.lwe</code> where it is; reset the slot at <code>RQ_SLOT(seqno)</code> (<code>snd_slots[p].time = now</code>, <code>snd_slots[p].flags = 0</code>); queue an <code>rxm_entry</code> (saves a packet copy, arms a wheel timer at <code>now + (rto << rto_mul)</code>). Piggyback ACK (<code>pci.ackno = rcv_cr.lwe</code>) while the a-timer for the most recent received DATA packet has not yet expired (<code>now - rcv_cr.act <= t_a</code>); on piggyback, set <code>rcv_cr.seqno = rcv_cr.lwe</code> so the next delayed-ACK fire is suppressed. See [[#8. Retransmission|Section 8]] for <code>t_a</code> / <code>t_r</code> semantics.
# Best-effort mode (no FRTX): advance <code>snd_cr.lwe</code> immediately (<code>snd_cr.lwe = snd_cr.lwe + 1</code>, <code>snd_cr.rwe = snd_cr.lwe + RQ_SIZE</code>); no retransmit state. No send-side RTT probe is armed in this mode (<code>rtt_probe_arm</code> requires an in-flight <code>seqno</code>, which best-effort never has); the rx-driven cold seeder in <code>frcti_rcv</code> is the only probe path.
# In reliable mode, optionally arm an RTT probe ([[#12. RTT estimation|Section 12]]).

== 6. Receive path ==

=== 6.1. Early-exit dispatch ===

Keepalive (KA), RTT probe (RTTP), pre-DRF NACK, and rendezvous
(RDVS) packets short-circuit out of <code>frcti_rcv</code> before the locked
main path; each handler takes its own lock internally.

<syntaxhighlight lang="text">
incoming packet
|
v
+---------+
| KA? |---yes--> ka_rcv ; return
+---------+
|no
v
+---------+
| RTTP? |---yes--> rttp_rcv; return
+---------+
|no
v
+---------+
| NACK? |---yes--> nack_rcv; return (see Section 9)
+---------+
|no
v
+---------+
| RDVS? |---yes--> rdv_rcv ; return (reply bare FC, ackno=0)
+---------+
|no
v
acquire wrlock; enter locked main path
</syntaxhighlight>

;<code>KA</code>
:refresh <code>t_ka_rcv</code>, honour piggybacked ACK.
;<code>RTTP</code>
:probe (echo back nonce) or echo (verify nonce, sample RTT).
;<code>NACK</code>
:pre-DRF, sender-side handler. See [[#9. Pre-DRF NACK|Section 9]].
;<code>RDVS</code>
:reply with a bare FC packet (<code>ackno = 0</code>); <code>rdlock</code> only.

=== 6.2. Locked main path ===

Steps below run with the per-flow <code>frcti.lock</code> held for writing
(<code>pthread_rwlock_wrlock</code>) unless noted.

;<code>rcv_inact_check</code>
:Only meaningful when the receive side is stale. On DRF (Data Run Flag): release <code>rq[]</code> slots, rebase <code>rcv_cr</code>, continue. On stale DATA without DRF: fire a pre-DRF NACK if cooldown allows ([[#9. Pre-DRF NACK|Section 9]]), then discard the packet; on cooldown, drop without sending a NACK (a pending cumulative ACK from <code>drop_packet</code> may still go out). Non-DATA, non-DRF arrivals bypass <code>rcv_inact_check</code> entirely; pure-DRF stale arrivals fall through after the DRF rebase branch.

;DATA-only act refresh
:Refresh <code>rcv_cr.act</code> only when <code>FRCT_DATA</code> is set, so that non-DATA packets never block the next DRF rebase.

;Wire-dup gate
:Before flag-driven dispatch, drop wire-duplicate ACKs and wire-duplicate DATA (<code>is_dup_ack</code> / <code>is_dup_data</code>). The DATA check is bypassed for <code>FRCT_RXM</code>-bearing arrivals so the piggybacked ACK / SACK / FC carried on a retransmitted DATA at an already-ACK'd <code>seqno</code> is still applied; the stale-in-window branch below then drops the packet.

;<code>ACK</code>
:Drop ACKs whose <code>ackno</code> falls outside <code>(snd_cr.lwe, snd_cr.seqno]</code>. If <code>ackno == snd_cr.lwe</code> (non-advancing cumulative ACK), drive RACK fast-retransmit consideration ([[#8. Retransmission|Section 8]]). Otherwise advance <code>snd_cr.lwe = ackno</code>, collapse <code>rto_mul</code> to 0 (Karn-gated by <code>SND_RTX</code> on the just-acknowledged slot, the old head-of-line), reset <code>dup_thresh</code> to 0, update <code>t_latest_ack</code> to the send-time of the slot at <code>ackno-1</code> (consumed by RACK and SACK below), decay <code>reo_wnd_mult</code> per RFC 8985 sec. 6.2 step 4, exit NewReno-careful recovery (see [[#8. Retransmission|Section 8]]) on <code>ackno >= recovery_high</code> or <code>ackno == snd_cr.seqno</code>, and feed an RTT sample if eligible ([[#12. RTT estimation|Section 12]]).

;<code>SACK</code>
:Walk the block list. For each block (a present range above <code>lwe</code>) NULL out <code>snd_slots[k].rxm</code>, clear the slot's per-send flags, and advance <code>t_latest_ack</code> to the latest send-time covered (the Forward Acknowledgement / fack equivalent, Mathis & Mahdavi 1996); the first block whose start clamps to <code>snd_cr.lwe</code> skips this fack update so that a head-of-line clamp does not falsely advance fack. For un-SACKed gaps below <code>hi_sacked</code>, stage a retransmit per slot that is (1) still owned (<code>rxm != NULL</code>), (2) not already <code>SND_FAST_RXM</code>, (3) not aged out past <code>t_r</code>, and (4) either outside the RACK reorder window <code>R</code> OR with <code>dup_thresh >= DUP_THRESH</code> (the RFC 8985 sec. 6.2 hybrid trigger). Mark the slot <code>SND_FAST_RXM</code> and NULL the <code>rxm</code> at stage time. Capped at <code>SACK_RXM_MAX</code> staged retransmits per receive pass; what's left rides the next SACK.

;<code>FC</code>
:Bump <code>snd_cr.rwe</code> (clamped to <code>lwe + RQ_SIZE</code>, never shrinks) and mark window open.

;<code>DATA</code>
:Bounds-check <code>seqno</code> against window. On stale-dup (<code>seqno < rcv_cr.lwe</code>), set <code>rcv_cr.seqno = seqno</code> to force a fresh ACK on the next <code>ack_snd</code>, then drop. On accept: both FRTX and best-effort stash the packet-buffer index into <code>rq[seqno mod RQ_SIZE]</code>. Fragments stash unchanged - the role bits are inspected only at consume time ([[#7.2. Fragmentation and reassembly|Section 7.2]]). On out-of-order arrival, build a SACK reply if not rate-limited (per [[#3. Protocol parameters|Section 3]]) and not deduplicated against the previous <code>(rcv_cr.lwe, n_blocks)</code> pair; D-SACK reports always bypass the dedup. If both rate-limit and dedup suppress the reply, neither SACK nor delayed-ACK fires (the sender picks up the gap on its next ACK). On in-order arrival, arm the delayed-ACK timer.

;<code>drop_packet</code> exit
:Releases the per-packet shared-memory buffer (<code>spb</code>), then calls <code>ack_snd</code> synchronously after the <code>spb</code> release to surface any pending cumulative ACK.

== 7. Read path and reassembly ==

=== 7.1. Read path ===

<code>flow_read</code> returns a full reassembled SDU (Service Data Unit) via
<code>frcti_consume</code> on every FRCP SDU-mode flow (FRTX or best-effort);
stream-mode is covered in [[#16. Stream-mode flows|Section 16]]. An incomplete head-of-line
(HoL) run yields <code>-EAGAIN</code>; an oversized run yields <code>-EMSGSIZE</code> (the
run is dropped so the flow does not stall). On best-effort flows,
a permanently-lost mid-fragment is dropped as soon as a later
complete SDU becomes visible in the ring ([[#7.2. Fragmentation and reassembly|Section 7.2]] skip-past-
gap).

Raw flows carry no <code>frcti</code>, so <code>flow_read</code> returns the next pending
packet-buffer index directly, with no role-bit inspection. (Raw
service is selected via <code>qos.service == SVC_RAW</code> at flow allocation,
which suppresses <code>frcti</code> creation.)

<code>frcti_pdu_ready</code> is the no-advance peek used by <code>fevent</code> (the
Ouroboros flow-event multiplexer, the <code>poll(2)</code>-equivalent on
flows). It returns ready only when the head-of-line run is
complete and the lead packet (a Protocol Data Unit, here one FRCP
packet) is present at <code>rcv_cr.rwe - RQ_SIZE</code>; any other state
(including the best-effort skip-past-gap case) returns not ready,
and <code>frcti_consume</code> is left to drop the broken prefix and re-
inspect.

=== 7.2. Fragmentation and reassembly ===

Send side (<code>flow_write_frag</code>). An SDU larger than
<code>(frag_mtu - PCI)</code> is split into <code>ceil(count / (frag_mtu - PCI))</code>
fragments; each fragment is its own FRCP packet with its own
<code>seqno</code> and a per-fragment role flag pair ([[#1.2. Flag bits|Section 1.2]]). Roles are
assigned at emit time:

{| class="wikitable"
! i !! Role
|-
| <code>n=1</code> || <code>SOLE</code>
|-
| <code>i=0</code> || <code>FIRST</code>
|-
| <code>i=n-1</code> || <code>LAST</code>
|-
| else || <code>MID</code>
|}

A mid-loop allocation or transmit failure may yield a partial
write: the call returns the bytes already enqueued (<code>off > 0</code>) or
the underlying error (<code>off == 0</code>). Best-effort flows fragment
identically; on the receiver, a partial run with a permanently-
lost fragment is dropped when a later complete SDU is visible in
the ring (see skip-past-gap below). Raw flows carry no PCI and
refuse anything larger than the layer's user MTU (<code>-EMSGSIZE</code>).

Wire-level recovery is fragment-agnostic on FRTX flows: each
fragment's <code>seqno</code> flows through SACK / RACK / RTO / NACK exactly
as for a SOLE DATA packet, and reassembly does not re-enter the
loss-detection path. Best-effort flows run the same <code>seqno</code>
machinery (DRF, FC, ACK piggyback, pre-DRF NACK emit) but queue
no <code>rxm</code> state at the sender, so a lost MID is unrecoverable;
skip-past-gap handles it (below).

Receive side. Fragments stash into <code>rq[seqno]</code> unchanged; role bits
are read only at consume time. <code>frag_run_inspect</code>, called from
<code>frcti_consume</code>, walks the ring starting at the oldest still-
undelivered <code>seqno</code> <code>base = rcv_cr.rwe - RQ_SIZE</code> (equal to <code>rcv_cr.lwe</code>
only when no partial run is in progress; during a partial run <code>lwe</code>
has already advanced past <code>base</code>). It produces one of three
outcomes:

{| class="wikitable"
! Outcome !! Cause
|-
| <code>DELIVER (n)</code>
| <code>rq[base]=SOLE</code> (<code>n=1</code>), or <code>rq[base]=FIRST</code> and a <code>LAST</code> follows in slots <code>[base+1..base+n-1]</code> with all intermediate roles in <code>{MID,FIRST,LAST}</code> contiguous.
|-
| <code>DROP (n)</code>
| <code>rq[base]</code> is <code>MID</code> or <code>LAST</code> without a preceding <code>FIRST</code> (<code>n=1</code>); a <code>FIRST..[non-LAST]..new-FIRST</code> or new-<code>SOLE</code> mid-run (drop the broken prefix with <code>n</code> = run length minus 1, so the new <code>FIRST</code>/<code>SOLE</code> stays); or, on best-effort flows, a gap at <code>base</code> with a <code>FIRST</code>/<code>SOLE</code> later in the ring (drop up to the new run start).
|-
| <code>NOT_READY</code>
| <code>rq[base]</code> absent or <code>FIRST..[non-LAST]</code> with no later <code>FIRST</code>/<code>SOLE</code> in the ring (FRTX waits for retx; best-effort waits for arrival).
|}

<code>DELIVER</code> triggers <code>frag_gather</code>: a scatter-gather <code>memcpy</code> of the <code>n</code>
consecutive fragments at <code>rq[base..base+n-1]</code> directly into the
caller's buffer; each per-packet shared-memory buffer (<code>spb</code>) is
released and <code>rwe</code> advances by <code>n</code>. <code>lwe</code> was already advanced
incrementally as each contiguous fragment arrived; <code>frag_gather</code>
only restores the fixed-width invariant <code>rwe == lwe + RQ_SIZE</code>.
No intermediate reassembly buffer is allocated.

<code>DROP</code> advances <code>rwe</code> past the broken prefix (releasing the <code>spb</code>s)
and pulls <code>lwe</code> up to the new trailing edge if needed; the next
consume retries from the new <code>base</code>. Oversize or arithmetically
overflowing delivery (sum of fragment lengths > <code>max_rcv_sdu</code>, sum
> caller's buffer, or running-sum overflow) also drops the run
with <code>-EMSGSIZE</code>.

Skip-past-gap (best-effort only). On FRTX, a gap in the run means
"waiting for retransmit" and <code>frag_run_inspect</code> returns <code>NOT_READY</code>.
On best-effort flows the gap is permanent, so <code>frag_run_inspect</code>
scans forward in the ring for the next <code>FIRST</code> or <code>SOLE</code>; if one is
visible within <code>RQ_SIZE</code>, it returns <code>DROP</code> for the broken prefix and
the consume loop retries at the new <code>lwe</code>. Memory hold is bounded
by <code>RQ_SIZE</code>; the partial releases on the next consume call once a
later complete run exists. Voice-like flows (one <code>SOLE</code> per SDU)
see no extra wait: any later <code>SOLE</code> makes the prior gap droppable
immediately.

The choice to defer reassembly to consume time keeps the receive
path zero-copy: fragments stay in the shared-memory ring until
the application pulls, and the SDU lands directly in the caller's
buffer.

== 8. Retransmission ==

FRCP is bounded by two delta-t-derived timers (Watson 1981, see
[[#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_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.

Each in-flight FRTX <code>seqno</code> owns one <code>rxm_entry</code>, armed in a hashed
timing wheel; the wheel deadline is the slot's next eligible
retransmit time.

;RTO timer
:On fire (<code>rxm_due</code>), re-emit with <code>FRCT_RXM</code>, mark <code>SND_RTX</code> (Karn-suppress next ACK's RTT sample), and (for the head-of-line (HoL) slot only) bump <code>rto_mul</code> up to <code>MAX_RTO_MUL</code>. Wheel deadline is <code>t_send + (rto << rto_mul)</code>. Re-armed unless consumed. The RTO timer also clears <code>SND_FAST_RXM</code> (re-arming fast-retransmit eligibility), resets <code>reo_wnd_mult</code> to 1 on a HoL fire (RFC 8985 sec. 6.2 step 4 reset clause), and marks the flow <code>ACL_FLOWDOWN</code> if its <code>frct_tx</code> call fails.

;r-timer guard
:Before any retransmit attempt, check <code>(now - t0)</code> against <code>t_r</code>. If exceeded, the slot is no longer eligible for retransmit. Only the RTO timer (<code>rxm_due</code>) treats r-timer expiry as terminal: it marks the flow <code>ACL_FLOWDOWN</code> (peer unreachable). Fast-retransmit, SACK-driven retransmit, and NACK-driven head-of-line re-emit silently skip aged-out slots and defer the flow-down decision to the next RTO fire.

;Fast retransmit (hybrid trigger, RFC 8985 sec. 6.2)
:On a non-advancing cumulative ACK with the scoreboard advanced, fire one fast retransmit when EITHER (a) the head-of-line slot's latest send is older than the RACK reorder window <code>R</code> ([[#3. Protocol parameters|Section 3]]) and not yet aged out, OR (b) the SACK <code>dup-thresh</code> count above <code>snd_cr.lwe</code> reaches <code>DUP_THRESH</code> (= 3, RFC 8985 sec. 6.2 step 4). Fires at most once per non-advancing cumulative-ACK value, gated by <code>rack_fired_lwe</code> (the <code>snd_cr.lwe</code> at which fast-retransmit last fired). Set <code>SND_FAST_RXM</code> on the slot (one-shot per-slot gate) and enter NewReno-style careful recovery (see NewReno below in this section).
:The RACK reorder window <code>R</code> uses the RFC 8985 sec. 6.2 form <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> with a <code>MIN_REORDER_NS = 250 us</code> floor. Before the first RTT sample seeds <code>min_rtt</code>, <code>R</code> falls back to <code>MIN(reo_wnd_mult * SRTT / 4, SRTT)</code>, still floored at <code>MIN_REORDER_NS</code> (consistent with the windowed-minimum fallback described in [[#12. RTT estimation|Section 12]]). <code>min_rtt</code> is a windowed minimum over the last <code>MIN_RTT_WIN_NS</code> = 5 min of RTT samples (matches the Linux <code>tcp_min_rtt_wlen</code> default) so a route change to a longer path eventually re-anchors the reorder window without relying on <code>reo_wnd_mult</code> growth alone.

;SACK-driven retransmit
:For each gap below <code>hi_sacked</code> whose slot is (1) still owned, (2) not already <code>SND_FAST_RXM</code>, (3) not aged out past <code>t_r</code>, and (4) either outside the RACK window <code>R</code> OR with <code>dup_thresh >= DUP_THRESH</code> (same hybrid as fast-retransmit, see [[#6.2. Locked main path|Section 6.2]]), re-emit. Each SACK-driven retransmit re-arms a fresh <code>rxm</code> so a lost retransmit can still be recovered by its own RTO timer.

;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.

== 9. Pre-DRF NACK ==

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.

;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>)
:When an incoming DATA packet has no DRF and rcv-side activity is older than <code>rcv_cr.inact</code>, the receiver emits a bare packet with <code>flags = FRCT_NACK</code> and <code>seqno = arrival_seqno - 1</code> (informational only, not consulted by the receive handler). The cooldown in [[#3. Protocol parameters|Section 3]] rate-limits the burst. Non-DATA non-DRF arrivals bypass <code>rcv_inact_check</code> entirely; non-DATA DRF still rebases via the DRF branch.

;Receive (<code>frcti_nack_rcv</code>)
: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 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.

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 ==

Cumulative ACK is <code>ackno = rcv_cr.lwe</code>. On out-of-order arrival the
receiver also emits a SACK packet ([[#1.3. SACK payload|Section 1.3]]) whose payload lists
''present'' blocks above <code>lwe</code> (analogous to TCP SACK / QUIC ACK
ranges). SACKs are rate-limited per [[#3. Protocol parameters|Section 3]] and suppressed when
neither <code>lwe</code> nor block count has changed since the last SACK.

D-SACK reports (RFC 2883) are emitted in-band as <code>block[0]</code> of an
otherwise normal SACK frame (see [[#1.3. SACK payload|Section 1.3]] for the encoding).
Two receiver triggers arm a pending D-SACK report (single-slot,
latest-wins):

* DATA arrival with <code>seqno < rcv_cr.lwe</code>, both wire-dup (no RXM, <code>is_dup_data</code> path) and retransmit (RXM, post-FC branch) (RFC 2883 sec. 4.1.1, full duplicate)
* <code>rq_accept</code> conflict, slot already occupied in <code>[lwe, rwe)</code> (RFC 2883 sec. 4.1.2, partial duplicate)

When a D-SACK is pending and the standard scoreboard SACK would be
suppressed by dedup or rate-limit, the report is emitted as a
stand-alone SACK frame through the normal <code>ack_snd</code> path; when a
D-SACK report is pending the path bypasses dedup and the <code>TICTIME</code>
rate-limit, but the a-timer suppression on rcv inactivity still
applies.

Bare ACKs are deferred via a per-flow delayed-ACK timer (one in
flight at a time, atomic test-and-set dedup; fires per [[#3. Protocol parameters|Section 3]]
after the first in-order arrival). Suppressed if (1) no new
<code>seqno</code>, (2) rcv side is inactive (older than <code>t_a</code>), or (3) the
sender just sent within <code>TICTIME</code>. A pending D-SACK ride-through
bypasses (1) and (3); the a-timer gate (2) is unconditional.

== 11. Flow control ==

The receiver advertises <code>rwe</code> in every FC field. The sender treats
its <code>snd_cr.rwe</code> as the absolute right edge: when
<code>snd_cr.seqno >= snd_cr.rwe</code> the window is closed and <code>flow_write</code>
yields. While closed, the sender periodically emits RDVS
(rendezvous) packets (cadence <code>DELT_RDV</code>); the receiver replies with
a bare FC packet (<code>ackno = 0</code>) that reopens the window. Once the
window has been closed for longer than <code>MAX_RDV</code> the sender stops
emitting RDVS but does not tear the flow down - the writer keeps
blocking until either a peer-driven FC arrives or the KA
(keepalive) / r-timer marks the flow.

<code>rwe</code> is clamped to <code>lwe + RQ_SIZE</code> on receipt and MUST NOT shrink:
a backward <code>rwe</code> is silently clamped to the current <code>snd_cr.rwe</code>;
the FC packet still reopens the window.

== 12. RTT estimation ==

Active RTTP probes ([[#1.4. RTTP payload|Section 1.4]]) carry a 32-bit <code>probe_id</code> (0
reserved) and a 16-byte random nonce echoed verbatim - defends
against spoofed replies. A ring of <code>RTTP_RING</code> in-flight probes is
kept; an echo whose <code>(id, nonce)</code> doesn't match the ring slot is
dropped. A single RTTP sample is clamped to <code>RTT_CLAMP_MUL * srtt</code>
(compile-time <code>RTT_CLAMP_MUL = 16</code>) once <code>srtt</code> is seeded; the first
cold-probe sample feeds <code>rtt_update</code> raw.

Probe arming gates:

;Cold (no <code>srtt</code> yet)
:the receive path arms at most one probe per 100 ms via <code>frcti_rcv_probe</code> (<code>PROBE_DUE_COLD</code>); arming requires an incoming packet. Active send-path arming bails while <code>srtt == 0</code>.
;Warm (<code>rtt_probe_arm</code>, called from <code>frcti_snd</code>)
:outstanding data (<code>snd_cr.seqno > snd_cr.lwe</code>), AND at least <code>2 * srtt</code> since <code>t_rcv_rtt</code> (last RTT receive of any kind), AND at least <code>srtt</code> since <code>t_snd_probe</code> (last probe emit).

Sample feeds either Linux's asymmetric <code>mdev</code> estimator
(<code>FRCT_LINUX_RTT_ESTIMATOR</code>, default ON) or RFC 6298 symmetric EWMA
(compile option). <code>srtt</code> is floored at 10 ms when seeded from a
hint, at 1 us after every update (including the first seeding
sample); <code>mdev</code> floored at 100 ns.

:<code>RTO = max(rto_min, 2 * srtt, srtt + (mdev << MDEV_MUL))</code>

(the <code>2 * srtt</code> floor is an FRCT addition not in RFC 6298).
Effective wheel deadline capped per [[#3. Protocol parameters|Section 3]].

ACK-derived samples (<code>frcti_ack_rcv</code> -> <code>rtt_sample_eligible</code>), beyond
the cum-ACK advance gate in <code>frcti_ack_rcv</code> (<code>ackno > lwe</code> and
<code>ackno <= seqno</code>), require all of: not in recovery; ACK packet does
not carry <code>FRCT_RXM</code>; HoL slot's <code>SND_RTX</code> bit clear; slot's <code>rxm</code>
pointer non-NULL (not SACK-consumed); <code>lwe</code> not below the <code>rtt_lwe</code>
fence; <code>srtt</code> already seeded by an RTTP probe. There is no ACK-only
seeding.

Every eligible sample also feeds <code>RACK.min_RTT</code> (RFC 8985 sec. 6.2)
via a windowed minimum: replace whenever the sample is strictly
smaller OR more than <code>MIN_RTT_WIN_NS</code> (5 min, matches Linux
<code>tcp_min_rtt_wlen</code>) has elapsed since the current min was set. The
downward branch is immediate (faster path picked up at once); the
upward branch is gated on the window (a transient queue burst does
not poison the estimate, but a sustained route change to a longer
path re-anchors <code>min_RTT</code> after at most one window). Seeded from
<code>rtt_hint</code> at <code>rtt_init</code>; 0 acts as the unset sentinel and the base
in <code>rack_reorder_window</code> falls back from <code>min_RTT</code> to <code>SRTT</code> (so
<code>R = mult * SRTT/4</code>, capped at <code>SRTT</code>, floored at <code>MIN_REORDER_NS</code>)
until the first sample. See [[#6.2. Locked main path|Section 6.2]].

== 13. Liveness (keepalive) ==

When <code>qs.timeout > 0</code> a per-flow KA (keepalive) timer is armed.
Arming uses <code>rcv_cr.act</code> for the deadline computation:

:<code>deadline = min(snd_act + qs.timeout/4, rcv_act + qs.timeout)</code>

(clamped to <code>now + qs.timeout/4</code> if already past). The timer fires
either on sender idleness (to send a KA) or on receiver idleness
(to declare the peer dead). On fire (<code>ka_snd</code>) the peer-dead test
uses <code>max(rcv_cr.act, t_ka_rcv)</code> so a recent KA reply counts even
when no DATA has arrived:

* If <code>now - max(rcv_cr.act, t_ka_rcv) > qs.timeout</code>, mark the flow <code>ACL_FLOWPEER</code> and notify the per-process flow-event set (<code>proc.fqset</code>) with <code>FLOW_PEER</code>.
* Else if <code>snd_idle > qs.timeout/4</code>, emit a bare <code>KA | ACK</code> (<code>ackno = rcv_cr.lwe</code>) and re-arm.
* Else just re-arm.

Note: <code>rx_rb</code> and <code>tx_rb</code> are the receive and transmit shared-memory
ring buffers. The r-timer raises <code>ACL_FLOWDOWN</code> on both (route is
broken); keepalive raises <code>ACL_FLOWPEER</code> on <code>rx_rb</code> only and notifies
the flow-event set (peer is silent, writer keeps <code>tx_rb</code> usable) -
distinct ACLs. <code>qs.timeout == 0</code> disables keepalive entirely; a
silent peer crash is then undetected.

== 14. Linger / teardown ==

On <code>flow_dealloc</code>, <code>frcti_dealloc</code> computes a grace timeout

:<code>max(rcv_cr.act + rcv_cr.inact, snd_cr.act + snd_cr.inact) - now</code>

(floored at 0 and converted to seconds) and returns it; <code>flow_dealloc</code>
forwards this to the IRMd as the dealloc grace. The IRMd, not FRCT,
performs the wait. Before computing the timeout, FRCT may emit a
final ACK when <code>rcv_cr.lwe != rcv_cr.seqno</code> (the peer has not been
told the most recent cumulative ACK) AND the rcv side has been
active within <code>t_a</code> (a-timer not aged out).

<code>FRCTFLINGER</code> is honoured only when <code>snd_cr.lwe < edge</code>, where <code>edge =
snd_fin_seqno</code> after FIN has been sent in stream mode and
<code>snd_cr.seqno</code> otherwise (data or FIN still in flight). The drain
itself runs in <code>flow_dealloc</code>'s <code>while (FRCTI_LINGERING)</code> loop, not in
<code>frcti_dealloc</code>.

The fd is single-reader / single-writer (documented in the
manpages). <code>flow_write</code> pumps <code>rx_rb</code> on every call (via
<code>flow_wait_window</code> -> <code>flow_drain_rx_nb</code>) and additionally blocks on
<code>rx_rb</code> when the send window is closed. A pure-writer thread thus
consumes ACKs without a dedicated reader.

== 15. Heritage and adopted techniques ==

Delta-t (Watson, 1981) is the primary heritage; FRCP descends from
the delta-t protocol family via the Recursive InterNetwork
Architecture (RINA; Day, "Patterns in Network Architecture", 2008,
ch. 9). Timer-based connection management
(no SYN/FIN handshake, per-flow state born on first DATA and
reclaimed after <code>t_mpl + a + r</code> of silence), the DRF marker, and the
<code>t_mpl</code> / <code>t_a</code> / <code>t_r</code> timers all come from delta-t. See Watson,
"Timer-Based Mechanisms in Reliable Transport Protocol Connection
Management", Computer Networks 5 (1981).

The unified <code>flow_alloc(name, qos, ...)</code> primitive and its
multi-axis QoS-cube argument ([[#2.2. Service modes (orthogonal axes)|Section 2.2]]) also come from RINA
(Day 2008, ch. 6; Grasa et al., "IRATI: investigating RINA as an
alternative to TCP/IP", Computer Networks 92 (2015)) - reliability,
ordering, CRC presence, and encryption are flow attributes, not
separate sockets or protocols.

The table below summarises additional adopted techniques and their
references.

{| class="wikitable"
! FRCP mechanism !! Heritage !! Reference / note
|-
| Random new <code>seqno</code> on <code>seqno_rotate</code> || TCP ISN || RFC 6528 (Gont & Bellovin, 2012). QUIC PN-space reset (RFC 9000 sec. 12.3) is a structural analogue.
|-
| Cumulative ACK, left-window-edge advance || TCP || RFC 793 / RFC 9293
|-
| Receive window with non-shrink rule || TCP || RFC 793 sec. 3.7 / RFC 9293 sec. 3.8.6; RFC 1122 sec. 4.2.2.16 for the explicit non-shrink prohibition
|-
| Modular <code>seqno</code> arithmetic (<code>before</code>/<code>after</code> helpers) || TCP || RFC 793 sec. 3.3 / RFC 9293 sec. 3.4
|-
| Selective ACK block list || TCP || RFC 2018 (Mathis et al., 1996). Encoded as a typed FRCP packet rather than a TCP option, so framing is closer to QUIC ACK frames. D-SACK (RFC 2883) carried in-band as <code>block[0]</code>; see [[#1.3. SACK payload|Section 1.3]].
|-
| NewReno-careful recovery with <code>recovery_high</code> gate || TCP || RFC 6582 (Henderson et al., 2012); QUIC builds on the same model in RFC 9002 sec. 7.3.2. Cwnd half absent (CC in IPCP).
|-
| RACK reordering window for fast retransmit || TCP || RFC 8985 (Cheng et al., 2021). FRCP <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> with a <code>MIN_REORDER_NS = 250 us</code> floor against <code>srtt</code> collapse; matches RFC 8985 sec. 6.2 and Linux <code>tcp_rack_reo_wnd</code>. DSACK-driven <code>reo_wnd_mult</code> (sec. 6.2 step 4) is adopted; see [[#1.3. SACK payload|Section 1.3]] for the wire encoding. The hybrid RACK-or-<code>DUP_THRESH</code> trigger from RFC 8985 sec. 6.2 step 4 is adopted ([[#8. Retransmission|Section 8]]). QUIC's analogue in RFC 9002 sec. 6.1.2 uses <code>max(srtt, latest_rtt)</code> as the base.
|-
| 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> = 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.
|-
| Delayed ACK with rate suppression || TCP || RFC 813 (Clark, 1982); RFC 1122 sec. 4.2.3.2; RFC 5681 sec. 4.2. Single-deadline coalescing rather than "ack-every-other-segment".
|-
| Zero-window-probe / persist-timer analogue (RDVS) || TCP || RFC 1122 sec. 4.2.2.17 / RFC 9293 sec. 3.8.6.1. RDVS solicits an FC reply, distinct from QUIC <code>DATA_BLOCKED</code> (RFC 9000 sec. 19.12), which is one-way notification. <code>MAX_RDV</code> give-up departs from TCP.
|-
| Multiplexed control on a single PCI || SCTP / QUIC || SCTP chunk bundling (RFC 9260 sec. 6.10); QUIC frame multiplexing (RFC 9000 sec. 12.4). Cleaner fit than TCP's separate-flag-bits design.
|-
| ACK ranges as multiple discontiguous acked blocks || QUIC || QUIC ACK frame (RFC 9000 sec. 19.3). FRCP SACK is conceptually QUIC-frame-shaped even though encoded as absolute <code>[start,end]</code> pairs.
|-
| Nonce-authenticated active RTT / liveness probing (RTTP) || QUIC <code>PATH_CHALLENGE</code> || <code>PATH_CHALLENGE</code> / <code>PATH_RESPONSE</code> (RFC 9000 sec. 8.2, sec. 19.17, sec. 19.18). WebRTC ICE consent-freshness (RFC 7675) is the same pattern. QUIC's nonce is 8 octets; FRCP chooses 16.
|-
| Probing distinct from keepalive || QUIC || KA timer answers "peer alive?", RTTP answers "path measurable?", as in QUIC PING (RFC 9000 sec. 19.2) vs <code>PATH_CHALLENGE</code>.
|-
| Bare KA + ACK keepalive packets || QUIC / SCTP || QUIC PING (RFC 9000 sec. 19.2); SCTP HEARTBEAT / HEARTBEAT-ACK (RFC 9260 sec. 8.3). SCTP HEARTBEAT also carries an opaque echoed blob, structurally similar to FRCP RTTP.
|-
| (<code>FFGM</code>, <code>LFGM</code>) fragment-role bits ([[#7.2. Fragmentation and reassembly|Section 7.2]]) || SCTP || RFC 9260 sec. 3.3.1 DATA chunk B/E bits encode the same four states (<code>B+E=SOLE</code>, <code>B-only=FIRST</code>, neither=<code>MID</code>, <code>E-only=LAST</code>). Each fragment carries its own <code>seqno</code>/TSN and is independently retransmitted.
|-
| Stream byte-offset reassembly (Sections [[#1.5. Stream PCI extension|1.5]], [[#16. Stream-mode flows|16]]) || QUIC || QUIC STREAM frame (RFC 9000 sec. 19.8) uses Offset + Length varints; FRCP uses fixed 32-bit <code>start</code> / <code>end</code>. One stream per flow vs QUIC's many streams multiplexed.
|-
| FIN end-of-stream marker (Sections [[#1.2. Flag bits|1.2]], [[#16. Stream-mode flows|16]]) || TCP / QUIC || TCP FIN flag (RFC 9293 sec. 3.1) closes one half of the byte stream; QUIC STREAM frame FIN bit (RFC 9000 sec. 19.8) does the same per stream with an immutable final-size invariance (RFC 9000 sec. 4.5: the final size is fixed once observed). FRCP's FIN consumes one packet <code>seqno</code> (not one byte of stream space) and is idempotent on the sender side.
|-
| Stream byte-credit flow control ([[#16. Stream-mode flows|Section 16]]) || QUIC || <code>MAX_STREAM_DATA</code> (RFC 9000 sec. 4.1, sec. 19.10). FRCP projects a per-flow byte budget onto the <code>seqno</code>-space <code>rwe</code>. Single stream per flow collapses QUIC's <code>MAX_DATA</code> / <code>MAX_STREAM_DATA</code> distinction.
|-
| Header protection (encrypted seqnos) || QUIC || QUIC RFC 9001 sec. 5.4 applies header protection on top of AEAD to mask the packet number. FRCP's per-flow AEAD wrap ([[#16. Stream-mode flows|Section 16]]) is wider: it encrypts the entire PCI including <code>seqno</code> because the IPCP below already routes, so no destination connection-ID needs to stay in clear (cf. RFC 9000 sec. 5.2).
|-
| Two-bit fragment role polarity || SCTP || The (<code>FFGM</code>, <code>LFGM</code>) pair follows SCTP B/E (begin = 1 / end = 1) rather than IPv4 MF (RFC 791 sec. 3.2), which has the inverse polarity (MF = 1 means NOT last).
|-
| Orthogonal reliability / ordering axes ([[#2.2. Service modes (orthogonal axes)|Section 2.2]]) || SCTP || PR-SCTP (RFC 3758, per-message partial reliability) and SCTP DATA U-bit (RFC 9260 sec. 3.3.1, per-message unordered) are the closest precedents for decoupling reliability from ordering; FRCP sets them per-flow rather than per-message.
|-
| Orthogonal CRC (<code>qs.ber == 0</code>) || UDP-Lite || RFC 3828 (Larzon et al., 2004) lets the sender pick a per-packet Checksum Coverage and the receiver enforce a locally configured minimum (no in-band negotiation; sec. 3.1, sec. 3.3). FRCP gates a full CRC trailer on <code>qs.ber == 0</code> at flow setup. Contrast TCP / SCTP (mandatory checksum) and QUIC (AEAD subsumes CRC).
|-
| Setup-time service negotiation || DCCP / SCTP / QUIC || DCCP Service Codes (RFC 4340 sec. 8.1.2, RFC 5595); SCTP INIT parameters (RFC 9260 sec. 3.3.2); QUIC transport parameters (RFC 9000 sec. 7.4). All negotiate service properties at connection setup; only RINA's QoS cube exposes them as an orthogonal vector.
|}

=== 15.1. Original to FRCP (no clean prior art) ===

* Pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]): receiver-driven nudge exploiting <code>snd_cr.inact > rcv_cr.inact</code>. Closest analogues are SCTP Gap Ack Blocks (RFC 9260 sec. 3.3.4) and DCCP Ack Vector (RFC 4340 sec. 11.4) - both let the receiver describe gaps to the sender, but neither targets the cross-epoch / pre-DRF case.
* <code>MAX_RDV</code> window-probe give-up: neither TCP (persist-timer probes until application or R2 abort, RFC 9293 sec. 3.8.6.1) nor QUIC has an explicit FC-give-up counter. A recursive-network choice: outer layers can drop the flow.
* Skip-past-gap reassembly ([[#7.2. Fragmentation and reassembly|Section 7.2]]): SCTP fragments and reassembles every flow regardless of reliability/ordering, using its own per-stream reassembly queue; QUIC fragments via STREAM offsets. FRCP fragments best-effort flows too, but the receiver drops the broken prefix the moment a later run-start (<code>FIRST</code> or <code>SOLE</code> role) is visible inside the <code>RQ_SIZE</code>-wide reorder ring - no IP-frag-style timeout, no SCTP-style explicit abort. If no later run-start arrives within the ring, <code>frag_run_inspect</code> returns <code>NOT_READY</code> and the partial run keeps its slots; the next inspect retries. The trade-off: a permanently-lost <code>MID</code> in a long isolated run holds slots until either a later <code>FIRST</code>/<code>SOLE</code> appears in the ring or the writer stops, at which point the slots are reclaimed on flow teardown.
* Reassembly deferred to consume time ([[#7.2. Fragmentation and reassembly|Section 7.2]]), message mode only (<code>qos.service == SVC_MESSAGE</code>): SCTP (RFC 9260 sec. 6.9), QUIC (RFC 9000 sec. 2.2), and TCP (RFC 9293) all hold reassembly state at the receive boundary. FRCP message-mode leaves fragments in the shared-memory ring until <code>flow_read</code> pulls and lands the SDU directly in the caller's buffer. Stream mode ([[#16. Stream-mode flows|Section 16]]) uses the standard QUIC-style direct ring placement on receive and does not defer. The optimisation is enabled by the Shared-Memory Subsystem (SSM) packet-buffer ring (see <code>struct ssm_pk_buff</code> at [[#1.1. PCI header|Section 1.1]]); the analogue is OS-level scatter-gather I/O (<code>recvmsg+iovec</code>), not a transport-layer prior art.
* TLP-equivalent tail-loss recovery (RFC 8985 sec. 7; RFC 9002 sec. 6.2): FRCP does not emit an explicit Tail Loss Probe packet, but the same goal is met implicitly by RACK loss detection ([[#8. Retransmission|Section 8]]) firing on a non-advancing cumulative ACK once the head-of-line slot ages past the RACK reorder window <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> - well below <code>RTO = max(2 * SRTT, SRTT + (mdev << MDEV_MUL))</code>. A receiver-driven nudge is also available via the pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]).

=== 15.2. Not adopted ===

* Slow start, congestion window (cwnd), Additive Increase / Multiplicative Decrease (AIMD), NewReno cwnd inflation. Congestion control lives in the IPCP CA policies and is driven by Explicit Congestion Notification (ECN, RFC 3168).
* Nagle / silly-window-syndrome (SWS) avoidance (RFC 896, RFC 1122 sec. 4.2.3.4). (Deferred work, not adopted in the current spec.)
* TCP Timestamps (RFC 7323) / Protection Against Wrapped Sequences (PAWS) - RTT measurement uses RTTP, not per-segment timestamps. A peer-supplied timestamp echoed on every ACK lets a malicious peer drive the <code>srtt</code> estimate arbitrarily low, collapsing the RTO and triggering a self-inflicted retransmit storm. RTTP confines RTT measurement to nonce-authenticated probe round-trips, where a forged echo is rejected before it can reach the estimator.
* ECN (Explicit Congestion Notification) response inside FRCP (consumed by IPCP Congestion Avoidance / CA).
* 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).

== 16. Stream-mode flows ==

When a flow is allocated with <code>qos.service == SVC_STREAM</code> both peers
switch to byte-stream semantics, layered on top of the FRTX reorder
machinery already described in Sections [[#6. Receive path|6]]-[[#8. Retransmission|8]].

=== 16.1. Send ===

The sender splits the caller's octets into chunks of at most
<code>(frag_mtu - base PCI - stream PCI extension)</code> octets (Sections [[#1.1. PCI header|1.1]]
and [[#1.5. Stream PCI extension|1.5]]). Each chunk is one DATA packet with its own <code>seqno</code> and a
<code>[start, end)</code> byte range copied from a monotonic stream counter.
In stream mode <code>FFGM</code> and <code>LFGM</code> are unused and MUST be transmitted as
zero; the per-byte position is carried by the <code>[start, end)</code>
extension instead.

End-of-stream is signalled with a 0-byte DATA packet that has <code>FIN</code>
(bit 12) set, emitted on the FIN triggers listed in [[#1.2. Flag bits|Section 1.2]]
(WR-half close, <code>flow_dealloc</code>, and any other path that yields the
final byte). The sender MUST emit at most one FIN per flow; its
<code>[start, end)</code> MUST equal <code>[final-byte, final-byte)</code> (i.e., empty
interval at the final byte position; final-size invariance,
analogous to QUIC RFC 9000 sec. 4.5). Idempotency is enforced by
an <code>snd_fin_sent</code> guard.

=== 16.2. Receive ===

On arrival the receiver places the payload directly into a per-flow
byte-indexed receive ring of width <code>ring_sz</code> (octets) at the position
indicated by <code>start</code>, with a two-segment <code>memcpy</code> across the ring
boundary if needed. Receipt is recorded in the FRTX reorder
machinery ([[#6.2. Locked main path|Section 6.2]]) augmented with the packet's <code>start</code>, <code>end</code>, and
FIN bit per slot. When a packet's <code>[start, end)</code> front-overlaps
bytes already at or below the byte high-water mark, the overlap is
trimmed before placement so the same byte is never written twice.
After stashing, the receiver advances <code>lwe</code> and the byte high-water
mark across any newly-contiguous prefix. Each slot advanced MUST
satisfy <code>start == the last-delivered slot's end</code>; a slot whose
<code>start</code> does not equal that <code>end</code> is silently dropped at delivery time
(the <code>seqno</code> is consumed, no stream bytes contributed) and the high-
water mark does not advance past it. The stream byte-stream
stalls at that point - there is no flow-tear-down on mismatch.
This filters spliced or off-path-injected slots that fall in
window without strong cryptographic authentication.

A FIN slot marks end-of-stream at advance time only if its byte
position equals the last-delivered slot's <code>end</code>; otherwise the FIN
is ignored and the corresponding <code>seqno</code> occupies a slot but
contributes no stream bytes. No packet buffer is held after the
ring copy.

=== 16.3. Read ===

<code>flow_read</code> returns up to <code>count</code> octets from the contiguous prefix
<code>[next, high-water)</code>, where <code>next</code> is the byte the application has
already consumed up to and <code>high-water</code> is the rightmost contiguous
byte received. When the stream is fully drained AND end-of-stream
(EOS) was observed (<code>next == EOS</code> byte position), <code>flow_read</code> returns
0 (<code>EOF</code>) - the same shape POSIX <code>read(2)</code> uses on TCP after a peer
FIN.

=== 16.4. Flow control ===

ACK / SACK / RACK / RTO machinery is unchanged; the FRTX reorder
ring is reused as a per-<code>seqno</code> received-bitmap. Let <code>per_pkt =
(frag_mtu - base PCI - stream PCI extension)</code>, the maximum stream-
byte payload one DATA packet can carry ([[#16.1. Send|Section 16.1]]). The
receive window advertised in FC is clamped so the byte window
(<code>ring_sz</code>) cannot be overrun: the <code>seqno</code>-space <code>rwe</code> is at most
<code>rcv_cr.lwe + ring_sz / per_pkt</code>.

This is the QUIC byte-credit flow-control model
(<code>MAX_STREAM_DATA</code>, RFC 9000 sec. 4.1 and sec. 19.10) projected onto
<code>seqno</code> space. With one stream per flow there is no <code>MAX_DATA</code> /
<code>MAX_STREAM_DATA</code> distinction. Receiver-side silly-window-syndrome
(SWS) avoidance (RFC 9293 sec. 3.8.6.2.2) is achieved by combining
the consume-time <code>rwe</code> bump with the global non-shrink rule from
[[#11. Flow control|Section 11]].

=== 16.5. Security considerations ===

Threat model. An attacker that can observe (on-path passive) or
predict (off-path blind) the flow's seqnos and byte offsets on an
unencrypted stream flow can inject DATA or FIN at any in-window
position. The in-line consistency checks above (<code>start</code> == prior
<code>end</code> on advance; FIN MUST be 0-byte; FIN MUST sit at the final
byte position) realise the spirit of RFC 5961's "sequence-window
plus exact-position match for control bits" without an explicit
challenge-ACK probe; they make a few specific blind attack shapes
harder but are not cryptographic authentication. This is
comparable to TCP without the TCP Authentication Option (TCP-AO,
RFC 5925), tighter than a
pre-RFC-5961 TCP stack, and roughly equivalent to a modern
RFC 5961 stack against blind off-path injection - none of these
help once the attacker can sniff. TLS over TCP (RFC 8446)
encrypts only the TCP payload and leaves TCP seqnos, ACKs, FIN,
and RST in the clear, so TLS does NOT defend against TCP-header-
level injection; QUIC (RFC 9000) hides packet numbers under
header protection (RFC 9001 sec. 5.4), so this specific weakness
does not apply to QUIC.

Mitigation: AEAD. When the flow has encryption enabled the
recommended AEAD ciphers (AES-GCM, RFC 5288; or ChaCha20-Poly1305,
RFC 8439) wrap the entire FRCP packet on the wire - PCI, stream
extension, body, and the CRC trailer when <code>ber == 0</code> - under a
per-flow symmetric key derived from the flow's own key exchange
([[#1.1. PCI header|Section 1.1]]). The AEAD tag (~2^-128 forgery probability)
dominates the CRC (~2^-32) for integrity in this mode but the CRC
trailer is currently retained inside the wrap (see [[#1.1. PCI header|Section 1.1]]).
Implementations MUST NOT rely on the security properties below
when a non-AEAD cipher (e.g. AES-CTR alone) is negotiated; non-
AEAD modes provide confidentiality only and the threat-model
claims do not hold.

With an AEAD cipher in use, seqnos, byte offsets, and the FIN bit
are both authenticated and confidential. Against an off-path or
on-path-passive attacker this is:

* Stronger than TCP+TLS (TCP header in the clear).
* Stronger than TCP+TCP-AO (header authenticated but visible).
* 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. 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 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
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 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 ==

This section lists the IETF documents, published works, and
source-code references cited inline elsewhere in this document.
IETF documents are cited inline as "RFC NNNN sec. X.Y"; books,
journal papers, and source-code references are cited inline by
author and year (or by file and function name) and are listed
here for convenience.

=== 17.1. IETF documents ===

;[RFC 791]
:J. Postel, "Internet Protocol", STD 5, RFC 791, September 1981.
;[RFC 793]
:J. Postel, "Transmission Control Protocol", STD 7, RFC 793, September 1981. Obsoleted by RFC 9293.
;[RFC 813]
:D. D. Clark, "Window and Acknowledgement Strategy in TCP", RFC 813, July 1982.
;[RFC 896]
:J. Nagle, "Congestion Control in IP/TCP Internetworks", RFC 896, January 1984.
;[RFC 1122]
:R. Braden (ed.), "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
;[RFC 2018]
:M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
;[RFC 2119]
:S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
;[RFC 2883]
:S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
;[RFC 3758]
:R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
;[RFC 3828]
:L-A. Larzon, M. Degermark, S. Pink, L-E. Jonsson (ed.), G. Fairhurst (ed.), "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
;[RFC 4303]
:S. Kent, "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
;[RFC 4340]
:E. Kohler, M. Handley, S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
;[RFC 5288]
:J. Salowey, A. Choudhury, D. McGrew, "AES Galois Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, August 2008.
;[RFC 5595]
:G. Fairhurst, "The Datagram Congestion Control Protocol (DCCP) Service Codes", RFC 5595, September 2009.
;[RFC 5681]
:M. Allman, V. Paxson, E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
;[RFC 5925]
:J. Touch, A. Mankin, R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
;[RFC 5961]
:A. Ramaiah, R. Stewart, M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, August 2010.
;[RFC 6298]
:V. Paxson, M. Allman, J. Chu, M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, June 2011.
;[RFC 6528]
:F. Gont, S. Bellovin, "Defending against Sequence Number Attacks", RFC 6528, February 2012. Obsoletes RFC 1948.
;[RFC 6582]
:T. Henderson, S. Floyd, A. Gurtov, Y. Nishida, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 6582, April 2012.
;[RFC 7323]
:D. Borman, B. Braden, V. Jacobson, R. Scheffenegger (ed.), "TCP Extensions for High Performance", RFC 7323, September 2014.
;[RFC 7675]
:M. Perumal, D. Wing, R. Ravindranath, T. Reddy, M. Thomson, "Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness", RFC 7675, October 2015.
;[RFC 8174]
:B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017.
;[RFC 8200]
:S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, July 2017.
;[RFC 8439]
:Y. Nir, A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 8439, June 2018.
;[RFC 8446]
:E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, August 2018.
;[RFC 8985]
:Y. Cheng, N. Cardwell, N. Dukkipati, P. Jha, "The RACK-TLP Loss Detection Algorithm for TCP", RFC 8985, February 2021.
;[RFC 9000]
:J. Iyengar (ed.), M. Thomson (ed.), "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, May 2021.
;[RFC 9001]
:M. Thomson (ed.), S. Turner (ed.), "Using TLS to Secure QUIC", RFC 9001, May 2021.
;[RFC 9002]
:J. Iyengar (ed.), I. Swett (ed.), "QUIC Loss Detection and Congestion Control", RFC 9002, May 2021.
;[RFC 9147]
:E. Rescorla, H. Tschofenig, N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, April 2022.
;[RFC 9260]
:R. Stewart, M. Tuexen, K. Nielsen, "Stream Control Transmission Protocol", RFC 9260, June 2022. Obsoletes RFC 4960.
;[RFC 9293]
:W. Eddy (ed.), "Transmission Control Protocol (TCP)", STD 7, RFC 9293, August 2022. Obsoletes RFC 793 and several follow-ons; updates RFC 1122 and others.

=== 17.2. Books and journal papers ===

;[Day08]
:J. Day, "Patterns in Network Architecture: A Return to Fundamentals", Prentice Hall, 2008.
;[Grasa15]
:E. Grasa et al., "IRATI: investigating RINA as an alternative to TCP/IP", Computer Networks, Vol. 92, December 2015.
;[KP87]
:P. Karn, C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", ACM SIGCOMM, August 1987.
;[Wat81]
:R. W. Watson, "Timer-Based Mechanisms in Reliable Transport Protocol Connection Management", Computer Networks, Vol. 5, 1981.

=== 17.3. Source-code references ===

;[Linux-RTT]
:<code>tcp_rtt_estimator()</code> in <code>net/ipv4/tcp_input.c</code> of the Linux kernel, defining the asymmetric <code>mdev</code> variance update used as FRCP's default RTT estimator ([[#12. RTT estimation|Section 12]]). Line-stable browseable copy at https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_input.c.

[[Category:Protocols]]
[[Category:Ouroboros internals]]

Flow and Retransmission Control Protocol

2026-05-17T15:24:25Z

Dimitri: /* 1.3. SACK payload */

{{DISPLAYTITLE:FRCP - Flow and Retransmission Control Protocol}}

FRCP runs end-to-end between two peers over a flow. It delivers
reliability, in-order delivery, flow control, and liveness.
Congestion Control (CC) is not in FRCP - that lives in the IPC
Process (IPCP) Congestion Avoidance (CA) policies, orthogonal to
FRCP. Flow allocation, naming, and IPCP lifecycle are handled by
the IPC Resource Manager daemon (IRMd).

FRCT (Flow and Retransmission Control Task) is the libouroboros
implementation of FRCP; the task lives in <code>src/lib/frct.c</code>. The
remainder of this document describes the FRCP wire protocol and the
behaviour FRCT realises. Code symbols retain the <code>FRCT_</code> prefix
(<code>FRCT_DATA</code>, <code>FRCT_RXM</code>, ...) because they belong to the implementing
task; this document references them verbatim.

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in <code>BCP</code> 14 (Best
Current Practice; RFC 2119, RFC 8174) when, and only when, they
appear in all capitals.

== Notation ==

;<code>u32</code>, <code>u8</code>
:Unsigned 32-bit / 8-bit integers (kernel-C style).
;<code>ns</code>
:Nanoseconds.

Modular sequence-number comparators (32-bit, modulo 2^32):

;<code>before(a, b)</code>
:<code>(int32_t)(a - b) < 0</code>
;<code>after(a, b)</code>
:<code>before(b, a)</code>

Used throughout for <code>ackno</code> / <code>seqno</code> ordering checks.

Round-Trip Time (RTT) abbreviations used throughout:

;<code>SRTT</code>
:Smoothed RTT estimate (RFC 6298).
;<code>mdev</code>
:Mean deviation of RTT (Linux variance estimator).
;<code>EWMA</code>
:Exponentially Weighted Moving Average.
;<code>RTO</code>
:Retransmission Timeout, <code>max(RTO_MIN, srtt + (mdev << MDEV_MUL))</code>.

Timer-bound symbols <code>t_a</code> (a-timer, ACK delay) and <code>t_r</code> (r-timer,
retransmission window) are defined in [[#8. Retransmission|Section 8]]; <code>t_mpl</code> (Maximum
Packet Lifetime) is introduced in [[#2.1. Per-flow state|Section 2.1]] (the <code>inact</code> field)
with heritage in [[#15. Heritage and adopted techniques|Section 15]].

Wire-format diagrams follow the IETF convention: bit 0 is the
leftmost (most significant) bit and fields are in network byte
order unless stated otherwise.

__TOC__

== 1. Wire format ==

=== 1.1. PCI header ===

Fixed 16-octet base Protocol-Control Information (PCI) header
prefixed to every FRCP packet (RFC convention: bit 0 leftmost,
most-significant bit first). All multi-byte fields except <code>hcs</code>
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
[[#1.5. Stream PCI extension|Section 1.5]]); SACK and RTTP carry their own payloads after the
base PCI.

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | hcs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ackno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload (variable) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>flags</code>
:feature/type bitmap (see [[#1.2. Flag bits|Section 1.2]]).
;<code>hcs</code>
:CRC-16-CCITT-FALSE Header Check Sequence (HCS) over <code>flags</code> + <code>window</code> + <code>seqno</code> + <code>ackno</code> (+ stream extension when present); the two octets of the <code>hcs</code> field itself are omitted from the CRC input. Verified on receive before any flag-driven dispatch.
;<code>window</code>
:receiver-advertised right window edge (valid iff FC).
;<code>seqno</code>
:per-flow sequence number.
;<code>ackno</code>
:cumulative Acknowledgement (ACK) (valid iff ACK).

A single packet can simultaneously carry DATA + ACK + FC (Flow
Control) + RXM (Retransmission) by ORing flag bits; the PCI
multiplexes control on the same wire frame in the spirit of SCTP
chunk bundling (RFC 9260 sec. 6.10) and QUIC frame multiplexing
(RFC 9000 sec. 12.4). DATA-bearing packets carry the caller's
payload after the PCI; SACK (Selective Acknowledgement) and RTTP
(Round-Trip Time Probe) carry their own typed payloads after the
PCI.

Optional framing (per-flow, see [[#2.2. Service modes (orthogonal axes)|Section 2.2]]). On the wire, the
order from inside out is:

{| class="wikitable"
! Layer !! Scope
|-
| <code>[ PCI + body ]</code>
| The FRCP packet.
|-
| <code>[ PCI + body + CRC-32 ]</code>
| CRC-32 covers the body only (PCI is in HCS); appended iff <code>qs.ber == 0</code> on DATA, or on every SACK packet.
|-
| <code>[ AEAD-wrap of above ]</code>
| Iff Authenticated Encryption with Associated Data (AEAD) is enabled.
|}

* 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.
* 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>).

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

=== 1.2. Flag bits ===

Flag bits are numbered most-significant-bit first to match the wire
diagram (bit numbering per [[#1.1. PCI header|Section 1.1]]; bit 0 is the MSB of the
16-bit <code>flags</code> field and lands at wire-position 0 in network byte
order). Bits 13..15 are reserved and MUST be transmitted as zero.

{| class="wikitable"
! Bit !! Mask !! Name !! Meaning
|-
| 0 || <code>0x8000</code> || <code>DATA</code> || Carries caller payload
|-
| 1 || <code>0x4000</code> || <code>DRF</code> || Data Run Flag: start of a fresh run
|-
| 2 || <code>0x2000</code> || <code>ACK</code> || Acknowledgement: <code>ackno</code> field valid
|-
| 3 || <code>0x1000</code> || <code>NACK</code> || Negative ACK; <code>seqno = arrival_seqno-1</code>
|-
| 4 || <code>0x0800</code> || <code>FC</code> || Flow Control: <code>window</code> field valid (<code>rwe</code>)
|-
| 5 || <code>0x0400</code> || <code>RDVS</code> || Rendezvous probe (window-closed)
|-
| 6 || <code>0x0200</code> || <code>FFGM</code> || First Fragment (role bit 0; see below)
|-
| 7 || <code>0x0100</code> || <code>LFGM</code> || Last Fragment (role bit 1; see below)
|-
| 8 || <code>0x0080</code> || <code>RXM</code> || Retransmission
|-
| 9 || <code>0x0040</code> || <code>SACK</code> || Selective ACK block list in payload
|-
| 10 || <code>0x0020</code> || <code>RTTP</code> || RTT Probe / echo (payload follows)
|-
| 11 || <code>0x0010</code> || <code>KA</code> || Keepalive
|-
| 12 || <code>0x0008</code> || <code>FIN</code> || End-of-stream marker (stream mode)
|-
| 13-15 || -- || -- || Reserved (MUST be zero)
|}

The (<code>FFGM</code>, <code>LFGM</code>) pair encodes the fragment role of a DATA-bearing
Service Data Unit (SDU), SCTP-style begin/end flags (RFC 9260
sec. 3.3.1):

{| class="wikitable"
! FFGM !! LFGM !! Role
|-
| 1 || 1 || Sole / un-fragmented SDU (begin AND end)
|-
| 1 || 0 || First fragment of a multi-fragment SDU
|-
| 0 || 0 || Middle fragment
|-
| 0 || 1 || Last fragment
|}

Each fragment is carried in its own FRCP packet with its own <code>seqno</code>;
FRTX (the FRCT Retransmission service mode, see [[#2.2. Service modes (orthogonal axes)|Section 2.2]])
recovers individual fragments via the normal Retransmission Timeout
(RTO) / SACK / Recent Acknowledgement (RACK, RFC 8985) path. The
receiver reassembles the SDU at consume time once the contiguous
[FIRST .. LAST] run has fully arrived. On non-DATA packets the role
bits are unused and MUST be transmitted as zero.

In stream mode (<code>qos.service == SVC_STREAM</code>, see [[#16. Stream-mode flows|Section 16]]) there are
no SDU boundaries to encode, so <code>FFGM</code> and <code>LFGM</code> are unused and MUST
be transmitted as zero. End-of-stream uses a dedicated bit (<code>FIN</code>,
bit 12) carried on a 0-byte DATA packet, emitted at write-half close
(<code>fccntl</code> to <code>FLOWFRDONLY</code>), during linger drain, and at <code>flow_dealloc</code>;
emission is idempotent (first call wins). After contiguous delivery
of the FIN-bearing slot, the receiver latches <code>byte_fin</code> at the FIN's
start offset; <code>flow_read</code> returns 0 (end-of-file, <code>EOF</code>) once buffered
bytes have been drained up to <code>byte_fin</code>. Per-byte position is
carried by the [start, end) extension ([[#1.5. Stream PCI extension|Section 1.5]]).

=== 1.3. SACK payload ===

A SACK packet has the <code>FRCT_ACK | FRCT_FC | FRCT_SACK</code> flag bits set
(bit numbering per [[#1.1. PCI header|Section 1.1]]). Following the 16-octet PCI, the
payload is a 2-octet block count (network byte order), 2 octets of
padding to 4-byte align the block list, then <code>n_blocks</code> pairs of
32-bit start/end seqnos describing ''present'' (received) ranges
above the cumulative ACK.

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_blocks | padding (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start[0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end[0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... n_blocks pairs total ...
</syntaxhighlight>

<code>n_blocks <= SACK_MAX_BLOCKS</code> (2048). The per-flow effective cap is
further bounded by <code>(frag_mtu - PCI - 4) / 8</code> blocks per packet; SACK
packets carry no stream extension, so PCI here is the 16-octet base
header even on stream-mode flows.

Wire invariant: every block produced by the receiver, except an
optional leading Duplicate SACK (D-SACK) block as described below,
describes a range strictly above the cumulative ACK carried in the
PCI <code>ackno</code> field (<code>after(start[i], ackno)</code>). This makes the D-SACK
convention below unambiguous; the receiver-side builder MUST
preserve it.

Duplicate SACK (D-SACK, RFC 2883) is signalled in-band: no flag
bit, no extra framing. Modular seqno arithmetic uses the
<code>before()</code> / <code>after()</code> comparators defined in the Notation block.

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)
:<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)
:<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.

The <code>reo_wnd_mult</code> halving cadence (once per 16 cumulatively-ACK'd
seqnos since the most-recent D-SACK arrival or halve event) and
the reset-to-1 on a HoL RTO fire are both per the same RFC 8985
clause. The clamp-and-skip path in the regular SACK-mark loop is
incidentally idempotent on any leftover case-1 or case-2 block
(<code>start < snd_cr.lwe</code> clamps to <code>snd_cr.lwe</code> and the inner loop
skips <code>k == snd_cr.lwe</code>; case-2 re-NULLs slots already marked
received by later blocks), so block[0] is harmless even when fed
to the loop.

=== 1.4. RTTP payload ===

An RTTP (Round-Trip Time Probe) packet has only the <code>FRCT_RTTP</code> flag
set (bit numbering per [[#1.1. PCI header|Section 1.1]]). Following the 16-octet PCI,
the payload is 24 octets (packed):

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| probe_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| echo_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ nonce (16 octets, echoed verbatim) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>probe_id</code>
:sender counter, 0 on reply, 0 reserved.
;<code>echo_id</code>
:peer's <code>probe_id</code>, 0 on outbound probe.
;<code>nonce</code>
:random, echoed unmodified, memcmp'd to defeat spoof.

=== 1.5. Stream PCI extension ===

A stream-mode flow (<code>qos.service == SVC_STREAM</code>) carries an extra
8-octet extension after the 16-octet base PCI on every DATA packet
(bit numbering per [[#1.1. PCI header|Section 1.1]]):

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>start</code>
:octet offset of the first payload byte in the stream.
;<code>end</code>
:octet offset one past the last payload byte; <code>end - start</code> equals the on-wire payload length.

Total stream-mode PCI for DATA packets is 24 octets (16 base + 8
extension); control packets (SACK, RTTP, bare ACK, KA, etc.) retain
the 16-octet base PCI. Stream mode MUST be negotiated at flow
allocation; the extension is present iff stream mode is in use,
never on a per-packet basis. Both peers MUST treat <code>start</code>/<code>end</code> as
monotonic 32-bit byte offsets; when a slot reaches the head of the
contiguous run with <code>start</code> not equal to the prior packet's <code>end</code> the
slot is silently dropped at delivery time ([[#16. Stream-mode flows|Section 16]]) rather
than rejected at stash.

This is the QUIC STREAM-frame reassembly model (RFC 9000 sec. 19.8):
each packet carries its packet <code>seqno</code> (this PCI's <code>seqno</code> field) and a
separate stream byte position (<code>start</code>/<code>end</code>). Separating the two
avoids TCP's conflation of packet identity with byte position which
forces Karn's algorithm for Round-Trip Time (RTT) sampling (no RTT
sample on retransmits, RFC 6298 sec. 3); FRCP applies the
Karn-equivalent gate via a combination of per-packet <code>FRCT_RXM</code>,
per-slot <code>SND_RTX</code> flags, and a sample-fence <code>rtt_lwe</code> (see [[#2.1. Per-flow state|Section 2.1]]
and [[#12. RTT estimation|Section 12]]). FRCP's fixed-32-bit <code>start</code>/<code>end</code> wrap at 4 GiB of
wire bytes, narrower than QUIC's 62-bit varint offset (cf. RFC 9000
sec. 16); the on-wire wrap is handled by the same modular <code>before()</code>
/ <code>after()</code> comparators ([[#1.3. SACK payload|Section 1.3]]) FRCP uses for seqnos, which
remain unambiguous as long as the in-flight byte window stays
strictly under 2 GiB (the half-range of the signed-int32 difference
in <code>before()</code>). The default per-flow ring is 1 MiB; the
implementation caps <code>ring_sz</code> at 128 MiB (<code>FRCT_STREAM_RING_SZ_MAX</code>),
well below the 2 GiB half-range bound. The runtime byte counters
exposed via FUSE (Filesystem in Userspace) in the Ouroboros
Resource Information Base (RIB, a virtual-filesystem introspection
bridge) are platform <code>size_t</code> and do not wrap on 64-bit hosts.

== 2. Per-flow state and service modes ==

=== 2.1. Per-flow state ===

Each flow keeps a sender control record and a receiver control
record:

;<code>lwe</code> : <code>u32</code>
:snd: oldest unacked <code>seqno</code> (cumulative ACK boundary as seen by sender); rcv: next in-order <code>seqno</code> expected
;<code>rwe</code> : <code>u32</code>
:snd: peer-advertised right window edge; rcv: locally-advertised right window edge
;<code>cflags</code> : <code>u8</code>
:per-direction feature flags: retransmission (<code>FRCTFRTX</code>), receiver flow control (<code>FRCTFRESCNTL</code>), linger-on-close (<code>FRCTFLINGER</code>); see <code><ouroboros/fccntl.h></code>
;<code>seqno</code> : <code>u32</code>
:snd: next <code>seqno</code> to send; rcv: force-ACK trigger - set on a stale or dup DATA so the next <code>ack_snd</code> emits a fresh cumulative ACK
;<code>ackno</code> : <code>u32</code>
:snd: <code>seqno</code> counter for standalone ACK-bearing control packets (delayed ACK, SACK, final ACK on dealloc); not bumped on piggybacked ACK riding a DATA packet (which uses the DATA <code>seqno</code>). Used by wire-dup ACK detection; rcv: incoming-ACK dedup tracker
;<code>act</code> : <code>ns</code>
:last activity (used by inactivity / DRF)
;<code>inact</code> : <code>ns</code>
:inactivity threshold; sender = <code>3*mpl + a + r + 1s</code>, receiver = <code>2*mpl + a + r + 1s</code>. <code>mpl</code> is the Maximum Packet Lifetime (delta-t terminology; see [[#15. Heritage and adopted techniques|Section 15]]); <code>a</code> and <code>r</code> are the FRCT a-timer and r-timer bounds (see [[#8. Retransmission|Section 8]]). The asymmetry is load-bearing for pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]).

The sender holds a per-slot ring <code>snd_slots[RQ_SIZE]</code> keyed by
<code>(seqno mod RQ_SIZE)</code>. Each slot tracks its retransmit entry (<code>rxm</code>),
last-send timestamp, and retransmit flag bits: <code>SND_RTX</code> (a
retransmit is pending or has fired, gates the next RTT sample
under Karn) and <code>SND_FAST_RXM</code> (one-shot fast-retransmit staged for
this loss event).

The receiver holds a parallel reorder ring <code>rcv_slots[RQ_SIZE]</code>
(referred to as <code>rq[]</code> in prose) holding stashed out-of-order
packet-buffer indexes; both FRTX and best-effort flows share this
path. The invariant <code>rwe - lwe <= RQ_SIZE</code> holds: on each consume
the receiver advances <code>rwe</code> by the consumed count, capping the
receive window at <code>RQ_SIZE</code> <code>seqno</code> slots.

A separate fence variable <code>rtt_lwe</code> is bumped on every retransmit
(timer-fire, SACK-driven, fast-rxm, NACK-driven) and on every
<code>seqno_rotate</code> ([[#4. Sequence-number rotation (DRF)|Section 4]]) to mark the <code>seqno</code> range whose RTT samples
MUST be discarded.

=== 2.2. Service modes (orthogonal axes) ===

FRCP exposes its wire features as a vector of independent QoS
axes selected at flow allocation time. All flows go through the
same <code>flow_alloc(name, qos, ...)</code> primitive; the <code>qosspec_t</code> passed
in determines which protocol machinery engages on the wire. This
contrasts with the POSIX BSD socket model where TCP and UDP
require different socket types (<code>SOCK_STREAM</code> / <code>SOCK_DGRAM</code>).

The axes:

;<code>service</code>
:0 = unordered (no FRCP engagement: raw datagrams, no PCI on the wire, UDP-equivalent at this layer); 1 = message-ordered (FRCP engaged; SDU boundaries preserved across fragmentation); 2 = stream (byte-oriented, no SDU boundaries; FRTX required)
;<code>loss</code>
:0 = lossless service requested: FRTX retransmit machinery engages ([[#8. Retransmission|Section 8]]); MUST be 0 for <code>service=2</code>. Non-zero = best-effort, FRTX off.
;<code>ber</code>
:Bit Error Rate tolerance. 0 = error-free service requested: a CRC trailer is appended after the body of DATA packets and verified on receive (added / checked outside the FRCP PCI; see [[#1.1. PCI header|Section 1.1]]). Non-zero = peer accepts errors; trailer omitted. SACK control packets carry a CRC32 trailer regardless of <code>ber</code>; the <code>ber</code> gate applies to DATA only.
;<code>timeout</code>
:Peer-timeout (ms); 0 disables the keepalive timer. Independent of FRCP engagement.

Encryption is a separate per-flow attribute set at flow setup;
when enabled it wraps the FRCP packet (PCI + body, plus the CRC
trailer if any) under AEAD, expanding the <code>spb</code> by <code>headsz</code> + <code>tailsz</code>
octets (nonce / tag). The CRC trailer is currently kept inside
the AEAD wrap (see [[#1.1. PCI header|Section 1.1]]).

Reachable combinations exported by <code>include/ouroboros/qos.h</code>:

{| class="wikitable"
! Cube !! <code>service</code> !! <code>loss</code> !! <code>ber</code> !! Engaged
|-
| <code>qos_raw</code> || 0 || 1 || 1 || Raw passthrough
|-
| <code>qos_raw_safe</code> || 0 || 1 || 0 || Raw + CRC trailer
|-
| <code>qos_rt</code> || 1 || 1 || 1 || FRCP, no FRTX, no CRC
|-
| <code>qos_rt_safe</code> || 1 || 1 || 0 || FRCP, no FRTX, CRC
|-
| <code>qos_msg</code> || 1 || 0 || 0 || FRCP + FRTX
|-
| <code>qos_stream</code> || 2 || 0 || 0 || FRCP + FRTX, stream
|}

Forced couplings actually enforced by the public API:

* <code>service == SVC_STREAM</code> (2) requires <code>loss == 0</code>; <code>flow_alloc</code> / <code>flow_accept</code> reject the pair otherwise with <code>-EINVAL</code>.
* FRTX requires FRCP engagement (<code>service != SVC_RAW</code>); requesting <code>loss = 0</code> with <code>service = SVC_RAW</code> is structurally a no-op because no <code>frcti</code> is created.
* The <code>QOS_DISABLE_CRC</code> build flag globally forces <code>ber = 1</code>. Note: this flag defaults to ON, so default builds ship with CRC disabled until <code>QOS_DISABLE_CRC</code> is set to OFF.

Caveat: the API does NOT force <code>ber = 0</code> when <code>service != SVC_RAW</code>.
<code>qos_rt</code> has <code>service = SVC_MESSAGE</code> with <code>ber = 1</code>, which means the PCI
itself is not CRC-protected on that cube; the HCS ([[#1.1. PCI header|Section 1.1]])
remains the only integrity check on the header.

The FRCP-no-FRTX regime (<code>service = SVC_MESSAGE</code>, <code>loss > 0</code>) is meaningful
and live: sequence numbering, in-order delivery, flow-control
advertisement, KA, DRF rotation, and SDU fragmentation /
reassembly ([[#7.2. Fragmentation and reassembly|Section 7.2]]) all run. Lost packets are dropped
rather than retransmitted; a permanently-lost mid-fragment is
dropped via skip-past-gap once a later SDU is visible in the
reorder ring.

== 3. Protocol parameters ==

{| class="wikitable"
! Parameter !! Value !! Role
|-
| <code>RQ_SIZE</code> || compile-time, power of 2 (default 128) || Slot ring / rcv window width
|-
| <code>START_WINDOW</code> || compile-time, power of 2 (default 128) || Initial <code>rwe-lwe</code> after rotate
|-
| <code>RTO_MIN</code> || <code>MAX(250 us build-tunable, 1<<RXMQ_RES)</code>; per-flow via <code>fccntl</code> (<code>FRCTSRTOMIN</code>). Default ~1 ms with <code>RXMQ_RES=20</code>. || RTO floor; also floored at the retransmit-wheel resolution (~1 ms by default).
|-
| <code>MAX_RTO_MUL</code> || 20 || Backoff shift cap
|-
| RACK window <code>R</code> || <code>MIN(reo_wnd_mult * min_RTT/4, SRTT)</code> with <code>MIN_REORDER_NS = 250 us</code> floor; <code>reo_wnd_mult</code> scales on D-SACK, cap 20 || Reorder window; per RFC 8985 sec. 6.2; <code>reo_wnd_mult</code> per sec. 6.2 step 4
|-
| <code>MIN_RTT_WIN_NS</code> || 300 s (5 min, Linux <code>tcp_min_rtt_wlen</code>) || <code>min_RTT</code> windowed re-anchor
|-
| <code>REO_WND_MULT_MAX</code> || 20 (RFC 8985 sec. 6.2 step 4) || <code>reo_wnd_mult</code> cap
|-
| <code>REO_DECAY_PKTS</code> || 16 (RFC 8985 sec. 6.2 step 4 / <code>RACK.reo_wnd_persist</code>) || Fresh-ACK'd seq count per halving
|-
| <code>MAX_DSACK_LAG</code> || <code>RQ_SIZE</code> || D-SACK sanity cap
|-
| <code>RTT_QUARANTINE</code> || 32 (<code>seqno</code> steps) || NewReno gate pad
|-
| SACK rate-limit || <code>SACK_MIN_GAP_NS</code> (250 us, fixed) || Min SACK gap
|-
| <code>SACK_MAX_BLOCKS</code> || 2048 (wire cap; per-flow capped at <code>(frag_mtu-PCI-4)/8</code>) || Per-SACK block cap
|-
| <code>SACK_RXM_MAX</code> || 32 || Per-pass staged retransmit cap
|-
| <code>DUP_THRESH</code> || 3 (RFC 8985 default) || Hybrid fast-rxm trigger ([[#8. Retransmission|Section 8]])
|-
| <code>MDEV_MUL</code> || 2 (build-tunable via <code>FRCT_RTO_MDEV_MULTIPLIER</code>) || <code>mdev</code> shift in <code>RTO = srtt + (mdev << MDEV_MUL)</code>
|-
| RTTP nonce || 16 octets || Echoed verbatim
|-
| <code>RTTP_RING</code> || 8 || In-flight probes
|-
| RTT clamp || <code>16 * srtt</code> || Probe-sample upper bound (ACK-derived RTT samples gated by Karn / recovery only)
|-
| Cold-probe cadence || 100 ms (rx-driven; see [[#12. RTT estimation|Section 12]]) || Pre-<code>srtt</code> RTTP rate
|-
| <code>DELT_RDV</code> || 100 ms || RDVS emit cadence
|-
| <code>MAX_RDV</code> || 1 s || RDVS give-up
|-
| Delayed-ACK fire || <code>2 * TICTIME</code> (<code>TICTIME</code> = FRCT tick granularity, default 5 ms; <code>2*TICTIME = 10 ms</code> by default) || Fired after the first in-order DATA arrival; tick is build-tunable
|-
| NACK send cooldown || <code>srtt</code> when an <code>srtt</code> sample exists, else 100 ms || Pre-DRF NACK rate-limit
|-
| <code>MAX_SDU</code> || 1 MiB || Max reassembled SDU; configurable per flow
|}

The per-flow fragment Maximum Transmission Unit (MTU) is computed
at flow setup from the lower IPCP's mtu minus encryption
<code>headsz</code> / <code>tailsz</code> and CRC trailer; there is no FRCT-level default or
environment-variable override.

== 4. Sequence-number rotation (DRF) ==

The DRF (Data Run Flag) bit on an outbound packet means "this is
the start of a fresh data run" and is set whenever the sender has
nothing in flight (<code>snd_cr.seqno == snd_cr.lwe</code>).

Independently of that, if the sender has been idle longer than
<code>snd_cr.inact</code> AND the pipe is empty (<code>snd_cr.seqno == snd_cr.lwe</code>),
<code>seqno_rotate()</code> rolls a random new <code>seqno</code> before the send and
resets

<syntaxhighlight lang="text">
snd_cr.seqno = random()
snd_cr.lwe = snd_cr.seqno
snd_cr.rwe = snd_cr.seqno + START_WINDOW
rtt_lwe = snd_cr.seqno
in_recovery = false (recovery state, see Section 8)
recovery_high = snd_cr.seqno
</syntaxhighlight>

The receiver, on observing rcv-side inactivity
(<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
below). Non-DATA control packets pass through without the DRF
requirement. On DRF the receiver releases the <code>rq[]</code> slots and
rebases

<syntaxhighlight lang="text">
rcv_cr.lwe = seqno
rcv_cr.rwe = seqno + RQ_SIZE
rcv_cr.seqno = seqno
</syntaxhighlight>

If the inactive packet has DATA but no DRF, a rate-limited NACK is
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).

== 5. Send path ==

# If the SDU exceeds <code>(frag_mtu - data_hdr_len)</code>, the caller (<code>dev.c</code>) fans it out into <code>ceil(count / (frag_mtu - data_hdr_len))</code> fragments, each emitted via <code>frcti_snd</code> as its own DATA packet with a per-fragment role ([[#7.2. Fragmentation and reassembly|Section 7.2]]); both FRTX and best-effort flows fragment. Raw flows (no FRCP engagement, <code>qos.service == SVC_RAW</code>) carry no PCI and return <code>-EMSGSIZE</code> for any SDU larger than one packet at the layer below. An SDU that fits in a single packet is sent as SOLE. <code>frcti_snd</code> reserves PCI head room; sets DATA, plus DRF when the pipe is empty (<code>snd_cr.seqno == snd_cr.lwe</code>).
# <code>seqno_rotate()</code> if past sender inactivity and the pipe is empty ([[#4. Sequence-number rotation (DRF)|Section 4]]).
# Advertise FC (<code>pci.window = frcti_advert_rwe(frcti)</code>, i.e. <code>rcv_cr.rwe</code> clamped to <code>rcv_cr.lwe + ring_seq_cap</code> in stream mode) when the receiver side is recent: <code>now - rcv_cr.act < rcv_cr.inact</code>.
# Reliable mode (FRTX): leave <code>snd_cr.lwe</code> where it is; reset the slot at <code>RQ_SLOT(seqno)</code> (<code>snd_slots[p].time = now</code>, <code>snd_slots[p].flags = 0</code>); queue an <code>rxm_entry</code> (saves a packet copy, arms a wheel timer at <code>now + (rto << rto_mul)</code>). Piggyback ACK (<code>pci.ackno = rcv_cr.lwe</code>) while the a-timer for the most recent received DATA packet has not yet expired (<code>now - rcv_cr.act <= t_a</code>); on piggyback, set <code>rcv_cr.seqno = rcv_cr.lwe</code> so the next delayed-ACK fire is suppressed. See [[#8. Retransmission|Section 8]] for <code>t_a</code> / <code>t_r</code> semantics.
# Best-effort mode (no FRTX): advance <code>snd_cr.lwe</code> immediately (<code>snd_cr.lwe = snd_cr.lwe + 1</code>, <code>snd_cr.rwe = snd_cr.lwe + RQ_SIZE</code>); no retransmit state. No send-side RTT probe is armed in this mode (<code>rtt_probe_arm</code> requires an in-flight <code>seqno</code>, which best-effort never has); the rx-driven cold seeder in <code>frcti_rcv</code> is the only probe path.
# In reliable mode, optionally arm an RTT probe ([[#12. RTT estimation|Section 12]]).

== 6. Receive path ==

=== 6.1. Early-exit dispatch ===

Keepalive (KA), RTT probe (RTTP), pre-DRF NACK, and rendezvous
(RDVS) packets short-circuit out of <code>frcti_rcv</code> before the locked
main path; each handler takes its own lock internally.

<syntaxhighlight lang="text">
incoming packet
|
v
+---------+
| KA? |---yes--> ka_rcv ; return
+---------+
|no
v
+---------+
| RTTP? |---yes--> rttp_rcv; return
+---------+
|no
v
+---------+
| NACK? |---yes--> nack_rcv; return (see Section 9)
+---------+
|no
v
+---------+
| RDVS? |---yes--> rdv_rcv ; return (reply bare FC, ackno=0)
+---------+
|no
v
acquire wrlock; enter locked main path
</syntaxhighlight>

;<code>KA</code>
:refresh <code>t_ka_rcv</code>, honour piggybacked ACK.
;<code>RTTP</code>
:probe (echo back nonce) or echo (verify nonce, sample RTT).
;<code>NACK</code>
:pre-DRF, sender-side handler. See [[#9. Pre-DRF NACK|Section 9]].
;<code>RDVS</code>
:reply with a bare FC packet (<code>ackno = 0</code>); <code>rdlock</code> only.

=== 6.2. Locked main path ===

Steps below run with the per-flow <code>frcti.lock</code> held for writing
(<code>pthread_rwlock_wrlock</code>) unless noted.

;<code>rcv_inact_check</code>
:Only meaningful when the receive side is stale. On DRF (Data Run Flag): release <code>rq[]</code> slots, rebase <code>rcv_cr</code>, continue. On stale DATA without DRF: fire a pre-DRF NACK if cooldown allows ([[#9. Pre-DRF NACK|Section 9]]), then discard the packet; on cooldown, drop without sending a NACK (a pending cumulative ACK from <code>drop_packet</code> may still go out). Non-DATA, non-DRF arrivals bypass <code>rcv_inact_check</code> entirely; pure-DRF stale arrivals fall through after the DRF rebase branch.

;DATA-only act refresh
:Refresh <code>rcv_cr.act</code> only when <code>FRCT_DATA</code> is set, so that non-DATA packets never block the next DRF rebase.

;Wire-dup gate
:Before flag-driven dispatch, drop wire-duplicate ACKs and wire-duplicate DATA (<code>is_dup_ack</code> / <code>is_dup_data</code>). The DATA check is bypassed for <code>FRCT_RXM</code>-bearing arrivals so the piggybacked ACK / SACK / FC carried on a retransmitted DATA at an already-ACK'd <code>seqno</code> is still applied; the stale-in-window branch below then drops the packet.

;<code>ACK</code>
:Drop ACKs whose <code>ackno</code> falls outside <code>(snd_cr.lwe, snd_cr.seqno]</code>. If <code>ackno == snd_cr.lwe</code> (non-advancing cumulative ACK), drive RACK fast-retransmit consideration ([[#8. Retransmission|Section 8]]). Otherwise advance <code>snd_cr.lwe = ackno</code>, collapse <code>rto_mul</code> to 0 (Karn-gated by <code>SND_RTX</code> on the just-acknowledged slot, the old head-of-line), reset <code>dup_thresh</code> to 0, update <code>t_latest_ack</code> to the send-time of the slot at <code>ackno-1</code> (consumed by RACK and SACK below), decay <code>reo_wnd_mult</code> per RFC 8985 sec. 6.2 step 4, exit NewReno-careful recovery (see [[#8. Retransmission|Section 8]]) on <code>ackno >= recovery_high</code> or <code>ackno == snd_cr.seqno</code>, and feed an RTT sample if eligible ([[#12. RTT estimation|Section 12]]).

;<code>SACK</code>
:Walk the block list. For each block (a present range above <code>lwe</code>) NULL out <code>snd_slots[k].rxm</code>, clear the slot's per-send flags, and advance <code>t_latest_ack</code> to the latest send-time covered (the Forward Acknowledgement / fack equivalent, Mathis & Mahdavi 1996); the first block whose start clamps to <code>snd_cr.lwe</code> skips this fack update so that a head-of-line clamp does not falsely advance fack. For un-SACKed gaps below <code>hi_sacked</code>, stage a retransmit per slot that is (1) still owned (<code>rxm != NULL</code>), (2) not already <code>SND_FAST_RXM</code>, (3) not aged out past <code>t_r</code>, and (4) either outside the RACK reorder window <code>R</code> OR with <code>dup_thresh >= DUP_THRESH</code> (the RFC 8985 sec. 6.2 hybrid trigger). Mark the slot <code>SND_FAST_RXM</code> and NULL the <code>rxm</code> at stage time. Capped at <code>SACK_RXM_MAX</code> staged retransmits per receive pass; what's left rides the next SACK.

;<code>FC</code>
:Bump <code>snd_cr.rwe</code> (clamped to <code>lwe + RQ_SIZE</code>, never shrinks) and mark window open.

;<code>DATA</code>
:Bounds-check <code>seqno</code> against window. On stale-dup (<code>seqno < rcv_cr.lwe</code>), set <code>rcv_cr.seqno = seqno</code> to force a fresh ACK on the next <code>ack_snd</code>, then drop. On accept: both FRTX and best-effort stash the packet-buffer index into <code>rq[seqno mod RQ_SIZE]</code>. Fragments stash unchanged - the role bits are inspected only at consume time ([[#7.2. Fragmentation and reassembly|Section 7.2]]). On out-of-order arrival, build a SACK reply if not rate-limited (per [[#3. Protocol parameters|Section 3]]) and not deduplicated against the previous <code>(rcv_cr.lwe, n_blocks)</code> pair; D-SACK reports always bypass the dedup. If both rate-limit and dedup suppress the reply, neither SACK nor delayed-ACK fires (the sender picks up the gap on its next ACK). On in-order arrival, arm the delayed-ACK timer.

;<code>drop_packet</code> exit
:Releases the per-packet shared-memory buffer (<code>spb</code>), then calls <code>ack_snd</code> synchronously after the <code>spb</code> release to surface any pending cumulative ACK.

== 7. Read path and reassembly ==

=== 7.1. Read path ===

<code>flow_read</code> returns a full reassembled SDU (Service Data Unit) via
<code>frcti_consume</code> on every FRCP SDU-mode flow (FRTX or best-effort);
stream-mode is covered in [[#16. Stream-mode flows|Section 16]]. An incomplete head-of-line
(HoL) run yields <code>-EAGAIN</code>; an oversized run yields <code>-EMSGSIZE</code> (the
run is dropped so the flow does not stall). On best-effort flows,
a permanently-lost mid-fragment is dropped as soon as a later
complete SDU becomes visible in the ring ([[#7.2. Fragmentation and reassembly|Section 7.2]] skip-past-
gap).

Raw flows carry no <code>frcti</code>, so <code>flow_read</code> returns the next pending
packet-buffer index directly, with no role-bit inspection. (Raw
service is selected via <code>qos.service == SVC_RAW</code> at flow allocation,
which suppresses <code>frcti</code> creation.)

<code>frcti_pdu_ready</code> is the no-advance peek used by <code>fevent</code> (the
Ouroboros flow-event multiplexer, the <code>poll(2)</code>-equivalent on
flows). It returns ready only when the head-of-line run is
complete and the lead packet (a Protocol Data Unit, here one FRCP
packet) is present at <code>rcv_cr.rwe - RQ_SIZE</code>; any other state
(including the best-effort skip-past-gap case) returns not ready,
and <code>frcti_consume</code> is left to drop the broken prefix and re-
inspect.

=== 7.2. Fragmentation and reassembly ===

Send side (<code>flow_write_frag</code>). An SDU larger than
<code>(frag_mtu - PCI)</code> is split into <code>ceil(count / (frag_mtu - PCI))</code>
fragments; each fragment is its own FRCP packet with its own
<code>seqno</code> and a per-fragment role flag pair ([[#1.2. Flag bits|Section 1.2]]). Roles are
assigned at emit time:

{| class="wikitable"
! i !! Role
|-
| <code>n=1</code> || <code>SOLE</code>
|-
| <code>i=0</code> || <code>FIRST</code>
|-
| <code>i=n-1</code> || <code>LAST</code>
|-
| else || <code>MID</code>
|}

A mid-loop allocation or transmit failure may yield a partial
write: the call returns the bytes already enqueued (<code>off > 0</code>) or
the underlying error (<code>off == 0</code>). Best-effort flows fragment
identically; on the receiver, a partial run with a permanently-
lost fragment is dropped when a later complete SDU is visible in
the ring (see skip-past-gap below). Raw flows carry no PCI and
refuse anything larger than the layer's user MTU (<code>-EMSGSIZE</code>).

Wire-level recovery is fragment-agnostic on FRTX flows: each
fragment's <code>seqno</code> flows through SACK / RACK / RTO / NACK exactly
as for a SOLE DATA packet, and reassembly does not re-enter the
loss-detection path. Best-effort flows run the same <code>seqno</code>
machinery (DRF, FC, ACK piggyback, pre-DRF NACK emit) but queue
no <code>rxm</code> state at the sender, so a lost MID is unrecoverable;
skip-past-gap handles it (below).

Receive side. Fragments stash into <code>rq[seqno]</code> unchanged; role bits
are read only at consume time. <code>frag_run_inspect</code>, called from
<code>frcti_consume</code>, walks the ring starting at the oldest still-
undelivered <code>seqno</code> <code>base = rcv_cr.rwe - RQ_SIZE</code> (equal to <code>rcv_cr.lwe</code>
only when no partial run is in progress; during a partial run <code>lwe</code>
has already advanced past <code>base</code>). It produces one of three
outcomes:

{| class="wikitable"
! Outcome !! Cause
|-
| <code>DELIVER (n)</code>
| <code>rq[base]=SOLE</code> (<code>n=1</code>), or <code>rq[base]=FIRST</code> and a <code>LAST</code> follows in slots <code>[base+1..base+n-1]</code> with all intermediate roles in <code>{MID,FIRST,LAST}</code> contiguous.
|-
| <code>DROP (n)</code>
| <code>rq[base]</code> is <code>MID</code> or <code>LAST</code> without a preceding <code>FIRST</code> (<code>n=1</code>); a <code>FIRST..[non-LAST]..new-FIRST</code> or new-<code>SOLE</code> mid-run (drop the broken prefix with <code>n</code> = run length minus 1, so the new <code>FIRST</code>/<code>SOLE</code> stays); or, on best-effort flows, a gap at <code>base</code> with a <code>FIRST</code>/<code>SOLE</code> later in the ring (drop up to the new run start).
|-
| <code>NOT_READY</code>
| <code>rq[base]</code> absent or <code>FIRST..[non-LAST]</code> with no later <code>FIRST</code>/<code>SOLE</code> in the ring (FRTX waits for retx; best-effort waits for arrival).
|}

<code>DELIVER</code> triggers <code>frag_gather</code>: a scatter-gather <code>memcpy</code> of the <code>n</code>
consecutive fragments at <code>rq[base..base+n-1]</code> directly into the
caller's buffer; each per-packet shared-memory buffer (<code>spb</code>) is
released and <code>rwe</code> advances by <code>n</code>. <code>lwe</code> was already advanced
incrementally as each contiguous fragment arrived; <code>frag_gather</code>
only restores the fixed-width invariant <code>rwe == lwe + RQ_SIZE</code>.
No intermediate reassembly buffer is allocated.

<code>DROP</code> advances <code>rwe</code> past the broken prefix (releasing the <code>spb</code>s)
and pulls <code>lwe</code> up to the new trailing edge if needed; the next
consume retries from the new <code>base</code>. Oversize or arithmetically
overflowing delivery (sum of fragment lengths > <code>max_rcv_sdu</code>, sum
> caller's buffer, or running-sum overflow) also drops the run
with <code>-EMSGSIZE</code>.

Skip-past-gap (best-effort only). On FRTX, a gap in the run means
"waiting for retransmit" and <code>frag_run_inspect</code> returns <code>NOT_READY</code>.
On best-effort flows the gap is permanent, so <code>frag_run_inspect</code>
scans forward in the ring for the next <code>FIRST</code> or <code>SOLE</code>; if one is
visible within <code>RQ_SIZE</code>, it returns <code>DROP</code> for the broken prefix and
the consume loop retries at the new <code>lwe</code>. Memory hold is bounded
by <code>RQ_SIZE</code>; the partial releases on the next consume call once a
later complete run exists. Voice-like flows (one <code>SOLE</code> per SDU)
see no extra wait: any later <code>SOLE</code> makes the prior gap droppable
immediately.

The choice to defer reassembly to consume time keeps the receive
path zero-copy: fragments stay in the shared-memory ring until
the application pulls, and the SDU lands directly in the caller's
buffer.

== 8. Retransmission ==

FRCP is bounded by two delta-t-derived timers (Watson 1981, see
[[#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_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.

Each in-flight FRTX <code>seqno</code> owns one <code>rxm_entry</code>, armed in a hashed
timing wheel; the wheel deadline is the slot's next eligible
retransmit time.

;RTO timer
:On fire (<code>rxm_due</code>), re-emit with <code>FRCT_RXM</code>, mark <code>SND_RTX</code> (Karn-suppress next ACK's RTT sample), and (for the head-of-line (HoL) slot only) bump <code>rto_mul</code> up to <code>MAX_RTO_MUL</code>. Wheel deadline is <code>t_send + (rto << rto_mul)</code>. Re-armed unless consumed. The RTO timer also clears <code>SND_FAST_RXM</code> (re-arming fast-retransmit eligibility), resets <code>reo_wnd_mult</code> to 1 on a HoL fire (RFC 8985 sec. 6.2 step 4 reset clause), and marks the flow <code>ACL_FLOWDOWN</code> if its <code>frct_tx</code> call fails.

;r-timer guard
:Before any retransmit attempt, check <code>(now - t0)</code> against <code>t_r</code>. If exceeded, the slot is no longer eligible for retransmit. Only the RTO timer (<code>rxm_due</code>) treats r-timer expiry as terminal: it marks the flow <code>ACL_FLOWDOWN</code> (peer unreachable). Fast-retransmit, SACK-driven retransmit, and NACK-driven head-of-line re-emit silently skip aged-out slots and defer the flow-down decision to the next RTO fire.

;Fast retransmit (hybrid trigger, RFC 8985 sec. 6.2)
:On a non-advancing cumulative ACK with the scoreboard advanced, fire one fast retransmit when EITHER (a) the head-of-line slot's latest send is older than the RACK reorder window <code>R</code> ([[#3. Protocol parameters|Section 3]]) and not yet aged out, OR (b) the SACK <code>dup-thresh</code> count above <code>snd_cr.lwe</code> reaches <code>DUP_THRESH</code> (= 3, RFC 8985 sec. 6.2 step 4). Fires at most once per non-advancing cumulative-ACK value, gated by <code>rack_fired_lwe</code> (the <code>snd_cr.lwe</code> at which fast-retransmit last fired). Set <code>SND_FAST_RXM</code> on the slot (one-shot per-slot gate) and enter NewReno-style careful recovery (see NewReno below in this section).
:The RACK reorder window <code>R</code> uses the RFC 8985 sec. 6.2 form <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> with a <code>MIN_REORDER_NS = 250 us</code> floor. Before the first RTT sample seeds <code>min_rtt</code>, <code>R</code> falls back to <code>MIN(reo_wnd_mult * SRTT / 4, SRTT)</code>, still floored at <code>MIN_REORDER_NS</code> (consistent with the windowed-minimum fallback described in [[#12. RTT estimation|Section 12]]). <code>min_rtt</code> is a windowed minimum over the last <code>MIN_RTT_WIN_NS</code> = 5 min of RTT samples (matches the Linux <code>tcp_min_rtt_wlen</code> default) so a route change to a longer path eventually re-anchors the reorder window without relying on <code>reo_wnd_mult</code> growth alone.

;SACK-driven retransmit
:For each gap below <code>hi_sacked</code> whose slot is (1) still owned, (2) not already <code>SND_FAST_RXM</code>, (3) not aged out past <code>t_r</code>, and (4) either outside the RACK window <code>R</code> OR with <code>dup_thresh >= DUP_THRESH</code> (same hybrid as fast-retransmit, see [[#6.2. Locked main path|Section 6.2]]), re-emit. Each SACK-driven retransmit re-arms a fresh <code>rxm</code> so a lost retransmit can still be recovered by its own RTO timer.

;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.

== 9. Pre-DRF NACK ==

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.

;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>)
:When an incoming DATA packet has no DRF and rcv-side activity is older than <code>rcv_cr.inact</code>, the receiver emits a bare packet with <code>flags = FRCT_NACK</code> and <code>seqno = arrival_seqno - 1</code> (informational only, not consulted by the receive handler). The cooldown in [[#3. Protocol parameters|Section 3]] rate-limits the burst. Non-DATA non-DRF arrivals bypass <code>rcv_inact_check</code> entirely; non-DATA DRF still rebases via the DRF branch.

;Receive (<code>frcti_nack_rcv</code>)
: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 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.

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 ==

Cumulative ACK is <code>ackno = rcv_cr.lwe</code>. On out-of-order arrival the
receiver also emits a SACK packet ([[#1.3. SACK payload|Section 1.3]]) whose payload lists
''present'' blocks above <code>lwe</code> (analogous to TCP SACK / QUIC ACK
ranges). SACKs are rate-limited per [[#3. Protocol parameters|Section 3]] and suppressed when
neither <code>lwe</code> nor block count has changed since the last SACK.

D-SACK reports (RFC 2883) are emitted in-band as <code>block[0]</code> of an
otherwise normal SACK frame (see [[#1.3. SACK payload|Section 1.3]] for the encoding).
Two receiver triggers arm a pending D-SACK report (single-slot,
latest-wins):

* DATA arrival with <code>seqno < rcv_cr.lwe</code>, both wire-dup (no RXM, <code>is_dup_data</code> path) and retransmit (RXM, post-FC branch) (RFC 2883 sec. 4.1.1, full duplicate)
* <code>rq_accept</code> conflict, slot already occupied in <code>[lwe, rwe)</code> (RFC 2883 sec. 4.1.2, partial duplicate)

When a D-SACK is pending and the standard scoreboard SACK would be
suppressed by dedup or rate-limit, the report is emitted as a
stand-alone SACK frame through the normal <code>ack_snd</code> path; when a
D-SACK report is pending the path bypasses dedup and the <code>TICTIME</code>
rate-limit, but the a-timer suppression on rcv inactivity still
applies.

Bare ACKs are deferred via a per-flow delayed-ACK timer (one in
flight at a time, atomic test-and-set dedup; fires per [[#3. Protocol parameters|Section 3]]
after the first in-order arrival). Suppressed if (1) no new
<code>seqno</code>, (2) rcv side is inactive (older than <code>t_a</code>), or (3) the
sender just sent within <code>TICTIME</code>. A pending D-SACK ride-through
bypasses (1) and (3); the a-timer gate (2) is unconditional.

== 11. Flow control ==

The receiver advertises <code>rwe</code> in every FC field. The sender treats
its <code>snd_cr.rwe</code> as the absolute right edge: when
<code>snd_cr.seqno >= snd_cr.rwe</code> the window is closed and <code>flow_write</code>
yields. While closed, the sender periodically emits RDVS
(rendezvous) packets (cadence <code>DELT_RDV</code>); the receiver replies with
a bare FC packet (<code>ackno = 0</code>) that reopens the window. Once the
window has been closed for longer than <code>MAX_RDV</code> the sender stops
emitting RDVS but does not tear the flow down - the writer keeps
blocking until either a peer-driven FC arrives or the KA
(keepalive) / r-timer marks the flow.

<code>rwe</code> is clamped to <code>lwe + RQ_SIZE</code> on receipt and MUST NOT shrink:
a backward <code>rwe</code> is silently clamped to the current <code>snd_cr.rwe</code>;
the FC packet still reopens the window.

== 12. RTT estimation ==

Active RTTP probes ([[#1.4. RTTP payload|Section 1.4]]) carry a 32-bit <code>probe_id</code> (0
reserved) and a 16-byte random nonce echoed verbatim - defends
against spoofed replies. A ring of <code>RTTP_RING</code> in-flight probes is
kept; an echo whose <code>(id, nonce)</code> doesn't match the ring slot is
dropped. A single RTTP sample is clamped to <code>RTT_CLAMP_MUL * srtt</code>
(compile-time <code>RTT_CLAMP_MUL = 16</code>) once <code>srtt</code> is seeded; the first
cold-probe sample feeds <code>rtt_update</code> raw.

Probe arming gates:

;Cold (no <code>srtt</code> yet)
:the receive path arms at most one probe per 100 ms via <code>frcti_rcv_probe</code> (<code>PROBE_DUE_COLD</code>); arming requires an incoming packet. Active send-path arming bails while <code>srtt == 0</code>.
;Warm (<code>rtt_probe_arm</code>, called from <code>frcti_snd</code>)
:outstanding data (<code>snd_cr.seqno > snd_cr.lwe</code>), AND at least <code>2 * srtt</code> since <code>t_rcv_rtt</code> (last RTT receive of any kind), AND at least <code>srtt</code> since <code>t_snd_probe</code> (last probe emit).

Sample feeds either Linux's asymmetric <code>mdev</code> estimator
(<code>FRCT_LINUX_RTT_ESTIMATOR</code>, default ON) or RFC 6298 symmetric EWMA
(compile option). <code>srtt</code> is floored at 10 ms when seeded from a
hint, at 1 us after every update (including the first seeding
sample); <code>mdev</code> floored at 100 ns.

:<code>RTO = max(rto_min, 2 * srtt, srtt + (mdev << MDEV_MUL))</code>

(the <code>2 * srtt</code> floor is an FRCT addition not in RFC 6298).
Effective wheel deadline capped per [[#3. Protocol parameters|Section 3]].

ACK-derived samples (<code>frcti_ack_rcv</code> -> <code>rtt_sample_eligible</code>), beyond
the cum-ACK advance gate in <code>frcti_ack_rcv</code> (<code>ackno > lwe</code> and
<code>ackno <= seqno</code>), require all of: not in recovery; ACK packet does
not carry <code>FRCT_RXM</code>; HoL slot's <code>SND_RTX</code> bit clear; slot's <code>rxm</code>
pointer non-NULL (not SACK-consumed); <code>lwe</code> not below the <code>rtt_lwe</code>
fence; <code>srtt</code> already seeded by an RTTP probe. There is no ACK-only
seeding.

Every eligible sample also feeds <code>RACK.min_RTT</code> (RFC 8985 sec. 6.2)
via a windowed minimum: replace whenever the sample is strictly
smaller OR more than <code>MIN_RTT_WIN_NS</code> (5 min, matches Linux
<code>tcp_min_rtt_wlen</code>) has elapsed since the current min was set. The
downward branch is immediate (faster path picked up at once); the
upward branch is gated on the window (a transient queue burst does
not poison the estimate, but a sustained route change to a longer
path re-anchors <code>min_RTT</code> after at most one window). Seeded from
<code>rtt_hint</code> at <code>rtt_init</code>; 0 acts as the unset sentinel and the base
in <code>rack_reorder_window</code> falls back from <code>min_RTT</code> to <code>SRTT</code> (so
<code>R = mult * SRTT/4</code>, capped at <code>SRTT</code>, floored at <code>MIN_REORDER_NS</code>)
until the first sample. See [[#6.2. Locked main path|Section 6.2]].

== 13. Liveness (keepalive) ==

When <code>qs.timeout > 0</code> a per-flow KA (keepalive) timer is armed.
Arming uses <code>rcv_cr.act</code> for the deadline computation:

:<code>deadline = min(snd_act + qs.timeout/4, rcv_act + qs.timeout)</code>

(clamped to <code>now + qs.timeout/4</code> if already past). The timer fires
either on sender idleness (to send a KA) or on receiver idleness
(to declare the peer dead). On fire (<code>ka_snd</code>) the peer-dead test
uses <code>max(rcv_cr.act, t_ka_rcv)</code> so a recent KA reply counts even
when no DATA has arrived:

* If <code>now - max(rcv_cr.act, t_ka_rcv) > qs.timeout</code>, mark the flow <code>ACL_FLOWPEER</code> and notify the per-process flow-event set (<code>proc.fqset</code>) with <code>FLOW_PEER</code>.
* Else if <code>snd_idle > qs.timeout/4</code>, emit a bare <code>KA | ACK</code> (<code>ackno = rcv_cr.lwe</code>) and re-arm.
* Else just re-arm.

Note: <code>rx_rb</code> and <code>tx_rb</code> are the receive and transmit shared-memory
ring buffers. The r-timer raises <code>ACL_FLOWDOWN</code> on both (route is
broken); keepalive raises <code>ACL_FLOWPEER</code> on <code>rx_rb</code> only and notifies
the flow-event set (peer is silent, writer keeps <code>tx_rb</code> usable) -
distinct ACLs. <code>qs.timeout == 0</code> disables keepalive entirely; a
silent peer crash is then undetected.

== 14. Linger / teardown ==

On <code>flow_dealloc</code>, <code>frcti_dealloc</code> computes a grace timeout

:<code>max(rcv_cr.act + rcv_cr.inact, snd_cr.act + snd_cr.inact) - now</code>

(floored at 0 and converted to seconds) and returns it; <code>flow_dealloc</code>
forwards this to the IRMd as the dealloc grace. The IRMd, not FRCT,
performs the wait. Before computing the timeout, FRCT may emit a
final ACK when <code>rcv_cr.lwe != rcv_cr.seqno</code> (the peer has not been
told the most recent cumulative ACK) AND the rcv side has been
active within <code>t_a</code> (a-timer not aged out).

<code>FRCTFLINGER</code> is honoured only when <code>snd_cr.lwe < edge</code>, where <code>edge =
snd_fin_seqno</code> after FIN has been sent in stream mode and
<code>snd_cr.seqno</code> otherwise (data or FIN still in flight). The drain
itself runs in <code>flow_dealloc</code>'s <code>while (FRCTI_LINGERING)</code> loop, not in
<code>frcti_dealloc</code>.

The fd is single-reader / single-writer (documented in the
manpages). <code>flow_write</code> pumps <code>rx_rb</code> on every call (via
<code>flow_wait_window</code> -> <code>flow_drain_rx_nb</code>) and additionally blocks on
<code>rx_rb</code> when the send window is closed. A pure-writer thread thus
consumes ACKs without a dedicated reader.

== 15. Heritage and adopted techniques ==

Delta-t (Watson, 1981) is the primary heritage; FRCP descends from
the delta-t protocol family via the Recursive InterNetwork
Architecture (RINA; Day, "Patterns in Network Architecture", 2008,
ch. 9). Timer-based connection management
(no SYN/FIN handshake, per-flow state born on first DATA and
reclaimed after <code>t_mpl + a + r</code> of silence), the DRF marker, and the
<code>t_mpl</code> / <code>t_a</code> / <code>t_r</code> timers all come from delta-t. See Watson,
"Timer-Based Mechanisms in Reliable Transport Protocol Connection
Management", Computer Networks 5 (1981).

The unified <code>flow_alloc(name, qos, ...)</code> primitive and its
multi-axis QoS-cube argument ([[#2.2. Service modes (orthogonal axes)|Section 2.2]]) also come from RINA
(Day 2008, ch. 6; Grasa et al., "IRATI: investigating RINA as an
alternative to TCP/IP", Computer Networks 92 (2015)) - reliability,
ordering, CRC presence, and encryption are flow attributes, not
separate sockets or protocols.

The table below summarises additional adopted techniques and their
references.

{| class="wikitable"
! FRCP mechanism !! Heritage !! Reference / note
|-
| Random new <code>seqno</code> on <code>seqno_rotate</code> || TCP ISN || RFC 6528 (Gont & Bellovin, 2012). QUIC PN-space reset (RFC 9000 sec. 12.3) is a structural analogue.
|-
| Cumulative ACK, left-window-edge advance || TCP || RFC 793 / RFC 9293
|-
| Receive window with non-shrink rule || TCP || RFC 793 sec. 3.7 / RFC 9293 sec. 3.8.6; RFC 1122 sec. 4.2.2.16 for the explicit non-shrink prohibition
|-
| Modular <code>seqno</code> arithmetic (<code>before</code>/<code>after</code> helpers) || TCP || RFC 793 sec. 3.3 / RFC 9293 sec. 3.4
|-
| Selective ACK block list || TCP || RFC 2018 (Mathis et al., 1996). Encoded as a typed FRCP packet rather than a TCP option, so framing is closer to QUIC ACK frames. D-SACK (RFC 2883) carried in-band as <code>block[0]</code>; see [[#1.3. SACK payload|Section 1.3]].
|-
| NewReno-careful recovery with <code>recovery_high</code> gate || TCP || RFC 6582 (Henderson et al., 2012); QUIC builds on the same model in RFC 9002 sec. 7.3.2. Cwnd half absent (CC in IPCP).
|-
| RACK reordering window for fast retransmit || TCP || RFC 8985 (Cheng et al., 2021). FRCP <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> with a <code>MIN_REORDER_NS = 250 us</code> floor against <code>srtt</code> collapse; matches RFC 8985 sec. 6.2 and Linux <code>tcp_rack_reo_wnd</code>. DSACK-driven <code>reo_wnd_mult</code> (sec. 6.2 step 4) is adopted; see [[#1.3. SACK payload|Section 1.3]] for the wire encoding. The hybrid RACK-or-<code>DUP_THRESH</code> trigger from RFC 8985 sec. 6.2 step 4 is adopted ([[#8. Retransmission|Section 8]]). QUIC's analogue in RFC 9002 sec. 6.1.2 uses <code>max(srtt, latest_rtt)</code> as the base.
|-
| 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> = 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.
|-
| Delayed ACK with rate suppression || TCP || RFC 813 (Clark, 1982); RFC 1122 sec. 4.2.3.2; RFC 5681 sec. 4.2. Single-deadline coalescing rather than "ack-every-other-segment".
|-
| Zero-window-probe / persist-timer analogue (RDVS) || TCP || RFC 1122 sec. 4.2.2.17 / RFC 9293 sec. 3.8.6.1. RDVS solicits an FC reply, distinct from QUIC <code>DATA_BLOCKED</code> (RFC 9000 sec. 19.12), which is one-way notification. <code>MAX_RDV</code> give-up departs from TCP.
|-
| Multiplexed control on a single PCI || SCTP / QUIC || SCTP chunk bundling (RFC 9260 sec. 6.10); QUIC frame multiplexing (RFC 9000 sec. 12.4). Cleaner fit than TCP's separate-flag-bits design.
|-
| ACK ranges as multiple discontiguous acked blocks || QUIC || QUIC ACK frame (RFC 9000 sec. 19.3). FRCP SACK is conceptually QUIC-frame-shaped even though encoded as absolute <code>[start,end]</code> pairs.
|-
| Nonce-authenticated active RTT / liveness probing (RTTP) || QUIC <code>PATH_CHALLENGE</code> || <code>PATH_CHALLENGE</code> / <code>PATH_RESPONSE</code> (RFC 9000 sec. 8.2, sec. 19.17, sec. 19.18). WebRTC ICE consent-freshness (RFC 7675) is the same pattern. QUIC's nonce is 8 octets; FRCP chooses 16.
|-
| Probing distinct from keepalive || QUIC || KA timer answers "peer alive?", RTTP answers "path measurable?", as in QUIC PING (RFC 9000 sec. 19.2) vs <code>PATH_CHALLENGE</code>.
|-
| Bare KA + ACK keepalive packets || QUIC / SCTP || QUIC PING (RFC 9000 sec. 19.2); SCTP HEARTBEAT / HEARTBEAT-ACK (RFC 9260 sec. 8.3). SCTP HEARTBEAT also carries an opaque echoed blob, structurally similar to FRCP RTTP.
|-
| (<code>FFGM</code>, <code>LFGM</code>) fragment-role bits ([[#7.2. Fragmentation and reassembly|Section 7.2]]) || SCTP || RFC 9260 sec. 3.3.1 DATA chunk B/E bits encode the same four states (<code>B+E=SOLE</code>, <code>B-only=FIRST</code>, neither=<code>MID</code>, <code>E-only=LAST</code>). Each fragment carries its own <code>seqno</code>/TSN and is independently retransmitted.
|-
| Stream byte-offset reassembly (Sections [[#1.5. Stream PCI extension|1.5]], [[#16. Stream-mode flows|16]]) || QUIC || QUIC STREAM frame (RFC 9000 sec. 19.8) uses Offset + Length varints; FRCP uses fixed 32-bit <code>start</code> / <code>end</code>. One stream per flow vs QUIC's many streams multiplexed.
|-
| FIN end-of-stream marker (Sections [[#1.2. Flag bits|1.2]], [[#16. Stream-mode flows|16]]) || TCP / QUIC || TCP FIN flag (RFC 9293 sec. 3.1) closes one half of the byte stream; QUIC STREAM frame FIN bit (RFC 9000 sec. 19.8) does the same per stream with an immutable final-size invariance (RFC 9000 sec. 4.5: the final size is fixed once observed). FRCP's FIN consumes one packet <code>seqno</code> (not one byte of stream space) and is idempotent on the sender side.
|-
| Stream byte-credit flow control ([[#16. Stream-mode flows|Section 16]]) || QUIC || <code>MAX_STREAM_DATA</code> (RFC 9000 sec. 4.1, sec. 19.10). FRCP projects a per-flow byte budget onto the <code>seqno</code>-space <code>rwe</code>. Single stream per flow collapses QUIC's <code>MAX_DATA</code> / <code>MAX_STREAM_DATA</code> distinction.
|-
| Header protection (encrypted seqnos) || QUIC || QUIC RFC 9001 sec. 5.4 applies header protection on top of AEAD to mask the packet number. FRCP's per-flow AEAD wrap ([[#16. Stream-mode flows|Section 16]]) is wider: it encrypts the entire PCI including <code>seqno</code> because the IPCP below already routes, so no destination connection-ID needs to stay in clear (cf. RFC 9000 sec. 5.2).
|-
| Two-bit fragment role polarity || SCTP || The (<code>FFGM</code>, <code>LFGM</code>) pair follows SCTP B/E (begin = 1 / end = 1) rather than IPv4 MF (RFC 791 sec. 3.2), which has the inverse polarity (MF = 1 means NOT last).
|-
| Orthogonal reliability / ordering axes ([[#2.2. Service modes (orthogonal axes)|Section 2.2]]) || SCTP || PR-SCTP (RFC 3758, per-message partial reliability) and SCTP DATA U-bit (RFC 9260 sec. 3.3.1, per-message unordered) are the closest precedents for decoupling reliability from ordering; FRCP sets them per-flow rather than per-message.
|-
| Orthogonal CRC (<code>qs.ber == 0</code>) || UDP-Lite || RFC 3828 (Larzon et al., 2004) lets the sender pick a per-packet Checksum Coverage and the receiver enforce a locally configured minimum (no in-band negotiation; sec. 3.1, sec. 3.3). FRCP gates a full CRC trailer on <code>qs.ber == 0</code> at flow setup. Contrast TCP / SCTP (mandatory checksum) and QUIC (AEAD subsumes CRC).
|-
| Setup-time service negotiation || DCCP / SCTP / QUIC || DCCP Service Codes (RFC 4340 sec. 8.1.2, RFC 5595); SCTP INIT parameters (RFC 9260 sec. 3.3.2); QUIC transport parameters (RFC 9000 sec. 7.4). All negotiate service properties at connection setup; only RINA's QoS cube exposes them as an orthogonal vector.
|}

=== 15.1. Original to FRCP (no clean prior art) ===

* Pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]): receiver-driven nudge exploiting <code>snd_cr.inact > rcv_cr.inact</code>. Closest analogues are SCTP Gap Ack Blocks (RFC 9260 sec. 3.3.4) and DCCP Ack Vector (RFC 4340 sec. 11.4) - both let the receiver describe gaps to the sender, but neither targets the cross-epoch / pre-DRF case.
* <code>MAX_RDV</code> window-probe give-up: neither TCP (persist-timer probes until application or R2 abort, RFC 9293 sec. 3.8.6.1) nor QUIC has an explicit FC-give-up counter. A recursive-network choice: outer layers can drop the flow.
* Skip-past-gap reassembly ([[#7.2. Fragmentation and reassembly|Section 7.2]]): SCTP fragments and reassembles every flow regardless of reliability/ordering, using its own per-stream reassembly queue; QUIC fragments via STREAM offsets. FRCP fragments best-effort flows too, but the receiver drops the broken prefix the moment a later run-start (<code>FIRST</code> or <code>SOLE</code> role) is visible inside the <code>RQ_SIZE</code>-wide reorder ring - no IP-frag-style timeout, no SCTP-style explicit abort. If no later run-start arrives within the ring, <code>frag_run_inspect</code> returns <code>NOT_READY</code> and the partial run keeps its slots; the next inspect retries. The trade-off: a permanently-lost <code>MID</code> in a long isolated run holds slots until either a later <code>FIRST</code>/<code>SOLE</code> appears in the ring or the writer stops, at which point the slots are reclaimed on flow teardown.
* Reassembly deferred to consume time ([[#7.2. Fragmentation and reassembly|Section 7.2]]), message mode only (<code>qos.service == SVC_MESSAGE</code>): SCTP (RFC 9260 sec. 6.9), QUIC (RFC 9000 sec. 2.2), and TCP (RFC 9293) all hold reassembly state at the receive boundary. FRCP message-mode leaves fragments in the shared-memory ring until <code>flow_read</code> pulls and lands the SDU directly in the caller's buffer. Stream mode ([[#16. Stream-mode flows|Section 16]]) uses the standard QUIC-style direct ring placement on receive and does not defer. The optimisation is enabled by the Shared-Memory Subsystem (SSM) packet-buffer ring (see <code>struct ssm_pk_buff</code> at [[#1.1. PCI header|Section 1.1]]); the analogue is OS-level scatter-gather I/O (<code>recvmsg+iovec</code>), not a transport-layer prior art.
* TLP-equivalent tail-loss recovery (RFC 8985 sec. 7; RFC 9002 sec. 6.2): FRCP does not emit an explicit Tail Loss Probe packet, but the same goal is met implicitly by RACK loss detection ([[#8. Retransmission|Section 8]]) firing on a non-advancing cumulative ACK once the head-of-line slot ages past the RACK reorder window <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> - well below <code>RTO = max(2 * SRTT, SRTT + (mdev << MDEV_MUL))</code>. A receiver-driven nudge is also available via the pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]).

=== 15.2. Not adopted ===

* Slow start, congestion window (cwnd), Additive Increase / Multiplicative Decrease (AIMD), NewReno cwnd inflation. Congestion control lives in the IPCP CA policies and is driven by Explicit Congestion Notification (ECN, RFC 3168).
* Nagle / silly-window-syndrome (SWS) avoidance (RFC 896, RFC 1122 sec. 4.2.3.4). (Deferred work, not adopted in the current spec.)
* TCP Timestamps (RFC 7323) / Protection Against Wrapped Sequences (PAWS) - RTT measurement uses RTTP, not per-segment timestamps. A peer-supplied timestamp echoed on every ACK lets a malicious peer drive the <code>srtt</code> estimate arbitrarily low, collapsing the RTO and triggering a self-inflicted retransmit storm. RTTP confines RTT measurement to nonce-authenticated probe round-trips, where a forged echo is rejected before it can reach the estimator.
* ECN (Explicit Congestion Notification) response inside FRCP (consumed by IPCP Congestion Avoidance / CA).
* 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).

== 16. Stream-mode flows ==

When a flow is allocated with <code>qos.service == SVC_STREAM</code> both peers
switch to byte-stream semantics, layered on top of the FRTX reorder
machinery already described in Sections [[#6. Receive path|6]]-[[#8. Retransmission|8]].

=== 16.1. Send ===

The sender splits the caller's octets into chunks of at most
<code>(frag_mtu - base PCI - stream PCI extension)</code> octets (Sections [[#1.1. PCI header|1.1]]
and [[#1.5. Stream PCI extension|1.5]]). Each chunk is one DATA packet with its own <code>seqno</code> and a
<code>[start, end)</code> byte range copied from a monotonic stream counter.
In stream mode <code>FFGM</code> and <code>LFGM</code> are unused and MUST be transmitted as
zero; the per-byte position is carried by the <code>[start, end)</code>
extension instead.

End-of-stream is signalled with a 0-byte DATA packet that has <code>FIN</code>
(bit 12) set, emitted on the FIN triggers listed in [[#1.2. Flag bits|Section 1.2]]
(WR-half close, <code>flow_dealloc</code>, and any other path that yields the
final byte). The sender MUST emit at most one FIN per flow; its
<code>[start, end)</code> MUST equal <code>[final-byte, final-byte)</code> (i.e., empty
interval at the final byte position; final-size invariance,
analogous to QUIC RFC 9000 sec. 4.5). Idempotency is enforced by
an <code>snd_fin_sent</code> guard.

=== 16.2. Receive ===

On arrival the receiver places the payload directly into a per-flow
byte-indexed receive ring of width <code>ring_sz</code> (octets) at the position
indicated by <code>start</code>, with a two-segment <code>memcpy</code> across the ring
boundary if needed. Receipt is recorded in the FRTX reorder
machinery ([[#6.2. Locked main path|Section 6.2]]) augmented with the packet's <code>start</code>, <code>end</code>, and
FIN bit per slot. When a packet's <code>[start, end)</code> front-overlaps
bytes already at or below the byte high-water mark, the overlap is
trimmed before placement so the same byte is never written twice.
After stashing, the receiver advances <code>lwe</code> and the byte high-water
mark across any newly-contiguous prefix. Each slot advanced MUST
satisfy <code>start == the last-delivered slot's end</code>; a slot whose
<code>start</code> does not equal that <code>end</code> is silently dropped at delivery time
(the <code>seqno</code> is consumed, no stream bytes contributed) and the high-
water mark does not advance past it. The stream byte-stream
stalls at that point - there is no flow-tear-down on mismatch.
This filters spliced or off-path-injected slots that fall in
window without strong cryptographic authentication.

A FIN slot marks end-of-stream at advance time only if its byte
position equals the last-delivered slot's <code>end</code>; otherwise the FIN
is ignored and the corresponding <code>seqno</code> occupies a slot but
contributes no stream bytes. No packet buffer is held after the
ring copy.

=== 16.3. Read ===

<code>flow_read</code> returns up to <code>count</code> octets from the contiguous prefix
<code>[next, high-water)</code>, where <code>next</code> is the byte the application has
already consumed up to and <code>high-water</code> is the rightmost contiguous
byte received. When the stream is fully drained AND end-of-stream
(EOS) was observed (<code>next == EOS</code> byte position), <code>flow_read</code> returns
0 (<code>EOF</code>) - the same shape POSIX <code>read(2)</code> uses on TCP after a peer
FIN.

=== 16.4. Flow control ===

ACK / SACK / RACK / RTO machinery is unchanged; the FRTX reorder
ring is reused as a per-<code>seqno</code> received-bitmap. Let <code>per_pkt =
(frag_mtu - base PCI - stream PCI extension)</code>, the maximum stream-
byte payload one DATA packet can carry ([[#16.1. Send|Section 16.1]]). The
receive window advertised in FC is clamped so the byte window
(<code>ring_sz</code>) cannot be overrun: the <code>seqno</code>-space <code>rwe</code> is at most
<code>rcv_cr.lwe + ring_sz / per_pkt</code>.

This is the QUIC byte-credit flow-control model
(<code>MAX_STREAM_DATA</code>, RFC 9000 sec. 4.1 and sec. 19.10) projected onto
<code>seqno</code> space. With one stream per flow there is no <code>MAX_DATA</code> /
<code>MAX_STREAM_DATA</code> distinction. Receiver-side silly-window-syndrome
(SWS) avoidance (RFC 9293 sec. 3.8.6.2.2) is achieved by combining
the consume-time <code>rwe</code> bump with the global non-shrink rule from
[[#11. Flow control|Section 11]].

=== 16.5. Security considerations ===

Threat model. An attacker that can observe (on-path passive) or
predict (off-path blind) the flow's seqnos and byte offsets on an
unencrypted stream flow can inject DATA or FIN at any in-window
position. The in-line consistency checks above (<code>start</code> == prior
<code>end</code> on advance; FIN MUST be 0-byte; FIN MUST sit at the final
byte position) realise the spirit of RFC 5961's "sequence-window
plus exact-position match for control bits" without an explicit
challenge-ACK probe; they make a few specific blind attack shapes
harder but are not cryptographic authentication. This is
comparable to TCP without the TCP Authentication Option (TCP-AO,
RFC 5925), tighter than a
pre-RFC-5961 TCP stack, and roughly equivalent to a modern
RFC 5961 stack against blind off-path injection - none of these
help once the attacker can sniff. TLS over TCP (RFC 8446)
encrypts only the TCP payload and leaves TCP seqnos, ACKs, FIN,
and RST in the clear, so TLS does NOT defend against TCP-header-
level injection; QUIC (RFC 9000) hides packet numbers under
header protection (RFC 9001 sec. 5.4), so this specific weakness
does not apply to QUIC.

Mitigation: AEAD. When the flow has encryption enabled the
recommended AEAD ciphers (AES-GCM, RFC 5288; or ChaCha20-Poly1305,
RFC 8439) wrap the entire FRCP packet on the wire - PCI, stream
extension, body, and the CRC trailer when <code>ber == 0</code> - under a
per-flow symmetric key derived from the flow's own key exchange
([[#1.1. PCI header|Section 1.1]]). The AEAD tag (~2^-128 forgery probability)
dominates the CRC (~2^-32) for integrity in this mode but the CRC
trailer is currently retained inside the wrap (see [[#1.1. PCI header|Section 1.1]]).
Implementations MUST NOT rely on the security properties below
when a non-AEAD cipher (e.g. AES-CTR alone) is negotiated; non-
AEAD modes provide confidentiality only and the threat-model
claims do not hold.

With an AEAD cipher in use, seqnos, byte offsets, and the FIN bit
are both authenticated and confidential. Against an off-path or
on-path-passive attacker this is:

* Stronger than TCP+TLS (TCP header in the clear).
* Stronger than TCP+TCP-AO (header authenticated but visible).
* 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. 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 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
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 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 ==

This section lists the IETF documents, published works, and
source-code references cited inline elsewhere in this document.
IETF documents are cited inline as "RFC NNNN sec. X.Y"; books,
journal papers, and source-code references are cited inline by
author and year (or by file and function name) and are listed
here for convenience.

=== 17.1. IETF documents ===

;[RFC 791]
:J. Postel, "Internet Protocol", STD 5, RFC 791, September 1981.
;[RFC 793]
:J. Postel, "Transmission Control Protocol", STD 7, RFC 793, September 1981. Obsoleted by RFC 9293.
;[RFC 813]
:D. D. Clark, "Window and Acknowledgement Strategy in TCP", RFC 813, July 1982.
;[RFC 896]
:J. Nagle, "Congestion Control in IP/TCP Internetworks", RFC 896, January 1984.
;[RFC 1122]
:R. Braden (ed.), "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
;[RFC 2018]
:M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
;[RFC 2119]
:S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
;[RFC 2883]
:S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
;[RFC 3758]
:R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
;[RFC 3828]
:L-A. Larzon, M. Degermark, S. Pink, L-E. Jonsson (ed.), G. Fairhurst (ed.), "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
;[RFC 4303]
:S. Kent, "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
;[RFC 4340]
:E. Kohler, M. Handley, S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
;[RFC 5288]
:J. Salowey, A. Choudhury, D. McGrew, "AES Galois Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, August 2008.
;[RFC 5595]
:G. Fairhurst, "The Datagram Congestion Control Protocol (DCCP) Service Codes", RFC 5595, September 2009.
;[RFC 5681]
:M. Allman, V. Paxson, E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
;[RFC 5925]
:J. Touch, A. Mankin, R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
;[RFC 5961]
:A. Ramaiah, R. Stewart, M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, August 2010.
;[RFC 6298]
:V. Paxson, M. Allman, J. Chu, M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, June 2011.
;[RFC 6528]
:F. Gont, S. Bellovin, "Defending against Sequence Number Attacks", RFC 6528, February 2012. Obsoletes RFC 1948.
;[RFC 6582]
:T. Henderson, S. Floyd, A. Gurtov, Y. Nishida, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 6582, April 2012.
;[RFC 7323]
:D. Borman, B. Braden, V. Jacobson, R. Scheffenegger (ed.), "TCP Extensions for High Performance", RFC 7323, September 2014.
;[RFC 7675]
:M. Perumal, D. Wing, R. Ravindranath, T. Reddy, M. Thomson, "Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness", RFC 7675, October 2015.
;[RFC 8174]
:B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017.
;[RFC 8200]
:S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, July 2017.
;[RFC 8439]
:Y. Nir, A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 8439, June 2018.
;[RFC 8446]
:E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, August 2018.
;[RFC 8985]
:Y. Cheng, N. Cardwell, N. Dukkipati, P. Jha, "The RACK-TLP Loss Detection Algorithm for TCP", RFC 8985, February 2021.
;[RFC 9000]
:J. Iyengar (ed.), M. Thomson (ed.), "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, May 2021.
;[RFC 9001]
:M. Thomson (ed.), S. Turner (ed.), "Using TLS to Secure QUIC", RFC 9001, May 2021.
;[RFC 9002]
:J. Iyengar (ed.), I. Swett (ed.), "QUIC Loss Detection and Congestion Control", RFC 9002, May 2021.
;[RFC 9147]
:E. Rescorla, H. Tschofenig, N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, April 2022.
;[RFC 9260]
:R. Stewart, M. Tuexen, K. Nielsen, "Stream Control Transmission Protocol", RFC 9260, June 2022. Obsoletes RFC 4960.
;[RFC 9293]
:W. Eddy (ed.), "Transmission Control Protocol (TCP)", STD 7, RFC 9293, August 2022. Obsoletes RFC 793 and several follow-ons; updates RFC 1122 and others.

=== 17.2. Books and journal papers ===

;[Day08]
:J. Day, "Patterns in Network Architecture: A Return to Fundamentals", Prentice Hall, 2008.
;[Grasa15]
:E. Grasa et al., "IRATI: investigating RINA as an alternative to TCP/IP", Computer Networks, Vol. 92, December 2015.
;[KP87]
:P. Karn, C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", ACM SIGCOMM, August 1987.
;[Wat81]
:R. W. Watson, "Timer-Based Mechanisms in Reliable Transport Protocol Connection Management", Computer Networks, Vol. 5, 1981.

=== 17.3. Source-code references ===

;[Linux-RTT]
:<code>tcp_rtt_estimator()</code> in <code>net/ipv4/tcp_input.c</code> of the Linux kernel, defining the asymmetric <code>mdev</code> variance update used as FRCP's default RTT estimator ([[#12. RTT estimation|Section 12]]). Line-stable browseable copy at https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_input.c.

[[Category:Protocols]]
[[Category:Ouroboros internals]]

Flow and Retransmission Control Protocol

2026-05-17T15:17:17Z

Dimitri: /* 1.3. SACK payload */

{{DISPLAYTITLE:FRCP - Flow and Retransmission Control Protocol}}

FRCP runs end-to-end between two peers over a flow. It delivers
reliability, in-order delivery, flow control, and liveness.
Congestion Control (CC) is not in FRCP - that lives in the IPC
Process (IPCP) Congestion Avoidance (CA) policies, orthogonal to
FRCP. Flow allocation, naming, and IPCP lifecycle are handled by
the IPC Resource Manager daemon (IRMd).

FRCT (Flow and Retransmission Control Task) is the libouroboros
implementation of FRCP; the task lives in <code>src/lib/frct.c</code>. The
remainder of this document describes the FRCP wire protocol and the
behaviour FRCT realises. Code symbols retain the <code>FRCT_</code> prefix
(<code>FRCT_DATA</code>, <code>FRCT_RXM</code>, ...) because they belong to the implementing
task; this document references them verbatim.

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in <code>BCP</code> 14 (Best
Current Practice; RFC 2119, RFC 8174) when, and only when, they
appear in all capitals.

== Notation ==

;<code>u32</code>, <code>u8</code>
:Unsigned 32-bit / 8-bit integers (kernel-C style).
;<code>ns</code>
:Nanoseconds.

Modular sequence-number comparators (32-bit, modulo 2^32):

;<code>before(a, b)</code>
:<code>(int32_t)(a - b) < 0</code>
;<code>after(a, b)</code>
:<code>before(b, a)</code>

Used throughout for <code>ackno</code> / <code>seqno</code> ordering checks.

Round-Trip Time (RTT) abbreviations used throughout:

;<code>SRTT</code>
:Smoothed RTT estimate (RFC 6298).
;<code>mdev</code>
:Mean deviation of RTT (Linux variance estimator).
;<code>EWMA</code>
:Exponentially Weighted Moving Average.
;<code>RTO</code>
:Retransmission Timeout, <code>max(RTO_MIN, srtt + (mdev << MDEV_MUL))</code>.

Timer-bound symbols <code>t_a</code> (a-timer, ACK delay) and <code>t_r</code> (r-timer,
retransmission window) are defined in [[#8. Retransmission|Section 8]]; <code>t_mpl</code> (Maximum
Packet Lifetime) is introduced in [[#2.1. Per-flow state|Section 2.1]] (the <code>inact</code> field)
with heritage in [[#15. Heritage and adopted techniques|Section 15]].

Wire-format diagrams follow the IETF convention: bit 0 is the
leftmost (most significant) bit and fields are in network byte
order unless stated otherwise.

__TOC__

== 1. Wire format ==

=== 1.1. PCI header ===

Fixed 16-octet base Protocol-Control Information (PCI) header
prefixed to every FRCP packet (RFC convention: bit 0 leftmost,
most-significant bit first). All multi-byte fields except <code>hcs</code>
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
[[#1.5. Stream PCI extension|Section 1.5]]); SACK and RTTP carry their own payloads after the
base PCI.

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | hcs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ackno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload (variable) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>flags</code>
:feature/type bitmap (see [[#1.2. Flag bits|Section 1.2]]).
;<code>hcs</code>
:CRC-16-CCITT-FALSE Header Check Sequence (HCS) over <code>flags</code> + <code>window</code> + <code>seqno</code> + <code>ackno</code> (+ stream extension when present); the two octets of the <code>hcs</code> field itself are omitted from the CRC input. Verified on receive before any flag-driven dispatch.
;<code>window</code>
:receiver-advertised right window edge (valid iff FC).
;<code>seqno</code>
:per-flow sequence number.
;<code>ackno</code>
:cumulative Acknowledgement (ACK) (valid iff ACK).

A single packet can simultaneously carry DATA + ACK + FC (Flow
Control) + RXM (Retransmission) by ORing flag bits; the PCI
multiplexes control on the same wire frame in the spirit of SCTP
chunk bundling (RFC 9260 sec. 6.10) and QUIC frame multiplexing
(RFC 9000 sec. 12.4). DATA-bearing packets carry the caller's
payload after the PCI; SACK (Selective Acknowledgement) and RTTP
(Round-Trip Time Probe) carry their own typed payloads after the
PCI.

Optional framing (per-flow, see [[#2.2. Service modes (orthogonal axes)|Section 2.2]]). On the wire, the
order from inside out is:

{| class="wikitable"
! Layer !! Scope
|-
| <code>[ PCI + body ]</code>
| The FRCP packet.
|-
| <code>[ PCI + body + CRC-32 ]</code>
| CRC-32 covers the body only (PCI is in HCS); appended iff <code>qs.ber == 0</code> on DATA, or on every SACK packet.
|-
| <code>[ AEAD-wrap of above ]</code>
| Iff Authenticated Encryption with Associated Data (AEAD) is enabled.
|}

* 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.
* 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>).

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

=== 1.2. Flag bits ===

Flag bits are numbered most-significant-bit first to match the wire
diagram (bit numbering per [[#1.1. PCI header|Section 1.1]]; bit 0 is the MSB of the
16-bit <code>flags</code> field and lands at wire-position 0 in network byte
order). Bits 13..15 are reserved and MUST be transmitted as zero.

{| class="wikitable"
! Bit !! Mask !! Name !! Meaning
|-
| 0 || <code>0x8000</code> || <code>DATA</code> || Carries caller payload
|-
| 1 || <code>0x4000</code> || <code>DRF</code> || Data Run Flag: start of a fresh run
|-
| 2 || <code>0x2000</code> || <code>ACK</code> || Acknowledgement: <code>ackno</code> field valid
|-
| 3 || <code>0x1000</code> || <code>NACK</code> || Negative ACK; <code>seqno = arrival_seqno-1</code>
|-
| 4 || <code>0x0800</code> || <code>FC</code> || Flow Control: <code>window</code> field valid (<code>rwe</code>)
|-
| 5 || <code>0x0400</code> || <code>RDVS</code> || Rendezvous probe (window-closed)
|-
| 6 || <code>0x0200</code> || <code>FFGM</code> || First Fragment (role bit 0; see below)
|-
| 7 || <code>0x0100</code> || <code>LFGM</code> || Last Fragment (role bit 1; see below)
|-
| 8 || <code>0x0080</code> || <code>RXM</code> || Retransmission
|-
| 9 || <code>0x0040</code> || <code>SACK</code> || Selective ACK block list in payload
|-
| 10 || <code>0x0020</code> || <code>RTTP</code> || RTT Probe / echo (payload follows)
|-
| 11 || <code>0x0010</code> || <code>KA</code> || Keepalive
|-
| 12 || <code>0x0008</code> || <code>FIN</code> || End-of-stream marker (stream mode)
|-
| 13-15 || -- || -- || Reserved (MUST be zero)
|}

The (<code>FFGM</code>, <code>LFGM</code>) pair encodes the fragment role of a DATA-bearing
Service Data Unit (SDU), SCTP-style begin/end flags (RFC 9260
sec. 3.3.1):

{| class="wikitable"
! FFGM !! LFGM !! Role
|-
| 1 || 1 || Sole / un-fragmented SDU (begin AND end)
|-
| 1 || 0 || First fragment of a multi-fragment SDU
|-
| 0 || 0 || Middle fragment
|-
| 0 || 1 || Last fragment
|}

Each fragment is carried in its own FRCP packet with its own <code>seqno</code>;
FRTX (the FRCT Retransmission service mode, see [[#2.2. Service modes (orthogonal axes)|Section 2.2]])
recovers individual fragments via the normal Retransmission Timeout
(RTO) / SACK / Recent Acknowledgement (RACK, RFC 8985) path. The
receiver reassembles the SDU at consume time once the contiguous
[FIRST .. LAST] run has fully arrived. On non-DATA packets the role
bits are unused and MUST be transmitted as zero.

In stream mode (<code>qos.service == SVC_STREAM</code>, see [[#16. Stream-mode flows|Section 16]]) there are
no SDU boundaries to encode, so <code>FFGM</code> and <code>LFGM</code> are unused and MUST
be transmitted as zero. End-of-stream uses a dedicated bit (<code>FIN</code>,
bit 12) carried on a 0-byte DATA packet, emitted at write-half close
(<code>fccntl</code> to <code>FLOWFRDONLY</code>), during linger drain, and at <code>flow_dealloc</code>;
emission is idempotent (first call wins). After contiguous delivery
of the FIN-bearing slot, the receiver latches <code>byte_fin</code> at the FIN's
start offset; <code>flow_read</code> returns 0 (end-of-file, <code>EOF</code>) once buffered
bytes have been drained up to <code>byte_fin</code>. Per-byte position is
carried by the [start, end) extension ([[#1.5. Stream PCI extension|Section 1.5]]).

=== 1.3. SACK payload ===

A SACK packet has the <code>FRCT_ACK | FRCT_FC | FRCT_SACK</code> flag bits set
(bit numbering per [[#1.1. PCI header|Section 1.1]]). Following the 16-octet PCI, the
payload is a 2-octet block count (network byte order), 2 octets of
padding to 4-byte align the block list, then <code>n_blocks</code> pairs of
32-bit start/end seqnos describing ''present'' (received) ranges
above the cumulative ACK.

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_blocks | padding (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start[0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end[0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... n_blocks pairs total ...
</syntaxhighlight>

<code>n_blocks <= SACK_MAX_BLOCKS</code> (2048). The per-flow effective cap is
further bounded by <code>(frag_mtu - PCI - 4) / 8</code> blocks per packet; SACK
packets carry no stream extension, so PCI here is the 16-octet base
header even on stream-mode flows.

Wire invariant: every block produced by the receiver, except an
optional leading Duplicate SACK (D-SACK) block as described below,
describes a range strictly above the cumulative ACK carried in the
PCI <code>ackno</code> field (<code>after(start[i], ackno)</code>). This makes the D-SACK
convention below unambiguous; the receiver-side builder MUST
preserve it.

Duplicate SACK (D-SACK, RFC 2883) is signalled in-band: no flag
bit, no extra framing. Modular seqno arithmetic uses the
<code>before()</code> / <code>after()</code> comparators defined in the Notation block.
<code>Block[0]</code> carries a D-SACK report when either:

;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.
;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.

On receipt the sender feeds <code>block[0]</code> into the RACK
<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
most recent D-SACK arrival or halve event, reset to 1 on an RTO
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
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 ===

An RTTP (Round-Trip Time Probe) packet has only the <code>FRCT_RTTP</code> flag
set (bit numbering per [[#1.1. PCI header|Section 1.1]]). Following the 16-octet PCI,
the payload is 24 octets (packed):

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| probe_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| echo_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ nonce (16 octets, echoed verbatim) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>probe_id</code>
:sender counter, 0 on reply, 0 reserved.
;<code>echo_id</code>
:peer's <code>probe_id</code>, 0 on outbound probe.
;<code>nonce</code>
:random, echoed unmodified, memcmp'd to defeat spoof.

=== 1.5. Stream PCI extension ===

A stream-mode flow (<code>qos.service == SVC_STREAM</code>) carries an extra
8-octet extension after the 16-octet base PCI on every DATA packet
(bit numbering per [[#1.1. PCI header|Section 1.1]]):

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>start</code>
:octet offset of the first payload byte in the stream.
;<code>end</code>
:octet offset one past the last payload byte; <code>end - start</code> equals the on-wire payload length.

Total stream-mode PCI for DATA packets is 24 octets (16 base + 8
extension); control packets (SACK, RTTP, bare ACK, KA, etc.) retain
the 16-octet base PCI. Stream mode MUST be negotiated at flow
allocation; the extension is present iff stream mode is in use,
never on a per-packet basis. Both peers MUST treat <code>start</code>/<code>end</code> as
monotonic 32-bit byte offsets; when a slot reaches the head of the
contiguous run with <code>start</code> not equal to the prior packet's <code>end</code> the
slot is silently dropped at delivery time ([[#16. Stream-mode flows|Section 16]]) rather
than rejected at stash.

This is the QUIC STREAM-frame reassembly model (RFC 9000 sec. 19.8):
each packet carries its packet <code>seqno</code> (this PCI's <code>seqno</code> field) and a
separate stream byte position (<code>start</code>/<code>end</code>). Separating the two
avoids TCP's conflation of packet identity with byte position which
forces Karn's algorithm for Round-Trip Time (RTT) sampling (no RTT
sample on retransmits, RFC 6298 sec. 3); FRCP applies the
Karn-equivalent gate via a combination of per-packet <code>FRCT_RXM</code>,
per-slot <code>SND_RTX</code> flags, and a sample-fence <code>rtt_lwe</code> (see [[#2.1. Per-flow state|Section 2.1]]
and [[#12. RTT estimation|Section 12]]). FRCP's fixed-32-bit <code>start</code>/<code>end</code> wrap at 4 GiB of
wire bytes, narrower than QUIC's 62-bit varint offset (cf. RFC 9000
sec. 16); the on-wire wrap is handled by the same modular <code>before()</code>
/ <code>after()</code> comparators ([[#1.3. SACK payload|Section 1.3]]) FRCP uses for seqnos, which
remain unambiguous as long as the in-flight byte window stays
strictly under 2 GiB (the half-range of the signed-int32 difference
in <code>before()</code>). The default per-flow ring is 1 MiB; the
implementation caps <code>ring_sz</code> at 128 MiB (<code>FRCT_STREAM_RING_SZ_MAX</code>),
well below the 2 GiB half-range bound. The runtime byte counters
exposed via FUSE (Filesystem in Userspace) in the Ouroboros
Resource Information Base (RIB, a virtual-filesystem introspection
bridge) are platform <code>size_t</code> and do not wrap on 64-bit hosts.

== 2. Per-flow state and service modes ==

=== 2.1. Per-flow state ===

Each flow keeps a sender control record and a receiver control
record:

;<code>lwe</code> : <code>u32</code>
:snd: oldest unacked <code>seqno</code> (cumulative ACK boundary as seen by sender); rcv: next in-order <code>seqno</code> expected
;<code>rwe</code> : <code>u32</code>
:snd: peer-advertised right window edge; rcv: locally-advertised right window edge
;<code>cflags</code> : <code>u8</code>
:per-direction feature flags: retransmission (<code>FRCTFRTX</code>), receiver flow control (<code>FRCTFRESCNTL</code>), linger-on-close (<code>FRCTFLINGER</code>); see <code><ouroboros/fccntl.h></code>
;<code>seqno</code> : <code>u32</code>
:snd: next <code>seqno</code> to send; rcv: force-ACK trigger - set on a stale or dup DATA so the next <code>ack_snd</code> emits a fresh cumulative ACK
;<code>ackno</code> : <code>u32</code>
:snd: <code>seqno</code> counter for standalone ACK-bearing control packets (delayed ACK, SACK, final ACK on dealloc); not bumped on piggybacked ACK riding a DATA packet (which uses the DATA <code>seqno</code>). Used by wire-dup ACK detection; rcv: incoming-ACK dedup tracker
;<code>act</code> : <code>ns</code>
:last activity (used by inactivity / DRF)
;<code>inact</code> : <code>ns</code>
:inactivity threshold; sender = <code>3*mpl + a + r + 1s</code>, receiver = <code>2*mpl + a + r + 1s</code>. <code>mpl</code> is the Maximum Packet Lifetime (delta-t terminology; see [[#15. Heritage and adopted techniques|Section 15]]); <code>a</code> and <code>r</code> are the FRCT a-timer and r-timer bounds (see [[#8. Retransmission|Section 8]]). The asymmetry is load-bearing for pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]).

The sender holds a per-slot ring <code>snd_slots[RQ_SIZE]</code> keyed by
<code>(seqno mod RQ_SIZE)</code>. Each slot tracks its retransmit entry (<code>rxm</code>),
last-send timestamp, and retransmit flag bits: <code>SND_RTX</code> (a
retransmit is pending or has fired, gates the next RTT sample
under Karn) and <code>SND_FAST_RXM</code> (one-shot fast-retransmit staged for
this loss event).

The receiver holds a parallel reorder ring <code>rcv_slots[RQ_SIZE]</code>
(referred to as <code>rq[]</code> in prose) holding stashed out-of-order
packet-buffer indexes; both FRTX and best-effort flows share this
path. The invariant <code>rwe - lwe <= RQ_SIZE</code> holds: on each consume
the receiver advances <code>rwe</code> by the consumed count, capping the
receive window at <code>RQ_SIZE</code> <code>seqno</code> slots.

A separate fence variable <code>rtt_lwe</code> is bumped on every retransmit
(timer-fire, SACK-driven, fast-rxm, NACK-driven) and on every
<code>seqno_rotate</code> ([[#4. Sequence-number rotation (DRF)|Section 4]]) to mark the <code>seqno</code> range whose RTT samples
MUST be discarded.

=== 2.2. Service modes (orthogonal axes) ===

FRCP exposes its wire features as a vector of independent QoS
axes selected at flow allocation time. All flows go through the
same <code>flow_alloc(name, qos, ...)</code> primitive; the <code>qosspec_t</code> passed
in determines which protocol machinery engages on the wire. This
contrasts with the POSIX BSD socket model where TCP and UDP
require different socket types (<code>SOCK_STREAM</code> / <code>SOCK_DGRAM</code>).

The axes:

;<code>service</code>
:0 = unordered (no FRCP engagement: raw datagrams, no PCI on the wire, UDP-equivalent at this layer); 1 = message-ordered (FRCP engaged; SDU boundaries preserved across fragmentation); 2 = stream (byte-oriented, no SDU boundaries; FRTX required)
;<code>loss</code>
:0 = lossless service requested: FRTX retransmit machinery engages ([[#8. Retransmission|Section 8]]); MUST be 0 for <code>service=2</code>. Non-zero = best-effort, FRTX off.
;<code>ber</code>
:Bit Error Rate tolerance. 0 = error-free service requested: a CRC trailer is appended after the body of DATA packets and verified on receive (added / checked outside the FRCP PCI; see [[#1.1. PCI header|Section 1.1]]). Non-zero = peer accepts errors; trailer omitted. SACK control packets carry a CRC32 trailer regardless of <code>ber</code>; the <code>ber</code> gate applies to DATA only.
;<code>timeout</code>
:Peer-timeout (ms); 0 disables the keepalive timer. Independent of FRCP engagement.

Encryption is a separate per-flow attribute set at flow setup;
when enabled it wraps the FRCP packet (PCI + body, plus the CRC
trailer if any) under AEAD, expanding the <code>spb</code> by <code>headsz</code> + <code>tailsz</code>
octets (nonce / tag). The CRC trailer is currently kept inside
the AEAD wrap (see [[#1.1. PCI header|Section 1.1]]).

Reachable combinations exported by <code>include/ouroboros/qos.h</code>:

{| class="wikitable"
! Cube !! <code>service</code> !! <code>loss</code> !! <code>ber</code> !! Engaged
|-
| <code>qos_raw</code> || 0 || 1 || 1 || Raw passthrough
|-
| <code>qos_raw_safe</code> || 0 || 1 || 0 || Raw + CRC trailer
|-
| <code>qos_rt</code> || 1 || 1 || 1 || FRCP, no FRTX, no CRC
|-
| <code>qos_rt_safe</code> || 1 || 1 || 0 || FRCP, no FRTX, CRC
|-
| <code>qos_msg</code> || 1 || 0 || 0 || FRCP + FRTX
|-
| <code>qos_stream</code> || 2 || 0 || 0 || FRCP + FRTX, stream
|}

Forced couplings actually enforced by the public API:

* <code>service == SVC_STREAM</code> (2) requires <code>loss == 0</code>; <code>flow_alloc</code> / <code>flow_accept</code> reject the pair otherwise with <code>-EINVAL</code>.
* FRTX requires FRCP engagement (<code>service != SVC_RAW</code>); requesting <code>loss = 0</code> with <code>service = SVC_RAW</code> is structurally a no-op because no <code>frcti</code> is created.
* The <code>QOS_DISABLE_CRC</code> build flag globally forces <code>ber = 1</code>. Note: this flag defaults to ON, so default builds ship with CRC disabled until <code>QOS_DISABLE_CRC</code> is set to OFF.

Caveat: the API does NOT force <code>ber = 0</code> when <code>service != SVC_RAW</code>.
<code>qos_rt</code> has <code>service = SVC_MESSAGE</code> with <code>ber = 1</code>, which means the PCI
itself is not CRC-protected on that cube; the HCS ([[#1.1. PCI header|Section 1.1]])
remains the only integrity check on the header.

The FRCP-no-FRTX regime (<code>service = SVC_MESSAGE</code>, <code>loss > 0</code>) is meaningful
and live: sequence numbering, in-order delivery, flow-control
advertisement, KA, DRF rotation, and SDU fragmentation /
reassembly ([[#7.2. Fragmentation and reassembly|Section 7.2]]) all run. Lost packets are dropped
rather than retransmitted; a permanently-lost mid-fragment is
dropped via skip-past-gap once a later SDU is visible in the
reorder ring.

== 3. Protocol parameters ==

{| class="wikitable"
! Parameter !! Value !! Role
|-
| <code>RQ_SIZE</code> || compile-time, power of 2 (default 128) || Slot ring / rcv window width
|-
| <code>START_WINDOW</code> || compile-time, power of 2 (default 128) || Initial <code>rwe-lwe</code> after rotate
|-
| <code>RTO_MIN</code> || <code>MAX(250 us build-tunable, 1<<RXMQ_RES)</code>; per-flow via <code>fccntl</code> (<code>FRCTSRTOMIN</code>). Default ~1 ms with <code>RXMQ_RES=20</code>. || RTO floor; also floored at the retransmit-wheel resolution (~1 ms by default).
|-
| <code>MAX_RTO_MUL</code> || 20 || Backoff shift cap
|-
| RACK window <code>R</code> || <code>MIN(reo_wnd_mult * min_RTT/4, SRTT)</code> with <code>MIN_REORDER_NS = 250 us</code> floor; <code>reo_wnd_mult</code> scales on D-SACK, cap 20 || Reorder window; per RFC 8985 sec. 6.2; <code>reo_wnd_mult</code> per sec. 6.2 step 4
|-
| <code>MIN_RTT_WIN_NS</code> || 300 s (5 min, Linux <code>tcp_min_rtt_wlen</code>) || <code>min_RTT</code> windowed re-anchor
|-
| <code>REO_WND_MULT_MAX</code> || 20 (RFC 8985 sec. 6.2 step 4) || <code>reo_wnd_mult</code> cap
|-
| <code>REO_DECAY_PKTS</code> || 16 (RFC 8985 sec. 6.2 step 4 / <code>RACK.reo_wnd_persist</code>) || Fresh-ACK'd seq count per halving
|-
| <code>MAX_DSACK_LAG</code> || <code>RQ_SIZE</code> || D-SACK sanity cap
|-
| <code>RTT_QUARANTINE</code> || 32 (<code>seqno</code> steps) || NewReno gate pad
|-
| SACK rate-limit || <code>SACK_MIN_GAP_NS</code> (250 us, fixed) || Min SACK gap
|-
| <code>SACK_MAX_BLOCKS</code> || 2048 (wire cap; per-flow capped at <code>(frag_mtu-PCI-4)/8</code>) || Per-SACK block cap
|-
| <code>SACK_RXM_MAX</code> || 32 || Per-pass staged retransmit cap
|-
| <code>DUP_THRESH</code> || 3 (RFC 8985 default) || Hybrid fast-rxm trigger ([[#8. Retransmission|Section 8]])
|-
| <code>MDEV_MUL</code> || 2 (build-tunable via <code>FRCT_RTO_MDEV_MULTIPLIER</code>) || <code>mdev</code> shift in <code>RTO = srtt + (mdev << MDEV_MUL)</code>
|-
| RTTP nonce || 16 octets || Echoed verbatim
|-
| <code>RTTP_RING</code> || 8 || In-flight probes
|-
| RTT clamp || <code>16 * srtt</code> || Probe-sample upper bound (ACK-derived RTT samples gated by Karn / recovery only)
|-
| Cold-probe cadence || 100 ms (rx-driven; see [[#12. RTT estimation|Section 12]]) || Pre-<code>srtt</code> RTTP rate
|-
| <code>DELT_RDV</code> || 100 ms || RDVS emit cadence
|-
| <code>MAX_RDV</code> || 1 s || RDVS give-up
|-
| Delayed-ACK fire || <code>2 * TICTIME</code> (<code>TICTIME</code> = FRCT tick granularity, default 5 ms; <code>2*TICTIME = 10 ms</code> by default) || Fired after the first in-order DATA arrival; tick is build-tunable
|-
| NACK send cooldown || <code>srtt</code> when an <code>srtt</code> sample exists, else 100 ms || Pre-DRF NACK rate-limit
|-
| <code>MAX_SDU</code> || 1 MiB || Max reassembled SDU; configurable per flow
|}

The per-flow fragment Maximum Transmission Unit (MTU) is computed
at flow setup from the lower IPCP's mtu minus encryption
<code>headsz</code> / <code>tailsz</code> and CRC trailer; there is no FRCT-level default or
environment-variable override.

== 4. Sequence-number rotation (DRF) ==

The DRF (Data Run Flag) bit on an outbound packet means "this is
the start of a fresh data run" and is set whenever the sender has
nothing in flight (<code>snd_cr.seqno == snd_cr.lwe</code>).

Independently of that, if the sender has been idle longer than
<code>snd_cr.inact</code> AND the pipe is empty (<code>snd_cr.seqno == snd_cr.lwe</code>),
<code>seqno_rotate()</code> rolls a random new <code>seqno</code> before the send and
resets

<syntaxhighlight lang="text">
snd_cr.seqno = random()
snd_cr.lwe = snd_cr.seqno
snd_cr.rwe = snd_cr.seqno + START_WINDOW
rtt_lwe = snd_cr.seqno
in_recovery = false (recovery state, see Section 8)
recovery_high = snd_cr.seqno
</syntaxhighlight>

The receiver, on observing rcv-side inactivity
(<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
below). Non-DATA control packets pass through without the DRF
requirement. On DRF the receiver releases the <code>rq[]</code> slots and
rebases

<syntaxhighlight lang="text">
rcv_cr.lwe = seqno
rcv_cr.rwe = seqno + RQ_SIZE
rcv_cr.seqno = seqno
</syntaxhighlight>

If the inactive packet has DATA but no DRF, a rate-limited NACK is
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).

== 5. Send path ==

# If the SDU exceeds <code>(frag_mtu - data_hdr_len)</code>, the caller (<code>dev.c</code>) fans it out into <code>ceil(count / (frag_mtu - data_hdr_len))</code> fragments, each emitted via <code>frcti_snd</code> as its own DATA packet with a per-fragment role ([[#7.2. Fragmentation and reassembly|Section 7.2]]); both FRTX and best-effort flows fragment. Raw flows (no FRCP engagement, <code>qos.service == SVC_RAW</code>) carry no PCI and return <code>-EMSGSIZE</code> for any SDU larger than one packet at the layer below. An SDU that fits in a single packet is sent as SOLE. <code>frcti_snd</code> reserves PCI head room; sets DATA, plus DRF when the pipe is empty (<code>snd_cr.seqno == snd_cr.lwe</code>).
# <code>seqno_rotate()</code> if past sender inactivity and the pipe is empty ([[#4. Sequence-number rotation (DRF)|Section 4]]).
# Advertise FC (<code>pci.window = frcti_advert_rwe(frcti)</code>, i.e. <code>rcv_cr.rwe</code> clamped to <code>rcv_cr.lwe + ring_seq_cap</code> in stream mode) when the receiver side is recent: <code>now - rcv_cr.act < rcv_cr.inact</code>.
# Reliable mode (FRTX): leave <code>snd_cr.lwe</code> where it is; reset the slot at <code>RQ_SLOT(seqno)</code> (<code>snd_slots[p].time = now</code>, <code>snd_slots[p].flags = 0</code>); queue an <code>rxm_entry</code> (saves a packet copy, arms a wheel timer at <code>now + (rto << rto_mul)</code>). Piggyback ACK (<code>pci.ackno = rcv_cr.lwe</code>) while the a-timer for the most recent received DATA packet has not yet expired (<code>now - rcv_cr.act <= t_a</code>); on piggyback, set <code>rcv_cr.seqno = rcv_cr.lwe</code> so the next delayed-ACK fire is suppressed. See [[#8. Retransmission|Section 8]] for <code>t_a</code> / <code>t_r</code> semantics.
# Best-effort mode (no FRTX): advance <code>snd_cr.lwe</code> immediately (<code>snd_cr.lwe = snd_cr.lwe + 1</code>, <code>snd_cr.rwe = snd_cr.lwe + RQ_SIZE</code>); no retransmit state. No send-side RTT probe is armed in this mode (<code>rtt_probe_arm</code> requires an in-flight <code>seqno</code>, which best-effort never has); the rx-driven cold seeder in <code>frcti_rcv</code> is the only probe path.
# In reliable mode, optionally arm an RTT probe ([[#12. RTT estimation|Section 12]]).

== 6. Receive path ==

=== 6.1. Early-exit dispatch ===

Keepalive (KA), RTT probe (RTTP), pre-DRF NACK, and rendezvous
(RDVS) packets short-circuit out of <code>frcti_rcv</code> before the locked
main path; each handler takes its own lock internally.

<syntaxhighlight lang="text">
incoming packet
|
v
+---------+
| KA? |---yes--> ka_rcv ; return
+---------+
|no
v
+---------+
| RTTP? |---yes--> rttp_rcv; return
+---------+
|no
v
+---------+
| NACK? |---yes--> nack_rcv; return (see Section 9)
+---------+
|no
v
+---------+
| RDVS? |---yes--> rdv_rcv ; return (reply bare FC, ackno=0)
+---------+
|no
v
acquire wrlock; enter locked main path
</syntaxhighlight>

;<code>KA</code>
:refresh <code>t_ka_rcv</code>, honour piggybacked ACK.
;<code>RTTP</code>
:probe (echo back nonce) or echo (verify nonce, sample RTT).
;<code>NACK</code>
:pre-DRF, sender-side handler. See [[#9. Pre-DRF NACK|Section 9]].
;<code>RDVS</code>
:reply with a bare FC packet (<code>ackno = 0</code>); <code>rdlock</code> only.

=== 6.2. Locked main path ===

Steps below run with the per-flow <code>frcti.lock</code> held for writing
(<code>pthread_rwlock_wrlock</code>) unless noted.

;<code>rcv_inact_check</code>
:Only meaningful when the receive side is stale. On DRF (Data Run Flag): release <code>rq[]</code> slots, rebase <code>rcv_cr</code>, continue. On stale DATA without DRF: fire a pre-DRF NACK if cooldown allows ([[#9. Pre-DRF NACK|Section 9]]), then discard the packet; on cooldown, drop without sending a NACK (a pending cumulative ACK from <code>drop_packet</code> may still go out). Non-DATA, non-DRF arrivals bypass <code>rcv_inact_check</code> entirely; pure-DRF stale arrivals fall through after the DRF rebase branch.

;DATA-only act refresh
:Refresh <code>rcv_cr.act</code> only when <code>FRCT_DATA</code> is set, so that non-DATA packets never block the next DRF rebase.

;Wire-dup gate
:Before flag-driven dispatch, drop wire-duplicate ACKs and wire-duplicate DATA (<code>is_dup_ack</code> / <code>is_dup_data</code>). The DATA check is bypassed for <code>FRCT_RXM</code>-bearing arrivals so the piggybacked ACK / SACK / FC carried on a retransmitted DATA at an already-ACK'd <code>seqno</code> is still applied; the stale-in-window branch below then drops the packet.

;<code>ACK</code>
:Drop ACKs whose <code>ackno</code> falls outside <code>(snd_cr.lwe, snd_cr.seqno]</code>. If <code>ackno == snd_cr.lwe</code> (non-advancing cumulative ACK), drive RACK fast-retransmit consideration ([[#8. Retransmission|Section 8]]). Otherwise advance <code>snd_cr.lwe = ackno</code>, collapse <code>rto_mul</code> to 0 (Karn-gated by <code>SND_RTX</code> on the just-acknowledged slot, the old head-of-line), reset <code>dup_thresh</code> to 0, update <code>t_latest_ack</code> to the send-time of the slot at <code>ackno-1</code> (consumed by RACK and SACK below), decay <code>reo_wnd_mult</code> per RFC 8985 sec. 6.2 step 4, exit NewReno-careful recovery (see [[#8. Retransmission|Section 8]]) on <code>ackno >= recovery_high</code> or <code>ackno == snd_cr.seqno</code>, and feed an RTT sample if eligible ([[#12. RTT estimation|Section 12]]).

;<code>SACK</code>
:Walk the block list. For each block (a present range above <code>lwe</code>) NULL out <code>snd_slots[k].rxm</code>, clear the slot's per-send flags, and advance <code>t_latest_ack</code> to the latest send-time covered (the Forward Acknowledgement / fack equivalent, Mathis & Mahdavi 1996); the first block whose start clamps to <code>snd_cr.lwe</code> skips this fack update so that a head-of-line clamp does not falsely advance fack. For un-SACKed gaps below <code>hi_sacked</code>, stage a retransmit per slot that is (1) still owned (<code>rxm != NULL</code>), (2) not already <code>SND_FAST_RXM</code>, (3) not aged out past <code>t_r</code>, and (4) either outside the RACK reorder window <code>R</code> OR with <code>dup_thresh >= DUP_THRESH</code> (the RFC 8985 sec. 6.2 hybrid trigger). Mark the slot <code>SND_FAST_RXM</code> and NULL the <code>rxm</code> at stage time. Capped at <code>SACK_RXM_MAX</code> staged retransmits per receive pass; what's left rides the next SACK.

;<code>FC</code>
:Bump <code>snd_cr.rwe</code> (clamped to <code>lwe + RQ_SIZE</code>, never shrinks) and mark window open.

;<code>DATA</code>
:Bounds-check <code>seqno</code> against window. On stale-dup (<code>seqno < rcv_cr.lwe</code>), set <code>rcv_cr.seqno = seqno</code> to force a fresh ACK on the next <code>ack_snd</code>, then drop. On accept: both FRTX and best-effort stash the packet-buffer index into <code>rq[seqno mod RQ_SIZE]</code>. Fragments stash unchanged - the role bits are inspected only at consume time ([[#7.2. Fragmentation and reassembly|Section 7.2]]). On out-of-order arrival, build a SACK reply if not rate-limited (per [[#3. Protocol parameters|Section 3]]) and not deduplicated against the previous <code>(rcv_cr.lwe, n_blocks)</code> pair; D-SACK reports always bypass the dedup. If both rate-limit and dedup suppress the reply, neither SACK nor delayed-ACK fires (the sender picks up the gap on its next ACK). On in-order arrival, arm the delayed-ACK timer.

;<code>drop_packet</code> exit
:Releases the per-packet shared-memory buffer (<code>spb</code>), then calls <code>ack_snd</code> synchronously after the <code>spb</code> release to surface any pending cumulative ACK.

== 7. Read path and reassembly ==

=== 7.1. Read path ===

<code>flow_read</code> returns a full reassembled SDU (Service Data Unit) via
<code>frcti_consume</code> on every FRCP SDU-mode flow (FRTX or best-effort);
stream-mode is covered in [[#16. Stream-mode flows|Section 16]]. An incomplete head-of-line
(HoL) run yields <code>-EAGAIN</code>; an oversized run yields <code>-EMSGSIZE</code> (the
run is dropped so the flow does not stall). On best-effort flows,
a permanently-lost mid-fragment is dropped as soon as a later
complete SDU becomes visible in the ring ([[#7.2. Fragmentation and reassembly|Section 7.2]] skip-past-
gap).

Raw flows carry no <code>frcti</code>, so <code>flow_read</code> returns the next pending
packet-buffer index directly, with no role-bit inspection. (Raw
service is selected via <code>qos.service == SVC_RAW</code> at flow allocation,
which suppresses <code>frcti</code> creation.)

<code>frcti_pdu_ready</code> is the no-advance peek used by <code>fevent</code> (the
Ouroboros flow-event multiplexer, the <code>poll(2)</code>-equivalent on
flows). It returns ready only when the head-of-line run is
complete and the lead packet (a Protocol Data Unit, here one FRCP
packet) is present at <code>rcv_cr.rwe - RQ_SIZE</code>; any other state
(including the best-effort skip-past-gap case) returns not ready,
and <code>frcti_consume</code> is left to drop the broken prefix and re-
inspect.

=== 7.2. Fragmentation and reassembly ===

Send side (<code>flow_write_frag</code>). An SDU larger than
<code>(frag_mtu - PCI)</code> is split into <code>ceil(count / (frag_mtu - PCI))</code>
fragments; each fragment is its own FRCP packet with its own
<code>seqno</code> and a per-fragment role flag pair ([[#1.2. Flag bits|Section 1.2]]). Roles are
assigned at emit time:

{| class="wikitable"
! i !! Role
|-
| <code>n=1</code> || <code>SOLE</code>
|-
| <code>i=0</code> || <code>FIRST</code>
|-
| <code>i=n-1</code> || <code>LAST</code>
|-
| else || <code>MID</code>
|}

A mid-loop allocation or transmit failure may yield a partial
write: the call returns the bytes already enqueued (<code>off > 0</code>) or
the underlying error (<code>off == 0</code>). Best-effort flows fragment
identically; on the receiver, a partial run with a permanently-
lost fragment is dropped when a later complete SDU is visible in
the ring (see skip-past-gap below). Raw flows carry no PCI and
refuse anything larger than the layer's user MTU (<code>-EMSGSIZE</code>).

Wire-level recovery is fragment-agnostic on FRTX flows: each
fragment's <code>seqno</code> flows through SACK / RACK / RTO / NACK exactly
as for a SOLE DATA packet, and reassembly does not re-enter the
loss-detection path. Best-effort flows run the same <code>seqno</code>
machinery (DRF, FC, ACK piggyback, pre-DRF NACK emit) but queue
no <code>rxm</code> state at the sender, so a lost MID is unrecoverable;
skip-past-gap handles it (below).

Receive side. Fragments stash into <code>rq[seqno]</code> unchanged; role bits
are read only at consume time. <code>frag_run_inspect</code>, called from
<code>frcti_consume</code>, walks the ring starting at the oldest still-
undelivered <code>seqno</code> <code>base = rcv_cr.rwe - RQ_SIZE</code> (equal to <code>rcv_cr.lwe</code>
only when no partial run is in progress; during a partial run <code>lwe</code>
has already advanced past <code>base</code>). It produces one of three
outcomes:

{| class="wikitable"
! Outcome !! Cause
|-
| <code>DELIVER (n)</code>
| <code>rq[base]=SOLE</code> (<code>n=1</code>), or <code>rq[base]=FIRST</code> and a <code>LAST</code> follows in slots <code>[base+1..base+n-1]</code> with all intermediate roles in <code>{MID,FIRST,LAST}</code> contiguous.
|-
| <code>DROP (n)</code>
| <code>rq[base]</code> is <code>MID</code> or <code>LAST</code> without a preceding <code>FIRST</code> (<code>n=1</code>); a <code>FIRST..[non-LAST]..new-FIRST</code> or new-<code>SOLE</code> mid-run (drop the broken prefix with <code>n</code> = run length minus 1, so the new <code>FIRST</code>/<code>SOLE</code> stays); or, on best-effort flows, a gap at <code>base</code> with a <code>FIRST</code>/<code>SOLE</code> later in the ring (drop up to the new run start).
|-
| <code>NOT_READY</code>
| <code>rq[base]</code> absent or <code>FIRST..[non-LAST]</code> with no later <code>FIRST</code>/<code>SOLE</code> in the ring (FRTX waits for retx; best-effort waits for arrival).
|}

<code>DELIVER</code> triggers <code>frag_gather</code>: a scatter-gather <code>memcpy</code> of the <code>n</code>
consecutive fragments at <code>rq[base..base+n-1]</code> directly into the
caller's buffer; each per-packet shared-memory buffer (<code>spb</code>) is
released and <code>rwe</code> advances by <code>n</code>. <code>lwe</code> was already advanced
incrementally as each contiguous fragment arrived; <code>frag_gather</code>
only restores the fixed-width invariant <code>rwe == lwe + RQ_SIZE</code>.
No intermediate reassembly buffer is allocated.

<code>DROP</code> advances <code>rwe</code> past the broken prefix (releasing the <code>spb</code>s)
and pulls <code>lwe</code> up to the new trailing edge if needed; the next
consume retries from the new <code>base</code>. Oversize or arithmetically
overflowing delivery (sum of fragment lengths > <code>max_rcv_sdu</code>, sum
> caller's buffer, or running-sum overflow) also drops the run
with <code>-EMSGSIZE</code>.

Skip-past-gap (best-effort only). On FRTX, a gap in the run means
"waiting for retransmit" and <code>frag_run_inspect</code> returns <code>NOT_READY</code>.
On best-effort flows the gap is permanent, so <code>frag_run_inspect</code>
scans forward in the ring for the next <code>FIRST</code> or <code>SOLE</code>; if one is
visible within <code>RQ_SIZE</code>, it returns <code>DROP</code> for the broken prefix and
the consume loop retries at the new <code>lwe</code>. Memory hold is bounded
by <code>RQ_SIZE</code>; the partial releases on the next consume call once a
later complete run exists. Voice-like flows (one <code>SOLE</code> per SDU)
see no extra wait: any later <code>SOLE</code> makes the prior gap droppable
immediately.

The choice to defer reassembly to consume time keeps the receive
path zero-copy: fragments stay in the shared-memory ring until
the application pulls, and the SDU lands directly in the caller's
buffer.

== 8. Retransmission ==

FRCP is bounded by two delta-t-derived timers (Watson 1981, see
[[#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_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.

Each in-flight FRTX <code>seqno</code> owns one <code>rxm_entry</code>, armed in a hashed
timing wheel; the wheel deadline is the slot's next eligible
retransmit time.

;RTO timer
:On fire (<code>rxm_due</code>), re-emit with <code>FRCT_RXM</code>, mark <code>SND_RTX</code> (Karn-suppress next ACK's RTT sample), and (for the head-of-line (HoL) slot only) bump <code>rto_mul</code> up to <code>MAX_RTO_MUL</code>. Wheel deadline is <code>t_send + (rto << rto_mul)</code>. Re-armed unless consumed. The RTO timer also clears <code>SND_FAST_RXM</code> (re-arming fast-retransmit eligibility), resets <code>reo_wnd_mult</code> to 1 on a HoL fire (RFC 8985 sec. 6.2 step 4 reset clause), and marks the flow <code>ACL_FLOWDOWN</code> if its <code>frct_tx</code> call fails.

;r-timer guard
:Before any retransmit attempt, check <code>(now - t0)</code> against <code>t_r</code>. If exceeded, the slot is no longer eligible for retransmit. Only the RTO timer (<code>rxm_due</code>) treats r-timer expiry as terminal: it marks the flow <code>ACL_FLOWDOWN</code> (peer unreachable). Fast-retransmit, SACK-driven retransmit, and NACK-driven head-of-line re-emit silently skip aged-out slots and defer the flow-down decision to the next RTO fire.

;Fast retransmit (hybrid trigger, RFC 8985 sec. 6.2)
:On a non-advancing cumulative ACK with the scoreboard advanced, fire one fast retransmit when EITHER (a) the head-of-line slot's latest send is older than the RACK reorder window <code>R</code> ([[#3. Protocol parameters|Section 3]]) and not yet aged out, OR (b) the SACK <code>dup-thresh</code> count above <code>snd_cr.lwe</code> reaches <code>DUP_THRESH</code> (= 3, RFC 8985 sec. 6.2 step 4). Fires at most once per non-advancing cumulative-ACK value, gated by <code>rack_fired_lwe</code> (the <code>snd_cr.lwe</code> at which fast-retransmit last fired). Set <code>SND_FAST_RXM</code> on the slot (one-shot per-slot gate) and enter NewReno-style careful recovery (see NewReno below in this section).
:The RACK reorder window <code>R</code> uses the RFC 8985 sec. 6.2 form <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> with a <code>MIN_REORDER_NS = 250 us</code> floor. Before the first RTT sample seeds <code>min_rtt</code>, <code>R</code> falls back to <code>MIN(reo_wnd_mult * SRTT / 4, SRTT)</code>, still floored at <code>MIN_REORDER_NS</code> (consistent with the windowed-minimum fallback described in [[#12. RTT estimation|Section 12]]). <code>min_rtt</code> is a windowed minimum over the last <code>MIN_RTT_WIN_NS</code> = 5 min of RTT samples (matches the Linux <code>tcp_min_rtt_wlen</code> default) so a route change to a longer path eventually re-anchors the reorder window without relying on <code>reo_wnd_mult</code> growth alone.

;SACK-driven retransmit
:For each gap below <code>hi_sacked</code> whose slot is (1) still owned, (2) not already <code>SND_FAST_RXM</code>, (3) not aged out past <code>t_r</code>, and (4) either outside the RACK window <code>R</code> OR with <code>dup_thresh >= DUP_THRESH</code> (same hybrid as fast-retransmit, see [[#6.2. Locked main path|Section 6.2]]), re-emit. Each SACK-driven retransmit re-arms a fresh <code>rxm</code> so a lost retransmit can still be recovered by its own RTO timer.

;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.

== 9. Pre-DRF NACK ==

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.

;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>)
:When an incoming DATA packet has no DRF and rcv-side activity is older than <code>rcv_cr.inact</code>, the receiver emits a bare packet with <code>flags = FRCT_NACK</code> and <code>seqno = arrival_seqno - 1</code> (informational only, not consulted by the receive handler). The cooldown in [[#3. Protocol parameters|Section 3]] rate-limits the burst. Non-DATA non-DRF arrivals bypass <code>rcv_inact_check</code> entirely; non-DATA DRF still rebases via the DRF branch.

;Receive (<code>frcti_nack_rcv</code>)
: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 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.

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 ==

Cumulative ACK is <code>ackno = rcv_cr.lwe</code>. On out-of-order arrival the
receiver also emits a SACK packet ([[#1.3. SACK payload|Section 1.3]]) whose payload lists
''present'' blocks above <code>lwe</code> (analogous to TCP SACK / QUIC ACK
ranges). SACKs are rate-limited per [[#3. Protocol parameters|Section 3]] and suppressed when
neither <code>lwe</code> nor block count has changed since the last SACK.

D-SACK reports (RFC 2883) are emitted in-band as <code>block[0]</code> of an
otherwise normal SACK frame (see [[#1.3. SACK payload|Section 1.3]] for the encoding).
Two receiver triggers arm a pending D-SACK report (single-slot,
latest-wins):

* DATA arrival with <code>seqno < rcv_cr.lwe</code>, both wire-dup (no RXM, <code>is_dup_data</code> path) and retransmit (RXM, post-FC branch) (RFC 2883 sec. 4.1.1, full duplicate)
* <code>rq_accept</code> conflict, slot already occupied in <code>[lwe, rwe)</code> (RFC 2883 sec. 4.1.2, partial duplicate)

When a D-SACK is pending and the standard scoreboard SACK would be
suppressed by dedup or rate-limit, the report is emitted as a
stand-alone SACK frame through the normal <code>ack_snd</code> path; when a
D-SACK report is pending the path bypasses dedup and the <code>TICTIME</code>
rate-limit, but the a-timer suppression on rcv inactivity still
applies.

Bare ACKs are deferred via a per-flow delayed-ACK timer (one in
flight at a time, atomic test-and-set dedup; fires per [[#3. Protocol parameters|Section 3]]
after the first in-order arrival). Suppressed if (1) no new
<code>seqno</code>, (2) rcv side is inactive (older than <code>t_a</code>), or (3) the
sender just sent within <code>TICTIME</code>. A pending D-SACK ride-through
bypasses (1) and (3); the a-timer gate (2) is unconditional.

== 11. Flow control ==

The receiver advertises <code>rwe</code> in every FC field. The sender treats
its <code>snd_cr.rwe</code> as the absolute right edge: when
<code>snd_cr.seqno >= snd_cr.rwe</code> the window is closed and <code>flow_write</code>
yields. While closed, the sender periodically emits RDVS
(rendezvous) packets (cadence <code>DELT_RDV</code>); the receiver replies with
a bare FC packet (<code>ackno = 0</code>) that reopens the window. Once the
window has been closed for longer than <code>MAX_RDV</code> the sender stops
emitting RDVS but does not tear the flow down - the writer keeps
blocking until either a peer-driven FC arrives or the KA
(keepalive) / r-timer marks the flow.

<code>rwe</code> is clamped to <code>lwe + RQ_SIZE</code> on receipt and MUST NOT shrink:
a backward <code>rwe</code> is silently clamped to the current <code>snd_cr.rwe</code>;
the FC packet still reopens the window.

== 12. RTT estimation ==

Active RTTP probes ([[#1.4. RTTP payload|Section 1.4]]) carry a 32-bit <code>probe_id</code> (0
reserved) and a 16-byte random nonce echoed verbatim - defends
against spoofed replies. A ring of <code>RTTP_RING</code> in-flight probes is
kept; an echo whose <code>(id, nonce)</code> doesn't match the ring slot is
dropped. A single RTTP sample is clamped to <code>RTT_CLAMP_MUL * srtt</code>
(compile-time <code>RTT_CLAMP_MUL = 16</code>) once <code>srtt</code> is seeded; the first
cold-probe sample feeds <code>rtt_update</code> raw.

Probe arming gates:

;Cold (no <code>srtt</code> yet)
:the receive path arms at most one probe per 100 ms via <code>frcti_rcv_probe</code> (<code>PROBE_DUE_COLD</code>); arming requires an incoming packet. Active send-path arming bails while <code>srtt == 0</code>.
;Warm (<code>rtt_probe_arm</code>, called from <code>frcti_snd</code>)
:outstanding data (<code>snd_cr.seqno > snd_cr.lwe</code>), AND at least <code>2 * srtt</code> since <code>t_rcv_rtt</code> (last RTT receive of any kind), AND at least <code>srtt</code> since <code>t_snd_probe</code> (last probe emit).

Sample feeds either Linux's asymmetric <code>mdev</code> estimator
(<code>FRCT_LINUX_RTT_ESTIMATOR</code>, default ON) or RFC 6298 symmetric EWMA
(compile option). <code>srtt</code> is floored at 10 ms when seeded from a
hint, at 1 us after every update (including the first seeding
sample); <code>mdev</code> floored at 100 ns.

:<code>RTO = max(rto_min, 2 * srtt, srtt + (mdev << MDEV_MUL))</code>

(the <code>2 * srtt</code> floor is an FRCT addition not in RFC 6298).
Effective wheel deadline capped per [[#3. Protocol parameters|Section 3]].

ACK-derived samples (<code>frcti_ack_rcv</code> -> <code>rtt_sample_eligible</code>), beyond
the cum-ACK advance gate in <code>frcti_ack_rcv</code> (<code>ackno > lwe</code> and
<code>ackno <= seqno</code>), require all of: not in recovery; ACK packet does
not carry <code>FRCT_RXM</code>; HoL slot's <code>SND_RTX</code> bit clear; slot's <code>rxm</code>
pointer non-NULL (not SACK-consumed); <code>lwe</code> not below the <code>rtt_lwe</code>
fence; <code>srtt</code> already seeded by an RTTP probe. There is no ACK-only
seeding.

Every eligible sample also feeds <code>RACK.min_RTT</code> (RFC 8985 sec. 6.2)
via a windowed minimum: replace whenever the sample is strictly
smaller OR more than <code>MIN_RTT_WIN_NS</code> (5 min, matches Linux
<code>tcp_min_rtt_wlen</code>) has elapsed since the current min was set. The
downward branch is immediate (faster path picked up at once); the
upward branch is gated on the window (a transient queue burst does
not poison the estimate, but a sustained route change to a longer
path re-anchors <code>min_RTT</code> after at most one window). Seeded from
<code>rtt_hint</code> at <code>rtt_init</code>; 0 acts as the unset sentinel and the base
in <code>rack_reorder_window</code> falls back from <code>min_RTT</code> to <code>SRTT</code> (so
<code>R = mult * SRTT/4</code>, capped at <code>SRTT</code>, floored at <code>MIN_REORDER_NS</code>)
until the first sample. See [[#6.2. Locked main path|Section 6.2]].

== 13. Liveness (keepalive) ==

When <code>qs.timeout > 0</code> a per-flow KA (keepalive) timer is armed.
Arming uses <code>rcv_cr.act</code> for the deadline computation:

:<code>deadline = min(snd_act + qs.timeout/4, rcv_act + qs.timeout)</code>

(clamped to <code>now + qs.timeout/4</code> if already past). The timer fires
either on sender idleness (to send a KA) or on receiver idleness
(to declare the peer dead). On fire (<code>ka_snd</code>) the peer-dead test
uses <code>max(rcv_cr.act, t_ka_rcv)</code> so a recent KA reply counts even
when no DATA has arrived:

* If <code>now - max(rcv_cr.act, t_ka_rcv) > qs.timeout</code>, mark the flow <code>ACL_FLOWPEER</code> and notify the per-process flow-event set (<code>proc.fqset</code>) with <code>FLOW_PEER</code>.
* Else if <code>snd_idle > qs.timeout/4</code>, emit a bare <code>KA | ACK</code> (<code>ackno = rcv_cr.lwe</code>) and re-arm.
* Else just re-arm.

Note: <code>rx_rb</code> and <code>tx_rb</code> are the receive and transmit shared-memory
ring buffers. The r-timer raises <code>ACL_FLOWDOWN</code> on both (route is
broken); keepalive raises <code>ACL_FLOWPEER</code> on <code>rx_rb</code> only and notifies
the flow-event set (peer is silent, writer keeps <code>tx_rb</code> usable) -
distinct ACLs. <code>qs.timeout == 0</code> disables keepalive entirely; a
silent peer crash is then undetected.

== 14. Linger / teardown ==

On <code>flow_dealloc</code>, <code>frcti_dealloc</code> computes a grace timeout

:<code>max(rcv_cr.act + rcv_cr.inact, snd_cr.act + snd_cr.inact) - now</code>

(floored at 0 and converted to seconds) and returns it; <code>flow_dealloc</code>
forwards this to the IRMd as the dealloc grace. The IRMd, not FRCT,
performs the wait. Before computing the timeout, FRCT may emit a
final ACK when <code>rcv_cr.lwe != rcv_cr.seqno</code> (the peer has not been
told the most recent cumulative ACK) AND the rcv side has been
active within <code>t_a</code> (a-timer not aged out).

<code>FRCTFLINGER</code> is honoured only when <code>snd_cr.lwe < edge</code>, where <code>edge =
snd_fin_seqno</code> after FIN has been sent in stream mode and
<code>snd_cr.seqno</code> otherwise (data or FIN still in flight). The drain
itself runs in <code>flow_dealloc</code>'s <code>while (FRCTI_LINGERING)</code> loop, not in
<code>frcti_dealloc</code>.

The fd is single-reader / single-writer (documented in the
manpages). <code>flow_write</code> pumps <code>rx_rb</code> on every call (via
<code>flow_wait_window</code> -> <code>flow_drain_rx_nb</code>) and additionally blocks on
<code>rx_rb</code> when the send window is closed. A pure-writer thread thus
consumes ACKs without a dedicated reader.

== 15. Heritage and adopted techniques ==

Delta-t (Watson, 1981) is the primary heritage; FRCP descends from
the delta-t protocol family via the Recursive InterNetwork
Architecture (RINA; Day, "Patterns in Network Architecture", 2008,
ch. 9). Timer-based connection management
(no SYN/FIN handshake, per-flow state born on first DATA and
reclaimed after <code>t_mpl + a + r</code> of silence), the DRF marker, and the
<code>t_mpl</code> / <code>t_a</code> / <code>t_r</code> timers all come from delta-t. See Watson,
"Timer-Based Mechanisms in Reliable Transport Protocol Connection
Management", Computer Networks 5 (1981).

The unified <code>flow_alloc(name, qos, ...)</code> primitive and its
multi-axis QoS-cube argument ([[#2.2. Service modes (orthogonal axes)|Section 2.2]]) also come from RINA
(Day 2008, ch. 6; Grasa et al., "IRATI: investigating RINA as an
alternative to TCP/IP", Computer Networks 92 (2015)) - reliability,
ordering, CRC presence, and encryption are flow attributes, not
separate sockets or protocols.

The table below summarises additional adopted techniques and their
references.

{| class="wikitable"
! FRCP mechanism !! Heritage !! Reference / note
|-
| Random new <code>seqno</code> on <code>seqno_rotate</code> || TCP ISN || RFC 6528 (Gont & Bellovin, 2012). QUIC PN-space reset (RFC 9000 sec. 12.3) is a structural analogue.
|-
| Cumulative ACK, left-window-edge advance || TCP || RFC 793 / RFC 9293
|-
| Receive window with non-shrink rule || TCP || RFC 793 sec. 3.7 / RFC 9293 sec. 3.8.6; RFC 1122 sec. 4.2.2.16 for the explicit non-shrink prohibition
|-
| Modular <code>seqno</code> arithmetic (<code>before</code>/<code>after</code> helpers) || TCP || RFC 793 sec. 3.3 / RFC 9293 sec. 3.4
|-
| Selective ACK block list || TCP || RFC 2018 (Mathis et al., 1996). Encoded as a typed FRCP packet rather than a TCP option, so framing is closer to QUIC ACK frames. D-SACK (RFC 2883) carried in-band as <code>block[0]</code>; see [[#1.3. SACK payload|Section 1.3]].
|-
| NewReno-careful recovery with <code>recovery_high</code> gate || TCP || RFC 6582 (Henderson et al., 2012); QUIC builds on the same model in RFC 9002 sec. 7.3.2. Cwnd half absent (CC in IPCP).
|-
| RACK reordering window for fast retransmit || TCP || RFC 8985 (Cheng et al., 2021). FRCP <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> with a <code>MIN_REORDER_NS = 250 us</code> floor against <code>srtt</code> collapse; matches RFC 8985 sec. 6.2 and Linux <code>tcp_rack_reo_wnd</code>. DSACK-driven <code>reo_wnd_mult</code> (sec. 6.2 step 4) is adopted; see [[#1.3. SACK payload|Section 1.3]] for the wire encoding. The hybrid RACK-or-<code>DUP_THRESH</code> trigger from RFC 8985 sec. 6.2 step 4 is adopted ([[#8. Retransmission|Section 8]]). QUIC's analogue in RFC 9002 sec. 6.1.2 uses <code>max(srtt, latest_rtt)</code> as the base.
|-
| 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> = 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.
|-
| Delayed ACK with rate suppression || TCP || RFC 813 (Clark, 1982); RFC 1122 sec. 4.2.3.2; RFC 5681 sec. 4.2. Single-deadline coalescing rather than "ack-every-other-segment".
|-
| Zero-window-probe / persist-timer analogue (RDVS) || TCP || RFC 1122 sec. 4.2.2.17 / RFC 9293 sec. 3.8.6.1. RDVS solicits an FC reply, distinct from QUIC <code>DATA_BLOCKED</code> (RFC 9000 sec. 19.12), which is one-way notification. <code>MAX_RDV</code> give-up departs from TCP.
|-
| Multiplexed control on a single PCI || SCTP / QUIC || SCTP chunk bundling (RFC 9260 sec. 6.10); QUIC frame multiplexing (RFC 9000 sec. 12.4). Cleaner fit than TCP's separate-flag-bits design.
|-
| ACK ranges as multiple discontiguous acked blocks || QUIC || QUIC ACK frame (RFC 9000 sec. 19.3). FRCP SACK is conceptually QUIC-frame-shaped even though encoded as absolute <code>[start,end]</code> pairs.
|-
| Nonce-authenticated active RTT / liveness probing (RTTP) || QUIC <code>PATH_CHALLENGE</code> || <code>PATH_CHALLENGE</code> / <code>PATH_RESPONSE</code> (RFC 9000 sec. 8.2, sec. 19.17, sec. 19.18). WebRTC ICE consent-freshness (RFC 7675) is the same pattern. QUIC's nonce is 8 octets; FRCP chooses 16.
|-
| Probing distinct from keepalive || QUIC || KA timer answers "peer alive?", RTTP answers "path measurable?", as in QUIC PING (RFC 9000 sec. 19.2) vs <code>PATH_CHALLENGE</code>.
|-
| Bare KA + ACK keepalive packets || QUIC / SCTP || QUIC PING (RFC 9000 sec. 19.2); SCTP HEARTBEAT / HEARTBEAT-ACK (RFC 9260 sec. 8.3). SCTP HEARTBEAT also carries an opaque echoed blob, structurally similar to FRCP RTTP.
|-
| (<code>FFGM</code>, <code>LFGM</code>) fragment-role bits ([[#7.2. Fragmentation and reassembly|Section 7.2]]) || SCTP || RFC 9260 sec. 3.3.1 DATA chunk B/E bits encode the same four states (<code>B+E=SOLE</code>, <code>B-only=FIRST</code>, neither=<code>MID</code>, <code>E-only=LAST</code>). Each fragment carries its own <code>seqno</code>/TSN and is independently retransmitted.
|-
| Stream byte-offset reassembly (Sections [[#1.5. Stream PCI extension|1.5]], [[#16. Stream-mode flows|16]]) || QUIC || QUIC STREAM frame (RFC 9000 sec. 19.8) uses Offset + Length varints; FRCP uses fixed 32-bit <code>start</code> / <code>end</code>. One stream per flow vs QUIC's many streams multiplexed.
|-
| FIN end-of-stream marker (Sections [[#1.2. Flag bits|1.2]], [[#16. Stream-mode flows|16]]) || TCP / QUIC || TCP FIN flag (RFC 9293 sec. 3.1) closes one half of the byte stream; QUIC STREAM frame FIN bit (RFC 9000 sec. 19.8) does the same per stream with an immutable final-size invariance (RFC 9000 sec. 4.5: the final size is fixed once observed). FRCP's FIN consumes one packet <code>seqno</code> (not one byte of stream space) and is idempotent on the sender side.
|-
| Stream byte-credit flow control ([[#16. Stream-mode flows|Section 16]]) || QUIC || <code>MAX_STREAM_DATA</code> (RFC 9000 sec. 4.1, sec. 19.10). FRCP projects a per-flow byte budget onto the <code>seqno</code>-space <code>rwe</code>. Single stream per flow collapses QUIC's <code>MAX_DATA</code> / <code>MAX_STREAM_DATA</code> distinction.
|-
| Header protection (encrypted seqnos) || QUIC || QUIC RFC 9001 sec. 5.4 applies header protection on top of AEAD to mask the packet number. FRCP's per-flow AEAD wrap ([[#16. Stream-mode flows|Section 16]]) is wider: it encrypts the entire PCI including <code>seqno</code> because the IPCP below already routes, so no destination connection-ID needs to stay in clear (cf. RFC 9000 sec. 5.2).
|-
| Two-bit fragment role polarity || SCTP || The (<code>FFGM</code>, <code>LFGM</code>) pair follows SCTP B/E (begin = 1 / end = 1) rather than IPv4 MF (RFC 791 sec. 3.2), which has the inverse polarity (MF = 1 means NOT last).
|-
| Orthogonal reliability / ordering axes ([[#2.2. Service modes (orthogonal axes)|Section 2.2]]) || SCTP || PR-SCTP (RFC 3758, per-message partial reliability) and SCTP DATA U-bit (RFC 9260 sec. 3.3.1, per-message unordered) are the closest precedents for decoupling reliability from ordering; FRCP sets them per-flow rather than per-message.
|-
| Orthogonal CRC (<code>qs.ber == 0</code>) || UDP-Lite || RFC 3828 (Larzon et al., 2004) lets the sender pick a per-packet Checksum Coverage and the receiver enforce a locally configured minimum (no in-band negotiation; sec. 3.1, sec. 3.3). FRCP gates a full CRC trailer on <code>qs.ber == 0</code> at flow setup. Contrast TCP / SCTP (mandatory checksum) and QUIC (AEAD subsumes CRC).
|-
| Setup-time service negotiation || DCCP / SCTP / QUIC || DCCP Service Codes (RFC 4340 sec. 8.1.2, RFC 5595); SCTP INIT parameters (RFC 9260 sec. 3.3.2); QUIC transport parameters (RFC 9000 sec. 7.4). All negotiate service properties at connection setup; only RINA's QoS cube exposes them as an orthogonal vector.
|}

=== 15.1. Original to FRCP (no clean prior art) ===

* Pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]): receiver-driven nudge exploiting <code>snd_cr.inact > rcv_cr.inact</code>. Closest analogues are SCTP Gap Ack Blocks (RFC 9260 sec. 3.3.4) and DCCP Ack Vector (RFC 4340 sec. 11.4) - both let the receiver describe gaps to the sender, but neither targets the cross-epoch / pre-DRF case.
* <code>MAX_RDV</code> window-probe give-up: neither TCP (persist-timer probes until application or R2 abort, RFC 9293 sec. 3.8.6.1) nor QUIC has an explicit FC-give-up counter. A recursive-network choice: outer layers can drop the flow.
* Skip-past-gap reassembly ([[#7.2. Fragmentation and reassembly|Section 7.2]]): SCTP fragments and reassembles every flow regardless of reliability/ordering, using its own per-stream reassembly queue; QUIC fragments via STREAM offsets. FRCP fragments best-effort flows too, but the receiver drops the broken prefix the moment a later run-start (<code>FIRST</code> or <code>SOLE</code> role) is visible inside the <code>RQ_SIZE</code>-wide reorder ring - no IP-frag-style timeout, no SCTP-style explicit abort. If no later run-start arrives within the ring, <code>frag_run_inspect</code> returns <code>NOT_READY</code> and the partial run keeps its slots; the next inspect retries. The trade-off: a permanently-lost <code>MID</code> in a long isolated run holds slots until either a later <code>FIRST</code>/<code>SOLE</code> appears in the ring or the writer stops, at which point the slots are reclaimed on flow teardown.
* Reassembly deferred to consume time ([[#7.2. Fragmentation and reassembly|Section 7.2]]), message mode only (<code>qos.service == SVC_MESSAGE</code>): SCTP (RFC 9260 sec. 6.9), QUIC (RFC 9000 sec. 2.2), and TCP (RFC 9293) all hold reassembly state at the receive boundary. FRCP message-mode leaves fragments in the shared-memory ring until <code>flow_read</code> pulls and lands the SDU directly in the caller's buffer. Stream mode ([[#16. Stream-mode flows|Section 16]]) uses the standard QUIC-style direct ring placement on receive and does not defer. The optimisation is enabled by the Shared-Memory Subsystem (SSM) packet-buffer ring (see <code>struct ssm_pk_buff</code> at [[#1.1. PCI header|Section 1.1]]); the analogue is OS-level scatter-gather I/O (<code>recvmsg+iovec</code>), not a transport-layer prior art.
* TLP-equivalent tail-loss recovery (RFC 8985 sec. 7; RFC 9002 sec. 6.2): FRCP does not emit an explicit Tail Loss Probe packet, but the same goal is met implicitly by RACK loss detection ([[#8. Retransmission|Section 8]]) firing on a non-advancing cumulative ACK once the head-of-line slot ages past the RACK reorder window <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> - well below <code>RTO = max(2 * SRTT, SRTT + (mdev << MDEV_MUL))</code>. A receiver-driven nudge is also available via the pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]).

=== 15.2. Not adopted ===

* Slow start, congestion window (cwnd), Additive Increase / Multiplicative Decrease (AIMD), NewReno cwnd inflation. Congestion control lives in the IPCP CA policies and is driven by Explicit Congestion Notification (ECN, RFC 3168).
* Nagle / silly-window-syndrome (SWS) avoidance (RFC 896, RFC 1122 sec. 4.2.3.4). (Deferred work, not adopted in the current spec.)
* TCP Timestamps (RFC 7323) / Protection Against Wrapped Sequences (PAWS) - RTT measurement uses RTTP, not per-segment timestamps. A peer-supplied timestamp echoed on every ACK lets a malicious peer drive the <code>srtt</code> estimate arbitrarily low, collapsing the RTO and triggering a self-inflicted retransmit storm. RTTP confines RTT measurement to nonce-authenticated probe round-trips, where a forged echo is rejected before it can reach the estimator.
* ECN (Explicit Congestion Notification) response inside FRCP (consumed by IPCP Congestion Avoidance / CA).
* 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).

== 16. Stream-mode flows ==

When a flow is allocated with <code>qos.service == SVC_STREAM</code> both peers
switch to byte-stream semantics, layered on top of the FRTX reorder
machinery already described in Sections [[#6. Receive path|6]]-[[#8. Retransmission|8]].

=== 16.1. Send ===

The sender splits the caller's octets into chunks of at most
<code>(frag_mtu - base PCI - stream PCI extension)</code> octets (Sections [[#1.1. PCI header|1.1]]
and [[#1.5. Stream PCI extension|1.5]]). Each chunk is one DATA packet with its own <code>seqno</code> and a
<code>[start, end)</code> byte range copied from a monotonic stream counter.
In stream mode <code>FFGM</code> and <code>LFGM</code> are unused and MUST be transmitted as
zero; the per-byte position is carried by the <code>[start, end)</code>
extension instead.

End-of-stream is signalled with a 0-byte DATA packet that has <code>FIN</code>
(bit 12) set, emitted on the FIN triggers listed in [[#1.2. Flag bits|Section 1.2]]
(WR-half close, <code>flow_dealloc</code>, and any other path that yields the
final byte). The sender MUST emit at most one FIN per flow; its
<code>[start, end)</code> MUST equal <code>[final-byte, final-byte)</code> (i.e., empty
interval at the final byte position; final-size invariance,
analogous to QUIC RFC 9000 sec. 4.5). Idempotency is enforced by
an <code>snd_fin_sent</code> guard.

=== 16.2. Receive ===

On arrival the receiver places the payload directly into a per-flow
byte-indexed receive ring of width <code>ring_sz</code> (octets) at the position
indicated by <code>start</code>, with a two-segment <code>memcpy</code> across the ring
boundary if needed. Receipt is recorded in the FRTX reorder
machinery ([[#6.2. Locked main path|Section 6.2]]) augmented with the packet's <code>start</code>, <code>end</code>, and
FIN bit per slot. When a packet's <code>[start, end)</code> front-overlaps
bytes already at or below the byte high-water mark, the overlap is
trimmed before placement so the same byte is never written twice.
After stashing, the receiver advances <code>lwe</code> and the byte high-water
mark across any newly-contiguous prefix. Each slot advanced MUST
satisfy <code>start == the last-delivered slot's end</code>; a slot whose
<code>start</code> does not equal that <code>end</code> is silently dropped at delivery time
(the <code>seqno</code> is consumed, no stream bytes contributed) and the high-
water mark does not advance past it. The stream byte-stream
stalls at that point - there is no flow-tear-down on mismatch.
This filters spliced or off-path-injected slots that fall in
window without strong cryptographic authentication.

A FIN slot marks end-of-stream at advance time only if its byte
position equals the last-delivered slot's <code>end</code>; otherwise the FIN
is ignored and the corresponding <code>seqno</code> occupies a slot but
contributes no stream bytes. No packet buffer is held after the
ring copy.

=== 16.3. Read ===

<code>flow_read</code> returns up to <code>count</code> octets from the contiguous prefix
<code>[next, high-water)</code>, where <code>next</code> is the byte the application has
already consumed up to and <code>high-water</code> is the rightmost contiguous
byte received. When the stream is fully drained AND end-of-stream
(EOS) was observed (<code>next == EOS</code> byte position), <code>flow_read</code> returns
0 (<code>EOF</code>) - the same shape POSIX <code>read(2)</code> uses on TCP after a peer
FIN.

=== 16.4. Flow control ===

ACK / SACK / RACK / RTO machinery is unchanged; the FRTX reorder
ring is reused as a per-<code>seqno</code> received-bitmap. Let <code>per_pkt =
(frag_mtu - base PCI - stream PCI extension)</code>, the maximum stream-
byte payload one DATA packet can carry ([[#16.1. Send|Section 16.1]]). The
receive window advertised in FC is clamped so the byte window
(<code>ring_sz</code>) cannot be overrun: the <code>seqno</code>-space <code>rwe</code> is at most
<code>rcv_cr.lwe + ring_sz / per_pkt</code>.

This is the QUIC byte-credit flow-control model
(<code>MAX_STREAM_DATA</code>, RFC 9000 sec. 4.1 and sec. 19.10) projected onto
<code>seqno</code> space. With one stream per flow there is no <code>MAX_DATA</code> /
<code>MAX_STREAM_DATA</code> distinction. Receiver-side silly-window-syndrome
(SWS) avoidance (RFC 9293 sec. 3.8.6.2.2) is achieved by combining
the consume-time <code>rwe</code> bump with the global non-shrink rule from
[[#11. Flow control|Section 11]].

=== 16.5. Security considerations ===

Threat model. An attacker that can observe (on-path passive) or
predict (off-path blind) the flow's seqnos and byte offsets on an
unencrypted stream flow can inject DATA or FIN at any in-window
position. The in-line consistency checks above (<code>start</code> == prior
<code>end</code> on advance; FIN MUST be 0-byte; FIN MUST sit at the final
byte position) realise the spirit of RFC 5961's "sequence-window
plus exact-position match for control bits" without an explicit
challenge-ACK probe; they make a few specific blind attack shapes
harder but are not cryptographic authentication. This is
comparable to TCP without the TCP Authentication Option (TCP-AO,
RFC 5925), tighter than a
pre-RFC-5961 TCP stack, and roughly equivalent to a modern
RFC 5961 stack against blind off-path injection - none of these
help once the attacker can sniff. TLS over TCP (RFC 8446)
encrypts only the TCP payload and leaves TCP seqnos, ACKs, FIN,
and RST in the clear, so TLS does NOT defend against TCP-header-
level injection; QUIC (RFC 9000) hides packet numbers under
header protection (RFC 9001 sec. 5.4), so this specific weakness
does not apply to QUIC.

Mitigation: AEAD. When the flow has encryption enabled the
recommended AEAD ciphers (AES-GCM, RFC 5288; or ChaCha20-Poly1305,
RFC 8439) wrap the entire FRCP packet on the wire - PCI, stream
extension, body, and the CRC trailer when <code>ber == 0</code> - under a
per-flow symmetric key derived from the flow's own key exchange
([[#1.1. PCI header|Section 1.1]]). The AEAD tag (~2^-128 forgery probability)
dominates the CRC (~2^-32) for integrity in this mode but the CRC
trailer is currently retained inside the wrap (see [[#1.1. PCI header|Section 1.1]]).
Implementations MUST NOT rely on the security properties below
when a non-AEAD cipher (e.g. AES-CTR alone) is negotiated; non-
AEAD modes provide confidentiality only and the threat-model
claims do not hold.

With an AEAD cipher in use, seqnos, byte offsets, and the FIN bit
are both authenticated and confidential. Against an off-path or
on-path-passive attacker this is:

* Stronger than TCP+TLS (TCP header in the clear).
* Stronger than TCP+TCP-AO (header authenticated but visible).
* 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. 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 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
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 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 ==

This section lists the IETF documents, published works, and
source-code references cited inline elsewhere in this document.
IETF documents are cited inline as "RFC NNNN sec. X.Y"; books,
journal papers, and source-code references are cited inline by
author and year (or by file and function name) and are listed
here for convenience.

=== 17.1. IETF documents ===

;[RFC 791]
:J. Postel, "Internet Protocol", STD 5, RFC 791, September 1981.
;[RFC 793]
:J. Postel, "Transmission Control Protocol", STD 7, RFC 793, September 1981. Obsoleted by RFC 9293.
;[RFC 813]
:D. D. Clark, "Window and Acknowledgement Strategy in TCP", RFC 813, July 1982.
;[RFC 896]
:J. Nagle, "Congestion Control in IP/TCP Internetworks", RFC 896, January 1984.
;[RFC 1122]
:R. Braden (ed.), "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
;[RFC 2018]
:M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
;[RFC 2119]
:S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
;[RFC 2883]
:S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
;[RFC 3758]
:R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
;[RFC 3828]
:L-A. Larzon, M. Degermark, S. Pink, L-E. Jonsson (ed.), G. Fairhurst (ed.), "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
;[RFC 4303]
:S. Kent, "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
;[RFC 4340]
:E. Kohler, M. Handley, S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
;[RFC 5288]
:J. Salowey, A. Choudhury, D. McGrew, "AES Galois Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, August 2008.
;[RFC 5595]
:G. Fairhurst, "The Datagram Congestion Control Protocol (DCCP) Service Codes", RFC 5595, September 2009.
;[RFC 5681]
:M. Allman, V. Paxson, E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
;[RFC 5925]
:J. Touch, A. Mankin, R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
;[RFC 5961]
:A. Ramaiah, R. Stewart, M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, August 2010.
;[RFC 6298]
:V. Paxson, M. Allman, J. Chu, M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, June 2011.
;[RFC 6528]
:F. Gont, S. Bellovin, "Defending against Sequence Number Attacks", RFC 6528, February 2012. Obsoletes RFC 1948.
;[RFC 6582]
:T. Henderson, S. Floyd, A. Gurtov, Y. Nishida, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 6582, April 2012.
;[RFC 7323]
:D. Borman, B. Braden, V. Jacobson, R. Scheffenegger (ed.), "TCP Extensions for High Performance", RFC 7323, September 2014.
;[RFC 7675]
:M. Perumal, D. Wing, R. Ravindranath, T. Reddy, M. Thomson, "Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness", RFC 7675, October 2015.
;[RFC 8174]
:B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017.
;[RFC 8200]
:S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, July 2017.
;[RFC 8439]
:Y. Nir, A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 8439, June 2018.
;[RFC 8446]
:E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, August 2018.
;[RFC 8985]
:Y. Cheng, N. Cardwell, N. Dukkipati, P. Jha, "The RACK-TLP Loss Detection Algorithm for TCP", RFC 8985, February 2021.
;[RFC 9000]
:J. Iyengar (ed.), M. Thomson (ed.), "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, May 2021.
;[RFC 9001]
:M. Thomson (ed.), S. Turner (ed.), "Using TLS to Secure QUIC", RFC 9001, May 2021.
;[RFC 9002]
:J. Iyengar (ed.), I. Swett (ed.), "QUIC Loss Detection and Congestion Control", RFC 9002, May 2021.
;[RFC 9147]
:E. Rescorla, H. Tschofenig, N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, April 2022.
;[RFC 9260]
:R. Stewart, M. Tuexen, K. Nielsen, "Stream Control Transmission Protocol", RFC 9260, June 2022. Obsoletes RFC 4960.
;[RFC 9293]
:W. Eddy (ed.), "Transmission Control Protocol (TCP)", STD 7, RFC 9293, August 2022. Obsoletes RFC 793 and several follow-ons; updates RFC 1122 and others.

=== 17.2. Books and journal papers ===

;[Day08]
:J. Day, "Patterns in Network Architecture: A Return to Fundamentals", Prentice Hall, 2008.
;[Grasa15]
:E. Grasa et al., "IRATI: investigating RINA as an alternative to TCP/IP", Computer Networks, Vol. 92, December 2015.
;[KP87]
:P. Karn, C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", ACM SIGCOMM, August 1987.
;[Wat81]
:R. W. Watson, "Timer-Based Mechanisms in Reliable Transport Protocol Connection Management", Computer Networks, Vol. 5, 1981.

=== 17.3. Source-code references ===

;[Linux-RTT]
:<code>tcp_rtt_estimator()</code> in <code>net/ipv4/tcp_input.c</code> of the Linux kernel, defining the asymmetric <code>mdev</code> variance update used as FRCP's default RTT estimator ([[#12. RTT estimation|Section 12]]). Line-stable browseable copy at https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_input.c.

[[Category:Protocols]]
[[Category:Ouroboros internals]]

Flow and Retransmission Control Protocol

2026-05-17T15:12:21Z

Dimitri: /* 16.5. Security considerations */

{{DISPLAYTITLE:FRCP - Flow and Retransmission Control Protocol}}

FRCP runs end-to-end between two peers over a flow. It delivers
reliability, in-order delivery, flow control, and liveness.
Congestion Control (CC) is not in FRCP - that lives in the IPC
Process (IPCP) Congestion Avoidance (CA) policies, orthogonal to
FRCP. Flow allocation, naming, and IPCP lifecycle are handled by
the IPC Resource Manager daemon (IRMd).

FRCT (Flow and Retransmission Control Task) is the libouroboros
implementation of FRCP; the task lives in <code>src/lib/frct.c</code>. The
remainder of this document describes the FRCP wire protocol and the
behaviour FRCT realises. Code symbols retain the <code>FRCT_</code> prefix
(<code>FRCT_DATA</code>, <code>FRCT_RXM</code>, ...) because they belong to the implementing
task; this document references them verbatim.

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in <code>BCP</code> 14 (Best
Current Practice; RFC 2119, RFC 8174) when, and only when, they
appear in all capitals.

== Notation ==

;<code>u32</code>, <code>u8</code>
:Unsigned 32-bit / 8-bit integers (kernel-C style).
;<code>ns</code>
:Nanoseconds.

Modular sequence-number comparators (32-bit, modulo 2^32):

;<code>before(a, b)</code>
:<code>(int32_t)(a - b) < 0</code>
;<code>after(a, b)</code>
:<code>before(b, a)</code>

Used throughout for <code>ackno</code> / <code>seqno</code> ordering checks.

Round-Trip Time (RTT) abbreviations used throughout:

;<code>SRTT</code>
:Smoothed RTT estimate (RFC 6298).
;<code>mdev</code>
:Mean deviation of RTT (Linux variance estimator).
;<code>EWMA</code>
:Exponentially Weighted Moving Average.
;<code>RTO</code>
:Retransmission Timeout, <code>max(RTO_MIN, srtt + (mdev << MDEV_MUL))</code>.

Timer-bound symbols <code>t_a</code> (a-timer, ACK delay) and <code>t_r</code> (r-timer,
retransmission window) are defined in [[#8. Retransmission|Section 8]]; <code>t_mpl</code> (Maximum
Packet Lifetime) is introduced in [[#2.1. Per-flow state|Section 2.1]] (the <code>inact</code> field)
with heritage in [[#15. Heritage and adopted techniques|Section 15]].

Wire-format diagrams follow the IETF convention: bit 0 is the
leftmost (most significant) bit and fields are in network byte
order unless stated otherwise.

__TOC__

== 1. Wire format ==

=== 1.1. PCI header ===

Fixed 16-octet base Protocol-Control Information (PCI) header
prefixed to every FRCP packet (RFC convention: bit 0 leftmost,
most-significant bit first). All multi-byte fields except <code>hcs</code>
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
[[#1.5. Stream PCI extension|Section 1.5]]); SACK and RTTP carry their own payloads after the
base PCI.

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | hcs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ackno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload (variable) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>flags</code>
:feature/type bitmap (see [[#1.2. Flag bits|Section 1.2]]).
;<code>hcs</code>
:CRC-16-CCITT-FALSE Header Check Sequence (HCS) over <code>flags</code> + <code>window</code> + <code>seqno</code> + <code>ackno</code> (+ stream extension when present); the two octets of the <code>hcs</code> field itself are omitted from the CRC input. Verified on receive before any flag-driven dispatch.
;<code>window</code>
:receiver-advertised right window edge (valid iff FC).
;<code>seqno</code>
:per-flow sequence number.
;<code>ackno</code>
:cumulative Acknowledgement (ACK) (valid iff ACK).

A single packet can simultaneously carry DATA + ACK + FC (Flow
Control) + RXM (Retransmission) by ORing flag bits; the PCI
multiplexes control on the same wire frame in the spirit of SCTP
chunk bundling (RFC 9260 sec. 6.10) and QUIC frame multiplexing
(RFC 9000 sec. 12.4). DATA-bearing packets carry the caller's
payload after the PCI; SACK (Selective Acknowledgement) and RTTP
(Round-Trip Time Probe) carry their own typed payloads after the
PCI.

Optional framing (per-flow, see [[#2.2. Service modes (orthogonal axes)|Section 2.2]]). On the wire, the
order from inside out is:

{| class="wikitable"
! Layer !! Scope
|-
| <code>[ PCI + body ]</code>
| The FRCP packet.
|-
| <code>[ PCI + body + CRC-32 ]</code>
| CRC-32 covers the body only (PCI is in HCS); appended iff <code>qs.ber == 0</code> on DATA, or on every SACK packet.
|-
| <code>[ AEAD-wrap of above ]</code>
| Iff Authenticated Encryption with Associated Data (AEAD) is enabled.
|}

* 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.
* 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>).

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

=== 1.2. Flag bits ===

Flag bits are numbered most-significant-bit first to match the wire
diagram (bit numbering per [[#1.1. PCI header|Section 1.1]]; bit 0 is the MSB of the
16-bit <code>flags</code> field and lands at wire-position 0 in network byte
order). Bits 13..15 are reserved and MUST be transmitted as zero.

{| class="wikitable"
! Bit !! Mask !! Name !! Meaning
|-
| 0 || <code>0x8000</code> || <code>DATA</code> || Carries caller payload
|-
| 1 || <code>0x4000</code> || <code>DRF</code> || Data Run Flag: start of a fresh run
|-
| 2 || <code>0x2000</code> || <code>ACK</code> || Acknowledgement: <code>ackno</code> field valid
|-
| 3 || <code>0x1000</code> || <code>NACK</code> || Negative ACK; <code>seqno = arrival_seqno-1</code>
|-
| 4 || <code>0x0800</code> || <code>FC</code> || Flow Control: <code>window</code> field valid (<code>rwe</code>)
|-
| 5 || <code>0x0400</code> || <code>RDVS</code> || Rendezvous probe (window-closed)
|-
| 6 || <code>0x0200</code> || <code>FFGM</code> || First Fragment (role bit 0; see below)
|-
| 7 || <code>0x0100</code> || <code>LFGM</code> || Last Fragment (role bit 1; see below)
|-
| 8 || <code>0x0080</code> || <code>RXM</code> || Retransmission
|-
| 9 || <code>0x0040</code> || <code>SACK</code> || Selective ACK block list in payload
|-
| 10 || <code>0x0020</code> || <code>RTTP</code> || RTT Probe / echo (payload follows)
|-
| 11 || <code>0x0010</code> || <code>KA</code> || Keepalive
|-
| 12 || <code>0x0008</code> || <code>FIN</code> || End-of-stream marker (stream mode)
|-
| 13-15 || -- || -- || Reserved (MUST be zero)
|}

The (<code>FFGM</code>, <code>LFGM</code>) pair encodes the fragment role of a DATA-bearing
Service Data Unit (SDU), SCTP-style begin/end flags (RFC 9260
sec. 3.3.1):

{| class="wikitable"
! FFGM !! LFGM !! Role
|-
| 1 || 1 || Sole / un-fragmented SDU (begin AND end)
|-
| 1 || 0 || First fragment of a multi-fragment SDU
|-
| 0 || 0 || Middle fragment
|-
| 0 || 1 || Last fragment
|}

Each fragment is carried in its own FRCP packet with its own <code>seqno</code>;
FRTX (the FRCT Retransmission service mode, see [[#2.2. Service modes (orthogonal axes)|Section 2.2]])
recovers individual fragments via the normal Retransmission Timeout
(RTO) / SACK / Recent Acknowledgement (RACK, RFC 8985) path. The
receiver reassembles the SDU at consume time once the contiguous
[FIRST .. LAST] run has fully arrived. On non-DATA packets the role
bits are unused and MUST be transmitted as zero.

In stream mode (<code>qos.service == SVC_STREAM</code>, see [[#16. Stream-mode flows|Section 16]]) there are
no SDU boundaries to encode, so <code>FFGM</code> and <code>LFGM</code> are unused and MUST
be transmitted as zero. End-of-stream uses a dedicated bit (<code>FIN</code>,
bit 12) carried on a 0-byte DATA packet, emitted at write-half close
(<code>fccntl</code> to <code>FLOWFRDONLY</code>), during linger drain, and at <code>flow_dealloc</code>;
emission is idempotent (first call wins). After contiguous delivery
of the FIN-bearing slot, the receiver latches <code>byte_fin</code> at the FIN's
start offset; <code>flow_read</code> returns 0 (end-of-file, <code>EOF</code>) once buffered
bytes have been drained up to <code>byte_fin</code>. Per-byte position is
carried by the [start, end) extension ([[#1.5. Stream PCI extension|Section 1.5]]).

=== 1.3. SACK payload ===

A SACK packet has the <code>FRCT_ACK | FRCT_FC | FRCT_SACK</code> flag bits set
(bit numbering per [[#1.1. PCI header|Section 1.1]]). Following the 16-octet PCI, the
payload is a 2-octet block count (network byte order), 2 octets of
padding to 4-byte align the block list, then <code>n_blocks</code> pairs of
32-bit start/end seqnos describing ''present'' (received) ranges
above the cumulative ACK.

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_blocks | padding (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start[0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end[0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... n_blocks pairs total ...
</syntaxhighlight>

<code>n_blocks <= SACK_MAX_BLOCKS</code> (2048). The per-flow effective cap is
further bounded by <code>(frag_mtu - PCI - 4) / 8</code> blocks per packet; SACK
packets carry no stream extension, so PCI here is the 16-octet base
header even on stream-mode flows.

Wire invariant: every block produced by the receiver, except an
optional leading Duplicate SACK (D-SACK) block as described below,
describes a range strictly above the cumulative ACK carried in the
PCI <code>ackno</code> field (<code>after(start[i], ackno)</code>). This makes the D-SACK
convention below unambiguous; the receiver-side builder MUST
preserve it.

Duplicate SACK (D-SACK, RFC 2883) is signalled in-band: no flag
bit, no extra framing. Modular seqno arithmetic uses the
<code>before()</code> / <code>after()</code> comparators defined in the Notation block.
<code>Block[0]</code> carries a D-SACK report when either:

;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.
;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.

Senders that do not implement D-SACK process <code>block[0]</code> through the
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
(cap 20), halve once per 16 cumulatively-ACK'd seqnos since the
most recent D-SACK arrival or halve event, reset to 1 on an RTO
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
count as gaps.

=== 1.4. RTTP payload ===

An RTTP (Round-Trip Time Probe) packet has only the <code>FRCT_RTTP</code> flag
set (bit numbering per [[#1.1. PCI header|Section 1.1]]). Following the 16-octet PCI,
the payload is 24 octets (packed):

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| probe_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| echo_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ nonce (16 octets, echoed verbatim) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>probe_id</code>
:sender counter, 0 on reply, 0 reserved.
;<code>echo_id</code>
:peer's <code>probe_id</code>, 0 on outbound probe.
;<code>nonce</code>
:random, echoed unmodified, memcmp'd to defeat spoof.

=== 1.5. Stream PCI extension ===

A stream-mode flow (<code>qos.service == SVC_STREAM</code>) carries an extra
8-octet extension after the 16-octet base PCI on every DATA packet
(bit numbering per [[#1.1. PCI header|Section 1.1]]):

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>start</code>
:octet offset of the first payload byte in the stream.
;<code>end</code>
:octet offset one past the last payload byte; <code>end - start</code> equals the on-wire payload length.

Total stream-mode PCI for DATA packets is 24 octets (16 base + 8
extension); control packets (SACK, RTTP, bare ACK, KA, etc.) retain
the 16-octet base PCI. Stream mode MUST be negotiated at flow
allocation; the extension is present iff stream mode is in use,
never on a per-packet basis. Both peers MUST treat <code>start</code>/<code>end</code> as
monotonic 32-bit byte offsets; when a slot reaches the head of the
contiguous run with <code>start</code> not equal to the prior packet's <code>end</code> the
slot is silently dropped at delivery time ([[#16. Stream-mode flows|Section 16]]) rather
than rejected at stash.

This is the QUIC STREAM-frame reassembly model (RFC 9000 sec. 19.8):
each packet carries its packet <code>seqno</code> (this PCI's <code>seqno</code> field) and a
separate stream byte position (<code>start</code>/<code>end</code>). Separating the two
avoids TCP's conflation of packet identity with byte position which
forces Karn's algorithm for Round-Trip Time (RTT) sampling (no RTT
sample on retransmits, RFC 6298 sec. 3); FRCP applies the
Karn-equivalent gate via a combination of per-packet <code>FRCT_RXM</code>,
per-slot <code>SND_RTX</code> flags, and a sample-fence <code>rtt_lwe</code> (see [[#2.1. Per-flow state|Section 2.1]]
and [[#12. RTT estimation|Section 12]]). FRCP's fixed-32-bit <code>start</code>/<code>end</code> wrap at 4 GiB of
wire bytes, narrower than QUIC's 62-bit varint offset (cf. RFC 9000
sec. 16); the on-wire wrap is handled by the same modular <code>before()</code>
/ <code>after()</code> comparators ([[#1.3. SACK payload|Section 1.3]]) FRCP uses for seqnos, which
remain unambiguous as long as the in-flight byte window stays
strictly under 2 GiB (the half-range of the signed-int32 difference
in <code>before()</code>). The default per-flow ring is 1 MiB; the
implementation caps <code>ring_sz</code> at 128 MiB (<code>FRCT_STREAM_RING_SZ_MAX</code>),
well below the 2 GiB half-range bound. The runtime byte counters
exposed via FUSE (Filesystem in Userspace) in the Ouroboros
Resource Information Base (RIB, a virtual-filesystem introspection
bridge) are platform <code>size_t</code> and do not wrap on 64-bit hosts.

== 2. Per-flow state and service modes ==

=== 2.1. Per-flow state ===

Each flow keeps a sender control record and a receiver control
record:

;<code>lwe</code> : <code>u32</code>
:snd: oldest unacked <code>seqno</code> (cumulative ACK boundary as seen by sender); rcv: next in-order <code>seqno</code> expected
;<code>rwe</code> : <code>u32</code>
:snd: peer-advertised right window edge; rcv: locally-advertised right window edge
;<code>cflags</code> : <code>u8</code>
:per-direction feature flags: retransmission (<code>FRCTFRTX</code>), receiver flow control (<code>FRCTFRESCNTL</code>), linger-on-close (<code>FRCTFLINGER</code>); see <code><ouroboros/fccntl.h></code>
;<code>seqno</code> : <code>u32</code>
:snd: next <code>seqno</code> to send; rcv: force-ACK trigger - set on a stale or dup DATA so the next <code>ack_snd</code> emits a fresh cumulative ACK
;<code>ackno</code> : <code>u32</code>
:snd: <code>seqno</code> counter for standalone ACK-bearing control packets (delayed ACK, SACK, final ACK on dealloc); not bumped on piggybacked ACK riding a DATA packet (which uses the DATA <code>seqno</code>). Used by wire-dup ACK detection; rcv: incoming-ACK dedup tracker
;<code>act</code> : <code>ns</code>
:last activity (used by inactivity / DRF)
;<code>inact</code> : <code>ns</code>
:inactivity threshold; sender = <code>3*mpl + a + r + 1s</code>, receiver = <code>2*mpl + a + r + 1s</code>. <code>mpl</code> is the Maximum Packet Lifetime (delta-t terminology; see [[#15. Heritage and adopted techniques|Section 15]]); <code>a</code> and <code>r</code> are the FRCT a-timer and r-timer bounds (see [[#8. Retransmission|Section 8]]). The asymmetry is load-bearing for pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]).

The sender holds a per-slot ring <code>snd_slots[RQ_SIZE]</code> keyed by
<code>(seqno mod RQ_SIZE)</code>. Each slot tracks its retransmit entry (<code>rxm</code>),
last-send timestamp, and retransmit flag bits: <code>SND_RTX</code> (a
retransmit is pending or has fired, gates the next RTT sample
under Karn) and <code>SND_FAST_RXM</code> (one-shot fast-retransmit staged for
this loss event).

The receiver holds a parallel reorder ring <code>rcv_slots[RQ_SIZE]</code>
(referred to as <code>rq[]</code> in prose) holding stashed out-of-order
packet-buffer indexes; both FRTX and best-effort flows share this
path. The invariant <code>rwe - lwe <= RQ_SIZE</code> holds: on each consume
the receiver advances <code>rwe</code> by the consumed count, capping the
receive window at <code>RQ_SIZE</code> <code>seqno</code> slots.

A separate fence variable <code>rtt_lwe</code> is bumped on every retransmit
(timer-fire, SACK-driven, fast-rxm, NACK-driven) and on every
<code>seqno_rotate</code> ([[#4. Sequence-number rotation (DRF)|Section 4]]) to mark the <code>seqno</code> range whose RTT samples
MUST be discarded.

=== 2.2. Service modes (orthogonal axes) ===

FRCP exposes its wire features as a vector of independent QoS
axes selected at flow allocation time. All flows go through the
same <code>flow_alloc(name, qos, ...)</code> primitive; the <code>qosspec_t</code> passed
in determines which protocol machinery engages on the wire. This
contrasts with the POSIX BSD socket model where TCP and UDP
require different socket types (<code>SOCK_STREAM</code> / <code>SOCK_DGRAM</code>).

The axes:

;<code>service</code>
:0 = unordered (no FRCP engagement: raw datagrams, no PCI on the wire, UDP-equivalent at this layer); 1 = message-ordered (FRCP engaged; SDU boundaries preserved across fragmentation); 2 = stream (byte-oriented, no SDU boundaries; FRTX required)
;<code>loss</code>
:0 = lossless service requested: FRTX retransmit machinery engages ([[#8. Retransmission|Section 8]]); MUST be 0 for <code>service=2</code>. Non-zero = best-effort, FRTX off.
;<code>ber</code>
:Bit Error Rate tolerance. 0 = error-free service requested: a CRC trailer is appended after the body of DATA packets and verified on receive (added / checked outside the FRCP PCI; see [[#1.1. PCI header|Section 1.1]]). Non-zero = peer accepts errors; trailer omitted. SACK control packets carry a CRC32 trailer regardless of <code>ber</code>; the <code>ber</code> gate applies to DATA only.
;<code>timeout</code>
:Peer-timeout (ms); 0 disables the keepalive timer. Independent of FRCP engagement.

Encryption is a separate per-flow attribute set at flow setup;
when enabled it wraps the FRCP packet (PCI + body, plus the CRC
trailer if any) under AEAD, expanding the <code>spb</code> by <code>headsz</code> + <code>tailsz</code>
octets (nonce / tag). The CRC trailer is currently kept inside
the AEAD wrap (see [[#1.1. PCI header|Section 1.1]]).

Reachable combinations exported by <code>include/ouroboros/qos.h</code>:

{| class="wikitable"
! Cube !! <code>service</code> !! <code>loss</code> !! <code>ber</code> !! Engaged
|-
| <code>qos_raw</code> || 0 || 1 || 1 || Raw passthrough
|-
| <code>qos_raw_safe</code> || 0 || 1 || 0 || Raw + CRC trailer
|-
| <code>qos_rt</code> || 1 || 1 || 1 || FRCP, no FRTX, no CRC
|-
| <code>qos_rt_safe</code> || 1 || 1 || 0 || FRCP, no FRTX, CRC
|-
| <code>qos_msg</code> || 1 || 0 || 0 || FRCP + FRTX
|-
| <code>qos_stream</code> || 2 || 0 || 0 || FRCP + FRTX, stream
|}

Forced couplings actually enforced by the public API:

* <code>service == SVC_STREAM</code> (2) requires <code>loss == 0</code>; <code>flow_alloc</code> / <code>flow_accept</code> reject the pair otherwise with <code>-EINVAL</code>.
* FRTX requires FRCP engagement (<code>service != SVC_RAW</code>); requesting <code>loss = 0</code> with <code>service = SVC_RAW</code> is structurally a no-op because no <code>frcti</code> is created.
* The <code>QOS_DISABLE_CRC</code> build flag globally forces <code>ber = 1</code>. Note: this flag defaults to ON, so default builds ship with CRC disabled until <code>QOS_DISABLE_CRC</code> is set to OFF.

Caveat: the API does NOT force <code>ber = 0</code> when <code>service != SVC_RAW</code>.
<code>qos_rt</code> has <code>service = SVC_MESSAGE</code> with <code>ber = 1</code>, which means the PCI
itself is not CRC-protected on that cube; the HCS ([[#1.1. PCI header|Section 1.1]])
remains the only integrity check on the header.

The FRCP-no-FRTX regime (<code>service = SVC_MESSAGE</code>, <code>loss > 0</code>) is meaningful
and live: sequence numbering, in-order delivery, flow-control
advertisement, KA, DRF rotation, and SDU fragmentation /
reassembly ([[#7.2. Fragmentation and reassembly|Section 7.2]]) all run. Lost packets are dropped
rather than retransmitted; a permanently-lost mid-fragment is
dropped via skip-past-gap once a later SDU is visible in the
reorder ring.

== 3. Protocol parameters ==

{| class="wikitable"
! Parameter !! Value !! Role
|-
| <code>RQ_SIZE</code> || compile-time, power of 2 (default 128) || Slot ring / rcv window width
|-
| <code>START_WINDOW</code> || compile-time, power of 2 (default 128) || Initial <code>rwe-lwe</code> after rotate
|-
| <code>RTO_MIN</code> || <code>MAX(250 us build-tunable, 1<<RXMQ_RES)</code>; per-flow via <code>fccntl</code> (<code>FRCTSRTOMIN</code>). Default ~1 ms with <code>RXMQ_RES=20</code>. || RTO floor; also floored at the retransmit-wheel resolution (~1 ms by default).
|-
| <code>MAX_RTO_MUL</code> || 20 || Backoff shift cap
|-
| RACK window <code>R</code> || <code>MIN(reo_wnd_mult * min_RTT/4, SRTT)</code> with <code>MIN_REORDER_NS = 250 us</code> floor; <code>reo_wnd_mult</code> scales on D-SACK, cap 20 || Reorder window; per RFC 8985 sec. 6.2; <code>reo_wnd_mult</code> per sec. 6.2 step 4
|-
| <code>MIN_RTT_WIN_NS</code> || 300 s (5 min, Linux <code>tcp_min_rtt_wlen</code>) || <code>min_RTT</code> windowed re-anchor
|-
| <code>REO_WND_MULT_MAX</code> || 20 (RFC 8985 sec. 6.2 step 4) || <code>reo_wnd_mult</code> cap
|-
| <code>REO_DECAY_PKTS</code> || 16 (RFC 8985 sec. 6.2 step 4 / <code>RACK.reo_wnd_persist</code>) || Fresh-ACK'd seq count per halving
|-
| <code>MAX_DSACK_LAG</code> || <code>RQ_SIZE</code> || D-SACK sanity cap
|-
| <code>RTT_QUARANTINE</code> || 32 (<code>seqno</code> steps) || NewReno gate pad
|-
| SACK rate-limit || <code>SACK_MIN_GAP_NS</code> (250 us, fixed) || Min SACK gap
|-
| <code>SACK_MAX_BLOCKS</code> || 2048 (wire cap; per-flow capped at <code>(frag_mtu-PCI-4)/8</code>) || Per-SACK block cap
|-
| <code>SACK_RXM_MAX</code> || 32 || Per-pass staged retransmit cap
|-
| <code>DUP_THRESH</code> || 3 (RFC 8985 default) || Hybrid fast-rxm trigger ([[#8. Retransmission|Section 8]])
|-
| <code>MDEV_MUL</code> || 2 (build-tunable via <code>FRCT_RTO_MDEV_MULTIPLIER</code>) || <code>mdev</code> shift in <code>RTO = srtt + (mdev << MDEV_MUL)</code>
|-
| RTTP nonce || 16 octets || Echoed verbatim
|-
| <code>RTTP_RING</code> || 8 || In-flight probes
|-
| RTT clamp || <code>16 * srtt</code> || Probe-sample upper bound (ACK-derived RTT samples gated by Karn / recovery only)
|-
| Cold-probe cadence || 100 ms (rx-driven; see [[#12. RTT estimation|Section 12]]) || Pre-<code>srtt</code> RTTP rate
|-
| <code>DELT_RDV</code> || 100 ms || RDVS emit cadence
|-
| <code>MAX_RDV</code> || 1 s || RDVS give-up
|-
| Delayed-ACK fire || <code>2 * TICTIME</code> (<code>TICTIME</code> = FRCT tick granularity, default 5 ms; <code>2*TICTIME = 10 ms</code> by default) || Fired after the first in-order DATA arrival; tick is build-tunable
|-
| NACK send cooldown || <code>srtt</code> when an <code>srtt</code> sample exists, else 100 ms || Pre-DRF NACK rate-limit
|-
| <code>MAX_SDU</code> || 1 MiB || Max reassembled SDU; configurable per flow
|}

The per-flow fragment Maximum Transmission Unit (MTU) is computed
at flow setup from the lower IPCP's mtu minus encryption
<code>headsz</code> / <code>tailsz</code> and CRC trailer; there is no FRCT-level default or
environment-variable override.

== 4. Sequence-number rotation (DRF) ==

The DRF (Data Run Flag) bit on an outbound packet means "this is
the start of a fresh data run" and is set whenever the sender has
nothing in flight (<code>snd_cr.seqno == snd_cr.lwe</code>).

Independently of that, if the sender has been idle longer than
<code>snd_cr.inact</code> AND the pipe is empty (<code>snd_cr.seqno == snd_cr.lwe</code>),
<code>seqno_rotate()</code> rolls a random new <code>seqno</code> before the send and
resets

<syntaxhighlight lang="text">
snd_cr.seqno = random()
snd_cr.lwe = snd_cr.seqno
snd_cr.rwe = snd_cr.seqno + START_WINDOW
rtt_lwe = snd_cr.seqno
in_recovery = false (recovery state, see Section 8)
recovery_high = snd_cr.seqno
</syntaxhighlight>

The receiver, on observing rcv-side inactivity
(<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
below). Non-DATA control packets pass through without the DRF
requirement. On DRF the receiver releases the <code>rq[]</code> slots and
rebases

<syntaxhighlight lang="text">
rcv_cr.lwe = seqno
rcv_cr.rwe = seqno + RQ_SIZE
rcv_cr.seqno = seqno
</syntaxhighlight>

If the inactive packet has DATA but no DRF, a rate-limited NACK is
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).

== 5. Send path ==

# If the SDU exceeds <code>(frag_mtu - data_hdr_len)</code>, the caller (<code>dev.c</code>) fans it out into <code>ceil(count / (frag_mtu - data_hdr_len))</code> fragments, each emitted via <code>frcti_snd</code> as its own DATA packet with a per-fragment role ([[#7.2. Fragmentation and reassembly|Section 7.2]]); both FRTX and best-effort flows fragment. Raw flows (no FRCP engagement, <code>qos.service == SVC_RAW</code>) carry no PCI and return <code>-EMSGSIZE</code> for any SDU larger than one packet at the layer below. An SDU that fits in a single packet is sent as SOLE. <code>frcti_snd</code> reserves PCI head room; sets DATA, plus DRF when the pipe is empty (<code>snd_cr.seqno == snd_cr.lwe</code>).
# <code>seqno_rotate()</code> if past sender inactivity and the pipe is empty ([[#4. Sequence-number rotation (DRF)|Section 4]]).
# Advertise FC (<code>pci.window = frcti_advert_rwe(frcti)</code>, i.e. <code>rcv_cr.rwe</code> clamped to <code>rcv_cr.lwe + ring_seq_cap</code> in stream mode) when the receiver side is recent: <code>now - rcv_cr.act < rcv_cr.inact</code>.
# Reliable mode (FRTX): leave <code>snd_cr.lwe</code> where it is; reset the slot at <code>RQ_SLOT(seqno)</code> (<code>snd_slots[p].time = now</code>, <code>snd_slots[p].flags = 0</code>); queue an <code>rxm_entry</code> (saves a packet copy, arms a wheel timer at <code>now + (rto << rto_mul)</code>). Piggyback ACK (<code>pci.ackno = rcv_cr.lwe</code>) while the a-timer for the most recent received DATA packet has not yet expired (<code>now - rcv_cr.act <= t_a</code>); on piggyback, set <code>rcv_cr.seqno = rcv_cr.lwe</code> so the next delayed-ACK fire is suppressed. See [[#8. Retransmission|Section 8]] for <code>t_a</code> / <code>t_r</code> semantics.
# Best-effort mode (no FRTX): advance <code>snd_cr.lwe</code> immediately (<code>snd_cr.lwe = snd_cr.lwe + 1</code>, <code>snd_cr.rwe = snd_cr.lwe + RQ_SIZE</code>); no retransmit state. No send-side RTT probe is armed in this mode (<code>rtt_probe_arm</code> requires an in-flight <code>seqno</code>, which best-effort never has); the rx-driven cold seeder in <code>frcti_rcv</code> is the only probe path.
# In reliable mode, optionally arm an RTT probe ([[#12. RTT estimation|Section 12]]).

== 6. Receive path ==

=== 6.1. Early-exit dispatch ===

Keepalive (KA), RTT probe (RTTP), pre-DRF NACK, and rendezvous
(RDVS) packets short-circuit out of <code>frcti_rcv</code> before the locked
main path; each handler takes its own lock internally.

<syntaxhighlight lang="text">
incoming packet
|
v
+---------+
| KA? |---yes--> ka_rcv ; return
+---------+
|no
v
+---------+
| RTTP? |---yes--> rttp_rcv; return
+---------+
|no
v
+---------+
| NACK? |---yes--> nack_rcv; return (see Section 9)
+---------+
|no
v
+---------+
| RDVS? |---yes--> rdv_rcv ; return (reply bare FC, ackno=0)
+---------+
|no
v
acquire wrlock; enter locked main path
</syntaxhighlight>

;<code>KA</code>
:refresh <code>t_ka_rcv</code>, honour piggybacked ACK.
;<code>RTTP</code>
:probe (echo back nonce) or echo (verify nonce, sample RTT).
;<code>NACK</code>
:pre-DRF, sender-side handler. See [[#9. Pre-DRF NACK|Section 9]].
;<code>RDVS</code>
:reply with a bare FC packet (<code>ackno = 0</code>); <code>rdlock</code> only.

=== 6.2. Locked main path ===

Steps below run with the per-flow <code>frcti.lock</code> held for writing
(<code>pthread_rwlock_wrlock</code>) unless noted.

;<code>rcv_inact_check</code>
:Only meaningful when the receive side is stale. On DRF (Data Run Flag): release <code>rq[]</code> slots, rebase <code>rcv_cr</code>, continue. On stale DATA without DRF: fire a pre-DRF NACK if cooldown allows ([[#9. Pre-DRF NACK|Section 9]]), then discard the packet; on cooldown, drop without sending a NACK (a pending cumulative ACK from <code>drop_packet</code> may still go out). Non-DATA, non-DRF arrivals bypass <code>rcv_inact_check</code> entirely; pure-DRF stale arrivals fall through after the DRF rebase branch.

;DATA-only act refresh
:Refresh <code>rcv_cr.act</code> only when <code>FRCT_DATA</code> is set, so that non-DATA packets never block the next DRF rebase.

;Wire-dup gate
:Before flag-driven dispatch, drop wire-duplicate ACKs and wire-duplicate DATA (<code>is_dup_ack</code> / <code>is_dup_data</code>). The DATA check is bypassed for <code>FRCT_RXM</code>-bearing arrivals so the piggybacked ACK / SACK / FC carried on a retransmitted DATA at an already-ACK'd <code>seqno</code> is still applied; the stale-in-window branch below then drops the packet.

;<code>ACK</code>
:Drop ACKs whose <code>ackno</code> falls outside <code>(snd_cr.lwe, snd_cr.seqno]</code>. If <code>ackno == snd_cr.lwe</code> (non-advancing cumulative ACK), drive RACK fast-retransmit consideration ([[#8. Retransmission|Section 8]]). Otherwise advance <code>snd_cr.lwe = ackno</code>, collapse <code>rto_mul</code> to 0 (Karn-gated by <code>SND_RTX</code> on the just-acknowledged slot, the old head-of-line), reset <code>dup_thresh</code> to 0, update <code>t_latest_ack</code> to the send-time of the slot at <code>ackno-1</code> (consumed by RACK and SACK below), decay <code>reo_wnd_mult</code> per RFC 8985 sec. 6.2 step 4, exit NewReno-careful recovery (see [[#8. Retransmission|Section 8]]) on <code>ackno >= recovery_high</code> or <code>ackno == snd_cr.seqno</code>, and feed an RTT sample if eligible ([[#12. RTT estimation|Section 12]]).

;<code>SACK</code>
:Walk the block list. For each block (a present range above <code>lwe</code>) NULL out <code>snd_slots[k].rxm</code>, clear the slot's per-send flags, and advance <code>t_latest_ack</code> to the latest send-time covered (the Forward Acknowledgement / fack equivalent, Mathis & Mahdavi 1996); the first block whose start clamps to <code>snd_cr.lwe</code> skips this fack update so that a head-of-line clamp does not falsely advance fack. For un-SACKed gaps below <code>hi_sacked</code>, stage a retransmit per slot that is (1) still owned (<code>rxm != NULL</code>), (2) not already <code>SND_FAST_RXM</code>, (3) not aged out past <code>t_r</code>, and (4) either outside the RACK reorder window <code>R</code> OR with <code>dup_thresh >= DUP_THRESH</code> (the RFC 8985 sec. 6.2 hybrid trigger). Mark the slot <code>SND_FAST_RXM</code> and NULL the <code>rxm</code> at stage time. Capped at <code>SACK_RXM_MAX</code> staged retransmits per receive pass; what's left rides the next SACK.

;<code>FC</code>
:Bump <code>snd_cr.rwe</code> (clamped to <code>lwe + RQ_SIZE</code>, never shrinks) and mark window open.

;<code>DATA</code>
:Bounds-check <code>seqno</code> against window. On stale-dup (<code>seqno < rcv_cr.lwe</code>), set <code>rcv_cr.seqno = seqno</code> to force a fresh ACK on the next <code>ack_snd</code>, then drop. On accept: both FRTX and best-effort stash the packet-buffer index into <code>rq[seqno mod RQ_SIZE]</code>. Fragments stash unchanged - the role bits are inspected only at consume time ([[#7.2. Fragmentation and reassembly|Section 7.2]]). On out-of-order arrival, build a SACK reply if not rate-limited (per [[#3. Protocol parameters|Section 3]]) and not deduplicated against the previous <code>(rcv_cr.lwe, n_blocks)</code> pair; D-SACK reports always bypass the dedup. If both rate-limit and dedup suppress the reply, neither SACK nor delayed-ACK fires (the sender picks up the gap on its next ACK). On in-order arrival, arm the delayed-ACK timer.

;<code>drop_packet</code> exit
:Releases the per-packet shared-memory buffer (<code>spb</code>), then calls <code>ack_snd</code> synchronously after the <code>spb</code> release to surface any pending cumulative ACK.

== 7. Read path and reassembly ==

=== 7.1. Read path ===

<code>flow_read</code> returns a full reassembled SDU (Service Data Unit) via
<code>frcti_consume</code> on every FRCP SDU-mode flow (FRTX or best-effort);
stream-mode is covered in [[#16. Stream-mode flows|Section 16]]. An incomplete head-of-line
(HoL) run yields <code>-EAGAIN</code>; an oversized run yields <code>-EMSGSIZE</code> (the
run is dropped so the flow does not stall). On best-effort flows,
a permanently-lost mid-fragment is dropped as soon as a later
complete SDU becomes visible in the ring ([[#7.2. Fragmentation and reassembly|Section 7.2]] skip-past-
gap).

Raw flows carry no <code>frcti</code>, so <code>flow_read</code> returns the next pending
packet-buffer index directly, with no role-bit inspection. (Raw
service is selected via <code>qos.service == SVC_RAW</code> at flow allocation,
which suppresses <code>frcti</code> creation.)

<code>frcti_pdu_ready</code> is the no-advance peek used by <code>fevent</code> (the
Ouroboros flow-event multiplexer, the <code>poll(2)</code>-equivalent on
flows). It returns ready only when the head-of-line run is
complete and the lead packet (a Protocol Data Unit, here one FRCP
packet) is present at <code>rcv_cr.rwe - RQ_SIZE</code>; any other state
(including the best-effort skip-past-gap case) returns not ready,
and <code>frcti_consume</code> is left to drop the broken prefix and re-
inspect.

=== 7.2. Fragmentation and reassembly ===

Send side (<code>flow_write_frag</code>). An SDU larger than
<code>(frag_mtu - PCI)</code> is split into <code>ceil(count / (frag_mtu - PCI))</code>
fragments; each fragment is its own FRCP packet with its own
<code>seqno</code> and a per-fragment role flag pair ([[#1.2. Flag bits|Section 1.2]]). Roles are
assigned at emit time:

{| class="wikitable"
! i !! Role
|-
| <code>n=1</code> || <code>SOLE</code>
|-
| <code>i=0</code> || <code>FIRST</code>
|-
| <code>i=n-1</code> || <code>LAST</code>
|-
| else || <code>MID</code>
|}

A mid-loop allocation or transmit failure may yield a partial
write: the call returns the bytes already enqueued (<code>off > 0</code>) or
the underlying error (<code>off == 0</code>). Best-effort flows fragment
identically; on the receiver, a partial run with a permanently-
lost fragment is dropped when a later complete SDU is visible in
the ring (see skip-past-gap below). Raw flows carry no PCI and
refuse anything larger than the layer's user MTU (<code>-EMSGSIZE</code>).

Wire-level recovery is fragment-agnostic on FRTX flows: each
fragment's <code>seqno</code> flows through SACK / RACK / RTO / NACK exactly
as for a SOLE DATA packet, and reassembly does not re-enter the
loss-detection path. Best-effort flows run the same <code>seqno</code>
machinery (DRF, FC, ACK piggyback, pre-DRF NACK emit) but queue
no <code>rxm</code> state at the sender, so a lost MID is unrecoverable;
skip-past-gap handles it (below).

Receive side. Fragments stash into <code>rq[seqno]</code> unchanged; role bits
are read only at consume time. <code>frag_run_inspect</code>, called from
<code>frcti_consume</code>, walks the ring starting at the oldest still-
undelivered <code>seqno</code> <code>base = rcv_cr.rwe - RQ_SIZE</code> (equal to <code>rcv_cr.lwe</code>
only when no partial run is in progress; during a partial run <code>lwe</code>
has already advanced past <code>base</code>). It produces one of three
outcomes:

{| class="wikitable"
! Outcome !! Cause
|-
| <code>DELIVER (n)</code>
| <code>rq[base]=SOLE</code> (<code>n=1</code>), or <code>rq[base]=FIRST</code> and a <code>LAST</code> follows in slots <code>[base+1..base+n-1]</code> with all intermediate roles in <code>{MID,FIRST,LAST}</code> contiguous.
|-
| <code>DROP (n)</code>
| <code>rq[base]</code> is <code>MID</code> or <code>LAST</code> without a preceding <code>FIRST</code> (<code>n=1</code>); a <code>FIRST..[non-LAST]..new-FIRST</code> or new-<code>SOLE</code> mid-run (drop the broken prefix with <code>n</code> = run length minus 1, so the new <code>FIRST</code>/<code>SOLE</code> stays); or, on best-effort flows, a gap at <code>base</code> with a <code>FIRST</code>/<code>SOLE</code> later in the ring (drop up to the new run start).
|-
| <code>NOT_READY</code>
| <code>rq[base]</code> absent or <code>FIRST..[non-LAST]</code> with no later <code>FIRST</code>/<code>SOLE</code> in the ring (FRTX waits for retx; best-effort waits for arrival).
|}

<code>DELIVER</code> triggers <code>frag_gather</code>: a scatter-gather <code>memcpy</code> of the <code>n</code>
consecutive fragments at <code>rq[base..base+n-1]</code> directly into the
caller's buffer; each per-packet shared-memory buffer (<code>spb</code>) is
released and <code>rwe</code> advances by <code>n</code>. <code>lwe</code> was already advanced
incrementally as each contiguous fragment arrived; <code>frag_gather</code>
only restores the fixed-width invariant <code>rwe == lwe + RQ_SIZE</code>.
No intermediate reassembly buffer is allocated.

<code>DROP</code> advances <code>rwe</code> past the broken prefix (releasing the <code>spb</code>s)
and pulls <code>lwe</code> up to the new trailing edge if needed; the next
consume retries from the new <code>base</code>. Oversize or arithmetically
overflowing delivery (sum of fragment lengths > <code>max_rcv_sdu</code>, sum
> caller's buffer, or running-sum overflow) also drops the run
with <code>-EMSGSIZE</code>.

Skip-past-gap (best-effort only). On FRTX, a gap in the run means
"waiting for retransmit" and <code>frag_run_inspect</code> returns <code>NOT_READY</code>.
On best-effort flows the gap is permanent, so <code>frag_run_inspect</code>
scans forward in the ring for the next <code>FIRST</code> or <code>SOLE</code>; if one is
visible within <code>RQ_SIZE</code>, it returns <code>DROP</code> for the broken prefix and
the consume loop retries at the new <code>lwe</code>. Memory hold is bounded
by <code>RQ_SIZE</code>; the partial releases on the next consume call once a
later complete run exists. Voice-like flows (one <code>SOLE</code> per SDU)
see no extra wait: any later <code>SOLE</code> makes the prior gap droppable
immediately.

The choice to defer reassembly to consume time keeps the receive
path zero-copy: fragments stay in the shared-memory ring until
the application pulls, and the SDU lands directly in the caller's
buffer.

== 8. Retransmission ==

FRCP is bounded by two delta-t-derived timers (Watson 1981, see
[[#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_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.

Each in-flight FRTX <code>seqno</code> owns one <code>rxm_entry</code>, armed in a hashed
timing wheel; the wheel deadline is the slot's next eligible
retransmit time.

;RTO timer
:On fire (<code>rxm_due</code>), re-emit with <code>FRCT_RXM</code>, mark <code>SND_RTX</code> (Karn-suppress next ACK's RTT sample), and (for the head-of-line (HoL) slot only) bump <code>rto_mul</code> up to <code>MAX_RTO_MUL</code>. Wheel deadline is <code>t_send + (rto << rto_mul)</code>. Re-armed unless consumed. The RTO timer also clears <code>SND_FAST_RXM</code> (re-arming fast-retransmit eligibility), resets <code>reo_wnd_mult</code> to 1 on a HoL fire (RFC 8985 sec. 6.2 step 4 reset clause), and marks the flow <code>ACL_FLOWDOWN</code> if its <code>frct_tx</code> call fails.

;r-timer guard
:Before any retransmit attempt, check <code>(now - t0)</code> against <code>t_r</code>. If exceeded, the slot is no longer eligible for retransmit. Only the RTO timer (<code>rxm_due</code>) treats r-timer expiry as terminal: it marks the flow <code>ACL_FLOWDOWN</code> (peer unreachable). Fast-retransmit, SACK-driven retransmit, and NACK-driven head-of-line re-emit silently skip aged-out slots and defer the flow-down decision to the next RTO fire.

;Fast retransmit (hybrid trigger, RFC 8985 sec. 6.2)
:On a non-advancing cumulative ACK with the scoreboard advanced, fire one fast retransmit when EITHER (a) the head-of-line slot's latest send is older than the RACK reorder window <code>R</code> ([[#3. Protocol parameters|Section 3]]) and not yet aged out, OR (b) the SACK <code>dup-thresh</code> count above <code>snd_cr.lwe</code> reaches <code>DUP_THRESH</code> (= 3, RFC 8985 sec. 6.2 step 4). Fires at most once per non-advancing cumulative-ACK value, gated by <code>rack_fired_lwe</code> (the <code>snd_cr.lwe</code> at which fast-retransmit last fired). Set <code>SND_FAST_RXM</code> on the slot (one-shot per-slot gate) and enter NewReno-style careful recovery (see NewReno below in this section).
:The RACK reorder window <code>R</code> uses the RFC 8985 sec. 6.2 form <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> with a <code>MIN_REORDER_NS = 250 us</code> floor. Before the first RTT sample seeds <code>min_rtt</code>, <code>R</code> falls back to <code>MIN(reo_wnd_mult * SRTT / 4, SRTT)</code>, still floored at <code>MIN_REORDER_NS</code> (consistent with the windowed-minimum fallback described in [[#12. RTT estimation|Section 12]]). <code>min_rtt</code> is a windowed minimum over the last <code>MIN_RTT_WIN_NS</code> = 5 min of RTT samples (matches the Linux <code>tcp_min_rtt_wlen</code> default) so a route change to a longer path eventually re-anchors the reorder window without relying on <code>reo_wnd_mult</code> growth alone.

;SACK-driven retransmit
:For each gap below <code>hi_sacked</code> whose slot is (1) still owned, (2) not already <code>SND_FAST_RXM</code>, (3) not aged out past <code>t_r</code>, and (4) either outside the RACK window <code>R</code> OR with <code>dup_thresh >= DUP_THRESH</code> (same hybrid as fast-retransmit, see [[#6.2. Locked main path|Section 6.2]]), re-emit. Each SACK-driven retransmit re-arms a fresh <code>rxm</code> so a lost retransmit can still be recovered by its own RTO timer.

;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.

== 9. Pre-DRF NACK ==

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.

;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>)
:When an incoming DATA packet has no DRF and rcv-side activity is older than <code>rcv_cr.inact</code>, the receiver emits a bare packet with <code>flags = FRCT_NACK</code> and <code>seqno = arrival_seqno - 1</code> (informational only, not consulted by the receive handler). The cooldown in [[#3. Protocol parameters|Section 3]] rate-limits the burst. Non-DATA non-DRF arrivals bypass <code>rcv_inact_check</code> entirely; non-DATA DRF still rebases via the DRF branch.

;Receive (<code>frcti_nack_rcv</code>)
: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 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.

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 ==

Cumulative ACK is <code>ackno = rcv_cr.lwe</code>. On out-of-order arrival the
receiver also emits a SACK packet ([[#1.3. SACK payload|Section 1.3]]) whose payload lists
''present'' blocks above <code>lwe</code> (analogous to TCP SACK / QUIC ACK
ranges). SACKs are rate-limited per [[#3. Protocol parameters|Section 3]] and suppressed when
neither <code>lwe</code> nor block count has changed since the last SACK.

D-SACK reports (RFC 2883) are emitted in-band as <code>block[0]</code> of an
otherwise normal SACK frame (see [[#1.3. SACK payload|Section 1.3]] for the encoding).
Two receiver triggers arm a pending D-SACK report (single-slot,
latest-wins):

* DATA arrival with <code>seqno < rcv_cr.lwe</code>, both wire-dup (no RXM, <code>is_dup_data</code> path) and retransmit (RXM, post-FC branch) (RFC 2883 sec. 4.1.1, full duplicate)
* <code>rq_accept</code> conflict, slot already occupied in <code>[lwe, rwe)</code> (RFC 2883 sec. 4.1.2, partial duplicate)

When a D-SACK is pending and the standard scoreboard SACK would be
suppressed by dedup or rate-limit, the report is emitted as a
stand-alone SACK frame through the normal <code>ack_snd</code> path; when a
D-SACK report is pending the path bypasses dedup and the <code>TICTIME</code>
rate-limit, but the a-timer suppression on rcv inactivity still
applies.

Bare ACKs are deferred via a per-flow delayed-ACK timer (one in
flight at a time, atomic test-and-set dedup; fires per [[#3. Protocol parameters|Section 3]]
after the first in-order arrival). Suppressed if (1) no new
<code>seqno</code>, (2) rcv side is inactive (older than <code>t_a</code>), or (3) the
sender just sent within <code>TICTIME</code>. A pending D-SACK ride-through
bypasses (1) and (3); the a-timer gate (2) is unconditional.

== 11. Flow control ==

The receiver advertises <code>rwe</code> in every FC field. The sender treats
its <code>snd_cr.rwe</code> as the absolute right edge: when
<code>snd_cr.seqno >= snd_cr.rwe</code> the window is closed and <code>flow_write</code>
yields. While closed, the sender periodically emits RDVS
(rendezvous) packets (cadence <code>DELT_RDV</code>); the receiver replies with
a bare FC packet (<code>ackno = 0</code>) that reopens the window. Once the
window has been closed for longer than <code>MAX_RDV</code> the sender stops
emitting RDVS but does not tear the flow down - the writer keeps
blocking until either a peer-driven FC arrives or the KA
(keepalive) / r-timer marks the flow.

<code>rwe</code> is clamped to <code>lwe + RQ_SIZE</code> on receipt and MUST NOT shrink:
a backward <code>rwe</code> is silently clamped to the current <code>snd_cr.rwe</code>;
the FC packet still reopens the window.

== 12. RTT estimation ==

Active RTTP probes ([[#1.4. RTTP payload|Section 1.4]]) carry a 32-bit <code>probe_id</code> (0
reserved) and a 16-byte random nonce echoed verbatim - defends
against spoofed replies. A ring of <code>RTTP_RING</code> in-flight probes is
kept; an echo whose <code>(id, nonce)</code> doesn't match the ring slot is
dropped. A single RTTP sample is clamped to <code>RTT_CLAMP_MUL * srtt</code>
(compile-time <code>RTT_CLAMP_MUL = 16</code>) once <code>srtt</code> is seeded; the first
cold-probe sample feeds <code>rtt_update</code> raw.

Probe arming gates:

;Cold (no <code>srtt</code> yet)
:the receive path arms at most one probe per 100 ms via <code>frcti_rcv_probe</code> (<code>PROBE_DUE_COLD</code>); arming requires an incoming packet. Active send-path arming bails while <code>srtt == 0</code>.
;Warm (<code>rtt_probe_arm</code>, called from <code>frcti_snd</code>)
:outstanding data (<code>snd_cr.seqno > snd_cr.lwe</code>), AND at least <code>2 * srtt</code> since <code>t_rcv_rtt</code> (last RTT receive of any kind), AND at least <code>srtt</code> since <code>t_snd_probe</code> (last probe emit).

Sample feeds either Linux's asymmetric <code>mdev</code> estimator
(<code>FRCT_LINUX_RTT_ESTIMATOR</code>, default ON) or RFC 6298 symmetric EWMA
(compile option). <code>srtt</code> is floored at 10 ms when seeded from a
hint, at 1 us after every update (including the first seeding
sample); <code>mdev</code> floored at 100 ns.

:<code>RTO = max(rto_min, 2 * srtt, srtt + (mdev << MDEV_MUL))</code>

(the <code>2 * srtt</code> floor is an FRCT addition not in RFC 6298).
Effective wheel deadline capped per [[#3. Protocol parameters|Section 3]].

ACK-derived samples (<code>frcti_ack_rcv</code> -> <code>rtt_sample_eligible</code>), beyond
the cum-ACK advance gate in <code>frcti_ack_rcv</code> (<code>ackno > lwe</code> and
<code>ackno <= seqno</code>), require all of: not in recovery; ACK packet does
not carry <code>FRCT_RXM</code>; HoL slot's <code>SND_RTX</code> bit clear; slot's <code>rxm</code>
pointer non-NULL (not SACK-consumed); <code>lwe</code> not below the <code>rtt_lwe</code>
fence; <code>srtt</code> already seeded by an RTTP probe. There is no ACK-only
seeding.

Every eligible sample also feeds <code>RACK.min_RTT</code> (RFC 8985 sec. 6.2)
via a windowed minimum: replace whenever the sample is strictly
smaller OR more than <code>MIN_RTT_WIN_NS</code> (5 min, matches Linux
<code>tcp_min_rtt_wlen</code>) has elapsed since the current min was set. The
downward branch is immediate (faster path picked up at once); the
upward branch is gated on the window (a transient queue burst does
not poison the estimate, but a sustained route change to a longer
path re-anchors <code>min_RTT</code> after at most one window). Seeded from
<code>rtt_hint</code> at <code>rtt_init</code>; 0 acts as the unset sentinel and the base
in <code>rack_reorder_window</code> falls back from <code>min_RTT</code> to <code>SRTT</code> (so
<code>R = mult * SRTT/4</code>, capped at <code>SRTT</code>, floored at <code>MIN_REORDER_NS</code>)
until the first sample. See [[#6.2. Locked main path|Section 6.2]].

== 13. Liveness (keepalive) ==

When <code>qs.timeout > 0</code> a per-flow KA (keepalive) timer is armed.
Arming uses <code>rcv_cr.act</code> for the deadline computation:

:<code>deadline = min(snd_act + qs.timeout/4, rcv_act + qs.timeout)</code>

(clamped to <code>now + qs.timeout/4</code> if already past). The timer fires
either on sender idleness (to send a KA) or on receiver idleness
(to declare the peer dead). On fire (<code>ka_snd</code>) the peer-dead test
uses <code>max(rcv_cr.act, t_ka_rcv)</code> so a recent KA reply counts even
when no DATA has arrived:

* If <code>now - max(rcv_cr.act, t_ka_rcv) > qs.timeout</code>, mark the flow <code>ACL_FLOWPEER</code> and notify the per-process flow-event set (<code>proc.fqset</code>) with <code>FLOW_PEER</code>.
* Else if <code>snd_idle > qs.timeout/4</code>, emit a bare <code>KA | ACK</code> (<code>ackno = rcv_cr.lwe</code>) and re-arm.
* Else just re-arm.

Note: <code>rx_rb</code> and <code>tx_rb</code> are the receive and transmit shared-memory
ring buffers. The r-timer raises <code>ACL_FLOWDOWN</code> on both (route is
broken); keepalive raises <code>ACL_FLOWPEER</code> on <code>rx_rb</code> only and notifies
the flow-event set (peer is silent, writer keeps <code>tx_rb</code> usable) -
distinct ACLs. <code>qs.timeout == 0</code> disables keepalive entirely; a
silent peer crash is then undetected.

== 14. Linger / teardown ==

On <code>flow_dealloc</code>, <code>frcti_dealloc</code> computes a grace timeout

:<code>max(rcv_cr.act + rcv_cr.inact, snd_cr.act + snd_cr.inact) - now</code>

(floored at 0 and converted to seconds) and returns it; <code>flow_dealloc</code>
forwards this to the IRMd as the dealloc grace. The IRMd, not FRCT,
performs the wait. Before computing the timeout, FRCT may emit a
final ACK when <code>rcv_cr.lwe != rcv_cr.seqno</code> (the peer has not been
told the most recent cumulative ACK) AND the rcv side has been
active within <code>t_a</code> (a-timer not aged out).

<code>FRCTFLINGER</code> is honoured only when <code>snd_cr.lwe < edge</code>, where <code>edge =
snd_fin_seqno</code> after FIN has been sent in stream mode and
<code>snd_cr.seqno</code> otherwise (data or FIN still in flight). The drain
itself runs in <code>flow_dealloc</code>'s <code>while (FRCTI_LINGERING)</code> loop, not in
<code>frcti_dealloc</code>.

The fd is single-reader / single-writer (documented in the
manpages). <code>flow_write</code> pumps <code>rx_rb</code> on every call (via
<code>flow_wait_window</code> -> <code>flow_drain_rx_nb</code>) and additionally blocks on
<code>rx_rb</code> when the send window is closed. A pure-writer thread thus
consumes ACKs without a dedicated reader.

== 15. Heritage and adopted techniques ==

Delta-t (Watson, 1981) is the primary heritage; FRCP descends from
the delta-t protocol family via the Recursive InterNetwork
Architecture (RINA; Day, "Patterns in Network Architecture", 2008,
ch. 9). Timer-based connection management
(no SYN/FIN handshake, per-flow state born on first DATA and
reclaimed after <code>t_mpl + a + r</code> of silence), the DRF marker, and the
<code>t_mpl</code> / <code>t_a</code> / <code>t_r</code> timers all come from delta-t. See Watson,
"Timer-Based Mechanisms in Reliable Transport Protocol Connection
Management", Computer Networks 5 (1981).

The unified <code>flow_alloc(name, qos, ...)</code> primitive and its
multi-axis QoS-cube argument ([[#2.2. Service modes (orthogonal axes)|Section 2.2]]) also come from RINA
(Day 2008, ch. 6; Grasa et al., "IRATI: investigating RINA as an
alternative to TCP/IP", Computer Networks 92 (2015)) - reliability,
ordering, CRC presence, and encryption are flow attributes, not
separate sockets or protocols.

The table below summarises additional adopted techniques and their
references.

{| class="wikitable"
! FRCP mechanism !! Heritage !! Reference / note
|-
| Random new <code>seqno</code> on <code>seqno_rotate</code> || TCP ISN || RFC 6528 (Gont & Bellovin, 2012). QUIC PN-space reset (RFC 9000 sec. 12.3) is a structural analogue.
|-
| Cumulative ACK, left-window-edge advance || TCP || RFC 793 / RFC 9293
|-
| Receive window with non-shrink rule || TCP || RFC 793 sec. 3.7 / RFC 9293 sec. 3.8.6; RFC 1122 sec. 4.2.2.16 for the explicit non-shrink prohibition
|-
| Modular <code>seqno</code> arithmetic (<code>before</code>/<code>after</code> helpers) || TCP || RFC 793 sec. 3.3 / RFC 9293 sec. 3.4
|-
| Selective ACK block list || TCP || RFC 2018 (Mathis et al., 1996). Encoded as a typed FRCP packet rather than a TCP option, so framing is closer to QUIC ACK frames. D-SACK (RFC 2883) carried in-band as <code>block[0]</code>; see [[#1.3. SACK payload|Section 1.3]].
|-
| NewReno-careful recovery with <code>recovery_high</code> gate || TCP || RFC 6582 (Henderson et al., 2012); QUIC builds on the same model in RFC 9002 sec. 7.3.2. Cwnd half absent (CC in IPCP).
|-
| RACK reordering window for fast retransmit || TCP || RFC 8985 (Cheng et al., 2021). FRCP <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> with a <code>MIN_REORDER_NS = 250 us</code> floor against <code>srtt</code> collapse; matches RFC 8985 sec. 6.2 and Linux <code>tcp_rack_reo_wnd</code>. DSACK-driven <code>reo_wnd_mult</code> (sec. 6.2 step 4) is adopted; see [[#1.3. SACK payload|Section 1.3]] for the wire encoding. The hybrid RACK-or-<code>DUP_THRESH</code> trigger from RFC 8985 sec. 6.2 step 4 is adopted ([[#8. Retransmission|Section 8]]). QUIC's analogue in RFC 9002 sec. 6.1.2 uses <code>max(srtt, latest_rtt)</code> as the base.
|-
| 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> = 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.
|-
| Delayed ACK with rate suppression || TCP || RFC 813 (Clark, 1982); RFC 1122 sec. 4.2.3.2; RFC 5681 sec. 4.2. Single-deadline coalescing rather than "ack-every-other-segment".
|-
| Zero-window-probe / persist-timer analogue (RDVS) || TCP || RFC 1122 sec. 4.2.2.17 / RFC 9293 sec. 3.8.6.1. RDVS solicits an FC reply, distinct from QUIC <code>DATA_BLOCKED</code> (RFC 9000 sec. 19.12), which is one-way notification. <code>MAX_RDV</code> give-up departs from TCP.
|-
| Multiplexed control on a single PCI || SCTP / QUIC || SCTP chunk bundling (RFC 9260 sec. 6.10); QUIC frame multiplexing (RFC 9000 sec. 12.4). Cleaner fit than TCP's separate-flag-bits design.
|-
| ACK ranges as multiple discontiguous acked blocks || QUIC || QUIC ACK frame (RFC 9000 sec. 19.3). FRCP SACK is conceptually QUIC-frame-shaped even though encoded as absolute <code>[start,end]</code> pairs.
|-
| Nonce-authenticated active RTT / liveness probing (RTTP) || QUIC <code>PATH_CHALLENGE</code> || <code>PATH_CHALLENGE</code> / <code>PATH_RESPONSE</code> (RFC 9000 sec. 8.2, sec. 19.17, sec. 19.18). WebRTC ICE consent-freshness (RFC 7675) is the same pattern. QUIC's nonce is 8 octets; FRCP chooses 16.
|-
| Probing distinct from keepalive || QUIC || KA timer answers "peer alive?", RTTP answers "path measurable?", as in QUIC PING (RFC 9000 sec. 19.2) vs <code>PATH_CHALLENGE</code>.
|-
| Bare KA + ACK keepalive packets || QUIC / SCTP || QUIC PING (RFC 9000 sec. 19.2); SCTP HEARTBEAT / HEARTBEAT-ACK (RFC 9260 sec. 8.3). SCTP HEARTBEAT also carries an opaque echoed blob, structurally similar to FRCP RTTP.
|-
| (<code>FFGM</code>, <code>LFGM</code>) fragment-role bits ([[#7.2. Fragmentation and reassembly|Section 7.2]]) || SCTP || RFC 9260 sec. 3.3.1 DATA chunk B/E bits encode the same four states (<code>B+E=SOLE</code>, <code>B-only=FIRST</code>, neither=<code>MID</code>, <code>E-only=LAST</code>). Each fragment carries its own <code>seqno</code>/TSN and is independently retransmitted.
|-
| Stream byte-offset reassembly (Sections [[#1.5. Stream PCI extension|1.5]], [[#16. Stream-mode flows|16]]) || QUIC || QUIC STREAM frame (RFC 9000 sec. 19.8) uses Offset + Length varints; FRCP uses fixed 32-bit <code>start</code> / <code>end</code>. One stream per flow vs QUIC's many streams multiplexed.
|-
| FIN end-of-stream marker (Sections [[#1.2. Flag bits|1.2]], [[#16. Stream-mode flows|16]]) || TCP / QUIC || TCP FIN flag (RFC 9293 sec. 3.1) closes one half of the byte stream; QUIC STREAM frame FIN bit (RFC 9000 sec. 19.8) does the same per stream with an immutable final-size invariance (RFC 9000 sec. 4.5: the final size is fixed once observed). FRCP's FIN consumes one packet <code>seqno</code> (not one byte of stream space) and is idempotent on the sender side.
|-
| Stream byte-credit flow control ([[#16. Stream-mode flows|Section 16]]) || QUIC || <code>MAX_STREAM_DATA</code> (RFC 9000 sec. 4.1, sec. 19.10). FRCP projects a per-flow byte budget onto the <code>seqno</code>-space <code>rwe</code>. Single stream per flow collapses QUIC's <code>MAX_DATA</code> / <code>MAX_STREAM_DATA</code> distinction.
|-
| Header protection (encrypted seqnos) || QUIC || QUIC RFC 9001 sec. 5.4 applies header protection on top of AEAD to mask the packet number. FRCP's per-flow AEAD wrap ([[#16. Stream-mode flows|Section 16]]) is wider: it encrypts the entire PCI including <code>seqno</code> because the IPCP below already routes, so no destination connection-ID needs to stay in clear (cf. RFC 9000 sec. 5.2).
|-
| Two-bit fragment role polarity || SCTP || The (<code>FFGM</code>, <code>LFGM</code>) pair follows SCTP B/E (begin = 1 / end = 1) rather than IPv4 MF (RFC 791 sec. 3.2), which has the inverse polarity (MF = 1 means NOT last).
|-
| Orthogonal reliability / ordering axes ([[#2.2. Service modes (orthogonal axes)|Section 2.2]]) || SCTP || PR-SCTP (RFC 3758, per-message partial reliability) and SCTP DATA U-bit (RFC 9260 sec. 3.3.1, per-message unordered) are the closest precedents for decoupling reliability from ordering; FRCP sets them per-flow rather than per-message.
|-
| Orthogonal CRC (<code>qs.ber == 0</code>) || UDP-Lite || RFC 3828 (Larzon et al., 2004) lets the sender pick a per-packet Checksum Coverage and the receiver enforce a locally configured minimum (no in-band negotiation; sec. 3.1, sec. 3.3). FRCP gates a full CRC trailer on <code>qs.ber == 0</code> at flow setup. Contrast TCP / SCTP (mandatory checksum) and QUIC (AEAD subsumes CRC).
|-
| Setup-time service negotiation || DCCP / SCTP / QUIC || DCCP Service Codes (RFC 4340 sec. 8.1.2, RFC 5595); SCTP INIT parameters (RFC 9260 sec. 3.3.2); QUIC transport parameters (RFC 9000 sec. 7.4). All negotiate service properties at connection setup; only RINA's QoS cube exposes them as an orthogonal vector.
|}

=== 15.1. Original to FRCP (no clean prior art) ===

* Pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]): receiver-driven nudge exploiting <code>snd_cr.inact > rcv_cr.inact</code>. Closest analogues are SCTP Gap Ack Blocks (RFC 9260 sec. 3.3.4) and DCCP Ack Vector (RFC 4340 sec. 11.4) - both let the receiver describe gaps to the sender, but neither targets the cross-epoch / pre-DRF case.
* <code>MAX_RDV</code> window-probe give-up: neither TCP (persist-timer probes until application or R2 abort, RFC 9293 sec. 3.8.6.1) nor QUIC has an explicit FC-give-up counter. A recursive-network choice: outer layers can drop the flow.
* Skip-past-gap reassembly ([[#7.2. Fragmentation and reassembly|Section 7.2]]): SCTP fragments and reassembles every flow regardless of reliability/ordering, using its own per-stream reassembly queue; QUIC fragments via STREAM offsets. FRCP fragments best-effort flows too, but the receiver drops the broken prefix the moment a later run-start (<code>FIRST</code> or <code>SOLE</code> role) is visible inside the <code>RQ_SIZE</code>-wide reorder ring - no IP-frag-style timeout, no SCTP-style explicit abort. If no later run-start arrives within the ring, <code>frag_run_inspect</code> returns <code>NOT_READY</code> and the partial run keeps its slots; the next inspect retries. The trade-off: a permanently-lost <code>MID</code> in a long isolated run holds slots until either a later <code>FIRST</code>/<code>SOLE</code> appears in the ring or the writer stops, at which point the slots are reclaimed on flow teardown.
* Reassembly deferred to consume time ([[#7.2. Fragmentation and reassembly|Section 7.2]]), message mode only (<code>qos.service == SVC_MESSAGE</code>): SCTP (RFC 9260 sec. 6.9), QUIC (RFC 9000 sec. 2.2), and TCP (RFC 9293) all hold reassembly state at the receive boundary. FRCP message-mode leaves fragments in the shared-memory ring until <code>flow_read</code> pulls and lands the SDU directly in the caller's buffer. Stream mode ([[#16. Stream-mode flows|Section 16]]) uses the standard QUIC-style direct ring placement on receive and does not defer. The optimisation is enabled by the Shared-Memory Subsystem (SSM) packet-buffer ring (see <code>struct ssm_pk_buff</code> at [[#1.1. PCI header|Section 1.1]]); the analogue is OS-level scatter-gather I/O (<code>recvmsg+iovec</code>), not a transport-layer prior art.
* TLP-equivalent tail-loss recovery (RFC 8985 sec. 7; RFC 9002 sec. 6.2): FRCP does not emit an explicit Tail Loss Probe packet, but the same goal is met implicitly by RACK loss detection ([[#8. Retransmission|Section 8]]) firing on a non-advancing cumulative ACK once the head-of-line slot ages past the RACK reorder window <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> - well below <code>RTO = max(2 * SRTT, SRTT + (mdev << MDEV_MUL))</code>. A receiver-driven nudge is also available via the pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]).

=== 15.2. Not adopted ===

* Slow start, congestion window (cwnd), Additive Increase / Multiplicative Decrease (AIMD), NewReno cwnd inflation. Congestion control lives in the IPCP CA policies and is driven by Explicit Congestion Notification (ECN, RFC 3168).
* Nagle / silly-window-syndrome (SWS) avoidance (RFC 896, RFC 1122 sec. 4.2.3.4). (Deferred work, not adopted in the current spec.)
* TCP Timestamps (RFC 7323) / Protection Against Wrapped Sequences (PAWS) - RTT measurement uses RTTP, not per-segment timestamps. A peer-supplied timestamp echoed on every ACK lets a malicious peer drive the <code>srtt</code> estimate arbitrarily low, collapsing the RTO and triggering a self-inflicted retransmit storm. RTTP confines RTT measurement to nonce-authenticated probe round-trips, where a forged echo is rejected before it can reach the estimator.
* ECN (Explicit Congestion Notification) response inside FRCP (consumed by IPCP Congestion Avoidance / CA).
* 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).

== 16. Stream-mode flows ==

When a flow is allocated with <code>qos.service == SVC_STREAM</code> both peers
switch to byte-stream semantics, layered on top of the FRTX reorder
machinery already described in Sections [[#6. Receive path|6]]-[[#8. Retransmission|8]].

=== 16.1. Send ===

The sender splits the caller's octets into chunks of at most
<code>(frag_mtu - base PCI - stream PCI extension)</code> octets (Sections [[#1.1. PCI header|1.1]]
and [[#1.5. Stream PCI extension|1.5]]). Each chunk is one DATA packet with its own <code>seqno</code> and a
<code>[start, end)</code> byte range copied from a monotonic stream counter.
In stream mode <code>FFGM</code> and <code>LFGM</code> are unused and MUST be transmitted as
zero; the per-byte position is carried by the <code>[start, end)</code>
extension instead.

End-of-stream is signalled with a 0-byte DATA packet that has <code>FIN</code>
(bit 12) set, emitted on the FIN triggers listed in [[#1.2. Flag bits|Section 1.2]]
(WR-half close, <code>flow_dealloc</code>, and any other path that yields the
final byte). The sender MUST emit at most one FIN per flow; its
<code>[start, end)</code> MUST equal <code>[final-byte, final-byte)</code> (i.e., empty
interval at the final byte position; final-size invariance,
analogous to QUIC RFC 9000 sec. 4.5). Idempotency is enforced by
an <code>snd_fin_sent</code> guard.

=== 16.2. Receive ===

On arrival the receiver places the payload directly into a per-flow
byte-indexed receive ring of width <code>ring_sz</code> (octets) at the position
indicated by <code>start</code>, with a two-segment <code>memcpy</code> across the ring
boundary if needed. Receipt is recorded in the FRTX reorder
machinery ([[#6.2. Locked main path|Section 6.2]]) augmented with the packet's <code>start</code>, <code>end</code>, and
FIN bit per slot. When a packet's <code>[start, end)</code> front-overlaps
bytes already at or below the byte high-water mark, the overlap is
trimmed before placement so the same byte is never written twice.
After stashing, the receiver advances <code>lwe</code> and the byte high-water
mark across any newly-contiguous prefix. Each slot advanced MUST
satisfy <code>start == the last-delivered slot's end</code>; a slot whose
<code>start</code> does not equal that <code>end</code> is silently dropped at delivery time
(the <code>seqno</code> is consumed, no stream bytes contributed) and the high-
water mark does not advance past it. The stream byte-stream
stalls at that point - there is no flow-tear-down on mismatch.
This filters spliced or off-path-injected slots that fall in
window without strong cryptographic authentication.

A FIN slot marks end-of-stream at advance time only if its byte
position equals the last-delivered slot's <code>end</code>; otherwise the FIN
is ignored and the corresponding <code>seqno</code> occupies a slot but
contributes no stream bytes. No packet buffer is held after the
ring copy.

=== 16.3. Read ===

<code>flow_read</code> returns up to <code>count</code> octets from the contiguous prefix
<code>[next, high-water)</code>, where <code>next</code> is the byte the application has
already consumed up to and <code>high-water</code> is the rightmost contiguous
byte received. When the stream is fully drained AND end-of-stream
(EOS) was observed (<code>next == EOS</code> byte position), <code>flow_read</code> returns
0 (<code>EOF</code>) - the same shape POSIX <code>read(2)</code> uses on TCP after a peer
FIN.

=== 16.4. Flow control ===

ACK / SACK / RACK / RTO machinery is unchanged; the FRTX reorder
ring is reused as a per-<code>seqno</code> received-bitmap. Let <code>per_pkt =
(frag_mtu - base PCI - stream PCI extension)</code>, the maximum stream-
byte payload one DATA packet can carry ([[#16.1. Send|Section 16.1]]). The
receive window advertised in FC is clamped so the byte window
(<code>ring_sz</code>) cannot be overrun: the <code>seqno</code>-space <code>rwe</code> is at most
<code>rcv_cr.lwe + ring_sz / per_pkt</code>.

This is the QUIC byte-credit flow-control model
(<code>MAX_STREAM_DATA</code>, RFC 9000 sec. 4.1 and sec. 19.10) projected onto
<code>seqno</code> space. With one stream per flow there is no <code>MAX_DATA</code> /
<code>MAX_STREAM_DATA</code> distinction. Receiver-side silly-window-syndrome
(SWS) avoidance (RFC 9293 sec. 3.8.6.2.2) is achieved by combining
the consume-time <code>rwe</code> bump with the global non-shrink rule from
[[#11. Flow control|Section 11]].

=== 16.5. Security considerations ===

Threat model. An attacker that can observe (on-path passive) or
predict (off-path blind) the flow's seqnos and byte offsets on an
unencrypted stream flow can inject DATA or FIN at any in-window
position. The in-line consistency checks above (<code>start</code> == prior
<code>end</code> on advance; FIN MUST be 0-byte; FIN MUST sit at the final
byte position) realise the spirit of RFC 5961's "sequence-window
plus exact-position match for control bits" without an explicit
challenge-ACK probe; they make a few specific blind attack shapes
harder but are not cryptographic authentication. This is
comparable to TCP without the TCP Authentication Option (TCP-AO,
RFC 5925), tighter than a
pre-RFC-5961 TCP stack, and roughly equivalent to a modern
RFC 5961 stack against blind off-path injection - none of these
help once the attacker can sniff. TLS over TCP (RFC 8446)
encrypts only the TCP payload and leaves TCP seqnos, ACKs, FIN,
and RST in the clear, so TLS does NOT defend against TCP-header-
level injection; QUIC (RFC 9000) hides packet numbers under
header protection (RFC 9001 sec. 5.4), so this specific weakness
does not apply to QUIC.

Mitigation: AEAD. When the flow has encryption enabled the
recommended AEAD ciphers (AES-GCM, RFC 5288; or ChaCha20-Poly1305,
RFC 8439) wrap the entire FRCP packet on the wire - PCI, stream
extension, body, and the CRC trailer when <code>ber == 0</code> - under a
per-flow symmetric key derived from the flow's own key exchange
([[#1.1. PCI header|Section 1.1]]). The AEAD tag (~2^-128 forgery probability)
dominates the CRC (~2^-32) for integrity in this mode but the CRC
trailer is currently retained inside the wrap (see [[#1.1. PCI header|Section 1.1]]).
Implementations MUST NOT rely on the security properties below
when a non-AEAD cipher (e.g. AES-CTR alone) is negotiated; non-
AEAD modes provide confidentiality only and the threat-model
claims do not hold.

With an AEAD cipher in use, seqnos, byte offsets, and the FIN bit
are both authenticated and confidential. Against an off-path or
on-path-passive attacker this is:

* Stronger than TCP+TLS (TCP header in the clear).
* Stronger than TCP+TCP-AO (header authenticated but visible).
* 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. 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 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
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 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 ==

This section lists the IETF documents, published works, and
source-code references cited inline elsewhere in this document.
IETF documents are cited inline as "RFC NNNN sec. X.Y"; books,
journal papers, and source-code references are cited inline by
author and year (or by file and function name) and are listed
here for convenience.

=== 17.1. IETF documents ===

;[RFC 791]
:J. Postel, "Internet Protocol", STD 5, RFC 791, September 1981.
;[RFC 793]
:J. Postel, "Transmission Control Protocol", STD 7, RFC 793, September 1981. Obsoleted by RFC 9293.
;[RFC 813]
:D. D. Clark, "Window and Acknowledgement Strategy in TCP", RFC 813, July 1982.
;[RFC 896]
:J. Nagle, "Congestion Control in IP/TCP Internetworks", RFC 896, January 1984.
;[RFC 1122]
:R. Braden (ed.), "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
;[RFC 2018]
:M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
;[RFC 2119]
:S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
;[RFC 2883]
:S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
;[RFC 3758]
:R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
;[RFC 3828]
:L-A. Larzon, M. Degermark, S. Pink, L-E. Jonsson (ed.), G. Fairhurst (ed.), "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
;[RFC 4303]
:S. Kent, "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
;[RFC 4340]
:E. Kohler, M. Handley, S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
;[RFC 5288]
:J. Salowey, A. Choudhury, D. McGrew, "AES Galois Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, August 2008.
;[RFC 5595]
:G. Fairhurst, "The Datagram Congestion Control Protocol (DCCP) Service Codes", RFC 5595, September 2009.
;[RFC 5681]
:M. Allman, V. Paxson, E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
;[RFC 5925]
:J. Touch, A. Mankin, R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
;[RFC 5961]
:A. Ramaiah, R. Stewart, M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, August 2010.
;[RFC 6298]
:V. Paxson, M. Allman, J. Chu, M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, June 2011.
;[RFC 6528]
:F. Gont, S. Bellovin, "Defending against Sequence Number Attacks", RFC 6528, February 2012. Obsoletes RFC 1948.
;[RFC 6582]
:T. Henderson, S. Floyd, A. Gurtov, Y. Nishida, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 6582, April 2012.
;[RFC 7323]
:D. Borman, B. Braden, V. Jacobson, R. Scheffenegger (ed.), "TCP Extensions for High Performance", RFC 7323, September 2014.
;[RFC 7675]
:M. Perumal, D. Wing, R. Ravindranath, T. Reddy, M. Thomson, "Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness", RFC 7675, October 2015.
;[RFC 8174]
:B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017.
;[RFC 8200]
:S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, July 2017.
;[RFC 8439]
:Y. Nir, A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 8439, June 2018.
;[RFC 8446]
:E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, August 2018.
;[RFC 8985]
:Y. Cheng, N. Cardwell, N. Dukkipati, P. Jha, "The RACK-TLP Loss Detection Algorithm for TCP", RFC 8985, February 2021.
;[RFC 9000]
:J. Iyengar (ed.), M. Thomson (ed.), "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, May 2021.
;[RFC 9001]
:M. Thomson (ed.), S. Turner (ed.), "Using TLS to Secure QUIC", RFC 9001, May 2021.
;[RFC 9002]
:J. Iyengar (ed.), I. Swett (ed.), "QUIC Loss Detection and Congestion Control", RFC 9002, May 2021.
;[RFC 9147]
:E. Rescorla, H. Tschofenig, N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, April 2022.
;[RFC 9260]
:R. Stewart, M. Tuexen, K. Nielsen, "Stream Control Transmission Protocol", RFC 9260, June 2022. Obsoletes RFC 4960.
;[RFC 9293]
:W. Eddy (ed.), "Transmission Control Protocol (TCP)", STD 7, RFC 9293, August 2022. Obsoletes RFC 793 and several follow-ons; updates RFC 1122 and others.

=== 17.2. Books and journal papers ===

;[Day08]
:J. Day, "Patterns in Network Architecture: A Return to Fundamentals", Prentice Hall, 2008.
;[Grasa15]
:E. Grasa et al., "IRATI: investigating RINA as an alternative to TCP/IP", Computer Networks, Vol. 92, December 2015.
;[KP87]
:P. Karn, C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", ACM SIGCOMM, August 1987.
;[Wat81]
:R. W. Watson, "Timer-Based Mechanisms in Reliable Transport Protocol Connection Management", Computer Networks, Vol. 5, 1981.

=== 17.3. Source-code references ===

;[Linux-RTT]
:<code>tcp_rtt_estimator()</code> in <code>net/ipv4/tcp_input.c</code> of the Linux kernel, defining the asymmetric <code>mdev</code> variance update used as FRCP's default RTT estimator ([[#12. RTT estimation|Section 12]]). Line-stable browseable copy at https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_input.c.

[[Category:Protocols]]
[[Category:Ouroboros internals]]

Flow and Retransmission Control Protocol

2026-05-17T15:11:27Z

Dimitri: /* 16.5. Security considerations */

{{DISPLAYTITLE:FRCP - Flow and Retransmission Control Protocol}}

FRCP runs end-to-end between two peers over a flow. It delivers
reliability, in-order delivery, flow control, and liveness.
Congestion Control (CC) is not in FRCP - that lives in the IPC
Process (IPCP) Congestion Avoidance (CA) policies, orthogonal to
FRCP. Flow allocation, naming, and IPCP lifecycle are handled by
the IPC Resource Manager daemon (IRMd).

FRCT (Flow and Retransmission Control Task) is the libouroboros
implementation of FRCP; the task lives in <code>src/lib/frct.c</code>. The
remainder of this document describes the FRCP wire protocol and the
behaviour FRCT realises. Code symbols retain the <code>FRCT_</code> prefix
(<code>FRCT_DATA</code>, <code>FRCT_RXM</code>, ...) because they belong to the implementing
task; this document references them verbatim.

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in <code>BCP</code> 14 (Best
Current Practice; RFC 2119, RFC 8174) when, and only when, they
appear in all capitals.

== Notation ==

;<code>u32</code>, <code>u8</code>
:Unsigned 32-bit / 8-bit integers (kernel-C style).
;<code>ns</code>
:Nanoseconds.

Modular sequence-number comparators (32-bit, modulo 2^32):

;<code>before(a, b)</code>
:<code>(int32_t)(a - b) < 0</code>
;<code>after(a, b)</code>
:<code>before(b, a)</code>

Used throughout for <code>ackno</code> / <code>seqno</code> ordering checks.

Round-Trip Time (RTT) abbreviations used throughout:

;<code>SRTT</code>
:Smoothed RTT estimate (RFC 6298).
;<code>mdev</code>
:Mean deviation of RTT (Linux variance estimator).
;<code>EWMA</code>
:Exponentially Weighted Moving Average.
;<code>RTO</code>
:Retransmission Timeout, <code>max(RTO_MIN, srtt + (mdev << MDEV_MUL))</code>.

Timer-bound symbols <code>t_a</code> (a-timer, ACK delay) and <code>t_r</code> (r-timer,
retransmission window) are defined in [[#8. Retransmission|Section 8]]; <code>t_mpl</code> (Maximum
Packet Lifetime) is introduced in [[#2.1. Per-flow state|Section 2.1]] (the <code>inact</code> field)
with heritage in [[#15. Heritage and adopted techniques|Section 15]].

Wire-format diagrams follow the IETF convention: bit 0 is the
leftmost (most significant) bit and fields are in network byte
order unless stated otherwise.

__TOC__

== 1. Wire format ==

=== 1.1. PCI header ===

Fixed 16-octet base Protocol-Control Information (PCI) header
prefixed to every FRCP packet (RFC convention: bit 0 leftmost,
most-significant bit first). All multi-byte fields except <code>hcs</code>
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
[[#1.5. Stream PCI extension|Section 1.5]]); SACK and RTTP carry their own payloads after the
base PCI.

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | hcs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ackno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload (variable) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>flags</code>
:feature/type bitmap (see [[#1.2. Flag bits|Section 1.2]]).
;<code>hcs</code>
:CRC-16-CCITT-FALSE Header Check Sequence (HCS) over <code>flags</code> + <code>window</code> + <code>seqno</code> + <code>ackno</code> (+ stream extension when present); the two octets of the <code>hcs</code> field itself are omitted from the CRC input. Verified on receive before any flag-driven dispatch.
;<code>window</code>
:receiver-advertised right window edge (valid iff FC).
;<code>seqno</code>
:per-flow sequence number.
;<code>ackno</code>
:cumulative Acknowledgement (ACK) (valid iff ACK).

A single packet can simultaneously carry DATA + ACK + FC (Flow
Control) + RXM (Retransmission) by ORing flag bits; the PCI
multiplexes control on the same wire frame in the spirit of SCTP
chunk bundling (RFC 9260 sec. 6.10) and QUIC frame multiplexing
(RFC 9000 sec. 12.4). DATA-bearing packets carry the caller's
payload after the PCI; SACK (Selective Acknowledgement) and RTTP
(Round-Trip Time Probe) carry their own typed payloads after the
PCI.

Optional framing (per-flow, see [[#2.2. Service modes (orthogonal axes)|Section 2.2]]). On the wire, the
order from inside out is:

{| class="wikitable"
! Layer !! Scope
|-
| <code>[ PCI + body ]</code>
| The FRCP packet.
|-
| <code>[ PCI + body + CRC-32 ]</code>
| CRC-32 covers the body only (PCI is in HCS); appended iff <code>qs.ber == 0</code> on DATA, or on every SACK packet.
|-
| <code>[ AEAD-wrap of above ]</code>
| Iff Authenticated Encryption with Associated Data (AEAD) is enabled.
|}

* 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.
* 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>).

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

=== 1.2. Flag bits ===

Flag bits are numbered most-significant-bit first to match the wire
diagram (bit numbering per [[#1.1. PCI header|Section 1.1]]; bit 0 is the MSB of the
16-bit <code>flags</code> field and lands at wire-position 0 in network byte
order). Bits 13..15 are reserved and MUST be transmitted as zero.

{| class="wikitable"
! Bit !! Mask !! Name !! Meaning
|-
| 0 || <code>0x8000</code> || <code>DATA</code> || Carries caller payload
|-
| 1 || <code>0x4000</code> || <code>DRF</code> || Data Run Flag: start of a fresh run
|-
| 2 || <code>0x2000</code> || <code>ACK</code> || Acknowledgement: <code>ackno</code> field valid
|-
| 3 || <code>0x1000</code> || <code>NACK</code> || Negative ACK; <code>seqno = arrival_seqno-1</code>
|-
| 4 || <code>0x0800</code> || <code>FC</code> || Flow Control: <code>window</code> field valid (<code>rwe</code>)
|-
| 5 || <code>0x0400</code> || <code>RDVS</code> || Rendezvous probe (window-closed)
|-
| 6 || <code>0x0200</code> || <code>FFGM</code> || First Fragment (role bit 0; see below)
|-
| 7 || <code>0x0100</code> || <code>LFGM</code> || Last Fragment (role bit 1; see below)
|-
| 8 || <code>0x0080</code> || <code>RXM</code> || Retransmission
|-
| 9 || <code>0x0040</code> || <code>SACK</code> || Selective ACK block list in payload
|-
| 10 || <code>0x0020</code> || <code>RTTP</code> || RTT Probe / echo (payload follows)
|-
| 11 || <code>0x0010</code> || <code>KA</code> || Keepalive
|-
| 12 || <code>0x0008</code> || <code>FIN</code> || End-of-stream marker (stream mode)
|-
| 13-15 || -- || -- || Reserved (MUST be zero)
|}

The (<code>FFGM</code>, <code>LFGM</code>) pair encodes the fragment role of a DATA-bearing
Service Data Unit (SDU), SCTP-style begin/end flags (RFC 9260
sec. 3.3.1):

{| class="wikitable"
! FFGM !! LFGM !! Role
|-
| 1 || 1 || Sole / un-fragmented SDU (begin AND end)
|-
| 1 || 0 || First fragment of a multi-fragment SDU
|-
| 0 || 0 || Middle fragment
|-
| 0 || 1 || Last fragment
|}

Each fragment is carried in its own FRCP packet with its own <code>seqno</code>;
FRTX (the FRCT Retransmission service mode, see [[#2.2. Service modes (orthogonal axes)|Section 2.2]])
recovers individual fragments via the normal Retransmission Timeout
(RTO) / SACK / Recent Acknowledgement (RACK, RFC 8985) path. The
receiver reassembles the SDU at consume time once the contiguous
[FIRST .. LAST] run has fully arrived. On non-DATA packets the role
bits are unused and MUST be transmitted as zero.

In stream mode (<code>qos.service == SVC_STREAM</code>, see [[#16. Stream-mode flows|Section 16]]) there are
no SDU boundaries to encode, so <code>FFGM</code> and <code>LFGM</code> are unused and MUST
be transmitted as zero. End-of-stream uses a dedicated bit (<code>FIN</code>,
bit 12) carried on a 0-byte DATA packet, emitted at write-half close
(<code>fccntl</code> to <code>FLOWFRDONLY</code>), during linger drain, and at <code>flow_dealloc</code>;
emission is idempotent (first call wins). After contiguous delivery
of the FIN-bearing slot, the receiver latches <code>byte_fin</code> at the FIN's
start offset; <code>flow_read</code> returns 0 (end-of-file, <code>EOF</code>) once buffered
bytes have been drained up to <code>byte_fin</code>. Per-byte position is
carried by the [start, end) extension ([[#1.5. Stream PCI extension|Section 1.5]]).

=== 1.3. SACK payload ===

A SACK packet has the <code>FRCT_ACK | FRCT_FC | FRCT_SACK</code> flag bits set
(bit numbering per [[#1.1. PCI header|Section 1.1]]). Following the 16-octet PCI, the
payload is a 2-octet block count (network byte order), 2 octets of
padding to 4-byte align the block list, then <code>n_blocks</code> pairs of
32-bit start/end seqnos describing ''present'' (received) ranges
above the cumulative ACK.

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_blocks | padding (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start[0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end[0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... n_blocks pairs total ...
</syntaxhighlight>

<code>n_blocks <= SACK_MAX_BLOCKS</code> (2048). The per-flow effective cap is
further bounded by <code>(frag_mtu - PCI - 4) / 8</code> blocks per packet; SACK
packets carry no stream extension, so PCI here is the 16-octet base
header even on stream-mode flows.

Wire invariant: every block produced by the receiver, except an
optional leading Duplicate SACK (D-SACK) block as described below,
describes a range strictly above the cumulative ACK carried in the
PCI <code>ackno</code> field (<code>after(start[i], ackno)</code>). This makes the D-SACK
convention below unambiguous; the receiver-side builder MUST
preserve it.

Duplicate SACK (D-SACK, RFC 2883) is signalled in-band: no flag
bit, no extra framing. Modular seqno arithmetic uses the
<code>before()</code> / <code>after()</code> comparators defined in the Notation block.
<code>Block[0]</code> carries a D-SACK report when either:

;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.
;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.

Senders that do not implement D-SACK process <code>block[0]</code> through the
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
(cap 20), halve once per 16 cumulatively-ACK'd seqnos since the
most recent D-SACK arrival or halve event, reset to 1 on an RTO
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
count as gaps.

=== 1.4. RTTP payload ===

An RTTP (Round-Trip Time Probe) packet has only the <code>FRCT_RTTP</code> flag
set (bit numbering per [[#1.1. PCI header|Section 1.1]]). Following the 16-octet PCI,
the payload is 24 octets (packed):

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| probe_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| echo_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ nonce (16 octets, echoed verbatim) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>probe_id</code>
:sender counter, 0 on reply, 0 reserved.
;<code>echo_id</code>
:peer's <code>probe_id</code>, 0 on outbound probe.
;<code>nonce</code>
:random, echoed unmodified, memcmp'd to defeat spoof.

=== 1.5. Stream PCI extension ===

A stream-mode flow (<code>qos.service == SVC_STREAM</code>) carries an extra
8-octet extension after the 16-octet base PCI on every DATA packet
(bit numbering per [[#1.1. PCI header|Section 1.1]]):

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>start</code>
:octet offset of the first payload byte in the stream.
;<code>end</code>
:octet offset one past the last payload byte; <code>end - start</code> equals the on-wire payload length.

Total stream-mode PCI for DATA packets is 24 octets (16 base + 8
extension); control packets (SACK, RTTP, bare ACK, KA, etc.) retain
the 16-octet base PCI. Stream mode MUST be negotiated at flow
allocation; the extension is present iff stream mode is in use,
never on a per-packet basis. Both peers MUST treat <code>start</code>/<code>end</code> as
monotonic 32-bit byte offsets; when a slot reaches the head of the
contiguous run with <code>start</code> not equal to the prior packet's <code>end</code> the
slot is silently dropped at delivery time ([[#16. Stream-mode flows|Section 16]]) rather
than rejected at stash.

This is the QUIC STREAM-frame reassembly model (RFC 9000 sec. 19.8):
each packet carries its packet <code>seqno</code> (this PCI's <code>seqno</code> field) and a
separate stream byte position (<code>start</code>/<code>end</code>). Separating the two
avoids TCP's conflation of packet identity with byte position which
forces Karn's algorithm for Round-Trip Time (RTT) sampling (no RTT
sample on retransmits, RFC 6298 sec. 3); FRCP applies the
Karn-equivalent gate via a combination of per-packet <code>FRCT_RXM</code>,
per-slot <code>SND_RTX</code> flags, and a sample-fence <code>rtt_lwe</code> (see [[#2.1. Per-flow state|Section 2.1]]
and [[#12. RTT estimation|Section 12]]). FRCP's fixed-32-bit <code>start</code>/<code>end</code> wrap at 4 GiB of
wire bytes, narrower than QUIC's 62-bit varint offset (cf. RFC 9000
sec. 16); the on-wire wrap is handled by the same modular <code>before()</code>
/ <code>after()</code> comparators ([[#1.3. SACK payload|Section 1.3]]) FRCP uses for seqnos, which
remain unambiguous as long as the in-flight byte window stays
strictly under 2 GiB (the half-range of the signed-int32 difference
in <code>before()</code>). The default per-flow ring is 1 MiB; the
implementation caps <code>ring_sz</code> at 128 MiB (<code>FRCT_STREAM_RING_SZ_MAX</code>),
well below the 2 GiB half-range bound. The runtime byte counters
exposed via FUSE (Filesystem in Userspace) in the Ouroboros
Resource Information Base (RIB, a virtual-filesystem introspection
bridge) are platform <code>size_t</code> and do not wrap on 64-bit hosts.

== 2. Per-flow state and service modes ==

=== 2.1. Per-flow state ===

Each flow keeps a sender control record and a receiver control
record:

;<code>lwe</code> : <code>u32</code>
:snd: oldest unacked <code>seqno</code> (cumulative ACK boundary as seen by sender); rcv: next in-order <code>seqno</code> expected
;<code>rwe</code> : <code>u32</code>
:snd: peer-advertised right window edge; rcv: locally-advertised right window edge
;<code>cflags</code> : <code>u8</code>
:per-direction feature flags: retransmission (<code>FRCTFRTX</code>), receiver flow control (<code>FRCTFRESCNTL</code>), linger-on-close (<code>FRCTFLINGER</code>); see <code><ouroboros/fccntl.h></code>
;<code>seqno</code> : <code>u32</code>
:snd: next <code>seqno</code> to send; rcv: force-ACK trigger - set on a stale or dup DATA so the next <code>ack_snd</code> emits a fresh cumulative ACK
;<code>ackno</code> : <code>u32</code>
:snd: <code>seqno</code> counter for standalone ACK-bearing control packets (delayed ACK, SACK, final ACK on dealloc); not bumped on piggybacked ACK riding a DATA packet (which uses the DATA <code>seqno</code>). Used by wire-dup ACK detection; rcv: incoming-ACK dedup tracker
;<code>act</code> : <code>ns</code>
:last activity (used by inactivity / DRF)
;<code>inact</code> : <code>ns</code>
:inactivity threshold; sender = <code>3*mpl + a + r + 1s</code>, receiver = <code>2*mpl + a + r + 1s</code>. <code>mpl</code> is the Maximum Packet Lifetime (delta-t terminology; see [[#15. Heritage and adopted techniques|Section 15]]); <code>a</code> and <code>r</code> are the FRCT a-timer and r-timer bounds (see [[#8. Retransmission|Section 8]]). The asymmetry is load-bearing for pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]).

The sender holds a per-slot ring <code>snd_slots[RQ_SIZE]</code> keyed by
<code>(seqno mod RQ_SIZE)</code>. Each slot tracks its retransmit entry (<code>rxm</code>),
last-send timestamp, and retransmit flag bits: <code>SND_RTX</code> (a
retransmit is pending or has fired, gates the next RTT sample
under Karn) and <code>SND_FAST_RXM</code> (one-shot fast-retransmit staged for
this loss event).

The receiver holds a parallel reorder ring <code>rcv_slots[RQ_SIZE]</code>
(referred to as <code>rq[]</code> in prose) holding stashed out-of-order
packet-buffer indexes; both FRTX and best-effort flows share this
path. The invariant <code>rwe - lwe <= RQ_SIZE</code> holds: on each consume
the receiver advances <code>rwe</code> by the consumed count, capping the
receive window at <code>RQ_SIZE</code> <code>seqno</code> slots.

A separate fence variable <code>rtt_lwe</code> is bumped on every retransmit
(timer-fire, SACK-driven, fast-rxm, NACK-driven) and on every
<code>seqno_rotate</code> ([[#4. Sequence-number rotation (DRF)|Section 4]]) to mark the <code>seqno</code> range whose RTT samples
MUST be discarded.

=== 2.2. Service modes (orthogonal axes) ===

FRCP exposes its wire features as a vector of independent QoS
axes selected at flow allocation time. All flows go through the
same <code>flow_alloc(name, qos, ...)</code> primitive; the <code>qosspec_t</code> passed
in determines which protocol machinery engages on the wire. This
contrasts with the POSIX BSD socket model where TCP and UDP
require different socket types (<code>SOCK_STREAM</code> / <code>SOCK_DGRAM</code>).

The axes:

;<code>service</code>
:0 = unordered (no FRCP engagement: raw datagrams, no PCI on the wire, UDP-equivalent at this layer); 1 = message-ordered (FRCP engaged; SDU boundaries preserved across fragmentation); 2 = stream (byte-oriented, no SDU boundaries; FRTX required)
;<code>loss</code>
:0 = lossless service requested: FRTX retransmit machinery engages ([[#8. Retransmission|Section 8]]); MUST be 0 for <code>service=2</code>. Non-zero = best-effort, FRTX off.
;<code>ber</code>
:Bit Error Rate tolerance. 0 = error-free service requested: a CRC trailer is appended after the body of DATA packets and verified on receive (added / checked outside the FRCP PCI; see [[#1.1. PCI header|Section 1.1]]). Non-zero = peer accepts errors; trailer omitted. SACK control packets carry a CRC32 trailer regardless of <code>ber</code>; the <code>ber</code> gate applies to DATA only.
;<code>timeout</code>
:Peer-timeout (ms); 0 disables the keepalive timer. Independent of FRCP engagement.

Encryption is a separate per-flow attribute set at flow setup;
when enabled it wraps the FRCP packet (PCI + body, plus the CRC
trailer if any) under AEAD, expanding the <code>spb</code> by <code>headsz</code> + <code>tailsz</code>
octets (nonce / tag). The CRC trailer is currently kept inside
the AEAD wrap (see [[#1.1. PCI header|Section 1.1]]).

Reachable combinations exported by <code>include/ouroboros/qos.h</code>:

{| class="wikitable"
! Cube !! <code>service</code> !! <code>loss</code> !! <code>ber</code> !! Engaged
|-
| <code>qos_raw</code> || 0 || 1 || 1 || Raw passthrough
|-
| <code>qos_raw_safe</code> || 0 || 1 || 0 || Raw + CRC trailer
|-
| <code>qos_rt</code> || 1 || 1 || 1 || FRCP, no FRTX, no CRC
|-
| <code>qos_rt_safe</code> || 1 || 1 || 0 || FRCP, no FRTX, CRC
|-
| <code>qos_msg</code> || 1 || 0 || 0 || FRCP + FRTX
|-
| <code>qos_stream</code> || 2 || 0 || 0 || FRCP + FRTX, stream
|}

Forced couplings actually enforced by the public API:

* <code>service == SVC_STREAM</code> (2) requires <code>loss == 0</code>; <code>flow_alloc</code> / <code>flow_accept</code> reject the pair otherwise with <code>-EINVAL</code>.
* FRTX requires FRCP engagement (<code>service != SVC_RAW</code>); requesting <code>loss = 0</code> with <code>service = SVC_RAW</code> is structurally a no-op because no <code>frcti</code> is created.
* The <code>QOS_DISABLE_CRC</code> build flag globally forces <code>ber = 1</code>. Note: this flag defaults to ON, so default builds ship with CRC disabled until <code>QOS_DISABLE_CRC</code> is set to OFF.

Caveat: the API does NOT force <code>ber = 0</code> when <code>service != SVC_RAW</code>.
<code>qos_rt</code> has <code>service = SVC_MESSAGE</code> with <code>ber = 1</code>, which means the PCI
itself is not CRC-protected on that cube; the HCS ([[#1.1. PCI header|Section 1.1]])
remains the only integrity check on the header.

The FRCP-no-FRTX regime (<code>service = SVC_MESSAGE</code>, <code>loss > 0</code>) is meaningful
and live: sequence numbering, in-order delivery, flow-control
advertisement, KA, DRF rotation, and SDU fragmentation /
reassembly ([[#7.2. Fragmentation and reassembly|Section 7.2]]) all run. Lost packets are dropped
rather than retransmitted; a permanently-lost mid-fragment is
dropped via skip-past-gap once a later SDU is visible in the
reorder ring.

== 3. Protocol parameters ==

{| class="wikitable"
! Parameter !! Value !! Role
|-
| <code>RQ_SIZE</code> || compile-time, power of 2 (default 128) || Slot ring / rcv window width
|-
| <code>START_WINDOW</code> || compile-time, power of 2 (default 128) || Initial <code>rwe-lwe</code> after rotate
|-
| <code>RTO_MIN</code> || <code>MAX(250 us build-tunable, 1<<RXMQ_RES)</code>; per-flow via <code>fccntl</code> (<code>FRCTSRTOMIN</code>). Default ~1 ms with <code>RXMQ_RES=20</code>. || RTO floor; also floored at the retransmit-wheel resolution (~1 ms by default).
|-
| <code>MAX_RTO_MUL</code> || 20 || Backoff shift cap
|-
| RACK window <code>R</code> || <code>MIN(reo_wnd_mult * min_RTT/4, SRTT)</code> with <code>MIN_REORDER_NS = 250 us</code> floor; <code>reo_wnd_mult</code> scales on D-SACK, cap 20 || Reorder window; per RFC 8985 sec. 6.2; <code>reo_wnd_mult</code> per sec. 6.2 step 4
|-
| <code>MIN_RTT_WIN_NS</code> || 300 s (5 min, Linux <code>tcp_min_rtt_wlen</code>) || <code>min_RTT</code> windowed re-anchor
|-
| <code>REO_WND_MULT_MAX</code> || 20 (RFC 8985 sec. 6.2 step 4) || <code>reo_wnd_mult</code> cap
|-
| <code>REO_DECAY_PKTS</code> || 16 (RFC 8985 sec. 6.2 step 4 / <code>RACK.reo_wnd_persist</code>) || Fresh-ACK'd seq count per halving
|-
| <code>MAX_DSACK_LAG</code> || <code>RQ_SIZE</code> || D-SACK sanity cap
|-
| <code>RTT_QUARANTINE</code> || 32 (<code>seqno</code> steps) || NewReno gate pad
|-
| SACK rate-limit || <code>SACK_MIN_GAP_NS</code> (250 us, fixed) || Min SACK gap
|-
| <code>SACK_MAX_BLOCKS</code> || 2048 (wire cap; per-flow capped at <code>(frag_mtu-PCI-4)/8</code>) || Per-SACK block cap
|-
| <code>SACK_RXM_MAX</code> || 32 || Per-pass staged retransmit cap
|-
| <code>DUP_THRESH</code> || 3 (RFC 8985 default) || Hybrid fast-rxm trigger ([[#8. Retransmission|Section 8]])
|-
| <code>MDEV_MUL</code> || 2 (build-tunable via <code>FRCT_RTO_MDEV_MULTIPLIER</code>) || <code>mdev</code> shift in <code>RTO = srtt + (mdev << MDEV_MUL)</code>
|-
| RTTP nonce || 16 octets || Echoed verbatim
|-
| <code>RTTP_RING</code> || 8 || In-flight probes
|-
| RTT clamp || <code>16 * srtt</code> || Probe-sample upper bound (ACK-derived RTT samples gated by Karn / recovery only)
|-
| Cold-probe cadence || 100 ms (rx-driven; see [[#12. RTT estimation|Section 12]]) || Pre-<code>srtt</code> RTTP rate
|-
| <code>DELT_RDV</code> || 100 ms || RDVS emit cadence
|-
| <code>MAX_RDV</code> || 1 s || RDVS give-up
|-
| Delayed-ACK fire || <code>2 * TICTIME</code> (<code>TICTIME</code> = FRCT tick granularity, default 5 ms; <code>2*TICTIME = 10 ms</code> by default) || Fired after the first in-order DATA arrival; tick is build-tunable
|-
| NACK send cooldown || <code>srtt</code> when an <code>srtt</code> sample exists, else 100 ms || Pre-DRF NACK rate-limit
|-
| <code>MAX_SDU</code> || 1 MiB || Max reassembled SDU; configurable per flow
|}

The per-flow fragment Maximum Transmission Unit (MTU) is computed
at flow setup from the lower IPCP's mtu minus encryption
<code>headsz</code> / <code>tailsz</code> and CRC trailer; there is no FRCT-level default or
environment-variable override.

== 4. Sequence-number rotation (DRF) ==

The DRF (Data Run Flag) bit on an outbound packet means "this is
the start of a fresh data run" and is set whenever the sender has
nothing in flight (<code>snd_cr.seqno == snd_cr.lwe</code>).

Independently of that, if the sender has been idle longer than
<code>snd_cr.inact</code> AND the pipe is empty (<code>snd_cr.seqno == snd_cr.lwe</code>),
<code>seqno_rotate()</code> rolls a random new <code>seqno</code> before the send and
resets

<syntaxhighlight lang="text">
snd_cr.seqno = random()
snd_cr.lwe = snd_cr.seqno
snd_cr.rwe = snd_cr.seqno + START_WINDOW
rtt_lwe = snd_cr.seqno
in_recovery = false (recovery state, see Section 8)
recovery_high = snd_cr.seqno
</syntaxhighlight>

The receiver, on observing rcv-side inactivity
(<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
below). Non-DATA control packets pass through without the DRF
requirement. On DRF the receiver releases the <code>rq[]</code> slots and
rebases

<syntaxhighlight lang="text">
rcv_cr.lwe = seqno
rcv_cr.rwe = seqno + RQ_SIZE
rcv_cr.seqno = seqno
</syntaxhighlight>

If the inactive packet has DATA but no DRF, a rate-limited NACK is
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).

== 5. Send path ==

# If the SDU exceeds <code>(frag_mtu - data_hdr_len)</code>, the caller (<code>dev.c</code>) fans it out into <code>ceil(count / (frag_mtu - data_hdr_len))</code> fragments, each emitted via <code>frcti_snd</code> as its own DATA packet with a per-fragment role ([[#7.2. Fragmentation and reassembly|Section 7.2]]); both FRTX and best-effort flows fragment. Raw flows (no FRCP engagement, <code>qos.service == SVC_RAW</code>) carry no PCI and return <code>-EMSGSIZE</code> for any SDU larger than one packet at the layer below. An SDU that fits in a single packet is sent as SOLE. <code>frcti_snd</code> reserves PCI head room; sets DATA, plus DRF when the pipe is empty (<code>snd_cr.seqno == snd_cr.lwe</code>).
# <code>seqno_rotate()</code> if past sender inactivity and the pipe is empty ([[#4. Sequence-number rotation (DRF)|Section 4]]).
# Advertise FC (<code>pci.window = frcti_advert_rwe(frcti)</code>, i.e. <code>rcv_cr.rwe</code> clamped to <code>rcv_cr.lwe + ring_seq_cap</code> in stream mode) when the receiver side is recent: <code>now - rcv_cr.act < rcv_cr.inact</code>.
# Reliable mode (FRTX): leave <code>snd_cr.lwe</code> where it is; reset the slot at <code>RQ_SLOT(seqno)</code> (<code>snd_slots[p].time = now</code>, <code>snd_slots[p].flags = 0</code>); queue an <code>rxm_entry</code> (saves a packet copy, arms a wheel timer at <code>now + (rto << rto_mul)</code>). Piggyback ACK (<code>pci.ackno = rcv_cr.lwe</code>) while the a-timer for the most recent received DATA packet has not yet expired (<code>now - rcv_cr.act <= t_a</code>); on piggyback, set <code>rcv_cr.seqno = rcv_cr.lwe</code> so the next delayed-ACK fire is suppressed. See [[#8. Retransmission|Section 8]] for <code>t_a</code> / <code>t_r</code> semantics.
# Best-effort mode (no FRTX): advance <code>snd_cr.lwe</code> immediately (<code>snd_cr.lwe = snd_cr.lwe + 1</code>, <code>snd_cr.rwe = snd_cr.lwe + RQ_SIZE</code>); no retransmit state. No send-side RTT probe is armed in this mode (<code>rtt_probe_arm</code> requires an in-flight <code>seqno</code>, which best-effort never has); the rx-driven cold seeder in <code>frcti_rcv</code> is the only probe path.
# In reliable mode, optionally arm an RTT probe ([[#12. RTT estimation|Section 12]]).

== 6. Receive path ==

=== 6.1. Early-exit dispatch ===

Keepalive (KA), RTT probe (RTTP), pre-DRF NACK, and rendezvous
(RDVS) packets short-circuit out of <code>frcti_rcv</code> before the locked
main path; each handler takes its own lock internally.

<syntaxhighlight lang="text">
incoming packet
|
v
+---------+
| KA? |---yes--> ka_rcv ; return
+---------+
|no
v
+---------+
| RTTP? |---yes--> rttp_rcv; return
+---------+
|no
v
+---------+
| NACK? |---yes--> nack_rcv; return (see Section 9)
+---------+
|no
v
+---------+
| RDVS? |---yes--> rdv_rcv ; return (reply bare FC, ackno=0)
+---------+
|no
v
acquire wrlock; enter locked main path
</syntaxhighlight>

;<code>KA</code>
:refresh <code>t_ka_rcv</code>, honour piggybacked ACK.
;<code>RTTP</code>
:probe (echo back nonce) or echo (verify nonce, sample RTT).
;<code>NACK</code>
:pre-DRF, sender-side handler. See [[#9. Pre-DRF NACK|Section 9]].
;<code>RDVS</code>
:reply with a bare FC packet (<code>ackno = 0</code>); <code>rdlock</code> only.

=== 6.2. Locked main path ===

Steps below run with the per-flow <code>frcti.lock</code> held for writing
(<code>pthread_rwlock_wrlock</code>) unless noted.

;<code>rcv_inact_check</code>
:Only meaningful when the receive side is stale. On DRF (Data Run Flag): release <code>rq[]</code> slots, rebase <code>rcv_cr</code>, continue. On stale DATA without DRF: fire a pre-DRF NACK if cooldown allows ([[#9. Pre-DRF NACK|Section 9]]), then discard the packet; on cooldown, drop without sending a NACK (a pending cumulative ACK from <code>drop_packet</code> may still go out). Non-DATA, non-DRF arrivals bypass <code>rcv_inact_check</code> entirely; pure-DRF stale arrivals fall through after the DRF rebase branch.

;DATA-only act refresh
:Refresh <code>rcv_cr.act</code> only when <code>FRCT_DATA</code> is set, so that non-DATA packets never block the next DRF rebase.

;Wire-dup gate
:Before flag-driven dispatch, drop wire-duplicate ACKs and wire-duplicate DATA (<code>is_dup_ack</code> / <code>is_dup_data</code>). The DATA check is bypassed for <code>FRCT_RXM</code>-bearing arrivals so the piggybacked ACK / SACK / FC carried on a retransmitted DATA at an already-ACK'd <code>seqno</code> is still applied; the stale-in-window branch below then drops the packet.

;<code>ACK</code>
:Drop ACKs whose <code>ackno</code> falls outside <code>(snd_cr.lwe, snd_cr.seqno]</code>. If <code>ackno == snd_cr.lwe</code> (non-advancing cumulative ACK), drive RACK fast-retransmit consideration ([[#8. Retransmission|Section 8]]). Otherwise advance <code>snd_cr.lwe = ackno</code>, collapse <code>rto_mul</code> to 0 (Karn-gated by <code>SND_RTX</code> on the just-acknowledged slot, the old head-of-line), reset <code>dup_thresh</code> to 0, update <code>t_latest_ack</code> to the send-time of the slot at <code>ackno-1</code> (consumed by RACK and SACK below), decay <code>reo_wnd_mult</code> per RFC 8985 sec. 6.2 step 4, exit NewReno-careful recovery (see [[#8. Retransmission|Section 8]]) on <code>ackno >= recovery_high</code> or <code>ackno == snd_cr.seqno</code>, and feed an RTT sample if eligible ([[#12. RTT estimation|Section 12]]).

;<code>SACK</code>
:Walk the block list. For each block (a present range above <code>lwe</code>) NULL out <code>snd_slots[k].rxm</code>, clear the slot's per-send flags, and advance <code>t_latest_ack</code> to the latest send-time covered (the Forward Acknowledgement / fack equivalent, Mathis & Mahdavi 1996); the first block whose start clamps to <code>snd_cr.lwe</code> skips this fack update so that a head-of-line clamp does not falsely advance fack. For un-SACKed gaps below <code>hi_sacked</code>, stage a retransmit per slot that is (1) still owned (<code>rxm != NULL</code>), (2) not already <code>SND_FAST_RXM</code>, (3) not aged out past <code>t_r</code>, and (4) either outside the RACK reorder window <code>R</code> OR with <code>dup_thresh >= DUP_THRESH</code> (the RFC 8985 sec. 6.2 hybrid trigger). Mark the slot <code>SND_FAST_RXM</code> and NULL the <code>rxm</code> at stage time. Capped at <code>SACK_RXM_MAX</code> staged retransmits per receive pass; what's left rides the next SACK.

;<code>FC</code>
:Bump <code>snd_cr.rwe</code> (clamped to <code>lwe + RQ_SIZE</code>, never shrinks) and mark window open.

;<code>DATA</code>
:Bounds-check <code>seqno</code> against window. On stale-dup (<code>seqno < rcv_cr.lwe</code>), set <code>rcv_cr.seqno = seqno</code> to force a fresh ACK on the next <code>ack_snd</code>, then drop. On accept: both FRTX and best-effort stash the packet-buffer index into <code>rq[seqno mod RQ_SIZE]</code>. Fragments stash unchanged - the role bits are inspected only at consume time ([[#7.2. Fragmentation and reassembly|Section 7.2]]). On out-of-order arrival, build a SACK reply if not rate-limited (per [[#3. Protocol parameters|Section 3]]) and not deduplicated against the previous <code>(rcv_cr.lwe, n_blocks)</code> pair; D-SACK reports always bypass the dedup. If both rate-limit and dedup suppress the reply, neither SACK nor delayed-ACK fires (the sender picks up the gap on its next ACK). On in-order arrival, arm the delayed-ACK timer.

;<code>drop_packet</code> exit
:Releases the per-packet shared-memory buffer (<code>spb</code>), then calls <code>ack_snd</code> synchronously after the <code>spb</code> release to surface any pending cumulative ACK.

== 7. Read path and reassembly ==

=== 7.1. Read path ===

<code>flow_read</code> returns a full reassembled SDU (Service Data Unit) via
<code>frcti_consume</code> on every FRCP SDU-mode flow (FRTX or best-effort);
stream-mode is covered in [[#16. Stream-mode flows|Section 16]]. An incomplete head-of-line
(HoL) run yields <code>-EAGAIN</code>; an oversized run yields <code>-EMSGSIZE</code> (the
run is dropped so the flow does not stall). On best-effort flows,
a permanently-lost mid-fragment is dropped as soon as a later
complete SDU becomes visible in the ring ([[#7.2. Fragmentation and reassembly|Section 7.2]] skip-past-
gap).

Raw flows carry no <code>frcti</code>, so <code>flow_read</code> returns the next pending
packet-buffer index directly, with no role-bit inspection. (Raw
service is selected via <code>qos.service == SVC_RAW</code> at flow allocation,
which suppresses <code>frcti</code> creation.)

<code>frcti_pdu_ready</code> is the no-advance peek used by <code>fevent</code> (the
Ouroboros flow-event multiplexer, the <code>poll(2)</code>-equivalent on
flows). It returns ready only when the head-of-line run is
complete and the lead packet (a Protocol Data Unit, here one FRCP
packet) is present at <code>rcv_cr.rwe - RQ_SIZE</code>; any other state
(including the best-effort skip-past-gap case) returns not ready,
and <code>frcti_consume</code> is left to drop the broken prefix and re-
inspect.

=== 7.2. Fragmentation and reassembly ===

Send side (<code>flow_write_frag</code>). An SDU larger than
<code>(frag_mtu - PCI)</code> is split into <code>ceil(count / (frag_mtu - PCI))</code>
fragments; each fragment is its own FRCP packet with its own
<code>seqno</code> and a per-fragment role flag pair ([[#1.2. Flag bits|Section 1.2]]). Roles are
assigned at emit time:

{| class="wikitable"
! i !! Role
|-
| <code>n=1</code> || <code>SOLE</code>
|-
| <code>i=0</code> || <code>FIRST</code>
|-
| <code>i=n-1</code> || <code>LAST</code>
|-
| else || <code>MID</code>
|}

A mid-loop allocation or transmit failure may yield a partial
write: the call returns the bytes already enqueued (<code>off > 0</code>) or
the underlying error (<code>off == 0</code>). Best-effort flows fragment
identically; on the receiver, a partial run with a permanently-
lost fragment is dropped when a later complete SDU is visible in
the ring (see skip-past-gap below). Raw flows carry no PCI and
refuse anything larger than the layer's user MTU (<code>-EMSGSIZE</code>).

Wire-level recovery is fragment-agnostic on FRTX flows: each
fragment's <code>seqno</code> flows through SACK / RACK / RTO / NACK exactly
as for a SOLE DATA packet, and reassembly does not re-enter the
loss-detection path. Best-effort flows run the same <code>seqno</code>
machinery (DRF, FC, ACK piggyback, pre-DRF NACK emit) but queue
no <code>rxm</code> state at the sender, so a lost MID is unrecoverable;
skip-past-gap handles it (below).

Receive side. Fragments stash into <code>rq[seqno]</code> unchanged; role bits
are read only at consume time. <code>frag_run_inspect</code>, called from
<code>frcti_consume</code>, walks the ring starting at the oldest still-
undelivered <code>seqno</code> <code>base = rcv_cr.rwe - RQ_SIZE</code> (equal to <code>rcv_cr.lwe</code>
only when no partial run is in progress; during a partial run <code>lwe</code>
has already advanced past <code>base</code>). It produces one of three
outcomes:

{| class="wikitable"
! Outcome !! Cause
|-
| <code>DELIVER (n)</code>
| <code>rq[base]=SOLE</code> (<code>n=1</code>), or <code>rq[base]=FIRST</code> and a <code>LAST</code> follows in slots <code>[base+1..base+n-1]</code> with all intermediate roles in <code>{MID,FIRST,LAST}</code> contiguous.
|-
| <code>DROP (n)</code>
| <code>rq[base]</code> is <code>MID</code> or <code>LAST</code> without a preceding <code>FIRST</code> (<code>n=1</code>); a <code>FIRST..[non-LAST]..new-FIRST</code> or new-<code>SOLE</code> mid-run (drop the broken prefix with <code>n</code> = run length minus 1, so the new <code>FIRST</code>/<code>SOLE</code> stays); or, on best-effort flows, a gap at <code>base</code> with a <code>FIRST</code>/<code>SOLE</code> later in the ring (drop up to the new run start).
|-
| <code>NOT_READY</code>
| <code>rq[base]</code> absent or <code>FIRST..[non-LAST]</code> with no later <code>FIRST</code>/<code>SOLE</code> in the ring (FRTX waits for retx; best-effort waits for arrival).
|}

<code>DELIVER</code> triggers <code>frag_gather</code>: a scatter-gather <code>memcpy</code> of the <code>n</code>
consecutive fragments at <code>rq[base..base+n-1]</code> directly into the
caller's buffer; each per-packet shared-memory buffer (<code>spb</code>) is
released and <code>rwe</code> advances by <code>n</code>. <code>lwe</code> was already advanced
incrementally as each contiguous fragment arrived; <code>frag_gather</code>
only restores the fixed-width invariant <code>rwe == lwe + RQ_SIZE</code>.
No intermediate reassembly buffer is allocated.

<code>DROP</code> advances <code>rwe</code> past the broken prefix (releasing the <code>spb</code>s)
and pulls <code>lwe</code> up to the new trailing edge if needed; the next
consume retries from the new <code>base</code>. Oversize or arithmetically
overflowing delivery (sum of fragment lengths > <code>max_rcv_sdu</code>, sum
> caller's buffer, or running-sum overflow) also drops the run
with <code>-EMSGSIZE</code>.

Skip-past-gap (best-effort only). On FRTX, a gap in the run means
"waiting for retransmit" and <code>frag_run_inspect</code> returns <code>NOT_READY</code>.
On best-effort flows the gap is permanent, so <code>frag_run_inspect</code>
scans forward in the ring for the next <code>FIRST</code> or <code>SOLE</code>; if one is
visible within <code>RQ_SIZE</code>, it returns <code>DROP</code> for the broken prefix and
the consume loop retries at the new <code>lwe</code>. Memory hold is bounded
by <code>RQ_SIZE</code>; the partial releases on the next consume call once a
later complete run exists. Voice-like flows (one <code>SOLE</code> per SDU)
see no extra wait: any later <code>SOLE</code> makes the prior gap droppable
immediately.

The choice to defer reassembly to consume time keeps the receive
path zero-copy: fragments stay in the shared-memory ring until
the application pulls, and the SDU lands directly in the caller's
buffer.

== 8. Retransmission ==

FRCP is bounded by two delta-t-derived timers (Watson 1981, see
[[#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_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.

Each in-flight FRTX <code>seqno</code> owns one <code>rxm_entry</code>, armed in a hashed
timing wheel; the wheel deadline is the slot's next eligible
retransmit time.

;RTO timer
:On fire (<code>rxm_due</code>), re-emit with <code>FRCT_RXM</code>, mark <code>SND_RTX</code> (Karn-suppress next ACK's RTT sample), and (for the head-of-line (HoL) slot only) bump <code>rto_mul</code> up to <code>MAX_RTO_MUL</code>. Wheel deadline is <code>t_send + (rto << rto_mul)</code>. Re-armed unless consumed. The RTO timer also clears <code>SND_FAST_RXM</code> (re-arming fast-retransmit eligibility), resets <code>reo_wnd_mult</code> to 1 on a HoL fire (RFC 8985 sec. 6.2 step 4 reset clause), and marks the flow <code>ACL_FLOWDOWN</code> if its <code>frct_tx</code> call fails.

;r-timer guard
:Before any retransmit attempt, check <code>(now - t0)</code> against <code>t_r</code>. If exceeded, the slot is no longer eligible for retransmit. Only the RTO timer (<code>rxm_due</code>) treats r-timer expiry as terminal: it marks the flow <code>ACL_FLOWDOWN</code> (peer unreachable). Fast-retransmit, SACK-driven retransmit, and NACK-driven head-of-line re-emit silently skip aged-out slots and defer the flow-down decision to the next RTO fire.

;Fast retransmit (hybrid trigger, RFC 8985 sec. 6.2)
:On a non-advancing cumulative ACK with the scoreboard advanced, fire one fast retransmit when EITHER (a) the head-of-line slot's latest send is older than the RACK reorder window <code>R</code> ([[#3. Protocol parameters|Section 3]]) and not yet aged out, OR (b) the SACK <code>dup-thresh</code> count above <code>snd_cr.lwe</code> reaches <code>DUP_THRESH</code> (= 3, RFC 8985 sec. 6.2 step 4). Fires at most once per non-advancing cumulative-ACK value, gated by <code>rack_fired_lwe</code> (the <code>snd_cr.lwe</code> at which fast-retransmit last fired). Set <code>SND_FAST_RXM</code> on the slot (one-shot per-slot gate) and enter NewReno-style careful recovery (see NewReno below in this section).
:The RACK reorder window <code>R</code> uses the RFC 8985 sec. 6.2 form <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> with a <code>MIN_REORDER_NS = 250 us</code> floor. Before the first RTT sample seeds <code>min_rtt</code>, <code>R</code> falls back to <code>MIN(reo_wnd_mult * SRTT / 4, SRTT)</code>, still floored at <code>MIN_REORDER_NS</code> (consistent with the windowed-minimum fallback described in [[#12. RTT estimation|Section 12]]). <code>min_rtt</code> is a windowed minimum over the last <code>MIN_RTT_WIN_NS</code> = 5 min of RTT samples (matches the Linux <code>tcp_min_rtt_wlen</code> default) so a route change to a longer path eventually re-anchors the reorder window without relying on <code>reo_wnd_mult</code> growth alone.

;SACK-driven retransmit
:For each gap below <code>hi_sacked</code> whose slot is (1) still owned, (2) not already <code>SND_FAST_RXM</code>, (3) not aged out past <code>t_r</code>, and (4) either outside the RACK window <code>R</code> OR with <code>dup_thresh >= DUP_THRESH</code> (same hybrid as fast-retransmit, see [[#6.2. Locked main path|Section 6.2]]), re-emit. Each SACK-driven retransmit re-arms a fresh <code>rxm</code> so a lost retransmit can still be recovered by its own RTO timer.

;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.

== 9. Pre-DRF NACK ==

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.

;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>)
:When an incoming DATA packet has no DRF and rcv-side activity is older than <code>rcv_cr.inact</code>, the receiver emits a bare packet with <code>flags = FRCT_NACK</code> and <code>seqno = arrival_seqno - 1</code> (informational only, not consulted by the receive handler). The cooldown in [[#3. Protocol parameters|Section 3]] rate-limits the burst. Non-DATA non-DRF arrivals bypass <code>rcv_inact_check</code> entirely; non-DATA DRF still rebases via the DRF branch.

;Receive (<code>frcti_nack_rcv</code>)
: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 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.

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 ==

Cumulative ACK is <code>ackno = rcv_cr.lwe</code>. On out-of-order arrival the
receiver also emits a SACK packet ([[#1.3. SACK payload|Section 1.3]]) whose payload lists
''present'' blocks above <code>lwe</code> (analogous to TCP SACK / QUIC ACK
ranges). SACKs are rate-limited per [[#3. Protocol parameters|Section 3]] and suppressed when
neither <code>lwe</code> nor block count has changed since the last SACK.

D-SACK reports (RFC 2883) are emitted in-band as <code>block[0]</code> of an
otherwise normal SACK frame (see [[#1.3. SACK payload|Section 1.3]] for the encoding).
Two receiver triggers arm a pending D-SACK report (single-slot,
latest-wins):

* DATA arrival with <code>seqno < rcv_cr.lwe</code>, both wire-dup (no RXM, <code>is_dup_data</code> path) and retransmit (RXM, post-FC branch) (RFC 2883 sec. 4.1.1, full duplicate)
* <code>rq_accept</code> conflict, slot already occupied in <code>[lwe, rwe)</code> (RFC 2883 sec. 4.1.2, partial duplicate)

When a D-SACK is pending and the standard scoreboard SACK would be
suppressed by dedup or rate-limit, the report is emitted as a
stand-alone SACK frame through the normal <code>ack_snd</code> path; when a
D-SACK report is pending the path bypasses dedup and the <code>TICTIME</code>
rate-limit, but the a-timer suppression on rcv inactivity still
applies.

Bare ACKs are deferred via a per-flow delayed-ACK timer (one in
flight at a time, atomic test-and-set dedup; fires per [[#3. Protocol parameters|Section 3]]
after the first in-order arrival). Suppressed if (1) no new
<code>seqno</code>, (2) rcv side is inactive (older than <code>t_a</code>), or (3) the
sender just sent within <code>TICTIME</code>. A pending D-SACK ride-through
bypasses (1) and (3); the a-timer gate (2) is unconditional.

== 11. Flow control ==

The receiver advertises <code>rwe</code> in every FC field. The sender treats
its <code>snd_cr.rwe</code> as the absolute right edge: when
<code>snd_cr.seqno >= snd_cr.rwe</code> the window is closed and <code>flow_write</code>
yields. While closed, the sender periodically emits RDVS
(rendezvous) packets (cadence <code>DELT_RDV</code>); the receiver replies with
a bare FC packet (<code>ackno = 0</code>) that reopens the window. Once the
window has been closed for longer than <code>MAX_RDV</code> the sender stops
emitting RDVS but does not tear the flow down - the writer keeps
blocking until either a peer-driven FC arrives or the KA
(keepalive) / r-timer marks the flow.

<code>rwe</code> is clamped to <code>lwe + RQ_SIZE</code> on receipt and MUST NOT shrink:
a backward <code>rwe</code> is silently clamped to the current <code>snd_cr.rwe</code>;
the FC packet still reopens the window.

== 12. RTT estimation ==

Active RTTP probes ([[#1.4. RTTP payload|Section 1.4]]) carry a 32-bit <code>probe_id</code> (0
reserved) and a 16-byte random nonce echoed verbatim - defends
against spoofed replies. A ring of <code>RTTP_RING</code> in-flight probes is
kept; an echo whose <code>(id, nonce)</code> doesn't match the ring slot is
dropped. A single RTTP sample is clamped to <code>RTT_CLAMP_MUL * srtt</code>
(compile-time <code>RTT_CLAMP_MUL = 16</code>) once <code>srtt</code> is seeded; the first
cold-probe sample feeds <code>rtt_update</code> raw.

Probe arming gates:

;Cold (no <code>srtt</code> yet)
:the receive path arms at most one probe per 100 ms via <code>frcti_rcv_probe</code> (<code>PROBE_DUE_COLD</code>); arming requires an incoming packet. Active send-path arming bails while <code>srtt == 0</code>.
;Warm (<code>rtt_probe_arm</code>, called from <code>frcti_snd</code>)
:outstanding data (<code>snd_cr.seqno > snd_cr.lwe</code>), AND at least <code>2 * srtt</code> since <code>t_rcv_rtt</code> (last RTT receive of any kind), AND at least <code>srtt</code> since <code>t_snd_probe</code> (last probe emit).

Sample feeds either Linux's asymmetric <code>mdev</code> estimator
(<code>FRCT_LINUX_RTT_ESTIMATOR</code>, default ON) or RFC 6298 symmetric EWMA
(compile option). <code>srtt</code> is floored at 10 ms when seeded from a
hint, at 1 us after every update (including the first seeding
sample); <code>mdev</code> floored at 100 ns.

:<code>RTO = max(rto_min, 2 * srtt, srtt + (mdev << MDEV_MUL))</code>

(the <code>2 * srtt</code> floor is an FRCT addition not in RFC 6298).
Effective wheel deadline capped per [[#3. Protocol parameters|Section 3]].

ACK-derived samples (<code>frcti_ack_rcv</code> -> <code>rtt_sample_eligible</code>), beyond
the cum-ACK advance gate in <code>frcti_ack_rcv</code> (<code>ackno > lwe</code> and
<code>ackno <= seqno</code>), require all of: not in recovery; ACK packet does
not carry <code>FRCT_RXM</code>; HoL slot's <code>SND_RTX</code> bit clear; slot's <code>rxm</code>
pointer non-NULL (not SACK-consumed); <code>lwe</code> not below the <code>rtt_lwe</code>
fence; <code>srtt</code> already seeded by an RTTP probe. There is no ACK-only
seeding.

Every eligible sample also feeds <code>RACK.min_RTT</code> (RFC 8985 sec. 6.2)
via a windowed minimum: replace whenever the sample is strictly
smaller OR more than <code>MIN_RTT_WIN_NS</code> (5 min, matches Linux
<code>tcp_min_rtt_wlen</code>) has elapsed since the current min was set. The
downward branch is immediate (faster path picked up at once); the
upward branch is gated on the window (a transient queue burst does
not poison the estimate, but a sustained route change to a longer
path re-anchors <code>min_RTT</code> after at most one window). Seeded from
<code>rtt_hint</code> at <code>rtt_init</code>; 0 acts as the unset sentinel and the base
in <code>rack_reorder_window</code> falls back from <code>min_RTT</code> to <code>SRTT</code> (so
<code>R = mult * SRTT/4</code>, capped at <code>SRTT</code>, floored at <code>MIN_REORDER_NS</code>)
until the first sample. See [[#6.2. Locked main path|Section 6.2]].

== 13. Liveness (keepalive) ==

When <code>qs.timeout > 0</code> a per-flow KA (keepalive) timer is armed.
Arming uses <code>rcv_cr.act</code> for the deadline computation:

:<code>deadline = min(snd_act + qs.timeout/4, rcv_act + qs.timeout)</code>

(clamped to <code>now + qs.timeout/4</code> if already past). The timer fires
either on sender idleness (to send a KA) or on receiver idleness
(to declare the peer dead). On fire (<code>ka_snd</code>) the peer-dead test
uses <code>max(rcv_cr.act, t_ka_rcv)</code> so a recent KA reply counts even
when no DATA has arrived:

* If <code>now - max(rcv_cr.act, t_ka_rcv) > qs.timeout</code>, mark the flow <code>ACL_FLOWPEER</code> and notify the per-process flow-event set (<code>proc.fqset</code>) with <code>FLOW_PEER</code>.
* Else if <code>snd_idle > qs.timeout/4</code>, emit a bare <code>KA | ACK</code> (<code>ackno = rcv_cr.lwe</code>) and re-arm.
* Else just re-arm.

Note: <code>rx_rb</code> and <code>tx_rb</code> are the receive and transmit shared-memory
ring buffers. The r-timer raises <code>ACL_FLOWDOWN</code> on both (route is
broken); keepalive raises <code>ACL_FLOWPEER</code> on <code>rx_rb</code> only and notifies
the flow-event set (peer is silent, writer keeps <code>tx_rb</code> usable) -
distinct ACLs. <code>qs.timeout == 0</code> disables keepalive entirely; a
silent peer crash is then undetected.

== 14. Linger / teardown ==

On <code>flow_dealloc</code>, <code>frcti_dealloc</code> computes a grace timeout

:<code>max(rcv_cr.act + rcv_cr.inact, snd_cr.act + snd_cr.inact) - now</code>

(floored at 0 and converted to seconds) and returns it; <code>flow_dealloc</code>
forwards this to the IRMd as the dealloc grace. The IRMd, not FRCT,
performs the wait. Before computing the timeout, FRCT may emit a
final ACK when <code>rcv_cr.lwe != rcv_cr.seqno</code> (the peer has not been
told the most recent cumulative ACK) AND the rcv side has been
active within <code>t_a</code> (a-timer not aged out).

<code>FRCTFLINGER</code> is honoured only when <code>snd_cr.lwe < edge</code>, where <code>edge =
snd_fin_seqno</code> after FIN has been sent in stream mode and
<code>snd_cr.seqno</code> otherwise (data or FIN still in flight). The drain
itself runs in <code>flow_dealloc</code>'s <code>while (FRCTI_LINGERING)</code> loop, not in
<code>frcti_dealloc</code>.

The fd is single-reader / single-writer (documented in the
manpages). <code>flow_write</code> pumps <code>rx_rb</code> on every call (via
<code>flow_wait_window</code> -> <code>flow_drain_rx_nb</code>) and additionally blocks on
<code>rx_rb</code> when the send window is closed. A pure-writer thread thus
consumes ACKs without a dedicated reader.

== 15. Heritage and adopted techniques ==

Delta-t (Watson, 1981) is the primary heritage; FRCP descends from
the delta-t protocol family via the Recursive InterNetwork
Architecture (RINA; Day, "Patterns in Network Architecture", 2008,
ch. 9). Timer-based connection management
(no SYN/FIN handshake, per-flow state born on first DATA and
reclaimed after <code>t_mpl + a + r</code> of silence), the DRF marker, and the
<code>t_mpl</code> / <code>t_a</code> / <code>t_r</code> timers all come from delta-t. See Watson,
"Timer-Based Mechanisms in Reliable Transport Protocol Connection
Management", Computer Networks 5 (1981).

The unified <code>flow_alloc(name, qos, ...)</code> primitive and its
multi-axis QoS-cube argument ([[#2.2. Service modes (orthogonal axes)|Section 2.2]]) also come from RINA
(Day 2008, ch. 6; Grasa et al., "IRATI: investigating RINA as an
alternative to TCP/IP", Computer Networks 92 (2015)) - reliability,
ordering, CRC presence, and encryption are flow attributes, not
separate sockets or protocols.

The table below summarises additional adopted techniques and their
references.

{| class="wikitable"
! FRCP mechanism !! Heritage !! Reference / note
|-
| Random new <code>seqno</code> on <code>seqno_rotate</code> || TCP ISN || RFC 6528 (Gont & Bellovin, 2012). QUIC PN-space reset (RFC 9000 sec. 12.3) is a structural analogue.
|-
| Cumulative ACK, left-window-edge advance || TCP || RFC 793 / RFC 9293
|-
| Receive window with non-shrink rule || TCP || RFC 793 sec. 3.7 / RFC 9293 sec. 3.8.6; RFC 1122 sec. 4.2.2.16 for the explicit non-shrink prohibition
|-
| Modular <code>seqno</code> arithmetic (<code>before</code>/<code>after</code> helpers) || TCP || RFC 793 sec. 3.3 / RFC 9293 sec. 3.4
|-
| Selective ACK block list || TCP || RFC 2018 (Mathis et al., 1996). Encoded as a typed FRCP packet rather than a TCP option, so framing is closer to QUIC ACK frames. D-SACK (RFC 2883) carried in-band as <code>block[0]</code>; see [[#1.3. SACK payload|Section 1.3]].
|-
| NewReno-careful recovery with <code>recovery_high</code> gate || TCP || RFC 6582 (Henderson et al., 2012); QUIC builds on the same model in RFC 9002 sec. 7.3.2. Cwnd half absent (CC in IPCP).
|-
| RACK reordering window for fast retransmit || TCP || RFC 8985 (Cheng et al., 2021). FRCP <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> with a <code>MIN_REORDER_NS = 250 us</code> floor against <code>srtt</code> collapse; matches RFC 8985 sec. 6.2 and Linux <code>tcp_rack_reo_wnd</code>. DSACK-driven <code>reo_wnd_mult</code> (sec. 6.2 step 4) is adopted; see [[#1.3. SACK payload|Section 1.3]] for the wire encoding. The hybrid RACK-or-<code>DUP_THRESH</code> trigger from RFC 8985 sec. 6.2 step 4 is adopted ([[#8. Retransmission|Section 8]]). QUIC's analogue in RFC 9002 sec. 6.1.2 uses <code>max(srtt, latest_rtt)</code> as the base.
|-
| 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> = 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.
|-
| Delayed ACK with rate suppression || TCP || RFC 813 (Clark, 1982); RFC 1122 sec. 4.2.3.2; RFC 5681 sec. 4.2. Single-deadline coalescing rather than "ack-every-other-segment".
|-
| Zero-window-probe / persist-timer analogue (RDVS) || TCP || RFC 1122 sec. 4.2.2.17 / RFC 9293 sec. 3.8.6.1. RDVS solicits an FC reply, distinct from QUIC <code>DATA_BLOCKED</code> (RFC 9000 sec. 19.12), which is one-way notification. <code>MAX_RDV</code> give-up departs from TCP.
|-
| Multiplexed control on a single PCI || SCTP / QUIC || SCTP chunk bundling (RFC 9260 sec. 6.10); QUIC frame multiplexing (RFC 9000 sec. 12.4). Cleaner fit than TCP's separate-flag-bits design.
|-
| ACK ranges as multiple discontiguous acked blocks || QUIC || QUIC ACK frame (RFC 9000 sec. 19.3). FRCP SACK is conceptually QUIC-frame-shaped even though encoded as absolute <code>[start,end]</code> pairs.
|-
| Nonce-authenticated active RTT / liveness probing (RTTP) || QUIC <code>PATH_CHALLENGE</code> || <code>PATH_CHALLENGE</code> / <code>PATH_RESPONSE</code> (RFC 9000 sec. 8.2, sec. 19.17, sec. 19.18). WebRTC ICE consent-freshness (RFC 7675) is the same pattern. QUIC's nonce is 8 octets; FRCP chooses 16.
|-
| Probing distinct from keepalive || QUIC || KA timer answers "peer alive?", RTTP answers "path measurable?", as in QUIC PING (RFC 9000 sec. 19.2) vs <code>PATH_CHALLENGE</code>.
|-
| Bare KA + ACK keepalive packets || QUIC / SCTP || QUIC PING (RFC 9000 sec. 19.2); SCTP HEARTBEAT / HEARTBEAT-ACK (RFC 9260 sec. 8.3). SCTP HEARTBEAT also carries an opaque echoed blob, structurally similar to FRCP RTTP.
|-
| (<code>FFGM</code>, <code>LFGM</code>) fragment-role bits ([[#7.2. Fragmentation and reassembly|Section 7.2]]) || SCTP || RFC 9260 sec. 3.3.1 DATA chunk B/E bits encode the same four states (<code>B+E=SOLE</code>, <code>B-only=FIRST</code>, neither=<code>MID</code>, <code>E-only=LAST</code>). Each fragment carries its own <code>seqno</code>/TSN and is independently retransmitted.
|-
| Stream byte-offset reassembly (Sections [[#1.5. Stream PCI extension|1.5]], [[#16. Stream-mode flows|16]]) || QUIC || QUIC STREAM frame (RFC 9000 sec. 19.8) uses Offset + Length varints; FRCP uses fixed 32-bit <code>start</code> / <code>end</code>. One stream per flow vs QUIC's many streams multiplexed.
|-
| FIN end-of-stream marker (Sections [[#1.2. Flag bits|1.2]], [[#16. Stream-mode flows|16]]) || TCP / QUIC || TCP FIN flag (RFC 9293 sec. 3.1) closes one half of the byte stream; QUIC STREAM frame FIN bit (RFC 9000 sec. 19.8) does the same per stream with an immutable final-size invariance (RFC 9000 sec. 4.5: the final size is fixed once observed). FRCP's FIN consumes one packet <code>seqno</code> (not one byte of stream space) and is idempotent on the sender side.
|-
| Stream byte-credit flow control ([[#16. Stream-mode flows|Section 16]]) || QUIC || <code>MAX_STREAM_DATA</code> (RFC 9000 sec. 4.1, sec. 19.10). FRCP projects a per-flow byte budget onto the <code>seqno</code>-space <code>rwe</code>. Single stream per flow collapses QUIC's <code>MAX_DATA</code> / <code>MAX_STREAM_DATA</code> distinction.
|-
| Header protection (encrypted seqnos) || QUIC || QUIC RFC 9001 sec. 5.4 applies header protection on top of AEAD to mask the packet number. FRCP's per-flow AEAD wrap ([[#16. Stream-mode flows|Section 16]]) is wider: it encrypts the entire PCI including <code>seqno</code> because the IPCP below already routes, so no destination connection-ID needs to stay in clear (cf. RFC 9000 sec. 5.2).
|-
| Two-bit fragment role polarity || SCTP || The (<code>FFGM</code>, <code>LFGM</code>) pair follows SCTP B/E (begin = 1 / end = 1) rather than IPv4 MF (RFC 791 sec. 3.2), which has the inverse polarity (MF = 1 means NOT last).
|-
| Orthogonal reliability / ordering axes ([[#2.2. Service modes (orthogonal axes)|Section 2.2]]) || SCTP || PR-SCTP (RFC 3758, per-message partial reliability) and SCTP DATA U-bit (RFC 9260 sec. 3.3.1, per-message unordered) are the closest precedents for decoupling reliability from ordering; FRCP sets them per-flow rather than per-message.
|-
| Orthogonal CRC (<code>qs.ber == 0</code>) || UDP-Lite || RFC 3828 (Larzon et al., 2004) lets the sender pick a per-packet Checksum Coverage and the receiver enforce a locally configured minimum (no in-band negotiation; sec. 3.1, sec. 3.3). FRCP gates a full CRC trailer on <code>qs.ber == 0</code> at flow setup. Contrast TCP / SCTP (mandatory checksum) and QUIC (AEAD subsumes CRC).
|-
| Setup-time service negotiation || DCCP / SCTP / QUIC || DCCP Service Codes (RFC 4340 sec. 8.1.2, RFC 5595); SCTP INIT parameters (RFC 9260 sec. 3.3.2); QUIC transport parameters (RFC 9000 sec. 7.4). All negotiate service properties at connection setup; only RINA's QoS cube exposes them as an orthogonal vector.
|}

=== 15.1. Original to FRCP (no clean prior art) ===

* Pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]): receiver-driven nudge exploiting <code>snd_cr.inact > rcv_cr.inact</code>. Closest analogues are SCTP Gap Ack Blocks (RFC 9260 sec. 3.3.4) and DCCP Ack Vector (RFC 4340 sec. 11.4) - both let the receiver describe gaps to the sender, but neither targets the cross-epoch / pre-DRF case.
* <code>MAX_RDV</code> window-probe give-up: neither TCP (persist-timer probes until application or R2 abort, RFC 9293 sec. 3.8.6.1) nor QUIC has an explicit FC-give-up counter. A recursive-network choice: outer layers can drop the flow.
* Skip-past-gap reassembly ([[#7.2. Fragmentation and reassembly|Section 7.2]]): SCTP fragments and reassembles every flow regardless of reliability/ordering, using its own per-stream reassembly queue; QUIC fragments via STREAM offsets. FRCP fragments best-effort flows too, but the receiver drops the broken prefix the moment a later run-start (<code>FIRST</code> or <code>SOLE</code> role) is visible inside the <code>RQ_SIZE</code>-wide reorder ring - no IP-frag-style timeout, no SCTP-style explicit abort. If no later run-start arrives within the ring, <code>frag_run_inspect</code> returns <code>NOT_READY</code> and the partial run keeps its slots; the next inspect retries. The trade-off: a permanently-lost <code>MID</code> in a long isolated run holds slots until either a later <code>FIRST</code>/<code>SOLE</code> appears in the ring or the writer stops, at which point the slots are reclaimed on flow teardown.
* Reassembly deferred to consume time ([[#7.2. Fragmentation and reassembly|Section 7.2]]), message mode only (<code>qos.service == SVC_MESSAGE</code>): SCTP (RFC 9260 sec. 6.9), QUIC (RFC 9000 sec. 2.2), and TCP (RFC 9293) all hold reassembly state at the receive boundary. FRCP message-mode leaves fragments in the shared-memory ring until <code>flow_read</code> pulls and lands the SDU directly in the caller's buffer. Stream mode ([[#16. Stream-mode flows|Section 16]]) uses the standard QUIC-style direct ring placement on receive and does not defer. The optimisation is enabled by the Shared-Memory Subsystem (SSM) packet-buffer ring (see <code>struct ssm_pk_buff</code> at [[#1.1. PCI header|Section 1.1]]); the analogue is OS-level scatter-gather I/O (<code>recvmsg+iovec</code>), not a transport-layer prior art.
* TLP-equivalent tail-loss recovery (RFC 8985 sec. 7; RFC 9002 sec. 6.2): FRCP does not emit an explicit Tail Loss Probe packet, but the same goal is met implicitly by RACK loss detection ([[#8. Retransmission|Section 8]]) firing on a non-advancing cumulative ACK once the head-of-line slot ages past the RACK reorder window <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> - well below <code>RTO = max(2 * SRTT, SRTT + (mdev << MDEV_MUL))</code>. A receiver-driven nudge is also available via the pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]).

=== 15.2. Not adopted ===

* Slow start, congestion window (cwnd), Additive Increase / Multiplicative Decrease (AIMD), NewReno cwnd inflation. Congestion control lives in the IPCP CA policies and is driven by Explicit Congestion Notification (ECN, RFC 3168).
* Nagle / silly-window-syndrome (SWS) avoidance (RFC 896, RFC 1122 sec. 4.2.3.4). (Deferred work, not adopted in the current spec.)
* TCP Timestamps (RFC 7323) / Protection Against Wrapped Sequences (PAWS) - RTT measurement uses RTTP, not per-segment timestamps. A peer-supplied timestamp echoed on every ACK lets a malicious peer drive the <code>srtt</code> estimate arbitrarily low, collapsing the RTO and triggering a self-inflicted retransmit storm. RTTP confines RTT measurement to nonce-authenticated probe round-trips, where a forged echo is rejected before it can reach the estimator.
* ECN (Explicit Congestion Notification) response inside FRCP (consumed by IPCP Congestion Avoidance / CA).
* 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).

== 16. Stream-mode flows ==

When a flow is allocated with <code>qos.service == SVC_STREAM</code> both peers
switch to byte-stream semantics, layered on top of the FRTX reorder
machinery already described in Sections [[#6. Receive path|6]]-[[#8. Retransmission|8]].

=== 16.1. Send ===

The sender splits the caller's octets into chunks of at most
<code>(frag_mtu - base PCI - stream PCI extension)</code> octets (Sections [[#1.1. PCI header|1.1]]
and [[#1.5. Stream PCI extension|1.5]]). Each chunk is one DATA packet with its own <code>seqno</code> and a
<code>[start, end)</code> byte range copied from a monotonic stream counter.
In stream mode <code>FFGM</code> and <code>LFGM</code> are unused and MUST be transmitted as
zero; the per-byte position is carried by the <code>[start, end)</code>
extension instead.

End-of-stream is signalled with a 0-byte DATA packet that has <code>FIN</code>
(bit 12) set, emitted on the FIN triggers listed in [[#1.2. Flag bits|Section 1.2]]
(WR-half close, <code>flow_dealloc</code>, and any other path that yields the
final byte). The sender MUST emit at most one FIN per flow; its
<code>[start, end)</code> MUST equal <code>[final-byte, final-byte)</code> (i.e., empty
interval at the final byte position; final-size invariance,
analogous to QUIC RFC 9000 sec. 4.5). Idempotency is enforced by
an <code>snd_fin_sent</code> guard.

=== 16.2. Receive ===

On arrival the receiver places the payload directly into a per-flow
byte-indexed receive ring of width <code>ring_sz</code> (octets) at the position
indicated by <code>start</code>, with a two-segment <code>memcpy</code> across the ring
boundary if needed. Receipt is recorded in the FRTX reorder
machinery ([[#6.2. Locked main path|Section 6.2]]) augmented with the packet's <code>start</code>, <code>end</code>, and
FIN bit per slot. When a packet's <code>[start, end)</code> front-overlaps
bytes already at or below the byte high-water mark, the overlap is
trimmed before placement so the same byte is never written twice.
After stashing, the receiver advances <code>lwe</code> and the byte high-water
mark across any newly-contiguous prefix. Each slot advanced MUST
satisfy <code>start == the last-delivered slot's end</code>; a slot whose
<code>start</code> does not equal that <code>end</code> is silently dropped at delivery time
(the <code>seqno</code> is consumed, no stream bytes contributed) and the high-
water mark does not advance past it. The stream byte-stream
stalls at that point - there is no flow-tear-down on mismatch.
This filters spliced or off-path-injected slots that fall in
window without strong cryptographic authentication.

A FIN slot marks end-of-stream at advance time only if its byte
position equals the last-delivered slot's <code>end</code>; otherwise the FIN
is ignored and the corresponding <code>seqno</code> occupies a slot but
contributes no stream bytes. No packet buffer is held after the
ring copy.

=== 16.3. Read ===

<code>flow_read</code> returns up to <code>count</code> octets from the contiguous prefix
<code>[next, high-water)</code>, where <code>next</code> is the byte the application has
already consumed up to and <code>high-water</code> is the rightmost contiguous
byte received. When the stream is fully drained AND end-of-stream
(EOS) was observed (<code>next == EOS</code> byte position), <code>flow_read</code> returns
0 (<code>EOF</code>) - the same shape POSIX <code>read(2)</code> uses on TCP after a peer
FIN.

=== 16.4. Flow control ===

ACK / SACK / RACK / RTO machinery is unchanged; the FRTX reorder
ring is reused as a per-<code>seqno</code> received-bitmap. Let <code>per_pkt =
(frag_mtu - base PCI - stream PCI extension)</code>, the maximum stream-
byte payload one DATA packet can carry ([[#16.1. Send|Section 16.1]]). The
receive window advertised in FC is clamped so the byte window
(<code>ring_sz</code>) cannot be overrun: the <code>seqno</code>-space <code>rwe</code> is at most
<code>rcv_cr.lwe + ring_sz / per_pkt</code>.

This is the QUIC byte-credit flow-control model
(<code>MAX_STREAM_DATA</code>, RFC 9000 sec. 4.1 and sec. 19.10) projected onto
<code>seqno</code> space. With one stream per flow there is no <code>MAX_DATA</code> /
<code>MAX_STREAM_DATA</code> distinction. Receiver-side silly-window-syndrome
(SWS) avoidance (RFC 9293 sec. 3.8.6.2.2) is achieved by combining
the consume-time <code>rwe</code> bump with the global non-shrink rule from
[[#11. Flow control|Section 11]].

=== 16.5. Security considerations ===

Threat model. An attacker that can observe (on-path passive) or
predict (off-path blind) the flow's seqnos and byte offsets on an
unencrypted stream flow can inject DATA or FIN at any in-window
position. The in-line consistency checks above (<code>start</code> == prior
<code>end</code> on advance; FIN MUST be 0-byte; FIN MUST sit at the final
byte position) realise the spirit of RFC 5961's "sequence-window
plus exact-position match for control bits" without an explicit
challenge-ACK probe; they make a few specific blind attack shapes
harder but are not cryptographic authentication. This is
comparable to TCP without the TCP Authentication Option (TCP-AO,
RFC 5925), tighter than a
pre-RFC-5961 TCP stack, and roughly equivalent to a modern
RFC 5961 stack against blind off-path injection - none of these
help once the attacker can sniff. TLS over TCP (RFC 8446)
encrypts only the TCP payload and leaves TCP seqnos, ACKs, FIN,
and RST in the clear, so TLS does NOT defend against TCP-header-
level injection; QUIC (RFC 9000) hides packet numbers under
header protection (RFC 9001 sec. 5.4), so this specific weakness
does not apply to QUIC.

Mitigation: AEAD. When the flow has encryption enabled the
recommended AEAD ciphers (AES-GCM, RFC 5288; or ChaCha20-Poly1305,
RFC 8439) wrap the entire FRCP packet on the wire - PCI, stream
extension, body, and the CRC trailer when <code>ber == 0</code> - under a
per-flow symmetric key derived from the flow's own key exchange
([[#1.1. PCI header|Section 1.1]]). The AEAD tag (~2^-128 forgery probability)
dominates the CRC (~2^-32) for integrity in this mode but the CRC
trailer is currently retained inside the wrap (see [[#1.1. PCI header|Section 1.1]]).
Implementations MUST NOT rely on the security properties below
when a non-AEAD cipher (e.g. AES-CTR alone) is negotiated; non-
AEAD modes provide confidentiality only and the threat-model
claims do not hold.

With an AEAD cipher in use, seqnos, byte offsets, and the FIN bit
are both authenticated and confidential. Against an off-path or
on-path-passive attacker this is:

* Stronger than TCP+TLS (TCP header in the clear).
* Stronger than TCP+TCP-AO (header authenticated but visible).
* 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. 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 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
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.

== 17. References ==

This section lists the IETF documents, published works, and
source-code references cited inline elsewhere in this document.
IETF documents are cited inline as "RFC NNNN sec. X.Y"; books,
journal papers, and source-code references are cited inline by
author and year (or by file and function name) and are listed
here for convenience.

=== 17.1. IETF documents ===

;[RFC 791]
:J. Postel, "Internet Protocol", STD 5, RFC 791, September 1981.
;[RFC 793]
:J. Postel, "Transmission Control Protocol", STD 7, RFC 793, September 1981. Obsoleted by RFC 9293.
;[RFC 813]
:D. D. Clark, "Window and Acknowledgement Strategy in TCP", RFC 813, July 1982.
;[RFC 896]
:J. Nagle, "Congestion Control in IP/TCP Internetworks", RFC 896, January 1984.
;[RFC 1122]
:R. Braden (ed.), "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
;[RFC 2018]
:M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
;[RFC 2119]
:S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
;[RFC 2883]
:S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
;[RFC 3758]
:R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
;[RFC 3828]
:L-A. Larzon, M. Degermark, S. Pink, L-E. Jonsson (ed.), G. Fairhurst (ed.), "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
;[RFC 4303]
:S. Kent, "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
;[RFC 4340]
:E. Kohler, M. Handley, S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
;[RFC 5288]
:J. Salowey, A. Choudhury, D. McGrew, "AES Galois Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, August 2008.
;[RFC 5595]
:G. Fairhurst, "The Datagram Congestion Control Protocol (DCCP) Service Codes", RFC 5595, September 2009.
;[RFC 5681]
:M. Allman, V. Paxson, E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
;[RFC 5925]
:J. Touch, A. Mankin, R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
;[RFC 5961]
:A. Ramaiah, R. Stewart, M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, August 2010.
;[RFC 6298]
:V. Paxson, M. Allman, J. Chu, M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, June 2011.
;[RFC 6528]
:F. Gont, S. Bellovin, "Defending against Sequence Number Attacks", RFC 6528, February 2012. Obsoletes RFC 1948.
;[RFC 6582]
:T. Henderson, S. Floyd, A. Gurtov, Y. Nishida, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 6582, April 2012.
;[RFC 7323]
:D. Borman, B. Braden, V. Jacobson, R. Scheffenegger (ed.), "TCP Extensions for High Performance", RFC 7323, September 2014.
;[RFC 7675]
:M. Perumal, D. Wing, R. Ravindranath, T. Reddy, M. Thomson, "Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness", RFC 7675, October 2015.
;[RFC 8174]
:B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017.
;[RFC 8200]
:S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, July 2017.
;[RFC 8439]
:Y. Nir, A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 8439, June 2018.
;[RFC 8446]
:E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, August 2018.
;[RFC 8985]
:Y. Cheng, N. Cardwell, N. Dukkipati, P. Jha, "The RACK-TLP Loss Detection Algorithm for TCP", RFC 8985, February 2021.
;[RFC 9000]
:J. Iyengar (ed.), M. Thomson (ed.), "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, May 2021.
;[RFC 9001]
:M. Thomson (ed.), S. Turner (ed.), "Using TLS to Secure QUIC", RFC 9001, May 2021.
;[RFC 9002]
:J. Iyengar (ed.), I. Swett (ed.), "QUIC Loss Detection and Congestion Control", RFC 9002, May 2021.
;[RFC 9147]
:E. Rescorla, H. Tschofenig, N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, April 2022.
;[RFC 9260]
:R. Stewart, M. Tuexen, K. Nielsen, "Stream Control Transmission Protocol", RFC 9260, June 2022. Obsoletes RFC 4960.
;[RFC 9293]
:W. Eddy (ed.), "Transmission Control Protocol (TCP)", STD 7, RFC 9293, August 2022. Obsoletes RFC 793 and several follow-ons; updates RFC 1122 and others.

=== 17.2. Books and journal papers ===

;[Day08]
:J. Day, "Patterns in Network Architecture: A Return to Fundamentals", Prentice Hall, 2008.
;[Grasa15]
:E. Grasa et al., "IRATI: investigating RINA as an alternative to TCP/IP", Computer Networks, Vol. 92, December 2015.
;[KP87]
:P. Karn, C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", ACM SIGCOMM, August 1987.
;[Wat81]
:R. W. Watson, "Timer-Based Mechanisms in Reliable Transport Protocol Connection Management", Computer Networks, Vol. 5, 1981.

=== 17.3. Source-code references ===

;[Linux-RTT]
:<code>tcp_rtt_estimator()</code> in <code>net/ipv4/tcp_input.c</code> of the Linux kernel, defining the asymmetric <code>mdev</code> variance update used as FRCP's default RTT estimator ([[#12. RTT estimation|Section 12]]). Line-stable browseable copy at https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_input.c.

[[Category:Protocols]]
[[Category:Ouroboros internals]]

Flow and Retransmission Control Protocol

2026-05-17T14:59:41Z

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

{{DISPLAYTITLE:FRCP - Flow and Retransmission Control Protocol}}

FRCP runs end-to-end between two peers over a flow. It delivers
reliability, in-order delivery, flow control, and liveness.
Congestion Control (CC) is not in FRCP - that lives in the IPC
Process (IPCP) Congestion Avoidance (CA) policies, orthogonal to
FRCP. Flow allocation, naming, and IPCP lifecycle are handled by
the IPC Resource Manager daemon (IRMd).

FRCT (Flow and Retransmission Control Task) is the libouroboros
implementation of FRCP; the task lives in <code>src/lib/frct.c</code>. The
remainder of this document describes the FRCP wire protocol and the
behaviour FRCT realises. Code symbols retain the <code>FRCT_</code> prefix
(<code>FRCT_DATA</code>, <code>FRCT_RXM</code>, ...) because they belong to the implementing
task; this document references them verbatim.

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in <code>BCP</code> 14 (Best
Current Practice; RFC 2119, RFC 8174) when, and only when, they
appear in all capitals.

== Notation ==

;<code>u32</code>, <code>u8</code>
:Unsigned 32-bit / 8-bit integers (kernel-C style).
;<code>ns</code>
:Nanoseconds.

Modular sequence-number comparators (32-bit, modulo 2^32):

;<code>before(a, b)</code>
:<code>(int32_t)(a - b) < 0</code>
;<code>after(a, b)</code>
:<code>before(b, a)</code>

Used throughout for <code>ackno</code> / <code>seqno</code> ordering checks.

Round-Trip Time (RTT) abbreviations used throughout:

;<code>SRTT</code>
:Smoothed RTT estimate (RFC 6298).
;<code>mdev</code>
:Mean deviation of RTT (Linux variance estimator).
;<code>EWMA</code>
:Exponentially Weighted Moving Average.
;<code>RTO</code>
:Retransmission Timeout, <code>max(RTO_MIN, srtt + (mdev << MDEV_MUL))</code>.

Timer-bound symbols <code>t_a</code> (a-timer, ACK delay) and <code>t_r</code> (r-timer,
retransmission window) are defined in [[#8. Retransmission|Section 8]]; <code>t_mpl</code> (Maximum
Packet Lifetime) is introduced in [[#2.1. Per-flow state|Section 2.1]] (the <code>inact</code> field)
with heritage in [[#15. Heritage and adopted techniques|Section 15]].

Wire-format diagrams follow the IETF convention: bit 0 is the
leftmost (most significant) bit and fields are in network byte
order unless stated otherwise.

__TOC__

== 1. Wire format ==

=== 1.1. PCI header ===

Fixed 16-octet base Protocol-Control Information (PCI) header
prefixed to every FRCP packet (RFC convention: bit 0 leftmost,
most-significant bit first). All multi-byte fields except <code>hcs</code>
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
[[#1.5. Stream PCI extension|Section 1.5]]); SACK and RTTP carry their own payloads after the
base PCI.

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | hcs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ackno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload (variable) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>flags</code>
:feature/type bitmap (see [[#1.2. Flag bits|Section 1.2]]).
;<code>hcs</code>
:CRC-16-CCITT-FALSE Header Check Sequence (HCS) over <code>flags</code> + <code>window</code> + <code>seqno</code> + <code>ackno</code> (+ stream extension when present); the two octets of the <code>hcs</code> field itself are omitted from the CRC input. Verified on receive before any flag-driven dispatch.
;<code>window</code>
:receiver-advertised right window edge (valid iff FC).
;<code>seqno</code>
:per-flow sequence number.
;<code>ackno</code>
:cumulative Acknowledgement (ACK) (valid iff ACK).

A single packet can simultaneously carry DATA + ACK + FC (Flow
Control) + RXM (Retransmission) by ORing flag bits; the PCI
multiplexes control on the same wire frame in the spirit of SCTP
chunk bundling (RFC 9260 sec. 6.10) and QUIC frame multiplexing
(RFC 9000 sec. 12.4). DATA-bearing packets carry the caller's
payload after the PCI; SACK (Selective Acknowledgement) and RTTP
(Round-Trip Time Probe) carry their own typed payloads after the
PCI.

Optional framing (per-flow, see [[#2.2. Service modes (orthogonal axes)|Section 2.2]]). On the wire, the
order from inside out is:

{| class="wikitable"
! Layer !! Scope
|-
| <code>[ PCI + body ]</code>
| The FRCP packet.
|-
| <code>[ PCI + body + CRC-32 ]</code>
| CRC-32 covers the body only (PCI is in HCS); appended iff <code>qs.ber == 0</code> on DATA, or on every SACK packet.
|-
| <code>[ AEAD-wrap of above ]</code>
| Iff Authenticated Encryption with Associated Data (AEAD) is enabled.
|}

* 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.
* 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>).

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

=== 1.2. Flag bits ===

Flag bits are numbered most-significant-bit first to match the wire
diagram (bit numbering per [[#1.1. PCI header|Section 1.1]]; bit 0 is the MSB of the
16-bit <code>flags</code> field and lands at wire-position 0 in network byte
order). Bits 13..15 are reserved and MUST be transmitted as zero.

{| class="wikitable"
! Bit !! Mask !! Name !! Meaning
|-
| 0 || <code>0x8000</code> || <code>DATA</code> || Carries caller payload
|-
| 1 || <code>0x4000</code> || <code>DRF</code> || Data Run Flag: start of a fresh run
|-
| 2 || <code>0x2000</code> || <code>ACK</code> || Acknowledgement: <code>ackno</code> field valid
|-
| 3 || <code>0x1000</code> || <code>NACK</code> || Negative ACK; <code>seqno = arrival_seqno-1</code>
|-
| 4 || <code>0x0800</code> || <code>FC</code> || Flow Control: <code>window</code> field valid (<code>rwe</code>)
|-
| 5 || <code>0x0400</code> || <code>RDVS</code> || Rendezvous probe (window-closed)
|-
| 6 || <code>0x0200</code> || <code>FFGM</code> || First Fragment (role bit 0; see below)
|-
| 7 || <code>0x0100</code> || <code>LFGM</code> || Last Fragment (role bit 1; see below)
|-
| 8 || <code>0x0080</code> || <code>RXM</code> || Retransmission
|-
| 9 || <code>0x0040</code> || <code>SACK</code> || Selective ACK block list in payload
|-
| 10 || <code>0x0020</code> || <code>RTTP</code> || RTT Probe / echo (payload follows)
|-
| 11 || <code>0x0010</code> || <code>KA</code> || Keepalive
|-
| 12 || <code>0x0008</code> || <code>FIN</code> || End-of-stream marker (stream mode)
|-
| 13-15 || -- || -- || Reserved (MUST be zero)
|}

The (<code>FFGM</code>, <code>LFGM</code>) pair encodes the fragment role of a DATA-bearing
Service Data Unit (SDU), SCTP-style begin/end flags (RFC 9260
sec. 3.3.1):

{| class="wikitable"
! FFGM !! LFGM !! Role
|-
| 1 || 1 || Sole / un-fragmented SDU (begin AND end)
|-
| 1 || 0 || First fragment of a multi-fragment SDU
|-
| 0 || 0 || Middle fragment
|-
| 0 || 1 || Last fragment
|}

Each fragment is carried in its own FRCP packet with its own <code>seqno</code>;
FRTX (the FRCT Retransmission service mode, see [[#2.2. Service modes (orthogonal axes)|Section 2.2]])
recovers individual fragments via the normal Retransmission Timeout
(RTO) / SACK / Recent Acknowledgement (RACK, RFC 8985) path. The
receiver reassembles the SDU at consume time once the contiguous
[FIRST .. LAST] run has fully arrived. On non-DATA packets the role
bits are unused and MUST be transmitted as zero.

In stream mode (<code>qos.service == SVC_STREAM</code>, see [[#16. Stream-mode flows|Section 16]]) there are
no SDU boundaries to encode, so <code>FFGM</code> and <code>LFGM</code> are unused and MUST
be transmitted as zero. End-of-stream uses a dedicated bit (<code>FIN</code>,
bit 12) carried on a 0-byte DATA packet, emitted at write-half close
(<code>fccntl</code> to <code>FLOWFRDONLY</code>), during linger drain, and at <code>flow_dealloc</code>;
emission is idempotent (first call wins). After contiguous delivery
of the FIN-bearing slot, the receiver latches <code>byte_fin</code> at the FIN's
start offset; <code>flow_read</code> returns 0 (end-of-file, <code>EOF</code>) once buffered
bytes have been drained up to <code>byte_fin</code>. Per-byte position is
carried by the [start, end) extension ([[#1.5. Stream PCI extension|Section 1.5]]).

=== 1.3. SACK payload ===

A SACK packet has the <code>FRCT_ACK | FRCT_FC | FRCT_SACK</code> flag bits set
(bit numbering per [[#1.1. PCI header|Section 1.1]]). Following the 16-octet PCI, the
payload is a 2-octet block count (network byte order), 2 octets of
padding to 4-byte align the block list, then <code>n_blocks</code> pairs of
32-bit start/end seqnos describing ''present'' (received) ranges
above the cumulative ACK.

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_blocks | padding (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start[0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end[0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... n_blocks pairs total ...
</syntaxhighlight>

<code>n_blocks <= SACK_MAX_BLOCKS</code> (2048). The per-flow effective cap is
further bounded by <code>(frag_mtu - PCI - 4) / 8</code> blocks per packet; SACK
packets carry no stream extension, so PCI here is the 16-octet base
header even on stream-mode flows.

Wire invariant: every block produced by the receiver, except an
optional leading Duplicate SACK (D-SACK) block as described below,
describes a range strictly above the cumulative ACK carried in the
PCI <code>ackno</code> field (<code>after(start[i], ackno)</code>). This makes the D-SACK
convention below unambiguous; the receiver-side builder MUST
preserve it.

Duplicate SACK (D-SACK, RFC 2883) is signalled in-band: no flag
bit, no extra framing. Modular seqno arithmetic uses the
<code>before()</code> / <code>after()</code> comparators defined in the Notation block.
<code>Block[0]</code> carries a D-SACK report when either:

;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.
;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.

Senders that do not implement D-SACK process <code>block[0]</code> through the
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
(cap 20), halve once per 16 cumulatively-ACK'd seqnos since the
most recent D-SACK arrival or halve event, reset to 1 on an RTO
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
count as gaps.

=== 1.4. RTTP payload ===

An RTTP (Round-Trip Time Probe) packet has only the <code>FRCT_RTTP</code> flag
set (bit numbering per [[#1.1. PCI header|Section 1.1]]). Following the 16-octet PCI,
the payload is 24 octets (packed):

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| probe_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| echo_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ nonce (16 octets, echoed verbatim) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>probe_id</code>
:sender counter, 0 on reply, 0 reserved.
;<code>echo_id</code>
:peer's <code>probe_id</code>, 0 on outbound probe.
;<code>nonce</code>
:random, echoed unmodified, memcmp'd to defeat spoof.

=== 1.5. Stream PCI extension ===

A stream-mode flow (<code>qos.service == SVC_STREAM</code>) carries an extra
8-octet extension after the 16-octet base PCI on every DATA packet
(bit numbering per [[#1.1. PCI header|Section 1.1]]):

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>start</code>
:octet offset of the first payload byte in the stream.
;<code>end</code>
:octet offset one past the last payload byte; <code>end - start</code> equals the on-wire payload length.

Total stream-mode PCI for DATA packets is 24 octets (16 base + 8
extension); control packets (SACK, RTTP, bare ACK, KA, etc.) retain
the 16-octet base PCI. Stream mode MUST be negotiated at flow
allocation; the extension is present iff stream mode is in use,
never on a per-packet basis. Both peers MUST treat <code>start</code>/<code>end</code> as
monotonic 32-bit byte offsets; when a slot reaches the head of the
contiguous run with <code>start</code> not equal to the prior packet's <code>end</code> the
slot is silently dropped at delivery time ([[#16. Stream-mode flows|Section 16]]) rather
than rejected at stash.

This is the QUIC STREAM-frame reassembly model (RFC 9000 sec. 19.8):
each packet carries its packet <code>seqno</code> (this PCI's <code>seqno</code> field) and a
separate stream byte position (<code>start</code>/<code>end</code>). Separating the two
avoids TCP's conflation of packet identity with byte position which
forces Karn's algorithm for Round-Trip Time (RTT) sampling (no RTT
sample on retransmits, RFC 6298 sec. 3); FRCP applies the
Karn-equivalent gate via a combination of per-packet <code>FRCT_RXM</code>,
per-slot <code>SND_RTX</code> flags, and a sample-fence <code>rtt_lwe</code> (see [[#2.1. Per-flow state|Section 2.1]]
and [[#12. RTT estimation|Section 12]]). FRCP's fixed-32-bit <code>start</code>/<code>end</code> wrap at 4 GiB of
wire bytes, narrower than QUIC's 62-bit varint offset (cf. RFC 9000
sec. 16); the on-wire wrap is handled by the same modular <code>before()</code>
/ <code>after()</code> comparators ([[#1.3. SACK payload|Section 1.3]]) FRCP uses for seqnos, which
remain unambiguous as long as the in-flight byte window stays
strictly under 2 GiB (the half-range of the signed-int32 difference
in <code>before()</code>). The default per-flow ring is 1 MiB; the
implementation caps <code>ring_sz</code> at 128 MiB (<code>FRCT_STREAM_RING_SZ_MAX</code>),
well below the 2 GiB half-range bound. The runtime byte counters
exposed via FUSE (Filesystem in Userspace) in the Ouroboros
Resource Information Base (RIB, a virtual-filesystem introspection
bridge) are platform <code>size_t</code> and do not wrap on 64-bit hosts.

== 2. Per-flow state and service modes ==

=== 2.1. Per-flow state ===

Each flow keeps a sender control record and a receiver control
record:

;<code>lwe</code> : <code>u32</code>
:snd: oldest unacked <code>seqno</code> (cumulative ACK boundary as seen by sender); rcv: next in-order <code>seqno</code> expected
;<code>rwe</code> : <code>u32</code>
:snd: peer-advertised right window edge; rcv: locally-advertised right window edge
;<code>cflags</code> : <code>u8</code>
:per-direction feature flags: retransmission (<code>FRCTFRTX</code>), receiver flow control (<code>FRCTFRESCNTL</code>), linger-on-close (<code>FRCTFLINGER</code>); see <code><ouroboros/fccntl.h></code>
;<code>seqno</code> : <code>u32</code>
:snd: next <code>seqno</code> to send; rcv: force-ACK trigger - set on a stale or dup DATA so the next <code>ack_snd</code> emits a fresh cumulative ACK
;<code>ackno</code> : <code>u32</code>
:snd: <code>seqno</code> counter for standalone ACK-bearing control packets (delayed ACK, SACK, final ACK on dealloc); not bumped on piggybacked ACK riding a DATA packet (which uses the DATA <code>seqno</code>). Used by wire-dup ACK detection; rcv: incoming-ACK dedup tracker
;<code>act</code> : <code>ns</code>
:last activity (used by inactivity / DRF)
;<code>inact</code> : <code>ns</code>
:inactivity threshold; sender = <code>3*mpl + a + r + 1s</code>, receiver = <code>2*mpl + a + r + 1s</code>. <code>mpl</code> is the Maximum Packet Lifetime (delta-t terminology; see [[#15. Heritage and adopted techniques|Section 15]]); <code>a</code> and <code>r</code> are the FRCT a-timer and r-timer bounds (see [[#8. Retransmission|Section 8]]). The asymmetry is load-bearing for pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]).

The sender holds a per-slot ring <code>snd_slots[RQ_SIZE]</code> keyed by
<code>(seqno mod RQ_SIZE)</code>. Each slot tracks its retransmit entry (<code>rxm</code>),
last-send timestamp, and retransmit flag bits: <code>SND_RTX</code> (a
retransmit is pending or has fired, gates the next RTT sample
under Karn) and <code>SND_FAST_RXM</code> (one-shot fast-retransmit staged for
this loss event).

The receiver holds a parallel reorder ring <code>rcv_slots[RQ_SIZE]</code>
(referred to as <code>rq[]</code> in prose) holding stashed out-of-order
packet-buffer indexes; both FRTX and best-effort flows share this
path. The invariant <code>rwe - lwe <= RQ_SIZE</code> holds: on each consume
the receiver advances <code>rwe</code> by the consumed count, capping the
receive window at <code>RQ_SIZE</code> <code>seqno</code> slots.

A separate fence variable <code>rtt_lwe</code> is bumped on every retransmit
(timer-fire, SACK-driven, fast-rxm, NACK-driven) and on every
<code>seqno_rotate</code> ([[#4. Sequence-number rotation (DRF)|Section 4]]) to mark the <code>seqno</code> range whose RTT samples
MUST be discarded.

=== 2.2. Service modes (orthogonal axes) ===

FRCP exposes its wire features as a vector of independent QoS
axes selected at flow allocation time. All flows go through the
same <code>flow_alloc(name, qos, ...)</code> primitive; the <code>qosspec_t</code> passed
in determines which protocol machinery engages on the wire. This
contrasts with the POSIX BSD socket model where TCP and UDP
require different socket types (<code>SOCK_STREAM</code> / <code>SOCK_DGRAM</code>).

The axes:

;<code>service</code>
:0 = unordered (no FRCP engagement: raw datagrams, no PCI on the wire, UDP-equivalent at this layer); 1 = message-ordered (FRCP engaged; SDU boundaries preserved across fragmentation); 2 = stream (byte-oriented, no SDU boundaries; FRTX required)
;<code>loss</code>
:0 = lossless service requested: FRTX retransmit machinery engages ([[#8. Retransmission|Section 8]]); MUST be 0 for <code>service=2</code>. Non-zero = best-effort, FRTX off.
;<code>ber</code>
:Bit Error Rate tolerance. 0 = error-free service requested: a CRC trailer is appended after the body of DATA packets and verified on receive (added / checked outside the FRCP PCI; see [[#1.1. PCI header|Section 1.1]]). Non-zero = peer accepts errors; trailer omitted. SACK control packets carry a CRC32 trailer regardless of <code>ber</code>; the <code>ber</code> gate applies to DATA only.
;<code>timeout</code>
:Peer-timeout (ms); 0 disables the keepalive timer. Independent of FRCP engagement.

Encryption is a separate per-flow attribute set at flow setup;
when enabled it wraps the FRCP packet (PCI + body, plus the CRC
trailer if any) under AEAD, expanding the <code>spb</code> by <code>headsz</code> + <code>tailsz</code>
octets (nonce / tag). The CRC trailer is currently kept inside
the AEAD wrap (see [[#1.1. PCI header|Section 1.1]]).

Reachable combinations exported by <code>include/ouroboros/qos.h</code>:

{| class="wikitable"
! Cube !! <code>service</code> !! <code>loss</code> !! <code>ber</code> !! Engaged
|-
| <code>qos_raw</code> || 0 || 1 || 1 || Raw passthrough
|-
| <code>qos_raw_safe</code> || 0 || 1 || 0 || Raw + CRC trailer
|-
| <code>qos_rt</code> || 1 || 1 || 1 || FRCP, no FRTX, no CRC
|-
| <code>qos_rt_safe</code> || 1 || 1 || 0 || FRCP, no FRTX, CRC
|-
| <code>qos_msg</code> || 1 || 0 || 0 || FRCP + FRTX
|-
| <code>qos_stream</code> || 2 || 0 || 0 || FRCP + FRTX, stream
|}

Forced couplings actually enforced by the public API:

* <code>service == SVC_STREAM</code> (2) requires <code>loss == 0</code>; <code>flow_alloc</code> / <code>flow_accept</code> reject the pair otherwise with <code>-EINVAL</code>.
* FRTX requires FRCP engagement (<code>service != SVC_RAW</code>); requesting <code>loss = 0</code> with <code>service = SVC_RAW</code> is structurally a no-op because no <code>frcti</code> is created.
* The <code>QOS_DISABLE_CRC</code> build flag globally forces <code>ber = 1</code>. Note: this flag defaults to ON, so default builds ship with CRC disabled until <code>QOS_DISABLE_CRC</code> is set to OFF.

Caveat: the API does NOT force <code>ber = 0</code> when <code>service != SVC_RAW</code>.
<code>qos_rt</code> has <code>service = SVC_MESSAGE</code> with <code>ber = 1</code>, which means the PCI
itself is not CRC-protected on that cube; the HCS ([[#1.1. PCI header|Section 1.1]])
remains the only integrity check on the header.

The FRCP-no-FRTX regime (<code>service = SVC_MESSAGE</code>, <code>loss > 0</code>) is meaningful
and live: sequence numbering, in-order delivery, flow-control
advertisement, KA, DRF rotation, and SDU fragmentation /
reassembly ([[#7.2. Fragmentation and reassembly|Section 7.2]]) all run. Lost packets are dropped
rather than retransmitted; a permanently-lost mid-fragment is
dropped via skip-past-gap once a later SDU is visible in the
reorder ring.

== 3. Protocol parameters ==

{| class="wikitable"
! Parameter !! Value !! Role
|-
| <code>RQ_SIZE</code> || compile-time, power of 2 (default 128) || Slot ring / rcv window width
|-
| <code>START_WINDOW</code> || compile-time, power of 2 (default 128) || Initial <code>rwe-lwe</code> after rotate
|-
| <code>RTO_MIN</code> || <code>MAX(250 us build-tunable, 1<<RXMQ_RES)</code>; per-flow via <code>fccntl</code> (<code>FRCTSRTOMIN</code>). Default ~1 ms with <code>RXMQ_RES=20</code>. || RTO floor; also floored at the retransmit-wheel resolution (~1 ms by default).
|-
| <code>MAX_RTO_MUL</code> || 20 || Backoff shift cap
|-
| RACK window <code>R</code> || <code>MIN(reo_wnd_mult * min_RTT/4, SRTT)</code> with <code>MIN_REORDER_NS = 250 us</code> floor; <code>reo_wnd_mult</code> scales on D-SACK, cap 20 || Reorder window; per RFC 8985 sec. 6.2; <code>reo_wnd_mult</code> per sec. 6.2 step 4
|-
| <code>MIN_RTT_WIN_NS</code> || 300 s (5 min, Linux <code>tcp_min_rtt_wlen</code>) || <code>min_RTT</code> windowed re-anchor
|-
| <code>REO_WND_MULT_MAX</code> || 20 (RFC 8985 sec. 6.2 step 4) || <code>reo_wnd_mult</code> cap
|-
| <code>REO_DECAY_PKTS</code> || 16 (RFC 8985 sec. 6.2 step 4 / <code>RACK.reo_wnd_persist</code>) || Fresh-ACK'd seq count per halving
|-
| <code>MAX_DSACK_LAG</code> || <code>RQ_SIZE</code> || D-SACK sanity cap
|-
| <code>RTT_QUARANTINE</code> || 32 (<code>seqno</code> steps) || NewReno gate pad
|-
| SACK rate-limit || <code>SACK_MIN_GAP_NS</code> (250 us, fixed) || Min SACK gap
|-
| <code>SACK_MAX_BLOCKS</code> || 2048 (wire cap; per-flow capped at <code>(frag_mtu-PCI-4)/8</code>) || Per-SACK block cap
|-
| <code>SACK_RXM_MAX</code> || 32 || Per-pass staged retransmit cap
|-
| <code>DUP_THRESH</code> || 3 (RFC 8985 default) || Hybrid fast-rxm trigger ([[#8. Retransmission|Section 8]])
|-
| <code>MDEV_MUL</code> || 2 (build-tunable via <code>FRCT_RTO_MDEV_MULTIPLIER</code>) || <code>mdev</code> shift in <code>RTO = srtt + (mdev << MDEV_MUL)</code>
|-
| RTTP nonce || 16 octets || Echoed verbatim
|-
| <code>RTTP_RING</code> || 8 || In-flight probes
|-
| RTT clamp || <code>16 * srtt</code> || Probe-sample upper bound (ACK-derived RTT samples gated by Karn / recovery only)
|-
| Cold-probe cadence || 100 ms (rx-driven; see [[#12. RTT estimation|Section 12]]) || Pre-<code>srtt</code> RTTP rate
|-
| <code>DELT_RDV</code> || 100 ms || RDVS emit cadence
|-
| <code>MAX_RDV</code> || 1 s || RDVS give-up
|-
| Delayed-ACK fire || <code>2 * TICTIME</code> (<code>TICTIME</code> = FRCT tick granularity, default 5 ms; <code>2*TICTIME = 10 ms</code> by default) || Fired after the first in-order DATA arrival; tick is build-tunable
|-
| NACK send cooldown || <code>srtt</code> when an <code>srtt</code> sample exists, else 100 ms || Pre-DRF NACK rate-limit
|-
| <code>MAX_SDU</code> || 1 MiB || Max reassembled SDU; configurable per flow
|}

The per-flow fragment Maximum Transmission Unit (MTU) is computed
at flow setup from the lower IPCP's mtu minus encryption
<code>headsz</code> / <code>tailsz</code> and CRC trailer; there is no FRCT-level default or
environment-variable override.

== 4. Sequence-number rotation (DRF) ==

The DRF (Data Run Flag) bit on an outbound packet means "this is
the start of a fresh data run" and is set whenever the sender has
nothing in flight (<code>snd_cr.seqno == snd_cr.lwe</code>).

Independently of that, if the sender has been idle longer than
<code>snd_cr.inact</code> AND the pipe is empty (<code>snd_cr.seqno == snd_cr.lwe</code>),
<code>seqno_rotate()</code> rolls a random new <code>seqno</code> before the send and
resets

<syntaxhighlight lang="text">
snd_cr.seqno = random()
snd_cr.lwe = snd_cr.seqno
snd_cr.rwe = snd_cr.seqno + START_WINDOW
rtt_lwe = snd_cr.seqno
in_recovery = false (recovery state, see Section 8)
recovery_high = snd_cr.seqno
</syntaxhighlight>

The receiver, on observing rcv-side inactivity
(<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
below). Non-DATA control packets pass through without the DRF
requirement. On DRF the receiver releases the <code>rq[]</code> slots and
rebases

<syntaxhighlight lang="text">
rcv_cr.lwe = seqno
rcv_cr.rwe = seqno + RQ_SIZE
rcv_cr.seqno = seqno
</syntaxhighlight>

If the inactive packet has DATA but no DRF, a rate-limited NACK is
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).

== 5. Send path ==

# If the SDU exceeds <code>(frag_mtu - data_hdr_len)</code>, the caller (<code>dev.c</code>) fans it out into <code>ceil(count / (frag_mtu - data_hdr_len))</code> fragments, each emitted via <code>frcti_snd</code> as its own DATA packet with a per-fragment role ([[#7.2. Fragmentation and reassembly|Section 7.2]]); both FRTX and best-effort flows fragment. Raw flows (no FRCP engagement, <code>qos.service == SVC_RAW</code>) carry no PCI and return <code>-EMSGSIZE</code> for any SDU larger than one packet at the layer below. An SDU that fits in a single packet is sent as SOLE. <code>frcti_snd</code> reserves PCI head room; sets DATA, plus DRF when the pipe is empty (<code>snd_cr.seqno == snd_cr.lwe</code>).
# <code>seqno_rotate()</code> if past sender inactivity and the pipe is empty ([[#4. Sequence-number rotation (DRF)|Section 4]]).
# Advertise FC (<code>pci.window = frcti_advert_rwe(frcti)</code>, i.e. <code>rcv_cr.rwe</code> clamped to <code>rcv_cr.lwe + ring_seq_cap</code> in stream mode) when the receiver side is recent: <code>now - rcv_cr.act < rcv_cr.inact</code>.
# Reliable mode (FRTX): leave <code>snd_cr.lwe</code> where it is; reset the slot at <code>RQ_SLOT(seqno)</code> (<code>snd_slots[p].time = now</code>, <code>snd_slots[p].flags = 0</code>); queue an <code>rxm_entry</code> (saves a packet copy, arms a wheel timer at <code>now + (rto << rto_mul)</code>). Piggyback ACK (<code>pci.ackno = rcv_cr.lwe</code>) while the a-timer for the most recent received DATA packet has not yet expired (<code>now - rcv_cr.act <= t_a</code>); on piggyback, set <code>rcv_cr.seqno = rcv_cr.lwe</code> so the next delayed-ACK fire is suppressed. See [[#8. Retransmission|Section 8]] for <code>t_a</code> / <code>t_r</code> semantics.
# Best-effort mode (no FRTX): advance <code>snd_cr.lwe</code> immediately (<code>snd_cr.lwe = snd_cr.lwe + 1</code>, <code>snd_cr.rwe = snd_cr.lwe + RQ_SIZE</code>); no retransmit state. No send-side RTT probe is armed in this mode (<code>rtt_probe_arm</code> requires an in-flight <code>seqno</code>, which best-effort never has); the rx-driven cold seeder in <code>frcti_rcv</code> is the only probe path.
# In reliable mode, optionally arm an RTT probe ([[#12. RTT estimation|Section 12]]).

== 6. Receive path ==

=== 6.1. Early-exit dispatch ===

Keepalive (KA), RTT probe (RTTP), pre-DRF NACK, and rendezvous
(RDVS) packets short-circuit out of <code>frcti_rcv</code> before the locked
main path; each handler takes its own lock internally.

<syntaxhighlight lang="text">
incoming packet
|
v
+---------+
| KA? |---yes--> ka_rcv ; return
+---------+
|no
v
+---------+
| RTTP? |---yes--> rttp_rcv; return
+---------+
|no
v
+---------+
| NACK? |---yes--> nack_rcv; return (see Section 9)
+---------+
|no
v
+---------+
| RDVS? |---yes--> rdv_rcv ; return (reply bare FC, ackno=0)
+---------+
|no
v
acquire wrlock; enter locked main path
</syntaxhighlight>

;<code>KA</code>
:refresh <code>t_ka_rcv</code>, honour piggybacked ACK.
;<code>RTTP</code>
:probe (echo back nonce) or echo (verify nonce, sample RTT).
;<code>NACK</code>
:pre-DRF, sender-side handler. See [[#9. Pre-DRF NACK|Section 9]].
;<code>RDVS</code>
:reply with a bare FC packet (<code>ackno = 0</code>); <code>rdlock</code> only.

=== 6.2. Locked main path ===

Steps below run with the per-flow <code>frcti.lock</code> held for writing
(<code>pthread_rwlock_wrlock</code>) unless noted.

;<code>rcv_inact_check</code>
:Only meaningful when the receive side is stale. On DRF (Data Run Flag): release <code>rq[]</code> slots, rebase <code>rcv_cr</code>, continue. On stale DATA without DRF: fire a pre-DRF NACK if cooldown allows ([[#9. Pre-DRF NACK|Section 9]]), then discard the packet; on cooldown, drop without sending a NACK (a pending cumulative ACK from <code>drop_packet</code> may still go out). Non-DATA, non-DRF arrivals bypass <code>rcv_inact_check</code> entirely; pure-DRF stale arrivals fall through after the DRF rebase branch.

;DATA-only act refresh
:Refresh <code>rcv_cr.act</code> only when <code>FRCT_DATA</code> is set, so that non-DATA packets never block the next DRF rebase.

;Wire-dup gate
:Before flag-driven dispatch, drop wire-duplicate ACKs and wire-duplicate DATA (<code>is_dup_ack</code> / <code>is_dup_data</code>). The DATA check is bypassed for <code>FRCT_RXM</code>-bearing arrivals so the piggybacked ACK / SACK / FC carried on a retransmitted DATA at an already-ACK'd <code>seqno</code> is still applied; the stale-in-window branch below then drops the packet.

;<code>ACK</code>
:Drop ACKs whose <code>ackno</code> falls outside <code>(snd_cr.lwe, snd_cr.seqno]</code>. If <code>ackno == snd_cr.lwe</code> (non-advancing cumulative ACK), drive RACK fast-retransmit consideration ([[#8. Retransmission|Section 8]]). Otherwise advance <code>snd_cr.lwe = ackno</code>, collapse <code>rto_mul</code> to 0 (Karn-gated by <code>SND_RTX</code> on the just-acknowledged slot, the old head-of-line), reset <code>dup_thresh</code> to 0, update <code>t_latest_ack</code> to the send-time of the slot at <code>ackno-1</code> (consumed by RACK and SACK below), decay <code>reo_wnd_mult</code> per RFC 8985 sec. 6.2 step 4, exit NewReno-careful recovery (see [[#8. Retransmission|Section 8]]) on <code>ackno >= recovery_high</code> or <code>ackno == snd_cr.seqno</code>, and feed an RTT sample if eligible ([[#12. RTT estimation|Section 12]]).

;<code>SACK</code>
:Walk the block list. For each block (a present range above <code>lwe</code>) NULL out <code>snd_slots[k].rxm</code>, clear the slot's per-send flags, and advance <code>t_latest_ack</code> to the latest send-time covered (the Forward Acknowledgement / fack equivalent, Mathis & Mahdavi 1996); the first block whose start clamps to <code>snd_cr.lwe</code> skips this fack update so that a head-of-line clamp does not falsely advance fack. For un-SACKed gaps below <code>hi_sacked</code>, stage a retransmit per slot that is (1) still owned (<code>rxm != NULL</code>), (2) not already <code>SND_FAST_RXM</code>, (3) not aged out past <code>t_r</code>, and (4) either outside the RACK reorder window <code>R</code> OR with <code>dup_thresh >= DUP_THRESH</code> (the RFC 8985 sec. 6.2 hybrid trigger). Mark the slot <code>SND_FAST_RXM</code> and NULL the <code>rxm</code> at stage time. Capped at <code>SACK_RXM_MAX</code> staged retransmits per receive pass; what's left rides the next SACK.

;<code>FC</code>
:Bump <code>snd_cr.rwe</code> (clamped to <code>lwe + RQ_SIZE</code>, never shrinks) and mark window open.

;<code>DATA</code>
:Bounds-check <code>seqno</code> against window. On stale-dup (<code>seqno < rcv_cr.lwe</code>), set <code>rcv_cr.seqno = seqno</code> to force a fresh ACK on the next <code>ack_snd</code>, then drop. On accept: both FRTX and best-effort stash the packet-buffer index into <code>rq[seqno mod RQ_SIZE]</code>. Fragments stash unchanged - the role bits are inspected only at consume time ([[#7.2. Fragmentation and reassembly|Section 7.2]]). On out-of-order arrival, build a SACK reply if not rate-limited (per [[#3. Protocol parameters|Section 3]]) and not deduplicated against the previous <code>(rcv_cr.lwe, n_blocks)</code> pair; D-SACK reports always bypass the dedup. If both rate-limit and dedup suppress the reply, neither SACK nor delayed-ACK fires (the sender picks up the gap on its next ACK). On in-order arrival, arm the delayed-ACK timer.

;<code>drop_packet</code> exit
:Releases the per-packet shared-memory buffer (<code>spb</code>), then calls <code>ack_snd</code> synchronously after the <code>spb</code> release to surface any pending cumulative ACK.

== 7. Read path and reassembly ==

=== 7.1. Read path ===

<code>flow_read</code> returns a full reassembled SDU (Service Data Unit) via
<code>frcti_consume</code> on every FRCP SDU-mode flow (FRTX or best-effort);
stream-mode is covered in [[#16. Stream-mode flows|Section 16]]. An incomplete head-of-line
(HoL) run yields <code>-EAGAIN</code>; an oversized run yields <code>-EMSGSIZE</code> (the
run is dropped so the flow does not stall). On best-effort flows,
a permanently-lost mid-fragment is dropped as soon as a later
complete SDU becomes visible in the ring ([[#7.2. Fragmentation and reassembly|Section 7.2]] skip-past-
gap).

Raw flows carry no <code>frcti</code>, so <code>flow_read</code> returns the next pending
packet-buffer index directly, with no role-bit inspection. (Raw
service is selected via <code>qos.service == SVC_RAW</code> at flow allocation,
which suppresses <code>frcti</code> creation.)

<code>frcti_pdu_ready</code> is the no-advance peek used by <code>fevent</code> (the
Ouroboros flow-event multiplexer, the <code>poll(2)</code>-equivalent on
flows). It returns ready only when the head-of-line run is
complete and the lead packet (a Protocol Data Unit, here one FRCP
packet) is present at <code>rcv_cr.rwe - RQ_SIZE</code>; any other state
(including the best-effort skip-past-gap case) returns not ready,
and <code>frcti_consume</code> is left to drop the broken prefix and re-
inspect.

=== 7.2. Fragmentation and reassembly ===

Send side (<code>flow_write_frag</code>). An SDU larger than
<code>(frag_mtu - PCI)</code> is split into <code>ceil(count / (frag_mtu - PCI))</code>
fragments; each fragment is its own FRCP packet with its own
<code>seqno</code> and a per-fragment role flag pair ([[#1.2. Flag bits|Section 1.2]]). Roles are
assigned at emit time:

{| class="wikitable"
! i !! Role
|-
| <code>n=1</code> || <code>SOLE</code>
|-
| <code>i=0</code> || <code>FIRST</code>
|-
| <code>i=n-1</code> || <code>LAST</code>
|-
| else || <code>MID</code>
|}

A mid-loop allocation or transmit failure may yield a partial
write: the call returns the bytes already enqueued (<code>off > 0</code>) or
the underlying error (<code>off == 0</code>). Best-effort flows fragment
identically; on the receiver, a partial run with a permanently-
lost fragment is dropped when a later complete SDU is visible in
the ring (see skip-past-gap below). Raw flows carry no PCI and
refuse anything larger than the layer's user MTU (<code>-EMSGSIZE</code>).

Wire-level recovery is fragment-agnostic on FRTX flows: each
fragment's <code>seqno</code> flows through SACK / RACK / RTO / NACK exactly
as for a SOLE DATA packet, and reassembly does not re-enter the
loss-detection path. Best-effort flows run the same <code>seqno</code>
machinery (DRF, FC, ACK piggyback, pre-DRF NACK emit) but queue
no <code>rxm</code> state at the sender, so a lost MID is unrecoverable;
skip-past-gap handles it (below).

Receive side. Fragments stash into <code>rq[seqno]</code> unchanged; role bits
are read only at consume time. <code>frag_run_inspect</code>, called from
<code>frcti_consume</code>, walks the ring starting at the oldest still-
undelivered <code>seqno</code> <code>base = rcv_cr.rwe - RQ_SIZE</code> (equal to <code>rcv_cr.lwe</code>
only when no partial run is in progress; during a partial run <code>lwe</code>
has already advanced past <code>base</code>). It produces one of three
outcomes:

{| class="wikitable"
! Outcome !! Cause
|-
| <code>DELIVER (n)</code>
| <code>rq[base]=SOLE</code> (<code>n=1</code>), or <code>rq[base]=FIRST</code> and a <code>LAST</code> follows in slots <code>[base+1..base+n-1]</code> with all intermediate roles in <code>{MID,FIRST,LAST}</code> contiguous.
|-
| <code>DROP (n)</code>
| <code>rq[base]</code> is <code>MID</code> or <code>LAST</code> without a preceding <code>FIRST</code> (<code>n=1</code>); a <code>FIRST..[non-LAST]..new-FIRST</code> or new-<code>SOLE</code> mid-run (drop the broken prefix with <code>n</code> = run length minus 1, so the new <code>FIRST</code>/<code>SOLE</code> stays); or, on best-effort flows, a gap at <code>base</code> with a <code>FIRST</code>/<code>SOLE</code> later in the ring (drop up to the new run start).
|-
| <code>NOT_READY</code>
| <code>rq[base]</code> absent or <code>FIRST..[non-LAST]</code> with no later <code>FIRST</code>/<code>SOLE</code> in the ring (FRTX waits for retx; best-effort waits for arrival).
|}

<code>DELIVER</code> triggers <code>frag_gather</code>: a scatter-gather <code>memcpy</code> of the <code>n</code>
consecutive fragments at <code>rq[base..base+n-1]</code> directly into the
caller's buffer; each per-packet shared-memory buffer (<code>spb</code>) is
released and <code>rwe</code> advances by <code>n</code>. <code>lwe</code> was already advanced
incrementally as each contiguous fragment arrived; <code>frag_gather</code>
only restores the fixed-width invariant <code>rwe == lwe + RQ_SIZE</code>.
No intermediate reassembly buffer is allocated.

<code>DROP</code> advances <code>rwe</code> past the broken prefix (releasing the <code>spb</code>s)
and pulls <code>lwe</code> up to the new trailing edge if needed; the next
consume retries from the new <code>base</code>. Oversize or arithmetically
overflowing delivery (sum of fragment lengths > <code>max_rcv_sdu</code>, sum
> caller's buffer, or running-sum overflow) also drops the run
with <code>-EMSGSIZE</code>.

Skip-past-gap (best-effort only). On FRTX, a gap in the run means
"waiting for retransmit" and <code>frag_run_inspect</code> returns <code>NOT_READY</code>.
On best-effort flows the gap is permanent, so <code>frag_run_inspect</code>
scans forward in the ring for the next <code>FIRST</code> or <code>SOLE</code>; if one is
visible within <code>RQ_SIZE</code>, it returns <code>DROP</code> for the broken prefix and
the consume loop retries at the new <code>lwe</code>. Memory hold is bounded
by <code>RQ_SIZE</code>; the partial releases on the next consume call once a
later complete run exists. Voice-like flows (one <code>SOLE</code> per SDU)
see no extra wait: any later <code>SOLE</code> makes the prior gap droppable
immediately.

The choice to defer reassembly to consume time keeps the receive
path zero-copy: fragments stay in the shared-memory ring until
the application pulls, and the SDU lands directly in the caller's
buffer.

== 8. Retransmission ==

FRCP is bounded by two delta-t-derived timers (Watson 1981, see
[[#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_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.

Each in-flight FRTX <code>seqno</code> owns one <code>rxm_entry</code>, armed in a hashed
timing wheel; the wheel deadline is the slot's next eligible
retransmit time.

;RTO timer
:On fire (<code>rxm_due</code>), re-emit with <code>FRCT_RXM</code>, mark <code>SND_RTX</code> (Karn-suppress next ACK's RTT sample), and (for the head-of-line (HoL) slot only) bump <code>rto_mul</code> up to <code>MAX_RTO_MUL</code>. Wheel deadline is <code>t_send + (rto << rto_mul)</code>. Re-armed unless consumed. The RTO timer also clears <code>SND_FAST_RXM</code> (re-arming fast-retransmit eligibility), resets <code>reo_wnd_mult</code> to 1 on a HoL fire (RFC 8985 sec. 6.2 step 4 reset clause), and marks the flow <code>ACL_FLOWDOWN</code> if its <code>frct_tx</code> call fails.

;r-timer guard
:Before any retransmit attempt, check <code>(now - t0)</code> against <code>t_r</code>. If exceeded, the slot is no longer eligible for retransmit. Only the RTO timer (<code>rxm_due</code>) treats r-timer expiry as terminal: it marks the flow <code>ACL_FLOWDOWN</code> (peer unreachable). Fast-retransmit, SACK-driven retransmit, and NACK-driven head-of-line re-emit silently skip aged-out slots and defer the flow-down decision to the next RTO fire.

;Fast retransmit (hybrid trigger, RFC 8985 sec. 6.2)
:On a non-advancing cumulative ACK with the scoreboard advanced, fire one fast retransmit when EITHER (a) the head-of-line slot's latest send is older than the RACK reorder window <code>R</code> ([[#3. Protocol parameters|Section 3]]) and not yet aged out, OR (b) the SACK <code>dup-thresh</code> count above <code>snd_cr.lwe</code> reaches <code>DUP_THRESH</code> (= 3, RFC 8985 sec. 6.2 step 4). Fires at most once per non-advancing cumulative-ACK value, gated by <code>rack_fired_lwe</code> (the <code>snd_cr.lwe</code> at which fast-retransmit last fired). Set <code>SND_FAST_RXM</code> on the slot (one-shot per-slot gate) and enter NewReno-style careful recovery (see NewReno below in this section).
:The RACK reorder window <code>R</code> uses the RFC 8985 sec. 6.2 form <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> with a <code>MIN_REORDER_NS = 250 us</code> floor. Before the first RTT sample seeds <code>min_rtt</code>, <code>R</code> falls back to <code>MIN(reo_wnd_mult * SRTT / 4, SRTT)</code>, still floored at <code>MIN_REORDER_NS</code> (consistent with the windowed-minimum fallback described in [[#12. RTT estimation|Section 12]]). <code>min_rtt</code> is a windowed minimum over the last <code>MIN_RTT_WIN_NS</code> = 5 min of RTT samples (matches the Linux <code>tcp_min_rtt_wlen</code> default) so a route change to a longer path eventually re-anchors the reorder window without relying on <code>reo_wnd_mult</code> growth alone.

;SACK-driven retransmit
:For each gap below <code>hi_sacked</code> whose slot is (1) still owned, (2) not already <code>SND_FAST_RXM</code>, (3) not aged out past <code>t_r</code>, and (4) either outside the RACK window <code>R</code> OR with <code>dup_thresh >= DUP_THRESH</code> (same hybrid as fast-retransmit, see [[#6.2. Locked main path|Section 6.2]]), re-emit. Each SACK-driven retransmit re-arms a fresh <code>rxm</code> so a lost retransmit can still be recovered by its own RTO timer.

;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.

== 9. Pre-DRF NACK ==

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.

;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>)
:When an incoming DATA packet has no DRF and rcv-side activity is older than <code>rcv_cr.inact</code>, the receiver emits a bare packet with <code>flags = FRCT_NACK</code> and <code>seqno = arrival_seqno - 1</code> (informational only, not consulted by the receive handler). The cooldown in [[#3. Protocol parameters|Section 3]] rate-limits the burst. Non-DATA non-DRF arrivals bypass <code>rcv_inact_check</code> entirely; non-DATA DRF still rebases via the DRF branch.

;Receive (<code>frcti_nack_rcv</code>)
: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 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.

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 ==

Cumulative ACK is <code>ackno = rcv_cr.lwe</code>. On out-of-order arrival the
receiver also emits a SACK packet ([[#1.3. SACK payload|Section 1.3]]) whose payload lists
''present'' blocks above <code>lwe</code> (analogous to TCP SACK / QUIC ACK
ranges). SACKs are rate-limited per [[#3. Protocol parameters|Section 3]] and suppressed when
neither <code>lwe</code> nor block count has changed since the last SACK.

D-SACK reports (RFC 2883) are emitted in-band as <code>block[0]</code> of an
otherwise normal SACK frame (see [[#1.3. SACK payload|Section 1.3]] for the encoding).
Two receiver triggers arm a pending D-SACK report (single-slot,
latest-wins):

* DATA arrival with <code>seqno < rcv_cr.lwe</code>, both wire-dup (no RXM, <code>is_dup_data</code> path) and retransmit (RXM, post-FC branch) (RFC 2883 sec. 4.1.1, full duplicate)
* <code>rq_accept</code> conflict, slot already occupied in <code>[lwe, rwe)</code> (RFC 2883 sec. 4.1.2, partial duplicate)

When a D-SACK is pending and the standard scoreboard SACK would be
suppressed by dedup or rate-limit, the report is emitted as a
stand-alone SACK frame through the normal <code>ack_snd</code> path; when a
D-SACK report is pending the path bypasses dedup and the <code>TICTIME</code>
rate-limit, but the a-timer suppression on rcv inactivity still
applies.

Bare ACKs are deferred via a per-flow delayed-ACK timer (one in
flight at a time, atomic test-and-set dedup; fires per [[#3. Protocol parameters|Section 3]]
after the first in-order arrival). Suppressed if (1) no new
<code>seqno</code>, (2) rcv side is inactive (older than <code>t_a</code>), or (3) the
sender just sent within <code>TICTIME</code>. A pending D-SACK ride-through
bypasses (1) and (3); the a-timer gate (2) is unconditional.

== 11. Flow control ==

The receiver advertises <code>rwe</code> in every FC field. The sender treats
its <code>snd_cr.rwe</code> as the absolute right edge: when
<code>snd_cr.seqno >= snd_cr.rwe</code> the window is closed and <code>flow_write</code>
yields. While closed, the sender periodically emits RDVS
(rendezvous) packets (cadence <code>DELT_RDV</code>); the receiver replies with
a bare FC packet (<code>ackno = 0</code>) that reopens the window. Once the
window has been closed for longer than <code>MAX_RDV</code> the sender stops
emitting RDVS but does not tear the flow down - the writer keeps
blocking until either a peer-driven FC arrives or the KA
(keepalive) / r-timer marks the flow.

<code>rwe</code> is clamped to <code>lwe + RQ_SIZE</code> on receipt and MUST NOT shrink:
a backward <code>rwe</code> is silently clamped to the current <code>snd_cr.rwe</code>;
the FC packet still reopens the window.

== 12. RTT estimation ==

Active RTTP probes ([[#1.4. RTTP payload|Section 1.4]]) carry a 32-bit <code>probe_id</code> (0
reserved) and a 16-byte random nonce echoed verbatim - defends
against spoofed replies. A ring of <code>RTTP_RING</code> in-flight probes is
kept; an echo whose <code>(id, nonce)</code> doesn't match the ring slot is
dropped. A single RTTP sample is clamped to <code>RTT_CLAMP_MUL * srtt</code>
(compile-time <code>RTT_CLAMP_MUL = 16</code>) once <code>srtt</code> is seeded; the first
cold-probe sample feeds <code>rtt_update</code> raw.

Probe arming gates:

;Cold (no <code>srtt</code> yet)
:the receive path arms at most one probe per 100 ms via <code>frcti_rcv_probe</code> (<code>PROBE_DUE_COLD</code>); arming requires an incoming packet. Active send-path arming bails while <code>srtt == 0</code>.
;Warm (<code>rtt_probe_arm</code>, called from <code>frcti_snd</code>)
:outstanding data (<code>snd_cr.seqno > snd_cr.lwe</code>), AND at least <code>2 * srtt</code> since <code>t_rcv_rtt</code> (last RTT receive of any kind), AND at least <code>srtt</code> since <code>t_snd_probe</code> (last probe emit).

Sample feeds either Linux's asymmetric <code>mdev</code> estimator
(<code>FRCT_LINUX_RTT_ESTIMATOR</code>, default ON) or RFC 6298 symmetric EWMA
(compile option). <code>srtt</code> is floored at 10 ms when seeded from a
hint, at 1 us after every update (including the first seeding
sample); <code>mdev</code> floored at 100 ns.

:<code>RTO = max(rto_min, 2 * srtt, srtt + (mdev << MDEV_MUL))</code>

(the <code>2 * srtt</code> floor is an FRCT addition not in RFC 6298).
Effective wheel deadline capped per [[#3. Protocol parameters|Section 3]].

ACK-derived samples (<code>frcti_ack_rcv</code> -> <code>rtt_sample_eligible</code>), beyond
the cum-ACK advance gate in <code>frcti_ack_rcv</code> (<code>ackno > lwe</code> and
<code>ackno <= seqno</code>), require all of: not in recovery; ACK packet does
not carry <code>FRCT_RXM</code>; HoL slot's <code>SND_RTX</code> bit clear; slot's <code>rxm</code>
pointer non-NULL (not SACK-consumed); <code>lwe</code> not below the <code>rtt_lwe</code>
fence; <code>srtt</code> already seeded by an RTTP probe. There is no ACK-only
seeding.

Every eligible sample also feeds <code>RACK.min_RTT</code> (RFC 8985 sec. 6.2)
via a windowed minimum: replace whenever the sample is strictly
smaller OR more than <code>MIN_RTT_WIN_NS</code> (5 min, matches Linux
<code>tcp_min_rtt_wlen</code>) has elapsed since the current min was set. The
downward branch is immediate (faster path picked up at once); the
upward branch is gated on the window (a transient queue burst does
not poison the estimate, but a sustained route change to a longer
path re-anchors <code>min_RTT</code> after at most one window). Seeded from
<code>rtt_hint</code> at <code>rtt_init</code>; 0 acts as the unset sentinel and the base
in <code>rack_reorder_window</code> falls back from <code>min_RTT</code> to <code>SRTT</code> (so
<code>R = mult * SRTT/4</code>, capped at <code>SRTT</code>, floored at <code>MIN_REORDER_NS</code>)
until the first sample. See [[#6.2. Locked main path|Section 6.2]].

== 13. Liveness (keepalive) ==

When <code>qs.timeout > 0</code> a per-flow KA (keepalive) timer is armed.
Arming uses <code>rcv_cr.act</code> for the deadline computation:

:<code>deadline = min(snd_act + qs.timeout/4, rcv_act + qs.timeout)</code>

(clamped to <code>now + qs.timeout/4</code> if already past). The timer fires
either on sender idleness (to send a KA) or on receiver idleness
(to declare the peer dead). On fire (<code>ka_snd</code>) the peer-dead test
uses <code>max(rcv_cr.act, t_ka_rcv)</code> so a recent KA reply counts even
when no DATA has arrived:

* If <code>now - max(rcv_cr.act, t_ka_rcv) > qs.timeout</code>, mark the flow <code>ACL_FLOWPEER</code> and notify the per-process flow-event set (<code>proc.fqset</code>) with <code>FLOW_PEER</code>.
* Else if <code>snd_idle > qs.timeout/4</code>, emit a bare <code>KA | ACK</code> (<code>ackno = rcv_cr.lwe</code>) and re-arm.
* Else just re-arm.

Note: <code>rx_rb</code> and <code>tx_rb</code> are the receive and transmit shared-memory
ring buffers. The r-timer raises <code>ACL_FLOWDOWN</code> on both (route is
broken); keepalive raises <code>ACL_FLOWPEER</code> on <code>rx_rb</code> only and notifies
the flow-event set (peer is silent, writer keeps <code>tx_rb</code> usable) -
distinct ACLs. <code>qs.timeout == 0</code> disables keepalive entirely; a
silent peer crash is then undetected.

== 14. Linger / teardown ==

On <code>flow_dealloc</code>, <code>frcti_dealloc</code> computes a grace timeout

:<code>max(rcv_cr.act + rcv_cr.inact, snd_cr.act + snd_cr.inact) - now</code>

(floored at 0 and converted to seconds) and returns it; <code>flow_dealloc</code>
forwards this to the IRMd as the dealloc grace. The IRMd, not FRCT,
performs the wait. Before computing the timeout, FRCT may emit a
final ACK when <code>rcv_cr.lwe != rcv_cr.seqno</code> (the peer has not been
told the most recent cumulative ACK) AND the rcv side has been
active within <code>t_a</code> (a-timer not aged out).

<code>FRCTFLINGER</code> is honoured only when <code>snd_cr.lwe < edge</code>, where <code>edge =
snd_fin_seqno</code> after FIN has been sent in stream mode and
<code>snd_cr.seqno</code> otherwise (data or FIN still in flight). The drain
itself runs in <code>flow_dealloc</code>'s <code>while (FRCTI_LINGERING)</code> loop, not in
<code>frcti_dealloc</code>.

The fd is single-reader / single-writer (documented in the
manpages). <code>flow_write</code> pumps <code>rx_rb</code> on every call (via
<code>flow_wait_window</code> -> <code>flow_drain_rx_nb</code>) and additionally blocks on
<code>rx_rb</code> when the send window is closed. A pure-writer thread thus
consumes ACKs without a dedicated reader.

== 15. Heritage and adopted techniques ==

Delta-t (Watson, 1981) is the primary heritage; FRCP descends from
the delta-t protocol family via the Recursive InterNetwork
Architecture (RINA; Day, "Patterns in Network Architecture", 2008,
ch. 9). Timer-based connection management
(no SYN/FIN handshake, per-flow state born on first DATA and
reclaimed after <code>t_mpl + a + r</code> of silence), the DRF marker, and the
<code>t_mpl</code> / <code>t_a</code> / <code>t_r</code> timers all come from delta-t. See Watson,
"Timer-Based Mechanisms in Reliable Transport Protocol Connection
Management", Computer Networks 5 (1981).

The unified <code>flow_alloc(name, qos, ...)</code> primitive and its
multi-axis QoS-cube argument ([[#2.2. Service modes (orthogonal axes)|Section 2.2]]) also come from RINA
(Day 2008, ch. 6; Grasa et al., "IRATI: investigating RINA as an
alternative to TCP/IP", Computer Networks 92 (2015)) - reliability,
ordering, CRC presence, and encryption are flow attributes, not
separate sockets or protocols.

The table below summarises additional adopted techniques and their
references.

{| class="wikitable"
! FRCP mechanism !! Heritage !! Reference / note
|-
| Random new <code>seqno</code> on <code>seqno_rotate</code> || TCP ISN || RFC 6528 (Gont & Bellovin, 2012). QUIC PN-space reset (RFC 9000 sec. 12.3) is a structural analogue.
|-
| Cumulative ACK, left-window-edge advance || TCP || RFC 793 / RFC 9293
|-
| Receive window with non-shrink rule || TCP || RFC 793 sec. 3.7 / RFC 9293 sec. 3.8.6; RFC 1122 sec. 4.2.2.16 for the explicit non-shrink prohibition
|-
| Modular <code>seqno</code> arithmetic (<code>before</code>/<code>after</code> helpers) || TCP || RFC 793 sec. 3.3 / RFC 9293 sec. 3.4
|-
| Selective ACK block list || TCP || RFC 2018 (Mathis et al., 1996). Encoded as a typed FRCP packet rather than a TCP option, so framing is closer to QUIC ACK frames. D-SACK (RFC 2883) carried in-band as <code>block[0]</code>; see [[#1.3. SACK payload|Section 1.3]].
|-
| NewReno-careful recovery with <code>recovery_high</code> gate || TCP || RFC 6582 (Henderson et al., 2012); QUIC builds on the same model in RFC 9002 sec. 7.3.2. Cwnd half absent (CC in IPCP).
|-
| RACK reordering window for fast retransmit || TCP || RFC 8985 (Cheng et al., 2021). FRCP <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> with a <code>MIN_REORDER_NS = 250 us</code> floor against <code>srtt</code> collapse; matches RFC 8985 sec. 6.2 and Linux <code>tcp_rack_reo_wnd</code>. DSACK-driven <code>reo_wnd_mult</code> (sec. 6.2 step 4) is adopted; see [[#1.3. SACK payload|Section 1.3]] for the wire encoding. The hybrid RACK-or-<code>DUP_THRESH</code> trigger from RFC 8985 sec. 6.2 step 4 is adopted ([[#8. Retransmission|Section 8]]). QUIC's analogue in RFC 9002 sec. 6.1.2 uses <code>max(srtt, latest_rtt)</code> as the base.
|-
| 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> = 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.
|-
| Delayed ACK with rate suppression || TCP || RFC 813 (Clark, 1982); RFC 1122 sec. 4.2.3.2; RFC 5681 sec. 4.2. Single-deadline coalescing rather than "ack-every-other-segment".
|-
| Zero-window-probe / persist-timer analogue (RDVS) || TCP || RFC 1122 sec. 4.2.2.17 / RFC 9293 sec. 3.8.6.1. RDVS solicits an FC reply, distinct from QUIC <code>DATA_BLOCKED</code> (RFC 9000 sec. 19.12), which is one-way notification. <code>MAX_RDV</code> give-up departs from TCP.
|-
| Multiplexed control on a single PCI || SCTP / QUIC || SCTP chunk bundling (RFC 9260 sec. 6.10); QUIC frame multiplexing (RFC 9000 sec. 12.4). Cleaner fit than TCP's separate-flag-bits design.
|-
| ACK ranges as multiple discontiguous acked blocks || QUIC || QUIC ACK frame (RFC 9000 sec. 19.3). FRCP SACK is conceptually QUIC-frame-shaped even though encoded as absolute <code>[start,end]</code> pairs.
|-
| Nonce-authenticated active RTT / liveness probing (RTTP) || QUIC <code>PATH_CHALLENGE</code> || <code>PATH_CHALLENGE</code> / <code>PATH_RESPONSE</code> (RFC 9000 sec. 8.2, sec. 19.17, sec. 19.18). WebRTC ICE consent-freshness (RFC 7675) is the same pattern. QUIC's nonce is 8 octets; FRCP chooses 16.
|-
| Probing distinct from keepalive || QUIC || KA timer answers "peer alive?", RTTP answers "path measurable?", as in QUIC PING (RFC 9000 sec. 19.2) vs <code>PATH_CHALLENGE</code>.
|-
| Bare KA + ACK keepalive packets || QUIC / SCTP || QUIC PING (RFC 9000 sec. 19.2); SCTP HEARTBEAT / HEARTBEAT-ACK (RFC 9260 sec. 8.3). SCTP HEARTBEAT also carries an opaque echoed blob, structurally similar to FRCP RTTP.
|-
| (<code>FFGM</code>, <code>LFGM</code>) fragment-role bits ([[#7.2. Fragmentation and reassembly|Section 7.2]]) || SCTP || RFC 9260 sec. 3.3.1 DATA chunk B/E bits encode the same four states (<code>B+E=SOLE</code>, <code>B-only=FIRST</code>, neither=<code>MID</code>, <code>E-only=LAST</code>). Each fragment carries its own <code>seqno</code>/TSN and is independently retransmitted.
|-
| Stream byte-offset reassembly (Sections [[#1.5. Stream PCI extension|1.5]], [[#16. Stream-mode flows|16]]) || QUIC || QUIC STREAM frame (RFC 9000 sec. 19.8) uses Offset + Length varints; FRCP uses fixed 32-bit <code>start</code> / <code>end</code>. One stream per flow vs QUIC's many streams multiplexed.
|-
| FIN end-of-stream marker (Sections [[#1.2. Flag bits|1.2]], [[#16. Stream-mode flows|16]]) || TCP / QUIC || TCP FIN flag (RFC 9293 sec. 3.1) closes one half of the byte stream; QUIC STREAM frame FIN bit (RFC 9000 sec. 19.8) does the same per stream with an immutable final-size invariance (RFC 9000 sec. 4.5: the final size is fixed once observed). FRCP's FIN consumes one packet <code>seqno</code> (not one byte of stream space) and is idempotent on the sender side.
|-
| Stream byte-credit flow control ([[#16. Stream-mode flows|Section 16]]) || QUIC || <code>MAX_STREAM_DATA</code> (RFC 9000 sec. 4.1, sec. 19.10). FRCP projects a per-flow byte budget onto the <code>seqno</code>-space <code>rwe</code>. Single stream per flow collapses QUIC's <code>MAX_DATA</code> / <code>MAX_STREAM_DATA</code> distinction.
|-
| Header protection (encrypted seqnos) || QUIC || QUIC RFC 9001 sec. 5.4 applies header protection on top of AEAD to mask the packet number. FRCP's per-flow AEAD wrap ([[#16. Stream-mode flows|Section 16]]) is wider: it encrypts the entire PCI including <code>seqno</code> because the IPCP below already routes, so no destination connection-ID needs to stay in clear (cf. RFC 9000 sec. 5.2).
|-
| Two-bit fragment role polarity || SCTP || The (<code>FFGM</code>, <code>LFGM</code>) pair follows SCTP B/E (begin = 1 / end = 1) rather than IPv4 MF (RFC 791 sec. 3.2), which has the inverse polarity (MF = 1 means NOT last).
|-
| Orthogonal reliability / ordering axes ([[#2.2. Service modes (orthogonal axes)|Section 2.2]]) || SCTP || PR-SCTP (RFC 3758, per-message partial reliability) and SCTP DATA U-bit (RFC 9260 sec. 3.3.1, per-message unordered) are the closest precedents for decoupling reliability from ordering; FRCP sets them per-flow rather than per-message.
|-
| Orthogonal CRC (<code>qs.ber == 0</code>) || UDP-Lite || RFC 3828 (Larzon et al., 2004) lets the sender pick a per-packet Checksum Coverage and the receiver enforce a locally configured minimum (no in-band negotiation; sec. 3.1, sec. 3.3). FRCP gates a full CRC trailer on <code>qs.ber == 0</code> at flow setup. Contrast TCP / SCTP (mandatory checksum) and QUIC (AEAD subsumes CRC).
|-
| Setup-time service negotiation || DCCP / SCTP / QUIC || DCCP Service Codes (RFC 4340 sec. 8.1.2, RFC 5595); SCTP INIT parameters (RFC 9260 sec. 3.3.2); QUIC transport parameters (RFC 9000 sec. 7.4). All negotiate service properties at connection setup; only RINA's QoS cube exposes them as an orthogonal vector.
|}

=== 15.1. Original to FRCP (no clean prior art) ===

* Pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]): receiver-driven nudge exploiting <code>snd_cr.inact > rcv_cr.inact</code>. Closest analogues are SCTP Gap Ack Blocks (RFC 9260 sec. 3.3.4) and DCCP Ack Vector (RFC 4340 sec. 11.4) - both let the receiver describe gaps to the sender, but neither targets the cross-epoch / pre-DRF case.
* <code>MAX_RDV</code> window-probe give-up: neither TCP (persist-timer probes until application or R2 abort, RFC 9293 sec. 3.8.6.1) nor QUIC has an explicit FC-give-up counter. A recursive-network choice: outer layers can drop the flow.
* Skip-past-gap reassembly ([[#7.2. Fragmentation and reassembly|Section 7.2]]): SCTP fragments and reassembles every flow regardless of reliability/ordering, using its own per-stream reassembly queue; QUIC fragments via STREAM offsets. FRCP fragments best-effort flows too, but the receiver drops the broken prefix the moment a later run-start (<code>FIRST</code> or <code>SOLE</code> role) is visible inside the <code>RQ_SIZE</code>-wide reorder ring - no IP-frag-style timeout, no SCTP-style explicit abort. If no later run-start arrives within the ring, <code>frag_run_inspect</code> returns <code>NOT_READY</code> and the partial run keeps its slots; the next inspect retries. The trade-off: a permanently-lost <code>MID</code> in a long isolated run holds slots until either a later <code>FIRST</code>/<code>SOLE</code> appears in the ring or the writer stops, at which point the slots are reclaimed on flow teardown.
* Reassembly deferred to consume time ([[#7.2. Fragmentation and reassembly|Section 7.2]]), message mode only (<code>qos.service == SVC_MESSAGE</code>): SCTP (RFC 9260 sec. 6.9), QUIC (RFC 9000 sec. 2.2), and TCP (RFC 9293) all hold reassembly state at the receive boundary. FRCP message-mode leaves fragments in the shared-memory ring until <code>flow_read</code> pulls and lands the SDU directly in the caller's buffer. Stream mode ([[#16. Stream-mode flows|Section 16]]) uses the standard QUIC-style direct ring placement on receive and does not defer. The optimisation is enabled by the Shared-Memory Subsystem (SSM) packet-buffer ring (see <code>struct ssm_pk_buff</code> at [[#1.1. PCI header|Section 1.1]]); the analogue is OS-level scatter-gather I/O (<code>recvmsg+iovec</code>), not a transport-layer prior art.
* TLP-equivalent tail-loss recovery (RFC 8985 sec. 7; RFC 9002 sec. 6.2): FRCP does not emit an explicit Tail Loss Probe packet, but the same goal is met implicitly by RACK loss detection ([[#8. Retransmission|Section 8]]) firing on a non-advancing cumulative ACK once the head-of-line slot ages past the RACK reorder window <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> - well below <code>RTO = max(2 * SRTT, SRTT + (mdev << MDEV_MUL))</code>. A receiver-driven nudge is also available via the pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]).

=== 15.2. Not adopted ===

* Slow start, congestion window (cwnd), Additive Increase / Multiplicative Decrease (AIMD), NewReno cwnd inflation. Congestion control lives in the IPCP CA policies and is driven by Explicit Congestion Notification (ECN, RFC 3168).
* Nagle / silly-window-syndrome (SWS) avoidance (RFC 896, RFC 1122 sec. 4.2.3.4). (Deferred work, not adopted in the current spec.)
* TCP Timestamps (RFC 7323) / Protection Against Wrapped Sequences (PAWS) - RTT measurement uses RTTP, not per-segment timestamps. A peer-supplied timestamp echoed on every ACK lets a malicious peer drive the <code>srtt</code> estimate arbitrarily low, collapsing the RTO and triggering a self-inflicted retransmit storm. RTTP confines RTT measurement to nonce-authenticated probe round-trips, where a forged echo is rejected before it can reach the estimator.
* ECN (Explicit Congestion Notification) response inside FRCP (consumed by IPCP Congestion Avoidance / CA).
* 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).

== 16. Stream-mode flows ==

When a flow is allocated with <code>qos.service == SVC_STREAM</code> both peers
switch to byte-stream semantics, layered on top of the FRTX reorder
machinery already described in Sections [[#6. Receive path|6]]-[[#8. Retransmission|8]].

=== 16.1. Send ===

The sender splits the caller's octets into chunks of at most
<code>(frag_mtu - base PCI - stream PCI extension)</code> octets (Sections [[#1.1. PCI header|1.1]]
and [[#1.5. Stream PCI extension|1.5]]). Each chunk is one DATA packet with its own <code>seqno</code> and a
<code>[start, end)</code> byte range copied from a monotonic stream counter.
In stream mode <code>FFGM</code> and <code>LFGM</code> are unused and MUST be transmitted as
zero; the per-byte position is carried by the <code>[start, end)</code>
extension instead.

End-of-stream is signalled with a 0-byte DATA packet that has <code>FIN</code>
(bit 12) set, emitted on the FIN triggers listed in [[#1.2. Flag bits|Section 1.2]]
(WR-half close, <code>flow_dealloc</code>, and any other path that yields the
final byte). The sender MUST emit at most one FIN per flow; its
<code>[start, end)</code> MUST equal <code>[final-byte, final-byte)</code> (i.e., empty
interval at the final byte position; final-size invariance,
analogous to QUIC RFC 9000 sec. 4.5). Idempotency is enforced by
an <code>snd_fin_sent</code> guard.

=== 16.2. Receive ===

On arrival the receiver places the payload directly into a per-flow
byte-indexed receive ring of width <code>ring_sz</code> (octets) at the position
indicated by <code>start</code>, with a two-segment <code>memcpy</code> across the ring
boundary if needed. Receipt is recorded in the FRTX reorder
machinery ([[#6.2. Locked main path|Section 6.2]]) augmented with the packet's <code>start</code>, <code>end</code>, and
FIN bit per slot. When a packet's <code>[start, end)</code> front-overlaps
bytes already at or below the byte high-water mark, the overlap is
trimmed before placement so the same byte is never written twice.
After stashing, the receiver advances <code>lwe</code> and the byte high-water
mark across any newly-contiguous prefix. Each slot advanced MUST
satisfy <code>start == the last-delivered slot's end</code>; a slot whose
<code>start</code> does not equal that <code>end</code> is silently dropped at delivery time
(the <code>seqno</code> is consumed, no stream bytes contributed) and the high-
water mark does not advance past it. The stream byte-stream
stalls at that point - there is no flow-tear-down on mismatch.
This filters spliced or off-path-injected slots that fall in
window without strong cryptographic authentication.

A FIN slot marks end-of-stream at advance time only if its byte
position equals the last-delivered slot's <code>end</code>; otherwise the FIN
is ignored and the corresponding <code>seqno</code> occupies a slot but
contributes no stream bytes. No packet buffer is held after the
ring copy.

=== 16.3. Read ===

<code>flow_read</code> returns up to <code>count</code> octets from the contiguous prefix
<code>[next, high-water)</code>, where <code>next</code> is the byte the application has
already consumed up to and <code>high-water</code> is the rightmost contiguous
byte received. When the stream is fully drained AND end-of-stream
(EOS) was observed (<code>next == EOS</code> byte position), <code>flow_read</code> returns
0 (<code>EOF</code>) - the same shape POSIX <code>read(2)</code> uses on TCP after a peer
FIN.

=== 16.4. Flow control ===

ACK / SACK / RACK / RTO machinery is unchanged; the FRTX reorder
ring is reused as a per-<code>seqno</code> received-bitmap. Let <code>per_pkt =
(frag_mtu - base PCI - stream PCI extension)</code>, the maximum stream-
byte payload one DATA packet can carry ([[#16.1. Send|Section 16.1]]). The
receive window advertised in FC is clamped so the byte window
(<code>ring_sz</code>) cannot be overrun: the <code>seqno</code>-space <code>rwe</code> is at most
<code>rcv_cr.lwe + ring_sz / per_pkt</code>.

This is the QUIC byte-credit flow-control model
(<code>MAX_STREAM_DATA</code>, RFC 9000 sec. 4.1 and sec. 19.10) projected onto
<code>seqno</code> space. With one stream per flow there is no <code>MAX_DATA</code> /
<code>MAX_STREAM_DATA</code> distinction. Receiver-side silly-window-syndrome
(SWS) avoidance (RFC 9293 sec. 3.8.6.2.2) is achieved by combining
the consume-time <code>rwe</code> bump with the global non-shrink rule from
[[#11. Flow control|Section 11]].

=== 16.5. Security considerations ===

Threat model. An attacker that can observe (on-path passive) or
predict (off-path blind) the flow's seqnos and byte offsets on an
unencrypted stream flow can inject DATA or FIN at any in-window
position. The in-line consistency checks above (<code>start</code> == prior
<code>end</code> on advance; FIN MUST be 0-byte; FIN MUST sit at the final
byte position) realise the spirit of RFC 5961's "sequence-window
plus exact-position match for control bits" without an explicit
challenge-ACK probe; they make a few specific blind attack shapes
harder but are not cryptographic authentication. This is
comparable to TCP without the TCP Authentication Option (TCP-AO,
RFC 5925), tighter than a
pre-RFC-5961 TCP stack, and roughly equivalent to a modern
RFC 5961 stack against blind off-path injection - none of these
help once the attacker can sniff. TLS over TCP (RFC 8446)
encrypts only the TCP payload and leaves TCP seqnos, ACKs, FIN,
and RST in the clear, so TLS does NOT defend against TCP-header-
level injection; QUIC (RFC 9000) hides packet numbers under
header protection (RFC 9001 sec. 5.4), so this specific weakness
does not apply to QUIC.

Mitigation: AEAD. When the flow has encryption enabled the
recommended AEAD ciphers (AES-GCM, RFC 5288; or ChaCha20-Poly1305,
RFC 8439) wrap the entire FRCP packet on the wire - PCI, stream
extension, body, and the CRC trailer when <code>ber == 0</code> - under a
per-flow symmetric key derived from the flow's own key exchange
([[#1.1. PCI header|Section 1.1]]). The AEAD tag (~2^-128 forgery probability)
dominates the CRC (~2^-32) for integrity in this mode but the CRC
trailer is currently retained inside the wrap (see [[#1.1. PCI header|Section 1.1]]).
Implementations MUST NOT rely on the security properties below
when a non-AEAD cipher (e.g. AES-CTR alone) is negotiated; non-
AEAD modes provide confidentiality only and the threat-model
claims do not hold.

With an AEAD cipher in use, seqnos, byte offsets, and the FIN bit
are both authenticated and confidential. Against an off-path or
on-path-passive attacker this is:

* Stronger than TCP+TLS (TCP header in the clear).
* Stronger than TCP+TCP-AO (header authenticated but visible).
* 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
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
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
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 MUST provide it at a higher
layer.

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.

== 17. References ==

This section lists the IETF documents, published works, and
source-code references cited inline elsewhere in this document.
IETF documents are cited inline as "RFC NNNN sec. X.Y"; books,
journal papers, and source-code references are cited inline by
author and year (or by file and function name) and are listed
here for convenience.

=== 17.1. IETF documents ===

;[RFC 791]
:J. Postel, "Internet Protocol", STD 5, RFC 791, September 1981.
;[RFC 793]
:J. Postel, "Transmission Control Protocol", STD 7, RFC 793, September 1981. Obsoleted by RFC 9293.
;[RFC 813]
:D. D. Clark, "Window and Acknowledgement Strategy in TCP", RFC 813, July 1982.
;[RFC 896]
:J. Nagle, "Congestion Control in IP/TCP Internetworks", RFC 896, January 1984.
;[RFC 1122]
:R. Braden (ed.), "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
;[RFC 2018]
:M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
;[RFC 2119]
:S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
;[RFC 2883]
:S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
;[RFC 3758]
:R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
;[RFC 3828]
:L-A. Larzon, M. Degermark, S. Pink, L-E. Jonsson (ed.), G. Fairhurst (ed.), "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
;[RFC 4303]
:S. Kent, "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
;[RFC 4340]
:E. Kohler, M. Handley, S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
;[RFC 5288]
:J. Salowey, A. Choudhury, D. McGrew, "AES Galois Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, August 2008.
;[RFC 5595]
:G. Fairhurst, "The Datagram Congestion Control Protocol (DCCP) Service Codes", RFC 5595, September 2009.
;[RFC 5681]
:M. Allman, V. Paxson, E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
;[RFC 5925]
:J. Touch, A. Mankin, R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
;[RFC 5961]
:A. Ramaiah, R. Stewart, M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, August 2010.
;[RFC 6298]
:V. Paxson, M. Allman, J. Chu, M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, June 2011.
;[RFC 6528]
:F. Gont, S. Bellovin, "Defending against Sequence Number Attacks", RFC 6528, February 2012. Obsoletes RFC 1948.
;[RFC 6582]
:T. Henderson, S. Floyd, A. Gurtov, Y. Nishida, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 6582, April 2012.
;[RFC 7323]
:D. Borman, B. Braden, V. Jacobson, R. Scheffenegger (ed.), "TCP Extensions for High Performance", RFC 7323, September 2014.
;[RFC 7675]
:M. Perumal, D. Wing, R. Ravindranath, T. Reddy, M. Thomson, "Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness", RFC 7675, October 2015.
;[RFC 8174]
:B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017.
;[RFC 8200]
:S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, July 2017.
;[RFC 8439]
:Y. Nir, A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 8439, June 2018.
;[RFC 8446]
:E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, August 2018.
;[RFC 8985]
:Y. Cheng, N. Cardwell, N. Dukkipati, P. Jha, "The RACK-TLP Loss Detection Algorithm for TCP", RFC 8985, February 2021.
;[RFC 9000]
:J. Iyengar (ed.), M. Thomson (ed.), "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, May 2021.
;[RFC 9001]
:M. Thomson (ed.), S. Turner (ed.), "Using TLS to Secure QUIC", RFC 9001, May 2021.
;[RFC 9002]
:J. Iyengar (ed.), I. Swett (ed.), "QUIC Loss Detection and Congestion Control", RFC 9002, May 2021.
;[RFC 9147]
:E. Rescorla, H. Tschofenig, N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, April 2022.
;[RFC 9260]
:R. Stewart, M. Tuexen, K. Nielsen, "Stream Control Transmission Protocol", RFC 9260, June 2022. Obsoletes RFC 4960.
;[RFC 9293]
:W. Eddy (ed.), "Transmission Control Protocol (TCP)", STD 7, RFC 9293, August 2022. Obsoletes RFC 793 and several follow-ons; updates RFC 1122 and others.

=== 17.2. Books and journal papers ===

;[Day08]
:J. Day, "Patterns in Network Architecture: A Return to Fundamentals", Prentice Hall, 2008.
;[Grasa15]
:E. Grasa et al., "IRATI: investigating RINA as an alternative to TCP/IP", Computer Networks, Vol. 92, December 2015.
;[KP87]
:P. Karn, C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", ACM SIGCOMM, August 1987.
;[Wat81]
:R. W. Watson, "Timer-Based Mechanisms in Reliable Transport Protocol Connection Management", Computer Networks, Vol. 5, 1981.

=== 17.3. Source-code references ===

;[Linux-RTT]
:<code>tcp_rtt_estimator()</code> in <code>net/ipv4/tcp_input.c</code> of the Linux kernel, defining the asymmetric <code>mdev</code> variance update used as FRCP's default RTT estimator ([[#12. RTT estimation|Section 12]]). Line-stable browseable copy at https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_input.c.

[[Category:Protocols]]
[[Category:Ouroboros internals]]

Flow and Retransmission Control Protocol

2026-05-17T14:47:17Z

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

{{DISPLAYTITLE:FRCP - Flow and Retransmission Control Protocol}}

FRCP runs end-to-end between two peers over a flow. It delivers
reliability, in-order delivery, flow control, and liveness.
Congestion Control (CC) is not in FRCP - that lives in the IPC
Process (IPCP) Congestion Avoidance (CA) policies, orthogonal to
FRCP. Flow allocation, naming, and IPCP lifecycle are handled by
the IPC Resource Manager daemon (IRMd).

FRCT (Flow and Retransmission Control Task) is the libouroboros
implementation of FRCP; the task lives in <code>src/lib/frct.c</code>. The
remainder of this document describes the FRCP wire protocol and the
behaviour FRCT realises. Code symbols retain the <code>FRCT_</code> prefix
(<code>FRCT_DATA</code>, <code>FRCT_RXM</code>, ...) because they belong to the implementing
task; this document references them verbatim.

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in <code>BCP</code> 14 (Best
Current Practice; RFC 2119, RFC 8174) when, and only when, they
appear in all capitals.

== Notation ==

;<code>u32</code>, <code>u8</code>
:Unsigned 32-bit / 8-bit integers (kernel-C style).
;<code>ns</code>
:Nanoseconds.

Modular sequence-number comparators (32-bit, modulo 2^32):

;<code>before(a, b)</code>
:<code>(int32_t)(a - b) < 0</code>
;<code>after(a, b)</code>
:<code>before(b, a)</code>

Used throughout for <code>ackno</code> / <code>seqno</code> ordering checks.

Round-Trip Time (RTT) abbreviations used throughout:

;<code>SRTT</code>
:Smoothed RTT estimate (RFC 6298).
;<code>mdev</code>
:Mean deviation of RTT (Linux variance estimator).
;<code>EWMA</code>
:Exponentially Weighted Moving Average.
;<code>RTO</code>
:Retransmission Timeout, <code>max(RTO_MIN, srtt + (mdev << MDEV_MUL))</code>.

Timer-bound symbols <code>t_a</code> (a-timer, ACK delay) and <code>t_r</code> (r-timer,
retransmission window) are defined in [[#8. Retransmission|Section 8]]; <code>t_mpl</code> (Maximum
Packet Lifetime) is introduced in [[#2.1. Per-flow state|Section 2.1]] (the <code>inact</code> field)
with heritage in [[#15. Heritage and adopted techniques|Section 15]].

Wire-format diagrams follow the IETF convention: bit 0 is the
leftmost (most significant) bit and fields are in network byte
order unless stated otherwise.

__TOC__

== 1. Wire format ==

=== 1.1. PCI header ===

Fixed 16-octet base Protocol-Control Information (PCI) header
prefixed to every FRCP packet (RFC convention: bit 0 leftmost,
most-significant bit first). All multi-byte fields except <code>hcs</code>
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
[[#1.5. Stream PCI extension|Section 1.5]]); SACK and RTTP carry their own payloads after the
base PCI.

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | hcs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ackno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload (variable) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>flags</code>
:feature/type bitmap (see [[#1.2. Flag bits|Section 1.2]]).
;<code>hcs</code>
:CRC-16-CCITT-FALSE Header Check Sequence (HCS) over <code>flags</code> + <code>window</code> + <code>seqno</code> + <code>ackno</code> (+ stream extension when present); the two octets of the <code>hcs</code> field itself are omitted from the CRC input. Verified on receive before any flag-driven dispatch.
;<code>window</code>
:receiver-advertised right window edge (valid iff FC).
;<code>seqno</code>
:per-flow sequence number.
;<code>ackno</code>
:cumulative Acknowledgement (ACK) (valid iff ACK).

A single packet can simultaneously carry DATA + ACK + FC (Flow
Control) + RXM (Retransmission) by ORing flag bits; the PCI
multiplexes control on the same wire frame in the spirit of SCTP
chunk bundling (RFC 9260 sec. 6.10) and QUIC frame multiplexing
(RFC 9000 sec. 12.4). DATA-bearing packets carry the caller's
payload after the PCI; SACK (Selective Acknowledgement) and RTTP
(Round-Trip Time Probe) carry their own typed payloads after the
PCI.

Optional framing (per-flow, see [[#2.2. Service modes (orthogonal axes)|Section 2.2]]). On the wire, the
order from inside out is:

{| class="wikitable"
! Layer !! Scope
|-
| <code>[ PCI + body ]</code>
| The FRCP packet.
|-
| <code>[ PCI + body + CRC-32 ]</code>
| CRC-32 covers the body only (PCI is in HCS); appended iff <code>qs.ber == 0</code> on DATA, or on every SACK packet.
|-
| <code>[ AEAD-wrap of above ]</code>
| Iff Authenticated Encryption with Associated Data (AEAD) is enabled.
|}

* 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.
* 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>).

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

=== 1.2. Flag bits ===

Flag bits are numbered most-significant-bit first to match the wire
diagram (bit numbering per [[#1.1. PCI header|Section 1.1]]; bit 0 is the MSB of the
16-bit <code>flags</code> field and lands at wire-position 0 in network byte
order). Bits 13..15 are reserved and MUST be transmitted as zero.

{| class="wikitable"
! Bit !! Mask !! Name !! Meaning
|-
| 0 || <code>0x8000</code> || <code>DATA</code> || Carries caller payload
|-
| 1 || <code>0x4000</code> || <code>DRF</code> || Data Run Flag: start of a fresh run
|-
| 2 || <code>0x2000</code> || <code>ACK</code> || Acknowledgement: <code>ackno</code> field valid
|-
| 3 || <code>0x1000</code> || <code>NACK</code> || Negative ACK; <code>seqno = arrival_seqno-1</code>
|-
| 4 || <code>0x0800</code> || <code>FC</code> || Flow Control: <code>window</code> field valid (<code>rwe</code>)
|-
| 5 || <code>0x0400</code> || <code>RDVS</code> || Rendezvous probe (window-closed)
|-
| 6 || <code>0x0200</code> || <code>FFGM</code> || First Fragment (role bit 0; see below)
|-
| 7 || <code>0x0100</code> || <code>LFGM</code> || Last Fragment (role bit 1; see below)
|-
| 8 || <code>0x0080</code> || <code>RXM</code> || Retransmission
|-
| 9 || <code>0x0040</code> || <code>SACK</code> || Selective ACK block list in payload
|-
| 10 || <code>0x0020</code> || <code>RTTP</code> || RTT Probe / echo (payload follows)
|-
| 11 || <code>0x0010</code> || <code>KA</code> || Keepalive
|-
| 12 || <code>0x0008</code> || <code>FIN</code> || End-of-stream marker (stream mode)
|-
| 13-15 || -- || -- || Reserved (MUST be zero)
|}

The (<code>FFGM</code>, <code>LFGM</code>) pair encodes the fragment role of a DATA-bearing
Service Data Unit (SDU), SCTP-style begin/end flags (RFC 9260
sec. 3.3.1):

{| class="wikitable"
! FFGM !! LFGM !! Role
|-
| 1 || 1 || Sole / un-fragmented SDU (begin AND end)
|-
| 1 || 0 || First fragment of a multi-fragment SDU
|-
| 0 || 0 || Middle fragment
|-
| 0 || 1 || Last fragment
|}

Each fragment is carried in its own FRCP packet with its own <code>seqno</code>;
FRTX (the FRCT Retransmission service mode, see [[#2.2. Service modes (orthogonal axes)|Section 2.2]])
recovers individual fragments via the normal Retransmission Timeout
(RTO) / SACK / Recent Acknowledgement (RACK, RFC 8985) path. The
receiver reassembles the SDU at consume time once the contiguous
[FIRST .. LAST] run has fully arrived. On non-DATA packets the role
bits are unused and MUST be transmitted as zero.

In stream mode (<code>qos.service == SVC_STREAM</code>, see [[#16. Stream-mode flows|Section 16]]) there are
no SDU boundaries to encode, so <code>FFGM</code> and <code>LFGM</code> are unused and MUST
be transmitted as zero. End-of-stream uses a dedicated bit (<code>FIN</code>,
bit 12) carried on a 0-byte DATA packet, emitted at write-half close
(<code>fccntl</code> to <code>FLOWFRDONLY</code>), during linger drain, and at <code>flow_dealloc</code>;
emission is idempotent (first call wins). After contiguous delivery
of the FIN-bearing slot, the receiver latches <code>byte_fin</code> at the FIN's
start offset; <code>flow_read</code> returns 0 (end-of-file, <code>EOF</code>) once buffered
bytes have been drained up to <code>byte_fin</code>. Per-byte position is
carried by the [start, end) extension ([[#1.5. Stream PCI extension|Section 1.5]]).

=== 1.3. SACK payload ===

A SACK packet has the <code>FRCT_ACK | FRCT_FC | FRCT_SACK</code> flag bits set
(bit numbering per [[#1.1. PCI header|Section 1.1]]). Following the 16-octet PCI, the
payload is a 2-octet block count (network byte order), 2 octets of
padding to 4-byte align the block list, then <code>n_blocks</code> pairs of
32-bit start/end seqnos describing ''present'' (received) ranges
above the cumulative ACK.

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_blocks | padding (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start[0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end[0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... n_blocks pairs total ...
</syntaxhighlight>

<code>n_blocks <= SACK_MAX_BLOCKS</code> (2048). The per-flow effective cap is
further bounded by <code>(frag_mtu - PCI - 4) / 8</code> blocks per packet; SACK
packets carry no stream extension, so PCI here is the 16-octet base
header even on stream-mode flows.

Wire invariant: every block produced by the receiver, except an
optional leading Duplicate SACK (D-SACK) block as described below,
describes a range strictly above the cumulative ACK carried in the
PCI <code>ackno</code> field (<code>after(start[i], ackno)</code>). This makes the D-SACK
convention below unambiguous; the receiver-side builder MUST
preserve it.

Duplicate SACK (D-SACK, RFC 2883) is signalled in-band: no flag
bit, no extra framing. Modular seqno arithmetic uses the
<code>before()</code> / <code>after()</code> comparators defined in the Notation block.
<code>Block[0]</code> carries a D-SACK report when either:

;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.
;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.

Senders that do not implement D-SACK process <code>block[0]</code> through the
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
(cap 20), halve once per 16 cumulatively-ACK'd seqnos since the
most recent D-SACK arrival or halve event, reset to 1 on an RTO
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
count as gaps.

=== 1.4. RTTP payload ===

An RTTP (Round-Trip Time Probe) packet has only the <code>FRCT_RTTP</code> flag
set (bit numbering per [[#1.1. PCI header|Section 1.1]]). Following the 16-octet PCI,
the payload is 24 octets (packed):

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| probe_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| echo_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ nonce (16 octets, echoed verbatim) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>probe_id</code>
:sender counter, 0 on reply, 0 reserved.
;<code>echo_id</code>
:peer's <code>probe_id</code>, 0 on outbound probe.
;<code>nonce</code>
:random, echoed unmodified, memcmp'd to defeat spoof.

=== 1.5. Stream PCI extension ===

A stream-mode flow (<code>qos.service == SVC_STREAM</code>) carries an extra
8-octet extension after the 16-octet base PCI on every DATA packet
(bit numbering per [[#1.1. PCI header|Section 1.1]]):

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>start</code>
:octet offset of the first payload byte in the stream.
;<code>end</code>
:octet offset one past the last payload byte; <code>end - start</code> equals the on-wire payload length.

Total stream-mode PCI for DATA packets is 24 octets (16 base + 8
extension); control packets (SACK, RTTP, bare ACK, KA, etc.) retain
the 16-octet base PCI. Stream mode MUST be negotiated at flow
allocation; the extension is present iff stream mode is in use,
never on a per-packet basis. Both peers MUST treat <code>start</code>/<code>end</code> as
monotonic 32-bit byte offsets; when a slot reaches the head of the
contiguous run with <code>start</code> not equal to the prior packet's <code>end</code> the
slot is silently dropped at delivery time ([[#16. Stream-mode flows|Section 16]]) rather
than rejected at stash.

This is the QUIC STREAM-frame reassembly model (RFC 9000 sec. 19.8):
each packet carries its packet <code>seqno</code> (this PCI's <code>seqno</code> field) and a
separate stream byte position (<code>start</code>/<code>end</code>). Separating the two
avoids TCP's conflation of packet identity with byte position which
forces Karn's algorithm for Round-Trip Time (RTT) sampling (no RTT
sample on retransmits, RFC 6298 sec. 3); FRCP applies the
Karn-equivalent gate via a combination of per-packet <code>FRCT_RXM</code>,
per-slot <code>SND_RTX</code> flags, and a sample-fence <code>rtt_lwe</code> (see [[#2.1. Per-flow state|Section 2.1]]
and [[#12. RTT estimation|Section 12]]). FRCP's fixed-32-bit <code>start</code>/<code>end</code> wrap at 4 GiB of
wire bytes, narrower than QUIC's 62-bit varint offset (cf. RFC 9000
sec. 16); the on-wire wrap is handled by the same modular <code>before()</code>
/ <code>after()</code> comparators ([[#1.3. SACK payload|Section 1.3]]) FRCP uses for seqnos, which
remain unambiguous as long as the in-flight byte window stays
strictly under 2 GiB (the half-range of the signed-int32 difference
in <code>before()</code>). The default per-flow ring is 1 MiB; the
implementation caps <code>ring_sz</code> at 128 MiB (<code>FRCT_STREAM_RING_SZ_MAX</code>),
well below the 2 GiB half-range bound. The runtime byte counters
exposed via FUSE (Filesystem in Userspace) in the Ouroboros
Resource Information Base (RIB, a virtual-filesystem introspection
bridge) are platform <code>size_t</code> and do not wrap on 64-bit hosts.

== 2. Per-flow state and service modes ==

=== 2.1. Per-flow state ===

Each flow keeps a sender control record and a receiver control
record:

;<code>lwe</code> : <code>u32</code>
:snd: oldest unacked <code>seqno</code> (cumulative ACK boundary as seen by sender); rcv: next in-order <code>seqno</code> expected
;<code>rwe</code> : <code>u32</code>
:snd: peer-advertised right window edge; rcv: locally-advertised right window edge
;<code>cflags</code> : <code>u8</code>
:per-direction feature flags: retransmission (<code>FRCTFRTX</code>), receiver flow control (<code>FRCTFRESCNTL</code>), linger-on-close (<code>FRCTFLINGER</code>); see <code><ouroboros/fccntl.h></code>
;<code>seqno</code> : <code>u32</code>
:snd: next <code>seqno</code> to send; rcv: force-ACK trigger - set on a stale or dup DATA so the next <code>ack_snd</code> emits a fresh cumulative ACK
;<code>ackno</code> : <code>u32</code>
:snd: <code>seqno</code> counter for standalone ACK-bearing control packets (delayed ACK, SACK, final ACK on dealloc); not bumped on piggybacked ACK riding a DATA packet (which uses the DATA <code>seqno</code>). Used by wire-dup ACK detection; rcv: incoming-ACK dedup tracker
;<code>act</code> : <code>ns</code>
:last activity (used by inactivity / DRF)
;<code>inact</code> : <code>ns</code>
:inactivity threshold; sender = <code>3*mpl + a + r + 1s</code>, receiver = <code>2*mpl + a + r + 1s</code>. <code>mpl</code> is the Maximum Packet Lifetime (delta-t terminology; see [[#15. Heritage and adopted techniques|Section 15]]); <code>a</code> and <code>r</code> are the FRCT a-timer and r-timer bounds (see [[#8. Retransmission|Section 8]]). The asymmetry is load-bearing for pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]).

The sender holds a per-slot ring <code>snd_slots[RQ_SIZE]</code> keyed by
<code>(seqno mod RQ_SIZE)</code>. Each slot tracks its retransmit entry (<code>rxm</code>),
last-send timestamp, and retransmit flag bits: <code>SND_RTX</code> (a
retransmit is pending or has fired, gates the next RTT sample
under Karn) and <code>SND_FAST_RXM</code> (one-shot fast-retransmit staged for
this loss event).

The receiver holds a parallel reorder ring <code>rcv_slots[RQ_SIZE]</code>
(referred to as <code>rq[]</code> in prose) holding stashed out-of-order
packet-buffer indexes; both FRTX and best-effort flows share this
path. The invariant <code>rwe - lwe <= RQ_SIZE</code> holds: on each consume
the receiver advances <code>rwe</code> by the consumed count, capping the
receive window at <code>RQ_SIZE</code> <code>seqno</code> slots.

A separate fence variable <code>rtt_lwe</code> is bumped on every retransmit
(timer-fire, SACK-driven, fast-rxm, NACK-driven) and on every
<code>seqno_rotate</code> ([[#4. Sequence-number rotation (DRF)|Section 4]]) to mark the <code>seqno</code> range whose RTT samples
MUST be discarded.

=== 2.2. Service modes (orthogonal axes) ===

FRCP exposes its wire features as a vector of independent QoS
axes selected at flow allocation time. All flows go through the
same <code>flow_alloc(name, qos, ...)</code> primitive; the <code>qosspec_t</code> passed
in determines which protocol machinery engages on the wire. This
contrasts with the POSIX BSD socket model where TCP and UDP
require different socket types (<code>SOCK_STREAM</code> / <code>SOCK_DGRAM</code>).

The axes:

;<code>service</code>
:0 = unordered (no FRCP engagement: raw datagrams, no PCI on the wire, UDP-equivalent at this layer); 1 = message-ordered (FRCP engaged; SDU boundaries preserved across fragmentation); 2 = stream (byte-oriented, no SDU boundaries; FRTX required)
;<code>loss</code>
:0 = lossless service requested: FRTX retransmit machinery engages ([[#8. Retransmission|Section 8]]); MUST be 0 for <code>service=2</code>. Non-zero = best-effort, FRTX off.
;<code>ber</code>
:Bit Error Rate tolerance. 0 = error-free service requested: a CRC trailer is appended after the body of DATA packets and verified on receive (added / checked outside the FRCP PCI; see [[#1.1. PCI header|Section 1.1]]). Non-zero = peer accepts errors; trailer omitted. SACK control packets carry a CRC32 trailer regardless of <code>ber</code>; the <code>ber</code> gate applies to DATA only.
;<code>timeout</code>
:Peer-timeout (ms); 0 disables the keepalive timer. Independent of FRCP engagement.

Encryption is a separate per-flow attribute set at flow setup;
when enabled it wraps the FRCP packet (PCI + body, plus the CRC
trailer if any) under AEAD, expanding the <code>spb</code> by <code>headsz</code> + <code>tailsz</code>
octets (nonce / tag). The CRC trailer is currently kept inside
the AEAD wrap (see [[#1.1. PCI header|Section 1.1]]).

Reachable combinations exported by <code>include/ouroboros/qos.h</code>:

{| class="wikitable"
! Cube !! <code>service</code> !! <code>loss</code> !! <code>ber</code> !! Engaged
|-
| <code>qos_raw</code> || 0 || 1 || 1 || Raw passthrough
|-
| <code>qos_raw_safe</code> || 0 || 1 || 0 || Raw + CRC trailer
|-
| <code>qos_rt</code> || 1 || 1 || 1 || FRCP, no FRTX, no CRC
|-
| <code>qos_rt_safe</code> || 1 || 1 || 0 || FRCP, no FRTX, CRC
|-
| <code>qos_msg</code> || 1 || 0 || 0 || FRCP + FRTX
|-
| <code>qos_stream</code> || 2 || 0 || 0 || FRCP + FRTX, stream
|}

Forced couplings actually enforced by the public API:

* <code>service == SVC_STREAM</code> (2) requires <code>loss == 0</code>; <code>flow_alloc</code> / <code>flow_accept</code> reject the pair otherwise with <code>-EINVAL</code>.
* FRTX requires FRCP engagement (<code>service != SVC_RAW</code>); requesting <code>loss = 0</code> with <code>service = SVC_RAW</code> is structurally a no-op because no <code>frcti</code> is created.
* The <code>QOS_DISABLE_CRC</code> build flag globally forces <code>ber = 1</code>. Note: this flag defaults to ON, so default builds ship with CRC disabled until <code>QOS_DISABLE_CRC</code> is set to OFF.

Caveat: the API does NOT force <code>ber = 0</code> when <code>service != SVC_RAW</code>.
<code>qos_rt</code> has <code>service = SVC_MESSAGE</code> with <code>ber = 1</code>, which means the PCI
itself is not CRC-protected on that cube; the HCS ([[#1.1. PCI header|Section 1.1]])
remains the only integrity check on the header.

The FRCP-no-FRTX regime (<code>service = SVC_MESSAGE</code>, <code>loss > 0</code>) is meaningful
and live: sequence numbering, in-order delivery, flow-control
advertisement, KA, DRF rotation, and SDU fragmentation /
reassembly ([[#7.2. Fragmentation and reassembly|Section 7.2]]) all run. Lost packets are dropped
rather than retransmitted; a permanently-lost mid-fragment is
dropped via skip-past-gap once a later SDU is visible in the
reorder ring.

== 3. Protocol parameters ==

{| class="wikitable"
! Parameter !! Value !! Role
|-
| <code>RQ_SIZE</code> || compile-time, power of 2 (default 128) || Slot ring / rcv window width
|-
| <code>START_WINDOW</code> || compile-time, power of 2 (default 128) || Initial <code>rwe-lwe</code> after rotate
|-
| <code>RTO_MIN</code> || <code>MAX(250 us build-tunable, 1<<RXMQ_RES)</code>; per-flow via <code>fccntl</code> (<code>FRCTSRTOMIN</code>). Default ~1 ms with <code>RXMQ_RES=20</code>. || RTO floor; also floored at the retransmit-wheel resolution (~1 ms by default).
|-
| <code>MAX_RTO_MUL</code> || 20 || Backoff shift cap
|-
| RACK window <code>R</code> || <code>MIN(reo_wnd_mult * min_RTT/4, SRTT)</code> with <code>MIN_REORDER_NS = 250 us</code> floor; <code>reo_wnd_mult</code> scales on D-SACK, cap 20 || Reorder window; per RFC 8985 sec. 6.2; <code>reo_wnd_mult</code> per sec. 6.2 step 4
|-
| <code>MIN_RTT_WIN_NS</code> || 300 s (5 min, Linux <code>tcp_min_rtt_wlen</code>) || <code>min_RTT</code> windowed re-anchor
|-
| <code>REO_WND_MULT_MAX</code> || 20 (RFC 8985 sec. 6.2 step 4) || <code>reo_wnd_mult</code> cap
|-
| <code>REO_DECAY_PKTS</code> || 16 (RFC 8985 sec. 6.2 step 4 / <code>RACK.reo_wnd_persist</code>) || Fresh-ACK'd seq count per halving
|-
| <code>MAX_DSACK_LAG</code> || <code>RQ_SIZE</code> || D-SACK sanity cap
|-
| <code>RTT_QUARANTINE</code> || 32 (<code>seqno</code> steps) || NewReno gate pad
|-
| SACK rate-limit || <code>SACK_MIN_GAP_NS</code> (250 us, fixed) || Min SACK gap
|-
| <code>SACK_MAX_BLOCKS</code> || 2048 (wire cap; per-flow capped at <code>(frag_mtu-PCI-4)/8</code>) || Per-SACK block cap
|-
| <code>SACK_RXM_MAX</code> || 32 || Per-pass staged retransmit cap
|-
| <code>DUP_THRESH</code> || 3 (RFC 8985 default) || Hybrid fast-rxm trigger ([[#8. Retransmission|Section 8]])
|-
| <code>MDEV_MUL</code> || 2 (build-tunable via <code>FRCT_RTO_MDEV_MULTIPLIER</code>) || <code>mdev</code> shift in <code>RTO = srtt + (mdev << MDEV_MUL)</code>
|-
| RTTP nonce || 16 octets || Echoed verbatim
|-
| <code>RTTP_RING</code> || 8 || In-flight probes
|-
| RTT clamp || <code>16 * srtt</code> || Probe-sample upper bound (ACK-derived RTT samples gated by Karn / recovery only)
|-
| Cold-probe cadence || 100 ms (rx-driven; see [[#12. RTT estimation|Section 12]]) || Pre-<code>srtt</code> RTTP rate
|-
| <code>DELT_RDV</code> || 100 ms || RDVS emit cadence
|-
| <code>MAX_RDV</code> || 1 s || RDVS give-up
|-
| Delayed-ACK fire || <code>2 * TICTIME</code> (<code>TICTIME</code> = FRCT tick granularity, default 5 ms; <code>2*TICTIME = 10 ms</code> by default) || Fired after the first in-order DATA arrival; tick is build-tunable
|-
| NACK send cooldown || <code>srtt</code> when an <code>srtt</code> sample exists, else 100 ms || Pre-DRF NACK rate-limit
|-
| <code>MAX_SDU</code> || 1 MiB || Max reassembled SDU; configurable per flow
|}

The per-flow fragment Maximum Transmission Unit (MTU) is computed
at flow setup from the lower IPCP's mtu minus encryption
<code>headsz</code> / <code>tailsz</code> and CRC trailer; there is no FRCT-level default or
environment-variable override.

== 4. Sequence-number rotation (DRF) ==

The DRF (Data Run Flag) bit on an outbound packet means "this is
the start of a fresh data run" and is set whenever the sender has
nothing in flight (<code>snd_cr.seqno == snd_cr.lwe</code>).

Independently of that, if the sender has been idle longer than
<code>snd_cr.inact</code> AND the pipe is empty (<code>snd_cr.seqno == snd_cr.lwe</code>),
<code>seqno_rotate()</code> rolls a random new <code>seqno</code> before the send and
resets

<syntaxhighlight lang="text">
snd_cr.seqno = random()
snd_cr.lwe = snd_cr.seqno
snd_cr.rwe = snd_cr.seqno + START_WINDOW
rtt_lwe = snd_cr.seqno
in_recovery = false (recovery state, see Section 8)
recovery_high = snd_cr.seqno
</syntaxhighlight>

The receiver, on observing rcv-side inactivity
(<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
below). Non-DATA control packets pass through without the DRF
requirement. On DRF the receiver releases the <code>rq[]</code> slots and
rebases

<syntaxhighlight lang="text">
rcv_cr.lwe = seqno
rcv_cr.rwe = seqno + RQ_SIZE
rcv_cr.seqno = seqno
</syntaxhighlight>

If the inactive packet has DATA but no DRF, a rate-limited NACK is
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).

== 5. Send path ==

# If the SDU exceeds <code>(frag_mtu - data_hdr_len)</code>, the caller (<code>dev.c</code>) fans it out into <code>ceil(count / (frag_mtu - data_hdr_len))</code> fragments, each emitted via <code>frcti_snd</code> as its own DATA packet with a per-fragment role ([[#7.2. Fragmentation and reassembly|Section 7.2]]); both FRTX and best-effort flows fragment. Raw flows (no FRCP engagement, <code>qos.service == SVC_RAW</code>) carry no PCI and return <code>-EMSGSIZE</code> for any SDU larger than one packet at the layer below. An SDU that fits in a single packet is sent as SOLE. <code>frcti_snd</code> reserves PCI head room; sets DATA, plus DRF when the pipe is empty (<code>snd_cr.seqno == snd_cr.lwe</code>).
# <code>seqno_rotate()</code> if past sender inactivity and the pipe is empty ([[#4. Sequence-number rotation (DRF)|Section 4]]).
# Advertise FC (<code>pci.window = frcti_advert_rwe(frcti)</code>, i.e. <code>rcv_cr.rwe</code> clamped to <code>rcv_cr.lwe + ring_seq_cap</code> in stream mode) when the receiver side is recent: <code>now - rcv_cr.act < rcv_cr.inact</code>.
# Reliable mode (FRTX): leave <code>snd_cr.lwe</code> where it is; reset the slot at <code>RQ_SLOT(seqno)</code> (<code>snd_slots[p].time = now</code>, <code>snd_slots[p].flags = 0</code>); queue an <code>rxm_entry</code> (saves a packet copy, arms a wheel timer at <code>now + (rto << rto_mul)</code>). Piggyback ACK (<code>pci.ackno = rcv_cr.lwe</code>) while the a-timer for the most recent received DATA packet has not yet expired (<code>now - rcv_cr.act <= t_a</code>); on piggyback, set <code>rcv_cr.seqno = rcv_cr.lwe</code> so the next delayed-ACK fire is suppressed. See [[#8. Retransmission|Section 8]] for <code>t_a</code> / <code>t_r</code> semantics.
# Best-effort mode (no FRTX): advance <code>snd_cr.lwe</code> immediately (<code>snd_cr.lwe = snd_cr.lwe + 1</code>, <code>snd_cr.rwe = snd_cr.lwe + RQ_SIZE</code>); no retransmit state. No send-side RTT probe is armed in this mode (<code>rtt_probe_arm</code> requires an in-flight <code>seqno</code>, which best-effort never has); the rx-driven cold seeder in <code>frcti_rcv</code> is the only probe path.
# In reliable mode, optionally arm an RTT probe ([[#12. RTT estimation|Section 12]]).

== 6. Receive path ==

=== 6.1. Early-exit dispatch ===

Keepalive (KA), RTT probe (RTTP), pre-DRF NACK, and rendezvous
(RDVS) packets short-circuit out of <code>frcti_rcv</code> before the locked
main path; each handler takes its own lock internally.

<syntaxhighlight lang="text">
incoming packet
|
v
+---------+
| KA? |---yes--> ka_rcv ; return
+---------+
|no
v
+---------+
| RTTP? |---yes--> rttp_rcv; return
+---------+
|no
v
+---------+
| NACK? |---yes--> nack_rcv; return (see Section 9)
+---------+
|no
v
+---------+
| RDVS? |---yes--> rdv_rcv ; return (reply bare FC, ackno=0)
+---------+
|no
v
acquire wrlock; enter locked main path
</syntaxhighlight>

;<code>KA</code>
:refresh <code>t_ka_rcv</code>, honour piggybacked ACK.
;<code>RTTP</code>
:probe (echo back nonce) or echo (verify nonce, sample RTT).
;<code>NACK</code>
:pre-DRF, sender-side handler. See [[#9. Pre-DRF NACK|Section 9]].
;<code>RDVS</code>
:reply with a bare FC packet (<code>ackno = 0</code>); <code>rdlock</code> only.

=== 6.2. Locked main path ===

Steps below run with the per-flow <code>frcti.lock</code> held for writing
(<code>pthread_rwlock_wrlock</code>) unless noted.

;<code>rcv_inact_check</code>
:Only meaningful when the receive side is stale. On DRF (Data Run Flag): release <code>rq[]</code> slots, rebase <code>rcv_cr</code>, continue. On stale DATA without DRF: fire a pre-DRF NACK if cooldown allows ([[#9. Pre-DRF NACK|Section 9]]), then discard the packet; on cooldown, drop without sending a NACK (a pending cumulative ACK from <code>drop_packet</code> may still go out). Non-DATA, non-DRF arrivals bypass <code>rcv_inact_check</code> entirely; pure-DRF stale arrivals fall through after the DRF rebase branch.

;DATA-only act refresh
:Refresh <code>rcv_cr.act</code> only when <code>FRCT_DATA</code> is set, so that non-DATA packets never block the next DRF rebase.

;Wire-dup gate
:Before flag-driven dispatch, drop wire-duplicate ACKs and wire-duplicate DATA (<code>is_dup_ack</code> / <code>is_dup_data</code>). The DATA check is bypassed for <code>FRCT_RXM</code>-bearing arrivals so the piggybacked ACK / SACK / FC carried on a retransmitted DATA at an already-ACK'd <code>seqno</code> is still applied; the stale-in-window branch below then drops the packet.

;<code>ACK</code>
:Drop ACKs whose <code>ackno</code> falls outside <code>(snd_cr.lwe, snd_cr.seqno]</code>. If <code>ackno == snd_cr.lwe</code> (non-advancing cumulative ACK), drive RACK fast-retransmit consideration ([[#8. Retransmission|Section 8]]). Otherwise advance <code>snd_cr.lwe = ackno</code>, collapse <code>rto_mul</code> to 0 (Karn-gated by <code>SND_RTX</code> on the just-acknowledged slot, the old head-of-line), reset <code>dup_thresh</code> to 0, update <code>t_latest_ack</code> to the send-time of the slot at <code>ackno-1</code> (consumed by RACK and SACK below), decay <code>reo_wnd_mult</code> per RFC 8985 sec. 6.2 step 4, exit NewReno-careful recovery (see [[#8. Retransmission|Section 8]]) on <code>ackno >= recovery_high</code> or <code>ackno == snd_cr.seqno</code>, and feed an RTT sample if eligible ([[#12. RTT estimation|Section 12]]).

;<code>SACK</code>
:Walk the block list. For each block (a present range above <code>lwe</code>) NULL out <code>snd_slots[k].rxm</code>, clear the slot's per-send flags, and advance <code>t_latest_ack</code> to the latest send-time covered (the Forward Acknowledgement / fack equivalent, Mathis & Mahdavi 1996); the first block whose start clamps to <code>snd_cr.lwe</code> skips this fack update so that a head-of-line clamp does not falsely advance fack. For un-SACKed gaps below <code>hi_sacked</code>, stage a retransmit per slot that is (1) still owned (<code>rxm != NULL</code>), (2) not already <code>SND_FAST_RXM</code>, (3) not aged out past <code>t_r</code>, and (4) either outside the RACK reorder window <code>R</code> OR with <code>dup_thresh >= DUP_THRESH</code> (the RFC 8985 sec. 6.2 hybrid trigger). Mark the slot <code>SND_FAST_RXM</code> and NULL the <code>rxm</code> at stage time. Capped at <code>SACK_RXM_MAX</code> staged retransmits per receive pass; what's left rides the next SACK.

;<code>FC</code>
:Bump <code>snd_cr.rwe</code> (clamped to <code>lwe + RQ_SIZE</code>, never shrinks) and mark window open.

;<code>DATA</code>
:Bounds-check <code>seqno</code> against window. On stale-dup (<code>seqno < rcv_cr.lwe</code>), set <code>rcv_cr.seqno = seqno</code> to force a fresh ACK on the next <code>ack_snd</code>, then drop. On accept: both FRTX and best-effort stash the packet-buffer index into <code>rq[seqno mod RQ_SIZE]</code>. Fragments stash unchanged - the role bits are inspected only at consume time ([[#7.2. Fragmentation and reassembly|Section 7.2]]). On out-of-order arrival, build a SACK reply if not rate-limited (per [[#3. Protocol parameters|Section 3]]) and not deduplicated against the previous <code>(rcv_cr.lwe, n_blocks)</code> pair; D-SACK reports always bypass the dedup. If both rate-limit and dedup suppress the reply, neither SACK nor delayed-ACK fires (the sender picks up the gap on its next ACK). On in-order arrival, arm the delayed-ACK timer.

;<code>drop_packet</code> exit
:Releases the per-packet shared-memory buffer (<code>spb</code>), then calls <code>ack_snd</code> synchronously after the <code>spb</code> release to surface any pending cumulative ACK.

== 7. Read path and reassembly ==

=== 7.1. Read path ===

<code>flow_read</code> returns a full reassembled SDU (Service Data Unit) via
<code>frcti_consume</code> on every FRCP SDU-mode flow (FRTX or best-effort);
stream-mode is covered in [[#16. Stream-mode flows|Section 16]]. An incomplete head-of-line
(HoL) run yields <code>-EAGAIN</code>; an oversized run yields <code>-EMSGSIZE</code> (the
run is dropped so the flow does not stall). On best-effort flows,
a permanently-lost mid-fragment is dropped as soon as a later
complete SDU becomes visible in the ring ([[#7.2. Fragmentation and reassembly|Section 7.2]] skip-past-
gap).

Raw flows carry no <code>frcti</code>, so <code>flow_read</code> returns the next pending
packet-buffer index directly, with no role-bit inspection. (Raw
service is selected via <code>qos.service == SVC_RAW</code> at flow allocation,
which suppresses <code>frcti</code> creation.)

<code>frcti_pdu_ready</code> is the no-advance peek used by <code>fevent</code> (the
Ouroboros flow-event multiplexer, the <code>poll(2)</code>-equivalent on
flows). It returns ready only when the head-of-line run is
complete and the lead packet (a Protocol Data Unit, here one FRCP
packet) is present at <code>rcv_cr.rwe - RQ_SIZE</code>; any other state
(including the best-effort skip-past-gap case) returns not ready,
and <code>frcti_consume</code> is left to drop the broken prefix and re-
inspect.

=== 7.2. Fragmentation and reassembly ===

Send side (<code>flow_write_frag</code>). An SDU larger than
<code>(frag_mtu - PCI)</code> is split into <code>ceil(count / (frag_mtu - PCI))</code>
fragments; each fragment is its own FRCP packet with its own
<code>seqno</code> and a per-fragment role flag pair ([[#1.2. Flag bits|Section 1.2]]). Roles are
assigned at emit time:

{| class="wikitable"
! i !! Role
|-
| <code>n=1</code> || <code>SOLE</code>
|-
| <code>i=0</code> || <code>FIRST</code>
|-
| <code>i=n-1</code> || <code>LAST</code>
|-
| else || <code>MID</code>
|}

A mid-loop allocation or transmit failure may yield a partial
write: the call returns the bytes already enqueued (<code>off > 0</code>) or
the underlying error (<code>off == 0</code>). Best-effort flows fragment
identically; on the receiver, a partial run with a permanently-
lost fragment is dropped when a later complete SDU is visible in
the ring (see skip-past-gap below). Raw flows carry no PCI and
refuse anything larger than the layer's user MTU (<code>-EMSGSIZE</code>).

Wire-level recovery is fragment-agnostic on FRTX flows: each
fragment's <code>seqno</code> flows through SACK / RACK / RTO / NACK exactly
as for a SOLE DATA packet, and reassembly does not re-enter the
loss-detection path. Best-effort flows run the same <code>seqno</code>
machinery (DRF, FC, ACK piggyback, pre-DRF NACK emit) but queue
no <code>rxm</code> state at the sender, so a lost MID is unrecoverable;
skip-past-gap handles it (below).

Receive side. Fragments stash into <code>rq[seqno]</code> unchanged; role bits
are read only at consume time. <code>frag_run_inspect</code>, called from
<code>frcti_consume</code>, walks the ring starting at the oldest still-
undelivered <code>seqno</code> <code>base = rcv_cr.rwe - RQ_SIZE</code> (equal to <code>rcv_cr.lwe</code>
only when no partial run is in progress; during a partial run <code>lwe</code>
has already advanced past <code>base</code>). It produces one of three
outcomes:

{| class="wikitable"
! Outcome !! Cause
|-
| <code>DELIVER (n)</code>
| <code>rq[base]=SOLE</code> (<code>n=1</code>), or <code>rq[base]=FIRST</code> and a <code>LAST</code> follows in slots <code>[base+1..base+n-1]</code> with all intermediate roles in <code>{MID,FIRST,LAST}</code> contiguous.
|-
| <code>DROP (n)</code>
| <code>rq[base]</code> is <code>MID</code> or <code>LAST</code> without a preceding <code>FIRST</code> (<code>n=1</code>); a <code>FIRST..[non-LAST]..new-FIRST</code> or new-<code>SOLE</code> mid-run (drop the broken prefix with <code>n</code> = run length minus 1, so the new <code>FIRST</code>/<code>SOLE</code> stays); or, on best-effort flows, a gap at <code>base</code> with a <code>FIRST</code>/<code>SOLE</code> later in the ring (drop up to the new run start).
|-
| <code>NOT_READY</code>
| <code>rq[base]</code> absent or <code>FIRST..[non-LAST]</code> with no later <code>FIRST</code>/<code>SOLE</code> in the ring (FRTX waits for retx; best-effort waits for arrival).
|}

<code>DELIVER</code> triggers <code>frag_gather</code>: a scatter-gather <code>memcpy</code> of the <code>n</code>
consecutive fragments at <code>rq[base..base+n-1]</code> directly into the
caller's buffer; each per-packet shared-memory buffer (<code>spb</code>) is
released and <code>rwe</code> advances by <code>n</code>. <code>lwe</code> was already advanced
incrementally as each contiguous fragment arrived; <code>frag_gather</code>
only restores the fixed-width invariant <code>rwe == lwe + RQ_SIZE</code>.
No intermediate reassembly buffer is allocated.

<code>DROP</code> advances <code>rwe</code> past the broken prefix (releasing the <code>spb</code>s)
and pulls <code>lwe</code> up to the new trailing edge if needed; the next
consume retries from the new <code>base</code>. Oversize or arithmetically
overflowing delivery (sum of fragment lengths > <code>max_rcv_sdu</code>, sum
> caller's buffer, or running-sum overflow) also drops the run
with <code>-EMSGSIZE</code>.

Skip-past-gap (best-effort only). On FRTX, a gap in the run means
"waiting for retransmit" and <code>frag_run_inspect</code> returns <code>NOT_READY</code>.
On best-effort flows the gap is permanent, so <code>frag_run_inspect</code>
scans forward in the ring for the next <code>FIRST</code> or <code>SOLE</code>; if one is
visible within <code>RQ_SIZE</code>, it returns <code>DROP</code> for the broken prefix and
the consume loop retries at the new <code>lwe</code>. Memory hold is bounded
by <code>RQ_SIZE</code>; the partial releases on the next consume call once a
later complete run exists. Voice-like flows (one <code>SOLE</code> per SDU)
see no extra wait: any later <code>SOLE</code> makes the prior gap droppable
immediately.

The choice to defer reassembly to consume time keeps the receive
path zero-copy: fragments stay in the shared-memory ring until
the application pulls, and the SDU lands directly in the caller's
buffer.

== 8. Retransmission ==

FRCP is bounded by two delta-t-derived timers (Watson 1981, see
[[#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_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.

Each in-flight FRTX <code>seqno</code> owns one <code>rxm_entry</code>, armed in a hashed
timing wheel; the wheel deadline is the slot's next eligible
retransmit time.

;RTO timer
:On fire (<code>rxm_due</code>), re-emit with <code>FRCT_RXM</code>, mark <code>SND_RTX</code> (Karn-suppress next ACK's RTT sample), and (for the head-of-line (HoL) slot only) bump <code>rto_mul</code> up to <code>MAX_RTO_MUL</code>. Wheel deadline is <code>t_send + (rto << rto_mul)</code>. Re-armed unless consumed. The RTO timer also clears <code>SND_FAST_RXM</code> (re-arming fast-retransmit eligibility), resets <code>reo_wnd_mult</code> to 1 on a HoL fire (RFC 8985 sec. 6.2 step 4 reset clause), and marks the flow <code>ACL_FLOWDOWN</code> if its <code>frct_tx</code> call fails.

;r-timer guard
:Before any retransmit attempt, check <code>(now - t0)</code> against <code>t_r</code>. If exceeded, the slot is no longer eligible for retransmit. Only the RTO timer (<code>rxm_due</code>) treats r-timer expiry as terminal: it marks the flow <code>ACL_FLOWDOWN</code> (peer unreachable). Fast-retransmit, SACK-driven retransmit, and NACK-driven head-of-line re-emit silently skip aged-out slots and defer the flow-down decision to the next RTO fire.

;Fast retransmit (hybrid trigger, RFC 8985 sec. 6.2)
:On a non-advancing cumulative ACK with the scoreboard advanced, fire one fast retransmit when EITHER (a) the head-of-line slot's latest send is older than the RACK reorder window <code>R</code> ([[#3. Protocol parameters|Section 3]]) and not yet aged out, OR (b) the SACK <code>dup-thresh</code> count above <code>snd_cr.lwe</code> reaches <code>DUP_THRESH</code> (= 3, RFC 8985 sec. 6.2 step 4). Fires at most once per non-advancing cumulative-ACK value, gated by <code>rack_fired_lwe</code> (the <code>snd_cr.lwe</code> at which fast-retransmit last fired). Set <code>SND_FAST_RXM</code> on the slot (one-shot per-slot gate) and enter NewReno-style careful recovery (see NewReno below in this section).
:The RACK reorder window <code>R</code> uses the RFC 8985 sec. 6.2 form <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> with a <code>MIN_REORDER_NS = 250 us</code> floor. Before the first RTT sample seeds <code>min_rtt</code>, <code>R</code> falls back to <code>MIN(reo_wnd_mult * SRTT / 4, SRTT)</code>, still floored at <code>MIN_REORDER_NS</code> (consistent with the windowed-minimum fallback described in [[#12. RTT estimation|Section 12]]). <code>min_rtt</code> is a windowed minimum over the last <code>MIN_RTT_WIN_NS</code> = 5 min of RTT samples (matches the Linux <code>tcp_min_rtt_wlen</code> default) so a route change to a longer path eventually re-anchors the reorder window without relying on <code>reo_wnd_mult</code> growth alone.

;SACK-driven retransmit
:For each gap below <code>hi_sacked</code> whose slot is (1) still owned, (2) not already <code>SND_FAST_RXM</code>, (3) not aged out past <code>t_r</code>, and (4) either outside the RACK window <code>R</code> OR with <code>dup_thresh >= DUP_THRESH</code> (same hybrid as fast-retransmit, see [[#6.2. Locked main path|Section 6.2]]), re-emit. Each SACK-driven retransmit re-arms a fresh <code>rxm</code> so a lost retransmit can still be recovered by its own RTO timer.

;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.

== 9. Pre-DRF NACK ==

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.

;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>)
:When an incoming DATA packet has no DRF and rcv-side activity is older than <code>rcv_cr.inact</code>, the receiver emits a bare packet with <code>flags = FRCT_NACK</code> and <code>seqno = arrival_seqno - 1</code> (informational only, not consulted by the receive handler). The cooldown in [[#3. Protocol parameters|Section 3]] rate-limits the burst. Non-DATA non-DRF arrivals bypass <code>rcv_inact_check</code> entirely; non-DATA DRF still rebases via the DRF branch.

;Receive (<code>frcti_nack_rcv</code>)
: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 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.

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 ==

Cumulative ACK is <code>ackno = rcv_cr.lwe</code>. On out-of-order arrival the
receiver also emits a SACK packet ([[#1.3. SACK payload|Section 1.3]]) whose payload lists
''present'' blocks above <code>lwe</code> (analogous to TCP SACK / QUIC ACK
ranges). SACKs are rate-limited per [[#3. Protocol parameters|Section 3]] and suppressed when
neither <code>lwe</code> nor block count has changed since the last SACK.

D-SACK reports (RFC 2883) are emitted in-band as <code>block[0]</code> of an
otherwise normal SACK frame (see [[#1.3. SACK payload|Section 1.3]] for the encoding).
Two receiver triggers arm a pending D-SACK report (single-slot,
latest-wins):

* DATA arrival with <code>seqno < rcv_cr.lwe</code>, both wire-dup (no RXM, <code>is_dup_data</code> path) and retransmit (RXM, post-FC branch) (RFC 2883 sec. 4.1.1, full duplicate)
* <code>rq_accept</code> conflict, slot already occupied in <code>[lwe, rwe)</code> (RFC 2883 sec. 4.1.2, partial duplicate)

When a D-SACK is pending and the standard scoreboard SACK would be
suppressed by dedup or rate-limit, the report is emitted as a
stand-alone SACK frame through the normal <code>ack_snd</code> path; when a
D-SACK report is pending the path bypasses dedup and the <code>TICTIME</code>
rate-limit, but the a-timer suppression on rcv inactivity still
applies.

Bare ACKs are deferred via a per-flow delayed-ACK timer (one in
flight at a time, atomic test-and-set dedup; fires per [[#3. Protocol parameters|Section 3]]
after the first in-order arrival). Suppressed if (1) no new
<code>seqno</code>, (2) rcv side is inactive (older than <code>t_a</code>), or (3) the
sender just sent within <code>TICTIME</code>. A pending D-SACK ride-through
bypasses (1) and (3); the a-timer gate (2) is unconditional.

== 11. Flow control ==

The receiver advertises <code>rwe</code> in every FC field. The sender treats
its <code>snd_cr.rwe</code> as the absolute right edge: when
<code>snd_cr.seqno >= snd_cr.rwe</code> the window is closed and <code>flow_write</code>
yields. While closed, the sender periodically emits RDVS
(rendezvous) packets (cadence <code>DELT_RDV</code>); the receiver replies with
a bare FC packet (<code>ackno = 0</code>) that reopens the window. Once the
window has been closed for longer than <code>MAX_RDV</code> the sender stops
emitting RDVS but does not tear the flow down - the writer keeps
blocking until either a peer-driven FC arrives or the KA
(keepalive) / r-timer marks the flow.

<code>rwe</code> is clamped to <code>lwe + RQ_SIZE</code> on receipt and MUST NOT shrink:
a backward <code>rwe</code> is silently clamped to the current <code>snd_cr.rwe</code>;
the FC packet still reopens the window.

== 12. RTT estimation ==

Active RTTP probes ([[#1.4. RTTP payload|Section 1.4]]) carry a 32-bit <code>probe_id</code> (0
reserved) and a 16-byte random nonce echoed verbatim - defends
against spoofed replies. A ring of <code>RTTP_RING</code> in-flight probes is
kept; an echo whose <code>(id, nonce)</code> doesn't match the ring slot is
dropped. A single RTTP sample is clamped to <code>RTT_CLAMP_MUL * srtt</code>
(compile-time <code>RTT_CLAMP_MUL = 16</code>) once <code>srtt</code> is seeded; the first
cold-probe sample feeds <code>rtt_update</code> raw.

Probe arming gates:

;Cold (no <code>srtt</code> yet)
:the receive path arms at most one probe per 100 ms via <code>frcti_rcv_probe</code> (<code>PROBE_DUE_COLD</code>); arming requires an incoming packet. Active send-path arming bails while <code>srtt == 0</code>.
;Warm (<code>rtt_probe_arm</code>, called from <code>frcti_snd</code>)
:outstanding data (<code>snd_cr.seqno > snd_cr.lwe</code>), AND at least <code>2 * srtt</code> since <code>t_rcv_rtt</code> (last RTT receive of any kind), AND at least <code>srtt</code> since <code>t_snd_probe</code> (last probe emit).

Sample feeds either Linux's asymmetric <code>mdev</code> estimator
(<code>FRCT_LINUX_RTT_ESTIMATOR</code>, default ON) or RFC 6298 symmetric EWMA
(compile option). <code>srtt</code> is floored at 10 ms when seeded from a
hint, at 1 us after every update (including the first seeding
sample); <code>mdev</code> floored at 100 ns.

:<code>RTO = max(rto_min, 2 * srtt, srtt + (mdev << MDEV_MUL))</code>

(the <code>2 * srtt</code> floor is an FRCT addition not in RFC 6298).
Effective wheel deadline capped per [[#3. Protocol parameters|Section 3]].

ACK-derived samples (<code>frcti_ack_rcv</code> -> <code>rtt_sample_eligible</code>), beyond
the cum-ACK advance gate in <code>frcti_ack_rcv</code> (<code>ackno > lwe</code> and
<code>ackno <= seqno</code>), require all of: not in recovery; ACK packet does
not carry <code>FRCT_RXM</code>; HoL slot's <code>SND_RTX</code> bit clear; slot's <code>rxm</code>
pointer non-NULL (not SACK-consumed); <code>lwe</code> not below the <code>rtt_lwe</code>
fence; <code>srtt</code> already seeded by an RTTP probe. There is no ACK-only
seeding.

Every eligible sample also feeds <code>RACK.min_RTT</code> (RFC 8985 sec. 6.2)
via a windowed minimum: replace whenever the sample is strictly
smaller OR more than <code>MIN_RTT_WIN_NS</code> (5 min, matches Linux
<code>tcp_min_rtt_wlen</code>) has elapsed since the current min was set. The
downward branch is immediate (faster path picked up at once); the
upward branch is gated on the window (a transient queue burst does
not poison the estimate, but a sustained route change to a longer
path re-anchors <code>min_RTT</code> after at most one window). Seeded from
<code>rtt_hint</code> at <code>rtt_init</code>; 0 acts as the unset sentinel and the base
in <code>rack_reorder_window</code> falls back from <code>min_RTT</code> to <code>SRTT</code> (so
<code>R = mult * SRTT/4</code>, capped at <code>SRTT</code>, floored at <code>MIN_REORDER_NS</code>)
until the first sample. See [[#6.2. Locked main path|Section 6.2]].

== 13. Liveness (keepalive) ==

When <code>qs.timeout > 0</code> a per-flow KA (keepalive) timer is armed.
Arming uses <code>rcv_cr.act</code> for the deadline computation:

:<code>deadline = min(snd_act + qs.timeout/4, rcv_act + qs.timeout)</code>

(clamped to <code>now + qs.timeout/4</code> if already past). The timer fires
either on sender idleness (to send a KA) or on receiver idleness
(to declare the peer dead). On fire (<code>ka_snd</code>) the peer-dead test
uses <code>max(rcv_cr.act, t_ka_rcv)</code> so a recent KA reply counts even
when no DATA has arrived:

* If <code>now - max(rcv_cr.act, t_ka_rcv) > qs.timeout</code>, mark the flow <code>ACL_FLOWPEER</code> and notify the per-process flow-event set (<code>proc.fqset</code>) with <code>FLOW_PEER</code>.
* Else if <code>snd_idle > qs.timeout/4</code>, emit a bare <code>KA | ACK</code> (<code>ackno = rcv_cr.lwe</code>) and re-arm.
* Else just re-arm.

Note: <code>rx_rb</code> and <code>tx_rb</code> are the receive and transmit shared-memory
ring buffers. The r-timer raises <code>ACL_FLOWDOWN</code> on both (route is
broken); keepalive raises <code>ACL_FLOWPEER</code> on <code>rx_rb</code> only and notifies
the flow-event set (peer is silent, writer keeps <code>tx_rb</code> usable) -
distinct ACLs. <code>qs.timeout == 0</code> disables keepalive entirely; a
silent peer crash is then undetected.

== 14. Linger / teardown ==

On <code>flow_dealloc</code>, <code>frcti_dealloc</code> computes a grace timeout

:<code>max(rcv_cr.act + rcv_cr.inact, snd_cr.act + snd_cr.inact) - now</code>

(floored at 0 and converted to seconds) and returns it; <code>flow_dealloc</code>
forwards this to the IRMd as the dealloc grace. The IRMd, not FRCT,
performs the wait. Before computing the timeout, FRCT may emit a
final ACK when <code>rcv_cr.lwe != rcv_cr.seqno</code> (the peer has not been
told the most recent cumulative ACK) AND the rcv side has been
active within <code>t_a</code> (a-timer not aged out).

<code>FRCTFLINGER</code> is honoured only when <code>snd_cr.lwe < edge</code>, where <code>edge =
snd_fin_seqno</code> after FIN has been sent in stream mode and
<code>snd_cr.seqno</code> otherwise (data or FIN still in flight). The drain
itself runs in <code>flow_dealloc</code>'s <code>while (FRCTI_LINGERING)</code> loop, not in
<code>frcti_dealloc</code>.

The fd is single-reader / single-writer (documented in the
manpages). <code>flow_write</code> pumps <code>rx_rb</code> on every call (via
<code>flow_wait_window</code> -> <code>flow_drain_rx_nb</code>) and additionally blocks on
<code>rx_rb</code> when the send window is closed. A pure-writer thread thus
consumes ACKs without a dedicated reader.

== 15. Heritage and adopted techniques ==

Delta-t (Watson, 1981) is the primary heritage; FRCP descends from
the delta-t protocol family via the Recursive InterNetwork
Architecture (RINA; Day, "Patterns in Network Architecture", 2008,
ch. 9). Timer-based connection management
(no SYN/FIN handshake, per-flow state born on first DATA and
reclaimed after <code>t_mpl + a + r</code> of silence), the DRF marker, and the
<code>t_mpl</code> / <code>t_a</code> / <code>t_r</code> timers all come from delta-t. See Watson,
"Timer-Based Mechanisms in Reliable Transport Protocol Connection
Management", Computer Networks 5 (1981).

The unified <code>flow_alloc(name, qos, ...)</code> primitive and its
multi-axis QoS-cube argument ([[#2.2. Service modes (orthogonal axes)|Section 2.2]]) also come from RINA
(Day 2008, ch. 6; Grasa et al., "IRATI: investigating RINA as an
alternative to TCP/IP", Computer Networks 92 (2015)) - reliability,
ordering, CRC presence, and encryption are flow attributes, not
separate sockets or protocols.

The table below summarises additional adopted techniques and their
references.

{| class="wikitable"
! FRCP mechanism !! Heritage !! Reference / note
|-
| Random new <code>seqno</code> on <code>seqno_rotate</code> || TCP ISN || RFC 6528 (Gont & Bellovin, 2012). QUIC PN-space reset (RFC 9000 sec. 12.3) is a structural analogue.
|-
| Cumulative ACK, left-window-edge advance || TCP || RFC 793 / RFC 9293
|-
| Receive window with non-shrink rule || TCP || RFC 793 sec. 3.7 / RFC 9293 sec. 3.8.6; RFC 1122 sec. 4.2.2.16 for the explicit non-shrink prohibition
|-
| Modular <code>seqno</code> arithmetic (<code>before</code>/<code>after</code> helpers) || TCP || RFC 793 sec. 3.3 / RFC 9293 sec. 3.4
|-
| Selective ACK block list || TCP || RFC 2018 (Mathis et al., 1996). Encoded as a typed FRCP packet rather than a TCP option, so framing is closer to QUIC ACK frames. D-SACK (RFC 2883) carried in-band as <code>block[0]</code>; see [[#1.3. SACK payload|Section 1.3]].
|-
| NewReno-careful recovery with <code>recovery_high</code> gate || TCP || RFC 6582 (Henderson et al., 2012); QUIC builds on the same model in RFC 9002 sec. 7.3.2. Cwnd half absent (CC in IPCP).
|-
| RACK reordering window for fast retransmit || TCP || RFC 8985 (Cheng et al., 2021). FRCP <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> with a <code>MIN_REORDER_NS = 250 us</code> floor against <code>srtt</code> collapse; matches RFC 8985 sec. 6.2 and Linux <code>tcp_rack_reo_wnd</code>. DSACK-driven <code>reo_wnd_mult</code> (sec. 6.2 step 4) is adopted; see [[#1.3. SACK payload|Section 1.3]] for the wire encoding. The hybrid RACK-or-<code>DUP_THRESH</code> trigger from RFC 8985 sec. 6.2 step 4 is adopted ([[#8. Retransmission|Section 8]]). QUIC's analogue in RFC 9002 sec. 6.1.2 uses <code>max(srtt, latest_rtt)</code> as the base.
|-
| 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.
|-
| 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.
|-
| Delayed ACK with rate suppression || TCP || RFC 813 (Clark, 1982); RFC 1122 sec. 4.2.3.2; RFC 5681 sec. 4.2. Single-deadline coalescing rather than "ack-every-other-segment".
|-
| Zero-window-probe / persist-timer analogue (RDVS) || TCP || RFC 1122 sec. 4.2.2.17 / RFC 9293 sec. 3.8.6.1. RDVS solicits an FC reply, distinct from QUIC <code>DATA_BLOCKED</code> (RFC 9000 sec. 19.12), which is one-way notification. <code>MAX_RDV</code> give-up departs from TCP.
|-
| Multiplexed control on a single PCI || SCTP / QUIC || SCTP chunk bundling (RFC 9260 sec. 6.10); QUIC frame multiplexing (RFC 9000 sec. 12.4). Cleaner fit than TCP's separate-flag-bits design.
|-
| ACK ranges as multiple discontiguous acked blocks || QUIC || QUIC ACK frame (RFC 9000 sec. 19.3). FRCP SACK is conceptually QUIC-frame-shaped even though encoded as absolute <code>[start,end]</code> pairs.
|-
| Nonce-authenticated active RTT / liveness probing (RTTP) || QUIC <code>PATH_CHALLENGE</code> || <code>PATH_CHALLENGE</code> / <code>PATH_RESPONSE</code> (RFC 9000 sec. 8.2, sec. 19.17, sec. 19.18). WebRTC ICE consent-freshness (RFC 7675) is the same pattern. QUIC's nonce is 8 octets; FRCP chooses 16.
|-
| Probing distinct from keepalive || QUIC || KA timer answers "peer alive?", RTTP answers "path measurable?", as in QUIC PING (RFC 9000 sec. 19.2) vs <code>PATH_CHALLENGE</code>.
|-
| Bare KA + ACK keepalive packets || QUIC / SCTP || QUIC PING (RFC 9000 sec. 19.2); SCTP HEARTBEAT / HEARTBEAT-ACK (RFC 9260 sec. 8.3). SCTP HEARTBEAT also carries an opaque echoed blob, structurally similar to FRCP RTTP.
|-
| (<code>FFGM</code>, <code>LFGM</code>) fragment-role bits ([[#7.2. Fragmentation and reassembly|Section 7.2]]) || SCTP || RFC 9260 sec. 3.3.1 DATA chunk B/E bits encode the same four states (<code>B+E=SOLE</code>, <code>B-only=FIRST</code>, neither=<code>MID</code>, <code>E-only=LAST</code>). Each fragment carries its own <code>seqno</code>/TSN and is independently retransmitted.
|-
| Stream byte-offset reassembly (Sections [[#1.5. Stream PCI extension|1.5]], [[#16. Stream-mode flows|16]]) || QUIC || QUIC STREAM frame (RFC 9000 sec. 19.8) uses Offset + Length varints; FRCP uses fixed 32-bit <code>start</code> / <code>end</code>. One stream per flow vs QUIC's many streams multiplexed.
|-
| FIN end-of-stream marker (Sections [[#1.2. Flag bits|1.2]], [[#16. Stream-mode flows|16]]) || TCP / QUIC || TCP FIN flag (RFC 9293 sec. 3.1) closes one half of the byte stream; QUIC STREAM frame FIN bit (RFC 9000 sec. 19.8) does the same per stream with an immutable final-size invariance (RFC 9000 sec. 4.5: the final size is fixed once observed). FRCP's FIN consumes one packet <code>seqno</code> (not one byte of stream space) and is idempotent on the sender side.
|-
| Stream byte-credit flow control ([[#16. Stream-mode flows|Section 16]]) || QUIC || <code>MAX_STREAM_DATA</code> (RFC 9000 sec. 4.1, sec. 19.10). FRCP projects a per-flow byte budget onto the <code>seqno</code>-space <code>rwe</code>. Single stream per flow collapses QUIC's <code>MAX_DATA</code> / <code>MAX_STREAM_DATA</code> distinction.
|-
| Header protection (encrypted seqnos) || QUIC || QUIC RFC 9001 sec. 5.4 applies header protection on top of AEAD to mask the packet number. FRCP's per-flow AEAD wrap ([[#16. Stream-mode flows|Section 16]]) is wider: it encrypts the entire PCI including <code>seqno</code> because the IPCP below already routes, so no destination connection-ID needs to stay in clear (cf. RFC 9000 sec. 5.2).
|-
| Two-bit fragment role polarity || SCTP || The (<code>FFGM</code>, <code>LFGM</code>) pair follows SCTP B/E (begin = 1 / end = 1) rather than IPv4 MF (RFC 791 sec. 3.2), which has the inverse polarity (MF = 1 means NOT last).
|-
| Orthogonal reliability / ordering axes ([[#2.2. Service modes (orthogonal axes)|Section 2.2]]) || SCTP || PR-SCTP (RFC 3758, per-message partial reliability) and SCTP DATA U-bit (RFC 9260 sec. 3.3.1, per-message unordered) are the closest precedents for decoupling reliability from ordering; FRCP sets them per-flow rather than per-message.
|-
| Orthogonal CRC (<code>qs.ber == 0</code>) || UDP-Lite || RFC 3828 (Larzon et al., 2004) lets the sender pick a per-packet Checksum Coverage and the receiver enforce a locally configured minimum (no in-band negotiation; sec. 3.1, sec. 3.3). FRCP gates a full CRC trailer on <code>qs.ber == 0</code> at flow setup. Contrast TCP / SCTP (mandatory checksum) and QUIC (AEAD subsumes CRC).
|-
| Setup-time service negotiation || DCCP / SCTP / QUIC || DCCP Service Codes (RFC 4340 sec. 8.1.2, RFC 5595); SCTP INIT parameters (RFC 9260 sec. 3.3.2); QUIC transport parameters (RFC 9000 sec. 7.4). All negotiate service properties at connection setup; only RINA's QoS cube exposes them as an orthogonal vector.
|}

=== 15.1. Original to FRCP (no clean prior art) ===

* Pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]): receiver-driven nudge exploiting <code>snd_cr.inact > rcv_cr.inact</code>. Closest analogues are SCTP Gap Ack Blocks (RFC 9260 sec. 3.3.4) and DCCP Ack Vector (RFC 4340 sec. 11.4) - both let the receiver describe gaps to the sender, but neither targets the cross-epoch / pre-DRF case.
* <code>MAX_RDV</code> window-probe give-up: neither TCP (persist-timer probes until application or R2 abort, RFC 9293 sec. 3.8.6.1) nor QUIC has an explicit FC-give-up counter. A recursive-network choice: outer layers can drop the flow.
* Skip-past-gap reassembly ([[#7.2. Fragmentation and reassembly|Section 7.2]]): SCTP fragments and reassembles every flow regardless of reliability/ordering, using its own per-stream reassembly queue; QUIC fragments via STREAM offsets. FRCP fragments best-effort flows too, but the receiver drops the broken prefix the moment a later run-start (<code>FIRST</code> or <code>SOLE</code> role) is visible inside the <code>RQ_SIZE</code>-wide reorder ring - no IP-frag-style timeout, no SCTP-style explicit abort. If no later run-start arrives within the ring, <code>frag_run_inspect</code> returns <code>NOT_READY</code> and the partial run keeps its slots; the next inspect retries. The trade-off: a permanently-lost <code>MID</code> in a long isolated run holds slots until either a later <code>FIRST</code>/<code>SOLE</code> appears in the ring or the writer stops, at which point the slots are reclaimed on flow teardown.
* Reassembly deferred to consume time ([[#7.2. Fragmentation and reassembly|Section 7.2]]), message mode only (<code>qos.service == SVC_MESSAGE</code>): SCTP (RFC 9260 sec. 6.9), QUIC (RFC 9000 sec. 2.2), and TCP (RFC 9293) all hold reassembly state at the receive boundary. FRCP message-mode leaves fragments in the shared-memory ring until <code>flow_read</code> pulls and lands the SDU directly in the caller's buffer. Stream mode ([[#16. Stream-mode flows|Section 16]]) uses the standard QUIC-style direct ring placement on receive and does not defer. The optimisation is enabled by the Shared-Memory Subsystem (SSM) packet-buffer ring (see <code>struct ssm_pk_buff</code> at [[#1.1. PCI header|Section 1.1]]); the analogue is OS-level scatter-gather I/O (<code>recvmsg+iovec</code>), not a transport-layer prior art.
* TLP-equivalent tail-loss recovery (RFC 8985 sec. 7; RFC 9002 sec. 6.2): FRCP does not emit an explicit Tail Loss Probe packet, but the same goal is met implicitly by RACK loss detection ([[#8. Retransmission|Section 8]]) firing on a non-advancing cumulative ACK once the head-of-line slot ages past the RACK reorder window <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> - well below <code>RTO = max(2 * SRTT, SRTT + (mdev << MDEV_MUL))</code>. A receiver-driven nudge is also available via the pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]).

=== 15.2. Not adopted ===

* Slow start, congestion window (cwnd), Additive Increase / Multiplicative Decrease (AIMD), NewReno cwnd inflation. Congestion control lives in the IPCP CA policies and is driven by Explicit Congestion Notification (ECN, RFC 3168).
* Nagle / silly-window-syndrome (SWS) avoidance (RFC 896, RFC 1122 sec. 4.2.3.4). (Deferred work, not adopted in the current spec.)
* TCP Timestamps (RFC 7323) / Protection Against Wrapped Sequences (PAWS) - RTT measurement uses RTTP, not per-segment timestamps. A peer-supplied timestamp echoed on every ACK lets a malicious peer drive the <code>srtt</code> estimate arbitrarily low, collapsing the RTO and triggering a self-inflicted retransmit storm. RTTP confines RTT measurement to nonce-authenticated probe round-trips, where a forged echo is rejected before it can reach the estimator.
* ECN (Explicit Congestion Notification) response inside FRCP (consumed by IPCP Congestion Avoidance / CA).
* 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).

== 16. Stream-mode flows ==

When a flow is allocated with <code>qos.service == SVC_STREAM</code> both peers
switch to byte-stream semantics, layered on top of the FRTX reorder
machinery already described in Sections [[#6. Receive path|6]]-[[#8. Retransmission|8]].

=== 16.1. Send ===

The sender splits the caller's octets into chunks of at most
<code>(frag_mtu - base PCI - stream PCI extension)</code> octets (Sections [[#1.1. PCI header|1.1]]
and [[#1.5. Stream PCI extension|1.5]]). Each chunk is one DATA packet with its own <code>seqno</code> and a
<code>[start, end)</code> byte range copied from a monotonic stream counter.
In stream mode <code>FFGM</code> and <code>LFGM</code> are unused and MUST be transmitted as
zero; the per-byte position is carried by the <code>[start, end)</code>
extension instead.

End-of-stream is signalled with a 0-byte DATA packet that has <code>FIN</code>
(bit 12) set, emitted on the FIN triggers listed in [[#1.2. Flag bits|Section 1.2]]
(WR-half close, <code>flow_dealloc</code>, and any other path that yields the
final byte). The sender MUST emit at most one FIN per flow; its
<code>[start, end)</code> MUST equal <code>[final-byte, final-byte)</code> (i.e., empty
interval at the final byte position; final-size invariance,
analogous to QUIC RFC 9000 sec. 4.5). Idempotency is enforced by
an <code>snd_fin_sent</code> guard.

=== 16.2. Receive ===

On arrival the receiver places the payload directly into a per-flow
byte-indexed receive ring of width <code>ring_sz</code> (octets) at the position
indicated by <code>start</code>, with a two-segment <code>memcpy</code> across the ring
boundary if needed. Receipt is recorded in the FRTX reorder
machinery ([[#6.2. Locked main path|Section 6.2]]) augmented with the packet's <code>start</code>, <code>end</code>, and
FIN bit per slot. When a packet's <code>[start, end)</code> front-overlaps
bytes already at or below the byte high-water mark, the overlap is
trimmed before placement so the same byte is never written twice.
After stashing, the receiver advances <code>lwe</code> and the byte high-water
mark across any newly-contiguous prefix. Each slot advanced MUST
satisfy <code>start == the last-delivered slot's end</code>; a slot whose
<code>start</code> does not equal that <code>end</code> is silently dropped at delivery time
(the <code>seqno</code> is consumed, no stream bytes contributed) and the high-
water mark does not advance past it. The stream byte-stream
stalls at that point - there is no flow-tear-down on mismatch.
This filters spliced or off-path-injected slots that fall in
window without strong cryptographic authentication.

A FIN slot marks end-of-stream at advance time only if its byte
position equals the last-delivered slot's <code>end</code>; otherwise the FIN
is ignored and the corresponding <code>seqno</code> occupies a slot but
contributes no stream bytes. No packet buffer is held after the
ring copy.

=== 16.3. Read ===

<code>flow_read</code> returns up to <code>count</code> octets from the contiguous prefix
<code>[next, high-water)</code>, where <code>next</code> is the byte the application has
already consumed up to and <code>high-water</code> is the rightmost contiguous
byte received. When the stream is fully drained AND end-of-stream
(EOS) was observed (<code>next == EOS</code> byte position), <code>flow_read</code> returns
0 (<code>EOF</code>) - the same shape POSIX <code>read(2)</code> uses on TCP after a peer
FIN.

=== 16.4. Flow control ===

ACK / SACK / RACK / RTO machinery is unchanged; the FRTX reorder
ring is reused as a per-<code>seqno</code> received-bitmap. Let <code>per_pkt =
(frag_mtu - base PCI - stream PCI extension)</code>, the maximum stream-
byte payload one DATA packet can carry ([[#16.1. Send|Section 16.1]]). The
receive window advertised in FC is clamped so the byte window
(<code>ring_sz</code>) cannot be overrun: the <code>seqno</code>-space <code>rwe</code> is at most
<code>rcv_cr.lwe + ring_sz / per_pkt</code>.

This is the QUIC byte-credit flow-control model
(<code>MAX_STREAM_DATA</code>, RFC 9000 sec. 4.1 and sec. 19.10) projected onto
<code>seqno</code> space. With one stream per flow there is no <code>MAX_DATA</code> /
<code>MAX_STREAM_DATA</code> distinction. Receiver-side silly-window-syndrome
(SWS) avoidance (RFC 9293 sec. 3.8.6.2.2) is achieved by combining
the consume-time <code>rwe</code> bump with the global non-shrink rule from
[[#11. Flow control|Section 11]].

=== 16.5. Security considerations ===

Threat model. An attacker that can observe (on-path passive) or
predict (off-path blind) the flow's seqnos and byte offsets on an
unencrypted stream flow can inject DATA or FIN at any in-window
position. The in-line consistency checks above (<code>start</code> == prior
<code>end</code> on advance; FIN MUST be 0-byte; FIN MUST sit at the final
byte position) realise the spirit of RFC 5961's "sequence-window
plus exact-position match for control bits" without an explicit
challenge-ACK probe; they make a few specific blind attack shapes
harder but are not cryptographic authentication. This is
comparable to TCP without the TCP Authentication Option (TCP-AO,
RFC 5925), tighter than a
pre-RFC-5961 TCP stack, and roughly equivalent to a modern
RFC 5961 stack against blind off-path injection - none of these
help once the attacker can sniff. TLS over TCP (RFC 8446)
encrypts only the TCP payload and leaves TCP seqnos, ACKs, FIN,
and RST in the clear, so TLS does NOT defend against TCP-header-
level injection; QUIC (RFC 9000) hides packet numbers under
header protection (RFC 9001 sec. 5.4), so this specific weakness
does not apply to QUIC.

Mitigation: AEAD. When the flow has encryption enabled the
recommended AEAD ciphers (AES-GCM, RFC 5288; or ChaCha20-Poly1305,
RFC 8439) wrap the entire FRCP packet on the wire - PCI, stream
extension, body, and the CRC trailer when <code>ber == 0</code> - under a
per-flow symmetric key derived from the flow's own key exchange
([[#1.1. PCI header|Section 1.1]]). The AEAD tag (~2^-128 forgery probability)
dominates the CRC (~2^-32) for integrity in this mode but the CRC
trailer is currently retained inside the wrap (see [[#1.1. PCI header|Section 1.1]]).
Implementations MUST NOT rely on the security properties below
when a non-AEAD cipher (e.g. AES-CTR alone) is negotiated; non-
AEAD modes provide confidentiality only and the threat-model
claims do not hold.

With an AEAD cipher in use, seqnos, byte offsets, and the FIN bit
are both authenticated and confidential. Against an off-path or
on-path-passive attacker this is:

* Stronger than TCP+TLS (TCP header in the clear).
* Stronger than TCP+TCP-AO (header authenticated but visible).
* 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
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
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
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 MUST provide it at a higher
layer.

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.

== 17. References ==

This section lists the IETF documents, published works, and
source-code references cited inline elsewhere in this document.
IETF documents are cited inline as "RFC NNNN sec. X.Y"; books,
journal papers, and source-code references are cited inline by
author and year (or by file and function name) and are listed
here for convenience.

=== 17.1. IETF documents ===

;[RFC 791]
:J. Postel, "Internet Protocol", STD 5, RFC 791, September 1981.
;[RFC 793]
:J. Postel, "Transmission Control Protocol", STD 7, RFC 793, September 1981. Obsoleted by RFC 9293.
;[RFC 813]
:D. D. Clark, "Window and Acknowledgement Strategy in TCP", RFC 813, July 1982.
;[RFC 896]
:J. Nagle, "Congestion Control in IP/TCP Internetworks", RFC 896, January 1984.
;[RFC 1122]
:R. Braden (ed.), "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
;[RFC 2018]
:M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
;[RFC 2119]
:S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
;[RFC 2883]
:S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
;[RFC 3758]
:R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
;[RFC 3828]
:L-A. Larzon, M. Degermark, S. Pink, L-E. Jonsson (ed.), G. Fairhurst (ed.), "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
;[RFC 4303]
:S. Kent, "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
;[RFC 4340]
:E. Kohler, M. Handley, S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
;[RFC 5288]
:J. Salowey, A. Choudhury, D. McGrew, "AES Galois Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, August 2008.
;[RFC 5595]
:G. Fairhurst, "The Datagram Congestion Control Protocol (DCCP) Service Codes", RFC 5595, September 2009.
;[RFC 5681]
:M. Allman, V. Paxson, E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
;[RFC 5925]
:J. Touch, A. Mankin, R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
;[RFC 5961]
:A. Ramaiah, R. Stewart, M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, August 2010.
;[RFC 6298]
:V. Paxson, M. Allman, J. Chu, M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, June 2011.
;[RFC 6528]
:F. Gont, S. Bellovin, "Defending against Sequence Number Attacks", RFC 6528, February 2012. Obsoletes RFC 1948.
;[RFC 6582]
:T. Henderson, S. Floyd, A. Gurtov, Y. Nishida, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 6582, April 2012.
;[RFC 7323]
:D. Borman, B. Braden, V. Jacobson, R. Scheffenegger (ed.), "TCP Extensions for High Performance", RFC 7323, September 2014.
;[RFC 7675]
:M. Perumal, D. Wing, R. Ravindranath, T. Reddy, M. Thomson, "Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness", RFC 7675, October 2015.
;[RFC 8174]
:B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017.
;[RFC 8200]
:S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, July 2017.
;[RFC 8439]
:Y. Nir, A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 8439, June 2018.
;[RFC 8446]
:E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, August 2018.
;[RFC 8985]
:Y. Cheng, N. Cardwell, N. Dukkipati, P. Jha, "The RACK-TLP Loss Detection Algorithm for TCP", RFC 8985, February 2021.
;[RFC 9000]
:J. Iyengar (ed.), M. Thomson (ed.), "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, May 2021.
;[RFC 9001]
:M. Thomson (ed.), S. Turner (ed.), "Using TLS to Secure QUIC", RFC 9001, May 2021.
;[RFC 9002]
:J. Iyengar (ed.), I. Swett (ed.), "QUIC Loss Detection and Congestion Control", RFC 9002, May 2021.
;[RFC 9147]
:E. Rescorla, H. Tschofenig, N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, April 2022.
;[RFC 9260]
:R. Stewart, M. Tuexen, K. Nielsen, "Stream Control Transmission Protocol", RFC 9260, June 2022. Obsoletes RFC 4960.
;[RFC 9293]
:W. Eddy (ed.), "Transmission Control Protocol (TCP)", STD 7, RFC 9293, August 2022. Obsoletes RFC 793 and several follow-ons; updates RFC 1122 and others.

=== 17.2. Books and journal papers ===

;[Day08]
:J. Day, "Patterns in Network Architecture: A Return to Fundamentals", Prentice Hall, 2008.
;[Grasa15]
:E. Grasa et al., "IRATI: investigating RINA as an alternative to TCP/IP", Computer Networks, Vol. 92, December 2015.
;[KP87]
:P. Karn, C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", ACM SIGCOMM, August 1987.
;[Wat81]
:R. W. Watson, "Timer-Based Mechanisms in Reliable Transport Protocol Connection Management", Computer Networks, Vol. 5, 1981.

=== 17.3. Source-code references ===

;[Linux-RTT]
:<code>tcp_rtt_estimator()</code> in <code>net/ipv4/tcp_input.c</code> of the Linux kernel, defining the asymmetric <code>mdev</code> variance update used as FRCP's default RTT estimator ([[#12. RTT estimation|Section 12]]). Line-stable browseable copy at https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_input.c.

[[Category:Protocols]]
[[Category:Ouroboros internals]]

Flow and Retransmission Control Protocol

2026-05-17T14:40:10Z

Dimitri:

{{DISPLAYTITLE:FRCP - Flow and Retransmission Control Protocol}}

FRCP runs end-to-end between two peers over a flow. It delivers
reliability, in-order delivery, flow control, and liveness.
Congestion Control (CC) is not in FRCP - that lives in the IPC
Process (IPCP) Congestion Avoidance (CA) policies, orthogonal to
FRCP. Flow allocation, naming, and IPCP lifecycle are handled by
the IPC Resource Manager daemon (IRMd).

FRCT (Flow and Retransmission Control Task) is the libouroboros
implementation of FRCP; the task lives in <code>src/lib/frct.c</code>. The
remainder of this document describes the FRCP wire protocol and the
behaviour FRCT realises. Code symbols retain the <code>FRCT_</code> prefix
(<code>FRCT_DATA</code>, <code>FRCT_RXM</code>, ...) because they belong to the implementing
task; this document references them verbatim.

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in <code>BCP</code> 14 (Best
Current Practice; RFC 2119, RFC 8174) when, and only when, they
appear in all capitals.

== Notation ==

;<code>u32</code>, <code>u8</code>
:Unsigned 32-bit / 8-bit integers (kernel-C style).
;<code>ns</code>
:Nanoseconds.

Modular sequence-number comparators (32-bit, modulo 2^32):

;<code>before(a, b)</code>
:<code>(int32_t)(a - b) < 0</code>
;<code>after(a, b)</code>
:<code>before(b, a)</code>

Used throughout for <code>ackno</code> / <code>seqno</code> ordering checks.

Round-Trip Time (RTT) abbreviations used throughout:

;<code>SRTT</code>
:Smoothed RTT estimate (RFC 6298).
;<code>mdev</code>
:Mean deviation of RTT (Linux variance estimator).
;<code>EWMA</code>
:Exponentially Weighted Moving Average.
;<code>RTO</code>
:Retransmission Timeout, <code>max(RTO_MIN, srtt + (mdev << MDEV_MUL))</code>.

Timer-bound symbols <code>t_a</code> (a-timer, ACK delay) and <code>t_r</code> (r-timer,
retransmission window) are defined in [[#8. Retransmission|Section 8]]; <code>t_mpl</code> (Maximum
Packet Lifetime) is introduced in [[#2.1. Per-flow state|Section 2.1]] (the <code>inact</code> field)
with heritage in [[#15. Heritage and adopted techniques|Section 15]].

Wire-format diagrams follow the IETF convention: bit 0 is the
leftmost (most significant) bit and fields are in network byte
order unless stated otherwise.

__TOC__

== 1. Wire format ==

=== 1.1. PCI header ===

Fixed 16-octet base Protocol-Control Information (PCI) header
prefixed to every FRCP packet (RFC convention: bit 0 leftmost,
most-significant bit first). All multi-byte fields except <code>hcs</code>
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
[[#1.5. Stream PCI extension|Section 1.5]]); SACK and RTTP carry their own payloads after the
base PCI.

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | hcs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ackno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload (variable) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>flags</code>
:feature/type bitmap (see [[#1.2. Flag bits|Section 1.2]]).
;<code>hcs</code>
:CRC-16-CCITT-FALSE Header Check Sequence (HCS) over <code>flags</code> + <code>window</code> + <code>seqno</code> + <code>ackno</code> (+ stream extension when present); the two octets of the <code>hcs</code> field itself are omitted from the CRC input. Verified on receive before any flag-driven dispatch.
;<code>window</code>
:receiver-advertised right window edge (valid iff FC).
;<code>seqno</code>
:per-flow sequence number.
;<code>ackno</code>
:cumulative Acknowledgement (ACK) (valid iff ACK).

A single packet can simultaneously carry DATA + ACK + FC (Flow
Control) + RXM (Retransmission) by ORing flag bits; the PCI
multiplexes control on the same wire frame in the spirit of SCTP
chunk bundling (RFC 9260 sec. 6.10) and QUIC frame multiplexing
(RFC 9000 sec. 12.4). DATA-bearing packets carry the caller's
payload after the PCI; SACK (Selective Acknowledgement) and RTTP
(Round-Trip Time Probe) carry their own typed payloads after the
PCI.

Optional framing (per-flow, see [[#2.2. Service modes (orthogonal axes)|Section 2.2]]). On the wire, the
order from inside out is:

{| class="wikitable"
! Layer !! Scope
|-
| <code>[ PCI + body ]</code>
| The FRCP packet.
|-
| <code>[ PCI + body + CRC-32 ]</code>
| CRC-32 covers the body only (PCI is in HCS); appended iff <code>qs.ber == 0</code> on DATA, or on every SACK packet.
|-
| <code>[ AEAD-wrap of above ]</code>
| Iff Authenticated Encryption with Associated Data (AEAD) is enabled.
|}

* 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.
* 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>).

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

=== 1.2. Flag bits ===

Flag bits are numbered most-significant-bit first to match the wire
diagram (bit numbering per [[#1.1. PCI header|Section 1.1]]; bit 0 is the MSB of the
16-bit <code>flags</code> field and lands at wire-position 0 in network byte
order). Bits 13..15 are reserved and MUST be transmitted as zero.

{| class="wikitable"
! Bit !! Mask !! Name !! Meaning
|-
| 0 || <code>0x8000</code> || <code>DATA</code> || Carries caller payload
|-
| 1 || <code>0x4000</code> || <code>DRF</code> || Data Run Flag: start of a fresh run
|-
| 2 || <code>0x2000</code> || <code>ACK</code> || Acknowledgement: <code>ackno</code> field valid
|-
| 3 || <code>0x1000</code> || <code>NACK</code> || Negative ACK; <code>seqno = arrival_seqno-1</code>
|-
| 4 || <code>0x0800</code> || <code>FC</code> || Flow Control: <code>window</code> field valid (<code>rwe</code>)
|-
| 5 || <code>0x0400</code> || <code>RDVS</code> || Rendezvous probe (window-closed)
|-
| 6 || <code>0x0200</code> || <code>FFGM</code> || First Fragment (role bit 0; see below)
|-
| 7 || <code>0x0100</code> || <code>LFGM</code> || Last Fragment (role bit 1; see below)
|-
| 8 || <code>0x0080</code> || <code>RXM</code> || Retransmission
|-
| 9 || <code>0x0040</code> || <code>SACK</code> || Selective ACK block list in payload
|-
| 10 || <code>0x0020</code> || <code>RTTP</code> || RTT Probe / echo (payload follows)
|-
| 11 || <code>0x0010</code> || <code>KA</code> || Keepalive
|-
| 12 || <code>0x0008</code> || <code>FIN</code> || End-of-stream marker (stream mode)
|-
| 13-15 || -- || -- || Reserved (MUST be zero)
|}

The (<code>FFGM</code>, <code>LFGM</code>) pair encodes the fragment role of a DATA-bearing
Service Data Unit (SDU), SCTP-style begin/end flags (RFC 9260
sec. 3.3.1):

{| class="wikitable"
! FFGM !! LFGM !! Role
|-
| 1 || 1 || Sole / un-fragmented SDU (begin AND end)
|-
| 1 || 0 || First fragment of a multi-fragment SDU
|-
| 0 || 0 || Middle fragment
|-
| 0 || 1 || Last fragment
|}

Each fragment is carried in its own FRCP packet with its own <code>seqno</code>;
FRTX (the FRCT Retransmission service mode, see [[#2.2. Service modes (orthogonal axes)|Section 2.2]])
recovers individual fragments via the normal Retransmission Timeout
(RTO) / SACK / Recent Acknowledgement (RACK, RFC 8985) path. The
receiver reassembles the SDU at consume time once the contiguous
[FIRST .. LAST] run has fully arrived. On non-DATA packets the role
bits are unused and MUST be transmitted as zero.

In stream mode (<code>qos.service == SVC_STREAM</code>, see [[#16. Stream-mode flows|Section 16]]) there are
no SDU boundaries to encode, so <code>FFGM</code> and <code>LFGM</code> are unused and MUST
be transmitted as zero. End-of-stream uses a dedicated bit (<code>FIN</code>,
bit 12) carried on a 0-byte DATA packet, emitted at write-half close
(<code>fccntl</code> to <code>FLOWFRDONLY</code>), during linger drain, and at <code>flow_dealloc</code>;
emission is idempotent (first call wins). After contiguous delivery
of the FIN-bearing slot, the receiver latches <code>byte_fin</code> at the FIN's
start offset; <code>flow_read</code> returns 0 (end-of-file, <code>EOF</code>) once buffered
bytes have been drained up to <code>byte_fin</code>. Per-byte position is
carried by the [start, end) extension ([[#1.5. Stream PCI extension|Section 1.5]]).

=== 1.3. SACK payload ===

A SACK packet has the <code>FRCT_ACK | FRCT_FC | FRCT_SACK</code> flag bits set
(bit numbering per [[#1.1. PCI header|Section 1.1]]). Following the 16-octet PCI, the
payload is a 2-octet block count (network byte order), 2 octets of
padding to 4-byte align the block list, then <code>n_blocks</code> pairs of
32-bit start/end seqnos describing ''present'' (received) ranges
above the cumulative ACK.

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_blocks | padding (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start[0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end[0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... n_blocks pairs total ...
</syntaxhighlight>

<code>n_blocks <= SACK_MAX_BLOCKS</code> (2048). The per-flow effective cap is
further bounded by <code>(frag_mtu - PCI - 4) / 8</code> blocks per packet; SACK
packets carry no stream extension, so PCI here is the 16-octet base
header even on stream-mode flows.

Wire invariant: every block produced by the receiver, except an
optional leading Duplicate SACK (D-SACK) block as described below,
describes a range strictly above the cumulative ACK carried in the
PCI <code>ackno</code> field (<code>after(start[i], ackno)</code>). This makes the D-SACK
convention below unambiguous; the receiver-side builder MUST
preserve it.

Duplicate SACK (D-SACK, RFC 2883) is signalled in-band: no flag
bit, no extra framing. Modular seqno arithmetic uses the
<code>before()</code> / <code>after()</code> comparators defined in the Notation block.
<code>Block[0]</code> carries a D-SACK report when either:

;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.
;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.

Senders that do not implement D-SACK process <code>block[0]</code> through the
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
(cap 20), halve once per 16 cumulatively-ACK'd seqnos since the
most recent D-SACK arrival or halve event, reset to 1 on an RTO
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
count as gaps.

=== 1.4. RTTP payload ===

An RTTP (Round-Trip Time Probe) packet has only the <code>FRCT_RTTP</code> flag
set (bit numbering per [[#1.1. PCI header|Section 1.1]]). Following the 16-octet PCI,
the payload is 24 octets (packed):

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| probe_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| echo_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ nonce (16 octets, echoed verbatim) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>probe_id</code>
:sender counter, 0 on reply, 0 reserved.
;<code>echo_id</code>
:peer's <code>probe_id</code>, 0 on outbound probe.
;<code>nonce</code>
:random, echoed unmodified, memcmp'd to defeat spoof.

=== 1.5. Stream PCI extension ===

A stream-mode flow (<code>qos.service == SVC_STREAM</code>) carries an extra
8-octet extension after the 16-octet base PCI on every DATA packet
(bit numbering per [[#1.1. PCI header|Section 1.1]]):

<syntaxhighlight lang="text">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>start</code>
:octet offset of the first payload byte in the stream.
;<code>end</code>
:octet offset one past the last payload byte; <code>end - start</code> equals the on-wire payload length.

Total stream-mode PCI for DATA packets is 24 octets (16 base + 8
extension); control packets (SACK, RTTP, bare ACK, KA, etc.) retain
the 16-octet base PCI. Stream mode MUST be negotiated at flow
allocation; the extension is present iff stream mode is in use,
never on a per-packet basis. Both peers MUST treat <code>start</code>/<code>end</code> as
monotonic 32-bit byte offsets; when a slot reaches the head of the
contiguous run with <code>start</code> not equal to the prior packet's <code>end</code> the
slot is silently dropped at delivery time ([[#16. Stream-mode flows|Section 16]]) rather
than rejected at stash.

This is the QUIC STREAM-frame reassembly model (RFC 9000 sec. 19.8):
each packet carries its packet <code>seqno</code> (this PCI's <code>seqno</code> field) and a
separate stream byte position (<code>start</code>/<code>end</code>). Separating the two
avoids TCP's conflation of packet identity with byte position which
forces Karn's algorithm for Round-Trip Time (RTT) sampling (no RTT
sample on retransmits, RFC 6298 sec. 3); FRCP applies the
Karn-equivalent gate via a combination of per-packet <code>FRCT_RXM</code>,
per-slot <code>SND_RTX</code> flags, and a sample-fence <code>rtt_lwe</code> (see [[#2.1. Per-flow state|Section 2.1]]
and [[#12. RTT estimation|Section 12]]). FRCP's fixed-32-bit <code>start</code>/<code>end</code> wrap at 4 GiB of
wire bytes, narrower than QUIC's 62-bit varint offset (cf. RFC 9000
sec. 16); the on-wire wrap is handled by the same modular <code>before()</code>
/ <code>after()</code> comparators ([[#1.3. SACK payload|Section 1.3]]) FRCP uses for seqnos, which
remain unambiguous as long as the in-flight byte window stays
strictly under 2 GiB (the half-range of the signed-int32 difference
in <code>before()</code>). The default per-flow ring is 1 MiB; the
implementation caps <code>ring_sz</code> at 128 MiB (<code>FRCT_STREAM_RING_SZ_MAX</code>),
well below the 2 GiB half-range bound. The runtime byte counters
exposed via FUSE (Filesystem in Userspace) in the Ouroboros
Resource Information Base (RIB, a virtual-filesystem introspection
bridge) are platform <code>size_t</code> and do not wrap on 64-bit hosts.

== 2. Per-flow state and service modes ==

=== 2.1. Per-flow state ===

Each flow keeps a sender control record and a receiver control
record:

;<code>lwe</code> : <code>u32</code>
:snd: oldest unacked <code>seqno</code> (cumulative ACK boundary as seen by sender); rcv: next in-order <code>seqno</code> expected
;<code>rwe</code> : <code>u32</code>
:snd: peer-advertised right window edge; rcv: locally-advertised right window edge
;<code>cflags</code> : <code>u8</code>
:per-direction feature flags: retransmission (<code>FRCTFRTX</code>), receiver flow control (<code>FRCTFRESCNTL</code>), linger-on-close (<code>FRCTFLINGER</code>); see <code><ouroboros/fccntl.h></code>
;<code>seqno</code> : <code>u32</code>
:snd: next <code>seqno</code> to send; rcv: force-ACK trigger - set on a stale or dup DATA so the next <code>ack_snd</code> emits a fresh cumulative ACK
;<code>ackno</code> : <code>u32</code>
:snd: <code>seqno</code> counter for standalone ACK-bearing control packets (delayed ACK, SACK, final ACK on dealloc); not bumped on piggybacked ACK riding a DATA packet (which uses the DATA <code>seqno</code>). Used by wire-dup ACK detection; rcv: incoming-ACK dedup tracker
;<code>act</code> : <code>ns</code>
:last activity (used by inactivity / DRF)
;<code>inact</code> : <code>ns</code>
:inactivity threshold; sender = <code>3*mpl + a + r + 1s</code>, receiver = <code>2*mpl + a + r + 1s</code>. <code>mpl</code> is the Maximum Packet Lifetime (delta-t terminology; see [[#15. Heritage and adopted techniques|Section 15]]); <code>a</code> and <code>r</code> are the FRCT a-timer and r-timer bounds (see [[#8. Retransmission|Section 8]]). The asymmetry is load-bearing for pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]).

The sender holds a per-slot ring <code>snd_slots[RQ_SIZE]</code> keyed by
<code>(seqno mod RQ_SIZE)</code>. Each slot tracks its retransmit entry (<code>rxm</code>),
last-send timestamp, and retransmit flag bits: <code>SND_RTX</code> (a
retransmit is pending or has fired, gates the next RTT sample
under Karn) and <code>SND_FAST_RXM</code> (one-shot fast-retransmit staged for
this loss event).

The receiver holds a parallel reorder ring <code>rcv_slots[RQ_SIZE]</code>
(referred to as <code>rq[]</code> in prose) holding stashed out-of-order
packet-buffer indexes; both FRTX and best-effort flows share this
path. The invariant <code>rwe - lwe <= RQ_SIZE</code> holds: on each consume
the receiver advances <code>rwe</code> by the consumed count, capping the
receive window at <code>RQ_SIZE</code> <code>seqno</code> slots.

A separate fence variable <code>rtt_lwe</code> is bumped on every retransmit
(timer-fire, SACK-driven, fast-rxm, NACK-driven) and on every
<code>seqno_rotate</code> ([[#4. Sequence-number rotation (DRF)|Section 4]]) to mark the <code>seqno</code> range whose RTT samples
MUST be discarded.

=== 2.2. Service modes (orthogonal axes) ===

FRCP exposes its wire features as a vector of independent QoS
axes selected at flow allocation time. All flows go through the
same <code>flow_alloc(name, qos, ...)</code> primitive; the <code>qosspec_t</code> passed
in determines which protocol machinery engages on the wire. This
contrasts with the POSIX BSD socket model where TCP and UDP
require different socket types (<code>SOCK_STREAM</code> / <code>SOCK_DGRAM</code>).

The axes:

;<code>service</code>
:0 = unordered (no FRCP engagement: raw datagrams, no PCI on the wire, UDP-equivalent at this layer); 1 = message-ordered (FRCP engaged; SDU boundaries preserved across fragmentation); 2 = stream (byte-oriented, no SDU boundaries; FRTX required)
;<code>loss</code>
:0 = lossless service requested: FRTX retransmit machinery engages ([[#8. Retransmission|Section 8]]); MUST be 0 for <code>service=2</code>. Non-zero = best-effort, FRTX off.
;<code>ber</code>
:Bit Error Rate tolerance. 0 = error-free service requested: a CRC trailer is appended after the body of DATA packets and verified on receive (added / checked outside the FRCP PCI; see [[#1.1. PCI header|Section 1.1]]). Non-zero = peer accepts errors; trailer omitted. SACK control packets carry a CRC32 trailer regardless of <code>ber</code>; the <code>ber</code> gate applies to DATA only.
;<code>timeout</code>
:Peer-timeout (ms); 0 disables the keepalive timer. Independent of FRCP engagement.

Encryption is a separate per-flow attribute set at flow setup;
when enabled it wraps the FRCP packet (PCI + body, plus the CRC
trailer if any) under AEAD, expanding the <code>spb</code> by <code>headsz</code> + <code>tailsz</code>
octets (nonce / tag). The CRC trailer is currently kept inside
the AEAD wrap (see [[#1.1. PCI header|Section 1.1]]).

Reachable combinations exported by <code>include/ouroboros/qos.h</code>:

{| class="wikitable"
! Cube !! <code>service</code> !! <code>loss</code> !! <code>ber</code> !! Engaged
|-
| <code>qos_raw</code> || 0 || 1 || 1 || Raw passthrough
|-
| <code>qos_raw_safe</code> || 0 || 1 || 0 || Raw + CRC trailer
|-
| <code>qos_rt</code> || 1 || 1 || 1 || FRCP, no FRTX, no CRC
|-
| <code>qos_rt_safe</code> || 1 || 1 || 0 || FRCP, no FRTX, CRC
|-
| <code>qos_msg</code> || 1 || 0 || 0 || FRCP + FRTX
|-
| <code>qos_stream</code> || 2 || 0 || 0 || FRCP + FRTX, stream
|}

Forced couplings actually enforced by the public API:

* <code>service == SVC_STREAM</code> (2) requires <code>loss == 0</code>; <code>flow_alloc</code> / <code>flow_accept</code> reject the pair otherwise with <code>-EINVAL</code>.
* FRTX requires FRCP engagement (<code>service != SVC_RAW</code>); requesting <code>loss = 0</code> with <code>service = SVC_RAW</code> is structurally a no-op because no <code>frcti</code> is created.
* The <code>QOS_DISABLE_CRC</code> build flag globally forces <code>ber = 1</code>. Note: this flag defaults to ON, so default builds ship with CRC disabled until <code>QOS_DISABLE_CRC</code> is set to OFF.

Caveat: the API does NOT force <code>ber = 0</code> when <code>service != SVC_RAW</code>.
<code>qos_rt</code> has <code>service = SVC_MESSAGE</code> with <code>ber = 1</code>, which means the PCI
itself is not CRC-protected on that cube; the HCS ([[#1.1. PCI header|Section 1.1]])
remains the only integrity check on the header.

The FRCP-no-FRTX regime (<code>service = SVC_MESSAGE</code>, <code>loss > 0</code>) is meaningful
and live: sequence numbering, in-order delivery, flow-control
advertisement, KA, DRF rotation, and SDU fragmentation /
reassembly ([[#7.2. Fragmentation and reassembly|Section 7.2]]) all run. Lost packets are dropped
rather than retransmitted; a permanently-lost mid-fragment is
dropped via skip-past-gap once a later SDU is visible in the
reorder ring.

== 3. Protocol parameters ==

{| class="wikitable"
! Parameter !! Value !! Role
|-
| <code>RQ_SIZE</code> || compile-time, power of 2 (default 128) || Slot ring / rcv window width
|-
| <code>START_WINDOW</code> || compile-time, power of 2 (default 128) || Initial <code>rwe-lwe</code> after rotate
|-
| <code>RTO_MIN</code> || <code>MAX(250 us build-tunable, 1<<RXMQ_RES)</code>; per-flow via <code>fccntl</code> (<code>FRCTSRTOMIN</code>). Default ~1 ms with <code>RXMQ_RES=20</code>. || RTO floor; also floored at the retransmit-wheel resolution (~1 ms by default).
|-
| <code>MAX_RTO_MUL</code> || 20 || Backoff shift cap
|-
| RACK window <code>R</code> || <code>MIN(reo_wnd_mult * min_RTT/4, SRTT)</code> with <code>MIN_REORDER_NS = 250 us</code> floor; <code>reo_wnd_mult</code> scales on D-SACK, cap 20 || Reorder window; per RFC 8985 sec. 6.2; <code>reo_wnd_mult</code> per sec. 6.2 step 4
|-
| <code>MIN_RTT_WIN_NS</code> || 300 s (5 min, Linux <code>tcp_min_rtt_wlen</code>) || <code>min_RTT</code> windowed re-anchor
|-
| <code>REO_WND_MULT_MAX</code> || 20 (RFC 8985 sec. 6.2 step 4) || <code>reo_wnd_mult</code> cap
|-
| <code>REO_DECAY_PKTS</code> || 16 (RFC 8985 sec. 6.2 step 4 / <code>RACK.reo_wnd_persist</code>) || Fresh-ACK'd seq count per halving
|-
| <code>MAX_DSACK_LAG</code> || <code>RQ_SIZE</code> || D-SACK sanity cap
|-
| <code>RTT_QUARANTINE</code> || 32 (<code>seqno</code> steps) || NewReno gate pad
|-
| SACK rate-limit || <code>SACK_MIN_GAP_NS</code> (250 us, fixed) || Min SACK gap
|-
| <code>SACK_MAX_BLOCKS</code> || 2048 (wire cap; per-flow capped at <code>(frag_mtu-PCI-4)/8</code>) || Per-SACK block cap
|-
| <code>SACK_RXM_MAX</code> || 32 || Per-pass staged retransmit cap
|-
| <code>DUP_THRESH</code> || 3 (RFC 8985 default) || Hybrid fast-rxm trigger ([[#8. Retransmission|Section 8]])
|-
| <code>MDEV_MUL</code> || 2 (build-tunable via <code>FRCT_RTO_MDEV_MULTIPLIER</code>) || <code>mdev</code> shift in <code>RTO = srtt + (mdev << MDEV_MUL)</code>
|-
| RTTP nonce || 16 octets || Echoed verbatim
|-
| <code>RTTP_RING</code> || 8 || In-flight probes
|-
| RTT clamp || <code>16 * srtt</code> || Probe-sample upper bound (ACK-derived RTT samples gated by Karn / recovery only)
|-
| Cold-probe cadence || 100 ms (rx-driven; see [[#12. RTT estimation|Section 12]]) || Pre-<code>srtt</code> RTTP rate
|-
| <code>DELT_RDV</code> || 100 ms || RDVS emit cadence
|-
| <code>MAX_RDV</code> || 1 s || RDVS give-up
|-
| Delayed-ACK fire || <code>2 * TICTIME</code> (<code>TICTIME</code> = FRCT tick granularity, default 5 ms; <code>2*TICTIME = 10 ms</code> by default) || Fired after the first in-order DATA arrival; tick is build-tunable
|-
| NACK send cooldown || <code>srtt</code> when an <code>srtt</code> sample exists, else 100 ms || Pre-DRF NACK rate-limit
|-
| <code>MAX_SDU</code> || 1 MiB || Max reassembled SDU; configurable per flow
|}

The per-flow fragment Maximum Transmission Unit (MTU) is computed
at flow setup from the lower IPCP's mtu minus encryption
<code>headsz</code> / <code>tailsz</code> and CRC trailer; there is no FRCT-level default or
environment-variable override.

== 4. Sequence-number rotation (DRF) ==

The DRF (Data Run Flag) bit on an outbound packet means "this is
the start of a fresh data run" and is set whenever the sender has
nothing in flight (<code>snd_cr.seqno == snd_cr.lwe</code>).

Independently of that, if the sender has been idle longer than
<code>snd_cr.inact</code> AND the pipe is empty (<code>snd_cr.seqno == snd_cr.lwe</code>),
<code>seqno_rotate()</code> rolls a random new <code>seqno</code> before the send and
resets

<syntaxhighlight lang="text">
snd_cr.seqno = random()
snd_cr.lwe = snd_cr.seqno
snd_cr.rwe = snd_cr.seqno + START_WINDOW
rtt_lwe = snd_cr.seqno
in_recovery = false (recovery state, see Section 8)
recovery_high = snd_cr.seqno
</syntaxhighlight>

The receiver, on observing rcv-side inactivity
(<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
below). Non-DATA control packets pass through without the DRF
requirement. On DRF the receiver releases the <code>rq[]</code> slots and
rebases

<syntaxhighlight lang="text">
rcv_cr.lwe = seqno
rcv_cr.rwe = seqno + RQ_SIZE
rcv_cr.seqno = seqno
</syntaxhighlight>

If the inactive packet has DATA but no DRF, a rate-limited NACK is
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).

== 5. Send path ==

# If the SDU exceeds <code>(frag_mtu - data_hdr_len)</code>, the caller (<code>dev.c</code>) fans it out into <code>ceil(count / (frag_mtu - data_hdr_len))</code> fragments, each emitted via <code>frcti_snd</code> as its own DATA packet with a per-fragment role ([[#7.2. Fragmentation and reassembly|Section 7.2]]); both FRTX and best-effort flows fragment. Raw flows (no FRCP engagement, <code>qos.service == SVC_RAW</code>) carry no PCI and return <code>-EMSGSIZE</code> for any SDU larger than one packet at the layer below. An SDU that fits in a single packet is sent as SOLE. <code>frcti_snd</code> reserves PCI head room; sets DATA, plus DRF when the pipe is empty (<code>snd_cr.seqno == snd_cr.lwe</code>).
# <code>seqno_rotate()</code> if past sender inactivity and the pipe is empty ([[#4. Sequence-number rotation (DRF)|Section 4]]).
# Advertise FC (<code>pci.window = frcti_advert_rwe(frcti)</code>, i.e. <code>rcv_cr.rwe</code> clamped to <code>rcv_cr.lwe + ring_seq_cap</code> in stream mode) when the receiver side is recent: <code>now - rcv_cr.act < rcv_cr.inact</code>.
# Reliable mode (FRTX): leave <code>snd_cr.lwe</code> where it is; reset the slot at <code>RQ_SLOT(seqno)</code> (<code>snd_slots[p].time = now</code>, <code>snd_slots[p].flags = 0</code>); queue an <code>rxm_entry</code> (saves a packet copy, arms a wheel timer at <code>now + (rto << rto_mul)</code>). Piggyback ACK (<code>pci.ackno = rcv_cr.lwe</code>) while the a-timer for the most recent received DATA packet has not yet expired (<code>now - rcv_cr.act <= t_a</code>); on piggyback, set <code>rcv_cr.seqno = rcv_cr.lwe</code> so the next delayed-ACK fire is suppressed. See [[#8. Retransmission|Section 8]] for <code>t_a</code> / <code>t_r</code> semantics.
# Best-effort mode (no FRTX): advance <code>snd_cr.lwe</code> immediately (<code>snd_cr.lwe = snd_cr.lwe + 1</code>, <code>snd_cr.rwe = snd_cr.lwe + RQ_SIZE</code>); no retransmit state. No send-side RTT probe is armed in this mode (<code>rtt_probe_arm</code> requires an in-flight <code>seqno</code>, which best-effort never has); the rx-driven cold seeder in <code>frcti_rcv</code> is the only probe path.
# In reliable mode, optionally arm an RTT probe ([[#12. RTT estimation|Section 12]]).

== 6. Receive path ==

=== 6.1. Early-exit dispatch ===

Keepalive (KA), RTT probe (RTTP), pre-DRF NACK, and rendezvous
(RDVS) packets short-circuit out of <code>frcti_rcv</code> before the locked
main path; each handler takes its own lock internally.

<syntaxhighlight lang="text">
incoming packet
|
v
+---------+
| KA? |---yes--> ka_rcv ; return
+---------+
|no
v
+---------+
| RTTP? |---yes--> rttp_rcv; return
+---------+
|no
v
+---------+
| NACK? |---yes--> nack_rcv; return (see Section 9)
+---------+
|no
v
+---------+
| RDVS? |---yes--> rdv_rcv ; return (reply bare FC, ackno=0)
+---------+
|no
v
acquire wrlock; enter locked main path
</syntaxhighlight>

;<code>KA</code>
:refresh <code>t_ka_rcv</code>, honour piggybacked ACK.
;<code>RTTP</code>
:probe (echo back nonce) or echo (verify nonce, sample RTT).
;<code>NACK</code>
:pre-DRF, sender-side handler. See [[#9. Pre-DRF NACK|Section 9]].
;<code>RDVS</code>
:reply with a bare FC packet (<code>ackno = 0</code>); <code>rdlock</code> only.

=== 6.2. Locked main path ===

Steps below run with the per-flow <code>frcti.lock</code> held for writing
(<code>pthread_rwlock_wrlock</code>) unless noted.

;<code>rcv_inact_check</code>
:Only meaningful when the receive side is stale. On DRF (Data Run Flag): release <code>rq[]</code> slots, rebase <code>rcv_cr</code>, continue. On stale DATA without DRF: fire a pre-DRF NACK if cooldown allows ([[#9. Pre-DRF NACK|Section 9]]), then discard the packet; on cooldown, drop without sending a NACK (a pending cumulative ACK from <code>drop_packet</code> may still go out). Non-DATA, non-DRF arrivals bypass <code>rcv_inact_check</code> entirely; pure-DRF stale arrivals fall through after the DRF rebase branch.

;DATA-only act refresh
:Refresh <code>rcv_cr.act</code> only when <code>FRCT_DATA</code> is set, so that non-DATA packets never block the next DRF rebase.

;Wire-dup gate
:Before flag-driven dispatch, drop wire-duplicate ACKs and wire-duplicate DATA (<code>is_dup_ack</code> / <code>is_dup_data</code>). The DATA check is bypassed for <code>FRCT_RXM</code>-bearing arrivals so the piggybacked ACK / SACK / FC carried on a retransmitted DATA at an already-ACK'd <code>seqno</code> is still applied; the stale-in-window branch below then drops the packet.

;<code>ACK</code>
:Drop ACKs whose <code>ackno</code> falls outside <code>(snd_cr.lwe, snd_cr.seqno]</code>. If <code>ackno == snd_cr.lwe</code> (non-advancing cumulative ACK), drive RACK fast-retransmit consideration ([[#8. Retransmission|Section 8]]). Otherwise advance <code>snd_cr.lwe = ackno</code>, collapse <code>rto_mul</code> to 0 (Karn-gated by <code>SND_RTX</code> on the just-acknowledged slot, the old head-of-line), reset <code>dup_thresh</code> to 0, update <code>t_latest_ack</code> to the send-time of the slot at <code>ackno-1</code> (consumed by RACK and SACK below), decay <code>reo_wnd_mult</code> per RFC 8985 sec. 6.2 step 4, exit NewReno-careful recovery (see [[#8. Retransmission|Section 8]]) on <code>ackno >= recovery_high</code> or <code>ackno == snd_cr.seqno</code>, and feed an RTT sample if eligible ([[#12. RTT estimation|Section 12]]).

;<code>SACK</code>
:Walk the block list. For each block (a present range above <code>lwe</code>) NULL out <code>snd_slots[k].rxm</code>, clear the slot's per-send flags, and advance <code>t_latest_ack</code> to the latest send-time covered (the Forward Acknowledgement / fack equivalent, Mathis & Mahdavi 1996); the first block whose start clamps to <code>snd_cr.lwe</code> skips this fack update so that a head-of-line clamp does not falsely advance fack. For un-SACKed gaps below <code>hi_sacked</code>, stage a retransmit per slot that is (1) still owned (<code>rxm != NULL</code>), (2) not already <code>SND_FAST_RXM</code>, (3) not aged out past <code>t_r</code>, and (4) either outside the RACK reorder window <code>R</code> OR with <code>dup_thresh >= DUP_THRESH</code> (the RFC 8985 sec. 6.2 hybrid trigger). Mark the slot <code>SND_FAST_RXM</code> and NULL the <code>rxm</code> at stage time. Capped at <code>SACK_RXM_MAX</code> staged retransmits per receive pass; what's left rides the next SACK.

;<code>FC</code>
:Bump <code>snd_cr.rwe</code> (clamped to <code>lwe + RQ_SIZE</code>, never shrinks) and mark window open.

;<code>DATA</code>
:Bounds-check <code>seqno</code> against window. On stale-dup (<code>seqno < rcv_cr.lwe</code>), set <code>rcv_cr.seqno = seqno</code> to force a fresh ACK on the next <code>ack_snd</code>, then drop. On accept: both FRTX and best-effort stash the packet-buffer index into <code>rq[seqno mod RQ_SIZE]</code>. Fragments stash unchanged - the role bits are inspected only at consume time ([[#7.2. Fragmentation and reassembly|Section 7.2]]). On out-of-order arrival, build a SACK reply if not rate-limited (per [[#3. Protocol parameters|Section 3]]) and not deduplicated against the previous <code>(rcv_cr.lwe, n_blocks)</code> pair; D-SACK reports always bypass the dedup. If both rate-limit and dedup suppress the reply, neither SACK nor delayed-ACK fires (the sender picks up the gap on its next ACK). On in-order arrival, arm the delayed-ACK timer.

;<code>drop_packet</code> exit
:Releases the per-packet shared-memory buffer (<code>spb</code>), then calls <code>ack_snd</code> synchronously after the <code>spb</code> release to surface any pending cumulative ACK.

== 7. Read path and reassembly ==

=== 7.1. Read path ===

<code>flow_read</code> returns a full reassembled SDU (Service Data Unit) via
<code>frcti_consume</code> on every FRCP SDU-mode flow (FRTX or best-effort);
stream-mode is covered in [[#16. Stream-mode flows|Section 16]]. An incomplete head-of-line
(HoL) run yields <code>-EAGAIN</code>; an oversized run yields <code>-EMSGSIZE</code> (the
run is dropped so the flow does not stall). On best-effort flows,
a permanently-lost mid-fragment is dropped as soon as a later
complete SDU becomes visible in the ring ([[#7.2. Fragmentation and reassembly|Section 7.2]] skip-past-
gap).

Raw flows carry no <code>frcti</code>, so <code>flow_read</code> returns the next pending
packet-buffer index directly, with no role-bit inspection. (Raw
service is selected via <code>qos.service == SVC_RAW</code> at flow allocation,
which suppresses <code>frcti</code> creation.)

<code>frcti_pdu_ready</code> is the no-advance peek used by <code>fevent</code> (the
Ouroboros flow-event multiplexer, the <code>poll(2)</code>-equivalent on
flows). It returns ready only when the head-of-line run is
complete and the lead packet (a Protocol Data Unit, here one FRCP
packet) is present at <code>rcv_cr.rwe - RQ_SIZE</code>; any other state
(including the best-effort skip-past-gap case) returns not ready,
and <code>frcti_consume</code> is left to drop the broken prefix and re-
inspect.

=== 7.2. Fragmentation and reassembly ===

Send side (<code>flow_write_frag</code>). An SDU larger than
<code>(frag_mtu - PCI)</code> is split into <code>ceil(count / (frag_mtu - PCI))</code>
fragments; each fragment is its own FRCP packet with its own
<code>seqno</code> and a per-fragment role flag pair ([[#1.2. Flag bits|Section 1.2]]). Roles are
assigned at emit time:

{| class="wikitable"
! i !! Role
|-
| <code>n=1</code> || <code>SOLE</code>
|-
| <code>i=0</code> || <code>FIRST</code>
|-
| <code>i=n-1</code> || <code>LAST</code>
|-
| else || <code>MID</code>
|}

A mid-loop allocation or transmit failure may yield a partial
write: the call returns the bytes already enqueued (<code>off > 0</code>) or
the underlying error (<code>off == 0</code>). Best-effort flows fragment
identically; on the receiver, a partial run with a permanently-
lost fragment is dropped when a later complete SDU is visible in
the ring (see skip-past-gap below). Raw flows carry no PCI and
refuse anything larger than the layer's user MTU (<code>-EMSGSIZE</code>).

Wire-level recovery is fragment-agnostic on FRTX flows: each
fragment's <code>seqno</code> flows through SACK / RACK / RTO / NACK exactly
as for a SOLE DATA packet, and reassembly does not re-enter the
loss-detection path. Best-effort flows run the same <code>seqno</code>
machinery (DRF, FC, ACK piggyback, pre-DRF NACK emit) but queue
no <code>rxm</code> state at the sender, so a lost MID is unrecoverable;
skip-past-gap handles it (below).

Receive side. Fragments stash into <code>rq[seqno]</code> unchanged; role bits
are read only at consume time. <code>frag_run_inspect</code>, called from
<code>frcti_consume</code>, walks the ring starting at the oldest still-
undelivered <code>seqno</code> <code>base = rcv_cr.rwe - RQ_SIZE</code> (equal to <code>rcv_cr.lwe</code>
only when no partial run is in progress; during a partial run <code>lwe</code>
has already advanced past <code>base</code>). It produces one of three
outcomes:

{| class="wikitable"
! Outcome !! Cause
|-
| <code>DELIVER (n)</code>
| <code>rq[base]=SOLE</code> (<code>n=1</code>), or <code>rq[base]=FIRST</code> and a <code>LAST</code> follows in slots <code>[base+1..base+n-1]</code> with all intermediate roles in <code>{MID,FIRST,LAST}</code> contiguous.
|-
| <code>DROP (n)</code>
| <code>rq[base]</code> is <code>MID</code> or <code>LAST</code> without a preceding <code>FIRST</code> (<code>n=1</code>); a <code>FIRST..[non-LAST]..new-FIRST</code> or new-<code>SOLE</code> mid-run (drop the broken prefix with <code>n</code> = run length minus 1, so the new <code>FIRST</code>/<code>SOLE</code> stays); or, on best-effort flows, a gap at <code>base</code> with a <code>FIRST</code>/<code>SOLE</code> later in the ring (drop up to the new run start).
|-
| <code>NOT_READY</code>
| <code>rq[base]</code> absent or <code>FIRST..[non-LAST]</code> with no later <code>FIRST</code>/<code>SOLE</code> in the ring (FRTX waits for retx; best-effort waits for arrival).
|}

<code>DELIVER</code> triggers <code>frag_gather</code>: a scatter-gather <code>memcpy</code> of the <code>n</code>
consecutive fragments at <code>rq[base..base+n-1]</code> directly into the
caller's buffer; each per-packet shared-memory buffer (<code>spb</code>) is
released and <code>rwe</code> advances by <code>n</code>. <code>lwe</code> was already advanced
incrementally as each contiguous fragment arrived; <code>frag_gather</code>
only restores the fixed-width invariant <code>rwe == lwe + RQ_SIZE</code>.
No intermediate reassembly buffer is allocated.

<code>DROP</code> advances <code>rwe</code> past the broken prefix (releasing the <code>spb</code>s)
and pulls <code>lwe</code> up to the new trailing edge if needed; the next
consume retries from the new <code>base</code>. Oversize or arithmetically
overflowing delivery (sum of fragment lengths > <code>max_rcv_sdu</code>, sum
> caller's buffer, or running-sum overflow) also drops the run
with <code>-EMSGSIZE</code>.

Skip-past-gap (best-effort only). On FRTX, a gap in the run means
"waiting for retransmit" and <code>frag_run_inspect</code> returns <code>NOT_READY</code>.
On best-effort flows the gap is permanent, so <code>frag_run_inspect</code>
scans forward in the ring for the next <code>FIRST</code> or <code>SOLE</code>; if one is
visible within <code>RQ_SIZE</code>, it returns <code>DROP</code> for the broken prefix and
the consume loop retries at the new <code>lwe</code>. Memory hold is bounded
by <code>RQ_SIZE</code>; the partial releases on the next consume call once a
later complete run exists. Voice-like flows (one <code>SOLE</code> per SDU)
see no extra wait: any later <code>SOLE</code> makes the prior gap droppable
immediately.

The choice to defer reassembly to consume time keeps the receive
path zero-copy: fragments stay in the shared-memory ring until
the application pulls, and the SDU lands directly in the caller's
buffer.

== 8. Retransmission ==

FRCP is bounded by two delta-t-derived timers (Watson 1981, see
[[#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_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.

Each in-flight FRTX <code>seqno</code> owns one <code>rxm_entry</code>, armed in a hashed
timing wheel; the wheel deadline is the slot's next eligible
retransmit time.

;RTO timer
:On fire (<code>rxm_due</code>), re-emit with <code>FRCT_RXM</code>, mark <code>SND_RTX</code> (Karn-suppress next ACK's RTT sample), and (for the head-of-line (HoL) slot only) bump <code>rto_mul</code> up to <code>MAX_RTO_MUL</code>. Wheel deadline is <code>t_send + (rto << rto_mul)</code>. Re-armed unless consumed. The RTO timer also clears <code>SND_FAST_RXM</code> (re-arming fast-retransmit eligibility), resets <code>reo_wnd_mult</code> to 1 on a HoL fire (RFC 8985 sec. 6.2 step 4 reset clause), and marks the flow <code>ACL_FLOWDOWN</code> if its <code>frct_tx</code> call fails.

;r-timer guard
:Before any retransmit attempt, check <code>(now - t0)</code> against <code>t_r</code>. If exceeded, the slot is no longer eligible for retransmit. Only the RTO timer (<code>rxm_due</code>) treats r-timer expiry as terminal: it marks the flow <code>ACL_FLOWDOWN</code> (peer unreachable). Fast-retransmit, SACK-driven retransmit, and NACK-driven head-of-line re-emit silently skip aged-out slots and defer the flow-down decision to the next RTO fire.

;Fast retransmit (hybrid trigger, RFC 8985 sec. 6.2)
:On a non-advancing cumulative ACK with the scoreboard advanced, fire one fast retransmit when EITHER (a) the head-of-line slot's latest send is older than the RACK reorder window <code>R</code> ([[#3. Protocol parameters|Section 3]]) and not yet aged out, OR (b) the SACK <code>dup-thresh</code> count above <code>snd_cr.lwe</code> reaches <code>DUP_THRESH</code> (= 3, RFC 8985 sec. 6.2 step 4). Fires at most once per non-advancing cumulative-ACK value, gated by <code>rack_fired_lwe</code> (the <code>snd_cr.lwe</code> at which fast-retransmit last fired). Set <code>SND_FAST_RXM</code> on the slot (one-shot per-slot gate) and enter NewReno-style careful recovery (see NewReno below in this section).
:The RACK reorder window <code>R</code> uses the RFC 8985 sec. 6.2 form <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> with a <code>MIN_REORDER_NS = 250 us</code> floor. Before the first RTT sample seeds <code>min_rtt</code>, <code>R</code> falls back to <code>MIN(reo_wnd_mult * SRTT / 4, SRTT)</code>, still floored at <code>MIN_REORDER_NS</code> (consistent with the windowed-minimum fallback described in [[#12. RTT estimation|Section 12]]). <code>min_rtt</code> is a windowed minimum over the last <code>MIN_RTT_WIN_NS</code> = 5 min of RTT samples (matches the Linux <code>tcp_min_rtt_wlen</code> default) so a route change to a longer path eventually re-anchors the reorder window without relying on <code>reo_wnd_mult</code> growth alone.

;SACK-driven retransmit
:For each gap below <code>hi_sacked</code> whose slot is (1) still owned, (2) not already <code>SND_FAST_RXM</code>, (3) not aged out past <code>t_r</code>, and (4) either outside the RACK window <code>R</code> OR with <code>dup_thresh >= DUP_THRESH</code> (same hybrid as fast-retransmit, see [[#6.2. Locked main path|Section 6.2]]), re-emit. Each SACK-driven retransmit re-arms a fresh <code>rxm</code> so a lost retransmit can still be recovered by its own RTO timer.

;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.

== 9. Pre-DRF NACK ==

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.

;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>)
:When an incoming DATA packet has no DRF and rcv-side activity is older than <code>rcv_cr.inact</code>, the receiver emits a bare packet with <code>flags = FRCT_NACK</code> and <code>seqno = arrival_seqno - 1</code> (informational only, not consulted by the receive handler). The cooldown in [[#3. Protocol parameters|Section 3]] rate-limits the burst. Non-DATA non-DRF arrivals bypass <code>rcv_inact_check</code> entirely; non-DATA DRF still rebases via the DRF branch.

;Receive (<code>frcti_nack_rcv</code>)
: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:

# 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.

== 10. Cumulative + selective ACK ==

Cumulative ACK is <code>ackno = rcv_cr.lwe</code>. On out-of-order arrival the
receiver also emits a SACK packet ([[#1.3. SACK payload|Section 1.3]]) whose payload lists
''present'' blocks above <code>lwe</code> (analogous to TCP SACK / QUIC ACK
ranges). SACKs are rate-limited per [[#3. Protocol parameters|Section 3]] and suppressed when
neither <code>lwe</code> nor block count has changed since the last SACK.

D-SACK reports (RFC 2883) are emitted in-band as <code>block[0]</code> of an
otherwise normal SACK frame (see [[#1.3. SACK payload|Section 1.3]] for the encoding).
Two receiver triggers arm a pending D-SACK report (single-slot,
latest-wins):

* DATA arrival with <code>seqno < rcv_cr.lwe</code>, both wire-dup (no RXM, <code>is_dup_data</code> path) and retransmit (RXM, post-FC branch) (RFC 2883 sec. 4.1.1, full duplicate)
* <code>rq_accept</code> conflict, slot already occupied in <code>[lwe, rwe)</code> (RFC 2883 sec. 4.1.2, partial duplicate)

When a D-SACK is pending and the standard scoreboard SACK would be
suppressed by dedup or rate-limit, the report is emitted as a
stand-alone SACK frame through the normal <code>ack_snd</code> path; when a
D-SACK report is pending the path bypasses dedup and the <code>TICTIME</code>
rate-limit, but the a-timer suppression on rcv inactivity still
applies.

Bare ACKs are deferred via a per-flow delayed-ACK timer (one in
flight at a time, atomic test-and-set dedup; fires per [[#3. Protocol parameters|Section 3]]
after the first in-order arrival). Suppressed if (1) no new
<code>seqno</code>, (2) rcv side is inactive (older than <code>t_a</code>), or (3) the
sender just sent within <code>TICTIME</code>. A pending D-SACK ride-through
bypasses (1) and (3); the a-timer gate (2) is unconditional.

== 11. Flow control ==

The receiver advertises <code>rwe</code> in every FC field. The sender treats
its <code>snd_cr.rwe</code> as the absolute right edge: when
<code>snd_cr.seqno >= snd_cr.rwe</code> the window is closed and <code>flow_write</code>
yields. While closed, the sender periodically emits RDVS
(rendezvous) packets (cadence <code>DELT_RDV</code>); the receiver replies with
a bare FC packet (<code>ackno = 0</code>) that reopens the window. Once the
window has been closed for longer than <code>MAX_RDV</code> the sender stops
emitting RDVS but does not tear the flow down - the writer keeps
blocking until either a peer-driven FC arrives or the KA
(keepalive) / r-timer marks the flow.

<code>rwe</code> is clamped to <code>lwe + RQ_SIZE</code> on receipt and MUST NOT shrink:
a backward <code>rwe</code> is silently clamped to the current <code>snd_cr.rwe</code>;
the FC packet still reopens the window.

== 12. RTT estimation ==

Active RTTP probes ([[#1.4. RTTP payload|Section 1.4]]) carry a 32-bit <code>probe_id</code> (0
reserved) and a 16-byte random nonce echoed verbatim - defends
against spoofed replies. A ring of <code>RTTP_RING</code> in-flight probes is
kept; an echo whose <code>(id, nonce)</code> doesn't match the ring slot is
dropped. A single RTTP sample is clamped to <code>RTT_CLAMP_MUL * srtt</code>
(compile-time <code>RTT_CLAMP_MUL = 16</code>) once <code>srtt</code> is seeded; the first
cold-probe sample feeds <code>rtt_update</code> raw.

Probe arming gates:

;Cold (no <code>srtt</code> yet)
:the receive path arms at most one probe per 100 ms via <code>frcti_rcv_probe</code> (<code>PROBE_DUE_COLD</code>); arming requires an incoming packet. Active send-path arming bails while <code>srtt == 0</code>.
;Warm (<code>rtt_probe_arm</code>, called from <code>frcti_snd</code>)
:outstanding data (<code>snd_cr.seqno > snd_cr.lwe</code>), AND at least <code>2 * srtt</code> since <code>t_rcv_rtt</code> (last RTT receive of any kind), AND at least <code>srtt</code> since <code>t_snd_probe</code> (last probe emit).

Sample feeds either Linux's asymmetric <code>mdev</code> estimator
(<code>FRCT_LINUX_RTT_ESTIMATOR</code>, default ON) or RFC 6298 symmetric EWMA
(compile option). <code>srtt</code> is floored at 10 ms when seeded from a
hint, at 1 us after every update (including the first seeding
sample); <code>mdev</code> floored at 100 ns.

:<code>RTO = max(rto_min, 2 * srtt, srtt + (mdev << MDEV_MUL))</code>

(the <code>2 * srtt</code> floor is an FRCT addition not in RFC 6298).
Effective wheel deadline capped per [[#3. Protocol parameters|Section 3]].

ACK-derived samples (<code>frcti_ack_rcv</code> -> <code>rtt_sample_eligible</code>), beyond
the cum-ACK advance gate in <code>frcti_ack_rcv</code> (<code>ackno > lwe</code> and
<code>ackno <= seqno</code>), require all of: not in recovery; ACK packet does
not carry <code>FRCT_RXM</code>; HoL slot's <code>SND_RTX</code> bit clear; slot's <code>rxm</code>
pointer non-NULL (not SACK-consumed); <code>lwe</code> not below the <code>rtt_lwe</code>
fence; <code>srtt</code> already seeded by an RTTP probe. There is no ACK-only
seeding.

Every eligible sample also feeds <code>RACK.min_RTT</code> (RFC 8985 sec. 6.2)
via a windowed minimum: replace whenever the sample is strictly
smaller OR more than <code>MIN_RTT_WIN_NS</code> (5 min, matches Linux
<code>tcp_min_rtt_wlen</code>) has elapsed since the current min was set. The
downward branch is immediate (faster path picked up at once); the
upward branch is gated on the window (a transient queue burst does
not poison the estimate, but a sustained route change to a longer
path re-anchors <code>min_RTT</code> after at most one window). Seeded from
<code>rtt_hint</code> at <code>rtt_init</code>; 0 acts as the unset sentinel and the base
in <code>rack_reorder_window</code> falls back from <code>min_RTT</code> to <code>SRTT</code> (so
<code>R = mult * SRTT/4</code>, capped at <code>SRTT</code>, floored at <code>MIN_REORDER_NS</code>)
until the first sample. See [[#6.2. Locked main path|Section 6.2]].

== 13. Liveness (keepalive) ==

When <code>qs.timeout > 0</code> a per-flow KA (keepalive) timer is armed.
Arming uses <code>rcv_cr.act</code> for the deadline computation:

:<code>deadline = min(snd_act + qs.timeout/4, rcv_act + qs.timeout)</code>

(clamped to <code>now + qs.timeout/4</code> if already past). The timer fires
either on sender idleness (to send a KA) or on receiver idleness
(to declare the peer dead). On fire (<code>ka_snd</code>) the peer-dead test
uses <code>max(rcv_cr.act, t_ka_rcv)</code> so a recent KA reply counts even
when no DATA has arrived:

* If <code>now - max(rcv_cr.act, t_ka_rcv) > qs.timeout</code>, mark the flow <code>ACL_FLOWPEER</code> and notify the per-process flow-event set (<code>proc.fqset</code>) with <code>FLOW_PEER</code>.
* Else if <code>snd_idle > qs.timeout/4</code>, emit a bare <code>KA | ACK</code> (<code>ackno = rcv_cr.lwe</code>) and re-arm.
* Else just re-arm.

Note: <code>rx_rb</code> and <code>tx_rb</code> are the receive and transmit shared-memory
ring buffers. The r-timer raises <code>ACL_FLOWDOWN</code> on both (route is
broken); keepalive raises <code>ACL_FLOWPEER</code> on <code>rx_rb</code> only and notifies
the flow-event set (peer is silent, writer keeps <code>tx_rb</code> usable) -
distinct ACLs. <code>qs.timeout == 0</code> disables keepalive entirely; a
silent peer crash is then undetected.

== 14. Linger / teardown ==

On <code>flow_dealloc</code>, <code>frcti_dealloc</code> computes a grace timeout

:<code>max(rcv_cr.act + rcv_cr.inact, snd_cr.act + snd_cr.inact) - now</code>

(floored at 0 and converted to seconds) and returns it; <code>flow_dealloc</code>
forwards this to the IRMd as the dealloc grace. The IRMd, not FRCT,
performs the wait. Before computing the timeout, FRCT may emit a
final ACK when <code>rcv_cr.lwe != rcv_cr.seqno</code> (the peer has not been
told the most recent cumulative ACK) AND the rcv side has been
active within <code>t_a</code> (a-timer not aged out).

<code>FRCTFLINGER</code> is honoured only when <code>snd_cr.lwe < edge</code>, where <code>edge =
snd_fin_seqno</code> after FIN has been sent in stream mode and
<code>snd_cr.seqno</code> otherwise (data or FIN still in flight). The drain
itself runs in <code>flow_dealloc</code>'s <code>while (FRCTI_LINGERING)</code> loop, not in
<code>frcti_dealloc</code>.

The fd is single-reader / single-writer (documented in the
manpages). <code>flow_write</code> pumps <code>rx_rb</code> on every call (via
<code>flow_wait_window</code> -> <code>flow_drain_rx_nb</code>) and additionally blocks on
<code>rx_rb</code> when the send window is closed. A pure-writer thread thus
consumes ACKs without a dedicated reader.

== 15. Heritage and adopted techniques ==

Delta-t (Watson, 1981) is the primary heritage; FRCP descends from
the delta-t protocol family via the Recursive InterNetwork
Architecture (RINA; Day, "Patterns in Network Architecture", 2008,
ch. 9). Timer-based connection management
(no SYN/FIN handshake, per-flow state born on first DATA and
reclaimed after <code>t_mpl + a + r</code> of silence), the DRF marker, and the
<code>t_mpl</code> / <code>t_a</code> / <code>t_r</code> timers all come from delta-t. See Watson,
"Timer-Based Mechanisms in Reliable Transport Protocol Connection
Management", Computer Networks 5 (1981).

The unified <code>flow_alloc(name, qos, ...)</code> primitive and its
multi-axis QoS-cube argument ([[#2.2. Service modes (orthogonal axes)|Section 2.2]]) also come from RINA
(Day 2008, ch. 6; Grasa et al., "IRATI: investigating RINA as an
alternative to TCP/IP", Computer Networks 92 (2015)) - reliability,
ordering, CRC presence, and encryption are flow attributes, not
separate sockets or protocols.

The table below summarises additional adopted techniques and their
references.

{| class="wikitable"
! FRCP mechanism !! Heritage !! Reference / note
|-
| Random new <code>seqno</code> on <code>seqno_rotate</code> || TCP ISN || RFC 6528 (Gont & Bellovin, 2012). QUIC PN-space reset (RFC 9000 sec. 12.3) is a structural analogue.
|-
| Cumulative ACK, left-window-edge advance || TCP || RFC 793 / RFC 9293
|-
| Receive window with non-shrink rule || TCP || RFC 793 sec. 3.7 / RFC 9293 sec. 3.8.6; RFC 1122 sec. 4.2.2.16 for the explicit non-shrink prohibition
|-
| Modular <code>seqno</code> arithmetic (<code>before</code>/<code>after</code> helpers) || TCP || RFC 793 sec. 3.3 / RFC 9293 sec. 3.4
|-
| Selective ACK block list || TCP || RFC 2018 (Mathis et al., 1996). Encoded as a typed FRCP packet rather than a TCP option, so framing is closer to QUIC ACK frames. D-SACK (RFC 2883) carried in-band as <code>block[0]</code>; see [[#1.3. SACK payload|Section 1.3]].
|-
| NewReno-careful recovery with <code>recovery_high</code> gate || TCP || RFC 6582 (Henderson et al., 2012); QUIC builds on the same model in RFC 9002 sec. 7.3.2. Cwnd half absent (CC in IPCP).
|-
| RACK reordering window for fast retransmit || TCP || RFC 8985 (Cheng et al., 2021). FRCP <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> with a <code>MIN_REORDER_NS = 250 us</code> floor against <code>srtt</code> collapse; matches RFC 8985 sec. 6.2 and Linux <code>tcp_rack_reo_wnd</code>. DSACK-driven <code>reo_wnd_mult</code> (sec. 6.2 step 4) is adopted; see [[#1.3. SACK payload|Section 1.3]] for the wire encoding. The hybrid RACK-or-<code>DUP_THRESH</code> trigger from RFC 8985 sec. 6.2 step 4 is adopted ([[#8. Retransmission|Section 8]]). QUIC's analogue in RFC 9002 sec. 6.1.2 uses <code>max(srtt, latest_rtt)</code> as the base.
|-
| 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.
|-
| 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.
|-
| Delayed ACK with rate suppression || TCP || RFC 813 (Clark, 1982); RFC 1122 sec. 4.2.3.2; RFC 5681 sec. 4.2. Single-deadline coalescing rather than "ack-every-other-segment".
|-
| Zero-window-probe / persist-timer analogue (RDVS) || TCP || RFC 1122 sec. 4.2.2.17 / RFC 9293 sec. 3.8.6.1. RDVS solicits an FC reply, distinct from QUIC <code>DATA_BLOCKED</code> (RFC 9000 sec. 19.12), which is one-way notification. <code>MAX_RDV</code> give-up departs from TCP.
|-
| Multiplexed control on a single PCI || SCTP / QUIC || SCTP chunk bundling (RFC 9260 sec. 6.10); QUIC frame multiplexing (RFC 9000 sec. 12.4). Cleaner fit than TCP's separate-flag-bits design.
|-
| ACK ranges as multiple discontiguous acked blocks || QUIC || QUIC ACK frame (RFC 9000 sec. 19.3). FRCP SACK is conceptually QUIC-frame-shaped even though encoded as absolute <code>[start,end]</code> pairs.
|-
| Nonce-authenticated active RTT / liveness probing (RTTP) || QUIC <code>PATH_CHALLENGE</code> || <code>PATH_CHALLENGE</code> / <code>PATH_RESPONSE</code> (RFC 9000 sec. 8.2, sec. 19.17, sec. 19.18). WebRTC ICE consent-freshness (RFC 7675) is the same pattern. QUIC's nonce is 8 octets; FRCP chooses 16.
|-
| Probing distinct from keepalive || QUIC || KA timer answers "peer alive?", RTTP answers "path measurable?", as in QUIC PING (RFC 9000 sec. 19.2) vs <code>PATH_CHALLENGE</code>.
|-
| Bare KA + ACK keepalive packets || QUIC / SCTP || QUIC PING (RFC 9000 sec. 19.2); SCTP HEARTBEAT / HEARTBEAT-ACK (RFC 9260 sec. 8.3). SCTP HEARTBEAT also carries an opaque echoed blob, structurally similar to FRCP RTTP.
|-
| (<code>FFGM</code>, <code>LFGM</code>) fragment-role bits ([[#7.2. Fragmentation and reassembly|Section 7.2]]) || SCTP || RFC 9260 sec. 3.3.1 DATA chunk B/E bits encode the same four states (<code>B+E=SOLE</code>, <code>B-only=FIRST</code>, neither=<code>MID</code>, <code>E-only=LAST</code>). Each fragment carries its own <code>seqno</code>/TSN and is independently retransmitted.
|-
| Stream byte-offset reassembly (Sections [[#1.5. Stream PCI extension|1.5]], [[#16. Stream-mode flows|16]]) || QUIC || QUIC STREAM frame (RFC 9000 sec. 19.8) uses Offset + Length varints; FRCP uses fixed 32-bit <code>start</code> / <code>end</code>. One stream per flow vs QUIC's many streams multiplexed.
|-
| FIN end-of-stream marker (Sections [[#1.2. Flag bits|1.2]], [[#16. Stream-mode flows|16]]) || TCP / QUIC || TCP FIN flag (RFC 9293 sec. 3.1) closes one half of the byte stream; QUIC STREAM frame FIN bit (RFC 9000 sec. 19.8) does the same per stream with an immutable final-size invariance (RFC 9000 sec. 4.5: the final size is fixed once observed). FRCP's FIN consumes one packet <code>seqno</code> (not one byte of stream space) and is idempotent on the sender side.
|-
| Stream byte-credit flow control ([[#16. Stream-mode flows|Section 16]]) || QUIC || <code>MAX_STREAM_DATA</code> (RFC 9000 sec. 4.1, sec. 19.10). FRCP projects a per-flow byte budget onto the <code>seqno</code>-space <code>rwe</code>. Single stream per flow collapses QUIC's <code>MAX_DATA</code> / <code>MAX_STREAM_DATA</code> distinction.
|-
| Header protection (encrypted seqnos) || QUIC || QUIC RFC 9001 sec. 5.4 applies header protection on top of AEAD to mask the packet number. FRCP's per-flow AEAD wrap ([[#16. Stream-mode flows|Section 16]]) is wider: it encrypts the entire PCI including <code>seqno</code> because the IPCP below already routes, so no destination connection-ID needs to stay in clear (cf. RFC 9000 sec. 5.2).
|-
| Two-bit fragment role polarity || SCTP || The (<code>FFGM</code>, <code>LFGM</code>) pair follows SCTP B/E (begin = 1 / end = 1) rather than IPv4 MF (RFC 791 sec. 3.2), which has the inverse polarity (MF = 1 means NOT last).
|-
| Orthogonal reliability / ordering axes ([[#2.2. Service modes (orthogonal axes)|Section 2.2]]) || SCTP || PR-SCTP (RFC 3758, per-message partial reliability) and SCTP DATA U-bit (RFC 9260 sec. 3.3.1, per-message unordered) are the closest precedents for decoupling reliability from ordering; FRCP sets them per-flow rather than per-message.
|-
| Orthogonal CRC (<code>qs.ber == 0</code>) || UDP-Lite || RFC 3828 (Larzon et al., 2004) lets the sender pick a per-packet Checksum Coverage and the receiver enforce a locally configured minimum (no in-band negotiation; sec. 3.1, sec. 3.3). FRCP gates a full CRC trailer on <code>qs.ber == 0</code> at flow setup. Contrast TCP / SCTP (mandatory checksum) and QUIC (AEAD subsumes CRC).
|-
| Setup-time service negotiation || DCCP / SCTP / QUIC || DCCP Service Codes (RFC 4340 sec. 8.1.2, RFC 5595); SCTP INIT parameters (RFC 9260 sec. 3.3.2); QUIC transport parameters (RFC 9000 sec. 7.4). All negotiate service properties at connection setup; only RINA's QoS cube exposes them as an orthogonal vector.
|}

=== 15.1. Original to FRCP (no clean prior art) ===

* Pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]): receiver-driven nudge exploiting <code>snd_cr.inact > rcv_cr.inact</code>. Closest analogues are SCTP Gap Ack Blocks (RFC 9260 sec. 3.3.4) and DCCP Ack Vector (RFC 4340 sec. 11.4) - both let the receiver describe gaps to the sender, but neither targets the cross-epoch / pre-DRF case.
* <code>MAX_RDV</code> window-probe give-up: neither TCP (persist-timer probes until application or R2 abort, RFC 9293 sec. 3.8.6.1) nor QUIC has an explicit FC-give-up counter. A recursive-network choice: outer layers can drop the flow.
* Skip-past-gap reassembly ([[#7.2. Fragmentation and reassembly|Section 7.2]]): SCTP fragments and reassembles every flow regardless of reliability/ordering, using its own per-stream reassembly queue; QUIC fragments via STREAM offsets. FRCP fragments best-effort flows too, but the receiver drops the broken prefix the moment a later run-start (<code>FIRST</code> or <code>SOLE</code> role) is visible inside the <code>RQ_SIZE</code>-wide reorder ring - no IP-frag-style timeout, no SCTP-style explicit abort. If no later run-start arrives within the ring, <code>frag_run_inspect</code> returns <code>NOT_READY</code> and the partial run keeps its slots; the next inspect retries. The trade-off: a permanently-lost <code>MID</code> in a long isolated run holds slots until either a later <code>FIRST</code>/<code>SOLE</code> appears in the ring or the writer stops, at which point the slots are reclaimed on flow teardown.
* Reassembly deferred to consume time ([[#7.2. Fragmentation and reassembly|Section 7.2]]), message mode only (<code>qos.service == SVC_MESSAGE</code>): SCTP (RFC 9260 sec. 6.9), QUIC (RFC 9000 sec. 2.2), and TCP (RFC 9293) all hold reassembly state at the receive boundary. FRCP message-mode leaves fragments in the shared-memory ring until <code>flow_read</code> pulls and lands the SDU directly in the caller's buffer. Stream mode ([[#16. Stream-mode flows|Section 16]]) uses the standard QUIC-style direct ring placement on receive and does not defer. The optimisation is enabled by the Shared-Memory Subsystem (SSM) packet-buffer ring (see <code>struct ssm_pk_buff</code> at [[#1.1. PCI header|Section 1.1]]); the analogue is OS-level scatter-gather I/O (<code>recvmsg+iovec</code>), not a transport-layer prior art.
* TLP-equivalent tail-loss recovery (RFC 8985 sec. 7; RFC 9002 sec. 6.2): FRCP does not emit an explicit Tail Loss Probe packet, but the same goal is met implicitly by RACK loss detection ([[#8. Retransmission|Section 8]]) firing on a non-advancing cumulative ACK once the head-of-line slot ages past the RACK reorder window <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> - well below <code>RTO = max(2 * SRTT, SRTT + (mdev << MDEV_MUL))</code>. A receiver-driven nudge is also available via the pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]).

=== 15.2. Not adopted ===

* Slow start, congestion window (cwnd), Additive Increase / Multiplicative Decrease (AIMD), NewReno cwnd inflation. Congestion control lives in the IPCP CA policies and is driven by Explicit Congestion Notification (ECN, RFC 3168).
* Nagle / silly-window-syndrome (SWS) avoidance (RFC 896, RFC 1122 sec. 4.2.3.4). (Deferred work, not adopted in the current spec.)
* TCP Timestamps (RFC 7323) / Protection Against Wrapped Sequences (PAWS) - RTT measurement uses RTTP, not per-segment timestamps. A peer-supplied timestamp echoed on every ACK lets a malicious peer drive the <code>srtt</code> estimate arbitrarily low, collapsing the RTO and triggering a self-inflicted retransmit storm. RTTP confines RTT measurement to nonce-authenticated probe round-trips, where a forged echo is rejected before it can reach the estimator.
* ECN (Explicit Congestion Notification) response inside FRCP (consumed by IPCP Congestion Avoidance / CA).
* 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).

== 16. Stream-mode flows ==

When a flow is allocated with <code>qos.service == SVC_STREAM</code> both peers
switch to byte-stream semantics, layered on top of the FRTX reorder
machinery already described in Sections [[#6. Receive path|6]]-[[#8. Retransmission|8]].

=== 16.1. Send ===

The sender splits the caller's octets into chunks of at most
<code>(frag_mtu - base PCI - stream PCI extension)</code> octets (Sections [[#1.1. PCI header|1.1]]
and [[#1.5. Stream PCI extension|1.5]]). Each chunk is one DATA packet with its own <code>seqno</code> and a
<code>[start, end)</code> byte range copied from a monotonic stream counter.
In stream mode <code>FFGM</code> and <code>LFGM</code> are unused and MUST be transmitted as
zero; the per-byte position is carried by the <code>[start, end)</code>
extension instead.

End-of-stream is signalled with a 0-byte DATA packet that has <code>FIN</code>
(bit 12) set, emitted on the FIN triggers listed in [[#1.2. Flag bits|Section 1.2]]
(WR-half close, <code>flow_dealloc</code>, and any other path that yields the
final byte). The sender MUST emit at most one FIN per flow; its
<code>[start, end)</code> MUST equal <code>[final-byte, final-byte)</code> (i.e., empty
interval at the final byte position; final-size invariance,
analogous to QUIC RFC 9000 sec. 4.5). Idempotency is enforced by
an <code>snd_fin_sent</code> guard.

=== 16.2. Receive ===

On arrival the receiver places the payload directly into a per-flow
byte-indexed receive ring of width <code>ring_sz</code> (octets) at the position
indicated by <code>start</code>, with a two-segment <code>memcpy</code> across the ring
boundary if needed. Receipt is recorded in the FRTX reorder
machinery ([[#6.2. Locked main path|Section 6.2]]) augmented with the packet's <code>start</code>, <code>end</code>, and
FIN bit per slot. When a packet's <code>[start, end)</code> front-overlaps
bytes already at or below the byte high-water mark, the overlap is
trimmed before placement so the same byte is never written twice.
After stashing, the receiver advances <code>lwe</code> and the byte high-water
mark across any newly-contiguous prefix. Each slot advanced MUST
satisfy <code>start == the last-delivered slot's end</code>; a slot whose
<code>start</code> does not equal that <code>end</code> is silently dropped at delivery time
(the <code>seqno</code> is consumed, no stream bytes contributed) and the high-
water mark does not advance past it. The stream byte-stream
stalls at that point - there is no flow-tear-down on mismatch.
This filters spliced or off-path-injected slots that fall in
window without strong cryptographic authentication.

A FIN slot marks end-of-stream at advance time only if its byte
position equals the last-delivered slot's <code>end</code>; otherwise the FIN
is ignored and the corresponding <code>seqno</code> occupies a slot but
contributes no stream bytes. No packet buffer is held after the
ring copy.

=== 16.3. Read ===

<code>flow_read</code> returns up to <code>count</code> octets from the contiguous prefix
<code>[next, high-water)</code>, where <code>next</code> is the byte the application has
already consumed up to and <code>high-water</code> is the rightmost contiguous
byte received. When the stream is fully drained AND end-of-stream
(EOS) was observed (<code>next == EOS</code> byte position), <code>flow_read</code> returns
0 (<code>EOF</code>) - the same shape POSIX <code>read(2)</code> uses on TCP after a peer
FIN.

=== 16.4. Flow control ===

ACK / SACK / RACK / RTO machinery is unchanged; the FRTX reorder
ring is reused as a per-<code>seqno</code> received-bitmap. Let <code>per_pkt =
(frag_mtu - base PCI - stream PCI extension)</code>, the maximum stream-
byte payload one DATA packet can carry ([[#16.1. Send|Section 16.1]]). The
receive window advertised in FC is clamped so the byte window
(<code>ring_sz</code>) cannot be overrun: the <code>seqno</code>-space <code>rwe</code> is at most
<code>rcv_cr.lwe + ring_sz / per_pkt</code>.

This is the QUIC byte-credit flow-control model
(<code>MAX_STREAM_DATA</code>, RFC 9000 sec. 4.1 and sec. 19.10) projected onto
<code>seqno</code> space. With one stream per flow there is no <code>MAX_DATA</code> /
<code>MAX_STREAM_DATA</code> distinction. Receiver-side silly-window-syndrome
(SWS) avoidance (RFC 9293 sec. 3.8.6.2.2) is achieved by combining
the consume-time <code>rwe</code> bump with the global non-shrink rule from
[[#11. Flow control|Section 11]].

=== 16.5. Security considerations ===

Threat model. An attacker that can observe (on-path passive) or
predict (off-path blind) the flow's seqnos and byte offsets on an
unencrypted stream flow can inject DATA or FIN at any in-window
position. The in-line consistency checks above (<code>start</code> == prior
<code>end</code> on advance; FIN MUST be 0-byte; FIN MUST sit at the final
byte position) realise the spirit of RFC 5961's "sequence-window
plus exact-position match for control bits" without an explicit
challenge-ACK probe; they make a few specific blind attack shapes
harder but are not cryptographic authentication. This is
comparable to TCP without the TCP Authentication Option (TCP-AO,
RFC 5925), tighter than a
pre-RFC-5961 TCP stack, and roughly equivalent to a modern
RFC 5961 stack against blind off-path injection - none of these
help once the attacker can sniff. TLS over TCP (RFC 8446)
encrypts only the TCP payload and leaves TCP seqnos, ACKs, FIN,
and RST in the clear, so TLS does NOT defend against TCP-header-
level injection; QUIC (RFC 9000) hides packet numbers under
header protection (RFC 9001 sec. 5.4), so this specific weakness
does not apply to QUIC.

Mitigation: AEAD. When the flow has encryption enabled the
recommended AEAD ciphers (AES-GCM, RFC 5288; or ChaCha20-Poly1305,
RFC 8439) wrap the entire FRCP packet on the wire - PCI, stream
extension, body, and the CRC trailer when <code>ber == 0</code> - under a
per-flow symmetric key derived from the flow's own key exchange
([[#1.1. PCI header|Section 1.1]]). The AEAD tag (~2^-128 forgery probability)
dominates the CRC (~2^-32) for integrity in this mode but the CRC
trailer is currently retained inside the wrap (see [[#1.1. PCI header|Section 1.1]]).
Implementations MUST NOT rely on the security properties below
when a non-AEAD cipher (e.g. AES-CTR alone) is negotiated; non-
AEAD modes provide confidentiality only and the threat-model
claims do not hold.

With an AEAD cipher in use, seqnos, byte offsets, and the FIN bit
are both authenticated and confidential. Against an off-path or
on-path-passive attacker this is:

* Stronger than TCP+TLS (TCP header in the clear).
* Stronger than TCP+TCP-AO (header authenticated but visible).
* 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
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
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
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 MUST provide it at a higher
layer.

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.

== 17. References ==

This section lists the IETF documents, published works, and
source-code references cited inline elsewhere in this document.
IETF documents are cited inline as "RFC NNNN sec. X.Y"; books,
journal papers, and source-code references are cited inline by
author and year (or by file and function name) and are listed
here for convenience.

=== 17.1. IETF documents ===

;[RFC 791]
:J. Postel, "Internet Protocol", STD 5, RFC 791, September 1981.
;[RFC 793]
:J. Postel, "Transmission Control Protocol", STD 7, RFC 793, September 1981. Obsoleted by RFC 9293.
;[RFC 813]
:D. D. Clark, "Window and Acknowledgement Strategy in TCP", RFC 813, July 1982.
;[RFC 896]
:J. Nagle, "Congestion Control in IP/TCP Internetworks", RFC 896, January 1984.
;[RFC 1122]
:R. Braden (ed.), "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
;[RFC 2018]
:M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
;[RFC 2119]
:S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
;[RFC 2883]
:S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
;[RFC 3758]
:R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
;[RFC 3828]
:L-A. Larzon, M. Degermark, S. Pink, L-E. Jonsson (ed.), G. Fairhurst (ed.), "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
;[RFC 4303]
:S. Kent, "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
;[RFC 4340]
:E. Kohler, M. Handley, S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
;[RFC 5288]
:J. Salowey, A. Choudhury, D. McGrew, "AES Galois Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, August 2008.
;[RFC 5595]
:G. Fairhurst, "The Datagram Congestion Control Protocol (DCCP) Service Codes", RFC 5595, September 2009.
;[RFC 5681]
:M. Allman, V. Paxson, E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
;[RFC 5925]
:J. Touch, A. Mankin, R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
;[RFC 5961]
:A. Ramaiah, R. Stewart, M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, August 2010.
;[RFC 6298]
:V. Paxson, M. Allman, J. Chu, M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, June 2011.
;[RFC 6528]
:F. Gont, S. Bellovin, "Defending against Sequence Number Attacks", RFC 6528, February 2012. Obsoletes RFC 1948.
;[RFC 6582]
:T. Henderson, S. Floyd, A. Gurtov, Y. Nishida, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 6582, April 2012.
;[RFC 7323]
:D. Borman, B. Braden, V. Jacobson, R. Scheffenegger (ed.), "TCP Extensions for High Performance", RFC 7323, September 2014.
;[RFC 7675]
:M. Perumal, D. Wing, R. Ravindranath, T. Reddy, M. Thomson, "Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness", RFC 7675, October 2015.
;[RFC 8174]
:B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017.
;[RFC 8200]
:S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, July 2017.
;[RFC 8439]
:Y. Nir, A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 8439, June 2018.
;[RFC 8446]
:E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, August 2018.
;[RFC 8985]
:Y. Cheng, N. Cardwell, N. Dukkipati, P. Jha, "The RACK-TLP Loss Detection Algorithm for TCP", RFC 8985, February 2021.
;[RFC 9000]
:J. Iyengar (ed.), M. Thomson (ed.), "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, May 2021.
;[RFC 9001]
:M. Thomson (ed.), S. Turner (ed.), "Using TLS to Secure QUIC", RFC 9001, May 2021.
;[RFC 9002]
:J. Iyengar (ed.), I. Swett (ed.), "QUIC Loss Detection and Congestion Control", RFC 9002, May 2021.
;[RFC 9147]
:E. Rescorla, H. Tschofenig, N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, April 2022.
;[RFC 9260]
:R. Stewart, M. Tuexen, K. Nielsen, "Stream Control Transmission Protocol", RFC 9260, June 2022. Obsoletes RFC 4960.
;[RFC 9293]
:W. Eddy (ed.), "Transmission Control Protocol (TCP)", STD 7, RFC 9293, August 2022. Obsoletes RFC 793 and several follow-ons; updates RFC 1122 and others.

=== 17.2. Books and journal papers ===

;[Day08]
:J. Day, "Patterns in Network Architecture: A Return to Fundamentals", Prentice Hall, 2008.
;[Grasa15]
:E. Grasa et al., "IRATI: investigating RINA as an alternative to TCP/IP", Computer Networks, Vol. 92, December 2015.
;[KP87]
:P. Karn, C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", ACM SIGCOMM, August 1987.
;[Wat81]
:R. W. Watson, "Timer-Based Mechanisms in Reliable Transport Protocol Connection Management", Computer Networks, Vol. 5, 1981.

=== 17.3. Source-code references ===

;[Linux-RTT]
:<code>tcp_rtt_estimator()</code> in <code>net/ipv4/tcp_input.c</code> of the Linux kernel, defining the asymmetric <code>mdev</code> variance update used as FRCP's default RTT estimator ([[#12. RTT estimation|Section 12]]). Line-stable browseable copy at https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_input.c.

[[Category:Protocols]]
[[Category:Ouroboros internals]]

Ouroboros Protocols

2026-05-17T13:52:13Z

Dimitri: /* Flow and Retransmission Control Protocol */

{{Under construction}}

The protocols in Ouroboros are designed with strong adherence to the principles of [https://en.wikipedia.org/wiki/Separation_of_concerns separation of concerns] and [https://en.wikipedia.org/wiki/Separation_of_mechanism_and_policy separation of mechanism and policy] in mind to prevent network ossification and protocol ossification from occuring.

There are 5 core protocols in Ouroboros.

== Data Transfer Protocol ==
Main page: [[Ouroboros Data Transfer Protocol]]

The Data Transfer Protocol resides in the [[Ouroboros Functional Layering|network forwarding layer]].

<syntaxhighlight>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-to-Live | QoS | ECN | PADDING |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ EID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ N + 1 Data +
. .
. .
</syntaxhighlight>

== Flow and Retransmission Control Protocol ==
Main page: [[Flow and Retransmission Control Protocol]]

The Flow and Retransmission Control Protocol resides in the [[Ouroboros Functional Layering|application end-to-end layer]].

<syntaxhighlight>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | hcs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ackno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload (variable) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

flags - feature/type bitmap (see 1.2).
hcs - CRC-16-CCITT-FALSE Header Check Sequence (HCS) over
flags + window + seqno + ackno (+ stream extension when
present); the two octets of the hcs field itself are
omitted from the CRC input. Verified on receive before
any flag-driven dispatch.
window - receiver-advertised right window edge (valid iff FC).
seqno - per-flow sequence number.
ackno - cumulative Acknowledgement (ACK) (valid iff ACK).
</syntaxhighlight>

== Flow Allocation Protocol ==
Main page: [[Ouroboros Flow Allocation Protocol]]

/*
* 0 1 2 3
* 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
* | | |
* + + |
* | | |
* + id (128 bits) + |
* | Unique flow allocation ID | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | | |
* + timestamp (64 bits) + |
* | UTC nanoseconds since epoch | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | crt_len (16 bits) | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | | |
* + certificate (variable) + |
* | X.509 certificate, DER encoded | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* |F|R| kex_len (14 bits) | | | Signed
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | | | Region
* + kex_data (variable) + |
* | public key (DER/raw) or ciphertext (KEM) | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | cipher_len (16 bits) | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | | |
* + cipher (variable) + |
* | symmetric cipher name (UTF-8) | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | data_len (16 bits) | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | | |
* + data (variable) + |
* | Piggybacked application data | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
* | sig_len (16 bits) | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
* | |
* + signature (variable) +
* | DSA signature over signed region |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*
* kex_len field bit layout:
* F (bit 15): Format - 0 = X.509 DER, 1 = Raw/Hybrid
* R (bit 14): Role - 0 = Server encaps, 1 = Client encaps
* (R is ignored for non-KEM algorithms)
* Bits 0-13: Length (0-16383 bytes)
*/
The Flow Allocation Protocol resides in the [[Ouroboros Functional Layering|network end-to-end layer]].

== Connection Establishment Protocol ==
Main page: [[Ouroboros Connection Establishment Protocol]]

== Enrollment Protocol ==
Main page: [[Ouroboros Enrolment Protocol]]

The Enrollment protocol is best seen as one of the application protocols for IPCPs.

Flow and Retransmission Control Protocol

2026-05-17T13:51:36Z

Dimitri: /* 1.1. PCI header */

= FRCP - Flow and Retransmission Control Protocol =

FRCP runs end-to-end between two peers over a flow. It delivers
reliability, in-order delivery, flow control, and liveness.
Congestion Control (CC) is not in FRCP - that lives in the IPC
Process (IPCP) Congestion Avoidance (CA) policies, orthogonal to
FRCP. Flow allocation, naming, and IPCP lifecycle are handled by
the IPC Resource Manager daemon (IRMd).

FRCT (Flow and Retransmission Control Task) is the libouroboros
implementation of FRCP; the task lives in src/lib/frct.c. The
remainder of this document describes the FRCP wire protocol and the
behaviour FRCT realises. Code symbols retain the FRCT_ prefix
(FRCT_DATA, FRCT_RXM, ...) because they belong to the implementing
task; this document references them verbatim.

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in BCP 14 (Best
Current Practice; RFC 2119, RFC 8174) when, and only when, they
appear in all capitals.

== Notation ==

<pre>
u32, u8 Unsigned 32-bit / 8-bit integers (kernel-C style).
ns Nanoseconds.
</pre>

Modular sequence-number comparators (32-bit, modulo 2^32):

<pre>
before(a, b) == (int32_t)(a - b) < 0
after(a, b) == before(b, a)
</pre>

Used throughout for ackno / seqno ordering checks.

Round-Trip Time (RTT) abbreviations used throughout:

<pre>
SRTT Smoothed RTT estimate (RFC 6298).
mdev Mean deviation of RTT (Linux variance estimator).
EWMA Exponentially Weighted Moving Average.
RTO Retransmission Timeout, max(RTO_MIN,
srtt + (mdev << MDEV_MUL)).
</pre>

Timer-bound symbols t_a (a-timer, ACK delay) and t_r (r-timer,
retransmission window) are defined in Section 8; t_mpl (Maximum
Packet Lifetime) is introduced in Section 2.1 (the inact field)
with heritage in Section 15.

Wire-format diagrams follow the IETF convention: bit 0 is the
leftmost (most significant) bit and fields are in network byte
order unless stated otherwise.

== 1. Wire format ==

=== 1.1. PCI header ===

Fixed 16-octet base Protocol-Control Information (PCI) header
prefixed to every FRCP packet (RFC convention: bit 0 leftmost,
most-significant bit first). All multi-byte fields except hcs
are in network byte order; hcs is an opaque 16-bit value that
the receiver recomputes from the wire bytes and compares to the
in-place pci->hcs 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
Section 1.5); SACK and RTTP carry their own payloads after the
base PCI.

<pre>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | hcs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ackno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload (variable) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>

<pre>
flags - feature/type bitmap (see 1.2).
hcs - CRC-16-CCITT-FALSE Header Check Sequence (HCS) over
flags + window + seqno + ackno (+ stream extension when
present); the two octets of the hcs field itself are
omitted from the CRC input. Verified on receive before
any flag-driven dispatch.
window - receiver-advertised right window edge (valid iff FC).
seqno - per-flow sequence number.
ackno - cumulative Acknowledgement (ACK) (valid iff ACK).
</pre>

A single packet can simultaneously carry DATA + ACK + FC (Flow
Control) + RXM (Retransmission) by ORing flag bits; the PCI
multiplexes control on the same wire frame in the spirit of SCTP
chunk bundling (RFC 9260 sec. 6.10) and QUIC frame multiplexing
(RFC 9000 sec. 12.4). DATA-bearing packets carry the caller's
payload after the PCI; SACK (Selective Acknowledgement) and RTTP
(Round-Trip Time Probe) carry their own typed payloads after the
PCI.

Optional framing (per-flow, see Section 2.2). On the wire, the
order from inside out is:

<pre>
[ PCI + body ] -- the FRCP packet
[ PCI + body + CRC-32 ] -- CRC-32 covers the body only (PCI
is in HCS); appended iff qs.ber
== 0 on DATA, or on every SACK
packet
[ AEAD-wrap of above ] -- iff Authenticated Encryption
with Associated Data (AEAD) is
enabled
</pre>

<pre>
- 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
0xEDB88320, init 0xFFFFFFFF, xor-out 0xFFFFFFFF) covers the
body on DATA when qs.ber == 0 and on every SACK packet; the
trailer is written as a raw uint32_t (the same convention as
hcs: 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.
- When encryption is enabled, the entire (possibly-CRC'd) FRCP
packet is wrapped with AEAD inside the shared-memory packet
buffer (spb, struct ssm_pk_buff); the packet grows by the AEAD
overhead, namely a leading nonce / Initialization Vector (IV)
of headsz bytes (crypt_get_ivsz) and a trailing authentication
tag of tailsz bytes (crypt_get_tagsz).
</pre>

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

=== 1.2. Flag bits ===

Flag bits are numbered most-significant-bit first to match the wire
diagram (bit numbering per Section 1.1; bit 0 is the MSB of the
16-bit flags field and lands at wire-position 0 in network byte
order). Bits 13..15 are reserved and MUST be transmitted as zero.

<pre>
+------+--------+--------+----------------------------------------+
| Bit | Mask | Name | Meaning |
+------+--------+--------+----------------------------------------+
| 0 | 0x8000 | DATA | Carries caller payload |
| 1 | 0x4000 | DRF | Data Run Flag: start of a fresh run |
| 2 | 0x2000 | ACK | Acknowledgement: ackno field valid |
| 3 | 0x1000 | NACK | Negative ACK; seqno = arrival_seqno-1 |
| 4 | 0x0800 | FC | Flow Control: window field valid (rwe) |
| 5 | 0x0400 | RDVS | Rendezvous probe (window-closed) |
| 6 | 0x0200 | FFGM | First Fragment (role bit 0; see below) |
| 7 | 0x0100 | LFGM | Last Fragment (role bit 1; see below) |
| 8 | 0x0080 | RXM | Retransmission |
| 9 | 0x0040 | SACK | Selective ACK block list in payload |
| 10 | 0x0020 | RTTP | RTT Probe / echo (payload follows) |
| 11 | 0x0010 | KA | Keepalive |
| 12 | 0x0008 | FIN | End-of-stream marker (stream mode) |
| 13-15| -- | -- | Reserved (MUST be zero) |
+------+--------+--------+----------------------------------------+
</pre>

The (FFGM, LFGM) pair encodes the fragment role of a DATA-bearing
Service Data Unit (SDU), SCTP-style begin/end flags (RFC 9260
sec. 3.3.1):

<pre>
+-----------+-------------------------------------------------+
| FFGM LFGM | Role |
+-----------+-------------------------------------------------+
| 1 1 | Sole / un-fragmented SDU (begin AND end) |
| 1 0 | First fragment of a multi-fragment SDU |
| 0 0 | Middle fragment |
| 0 1 | Last fragment |
+-----------+-------------------------------------------------+
</pre>

Each fragment is carried in its own FRCP packet with its own seqno;
FRTX (the FRCT Retransmission service mode, see Section 2.2)
recovers individual fragments via the normal Retransmission Timeout
(RTO) / SACK / Recent Acknowledgement (RACK, RFC 8985) path. The
receiver reassembles the SDU at consume time once the contiguous
[FIRST .. LAST] run has fully arrived. On non-DATA packets the role
bits are unused and MUST be transmitted as zero.

In stream mode (qos.service == SVC_STREAM, see Section 16) there are
no SDU boundaries to encode, so FFGM and LFGM are unused and MUST
be transmitted as zero. End-of-stream uses a dedicated bit (FIN,
bit 12) carried on a 0-byte DATA packet, emitted at write-half close
(fccntl to FLOWFRDONLY), during linger drain, and at flow_dealloc;
emission is idempotent (first call wins). After contiguous delivery
of the FIN-bearing slot, the receiver latches byte_fin at the FIN's
start offset; flow_read returns 0 (end-of-file, EOF) once buffered
bytes have been drained up to byte_fin. Per-byte position is
carried by the [start, end) extension (Section 1.5).

=== 1.3. SACK payload ===

A SACK packet has the FRCT_ACK | FRCT_FC | FRCT_SACK flag bits set
(bit numbering per Section 1.1). Following the 16-octet PCI, the
payload is a 2-octet block count (network byte order), 2 octets of
padding to 4-byte align the block list, then n_blocks pairs of
32-bit start/end seqnos describing *present* (received) ranges
above the cumulative ACK.

<pre>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_blocks | padding (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start[0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end[0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... n_blocks pairs total ...
</pre>

n_blocks <= SACK_MAX_BLOCKS (2048). The per-flow effective cap is
further bounded by (frag_mtu - PCI - 4) / 8 blocks per packet; SACK
packets carry no stream extension, so PCI here is the 16-octet base
header even on stream-mode flows.

Wire invariant: every block produced by the receiver, except an
optional leading Duplicate SACK (D-SACK) block as described below,
describes a range strictly above the cumulative ACK carried in the
PCI ackno field (after(start[i], ackno)). This makes the D-SACK
convention below unambiguous; the receiver-side builder MUST
preserve it.

Duplicate SACK (D-SACK, RFC 2883) is signalled in-band: no flag
bit, no extra framing. Modular seqno arithmetic uses the
before() / after() comparators defined in the Notation block.
Block[0] carries a D-SACK report when either:

<pre>
case 1 (RFC 2883 sec. 4.1.1, full duplicate):
before(blocks[0].start, ackno) and ackno - blocks[0].start is
within MAX_DSACK_LAG (== RQ_SIZE). A single duplicate seqno
observed below the cumulative ACK.
</pre>

<pre>
case 2 (RFC 2883 sec. 4.1.2, partial duplicate):
blocks[0] is a sub-range of some blocks[i>0] (not exactly
equal). Reports a duplicate of an in-window seqno that the
same packet's remaining SACK blocks already describe as
received.
</pre>

Senders that do not implement D-SACK process block[0] through the
normal SACK-mark loop and the existing clamp-and-skip path makes
case-1 a no-op (start < snd_cr.lwe clamps to snd_cr.lwe, the inner
loop then skips k == snd_cr.lwe) and case-2 idempotent (same slots
NULL'd twice). D-SACK-aware senders feed the report into the RACK
reo_wnd_mult scaler (RFC 8985 sec. 6.2 step 4): bump on receipt
(cap 20), halve once per 16 cumulatively-ACK'd seqnos since the
most recent D-SACK arrival or halve event, reset to 1 on an RTO
timer fire at the head-of-line. D-SACK alone never enters
NewReno-careful recovery (see Section 8); only non-D-SACK blocks
count as gaps.

=== 1.4. RTTP payload ===

An RTTP (Round-Trip Time Probe) packet has only the FRCT_RTTP flag
set (bit numbering per Section 1.1). Following the 16-octet PCI,
the payload is 24 octets (packed):

<pre>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| probe_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| echo_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ nonce (16 octets, echoed verbatim) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>

<pre>
probe_id - sender counter, 0 on reply, 0 reserved.
echo_id - peer's probe_id, 0 on outbound probe.
nonce - random, echoed unmodified, memcmp'd to defeat spoof.
</pre>

=== 1.5. Stream PCI extension ===

A stream-mode flow (qos.service == SVC_STREAM) carries an extra
8-octet extension after the 16-octet base PCI on every DATA packet
(bit numbering per Section 1.1):

<pre>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>

<pre>
start - octet offset of the first payload byte in the stream.
end - octet offset one past the last payload byte;
end - start equals the on-wire payload length.
</pre>

Total stream-mode PCI for DATA packets is 24 octets (16 base + 8
extension); control packets (SACK, RTTP, bare ACK, KA, etc.) retain
the 16-octet base PCI. Stream mode MUST be negotiated at flow
allocation; the extension is present iff stream mode is in use,
never on a per-packet basis. Both peers MUST treat start/end as
monotonic 32-bit byte offsets; when a slot reaches the head of the
contiguous run with start not equal to the prior packet's end the
slot is silently dropped at delivery time (Section 16) rather
than rejected at stash.

This is the QUIC STREAM-frame reassembly model (RFC 9000 sec. 19.8):
each packet carries its packet seqno (this PCI's seqno field) and a
separate stream byte position (start/end). Separating the two
avoids TCP's conflation of packet identity with byte position which
forces Karn's algorithm for Round-Trip Time (RTT) sampling (no RTT
sample on retransmits, RFC 6298 sec. 3); FRCP applies the
Karn-equivalent gate via a combination of per-packet FRCT_RXM,
per-slot SND_RTX flags, and a sample-fence rtt_lwe (see Section 2.1
and Section 12). FRCP's fixed-32-bit start/end wrap at 4 GiB of
wire bytes, narrower than QUIC's 62-bit varint offset (cf. RFC 9000
sec. 16); the on-wire wrap is handled by the same modular before()
/ after() comparators (Section 1.3) FRCP uses for seqnos, which
remain unambiguous as long as the in-flight byte window stays
strictly under 2 GiB (the half-range of the signed-int32 difference
in before()). The default per-flow ring is 1 MiB; the
implementation caps ring_sz at 128 MiB (FRCT_STREAM_RING_SZ_MAX),
well below the 2 GiB half-range bound. The runtime byte counters
exposed via FUSE (Filesystem in Userspace) in the Ouroboros
Resource Information Base (RIB, a virtual-filesystem introspection
bridge) are platform size_t and do not wrap on 64-bit hosts.

== 2. Per-flow state and service modes ==

=== 2.1. Per-flow state ===

Each flow keeps a sender control record and a receiver control
record:

<pre>
lwe : u32 snd: oldest unacked seqno (cumulative ACK
boundary as seen by sender);
rcv: next in-order seqno expected
rwe : u32 snd: peer-advertised right window edge;
rcv: locally-advertised right window edge
cflags : u8 per-direction feature flags: retransmission
(FRCTFRTX), receiver flow control
(FRCTFRESCNTL), linger-on-close (FRCTFLINGER);
see <ouroboros/fccntl.h>
seqno : u32 snd: next seqno to send;
rcv: force-ACK trigger - set on a stale or dup
DATA so the next ack_snd emits a fresh
cumulative ACK
ackno : u32 snd: outbound ACK-packet seqno counter,
incremented for every ACK-bearing packet (bare
ACK, delayed ACK, SACK); used by wire-dup ACK
detection;
rcv: incoming-ACK dedup tracker
act : ns last activity (used by inactivity / DRF)
inact : ns inactivity threshold; sender = 3*mpl + a + r + 1s,
receiver = 2*mpl + a + r + 1s. mpl is the
Maximum Packet Lifetime (delta-t terminology;
see Section 15); a and r are the FRCT a-timer
and r-timer bounds (see Section 8). The
asymmetry is load-bearing for pre-DRF NACK
(Section 9).
</pre>

The sender holds a per-slot ring snd_slots[RQ_SIZE] keyed by
(seqno mod RQ_SIZE). Each slot tracks its retransmit entry (rxm),
last-send timestamp, and retransmit flag bits: SND_RTX (a
retransmit is pending or has fired, gates the next RTT sample
under Karn) and SND_FAST_RXM (one-shot fast-retransmit staged for
this loss event).

The receiver holds a parallel reorder ring rcv_slots[RQ_SIZE]
(referred to as rq[] in prose) holding stashed out-of-order
packet-buffer indexes; both FRTX and best-effort flows share this
path. The invariant rwe - lwe <= RQ_SIZE holds: on each consume
the receiver advances rwe by the consumed count, capping the
receive window at RQ_SIZE seqno slots.

A separate fence variable rtt_lwe is bumped on every retransmit
(timer-fire, SACK-driven, fast-rxm, NACK-driven) and on every
seqno_rotate (Section 4) to mark the seqno range whose RTT samples
MUST be discarded.

=== 2.2. Service modes (orthogonal axes) ===

FRCP exposes its wire features as a vector of independent QoS
axes selected at flow allocation time. All flows go through the
same flow_alloc(name, qos, ...) primitive; the qosspec_t passed
in determines which protocol machinery engages on the wire. This
contrasts with the POSIX BSD socket model where TCP and UDP
require different socket types (SOCK_STREAM / SOCK_DGRAM).

The axes:

<pre>
service 0 = unordered (no FRCP engagement: raw datagrams,
no PCI on the wire, UDP-equivalent at this layer)
1 = message-ordered (FRCP engaged; SDU boundaries
preserved across fragmentation)
2 = stream (byte-oriented, no SDU boundaries; FRTX
required)
loss 0 = lossless service requested: FRTX retransmit
machinery engages (Section 8); MUST be 0 for
service=2. Non-zero = best-effort, FRTX off.
ber Bit Error Rate tolerance.
0 = error-free service requested: a CRC trailer is
appended after the body of DATA packets and verified
on receive (added / checked outside the FRCP PCI;
see Section 1.1). Non-zero = peer accepts errors;
trailer omitted. SACK control packets carry a
CRC32 trailer regardless of ber; the ber gate
applies to DATA only.
timeout Peer-timeout (ms); 0 disables the keepalive timer.
Independent of FRCP engagement.
</pre>

Encryption is a separate per-flow attribute set at flow setup;
when enabled it wraps the FRCP packet (PCI + body, plus the CRC
trailer if any) under AEAD, expanding the spb by headsz + tailsz
octets (nonce / tag). The CRC trailer is currently kept inside
the AEAD wrap (see Section 1.1).

Reachable combinations exported by include/ouroboros/qos.h:

<pre>
+-----------------+---------+------+-----+-----------------------+
| Cube | service | loss | ber | Engaged |
+-----------------+---------+------+-----+-----------------------+
| qos_raw | 0 | 1 | 1 | Raw passthrough |
| qos_raw_safe | 0 | 1 | 0 | Raw + CRC trailer |
| qos_rt | 1 | 1 | 1 | FRCP, no FRTX, no CRC |
| qos_rt_safe | 1 | 1 | 0 | FRCP, no FRTX, CRC |
| qos_msg | 1 | 0 | 0 | FRCP + FRTX |
| qos_stream | 2 | 0 | 0 | FRCP + FRTX, stream |
+-----------------+---------+------+-----+-----------------------+
</pre>

Forced couplings actually enforced by the public API:

<pre>
- service == SVC_STREAM (2) requires loss == 0; flow_alloc /
flow_accept reject the pair otherwise with -EINVAL.
- FRTX requires FRCP engagement (service != SVC_RAW); requesting
loss = 0 with service = SVC_RAW is structurally a no-op
because no frcti is created.
- The QOS_DISABLE_CRC build flag globally forces ber = 1.
Note: this flag defaults to ON, so default builds ship with
CRC disabled until QOS_DISABLE_CRC is set to OFF.
</pre>

Caveat: the API does NOT force ber = 0 when service != SVC_RAW.
qos_rt has service = SVC_MESSAGE with ber = 1, which means the PCI
itself is not CRC-protected on that cube; the HCS (Section 1.1)
remains the only integrity check on the header.

The FRCP-no-FRTX regime (service = SVC_MESSAGE, loss > 0) is meaningful
and live: sequence numbering, in-order delivery, flow-control
advertisement, KA, DRF rotation, and SDU fragmentation /
reassembly (Section 7.2) all run. Lost packets are dropped
rather than retransmitted; a permanently-lost mid-fragment is
dropped via skip-past-gap once a later SDU is visible in the
reorder ring.

== 3. Protocol parameters ==

<pre>
+--------------------+------------------------+-------------------+
| Parameter | Value | Role |
+--------------------+------------------------+-------------------+
| RQ_SIZE | compile-time, power of | Slot ring / rcv |
| | 2 (default 128) | window width |
| START_WINDOW | compile-time, power of | Initial rwe-lwe |
| | 2 (default 128) | after rotate |
| RTO_MIN | MAX(250 us build-tun- | RTO floor; also |
| | able, 1<<RXMQ_RES); | floored at the |
| | per-flow via fccntl | retransmit-wheel |
| | (FRCTSRTOMIN). | resolution |
| | Default ~1 ms with | (~1 ms by |
| | RXMQ_RES=20. | default). |
| MAX_RTO_MUL | 20 | Backoff shift cap |
| RACK window R | MIN(reo_wnd_mult | Reorder window; |
| | * min_RTT/4, SRTT) | per RFC 8985 |
| | with MIN_REORDER_NS | sec. 6.2; |
| | = 250 us floor; | reo_wnd_mult per |
| | reo_wnd_mult scales | sec. 6.2 step 4 |
| | on D-SACK, cap 20 | |
| MIN_RTT_WIN_NS | 300 s (5 min, Linux | min_RTT windowed |
| | tcp_min_rtt_wlen) | re-anchor |
| REO_WND_MULT_MAX | 20 (RFC 8985 sec. | reo_wnd_mult cap |
| | 6.2 step 4) | |
| REO_DECAY_PKTS | 16 (RFC 8985 sec. | Fresh-ACK'd seq |
| | 6.2 step 4 / | count per halving |
| | RACK.reo_wnd_persist) | |
| MAX_DSACK_LAG | RQ_SIZE | D-SACK sanity cap |
| RTT_QUARANTINE | 32 (seqno steps) | NewReno gate pad |
| SACK rate-limit | SACK_MIN_GAP_NS | Min SACK gap |
| | (250 us, fixed) | |
| SACK_MAX_BLOCKS | 2048 (wire cap; per- | Per-SACK block |
| | flow capped at | cap |
| | (frag_mtu-PCI-4)/8) | |
| SACK_RXM_MAX | 32 | Per-pass staged |
| | | retransmit cap |
| DUP_THRESH | 3 (RFC 8985 default) | Hybrid fast-rxm |
| | | trigger (Sec. 8) |
| MDEV_MUL | 2 (build-tunable via | mdev shift in |
| | FRCT_RTO_MDEV_- | RTO = srtt + |
| | MULTIPLIER) | (mdev << MDEV_MUL)|
| RTTP nonce | 16 octets | Echoed verbatim |
| RTTP_RING | 8 | In-flight probes |
| RTT clamp | 16 * srtt | Probe-sample |
| | | upper bound |
| | | (ACK-derived RTT |
| | | samples gated by |
| | | Karn / recovery |
| | | only) |
| Cold-probe cadence | 100 ms (rx-driven; | Pre-srtt RTTP |
| | see Section 12) | rate |
| DELT_RDV | 100 ms | RDVS emit cadence |
| MAX_RDV | 1 s | RDVS give-up |
| Delayed-ACK fire | 2 * TICTIME (TICTIME | Fired after the |
| | = FRCT tick gran- | first in-order |
| | ularity, default | DATA arrival; |
| | 5 ms; 2*TICTIME | tick is build- |
| | = 10 ms by default) | tunable |
| NACK send cooldown | srtt when an srtt | Pre-DRF NACK |
| | sample exists, else | rate-limit |
| | 100 ms | |
| MAX_SDU | 1 MiB | Max reassembled |
| | | SDU; configurable |
| | | per flow |
+--------------------+------------------------+-------------------+
</pre>

The per-flow fragment Maximum Transmission Unit (MTU) is computed
at flow setup from the lower IPCP's mtu minus encryption
headsz / tailsz and CRC trailer; there is no FRCT-level default or
environment-variable override.

== 4. Sequence-number rotation (DRF) ==

The DRF (Data Run Flag) bit on an outbound packet means "this is
the start of a fresh data run" and is set whenever the sender has
nothing in flight (snd_cr.seqno == snd_cr.lwe).

Independently of that, if the sender has been idle longer than
snd_cr.inact AND the pipe is empty (snd_cr.seqno == snd_cr.lwe),
seqno_rotate() rolls a random new seqno before the send and
resets

<pre>
snd_cr.seqno = random()
snd_cr.lwe = snd_cr.seqno
snd_cr.rwe = snd_cr.seqno + START_WINDOW
rtt_lwe = snd_cr.seqno
in_recovery = false (recovery state, see Section 8)
recovery_high = snd_cr.seqno
</pre>

The receiver, on observing rcv-side inactivity
(now - rcv_cr.act > rcv_cr.inact), requires a DRF on the next
DATA packet; otherwise it replies with a rate-limited NACK (see
below). Non-DATA control packets pass through without the DRF
requirement. On DRF the receiver releases the rq[] slots and
rebases

<pre>
rcv_cr.lwe = seqno
rcv_cr.rwe = seqno + RQ_SIZE
rcv_cr.seqno = seqno
</pre>

If the inactive packet has DATA but no DRF, a rate-limited NACK is
fired back to the sender (cooldown per Section 3); non-DATA stale
arrivals fall through to normal processing (no NACK, no drop).

== 5. Send path ==

<pre>
1. If the SDU exceeds (frag_mtu - data_hdr_len), the caller
(dev.c) fans it out into ceil(count / (frag_mtu -
data_hdr_len)) fragments, each emitted via frcti_snd as its
own DATA packet with a per-fragment role (Section 7.2);
both FRTX and best-effort flows fragment. Raw flows (no
FRCP engagement, qos.service == SVC_RAW) carry no PCI and
return -EMSGSIZE for any SDU larger than one packet at the
layer below. An SDU that fits in a single packet is sent
as SOLE. frcti_snd reserves PCI head room; sets DATA, plus
DRF when the pipe is empty (snd_cr.seqno == snd_cr.lwe).
2. seqno_rotate() if past sender inactivity and the pipe is
empty (Section 4).
3. Advertise FC (pci.window = frcti_advert_rwe(frcti), i.e.
rcv_cr.rwe clamped to rcv_cr.lwe + ring_seq_cap in stream
mode) when the receiver side is recent: now - rcv_cr.act
< rcv_cr.inact.
4. Reliable mode (FRTX): leave snd_cr.lwe where it is; reset
the slot at RQ_SLOT(seqno) (snd_slots[p].time = now,
snd_slots[p].flags = 0); queue an rxm_entry (saves a packet
copy, arms a wheel timer at now + (rto << rto_mul)).
Piggyback ACK (pci.ackno = rcv_cr.lwe) while the a-timer
for the most recent received DATA packet has not yet
expired (now - rcv_cr.act <= t_a); on piggyback, set
rcv_cr.seqno = rcv_cr.lwe so the next delayed-ACK fire is
suppressed. See Section 8 for t_a / t_r semantics.
5. Best-effort mode (no FRTX): advance snd_cr.lwe immediately
(snd_cr.lwe = snd_cr.lwe + 1, snd_cr.rwe = snd_cr.lwe +
RQ_SIZE); no retransmit state. No send-side RTT probe is
armed in this mode (rtt_probe_arm requires an in-flight
seqno, which best-effort never has); the rx-driven cold
seeder in frcti_rcv is the only probe path.
6. In reliable mode, optionally arm an RTT probe (Section 12).
</pre>

== 6. Receive path ==

=== 6.1. Early-exit dispatch ===

Keepalive (KA), RTT probe (RTTP), pre-DRF NACK, and rendezvous
(RDVS) packets short-circuit out of frcti_rcv before the locked
main path; each handler takes its own lock internally.

<pre>
incoming packet
|
v
+---------+
| KA? |---yes--> ka_rcv ; return
+---------+
|no
v
+---------+
| RTTP? |---yes--> rttp_rcv; return
+---------+
|no
v
+---------+
| NACK? |---yes--> nack_rcv; return (see Section 9)
+---------+
|no
v
+---------+
| RDVS? |---yes--> rdv_rcv ; return (reply bare FC, ackno=0)
+---------+
|no
v
acquire wrlock; enter locked main path
</pre>

<pre>
- KA : refresh t_ka_rcv, honour piggybacked ACK.
- RTTP : probe (echo back nonce) or echo (verify nonce, sample
RTT).
- NACK : pre-DRF, sender-side handler. See Section 9.
- RDVS : reply with a bare FC packet (ackno = 0); rdlock only.
</pre>

=== 6.2. Locked main path ===

Steps below run with the per-flow frcti.lock held for writing
(pthread_rwlock_wrlock) unless noted.

<pre>
rcv_inact_check
Only meaningful when the receive side is stale. On DRF
(Data Run Flag): release rq[] slots, rebase rcv_cr, continue.
On stale DATA without DRF: fire a pre-DRF NACK if cooldown
allows (Section 9), then discard the packet; on cooldown,
drop without sending a NACK (a pending cumulative ACK from
drop_packet may still go out). Non-DATA, non-DRF arrivals
bypass rcv_inact_check entirely; pure-DRF stale arrivals fall
through after the DRF rebase branch.
</pre>

<pre>
DATA-only act refresh
Refresh rcv_cr.act only when FRCT_DATA is set, so that non-DATA
packets never block the next DRF rebase.
</pre>

<pre>
Wire-dup gate
Before flag-driven dispatch, drop wire-duplicate ACKs and
wire-duplicate DATA (is_dup_ack / is_dup_data). The DATA
check is bypassed for FRCT_RXM-bearing arrivals so the
piggybacked ACK / SACK / FC carried on a retransmitted DATA
at an already-ACK'd seqno is still applied; the stale-in-
window branch below then drops the packet.
</pre>

<pre>
ACK
Drop ACKs whose ackno falls outside (snd_cr.lwe, snd_cr.seqno].
If ackno == snd_cr.lwe (non-advancing cumulative ACK), drive
RACK fast-retransmit consideration (Section 8). Otherwise
advance snd_cr.lwe = ackno, collapse rto_mul to 0 (Karn-gated
by SND_RTX on the just-acknowledged slot, the old head-of-
line), reset dup_thresh to 0, update t_latest_ack to the
send-time of the slot at ackno-1 (consumed by RACK and SACK
below), decay reo_wnd_mult per RFC 8985 sec. 6.2 step 4,
exit NewReno-careful recovery (see Section 8) on
ackno >= recovery_high or ackno == snd_cr.seqno, and feed an
RTT sample if eligible (Section 12).
</pre>

<pre>
SACK
Walk the block list. For each block (a present range above
lwe) NULL out snd_slots[k].rxm, clear the slot's per-send
flags, and advance t_latest_ack to the latest send-time
covered (the Forward Acknowledgement / fack equivalent,
Mathis & Mahdavi 1996); the first block whose start
clamps to snd_cr.lwe skips this fack update so that a head-
of-line clamp does not falsely advance fack. For un-SACKed
gaps below hi_sacked, stage a retransmit per slot that is
(1) still owned (rxm != NULL), (2) not already SND_FAST_RXM,
(3) not aged out past t_r, and (4) either outside the RACK
reorder window R OR with dup_thresh >= DUP_THRESH (the RFC
8985 sec. 6.2 hybrid trigger). Mark the slot SND_FAST_RXM
and NULL the rxm at stage time. Capped at SACK_RXM_MAX
staged retransmits per receive pass; what's left rides the
next SACK.
</pre>

<pre>
FC
Bump snd_cr.rwe (clamped to lwe + RQ_SIZE, never shrinks)
and mark window open.
</pre>

<pre>
DATA
Bounds-check seqno against window. On stale-dup
(seqno < rcv_cr.lwe), set rcv_cr.seqno = seqno to force a
fresh ACK on the next ack_snd, then drop. On accept: both
FRTX and best-effort stash the packet-buffer index into
rq[seqno mod RQ_SIZE]. Fragments stash unchanged - the role
bits are inspected only at consume time (Section 7.2). On
out-of-order arrival, build a SACK reply if not rate-limited
(per Section 3) and not deduplicated against the previous
(rcv_cr.lwe, n_blocks) pair; D-SACK reports always bypass the
dedup. If both rate-limit and dedup suppress the reply,
neither SACK nor delayed-ACK fires (the sender picks up the
gap on its next ACK). On in-order arrival, arm the delayed-
ACK timer.
</pre>

<pre>
drop_packet exit
Releases the per-packet shared-memory buffer (spb), then
calls ack_snd synchronously after the spb release to surface
any pending cumulative ACK.
</pre>

== 7. Read path and reassembly ==

=== 7.1. Read path ===

flow_read returns a full reassembled SDU (Service Data Unit) via
frcti_consume on every FRCP SDU-mode flow (FRTX or best-effort);
stream-mode is covered in Section 16. An incomplete head-of-line
(HoL) run yields -EAGAIN; an oversized run yields -EMSGSIZE (the
run is dropped so the flow does not stall). On best-effort flows,
a permanently-lost mid-fragment is dropped as soon as a later
complete SDU becomes visible in the ring (Section 7.2 skip-past-
gap).

Raw flows carry no frcti, so flow_read returns the next pending
packet-buffer index directly, with no role-bit inspection. (Raw
service is selected via qos.service == SVC_RAW at flow allocation,
which suppresses frcti creation.)

frcti_pdu_ready is the no-advance peek used by fevent (the
Ouroboros flow-event multiplexer, the poll(2)-equivalent on
flows). It returns ready only when the head-of-line run is
complete and the lead packet (a Protocol Data Unit, here one FRCP
packet) is present at rcv_cr.rwe - RQ_SIZE; any other state
(including the best-effort skip-past-gap case) returns not ready,
and frcti_consume is left to drop the broken prefix and re-
inspect.

=== 7.2. Fragmentation and reassembly ===

Send side (flow_write_frag). An SDU larger than
(frag_mtu - PCI) is split into ceil(count / (frag_mtu - PCI))
fragments; each fragment is its own FRCP packet with its own
seqno and a per-fragment role flag pair (Section 1.2). Roles are
assigned at emit time:

<pre>
+------+--------+
| i | Role |
+------+--------+
| n=1 | SOLE |
| i=0 | FIRST |
| i=n-1| LAST |
| else | MID |
+------+--------+
</pre>

A mid-loop allocation or transmit failure may yield a partial
write: the call returns the bytes already enqueued (off > 0) or
the underlying error (off == 0). Best-effort flows fragment
identically; on the receiver, a partial run with a permanently-
lost fragment is dropped when a later complete SDU is visible in
the ring (see skip-past-gap below). Raw flows carry no PCI and
refuse anything larger than the layer's user MTU (-EMSGSIZE).

Wire-level recovery is fragment-agnostic on FRTX flows: each
fragment's seqno flows through SACK / RACK / RTO / NACK exactly
as for a SOLE DATA packet, and reassembly does not re-enter the
loss-detection path. Best-effort flows run the same seqno
machinery (DRF, FC, ACK piggyback, pre-DRF NACK emit) but queue
no rxm state at the sender, so a lost MID is unrecoverable;
skip-past-gap handles it (below).

Receive side. Fragments stash into rq[seqno] unchanged; role bits
are read only at consume time. frag_run_inspect, called from
frcti_consume, walks the ring starting at the oldest still-
undelivered seqno base = rcv_cr.rwe - RQ_SIZE (equal to rcv_cr.lwe
only when no partial run is in progress; during a partial run lwe
has already advanced past base). It produces one of three
outcomes:

<pre>
+---------------+---------------------------------------------+
| Outcome | Cause |
+---------------+---------------------------------------------+
| DELIVER (n) | rq[base]=SOLE (n=1), or rq[base]=FIRST and |
| | a LAST follows in slots [base+1..base+n-1] |
| | with all intermediate roles in {MID,FIRST, |
| | LAST} contiguous. |
| DROP (n) | rq[base] is MID or LAST without a preceding |
| | FIRST (n=1); a FIRST..[non-LAST]..new-FIRST |
| | or new-SOLE mid-run (drop the broken prefix |
| | with n = run length minus 1, so the new |
| | FIRST/SOLE stays); or, on best-effort |
| | flows, a gap at base with a FIRST/SOLE |
| | later in the ring (drop up to the new run |
| | start). |
| NOT_READY | rq[base] absent or FIRST..[non-LAST] with |
| | no later FIRST/SOLE in the ring (FRTX waits |
| | for retx; best-effort waits for arrival). |
+---------------+---------------------------------------------+
</pre>

DELIVER triggers frag_gather: a scatter-gather memcpy of the n
consecutive fragments at rq[base..base+n-1] directly into the
caller's buffer; each per-packet shared-memory buffer (spb) is
released and rwe advances by n. lwe was already advanced
incrementally as each contiguous fragment arrived; frag_gather
only restores the fixed-width invariant rwe == lwe + RQ_SIZE.
No intermediate reassembly buffer is allocated.

DROP advances rwe past the broken prefix (releasing the spbs)
and pulls lwe up to the new trailing edge if needed; the next
consume retries from the new base. Oversize or arithmetically
overflowing delivery (sum of fragment lengths > max_rcv_sdu, sum
> caller's buffer, or running-sum overflow) also drops the run
with -EMSGSIZE.

Skip-past-gap (best-effort only). On FRTX, a gap in the run means
"waiting for retransmit" and frag_run_inspect returns NOT_READY.
On best-effort flows the gap is permanent, so frag_run_inspect
scans forward in the ring for the next FIRST or SOLE; if one is
visible within RQ_SIZE, it returns DROP for the broken prefix and
the consume loop retries at the new lwe. Memory hold is bounded
by RQ_SIZE; the partial releases on the next consume call once a
later complete run exists. Voice-like flows (one SOLE per SDU)
see no extra wait: any later SOLE makes the prior gap droppable
immediately.

The choice to defer reassembly to consume time keeps the receive
path zero-copy: fragments stay in the shared-memory ring until
the application pulls, and the SDU lands directly in the caller's
buffer.

== 8. Retransmission ==

FRCP is bounded by two delta-t-derived timers (Watson 1981, see
Section 15):

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

Each in-flight FRTX seqno owns one rxm_entry, armed in a hashed
timing wheel; the wheel deadline is the slot's next eligible
retransmit time.

<pre>
RTO timer
On fire (rxm_due), re-emit with FRCT_RXM, mark SND_RTX
(Karn-suppress next ACK's RTT sample), and (for the head-of-
line (HoL) slot only) bump rto_mul up to MAX_RTO_MUL. Wheel
deadline is t_send + (rto << rto_mul). Re-armed unless
consumed. The RTO timer also clears SND_FAST_RXM (re-arming
fast-retransmit eligibility), resets reo_wnd_mult to 1 on a
HoL fire (RFC 8985 sec. 6.2 step 4 reset clause), and marks
the flow ACL_FLOWDOWN if its frct_tx call fails.
</pre>

<pre>
r-timer guard
Before any retransmit attempt, check (now - t0) against t_r.
If exceeded, the slot is no longer eligible for retransmit.
Only the RTO timer (rxm_due) treats r-timer expiry as
terminal: it marks the flow ACL_FLOWDOWN (peer unreachable).
Fast-retransmit, SACK-driven retransmit, and NACK-driven
head-of-line re-emit silently skip aged-out slots and defer
the flow-down decision to the next RTO fire.
</pre>

<pre>
Fast retransmit (hybrid trigger, RFC 8985 sec. 6.2)
On a non-advancing cumulative ACK with the scoreboard
advanced, fire one fast retransmit when EITHER (a) the head-
of-line slot's latest send is older than the RACK reorder
window R (Section 3) and not yet aged out, OR (b) the SACK
dup-thresh count above snd_cr.lwe reaches DUP_THRESH (= 3,
RFC 8985 sec. 6.2 step 4). Fires at most once per non-
advancing cumulative-ACK value, gated by rack_fired_lwe (the
snd_cr.lwe at which fast-retransmit last fired). Set
SND_FAST_RXM on the slot (one-shot per-slot gate) and enter
NewReno-style careful recovery (see NewReno below in this
section).
</pre>

<pre>
The RACK reorder window R uses the RFC 8985 sec. 6.2 form
R = MIN(reo_wnd_mult * min_RTT / 4, SRTT) with a
MIN_REORDER_NS = 250 us floor. Before the first RTT sample
seeds min_rtt, R falls back to MIN(reo_wnd_mult * SRTT / 4,
SRTT), still floored at MIN_REORDER_NS (consistent with the
windowed-minimum fallback described in Section 12). min_rtt
is a windowed minimum over the last MIN_RTT_WIN_NS = 5 min of
RTT samples (matches the Linux tcp_min_rtt_wlen default) so a
route change to a longer path eventually re-anchors the
reorder window without relying on reo_wnd_mult growth alone.
</pre>

<pre>
SACK-driven retransmit
For each gap below hi_sacked whose slot is (1) still owned,
(2) not already SND_FAST_RXM, (3) not aged out past t_r, and
(4) either outside the RACK window R OR with dup_thresh >=
DUP_THRESH (same hybrid as fast-retransmit, see Section 6.2),
re-emit. Each SACK-driven retransmit re-arms a fresh rxm so
a lost retransmit can still be recovered by its own RTO
timer.
</pre>

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

== 9. Pre-DRF NACK ==

The two sides have different inactivity thresholds
(snd_cr.inact > rcv_cr.inact), 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.

<pre>
Send (frcti_nack_snd, called by frcti_rcv when rcv_inact_check
returns FRCT_INACT_NEED_NACK)
When an incoming DATA packet has no DRF and rcv-side activity
is older than rcv_cr.inact, the receiver emits a bare packet
with flags = FRCT_NACK and seqno = arrival_seqno - 1
(informational only, not consulted by the receive handler).
The cooldown in Section 3 rate-limits the burst. Non-DATA
non-DRF arrivals bypass rcv_inact_check entirely; non-DATA
DRF still rebases via the DRF branch.
</pre>

<pre>
Receive (frcti_nack_rcv)
Dispatched in the early-exit branch (Section 6.1), before
rcv_inact_check. The sender copies the head-of-line (HoL)
rxm packet, marks the slot SND_RTX | SND_FAST_RXM (Karn-
suppress next ACK, one-shot fast-rxm gate), sets rtt_lwe =
snd_cr.lwe + 1, and re-emits via fast_rxm_send with FRCT_RXM
and a refreshed ackno. The original rxm_entry 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 t_r, or
the HoL rxm pointer has been cleared by SACK or RACK.
</pre>

NACK serves two roles:

<pre>
1. 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 srtt is seeded by the first probe round-trip).
2. 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.
</pre>

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

== 10. Cumulative + selective ACK ==

Cumulative ACK is ackno = rcv_cr.lwe. On out-of-order arrival the
receiver also emits a SACK packet (Section 1.3) whose payload lists
*present* blocks above lwe (analogous to TCP SACK / QUIC ACK
ranges). SACKs are rate-limited per Section 3 and suppressed when
neither lwe nor block count has changed since the last SACK.

D-SACK reports (RFC 2883) are emitted in-band as block[0] of an
otherwise normal SACK frame (see Section 1.3 for the encoding).
Two receiver triggers arm a pending D-SACK report (single-slot,
latest-wins):

<pre>
- DATA arrival with seqno < rcv_cr.lwe, both wire-dup (no RXM,
is_dup_data path) and retransmit (RXM, post-FC branch)
(RFC 2883 sec. 4.1.1, full duplicate)
- rq_accept conflict, slot already occupied in [lwe, rwe)
(RFC 2883 sec. 4.1.2, partial duplicate)
</pre>

When a D-SACK is pending and the standard scoreboard SACK would be
suppressed by dedup or rate-limit, the report is emitted as a
stand-alone SACK frame through the normal ack_snd path; when a
D-SACK report is pending the path bypasses dedup and the TICTIME
rate-limit, but the a-timer suppression on rcv inactivity still
applies.

Bare ACKs are deferred via a per-flow delayed-ACK timer (one in
flight at a time, atomic test-and-set dedup; fires per Section 3
after the first in-order arrival). Suppressed if (1) no new
seqno, (2) rcv side is inactive (older than t_a), or (3) the
sender just sent within TICTIME. A pending D-SACK ride-through
bypasses (1) and (3); the a-timer gate (2) is unconditional.

== 11. Flow control ==

The receiver advertises rwe in every FC field. The sender treats
its snd_cr.rwe as the absolute right edge: when
snd_cr.seqno >= snd_cr.rwe the window is closed and flow_write
yields. While closed, the sender periodically emits RDVS
(rendezvous) packets (cadence DELT_RDV); the receiver replies with
a bare FC packet (ackno = 0) that reopens the window. Once the
window has been closed for longer than MAX_RDV the sender stops
emitting RDVS but does not tear the flow down - the writer keeps
blocking until either a peer-driven FC arrives or the KA
(keepalive) / r-timer marks the flow.

rwe is clamped to lwe + RQ_SIZE on receipt and MUST NOT shrink:
a backward rwe is silently clamped to the current snd_cr.rwe;
the FC packet still reopens the window.

== 12. RTT estimation ==

Active RTTP probes (Section 1.4) carry a 32-bit probe_id (0
reserved) and a 16-byte random nonce echoed verbatim - defends
against spoofed replies. A ring of RTTP_RING in-flight probes is
kept; an echo whose (id, nonce) doesn't match the ring slot is
dropped. A single RTTP sample is clamped to RTT_CLAMP_MUL * srtt
(compile-time RTT_CLAMP_MUL = 16) once srtt is seeded; the first
cold-probe sample feeds rtt_update raw.

Probe arming gates:

<pre>
- Cold (no srtt yet): the receive path arms at most one probe
per 100 ms via frcti_rcv_probe (PROBE_DUE_COLD); arming
requires an incoming packet. Active send-path arming bails
while srtt == 0.
- Warm (rtt_probe_arm, called from frcti_snd): outstanding
data (snd_cr.seqno > snd_cr.lwe), AND at least 2 * srtt
since t_rcv_rtt (last RTT receive of any kind), AND at
least srtt since t_snd_probe (last probe emit).
</pre>

Sample feeds either Linux's asymmetric mdev estimator
(FRCT_LINUX_RTT_ESTIMATOR, default ON) or RFC 6298 symmetric EWMA
(compile option). srtt is floored at 10 ms when seeded from a
hint, at 1 us after every update (including the first seeding
sample); mdev floored at 100 ns.

<pre>
RTO = max(rto_min, 2 * srtt, srtt + (mdev << MDEV_MUL))
</pre>

(the 2 * srtt floor is an FRCT addition not in RFC 6298).
Effective wheel deadline capped per Section 3.

ACK-derived samples (frcti_ack_rcv -> rtt_sample_eligible), beyond
the cum-ACK advance gate in frcti_ack_rcv (ackno > lwe and
ackno <= seqno), require all of: not in recovery; ACK packet does
not carry FRCT_RXM; HoL slot's SND_RTX bit clear; slot's rxm
pointer non-NULL (not SACK-consumed); lwe not below the rtt_lwe
fence; srtt already seeded by an RTTP probe. There is no ACK-only
seeding.

Every eligible sample also feeds RACK.min_RTT (RFC 8985 sec. 6.2)
via a windowed minimum: replace whenever the sample is strictly
smaller OR more than MIN_RTT_WIN_NS (5 min, matches Linux
tcp_min_rtt_wlen) has elapsed since the current min was set. The
downward branch is immediate (faster path picked up at once); the
upward branch is gated on the window (a transient queue burst does
not poison the estimate, but a sustained route change to a longer
path re-anchors min_RTT after at most one window). Seeded from
rtt_hint at rtt_init; 0 acts as the unset sentinel and the base
in rack_reorder_window falls back from min_RTT to SRTT (so
R = mult * SRTT/4, capped at SRTT, floored at MIN_REORDER_NS)
until the first sample. See Section 6.2.

== 13. Liveness (keepalive) ==

When qs.timeout > 0 a per-flow KA (keepalive) timer is armed.
Arming uses rcv_cr.act for the deadline computation:

<pre>
deadline = min(snd_act + qs.timeout/4,
rcv_act + qs.timeout)
</pre>

(clamped to now + qs.timeout/4 if already past). The timer fires
either on sender idleness (to send a KA) or on receiver idleness
(to declare the peer dead). On fire (ka_snd) the peer-dead test
uses max(rcv_cr.act, t_ka_rcv) so a recent KA reply counts even
when no DATA has arrived:

<pre>
- If now - max(rcv_cr.act, t_ka_rcv) > qs.timeout, mark the flow
ACL_FLOWPEER and notify the per-process flow-event set
(proc.fqset) with FLOW_PEER.
- Else if snd_idle > qs.timeout/4, emit a bare KA | ACK
(ackno = rcv_cr.lwe) and re-arm.
- Else just re-arm.
</pre>

Note: rx_rb and tx_rb are the receive and transmit shared-memory
ring buffers. The r-timer raises ACL_FLOWDOWN on both (route is
broken); keepalive raises ACL_FLOWPEER on rx_rb only and notifies
the flow-event set (peer is silent, writer keeps tx_rb usable) -
distinct ACLs. qs.timeout == 0 disables keepalive entirely; a
silent peer crash is then undetected.

== 14. Linger / teardown ==

On flow_dealloc, frcti_dealloc computes a grace timeout

<pre>
max(rcv_cr.act + rcv_cr.inact, snd_cr.act + snd_cr.inact) - now
</pre>

(floored at 0 and converted to seconds) and returns it; flow_dealloc
forwards this to the IRMd as the dealloc grace. The IRMd, not FRCT,
performs the wait. Before computing the timeout, FRCT may emit a
final ACK when rcv_cr.lwe != rcv_cr.seqno (the peer has not been
told the most recent cumulative ACK) AND the rcv side has been
active within t_a (a-timer not aged out).

FRCTFLINGER is honoured only when snd_cr.lwe < edge, where edge =
snd_fin_seqno after FIN has been sent in stream mode and
snd_cr.seqno otherwise (data or FIN still in flight). The drain
itself runs in flow_dealloc's while (FRCTI_LINGERING) loop, not in
frcti_dealloc.

The fd is single-reader / single-writer (documented in the
manpages). flow_write pumps rx_rb on every call (via
flow_wait_window -> flow_drain_rx_nb) and additionally blocks on
rx_rb when the send window is closed. A pure-writer thread thus
consumes ACKs without a dedicated reader.

== 15. Heritage and adopted techniques ==

Delta-t (Watson, 1981) is the primary heritage; FRCP descends from
the delta-t protocol family via the Recursive InterNetwork
Architecture (RINA; Day, "Patterns in Network Architecture", 2008,
ch. 9). Timer-based connection management
(no SYN/FIN handshake, per-flow state born on first DATA and
reclaimed after t_mpl + a + r of silence), the DRF marker, and the
t_mpl / t_a / t_r timers all come from delta-t. See Watson,
"Timer-Based Mechanisms in Reliable Transport Protocol Connection
Management", Computer Networks 5 (1981).

The unified `flow_alloc(name, qos, ...)` primitive and its
multi-axis QoS-cube argument (Section 2.2) also come from RINA
(Day 2008, ch. 6; Grasa et al., "IRATI: investigating RINA as an
alternative to TCP/IP", Computer Networks 92 (2015)) - reliability,
ordering, CRC presence, and encryption are flow attributes, not
separate sockets or protocols.

The table below summarises additional adopted techniques and their
references.

<pre>
+------------------------+------------------+------------------------+
| FRCP mechanism | Heritage | Reference / note |
+------------------------+------------------+------------------------+
| Random new seqno on | TCP ISN | RFC 6528 (Gont & |
| seqno_rotate | | Bellovin, 2012). |
| | | QUIC PN-space reset |
| | | (RFC 9000 sec. 12.3) |
| | | is a structural |
| | | analogue. |
+------------------------+------------------+------------------------+
| Cumulative ACK, | TCP | RFC 793 / RFC 9293 |
| left-window-edge | | |
| advance | | |
+------------------------+------------------+------------------------+
| Receive window with | TCP | RFC 793 sec. 3.7 / |
| non-shrink rule | | RFC 9293 sec. 3.8.6; |
| | | RFC 1122 sec. 4.2.2.16 |
| | | for the explicit non- |
| | | shrink prohibition |
+------------------------+------------------+------------------------+
| Modular seqno | TCP | RFC 793 sec. 3.3 / |
| arithmetic | | RFC 9293 sec. 3.4 |
| (before/after helpers) | | |
+------------------------+------------------+------------------------+
| Selective ACK block | TCP | RFC 2018 (Mathis et |
| list | | al., 1996). Encoded |
| | | as a typed FRCP packet |
| | | rather than a TCP |
| | | option, so framing is |
| | | closer to QUIC ACK |
| | | frames. D-SACK (RFC |
| | | 2883) carried in-band |
| | | as block[0]; see |
| | | Section 1.3. |
+------------------------+------------------+------------------------+
| NewReno-careful | TCP | RFC 6582 (Henderson |
| recovery with | | et al., 2012); QUIC |
| recovery_high gate | | builds on the same |
| | | model in RFC 9002 |
| | | sec. 7.3.2. Cwnd half |
| | | absent (CC in IPCP). |
+------------------------+------------------+------------------------+
| RACK reordering | TCP | RFC 8985 (Cheng et |
| window for fast | | al., 2021). FRCP |
| retransmit | | R = MIN(reo_wnd_mult * |
| | | min_RTT / 4, SRTT) |
| | | with a MIN_REORDER_NS |
| | | = 250 us floor against |
| | | srtt collapse; matches |
| | | RFC 8985 sec. 6.2 and |
| | | Linux tcp_rack_reo_wnd.|
| | | DSACK-driven |
| | | reo_wnd_mult (sec. 6.2 |
| | | step 4) is adopted; |
| | | see Section 1.3 for |
| | | the wire encoding. |
| | | The hybrid RACK-or- |
| | | DUP_THRESH trigger |
| | | from RFC 8985 sec. 6.2 |
| | | step 4 is adopted |
| | | (Section 8). QUIC's |
| | | analogue in RFC 9002 |
| | | sec. 6.1.2 uses |
| | | max(srtt, latest_rtt) |
| | | as the base. |
+------------------------+------------------+------------------------+
| Karn's algorithm: | TCP | Karn & Partridge, |
| no RTT sample on | | "Improving Round-Trip |
| retransmits, RTO- | | Time Estimates in |
| collapse freeze | | Reliable Transport |
| | | Protocols", SIGCOMM |
| | | 1987; RFC 6298 sec. 3. |
+------------------------+------------------+------------------------+
| RTO formula | TCP | RFC 6298 (Paxson et |
| RTO = max(RTO_MIN, | | al., 2011). RTO_MIN = |
| srtt + (mdev << | | 5 ms is below RFC 6298 |
| MDEV_MUL)) | | sec. 2.4's 1 s SHOULD- |
| | | floor - a recursive- |
| | | layer choice. |
+------------------------+------------------+------------------------+
| Linux asymmetric mdev | Linux kernel | tcp_rtt_estimator() in |
| estimator (default) | | net/ipv4/tcp_input.c; |
| | | the if(delta<0) m>>=3 |
| | | dampening is a |
| | | kernel divergence from |
| | | RFC 6298. RFC 6298 |
| | | EWMA available behind |
| | | a compile flag. |
+------------------------+------------------+------------------------+
| Delayed ACK with rate | TCP | RFC 813 (Clark, 1982); |
| suppression | | RFC 1122 sec. 4.2.3.2; |
| | | RFC 5681 sec. 4.2. |
| | | Single-deadline |
| | | coalescing rather than |
| | | "ack-every-other- |
| | | segment". |
+------------------------+------------------+------------------------+
| Zero-window-probe / | TCP | RFC 1122 sec. |
| persist-timer | | 4.2.2.17 / RFC 9293 |
| analogue (RDVS) | | sec. 3.8.6.1. RDVS |
| | | solicits an FC reply, |
| | | distinct from QUIC |
| | | DATA_BLOCKED (RFC 9000 |
| | | sec. 19.12), which is |
| | | one-way notification. |
| | | MAX_RDV give-up |
| | | departs from TCP. |
+------------------------+------------------+------------------------+
| Multiplexed control | SCTP / QUIC | SCTP chunk bundling |
| on a single PCI | | (RFC 9260 sec. 6.10); |
| | | QUIC frame |
| | | multiplexing (RFC 9000 |
| | | sec. 12.4). Cleaner |
| | | fit than TCP's |
| | | separate-flag-bits |
| | | design. |
+------------------------+------------------+------------------------+
| ACK ranges as | QUIC | QUIC ACK frame (RFC |
| multiple discontiguous | | 9000 sec. 19.3). FRCP |
| acked blocks | | SACK is conceptually |
| | | QUIC-frame-shaped |
| | | even though encoded |
| | | as absolute |
| | | [start,end] pairs. |
+------------------------+------------------+------------------------+
| Nonce-authenticated | QUIC | PATH_CHALLENGE / |
| active RTT / liveness | PATH_CHALLENGE | PATH_RESPONSE (RFC |
| probing (RTTP) | | 9000 sec. 8.2, |
| | | sec. 19.17, sec. |
| | | 19.18). WebRTC ICE |
| | | consent-freshness |
| | | (RFC 7675) is the |
| | | same pattern. QUIC's |
| | | nonce is 8 octets; |
| | | FRCP chooses 16. |
+------------------------+------------------+------------------------+
| Probing distinct from | QUIC | KA timer answers |
| keepalive | | "peer alive?", RTTP |
| | | answers "path |
| | | measurable?", as in |
| | | QUIC PING (RFC 9000 |
| | | sec. 19.2) vs |
| | | PATH_CHALLENGE. |
+------------------------+------------------+------------------------+
| Bare KA + ACK | QUIC / SCTP | QUIC PING (RFC 9000 |
| keepalive packets | | sec. 19.2); SCTP |
| | | HEARTBEAT / |
| | | HEARTBEAT-ACK (RFC |
| | | 9260 sec. 8.3). SCTP |
| | | HEARTBEAT also carries |
| | | an opaque echoed blob, |
| | | structurally similar |
| | | to FRCP RTTP. |
+------------------------+------------------+------------------------+
| (FFGM, LFGM) | SCTP | RFC 9260 sec. 3.3.1 |
| fragment-role bits | | DATA chunk B/E bits |
| (Section 7.2) | | encode the same four |
| | | states (B+E=SOLE, |
| | | B-only=FIRST, neither |
| | | =MID, E-only=LAST). |
| | | Each fragment carries |
| | | its own seqno/TSN and |
| | | is independently |
| | | retransmitted. |
+------------------------+------------------+------------------------+
| Stream byte-offset | QUIC | QUIC STREAM frame |
| reassembly | | (RFC 9000 sec. 19.8) |
| (Sections 1.5, 16) | | uses Offset + Length |
| | | varints; FRCP uses |
| | | fixed 32-bit start / |
| | | end. One stream per |
| | | flow vs QUIC's many |
| | | streams multiplexed. |
+------------------------+------------------+------------------------+
| FIN end-of-stream | TCP / QUIC | TCP FIN flag (RFC 9293 |
| marker | | sec. 3.1) closes one |
| (Sections 1.2, 16) | | half of the byte |
| | | stream; QUIC STREAM |
| | | frame FIN bit (RFC |
| | | 9000 sec. 19.8) does |
| | | the same per stream |
| | | with an immutable |
| | | final-size invariance |
| | | (RFC 9000 sec. 4.5: |
| | | the final size is |
| | | fixed once observed). |
| | | FRCP's FIN consumes |
| | | one packet seqno (not |
| | | one byte of stream |
| | | space) and is |
| | | idempotent on the |
| | | sender side. |
+------------------------+------------------+------------------------+
| Stream byte-credit | QUIC | MAX_STREAM_DATA (RFC |
| flow control | | 9000 sec. 4.1, sec. |
| (Section 16) | | 19.10). FRCP projects |
| | | a per-flow byte budget |
| | | onto the seqno-space |
| | | rwe. Single stream |
| | | per flow collapses |
| | | QUIC's MAX_DATA / |
| | | MAX_STREAM_ |
| | | DATA distinction. |
+------------------------+------------------+------------------------+
| Header protection | QUIC | QUIC RFC 9001 sec. 5.4 |
| (encrypted seqnos) | | applies header |
| | | protection on top of |
| | | AEAD to mask the |
| | | packet number. FRCP's |
| | | per-flow AEAD wrap |
| | | (Section 16) is wider: |
| | | it encrypts the entire |
| | | PCI including seqno |
| | | because the IPCP |
| | | below already routes, |
| | | so no destination |
| | | connection-ID needs to |
| | | stay in clear (cf. |
| | | RFC 9000 sec. 5.2). |
+------------------------+------------------+------------------------+
| Two-bit fragment role | SCTP | The (FFGM, LFGM) pair |
| polarity | | follows SCTP B/E |
| | | (begin = 1 / end = 1) |
| | | rather than IPv4 MF |
| | | (RFC 791 sec. 3.2), |
| | | which has the inverse |
| | | polarity (MF = 1 means |
| | | NOT last). |
+------------------------+------------------+------------------------+
| Orthogonal reliability | SCTP | PR-SCTP (RFC 3758, |
| / ordering axes | | per-message partial |
| (Section 2.2) | | reliability) and SCTP |
| | | DATA U-bit (RFC 9260 |
| | | sec. 3.3.1, per- |
| | | message unordered) |
| | | are the closest |
| | | precedents for |
| | | decoupling reliability |
| | | from ordering; FRCP |
| | | sets them per-flow |
| | | rather than per- |
| | | message. |
+------------------------+------------------+------------------------+
| Orthogonal CRC | UDP-Lite | RFC 3828 (Larzon et |
| (qs.ber == 0) | | al., 2004) lets the |
| | | sender pick a per- |
| | | packet Checksum |
| | | Coverage and the |
| | | receiver enforce a |
| | | locally configured |
| | | minimum (no in-band |
| | | negotiation; sec. 3.1, |
| | | sec. 3.3). FRCP |
| | | gates a full CRC |
| | | trailer on qs.ber == 0 |
| | | at flow setup. |
| | | Contrast TCP / SCTP |
| | | (mandatory checksum) |
| | | and QUIC (AEAD |
| | | subsumes CRC). |
+------------------------+------------------+------------------------+
| Setup-time service | DCCP / SCTP / | DCCP Service Codes |
| negotiation | QUIC | (RFC 4340 sec. 8.1.2, |
| | | RFC 5595); SCTP INIT |
| | | parameters (RFC 9260 |
| | | sec. 3.3.2); QUIC |
| | | transport parameters |
| | | (RFC 9000 sec. 7.4). |
| | | All negotiate service |
| | | properties at |
| | | connection setup; only |
| | | RINA's QoS cube |
| | | exposes them as an |
| | | orthogonal vector. |
+------------------------+------------------+------------------------+
</pre>

=== 15.1. Original to FRCP (no clean prior art) ===

<pre>
- Pre-DRF NACK (Section 9): receiver-driven nudge exploiting
snd_cr.inact > rcv_cr.inact. Closest analogues are SCTP Gap Ack
Blocks (RFC 9260 sec. 3.3.4) and DCCP Ack Vector (RFC 4340
sec. 11.4) - both let the receiver describe gaps to the sender,
but neither targets the cross-epoch / pre-DRF case.
- MAX_RDV window-probe give-up: neither TCP (persist-timer
probes until application or R2 abort, RFC 9293 sec. 3.8.6.1)
nor QUIC has an explicit FC-give-up counter. A recursive-
network choice: outer layers can drop the flow.
- Skip-past-gap reassembly (Section 7.2): SCTP fragments and
reassembles every flow regardless of reliability/ordering,
using its own per-stream reassembly queue; QUIC fragments via
STREAM offsets. FRCP fragments best-effort flows too, but
the receiver drops the broken prefix the moment a later run-
start (FIRST or SOLE role) is visible inside the RQ_SIZE-wide
reorder ring - no IP-frag-style timeout, no SCTP-style
explicit abort. If no later run-start arrives within the
ring, frag_run_inspect returns NOT_READY and the partial run
keeps its slots; the next inspect retries. The trade-off: a
permanently-lost MID in a long isolated run holds slots until
either a later FIRST/SOLE appears in the ring or the writer
stops, at which point the slots are reclaimed on flow
teardown.
- Reassembly deferred to consume time (Section 7.2), message
mode only (qos.service == SVC_MESSAGE): SCTP (RFC 9260
sec. 6.9), QUIC (RFC 9000 sec. 2.2), and TCP (RFC 9293) all
hold reassembly state at the receive boundary. FRCP message-
mode leaves fragments in the shared-memory ring until
flow_read pulls and lands the SDU directly in the caller's
buffer. Stream mode (Section 16) uses the standard QUIC-
style direct ring placement on receive and does not defer.
The optimisation is enabled by the Shared-Memory Subsystem
(SSM) packet-buffer ring (see struct ssm_pk_buff at
Section 1.1); the analogue is OS-level scatter-gather I/O
(recvmsg+iovec), not a transport-layer prior art.
- TLP-equivalent tail-loss recovery (RFC 8985 sec. 7;
RFC 9002 sec. 6.2): FRCP does not emit an explicit Tail Loss
Probe packet, but the same goal is met implicitly by RACK
loss detection (Section 8) firing on a non-advancing
cumulative ACK once the head-of-line slot ages past the RACK
reorder window R = MIN(reo_wnd_mult * min_RTT / 4, SRTT) -
well below RTO = max(2 * SRTT, SRTT + (mdev << MDEV_MUL)).
A receiver-driven nudge is also available via the pre-DRF
NACK (Section 9).
</pre>

=== 15.2. Not adopted ===

<pre>
- Slow start, congestion window (cwnd), Additive Increase /
Multiplicative Decrease (AIMD), NewReno cwnd inflation.
Congestion control lives in the IPCP CA policies and is
driven by Explicit Congestion Notification (ECN, RFC 3168).
- Nagle / silly-window-syndrome (SWS) avoidance (RFC 896, RFC
1122 sec. 4.2.3.4). (Deferred work, not adopted in the
current spec.)
- TCP Timestamps (RFC 7323) / Protection Against Wrapped
Sequences (PAWS) - RTT measurement uses RTTP,
not per-segment timestamps. A peer-supplied timestamp echoed
on every ACK lets a malicious peer drive the srtt estimate
arbitrarily low, collapsing the RTO and triggering a self-
inflicted retransmit storm. RTTP confines RTT measurement to
nonce-authenticated probe round-trips, where a forged echo is
rejected before it can reach the estimator.
- ECN (Explicit Congestion Notification) response inside FRCP
(consumed by IPCP Congestion Avoidance / CA).
- IP-style fragment-offset reassembly (RFC 791 sec. 3.2; RFC 8200
sec. 4.5). Message-mode FRCP relies on the FRCT rq[] reorder
ring keyed by seqno (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 [start, end) byte offsets
(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 (FFGM/LFGM) and skips the offsets; stream-mode
FRCP adopts the QUIC offset model (heritage table above).
</pre>

== 16. Stream-mode flows ==

When a flow is allocated with qos.service == SVC_STREAM both peers
switch to byte-stream semantics, layered on top of the FRTX reorder
machinery already described in Sections 6-8.

=== 16.1. Send ===

The sender splits the caller's octets into chunks of at most
(frag_mtu - base PCI - stream PCI extension) octets (Sections 1.1
and 1.5). Each chunk is one DATA packet with its own seqno and a
[start, end) byte range copied from a monotonic stream counter.
In stream mode FFGM and LFGM are unused and MUST be transmitted as
zero; the per-byte position is carried by the [start, end)
extension instead.

End-of-stream is signalled with a 0-byte DATA packet that has FIN
(bit 12) set, emitted on the FIN triggers listed in Section 1.2
(WR-half close, flow_dealloc, and any other path that yields the
final byte). The sender MUST emit at most one FIN per flow; its
[start, end) MUST equal [final-byte, final-byte) (i.e., empty
interval at the final byte position; final-size invariance,
analogous to QUIC RFC 9000 sec. 4.5). Idempotency is enforced by
an snd_fin_sent guard.

=== 16.2. Receive ===

On arrival the receiver places the payload directly into a per-flow
byte-indexed receive ring of width ring_sz (octets) at the position
indicated by start, with a two-segment memcpy across the ring
boundary if needed. Receipt is recorded in the FRTX reorder
machinery (Section 6.2) augmented with the packet's start, end, and
FIN bit per slot. When a packet's [start, end) front-overlaps
bytes already at or below the byte high-water mark, the overlap is
trimmed before placement so the same byte is never written twice.
After stashing, the receiver advances lwe and the byte high-water
mark across any newly-contiguous prefix. Each slot advanced MUST
satisfy `start == the last-delivered slot's end`; a slot whose
start does not equal that end is silently dropped at delivery time
(the seqno is consumed, no stream bytes contributed) and the high-
water mark does not advance past it. The stream byte-stream
stalls at that point - there is no flow-tear-down on mismatch.
This filters spliced or off-path-injected slots that fall in
window without strong cryptographic authentication.

A FIN slot marks end-of-stream at advance time only if its byte
position equals the last-delivered slot's end; otherwise the FIN
is ignored and the corresponding seqno occupies a slot but
contributes no stream bytes. No packet buffer is held after the
ring copy.

=== 16.3. Read ===

flow_read returns up to count octets from the contiguous prefix
[next, high-water), where next is the byte the application has
already consumed up to and high-water is the rightmost contiguous
byte received. When the stream is fully drained AND end-of-stream
(EOS) was observed (next == EOS byte position), flow_read returns
0 (EOF) - the same shape POSIX read(2) uses on TCP after a peer
FIN.

=== 16.4. Flow control ===

ACK / SACK / RACK / RTO machinery is unchanged; the FRTX reorder
ring is reused as a per-seqno received-bitmap. Let per_pkt =
(frag_mtu - base PCI - stream PCI extension), the maximum stream-
byte payload one DATA packet can carry (Section 16.1). The
receive window advertised in FC is clamped so the byte window
(ring_sz) cannot be overrun: the seqno-space rwe is at most
`rcv_cr.lwe + ring_sz / per_pkt`.

This is the QUIC byte-credit flow-control model
(MAX_STREAM_DATA, RFC 9000 sec. 4.1 and sec. 19.10) projected onto
seqno space. With one stream per flow there is no MAX_DATA /
MAX_STREAM_DATA distinction. Receiver-side silly-window-syndrome
(SWS) avoidance (RFC 9293 sec. 3.8.6.2.2) is achieved by combining
the consume-time rwe bump with the global non-shrink rule from
Section 11.

=== 16.5. Security considerations ===

Threat model. An attacker that can observe (on-path passive) or
predict (off-path blind) the flow's seqnos and byte offsets on an
unencrypted stream flow can inject DATA or FIN at any in-window
position. The in-line consistency checks above (start == prior
end on advance; FIN MUST be 0-byte; FIN MUST sit at the final
byte position) realise the spirit of RFC 5961's "sequence-window
plus exact-position match for control bits" without an explicit
challenge-ACK probe; they make a few specific blind attack shapes
harder but are not cryptographic authentication. This is
comparable to TCP without the TCP Authentication Option (TCP-AO,
RFC 5925), tighter than a
pre-RFC-5961 TCP stack, and roughly equivalent to a modern
RFC 5961 stack against blind off-path injection - none of these
help once the attacker can sniff. TLS over TCP (RFC 8446)
encrypts only the TCP payload and leaves TCP seqnos, ACKs, FIN,
and RST in the clear, so TLS does NOT defend against TCP-header-
level injection; QUIC (RFC 9000) hides packet numbers under
header protection (RFC 9001 sec. 5.4), so this specific weakness
does not apply to QUIC.

Mitigation: AEAD. When the flow has encryption enabled the
recommended AEAD ciphers (AES-GCM, RFC 5288; or ChaCha20-Poly1305,
RFC 8439) wrap the entire FRCP packet on the wire - PCI, stream
extension, body, and the CRC trailer when ber == 0 - under a
per-flow symmetric key derived from the flow's own key exchange
(Section 1.1). The AEAD tag (~2^-128 forgery probability)
dominates the CRC (~2^-32) for integrity in this mode but the CRC
trailer is currently retained inside the wrap (see Section 1.1).
Implementations MUST NOT rely on the security properties below
when a non-AEAD cipher (e.g. AES-CTR alone) is negotiated; non-
AEAD modes provide confidentiality only and the threat-model
claims do not hold.

With an AEAD cipher in use, seqnos, byte offsets, and the FIN bit
are both authenticated and confidential. Against an off-path or
on-path-passive attacker this is:

<pre>
- Stronger than TCP+TLS (TCP header in the clear).
- Stronger than TCP+TCP-AO (header authenticated but visible).
- 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.
</pre>

Keying granularity. FRCP runs key exchange (kex) per flow, so
each flow_alloc 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 kex 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
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
seqno-space duplicate-suppression in Section 6.2 rejects replayed
DATA after the AEAD strips the wrap, because the AEAD authenticates
the seqno and a replay re-presents an old seqno that is then
discarded either as a duplicate (still inside the receive window)
or as outside the receive window, depending on how far lwe has
advanced since the original packet was delivered. RAW
(qos.service == SVC_RAW) flows have no FRCP layer and therefore
no replay protection at the AEAD layer either; deployments that
need replay rejection on RAW flows MUST provide it at a higher
layer.

Layering. The AEAD wrap sits below FRCP on the data path, so
RAW best-effort flows (qos.service == SVC_RAW, the UDP-equivalent
service of 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.

== 17. References ==

This section lists the IETF documents, published works, and
source-code references cited inline elsewhere in this document.
IETF documents are cited inline as "RFC NNNN sec. X.Y"; books,
journal papers, and source-code references are cited inline by
author and year (or by file and function name) and are listed
here for convenience.

=== 17.1. IETF documents ===

<pre>
[RFC 791] J. Postel, "Internet Protocol", STD 5, RFC 791,
September 1981.
</pre>

<pre>
[RFC 793] J. Postel, "Transmission Control Protocol", STD 7,
RFC 793, September 1981. Obsoleted by RFC 9293.
</pre>

<pre>
[RFC 813] D. D. Clark, "Window and Acknowledgement Strategy
in TCP", RFC 813, July 1982.
</pre>

<pre>
[RFC 896] J. Nagle, "Congestion Control in IP/TCP
Internetworks", RFC 896, January 1984.
</pre>

<pre>
[RFC 1122] R. Braden (ed.), "Requirements for Internet Hosts
-- Communication Layers", STD 3, RFC 1122,
October 1989.
</pre>

<pre>
[RFC 2018] M. Mathis, J. Mahdavi, S. Floyd, A. Romanow,
"TCP Selective Acknowledgment Options", RFC 2018,
October 1996.
</pre>

<pre>
[RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
</pre>

<pre>
[RFC 2883] S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky,
"An Extension to the Selective Acknowledgement
(SACK) Option for TCP", RFC 2883, July 2000.
</pre>

<pre>
[RFC 3758] R. Stewart, M. Ramalho, Q. Xie, M. Tuexen,
P. Conrad, "Stream Control Transmission Protocol
(SCTP) Partial Reliability Extension", RFC 3758,
May 2004.
</pre>

<pre>
[RFC 3828] L-A. Larzon, M. Degermark, S. Pink, L-E. Jonsson
(ed.), G. Fairhurst (ed.), "The Lightweight User
Datagram Protocol (UDP-Lite)", RFC 3828,
July 2004.
</pre>

<pre>
[RFC 4303] S. Kent, "IP Encapsulating Security Payload
(ESP)", RFC 4303, December 2005.
</pre>

<pre>
[RFC 4340] E. Kohler, M. Handley, S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340,
March 2006.
</pre>

<pre>
[RFC 5288] J. Salowey, A. Choudhury, D. McGrew, "AES Galois
Counter Mode (GCM) Cipher Suites for TLS",
RFC 5288, August 2008.
</pre>

<pre>
[RFC 5595] G. Fairhurst, "The Datagram Congestion Control
Protocol (DCCP) Service Codes", RFC 5595,
September 2009.
</pre>

<pre>
[RFC 5681] M. Allman, V. Paxson, E. Blanton, "TCP Congestion
Control", RFC 5681, September 2009.
</pre>

<pre>
[RFC 5925] J. Touch, A. Mankin, R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010.
</pre>

<pre>
[RFC 5961] A. Ramaiah, R. Stewart, M. Dalal, "Improving
TCP's Robustness to Blind In-Window Attacks",
RFC 5961, August 2010.
</pre>

<pre>
[RFC 6298] V. Paxson, M. Allman, J. Chu, M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298,
June 2011.
</pre>

<pre>
[RFC 6528] F. Gont, S. Bellovin, "Defending against Sequence
Number Attacks", RFC 6528, February 2012.
Obsoletes RFC 1948.
</pre>

<pre>
[RFC 6582] T. Henderson, S. Floyd, A. Gurtov, Y. Nishida,
"The NewReno Modification to TCP's Fast Recovery
Algorithm", RFC 6582, April 2012.
</pre>

<pre>
[RFC 7323] D. Borman, B. Braden, V. Jacobson,
R. Scheffenegger (ed.), "TCP Extensions for High
Performance", RFC 7323, September 2014.
</pre>

<pre>
[RFC 7675] M. Perumal, D. Wing, R. Ravindranath, T. Reddy,
M. Thomson, "Session Traversal Utilities for NAT
(STUN) Usage for Consent Freshness", RFC 7675,
October 2015.
</pre>

<pre>
[RFC 8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in
RFC 2119 Key Words", BCP 14, RFC 8174, May 2017.
</pre>

<pre>
[RFC 8200] S. Deering, R. Hinden, "Internet Protocol,
Version 6 (IPv6) Specification", STD 86, RFC 8200,
July 2017.
</pre>

<pre>
[RFC 8439] Y. Nir, A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 8439, June 2018.
</pre>

<pre>
[RFC 8446] E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.3", RFC 8446, August 2018.
</pre>

<pre>
[RFC 8985] Y. Cheng, N. Cardwell, N. Dukkipati, P. Jha,
"The RACK-TLP Loss Detection Algorithm for TCP",
RFC 8985, February 2021.
</pre>

<pre>
[RFC 9000] J. Iyengar (ed.), M. Thomson (ed.), "QUIC: A
UDP-Based Multiplexed and Secure Transport",
RFC 9000, May 2021.
</pre>

<pre>
[RFC 9001] M. Thomson (ed.), S. Turner (ed.), "Using TLS to
Secure QUIC", RFC 9001, May 2021.
</pre>

<pre>
[RFC 9002] J. Iyengar (ed.), I. Swett (ed.), "QUIC Loss
Detection and Congestion Control", RFC 9002,
May 2021.
</pre>

<pre>
[RFC 9147] E. Rescorla, H. Tschofenig, N. Modadugu,
"The Datagram Transport Layer Security (DTLS)
Protocol Version 1.3", RFC 9147, April 2022.
</pre>

<pre>
[RFC 9260] R. Stewart, M. Tuexen, K. Nielsen, "Stream Control
Transmission Protocol", RFC 9260, June 2022.
Obsoletes RFC 4960.
</pre>

<pre>
[RFC 9293] W. Eddy (ed.), "Transmission Control Protocol
(TCP)", STD 7, RFC 9293, August 2022. Obsoletes
RFC 793 and several follow-ons; updates RFC 1122
and others.
</pre>

=== 17.2. Books and journal papers ===

<pre>
- J. Day, "Patterns in Network Architecture: A Return to
Fundamentals", Prentice Hall, 2008.
</pre>

<pre>
- E. Grasa et al., "IRATI: investigating RINA as an alternative
to TCP/IP", Computer Networks, Vol. 92, December 2015.
</pre>

<pre>
- P. Karn, C. Partridge, "Improving Round-Trip Time Estimates
in Reliable Transport Protocols", ACM SIGCOMM, August 1987.
</pre>

<pre>
- R. W. Watson, "Timer-Based Mechanisms in Reliable Transport
Protocol Connection Management", Computer Networks, Vol. 5,
1981.
</pre>

=== 17.3. Source-code references ===

<pre>
- tcp_rtt_estimator() in net/ipv4/tcp_input.c of the Linux
kernel, defining the asymmetric mdev variance update used as
FRCP's default RTT estimator (Section 12). Line-stable
browseable copy at
https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_input.c.
</pre>

Flow and Retransmission Control Protocol

2026-05-17T13:51:01Z

Dimitri: /* Table of Contents */

Flow and Retransmission Control Protocol

2026-05-17T13:50:31Z

Dimitri:

= FRCP - Flow and Retransmission Control Protocol =

FRCP runs end-to-end between two peers over a flow. It delivers
reliability, in-order delivery, flow control, and liveness.
Congestion Control (CC) is not in FRCP - that lives in the IPC
Process (IPCP) Congestion Avoidance (CA) policies, orthogonal to
FRCP. Flow allocation, naming, and IPCP lifecycle are handled by
the IPC Resource Manager daemon (IRMd).

FRCT (Flow and Retransmission Control Task) is the libouroboros
implementation of FRCP; the task lives in src/lib/frct.c. The
remainder of this document describes the FRCP wire protocol and the
behaviour FRCT realises. Code symbols retain the FRCT_ prefix
(FRCT_DATA, FRCT_RXM, ...) because they belong to the implementing
task; this document references them verbatim.

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in BCP 14 (Best
Current Practice; RFC 2119, RFC 8174) when, and only when, they
appear in all capitals.

== Notation ==

<pre>
u32, u8 Unsigned 32-bit / 8-bit integers (kernel-C style).
ns Nanoseconds.
</pre>

Modular sequence-number comparators (32-bit, modulo 2^32):

<pre>
before(a, b) == (int32_t)(a - b) < 0
after(a, b) == before(b, a)
</pre>

Used throughout for ackno / seqno ordering checks.

Round-Trip Time (RTT) abbreviations used throughout:

<pre>
SRTT Smoothed RTT estimate (RFC 6298).
mdev Mean deviation of RTT (Linux variance estimator).
EWMA Exponentially Weighted Moving Average.
RTO Retransmission Timeout, max(RTO_MIN,
srtt + (mdev << MDEV_MUL)).
</pre>

Timer-bound symbols t_a (a-timer, ACK delay) and t_r (r-timer,
retransmission window) are defined in Section 8; t_mpl (Maximum
Packet Lifetime) is introduced in Section 2.1 (the inact field)
with heritage in Section 15.

Wire-format diagrams follow the IETF convention: bit 0 is the
leftmost (most significant) bit and fields are in network byte
order unless stated otherwise.

=== Table of Contents ===

<pre>
1. Wire format
1.1. PCI header
1.2. Flag bits
1.3. SACK payload
1.4. RTTP payload
1.5. Stream PCI extension
2. Per-flow state and service modes
2.1. Per-flow state
2.2. Service modes (orthogonal axes)
3. Protocol parameters
4. Sequence-number rotation (DRF)
5. Send path
6. Receive path
6.1. Early-exit dispatch
6.2. Locked main path
7. Read path and reassembly
7.1. Read path
7.2. Fragmentation and reassembly
8. Retransmission
9. Pre-DRF NACK
10. Cumulative + selective ACK
11. Flow control
12. RTT estimation
13. Liveness (keepalive)
14. Linger / teardown
15. Heritage and adopted techniques
15.1. Original to FRCP (no clean prior art)
15.2. Not adopted
16. Stream-mode flows
16.1. Send
16.2. Receive
16.3. Read
16.4. Flow control
16.5. Security considerations
17. References
17.1. IETF documents
17.2. Books and journal papers
17.3. Source-code references
</pre>

== 1. Wire format ==

=== 1.1. PCI header ===

Fixed 16-octet base Protocol-Control Information (PCI) header
prefixed to every FRCP packet (RFC convention: bit 0 leftmost,
most-significant bit first). All multi-byte fields except hcs
are in network byte order; hcs is an opaque 16-bit value that
the receiver recomputes from the wire bytes and compares to the
in-place pci->hcs 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
Section 1.5); SACK and RTTP carry their own payloads after the
base PCI.

<pre>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | hcs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ackno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload (variable) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>

<pre>
flags - feature/type bitmap (see 1.2).
hcs - CRC-16-CCITT-FALSE Header Check Sequence (HCS) over
flags + window + seqno + ackno (+ stream extension when
present); the two octets of the hcs field itself are
omitted from the CRC input. Verified on receive before
any flag-driven dispatch.
window - receiver-advertised right window edge (valid iff FC).
seqno - per-flow sequence number.
ackno - cumulative Acknowledgement (ACK) (valid iff ACK).
</pre>

A single packet can simultaneously carry DATA + ACK + FC (Flow
Control) + RXM (Retransmission) by ORing flag bits; the PCI
multiplexes control on the same wire frame in the spirit of SCTP
chunk bundling (RFC 9260 sec. 6.10) and QUIC frame multiplexing
(RFC 9000 sec. 12.4). DATA-bearing packets carry the caller's
payload after the PCI; SACK (Selective Acknowledgement) and RTTP
(Round-Trip Time Probe) carry their own typed payloads after the
PCI.

Optional framing (per-flow, see Section 2.2). On the wire, the
order from inside out is:

<pre>
[ PCI + body ] -- the FRCP packet
[ PCI + body + CRC-32 ] -- CRC-32 covers the body only (PCI
is in HCS); appended iff qs.ber
== 0 on DATA, or on every SACK
packet
[ AEAD-wrap of above ] -- iff Authenticated Encryption
with Associated Data (AEAD) is
enabled
</pre>

<pre>
- 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
0xEDB88320, init 0xFFFFFFFF, xor-out 0xFFFFFFFF) covers the
body on DATA when qs.ber == 0 and on every SACK packet; the
trailer is written as a raw uint32_t (the same convention as
hcs: 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.
- When encryption is enabled, the entire (possibly-CRC'd) FRCP
packet is wrapped with AEAD inside the shared-memory packet
buffer (spb, struct ssm_pk_buff); the packet grows by the AEAD
overhead, namely a leading nonce / Initialization Vector (IV)
of headsz bytes (crypt_get_ivsz) and a trailing authentication
tag of tailsz bytes (crypt_get_tagsz).
</pre>

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

=== 1.2. Flag bits ===

Flag bits are numbered most-significant-bit first to match the wire
diagram (bit numbering per Section 1.1; bit 0 is the MSB of the
16-bit flags field and lands at wire-position 0 in network byte
order). Bits 13..15 are reserved and MUST be transmitted as zero.

<pre>
+------+--------+--------+----------------------------------------+
| Bit | Mask | Name | Meaning |
+------+--------+--------+----------------------------------------+
| 0 | 0x8000 | DATA | Carries caller payload |
| 1 | 0x4000 | DRF | Data Run Flag: start of a fresh run |
| 2 | 0x2000 | ACK | Acknowledgement: ackno field valid |
| 3 | 0x1000 | NACK | Negative ACK; seqno = arrival_seqno-1 |
| 4 | 0x0800 | FC | Flow Control: window field valid (rwe) |
| 5 | 0x0400 | RDVS | Rendezvous probe (window-closed) |
| 6 | 0x0200 | FFGM | First Fragment (role bit 0; see below) |
| 7 | 0x0100 | LFGM | Last Fragment (role bit 1; see below) |
| 8 | 0x0080 | RXM | Retransmission |
| 9 | 0x0040 | SACK | Selective ACK block list in payload |
| 10 | 0x0020 | RTTP | RTT Probe / echo (payload follows) |
| 11 | 0x0010 | KA | Keepalive |
| 12 | 0x0008 | FIN | End-of-stream marker (stream mode) |
| 13-15| -- | -- | Reserved (MUST be zero) |
+------+--------+--------+----------------------------------------+
</pre>

The (FFGM, LFGM) pair encodes the fragment role of a DATA-bearing
Service Data Unit (SDU), SCTP-style begin/end flags (RFC 9260
sec. 3.3.1):

<pre>
+-----------+-------------------------------------------------+
| FFGM LFGM | Role |
+-----------+-------------------------------------------------+
| 1 1 | Sole / un-fragmented SDU (begin AND end) |
| 1 0 | First fragment of a multi-fragment SDU |
| 0 0 | Middle fragment |
| 0 1 | Last fragment |
+-----------+-------------------------------------------------+
</pre>

Each fragment is carried in its own FRCP packet with its own seqno;
FRTX (the FRCT Retransmission service mode, see Section 2.2)
recovers individual fragments via the normal Retransmission Timeout
(RTO) / SACK / Recent Acknowledgement (RACK, RFC 8985) path. The
receiver reassembles the SDU at consume time once the contiguous
[FIRST .. LAST] run has fully arrived. On non-DATA packets the role
bits are unused and MUST be transmitted as zero.

In stream mode (qos.service == SVC_STREAM, see Section 16) there are
no SDU boundaries to encode, so FFGM and LFGM are unused and MUST
be transmitted as zero. End-of-stream uses a dedicated bit (FIN,
bit 12) carried on a 0-byte DATA packet, emitted at write-half close
(fccntl to FLOWFRDONLY), during linger drain, and at flow_dealloc;
emission is idempotent (first call wins). After contiguous delivery
of the FIN-bearing slot, the receiver latches byte_fin at the FIN's
start offset; flow_read returns 0 (end-of-file, EOF) once buffered
bytes have been drained up to byte_fin. Per-byte position is
carried by the [start, end) extension (Section 1.5).

=== 1.3. SACK payload ===

A SACK packet has the FRCT_ACK | FRCT_FC | FRCT_SACK flag bits set
(bit numbering per Section 1.1). Following the 16-octet PCI, the
payload is a 2-octet block count (network byte order), 2 octets of
padding to 4-byte align the block list, then n_blocks pairs of
32-bit start/end seqnos describing *present* (received) ranges
above the cumulative ACK.

<pre>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_blocks | padding (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start[0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end[0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... n_blocks pairs total ...
</pre>

n_blocks <= SACK_MAX_BLOCKS (2048). The per-flow effective cap is
further bounded by (frag_mtu - PCI - 4) / 8 blocks per packet; SACK
packets carry no stream extension, so PCI here is the 16-octet base
header even on stream-mode flows.

Wire invariant: every block produced by the receiver, except an
optional leading Duplicate SACK (D-SACK) block as described below,
describes a range strictly above the cumulative ACK carried in the
PCI ackno field (after(start[i], ackno)). This makes the D-SACK
convention below unambiguous; the receiver-side builder MUST
preserve it.

Duplicate SACK (D-SACK, RFC 2883) is signalled in-band: no flag
bit, no extra framing. Modular seqno arithmetic uses the
before() / after() comparators defined in the Notation block.
Block[0] carries a D-SACK report when either:

<pre>
case 1 (RFC 2883 sec. 4.1.1, full duplicate):
before(blocks[0].start, ackno) and ackno - blocks[0].start is
within MAX_DSACK_LAG (== RQ_SIZE). A single duplicate seqno
observed below the cumulative ACK.
</pre>

<pre>
case 2 (RFC 2883 sec. 4.1.2, partial duplicate):
blocks[0] is a sub-range of some blocks[i>0] (not exactly
equal). Reports a duplicate of an in-window seqno that the
same packet's remaining SACK blocks already describe as
received.
</pre>

Senders that do not implement D-SACK process block[0] through the
normal SACK-mark loop and the existing clamp-and-skip path makes
case-1 a no-op (start < snd_cr.lwe clamps to snd_cr.lwe, the inner
loop then skips k == snd_cr.lwe) and case-2 idempotent (same slots
NULL'd twice). D-SACK-aware senders feed the report into the RACK
reo_wnd_mult scaler (RFC 8985 sec. 6.2 step 4): bump on receipt
(cap 20), halve once per 16 cumulatively-ACK'd seqnos since the
most recent D-SACK arrival or halve event, reset to 1 on an RTO
timer fire at the head-of-line. D-SACK alone never enters
NewReno-careful recovery (see Section 8); only non-D-SACK blocks
count as gaps.

=== 1.4. RTTP payload ===

An RTTP (Round-Trip Time Probe) packet has only the FRCT_RTTP flag
set (bit numbering per Section 1.1). Following the 16-octet PCI,
the payload is 24 octets (packed):

<pre>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| probe_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| echo_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ nonce (16 octets, echoed verbatim) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>

<pre>
probe_id - sender counter, 0 on reply, 0 reserved.
echo_id - peer's probe_id, 0 on outbound probe.
nonce - random, echoed unmodified, memcmp'd to defeat spoof.
</pre>

=== 1.5. Stream PCI extension ===

A stream-mode flow (qos.service == SVC_STREAM) carries an extra
8-octet extension after the 16-octet base PCI on every DATA packet
(bit numbering per Section 1.1):

<pre>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>

<pre>
start - octet offset of the first payload byte in the stream.
end - octet offset one past the last payload byte;
end - start equals the on-wire payload length.
</pre>

Total stream-mode PCI for DATA packets is 24 octets (16 base + 8
extension); control packets (SACK, RTTP, bare ACK, KA, etc.) retain
the 16-octet base PCI. Stream mode MUST be negotiated at flow
allocation; the extension is present iff stream mode is in use,
never on a per-packet basis. Both peers MUST treat start/end as
monotonic 32-bit byte offsets; when a slot reaches the head of the
contiguous run with start not equal to the prior packet's end the
slot is silently dropped at delivery time (Section 16) rather
than rejected at stash.

This is the QUIC STREAM-frame reassembly model (RFC 9000 sec. 19.8):
each packet carries its packet seqno (this PCI's seqno field) and a
separate stream byte position (start/end). Separating the two
avoids TCP's conflation of packet identity with byte position which
forces Karn's algorithm for Round-Trip Time (RTT) sampling (no RTT
sample on retransmits, RFC 6298 sec. 3); FRCP applies the
Karn-equivalent gate via a combination of per-packet FRCT_RXM,
per-slot SND_RTX flags, and a sample-fence rtt_lwe (see Section 2.1
and Section 12). FRCP's fixed-32-bit start/end wrap at 4 GiB of
wire bytes, narrower than QUIC's 62-bit varint offset (cf. RFC 9000
sec. 16); the on-wire wrap is handled by the same modular before()
/ after() comparators (Section 1.3) FRCP uses for seqnos, which
remain unambiguous as long as the in-flight byte window stays
strictly under 2 GiB (the half-range of the signed-int32 difference
in before()). The default per-flow ring is 1 MiB; the
implementation caps ring_sz at 128 MiB (FRCT_STREAM_RING_SZ_MAX),
well below the 2 GiB half-range bound. The runtime byte counters
exposed via FUSE (Filesystem in Userspace) in the Ouroboros
Resource Information Base (RIB, a virtual-filesystem introspection
bridge) are platform size_t and do not wrap on 64-bit hosts.

== 2. Per-flow state and service modes ==

=== 2.1. Per-flow state ===

Each flow keeps a sender control record and a receiver control
record:

<pre>
lwe : u32 snd: oldest unacked seqno (cumulative ACK
boundary as seen by sender);
rcv: next in-order seqno expected
rwe : u32 snd: peer-advertised right window edge;
rcv: locally-advertised right window edge
cflags : u8 per-direction feature flags: retransmission
(FRCTFRTX), receiver flow control
(FRCTFRESCNTL), linger-on-close (FRCTFLINGER);
see <ouroboros/fccntl.h>
seqno : u32 snd: next seqno to send;
rcv: force-ACK trigger - set on a stale or dup
DATA so the next ack_snd emits a fresh
cumulative ACK
ackno : u32 snd: outbound ACK-packet seqno counter,
incremented for every ACK-bearing packet (bare
ACK, delayed ACK, SACK); used by wire-dup ACK
detection;
rcv: incoming-ACK dedup tracker
act : ns last activity (used by inactivity / DRF)
inact : ns inactivity threshold; sender = 3*mpl + a + r + 1s,
receiver = 2*mpl + a + r + 1s. mpl is the
Maximum Packet Lifetime (delta-t terminology;
see Section 15); a and r are the FRCT a-timer
and r-timer bounds (see Section 8). The
asymmetry is load-bearing for pre-DRF NACK
(Section 9).
</pre>

The sender holds a per-slot ring snd_slots[RQ_SIZE] keyed by
(seqno mod RQ_SIZE). Each slot tracks its retransmit entry (rxm),
last-send timestamp, and retransmit flag bits: SND_RTX (a
retransmit is pending or has fired, gates the next RTT sample
under Karn) and SND_FAST_RXM (one-shot fast-retransmit staged for
this loss event).

The receiver holds a parallel reorder ring rcv_slots[RQ_SIZE]
(referred to as rq[] in prose) holding stashed out-of-order
packet-buffer indexes; both FRTX and best-effort flows share this
path. The invariant rwe - lwe <= RQ_SIZE holds: on each consume
the receiver advances rwe by the consumed count, capping the
receive window at RQ_SIZE seqno slots.

A separate fence variable rtt_lwe is bumped on every retransmit
(timer-fire, SACK-driven, fast-rxm, NACK-driven) and on every
seqno_rotate (Section 4) to mark the seqno range whose RTT samples
MUST be discarded.

=== 2.2. Service modes (orthogonal axes) ===

FRCP exposes its wire features as a vector of independent QoS
axes selected at flow allocation time. All flows go through the
same flow_alloc(name, qos, ...) primitive; the qosspec_t passed
in determines which protocol machinery engages on the wire. This
contrasts with the POSIX BSD socket model where TCP and UDP
require different socket types (SOCK_STREAM / SOCK_DGRAM).

The axes:

<pre>
service 0 = unordered (no FRCP engagement: raw datagrams,
no PCI on the wire, UDP-equivalent at this layer)
1 = message-ordered (FRCP engaged; SDU boundaries
preserved across fragmentation)
2 = stream (byte-oriented, no SDU boundaries; FRTX
required)
loss 0 = lossless service requested: FRTX retransmit
machinery engages (Section 8); MUST be 0 for
service=2. Non-zero = best-effort, FRTX off.
ber Bit Error Rate tolerance.
0 = error-free service requested: a CRC trailer is
appended after the body of DATA packets and verified
on receive (added / checked outside the FRCP PCI;
see Section 1.1). Non-zero = peer accepts errors;
trailer omitted. SACK control packets carry a
CRC32 trailer regardless of ber; the ber gate
applies to DATA only.
timeout Peer-timeout (ms); 0 disables the keepalive timer.
Independent of FRCP engagement.
</pre>

Encryption is a separate per-flow attribute set at flow setup;
when enabled it wraps the FRCP packet (PCI + body, plus the CRC
trailer if any) under AEAD, expanding the spb by headsz + tailsz
octets (nonce / tag). The CRC trailer is currently kept inside
the AEAD wrap (see Section 1.1).

Reachable combinations exported by include/ouroboros/qos.h:

<pre>
+-----------------+---------+------+-----+-----------------------+
| Cube | service | loss | ber | Engaged |
+-----------------+---------+------+-----+-----------------------+
| qos_raw | 0 | 1 | 1 | Raw passthrough |
| qos_raw_safe | 0 | 1 | 0 | Raw + CRC trailer |
| qos_rt | 1 | 1 | 1 | FRCP, no FRTX, no CRC |
| qos_rt_safe | 1 | 1 | 0 | FRCP, no FRTX, CRC |
| qos_msg | 1 | 0 | 0 | FRCP + FRTX |
| qos_stream | 2 | 0 | 0 | FRCP + FRTX, stream |
+-----------------+---------+------+-----+-----------------------+
</pre>

Forced couplings actually enforced by the public API:

<pre>
- service == SVC_STREAM (2) requires loss == 0; flow_alloc /
flow_accept reject the pair otherwise with -EINVAL.
- FRTX requires FRCP engagement (service != SVC_RAW); requesting
loss = 0 with service = SVC_RAW is structurally a no-op
because no frcti is created.
- The QOS_DISABLE_CRC build flag globally forces ber = 1.
Note: this flag defaults to ON, so default builds ship with
CRC disabled until QOS_DISABLE_CRC is set to OFF.
</pre>

Caveat: the API does NOT force ber = 0 when service != SVC_RAW.
qos_rt has service = SVC_MESSAGE with ber = 1, which means the PCI
itself is not CRC-protected on that cube; the HCS (Section 1.1)
remains the only integrity check on the header.

The FRCP-no-FRTX regime (service = SVC_MESSAGE, loss > 0) is meaningful
and live: sequence numbering, in-order delivery, flow-control
advertisement, KA, DRF rotation, and SDU fragmentation /
reassembly (Section 7.2) all run. Lost packets are dropped
rather than retransmitted; a permanently-lost mid-fragment is
dropped via skip-past-gap once a later SDU is visible in the
reorder ring.

== 3. Protocol parameters ==

<pre>
+--------------------+------------------------+-------------------+
| Parameter | Value | Role |
+--------------------+------------------------+-------------------+
| RQ_SIZE | compile-time, power of | Slot ring / rcv |
| | 2 (default 128) | window width |
| START_WINDOW | compile-time, power of | Initial rwe-lwe |
| | 2 (default 128) | after rotate |
| RTO_MIN | MAX(250 us build-tun- | RTO floor; also |
| | able, 1<<RXMQ_RES); | floored at the |
| | per-flow via fccntl | retransmit-wheel |
| | (FRCTSRTOMIN). | resolution |
| | Default ~1 ms with | (~1 ms by |
| | RXMQ_RES=20. | default). |
| MAX_RTO_MUL | 20 | Backoff shift cap |
| RACK window R | MIN(reo_wnd_mult | Reorder window; |
| | * min_RTT/4, SRTT) | per RFC 8985 |
| | with MIN_REORDER_NS | sec. 6.2; |
| | = 250 us floor; | reo_wnd_mult per |
| | reo_wnd_mult scales | sec. 6.2 step 4 |
| | on D-SACK, cap 20 | |
| MIN_RTT_WIN_NS | 300 s (5 min, Linux | min_RTT windowed |
| | tcp_min_rtt_wlen) | re-anchor |
| REO_WND_MULT_MAX | 20 (RFC 8985 sec. | reo_wnd_mult cap |
| | 6.2 step 4) | |
| REO_DECAY_PKTS | 16 (RFC 8985 sec. | Fresh-ACK'd seq |
| | 6.2 step 4 / | count per halving |
| | RACK.reo_wnd_persist) | |
| MAX_DSACK_LAG | RQ_SIZE | D-SACK sanity cap |
| RTT_QUARANTINE | 32 (seqno steps) | NewReno gate pad |
| SACK rate-limit | SACK_MIN_GAP_NS | Min SACK gap |
| | (250 us, fixed) | |
| SACK_MAX_BLOCKS | 2048 (wire cap; per- | Per-SACK block |
| | flow capped at | cap |
| | (frag_mtu-PCI-4)/8) | |
| SACK_RXM_MAX | 32 | Per-pass staged |
| | | retransmit cap |
| DUP_THRESH | 3 (RFC 8985 default) | Hybrid fast-rxm |
| | | trigger (Sec. 8) |
| MDEV_MUL | 2 (build-tunable via | mdev shift in |
| | FRCT_RTO_MDEV_- | RTO = srtt + |
| | MULTIPLIER) | (mdev << MDEV_MUL)|
| RTTP nonce | 16 octets | Echoed verbatim |
| RTTP_RING | 8 | In-flight probes |
| RTT clamp | 16 * srtt | Probe-sample |
| | | upper bound |
| | | (ACK-derived RTT |
| | | samples gated by |
| | | Karn / recovery |
| | | only) |
| Cold-probe cadence | 100 ms (rx-driven; | Pre-srtt RTTP |
| | see Section 12) | rate |
| DELT_RDV | 100 ms | RDVS emit cadence |
| MAX_RDV | 1 s | RDVS give-up |
| Delayed-ACK fire | 2 * TICTIME (TICTIME | Fired after the |
| | = FRCT tick gran- | first in-order |
| | ularity, default | DATA arrival; |
| | 5 ms; 2*TICTIME | tick is build- |
| | = 10 ms by default) | tunable |
| NACK send cooldown | srtt when an srtt | Pre-DRF NACK |
| | sample exists, else | rate-limit |
| | 100 ms | |
| MAX_SDU | 1 MiB | Max reassembled |
| | | SDU; configurable |
| | | per flow |
+--------------------+------------------------+-------------------+
</pre>

The per-flow fragment Maximum Transmission Unit (MTU) is computed
at flow setup from the lower IPCP's mtu minus encryption
headsz / tailsz and CRC trailer; there is no FRCT-level default or
environment-variable override.

== 4. Sequence-number rotation (DRF) ==

The DRF (Data Run Flag) bit on an outbound packet means "this is
the start of a fresh data run" and is set whenever the sender has
nothing in flight (snd_cr.seqno == snd_cr.lwe).

Independently of that, if the sender has been idle longer than
snd_cr.inact AND the pipe is empty (snd_cr.seqno == snd_cr.lwe),
seqno_rotate() rolls a random new seqno before the send and
resets

<pre>
snd_cr.seqno = random()
snd_cr.lwe = snd_cr.seqno
snd_cr.rwe = snd_cr.seqno + START_WINDOW
rtt_lwe = snd_cr.seqno
in_recovery = false (recovery state, see Section 8)
recovery_high = snd_cr.seqno
</pre>

The receiver, on observing rcv-side inactivity
(now - rcv_cr.act > rcv_cr.inact), requires a DRF on the next
DATA packet; otherwise it replies with a rate-limited NACK (see
below). Non-DATA control packets pass through without the DRF
requirement. On DRF the receiver releases the rq[] slots and
rebases

<pre>
rcv_cr.lwe = seqno
rcv_cr.rwe = seqno + RQ_SIZE
rcv_cr.seqno = seqno
</pre>

If the inactive packet has DATA but no DRF, a rate-limited NACK is
fired back to the sender (cooldown per Section 3); non-DATA stale
arrivals fall through to normal processing (no NACK, no drop).

== 5. Send path ==

<pre>
1. If the SDU exceeds (frag_mtu - data_hdr_len), the caller
(dev.c) fans it out into ceil(count / (frag_mtu -
data_hdr_len)) fragments, each emitted via frcti_snd as its
own DATA packet with a per-fragment role (Section 7.2);
both FRTX and best-effort flows fragment. Raw flows (no
FRCP engagement, qos.service == SVC_RAW) carry no PCI and
return -EMSGSIZE for any SDU larger than one packet at the
layer below. An SDU that fits in a single packet is sent
as SOLE. frcti_snd reserves PCI head room; sets DATA, plus
DRF when the pipe is empty (snd_cr.seqno == snd_cr.lwe).
2. seqno_rotate() if past sender inactivity and the pipe is
empty (Section 4).
3. Advertise FC (pci.window = frcti_advert_rwe(frcti), i.e.
rcv_cr.rwe clamped to rcv_cr.lwe + ring_seq_cap in stream
mode) when the receiver side is recent: now - rcv_cr.act
< rcv_cr.inact.
4. Reliable mode (FRTX): leave snd_cr.lwe where it is; reset
the slot at RQ_SLOT(seqno) (snd_slots[p].time = now,
snd_slots[p].flags = 0); queue an rxm_entry (saves a packet
copy, arms a wheel timer at now + (rto << rto_mul)).
Piggyback ACK (pci.ackno = rcv_cr.lwe) while the a-timer
for the most recent received DATA packet has not yet
expired (now - rcv_cr.act <= t_a); on piggyback, set
rcv_cr.seqno = rcv_cr.lwe so the next delayed-ACK fire is
suppressed. See Section 8 for t_a / t_r semantics.
5. Best-effort mode (no FRTX): advance snd_cr.lwe immediately
(snd_cr.lwe = snd_cr.lwe + 1, snd_cr.rwe = snd_cr.lwe +
RQ_SIZE); no retransmit state. No send-side RTT probe is
armed in this mode (rtt_probe_arm requires an in-flight
seqno, which best-effort never has); the rx-driven cold
seeder in frcti_rcv is the only probe path.
6. In reliable mode, optionally arm an RTT probe (Section 12).
</pre>

== 6. Receive path ==

=== 6.1. Early-exit dispatch ===

Keepalive (KA), RTT probe (RTTP), pre-DRF NACK, and rendezvous
(RDVS) packets short-circuit out of frcti_rcv before the locked
main path; each handler takes its own lock internally.

<pre>
incoming packet
|
v
+---------+
| KA? |---yes--> ka_rcv ; return
+---------+
|no
v
+---------+
| RTTP? |---yes--> rttp_rcv; return
+---------+
|no
v
+---------+
| NACK? |---yes--> nack_rcv; return (see Section 9)
+---------+
|no
v
+---------+
| RDVS? |---yes--> rdv_rcv ; return (reply bare FC, ackno=0)
+---------+
|no
v
acquire wrlock; enter locked main path
</pre>

<pre>
- KA : refresh t_ka_rcv, honour piggybacked ACK.
- RTTP : probe (echo back nonce) or echo (verify nonce, sample
RTT).
- NACK : pre-DRF, sender-side handler. See Section 9.
- RDVS : reply with a bare FC packet (ackno = 0); rdlock only.
</pre>

=== 6.2. Locked main path ===

Steps below run with the per-flow frcti.lock held for writing
(pthread_rwlock_wrlock) unless noted.

<pre>
rcv_inact_check
Only meaningful when the receive side is stale. On DRF
(Data Run Flag): release rq[] slots, rebase rcv_cr, continue.
On stale DATA without DRF: fire a pre-DRF NACK if cooldown
allows (Section 9), then discard the packet; on cooldown,
drop without sending a NACK (a pending cumulative ACK from
drop_packet may still go out). Non-DATA, non-DRF arrivals
bypass rcv_inact_check entirely; pure-DRF stale arrivals fall
through after the DRF rebase branch.
</pre>

<pre>
DATA-only act refresh
Refresh rcv_cr.act only when FRCT_DATA is set, so that non-DATA
packets never block the next DRF rebase.
</pre>

<pre>
Wire-dup gate
Before flag-driven dispatch, drop wire-duplicate ACKs and
wire-duplicate DATA (is_dup_ack / is_dup_data). The DATA
check is bypassed for FRCT_RXM-bearing arrivals so the
piggybacked ACK / SACK / FC carried on a retransmitted DATA
at an already-ACK'd seqno is still applied; the stale-in-
window branch below then drops the packet.
</pre>

<pre>
ACK
Drop ACKs whose ackno falls outside (snd_cr.lwe, snd_cr.seqno].
If ackno == snd_cr.lwe (non-advancing cumulative ACK), drive
RACK fast-retransmit consideration (Section 8). Otherwise
advance snd_cr.lwe = ackno, collapse rto_mul to 0 (Karn-gated
by SND_RTX on the just-acknowledged slot, the old head-of-
line), reset dup_thresh to 0, update t_latest_ack to the
send-time of the slot at ackno-1 (consumed by RACK and SACK
below), decay reo_wnd_mult per RFC 8985 sec. 6.2 step 4,
exit NewReno-careful recovery (see Section 8) on
ackno >= recovery_high or ackno == snd_cr.seqno, and feed an
RTT sample if eligible (Section 12).
</pre>

<pre>
SACK
Walk the block list. For each block (a present range above
lwe) NULL out snd_slots[k].rxm, clear the slot's per-send
flags, and advance t_latest_ack to the latest send-time
covered (the Forward Acknowledgement / fack equivalent,
Mathis & Mahdavi 1996); the first block whose start
clamps to snd_cr.lwe skips this fack update so that a head-
of-line clamp does not falsely advance fack. For un-SACKed
gaps below hi_sacked, stage a retransmit per slot that is
(1) still owned (rxm != NULL), (2) not already SND_FAST_RXM,
(3) not aged out past t_r, and (4) either outside the RACK
reorder window R OR with dup_thresh >= DUP_THRESH (the RFC
8985 sec. 6.2 hybrid trigger). Mark the slot SND_FAST_RXM
and NULL the rxm at stage time. Capped at SACK_RXM_MAX
staged retransmits per receive pass; what's left rides the
next SACK.
</pre>

<pre>
FC
Bump snd_cr.rwe (clamped to lwe + RQ_SIZE, never shrinks)
and mark window open.
</pre>

<pre>
DATA
Bounds-check seqno against window. On stale-dup
(seqno < rcv_cr.lwe), set rcv_cr.seqno = seqno to force a
fresh ACK on the next ack_snd, then drop. On accept: both
FRTX and best-effort stash the packet-buffer index into
rq[seqno mod RQ_SIZE]. Fragments stash unchanged - the role
bits are inspected only at consume time (Section 7.2). On
out-of-order arrival, build a SACK reply if not rate-limited
(per Section 3) and not deduplicated against the previous
(rcv_cr.lwe, n_blocks) pair; D-SACK reports always bypass the
dedup. If both rate-limit and dedup suppress the reply,
neither SACK nor delayed-ACK fires (the sender picks up the
gap on its next ACK). On in-order arrival, arm the delayed-
ACK timer.
</pre>

<pre>
drop_packet exit
Releases the per-packet shared-memory buffer (spb), then
calls ack_snd synchronously after the spb release to surface
any pending cumulative ACK.
</pre>

== 7. Read path and reassembly ==

=== 7.1. Read path ===

flow_read returns a full reassembled SDU (Service Data Unit) via
frcti_consume on every FRCP SDU-mode flow (FRTX or best-effort);
stream-mode is covered in Section 16. An incomplete head-of-line
(HoL) run yields -EAGAIN; an oversized run yields -EMSGSIZE (the
run is dropped so the flow does not stall). On best-effort flows,
a permanently-lost mid-fragment is dropped as soon as a later
complete SDU becomes visible in the ring (Section 7.2 skip-past-
gap).

Raw flows carry no frcti, so flow_read returns the next pending
packet-buffer index directly, with no role-bit inspection. (Raw
service is selected via qos.service == SVC_RAW at flow allocation,
which suppresses frcti creation.)

frcti_pdu_ready is the no-advance peek used by fevent (the
Ouroboros flow-event multiplexer, the poll(2)-equivalent on
flows). It returns ready only when the head-of-line run is
complete and the lead packet (a Protocol Data Unit, here one FRCP
packet) is present at rcv_cr.rwe - RQ_SIZE; any other state
(including the best-effort skip-past-gap case) returns not ready,
and frcti_consume is left to drop the broken prefix and re-
inspect.

=== 7.2. Fragmentation and reassembly ===

Send side (flow_write_frag). An SDU larger than
(frag_mtu - PCI) is split into ceil(count / (frag_mtu - PCI))
fragments; each fragment is its own FRCP packet with its own
seqno and a per-fragment role flag pair (Section 1.2). Roles are
assigned at emit time:

<pre>
+------+--------+
| i | Role |
+------+--------+
| n=1 | SOLE |
| i=0 | FIRST |
| i=n-1| LAST |
| else | MID |
+------+--------+
</pre>

A mid-loop allocation or transmit failure may yield a partial
write: the call returns the bytes already enqueued (off > 0) or
the underlying error (off == 0). Best-effort flows fragment
identically; on the receiver, a partial run with a permanently-
lost fragment is dropped when a later complete SDU is visible in
the ring (see skip-past-gap below). Raw flows carry no PCI and
refuse anything larger than the layer's user MTU (-EMSGSIZE).

Wire-level recovery is fragment-agnostic on FRTX flows: each
fragment's seqno flows through SACK / RACK / RTO / NACK exactly
as for a SOLE DATA packet, and reassembly does not re-enter the
loss-detection path. Best-effort flows run the same seqno
machinery (DRF, FC, ACK piggyback, pre-DRF NACK emit) but queue
no rxm state at the sender, so a lost MID is unrecoverable;
skip-past-gap handles it (below).

Receive side. Fragments stash into rq[seqno] unchanged; role bits
are read only at consume time. frag_run_inspect, called from
frcti_consume, walks the ring starting at the oldest still-
undelivered seqno base = rcv_cr.rwe - RQ_SIZE (equal to rcv_cr.lwe
only when no partial run is in progress; during a partial run lwe
has already advanced past base). It produces one of three
outcomes:

<pre>
+---------------+---------------------------------------------+
| Outcome | Cause |
+---------------+---------------------------------------------+
| DELIVER (n) | rq[base]=SOLE (n=1), or rq[base]=FIRST and |
| | a LAST follows in slots [base+1..base+n-1] |
| | with all intermediate roles in {MID,FIRST, |
| | LAST} contiguous. |
| DROP (n) | rq[base] is MID or LAST without a preceding |
| | FIRST (n=1); a FIRST..[non-LAST]..new-FIRST |
| | or new-SOLE mid-run (drop the broken prefix |
| | with n = run length minus 1, so the new |
| | FIRST/SOLE stays); or, on best-effort |
| | flows, a gap at base with a FIRST/SOLE |
| | later in the ring (drop up to the new run |
| | start). |
| NOT_READY | rq[base] absent or FIRST..[non-LAST] with |
| | no later FIRST/SOLE in the ring (FRTX waits |
| | for retx; best-effort waits for arrival). |
+---------------+---------------------------------------------+
</pre>

DELIVER triggers frag_gather: a scatter-gather memcpy of the n
consecutive fragments at rq[base..base+n-1] directly into the
caller's buffer; each per-packet shared-memory buffer (spb) is
released and rwe advances by n. lwe was already advanced
incrementally as each contiguous fragment arrived; frag_gather
only restores the fixed-width invariant rwe == lwe + RQ_SIZE.
No intermediate reassembly buffer is allocated.

DROP advances rwe past the broken prefix (releasing the spbs)
and pulls lwe up to the new trailing edge if needed; the next
consume retries from the new base. Oversize or arithmetically
overflowing delivery (sum of fragment lengths > max_rcv_sdu, sum
> caller's buffer, or running-sum overflow) also drops the run
with -EMSGSIZE.

Skip-past-gap (best-effort only). On FRTX, a gap in the run means
"waiting for retransmit" and frag_run_inspect returns NOT_READY.
On best-effort flows the gap is permanent, so frag_run_inspect
scans forward in the ring for the next FIRST or SOLE; if one is
visible within RQ_SIZE, it returns DROP for the broken prefix and
the consume loop retries at the new lwe. Memory hold is bounded
by RQ_SIZE; the partial releases on the next consume call once a
later complete run exists. Voice-like flows (one SOLE per SDU)
see no extra wait: any later SOLE makes the prior gap droppable
immediately.

The choice to defer reassembly to consume time keeps the receive
path zero-copy: fragments stay in the shared-memory ring until
the application pulls, and the SDU lands directly in the caller's
buffer.

== 8. Retransmission ==

FRCP is bounded by two delta-t-derived timers (Watson 1981, see
Section 15):

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

Each in-flight FRTX seqno owns one rxm_entry, armed in a hashed
timing wheel; the wheel deadline is the slot's next eligible
retransmit time.

<pre>
RTO timer
On fire (rxm_due), re-emit with FRCT_RXM, mark SND_RTX
(Karn-suppress next ACK's RTT sample), and (for the head-of-
line (HoL) slot only) bump rto_mul up to MAX_RTO_MUL. Wheel
deadline is t_send + (rto << rto_mul). Re-armed unless
consumed. The RTO timer also clears SND_FAST_RXM (re-arming
fast-retransmit eligibility), resets reo_wnd_mult to 1 on a
HoL fire (RFC 8985 sec. 6.2 step 4 reset clause), and marks
the flow ACL_FLOWDOWN if its frct_tx call fails.
</pre>

<pre>
r-timer guard
Before any retransmit attempt, check (now - t0) against t_r.
If exceeded, the slot is no longer eligible for retransmit.
Only the RTO timer (rxm_due) treats r-timer expiry as
terminal: it marks the flow ACL_FLOWDOWN (peer unreachable).
Fast-retransmit, SACK-driven retransmit, and NACK-driven
head-of-line re-emit silently skip aged-out slots and defer
the flow-down decision to the next RTO fire.
</pre>

<pre>
Fast retransmit (hybrid trigger, RFC 8985 sec. 6.2)
On a non-advancing cumulative ACK with the scoreboard
advanced, fire one fast retransmit when EITHER (a) the head-
of-line slot's latest send is older than the RACK reorder
window R (Section 3) and not yet aged out, OR (b) the SACK
dup-thresh count above snd_cr.lwe reaches DUP_THRESH (= 3,
RFC 8985 sec. 6.2 step 4). Fires at most once per non-
advancing cumulative-ACK value, gated by rack_fired_lwe (the
snd_cr.lwe at which fast-retransmit last fired). Set
SND_FAST_RXM on the slot (one-shot per-slot gate) and enter
NewReno-style careful recovery (see NewReno below in this
section).
</pre>

<pre>
The RACK reorder window R uses the RFC 8985 sec. 6.2 form
R = MIN(reo_wnd_mult * min_RTT / 4, SRTT) with a
MIN_REORDER_NS = 250 us floor. Before the first RTT sample
seeds min_rtt, R falls back to MIN(reo_wnd_mult * SRTT / 4,
SRTT), still floored at MIN_REORDER_NS (consistent with the
windowed-minimum fallback described in Section 12). min_rtt
is a windowed minimum over the last MIN_RTT_WIN_NS = 5 min of
RTT samples (matches the Linux tcp_min_rtt_wlen default) so a
route change to a longer path eventually re-anchors the
reorder window without relying on reo_wnd_mult growth alone.
</pre>

<pre>
SACK-driven retransmit
For each gap below hi_sacked whose slot is (1) still owned,
(2) not already SND_FAST_RXM, (3) not aged out past t_r, and
(4) either outside the RACK window R OR with dup_thresh >=
DUP_THRESH (same hybrid as fast-retransmit, see Section 6.2),
re-emit. Each SACK-driven retransmit re-arms a fresh rxm so
a lost retransmit can still be recovered by its own RTO
timer.
</pre>

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

== 9. Pre-DRF NACK ==

The two sides have different inactivity thresholds
(snd_cr.inact > rcv_cr.inact), 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.

<pre>
Send (frcti_nack_snd, called by frcti_rcv when rcv_inact_check
returns FRCT_INACT_NEED_NACK)
When an incoming DATA packet has no DRF and rcv-side activity
is older than rcv_cr.inact, the receiver emits a bare packet
with flags = FRCT_NACK and seqno = arrival_seqno - 1
(informational only, not consulted by the receive handler).
The cooldown in Section 3 rate-limits the burst. Non-DATA
non-DRF arrivals bypass rcv_inact_check entirely; non-DATA
DRF still rebases via the DRF branch.
</pre>

<pre>
Receive (frcti_nack_rcv)
Dispatched in the early-exit branch (Section 6.1), before
rcv_inact_check. The sender copies the head-of-line (HoL)
rxm packet, marks the slot SND_RTX | SND_FAST_RXM (Karn-
suppress next ACK, one-shot fast-rxm gate), sets rtt_lwe =
snd_cr.lwe + 1, and re-emits via fast_rxm_send with FRCT_RXM
and a refreshed ackno. The original rxm_entry 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 t_r, or
the HoL rxm pointer has been cleared by SACK or RACK.
</pre>

NACK serves two roles:

<pre>
1. 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 srtt is seeded by the first probe round-trip).
2. 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.
</pre>

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

== 10. Cumulative + selective ACK ==

Cumulative ACK is ackno = rcv_cr.lwe. On out-of-order arrival the
receiver also emits a SACK packet (Section 1.3) whose payload lists
*present* blocks above lwe (analogous to TCP SACK / QUIC ACK
ranges). SACKs are rate-limited per Section 3 and suppressed when
neither lwe nor block count has changed since the last SACK.

D-SACK reports (RFC 2883) are emitted in-band as block[0] of an
otherwise normal SACK frame (see Section 1.3 for the encoding).
Two receiver triggers arm a pending D-SACK report (single-slot,
latest-wins):

<pre>
- DATA arrival with seqno < rcv_cr.lwe, both wire-dup (no RXM,
is_dup_data path) and retransmit (RXM, post-FC branch)
(RFC 2883 sec. 4.1.1, full duplicate)
- rq_accept conflict, slot already occupied in [lwe, rwe)
(RFC 2883 sec. 4.1.2, partial duplicate)
</pre>

When a D-SACK is pending and the standard scoreboard SACK would be
suppressed by dedup or rate-limit, the report is emitted as a
stand-alone SACK frame through the normal ack_snd path; when a
D-SACK report is pending the path bypasses dedup and the TICTIME
rate-limit, but the a-timer suppression on rcv inactivity still
applies.

Bare ACKs are deferred via a per-flow delayed-ACK timer (one in
flight at a time, atomic test-and-set dedup; fires per Section 3
after the first in-order arrival). Suppressed if (1) no new
seqno, (2) rcv side is inactive (older than t_a), or (3) the
sender just sent within TICTIME. A pending D-SACK ride-through
bypasses (1) and (3); the a-timer gate (2) is unconditional.

== 11. Flow control ==

The receiver advertises rwe in every FC field. The sender treats
its snd_cr.rwe as the absolute right edge: when
snd_cr.seqno >= snd_cr.rwe the window is closed and flow_write
yields. While closed, the sender periodically emits RDVS
(rendezvous) packets (cadence DELT_RDV); the receiver replies with
a bare FC packet (ackno = 0) that reopens the window. Once the
window has been closed for longer than MAX_RDV the sender stops
emitting RDVS but does not tear the flow down - the writer keeps
blocking until either a peer-driven FC arrives or the KA
(keepalive) / r-timer marks the flow.

rwe is clamped to lwe + RQ_SIZE on receipt and MUST NOT shrink:
a backward rwe is silently clamped to the current snd_cr.rwe;
the FC packet still reopens the window.

== 12. RTT estimation ==

Active RTTP probes (Section 1.4) carry a 32-bit probe_id (0
reserved) and a 16-byte random nonce echoed verbatim - defends
against spoofed replies. A ring of RTTP_RING in-flight probes is
kept; an echo whose (id, nonce) doesn't match the ring slot is
dropped. A single RTTP sample is clamped to RTT_CLAMP_MUL * srtt
(compile-time RTT_CLAMP_MUL = 16) once srtt is seeded; the first
cold-probe sample feeds rtt_update raw.

Probe arming gates:

<pre>
- Cold (no srtt yet): the receive path arms at most one probe
per 100 ms via frcti_rcv_probe (PROBE_DUE_COLD); arming
requires an incoming packet. Active send-path arming bails
while srtt == 0.
- Warm (rtt_probe_arm, called from frcti_snd): outstanding
data (snd_cr.seqno > snd_cr.lwe), AND at least 2 * srtt
since t_rcv_rtt (last RTT receive of any kind), AND at
least srtt since t_snd_probe (last probe emit).
</pre>

Sample feeds either Linux's asymmetric mdev estimator
(FRCT_LINUX_RTT_ESTIMATOR, default ON) or RFC 6298 symmetric EWMA
(compile option). srtt is floored at 10 ms when seeded from a
hint, at 1 us after every update (including the first seeding
sample); mdev floored at 100 ns.

<pre>
RTO = max(rto_min, 2 * srtt, srtt + (mdev << MDEV_MUL))
</pre>

(the 2 * srtt floor is an FRCT addition not in RFC 6298).
Effective wheel deadline capped per Section 3.

ACK-derived samples (frcti_ack_rcv -> rtt_sample_eligible), beyond
the cum-ACK advance gate in frcti_ack_rcv (ackno > lwe and
ackno <= seqno), require all of: not in recovery; ACK packet does
not carry FRCT_RXM; HoL slot's SND_RTX bit clear; slot's rxm
pointer non-NULL (not SACK-consumed); lwe not below the rtt_lwe
fence; srtt already seeded by an RTTP probe. There is no ACK-only
seeding.

Every eligible sample also feeds RACK.min_RTT (RFC 8985 sec. 6.2)
via a windowed minimum: replace whenever the sample is strictly
smaller OR more than MIN_RTT_WIN_NS (5 min, matches Linux
tcp_min_rtt_wlen) has elapsed since the current min was set. The
downward branch is immediate (faster path picked up at once); the
upward branch is gated on the window (a transient queue burst does
not poison the estimate, but a sustained route change to a longer
path re-anchors min_RTT after at most one window). Seeded from
rtt_hint at rtt_init; 0 acts as the unset sentinel and the base
in rack_reorder_window falls back from min_RTT to SRTT (so
R = mult * SRTT/4, capped at SRTT, floored at MIN_REORDER_NS)
until the first sample. See Section 6.2.

== 13. Liveness (keepalive) ==

When qs.timeout > 0 a per-flow KA (keepalive) timer is armed.
Arming uses rcv_cr.act for the deadline computation:

<pre>
deadline = min(snd_act + qs.timeout/4,
rcv_act + qs.timeout)
</pre>

(clamped to now + qs.timeout/4 if already past). The timer fires
either on sender idleness (to send a KA) or on receiver idleness
(to declare the peer dead). On fire (ka_snd) the peer-dead test
uses max(rcv_cr.act, t_ka_rcv) so a recent KA reply counts even
when no DATA has arrived:

<pre>
- If now - max(rcv_cr.act, t_ka_rcv) > qs.timeout, mark the flow
ACL_FLOWPEER and notify the per-process flow-event set
(proc.fqset) with FLOW_PEER.
- Else if snd_idle > qs.timeout/4, emit a bare KA | ACK
(ackno = rcv_cr.lwe) and re-arm.
- Else just re-arm.
</pre>

Note: rx_rb and tx_rb are the receive and transmit shared-memory
ring buffers. The r-timer raises ACL_FLOWDOWN on both (route is
broken); keepalive raises ACL_FLOWPEER on rx_rb only and notifies
the flow-event set (peer is silent, writer keeps tx_rb usable) -
distinct ACLs. qs.timeout == 0 disables keepalive entirely; a
silent peer crash is then undetected.

== 14. Linger / teardown ==

On flow_dealloc, frcti_dealloc computes a grace timeout

<pre>
max(rcv_cr.act + rcv_cr.inact, snd_cr.act + snd_cr.inact) - now
</pre>

(floored at 0 and converted to seconds) and returns it; flow_dealloc
forwards this to the IRMd as the dealloc grace. The IRMd, not FRCT,
performs the wait. Before computing the timeout, FRCT may emit a
final ACK when rcv_cr.lwe != rcv_cr.seqno (the peer has not been
told the most recent cumulative ACK) AND the rcv side has been
active within t_a (a-timer not aged out).

FRCTFLINGER is honoured only when snd_cr.lwe < edge, where edge =
snd_fin_seqno after FIN has been sent in stream mode and
snd_cr.seqno otherwise (data or FIN still in flight). The drain
itself runs in flow_dealloc's while (FRCTI_LINGERING) loop, not in
frcti_dealloc.

The fd is single-reader / single-writer (documented in the
manpages). flow_write pumps rx_rb on every call (via
flow_wait_window -> flow_drain_rx_nb) and additionally blocks on
rx_rb when the send window is closed. A pure-writer thread thus
consumes ACKs without a dedicated reader.

== 15. Heritage and adopted techniques ==

Delta-t (Watson, 1981) is the primary heritage; FRCP descends from
the delta-t protocol family via the Recursive InterNetwork
Architecture (RINA; Day, "Patterns in Network Architecture", 2008,
ch. 9). Timer-based connection management
(no SYN/FIN handshake, per-flow state born on first DATA and
reclaimed after t_mpl + a + r of silence), the DRF marker, and the
t_mpl / t_a / t_r timers all come from delta-t. See Watson,
"Timer-Based Mechanisms in Reliable Transport Protocol Connection
Management", Computer Networks 5 (1981).

The unified `flow_alloc(name, qos, ...)` primitive and its
multi-axis QoS-cube argument (Section 2.2) also come from RINA
(Day 2008, ch. 6; Grasa et al., "IRATI: investigating RINA as an
alternative to TCP/IP", Computer Networks 92 (2015)) - reliability,
ordering, CRC presence, and encryption are flow attributes, not
separate sockets or protocols.

The table below summarises additional adopted techniques and their
references.

<pre>
+------------------------+------------------+------------------------+
| FRCP mechanism | Heritage | Reference / note |
+------------------------+------------------+------------------------+
| Random new seqno on | TCP ISN | RFC 6528 (Gont & |
| seqno_rotate | | Bellovin, 2012). |
| | | QUIC PN-space reset |
| | | (RFC 9000 sec. 12.3) |
| | | is a structural |
| | | analogue. |
+------------------------+------------------+------------------------+
| Cumulative ACK, | TCP | RFC 793 / RFC 9293 |
| left-window-edge | | |
| advance | | |
+------------------------+------------------+------------------------+
| Receive window with | TCP | RFC 793 sec. 3.7 / |
| non-shrink rule | | RFC 9293 sec. 3.8.6; |
| | | RFC 1122 sec. 4.2.2.16 |
| | | for the explicit non- |
| | | shrink prohibition |
+------------------------+------------------+------------------------+
| Modular seqno | TCP | RFC 793 sec. 3.3 / |
| arithmetic | | RFC 9293 sec. 3.4 |
| (before/after helpers) | | |
+------------------------+------------------+------------------------+
| Selective ACK block | TCP | RFC 2018 (Mathis et |
| list | | al., 1996). Encoded |
| | | as a typed FRCP packet |
| | | rather than a TCP |
| | | option, so framing is |
| | | closer to QUIC ACK |
| | | frames. D-SACK (RFC |
| | | 2883) carried in-band |
| | | as block[0]; see |
| | | Section 1.3. |
+------------------------+------------------+------------------------+
| NewReno-careful | TCP | RFC 6582 (Henderson |
| recovery with | | et al., 2012); QUIC |
| recovery_high gate | | builds on the same |
| | | model in RFC 9002 |
| | | sec. 7.3.2. Cwnd half |
| | | absent (CC in IPCP). |
+------------------------+------------------+------------------------+
| RACK reordering | TCP | RFC 8985 (Cheng et |
| window for fast | | al., 2021). FRCP |
| retransmit | | R = MIN(reo_wnd_mult * |
| | | min_RTT / 4, SRTT) |
| | | with a MIN_REORDER_NS |
| | | = 250 us floor against |
| | | srtt collapse; matches |
| | | RFC 8985 sec. 6.2 and |
| | | Linux tcp_rack_reo_wnd.|
| | | DSACK-driven |
| | | reo_wnd_mult (sec. 6.2 |
| | | step 4) is adopted; |
| | | see Section 1.3 for |
| | | the wire encoding. |
| | | The hybrid RACK-or- |
| | | DUP_THRESH trigger |
| | | from RFC 8985 sec. 6.2 |
| | | step 4 is adopted |
| | | (Section 8). QUIC's |
| | | analogue in RFC 9002 |
| | | sec. 6.1.2 uses |
| | | max(srtt, latest_rtt) |
| | | as the base. |
+------------------------+------------------+------------------------+
| Karn's algorithm: | TCP | Karn & Partridge, |
| no RTT sample on | | "Improving Round-Trip |
| retransmits, RTO- | | Time Estimates in |
| collapse freeze | | Reliable Transport |
| | | Protocols", SIGCOMM |
| | | 1987; RFC 6298 sec. 3. |
+------------------------+------------------+------------------------+
| RTO formula | TCP | RFC 6298 (Paxson et |
| RTO = max(RTO_MIN, | | al., 2011). RTO_MIN = |
| srtt + (mdev << | | 5 ms is below RFC 6298 |
| MDEV_MUL)) | | sec. 2.4's 1 s SHOULD- |
| | | floor - a recursive- |
| | | layer choice. |
+------------------------+------------------+------------------------+
| Linux asymmetric mdev | Linux kernel | tcp_rtt_estimator() in |
| estimator (default) | | net/ipv4/tcp_input.c; |
| | | the if(delta<0) m>>=3 |
| | | dampening is a |
| | | kernel divergence from |
| | | RFC 6298. RFC 6298 |
| | | EWMA available behind |
| | | a compile flag. |
+------------------------+------------------+------------------------+
| Delayed ACK with rate | TCP | RFC 813 (Clark, 1982); |
| suppression | | RFC 1122 sec. 4.2.3.2; |
| | | RFC 5681 sec. 4.2. |
| | | Single-deadline |
| | | coalescing rather than |
| | | "ack-every-other- |
| | | segment". |
+------------------------+------------------+------------------------+
| Zero-window-probe / | TCP | RFC 1122 sec. |
| persist-timer | | 4.2.2.17 / RFC 9293 |
| analogue (RDVS) | | sec. 3.8.6.1. RDVS |
| | | solicits an FC reply, |
| | | distinct from QUIC |
| | | DATA_BLOCKED (RFC 9000 |
| | | sec. 19.12), which is |
| | | one-way notification. |
| | | MAX_RDV give-up |
| | | departs from TCP. |
+------------------------+------------------+------------------------+
| Multiplexed control | SCTP / QUIC | SCTP chunk bundling |
| on a single PCI | | (RFC 9260 sec. 6.10); |
| | | QUIC frame |
| | | multiplexing (RFC 9000 |
| | | sec. 12.4). Cleaner |
| | | fit than TCP's |
| | | separate-flag-bits |
| | | design. |
+------------------------+------------------+------------------------+
| ACK ranges as | QUIC | QUIC ACK frame (RFC |
| multiple discontiguous | | 9000 sec. 19.3). FRCP |
| acked blocks | | SACK is conceptually |
| | | QUIC-frame-shaped |
| | | even though encoded |
| | | as absolute |
| | | [start,end] pairs. |
+------------------------+------------------+------------------------+
| Nonce-authenticated | QUIC | PATH_CHALLENGE / |
| active RTT / liveness | PATH_CHALLENGE | PATH_RESPONSE (RFC |
| probing (RTTP) | | 9000 sec. 8.2, |
| | | sec. 19.17, sec. |
| | | 19.18). WebRTC ICE |
| | | consent-freshness |
| | | (RFC 7675) is the |
| | | same pattern. QUIC's |
| | | nonce is 8 octets; |
| | | FRCP chooses 16. |
+------------------------+------------------+------------------------+
| Probing distinct from | QUIC | KA timer answers |
| keepalive | | "peer alive?", RTTP |
| | | answers "path |
| | | measurable?", as in |
| | | QUIC PING (RFC 9000 |
| | | sec. 19.2) vs |
| | | PATH_CHALLENGE. |
+------------------------+------------------+------------------------+
| Bare KA + ACK | QUIC / SCTP | QUIC PING (RFC 9000 |
| keepalive packets | | sec. 19.2); SCTP |
| | | HEARTBEAT / |
| | | HEARTBEAT-ACK (RFC |
| | | 9260 sec. 8.3). SCTP |
| | | HEARTBEAT also carries |
| | | an opaque echoed blob, |
| | | structurally similar |
| | | to FRCP RTTP. |
+------------------------+------------------+------------------------+
| (FFGM, LFGM) | SCTP | RFC 9260 sec. 3.3.1 |
| fragment-role bits | | DATA chunk B/E bits |
| (Section 7.2) | | encode the same four |
| | | states (B+E=SOLE, |
| | | B-only=FIRST, neither |
| | | =MID, E-only=LAST). |
| | | Each fragment carries |
| | | its own seqno/TSN and |
| | | is independently |
| | | retransmitted. |
+------------------------+------------------+------------------------+
| Stream byte-offset | QUIC | QUIC STREAM frame |
| reassembly | | (RFC 9000 sec. 19.8) |
| (Sections 1.5, 16) | | uses Offset + Length |
| | | varints; FRCP uses |
| | | fixed 32-bit start / |
| | | end. One stream per |
| | | flow vs QUIC's many |
| | | streams multiplexed. |
+------------------------+------------------+------------------------+
| FIN end-of-stream | TCP / QUIC | TCP FIN flag (RFC 9293 |
| marker | | sec. 3.1) closes one |
| (Sections 1.2, 16) | | half of the byte |
| | | stream; QUIC STREAM |
| | | frame FIN bit (RFC |
| | | 9000 sec. 19.8) does |
| | | the same per stream |
| | | with an immutable |
| | | final-size invariance |
| | | (RFC 9000 sec. 4.5: |
| | | the final size is |
| | | fixed once observed). |
| | | FRCP's FIN consumes |
| | | one packet seqno (not |
| | | one byte of stream |
| | | space) and is |
| | | idempotent on the |
| | | sender side. |
+------------------------+------------------+------------------------+
| Stream byte-credit | QUIC | MAX_STREAM_DATA (RFC |
| flow control | | 9000 sec. 4.1, sec. |
| (Section 16) | | 19.10). FRCP projects |
| | | a per-flow byte budget |
| | | onto the seqno-space |
| | | rwe. Single stream |
| | | per flow collapses |
| | | QUIC's MAX_DATA / |
| | | MAX_STREAM_ |
| | | DATA distinction. |
+------------------------+------------------+------------------------+
| Header protection | QUIC | QUIC RFC 9001 sec. 5.4 |
| (encrypted seqnos) | | applies header |
| | | protection on top of |
| | | AEAD to mask the |
| | | packet number. FRCP's |
| | | per-flow AEAD wrap |
| | | (Section 16) is wider: |
| | | it encrypts the entire |
| | | PCI including seqno |
| | | because the IPCP |
| | | below already routes, |
| | | so no destination |
| | | connection-ID needs to |
| | | stay in clear (cf. |
| | | RFC 9000 sec. 5.2). |
+------------------------+------------------+------------------------+
| Two-bit fragment role | SCTP | The (FFGM, LFGM) pair |
| polarity | | follows SCTP B/E |
| | | (begin = 1 / end = 1) |
| | | rather than IPv4 MF |
| | | (RFC 791 sec. 3.2), |
| | | which has the inverse |
| | | polarity (MF = 1 means |
| | | NOT last). |
+------------------------+------------------+------------------------+
| Orthogonal reliability | SCTP | PR-SCTP (RFC 3758, |
| / ordering axes | | per-message partial |
| (Section 2.2) | | reliability) and SCTP |
| | | DATA U-bit (RFC 9260 |
| | | sec. 3.3.1, per- |
| | | message unordered) |
| | | are the closest |
| | | precedents for |
| | | decoupling reliability |
| | | from ordering; FRCP |
| | | sets them per-flow |
| | | rather than per- |
| | | message. |
+------------------------+------------------+------------------------+
| Orthogonal CRC | UDP-Lite | RFC 3828 (Larzon et |
| (qs.ber == 0) | | al., 2004) lets the |
| | | sender pick a per- |
| | | packet Checksum |
| | | Coverage and the |
| | | receiver enforce a |
| | | locally configured |
| | | minimum (no in-band |
| | | negotiation; sec. 3.1, |
| | | sec. 3.3). FRCP |
| | | gates a full CRC |
| | | trailer on qs.ber == 0 |
| | | at flow setup. |
| | | Contrast TCP / SCTP |
| | | (mandatory checksum) |
| | | and QUIC (AEAD |
| | | subsumes CRC). |
+------------------------+------------------+------------------------+
| Setup-time service | DCCP / SCTP / | DCCP Service Codes |
| negotiation | QUIC | (RFC 4340 sec. 8.1.2, |
| | | RFC 5595); SCTP INIT |
| | | parameters (RFC 9260 |
| | | sec. 3.3.2); QUIC |
| | | transport parameters |
| | | (RFC 9000 sec. 7.4). |
| | | All negotiate service |
| | | properties at |
| | | connection setup; only |
| | | RINA's QoS cube |
| | | exposes them as an |
| | | orthogonal vector. |
+------------------------+------------------+------------------------+
</pre>

=== 15.1. Original to FRCP (no clean prior art) ===

<pre>
- Pre-DRF NACK (Section 9): receiver-driven nudge exploiting
snd_cr.inact > rcv_cr.inact. Closest analogues are SCTP Gap Ack
Blocks (RFC 9260 sec. 3.3.4) and DCCP Ack Vector (RFC 4340
sec. 11.4) - both let the receiver describe gaps to the sender,
but neither targets the cross-epoch / pre-DRF case.
- MAX_RDV window-probe give-up: neither TCP (persist-timer
probes until application or R2 abort, RFC 9293 sec. 3.8.6.1)
nor QUIC has an explicit FC-give-up counter. A recursive-
network choice: outer layers can drop the flow.
- Skip-past-gap reassembly (Section 7.2): SCTP fragments and
reassembles every flow regardless of reliability/ordering,
using its own per-stream reassembly queue; QUIC fragments via
STREAM offsets. FRCP fragments best-effort flows too, but
the receiver drops the broken prefix the moment a later run-
start (FIRST or SOLE role) is visible inside the RQ_SIZE-wide
reorder ring - no IP-frag-style timeout, no SCTP-style
explicit abort. If no later run-start arrives within the
ring, frag_run_inspect returns NOT_READY and the partial run
keeps its slots; the next inspect retries. The trade-off: a
permanently-lost MID in a long isolated run holds slots until
either a later FIRST/SOLE appears in the ring or the writer
stops, at which point the slots are reclaimed on flow
teardown.
- Reassembly deferred to consume time (Section 7.2), message
mode only (qos.service == SVC_MESSAGE): SCTP (RFC 9260
sec. 6.9), QUIC (RFC 9000 sec. 2.2), and TCP (RFC 9293) all
hold reassembly state at the receive boundary. FRCP message-
mode leaves fragments in the shared-memory ring until
flow_read pulls and lands the SDU directly in the caller's
buffer. Stream mode (Section 16) uses the standard QUIC-
style direct ring placement on receive and does not defer.
The optimisation is enabled by the Shared-Memory Subsystem
(SSM) packet-buffer ring (see struct ssm_pk_buff at
Section 1.1); the analogue is OS-level scatter-gather I/O
(recvmsg+iovec), not a transport-layer prior art.
- TLP-equivalent tail-loss recovery (RFC 8985 sec. 7;
RFC 9002 sec. 6.2): FRCP does not emit an explicit Tail Loss
Probe packet, but the same goal is met implicitly by RACK
loss detection (Section 8) firing on a non-advancing
cumulative ACK once the head-of-line slot ages past the RACK
reorder window R = MIN(reo_wnd_mult * min_RTT / 4, SRTT) -
well below RTO = max(2 * SRTT, SRTT + (mdev << MDEV_MUL)).
A receiver-driven nudge is also available via the pre-DRF
NACK (Section 9).
</pre>

=== 15.2. Not adopted ===

<pre>
- Slow start, congestion window (cwnd), Additive Increase /
Multiplicative Decrease (AIMD), NewReno cwnd inflation.
Congestion control lives in the IPCP CA policies and is
driven by Explicit Congestion Notification (ECN, RFC 3168).
- Nagle / silly-window-syndrome (SWS) avoidance (RFC 896, RFC
1122 sec. 4.2.3.4). (Deferred work, not adopted in the
current spec.)
- TCP Timestamps (RFC 7323) / Protection Against Wrapped
Sequences (PAWS) - RTT measurement uses RTTP,
not per-segment timestamps. A peer-supplied timestamp echoed
on every ACK lets a malicious peer drive the srtt estimate
arbitrarily low, collapsing the RTO and triggering a self-
inflicted retransmit storm. RTTP confines RTT measurement to
nonce-authenticated probe round-trips, where a forged echo is
rejected before it can reach the estimator.
- ECN (Explicit Congestion Notification) response inside FRCP
(consumed by IPCP Congestion Avoidance / CA).
- IP-style fragment-offset reassembly (RFC 791 sec. 3.2; RFC 8200
sec. 4.5). Message-mode FRCP relies on the FRCT rq[] reorder
ring keyed by seqno (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 [start, end) byte offsets
(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 (FFGM/LFGM) and skips the offsets; stream-mode
FRCP adopts the QUIC offset model (heritage table above).
</pre>

== 16. Stream-mode flows ==

When a flow is allocated with qos.service == SVC_STREAM both peers
switch to byte-stream semantics, layered on top of the FRTX reorder
machinery already described in Sections 6-8.

=== 16.1. Send ===

The sender splits the caller's octets into chunks of at most
(frag_mtu - base PCI - stream PCI extension) octets (Sections 1.1
and 1.5). Each chunk is one DATA packet with its own seqno and a
[start, end) byte range copied from a monotonic stream counter.
In stream mode FFGM and LFGM are unused and MUST be transmitted as
zero; the per-byte position is carried by the [start, end)
extension instead.

End-of-stream is signalled with a 0-byte DATA packet that has FIN
(bit 12) set, emitted on the FIN triggers listed in Section 1.2
(WR-half close, flow_dealloc, and any other path that yields the
final byte). The sender MUST emit at most one FIN per flow; its
[start, end) MUST equal [final-byte, final-byte) (i.e., empty
interval at the final byte position; final-size invariance,
analogous to QUIC RFC 9000 sec. 4.5). Idempotency is enforced by
an snd_fin_sent guard.

=== 16.2. Receive ===

On arrival the receiver places the payload directly into a per-flow
byte-indexed receive ring of width ring_sz (octets) at the position
indicated by start, with a two-segment memcpy across the ring
boundary if needed. Receipt is recorded in the FRTX reorder
machinery (Section 6.2) augmented with the packet's start, end, and
FIN bit per slot. When a packet's [start, end) front-overlaps
bytes already at or below the byte high-water mark, the overlap is
trimmed before placement so the same byte is never written twice.
After stashing, the receiver advances lwe and the byte high-water
mark across any newly-contiguous prefix. Each slot advanced MUST
satisfy `start == the last-delivered slot's end`; a slot whose
start does not equal that end is silently dropped at delivery time
(the seqno is consumed, no stream bytes contributed) and the high-
water mark does not advance past it. The stream byte-stream
stalls at that point - there is no flow-tear-down on mismatch.
This filters spliced or off-path-injected slots that fall in
window without strong cryptographic authentication.

A FIN slot marks end-of-stream at advance time only if its byte
position equals the last-delivered slot's end; otherwise the FIN
is ignored and the corresponding seqno occupies a slot but
contributes no stream bytes. No packet buffer is held after the
ring copy.

=== 16.3. Read ===

flow_read returns up to count octets from the contiguous prefix
[next, high-water), where next is the byte the application has
already consumed up to and high-water is the rightmost contiguous
byte received. When the stream is fully drained AND end-of-stream
(EOS) was observed (next == EOS byte position), flow_read returns
0 (EOF) - the same shape POSIX read(2) uses on TCP after a peer
FIN.

=== 16.4. Flow control ===

ACK / SACK / RACK / RTO machinery is unchanged; the FRTX reorder
ring is reused as a per-seqno received-bitmap. Let per_pkt =
(frag_mtu - base PCI - stream PCI extension), the maximum stream-
byte payload one DATA packet can carry (Section 16.1). The
receive window advertised in FC is clamped so the byte window
(ring_sz) cannot be overrun: the seqno-space rwe is at most
`rcv_cr.lwe + ring_sz / per_pkt`.

This is the QUIC byte-credit flow-control model
(MAX_STREAM_DATA, RFC 9000 sec. 4.1 and sec. 19.10) projected onto
seqno space. With one stream per flow there is no MAX_DATA /
MAX_STREAM_DATA distinction. Receiver-side silly-window-syndrome
(SWS) avoidance (RFC 9293 sec. 3.8.6.2.2) is achieved by combining
the consume-time rwe bump with the global non-shrink rule from
Section 11.

=== 16.5. Security considerations ===

Threat model. An attacker that can observe (on-path passive) or
predict (off-path blind) the flow's seqnos and byte offsets on an
unencrypted stream flow can inject DATA or FIN at any in-window
position. The in-line consistency checks above (start == prior
end on advance; FIN MUST be 0-byte; FIN MUST sit at the final
byte position) realise the spirit of RFC 5961's "sequence-window
plus exact-position match for control bits" without an explicit
challenge-ACK probe; they make a few specific blind attack shapes
harder but are not cryptographic authentication. This is
comparable to TCP without the TCP Authentication Option (TCP-AO,
RFC 5925), tighter than a
pre-RFC-5961 TCP stack, and roughly equivalent to a modern
RFC 5961 stack against blind off-path injection - none of these
help once the attacker can sniff. TLS over TCP (RFC 8446)
encrypts only the TCP payload and leaves TCP seqnos, ACKs, FIN,
and RST in the clear, so TLS does NOT defend against TCP-header-
level injection; QUIC (RFC 9000) hides packet numbers under
header protection (RFC 9001 sec. 5.4), so this specific weakness
does not apply to QUIC.

Mitigation: AEAD. When the flow has encryption enabled the
recommended AEAD ciphers (AES-GCM, RFC 5288; or ChaCha20-Poly1305,
RFC 8439) wrap the entire FRCP packet on the wire - PCI, stream
extension, body, and the CRC trailer when ber == 0 - under a
per-flow symmetric key derived from the flow's own key exchange
(Section 1.1). The AEAD tag (~2^-128 forgery probability)
dominates the CRC (~2^-32) for integrity in this mode but the CRC
trailer is currently retained inside the wrap (see Section 1.1).
Implementations MUST NOT rely on the security properties below
when a non-AEAD cipher (e.g. AES-CTR alone) is negotiated; non-
AEAD modes provide confidentiality only and the threat-model
claims do not hold.

With an AEAD cipher in use, seqnos, byte offsets, and the FIN bit
are both authenticated and confidential. Against an off-path or
on-path-passive attacker this is:

<pre>
- Stronger than TCP+TLS (TCP header in the clear).
- Stronger than TCP+TCP-AO (header authenticated but visible).
- 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.
</pre>

Keying granularity. FRCP runs key exchange (kex) per flow, so
each flow_alloc 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 kex 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
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
seqno-space duplicate-suppression in Section 6.2 rejects replayed
DATA after the AEAD strips the wrap, because the AEAD authenticates
the seqno and a replay re-presents an old seqno that is then
discarded either as a duplicate (still inside the receive window)
or as outside the receive window, depending on how far lwe has
advanced since the original packet was delivered. RAW
(qos.service == SVC_RAW) flows have no FRCP layer and therefore
no replay protection at the AEAD layer either; deployments that
need replay rejection on RAW flows MUST provide it at a higher
layer.

Layering. The AEAD wrap sits below FRCP on the data path, so
RAW best-effort flows (qos.service == SVC_RAW, the UDP-equivalent
service of 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.

== 17. References ==

This section lists the IETF documents, published works, and
source-code references cited inline elsewhere in this document.
IETF documents are cited inline as "RFC NNNN sec. X.Y"; books,
journal papers, and source-code references are cited inline by
author and year (or by file and function name) and are listed
here for convenience.

=== 17.1. IETF documents ===

<pre>
[RFC 791] J. Postel, "Internet Protocol", STD 5, RFC 791,
September 1981.
</pre>

<pre>
[RFC 793] J. Postel, "Transmission Control Protocol", STD 7,
RFC 793, September 1981. Obsoleted by RFC 9293.
</pre>

<pre>
[RFC 813] D. D. Clark, "Window and Acknowledgement Strategy
in TCP", RFC 813, July 1982.
</pre>

<pre>
[RFC 896] J. Nagle, "Congestion Control in IP/TCP
Internetworks", RFC 896, January 1984.
</pre>

<pre>
[RFC 1122] R. Braden (ed.), "Requirements for Internet Hosts
-- Communication Layers", STD 3, RFC 1122,
October 1989.
</pre>

<pre>
[RFC 2018] M. Mathis, J. Mahdavi, S. Floyd, A. Romanow,
"TCP Selective Acknowledgment Options", RFC 2018,
October 1996.
</pre>

<pre>
[RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
</pre>

<pre>
[RFC 2883] S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky,
"An Extension to the Selective Acknowledgement
(SACK) Option for TCP", RFC 2883, July 2000.
</pre>

<pre>
[RFC 3758] R. Stewart, M. Ramalho, Q. Xie, M. Tuexen,
P. Conrad, "Stream Control Transmission Protocol
(SCTP) Partial Reliability Extension", RFC 3758,
May 2004.
</pre>

<pre>
[RFC 3828] L-A. Larzon, M. Degermark, S. Pink, L-E. Jonsson
(ed.), G. Fairhurst (ed.), "The Lightweight User
Datagram Protocol (UDP-Lite)", RFC 3828,
July 2004.
</pre>

<pre>
[RFC 4303] S. Kent, "IP Encapsulating Security Payload
(ESP)", RFC 4303, December 2005.
</pre>

<pre>
[RFC 4340] E. Kohler, M. Handley, S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340,
March 2006.
</pre>

<pre>
[RFC 5288] J. Salowey, A. Choudhury, D. McGrew, "AES Galois
Counter Mode (GCM) Cipher Suites for TLS",
RFC 5288, August 2008.
</pre>

<pre>
[RFC 5595] G. Fairhurst, "The Datagram Congestion Control
Protocol (DCCP) Service Codes", RFC 5595,
September 2009.
</pre>

<pre>
[RFC 5681] M. Allman, V. Paxson, E. Blanton, "TCP Congestion
Control", RFC 5681, September 2009.
</pre>

<pre>
[RFC 5925] J. Touch, A. Mankin, R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010.
</pre>

<pre>
[RFC 5961] A. Ramaiah, R. Stewart, M. Dalal, "Improving
TCP's Robustness to Blind In-Window Attacks",
RFC 5961, August 2010.
</pre>

<pre>
[RFC 6298] V. Paxson, M. Allman, J. Chu, M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298,
June 2011.
</pre>

<pre>
[RFC 6528] F. Gont, S. Bellovin, "Defending against Sequence
Number Attacks", RFC 6528, February 2012.
Obsoletes RFC 1948.
</pre>

<pre>
[RFC 6582] T. Henderson, S. Floyd, A. Gurtov, Y. Nishida,
"The NewReno Modification to TCP's Fast Recovery
Algorithm", RFC 6582, April 2012.
</pre>

<pre>
[RFC 7323] D. Borman, B. Braden, V. Jacobson,
R. Scheffenegger (ed.), "TCP Extensions for High
Performance", RFC 7323, September 2014.
</pre>

<pre>
[RFC 7675] M. Perumal, D. Wing, R. Ravindranath, T. Reddy,
M. Thomson, "Session Traversal Utilities for NAT
(STUN) Usage for Consent Freshness", RFC 7675,
October 2015.
</pre>

<pre>
[RFC 8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in
RFC 2119 Key Words", BCP 14, RFC 8174, May 2017.
</pre>

<pre>
[RFC 8200] S. Deering, R. Hinden, "Internet Protocol,
Version 6 (IPv6) Specification", STD 86, RFC 8200,
July 2017.
</pre>

<pre>
[RFC 8439] Y. Nir, A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 8439, June 2018.
</pre>

<pre>
[RFC 8446] E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.3", RFC 8446, August 2018.
</pre>

<pre>
[RFC 8985] Y. Cheng, N. Cardwell, N. Dukkipati, P. Jha,
"The RACK-TLP Loss Detection Algorithm for TCP",
RFC 8985, February 2021.
</pre>

<pre>
[RFC 9000] J. Iyengar (ed.), M. Thomson (ed.), "QUIC: A
UDP-Based Multiplexed and Secure Transport",
RFC 9000, May 2021.
</pre>

<pre>
[RFC 9001] M. Thomson (ed.), S. Turner (ed.), "Using TLS to
Secure QUIC", RFC 9001, May 2021.
</pre>

<pre>
[RFC 9002] J. Iyengar (ed.), I. Swett (ed.), "QUIC Loss
Detection and Congestion Control", RFC 9002,
May 2021.
</pre>

<pre>
[RFC 9147] E. Rescorla, H. Tschofenig, N. Modadugu,
"The Datagram Transport Layer Security (DTLS)
Protocol Version 1.3", RFC 9147, April 2022.
</pre>

<pre>
[RFC 9260] R. Stewart, M. Tuexen, K. Nielsen, "Stream Control
Transmission Protocol", RFC 9260, June 2022.
Obsoletes RFC 4960.
</pre>

<pre>
[RFC 9293] W. Eddy (ed.), "Transmission Control Protocol
(TCP)", STD 7, RFC 9293, August 2022. Obsoletes
RFC 793 and several follow-ons; updates RFC 1122
and others.
</pre>

=== 17.2. Books and journal papers ===

<pre>
- J. Day, "Patterns in Network Architecture: A Return to
Fundamentals", Prentice Hall, 2008.
</pre>

<pre>
- E. Grasa et al., "IRATI: investigating RINA as an alternative
to TCP/IP", Computer Networks, Vol. 92, December 2015.
</pre>

<pre>
- P. Karn, C. Partridge, "Improving Round-Trip Time Estimates
in Reliable Transport Protocols", ACM SIGCOMM, August 1987.
</pre>

<pre>
- R. W. Watson, "Timer-Based Mechanisms in Reliable Transport
Protocol Connection Management", Computer Networks, Vol. 5,
1981.
</pre>

=== 17.3. Source-code references ===

<pre>
- tcp_rtt_estimator() in net/ipv4/tcp_input.c of the Linux
kernel, defining the asymmetric mdev variance update used as
FRCP's default RTT estimator (Section 12). Line-stable
browseable copy at
https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_input.c.
</pre>

Prototype Version History

2026-02-22T16:59:51Z

Dimitri: /* 0.23 (Current version, February 22, 2026) */

Ouroboros is still in an early proof-of-concept prototype phase. Versions 0.x.y have no forward nor backward compatibility. We bump minor version with API or protocol changes. Within a minor version, different patch levels ''should'' be compatible (no guarantees).

Once the functionality has reached a minimal critical mass, and a sufficient degree of software stability has been achieved, a version 1.0.0 will be released with the intention to maintain backwards compatibility from that point. This is still many (man)years off.

This page summarizes the progress and the plans for the next prototype (minor) version. For a summary of the current implementation state, see [[Ouroboros Implementation Overview| our status page]].

== 0.24 (Current development branch) ==

== 0.23 (Current version, February 22, 2026) ==

* Added PQC support to the library, including ML-KEM, Hybrid ECDH-KEM key exchange and ML-DSA and SLH-DSA based authentication.
* IRMd now negotiates encryption strength between endpoints based on lowest-floor exchange.
* Replaced the rdrbuff with per-user and priviliged shared slab allocator pools for shared memory packet buffers.
* Added automatic key rotation for encrypted flows.
* Refactored the ring buffer implementation and removed the old rbuff_ll variant.
* IRMd now allows direct ring buffer connections between local processes, reducing overhead for same-machine IPC.
* Major refactoring of CMake modules, plus new targets for coverage reports and automatic version parsing from git tags.

== 0.22 ==
* Added flow authentication and the Flow Allocation Protocol header in the irmd
* Added UDP/IPv6 support
* Added protocol level debug logging
* Moved encryption control from qosspec to naming system
* Removed qosspec parameter from the broadcast API
* Refactored and simplified enrolment and connection manager
* Complete rewrite of the DHT for the unicast layer
* Refactored Ethernet IPCPs
* Deprecated appveyor in favor of codeberg/woodpecker CI
* Improved test coverage
* Improved systemd service and pkgconfig installation logic
* Improved ctest integration into build system

== 0.21 ==
* Moved public key handling from library to IRMd
* Refactor of IRMd / registry implementation

== 0.20 ==
* Improved configuration file handling
* Improved FUSE stability
* Log unique IDs to enrollment requests
* Print logo on startup when logging to std output
* Fix most common hangs on exit

== 0.19 ==
* Pass the N-1 layer MPL at flow allocation
* Add flow liveness monitoring.
* Allow multiple directories in an IPCP
* Dropped support for raptor
* Use one UDP port for the IPCP over UDP/IPv4

== 0.18 ==
* Use QoS cube for ECN marking
* Always use 64-bit endpoint IDs
* Add RIB statistics for flow allocator
* Add congestion avoidance policies
* Add flow control policies
* Add GCC 10 static analyzer build option

== 0.17 ==
* Rename systemd service to ouroboros
* Add tests for LFA and ECMP routing
* Add Equal-Cost Multi-Path routing policy

== 0.16 ==
* Removed support for SWIG bindings
* Add support for appveyor CI
* Add encryption support using OpenSSL

== 0.15 ==
* Rename normal IPCP to unicast IPCP
* Add flow_join API for broadcast IPCP

== 0.14 ==
* Add Explicit Congestion Notification field to DT
* Add broadcast IPCP

== 0.13 ==
* Disable CRC32 by default

== 0.12 ==
* Split error checking from FRCT
* Rename port_id to flow_id
* Rename SDU to packet
* Pass QoS spec at flow allocation
* Initial retransmission logic
* Support QoS specs for oping
* Use Endpoint ID's in fa protocol instead of fd

== 0.11 ==
* Simplify reg/unreg API
* Support for partial packet reads
* Add IPCP over Ethernet DIX

== 0.10 ==
* Revise lookup tracking in DHT
* Update man pages to CC-BY 4.0

== 0.9 ==
* Add patchlevels for future versions
* Add support for Raptor FPGA Layer-1 PoC

== 0.8 ==
* Use "program" instead of "application process"
* Use "process" instead of "application process instance"
* Send timestamp in oping
* Use 3-clause BSD license for tools

== 0.7 ==
* Use ELF sections to init/fini ouroboros
* Simplify PFT for LFA routing
* Add RIB to expose metrics via FUSE
* Deprecate Common Distribution Application Protocol (CDAP)
* Simplify enroll API
* Deprecate Graph Adjancency Manager component

== 0.6 ==
* Added a threadpool manager for improved concurrency
* Added Loop-Free Alternates (LFA) routing
* Add DHT as default directory policy

== 0.5 ==
* Move FRCT logic from IPCP to application library
* Split connection establishment from flow allocation
* Split flow manager into flow allocator and data transfer
* Register hashes in a layer instead of cleartext name
* Add netmap support for LLC shim
* Initial lockless rbuff implementation
* Add generic thread pool management
* Revise flow allocation API
* Split authentication from CACEP
* Revise CACEP API
* Exchange application protocol information during CACEP

== 0.4 ==
* Add support for syslog logging
* Revise RIB/CDAP as a btree structure
* Add B-tree implementation
* Add full-mesh policy for GAM
* Add Graph Adjacency Manager (GAM)
* Add flat address policy
* Add initial directory to normal IPCP
* Initial RIB/CDAP synchronization
* Add RIB/CDAP objects
* Add operf tool

== 0.3 ==
* Move all shared memory (shm) mgmt to IRMd
* Use shared memory tx/rx ring buffer per flow
* Split off bind/unbind (map/unmap name to process) from reg/unreg

== 0.2 ==
* Add shim DIF over LLC Ethernet
* Add CBR tool for performance testing
* Add IPCP over local memory

== 0.1 ==
* Add full flow allocator to UDP shim
* Implementation of flow related ops
* Simple echo application
* Initial shim IPCP over UDP/IPv4
* Add RINA name helpers
* Initial library code
* Initial SDU/PDU buffer code
* Initial APIs for IRM/IPCP/CFAP/DIF allocator
* Initial CDAP header
* LICENSE and CONTRIBUTORS files
* Initial documenents and GPLv2 license