From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp74.iad3a.emailsrvr.com (smtp74.iad3a.emailsrvr.com [173.203.187.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A36003B2A4 for ; Wed, 31 Aug 2022 15:51:28 -0400 (EDT) Received: from app1.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp10.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 38C9E5DC8 for ; Wed, 31 Aug 2022 15:51:28 -0400 (EDT) Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app1.wa-webapps.iad3a (Postfix) with ESMTP id 222C6E1193 for ; Wed, 31 Aug 2022 15:51:28 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Wed, 31 Aug 2022 15:51:28 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Wed, 31 Aug 2022 15:51:28 -0400 (EDT) From: "David P. Reed" To: starlink@lists.bufferbloat.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20220831155128000000_97275" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: X-Client-IP: 209.6.168.128 Message-ID: <1661975488.138231368@apps.rackspace.com> X-Mailer: webmail/19.0.18-RC X-Classification-ID: ce9259df-b1d3-476d-b6e6-55ffc63c1984-1-1 Subject: Re: [Starlink] Starlink "beam spread" 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 19:51:28 -0000 ------=_20220831155128000000_97275 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AHi Dick -=0Aglad you joined in the response, given your experience with = spatial multiplexing of RF.=0A =0AOn Wednesday, August 31, 2022 3:04pm, sta= rlink-request@lists.bufferbloat.net said:=0A=0A=0A=0A> Date: Wed, 31 Aug 20= 22 10:52:15 -0700=0A> From: "Dick Roy" =0A> To: "'Mik= e Puchol'" =0A> Cc: =0A> = Subject: Re: [Starlink] Starlink "beam spread"=0A> Message-ID: =0A> Content-Type: text/plain; charset=3D"iso-88= 59-1"=0A> On this particular one, the gateway beams are extremely narrow, a= round 1.5=C2=BA=0A> to 2.5=C2=BA. SpaceX is working on =E2=80=9Cmega-gatewa= ys=E2=80=9D where 32 antennas=0A> will=0A> co-exist. They are also deployin= g a new gateway design with a larger=0A> antenna, and thus narrower beamwid= th and more gain, allowing for a=0A> considerable reduction in TX power.=0A= > =0A> [RR] there is a much better way to do this! I sure hope starlink is= =0A> considering it. Large antennas with narrow beam widths are a sledgeham= mer to=0A> kill a fly.=0A> :-)=0A I'm pretty sure, from my examination of t= he dishy array (and the satellite arrays are likely the same) that at the f= ront-end electronics level their use of 64 QAM (six bits of signal quantiza= tion in amplitude and phase) isn't gonna allow much signalling in multiple = directions at once. That's a sampling theory issue, really.=0A =0AThere's a= lot of handwaving in the discussion here, mostly focused on "beam width" r= ather than combined channel capacity. To me that's the "sledgehammer" you a= re referring to.=0A =0ASo that's one aspect. But the other aspect that I'm = focused on is not in the arraycom space, it's in the question of how the hi= ghly variable (bursty) demand in both directions works out. The low-delay (= small packets) at the signalling rate are actually smaller than the number = of bits in transit over the 2 msec. path. So the packet level multiplexing = here (with more dishy terminals than the 4 240 Mb/sec channels afforded) is= also an issue. We aren't talking about one CBR uplink per dishy. It's bitr= ate is highly variable, given Internet load.=0A =0ANow RRUL from *one dishy= * doesn't address this problem properly. You need to look at what happens w= hen all the dishys (uplink and downlink) are wanting to saturate all up and= down links. Then you add a new packet that needs low latency (whether it i= s ACK packet for TCP or a click from a FPS, or an audio frame in a teleconf= erence, latency matters for all of these, and they aren't predictable in ad= vance). How long will it be before an uplink slot is opened? If there is no= load, it still requires a clear channel, so it requires waiting till one's= turn. Assume that each dishy using the uplink gets one uplink slot in a sl= ot time T. Then the delay till slot available can be short, if the slots ar= e short, all dishys get a turn within 2 msec. or less. But if there is a lo= ad in both the up and down direction (and one can easily have such a load f= rom file uploads or file downloads on each dishy, or a fairly big load from= UHD video streams to each dishy being "buffered" into a playback buffer on= a Smart TV), then latency due to queueing delay can soar.=0A =0AIf you don= 't allow all the dishys to use all the capacity of a satellite, the latency= problem gets smaller. But then, of course, you are wasting a bit of capaci= ty to preserve latency for low bitrate traffic.=0A =0AHowever, high bitrate= traffic also has latency requirements. It's not all "background".=0A =0AI'= m sure this is something that can be worked out by some algorithm that reac= hes toward the optimal state by dropping packets to signal TCP (or QUIC) th= at the transmitter needs to slow down to avoid building up queueing delay. = The problem here, though, is that all the focus in this discussion is about= "throughput" in a single link, and ignores the burstiness that is driving = the multiplexing.=0A =0AMy point is that the discussion here has focused en= tirely on achievable bitrate maximum, with no load and no burstiness.=0A = =0AThis isn't fixed by having more spatial control, to the extent that is p= ossible. It *is* fixable by suitable Automatic Queue Management in the sate= llite path (which will be the "bottleneck link" between the home and the pu= blic Internet), plus suitable end-to-end protocol congestion management tha= t responds to drops or ECN. (I don't know if the satellite looks at the pac= ket hard enough and has enough state to set the ECN bit or that it has enou= gh state to achieve bloom filter based fair queue dropping).=0A =0ADave Tah= t indicates he has some mysterious statistics from (single) dishy experimen= ts. It's a problem that we cannot see into the Starlink black box to unders= tand it fully.=0A =0ABut I'm CERTAIN that simplistic analysis about achieva= ble channel bitrates in the abstract will not capture the issues, and that = there will be LOTS of systemic problems that are not easily solved by just = thinking about rates and beam width. ------=_20220831155128000000_97275 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Dick -

=0A

glad you joined in the response, given your experience with = spatial multiplexing of RF.

=0A

 

=0A

On Wednesday, August 31, 2022 3:04pm, starlink-request@lists.= bufferbloat.net said:

=0A
= =0A

> Date: Wed, 31 Aug 2022 10:52:15 -0700
>= ; From: "Dick Roy" <dickroy@alum.mit.edu>
> To: "'Mike Puchol= '" <mike@starlink.sx>
> Cc: <starlink@lists.bufferbloat.ne= t>
> Subject: Re: [Starlink] Starlink "beam spread"
> Me= ssage-ID: <BCE2EFF2444C470C87D9D4C6D4E6E0A9@SRA6>
> Content-T= ype: text/plain; charset=3D"iso-8859-1"

=0A

> On = this particular one, the gateway beams are extremely narrow, around 1.5=C2= =BA
> to 2.5=C2=BA. SpaceX is working on =E2=80=9Cmega-gateways=E2= =80=9D where 32 antennas
> will
> co-exist. They are also d= eploying a new gateway design with a larger
> antenna, and thus nar= rower beamwidth and more gain, allowing for a
> considerable reduct= ion in TX power.
>
> [RR] there is a much better way to do= this! I sure hope starlink is
> considering it. Large antennas wit= h narrow beam widths are a sledgehammer to
> kill a fly.
> = :-)
 I'm pretty sure, from my examination of the dishy array (and= the satellite arrays are likely the same) that at the front-end electronic= s level their use of 64 QAM (six bits of signal quantization in amplitude a= nd phase) isn't gonna allow much signalling in multiple directions at once.= That's a sampling theory issue, really.

=0A

 <= /p>=0A

There's a lot of handwaving in the discussion he= re, mostly focused on "beam width" rather than combined channel capacity. T= o me that's the "sledgehammer" you are referring to.

=0A

 

=0A

So that's one aspect. But the other = aspect that I'm focused on is not in the arraycom space, it's in the questi= on of how the highly variable (bursty) demand in both directions works out.= The low-delay (small packets) at the signalling rate are actually smaller = than the number of bits in transit over the 2 msec. path. So the packet lev= el multiplexing here (with more dishy terminals than the 4 240 Mb/sec chann= els afforded) is also an issue. We aren't talking about one CBR uplink per = dishy. It's bitrate is highly variable, given Internet load.

=0A

 

=0A

Now RRUL from *one dishy* do= esn't address this problem properly. You need to look at what happens when = all the dishys (uplink and downlink) are wanting to saturate all up and dow= n links. Then you add a new packet that needs low latency (whether it is AC= K packet for TCP or a click from a FPS, or an audio frame in a teleconferen= ce, latency matters for all of these, and they aren't predictable in advanc= e). How long will it be before an uplink slot is opened? If there is no loa= d, it still requires a clear channel, so it requires waiting till one's tur= n. Assume that each dishy using the uplink gets one uplink slot in a slot t= ime T. Then the delay till slot available can be short, if the slots are sh= ort, all dishys get a turn within 2 msec. or less. But if there is a load i= n both the up and down direction (and one can easily have such a load from = file uploads or file downloads on each dishy, or a fairly big load from UHD= video streams to each dishy being "buffered" into a playback buffer on a S= mart TV), then latency due to queueing delay can soar.

