Является ли потеря пакетов в traceroute признаком регулирования скорости?

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.

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.