I rarely see mpls lines decreasing ttls. What I do see is traceroutes which are something like 2ms 3ms 38ms 5ms 8ms 9ms (target) That 38ms showing packet loss

I rarely see mpls lines decreasing ttls. What I do see is traceroutes which are something like 2ms 3ms 38ms 5ms 8ms 9ms (target) That 38ms showing packet losss too. I suspect it's the control plane that doesn't prioritise responses. As I have no access to intermediate hops, nor even a business relationship with the owner, traceroutes, and things like bgp.he.net, help me work out where problems may be occurring and sometimes let me reroute. Even on private wires it's hard to explain to network providers what an outage means. Sometimes a 10ms outage can be the difference between your application working and failing. Had a mikrotik at one event this year that I think was bouncing the queuing process from core to core. Looking at the rtp before and after showed it often throwing 30 packets out of order - about 15ms. Occasionally it would simply drop them, and that causes a major problem with broadcast video as normal FEC can cope with 20 losses on the trot at most. Had to change ISP in kiev a couple of years ago because of a frequent 136ms drop. I'd isolated it to the next upstream provider from our existing isp, but nothing more could be done as it seemed that was their only real transit provider, and 130ms doesn't really stop Facebook from working.