On Sunday, August 14, 2022 12:00pm, [email protected] said:



> Date: Sat, 13 Aug 2022 09:41:54 -0700
> From: Dave Taht <[email protected]>
> To: Dave Taht via Starlink <[email protected]>
> 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)


 
_______________________________________________
Starlink mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/starlink

Reply via email to