Technical Case · KT-000023

Intermittent Internet and RDP Drops Required Continuous Evidence

Users reported repeated remote-session drops and Internet instability, but many point-in-time tests looked normal.The incident became actionable only after the problem was measured over time and compared across paths.

Documented by Michael Miller Published September 9, 2026

Case ID

KT-000023

Networking / ISP / Remote Access

Status

Carrier Fault Confirmed / Remaining Path Reclassified

Technologies

WAN / ISP / RDP / Cloud Networking / Monitoring

Problem

What happened?

Users were experiencing recurring Internet instability and remote-session drops. The difficult part was that the problem was intermittent, so technician testing could easily land in a healthy window.

A single successful ping or clean remote session could not explain whether the network had been healthy all day.

Investigation

How was the changing fault domain proven?

Intermittent network problems are not disproven by a clean five-minute test. Measure the path over time.

Continuous evidence turns “the Internet feels slow” into something a carrier can act on.

Investigation path: User reports → Continuous monitoring → LAN/WAN comparison → Loss and latency evidence → Carrier escalation → Transport repair → Retest → Cloud-path comparison → Fault-domain reclassification

Step 1

Stop relying on point-in-time success

Continuous monitoring was collected because isolated tests frequently looked normal while the users continued reporting drops.

Step 2

Record measurable events

Packet loss, outages, latency spikes, restoration periods, and timing were documented so the problem could be correlated with user impact instead of described only as “slow Internet.”

Step 3

Compare internal and external targets

An Internet target and an internal target were compared to help separate local-network health from WAN instability.

Step 4

Escalate with source and destination evidence

The ISP case included the affected source/destination information and monitoring evidence. During part of the incident, the carrier/NOC confirmed a transport-path issue.

Step 5

Retest after the repair

Testing continued after carrier remediation instead of assuming the entire recurring symptom set had one permanent root cause.

Step 6

Reclassify the remaining path

Later ping and traceroute evidence showed healthy ISP delivery into a cloud provider network for a tested destination. That moved the remaining fault domain farther upstream for that path.

Finding

What was actually proven?

The incident contained changing network conditions, not one universal root cause

Users reported recurring Internet instability and remote-session drops, while many point-in-time tests looked normal. Continuous monitoring captured intermittent loss and outages; packet loss, outages, latency spikes, and restoration periods were documented while internal and Internet targets were compared.

The carrier escalation included source and destination information, and the ISP/NOC confirmed a transport-path issue during part of the incident. Testing continued after carrier remediation rather than treating the repair as permanent resolution of every symptom.

Later ping and traceroute evidence showed healthy ISP delivery into a cloud provider network for one tested destination. That result reclassified the remaining fault domain for that path; it did not prove that every upstream component or cloud path was healthy.

It does not support claiming that every RDP drop came from the same carrier fault, that the incident had one universal root cause, or that every remaining problem after the carrier repair was inside the ISP.

This page is the proof layer for evidence-driven intermittent network troubleshooting, not a replacement for the linked symptom-boundary, comparison, or verification methodologies.

Traceroute boundary

Traceroute is path evidence, not a pass/fail test by itself. Intermediate hops may not answer even when the final destination remains reachable.

Verification

Monitor long enough to capture the failure window, compare LAN and WAN targets, record loss and latency, preserve source/destination pairs, retest after carrier remediation, and correlate remote-session drops with measured network events.

Public-safe evidence boundary

This case does not expose customer names, ISP names, cloud-provider names, IP addresses, hostnames, circuit IDs, or ticket IDs.

Lessons Learned

Intermittent problems need evidence that survives a healthy moment.

Intermittent network problems are not disproven by a clean five-minute test. Measure the path over time.

The useful question is not whether the path works right now. It is whether the evidence shows where the path failed when the user experienced the problem, and whether that fault domain changes after remediation.

Related Resources

Scope, compare, and verify before naming the cause.

Scope