When a slow link reads as a dead patient monitor, TCP is the wrong contract

A remote patient monitoring team found that telemetry devices which ran cleanly in the lab began dropping their connections to the supervisor dashboard once they were deployed onto rural broadband, satellite links and congested cellular towers ^[1][3]. What matters is not that the link degraded but how the degradation presented: the operator saw a device that appeared completely offline rather than one that was late ^[4], which the author describes as a critical safety risk rather than a bug ^[5].

The account, published on dev.to, describes an edge device running Windows CE that continuously streamed ECG, SpO2 and heart rate to a central dashboard ^[1][2]. The diagnosis was TCP window exhaustion compounded by head-of-line blocking, constrained by the legacy operating system ^[6]. Round trip time between device and dashboard went from 20ms to upwards of 2500ms when network quality fell away ^[7], a factor of roughly 125 ^[8]. The Windows CE stack had a small, rigidly configured TcpWindowSize, so with acknowledgments arriving that late the device exhausted its outbound buffer and sat waiting, unable to transmit ^[9]. A fixed window is a hard cap on bytes in flight per round trip, so multiplying RTT by 125 divides usable throughput by the same figure ^[22]. The dashboard, seeing a prolonged freeze in incoming data, exceeded a naive timeout threshold, concluded the device had crashed, and dropped the socket ^[10]. Reconnecting meant a fresh handshake and state resynchronisation across a pipe that was already choked ^[11].

The obvious remedy was closed off in two directions. Changing TcpWindowSize through the Windows CE registry requires a global reboot or driver reload and cannot be adjusted at runtime as network conditions shift ^[12], and handing a large buffer allocation to an embedded device with limited RAM risks kernel-level memory exhaustion that would take the whole medical application down ^[13]. Underneath the tuning question sat a semantics question. TCP enforces absolute ordering, so a dropped frame 2 halts frames 3, 4 and 5 until frame 2 is retransmitted ^[14]; the team decided that a ten-second-old heartbeat reading is stale history and that real-time continuity mattered more than perfect historical delivery ^[15].

So they moved the window into their own code, running a custom sliding window protocol over UDP and taking on pacing, ordering and buffer management themselves ^[16]. Each packet carries a monotonically increasing 16-bit sequence ID, and the device may transmit ahead up to sequence ID plus the window size W without an intermediate acknowledgment ^[17]. The supervisor does not acknowledge individual frames; it sends a periodic feedback heartbeat stating the highest sequence it has processed, for example 104 ^[18]. On receipt the device slides its window base to 105, releases the older memory blocks and transmits 105 through 108 ^[19].

Two things are worth tracking. A 16-bit sequence space wraps after 65,536 values ^[21], and continuous vitals streaming will reach that boundary on a schedule set by frame rate; the published text describes a smart frame dropping stage for when the window slams shut but breaks off mid-sentence, so neither wraparound handling nor the drop policy is visible ^[20]. The other is the dashboard side. The original false disconnect came from treating data silence as device death ^[10], and an application-layer window only removes that failure if the supervisor's liveness test is rewritten to match.