DEV Community: Shashi Bhushan Savarn

Designing a Custom Application-Layer Sliding Window Protocol for High-Latency Networks

Shashi Bhushan Savarn — Tue, 18 Aug 2026 11:43:43 +0000

A few years ago, my team faced a critical engineering challenge. We were managing a remote patient monitoring system where the edge telemetry device ran on Windows CE. In a pristine laboratory setting with low latency, the system was flawless. It continuously streamed vital signs (ECG, SpO2, and heart rate) to a central supervisor monitoring dashboard.

However, once deployed into the field—where devices relied on erratic rural broadband, satellite links, or congested cellular towers—the system began to fail. The supervisor dashboard, sitting on a high-speed corporate network, regularly experienced connection dropouts. To the operator, it looked like the patient’s monitoring device was completely offline. In a medical environment, this wasn't just a bug; it was a critical safety risk.

Here is an architectural deep dive into why standard network stacks broke down under these conditions, and how we engineered a custom, application-layer Sliding Window Protocol to stabilize the telemetry pipeline.

The Root Cause: TCP Window Exhaustion & Head-of-Line Blocking

When analyzing the network drops, we discovered a classic distributed systems problem: TCP Window Exhaustion compounded by Head-of-Line (HoL) Blocking, constrained by a legacy operating system.

The Failure LoopThe Latency Trap: When network quality degraded, the Round Trip Time (RTT) between the Windows CE device and the supervisor dashboard skyrocketed from 20ms to upwards of 2500ms.

Buffer Starvation: The native TCP/IP stack in Windows CE had a small, rigidly configured window size (TcpWindowSize). Because network acknowledgments (ACKs) took so long to return across the high-latency link, the device quickly exhausted its outbound buffer. It spent all its time waiting, unable to transmit new packets.

The False-Positive Disconnect: On the other end, the supervisor software saw a prolonged freeze in incoming telemetry data. Exceeding its naive timeout threshold, the dashboard assumed the remote device had crashed and abruptly dropped the socket connections.
The Overhead Storm: Re-establishing a dropped connection meant executing a fresh handshake and state resynchronization, which further choked the already degraded network pipe.

Why We Couldn't Just "Fix the TCP Config"
A senior engineer's immediate instinct might be to tune the OS registry values or increase the TCP buffer size. As an architect, you must weigh platform limitations:

Windows CE Registry Inflexibility: Modifying TcpWindowSize via the Windows CE registry requires a global reboot or driver reload. You cannot dynamically adjust it at runtime based on shifting network topologies.

Memory Constraints: Giving a massive TCP buffer allocation to an embedded device running on limited RAM risks kernel-level memory exhaustion (OOM), which could crash the entire medical application.

The Reality of Medical Telemetry: Standard TCP enforces absolute data ordering. If Telemetry Frame #2 drops, TCP halts everything (Frames 3, 4, and 5) until Frame #2 is retransmitted. In live patient monitoring, a 10-second-old heartbeat metric is stale history. We cared infinitely more about real-time continuity than perfect historical delivery.

The Solution: A Custom Application-Layer Sliding Window

To bypass the rigid OS network layer, we decoupled our application state from standard TCP behavior by implementing a Custom Sliding Window Protocol over a lightweight, connectionless transport layer (UDP).

This put packet pacing, ordering, and buffer management entirely inside our application code.

1. Sequence Numbering & The Logical Window
Every telemetry packet was stamped with a unique, monotonically increasing 16-bit integer Sequence ID. We defined a strict Transmit Window (W) in memory. The edge device was permitted to continuously blast packets ahead of time up to Sequence ID + W without waiting for an intermediate acknowledgment.

2. Cumulative and Selective Feedback Loops
The supervisor application did not acknowledge individual frames. Instead, it sent a lightweight, periodic feedback heartbeat back to the edge device: "I have safely processed up to Sequence ID 104."

Upon receiving this cumulative acknowledgment, the Windows CE device would instantly "slide" its window base forward to 105, freeing up the older memory blocks and clearing room to transmit frames 105 through 108.

3. Smart Frame Dropping
If the network latency grew too severe and the transmit window slammed shut (e.g., frame 101 was never acknowledged, but 102, 103, and 104 were sent), our application layer executed a Priority Drop.
Instead of freezing the UI, the device cleared out the oldest unacknowledged frames from the buffer, updated its window base explicitly, and filled the next window slots with fresh, real-time vital signs. The supervisor dashboard was programmed to gracefully handle missing sequence gaps by interpolating the graph line, rather than panicking and dropping the connection.

Architectural Lessons for Senior Engineers

This project underscored a vital lesson that senior developers shifting into architecture frequently overlook: The operating system and the network stack are not magical boxes that solve every problem for you.

When designing edge, IoT, or critical distributed systems, keep these architectural paradigms in mind:

1. Match the Protocol to the Domain Domain: TCP guarantees delivery, but it does not guarantee timeliness. If your application values the freshness of data over absolute completion (like live video, gaming, or patient vitals), native TCP will eventually fail you on poor networks.

2. Design Explicit Application-Layer Backpressure: Never let an external network condition dictate your internal application memory allocation. If the network clogs, your system must have a deterministic policy for what to do with incoming data (Queue it, Drop it, or Throttle the producer).

3. Decouple App Availability from Network Stability: The supervisor application shouldn't equate a delayed packet with a dead node. Build smart heartbeat mechanisms that check for endpoint liveliness separately from the primary data ingestion streams.

Have you ever had to build a custom application-layer protocol to conquer hardware or network constraints? Let’s talk about your edge architecture experiences in the comments below!

Predicting CPU Spikes

Shashi Bhushan Savarn — Tue, 18 Aug 2026 11:09:47 +0000

