The cross-border latency bill: SD-WAN takes Shanghai→Singapore from 350 ms to 60 ms
Colleagues in the Shanghai office connecting to headquarters’ RDS (remote desktop) and SSL-VPN in Singapore had been suffering for years: ping 350+ ms, every click and keystroke in the remote session visibly lagging. Congestion, detours and jitter on cross-border internet paths (especially China outbound) are familiar pain to any company connecting Chinese offices to overseas resources.
Before / After measurements
After deploying a local provider’s SD-WAN solution (FastIP) — same laptops, same targets:
The full picture — behind the numbers is the difference between “barely usable” and “usable”
| Test | Before (internet) | After (SD-WAN) |
|---|---|---|
| ping RDS1 | 350+ ms | ≈60 ms |
| ping RDS2 | 350+ ms | ≈60 ms |
| ping SSL-VPN | 350+ ms | ≈70 ms |
Traceroute told the same story: the public path wandered a dozen-plus hops that shifted daily; after SD-WAN, traffic enters the provider’s optimized backbone within the first hops and the path holds steady.
For an interactive protocol like RDS, 350 ms → 60 ms isn’t “six times faster” — it’s the qualitative jump from “tolerated” to “near-local”. User feedback went from weekly complaints to “why is it so smooth today?”
Worth recording from the rollout
- Capture evidence before touching anything: ping/tracert screenshots from several user laptops pre-deployment, then the same suite after — that before/after pack is the ROI report for management and the SLA baseline for any future dispute with the provider;
- Test the real targets: not a speed-test site, but the actual RDS hosts and VPN entry users touch — you optimized the path to your resources, so measure exactly that;
- Cross-border circuits/SD-WAN in China are compliance-sensitive: use a properly licensed provider with a formal service and maintenance contract. No grey routes;
- SD-WAN isn’t a cure-all — it fixes the WAN path. If the bottleneck is the server side (an under-resourced RDS) or the last mile (office broadband), the money lands in the wrong place. Prove with traceroute and segmented pings that the latency really lives in the cross-border leg first.
Lesson
Cross-border experience problems: quantify first (segmented latency), then treat (path optimization), then accept (re-measure with the same method). A network upgrade with no “before” data has feelings for results and lobbying for budget.