[Submitted on 15 Jun 2026 (v1), last revised 22 Jul 2026 (this version, v3)]

View PDF HTML (experimental)

Abstract:Satellite terminals, industrial telemetry-and-control, embedded systems, tactical networks often multiplex a small, latency-critical message class with bulk traffic over one connection. A single FIFO connection can starve the critical class. Parallel connections cost another five-tuple (often blocked by carrier-grade NAT, port budgets, and operator policy), are not always available, and when the critical class is light are bandwidth-fair only in aggregate. We present CATS (Conductor-driven Asymmetric Transport Scheme), a sender-side, receiver-transparent TCP priority scheme in which a Conductor assigns each message a priority class and just-in-time sequence numbers under a credit-based shaper. CATS provides deterministic non-starvation, single-flow fairness, and a provable bounded per-class delay.
We then show CATS-over-TCP is not a tail-latency mechanism. Three structural barriers bound single-connection in-band priority: the in-order sequence space, the shared congestion window, and per-flow network QoS. These barriers explain why fair queuing and L4S fail to help a single connection and can worsen it by granting a parallel-connection competitor per-flow isolation while leaving in-band priority unserved, and why two parallel connections reduce tail latency by 4-8 times at the cost of another flow. We give CATS-over-QUIC as the principled escape: independent sequence spaces with per-stream isolation under aggregate-coupled congestion control attain the guarantees on one fair flow. A proof of concept shows unreliable datagrams achieve a flat tail (approx. 27 ms p99.9 vs. approx. 307 ms over TCP) by never retransmitting lost messages, while reliable streams still require an aggregate-coupled congestion controller; we frame this standards gap as a research program. An ns-3 evaluation across loss, contention, and handover regimes supports every claim, including the negative ones.

Submission history

From: Syed Muhammad Aqdas Rizvi [view email]
[v1] Mon, 15 Jun 2026 16:27:07 UTC (142 KB)
[v2] Mon, 13 Jul 2026 06:24:09 UTC (142 KB)
[v3] Wed, 22 Jul 2026 09:10:52 UTC (144 KB)