ouroboros/src/lib/dev.c, branch 0.24.0

ipcpd: Rework congestion avoidance

2026-07-19T09:44:36+00:00

Congestion avoidance is a property of the layer, orthogonal to ARQ and to flow control: FRCP retransmits and lets the peer pace the sender, per flow, end-to-end; the IPCP paces path aggregates. Each signal means one thing: a loss triggers a retransmission, a mark means congestion, the peer window means a slow receiver. Every flow is paced by the same rate law whatever its QoS, so a greedy raw sender shares a bottleneck fairly with a reliable stream. The unit of control is the (destination address, QoS cube) aggregate: all flows toward that destination share one controller and one rate; a start-time fair-queuing pacer divides the rate across them by deadline instead of blocking the send path, and a new flow rides the aggregate's estimates at its current rate, with no probing of its own. Slow start runs once per aggregate. The congestion signal is a multi-bit magnitude: forwarders mark packets with their standing queue depth, MAX-combined across hops, so a packet carries the deepest queue on its path. The receiver feeds back a time-integral mean over a window that adapts to the flow's byte rate, measuring a slow flow with the same fidelity as a fast one. The sender runs AIMD scaled by elapsed wall-clock time, which makes the steady-state allocation RTT-independent. The PCI gains one byte: the path capacity as a quarter-log2 code. Forwarders estimate their egress rate from busy-period drain and MIN-stamp the byte, the receiver returns the window minimum with its feedback, and the sender scales its rate floor and additive slope to the bottleneck (C / 32). A deep cut implies a backlogged bottleneck and a backlogged bottleneck advertises its capacity, so the scaled floor is live exactly when recovery needs it: the probe heals a halving in seconds at any link rate, and the floor bounds the deepest hole to a factor 32 below the bottleneck. Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

lib: Whitespace cleanup in dev and frct

2026-07-19T09:44:35+00:00

Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

lib: Fix locking on flow read

2026-07-08T09:02:24+00:00

Reading a deallocated flow could cause an assert on a negative id. The raw-flow path now holds proc.lock across flow_rx_spb rather than dropping it first, and the FRCT loop no longer releases and reacquires the lock on every iteration. Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

lib: Prefer writers on the proc flow lock

2026-07-08T09:02:24+00:00

FRCT readers hold proc.lock in a rdlock loop and could starve a pending flow accept waiting for the wrlock. Initialise the lock with the writer-nonrecursive kind on Linux with glibc, so writers are not indefinitely delayed. Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

lib: Clean up on cancelled blocking read

2026-07-08T09:02:24+00:00

Cancelling a thread that was blocked in ssm_rbuff_read_b/write_b didn't clean up the n_users reference. If it was in flow_rx_one it didn't unlock the process lock. Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

build: Make re-key watermark configurable

2026-06-29T06:33:00+00:00

KEY_REKEY_WM_CHECK_BITS now controls the watermark check, once per 2^n flow writes (FLOW_WM_CHECK in dev.c). Now the configuration check (check watermark < outstanding packets) is contained in lib.cmake instead of assuming the value of FLOW_WM_CHECK. Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

lib: Bound crc_check against short packets

2026-06-29T06:33:00+00:00

Reject a packet shorter than head_skip + CRCLEN before computing the CRC, instead of hashing over an underflowed length when the buffer is too small to hold the trailer. Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

irmd: Complete bidirectional flow re-keying

2026-06-29T06:32:59+00:00

Extend re-key delivery beyond the locally-initiated watermark path: Handle peer-initiated re-key requests, allowing one request and one response per flow at a time. The client side wins if both ends try to re-key at the same time. Caches the peer certificate to support cert-less authenticated/signed re-keys. After a rekey, the initiator promotes first (timer) and starts sending under the new key. The responder observes the new key (peer_synced) and then the responder promotes. The responder will self-decide to use the new keys if it exhausted the older set in the case where it never sees the peer (unidirectional flow). Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

irmd: Deliver flow re-keying

2026-06-29T06:32:58+00:00

Re-key each encrypted flow's batch root periodically so a long-lived flow never exhausts or over-uses a single root. The IRMd re-runs the OAP exchange with the peer IRMd over the flow-update relay. The per-flow re-keying state is tracked in the registry (reg_flow). A re-key delivers one root seed from the OAP exchange. keyrot immediately HKDF-expands it into 128 node keys (KR_NODES_SZ = 128 × 32 B) and wipes the root. Then each of the 128 node keys is itself a root → HKDF-expanded into 64 (2^KEY_NODE_BITS) leaf keys, forked per direction; each leaf key is the actual AEAD key, good for 2^20 packets (the low counter bits are its nonce/seq). If the number of keys runs low, a re-key will be triggered (KEY_REKEY_WATERMARK). The rekey is signalled out of band to the application. The rbuff ACL is generalized into a flags word, so an RB_REKEY bit rides alongside the access RB_RD/RB_WR and FLOWDOWN/FLOWPEER bits. The RD and WR bits are revised ditching the fcntl historical weirdness. The seed is pulled via flow_read/flow_write, installed with crypt_rekey(). TX holds the old epoch until the peer is observed on the new one (or a grace deadline elapses), promoted from both the read and write paths so a recv-mostly flow still advances. Also fix the FLOW_ACCEPT and FLOW_ALLOC handlers, which on a key-buffer allocation failure returned from inside the cleanup-push region: that leaked the reply message and skipped both the stack-key scrub and the cleanup pop. Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

ipcpd: Add flow-update relay

2026-06-29T06:32:58+00:00

This adds an ipcp_flow_update() call to relay opaque messages between the two IRMds (carried by FLOW_IRM_UPDATE messages), which passes it back up to the peer IRMd via ipcp_flow_update_arr(). The broadcast layer does not implement this. Needed for periodic re-keying of encrypted flows via OAP. Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders