said by bluepoint:Wrong, a technically knowledgeable person will look at every hop, any congestion at each route will affect the latency. And that's why traceroute helps technical people to find router problems if any.
A traceroute directs UDP or ICMP at EACH HOP separately, and gets an ICMP response from EACH HOP separately. Each measurement of latency is for the time which that individual hop responded to the UDP or ICMP from the traceroute.
If I am getting low latency from the last hop, then that is all that matters.
Latency at any particular hop that doesn't continue is latency to the CPU of that particular router hop. Modern day service provider routers have the management plane separated from the forwarding plane. A router responds to traceroutes from its management plane. If that management plane is busy, it will delay the ICMP response to the traceroute. All of the other traceroute packets pass through the router's forwarding plane, which is controlled by ASICs or other dedicated CPUs within the linecards of the router and are designed to forward packets quickly.
Maybe now you'll understand why high latency from a specific hop does not affect the entire round trip if the same latency is not being added to each hop thereafter.
Latency caused by congestion would show up at every hop in the traceroute, because the forwarding plane (the linecards) have the actual ports that would be congested. Adding the congestion latency to each traceroute packet that is being sent to each subsequent packet after the congested port.
This traceroute shows no signs of congestion latency.
