From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from vsmx001.dclux.xion.oxcs.net (vsmx001.dclux.xion.oxcs.net [185.74.65.81]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A1A733CB37 for ; Wed, 31 Aug 2022 05:56:04 -0400 (EDT) Received: from proxy-2.proxy.oxio.ns.xion.oxcs.net (proxy-2.proxy.oxio.ns.xion.oxcs.net [83.61.18.4]) by mx-out.dclux.xion.oxcs.net (Postfix) with ESMTPA id 448228C0378 for ; Wed, 31 Aug 2022 09:56:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dclux.xion.oxcs.net; s=mail1; t=1661939763; bh=BsmLy9Jqiv6//5NZansYjb3QUHH3p0OiH/PamooqDBY=; h=Date:From:To:In-Reply-To:References:Subject:From; b=mmgtg34L+cTjbkV/FIBLI6YLbSCzvXKm+kNM1+uStvK1KhEzkRVxbD2uU8invc0s6 6pOLeVCAjeQXG3ikN6N8sWmB25FWvROpOS2JMtjONGtdrOkidKWB/mjK4HI5uMMFwK yvVhQUqMqZ8+ZOjSnFrjLyfolbEWs/CSnhZAFDoAPvtfpuuFPmZRusfeklA7miMAdw p4+ac390PzKrsXPPVCqYwCh+ojqaciuoxI7+gdi5vYoC53RqmYIl20URkGnIFsq2b+ 8eOn4X/CG0z8AxpqNOQBwYs2QitGQBZEPBEFYa9GV02kpeEI0nyBwfaAoJ2NxzViP5 3XEpub4UoniKg== Date: Wed, 31 Aug 2022 11:55:55 +0200 From: Mike Puchol To: starlink@lists.bufferbloat.net Message-ID: <3175dea2-1925-4da5-bb7d-2569fa917d14@Spark> In-Reply-To: References: <1661905808.989521682@apps.rackspace.com> X-Readdle-Message-ID: 3175dea2-1925-4da5-bb7d-2569fa917d14@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="630f3031_20ee1348_2eb" X-VadeSecure-Status: LEGIT X-VADE-STATUS: LEGIT 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 09:56:05 -0000 --630f3031_20ee1348_2eb Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline The simulation is based on many thoughtful assumptions about the PHY leve= l. =46or starters, as Nathan mentions, each satellite has 4 ESAs, three f= or downlink, one for uplink. Each ESA is capable of generating 8 simulate= nous spot beams in two polarizations, which gives us 48 downlink beams, a= nd 16 uplink beams. Each beam is independently steerable, with an accurac= y of 0.1=C2=BA. This is known from =46CC filings and other public sources= of information. The statement that =22each satellite has=C2=A0=C2=A04 ph= ased array antenna that can each =22focus=22 in one direction=E2=80=9D is= thus incorrect. The filings also state that downlink beams use 240 MHz of effective bandw= idth from a 250 MHz channel, and 8 channels are available in the 2 GHz of= spectrum used for downlink. Thus, my simulation takes those 48 spot beam= s, assigns one of 8 =E2=80=9Ccolors=E2=80=9D to each, representing the co= rresponding channel. I took the filed GXT contours for the downlink spot beams, and worked out= the eccentricity parameters, which allow me to generate a spot beam=E2=80= =99s 3dB footprint at any azimuth and steering angle. This has been valid= ated against the GXT contours, and are quite accurate. I can thus work ou= t how many cells fall inside the =46OR (field of regard) of a spot beam, = allowing for simulation of beam spread. My simulation also takes into account the gateway links, only uses satell= ites that have a gateway link and are in the correct orbital slot, or lin= ked via ISL. Bottom line: is my simulation 100% accurate=3F Absolutely no= t. Is it completely inaccurate=3F Absolutely not either. Without knowing = how Starlink assigns resources, and a bit more about the air interface, i= t=E2=80=99s impossible to accurately simulate the constellation. Can I si= mulate how much overall capacity could be provided to the US, or a group = of cells=3F Yes, to a high degree of accuracy, based on all the knowledge= and work I mention above. What I=E2=80=99d also say is that I=E2=80=99m = not marketing for SpaceX or Starlink, thus, I have no vested interest in = painting a =E2=80=9Crosy=E2=80=9D picture of anything - I will simulate a= s accurately as I can, in some cases, the results will be optimistic and = best-case, in others, they will be worst-case too. I=E2=80=99ll discuss other statements made individually: > Multiple dishys probably will need to share the capacity of those 4 ant= ennas on the uplink from dishy to satellite. They also share the capacity= on the downlink (because the beaming tracks individual dishys. The first sentence is partly correct, in that the terminals must share th= e 4 antennas. However, one antenna is for uplink, three for downlink, and= work full-duplex. The second sentence is incorrect, the beams do not tra= ck individual terminals. At nadir, a spot beam is just larger than a sing= le cell, however, at maximum steering angle, a beam can cover 30+ cells. = The beam is serving any terminal inside the =46OR, without needing to tra= ck it individually. > How are they =22time shared=22=3F Well you have two problems here - one= is that you constantly drop dishys and pick up new ones as the satellite= moves, so the =22time division schedule=22 of each antenna has to be dyn= amic, especially as density of active dishys varies (and inactive ones mi= ght become active any millisecond or less - new packets being sent). The constellation doesn=E2=80=99t constantly pick up and drop terminals, = the resource allocation per cell lasts for minimum 15 seconds, and someti= mes as long as 3 minutes (based on direct observation). This resource cou= ld be a dedicated beam, or 50% of a single beam=E2=80=99s time. The satel= lite knows where the beams need to be pointed, and the terminal knows wha= t satellite it should be tracking, the only disruptions are handovers fro= m satellite to satellite (it=E2=80=99s break-before-make). The density of= active terminals can vary, but it=E2=80=99s not such that a cell may hav= e 200 terminals, 80% of which are on and off within miliseconds. People t= end to turn on their internet connection and leave it on, only to turn it= off if they leave or don=E2=80=99t need it for a long period, if at all.= In Kenya, 90% of our customers keep their CPE on 24/7. > Now it takes at least 4 milliseconds for the a new uplink slot to be ac= quired. That's the dishy->sat->dishy round trip at the speed of light. Mu= ltiple dishys per satellite antenna means that the uplink, and downlink t= raffic rates depend on how predictable the traffic is. There is a confusion in terms - once you are tracking a satellite, the sa= tellite will tell the terminal what slots it can use to transmit. I have = analyzed the uplink R=46, and it=E2=80=99s an O=46DM signal, with 128 sub= carriers on a 62.5 MHz channel, which is then split in the time domain. T= he measured uplink duty cycle is 14%, which is exactly what is in the =46= CC filings. If you assume a 6% time overhead from TDM beam switching on t= he satellite, you could still have 5 cells per uplink beam, with 20% dwel= l time per cell. You can then split the subcarriers 128 times in the freq= uency domain, to cater for multiple uplinks from that cell=E2=80=99s term= inals (so going full O=46DMA). Handover from satellite to satellite can t= ake longer, as you need to sync clocks, decode reference signal, etc. so = it could take 10-15ms. > Internet traffic (unlike classic voice or video which can be seen as a = constant bit rate channel with long silence periods) is bursty at all tim= escales. It's fractally bursty, as studies have shown. Nothing of this so= rt is even modeled in this work. Because it=E2=80=99s not meant to, and not even required for my intent. T= he simulation will tell you how much =E2=80=9Cbrute=E2=80=9D capacity you= can expect per cell and country, given a set of configurable parameters.= How you manage that capacity is a different issue, and also related to w= hat your users are doing. To simulate the burstiness of traffic in the St= arlink case would require analysis of a single satellite with the termina= ls it is serving, gateway links, and upstream links to the POP. You can t= hen extrapolate those to the entire constellation based on active satelli= tes, served cells, etc. I=E2=80=99m simulating the broad constellation behavior and dynamics, if = you want a per-packet level simulation, feel free to create one - mine is= not it, and won=E2=80=99t be :-) > The big problem in a multiplexed two way system (even at LEO) is that t= he satellite uplink traffic from one of the many terminals had to share o= ne or a few channels (frequencies) and they can't hear each other. So Int= ernet traffic has to be held until it can get a free time slot, or else t= he frequencies have to be divided among the terminals dynamically. This is solved by O=46DMA as implemented by Starlink, where all resources= are centrally controlled, and there is no random component other than in= itial registration, in the same way PRACH works in LTE. I see a lot of =E2=80=9Cthat can=E2=80=99t possibly be true=21=E2=80=9D f= rom the =E2=80=9Ctraditional=E2=80=9D satellite industry, as SpaceX seems= to be violating dogmas all the time. In the same way =E2=80=9Cthe indust= ry=E2=80=9D thought re-usable first stages would never work, Starlink is = facing its moment of disbelief. If we take beamhopping as an example, I=E2= =80=99ve heard from experts (not in quotes, actual experts) that claim th= ey cannot be doing it, as it=E2=80=99s extremely hard and would require m= assive computational power on the satellite. Once you poke that one, it b= ecomes clear the statement is driven from years of DVB-S2x exposure, wher= e the timings are so excruciatingly tight, that it is a big problem. Star= link goes about this by doing the computations on the ground by a central= scheduler, and then telling the satellites what to do. Oh, and not using= DVB-S2x. > This is the real issue with Starlink as load increases. And yet most pe= ople are pretending this scheduling problem doesn't exist=21 There is a capacity problem, as evidenced by customer complaints of slow = speeds at times, but that is not related to scheduling. They have, IMHO, = the scheduling pretty well resolved. If you can ellaborate on where you t= hink the problem is, it=E2=80=99d be useful. > But the multiplexing at the packet level given the burstiness of load a= nd 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 servi= ces as load grows. And that on top of bufferbloat (queueing delay under l= oad caused by not dropping packets) that is apparently a problem in the s= ystem. and not being addressed. There are definitely issues to be solved, and promises that were made whi= ch can be questioned. Whenever I hear anyone promising latency in a blank= et statement, eg =E2=80=9CThis service will provide 20ms of latency=21=E2= =80=9D, I push back with =E2=80=9CTo where, exactly=3F=E2=80=9D. The RDO=46 proposal itself wasn=E2=80=99t clear on this point, which drov= e SpaceX and others to question how the conformity parameters shoud be me= asured. Is latency to the POP useful to a customer=3F Sure, but what if 9= 0% of the customer=E2=80=99s traffic is to some VPN service in Latvia use= d for streaming soccer illegally=3F Does the customer have a right to com= plain=3F Is the latency measurement that the ISP is held to account with = the POP latency, or the latency to the farthest reaches of the Internet=3F= If you want a bed time read on responses to RDO=46 comments, head over h= ere:=C2=A0https://docs.fcc.gov/public/attachments/DOC-361785A1.pdf > My response to these kind of studies is =22measure based on reality=22 = before you imagine what a good model is. Unfortunately, only SpaceX can measure the entire system (and obviously d= oes), us mere mortals have to come up with models and simulations :-) Best, Mike On Aug 31, 2022, 02:43 +0200, Nathan Owens via Starlink , wrote: > Based on the spacing on the sat bus, it=E2=80=99s likely there=E2=80=99= s 3x TX antennas and 1x RX on the satellite. > > > On Tue, Aug 30, 2022 at 5:30 PM David P. Reed via Starlink wrote: > > > Hi Sascha - > > > On Tuesday, August 30, 2022 6:39pm, starlink-request=40lists.buffer= bloat.net said: > > > > Date: Tue, 30 Aug 2022 08:37:24 -0400 > > > > =46rom: Sascha Meinrath > > > > To: Dave Taht , Dave Taht via Starlink > > > > > > > > Subject: > > > > > > > > I'd be curious how accurate these simulations are -- even within = something as > > > > simple as LAN Wi-=46i, the =22simulations=22 often are wildly/hyp= erbolically > > > > over-stated. I could imagine that even a few over-rosy assumption= s would > > > > exponentially metastasize optimism within the satellite context. > > > > > > Very good point. They don't seem to be based on very thoughtful ass= umptions about the PHY level. > > > Remember, each satellite has=C2=A0 4 phased array antenna that can = each =22focus=22 in one direction. That's a pretty severe limit. Those an= tennas can either transmit or receive. They can't do both at the same tim= e. Multiple dishys probably will need to share the capacity of those 4 an= tennas on the uplink from dishy to satellite. They also share the capacit= y on the downlink (because the beaming tracks individual dishys. > > > > > > How are they =22time shared=22=3F Well you have two problems here -= one is that you constantly drop dishys and pick up new ones as the satel= lite moves, so the =22time division schedule=22 of each antenna has to be= dynamic, especially as density of active dishys varies (and inactive one= s might become active any millisecond or less - new packets being sent). > > > Now it takes at least 4 milliseconds for the a new uplink slot to b= e acquired. That's the dishy->sat->dishy round trip at the speed of light= . Multiple dishys per satellite antenna means that the uplink, and downli= nk traffic rates depend on how predictable the traffic is. > > > > > > Internet traffic (unlike classic voice or video which can be seen a= s a constant bit rate channel with long silence periods) is bursty at all= timescales. It's fractally bursty, as studies have shown. > > > > > > Nothing of this sort is even modeled in this work. > > > > > > Now I first started working with 2 way satellite technology back in= the Iridium days, and also with 2-way geosynchronous satellites that use= d R=46 transponders that just translated the frequency of the uplink to t= he downlink frequency and vice versa. (Tachyon was the company, I was wor= king on some technology for Nicholas Negroponte's 2B1 project that decide= d on Tachyon and not Iridium for all kinds of reasons). > > > > > > The big problem in a multiplexed two way system (even at LEO) is th= at the satellite uplink traffic from one of the many terminals had to sha= re one or a few channels (frequencies) and they can't hear each other. So= Internet traffic has to be held until it can get a free time slot, or el= se the frequencies have to be divided among the terminals dynamically. > > > > > > This is the real issue with Starlink as load increases. And yet mos= t people are pretending this scheduling problem doesn't exist=21 > > > > > > Even Dave Taht and his buddies who have worked on trying to solve t= he problem of sharing with 802.11 haven't made much progress in dealing w= ith bursty traffic sharing with heavy load. > > > > > > And yet people are modeling as if this didn't even matter=21=C2=A0 = (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 airline = satellite systems try to share capacity among multiple planes dynamically= .) > > > > > > The phased array tracking of satellites is indeed magical, and the = ability to (in principle) switch directions between every 6 bit symbol ti= me is very nice for the downlink from the satellite to multiple dishys. > > > Great technology. > > > > > > But the multiplexing at the packet level given the burstiness of lo= ad and the need to stay under 20 msec. packet latency from dishy to anywh= ere in the continent is a problem. That's gonna destroy all interactive s= ervices as load grows. And that on top of bufferbloat (queueing delay und= er load caused by not dropping packets) that is apparently a problem in t= he system. and not being addressed. > > > > > > My response to these kind of studies is =22measure based on reality= =22 before you imagine what a good model is. > > > > > > > > > > > --Sascha > > > > > > > > On 8/30/22 07:52, Dave Taht via Starlink wrote: > > > > > mike is doing some great visualizations here: > > > > > > > > > > https://twitter.com/mikepuchol/status/1564544963857326081 > > > > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > > Starlink mailing list > > > Starlink=40lists.bufferbloat.net > > > https://lists.bufferbloat.net/listinfo/starlink > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Starlink mailing list > Starlink=40lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink --630f3031_20ee1348_2eb Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
The simulation is based on many thoughtful assumpti= ons about the PHY level. =46or starters, as Nathan mentions, each satelli= te has 4 ESAs, three for downlink, one for uplink. Each ESA is capable of= generating 8 simulatenous spot beams in two polarizations, which gives u= s 48 downlink beams, and 16 uplink beams. Each beam is independently stee= rable, with an accuracy of 0.1=C2=BA. This is known from =46CC filings an= d other public sources of information. The statement that =22each sat= ellite has&=23160;&=23160;4 phased array antenna that can each =22focus=22= in one direction=E2=80=9D is thus incorrect.

The filings also state that downlink beams use 240 MHz of effective bandw= idth from a 250 MHz channel, and 8 channels are available in the 2 GHz of= spectrum used for downlink. Thus, my simulation takes those 48 spot beam= s, assigns one of 8 =E2=80=9Ccolors=E2=80=9D to each, representing the co= rresponding channel.

I took the filed GXT contours for the downlink spot beams, and worked out= the eccentricity parameters, which allow me to generate a spot beam=E2=80= =99s 3dB footprint at any azimuth and steering angle. This has been valid= ated against the GXT contours, and are quite accurate. I can thus work ou= t how many cells fall inside the =46OR (field of regard) of a spot beam, = allowing for simulation of beam spread.

My simulation also takes into account the gateway links, only uses satell= ites that have a gateway link and are in the correct orbital slot, or lin= ked via ISL. Bottom line: is my simulation 100% accurate=3F Absolutely no= t. Is it completely inaccurate=3F Absolutely not either. Without knowing = how Starlink assigns resources, and a bit more about the air interface, i= t=E2=80=99s impossible to accurately simulate the constellation. Can I si= mulate how much overall capacity could be provided to the US, or a group = of cells=3F Yes, to a high degree of accuracy, based on all the knowledge= and work I mention above. What I=E2=80=99d also say is that I=E2=80=99m = not marketing for SpaceX or Starlink, thus, I have no vested interest in = painting a =E2=80=9Crosy=E2=80=9D picture of anything - I will simulate a= s accurately as I can, in some cases, the results will be optimistic and = best-case, in others, they will be worst-case too.

I=E2=80=99ll discuss other statements made individually:
Multiple dishys probably will need to share the capacity of those 4 ante= nnas on the uplink from dishy to satellite. They also share the capacity = on the downlink (because the beaming tracks individual dishys.
The first sentence is partly correct, in that the t= erminals must share the 4 antennas. However, one antenna is for uplink, t= hree for downlink, and work full-duplex. The second sentence is incorrect= , the beams do not track individual terminals. At nadir, a spot beam is j= ust larger than a single cell, however, at maximum steering angle, a beam= can cover 30+ cells. The beam is serving any terminal inside the =46OR, = without needing to track it individually.
How are they =22time shared=22=3F Well you have two problems here - one = is that you constantly drop dishys and pick up new ones as the satellite = moves, so the =22time division schedule=22 of each antenna has to be dyna= mic, especially as density of active dishys varies (and inactive ones mig= ht become active any millisecond or less - new packets being sent).

The constellation doesn=E2=80=99t constantly pick up and drop terminals, = the resource allocation per cell lasts for minimum 15 seconds, and someti= mes as long as 3 minutes (based on direct observation). This resource cou= ld be a dedicated beam, or 50% of a single beam=E2=80=99s time. The satel= lite knows where the beams need to be pointed, and the terminal knows wha= t satellite it should be tracking, the only disruptions are handovers fro= m satellite to satellite (it=E2=80=99s break-before-make). The density of= active terminals can vary, but it=E2=80=99s not such that a cell may hav= e 200 terminals, 80% of which are on and off within miliseconds. People t= end to turn on their internet connection and leave it on, only to turn it= off if they leave or don=E2=80=99t need it for a long period, if at all.= In Kenya, 90% of our customers keep their CPE on 24/7.
Now it takes at least 4 milliseconds for the a new uplink slot to be acq= uired. That's the dishy->sat->dishy round trip at the speed of ligh= t. Multiple dishys per satellite antenna means that the uplink, and downl= ink traffic rates depend on how predictable the traffic is.

There is a confusion in terms - once you are tracking a satellite, the sa= tellite will tell the terminal what slots it can use to transmit. I have = analyzed the uplink R=46, and it=E2=80=99s an O=46DM signal, with 128 sub= carriers on a 62.5 MHz channel, which is then split in the time domain. T= he measured uplink duty cycle is 14%, which is exactly what is in the =46= CC filings. If you assume a 6% time overhead from TDM beam switching on t= he satellite, you could still have 5 cells per uplink beam, with 20% dwel= l time per cell. You can then split the subcarriers 128 times in the freq= uency domain, to cater for multiple uplinks from that cell=E2=80=99s term= inals (so going full O=46DMA). Handover from satellite to satellite can t= ake longer, as you need to sync clocks, decode reference signal, etc. so = it could take 10-15ms.
Internet traffic (unlike classic voice or video which can be seen as a c= onstant bit rate channel with long silence periods) is bursty at all time= scales. It's fractally bursty, as studies have shown. Nothing of this sor= t is even modeled in this work.

Because it=E2=80=99s not meant to, and not even required for my intent. T= he simulation will tell you how much =E2=80=9Cbrute=E2=80=9D capacity you= can expect per cell and country, given a set of configurable parameters.= How you manage that capacity is a different issue, and also related to w= hat your users are doing. To simulate the burstiness of traffic in the St= arlink case would require analysis of a single satellite with the termina= ls it is serving, gateway links, and upstream links to the POP. You can t= hen extrapolate those to the entire constellation based on active satelli= tes, served cells, etc.

I=E2=80=99m simulating the broad constellation behavior and dynamics, if = you want a per-packet level simulation, feel free to create one - mine is= not it, and won=E2=80=99t be :-)
The big problem in a multiplexed two way system (even at LEO) is that th= e satellite uplink traffic from one of the many terminals had to share on= e or a few channels (frequencies) and they can't hear each other. So Inte= rnet traffic has to be held until it can get a free time slot, or else th= e frequencies have to be divided among the terminals dynamically.

This is solved by O=46DMA as implemented by Starlink, where all resources= are centrally controlled, and there is no random component other than in= itial registration, in the same way PRACH works in LTE.&=23160;

I see a lot of =E2=80=9Cthat can=E2=80=99t possibly be true=21=E2=80=9D f= rom the =E2=80=9Ctraditional=E2=80=9D satellite industry, as SpaceX seems= to be violating dogmas all the time. In the same way =E2=80=9Cthe indust= ry=E2=80=9D thought re-usable first stages would never work, Starlink is = facing its moment of disbelief. If we take beamhopping as an example, I=E2= =80=99ve heard from experts (not in quotes, actual experts) that claim th= ey cannot be doing it, as it=E2=80=99s extremely hard and would require m= assive computational power on the satellite. Once you poke that one, it b= ecomes clear the statement is driven from years of DVB-S2x exposure, wher= e the timings are so excruciatingly tight, that it is a big problem. Star= link goes about this by doing the computations on the ground by a central= scheduler, and then telling the satellites what to do. Oh, and not using= DVB-S2x.
This is the real issue with Starlink as load increases. And yet most peo= ple are pretending this scheduling problem doesn't exist=21

There is a capacity problem, as evidenced by customer complaints of slow = speeds at times, but that is not related to scheduling. They have, IMHO, = the scheduling pretty well resolved. If you can ellaborate on where you t= hink the problem is, it=E2=80=99d be useful.
But the multiplexing at the packet level given the burstiness of load an= d the need to stay under 20 msec. packet latency from dishy to anywhere i= n 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 lo= ad caused by not dropping packets) that is apparently a problem in the sy= stem. and not being addressed.