=0A

 

=0A

If you don't allow all the dishys = to use all the capacity of a satellite, the latency problem gets smaller. B= ut then, of course, you are wasting a bit of capacity to preserve latency f= or low bitrate traffic.

=0A

 

=0A

However, high bitrate traffic also has latency requirements. It's= not all "background".

=0A

 

=0A

I'm sure this is something that can be worked out by some algorith= m that reaches toward the optimal state by dropping packets to signal TCP (= or QUIC) that the transmitter needs to slow down to avoid building up queue= ing delay. The problem here, though, is that all the focus in this discussi= on is about "throughput" in a single link, and ignores the burstiness that = is driving the multiplexing.

=0A

 

=0A

My point is that the discussion here has focused entirely on= achievable bitrate maximum, with no load and no burstiness.

=0A

 

=0A

This isn't fixed by having m= ore spatial control, to the extent that is possible. It *is* fixable by sui= table Automatic Queue Management in the satellite path (which will be the "= bottleneck link" between the home and the public Internet), plus suitable e= nd-to-end protocol congestion management that responds to drops or ECN. (I = don't know if the satellite looks at the packet hard enough and has enough = state to set the ECN bit or that it has enough state to achieve bloom filte= r based fair queue dropping).

=0A

 

=0A

Dave Taht indicates he has some mysterious statistics from = (single) dishy experiments. It's a problem that we cannot see into the Star= link black box to understand it fully.

=0A

 =0A

But I'm CERTAIN that simplistic analysis about ach= ievable channel bitrates in the abstract will not capture the issues, and t= hat there will be LOTS of systemic problems that are not easily solved by j= ust thinking about rates and beam width.

=0A
 ------=_20220831155128000000_97275--