would using a proxy server improve my routing/ping?

[mxnerd]

Sometime one ISP won't work with another ISP because of pure business reasons, like one is not willing to pay the other the amount of money its asking for. Then the ISP has to use another route that might take longer path.

 

[Mushkins]

How does a traceroute even work?

It's important to understand that a traceroute is a specifically designed network test designed to give you specific information about each individual hop between point A and point B. It is not necessarily reflective of a live connection between Point A and Point B. A tracert is more or less a series of pings to each host along the path, the latency displayed for each hop is the total latency between you and that specific hop.

It's also subject to bias. If an individual hop is configured for QoS to process ICMP packets at a lower priority than "real" traffic, the latency value reported will be higher than it would be for a legitimate connection through that hop. Likewise, if it outright rejects ICMP traffic you can see timeouts and the number could be further skewed.

It's also important to understand what exactly a tracert is telling you. It's a single data point from a test at that specific point in time. Routing protocols might update five minutes after you did it and give you an entirely different route based on what the internet as a whole worked out was a "better" route based on the configuration of those protocols. A tracert is just a single diagnostic test, not a full picture of what's happening between A and B at all times.

I know plenty of people who use proxy services to drastically decrease their latency, however you insist that it will not work for me because of the amount of time (30 milliseconds) it takes to leave my ISP's network. However, when I get below 30 ping, it still takes over 30 ms to leave my ISP's network. How is this possible?

Unless they live in your house, use the same internet connection as you, and are connecting to the same servers at the same time, their results are irrelevant. I'm not saying they don't have improvement, just that it is irrelevant to *you* as every connection is completely unique.

Think of it this way. You want to drive your car from Louisville to Chicago. There's two ways to get there, you can either take the back roads which will take 3 hours or you can take the highway which will take 2 hours. Regardless of which you choose, you still need to drive out of your neighborhood first to get to the highway or get to those back roads.

However, the township is doing sewer construction on your block, and your road is all torn up. If it's right in front of your house, no matter what road you choose it's going to delay you. But if it's down the street right in front of the ramp to the highway? There's no delay if you take the back roads, but there is if you take the highway. In this case, the Township is your ISP, and the roads are their local infrastructure. There are multiple paths within the Township and not all are weighted equally.

Enter Google Maps. Google maps doesn't know squat about road construction in your neighborhood, or it was mis-reported to them. Google Maps is going to tell you to get on the highway anyway because that's the fastest way to get to Chicago. As a local resident, you know that's BS and take the back roads instead of getting stuck in the massive two hour traffic jam that construction is causing. The township (Your ISP) telling Google Maps that road is closed and to re-route local traffic around it (your ISP futzing with their own routers) can help make the trip faster, but only in regards to issues within their specific township. But if there's another delay two towns over you're still going to hit a snag and the township (Your ISP) can't do squat about it.

Now Enter a VPN tunneling/proxy Service. This is Donald Trump, who just so happens to own a private airport in both Louisville AND one in Chicago. (AKA a dedicated point to point fibre line between two datacenters the VPN company owns). You buy a ticket on his private plane that cuts out any of the potential hiccups on the roads below and is much faster than the public road system (the internet). Sounds great, but you still need to drive over the roads in your neighborhood to get to the airport in the first place, which could cause a delay.

So yes, if you're covering a large geographic distance or there's a specific and persistent issue between you and the destination, paying a VPN company to piggyback off their dedicated, alternative high speed route that cuts the pain point out of the picture can absolutely reduce latency. But if the problem is with your ISP right outside your front door, A VPN/proxy isn't going to fix that because you still need to go through the trouble spot to get to the VPN tunnel.

If that pain point was literally the line in the street in front of your house, and you were getting massive packet loss and 500ms+ latency, then absolutely you could call your ISP and have them fix the issue. But what you're describing as an issue is actually right about where the service is designed to be performing as per the technology. It's already in spec, there's no problem for your ISP to actually fix, so there's nothing to be done. If you want a lower latency service, you'd need to pay the ISP an exorbitant amount of money to run and maintain fundamentally different infrastructure to your home.

 

[azazel1024]

Excellent description Mushkins. I would add though, not all roads out of the ISP are necessarily going to be the same. The paths through the ISP to the VPN/proxy may be lower latency than other routes through the ISP's network. I just wouldn't bet on it, especially if a lot of the latency is in the first couple of hops within the ISP's network.

One of things you could always do, if it is cheap/free, just try the service. If it speeds things up, great. If it doesn't, shrug and move on. There is zero way to know if it could without trying.

I have certainly seen where some paths out of an ISPs network could be 6-8ms of latency and others can be an easy 30-40ms. I have Verizon FIOS. To my employers website which is physically hosted about 20 miles from my house, I typically have 11-13ms of latency with about 6-8ms of that being the couple of hops from my router to the edge of Verizon's network. To the local Speedtest servers located about 20-40 miles to my house, the total latency tends to be more like 18ms with about 12-13ms of that being hops to the edge of Verizon's network. It is the same number of hops, but they are different edge routers. A connection to a server in Virginia, only a little further away from one of the speedtest servers is 35ms, because the latency to that edge router is 20ms. A connection to Chicago for me runs about 32ms...lower latency because the edge router latency is about 14ms.

It just depends so heavily in the routes your ISP chooses, who they've peered with to get to the destination and so on.

