Remote Work VPN Guide: Zoom/Teams/Slack Packet Loss and Latency Requirements and Route Testing

You can tell within minutes of a meeting whether your remote-work VPN was a good pick. Zoom, Teams, and Slack don't ask the same things of your network: video calls suffer from packet loss and jitter, messaging suffers when long-lived connections get reset, and file sync suffers from mid-transfer disconnects. This remote-work VPN guide breaks down the thresholds for each of these three workloads, then explains which scenarios IEPL dedicated lines, relay, and direct routes each suit — and how to measure latency, jitter, and packet loss yourself in a few minutes.

Latency, Jitter, and Packet Loss: The Three Real Causes of Meeting Lag

Bandwidth is the most overestimated metric. Zoom's official network requirements suggest roughly 1.5 Mbps up and down for 720p group video, a little more for 1080p; Teams' official guidance for 720p calls is in the same 1.5 Mbps up/down range. Ordinary home broadband and 4G/5G both clear that bar, so meeting lag is almost never a bandwidth problem — it's one of the three metrics below.

Latency is usually measured as round-trip time (RTT): the gap between when you speak and when the other person hears it. Below 150 ms, conversation feels natural; above 200 ms, you get obvious talking over each other, pauses, and the awkward "you go first" moment.

Jitter is how much latency fluctuates. When jitter is high, audio buffers can't adjust in time, so voices break up and sound robotic; meeting apps tolerate jitter even less than they tolerate latency.

Packet loss is the share of packets that never arrive. A little random loss can be masked by codecs, but once loss comes in bursts, the picture dissolves into blocks — and in bad cases the call drops and reconnects.

Of the three, latency is tolerable, jitter is hard to tolerate, and packet loss is the least tolerable. That's why a direct route with lower latency in the daytime can be worse at peak hours than a dedicated line with slightly higher latency but near-zero loss.

Zoom vs. Teams vs. Slack: Network Thresholds Compared

All three vendors' official docs land on nearly identical recommended thresholds: latency under 150 ms, jitter under 30 ms, packet loss under 1%. The real differences show up in what each is most sensitive to and what happens after a disconnect.

The table in one sentence: meetings care about packet loss and jitter, collaboration cares about whether connections stay up long-term, and sync cares about bandwidth. The three workloads have different needs, so route them separately.

IEPL Dedicated Lines, Relay, and Direct: How the Three Route Types Differ

Direct: the client connects straight from the local exit to a server in the target region. It's the shortest path, but the whole way runs over public international transit. It's usually fine during the day; when the exit congests at peak hours, latency and packet loss get worse together.

Relay: traffic first enters a relay node (commonly in Hong Kong, Singapore, or Japan), which then forwards it to the destination. It looks like a detour, but the detour skips exactly the most congested stretch of international transit, so it's usually more stable at peak hours than a direct connection.

IEPL dedicated line: an enterprise-grade international Ethernet private line that runs point-to-point over a dedicated channel, never touching the public internet. Latency is stable and packet loss is extremely low, making it the best of the three for long video meetings; it's also the most expensive, so it's better saved for stability-sensitive traffic like meetings than for downloading large files.

VPNFN currently covers 120+ countries and 180+ routes, and the route list includes all three types — which is what makes per-workload route selection possible.

Choosing Routes by Tool: Meetings, Collaboration, and Sync Go Separate Ways

Video meetings: IEPL dedicated line first

Meeting traffic is the only truly real-time workload — any jitter is audible. Give meetings their own IEPL dedicated line and add the relevant meeting domains to your split-routing rules in the client. If there's no dedicated-line entry point in your region, fall back to a low-loss relay route and avoid the most congested hours for long calls.

Messaging: stability matters more than speed

Slack and Teams messages ride long-lived connections. A few dozen extra milliseconds of latency goes unnoticed, but one connection reset delays notifications and forces unread state to resync. This traffic doesn't need a dedicated line — it needs you to stop switching nodes: turn off auto-switching and latency-based auto-selection, and pin a single relay route.

