Most routers do not put ping-processing in the "fast path". That is, instead of having the ping be processed by an ASIC, the ping gets processed by the router's CPU. And ping-processing is typically a lower-priority task. Because of that, you can't assume that the high variation in latency is because of Starlink.
Pretty sure that is the reason why he used
> ping across a Starlink connection from the customer side terminal to the first IP end point behind the Starlink earth station
instead of pinging the terminal itself.
(ICMP packets passing _through_ a router are handled just like any other traffic and are therefore OK for an analysis like this)
These changes are more typical of a physical path change, as suggested by the author.
CPU/soft processing latency would look more like additive noise.
I give some examples of RTT patterns in this talk: https://ripe77.ripe.net/archives/video/2250/
YMMV if you attempt the same traceroute from Bangalore or Sydney to London/Paris/NYC.
From my router in Dhaka pining a router on airtel in India, 36-38ms
Routers in the real would give very stable ping responses, no matter where they are based.
The last mile is usually the issue. Pretty much only Cogent and HE allow you to have packet loss
That’s meaningless. Control planes are often policed sure, but on overload will simply drop. In my experience they drop icmp to expired before echo response but most will generate ttl expired just fine.
Any router capable of processing a full bgp table, and to be honest any router made in the last 20 years, is perfectly capable of responding to icmp echos.
There was then a second argument that “3rd world” routers aren’t as good as ones in western country. In the majority of cases they’re exactly the same. That western arrogance is somewhere between insulting and amusing.
The final argument is about path loss/jitter/etc, specially loss on the first hop (your “my crappy 3G provider” argument)
That’s exactly what this test of starlink is showing.
Starlink is a great tool in specific cases, but the fanboyish ness often drowns out the actual benefits.
You be capping
That was a temporary situation though, and I think the worst I’ve seen in east Africa from the last 10 years.
I wonder how true that is anymore, with ICMPv6 processing being a mandatory part of IPv6. I could totally see ICMP processing being a low-priority task, but am far less certain that it would not be done by dedicated hardware these days.
On top of that, I've never, ever, ever noticed the behavior he's observing with either my cable ISP connection, or the terrestrial microwave link provided by my local WISP. I don't have enough data to say that I'd never see that behavior if I happened to ping some router powered by a potato... but I've pinged a whole bunch of systems over the years, and have never seen variation like what he describes.
Could have been traffic shaping or prioritization (their network was in complete shambles after all), but ICMP was definitely taking some lower priority queue or path.
ICMPv6 may be mandatory according to specs, but you can still drop most of it with no ill effects. You probably shouldn't drop needs fragmentation packets, but everyone has adapted to those being dropped sometimes, so...
If you ignore neighbor discovery, you'll have trouble reaching your neighbors, though.
But neighbor discovery is low volume mostly, and can be handled by the cpu, not the asic. Needs frag likely won't be directed at the router ip, the asic can forward them just fine though.
I've certainly seen much more variable ping times for routers than for the hosts behind them. If the router's cpu is less busy, ping times are usually a bit more than a host that's right there, and as the router's cpu gets more busy, the rtt increases or pings get dropped. It's not usually a factor of how busy the links are either; routers tend to have a pretty limited amount of cpu and if they're getting a lot of traffic, it's easy to overload them.
I haven't seen it happen quite in the bands like in the article, but sometimes it varies quite a bit. The results tend to be much more consistent if you can get a rtt from full host and not a router.
I believe a better technique would be to ping _through_ the router to another endpoint under ones own control, on the same network as the origin client, and where processing latency can be controlled. Basically ping yourself but via starlink and back.
That said, in practical terms he's quite right about the jitter problem. I maintain 2 networks myself at my remote home. One my microwave WISP for tight latency and jitter, and then Starlink for much better bandwidth/throughput.
> ping across a Starlink connection from the customer side terminal to the first IP end point behind the Starlink earth station