[Starlink] starlink terminal mod chip

[David P. Reed]

On Sunday, August 14, 2022 12:00pm, starlink-request at lists.bufferbloat.net said:



> Date: Sat, 13 Aug 2022 09:41:54 -0700
> From: Dave Taht <dave.taht at gmail.com>
> To: Dave Taht via Starlink <starlink at lists.bufferbloat.net>
> Subject: [Starlink] starlink terminal mod chip
> 
> It's been my hope that starlink would merely install cake on the
> uplink themselves... but it's finally possible to get in there and do
> the work ourselves:
> 
> [ https://github.com/KULeuven-COSIC/Starlink-FI ]( https://github.com/KULeuven-COSIC/Starlink-FI )
 
As a big fan of Cake (and a happy user of it), I think it's fair to say that Starlink's capacity sharing method does not have a stable rate, almost certainly. Has starlink published its link-scheduling approach? Probably it is closer to polled (controlled by the ground station, not the terminal).
Cake assumes that the uplink to the public Internet is, at the link layer, stable and unvarying in its rate, so cake's control theory assumes that. The downlink assumption is similar.
 
So here's why I would NOT recommend just adding Cake to the starlink terminal - it's the wrong link model.
 
Let's assume there is just one satellite that the terminal is using for its packets. The satellite is dealing with dozens of terminals at once. The satellite-to-ground-station link is more like a standard fixed rate link, being multiplexed among use by dozens of terminals.
 
This terminal traffic is NOT the way a "home router" uses a cable modem or DSL or fiber modem.
 
If you want to get something approaching minimal latency and  fair-queueing (which isn't "fair" because the term "fair" just means starvation free in most queueing theory and networking applications), you need to drop packets or send congestion signals that are based on the *achievable rate* of the link.
 
However, the achievable rate of the link is being dynamically managed by the *ground station* needing to balance traffic among all terminals generating flows through the ground station end.
 
Most likely this will result in Cake and the ground station getting in a "battle" to achieve good utilization.
 
The same issue arises if you try to use Cake in each node sharing a WiFi LAN. The WiFi protocols (including the polled mode in 802.11ax, but also the older 802.11 CSMA-CA Aloha style before 11ax) actively "schedule" the shared WLAN air link - either centrally or in a decentralized manner. Putting Cake as a congestion mechanism on a shared air link is problematic because the competing traffic causes the available capacity to vary tremendously, over short time intervals.
 
The problem here is that the timescale of the scheduling of link bandwidth is incompatible with the end-to-end TCP congestion control loops. This guarantees control theory instability.
 
Now if Starlink had some good, smart people who understand Internet congestion control and queueing theory and control theory in practice (and some of those are participating on this list, probably easy to hire [hint]) --- the obvious place to incorporate Cake or FQ-codel in the path from terminal to public Internet would be *in the ground station* (or maybe in the satellite, if the satellite actually controls the scheduling of access).
 
But before we get thrilled about reverse-engineering the Starlink terminal, remember, Starlink's technology is quite different from a cable data network or a GPON network in its packet architecture. Simple replacement of its software or simple patches probably won't work.
 
That said, the talk about breaking into the terminal is quite fascinating. I do believe Starlink has real defense-in-depth, though, so it's unlikely that Starlink other users are at all Pwned if you do that. Yeah, if its your terminal, you can probably sniff your traffic and mess up your use. It might be that you can disrupt (DoS) a satellite by "jamming" its "bent-pipe channels". But that's normal, nothing out of the ordinary. They will come and get you, and it is likely gonna get you jailed for a long time.
 
 
> 
> (great blackhat talk, btw)


 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/private/starlink/attachments/20220816/f0f2b8a2/attachment.html>