i guess what i'm saying is that you can't read much from the backscatter of what a either: - ping of each hop - eliciting a response from each hop (as traceroute does) as the basis for determining much.
you can perhaps derive SOME meaning from it, but that meaning rapidly diminishes when there are multiple intermediate networks involved, some of which you have no direct connectivity to verify problems with easily, likely different return path for traffic (asymmetric routing) etc.
When the cards consistently fall in certain patterns, you can actually read them quite easily.
The standard control plane arguments dont apply when the pattern holds all the way through to equipment under your {remote-}control.
it most certainly does. lets use an example network of: F | A---B---C---D---E | G you are looking at ICMP/traceroute responses through sending traffic to/from A & E. for all you know, there may be an ICMP DDoS attack going on from F-C or from G-C. the router 'C' is perfectly entitled to rate-limit the # of icmp responses it sends per second, and due to said traffic from F & G may be doing so. this would render your reading of the tea leaves of what A and E are seeing of C. this diagram is incredibly simplistic. for the "greater internet", we could add perhaps 50x connections at each of B, C & D, not to mention the path you posted showed upwards of a dozen hops - so more realistically there could be 4 or 5 order of magnitude more devices causing traffic in the path.
In this specific instance, I find interesting the disparity of results between each hop ICMP echo and traceroute time exceeded processing, all the way up to the final hop.
I wouldnt care if the application protocols rode well, but they dont seem to.
while you can paint a partial picture from elicited icmp responses, it certainly doesn't give you the full canvas. you've only tested traffic from A to E. what about A to F where those are ENDPOINTS and not ROUTERS? e.g. try a long-lived HTTP/FTP stream & see what you get. cheers, lincoln.