From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp112.iad3a.emailsrvr.com (smtp112.iad3a.emailsrvr.com [173.203.187.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 90AF63CB37 for ; Tue, 30 Aug 2022 20:30:09 -0400 (EDT) Received: from app27.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp31.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 200F42237D for ; Tue, 30 Aug 2022 20:30:09 -0400 (EDT) Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app27.wa-webapps.iad3a (Postfix) with ESMTP id F2D1021A00 for ; Tue, 30 Aug 2022 20:30:08 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Tue, 30 Aug 2022 20:30:08 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Tue, 30 Aug 2022 20:30:08 -0400 (EDT) From: "David P. Reed" To: starlink@lists.bufferbloat.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20220830203008000000_41042" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: X-Client-IP: 209.6.168.128 Message-ID: <1661905808.989521682@apps.rackspace.com> X-Mailer: webmail/19.0.18-RC X-Classification-ID: 50079745-ca9e-4ab7-a84a-3b5c3f1decdc-1-1 Subject: Re: [Starlink] gorgeous work on LEO beam spreading 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: Wed, 31 Aug 2022 00:30:09 -0000 ------=_20220830203008000000_41042 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AHi Sascha -=0AOn Tuesday, August 30, 2022 6:39pm, starlink-request@lists= .bufferbloat.net said:=0A> Date: Tue, 30 Aug 2022 08:37:24 -0400=0A=0A> Fro= m: Sascha Meinrath =0A> To: Dave Taht , Dave Taht via Starlink=0A> =0A> Subje= ct: =0A> =0A> I'd be curious how accurate these simulations are -- even wit= hin something as=0A> simple as LAN Wi-Fi, the "simulations" often are wildl= y/hyperbolically=0A> over-stated. I could imagine that even a few over-rosy= assumptions would=0A> exponentially metastasize optimism within the satell= ite context.=0A =0AVery good point. They don't seem to be based on very tho= ughtful assumptions about the PHY level.=0ARemember, each satellite has 4 = phased array antenna that can each "focus" in one direction. That's a prett= y severe limit. Those antennas can either transmit or receive. They can't d= o both at the same time. Multiple dishys probably will need to share the ca= pacity of those 4 antennas on the uplink from dishy to satellite. They also= share the capacity on the downlink (because the beaming tracks individual = dishys.=0A =0AHow are they "time shared"? Well you have two problems here -= one is that you constantly drop dishys and pick up new ones as the satelli= te moves, so the "time division schedule" of each antenna has to be dynamic= , especially as density of active dishys varies (and inactive ones might be= come active any millisecond or less - new packets being sent).=0ANow it tak= es at least 4 milliseconds for the a new uplink slot to be acquired. That's= the dishy->sat->dishy round trip at the speed of light. Multiple dishys pe= r satellite antenna means that the uplink, and downlink traffic rates depen= d on how predictable the traffic is.=0A =0AInternet traffic (unlike classic= voice or video which can be seen as a constant bit rate channel with long = silence periods) is bursty at all timescales. It's fractally bursty, as stu= dies have shown.=0A =0ANothing of this sort is even modeled in this work.= =0A =0ANow I first started working with 2 way satellite technology back in = the Iridium days, and also with 2-way geosynchronous satellites that used R= F transponders that just translated the frequency of the uplink to the down= link frequency and vice versa. (Tachyon was the company, I was working on s= ome technology for Nicholas Negroponte's 2B1 project that decided on Tachyo= n and not Iridium for all kinds of reasons).=0A =0AThe big problem in a mul= tiplexed two way system (even at LEO) is that the satellite uplink traffic = from one of the many terminals had to share one or a few channels (frequenc= ies) and they can't hear each other. So Internet traffic has to be held unt= il it can get a free time slot, or else the frequencies have to be divided = among the terminals dynamically.=0A =0AThis is the real issue with Starlink= as load increases. And yet most people are pretending this scheduling prob= lem doesn't exist!=0A =0AEven Dave Taht and his buddies who have worked on = trying to solve the problem of sharing with 802.11 haven't made much progre= ss in dealing with bursty traffic sharing with heavy load. =0A =0AAnd yet p= eople are modeling as if this didn't even matter! (well, it's not somethin= g that has arisen much in the classic one-way or non-multiplexed satellite = systems. I don't think even commercial airline satellite systems try to sha= re capacity among multiple planes dynamically.)=0A =0AThe phased array trac= king of satellites is indeed magical, and the ability to (in principle) swi= tch directions between every 6 bit symbol time is very nice for the downlin= k from the satellite to multiple dishys.=0AGreat technology.=0A =0ABut the = multiplexing at the packet level given the burstiness of load and the need = to stay under 20 msec. packet latency from dishy to anywhere in the contine= nt is a problem. That's gonna destroy all interactive services as load grow= s. And that on top of bufferbloat (queueing delay under load caused by not = dropping packets) that is apparently a problem in the system. and not being= addressed.=0A =0AMy response to these kind of studies is "measure based on= reality" before you imagine what a good model is.=0A =0A> =0A> --Sascha=0A= > =0A> On 8/30/22 07:52, Dave Taht via Starlink wrote:=0A> > mike is doing = some great visualizations here:=0A> >=0A> > https://twitter.com/mikepuchol/= status/1564544963857326081=0A> =0A=0A ------=_20220830203008000000_41042 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Sascha -

=0A

On Tuesday, August 30, 2022 6:39pm, starlink-request@lists= .bufferbloat.net said:
> Date: Tue, 30 Aug 2022 08:37:24 -0400

= =0A
=0A

> From: Sasc= ha Meinrath <sascha@thexlab.org>
> To: Dave Taht <dave.tah= t@gmail.com>, Dave Taht via Starlink
> <starlink@lists.buffer= bloat.net>
> Subject: 
>
> I'd be curious = how accurate these simulations are -- even within something as
> si= mple as LAN Wi-Fi, the "simulations" often are wildly/hyperbolically
&= gt; over-stated. I could imagine that even a few over-rosy assumptions woul= d
> exponentially metastasize optimism within the satellite context= .

=0A

 

=0A

Very good po= int. They don't seem to be based on very thoughtful assumptions about the P= HY level.

=0A

Remember, each satellite has  4 p= hased array antenna that can each "focus" in one direction. That's a pretty= severe limit. Those antennas can either transmit or receive. They can't do= both at the same time. Multiple dishys probably will need to share the cap= acity of those 4 antennas on the uplink from dishy to satellite. They also = share the capacity on the downlink (because the beaming tracks individual d= ishys.

=0A

 

=0A

How are= they "time shared"? Well you have two problems here - one is that you cons= tantly drop dishys and pick up new ones as the satellite moves, so the "tim= e division schedule" of each antenna has to be dynamic, especially as densi= ty of active dishys varies (and inactive ones might become active any milli= second or less - new packets being sent).

=0A

Now it= takes at least 4 milliseconds for the a new uplink slot to be acquired. Th= at's the dishy->sat->dishy round trip at the speed of light. Multiple= dishys per satellite antenna means that the uplink, and downlink traffic r= ates depend on how predictable the traffic is.

=0A

&= nbsp;

=0A

Internet traffic (unlike classic voice or = video which can be seen as a constant bit rate channel with long silence pe= riods) is bursty at all timescales. It's fractally bursty, as studies have = shown.

=0A

 

=0A

Nothing= of this sort is even modeled in this work.

=0A

&nbs= p;

=0A

Now I first started working with 2 way satell= ite technology back in the Iridium days, and also with 2-way geosynchronous= satellites that used RF transponders that just translated the frequency of= the uplink to the downlink frequency and vice versa. (Tachyon was the comp= any, I was working on some technology for Nicholas Negroponte's 2B1 project= that decided on Tachyon and not Iridium for all kinds of reasons).

=0A<= p style=3D"margin:0;padding:0;font-family: arial; font-size: 10pt; overflow= -wrap: break-word;"> 

=0A

The big problem in a = multiplexed two way system (even at LEO) is that the satellite uplink traff= ic from one of the many terminals had to share one or a few channels (frequ= encies) and they can't hear each other. So Internet traffic has to be held = until it can get a free time slot, or else the frequencies have to be divid= ed among the terminals dynamically.

=0A

 

= =0A

This is the real issue with Starlink as load increa= ses. And yet most people are pretending this scheduling problem doesn't exi= st!

=0A

 

=0A

Even Dave = Taht and his buddies who have worked on trying to solve the problem of shar= ing with 802.11 haven't made much progress in dealing with bursty traffic s= haring with heavy load. 

=0A

 

=0A

And yet people are modeling as if this didn't even matter!&= nbsp; (well, it's not something that has arisen much in the classic one-way= or non-multiplexed satellite systems. I don't think even commercial airlin= e satellite systems try to share capacity among multiple planes dynamically= .)

=0A

 

=0A

The phased = array tracking of satellites is indeed magical, and the ability to (in prin= ciple) switch directions between every 6 bit symbol time is very nice for t= he downlink from the satellite to multiple dishys.

=0A

Great technology.

=0A

 

=0A

But the multiplexing at the packet level given the burstiness of loa= d and the need to stay under 20 msec. packet latency from dishy to anywhere= in the continent is a problem. That's gonna destroy all interactive servic= es as load grows. And that on top of bufferbloat (queueing delay under load= caused by not dropping packets) that is apparently a problem in the system= . and not being addressed.

=0A

 

=0A

My response to these kind of studies is "measure based on real= ity" before you imagine what a good model is.

=0A

&n= bsp;

=0A

>
> --Sascha
>
&g= t; On 8/30/22 07:52, Dave Taht via Starlink wrote:
> > mike is d= oing some great visualizations here:
> >
> > https://= twitter.com/mikepuchol/status/1564544963857326081
>

=0A

 ------=_20220830203008000000_41042--