An IEPL label alone cannot tell you how fast a connection will feel. It describes a kind of private international network link, not a guarantee about every segment between your device and an online service. The result still depends on your local network, the provider’s handoff points, routing decisions, congestion, and the destination. This guide compares direct, transit, IEPL, and BGP routes, explains which metrics matter for gaming and video, and gives you a repeatable way to test before choosing a line.
What IEPL means—and what it does not
IEPL usually stands for International Ethernet Private Line. In general, the term refers to a private Ethernet service connecting network locations across borders. A service provider may use such a link between its points of presence, or PoPs, to carry traffic between regions. Compared with sending traffic entirely over the public internet, a private segment can offer more controlled transport and a more predictable network path between those locations.
That description does not mean that every connection using an IEPL-labelled route travels over one uninterrupted private circuit from your device to the website or game server. Your traffic first crosses your home or mobile network. It may then pass through an access provider, a local proxy or VPN entry, one or more intermediate networks, and finally the destination’s network. A private link may cover only part of that chain. The provider’s exact design, capacity planning, routing, and handoffs all affect the experience.
It is also important to distinguish IEPL from BGP. IEPL describes a type of network transport or service. BGP, the Border Gateway Protocol, is used to exchange reachability information between autonomous systems and to apply routing policies. A network can use BGP to choose how traffic enters or leaves an IEPL-connected PoP. The two terms are therefore not mutually exclusive options: a route may include a private link and still involve BGP-based decisions at its edges.
4
Route descriptions compared
5
Useful test dimensions
The word “dedicated” also needs context. It can refer to a reserved service or capacity between network locations, but it does not by itself tell you whether bandwidth is reserved end to end, how capacity is shared at other segments, or how congestion is managed. Ask what portion of the route is private, where it begins and ends, and what happens when traffic enters the public internet. If a provider cannot describe those boundaries, treat the label as a clue to investigate rather than as a performance result.
Direct, transit, IEPL, and BGP compared
Route labels are often used loosely in service descriptions, so compare the likely network path rather than assuming that each term names a complete, standardized product. In particular, “direct” may mean a path with fewer intermediate providers, a direct connection to a destination network, or simply the provider’s name for a route. Ask for the provider’s meaning before comparing it with transit or IEPL.
| Description | What it generally refers to | Potential benefit | What to verify |
|---|---|---|---|
| Direct | A path described as having a direct handoff or fewer intermediaries; the exact meaning varies by provider | Fewer network transitions may simplify troubleshooting or avoid a less suitable transit path | Where the direct handoff occurs, which destinations it covers, and whether the term means direct peering or something else |
| Transit | Traffic carried through one or more upstream networks that provide reachability to other networks | Broad reachability and access to destinations beyond a provider’s own network | Upstream networks, route changes, congestion patterns, and performance to your specific destination |
| IEPL | A private Ethernet link between network locations, often used for an international segment | More control over the segment covered by the private service | Link endpoints, capacity arrangements, public-internet handoffs, and the route after the far-end PoP |
| BGP-routed | A path selected through inter-network routing and policy using BGP; not a specific physical link type | Can support multiple routes and policy choices for reaching networks | Which network announces the route, how policy affects path selection, and whether return traffic takes a different path |
These descriptions can overlap. A provider may use an IEPL segment and then exchange traffic with another network through transit or peering. BGP may influence the route at one or more network boundaries. A path described as direct may still include several networks, depending on what “direct” means in that provider’s terminology. The useful comparison is the complete path relevant to your destination, not a one-word category.
Nor does a shorter-looking route necessarily perform better. Network distance, traffic engineering, congestion, packet handling, and the quality of each handoff matter. A route with fewer visible hops can still have higher latency or loss than one with more hops. Traceroute can help identify changes in the path, but some routers do not respond to probes, and displayed hop times do not always represent the forwarding performance of ordinary traffic.
The metrics that shape gaming, calls, and video
For interactive applications, round-trip latency is the time taken for a packet to reach a destination and for a response to return. Lower latency can make controls, conversations, and remote sessions feel more responsive, but the measurement only makes sense when you know the destination and test conditions. A result to a nearby test server cannot predict the path to a particular game region or video platform.
Jitter describes variation in latency over time. A connection with a reasonable average can still feel uneven if response times fluctuate substantially. Voice and live video applications use buffering and timing strategies to manage variation, but those strategies cannot compensate for every unstable path. Packet loss matters as well: missing packets may be retransmitted by some protocols, adding delay, while real-time applications may conceal loss with reduced quality or brief artifacts.
Throughput is the amount of data transferred over a period. Download capacity affects large downloads and video delivery; upload capacity matters for cloud backups, video calls, and sending files. A short speed-test peak is not the same as sustainable throughput. The result can also change with the test server, the number of simultaneous connections, the device, and other traffic sharing the local network.
Finally, consider latency under load. A route may respond quickly while idle but become less responsive when a download or upload fills a bottleneck. This is often relevant to households where one person streams or uploads while another plays a game or joins a call. If your application becomes sluggish only during transfers, compare idle latency with latency while the transfer is active instead of judging the route from a single unloaded test.
| Metric | What it can indicate | Most relevant to | Testing caution |
|---|---|---|---|
| Round-trip latency | How quickly a response returns from a specified destination | Gaming, calls, remote desktops, interactive browsing | Compare the same destination and protocol; do not equate a nearby test server with your target |
| Jitter | How much latency varies during a test period | Voice, live video, and time-sensitive interaction | An average alone may hide brief but disruptive variation |
| Packet loss | Whether test packets fail to reach the destination and return | Diagnosing interruptions, retransmissions, or choppy media | Some networks deprioritize diagnostic probes, so confirm with the application as well |
| Download and upload throughput | Data transfer capacity under the test conditions | Streaming, downloads, backups, and uploads | Record both directions and note the server and test configuration |
| Latency under load | How responsiveness changes while the connection is transferring data | Shared connections, calls during downloads, and gaming during uploads | Use a consistent transfer workload; background activity can affect the result |
Video playback is not determined by route latency alone. It depends on sustained throughput, the content delivery network selected by the platform, the device, and the player’s buffer. A route that gives a strong result to one test server may take a different path to a platform’s media server. For gaming, the selected game region and server are similarly important. Test the actual app or destination whenever possible, and separate a routing issue from an app-side or server-side problem.
Run a repeatable route test before choosing
Make the comparison controlled enough that the route is the main variable. Write down what you are testing, and change one setting at a time. Switching the route, client mode, test server, Wi-Fi band, and device together may produce a different result, but it will not show which change caused it.
- Choose the target first. Identify the game region, video service, work server, or other destination that matters to you. Use a test endpoint in the same region only as a supplementary comparison, not as a substitute for the actual destination.
- Keep the device and access network consistent. Use the same computer or phone and the same Wi-Fi or wired connection for each route. Pause large background transfers and note whether other people are using the network. If you also want to assess performance during busy household use, run that as a separate, clearly labelled test.
- Confirm the client’s routing behavior. Import or select one route in your compatible client, then verify which traffic is sent through it. Rule-based clients can send different apps or destinations along different paths; system proxy mode and TUN mode can also cover traffic differently. Do not assume that selecting a node automatically sends every application through it.
- Measure more than one thing. Record latency, jitter or variation, packet loss where the tool can measure it, and both download and upload throughput. Then try the real application. A speed-test score and an application check answer different questions.
- Repeat under comparable conditions. Test each route more than once and compare like with like: the same device, destination, test method, and approximate network conditions. Note the time and any interruptions. If results differ sharply, repeat before attributing the difference to the route.
- Check the path when results are surprising. Traceroute or the platform’s connection diagnostics may show where paths diverge, but intermediate routers can filter or deprioritize probes. Treat such output as evidence to investigate, not as a complete view of the data path.
When testing with a subscription-based proxy or VPN service, avoid running two clients that both attempt to control system routing at the same time. Close or disconnect the previous client before testing another. If a route appears connected but the application still uses the local network, check the client’s rules, DNS settings, proxy mode, and operating-system permissions. A successful connection indicator does not by itself prove that the intended application traffic is following that route.
If you need help importing a subscription or checking the basic client workflow, see the quick-start guide. Client interfaces differ, so use the instructions for your operating system and compatible client rather than copying settings intended for a different application.
- ✅ Compare the same destination across routes, not just automatically selected test servers.
- ✅ Record latency, variation, loss, and throughput separately so one strong score does not conceal another weakness.
- ✅ Test the application you care about after checking general network metrics.
- ❌ Do not treat a traceroute hop count as a direct ranking of route quality.
- ❌ Do not change several client and network settings at once and assume the route caused the outcome.
Choose for your use case, not the route label
For gaming, prioritize the correct game region, stable latency, low variation, and the absence of persistent packet loss. A route that reaches a nearby speed-test server quickly may still perform poorly to the game’s chosen server. Check the in-game region and connection information where available, then compare routes using the same session conditions. If performance changes during a match, consider server load and local Wi-Fi interference as well as the international path.
For video, focus on sustained throughput to the platform’s content servers and whether playback remains consistent during ordinary use. A private segment may be helpful when the public path to a region is congested or unpredictable, but the platform may select different delivery servers over time. Confirm playback in the actual app and quality setting you use. Do not infer video performance from a single generic download test.
For calls and remote work, consistency can matter more than a brief throughput peak. Check upload capacity, latency variation, and behavior while other traffic is active. A route that performs well while idle but becomes unresponsive during a file transfer may not fit a shared connection. For large downloads or backups, compare sustained transfer behavior and remember that the remote server may impose its own limits.
When comparing providers, ask clear questions: what locations does the private link connect, where does traffic enter and exit it, what network carries traffic after the exit point, and how are route problems reported? Ask whether “dedicated” refers to a private path, a capacity arrangement, or a product category. Then verify the answer with repeatable tests to your own destinations. If the provider only supplies a route name, you still need real-world evidence from the applications you plan to use.