Here's an example to try to illustrate it:
Code:
Tracing route to 199.91.189.74 over a maximum of 30 hops
<initial hops removed for security>
4 22 ms 24 ms 24 ms xe-7-0-0.chrlncpop-rtr1.southeast.rr.com [24.93.64.42]
5 29 ms 26 ms 36 ms bu-ether34.atlngamq46w-bcr00.tbone.rr.com [107.14.19.48]
6 28 ms 29 ms 29 ms ae-0-0.pr0.atl20.tbone.rr.com [66.109.6.171]
7 90 ms 78 ms 77 ms te0-0-0-10.ccr21.atl02.atlas.cogentco.com [154.54.12.109]
8 79 ms 79 ms 80 ms be2052.mpd21.atl01.atlas.cogentco.com [154.54.40.249]
9 90 ms 89 ms 89 ms be2168.ccr21.dca01.atlas.cogentco.com [154.54.31.94]
10 97 ms 95 ms * be2150.mpd21.jfk02.atlas.cogentco.com [154.54.31.130]
11 * 112 ms 111 ms be2106.ccr21.ymq02.atlas.cogentco.com [154.54.3.50]
12 70 ms 62 ms 68 ms 38.122.42.34
13 55 ms 51 ms 50 ms 10.2.2.1
14 48 ms 51 ms 50 ms 192.34.76.2
15 49 ms 51 ms 49 ms 199.91.189.234
16 49 ms 54 ms 48 ms 199.91.189.74
Trace complete.
Notice what is happening at hops 10 and 11. That is an intermittent timeout at those hops. This is happening because they are highly congested and traffic shaping rules are causing certain traffic to be assigned a lower priority, which potentially delays delivery and sometimes causes them to get discarded and retransmitted (this often referred to as throttling, mistakenly assumed to be P2P throttling, but it happens to all kinds of traffic during times of high congestion). This is something that needs to be addressed amongst the service providers--your ISP and the people they have partnered with to carry their traffic when it must go outside of their own segments. The trick is getting them to acknowledge the problem exists and getting them to commit to investigating it further (why submitting a tracert showing potential problems can help your cause).