From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp69.iad3a.emailsrvr.com (smtp69.iad3a.emailsrvr.com [173.203.187.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 1FE563B29D for ; Tue, 16 Aug 2022 15:29:19 -0400 (EDT) Received: from app21.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp1.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 6EFE342D5 for ; Tue, 16 Aug 2022 15:29:18 -0400 (EDT) Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app21.wa-webapps.iad3a (Postfix) with ESMTP id 5995160054 for ; Tue, 16 Aug 2022 15:29:18 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Tue, 16 Aug 2022 15:29:18 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Tue, 16 Aug 2022 15:29:18 -0400 (EDT) From: "David P. Reed" To: starlink@lists.bufferbloat.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20220816152918000000_98300" Importance: Normal X-Priority: 3 (Normal) X-Type: html X-Client-IP: 209.6.168.128 Message-ID: <1660678158.3642765@apps.rackspace.com> X-Mailer: webmail/19.0.17-RC X-Classification-ID: 5bf12d4e-83f7-45e5-be39-651434346550-1-1 Subject: Re: [Starlink] starlink terminal mod chip X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2022 19:29:19 -0000 ------=_20220816152918000000_98300 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A =0AOn Sunday, August 14, 2022 12:00pm, starlink-request@lists.bufferblo= at.net said:=0A=0A=0A=0A> Date: Sat, 13 Aug 2022 09:41:54 -0700=0A> From: D= ave Taht =0A> To: Dave Taht via Starlink =0A> Subject: [Starlink] starlink terminal mod chip=0A> = =0A> It's been my hope that starlink would merely install cake on the=0A> u= plink themselves... but it's finally possible to get in there and do=0A> th= e work ourselves:=0A> =0A> [ https://github.com/KULeuven-COSIC/Starlink-FI = ]( https://github.com/KULeuven-COSIC/Starlink-FI )=0A =0AAs a big fan of Ca= ke (and a happy user of it), I think it's fair to say that Starlink's capac= ity sharing method does not have a stable rate, almost certainly. Has starl= ink published its link-scheduling approach? Probably it is closer to polled= (controlled by the ground station, not the terminal).=0ACake assumes that = the uplink to the public Internet is, at the link layer, stable and unvaryi= ng in its rate, so cake's control theory assumes that. The downlink assumpt= ion is similar.=0A =0ASo here's why I would NOT recommend just adding Cake = to the starlink terminal - it's the wrong link model.=0A =0ALet's assume th= ere is just one satellite that the terminal is using for its packets. The s= atellite is dealing with dozens of terminals at once. The satellite-to-grou= nd-station link is more like a standard fixed rate link, being multiplexed = among use by dozens of terminals.=0A =0AThis terminal traffic is NOT the wa= y a "home router" uses a cable modem or DSL or fiber modem.=0A =0AIf you wa= nt to get something approaching minimal latency and fair-queueing (which i= sn't "fair" because the term "fair" just means starvation free in most queu= eing theory and networking applications), you need to drop packets or send = congestion signals that are based on the *achievable rate* of the link.=0A = =0AHowever, the achievable rate of the link is being dynamically managed by= the *ground station* needing to balance traffic among all terminals genera= ting flows through the ground station end.=0A =0AMost likely this will resu= lt in Cake and the ground station getting in a "battle" to achieve good uti= lization.=0A =0AThe same issue arises if you try to use Cake in each node s= haring a WiFi LAN. The WiFi protocols (including the polled mode in 802.11a= x, but also the older 802.11 CSMA-CA Aloha style before 11ax) actively "sch= edule" the shared WLAN air link - either centrally or in a decentralized ma= nner. Putting Cake as a congestion mechanism on a shared air link is proble= matic because the competing traffic causes the available capacity to vary t= remendously, over short time intervals.=0A =0AThe 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 instabi= lity.=0A =0ANow if Starlink had some good, smart people who understand Inte= rnet congestion control and queueing theory and control theory in practice = (and some of those are participating on this list, probably easy to hire [h= int]) --- the obvious place to incorporate Cake or FQ-codel in the path fro= m terminal to public Internet would be *in the ground station* (or maybe in= the satellite, if the satellite actually controls the scheduling of access= ).=0A =0ABut before we get thrilled about reverse-engineering the Starlink = terminal, remember, Starlink's technology is quite different from a cable d= ata network or a GPON network in its packet architecture. Simple replacemen= t of its software or simple patches probably won't work.=0A =0AThat said, t= he 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, y= ou can probably sniff your traffic and mess up your use. It might be that y= ou 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, an= d it is likely gonna get you jailed for a long time.=0A =0A =0A> =0A> (grea= t blackhat talk, btw)=0A=0A=0A ------=_20220816152918000000_98300 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

 

=0A

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

=

=0A
=0A

> Date: Sat, 13 Aug 2022 09:41:54 -0700
> From: Dave= Taht <dave.taht@gmail.com>
> To: Dave Taht via Starlink <= starlink@lists.bufferbloat.net>
> Subject: [Starlink] starlink t= erminal 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

=0A

 

=0A

A= s 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 cer= tainly. Has starlink published its link-scheduling approach? Probably it is= closer to polled (controlled by the ground station, not the terminal).

= =0A

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 sim= ilar.

=0A

 

=0A

So here's why I would NOT recommend j= ust adding Cake to the starlink terminal - it's the wrong link model.

= =0A

 

=0A

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 terminal= s.

=0A

 

=0A

This terminal traffic is NOT the way a = "home router" uses a cable modem or DSL or fiber modem.

=0A

 

=0A

If you want to get something approaching minimal latency and&n= bsp; fair-queueing (which isn't "fair" because the term "fair" just means s= tarvation free in most queueing theory and networking applications), you ne= ed to drop packets or send congestion signals that are based on the *achiev= able rate* of the link.

=0A

&= nbsp;

=0A

However, the achiev= able 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.

=0A

&nbs= p;

=0A

Most likely this will = result in Cake and the ground station getting in a "battle" to achieve good= utilization.

=0A

 

= =0A

The same issue arises if you= try to use Cake in each node sharing a WiFi LAN. The WiFi protocols (inclu= ding the polled mode in 802.11ax, but also the older 802.11 CSMA-CA Aloha s= tyle before 11ax) actively "schedule" the shared WLAN air link - either cen= trally or in a decentralized manner. Putting Cake as a congestion mechanism= on a shared air link is problematic because the competing traffic causes t= he available capacity to vary tremendously, over short time intervals.

= =0A

 

=0A

The problem here is that the timescale of the = scheduling of link bandwidth is incompatible with the end-to-end TCP conges= tion control loops. This guarantees control theory instability.

=0A

 

=0A

Now if Starlink had some good, smart people who unders= tand Internet congestion control and queueing theory and control theory in = practice (and some of those are participating on this list, probably easy t= o 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).

=0A

 

=0A=

But before we get thrilled abou= t reverse-engineering the Starlink terminal, remember, Starlink's technolog= y is quite different from a cable data network or a GPON network in its pac= ket architecture. Simple replacement of its software or simple patches prob= ably won't work.

=0A

 =0A

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 a= re at all Pwned if you do that. Yeah, if its your terminal, you can probabl= y 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.

=0A

 

=0A

&nbs= p;

=0A

>
> (great= blackhat talk, btw)

=0A
=0A

 =

------=_20220816152918000000_98300--