Speed of downloading images on these forums

Started by Tangled-Universe, October 11, 2018, 09:56:01 AM

Previous topic - Next topic

WAS

#15
Quote from: Tangled-Universe on October 14, 2018, 06:20:30 AM
Thanks Oshyan for clarifying and suggesting to ping/tracert.

I performed a ping once and a tracert twice and especially the tracert is interesting.
Something's off at hop 6.
Perhaps I should ask my ISP (Ziggo, do you also use that Ulco?).

I also timeout on hop 6 haha

Mind you, your ISP may not be able to help, as this is long outside the realm of your ISP, and part of another ISP/Server. In rare cases your network may be partially down, which could prevent DNS handshakes with certain servers in certain regions. Similar to when a domain is migrating to a new host, as the DNS go online, it has access to more of the net. The same thing could be happening at hop 6, it's network is having issues.

I do notice though, it seems once you hit that second Atlas server, the rest of the hops are all pretty slow up to 20 hops.

Tangled-Universe

Hop 6 is before Amsterdam, which is our exchange connecting to the USA through Atlas.
So I think something is going on in my country before the connection gets overseas.
That yours is bogging down at hop 6 is coincidence I'd guess.

WAS

#17
Quote from: Tangled-Universe on October 14, 2018, 04:28:10 PM
Hop 6 is before Amsterdam, which is our exchange connecting to the USA through Atlas.
So I think something is going on in my country before the connection gets overseas.
That yours is bogging down at hop 6 is coincidence I'd guess.

Of course, hence the laughing.

I'll also note you're piping through aorta.net which is known for their network troubles. That first hop could just be a dead aorta server which is... frequent. I actually once had to move a friends server to my data-center because of his global reach problem.

Oshyan

I should note that not all servers in a tracert will necessarily respond to this request. I see request timeouts all the time. Heck, try cnn.com, I get a timeout on hop 8, but their server itself responds just fine and the site loads, of course.

Also, no 150ms is not terrible for overseas to US. Not great either. But it shouldn't be causing really long site load times.

- Oshyan

WAS

#19
Quote from: Oshyan on October 14, 2018, 06:35:05 PM
I should note that not all servers in a tracert will necessarily respond to this request. I see request timeouts all the time. Heck, try cnn.com, I get a timeout on hop 8, but their server itself responds just fine and the site loads, of course.

Also, no 150ms is not terrible for overseas to US. Not great either. But it shouldn't be causing really long site load times.

- Oshyan

They should. The only reason they didn't, is they are overloaded via traffic, the packet was sent to the control brain (as apposed to data) and thus dropped because it's flagged priority (to not interfere with hardware). In that case, that hop in a traffic forwarding scenario can drop, or hang, and possibly timeout.

A firewall issue where the server just doesn't respond to this would cause the Tracert to end, and it would not note the trace being complete but aborted. Subsequently though a completely dead server (not just dead network wise during that tracert) would also case an aborted tracert.

However because it's complete, the packet was sent, and went through, the servers router was just having issues. These packets are sent three times consecutively. So if all three fail, but the rout is complete, it's definitely a routing issue, rather than a dead route.

This is also why high priority data centers use an actual server as a "Core" router, and often allow these low priority packets, that way if it's sent to via the control plane route, it is handled for debugging purposes. Such as gaming nodes. Physical routers have virtually no computing power and should drop these packets when it's under load.

It's very probable that hop is hanging, and causing the slowdown when actually processing taffic data. I get straight timeout pages a lot on here, but it's not a speed issue, just network routing. I'm also not sure using CNN and high-traffic routes are good comparisons. It's likely you'd see dropped packets considering consecutive traffic to that destination.

Oshyan

Your understanding differs from mine. Tracert is basically pinging all servers from you to a destination server and requesting a response. If a server is configured to not respond to ping (ICMP) requests, it will time out. Many servers are configured this way for security or other reasons and will thus result in a timeout. ICMP is also generally a low priority request so yes, congestion may also result in a timeout. I've seen one or two timeouts in many tracerts I've run over the years, it seldom indicated an issue, and often persisted over many routes to the same end point. It almost certainly indicated a server that was configured not to respond for whatever reason.

