The biggest thing we need is something that can pull the right stats off the dishy and dynamically adjust cake (on outbound at least) to have the right amount of buffering for the available bandwidth, so as to make for better statistical multiplexing (FQ) and active queue management (AQM)
It’s pretty simple: in mangled shell script syntax:
while up, down = getstats()
do
tc qdisc change dev eth0 root cake bandwidth $up
tc qdisc change dev ifb0 root cake bandwidth $down
done
Which any router directly in front of the dishy can do (which is what we’ve been doing)
But whatever magic “getstats()” would need to do is unclear from the stats we get out of it, and a better alternative would be for the dishy itself and their headends to be doing this with “BQL" backpressure.
As for the huge reductions of latency and jitter under working load, and a vast improvement in QoE - for what we’ve been able to achieve thus far, see appendix A here:
We’ve got plenty more data
on uploads and downloads and other forms of traffic (starlink is optimizing for ping, only, over ipv6. Sigh)…
… and a meeting with some starlink execs at 11AM today.
I’m pretty sure at this point we will be able to make a massive improvement in starlink’s network design very quickly, after that meeting.