4

This connection has severe connectivity issues like webpage timeouts and slow transfer speeds. Its a wireless HSDPA conection which I am accessing using a USB Modem (Huawei E303c).

Executing mtr google.com gives the following output :

Traceroute output

Is the high packet loss from that IP a sign that my ISP is trying to throttle speed and prevent connectivity? Is this packet loss an error from the ISP side or is this the normal way these type of networks are implemented?

Edit 1: As this post does not reveal much about the issue, the next post is here

Edit 2: While reading up on analyzing mtr traceroutes, I found this page. It says :

When there is packet loss to one hop that doesn’t persist to subsequent hops, the loss is caused by ICMP limiting.

bluefog
  • 179
  • 2
  • 9

2 Answers2

4

No. That IP just does a lousy job of locally generating ICMP errors. The proof is that points past it respond just fine. If there was something really wrong with that point, everything past it would be bad too.

Routers are optimized for routing. Core routers let traffic pass through them in highly-optimized hardware pathways. However, when they have to locally-generate traffic, that has to be dispatched to process level. And any routing tasks that take place at process level get priority. So it's often delayed or unreliable.

It doesn't mean anything about the reliability or throughput of the path.

David Schwartz
  • 61,528
  • 7
  • 100
  • 149
  • Thanks for the contribution. So the packet loss has nothing to do with the < 10kB/s browsing speeds and poor connectivity that I am getting? What could be the issue then? – bluefog Mar 13 '15 at 09:04
  • 1
    @bluefog There's no evidence of any packet loss. What appears to be happening is that that one particular device is simply not generating a reply packet. Nothing is being lost, a reply is simply not being generated. I have no idea what accounts for your poor browsing speeds since you haven't given me sufficient information. If you want help with that, make a post with as much information as possible. (How you're measuring speeds. What your local network looks like. The history of the problem. And so on.) – David Schwartz Mar 13 '15 at 09:06
  • The next post is [here](http://superuser.com/questions/889104/high-latency-in-network-access-on-mobile-broadband). Thanks :) – bluefog Mar 13 '15 at 09:47
3

Is the high packet loss from that IP a sign that my ISP is trying to throttle speed and prevent connectivity?

It could be a sign of throttling, but from what I am seeing I doubt that is the case based on where the packet loss is happening. But if it is not intermittent and happening continually, high packet loss like that is not normal. Read on.

Is this packet loss an error from the ISP side or is this the normal way these type of networks are implemented?

The “normal way these type of networks are implemented” is the simplest explanation for what you are seeing and sharing here. Remember: The Internet was built to be resilient first, with speed taking a backseat when “damage” is encountered.

That said, a consistent 79% packet loss is far from normal. If I do a similar mtr Traceroute here in the U.S., there are really no road bumps/packet-loss “black holes” like that unless there is a clear issue.

Looking at your mtr Traceroute output, the IP you see issues with (115.255.253.17) seems to be so far past the ISP stage it could be considered part of the larger Internet. So I doubt it is ISP-based throttling. Especially since it seems that your mtr Traceroute shows that issue happening past your ISP’s .bol.net.in switches (59.180.210.201 and 59.180.210.202) which appear to be connected to the ISP Mahanagar Telephone Nigam Limited (MTNL).

Digging into the GeoIP data on 115.255.253.17 shows that it is an IP address based in Maharashtra, Mumbai. So what you could be seeing is an Internet outage/“hiccup” happening on a part of the Internet in Mumbai itself? And doing further digging via a whois lookup on the same IP address 115.255.253.17 shows it is a part of Reliance Group, which seems to be a larger infrastructure provider in India.

If you ask me, I doubt that backbone infrastructure providers would be throttling traffic from users on a specific lower-level subscriber network like this. Why should everyone on Mahanagar Telephone Nigam Limited (MTNL)’s system be punished like this by the Reliance Group backbone network? I would consider it throttling if you saw this loss around the first few hops out of your immediate switch such as those hops from the .bol.net.in switches.

From my perspective here in the U.S., I would chalk this up to normal, intermittent Internet hiccups. And the fact your mtr Traceroute completed can be attributed to the resilience of the Internet to work around those hiccups. Nothing more and nothing less… Unless this condition is not intermittent but rather consistent; if that is the case something weird is happening and there’s no easy way to diagnose it from the side of an end-user.

All that said, I just read up on the concept of net neutrality in India and it seems that there are no laws in place governing net neutrality in India, so for all you know Reliance Group is deliberately doing something. But honestly my instinct would be that someone just inadvertently misconfigured a data switch somewhere and you are the only one to notice. So I would veer towards being open minded and recommend sharing this mtr Traceroute with the tech support folks at Mahanagar Telephone Nigam Limited (MTNL) to see what they say.

9 times out of 10, mistakes on computers—and honestly many things—are not based on maliciousness but rather incompetence. I’ve seen weirder things happen with tech infrastructure here in the U.S., so it’s worth a shot to report this to your ISP and see how they respond.

Giacomo1968
  • 53,069
  • 19
  • 162
  • 212
  • 1
    Thanks for the answer. This issue is not intermittent, I have been facing it for the past 1 month, but never bothered as I have a wired line at home. Does this mean that there is a bigger problem that's going on? I too had searched the IP and it turned out to be a DIA(Direct Internet Access) used by ISPs. – bluefog Mar 13 '15 at 06:46
  • 2
    @bluefog Honestly, 79% traffic loss is not normal, but if you have been facing this for the past month it might be something else because consistent data loss on *that level* is *not normal*. I just edited my answer to recommend you contact MTNL and let them know about this. Past that, we can only guess. – Giacomo1968 Mar 13 '15 at 06:53
  • 1
    Really appreciate the research and help. :) . I too had suspected some foul play from Reliance as they are also service providers in this region. Its weird that this issue has not been noticed. I did a similar traceroute with Vodafone, and as you say, there is no loss whatsoever. – bluefog Mar 13 '15 at 06:54
  • 3
    Never suspect malice when sheer incompetence might suffice! Having had some personal experience talking to the network admins from both these ISP's I was frankly not very impressed. This could very well be the sign of someone have goofed up some critical settings. – curious_cat Mar 13 '15 at 07:09
  • 1
    @curious_cat **“Never suspect malice when sheer incompetence might suffice!”** BINGO! – Giacomo1968 Mar 13 '15 at 07:13
  • 1
    @curious_cat I couldn't agree with you more. That is exactly the situation I am in right now. The tech support here is not up to the mark. – bluefog Mar 13 '15 at 07:15
  • @JakeGould There's no reason to think it's traffic loss. All the evidence suggests that this device simply isn't generating a reply at all. – David Schwartz Mar 13 '15 at 09:08
  • @DavidSchwartz I understand and respect your POV, but I will say this… At home right now my ISP is having some downstream issues. I can get to some sites without issue, but for the ones I am having issues, two IPs in the middle of my `mtr` Traceroute show major packet loss and past that, not so much. Clear peaks/valleys. Since `mtr` pings while it traces you can get lower numbers past a bottleneck—since the `mtr` pinging/tracingprocess runs continuously—whereas with a straight `traceroute` it’s just a single static trace where the first bump very clearly slows down anything past that. – Giacomo1968 Mar 13 '15 at 18:26