From Microsoft themselves:
Quote
Request Timed Out
This message indicates that no Echo Reply messages were received within the default time of 1 second. This can be due to many different causes; the most common include network congestion, failure of the ARP request, packet filtering, routing error, or a silent discard.
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc940095(v=technet.10)

Additionally, from ServerFault:
Quote
Routers can be configured to not respond with an ICMP message that traceroute depends on. Also, MPLS can do that because it is not routing, it is label switching.

When a router needs to create an ICMP message to send back to the source host, that is a low priority task that it may no get around to in time. Also, some router administrators don't want their busy routers to even need to spend cycles doing that, so they disable it altogether. It could also be that network administrators don't want to give away that information.

So a timeout on a *single* host may not mean anything at all.

Quote
There is only one real instance when a timeout on a traceroute is a bad thing. That is when you see timeouts that continue forward in the route. By that I mean when you see an individual timeout and then many more after that. There are two main instances when this can happen, the first and most common is that there is a firewall that was configured to block these packets in the route. The other instance is that a router is dropping packets going THROUGH it (i.e. Forwarding Plane(arms) packets) and this is can be a VERY bad sign. This is usually caused by one of three reasons either the router is overloaded, the router having a software or physical failure or the router is configured to do this(null route/blackholes).
https://www.hostdime.com/resources/trace-routes-timeouts/

- Oshyan

WAS

#21
Quote from: Oshyan on October 14, 2018, 11:45:25 PM
Your understanding differs from mine. Tracert is basically pinging all servers from you to a destination server and requesting a response. If a server is configured to not respond to ping (ICMP) requests, it will time out. Many servers are configured this way for security or other reasons and will thus result in a timeout. ICMP is also generally a low priority request so yes, congestion may also result in a timeout. I've seen one or two timeouts in many tracerts I've run over the years, it seldom indicated an issue, and often persisted over many routes to the same end point. It almost certainly indicated a server that was configured not to respond for whatever reason.

From Microsoft themselves:
Quote
Request Timed Out
This message indicates that no Echo Reply messages were received within the default time of 1 second. This can be due to many different causes; the most common include network congestion, failure of the ARP request, packet filtering, routing error, or a silent discard.
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc940095(v=technet.10)

Additionally, from ServerFault:
Quote
Routers can be configured to not respond with an ICMP message that traceroute depends on. Also, MPLS can do that because it is not routing, it is label switching.

When a router needs to create an ICMP message to send back to the source host, that is a low priority task that it may no get around to in time. Also, some router administrators don't want their busy routers to even need to spend cycles doing that, so they disable it altogether. It could also be that network administrators don't want to give away that information.

So a timeout on a *single* host may not mean anything at all.

Quote
There is only one real instance when a timeout on a traceroute is a bad thing. That is when you see timeouts that continue forward in the route. By that I mean when you see an individual timeout and then many more after that. There are two main instances when this can happen, the first and most common is that there is a firewall that was configured to block these packets in the route. The other instance is that a router is dropping packets going THROUGH it (i.e. Forwarding Plane(arms) packets) and this is can be a VERY bad sign. This is usually caused by one of three reasons either the router is overloaded, the router having a software or physical failure or the router is configured to do this(null route/blackholes).
https://www.hostdime.com/resources/trace-routes-timeouts/

- Oshyan

What you're failing to understand is if the router doesn't handle ICMP requests, the entire tracert command aborts, so it would end  there, and you'd know there is a firewall block/routing loop/misconfiguration at that router. "Traceroute proceeds unless all (three) sent packets are lost more than twice, then the connection is lost and the route cannot be evaluated" Wikipedia. If the three pings are lost, it tries again, if those three requests fail, it aborts.