There are definitely issues to be solved, and promises that were made whi= ch can be questioned. Whenever I hear anyone promising latency in a blank= et statement, eg =E2=80=9CThis service will provide 20ms of latency=21=E2= =80=9D, I push back with =E2=80=9CTo where, exactly=3F=E2=80=9D.&=23160;<= br />
The RDO=46 proposal itself wasn=E2=80=99t clear on this point, which drov= e SpaceX and others to question how the conformity parameters shoud be me= asured. Is latency to the POP useful to a customer=3F Sure, but what if 9= 0% of the customer=E2=80=99s traffic is to some VPN service in Latvia use= d for streaming soccer illegally=3F Does the customer have a right to com= plain=3F Is the latency measurement that the ISP is held to account with = the POP latency, or the latency to the farthest reaches of the Internet=3F= If you want a bed time read on responses to RDO=46 comments, head over h= ere:&=23160;https://docs.fcc.gov/public/attachmen= ts/DOC-361785A1.pdf
My response to these kind of studies is =22measure based on reality=22 b= efore you imagine what a good model is.

Unfortunately, only SpaceX can measure the entire system (and obviously d= oes), us mere mortals have to come up with models and simulations :-)

Best,

Mike
On Aug 31, 2022, 02:43 +0200, Natha= n Owens via Starlink <starlink=40lists.bufferbloat.net>, wrote:
Based on the spacing on the sat bus, it=E2=80=99s l= ikely there=E2=80=99s 3x TX antennas and 1x RX on the satellite.&=23160;<= /div>

