Sorry, I was in a workshop all day.
Starting with MTU stuff...
I'm assuming that the whole path (including the cool Starlink bits) at least supports a full-sized Ethernet frame. Old versions of iperf3 used to send 8K UDP packets by default, which would get chopped into Ethernet-sized fragments on the sending host. This was bad because if the network lost one of those fragments, the network might send all the other ones all the way to the end only to see them get dropped on the receiver side because it never got all the fragments. This tends to magnify the effects of packet loss. Nevertheless, that's what some UDP applications do (like NFS).
So somewhere around iperf-3.2 (2017-ish?) we changed the default UDP packet size to be derived from the path MTU, which we determined from the TCP control connection. Of course you can always change the size of UDP datagrams (
-l
flag), but SpaceX used the default.
I was worried about this at first because it looked like a Windows machine was involved (and for some reason there's a plethora of old Windows binaries floating around the Inter-tubes) but after some reflection I think the Windows terminal window was just for remote access to the phone maybe? So maybe this isn't an issue.
Endpoints can get overrun, although it doesn't usually happen at these bitrates. I've never run iperf3 on a phone though. Anyways, if I'm doing UDP tests and I see loss, one thing I'll often try is just bumping up the socket buffers (
-w
flag) just out of reflex.
Buffering in the routers (on each end of the links) is good for some applications and not others. For us, we're mostly interested in very large bulk data transfers, and there, good performance means not dropping anything. That can be bad for interactive applications because large buffers can cause delays without some kind of quality-of-service in place. (Sorry I'm dragging in a lot of other baggage.)
Sorta...I wonder if doing TCP would give a more accurate characterization of the path throughput, since it has to figure out what the bottleneck rate is.
Fun fact: We actually have a project that uses Starlink, I don't work on it though. Some of our staff have been grappling with the issue of how do we support science that isn't next to a National Laboratory and our backbone network. This often involves various wireless technologies, including Starlink:
ESnet is deploying a private cellular system and other wireless technologies to build partnerships with earth and environmental field scientists in remote locations!
lightbytes.es.net
Bruce.
PS. Speaking for myself as an individual, views not necessarily representative of my employer.