PS That 35ms, is to a VPN server in Virginia (because 35ms + latency from the VPN host to final destination), so it would be slower for me to use that than it would be to connect directly to the other example server in Chicago...though a different server in Chicago could be even slower. Possibly.

 

[Gryz]

You got a good practical understanding of traceroute, but there are some slight inaccuracies.

It's important to understand that a traceroute is a specifically designed network test designed to give you specific information about each individual hop between point A and point B.

I would say that traceroute does not give you any information about individual hops. It only tells you how many hops there are, tells you one IP-address of each hop (which can be converted to a domainname via DNS), and it gives an indication of the Round Trip Time to each of those hops. The hops themselves do not give any information.

It is not necessarily reflective of a live connection between Point A and Point B.

I would say it is.
Because if it isn't a reflection of the live path, then what is it ?

A tracert is more or less a series of pings to each host along the path, the latency displayed for each hop is the total latency between you and that specific hop.

It's not really pings. Even if ICMP is involved. You can only ping a destination if you know it's IP-address. When you start a traceroute, you know nothing about the path, so you can't ping anything. Except the end-destination.
BTW, the "hops" along the path are not hosts. They are routers. The difference between a host and a router is that a router can forward packets to others, while a host only handles traffic for which it is the endpoint (source or destination).

It's also subject to bias. If an individual hop is configured for QoS to process ICMP packets at a lower priority than "real" traffic, the latency value reported will be higher than it would be for a legitimate connection through that hop.

QoS is normally not the issue here.
The issue is how a router handles traffic that goes *through* it, versus traffic that it is an endpoint of.

Traceroute sends an UDP packet, or an ICMP packet to the destination that you typed in the traceroute command. Originally it used UDP. Mac and Linux still use UDP. Windows uses ICMP. The trick of traceroute is that it used the TTL in an interesting way. TTL stands for Time To Live. Each packet has a "hopcount" in its IP-header. The sender sets it to 64 or 32. Every time a router forwards a packet, the TTL is decremented by 1. If there is a routing loop somewhere (shouldn't happen, but it can) packets will cross 32 or 64 hops, and their TTL will go to 0. If a router receives a packet with TTL=1, it will decrement to TTL=0, and drop the packet. But it will also send a warning to the original sender of that packet. That's a ICMP Destination unreachable, Time Exceeded packet.

What happens is this:
Tracerouters send a packet with TTL=1. The first router on the path will decrement TTL=0, drop it, and send an ICMP warning to back to you. You look at the source IP-address of that ICMP warning. And you now know the IP-address of the first hop. Then traceroute sends a packet towards the same destination, but with TTL=2. The first router will forward the packet, the but 2nd router on the path will decrement TTL=0. The 2nd router sends a warning, and now you know the 2nd router on the path. It keeps doing this, until you get a reply from the destination.

Now my point:
When a router forwards a packet, it does that via the "fast path". Special hardware on high end routers, or in interrupt mode on a general-purple CPU. But when there is an error (TTL=0), the packet is treated differently. It is often "punted" to the control plane of the router, where a dedicated process will handle errors and generates and sends back the ICMP warning. This might take a *lot* longer than when the hardware forwards a packet. And that is why you can't totally trust the timing values you see in traceroute.

Likewise, if it outright rejects ICMP traffic you can see timeouts and the number could be further skewed.

True. Or if a router filters certain UDP ports, and by coincedence it's the port traceroute is sending packets too. (Not on Windows, as that one uses ICMP).

But you forget to mention the biggest weakness of traceroute.
Traffic on the Internet does not always follow symmetrical paths !

In fact, in most cases the forward traffic and the backward traffic will go over different paths. This is a result of the way ISPs deal with traffic amongst themselves. (There doesn't seem to be a good webpage with explanation to why most inter-AS routing is asymetrical. If you wanna know, ask, and I'll explain).

So when you do a traceroute from A to B, you will see the path that is taken from A to B. However, the path from B to A is probably significantly different. You can not find out how it is, unless B helps you.

In gaming (and other applications), the total RTT is important. (RTT = Round Trip Time. The time to go from A to B and back to A). Traceroute shows you only *half* the truth. The path from A to B might seem fine, but the path from B to A might be congested. And your gaming will be bad. But you don't know why.

Another minor issues might be load balancing. If there are hops with 2 parallel links between them, or if there are 2 different paths to get to the destination, then traffic will be "load balanced" over those paths. To get better overall throughput. However, the path of one "flow" will not change. That means you traceroutes from A to B might go over a slightly different path than your gaming packets from A to B. I think this usually isn't an issue, but in theory it certainly can happen.

It's also important to understand what exactly a tracert is telling you. It's a single data point from a test at that specific point in time. Routing protocols might update five minutes after you did it and give you an entirely different route based on what the internet as a whole worked out was a "better" route based on the configuration of those protocols. A tracert is just a single diagnostic test, not a full picture of what's happening between A and B at all times.

True. It's just a snapshot of the situation.
If you want to know more, you need to do traceroutes at various times in the day. Maybe even during a few days.

But usually the routing won't change too much. Routing on the Internet is mostly based on policy. Because real money is involved, ISPs want to determine in great detail how traffic is exchanged between ISPs. They do this via all kinds of policy mechanisms in BGP. (BGP is the protocol used to route packets between networks (between ISPs, between ASs)). So even though traceroute is only a snapshot, that snapshot often shows the normal situation.

I'm not saying they don't have improvement, just that it is irrelevant to *you* as every connection is completely unique.

Completely correct.