File sync and code repositories: bandwidth first

Cloud drives, Git pulls, and asset uploads are heavy TCP flows: they don't care much about latency, but they'll saturate a whole route. Put them on the same route as meeting traffic and meetings will stutter. The sensible approach is split routing: send sync traffic over direct or ordinary relay routes and meeting domains over the dedicated line, so they don't compete.

Which Plan to Pick: Monthly Subscription or Data Pack

Remote work means being online every day: meetings, messages, and sync run all day, so a monthly subscription fits better. Monthly plans come in three tiers: ¥9.9, ¥18, and ¥28. If you only travel occasionally or need a few weeks, data packs are ¥158 / 300GB, ¥358 / 1000GB, and ¥658 / 3000GB — use them until they run out, they never expire, and there's no end-of-month reset to worry about. Devices are unlimited: one running meetings over the dedicated line while another syncs over relay is no problem.

Split Routing and DNS: The Two Most Common Pitfalls

Split-routing rules decide which traffic takes which route. In rule mode, traffic is matched by domain, IP range, or region: matches go to the assigned node, everything else goes to the default node. For remote work, split at least meeting domains, collaboration domains, and sync domains into three groups: meetings to the dedicated line, collaboration to a fixed relay node, sync over direct. Global mode shoves all traffic down one route and is the single most likely cause of stuttering meetings.

UDP forwarding is a hard requirement for meetings. Video calls are built on WebRTC and prefer UDP; if the client or the route doesn't support UDP forwarding, calls fall back to TCP relaying, latency and jitter get noticeably worse, and in bad cases the call won't connect at all. When choosing a route, treat UDP support as mandatory.

DNS leaks happen when domain lookups skip the tunnel and go to your local ISP's DNS instead. Two things follow: resolutions may point to a more distant entry point, raising first-packet latency, and your browsing intent is exposed to the local DNS. Meeting apps do a lot of lookups before they connect, and if this step takes the long way around, no route quality later can make up for it. Turn on remote DNS resolution in your client, or set a trusted DNS server manually.

5-Minute Test: Measure Latency, Jitter, and Packet Loss Yourself

Rather than trusting the numbers on a marketing page, measure them yourself. These steps work on Windows, macOS, and Linux — just keep them in order.

ping -c 50 target-domain      # latency / jitter estimate / packet loss
mtr -rwzbc 100 target-domain  # per-hop packet loss and jitter (use tracert on Windows)

1. Rule out local problems first: turn off the proxy, ping your router's gateway, and confirm your own Wi-Fi isn't dropping packets. If loss starts locally, no route change will fix it.
2. Read the three lines ping gives you: average latency (avg), jitter estimate (mdev), and packet loss. The larger mdev is, the more jitter.
3. Look at the path: in mtr output, focus on the hop that loses packets consistently, not one that drops the occasional packet — backbone routers rate-limit ICMP as a matter of course, and sporadic loss on a single hop doesn't mean the link is bad.
4. Check the official stats panel during a call: Zoom's Statistics and Teams' Call Health show jitter, packet loss, and actual resolution in real time. The numbers you see during a meeting are what you actually feel.
5. Test once during the day and once at peak: compare latency and packet loss on the same node. A big swing means the route runs over a badly congested public path.

• ✅ Average latency under 150 ms, jitter under 30 ms, packet loss under 1%: good enough for meetings, no need to tinker.
• ✅ Daytime and peak-hour numbers are close: the path is stable and fine for regular meetings.
• ❌ Latency looks fine but jitter tops 30 ms: change routes — tweaking client settings won't help.
• ❌ Sustained loss above 1%, or a regular drop every few seconds: classic congestion or a bad route — switch nodes.
• ❌ The client shows low latency but jitter is high in the meeting: client numbers are mostly probe latency, not real-time link quality.

FAQ