This is a fairly common question that is asked so put down some thoughts
Short answer:
If you see a percentage of loss at any particular hop, that may be an indication that there is a problem with that particular router. However, it is common practice among some service providers to rate limit the ICMP traffic that MTR uses. This can give the illusion of packet loss when there is in fact no loss. To determine if the loss you’re seeing is real or due to rate limiting, take a look at the subsequent hop. If that hop shows a loss of 0.0%, then you are likely seeing ICMP rate limiting and not actual loss.
Long answer:
If you are using the Mikrotik traceroute tool, this is similar to the MTR tool.
It is important to understand when you are doing a traceroute that you are following the outbound path only. The return path may not be the same as your outbound path. Asymetric routing does not break the internet and happens far more than you think.
ICMP (ping) is sometimes blocked on routers or the remote host. Because a device does not respond to ICMP doesn’t mean it is down and no it is not more secure if you can’t ping it.
Read and understand here: http://shouldiblockicmp.com
To help fully diagnose the issue a reverse traceroute or a traceroute from the destination back to the source is required.
This is not always possible as you may not have access to the remote host. Sometimes the remote network may have a Looking Glass that you can carry out a traceroute from however it is not a very good tool to debug packetloss issues.
Linode has a great article explaining how MTR works in more detail.
https://www.linode.com/docs/guides/diagnosing-network-issues-with-mtr/#verify-packet-loss
If you have an issue with connectivity and logging it with a support desk it is recommended that you provide as much information as possible.
The network operator really wants to solve issues if there is one.
Not all helpdesk/support operators are equal and some have to or can only simply follow a process or script.
But most of the time it helps to think that you are working with the support desk as a team to solve the issue together.
The more information you can provide to the support desk the better. As my maths teacher used to say “show your workings”
Provide at least the Source IP you are testing from and the Destination IP you are attempting to reach.
Provide a traceroute or MTR from the source IP to the destination IP.
If you can provide the reverse trace even better.
If you have access to more than one destination that you can provide 2-way traces this helps even more.
The more information that is provided the more a network can narrow down the issue.