Remote Access over Unreliable Links: A Case for Packet-Level Redundancy

Remote access tools like RDP, VNC, or TeamViewer are core components of modern IT operations - whether for remote support, off-site development, or managing embedded systems in the field. However, these protocols generally assume stable, low-latency networks with minimal packet loss.

In practice, that's not always what they get.

The Problem: Real-Time Sensitivity Meets Unstable Links

Protocols like RDP and VNC are latency-sensitive and often loss-intolerant. Even a small amount of jitter ( variation in delay) or 2-3% packet loss can introduce:

• Noticeable input lag (mouse/keyboard)
• Visual artifacts or partial screen updates
• Complete session stalls under burst loss

When you're remoting into a device via LTE, Starlink, or a lossy VPN tunnel - this can quickly make the session unusable.

Traditional Mitigations Fall Short

Most remote access tools rely on ARQ (Automatic Repeat reQuest), retransmitting lost packets until they’re acknowledged. While this ensures data integrity, it introduces significant latency. Each retransmission can delay the stream by tens or even hundreds of milliseconds, especially when head-of-line blocking occurs. This is particularly damaging in interactive scenarios like remote desktops, where real-time responsiveness is key.

Burst losses make things worse: they cause multiple retransmissions in sequence, creating clustered delays. The result? Input lag, screen freezes, and irregular frame updates. On unstable links - such as LTE, lossy VPNs, or satellite - even the retransmissions themselves can be delayed or lost, compounding the problem.

An alternative approach is to avoid retransmission entirely. Instead of waiting to detect and repair loss, we can use packet-level redundancy: proactively send extra information so the receiver can recover missing packets on the fly. This keeps latency bounded and ensures a smoother user experience.

The Alternative: Network Coding as a Safety Net

With Random Linear Network Coding (RLNC) or other forms of application-layer forward error correction, you change the game. Instead of sending packets one-to-one, you send additional, redundant packets derived from the original data. As long as enough packets arrive, the missing ones can be reconstructed without any retransmissions.

Behavior Comparison Table

Scenario	Packet Loss	Traditional RDP (TCP)	RLNC-protected Stream
Ideal wired link	0%	Smooth	Smooth
LTE link, moving vehicle	5–10%	Laggy, freezes under load	Smooth interaction, minimal impact
Starlink, obstructed view	10–15% burst loss	Disconnects common	Session remains active, minor stutter
Remote industrial site via Wi-Fi bridge	5% constant loss + jitter	Severe degradation	Usable with no noticeable lag

Why It Matters

If your work depends on remote access in imperfect network conditions – such as field technicians, remote monitoring teams, or emergency response - you're often operating at the mercy of the network. RLNC or similar technologies give you a layer of transport resilience that doesn't require changing the underlying tools.

Technically, it behaves like a transparent tunnel - but smarter.

One Way to Use It

Tools like NanoPing apply this logic in practice. It wraps existing traffic in a coded stream that adapts to the network's conditions in real-time. You don’t have to change how you run VNC, RDP or SSH - but now it behaves as if the network were clean, even when it isn’t.