Predictive System Health Checks: What I Learned Testing ARIMA, SARIMA, and Prophet on Infrastructure Metrics

When building a system health check layer, knowing the current CPU, memory, or disk usage is only half the battle. If your dashboard says "CPU is at 85%," you are missing critical context. Is that a normal Tuesday morning spike? Or is it a runaway process that will crash the server in twenty minutes?

To build an intelligent, predictive health check layer for my application, I decided to move past reactive thresholds. I ran a series of head-to-head experiments using three heavy hitters in time-series forecasting: ARIMA, SARIMA, and Facebook Prophet.

I tested them against diverse, real-world infrastructure shapes—ranging from daily 9-to-5 spikes to slow-burning memory leaks.
Here is a deep dive into what worked, what failed, and how data frequency and history length completely change the game.

The Tech Stack & Test Dataset Shapes
To see where each model shined or sputtered, I evaluated them on three core infrastructure metrics: CPU (highly volatile), Memory (gradual/stepped), and Disk Space (linear growth).
I fed these metrics into three statistical frameworks:

ARIMA (Autoregressive Integrated Moving Average): The classic baseline. Best for short-term, non-seasonal trends.
SARIMA (Seasonal ARIMA): ARIMA's older sibling. It adds seasonal parameters to capture repeating cycles (like a 24-hour day).
Prophet: An additive model optimized for business time series with strong seasonal patterns and multiple curve shifts.

I threw five distinct data anomalies and patterns at these models to see how they would react:

Daily Workday Spike: (High usage 9-to-5, dead at night)
Gradual Linear Creep: (Slow, steady memory or disk growth)
Once-a-Month Spike: (Monthly cron jobs or payroll processing)
Random Spike: (Unpredictable traffic/DDOS bursts)
Smooth Wave Pattern: (Usual gradual increase/decrease)

Performance Breakdown: Which Model Won?

Pattern 1: Gradual Increases & Memory Creeps
Winner: Prophet
The Reality: Prophet knocked this out of the park. When an application has a slow memory leak or a steady growth in disk usage, Prophet isolates the structural trend line beautifully from day-to-day noise. It handles non-linear growth curves without overreacting.
The Losers: ARIMA and SARIMA tend to "flatline" too early or get heavily distorted by minor short-term fluctuations, missing the macro-trajectory of a slow-burn failure.

Pattern 2: Daily Workday Spikes (Hourly Data)
Winner: SARIMA
The Reality: When infrastructure metrics strictly adhere to human schedules (e.g., traffic surges at 9 AM and drops at 6 PM), SARIMA dominates. Once you properly configure its seasonal period parameter (s=24 for hourly data), it locks onto the daily pattern with razor-sharp precision.
The Runner-Up: Prophet performs adequately here, but it tends to slightly smooth out the sharp peaks, making its maximum capacity forecasts a bit too conservative for infrastructure alerting.

Pattern 3: Once-a-Month Spikes
Winner: None (Structural Failure)
The Reality: Every model failed here unless given years of data. If your dataset only spans 3 months, a monthly cron job or billing cycle only appears 3 times. Statistical models cannot confidently separate a 3-occurrence spike from a random outlier. They either ignore the monthly spike entirely or treat it as a trend disruption.

Pattern 4: Random Spikes & Traffic Bursts
Winner: None
The Reality: Time-series forecasting models assume the future is a function of the past. A completely random spike (like a sudden micro-burst of traffic or a rogue script execution) breaks these models completely.
The Danger: ARIMA and SARIMA are especially vulnerable here; they often interpret a massive random spike as the beginning of a major upward trend, leading to wild, panicked forecasts for the subsequent hours.

The Hidden Variable: Data Frequency vs. History Length
One of my biggest takeaways was that the math doesn't matter if your data granularity is wrong. I observed a direct trade-off between the frequency of data collection and the historical window used for training:
Scenario A: Every hour for the last 1 week

Best for: Identifying intra-day cycles and immediate next-hour alerts.
The Problem: The model becomes blind to long-term trends. It assumes the world resets every Sunday night. If your memory is gradually creeping up week-over-week, this training window will completely miss it.

Scenario B: Every 12 hours for the last 3 months

Best for: Macro-capacity planning, disk space runway prediction, and tracking monthly baselines.
The Problem: You lose all fine-grained peak visibility. A critical, high-intensity CPU spike that lasts for 2 hours gets completely smoothed out and averaged into oblivion. The model will tell you your system is perfectly fine when it is actually choking during peak hours.

Practical Engineering Takeaways
If you are looking to build predictive alerts or trend graphs into your own applications, save yourself some time and follow these engineering rules:

1. Decouple Your Models: Do not use a single model for your system health dashboard. Use Prophet to track slow-moving variables like disk allocation and memory creep. Use SARIMA to forecast highly cyclical, usage-dependent patterns like CPU spikes.
2. Sanitize Your Data Before Training: Because random spikes break statistical models, you must clean your training data. Apply a rolling median filter or a simple outlier truncation step to strip out random 1-minute 100% CPU spikes before feeding the data to the model. Otherwise, your model will spend days forecasting "ghost" anomalies.
3. Align Granularity to the Goal: If you want to prevent out-of-memory (OOM) crashes today, train an hourly model on a 14-day history. If you want to know when to upgrade your AWS EBS volumes, train a 12-hour aggregated model on a 6-month history.

What are you using?
Building an automated predictive system is iterative, and no statistical model fits perfectly out of the box without tweaking parameters.
Have you tried building time-series forecasting into your DevOps or application monitoring stack? Do you lean toward classic stats models, or have you migrated to deep learning solutions? Let's discuss in the comments below!