The post is indeed familiar.
There is no queuing mechanism that can manage the dozens or hundreds of connections a torrent client makes inbound. Anyone claiming inbound shaping is robust in those conditions is simply wrong. You have to set the bandwidth way low to mitigate microbursts as flows can and will saturate your connection before your router dropping packets, which is all it can do over UTP however pretty the queuing is, makes an impact.
The hops between your router and 18.104.22.168 are irrelevant. If you aren't experiencing any notable issues all is fine.
Not downloading potentially interesting content via dozens or hundreds of individual connections that may be unresponsive to congestion control seems a good idea as far as ways to stop it to.
Your Zoom call is one stream. You may have 250 peers on a torrent. How does your bandwidth look split 251 ways?
The intermediate hops may spike because they have better things to do than answer your traceroute. Routers have a forwarding plane which moves your traffic around to its destination and a control plane which deals with things like pings and traceroutes. On the carrier grade kit BT Wholesale use those are entirely uncoupled from each other. The forwarding plane uses ASICs and is super fast, the control plane at least in part uses commodity hardware and has way better things to do with its time than issue you an ICMP TTL Expired so may be late in responding.
If you must torrent may I recommend a QoS policy that recognises HTTPS traffic and guarantees it 50%+ of the capacity and drops everything else? That will hopefully mitigate microbursts.
Incidentally microbursts - your first hop, the BT BRAS, doesn't care what order it delivers packets to you in, and if torrent traffic is overwhelming your capacity before the QoS you and they have in place kicks in some traffic will be delayed.
Openreach don't care what they're sending you and don't do any kind of WFQ to let smaller packets through in between gaps. BTW don't either. First in, first out.
Either the QoS policy I mentioned above whitelisting known real-time traffic and heavily shaping else so that the TCP flows can't ramp up and UTP congestion control kicks in early or stop the torrents.
Ignore the routers on the way to the end destination. They may respond late if at all as they're there to route not to respond to your trace and have better things to do. They also have rate limits set on how often they'll respond to such things to avoid DoS conditions. The line cards in BRAS, your 172 hop, are usually pretty smart, deeper into the network the intelligence drops alongside the care for your traceroutes.
Regarding the jump in latency between a couple of the hops light takes time to travel so unless you discover superluminal transmission speeds there's about an 8 ms round trip to Yorkshire in the middle of the UK going up to 20 ms or so in the Highlands to London. Light doesn't get close to full speed on regular fibre, more like 2/3rds, and even at 200,000 km a second takes a little while to get from Scotland to London and back. At 200,000 km/s, a 500 km fibre run, remember these DM aren't straight lines and usually follow major roads, you're talking a 1000 km round trip, or 5 ms @ 200,000 km/s.
That's your increase as you go along the BT network: the speed of light.
PS Congratulations on bringing me back to this forum to answer this. I thought it should have been answered either here or the other place a while back and got bored reading it so thought I'd close it off.
Torrents are worst case scenario for inbound shaping, inbound shaping isn't great anyway, intermediate router latency is unreliable: monitor the end host via ping not traceroute.
Building better networks, not just faster ones.
Edited by CarlTSpeak (Tue 15-Dec-20 01:12:49)