On Tue, Aug 30, 2022 at 5= :30 PM David P. Reed via Starlink <starlink=40lists.bufferbloat.net> wrote:

= Hi Sascha -

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

= > =46rom: Sascha Meinrath <sascha=40thexlab.org>
> To: Dave Taht <dave.taht=40gmail.com<= /a>>, Dave Taht via Starlink
> <starlink=40lists.bufferblo= at.net>
> Subject:&=23160;
>
> I'd be curious how accurate these simulations are -- even within som= ething as
> simple as LAN Wi-=46i, the =22simulations=22 often are wildly/hyperb= olically
> over-stated. I could imagine that even a few over-rosy assumptions w= ould
> exponentially metastasize optimism within the satellite context.

= &=23160;

= Very good point. They don't seem to be based on very thou= ghtful assumptions about the PHY level.

= Remember, each satellite has&=23160; 4 phased array anten= na that can each =22focus=22 in one direction. That's a pretty severe lim= it. Those antennas can either transmit or receive. They can't do both at = the same time. Multiple dishys probably will need to share the capacity o= f those 4 antennas on the uplink from dishy to satellite. They also share= the capacity on the downlink (because the beaming tracks individual dish= ys.

= &=23160;

= How are they =22time shared=22=3F Well you have two probl= ems here - one is that you constantly drop dishys and pick up new ones as= the satellite moves, so the =22time division schedule=22 of each antenna= has to be dynamic, especially as density of active dishys varies (and in= active ones might become active any millisecond or less - new packets bei= ng sent).

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

= &=23160;

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

= &=23160;

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

= &=23160;

= Now I first started working with 2 way satellite technolo= gy back in the Iridium days, and also with 2-way geosynchronous satellite= s that used R=46 transponders that just translated the frequency of the u= plink to the downlink frequency and vice versa. (Tachyon was the company,= I was working on some technology for Nicholas Negroponte's 2B1 project t= hat decided on Tachyon and not Iridium for all kinds of reasons).<= /p>

= &=23160;

= The big problem in a multiplexed 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 (frequencies) and they can't hear each= other. So Internet traffic has to be held until it can get a free time s= lot, or else the frequencies have to be divided among the terminals dynam= ically.

= &=23160;

= This is the real issue with Starlink as load increases. A= nd yet most people are pretending this scheduling problem doesn't exist=21=

= &=23160;

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

= &=23160;

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

= &=23160;

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

= Great technology.

= &=23160;

= But the multiplexing at the packet level given the bursti= ness of load and the need to stay under 20 msec. packet latency from dish= y to anywhere in the continent is a problem. That's gonna destroy all int= eractive services as load grows. And that on top of bufferbloat (queueing= delay under load caused by not dropping packets) that is apparently a pr= oblem in the system. and not being addressed.

= &=23160;

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

= &=23160;

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

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Starlink mailing list
Starlink=40lists.bufferbloat.net
https://lists.bufferbloat.net/listi= nfo/starlink
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Starlink mailing list
Starlink=40lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink
--630f3031_20ee1348_2eb--