It can't get to the next host if it's been blocked, which is why the command aborts..

For example, if I do not use my VPN, and use MetroPCS, tracert will be blocked by the first route, and abort, as my ISP doesn't allow ICMP requests.

Most servers in the commercial world don't block ICMP requests or even UDP or TCP requests of the echo nature, because of debugging concerns of networks and global reach.

And it's simply by about 1000 fold, that the router is just ignoring the request and passing it through (control path) rather than replying, because it's busy. When it hits the control path on a physical router it will almost 100% of the time be dropped unless it's idle. In fact without custom roms I don't think you can even change this low priority behavior unless using a actual server as a core firewall for the data center / network. This is because the CPU of a router is designed specifically for it's data path usage and has hardly any control path power.

Oshyan

#22
We're still reading and understanding this stuff differently, it seems (including Wikipedia). A server can be configured to forward the packet but not send an ICMP response to a ping request on timeout. If a hop fails, it does *not* kill the sequence inherently (that's obvious because, uh, look at Martin's screenshot, there are servers that follow it). Rather, the tracert function sends another request with an incremented TTL and the server that didn't send back a response to ping may *still* forward that request to the *next* server.

Your update to the reply above basically agrees now with what I'm saying:

QuoteWhen it hits the control path on a physical router it will almost 100% of the time be dropped unless it's idle. In fact without custom roms I don't think you can even change this low priority behavior unless using a actual server as a core firewall for the data center / network. This is because the CPU of a router is designed specifically for it's data path usage and has hardly any control path power.

That right there says that a timeout is *not* necessarily indicative of any problem - of a part of the route that is "not working right or unusually slow" - because most routers are not going to be idle.

- Oshyan

WAS

#23
Quote from: Oshyan on October 15, 2018, 12:19:45 AM
We're still reading and understanding this stuff differently, it seems (including Wikipedia). A server can be configured to forward the packet but not send an ICMP response to a ping request on timeout. If a hop fails, it does *not* kill the sequence inherently (that's obvious because, uh, look at Martin's screenshot, there are servers that follow it). Rather, the tracert function sends another request with an incremented TTL and the server that didn't send back a response to ping may *still* forward that request to the *next* server.

Your update to the reply above basically agrees now with what I'm saying:

QuoteWhen it hits the control path on a physical router it will almost 100% of the time be dropped unless it's idle. In fact without custom roms I don't think you can even change this low priority behavior unless using a actual server as a core firewall for the data center / network. This is because the CPU of a router is designed specifically for it's data path usage and has hardly any control path power.

That right there says that a timeout is *not* necessarily indicative of any problem - of a part of the route that is "not working right or unusually slow" - because most routers are not going to be idle.

- Oshyan

The timeout is because their is no response, not because the request has been altogether blocked. The request continued on it's path. That's why the wikipedia specifies a second attempt if all three timeout and it can't continue on it's route (which you can see in your network activity). If it continues on it's route, there is no need to try again, and just list the timeouts, as it got no reply.

A firewall will either accept or not accept these packages. If it doesn't accept them, the route is blocked at that point. I'm not aware of any "Deny but Reply" flag. It's based on a 0/1 flag. You can reroute the request somewhere else that would reply. But none of that helps diagnose network issues and isn't a standard thing to do in the least. An example of this is my old host datashack, you could not ICMP the data-center, but they would pass-through to a specific server if that was the destination.

A router also can handle tons (like enough to handle networks like Facebook and such) of data paths, so if it's getting to the control path, inherently, it's blogged down, Oshyan. If requests are constantly hitting the control path and relying on priority, there is most certainly a network issue and the router is overloaded.

Additionally, here is a couple more tracerts to planetside and you can see hop 6 (with networklayer) I get a timeout, but not always, but than again, I get timeouts visiting planetside occasionally for no reason almost immediately, and that server could be the reason unless planetside is going down occasionally briefly, but likely, like most the time, it's a network thing.

Dune

132ms and a timeout at hop 7....  ???