[Starlink] Starlink "beam spread"

[Starlink] Starlink "beam spread"

[David P. Reed]

[-- Attachment #1: Type: text/plain, Size: 2041 bytes --]


I have no clue why this matters (other than this is in color).
 
The phased array antennas used by Starlink are quite limited - in particular, there are 4 on each satellite and each earth-ground path is half-duplex, TDM, essentially. Limited by hardware. The problem of signal equalization and quantization limits prevent "space division multiplexing" and "frequency division multiplexing" in practice.
 
The 4 msec "turnaround time" at the physical level (satellite) means that time from a packet arriving at one end to be sent to the other end of the sat-dishy links gets worse the more dishys are served by one of the 4 antennas on the satellite. 

trying to increase the coverage of an individual satellite basically means serving more dishys per satellite, with less total bit rate, and much longer latency due to the half duplexness.
 
Now if the total bit rate of a sat-to-dishy link were, say, 1 Gigabit, like an 802.11ac AP gives you, and the turnaround time were under 1 microsecond rather than 4 msec.  maybe then you could get reasonable Internet service to dishys.
 
But 240 Mb/s or 172 Mb/s as proposed for getting a bit more coverage per satellite? This is nowhere near competitive with what we expect in the US. 
 
Sorry to rain on all the techy dreaming.
 
First, it's worth looking at all the problems currently in WiFi performance when you share an AP with multiple active stations using 100's of Gb/s on the average (not just occasionally).
 
Dave - you tried in "make-wifi-fast", and the architecture gets in the way there. (yeah you can get point to point gigabit/sec single file transfers, but to do that you invoke features that destroy latency and introduce huge variability if you share the AP at all, for these reasons).
 
Starlink is a good "last resort" service as constituted. But fiber and last few-hundred meters wireless is SO much better able to deliver good Internet service scalably.
Even that assumes fixing the bufferbloat that the Starlink folks don't seem to be able to address...

[-- Attachment #2: Type: text/html, Size: 3901 bytes --]

Re: [Starlink] Starlink "beam spread"

[Doc Searls]

All good points.

I'm also wondering if (and how) Starlink is improving any satellite gear in successive launches. And, if that's the case, what would be the upper limit to what's possible with the system?

I ask the first question because Starlink has been deorbiting quite a few satellites...

https://spacenews.com/spacex-launches-starlink-satellites-as-it-deorbits-original-ones/

https://www.space.com/spacex-starlink-satellite-deorbit-video

... while launching many new ones. 

For example, there will be a Falcon launch from Vandenberg, of several dozen satellites, at 10:30 (or :40) PM Pacific time on Wednesday night (though there are conflicting reports, and launches often get canceled):

https://www.edhat.com/news/spacex-starlink-launch-rescheduled-for-tuesday

https://www.spacelaunchschedule.com/category/vandenberg-sfb/

https://www.space.com/spacex-starlink-group-3-4-launch-rocket-landing

https://www.ksby.com/news/local-news/spacex-targets-tuesday-night-for-falcon-9-launch-of-starlink-satellites

A late evening launch time makes for good viewing because it's dark enough to see the launch from a distance, and the rocket hits sunlight at the edge of space, where exhaust moves outward in all directions uncontained by atmosphere, leaving a tubular trail in the sky.

Here is a collection of screen grabs from a camcorder recording of a launch in 2005: https://www.flickr.com/photos/docsearls/albums/999576 This launch will be later in the evening, but still quite visible. One big difference will be the return trip of the first stage to a platform out in the ocean. I caught one of those in this series of shots here: https://www.flickr.com/photos/docsearls/albums/72157701027229232

(Forgive my indulgence in space-freakery. I do enjoy this stuff, and I'm not here in Santa Barbara often enough. But I am here now, so I'll be shooting it again, this time with a new camera and a longer lens.)

Doc

> On Aug 30, 2022, at 9:53 AM, David P. Reed via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
> I have no clue why this matters (other than this is in color).
>  
> The phased array antennas used by Starlink are quite limited - in particular, there are 4 on each satellite and each earth-ground path is half-duplex, TDM, essentially. Limited by hardware. The problem of signal equalization and quantization limits prevent "space division multiplexing" and "frequency division multiplexing" in practice.
>  
> The 4 msec "turnaround time" at the physical level (satellite) means that time from a packet arriving at one end to be sent to the other end of the sat-dishy links gets worse the more dishys are served by one of the 4 antennas on the satellite. 
> 
> trying to increase the coverage of an individual satellite basically means serving more dishys per satellite, with less total bit rate, and much longer latency due to the half duplexness.
>  
> Now if the total bit rate of a sat-to-dishy link were, say, 1 Gigabit, like an 802.11ac AP gives you, and the turnaround time were under 1 microsecond rather than 4 msec.  maybe then you could get reasonable Internet service to dishys.
>  
> But 240 Mb/s or 172 Mb/s as proposed for getting a bit more coverage per satellite? This is nowhere near competitive with what we expect in the US. 
>  
> Sorry to rain on all the techy dreaming.
>  
> First, it's worth looking at all the problems currently in WiFi performance when you share an AP with multiple active stations using 100's of Gb/s on the average (not just occasionally).
>  
> Dave - you tried in "make-wifi-fast", and the architecture gets in the way there. (yeah you can get point to point gigabit/sec single file transfers, but to do that you invoke features that destroy latency and introduce huge variability if you share the AP at all, for these reasons).
>  
> Starlink is a good "last resort" service as constituted. But fiber and last few-hundred meters wireless is SO much better able to deliver good Internet service scalably.
> Even that assumes fixing the bufferbloat that the Starlink folks don't seem to be able to address...
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Starlink "beam spread"

[Mike Puchol]

[-- Attachment #1: Type: text/plain, Size: 8682 bytes --]

Given that I may have triggered this, and with my limited understanding of how Starlink is put together from a resource allocation standpoint, first, some caveats:

• A simulation without inside knowledge is always going to be an approximation. In my case, it’s usually the best-case scenario.
• The simulation of a country should not be done in isolation to increase realism. Many of the satellites over the northern US are also serving Canada, which means there are less resources available to US cells than the simulation portrays.
• The real constellation would allocate resources based on demand, primarily, and Starlink knows said demand quite accurately (once ESIMs are in place, this will change!). Thus, cells which are in very densely populated areas, which I include, would likely receive very few resources, if any. Many empty cells or those with no customers won’t receive resources either.

Starlink has essentially these mechanisms to increase the number of cells covered by the constellation at any given time (others like number of beams are fixed in hardware):

• TDM aka beamhopping: split 100% of “airtime” into frames, and allocate certain number of frames to more than one cell. Can provide asymmetric capacity based on demand per cell. The switching time from cell to cell is the driver for how far you can split the beam in the time domain, before the switching overhead starts killing performance.

• Beam spread: as the beam is steered away from nadir, it becomes larger and elliptical, thus covering more than one cell (apart from the target cell). Allows to split the beam resources allocated to the center cell amongst all other cells in the FOR (field of regard). Cannot be asymmetric without enforcing terminal discipline, where each terminal is receiving 100% of the downlink (which could be 10% of the full beam if TDM splits into 10 cells), but is only grabbing what is addressed to it specifically (akin to an LTE network).

• Multiple beams over a single cell: up to eight spot beams can be projected onto a single cell without running into EPFD limits, as long as each one uses one of the eight frequencies available. These simultaneous beams could come from one or more satellites. This is how you can get additional capacity to a cell, for example, to compensate for reduction by TDM. Two beams at 50% duty cycle make up for one full beam. The advantage is spatial diversity, where a terminal that has one satellite obstructed could opt from a beam from a different, non-obstructed satellite.

We must also understand provisioned vs. advertised capacity. In Kenya, we provision 1.5 Mbps per customer, but advertise and sell a 5 Mbps service. Actual average per customer is 1.2 Mbps. If we took a single beam capable of 700 Mbps (many observations and circumstantial evidence support this figure), at 1.5 Mbps provisioned it would serve ~466 customers. Once you start applying TDM, beam spread, etc. the number reduces, and can only be compensated by adding additional beams. It’d be interesting to hear what ISPs in the US provision their customers with.

Of course fiber is the top option if you can get it economically, but if there are vast regions of the US (not considered a developing country) still not serviced by it, or even by fast WISPs, then there are reasons to look for alternatives - I’m willing to bet a financial analysis doesn’t warrant laying thousands of kilometers of fiber to serve relatively few customers. Starlink is providing significant service levels to people who could only dream, with all its growing pains and inefficiencies.

If you start talking about “connecting the unconnected” (a kitten dies every time that one is said), then fiber is one option, but it becomes more relevant for major backhaul, not even middle or last mile. People who have a disposable income of $1 to $5 per month just cannot be serviced by a financially viable service that relies on fiber. Here, you need to start getting creative.

Best,

Mike
On Aug 30, 2022, 19:32 +0200, Doc Searls via Starlink <starlink@lists.bufferbloat.net>, wrote:
> All good points.
>
> I'm also wondering if (and how) Starlink is improving any satellite gear in successive launches. And, if that's the case, what would be the upper limit to what's possible with the system?
>
> I ask the first question because Starlink has been deorbiting quite a few satellites...
>
> https://spacenews.com/spacex-launches-starlink-satellites-as-it-deorbits-original-ones/
>
> https://www.space.com/spacex-starlink-satellite-deorbit-video
>
> ... while launching many new ones.
>
> For example, there will be a Falcon launch from Vandenberg, of several dozen satellites, at 10:30 (or :40) PM Pacific time on Wednesday night (though there are conflicting reports, and launches often get canceled):
>
> https://www.edhat.com/news/spacex-starlink-launch-rescheduled-for-tuesday
>
> https://www.spacelaunchschedule.com/category/vandenberg-sfb/
>
> https://www.space.com/spacex-starlink-group-3-4-launch-rocket-landing
>
> https://www.ksby.com/news/local-news/spacex-targets-tuesday-night-for-falcon-9-launch-of-starlink-satellites
>
> A late evening launch time makes for good viewing because it's dark enough to see the launch from a distance, and the rocket hits sunlight at the edge of space, where exhaust moves outward in all directions uncontained by atmosphere, leaving a tubular trail in the sky.
>
> Here is a collection of screen grabs from a camcorder recording of a launch in 2005: https://www.flickr.com/photos/docsearls/albums/999576 This launch will be later in the evening, but still quite visible. One big difference will be the return trip of the first stage to a platform out in the ocean. I caught one of those in this series of shots here: https://www.flickr.com/photos/docsearls/albums/72157701027229232
>
> (Forgive my indulgence in space-freakery. I do enjoy this stuff, and I'm not here in Santa Barbara often enough. But I am here now, so I'll be shooting it again, this time with a new camera and a longer lens.)
>
> Doc
>
> > On Aug 30, 2022, at 9:53 AM, David P. Reed via Starlink <starlink@lists.bufferbloat.net> wrote:
> >
> > I have no clue why this matters (other than this is in color).
> >
> > The phased array antennas used by Starlink are quite limited - in particular, there are 4 on each satellite and each earth-ground path is half-duplex, TDM, essentially. Limited by hardware. The problem of signal equalization and quantization limits prevent "space division multiplexing" and "frequency division multiplexing" in practice.
> >
> > The 4 msec "turnaround time" at the physical level (satellite) means that time from a packet arriving at one end to be sent to the other end of the sat-dishy links gets worse the more dishys are served by one of the 4 antennas on the satellite.
> >
> > trying to increase the coverage of an individual satellite basically means serving more dishys per satellite, with less total bit rate, and much longer latency due to the half duplexness.
> >
> > Now if the total bit rate of a sat-to-dishy link were, say, 1 Gigabit, like an 802.11ac AP gives you, and the turnaround time were under 1 microsecond rather than 4 msec. maybe then you could get reasonable Internet service to dishys.
> >
> > But 240 Mb/s or 172 Mb/s as proposed for getting a bit more coverage per satellite? This is nowhere near competitive with what we expect in the US.
> >
> > Sorry to rain on all the techy dreaming.
> >
> > First, it's worth looking at all the problems currently in WiFi performance when you share an AP with multiple active stations using 100's of Gb/s on the average (not just occasionally).
> >
> > Dave - you tried in "make-wifi-fast", and the architecture gets in the way there. (yeah you can get point to point gigabit/sec single file transfers, but to do that you invoke features that destroy latency and introduce huge variability if you share the AP at all, for these reasons).
> >
> > Starlink is a good "last resort" service as constituted. But fiber and last few-hundred meters wireless is SO much better able to deliver good Internet service scalably.
> > Even that assumes fixing the bufferbloat that the Starlink folks don't seem to be able to address...
> > _______________________________________________
> > Starlink mailing list
> > Starlink@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/starlink
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

[-- Attachment #2: Type: text/html, Size: 9557 bytes --]

Re: [Starlink] Starlink "beam spread"

[Daniel AJ Sokolov]

On 2022-08-30 at 13:09, Mike Puchol via Starlink wrote:
> People who have a disposable income of $1 to $5 per month just cannot
> be serviced by a financially viable service that relies on fiber.
> Here, you need to start getting creative.

Indeed, but they can't afford Starlink either.
Daniel

Re: [Starlink] Starlink "beam spread"

[Mike Puchol]

[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]

Indeed, and that’s why I said you need to start getting creative.

If I can get a terminal that supplies 150 Mbps, I can provision 1.5 Mbps per customer to 100 customers. I can get a cheap OLT and run no more than 500 meters of EPON (cheaper than GPON) from the Starlink terminal, using splitters along the way, thus minimize risk of breaks and cuts. An EPON OLT supports 64 ONUs per port, so my cost is about $400 plus two SFPs at $50, total central CAPEX per customer $5. I amortize that with one month of service fee at $5...

I won’t do the full breakdown but you should get the idea :-)

Best,

Mike
On Aug 30, 2022, 22:36 +0200, Daniel AJ Sokolov via Starlink <starlink@lists.bufferbloat.net>, wrote:
> On 2022-08-30 at 13:09, Mike Puchol via Starlink wrote:
> > People who have a disposable income of $1 to $5 per month just cannot
> > be serviced by a financially viable service that relies on fiber.
> > Here, you need to start getting creative.
>
> Indeed, but they can't afford Starlink either.
> Daniel
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

[-- Attachment #2: Type: text/html, Size: 1771 bytes --]

Re: [Starlink] Starlink "beam spread"

[David Lang]

On Tue, 30 Aug 2022, David P. Reed via Starlink wrote:

> Starlink is a good "last resort" service as constituted. But fiber and last few-hundred meters wireless is SO much better able to deliver good Internet service scalably.

You are absolutly correct that people who can get fiber (and probably even most 
DSL) are far better using that than Starlink, and last-few-hundred-meters 
wireless can be better (like DSL, it depends on the exact service available)

But stating this as if it means problems for Starlink is a strawman argument.

People who can get that sort of service are not the target users for Starlink. 
The vast majority of the land area in the US does not have such service 
available (for that matter, as the T-Mobile/SpaceX announcement pointed out, the 
vast majority of the land area in the US does not even have voice/text cell 
coverage). Those areas (plus mobile use, RVs, boats, aircraft, event coverage, 
disaster coverage, etc) are what Starlink is aimed at.

Admittedly, some of these needs could be covered by last-few-hundred-meters 
wireless, but such services also are limited in the number of users they 
support, and their detractors point out how they are massive fails when compared 
to wired service, so they are far from ubiquitous, they need just the right 
conditions (enough users in range to be profitable, but not so many that they 
are wll served by wired service)

My sister was on a wireless service, and the best that they could provide was 
2Mb (and that was more weather sensitive than Starlink is), Starlink is a game 
changer for her family.

David Lang
In Theory, Theory and Practice are the same, In Practice they are different.

Re: [Starlink] Starlink "beam spread"

[David Lang]

[-- Attachment #1: Type: text/plain, Size: 1363 bytes --]

On Tue, 30 Aug 2022, Mike Puchol via Starlink wrote:

> • Multiple beams over a single cell: up to eight spot beams can be projected 
> onto a single cell without running into EPFD limits, as long as each one uses 
> one of the eight frequencies available. These simultaneous beams could come 
> from one or more satellites. This is how you can get additional capacity to a 
> cell, for example, to compensate for reduction by TDM. Two beams at 50% duty 
> cycle make up for one full beam. The advantage is spatial diversity, where a 
> terminal that has one satellite obstructed could opt from a beam from a 
> different, non-obstructed satellite.

you can also have multiple beams per cell by talking to satellites that are 
sufficiently far apart that the ground station can form it's beam to hit one 
satellite without interfering with the other. The groudn receivers that are 
listening to multiple satellites on the same frequency will have a higher noise 
level, but can still use beam forming to hear one more efficiently than another.

lower altitude satelites also reduce the cell size (improving frequency re-use), 
and Starlink is intending to start putting up sats (340Km vs the current 550Km)

The Starlink V2 satllites are also significantly larger, with more and larger 
antennas, which translates into more beams, and tighter beams.

David Lang

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Starlink "beam spread"

[Brandon Butterworth]

On Tue Aug 30, 2022 at 02:01:49PM -0700, David Lang via Starlink wrote:
> You are absolutly correct that people who can get fiber (and probably even 
> most DSL) are far better using that than Starlink, and 
> last-few-hundred-meters wireless can be better (like DSL, it depends on the 
> exact service available)
 ...
> People who can get that sort of service are not the target users for 
> Starlink.

But unless Starlink turn them away some will still take the
service despite better options.

I do UK FWA and FTTP in rural areas and know others in the
industry. Some have reported being turned down as the
odd customer is waiting for Starlink (instead of taking a
government GBP4k+ subsidy giving them free fibre/FWA install)

There's no telling some people.

brandon

Re: [Starlink] Starlink "beam spread"

[David Lang]

On Tue, 30 Aug 2022, Brandon Butterworth wrote:

> On Tue Aug 30, 2022 at 02:01:49PM -0700, David Lang via Starlink wrote:
>> You are absolutly correct that people who can get fiber (and probably even
>> most DSL) are far better using that than Starlink, and
>> last-few-hundred-meters wireless can be better (like DSL, it depends on the
>> exact service available)
> ...
>> People who can get that sort of service are not the target users for
>> Starlink.
>
> But unless Starlink turn them away some will still take the
> service despite better options.

Sure, and I am one of them. (I have cable service Internet available), but if 
people are picking something in spite of 'better' service being available, 
is it really 'better' for that person, or is it only 'better' on paper?

Why should you argue with people who make that decision?

I actually have both cable service and starlink, I make my living by working 
remotely, and it's worth it to me to have a backup Internet service available 
(and I don't have fiber availale here in the middle of a city in Southern 
California, and the best DSL at my location is 8/1 @$150/month for a 
dual-dedicated line)

David Lang

Re: [Starlink] Starlink "beam spread"

[Brandon Butterworth]

On Tue Aug 30, 2022 at 03:21:50PM -0700, David Lang wrote:
> Why should you argue with people who make that decision?

There is no arguing, low take up does however make it harder
to cover the rest of the community if there are many hold outs.

> best DSL at my location is 8/1 @$150/month for 
> a dual-dedicated line)

I (not BBC) sell 1G symmetical AE FTTP for GBP35 in rural Scotland.

brandon

Re: [Starlink] Starlink "beam spread"

[Ulrich Speidel]

[-- Attachment #1: Type: text/plain, Size: 3523 bytes --]

There's another aspect here that is often overlooked when looking purely 
at the data rate that you can get from your fibre/cable/wifi/satellite, 
and this is where the data comes from.

A large percentage of Internet content these days comes from content 
delivery networks (CDNs). These innately work on the assumption that 
it's the core of the Internet that presents a bottleneck, and that the 
aggregate bandwidth of all last mile connections is high in comparison. 
A second assumption is that a large share of the content that gets 
requested gets requested many times, and many times by users in the same 
corner(s) of the Internet. The conclusion is that therefore content is 
best served from a location close to the end user, so as to keep RTTs 
low and - importantly - keep the load of long distance bottleneck links.

Now it's fairly clear that large numbers of fibres to end users make for 
the best kind of network between CDN and end user. Local WiFi hotspots 
with limited range allow frequency re-use, as do ground based cellular 
networks, so they're OK, too, in that respect.  But anything that needs 
to project RF energy over a longer distance to get directly to the end 
user hasn't got nature on its side.

This is, IMHO, Starlink's biggest design flaw at the moment: Going 
direct to end user site rather providing a bridge to a local ISP may be 
circumventing the lack of last mile infrastructure in the US, but it 
also makes incredibly inefficient use of spectrum and satellite 
resource. If every viral cat video that a thousand Starlink users in 
Iowa are just dying to see literally has to go to space a thousand times 
and back again rather than once, you arguably have a problem.

And yes, small neighbourhood networks of the type Mike described could 
put a significant dent into that problem. But do Starlink actually see 
Mike supplying 100 people as helpful, or do they see it as 99 customers 
they can no longer sell a dishy to? Given how they push their services 
into the market, I suspect it might be the latter.

On 31/08/2022 10:07 am, Brandon Butterworth via Starlink wrote:
> On Tue Aug 30, 2022 at 02:01:49PM -0700, David Lang via Starlink wrote:
> > You are absolutly correct that people who can get fiber (and 
> probably even
> > most DSL) are far better using that than Starlink, and
> > last-few-hundred-meters wireless can be better (like DSL, it depends 
> on the
> > exact service available)
> ...
> > People who can get that sort of service are not the target users for
> > Starlink.
>
> But unless Starlink turn them away some will still take the
> service despite better options.
>
> I do UK FWA and FTTP in rural areas and know others in the
> industry. Some have reported being turned down as the
> odd customer is waiting for Starlink (instead of taking a
> government GBP4k+ subsidy giving them free fibre/FWA install)
>
> There's no telling some people.
>
> brandon
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink 
> <https://lists.bufferbloat.net/listinfo/starlink>

-- 
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz  
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************



[-- Attachment #2: Type: text/html, Size: 4599 bytes --]

Re: [Starlink] Starlink "beam spread"

[David Lang]

On Tue, 30 Aug 2022, Brandon Butterworth wrote:

>> best DSL at my location is 8/1 @$150/month for
>> a dual-dedicated line)
>
> I (not BBC) sell 1G symmetical AE FTTP for GBP35 in rural Scotland.

but that's not available where I am (my city did just sign a deal to get fiber 
layed throughout the city over the next few years, so this will change)

people need to stop thinking that because fiber is available where you live, 
everyone has access to it. I'm in one of the largest population centers in the 
US, not out in the boonies, and what I have is limited.

David Lang

Re: [Starlink] Starlink "beam spread"

[David Lang]

[-- Attachment #1: Type: text/plain, Size: 4104 bytes --]

They are going for simple to use. That favors per-location uses. I haven't seen 
them doing anything to discourage local ISP type networks, and some of the 
things I've seen them do (in terms of starlink to remote Indian villages) seems 
like they are probably doing a single Starlink + local wifi.

Their 'business' version seems ideal for this local ISP approach.

But that takes someone on the ground willing to take the work on to 
build/maintain such a network. Not hard for someone who knows what they are 
doing and has an in with the local regulators, but for SpaceX to push it would 
be a distraction to their staff and bring on even more accusations of their 
service being unsuitable (remember, this started off from the claim that a 
dedicated dish per house wasn't acceptably fast)

David Lang

On Wed, 31 Aug 2022, Ulrich Speidel via Starlink wrote:

> There's another aspect here that is often overlooked when looking purely at 
> the data rate that you can get from your fibre/cable/wifi/satellite, and this 
> is where the data comes from.
>
> A large percentage of Internet content these days comes from content delivery 
> networks (CDNs). These innately work on the assumption that it's the core of 
> the Internet that presents a bottleneck, and that the aggregate bandwidth of 
> all last mile connections is high in comparison. A second assumption is that 
> a large share of the content that gets requested gets requested many times, 
> and many times by users in the same corner(s) of the Internet. The conclusion 
> is that therefore content is best served from a location close to the end 
> user, so as to keep RTTs low and - importantly - keep the load of long 
> distance bottleneck links.
>
> Now it's fairly clear that large numbers of fibres to end users make for the 
> best kind of network between CDN and end user. Local WiFi hotspots with 
> limited range allow frequency re-use, as do ground based cellular networks, 
> so they're OK, too, in that respect.  But anything that needs to project RF 
> energy over a longer distance to get directly to the end user hasn't got 
> nature on its side.
>
> This is, IMHO, Starlink's biggest design flaw at the moment: Going direct to 
> end user site rather providing a bridge to a local ISP may be circumventing 
> the lack of last mile infrastructure in the US, but it also makes incredibly 
> inefficient use of spectrum and satellite resource. If every viral cat video 
> that a thousand Starlink users in Iowa are just dying to see literally has to 
> go to space a thousand times and back again rather than once, you arguably 
> have a problem.
>
> And yes, small neighbourhood networks of the type Mike described could put a 
> significant dent into that problem. But do Starlink actually see Mike 
> supplying 100 people as helpful, or do they see it as 99 customers they can 
> no longer sell a dishy to? Given how they push their services into the 
> market, I suspect it might be the latter.
>
> On 31/08/2022 10:07 am, Brandon Butterworth via Starlink wrote:
>> On Tue Aug 30, 2022 at 02:01:49PM -0700, David Lang via Starlink wrote:
>> > You are absolutly correct that people who can get fiber (and probably 
>> even
>> > most DSL) are far better using that than Starlink, and
>> > last-few-hundred-meters wireless can be better (like DSL, it depends on 
>> the
>> > exact service available)
>> ...
>> > People who can get that sort of service are not the target users for
>> > Starlink.
>> 
>> But unless Starlink turn them away some will still take the
>> service despite better options.
>> 
>> I do UK FWA and FTTP in rural areas and know others in the
>> industry. Some have reported being turned down as the
>> odd customer is waiting for Starlink (instead of taking a
>> government GBP4k+ subsidy giving them free fibre/FWA install)
>> 
>> There's no telling some people.
>> 
>> brandon
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink 
>> <https://lists.bufferbloat.net/listinfo/starlink>
>
>

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Starlink "beam spread"

[David P. Reed]

[-- Attachment #1: Type: text/plain, Size: 1113 bytes --]


I wasn't starting a discussion about Starlink the business. I was talking about Starlink the technology and the "dreams" that people project onto that technology.
 
I'm happy if the current customers are happy and remain happy. Just pointing out that there are pretty severe limitations in the physical capabilities of the technology of the satellites and dishys that will limit how many customers can be served in an area.
 
I was reacting to the idea Dave Taht brought up that somehow the satellites can cover "more" area per satellite, if they go to a lower total bit rate (175 vs. 240 per antenna on each satellite).
 
I'm a radio engineer, trained in stuff like phased array antenna designs, and power, etc. I'm also a communications protocol engineer, trained in multiplexing techniques.
 
I'm not saying Starlink engineers are incompetent, but I am saying that what Musk (who despite the fact that he pretends to be an engineer is not one, never has been one) has described in his visionary speeches is not what Starlink is delivering today, and that's because it basically can't be delivered.
 

[-- Attachment #2: Type: text/html, Size: 2151 bytes --]

Re: [Starlink] Starlink "beam spread"

[Brandon Butterworth]

On Tue Aug 30, 2022 at 04:07:36PM -0700, David Lang wrote:
> people need to stop thinking that because fiber is available where you 
> live, everyone has access to it

On the contrary, it's still not available where I am in London, and that
location was even worse off (sub 1Mb/s DSL in 2017 when we started).

The point of going agressively good was to shame the larger incumbents
to do better. The altnet industry suceeded and now it's being rolled out
in cities too though still a few years away here.

At the time I could not have built this in a city so doing rural
served two purposes - help those without, help get everyone done
sometime the only way to progress things is by direct or
indirect action.

I recognise USA has other issues making it harder.

brandon

Re: [Starlink] Starlink "beam spread"

[David Lang]

I have no problems with people making technical arguments saying that there are 
limitations on the service that Starlink can provide (I may argue technical 
specifics or point out things I think you miss, but I won't claim that you are 
arguing in bad faith), but when someone then goes beyond that and says that what 
it can provide is a level that's unacceptable to Americans or dismissing it 
because fiber is better, then I'll respond and say that the person is arguing in 
bad faith.

David Lang


On Tue, 30 Aug 2022, David P. Reed wrote:

> Date: Tue, 30 Aug 2022 19:28:56 -0400 (EDT)
> From: David P. Reed <dpreed@deepplum.com>
> To: Brandon Butterworth <brandon@rd.bbc.co.uk>
> Cc: David Lang <david@lang.hm>, Brandon Butterworth <brandon@rd.bbc.co.uk>,
>     starlink@lists.bufferbloat.net
> Subject: Re: [Starlink] Starlink "beam spread"
> 
>
> I wasn't starting a discussion about Starlink the business. I was talking about Starlink the technology and the "dreams" that people project onto that technology.
> 
> I'm happy if the current customers are happy and remain happy. Just pointing out that there are pretty severe limitations in the physical capabilities of the technology of the satellites and dishys that will limit how many customers can be served in an area.
> 
> I was reacting to the idea Dave Taht brought up that somehow the satellites can cover "more" area per satellite, if they go to a lower total bit rate (175 vs. 240 per antenna on each satellite).
> 
> I'm a radio engineer, trained in stuff like phased array antenna designs, and power, etc. I'm also a communications protocol engineer, trained in multiplexing techniques.
> 
> I'm not saying Starlink engineers are incompetent, but I am saying that what Musk (who despite the fact that he pretends to be an engineer is not one, never has been one) has described in his visionary speeches is not what Starlink is delivering today, and that's because it basically can't be delivered.

Re: [Starlink] Starlink "beam spread"

[Dave Taht]

My central thesis has long been that 25/5 mbit service - debloated -
was more than good enough for your typical family of 4, no matter the
country, WFH, or not.

Re: [Starlink] Starlink "beam spread"

[David P. Reed]

[-- Attachment #1: Type: text/plain, Size: 2442 bytes --]


Then Elon Musk is making proposals in bad faith, because he is leading people to believe that his system can do stuff it clearly cannot do.
 
Which they proved when they failed to meet the requirements of the US rural service funding program, after claiming they could.
 
On Tuesday, August 30, 2022 8:12pm, "David Lang" <david@lang.hm> said:



> I have no problems with people making technical arguments saying that there are
> limitations on the service that Starlink can provide (I may argue technical
> specifics or point out things I think you miss, but I won't claim that you are
> arguing in bad faith), but when someone then goes beyond that and says that what
> it can provide is a level that's unacceptable to Americans or dismissing it
> because fiber is better, then I'll respond and say that the person is arguing in
> bad faith.
> 
> David Lang
> 
> 
> On Tue, 30 Aug 2022, David P. Reed wrote:
> 
> > Date: Tue, 30 Aug 2022 19:28:56 -0400 (EDT)
> > From: David P. Reed <dpreed@deepplum.com>
> > To: Brandon Butterworth <brandon@rd.bbc.co.uk>
> > Cc: David Lang <david@lang.hm>, Brandon Butterworth
> <brandon@rd.bbc.co.uk>,
> > starlink@lists.bufferbloat.net
> > Subject: Re: [Starlink] Starlink "beam spread"
> >
> >
> > I wasn't starting a discussion about Starlink the business. I was talking
> about Starlink the technology and the "dreams" that people project onto that
> technology.
> >
> > I'm happy if the current customers are happy and remain happy. Just pointing
> out that there are pretty severe limitations in the physical capabilities of the
> technology of the satellites and dishys that will limit how many customers can be
> served in an area.
> >
> > I was reacting to the idea Dave Taht brought up that somehow the satellites
> can cover "more" area per satellite, if they go to a lower total bit rate (175 vs.
> 240 per antenna on each satellite).
> >
> > I'm a radio engineer, trained in stuff like phased array antenna designs, and
> power, etc. I'm also a communications protocol engineer, trained in multiplexing
> techniques.
> >
> > I'm not saying Starlink engineers are incompetent, but I am saying that what
> Musk (who despite the fact that he pretends to be an engineer is not one, never
> has been one) has described in his visionary speeches is not what Starlink is
> delivering today, and that's because it basically can't be delivered.
> 

[-- Attachment #2: Type: text/html, Size: 3505 bytes --]

Re: [Starlink] Starlink "beam spread"

[tom]

[-- Attachment #1: Type: text/plain, Size: 4597 bytes --]

I think that CDNs will initially collocate some servers at SL uplink/downlink sites and then, eventually, in space where they can be accessed by sat-sat links. This sems a natural extension of business model both for CDNs and for SL and other satellite providers. For starters, there’s no good reason why a DNS query should take four hops. The more content that moves to space, the faster the response time for SL and the less load on its uplink/downlink sites. I speculated more about that evolution here The Internet and The Cloud Are Going into Space <https://blog.tomevslin.com/2021/07/the-internet-and-the-cloud-are-going-into-space.html>  and speculated that there will also be orbital cloud computing centers for many reasons including solar power Computing Clouds in Orbit – A Possible Roadmap <https://blog.tomevslin.com/2021/07/computing-clouds-in-orbit-a-possible-roadmap.html> 

 

 

 

From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of Ulrich Speidel via Starlink
Sent: Tuesday, August 30, 2022 6:51 PM
To: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] Starlink "beam spread"

 

There's another aspect here that is often overlooked when looking purely at the data rate that you can get from your fibre/cable/wifi/satellite, and this is where the data comes from.

A large percentage of Internet content these days comes from content delivery networks (CDNs). These innately work on the assumption that it's the core of the Internet that presents a bottleneck, and that the aggregate bandwidth of all last mile connections is high in comparison. A second assumption is that a large share of the content that gets requested gets requested many times, and many times by users in the same corner(s) of the Internet. The conclusion is that therefore content is best served from a location close to the end user, so as to keep RTTs low and - importantly - keep the load of long distance bottleneck links.

Now it's fairly clear that large numbers of fibres to end users make for the best kind of network between CDN and end user. Local WiFi hotspots with limited range allow frequency re-use, as do ground based cellular networks, so they're OK, too, in that respect.  But anything that needs to project RF energy over a longer distance to get directly to the end user hasn't got nature on its side.

This is, IMHO, Starlink's biggest design flaw at the moment: Going direct to end user site rather providing a bridge to a local ISP may be circumventing the lack of last mile infrastructure in the US, but it also makes incredibly inefficient use of spectrum and satellite resource. If every viral cat video that a thousand Starlink users in Iowa are just dying to see literally has to go to space a thousand times and back again rather than once, you arguably have a problem.

And yes, small neighbourhood networks of the type Mike described could put a significant dent into that problem. But do Starlink actually see Mike supplying 100 people as helpful, or do they see it as 99 customers they can no longer sell a dishy to? Given how they push their services into the market, I suspect it might be the latter. 

On 31/08/2022 10:07 am, Brandon Butterworth via Starlink wrote:

On Tue Aug 30, 2022 at 02:01:49PM -0700, David Lang via Starlink wrote:
> You are absolutly correct that people who can get fiber (and probably even 
> most DSL) are far better using that than Starlink, and 
> last-few-hundred-meters wireless can be better (like DSL, it depends on the 
> exact service available)
...
> People who can get that sort of service are not the target users for 
> Starlink.

But unless Starlink turn them away some will still take the
service despite better options.

I do UK FWA and FTTP in rural areas and know others in the
industry. Some have reported being turned down as the
odd customer is waiting for Starlink (instead of taking a
government GBP4k+ subsidy giving them free fibre/FWA install)

There's no telling some people.

brandon
_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net> 
https://lists.bufferbloat.net/listinfo/starlink

-- 
****************************************************************
Dr. Ulrich Speidel
 
School of Computer Science
 
Room 303S.594 (City Campus)
 
The University of Auckland
u.speidel@auckland.ac.nz <mailto:u.speidel@auckland.ac.nz>  
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************
 
 
 

[-- Attachment #2: Type: text/html, Size: 7555 bytes --]

Re: [Starlink] Starlink "beam spread"

[Dave Taht]

I think f-root dns servers in LEO makes a lot of sense. It's not a lot
of data, nor does it require much cpu. and dns lookups are a frequent
source of major latency.

CDN in space, well, how much mass, energy, does a set of spindles
need? Can raid arrays of modern flash or disk survive serious SEVs?

Re: [Starlink] Starlink "beam spread"

[Sebastian Moeller]

Hi Ulrich,

On 31 August 2022 00:50:35 CEST, Ulrich Speidel via Starlink <starlink@lists.bufferbloat.net> wrote:
>There's another aspect here that is often overlooked when looking purely at the data rate that you can get from your fibre/cable/wifi/satellite, and this is where the data comes from.
>
>A large percentage of Internet content these days comes from content delivery networks (CDNs). These innately work on the assumption that it's the core of the Internet that presents a bottleneck, and that the aggregate bandwidth of all last mile connections is high in comparison. A second assumption is that a large share of the content that gets requested gets requested many times, and many times by users in the same corner(s) of the Internet. The conclusion is that therefore content is best served from a location close to the end user, so as to keep RTTs low and - importantly - keep the load of long distance bottleneck links.
>
>Now it's fairly clear that large numbers of fibres to end users make for the best kind of network between CDN and end user. Local WiFi hotspots with limited range allow frequency re-use, as do ground based cellular networks, so they're OK, too, in that respect.  But anything that needs to project RF energy over a longer distance to get directly to the end user hasn't got nature on its side.
>
>This is, IMHO, Starlink's biggest design flaw at the moment: Going direct to end user site rather providing a bridge to a local ISP may be circumventing the lack of last mile infrastructure in the US, but it also makes incredibly inefficient use of spectrum and satellite resource. If every viral cat video that a thousand Starlink users in Iowa are just dying to see literally has to go to space a thousand times and back again rather than once, you arguably have a problem.

        Why? Internet access service is predominantly a service to transport any packets the users send and request when they do so. Caching content closer to the users or multicast tricks are basically optimizations that (occasionally) help decrease costs/increase margins for the operator, but IMHO they are exactly that, optimizations. So if they can not be used, no harm is done. Since caching is not perfect, such optimisations really are no way to safely increase the oversubscription rate either. Mind you I am not saying such measures are useless, but in IAS I consider them to be optional. Ideas about caching in space seem a bit pie-in-the-sky (pun intended) since at 4ms delay this would only help if operating CDNs in space would be cheaper than on earth at the base station or if the ground to satellite capacity was smaller then the aggregate satellite to end user capacity (both per satellite), no? 

Regards
        P.

P.S.: I think the same applies to GSM/LTE/5G basestations, as far as I can see 'edge' servuces (storage or compute) are interesting options for ISPs to offer higher ARPU products than commodity IAS, and not things required for a functional internet. Again nothing bad about offering such services, just they are optional.


>
>And yes, small neighbourhood networks of the type Mike described could put a significant dent into that problem. But do Starlink actually see Mike supplying 100 people as helpful, or do they see it as 99 customers they can no longer sell a dishy to? Given how they push their services into the market, I suspect it might be the latter.
>
>On 31/08/2022 10:07 am, Brandon Butterworth via Starlink wrote:
>> On Tue Aug 30, 2022 at 02:01:49PM -0700, David Lang via Starlink wrote:
>> > You are absolutly correct that people who can get fiber (and probably even
>> > most DSL) are far better using that than Starlink, and
>> > last-few-hundred-meters wireless can be better (like DSL, it depends on the
>> > exact service available)
>> ...
>> > People who can get that sort of service are not the target users for
>> > Starlink.
>> 
>> But unless Starlink turn them away some will still take the
>> service despite better options.
>> 
>> I do UK FWA and FTTP in rural areas and know others in the
>> industry. Some have reported being turned down as the
>> odd customer is waiting for Starlink (instead of taking a
>> government GBP4k+ subsidy giving them free fibre/FWA install)
>> 
>> There's no telling some people.
>> 
>> brandon
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [Starlink] Starlink "beam spread"

[Ulrich Speidel]

On 31/08/2022 6:26 pm, Sebastian Moeller wrote:
> Hi Ulrich,
>
> On 31 August 2022 00:50:35 CEST, Ulrich Speidel via Starlink 
> <starlink@lists.bufferbloat.net> wrote:
> >There's another aspect here that is often overlooked when looking 
> purely at the data rate that you can get from your 
> fibre/cable/wifi/satellite, and this is where the data comes from.
> >
> >A large percentage of Internet content these days comes from content 
> delivery networks (CDNs). These innately work on the assumption that 
> it's the core of the Internet that presents a bottleneck, and that the 
> aggregate bandwidth of all last mile connections is high in 
> comparison. A second assumption is that a large share of the content 
> that gets requested gets requested many times, and many times by users 
> in the same corner(s) of the Internet. The conclusion is that 
> therefore content is best served from a location close to the end 
> user, so as to keep RTTs low and - importantly - keep the load of long 
> distance bottleneck links.
> >
> >Now it's fairly clear that large numbers of fibres to end users make 
> for the best kind of network between CDN and end user. Local WiFi 
> hotspots with limited range allow frequency re-use, as do ground based 
> cellular networks, so they're OK, too, in that respect.  But anything 
> that needs to project RF energy over a longer distance to get directly 
> to the end user hasn't got nature on its side.
> >
> >This is, IMHO, Starlink's biggest design flaw at the moment: Going 
> direct to end user site rather providing a bridge to a local ISP may 
> be circumventing the lack of last mile infrastructure in the US, but 
> it also makes incredibly inefficient use of spectrum and satellite 
> resource. If every viral cat video that a thousand Starlink users in 
> Iowa are just dying to see literally has to go to space a thousand 
> times and back again rather than once, you arguably have a problem.
>
> Why? Internet access service is predominantly a service to transport 
> any packets the users send and request when they do so. Caching 
> content closer to the users or multicast tricks are basically 
> optimizations that (occasionally) help decrease costs/increase margins 
> for the operator, but IMHO they are exactly that, optimizations. So if 
> they can not be used, no harm is done. Since caching is not perfect, 
> such optimisations really are no way to safely increase the 
> oversubscription rate either. Mind you I am not saying such measures 
> are useless, but in IAS I consider them to be optional. Ideas about 
> caching in space seem a bit pie-in-the-sky (pun intended) since at 4ms 
> delay this would only help if operating CDNs in space would be cheaper 
> than on earth at the base station or if the ground to satellite 
> capacity was smaller then the aggregate satellite to end user capacity 
> (both per satellite), no?

Now, assuming for a moment that your typical Starlink user isn't so 
different from your average Internet user anywhere else in that they 
like to watch Netflix, YouTube, TikTok etc., then having a simple 
"transport layer and below" view of a system that's providing 
connectivity simply isn't enough.

The problem is that - Zoom meetings aside - the vast majority of data 
that enters an end user device these days comes from a CDN server 
somewhere. It's quietly gotten so pervasive that if a major CDN provider 
(or cloud service provider or however they like to refer to themselves 
these days) has an outage, the media will report - incorrectly of course 
- that "the Internet is down". So it's not just something that's 
optional anymore, and hasn't been for a while. It's an integral part of 
the landscape. Access strata folk please take note!

This isn't a (huge) problem on classical mobile networks with base 
stations because of the amount of frequency division multiplexing you 
can do with a combination of high cell density, the ensuing ability to 
communicate with lower power, which enables spatial separation and hence 
frequency reuse. Add beam forming and a few other nice techniques, and 
you're fine. Same with WiFi, essentially. So as data emerges from a CDN 
server (remember, most of this is on demand unicast and not 
broadcasting), it'll initially go into relatively local fibre backbones 
(no bottleneck) and then either onto a fibre to the home, a DSL line, a 
WiFi system, or a terrestrial mobile 4G/5G/6G network, and none of these 
present a bottleneck at any one point.

This is different with satellites, including LEO and Starlink. If your 
CDN or origin server sits at the remote end of the satellite link as 
seen from the end users, then every copy of your cat video (again, 
assuming on-demand here) must transit the link each time it's requested, 
unless there's a cache on the local end that multiple users get their 
copies from. There is just no way around this. As such, the comparison 
of Starlink to GSM/LTE/5G base stations just doesn't work here.

So throw in the "edge" as in "edge" computing. In a direct-to-site 
satellite network, the edgiest bit of the edge is the satellite itself. 
If we put a CDN server (cache if you wish) there, then yes we have saved 
us the repeated use of the link on the uplink side. But we still have 
the downlink to contend with where the video will have to be transmitted 
for each user who wants it. This combines with the uncomfortable truth 
that an RF "beam" from a satellite isn't as selective as a laser beam, 
so the options for frequency re-use from orbit aren't anywhere near as 
good as from a mobile base station across the road: Any beam pointed at 
you can be heard for many miles around and therefore no other user can 
re-use that frequency (with the same burst slot etc.).

So by putting a cache on the server, you've reduced the need for 
multiple redundant transmissions overall by almost half, but this 
doesn't help much because you really need to cut that need by orders of 
magnitude. Moreover, there's another problem: Power. Running CDN servers 
is a power hungry business, as anyone running cloud data centres at 
scale will be happy to attest to (in Singapore, the drain on the power 
network from data centres got so bad that they banned new ones for a 
while). Unfortunately, power is the one thing a LEO satellite that's 
built to achieve minimum weight is going to have least of.

ICN essentially suffers from the same problem when it comes to Starlink 
- if the information (cat video) you want is on the bird and it's 
unicast to you over an encrypted connection, then the video still needs 
to come down 1000 times if 1000 users want to watch it.

-- 

****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************

Re: [Starlink] Starlink "beam spread"

[Hayden Simon]

[-- Attachment #1: Type: text/plain, Size: 7830 bytes --]

Throwing it out here that I love this group. I *really* enjoy that you all understand the challenges, limitations and potential points for optimisation so well.

It’s a significant shift from my daily grind.


HAYDEN SIMON
UBER GROUP LIMITED
MANAGING DIRECTOR - SUPREME OVERLORD
E: h@uber.nz
M: 021 0707 014
W: www.uber.nz
53 PORT ROAD | PO BOX 5083 | WHANGAREI | NEW ZEALAND
-----Original Message-----
From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of Ulrich Speidel via Starlink
Sent: Wednesday, 31 August 2022 7:25 pm
To: Sebastian Moeller <moeller0@gmx.de>; Ulrich Speidel via Starlink <starlink@lists.bufferbloat.net>
Subject: Re: [Starlink] Starlink "beam spread"

On 31/08/2022 6:26 pm, Sebastian Moeller wrote:
> Hi Ulrich,
>
> On 31 August 2022 00:50:35 CEST, Ulrich Speidel via Starlink
> <starlink@lists.bufferbloat.net> wrote:
> >There's another aspect here that is often overlooked when looking
> purely at the data rate that you can get from your
> fibre/cable/wifi/satellite, and this is where the data comes from.
> >
> >A large percentage of Internet content these days comes from content
> delivery networks (CDNs). These innately work on the assumption that
> it's the core of the Internet that presents a bottleneck, and that the
> aggregate bandwidth of all last mile connections is high in
> comparison. A second assumption is that a large share of the content
> that gets requested gets requested many times, and many times by users
> in the same corner(s) of the Internet. The conclusion is that
> therefore content is best served from a location close to the end
> user, so as to keep RTTs low and - importantly - keep the load of long
> distance bottleneck links.
> >
> >Now it's fairly clear that large numbers of fibres to end users make
> for the best kind of network between CDN and end user. Local WiFi
> hotspots with limited range allow frequency re-use, as do ground based
> cellular networks, so they're OK, too, in that respect.  But anything
> that needs to project RF energy over a longer distance to get directly
> to the end user hasn't got nature on its side.
> >
> >This is, IMHO, Starlink's biggest design flaw at the moment: Going
> direct to end user site rather providing a bridge to a local ISP may
> be circumventing the lack of last mile infrastructure in the US, but
> it also makes incredibly inefficient use of spectrum and satellite
> resource. If every viral cat video that a thousand Starlink users in
> Iowa are just dying to see literally has to go to space a thousand
> times and back again rather than once, you arguably have a problem.
>
> Why? Internet access service is predominantly a service to transport
> any packets the users send and request when they do so. Caching
> content closer to the users or multicast tricks are basically
> optimizations that (occasionally) help decrease costs/increase margins
> for the operator, but IMHO they are exactly that, optimizations. So if
> they can not be used, no harm is done. Since caching is not perfect,
> such optimisations really are no way to safely increase the
> oversubscription rate either. Mind you I am not saying such measures
> are useless, but in IAS I consider them to be optional. Ideas about
> caching in space seem a bit pie-in-the-sky (pun intended) since at 4ms
> delay this would only help if operating CDNs in space would be cheaper
> than on earth at the base station or if the ground to satellite
> capacity was smaller then the aggregate satellite to end user capacity
> (both per satellite), no?

Now, assuming for a moment that your typical Starlink user isn't so different from your average Internet user anywhere else in that they like to watch Netflix, YouTube, TikTok etc., then having a simple "transport layer and below" view of a system that's providing connectivity simply isn't enough.

The problem is that - Zoom meetings aside - the vast majority of data that enters an end user device these days comes from a CDN server somewhere. It's quietly gotten so pervasive that if a major CDN provider (or cloud service provider or however they like to refer to themselves these days) has an outage, the media will report - incorrectly of course
- that "the Internet is down". So it's not just something that's optional anymore, and hasn't been for a while. It's an integral part of the landscape. Access strata folk please take note!

This isn't a (huge) problem on classical mobile networks with base stations because of the amount of frequency division multiplexing you can do with a combination of high cell density, the ensuing ability to communicate with lower power, which enables spatial separation and hence frequency reuse. Add beam forming and a few other nice techniques, and you're fine. Same with WiFi, essentially. So as data emerges from a CDN server (remember, most of this is on demand unicast and not broadcasting), it'll initially go into relatively local fibre backbones (no bottleneck) and then either onto a fibre to the home, a DSL line, a WiFi system, or a terrestrial mobile 4G/5G/6G network, and none of these present a bottleneck at any one point.

This is different with satellites, including LEO and Starlink. If your CDN or origin server sits at the remote end of the satellite link as seen from the end users, then every copy of your cat video (again, assuming on-demand here) must transit the link each time it's requested, unless there's a cache on the local end that multiple users get their copies from. There is just no way around this. As such, the comparison of Starlink to GSM/LTE/5G base stations just doesn't work here.

So throw in the "edge" as in "edge" computing. In a direct-to-site satellite network, the edgiest bit of the edge is the satellite itself.
If we put a CDN server (cache if you wish) there, then yes we have saved us the repeated use of the link on the uplink side. But we still have the downlink to contend with where the video will have to be transmitted for each user who wants it. This combines with the uncomfortable truth that an RF "beam" from a satellite isn't as selective as a laser beam, so the options for frequency re-use from orbit aren't anywhere near as good as from a mobile base station across the road: Any beam pointed at you can be heard for many miles around and therefore no other user can re-use that frequency (with the same burst slot etc.).

So by putting a cache on the server, you've reduced the need for multiple redundant transmissions overall by almost half, but this doesn't help much because you really need to cut that need by orders of magnitude. Moreover, there's another problem: Power. Running CDN servers is a power hungry business, as anyone running cloud data centres at scale will be happy to attest to (in Singapore, the drain on the power network from data centres got so bad that they banned new ones for a while). Unfortunately, power is the one thing a LEO satellite that's built to achieve minimum weight is going to have least of.

ICN essentially suffers from the same problem when it comes to Starlink
- if the information (cat video) you want is on the bird and it's unicast to you over an encrypted connection, then the video still needs to come down 1000 times if 1000 users want to watch it.

--

****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************



_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink

[-- Attachment #2: Type: text/html, Size: 14961 bytes --]

Re: [Starlink] Starlink "beam spread"

[David Lang]

On Wed, 31 Aug 2022, Ulrich Speidel via Starlink wrote:

> This combines with the uncomfortable truth 
> that an RF "beam" from a satellite isn't as selective as a laser beam, 
> so the options for frequency re-use from orbit aren't anywhere near as 
> good as from a mobile base station across the road: Any beam pointed at 
> you can be heard for many miles around and therefore no other user can 
> re-use that frequency (with the same burst slot etc.).

not quite, you are forgetting that the antennas on the ground are also steerable 
arrays and so they can focus their 'receiving beam' at different satellites. 
This is less efficient than a transmitting beam as the satellites you aren't 
'pointed' at will increase your noise floor, but it does allow the same 
frequency to be used for multiple satellites into the same area at the same 
time.

David Lang

Re: [Starlink] Starlink "beam spread"

[Mike Puchol]

[-- Attachment #1: Type: text/plain, Size: 1856 bytes --]

A couple of notes on things said in the thread:
> But do Starlink actually see Mike supplying 100 people as helpful, or do they see it as 99 customers they can no longer sell a dishy to? Given how they push their services into the market, I suspect it might be the latter.

This is what we have seen - they started with an expensive service, expensive terminal. They acquired all the early adopters who go for Starlink come what may, price is no object, because they can justify it. Now, they start reducing prices to catch the next “wave” that didn’t see a fit within their needs / finances.

With Africa, even the cheaper pricing now is only affordable to 0.05% of the population (600k to 1 million users). To reach the deeper market, they will need to allow creative solutions, but that will only happen once they have tapped the available steps in the financial ladder.
> My central thesis has long been that 25/5 mbit service - debloated -
> was more than good enough for your typical family of 4, no matter the
> country, WFH, or not.

We provide a 5 Mbps service (1.5 Mbps provisioned), and Kenyans consume 220 GB per month on average over it. This is on par with “western” nations. I’m not so sure about the debloated part though :-)

Best,

Mike
On Aug 31, 2022, 02:59 +0200, Dave Taht via Starlink <starlink@lists.bufferbloat.net>, wrote:
> I think f-root dns servers in LEO makes a lot of sense. It's not a lot
> of data, nor does it require much cpu. and dns lookups are a frequent
> source of major latency.
>
> CDN in space, well, how much mass, energy, does a set of spindles
> need? Can raid arrays of modern flash or disk survive serious SEVs?
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

[-- Attachment #2: Type: text/html, Size: 2765 bytes --]

Re: [Starlink] Starlink "beam spread"

[Sebastian Moeller]

Hi Ulrich,

> On Aug 31, 2022, at 09:25, Ulrich Speidel <u.speidel@auckland.ac.nz> wrote:
> 
> On 31/08/2022 6:26 pm, Sebastian Moeller wrote:
>> Hi Ulrich,
>> 
>> On 31 August 2022 00:50:35 CEST, Ulrich Speidel via Starlink <starlink@lists.bufferbloat.net> wrote:
>> >There's another aspect here that is often overlooked when looking purely at the data rate that you can get from your fibre/cable/wifi/satellite, and this is where the data comes from.
>> >
>> >A large percentage of Internet content these days comes from content delivery networks (CDNs). These innately work on the assumption that it's the core of the Internet that presents a bottleneck, and that the aggregate bandwidth of all last mile connections is high in comparison. A second assumption is that a large share of the content that gets requested gets requested many times, and many times by users in the same corner(s) of the Internet. The conclusion is that therefore content is best served from a location close to the end user, so as to keep RTTs low and - importantly - keep the load of long distance bottleneck links.
>> >
>> >Now it's fairly clear that large numbers of fibres to end users make for the best kind of network between CDN and end user. Local WiFi hotspots with limited range allow frequency re-use, as do ground based cellular networks, so they're OK, too, in that respect.  But anything that needs to project RF energy over a longer distance to get directly to the end user hasn't got nature on its side.
>> >
>> >This is, IMHO, Starlink's biggest design flaw at the moment: Going direct to end user site rather providing a bridge to a local ISP may be circumventing the lack of last mile infrastructure in the US, but it also makes incredibly inefficient use of spectrum and satellite resource. If every viral cat video that a thousand Starlink users in Iowa are just dying to see literally has to go to space a thousand times and back again rather than once, you arguably have a problem.
>> 
>> Why? Internet access service is predominantly a service to transport any packets the users send and request when they do so. Caching content closer to the users or multicast tricks are basically optimizations that (occasionally) help decrease costs/increase margins for the operator, but IMHO they are exactly that, optimizations. So if they can not be used, no harm is done. Since caching is not perfect, such optimisations really are no way to safely increase the oversubscription rate either. Mind you I am not saying such measures are useless, but in IAS I consider them to be optional. Ideas about caching in space seem a bit pie-in-the-sky (pun intended) since at 4ms delay this would only help if operating CDNs in space would be cheaper than on earth at the base station or if the ground to satellite capacity was smaller then the aggregate satellite to end user capacity (both per satellite), no?
> 
> Now, assuming for a moment that your typical Starlink user isn't so different from your average Internet user anywhere else in that they like to watch Netflix, YouTube, TikTok etc., then having a simple "transport layer and below" view of a system that's providing connectivity simply isn't enough.

	Why? As I said, CDNs and Co. are (mostly economic) optimizations, internet access service (IAS) really is a dumb pipe service as little as ISPs enjoy that...


> The problem is that - Zoom meetings aside - the vast majority of data that enters an end user device these days comes from a CDN server somewhere.

	Again CDNs optimize the fact that there is a considerable overlap in the type of content users access, so that average usage patterns become predictable enough that caching becomes a viable strategy. But we only get these caches because one or more parties actually profit from doing so; ISPs might sell colocation in AS-internal data-centers for $money$, while content providers might save on their total transport costs, by reducing the total bit-miles. But both are inherently driven by the desire to increase revenue/surplus.


> It's quietly gotten so pervasive that if a major CDN provider (or cloud service provider or however they like to refer to themselves these days) has an outage, the media will report - incorrectly of course - that "the Internet is down". So it's not just something that's optional anymore, and hasn't been for a while. It's an integral part of the landscape. Access strata folk please take note!

	Well, that just means that the caching layer is too optimistic and has pretty abysmal failure points; on average CDNs probably are economically attractive enough that customers (the content providers who pay the CDNs) just accept/tolerate the occasional outage (it is not that big content prividers do not occasionally screw up on their side as well).

> This isn't a (huge) problem on classical mobile networks with base stations because of the amount of frequency division multiplexing you can do with a combination of high cell density, the ensuing ability to communicate with lower power, which enables spatial separation and hence frequency reuse. Add beam forming and a few other nice techniques, and you're fine. Same with WiFi, essentially. So as data emerges from a CDN server (remember, most of this is on demand unicast and not broadcasting), it'll initially go into relatively local fibre backbones (no bottleneck) and then either onto a fibre to the home, a DSL line, a WiFi system, or a terrestrial mobile 4G/5G/6G network, and none of these present a bottleneck at any one point.
> 
> This is different with satellites, including LEO and Starlink. If your CDN or origin server sits at the remote end of the satellite link as seen from the end users, then every copy of your cat video (again, assuming on-demand here) must transit the link each time it's requested, unless there's a cache on the local end that multiple users get their copies from. There is just no way around this. As such, the comparison of Starlink to GSM/LTE/5G base stations just doesn't work here.

	+1: I fully agree, but for such a cache to be wort-while a single starlink link would need to supply enough users that their aggregate consumption becomes predictable enough to make caching effective enough, no?

> 
> So throw in the "edge" as in "edge" computing. In a direct-to-site satellite network, the edgiest bit of the edge is the satellite itself. If we put a CDN server (cache if you wish) there, then yes we have saved us the repeated use of the link on the uplink side. But we still have the downlink to contend with where the video will have to be transmitted for each user who wants it. This combines with the uncomfortable truth that an RF "beam" from a satellite isn't as selective as a laser beam, so the options for frequency re-use from orbit aren't anywhere near as good as from a mobile base station across the road: Any beam pointed at you can be heard for many miles around and therefore no other user can re-use that frequency (with the same burst slot etc.).

	Yes, I tried to imply that, putting servers in space does not solve the load in the satellite problem.

> So by putting a cache on the server, you've reduced the need for multiple redundant transmissions overall by almost half, but this doesn't help much because you really need to cut that need by orders of magnitude.

	Worse, if aggregate CPE downlink = base station uplink, then all we have now is some power saving as the base station might not need to send (much).


> Moreover, there's another problem: Power. Running CDN servers is a power hungry business, as anyone running cloud data centres at scale will be happy to attest to (in Singapore, the drain on the power network from data centres got so bad that they banned new ones for a while). Unfortunately, power is the one thing a LEO satellite that's built to achieve minimum weight is going to have least of.

	There is another issue I believe, cooling, vacuum is a hell of an isolator, so heat probably needs to be shed as IR light... 


> ICN essentially suffers from the same problem when it comes to Starlink - if the information (cat video) you want is on the bird and it's unicast to you over an encrypted connection, then the video still needs to come down 1000 times if 1000 users want to watch it.

	+1: I agree with that assessment. What could work (pie-in-the-sky) is if the base station control the CDN nodes, they could try to slot requests and try to see whether concurrent transfers of the same content could not be synchronized and the unicast silently converted into multicast between base station and dishy. But I have no intuition whether that kind of synchronicity is realistic for everyting but a few events like a soccer world cup final, a cricket test match, of something like the superb owl finals series... (maybe such events are massive enough that such an exercise might still be worth while, I do not know).

Regards
	Sebastian


> 
> -- 
> 
> ****************************************************************
> Dr. Ulrich Speidel
> 
> School of Computer Science
> 
> Room 303S.594 (City Campus)
> 
> The University of Auckland
> u.speidel@auckland.ac.nz
> http://www.cs.auckland.ac.nz/~ulrich/
> ****************************************************************
> 
> 
> 

Re: [Starlink] Starlink "beam spread"

[Brandon Butterworth]

On Wed Aug 31, 2022 at 09:49:50AM +0200, Sebastian Moeller via Starlink wrote:
> +1: I agree with that assessment. What could work (pie-in-the-sky) is if
> the base station control the CDN nodes, they could try to slot requests
> and try to see whether concurrent transfers of the same content could
> not be synchronized and the unicast silently converted into multicast
> between base station and dishy.

Access to a good enough aggregation point is hard

With DSL aggregation, via PPP/L2TP to a few central gateways flattening
any cdn/multicast down to unicast for a large part of the network, limited
how far into the network we could embed our CDN.

Mobile has similar aggregation issues hence eMBMS, we did some work
in 3GPP to extend that to provide a single shared service between
operators so only one set of spectrum was used. It still didn't
create enough capacity vs the demand to make it to deployment yet.

With Starlink capacity being multiplexed per Dishy and uplink
and downlink capacity equal on each satellite there doesn't appear
to be any sharing gain to be had there warranting a CDN in space.

We explored the same situation with the Avanti geo stationary
satellite the last time satellite internet was popular.

Options for Starlink growth are probably not disimilar to 5G - more
MIMO and spectral efficiency. If that gives a satellite more capacity
to Dishys than to ground stations a CDN could be included to make use
of it, probably a single shared CDN (though carrier CDNs didn't go
well in DSL days and as with mobile edge compute the opportunity to
charge for it may limit take up).

I'm assuming there is no scope for shared capacity to all Dishys
permitting something similar to eMBMS, is that true?
 
Do satellite to satellite links change the balance to make a CDN more
likely with the opportunity to upload from less busy regions, or through
cache to cache traffic (content is often geo limited so satellites could
hold some content pools above a certain geo areas allowing cdn storage
re use)?

> But I have no intuition whether that kind of synchronicity is realistic
> for everyting but a few events like a soccer world cup final, a cricket
> test match

I suspect that may be the case. Such GEO limited content complicates matters.

We made our CDN available as a VM which some operators have deployed on
their own hardware (a sort of carrier CDN light) so in theory it could sit
on a Starlink satellite but how many CDNs could they support, just Netflix?

brandon

Re: [Starlink] Starlink "beam spread"

[David Lang]

On Wed, 31 Aug 2022, Brandon Butterworth via Starlink wrote:

> With Starlink capacity being multiplexed per Dishy and uplink
> and downlink capacity equal on each satellite there doesn't appear
> to be any sharing gain to be had there warranting a CDN in space.

don't forget that there are also the laser links, they could link you to a 
shared space CDN, and they also 'complicate' the uplink/downlink calculations 
for any one satellite.

David Lang

Re: [Starlink] Starlink "beam spread"

[Mike Puchol]

[-- Attachment #1: Type: text/plain, Size: 1500 bytes --]

On this particular one, the gateway beams are extremely narrow, around 1.5º to 2.5º. SpaceX is working on “mega-gateways” where 32 antennas will co-exist. They are also deploying a new gateway design with a larger antenna, and thus narrower beamwidth and more gain, allowing for a considerable reduction in TX power.

Best,

Mike
On Aug 31, 2022, 09:33 +0200, David Lang via Starlink <starlink@lists.bufferbloat.net>, wrote:
> On Wed, 31 Aug 2022, Ulrich Speidel via Starlink wrote:
>
> > This combines with the uncomfortable truth
> > that an RF "beam" from a satellite isn't as selective as a laser beam,
> > so the options for frequency re-use from orbit aren't anywhere near as
> > good as from a mobile base station across the road: Any beam pointed at
> > you can be heard for many miles around and therefore no other user can
> > re-use that frequency (with the same burst slot etc.).
>
> not quite, you are forgetting that the antennas on the ground are also steerable
> arrays and so they can focus their 'receiving beam' at different satellites.
> This is less efficient than a transmitting beam as the satellites you aren't
> 'pointed' at will increase your noise floor, but it does allow the same
> frequency to be used for multiple satellites into the same area at the same
> time.
>
> David Lang
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

[-- Attachment #2: Type: text/html, Size: 2080 bytes --]

Re: [Starlink] Starlink "beam spread"

[David Lang]

[-- Attachment #1: Type: text/plain, Size: 1851 bytes --]

I was actually referring to the possibility that the home dishy could point at 
different satellites, so you could have multiple satellites pointing at a given 
cell on the same frequency, and the dishy can aim it's beam to pick which one to 
hear as well as which one to transmit to.

David Lang

On Wed, 31 Aug 2022, Mike Puchol via Starlink wrote:

> On this particular one, the gateway beams are extremely narrow, around 1.5º to 2.5º. SpaceX is working on “mega-gateways” where 32 antennas will co-exist. They are also deploying a new gateway design with a larger antenna, and thus narrower beamwidth and more gain, allowing for a considerable reduction in TX power.
>
> Best,
>
> Mike
> On Aug 31, 2022, 09:33 +0200, David Lang via Starlink <starlink@lists.bufferbloat.net>, wrote:
>> On Wed, 31 Aug 2022, Ulrich Speidel via Starlink wrote:
>>
>>> This combines with the uncomfortable truth
>>> that an RF "beam" from a satellite isn't as selective as a laser beam,
>>> so the options for frequency re-use from orbit aren't anywhere near as
>>> good as from a mobile base station across the road: Any beam pointed at
>>> you can be heard for many miles around and therefore no other user can
>>> re-use that frequency (with the same burst slot etc.).
>>
>> not quite, you are forgetting that the antennas on the ground are also steerable
>> arrays and so they can focus their 'receiving beam' at different satellites.
>> This is less efficient than a transmitting beam as the satellites you aren't
>> 'pointed' at will increase your noise floor, but it does allow the same
>> frequency to be used for multiple satellites into the same area at the same
>> time.
>>
>> David Lang
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Starlink "beam spread"

[Mike Puchol]

[-- Attachment #1: Type: text/plain, Size: 2620 bytes --]

This is what happens today. We know there is at least a primary beam and a backup beam, and the terminal can pick the backup if it feels necessary (eg. the primary becomes obstructed). Technically, you could have 8 beams on a cell, each on a different frequency, and a subset of terminals use beam #1 as primary, #2 as backup, another subset use beam #3 as primary, #4 as backup, and so on.

Best,

Mike
On Aug 31, 2022, 12:06 +0200, David Lang <david@lang.hm>, wrote:
> I was actually referring to the possibility that the home dishy could point at
> different satellites, so you could have multiple satellites pointing at a given
> cell on the same frequency, and the dishy can aim it's beam to pick which one to
> hear as well as which one to transmit to.
>
> David Lang
>
> On Wed, 31 Aug 2022, Mike Puchol via Starlink wrote:
>
> > On this particular one, the gateway beams are extremely narrow, around 1.5º to 2.5º. SpaceX is working on “mega-gateways” where 32 antennas will co-exist. They are also deploying a new gateway design with a larger antenna, and thus narrower beamwidth and more gain, allowing for a considerable reduction in TX power.
> >
> > Best,
> >
> > Mike
> > On Aug 31, 2022, 09:33 +0200, David Lang via Starlink <starlink@lists.bufferbloat.net>, wrote:
> > > On Wed, 31 Aug 2022, Ulrich Speidel via Starlink wrote:
> > >
> > > > This combines with the uncomfortable truth
> > > > that an RF "beam" from a satellite isn't as selective as a laser beam,
> > > > so the options for frequency re-use from orbit aren't anywhere near as
> > > > good as from a mobile base station across the road: Any beam pointed at
> > > > you can be heard for many miles around and therefore no other user can
> > > > re-use that frequency (with the same burst slot etc.).
> > >
> > > not quite, you are forgetting that the antennas on the ground are also steerable
> > > arrays and so they can focus their 'receiving beam' at different satellites.
> > > This is less efficient than a transmitting beam as the satellites you aren't
> > > 'pointed' at will increase your noise floor, but it does allow the same
> > > frequency to be used for multiple satellites into the same area at the same
> > > time.
> > >
> > > David Lang
> > > _______________________________________________
> > > Starlink mailing list
> > > Starlink@lists.bufferbloat.net
> > > https://lists.bufferbloat.net/listinfo/starlink
> >
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

[-- Attachment #2: Type: text/html, Size: 3268 bytes --]

Re: [Starlink] Starlink "beam spread"

[Dave Collier-Brown]

[-- Attachment #1: Type: text/plain, Size: 4370 bytes --]

Mr Musk reminds me of a salesperson I once worked with, who first sold himself on all the impossible things GCOS could do better that OS/360, and then set out to convince customers.  The occasional customer would ask if he was barking mad (;-)) Others merely assumed we just hired liars as salesmen.

--dave

On 8/30/22 20:32, David P. Reed via Starlink wrote:

Then Elon Musk is making proposals in bad faith, because he is leading people to believe that his system can do stuff it clearly cannot do.



Which they proved when they failed to meet the requirements of the US rural service funding program, after claiming they could.



On Tuesday, August 30, 2022 8:12pm, "David Lang" <david@lang.hm><mailto:david@lang.hm> said:


> I have no problems with people making technical arguments saying that there are
> limitations on the service that Starlink can provide (I may argue technical
> specifics or point out things I think you miss, but I won't claim that you are
> arguing in bad faith), but when someone then goes beyond that and says that what
> it can provide is a level that's unacceptable to Americans or dismissing it
> because fiber is better, then I'll respond and say that the person is arguing in
> bad faith.
>
> David Lang
>
>
> On Tue, 30 Aug 2022, David P. Reed wrote:
>
> > Date: Tue, 30 Aug 2022 19:28:56 -0400 (EDT)
> > From: David P. Reed <dpreed@deepplum.com><mailto:dpreed@deepplum.com>
> > To: Brandon Butterworth <brandon@rd.bbc.co.uk><mailto:brandon@rd.bbc.co.uk>
> > Cc: David Lang <david@lang.hm><mailto:david@lang.hm>, Brandon Butterworth
> <brandon@rd.bbc.co.uk><mailto:brandon@rd.bbc.co.uk>,
> > starlink@lists.bufferbloat.net<mailto:starlink@lists.bufferbloat.net>
> > Subject: Re: [Starlink] Starlink "beam spread"
> >
> >
> > I wasn't starting a discussion about Starlink the business. I was talking
> about Starlink the technology and the "dreams" that people project onto that
> technology.
> >
> > I'm happy if the current customers are happy and remain happy. Just pointing
> out that there are pretty severe limitations in the physical capabilities of the
> technology of the satellites and dishys that will limit how many customers can be
> served in an area.
> >
> > I was reacting to the idea Dave Taht brought up that somehow the satellites
> can cover "more" area per satellite, if they go to a lower total bit rate (175 vs.
> 240 per antenna on each satellite).
> >
> > I'm a radio engineer, trained in stuff like phased array antenna designs, and
> power, etc. I'm also a communications protocol engineer, trained in multiplexing
> techniques.
> >
> > I'm not saying Starlink engineers are incompetent, but I am saying that what
> Musk (who despite the fact that he pretends to be an engineer is not one, never
> has been one) has described in his visionary speeches is not what Starlink is
> delivering today, and that's because it basically can't be delivered.
>



_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net<mailto:Starlink@lists.bufferbloat.net>
https://lists.bufferbloat.net/listinfo/starlink


--
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
dave.collier-brown@indexexchange.com<mailto:dave.collier-brown@indexexchange.com> |              -- Mark Twain


CONFIDENTIALITY NOTICE AND DISCLAIMER : This telecommunication, including any and all attachments, contains confidential information intended only for the person(s) to whom it is addressed. Any dissemination, distribution, copying or disclosure is strictly prohibited and is not a waiver of confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and delete the message from your inbox and deleted items folders. This telecommunication does not constitute an express or implied agreement to conduct transactions by electronic means, nor does it constitute a contract offer, a contract amendment or an acceptance of a contract offer. Contract terms contained in this telecommunication are subject to legal review and the completion of formal documentation and are not binding until same is confirmed in writing and has been signed by an authorized signatory.

[-- Attachment #2: Type: text/html, Size: 6564 bytes --]

Re: [Starlink] Starlink "beam spread"

[Ulrich Speidel]

Um, yes, but I think we're mixing a few things up here (trying to bundle 
responses here, so that's not just to you, David).

In lieu of a reliable Starlink link budget, I'm going by this one:

https://www.linkedin.com/pulse/quick-analysis-starlink-link-budget-potential-emf-david-witkowski/

Parameters here are a little outdated but the critical one is the EIRP 
at the transmitter of up to ~97 dBm. Say we're looking at a 30 GHz Ka 
band signal over a 600 km path, which is more reflective of the current 
constellation. Then Friis propagation gives us a path loss of about 178 
dB, and if we pretend for a moment that Dishy is actually a 60 cm 
diameter parabolic dish, we're looking at around 45 dBi receive antenna 
gain. Probably a little less as Dishy isn't actually a dish.

Then that gives us 97 dBm - 178 dB + 45 dB = -36 dBm at the ground 
receiver. Now I'm assuming here that this is for ALL user downlink beams 
from the satellite combined. What we don't really know is how many 
parallel signals a satellite multiplexes into these, but assuming at the 
moment a receive frontend bandwidth of about 100 MHz, noise power at the 
receiver should be around 38 pW or -74 dBm. That leaves Starlink around 
38 dB of SNR to play with. Shannon lets us send up to just over 1.25 
Gb/s in that kind of channel, but then again that's just the Shannon 
limit, and in practice, we'll be looking a a wee bit less.

That SNR also gives us an indication as to the signal separation Dishy 
needs to achieve from the beams from another satellite in order for that 
other satellite to re-use the same frequency. Note that this is 
significantly more than just the 3 dB that the 3 dB width of a beam 
gives us. The 3 dB width is what is commonly quoted as "beam width", and 
that's where you get those nice narrow angles. But that's just the width 
at which the beam drops to half its EIRP, not the width at which it can 
no longer interfere. For that, you need the 38 dB width - or thereabouts 
- if you can get it, and this will be significantly more than the 1.2 
degrees or so of 3dB beam width.

But even if you worked with 1.2 degrees at a distance of 600 km and you 
assumed that sort of beam width at the satellite, it still gives you an 
 >12 km radius on the ground within which you cannot reuse the downlink 
frequency from the same satellite. That's orders of magnitude more than 
the re-use spatial separation you can achieve in ground-based cellular 
networks. Note that the 0.1 deg beam "precision" is irrelevant here - 
that just tells me the increments in which they can point the beam, but 
not how wide it is and how intensity falls off with angle, or how bad 
the side lobes are.

Whether you can re-use the same frequency from another satellite to the 
same ground area is a good question. We really don't know the beam 
patterns that we get from the birds and from the Dishys, and without 
these it's difficult to say how much angular separation a ground station 
needs between two satellites using the same frequency in order to 
receive one but not be interfered with by the other. Basically, there 
are just too many variables in this for me to be overly optimistic that 
re-use by two different sources within a Starlink cell is possible. And 
I haven't even looked at the numbers for Ku band here.

CDNs & Co - are NOT just dumb economic optimisations to lower bit miles. 
They actually improve performance, and significantly so. A lower RTT 
between you and a server that you grab data from via TCP allows a much 
faster opening of the congestion window. With initial TCP cwnd's being 
typically 10 packets or around 15 kB of data, having a server within 10 
ms of your client means that you've transferred 15 kB after 5 ms, 45 kB 
after 10 ms, 105 kB after 15 ms, 225 kB after 20 ms, and 465 kB after 25 
ms. Make your RTT 100 ms, and it takes half a second to get to your 465 
kB. Having a CDN server in close topological proximity also generally 
reduces the number of queues between you and the server at which packets 
can die an untimely early death, and generally, by taking load off such 
links, reduces the probability of this happening at a lot of queues. 
Bottom line: Having a CDN keeps your users happier. Also, live streaming 
and video conferencing aside, most video is not multicast or broadcast, 
but unicast.

DNS on Starlink satellites: Good idea, lightweight, and I'd suspect 
maybe already in operation? It's low hanging fruit. CDNs on satellites: 
In the day and age of SSDs, having capacity on the satellite shouldn't 
really be an issue, although robustness may be. But heat in this sort of 
storage gets generated mostly when data is written, so it's a function 
of what percentage of your data that reaches the bird is going to end up 
in cache. Generally, on a LEO satellite that'll have to cache baseball 
videos while over the US, videos in a dozen different languages while 
over Europe, Bollywood clips while over India, cooking shows while over 
Australia and always the same old ads while over New Zealand, all the 
while not getting a lot of cache hits for stuff it put into cache 15 
minutes ago, would probably have to write a lot. Moreover, as you'd be 
reliant on the content you want being on the satellite that you are 
currently talking to, pretty much all satellites in the constellation 
would need to cache all content. In other words: If I watch a cat video 
now and thereby put it into the cache of the bird overhead, and then 
send you an e-mail and you're in my neighbourhood and you watch it half 
an hour later, my satellite would be on the other side of the world, and 
you'd have to have it re-uploaded to the CDN on the bird that's flying 
overhead our neighbourhood then. Not as efficient as a ground-based CDN 
on our ground-based network that's fed via a satellite link.

As long as Starlink is going to have in the order of hundreds of 
thousands of direct users, that problem won't go away.

On 31/08/2022 7:33 pm, David Lang wrote:

> On Wed, 31 Aug 2022, Ulrich Speidel via Starlink wrote:
>
>> This combines with the uncomfortable truth that an RF "beam" from a 
>> satellite isn't as selective as a laser beam, so the options for 
>> frequency re-use from orbit aren't anywhere near as good as from a 
>> mobile base station across the road: Any beam pointed at you can be 
>> heard for many miles around and therefore no other user can re-use 
>> that frequency (with the same burst slot etc.).
>
> not quite, you are forgetting that the antennas on the ground are also 
> steerable arrays and so they can focus their 'receiving beam' at 
> different satellites. This is less efficient than a transmitting beam 
> as the satellites you aren't 'pointed' at will increase your noise 
> floor, but it does allow the same frequency to be used for multiple 
> satellites into the same area at the same time.
>
> David Lang
>
-- 
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************

Re: [Starlink] Starlink "beam spread"

[Mike Puchol]

[-- Attachment #1: Type: text/plain, Size: 10733 bytes --]

A lot of detail on the RF side, and you raise some valid points! A few clarifications:

• Ka band is used exclusively for gateway links, and both satellite and gateway use parabollic antennas, where sidelobes etc. are greatly reduced compared to an ESA.

• Ku band is used exclusively for service links to terminals, and from FCC filings, we know that given Nco = 1, the constellation will not project two overlapping co-frequency beams. How much they extend this overlap “safety zone” away from the 3dB contour is not known, but could be calculated given enough information about the terminal.

As per some specific points:
> But that's just the width at which the beam drops to half its EIRP, not the width at which it can no longer interfere. For that, you need the 38 dB width - or thereabouts - if you can get it, and this will be significantly more than the 1.2 degrees or so of 3dB beam width.

You are correct in that the interference will come from an extended footprint, but how much the extended frequency affects the terminal is also a function of receive antenna selectivity, angle of arrival, receiver gain, etc. The Starlink terminal is not an omnidirectional antenna in receive, it is also selective by forming a receive beam with significantly more gain in a specific direction, thus increasing the SNR of the wanted signal. It would be interesting to dig into this one deeper, and see the effect on frequency re-use, that’s for sure!
> That's orders of magnitude more than the re-use spatial separation you can achieve in ground-based cellular networks

You are comparing an infrastructure that has evenly distributed “towers”, to a cellular network that can adjust density of towers by reducing output power and placing more of them closer together, forming smaller and smaller cells - which comes at a cost. I believe it’s unfair to compare any satellite constellation to a cellular network in these terms.
> We really don't know the beam patterns that we get from the birds and from the Dishys, and without these it's difficult to say how much angular separation a ground station needs between two satellites using the same frequency in order to receive one but not be interfered with by the other.

Oh but we do know the beam patterns - they are in the GXT files that accompany the Schedule S in FCC filings. I took them and created this view:



The three colors are 2dB, interpolated 3dB, and 4dB contours. I use these to calculate beam spread in the capacity simulation.
> Basically, there are just too many variables in this for me to be overly optimistic that re-use by two different sources within a Starlink cell is possible.

We know from gRPC data from the terminal itself that there is a primary beam, and a backup beam, and we know they come from different satellites. Re-use with the same frequency is not possible, as they would be violating Nco = 1, so that point is moot.

Best,

Mike
On Aug 31, 2022, 15:41 +0200, Ulrich Speidel via Starlink <starlink@lists.bufferbloat.net>, wrote:
> Um, yes, but I think we're mixing a few things up here (trying to bundle
> responses here, so that's not just to you, David).
>
> In lieu of a reliable Starlink link budget, I'm going by this one:
>
> https://www.linkedin.com/pulse/quick-analysis-starlink-link-budget-potential-emf-david-witkowski/
>
> Parameters here are a little outdated but the critical one is the EIRP
> at the transmitter of up to ~97 dBm. Say we're looking at a 30 GHz Ka
> band signal over a 600 km path, which is more reflective of the current
> constellation. Then Friis propagation gives us a path loss of about 178
> dB, and if we pretend for a moment that Dishy is actually a 60 cm
> diameter parabolic dish, we're looking at around 45 dBi receive antenna
> gain. Probably a little less as Dishy isn't actually a dish.
>
> Then that gives us 97 dBm - 178 dB + 45 dB = -36 dBm at the ground
> receiver. Now I'm assuming here that this is for ALL user downlink beams
> from the satellite combined. What we don't really know is how many
> parallel signals a satellite multiplexes into these, but assuming at the
> moment a receive frontend bandwidth of about 100 MHz, noise power at the
> receiver should be around 38 pW or -74 dBm. That leaves Starlink around
> 38 dB of SNR to play with. Shannon lets us send up to just over 1.25
> Gb/s in that kind of channel, but then again that's just the Shannon
> limit, and in practice, we'll be looking a a wee bit less.
>
> That SNR also gives us an indication as to the signal separation Dishy
> needs to achieve from the beams from another satellite in order for that
> other satellite to re-use the same frequency. Note that this is
> significantly more than just the 3 dB that the 3 dB width of a beam
> gives us. The 3 dB width is what is commonly quoted as "beam width", and
> that's where you get those nice narrow angles. But that's just the width
> at which the beam drops to half its EIRP, not the width at which it can
> no longer interfere. For that, you need the 38 dB width - or thereabouts
> - if you can get it, and this will be significantly more than the 1.2
> degrees or so of 3dB beam width.
>
> But even if you worked with 1.2 degrees at a distance of 600 km and you
> assumed that sort of beam width at the satellite, it still gives you an
> > 12 km radius on the ground within which you cannot reuse the downlink
> frequency from the same satellite. That's orders of magnitude more than
> the re-use spatial separation you can achieve in ground-based cellular
> networks. Note that the 0.1 deg beam "precision" is irrelevant here -
> that just tells me the increments in which they can point the beam, but
> not how wide it is and how intensity falls off with angle, or how bad
> the side lobes are.
>
> Whether you can re-use the same frequency from another satellite to the
> same ground area is a good question. We really don't know the beam
> patterns that we get from the birds and from the Dishys, and without
> these it's difficult to say how much angular separation a ground station
> needs between two satellites using the same frequency in order to
> receive one but not be interfered with by the other. Basically, there
> are just too many variables in this for me to be overly optimistic that
> re-use by two different sources within a Starlink cell is possible. And
> I haven't even looked at the numbers for Ku band here.
>
> CDNs & Co - are NOT just dumb economic optimisations to lower bit miles.
> They actually improve performance, and significantly so. A lower RTT
> between you and a server that you grab data from via TCP allows a much
> faster opening of the congestion window. With initial TCP cwnd's being
> typically 10 packets or around 15 kB of data, having a server within 10
> ms of your client means that you've transferred 15 kB after 5 ms, 45 kB
> after 10 ms, 105 kB after 15 ms, 225 kB after 20 ms, and 465 kB after 25
> ms. Make your RTT 100 ms, and it takes half a second to get to your 465
> kB. Having a CDN server in close topological proximity also generally
> reduces the number of queues between you and the server at which packets
> can die an untimely early death, and generally, by taking load off such
> links, reduces the probability of this happening at a lot of queues.
> Bottom line: Having a CDN keeps your users happier. Also, live streaming
> and video conferencing aside, most video is not multicast or broadcast,
> but unicast.
>
> DNS on Starlink satellites: Good idea, lightweight, and I'd suspect
> maybe already in operation? It's low hanging fruit. CDNs on satellites:
> In the day and age of SSDs, having capacity on the satellite shouldn't
> really be an issue, although robustness may be. But heat in this sort of
> storage gets generated mostly when data is written, so it's a function
> of what percentage of your data that reaches the bird is going to end up
> in cache. Generally, on a LEO satellite that'll have to cache baseball
> videos while over the US, videos in a dozen different languages while
> over Europe, Bollywood clips while over India, cooking shows while over
> Australia and always the same old ads while over New Zealand, all the
> while not getting a lot of cache hits for stuff it put into cache 15
> minutes ago, would probably have to write a lot. Moreover, as you'd be
> reliant on the content you want being on the satellite that you are
> currently talking to, pretty much all satellites in the constellation
> would need to cache all content. In other words: If I watch a cat video
> now and thereby put it into the cache of the bird overhead, and then
> send you an e-mail and you're in my neighbourhood and you watch it half
> an hour later, my satellite would be on the other side of the world, and
> you'd have to have it re-uploaded to the CDN on the bird that's flying
> overhead our neighbourhood then. Not as efficient as a ground-based CDN
> on our ground-based network that's fed via a satellite link.
>
> As long as Starlink is going to have in the order of hundreds of
> thousands of direct users, that problem won't go away.
>
> On 31/08/2022 7:33 pm, David Lang wrote:
>
> > On Wed, 31 Aug 2022, Ulrich Speidel via Starlink wrote:
> >
> > > This combines with the uncomfortable truth that an RF "beam" from a
> > > satellite isn't as selective as a laser beam, so the options for
> > > frequency re-use from orbit aren't anywhere near as good as from a
> > > mobile base station across the road: Any beam pointed at you can be
> > > heard for many miles around and therefore no other user can re-use
> > > that frequency (with the same burst slot etc.).
> >
> > not quite, you are forgetting that the antennas on the ground are also
> > steerable arrays and so they can focus their 'receiving beam' at
> > different satellites. This is less efficient than a transmitting beam
> > as the satellites you aren't 'pointed' at will increase your noise
> > floor, but it does allow the same frequency to be used for multiple
> > satellites into the same area at the same time.
> >
> > David Lang
> >
> --
> ****************************************************************
> Dr. Ulrich Speidel
>
> School of Computer Science
>
> Room 303S.594 (City Campus)
>
> The University of Auckland
> u.speidel@auckland.ac.nz
> http://www.cs.auckland.ac.nz/~ulrich/
> ****************************************************************
>
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

[-- Attachment #2.1: Type: text/html, Size: 12754 bytes --]

[-- Attachment #2.2: Spot beams.png --]
[-- Type: image/png, Size: 950806 bytes --]

Re: [Starlink] Starlink "beam spread"

[Dave Taht]

On Tue, Aug 30, 2022 at 9:53 AM David P. Reed via Starlink
<starlink@lists.bufferbloat.net> wrote:

> First, it's worth looking at all the problems currently in WiFi performance when you share an AP with multiple active stations using 100's of Gb/s on the average (not just occasionally).
>
> Dave - you tried in "make-wifi-fast", and the architecture gets in the way there. (yeah you can get point to point gigabit/sec single file transfers, but to do that you invoke features that destroy latency and introduce huge variability if you share the AP at all, for these reasons).

Didn't "try", did. :)
https://forum.openwrt.org/t/aql-and-the-ath10k-is-lovely/59002/830

Also managed the "high variability" problem to a large extent, being
able to 'slide' servicing sparse stations into that budget.

... If you consider being able to effectively multiplex 4 stations at
full load in both directions with under 30ms of queuing "good". Many
APs to this day, including enterprise ones, are behaving a lot
more like our initial results on that link above (if y'all scroll
back), but at least test houses like candelatech
have tcp test suites for multistation behaviors now and are feeding
those back to the vendors.

It's very possible to do 100x better than that (call it 300us) in wifi
with proper hardware support.

WiFi 7 holds the promise of multiple stations being able to transmit
on their own subchannel, which I will love if they can make it work,
but it has many flaws like "sounding".

>
>
> Starlink is a good "last resort" service as constituted. But fiber and last few-hundred meters wireless is SO much better able to deliver good Internet service scalably.

Starlink just has to be better than old DSL to succeed. It is, except
it's unusable for fps gaming.

> Even that assumes fixing the bufferbloat that the Starlink folks don't seem to be able to address...

It's been better lately on uploads. At the lowest tier of service
"idle", ~2mbit, it's rather sane. Only when
it gets "full" bandwidth from the controller does it get past 150ms
now. My guess is it's a tail drop per packet queue, dynamically
controlled. Not cake, no fq to be seen, way too much queuing in one
direction or another at the higher rates.

I basically shaped it to 6mbits up to avoid that behavior and only
notice a sat switch when it messes with my mosh or videoconference.
Done that way it's been a lot better than cell was.

Some other data: is you can always get a small flow through at 20ms
intervals nowadays, however,
if you attempt to send stuff at 10ms or 5ms intervals I've seen as
high as 14% packet drop. I do not
understand how that correlates back to service intervals or their
uplink  *at all*.

> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink



--
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC

[Starlink] starlink upload behavior

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 806 bytes --]

I have just been leaving cake at 6Mbit on the upload and that fq and
control make it much
more tolerable for my mix of videoconferencing and uploads. That said,
I hadn't looked
at the native performance in a while which is markedly better than it
was a few months ago, at least for this quick test run.

If anyone can make sense of these... for the first 1/3 of the trace
throughput is low and RTTs are *NICE*,
the second looks like a sat switch - still nice... then another sat
switch where I get full upload throughput
and the latency grows significantly.

If anyone is into packet captures:

http://www.taht.net/~d/starlink-1-auto.cap # starlink through their wifi
http://www.taht.net/~d/starlink-1-cake6.cap # starlink through their
wifi, with cake bandwidth 6mbit on mine

Graphs produced with xplot.

[-- Attachment #2: starlink-up-acks.png --]
[-- Type: image/png, Size: 9898 bytes --]

[-- Attachment #3: starlink-up-rtt.png --]
[-- Type: image/png, Size: 9919 bytes --]

[-- Attachment #4: starlink-up-tput.png --]
[-- Type: image/png, Size: 8332 bytes --]

[-- Attachment #5: starlink-zoomed.png --]
[-- Type: image/png, Size: 19365 bytes --]

[-- Attachment #6: starlink-cake6-rtt.png --]
[-- Type: image/png, Size: 9320 bytes --]

Re: [Starlink] Starlink "beam spread"

[Dick Roy]

[-- Attachment #1: Type: text/plain, Size: 1900 bytes --]

 

 

  _____  

From: Starlink [mailto:starlink-bounces@lists.bufferbloat.net] On Behalf Of
Mike Puchol via Starlink
Sent: Wednesday, August 31, 2022 2:59 AM
To: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] Starlink "beam spread"

 

On this particular one, the gateway beams are extremely narrow, around 1.5º
to 2.5º. SpaceX is working on “mega-gateways” where 32 antennas will
co-exist. They are also deploying a new gateway design with a larger
antenna, and thus narrower beamwidth and more gain, allowing for a
considerable reduction in TX power.

[RR] there is a much better way to do this! I sure hope starlink is
considering it. Large antennas with narrow beam widths are a sledgehammer to
kill a fly.

:-)

 

Best,

Mike

On Aug 31, 2022, 09:33 +0200, David Lang via Starlink
<starlink@lists.bufferbloat.net>, wrote:



On Wed, 31 Aug 2022, Ulrich Speidel via Starlink wrote:




This combines with the uncomfortable truth
that an RF "beam" from a satellite isn't as selective as a laser beam,
so the options for frequency re-use from orbit aren't anywhere near as
good as from a mobile base station across the road: Any beam pointed at
you can be heard for many miles around and therefore no other user can
re-use that frequency (with the same burst slot etc.).


not quite, you are forgetting that the antennas on the ground are also
steerable
arrays and so they can focus their 'receiving beam' at different satellites.
This is less efficient than a transmitting beam as the satellites you aren't
'pointed' at will increase your noise floor, but it does allow the same
frequency to be used for multiple satellites into the same area at the same
time.

David Lang
_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink


[-- Attachment #2: Type: text/html, Size: 5970 bytes --]

Re: [Starlink] Starlink "beam spread"

[David Lang]

Except that he has a track record of eventually delivering (late, and not as 
cheaply as originally thought, but delivering)

David Lang

On Wed, 31 Aug 2022, Dave Collier-Brown via Starlink wrote:

> Mr Musk reminds me of a salesperson I once worked with, who first sold 
> himself on all the impossible things GCOS could do better that OS/360, and 
> then set out to convince customers.  The occasional customer would ask if he 
> was barking mad (;-)) Others merely assumed we just hired liars as salesmen.
>
> --dave
>
> On 8/30/22 20:32, David P. Reed via Starlink wrote:
>
> Then Elon Musk is making proposals in bad faith, because he is leading people 
> to believe that his system can do stuff it clearly cannot do.
>
>
>
> Which they proved when they failed to meet the requirements of the US rural 
> service funding program, after claiming they could.
>
>
>
> On Tuesday, August 30, 2022 8:12pm, "David Lang" 
> <david@lang.hm><mailto:david@lang.hm> said:
>
>
>> I have no problems with people making technical arguments saying that there 
>> are
>> limitations on the service that Starlink can provide (I may argue technical
>> specifics or point out things I think you miss, but I won't claim that you 
>> are
>> arguing in bad faith), but when someone then goes beyond that and says that 
>> what
>> it can provide is a level that's unacceptable to Americans or dismissing it
>> because fiber is better, then I'll respond and say that the person is 
>> arguing in
>> bad faith.
>> 
>> David Lang
>> 
>> 
>> On Tue, 30 Aug 2022, David P. Reed wrote:
>> 
>> > Date: Tue, 30 Aug 2022 19:28:56 -0400 (EDT)
>> > From: David P. Reed <dpreed@deepplum.com><mailto:dpreed@deepplum.com>
>> > To: Brandon Butterworth 
>> <brandon@rd.bbc.co.uk><mailto:brandon@rd.bbc.co.uk>
>> > Cc: David Lang <david@lang.hm><mailto:david@lang.hm>, Brandon Butterworth
>> <brandon@rd.bbc.co.uk><mailto:brandon@rd.bbc.co.uk>,
>> > starlink@lists.bufferbloat.net<mailto:starlink@lists.bufferbloat.net>
>> > Subject: Re: [Starlink] Starlink "beam spread"
>> >
>> >
>> > I wasn't starting a discussion about Starlink the business. I was talking
>> about Starlink the technology and the "dreams" that people project onto 
>> that
>> technology.
>> >
>> > I'm happy if the current customers are happy and remain happy. Just 
>> pointing
>> out that there are pretty severe limitations in the physical capabilities 
>> of the
>> technology of the satellites and dishys that will limit how many customers 
>> can be
>> served in an area.
>> >
>> > I was reacting to the idea Dave Taht brought up that somehow the 
>> satellites
>> can cover "more" area per satellite, if they go to a lower total bit rate 
>> (175 vs.
>> 240 per antenna on each satellite).
>> >
>> > I'm a radio engineer, trained in stuff like phased array antenna designs, 
>> and
>> power, etc. I'm also a communications protocol engineer, trained in 
>> multiplexing
>> techniques.
>> >
>> > I'm not saying Starlink engineers are incompetent, but I am saying that 
>> what
>> Musk (who despite the fact that he pretends to be an engineer is not one, 
>> never
>> has been one) has described in his visionary speeches is not what Starlink 
>> is
>> delivering today, and that's because it basically can't be delivered.
>> 
>
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net<mailto:Starlink@lists.bufferbloat.net>
> https://lists.bufferbloat.net/listinfo/starlink
>
>
> --
> David Collier-Brown,         | Always do right. This will gratify
> System Programmer and Author | some people and astonish the rest
> dave.collier-brown@indexexchange.com<mailto:dave.collier-brown@indexexchange.com> 
> |              -- Mark Twain
>
>
> CONFIDENTIALITY NOTICE AND DISCLAIMER : This telecommunication, including any 
> and all attachments, contains confidential information intended only for the 
> person(s) to whom it is addressed. Any dissemination, distribution, copying 
> or disclosure is strictly prohibited and is not a waiver of confidentiality. 
> If you have received this telecommunication in error, please notify the 
> sender immediately by return electronic mail and delete the message from your 
> inbox and deleted items folders. This telecommunication does not constitute 
> an express or implied agreement to conduct transactions by electronic means, 
> nor does it constitute a contract offer, a contract amendment or an 
> acceptance of a contract offer. Contract terms contained in this 
> telecommunication are subject to legal review and the completion of formal 
> documentation and are not binding until same is confirmed in writing and has 
> been signed by an authorized signatory.
>

Re: [Starlink] Starlink "beam spread"

[Dave Taht]

On Tue, Aug 30, 2022 at 4:28 PM David P. Reed via Starlink
<starlink@lists.bufferbloat.net> wrote:
>
> I wasn't starting a discussion about Starlink the business. I was talking about Starlink the technology and the "dreams" that people project onto that technology.
>
>
>
> I'm happy if the current customers are happy and remain happy. Just pointing out that there are pretty severe limitations in the physical capabilities of the technology of the satellites and dishys that will limit how many customers can be served in an area.
>
>
>
> I was reacting to the idea Dave Taht brought up that somehow the satellites can cover "more" area per satellite, if they go to a lower total bit rate (175 vs. 240 per antenna on each satellite).

No, I'd started this excellent thread in admiration of mike's
graphical and animation talents. Back when I had a house, I had all of
tufte's work...

A good picture, a good (and representative) analogy, is worth (with
inflation) millions of words. Last night I was looking up at the stars
for the first time in a while, hoping to get a glimpse of the starlink
launch (nope - from half moon bay) and reflecting on an old piece I'd
written on orbital resonance:

http://the-edge.blogspot.com/2007/03/31-orbital-resonance-with-jupiter.html

And yearning for that flash of insight that would explain better - for
example, the inverse square law and how phased array antennas really
work, and the cost of transiting the atmosphere at an increasing
angle, and so many other things, including the economic model.

I used to take rides on asteroids a lot using the celestial simulator,
I wonder if that could be used to "see the view from the shells"...

I note that I found mark handleys early animations really helpful in
wrapping my head around how starlink might work, and he got it wrong
twice - first using isl, then ground stations, and now this primary
and backup beam concept that just went by on this list!!  that makes
huge amounts of sense (compared to using wifi retries) - I love it! I
can see it in my head now!

Bonus link: Epicycles. Lie flat on your back and think about those for a while:

http://the-edge.blogspot.com/2005/09/epicycles.html?m=0
>
>
>
> I'm a radio engineer, trained in stuff like phased array antenna designs, and power, etc. I'm also a communications protocol engineer, trained in multiplexing techniques.
>
>
>
> I'm not saying Starlink engineers are incompetent, but I am saying that what Musk (who despite the fact that he pretends to be an engineer is not one, never has been one) has described in his visionary speeches is not what Starlink is delivering today, and that's because it basically can't be delivered.

Every user of shared spectrum to date has always had their marketing
people talk about early bandwidth and performance for their new
tech... which was also destined to fade. didn't the press catch on for
3g, 4g, and 5g?


>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink



-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC

Re: [Starlink] Starlink "beam spread"

[Ulrich Speidel]

[-- Attachment #1: Type: text/plain, Size: 4233 bytes --]

See below.

On 1/09/2022 2:30 am, Mike Puchol via Starlink wrote:
> A lot of detail on the RF side, and you raise some valid points! A few 
> clarifications:
>
>   * Ka band is used exclusively for gateway links, and both satellite
>     and gateway use parabollic antennas, where sidelobes etc. are
>     greatly reduced compared to an ESA.
>
Note I worked on the basis of parabolics, so that bit would be covered.
>
>   * Ku band is used exclusively for service links to terminals, and
>     from FCC filings, we know that given Nco = 1, the constellation
>     will not project two overlapping co-frequency beams. How much they
>     extend this overlap “safety zone” away from the 3dB contour is not
>     known, but could be calculated given enough information about the
>     terminal.
>
Indeed. I used Ka band instead of Ku for my calculations even for 
downlink to end user because the narrower beams in that case would work 
in Starlink's favour. Entirely hypothetical, of course.
>
> As per some specific points:
>
>     But that's just the width at which the beam drops to half its
>     EIRP, not the width at which it can no longer interfere. For that,
>     you need the 38 dB width - or thereabouts - if you can get it, and
>     this will be significantly more than the 1.2 degrees or so of 3dB
>     beam width.
>
>
> You are correct in that the interference will come from an extended 
> footprint, but how much the extended frequency affects the terminal is 
> also a function of receive antenna selectivity, angle of arrival, 
> receiver gain, etc. The Starlink terminal is not an omnidirectional 
> antenna in receive, it is also selective by forming a receive beam 
> with significantly more gain in a specific direction, thus increasing 
> the SNR of the wanted signal. It would be interesting to dig into this 
> one deeper, and see the effect on frequency re-use, that’s for sure!
>
>     That's orders of magnitude more than the re-use spatial separation
>     you can achieve in ground-based cellular networks
>
>
> You are comparing an infrastructure that has evenly distributed 
> “towers”, to a cellular network that can adjust density of towers by 
> reducing output power and placing more of them closer together, 
> forming smaller and smaller cells - which comes at a cost. I believe 
> it’s unfair to compare any satellite constellation to a cellular 
> network in these terms.
Indeed, it's grossly unfair. But such is life ;-)
>
>     We really don't know the beam patterns that we get from the birds
>     and from the Dishys, and without these it's difficult to say how
>     much angular separation a ground station needs between two
>     satellites using the same frequency in order to receive one but
>     not be interfered with by the other. 
>
>
> Oh but we do know the beam patterns - they are in the GXT files that 
> accompany the Schedule S in FCC filings. I took them and created this 
> view:
>
>
>
> The three colors are 2dB, interpolated 3dB, and 4dB contours. I use 
> these to calculate beam spread in the capacity simulation.

That actually underlines my point nicely. If even the 4 dB contour in 
E-W direction is already in the order of 50 km across, then how wide 
will the interference contour be? Way more than for a mobile network's 
nano cells.

>     Basically, there are just too many variables in this for me to be
>     overly optimistic that re-use by two different sources within a
>     Starlink cell is possible.
>
>
> We know from gRPC data from the terminal itself that there is a 
> primary beam, and a backup beam, and we know they come from different 
> satellites. Re-use with the same frequency is not possible, as they 
> would be violating Nco = 1, so that point is moot.
Good. We're on the same song sheet then.
>
> Best,
>
> Mike
-- 

****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz  
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************



[-- Attachment #2.1: Type: text/html, Size: 7376 bytes --]

[-- Attachment #2.2: Spot%20beams.png --]
[-- Type: image/png, Size: 950806 bytes --]

Re: [Starlink] Starlink "beam spread"

[Sebastian Moeller]

Hi Ulrich,

focussing on the CDN part

> On Aug 31, 2022, at 15:41, Ulrich Speidel <u.speidel@auckland.ac.nz> wrote:
> [...]
> CDNs & Co - are NOT just dumb economic optimisations to lower bit miles. They actually improve performance, and significantly so. A lower RTT between you and a server that you grab data from via TCP allows a much faster opening of the congestion window. With initial TCP cwnd's being typically 10 packets or around 15 kB of data, having a server within 10 ms of your client means that you've transferred 15 kB after 5 ms, 45 kB after 10 ms, 105 kB after 15 ms, 225 kB after 20 ms, and 465 kB after 25 ms. Make your RTT 100 ms, and it takes half a second to get to your 465 kB. Having a CDN server in close topological proximity also generally reduces the number of queues between you and the server at which packets can die an untimely early death, and generally, by taking load off such links, reduces the probability of this happening at a lot of queues. Bottom line: Having a CDN keeps your users happier. Also, live streaming and video conferencing aside, most video is not multicast or broadcast, but unicast.
> [...]

Sure, that is a consequence of slow start*, but I argue that having 2ms or 20ms is not going to result in too noticeable a slow down, and bulk transfers like movies really do not care since DASH in all likelihood leaves slow-start for good after the initial ramp-up. Yes, 1ms versus 100ms makes a difference for interactive uses, but putting the CDN in space versus at the base station IMHO is a less clear improvement. Add to this that caches partly work by exploiting "locality", so e.g. for video streaming platforms I expect different countries to have different viewing profiles and hence different content needs to be cached, but satellites cover large "rings" around the world; meaning either you cache everything (or at least the content for your primary market) in space multiple times over so that your main service area is covered at all times or...

I am prepared to eat crow on this in the future, but I am highly skeptical about CDNs in space (in spite of it being a cool project from the technological side).


*) As it looks slow start is getting a bad rep from multiple sides, but I see not better alternative out there that solves the challenge slow-start tackles in a better way. Namely gradual ramping and probing of sending rates/congestion windows to avoid collapse, this in turn means that short flows will never reach capacity, the solution to which might well be, use longer flows then...

Re: [Starlink] Starlink "beam spread"

[Brandon Butterworth]

On Wed Aug 31, 2022 at 02:34:04AM -0700, David Lang wrote:
> On Wed, 31 Aug 2022, Brandon Butterworth via Starlink wrote:
> 
> >With Starlink capacity being multiplexed per Dishy and uplink
> >and downlink capacity equal on each satellite there doesn't appear
> >to be any sharing gain to be had there warranting a CDN in space.
> 
> don't forget that there are also the laser links, they could link you to a 
> shared space CDN, and they also 'complicate' the uplink/downlink 
> calculations for any one satellite.

That was the subject of the following paragraphs. I agree that is
likely the key enabler for a space CDN.

Some mentioned SSD density is too high for space.

We're used to some hard errors in flash, is the space error rate too
high to cope with, even with increased sparing?

Or is it the soft error rate that is too high? At least for a CDN the
soft rate is less of an issue as it is invalidating cache entries all
the time, this is just a new reason to that requires detecting, and
perhaps a less than whole file invaliation for more efficient replacement.

brandon

Re: [Starlink] Starlink "beam spread"

[Ulrich Speidel]

On 1/09/2022 7:58 pm, Sebastian Moeller wrote:
> Hi Ulrich,
>
> focussing on the CDN part
Sure, we're not on the same song sheet there yet I guess.
>
>> On Aug 31, 2022, at 15:41, Ulrich Speidel <u.speidel@auckland.ac.nz> wrote:
>> [...]
>> CDNs & Co - are NOT just dumb economic optimisations to lower bit miles. They actually improve performance, and significantly so. A lower RTT between you and a server that you grab data from via TCP allows a much faster opening of the congestion window. With initial TCP cwnd's being typically 10 packets or around 15 kB of data, having a server within 10 ms of your client means that you've transferred 15 kB after 5 ms, 45 kB after 10 ms, 105 kB after 15 ms, 225 kB after 20 ms, and 465 kB after 25 ms. Make your RTT 100 ms, and it takes half a second to get to your 465 kB. Having a CDN server in close topological proximity also generally reduces the number of queues between you and the server at which packets can die an untimely early death, and generally, by taking load off such links, reduces the probability of this happening at a lot of queues. Bottom line: Having a CDN keeps your users happier. Also, live streaming and video conferencing aside, most video is not multicast or broadcast, but unicast.
>> [...]
> Sure, that is a consequence of slow start*, but I argue that having 2ms or 20ms is not going to result in too noticeable a slow down, and bulk transfers like movies really do not care since DASH in all likelihood leaves slow-start for good after the initial ramp-up. Yes, 1ms versus 100ms makes a difference for interactive uses, but putting the CDN in space versus at the base station IMHO is a less clear improvement. Add to this that caches partly work by exploiting "locality", so e.g. for video streaming platforms I expect different countries to have different viewing profiles and hence different content needs to be cached, but satellites cover large "rings" around the world; meaning either you cache everything (or at least the content for your primary market) in space multiple times over so that your main service area is covered at all times or...
>
> I am prepared to eat crow on this in the future, but I am highly skeptical about CDNs in space (in spite of it being a cool project from the technological side).

Did I propose putting CDNs in space? I merely discussed whether there 
was any merit in this, and the answer is no.

As for the merit of CDNs in general (feeding into terrestrial last mile 
networks), that debate has been settled long ago. The example I chose 
was for TCP slow start in general. The difference isn't between 2 and 20 
ms but between your cwnd opening so slowly that a ~500 kB transfer takes 
half a second rather than 25 ms. And that example is easily extended.

If you have a network console on your browser, open a website that 
people frequently visit and have a look at how many files your browser 
loads for that. Have a look at how large they are. Then divide the size 
of each by 1500 bytes to get the number of packets in the transfer. Do a 
ping to the server the request goes to, and get the RTT. Then allow 10 
packets during the first RTT, 20 packets during the 2nd RTT, 40 during 
the 3rd, 80 during the 4th, and so on, and ask yourself how long it'll 
take to get all those packets across. And then you'll notice quickly 
that for size ranges up to a few MB, it makes a big difference whether 
the RTT is a few ms or a couple of hundred ms. A lot of common web site 
elements are in the order of a few 100 kB these days, and that means a 
few RTTs.

And yes, really small transfers done in less than one initial cwnd are a 
bit of an issue. You can see that on really crowded trunk GEO satellite 
links to a remote ISP. Because these small flows don't really back off, 
they are the only sort of flow that gets through, and as the load on the 
link increases, these can gobble up all the capacity while large flows die.

> *) As it looks slow start is getting a bad rep from multiple sides, but I see not better alternative out there that solves the challenge slow-start tackles in a better way. Namely gradual ramping and probing of sending rates/congestion windows to avoid collapse, this in turn means that short flows will never reach capacity, the solution to which might well be, use longer flows then...
>
-- 
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************

Re: [Starlink] starlink upload behavior

[Luis A. Cornejo]

[-- Attachment #1: Type: text/plain, Size: 1276 bytes --]

Dave,

Did you leave your ingress at 0?

How about ack filtering and overhead on egress? Do you mind sharing your tc
qdisc commands?

Have you run the auto rate script?

-Luis

On Wed, Aug 31, 2022 at 10:22 AM Dave Taht via Starlink <
starlink@lists.bufferbloat.net> wrote:

> I have just been leaving cake at 6Mbit on the upload and that fq and
> control make it much
> more tolerable for my mix of videoconferencing and uploads. That said,
> I hadn't looked
> at the native performance in a while which is markedly better than it
> was a few months ago, at least for this quick test run.
>
> If anyone can make sense of these... for the first 1/3 of the trace
> throughput is low and RTTs are *NICE*,
> the second looks like a sat switch - still nice... then another sat
> switch where I get full upload throughput
> and the latency grows significantly.
>
> If anyone is into packet captures:
>
> http://www.taht.net/~d/starlink-1-auto.cap # starlink through their wifi
> http://www.taht.net/~d/starlink-1-cake6.cap # starlink through their
> wifi, with cake bandwidth 6mbit on mine
>
> Graphs produced with xplot.
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>

[-- Attachment #2: Type: text/html, Size: 2225 bytes --]

Re: [Starlink] starlink upload behavior

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 6958 bytes --]

On Thu, Sep 1, 2022 at 12:24 PM Luis A. Cornejo
<luis.a.cornejo@gmail.com> wrote:
>
> Dave,
>
> Did you leave your ingress at 0?

I could never find an operating point that was suitable.

> How about ack filtering and overhead on egress? Do you mind sharing your tc qdisc commands?

ack-filter works better than ack-filter-aggressive, though I switch
back and forth.

> Have you run the auto rate script?

I used to - but my own usage is principally bound by annoyance at
upload speeds, so I reverted to just using ack-filtering and a 6Mbit
rate on uploads for the sqm-scripts. See attached.

For new subscribers to this list, the genesis of it all was the idea
of doing a cerowrt II project
targetted at making all of openwrt easily capable of interoperating
with starlink's products, and
in at least a few ways, superior. Despite pitching this in multiple
directions, no funding arrived, and Starlink stopped communicating
with us at all...

https://docs.google.com/document/d/1rVGC-iNq2NZ0jk4f3IAiVUHz2S9O6P-F3vVZU2yBYtw/edit#heading=h.qev8j7cst4lc

and instead we've been poking at various subprojects in loose
formation, off of that list. Notably, the cake-autorate work hit 1.0
with some decent solutions for LTE/5G that I hope more are using, some
details on that here:
https://forum.openwrt.org/t/cake-w-adaptive-bandwidth/135379

Given how the starlink network is (d)evolving, and my continued,
fervent hope they are upgrading their dishys and downlinks to manage
congestion better, I went back to paid work and polishing up the
openwrt 22.03 release. (I think we fixed the last major wifi bug a
week ago).

LibreQos is experiencing a small explosion of popularity, and I hope
more small ISPs are leaping on that. When we started developing cake
in 2015, XDP, ebpf didn't exist, and htb was too locky to scale much
past a gbit, we recently got LibreQos past 10gbits and 5000 60/6 mbit
users on really cheap hardware. Next stop, 20Gbit!

https://github.com/rchac/LibreQoS

I picked up a pretty cool FPGA the other day, as the stop after that
is 100Gbits. 6ns per packet is difficult.

A couple days worth of dishy cake stats:

tc -s qdisc show dev wlp3s0
qdisc cake 818c: root refcnt 2 bandwidth 6Mbit diffserv3
triple-isolate nonat nowash ack-filter split-gso rtt 100.0ms raw
overhead 0
 Sent 1090433207 bytes 3498702 pkt (dropped 240608, overlimits 2592116
requeues 0)
 backlog 0b 0p requeues 0
 memory used: 68Kb of 4Mb
 capacity estimate: 6Mbit
 min/max network layer size:           42 /    1514
 min/max overhead-adjusted size:       42 /    1514
 average network hdr offset:           14

                   Bulk  Best Effort        Voice
  thresh        375Kbit        6Mbit     1500Kbit
  target         48.4ms        5.0ms       12.1ms
  interval      143.4ms      100.0ms      107.1ms
  pk_delay          0us        3.2ms        384us
  av_delay          0us        415us         15us
  sp_delay          0us          3us          2us
  backlog            0b           0b           0b
  pkts                0      3732804         6506
  bytes               0   1105842362       295688
  way_inds            0       254569            0
  way_miss            0        32630           84
  way_cols            0            0            0
  drops               0           46            0
  marks               0          160            0
  ack_drop            0       240562            0
  sp_flows            0            2            0
  bk_flows            0            1            0
  un_flows            0            0            0
  max_len             0        13446          329
  quantum           300          300          300

For contrast here's two days worth of stats for a 60Mbit customer of
this wisp. Overall we see about a 1% drop rate...

qdisc cake c538: parent 7:1218 bandwidth unlimited diffserv4 triple-isolate nona
t nowash ack-filter split-gso rtt 100ms raw overhead 0
 Sent 1068282731 bytes 6570868 pkt (dropped 187845, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
 memory used: 292608b of 15140Kb
 capacity estimate: 0bit
 min/max network layer size:           60 /    1494
 min/max overhead-adjusted size:       60 /    1494
 average network hdr offset:           14

                   Bulk  Best Effort        Video        Voice
  thresh           0bit         0bit         0bit         0bit
  target            5ms          5ms          5ms          5ms
  interval        100ms        100ms        100ms        100ms
  pk_delay       1.08ms        196us        130us         44us
  av_delay         26us          4us          3us          2us
  sp_delay          0us          0us          1us          0us
  backlog            0b           0b           0b           0b
  pkts              258      6753105          320         5030
  bytes           15480   1081835162        24846       860791
  way_inds            0       499764            0            0
  way_miss           90        63092          229          309
  way_cols            0            0            0            0
  drops               0         1062            0            2
  marks               0           32            0            0
  ack_drop            0       186781            0            0
  sp_flows            0            1            0            1
  bk_flows            0            1            0            0
  un_flows            0            0            0            0
  max_len            60         1494         1422          590
  quantum          1514         1514         1514         1514



>
> -Luis
>
> On Wed, Aug 31, 2022 at 10:22 AM Dave Taht via Starlink <starlink@lists.bufferbloat.net> wrote:
>>
>> I have just been leaving cake at 6Mbit on the upload and that fq and
>> control make it much
>> more tolerable for my mix of videoconferencing and uploads. That said,
>> I hadn't looked
>> at the native performance in a while which is markedly better than it
>> was a few months ago, at least for this quick test run.
>>
>> If anyone can make sense of these... for the first 1/3 of the trace
>> throughput is low and RTTs are *NICE*,
>> the second looks like a sat switch - still nice... then another sat
>> switch where I get full upload throughput
>> and the latency grows significantly.
>>
>> If anyone is into packet captures:
>>
>> http://www.taht.net/~d/starlink-1-auto.cap # starlink through their wifi
>> http://www.taht.net/~d/starlink-1-cake6.cap # starlink through their
>> wifi, with cake bandwidth 6mbit on mine
>>
>> Graphs produced with xplot.
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink



-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC

[-- Attachment #2: wlp3s0.iface.conf --]
[-- Type: application/octet-stream, Size: 999 bytes --]

# Default SQM config; the variables defined here will be applied to all
# interfaces. To override values for a particular interface, copy this file to
# <dev>.iface.conf (e.g., "eth0.iface.conf" for eth0).
#
# When using ifupdown, the interface config file needs to exist for sqm-scripts
# to be activated on that interface. However, these defaults are still applied,
# so the interface config can be empty.

# Uplink and Downlink values are in kbps
UPLINK=6000
DOWNLINK=0
#DOWNLINK=40000

# SQM recipe to use. For more information, see /usr/lib/sqm/*.help
SCRIPT=piece_of_cake.qos

# Optional/advanced config

ENABLED=1
QDISC=cake

#LLAM=tc_stab
#LINKLAYER=none
#OVERHEAD=0
#STAB_MTU=2047
#STAB_TSIZE=512
#STAB_MPU=0

#ILIMIT=
#ELIMIT=
#ITARGET=
#ETARGET=

# ECN ingress resp. egress. Values are ECN or NOECN.
IECN=ECN
EECN=ECN

# Extra qdisc options ingress resp. egress
#IQDISC_OPTS=""
EQDISC_OPTS="ack-filter-aggressive"

# CoDel target
#TARGET=5ms

#ZERO_DSCP_INGRESS=1
#IGNORE_DSCP_INGRESS=1

Re: [Starlink] Starlink "beam spread"

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 774 bytes --]


Is there any orbit other than GEO that would make CDNs in space useful?

While current Starlink don't have lasers that could reach up to higher
orbits, maybe a subsequent generation could have such a thing.  Maybe there
could even be a standard which OneWeb/StarLink/??? could all agree to, and
CDN satellites (with bigger solar panels and longer service lifetimes) could
be built to.

Having said all of this, it sure seems that the better place today for CDNs
is within satellite serviced villages.    Some may even remember the Internet
Cache Protocol (ICP), which never really got anywhere (RFC2186).

There are perhaps energy arguments for moving datacenters to space, but stuff
just isn't reliable enough, and I'm sure it's a fail until you manufacture in
space.





[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: [Starlink] Starlink "beam spread"

[tom]

I think manufacturing orbital datacenters in space is absolutely necessary. Then, at no point, is a heavy set of frames needed to hold the weight of the boards. Producing the chips in a real vacuum no gravity environment may also allow radically different design

-----Original Message-----
From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of Michael Richardson via Starlink
Sent: Thursday, September 1, 2022 3:54 PM
To: Ulrich Speidel <u.speidel@auckland.ac.nz>; starlink@lists.bufferbloat.net
Subject: Re: [Starlink] Starlink "beam spread"


Is there any orbit other than GEO that would make CDNs in space useful?

While current Starlink don't have lasers that could reach up to higher orbits, maybe a subsequent generation could have such a thing.  Maybe there could even be a standard which OneWeb/StarLink/??? could all agree to, and CDN satellites (with bigger solar panels and longer service lifetimes) could be built to.

Having said all of this, it sure seems that the better place today for CDNs
is within satellite serviced villages.    Some may even remember the Internet
Cache Protocol (ICP), which never really got anywhere (RFC2186).

There are perhaps energy arguments for moving datacenters to space, but stuff just isn't reliable enough, and I'm sure it's a fail until you manufacture in space.

Re: [Starlink] Starlink "beam spread"

[Sebastian Moeller]

Hi Tom,

I wonder how etching would work with no gravity...


Regards
	Sebastian


> On Sep 1, 2022, at 23:08, Tom Evslin via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
> I think manufacturing orbital datacenters in space is absolutely necessary. Then, at no point, is a heavy set of frames needed to hold the weight of the boards. Producing the chips in a real vacuum no gravity environment may also allow radically different design
> 
> -----Original Message-----
> From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of Michael Richardson via Starlink
> Sent: Thursday, September 1, 2022 3:54 PM
> To: Ulrich Speidel <u.speidel@auckland.ac.nz>; starlink@lists.bufferbloat.net
> Subject: Re: [Starlink] Starlink "beam spread"
> 
> 
> Is there any orbit other than GEO that would make CDNs in space useful?
> 
> While current Starlink don't have lasers that could reach up to higher orbits, maybe a subsequent generation could have such a thing.  Maybe there could even be a standard which OneWeb/StarLink/??? could all agree to, and CDN satellites (with bigger solar panels and longer service lifetimes) could be built to.
> 
> Having said all of this, it sure seems that the better place today for CDNs
> is within satellite serviced villages.    Some may even remember the Internet
> Cache Protocol (ICP), which never really got anywhere (RFC2186).
> 
> There are perhaps energy arguments for moving datacenters to space, but stuff just isn't reliable enough, and I'm sure it's a fail until you manufacture in space.
> 
> 
> 
> 
> 
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Starlink "beam spread"

[tom]

Was beyond my competence. But, as a student of innovation, I'd guess that
lack of gravity is a hindrance to the customary way of etching; but, once
the usual way is ruled out, lack of gravity may become a constraint removed.


-----Original Message-----
From: Sebastian Moeller <moeller0@gmx.de> 
Sent: Friday, September 2, 2022 3:52 AM
To: tom@evslin.com
Cc: Michael Richardson <mcr@sandelman.ca>; Ulrich Speidel
<u.speidel@auckland.ac.nz>; starlink@lists.bufferbloat.net
Subject: Re: [Starlink] Starlink "beam spread"

Hi Tom,

I wonder how etching would work with no gravity...


Regards
	Sebastian


> On Sep 1, 2022, at 23:08, Tom Evslin via Starlink
<starlink@lists.bufferbloat.net> wrote:
> 
> I think manufacturing orbital datacenters in space is absolutely
necessary. Then, at no point, is a heavy set of frames needed to hold the
weight of the boards. Producing the chips in a real vacuum no gravity
environment may also allow radically different design
> 
> -----Original Message-----
> From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of
Michael Richardson via Starlink
> Sent: Thursday, September 1, 2022 3:54 PM
> To: Ulrich Speidel <u.speidel@auckland.ac.nz>;
starlink@lists.bufferbloat.net
> Subject: Re: [Starlink] Starlink "beam spread"
> 
> 
> Is there any orbit other than GEO that would make CDNs in space useful?
> 
> While current Starlink don't have lasers that could reach up to higher
orbits, maybe a subsequent generation could have such a thing.  Maybe there
could even be a standard which OneWeb/StarLink/??? could all agree to, and
CDN satellites (with bigger solar panels and longer service lifetimes) could
be built to.
> 
> Having said all of this, it sure seems that the better place today for
CDNs
> is within satellite serviced villages.    Some may even remember the
Internet
> Cache Protocol (ICP), which never really got anywhere (RFC2186).
> 
> There are perhaps energy arguments for moving datacenters to space, but
stuff just isn't reliable enough, and I'm sure it's a fail until you
manufacture in space.
> 
> 
> 
> 
> 
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Starlink "beam spread"

[Sebastian Moeller]

Hi Michael,


Thanks!

> On Sep 2, 2022, at 20:34, Michael Richardson <mcr@sandelman.ca> wrote:
> 
> 
> Sebastian Moeller <moeller0@gmx.de> wrote:
>>> sadly, they aren't doing IP processing.  I don't think that they ever
>>> will decide to for NIH reasons.  I suspect that their SDN hardware
>>> probably can, and I think that SR6 is probably ideal for their use,
>>> but...
> 
>> 	Why would SR6 be better than any other "underlay" encapsulation here,
>> like MPLS or SR-MPLS? Naively put this seems to trade 4 byte per label
>> with a full 40 byte IPv6 header plus 8 bytes plus 16 bytes per
> 
> SR6 collapses all those things into a single IPv6 forwarding engine.
> The idea is that it's converged.   As for the 44 byte header, as envisioned
> by the SR6 people, they would use the original header, but that's against the
> Ipv6 architecture.  There are ways to compress that header down if you need
> to do that.
> 
>> "label". Asking out of genuine curiosity what are those additional
>> bytes in overhead actually buying (except the freedom from MPLS).
> 
> IPv6 all the way down.


Thanks. Still puzzled but now in an informed way ;)

Regards
	Sebastian

Re: [Starlink] Starlink "beam spread"

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 991 bytes --]


Sebastian Moeller <moeller0@gmx.de> wrote:
    >> sadly, they aren't doing IP processing.  I don't think that they ever
    >> will decide to for NIH reasons.  I suspect that their SDN hardware
    >> probably can, and I think that SR6 is probably ideal for their use,
    >> but...

    > 	Why would SR6 be better than any other "underlay" encapsulation here,
    > like MPLS or SR-MPLS? Naively put this seems to trade 4 byte per label
    > with a full 40 byte IPv6 header plus 8 bytes plus 16 bytes per

SR6 collapses all those things into a single IPv6 forwarding engine.
The idea is that it's converged.   As for the 44 byte header, as envisioned
by the SR6 people, they would use the original header, but that's against the
Ipv6 architecture.  There are ways to compress that header down if you need
to do that.

    > "label". Asking out of genuine curiosity what are those additional
    > bytes in overhead actually buying (except the freedom from MPLS).

IPv6 all the way down.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [Starlink] Starlink "beam spread"

[Sebastian Moeller]

Hi Michael

> On Sep 1, 2022, at 21:56, Michael Richardson via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
> 
> David Fernández via Starlink wrote:
>> If Starlink satellites are processing IP packets, shouldn't them be
>> shown in traceroutes? They are not shown now, AFAIK.
> 
> sadly, they aren't doing IP processing.
> I don't think that they ever will decide to for NIH reasons.
> I suspect that their SDN hardware probably can, and I think that SR6 is
> probably ideal for their use, but...

	Why would SR6 be better than any other "underlay" encapsulation here, like MPLS or SR-MPLS? Naively put this seems to trade 4 byte per label with a full 40 byte IPv6 header plus 8 bytes plus 16 bytes per "label". Asking out of genuine curiosity what are those additional bytes in overhead actually buying (except the freedom from MPLS).

Regards
	Sebastian


> 
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Starlink "beam spread"

[David Fernández]

Starlink gateways are connected to Google data centres:
https://www.prnewswire.com/news-releases/google-cloud-and-spacexs-starlink-to-deliver-secure-global-connectivity-301290801.html

It has been said that one of the 'killer' applications of SATCOM for
companies could be one hop access to their business critical
applications in the cloud from anywhere.

Starlink goes with Google, SES (O3b) and iDirect with Microsoft Azure,
Kuiper for Amazon (in the future)...

Oneweb, Telesat... Others?

2022-09-01 18:33 GMT+02:00, Darrell Budic <budic@onholyground.com>:
> If I recall correctly, Starlink has told us they encrypt from ground to
> ground. So whatever they do in the sat constellation, it’s an underlay
> network and our IP traffic never sees it. This doesn’t preclude ISL, but it
> does work against the concept of a CDN in space. Seems like it’s easier for
> them to get on more IXs and even host cache servers at the ground stations
> if they have enough data center space at them. Of course, there’s nothing
> preventing them from putting up a satellite that gets treated as an endpoint
> and does decryption, but then it’s just another end point on their
> underlay.
>
>> On Sep 1, 2022, at 10:19 AM, David Fernández via Starlink
>> <starlink@lists.bufferbloat.net> wrote:
>>
>> If Starlink satellites are processing IP packets, shouldn't them be
>> shown in traceroutes? They are not shown now, AFAIK.
>>
>> A transparent geographical based routing could be possible, with
>> signal-pass-through approach to the next satellite on a path
>> connecting to a GW, via ISL, if the satellite receiving traffic from a
>> dishy does not have any GW at direct sight.
>>
>>> Date: Thu, 1 Sep 2022 09:46:20 +1200
>>> From: Ulrich Speidel <u.speidel@auckland.ac.nz>
>>> To: starlink@lists.bufferbloat.net
>>> Subject: Re: [Starlink] Starlink "beam spread"
>>> Message-ID: <7a357510-2d61-dd4a-a59f-3d7d4bd3727c@auckland.ac.nz>
>>> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>>>
>>> I work on the assumption that Starlink satellites are, or at least will
>>> eventually be, processing IP packets. For inter-satellite routing it's
>>> more or less a must-have unless you have some other packet switching
>>> protocol layered in between.
>>>
>>> On 1/09/2022 2:51 am, David Fernández via Starlink wrote:
>>>> "DNS on Starlink satellites: Good idea, lightweight, and I'd suspect
>>>> maybe already in operation?"
>>>>
>>>> Are the satellites processing IP packets? Are the ISLs even in
>>>> operation? I have been told Starlink satellites are transparent.
>>>>
>>>>
>>>>> Date: Thu, 1 Sep 2022 01:41:07 +1200
>>>>> From: Ulrich Speidel <u.speidel@auckland.ac.nz>
>>>>> To: David Lang <david@lang.hm>
>>>>> Cc: Sebastian Moeller <moeller0@gmx.de>, Ulrich Speidel via Starlink
>>>>> <starlink@lists.bufferbloat.net>
>>>>> Subject: Re: [Starlink] Starlink "beam spread"
>>>>> Message-ID: <56e56b0f-07bd-fe0c-9434-2663ae9d4404@auckland.ac.nz>
>>>>> Content-Type: text/plain; charset=UTF-8; format=flowed
>>>>>
>>>>> Um, yes, but I think we're mixing a few things up here (trying to
>>>>> bundle
>>>>> responses here, so that's not just to you, David).
>>>>>
>>>>> In lieu of a reliable Starlink link budget, I'm going by this one:
>>>>>
>>>>>
>>>> https://www.linkedin.com/pulse/quick-analysis-starlink-link-budget-potential-emf-david-witkowski/
>>>>
>>>> <https://www.linkedin.com/pulse/quick-analysis-starlink-link-budget-potential-emf-david-witkowski>
>>>>>
>>>>> Parameters here are a little outdated but the critical one is the EIRP
>>>>> at the transmitter of up to ~97 dBm. Say we're looking at a 30 GHz Ka
>>>>> band signal over a 600 km path, which is more reflective of the
>>>>> current
>>>>> constellation. Then Friis propagation gives us a path loss of about
>>>>> 178
>>>>> dB, and if we pretend for a moment that Dishy is actually a 60 cm
>>>>> diameter parabolic dish, we're looking at around 45 dBi receive
>>>>> antenna
>>>>> gain. Probably a little less as Dishy isn't actually a dish.
>>>>>
>>>>> Then that gives us 97 dBm - 178 dB + 45 dB = -36 dBm at the ground
>>>>> receiver. Now I'm assuming here that this is for ALL user downlink
>>>>> beams
>>>>> from the satellite combined. What we don't really know is how many
>>>>> parallel signals a satellite multiplexes into these, but assuming at
>>>>> the
>>>>> moment a receive frontend bandwidth of about 100 MHz, noise power at
>>>>> the
>>>>> receiver should be around 38 pW or -74 dBm. That leaves Starlink
>>>>> around
>>>>> 38 dB of SNR to play with. Shannon lets us send up to just over 1.25
>>>>> Gb/s in that kind of channel, but then again that's just the Shannon
>>>>> limit, and in practice, we'll be looking a a wee bit less.
>>>>>
>>>>> That SNR also gives us an indication as to the signal separation Dishy
>>>>> needs to achieve from the beams from another satellite in order for
>>>>> that
>>>>> other satellite to re-use the same frequency. Note that this is
>>>>> significantly more than just the 3 dB that the 3 dB width of a beam
>>>>> gives us. The 3 dB width is what is commonly quoted as "beam width",
>>>>> and
>>>>> that's where you get those nice narrow angles. But that's just the
>>>>> width
>>>>> at which the beam drops to half its EIRP, not the width at which it
>>>>> can
>>>>> no longer interfere. For that, you need the 38 dB width - or
>>>>> thereabouts
>>>>> - if you can get it, and this will be significantly more than the 1.2
>>>>> degrees or so of 3dB beam width.
>>>>>
>>>>> But even if you worked with 1.2 degrees at a distance of 600 km and
>>>>> you
>>>>> assumed that sort of beam width at the satellite, it still gives you
>>>>> an
>>>>>> 12 km radius on the ground within which you cannot reuse the downlink
>>>>> frequency from the same satellite. That's orders of magnitude more
>>>>> than
>>>>> the re-use spatial separation you can achieve in ground-based cellular
>>>>> networks. Note that the 0.1 deg beam "precision" is irrelevant here -
>>>>> that just tells me the increments in which they can point the beam,
>>>>> but
>>>>> not how wide it is and how intensity falls off with angle, or how bad
>>>>> the side lobes are.
>>>>>
>>>>> Whether you can re-use the same frequency from another satellite to
>>>>> the
>>>>> same ground area is a good question. We really don't know the beam
>>>>> patterns that we get from the birds and from the Dishys, and without
>>>>> these it's difficult to say how much angular separation a ground
>>>>> station
>>>>> needs between two satellites using the same frequency in order to
>>>>> receive one but not be interfered with by the other. Basically, there
>>>>> are just too many variables in this for me to be overly optimistic
>>>>> that
>>>>> re-use by two different sources within a Starlink cell is possible.
>>>>> And
>>>>> I haven't even looked at the numbers for Ku band here.
>>>>>
>>>>> CDNs & Co - are NOT just dumb economic optimisations to lower bit
>>>>> miles.
>>>>> They actually improve performance, and significantly so. A lower RTT
>>>>> between you and a server that you grab data from via TCP allows a much
>>>>> faster opening of the congestion window. With initial TCP cwnd's being
>>>>> typically 10 packets or around 15 kB of data, having a server within
>>>>> 10
>>>>> ms of your client means that you've transferred 15 kB after 5 ms, 45
>>>>> kB
>>>>> after 10 ms, 105 kB after 15 ms, 225 kB after 20 ms, and 465 kB after
>>>>> 25
>>>>> ms. Make your RTT 100 ms, and it takes half a second to get to your
>>>>> 465
>>>>> kB. Having a CDN server in close topological proximity also generally
>>>>> reduces the number of queues between you and the server at which
>>>>> packets
>>>>> can die an untimely early death, and generally, by taking load off
>>>>> such
>>>>> links, reduces the probability of this happening at a lot of queues.
>>>>> Bottom line: Having a CDN keeps your users happier. Also, live
>>>>> streaming
>>>>> and video conferencing aside, most video is not multicast or
>>>>> broadcast,
>>>>> but unicast.
>>>>>
>>>>> DNS on Starlink satellites: Good idea, lightweight, and I'd suspect
>>>>> maybe already in operation? It's low hanging fruit. CDNs on
>>>>> satellites:
>>>>> In the day and age of SSDs, having capacity on the satellite shouldn't
>>>>> really be an issue, although robustness may be. But heat in this sort
>>>>> of
>>>>> storage gets generated mostly when data is written, so it's a function
>>>>> of what percentage of your data that reaches the bird is going to end
>>>>> up
>>>>> in cache. Generally, on a LEO satellite that'll have to cache baseball
>>>>> videos while over the US, videos in a dozen different languages while
>>>>> over Europe, Bollywood clips while over India, cooking shows while
>>>>> over
>>>>> Australia and always the same old ads while over New Zealand, all the
>>>>> while not getting a lot of cache hits for stuff it put into cache 15
>>>>> minutes ago, would probably have to write a lot. Moreover, as you'd be
>>>>> reliant on the content you want being on the satellite that you are
>>>>> currently talking to, pretty much all satellites in the constellation
>>>>> would need to cache all content. In other words: If I watch a cat
>>>>> video
>>>>> now and thereby put it into the cache of the bird overhead, and then
>>>>> send you an e-mail and you're in my neighbourhood and you watch it
>>>>> half
>>>>> an hour later, my satellite would be on the other side of the world,
>>>>> and
>>>>> you'd have to have it re-uploaded to the CDN on the bird that's flying
>>>>> overhead our neighbourhood then. Not as efficient as a ground-based
>>>>> CDN
>>>>> on our ground-based network that's fed via a satellite link.
>>>>>
>>>>> As long as Starlink is going to have in the order of hundreds of
>>>>> thousands of direct users, that problem won't go away.
>>>>>
>>>>> On 31/08/2022 7:33 pm, David Lang wrote:
>>>>>
>>>>>> On Wed, 31 Aug 2022, Ulrich Speidel via Starlink wrote:
>>>>>>
>>>>>>> This combines with the uncomfortable truth that an RF "beam" from a
>>>>>>> satellite isn't as selective as a laser beam, so the options for
>>>>>>> frequency re-use from orbit aren't anywhere near as good as from a
>>>>>>> mobile base station across the road: Any beam pointed at you can be
>>>>>>> heard for many miles around and therefore no other user can re-use
>>>>>>> that frequency (with the same burst slot etc.).
>>>>>>
>>>>>> not quite, you are forgetting that the antennas on the ground are
>>>>>> also
>>>>>> steerable arrays and so they can focus their 'receiving beam' at
>>>>>> different satellites. This is less efficient than a transmitting beam
>>>>>> as the satellites you aren't 'pointed' at will increase your noise
>>>>>> floor, but it does allow the same frequency to be used for multiple
>>>>>> satellites into the same area at the same time.
>>>>>>
>>>>>> David Lang
>>>>>>
>>>>> --
>>>>> ****************************************************************
>>>>> Dr. Ulrich Speidel
>>>>>
>>>>> School of Computer Science
>>>>>
>>>>> Room 303S.594 (City Campus)
>>>>>
>>>>> The University of Auckland
>>>>> u.speidel@auckland.ac.nz
>>>>> http://www.cs.auckland.ac.nz/~ulrich/
>>>> <http://www.cs.auckland.ac.nz/~ulrich>
>>>>> ****************************************************************
>>>>>
>>>> _______________________________________________
>>>> Starlink mailing list
>>>> Starlink@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/starlink
>>>> <https://lists.bufferbloat.net/listinfo/starlink>
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>
>

Re: [Starlink] Starlink "beam spread"

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 393 bytes --]


David Fernández via Starlink wrote:
    > If Starlink satellites are processing IP packets, shouldn't them be
    > shown in traceroutes? They are not shown now, AFAIK.

sadly, they aren't doing IP processing.
I don't think that they ever will decide to for NIH reasons.
I suspect that their SDN hardware probably can, and I think that SR6 is
probably ideal for their use, but...


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: [Starlink] Starlink "beam spread"

[Dave Taht]

In general I have been assuming that the starlink mac layer was
"switched", didn't resemble ethernet much, and can run any protocol on
top. there's a lot of conceptions for this, but my
principal thought is that it looks like this:

dst, src, otherminimalstuff, encrypted payload..

the link to the sat itself is public key encrypted, as well as each
packet payload between dishy and ground.

Re: [Starlink] Starlink "beam spread"

[Darrell Budic]

If I recall correctly, Starlink has told us they encrypt from ground to ground. So whatever they do in the sat constellation, it’s an underlay network and our IP traffic never sees it. This doesn’t preclude ISL, but it does work against the concept of a CDN in space. Seems like it’s easier for them to get on more IXs and even host cache servers at the ground stations if they have enough data center space at them. Of course, there’s nothing preventing them from putting up a satellite that gets treated as an endpoint and does decryption, but then it’s just another end point on their underlay.

> On Sep 1, 2022, at 10:19 AM, David Fernández via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
> If Starlink satellites are processing IP packets, shouldn't them be
> shown in traceroutes? They are not shown now, AFAIK.
> 
> A transparent geographical based routing could be possible, with
> signal-pass-through approach to the next satellite on a path
> connecting to a GW, via ISL, if the satellite receiving traffic from a
> dishy does not have any GW at direct sight.
> 
>> Date: Thu, 1 Sep 2022 09:46:20 +1200
>> From: Ulrich Speidel <u.speidel@auckland.ac.nz>
>> To: starlink@lists.bufferbloat.net
>> Subject: Re: [Starlink] Starlink "beam spread"
>> Message-ID: <7a357510-2d61-dd4a-a59f-3d7d4bd3727c@auckland.ac.nz>
>> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>> 
>> I work on the assumption that Starlink satellites are, or at least will
>> eventually be, processing IP packets. For inter-satellite routing it's
>> more or less a must-have unless you have some other packet switching
>> protocol layered in between.
>> 
>> On 1/09/2022 2:51 am, David Fernández via Starlink wrote:
>>> "DNS on Starlink satellites: Good idea, lightweight, and I'd suspect
>>> maybe already in operation?"
>>> 
>>> Are the satellites processing IP packets? Are the ISLs even in
>>> operation? I have been told Starlink satellites are transparent.
>>> 
>>> 
>>>> Date: Thu, 1 Sep 2022 01:41:07 +1200
>>>> From: Ulrich Speidel <u.speidel@auckland.ac.nz>
>>>> To: David Lang <david@lang.hm>
>>>> Cc: Sebastian Moeller <moeller0@gmx.de>, Ulrich Speidel via Starlink
>>>> <starlink@lists.bufferbloat.net>
>>>> Subject: Re: [Starlink] Starlink "beam spread"
>>>> Message-ID: <56e56b0f-07bd-fe0c-9434-2663ae9d4404@auckland.ac.nz>
>>>> Content-Type: text/plain; charset=UTF-8; format=flowed
>>>> 
>>>> Um, yes, but I think we're mixing a few things up here (trying to bundle
>>>> responses here, so that's not just to you, David).
>>>> 
>>>> In lieu of a reliable Starlink link budget, I'm going by this one:
>>>> 
>>>> 
>>> https://www.linkedin.com/pulse/quick-analysis-starlink-link-budget-potential-emf-david-witkowski/
>>> 
>>> <https://www.linkedin.com/pulse/quick-analysis-starlink-link-budget-potential-emf-david-witkowski>
>>>> 
>>>> Parameters here are a little outdated but the critical one is the EIRP
>>>> at the transmitter of up to ~97 dBm. Say we're looking at a 30 GHz Ka
>>>> band signal over a 600 km path, which is more reflective of the current
>>>> constellation. Then Friis propagation gives us a path loss of about 178
>>>> dB, and if we pretend for a moment that Dishy is actually a 60 cm
>>>> diameter parabolic dish, we're looking at around 45 dBi receive antenna
>>>> gain. Probably a little less as Dishy isn't actually a dish.
>>>> 
>>>> Then that gives us 97 dBm - 178 dB + 45 dB = -36 dBm at the ground
>>>> receiver. Now I'm assuming here that this is for ALL user downlink beams
>>>> from the satellite combined. What we don't really know is how many
>>>> parallel signals a satellite multiplexes into these, but assuming at the
>>>> moment a receive frontend bandwidth of about 100 MHz, noise power at the
>>>> receiver should be around 38 pW or -74 dBm. That leaves Starlink around
>>>> 38 dB of SNR to play with. Shannon lets us send up to just over 1.25
>>>> Gb/s in that kind of channel, but then again that's just the Shannon
>>>> limit, and in practice, we'll be looking a a wee bit less.
>>>> 
>>>> That SNR also gives us an indication as to the signal separation Dishy
>>>> needs to achieve from the beams from another satellite in order for that
>>>> other satellite to re-use the same frequency. Note that this is
>>>> significantly more than just the 3 dB that the 3 dB width of a beam
>>>> gives us. The 3 dB width is what is commonly quoted as "beam width", and
>>>> that's where you get those nice narrow angles. But that's just the width
>>>> at which the beam drops to half its EIRP, not the width at which it can
>>>> no longer interfere. For that, you need the 38 dB width - or thereabouts
>>>> - if you can get it, and this will be significantly more than the 1.2
>>>> degrees or so of 3dB beam width.
>>>> 
>>>> But even if you worked with 1.2 degrees at a distance of 600 km and you
>>>> assumed that sort of beam width at the satellite, it still gives you an
>>>>> 12 km radius on the ground within which you cannot reuse the downlink
>>>> frequency from the same satellite. That's orders of magnitude more than
>>>> the re-use spatial separation you can achieve in ground-based cellular
>>>> networks. Note that the 0.1 deg beam "precision" is irrelevant here -
>>>> that just tells me the increments in which they can point the beam, but
>>>> not how wide it is and how intensity falls off with angle, or how bad
>>>> the side lobes are.
>>>> 
>>>> Whether you can re-use the same frequency from another satellite to the
>>>> same ground area is a good question. We really don't know the beam
>>>> patterns that we get from the birds and from the Dishys, and without
>>>> these it's difficult to say how much angular separation a ground station
>>>> needs between two satellites using the same frequency in order to
>>>> receive one but not be interfered with by the other. Basically, there
>>>> are just too many variables in this for me to be overly optimistic that
>>>> re-use by two different sources within a Starlink cell is possible. And
>>>> I haven't even looked at the numbers for Ku band here.
>>>> 
>>>> CDNs & Co - are NOT just dumb economic optimisations to lower bit miles.
>>>> They actually improve performance, and significantly so. A lower RTT
>>>> between you and a server that you grab data from via TCP allows a much
>>>> faster opening of the congestion window. With initial TCP cwnd's being
>>>> typically 10 packets or around 15 kB of data, having a server within 10
>>>> ms of your client means that you've transferred 15 kB after 5 ms, 45 kB
>>>> after 10 ms, 105 kB after 15 ms, 225 kB after 20 ms, and 465 kB after 25
>>>> ms. Make your RTT 100 ms, and it takes half a second to get to your 465
>>>> kB. Having a CDN server in close topological proximity also generally
>>>> reduces the number of queues between you and the server at which packets
>>>> can die an untimely early death, and generally, by taking load off such
>>>> links, reduces the probability of this happening at a lot of queues.
>>>> Bottom line: Having a CDN keeps your users happier. Also, live streaming
>>>> and video conferencing aside, most video is not multicast or broadcast,
>>>> but unicast.
>>>> 
>>>> DNS on Starlink satellites: Good idea, lightweight, and I'd suspect
>>>> maybe already in operation? It's low hanging fruit. CDNs on satellites:
>>>> In the day and age of SSDs, having capacity on the satellite shouldn't
>>>> really be an issue, although robustness may be. But heat in this sort of
>>>> storage gets generated mostly when data is written, so it's a function
>>>> of what percentage of your data that reaches the bird is going to end up
>>>> in cache. Generally, on a LEO satellite that'll have to cache baseball
>>>> videos while over the US, videos in a dozen different languages while
>>>> over Europe, Bollywood clips while over India, cooking shows while over
>>>> Australia and always the same old ads while over New Zealand, all the
>>>> while not getting a lot of cache hits for stuff it put into cache 15
>>>> minutes ago, would probably have to write a lot. Moreover, as you'd be
>>>> reliant on the content you want being on the satellite that you are
>>>> currently talking to, pretty much all satellites in the constellation
>>>> would need to cache all content. In other words: If I watch a cat video
>>>> now and thereby put it into the cache of the bird overhead, and then
>>>> send you an e-mail and you're in my neighbourhood and you watch it half
>>>> an hour later, my satellite would be on the other side of the world, and
>>>> you'd have to have it re-uploaded to the CDN on the bird that's flying
>>>> overhead our neighbourhood then. Not as efficient as a ground-based CDN
>>>> on our ground-based network that's fed via a satellite link.
>>>> 
>>>> As long as Starlink is going to have in the order of hundreds of
>>>> thousands of direct users, that problem won't go away.
>>>> 
>>>> On 31/08/2022 7:33 pm, David Lang wrote:
>>>> 
>>>>> On Wed, 31 Aug 2022, Ulrich Speidel via Starlink wrote:
>>>>> 
>>>>>> This combines with the uncomfortable truth that an RF "beam" from a
>>>>>> satellite isn't as selective as a laser beam, so the options for
>>>>>> frequency re-use from orbit aren't anywhere near as good as from a
>>>>>> mobile base station across the road: Any beam pointed at you can be
>>>>>> heard for many miles around and therefore no other user can re-use
>>>>>> that frequency (with the same burst slot etc.).
>>>>> 
>>>>> not quite, you are forgetting that the antennas on the ground are also
>>>>> steerable arrays and so they can focus their 'receiving beam' at
>>>>> different satellites. This is less efficient than a transmitting beam
>>>>> as the satellites you aren't 'pointed' at will increase your noise
>>>>> floor, but it does allow the same frequency to be used for multiple
>>>>> satellites into the same area at the same time.
>>>>> 
>>>>> David Lang
>>>>> 
>>>> --
>>>> ****************************************************************
>>>> Dr. Ulrich Speidel
>>>> 
>>>> School of Computer Science
>>>> 
>>>> Room 303S.594 (City Campus)
>>>> 
>>>> The University of Auckland
>>>> u.speidel@auckland.ac.nz
>>>> http://www.cs.auckland.ac.nz/~ulrich/
>>> <http://www.cs.auckland.ac.nz/~ulrich>
>>>> ****************************************************************
>>>> 
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
>>> <https://lists.bufferbloat.net/listinfo/starlink>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Starlink "beam spread"

[David Fernández]

If Starlink satellites are processing IP packets, shouldn't them be
shown in traceroutes? They are not shown now, AFAIK.

A transparent geographical based routing could be possible, with
signal-pass-through approach to the next satellite on a path
connecting to a GW, via ISL, if the satellite receiving traffic from a
dishy does not have any GW at direct sight.

> Date: Thu, 1 Sep 2022 09:46:20 +1200
> From: Ulrich Speidel <u.speidel@auckland.ac.nz>
> To: starlink@lists.bufferbloat.net
> Subject: Re: [Starlink] Starlink "beam spread"
> Message-ID: <7a357510-2d61-dd4a-a59f-3d7d4bd3727c@auckland.ac.nz>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> I work on the assumption that Starlink satellites are, or at least will
> eventually be, processing IP packets. For inter-satellite routing it's
> more or less a must-have unless you have some other packet switching
> protocol layered in between.
>
> On 1/09/2022 2:51 am, David Fernández via Starlink wrote:
>> "DNS on Starlink satellites: Good idea, lightweight, and I'd suspect
>> maybe already in operation?"
>>
>> Are the satellites processing IP packets? Are the ISLs even in
>> operation? I have been told Starlink satellites are transparent.
>>
>>
>> > Date: Thu, 1 Sep 2022 01:41:07 +1200
>> > From: Ulrich Speidel <u.speidel@auckland.ac.nz>
>> > To: David Lang <david@lang.hm>
>> > Cc: Sebastian Moeller <moeller0@gmx.de>, Ulrich Speidel via Starlink
>> > <starlink@lists.bufferbloat.net>
>> > Subject: Re: [Starlink] Starlink "beam spread"
>> > Message-ID: <56e56b0f-07bd-fe0c-9434-2663ae9d4404@auckland.ac.nz>
>> > Content-Type: text/plain; charset=UTF-8; format=flowed
>> >
>> > Um, yes, but I think we're mixing a few things up here (trying to bundle
>> > responses here, so that's not just to you, David).
>> >
>> > In lieu of a reliable Starlink link budget, I'm going by this one:
>> >
>> >
>> https://www.linkedin.com/pulse/quick-analysis-starlink-link-budget-potential-emf-david-witkowski/
>>
>> <https://www.linkedin.com/pulse/quick-analysis-starlink-link-budget-potential-emf-david-witkowski>
>> >
>> > Parameters here are a little outdated but the critical one is the EIRP
>> > at the transmitter of up to ~97 dBm. Say we're looking at a 30 GHz Ka
>> > band signal over a 600 km path, which is more reflective of the current
>> > constellation. Then Friis propagation gives us a path loss of about 178
>> > dB, and if we pretend for a moment that Dishy is actually a 60 cm
>> > diameter parabolic dish, we're looking at around 45 dBi receive antenna
>> > gain. Probably a little less as Dishy isn't actually a dish.
>> >
>> > Then that gives us 97 dBm - 178 dB + 45 dB = -36 dBm at the ground
>> > receiver. Now I'm assuming here that this is for ALL user downlink beams
>> > from the satellite combined. What we don't really know is how many
>> > parallel signals a satellite multiplexes into these, but assuming at the
>> > moment a receive frontend bandwidth of about 100 MHz, noise power at the
>> > receiver should be around 38 pW or -74 dBm. That leaves Starlink around
>> > 38 dB of SNR to play with. Shannon lets us send up to just over 1.25
>> > Gb/s in that kind of channel, but then again that's just the Shannon
>> > limit, and in practice, we'll be looking a a wee bit less.
>> >
>> > That SNR also gives us an indication as to the signal separation Dishy
>> > needs to achieve from the beams from another satellite in order for that
>> > other satellite to re-use the same frequency. Note that this is
>> > significantly more than just the 3 dB that the 3 dB width of a beam
>> > gives us. The 3 dB width is what is commonly quoted as "beam width", and
>> > that's where you get those nice narrow angles. But that's just the width
>> > at which the beam drops to half its EIRP, not the width at which it can
>> > no longer interfere. For that, you need the 38 dB width - or thereabouts
>> > - if you can get it, and this will be significantly more than the 1.2
>> > degrees or so of 3dB beam width.
>> >
>> > But even if you worked with 1.2 degrees at a distance of 600 km and you
>> > assumed that sort of beam width at the satellite, it still gives you an
>> > >12 km radius on the ground within which you cannot reuse the downlink
>> > frequency from the same satellite. That's orders of magnitude more than
>> > the re-use spatial separation you can achieve in ground-based cellular
>> > networks. Note that the 0.1 deg beam "precision" is irrelevant here -
>> > that just tells me the increments in which they can point the beam, but
>> > not how wide it is and how intensity falls off with angle, or how bad
>> > the side lobes are.
>> >
>> > Whether you can re-use the same frequency from another satellite to the
>> > same ground area is a good question. We really don't know the beam
>> > patterns that we get from the birds and from the Dishys, and without
>> > these it's difficult to say how much angular separation a ground station
>> > needs between two satellites using the same frequency in order to
>> > receive one but not be interfered with by the other. Basically, there
>> > are just too many variables in this for me to be overly optimistic that
>> > re-use by two different sources within a Starlink cell is possible. And
>> > I haven't even looked at the numbers for Ku band here.
>> >
>> > CDNs & Co - are NOT just dumb economic optimisations to lower bit miles.
>> > They actually improve performance, and significantly so. A lower RTT
>> > between you and a server that you grab data from via TCP allows a much
>> > faster opening of the congestion window. With initial TCP cwnd's being
>> > typically 10 packets or around 15 kB of data, having a server within 10
>> > ms of your client means that you've transferred 15 kB after 5 ms, 45 kB
>> > after 10 ms, 105 kB after 15 ms, 225 kB after 20 ms, and 465 kB after 25
>> > ms. Make your RTT 100 ms, and it takes half a second to get to your 465
>> > kB. Having a CDN server in close topological proximity also generally
>> > reduces the number of queues between you and the server at which packets
>> > can die an untimely early death, and generally, by taking load off such
>> > links, reduces the probability of this happening at a lot of queues.
>> > Bottom line: Having a CDN keeps your users happier. Also, live streaming
>> > and video conferencing aside, most video is not multicast or broadcast,
>> > but unicast.
>> >
>> > DNS on Starlink satellites: Good idea, lightweight, and I'd suspect
>> > maybe already in operation? It's low hanging fruit. CDNs on satellites:
>> > In the day and age of SSDs, having capacity on the satellite shouldn't
>> > really be an issue, although robustness may be. But heat in this sort of
>> > storage gets generated mostly when data is written, so it's a function
>> > of what percentage of your data that reaches the bird is going to end up
>> > in cache. Generally, on a LEO satellite that'll have to cache baseball
>> > videos while over the US, videos in a dozen different languages while
>> > over Europe, Bollywood clips while over India, cooking shows while over
>> > Australia and always the same old ads while over New Zealand, all the
>> > while not getting a lot of cache hits for stuff it put into cache 15
>> > minutes ago, would probably have to write a lot. Moreover, as you'd be
>> > reliant on the content you want being on the satellite that you are
>> > currently talking to, pretty much all satellites in the constellation
>> > would need to cache all content. In other words: If I watch a cat video
>> > now and thereby put it into the cache of the bird overhead, and then
>> > send you an e-mail and you're in my neighbourhood and you watch it half
>> > an hour later, my satellite would be on the other side of the world, and
>> > you'd have to have it re-uploaded to the CDN on the bird that's flying
>> > overhead our neighbourhood then. Not as efficient as a ground-based CDN
>> > on our ground-based network that's fed via a satellite link.
>> >
>> > As long as Starlink is going to have in the order of hundreds of
>> > thousands of direct users, that problem won't go away.
>> >
>> > On 31/08/2022 7:33 pm, David Lang wrote:
>> >
>> >> On Wed, 31 Aug 2022, Ulrich Speidel via Starlink wrote:
>> >>
>> >>> This combines with the uncomfortable truth that an RF "beam" from a
>> >>> satellite isn't as selective as a laser beam, so the options for
>> >>> frequency re-use from orbit aren't anywhere near as good as from a
>> >>> mobile base station across the road: Any beam pointed at you can be
>> >>> heard for many miles around and therefore no other user can re-use
>> >>> that frequency (with the same burst slot etc.).
>> >>
>> >> not quite, you are forgetting that the antennas on the ground are also
>> >> steerable arrays and so they can focus their 'receiving beam' at
>> >> different satellites. This is less efficient than a transmitting beam
>> >> as the satellites you aren't 'pointed' at will increase your noise
>> >> floor, but it does allow the same frequency to be used for multiple
>> >> satellites into the same area at the same time.
>> >>
>> >> David Lang
>> >>
>> > --
>> > ****************************************************************
>> > Dr. Ulrich Speidel
>> >
>> > School of Computer Science
>> >
>> > Room 303S.594 (City Campus)
>> >
>> > The University of Auckland
>> > u.speidel@auckland.ac.nz
>> > http://www.cs.auckland.ac.nz/~ulrich/
>> <http://www.cs.auckland.ac.nz/~ulrich>
>> > ****************************************************************
>> >
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>> <https://lists.bufferbloat.net/listinfo/starlink>

Re: [Starlink] Starlink "beam spread"

[Ulrich Speidel]

[-- Attachment #1: Type: text/plain, Size: 840 bytes --]

On 1/09/2022 7:05 pm, Mike Puchol via Starlink wrote:
>
> There is circumstantial evidence from a user in Nigeria that was 
> getting service and exiting via London, there is no evidence that any 
> of the gateways in Nigeria are operational, so ISL could have played a 
> role: 
> https://www.reddit.com/r/Starlink/comments/wwg0nc/starlink_speed_test_in_nigeria/ 
> <https://www.reddit.com/r/Starlink/comments/wwg0nc/starlink_speed_test_in_nigeria/>
>
Where does it mention that it was exiting via London?

-- 

****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz  
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************



[-- Attachment #2: Type: text/html, Size: 1611 bytes --]

Re: [Starlink] Starlink "beam spread"

[David Lang]

On Wed, 31 Aug 2022, David P. Reed wrote:

> I'm not going to reason from "intersatellite" routing being operational until 
> they offer it in operation. It's feasible, sort of. Laser beam aiming is quite 
> different from phased array beam steering, and though they may have tested it 
> between two satellites, that makes it a "link technology" not a network. (you 
> can steer a laser beam by moving lightweight mirrors, I know. But tracking 
> isn't so easy when both satellites are moving relative to each other - it 
> seems like way beyond the technology base that Starlink has put in its 
> satellites so far. But who knows.

They have been launching laser enabled satellites for a while now. I suspect
that the only way we will really know when they are enabled is when we see
coverage expand to the poles and mid-ocean (unless they make announcements about
it)

I doubt that they would be launching laser enabled satellites that could not
track each other.

David Lang

Re: [Starlink] Starlink "beam spread"

[Mike Puchol]

[-- Attachment #1: Type: text/plain, Size: 2916 bytes --]

The primary reason for -not- offering service in any given country is, primarily, regulatory (see the South Africa case). Once they
> I'm not going to reason from "intersatellite" routing being operational until they offer it in operation. It's feasible, sort of. Laser beam aiming is quite different from phased array beam steering, and though they may have tested it between two satellites, that makes it a "link technology" not a network. (you can steer a laser beam by moving lightweight mirrors, I know. But tracking isn't so easy when both satellites are moving relative to each other - it seems like way beyond the technology base that Starlink has put in its satellites so far. But who knows.

We operate several of these in Kenya: https://x.company/projects/taara

They offer 20 Gbps at distances of 20km, and they operate under considerably more vibration, motion, and scintillation than you have in space. They have no issue keeping track of each other once initial acquisition is made. SpaceX launched 10 satellites into polar orbit in Jan 2021, which it used to test and characterize the ISL optical heads - you could see them positioning the satellites in configurations to test side-looking (thus cross-plane), and at different altitudes (cross-shell), and even parallel links to characterize hardware differences (we did this with ours in Kenya too). It was fascinating to watch. I’m quite certain the least problem for Starlink (unless they made major boo-boos in hardware or software) is acquisition and tracking.

A very good book (but not cheap) on the topic is "Free Space Optical Communication” by Hemani Kaushal.
> As far as "intersatellite" routing being out there soon, well, there's no evidence it's happening soon.

There is circumstantial evidence from a user in Nigeria that was getting service and exiting via London, there is no evidence that any of the gateways in Nigeria are operational, so ISL could have played a role: https://www.reddit.com/r/Starlink/comments/wwg0nc/starlink_speed_test_in_nigeria/

Best,

Mike
On Aug 31, 2022, 23:33 +0200, David Lang via Starlink <starlink@lists.bufferbloat.net>, wrote:
> On Wed, 31 Aug 2022, David P. Reed wrote:
>
> > What's interesting to me is that their coverage map definitely doesn't cover
> > Africa, South America, Cuba, large parts of Asia, and it isn't planned - if
> > they had "mesh routing" working among satellites, those would be easy. But
> > instead, they seem to be focused on the satellite one-bounce architecture
> > (what the satellite industry calls "bent-pipe" however it is done).
>
> The countries covered in the coverage map seems to be as much or more restricted
> by regulations as anything technical.
>
> David Lang
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

[-- Attachment #2: Type: text/html, Size: 4071 bytes --]

Re: [Starlink] Starlink "beam spread"

[Lin Han]

[-- Attachment #1: Type: text/plain, Size: 11734 bytes --]

Hi, Ulrich,

I agree with you even I don't know if StarLink satellite will process IP packet. IETF may work on this area soon. IP is the mandatory if some IP based features are moved to satellite, such as DNS, CDN, etc. Also, from 3GPP perspective, future LEO satellite network should be IP based. Then, the NTN integration with 5G and Internet can be done.
check out my slide: https://datatracker.ietf.org/doc/slides-114-hotrfc-sessa-the-leo-satellite-networking-lin-han/. We will have side meeting to discuss this in the next IETF 115 (London).

BRs.

Lin



From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of Ulrich Speidel via Starlink
Sent: Wednesday, August 31, 2022 2:46 PM
To: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] Starlink "beam spread"


I work on the assumption that Starlink satellites are, or at least will eventually be, processing IP packets. For inter-satellite routing it's more or less a must-have unless you have some other packet switching protocol layered in between.
On 1/09/2022 2:51 am, David Fernández via Starlink wrote:
"DNS on Starlink satellites: Good idea, lightweight, and I'd suspect
maybe already in operation?"

Are the satellites processing IP packets? Are the ISLs even in
operation? I have been told Starlink satellites are transparent.


> Date: Thu, 1 Sep 2022 01:41:07 +1200
> From: Ulrich Speidel <u.speidel@auckland.ac.nz><mailto:u.speidel@auckland.ac.nz>
> To: David Lang <david@lang.hm><mailto:david@lang.hm>
> Cc: Sebastian Moeller <moeller0@gmx.de><mailto:moeller0@gmx.de>, Ulrich Speidel via Starlink
> <starlink@lists.bufferbloat.net><mailto:starlink@lists.bufferbloat.net>
> Subject: Re: [Starlink] Starlink "beam spread"
> Message-ID: <56e56b0f-07bd-fe0c-9434-2663ae9d4404@auckland.ac.nz><mailto:56e56b0f-07bd-fe0c-9434-2663ae9d4404@auckland.ac.nz>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Um, yes, but I think we're mixing a few things up here (trying to bundle
> responses here, so that's not just to you, David).
>
> In lieu of a reliable Starlink link budget, I'm going by this one:
>
> https://www.linkedin.com/pulse/quick-analysis-starlink-link-budget-potential-emf-david-witkowski/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fpulse%2Fquick-analysis-starlink-link-budget-potential-emf-david-witkowski&data=05%7C01%7Clin.han%40futurewei.com%7Ca42f8a5df7de45f239e708da8b9a4324%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637975791971369095%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2F%2BC4lM8fTdy9ZwX9%2FvGWPsoDKgDo3JWWxldoKyF%2FePw%3D&reserved=0>
>
> Parameters here are a little outdated but the critical one is the EIRP
> at the transmitter of up to ~97 dBm. Say we're looking at a 30 GHz Ka
> band signal over a 600 km path, which is more reflective of the current
> constellation. Then Friis propagation gives us a path loss of about 178
> dB, and if we pretend for a moment that Dishy is actually a 60 cm
> diameter parabolic dish, we're looking at around 45 dBi receive antenna
> gain. Probably a little less as Dishy isn't actually a dish.
>
> Then that gives us 97 dBm - 178 dB + 45 dB = -36 dBm at the ground
> receiver. Now I'm assuming here that this is for ALL user downlink beams
> from the satellite combined. What we don't really know is how many
> parallel signals a satellite multiplexes into these, but assuming at the
> moment a receive frontend bandwidth of about 100 MHz, noise power at the
> receiver should be around 38 pW or -74 dBm. That leaves Starlink around
> 38 dB of SNR to play with. Shannon lets us send up to just over 1.25
> Gb/s in that kind of channel, but then again that's just the Shannon
> limit, and in practice, we'll be looking a a wee bit less.
>
> That SNR also gives us an indication as to the signal separation Dishy
> needs to achieve from the beams from another satellite in order for that
> other satellite to re-use the same frequency. Note that this is
> significantly more than just the 3 dB that the 3 dB width of a beam
> gives us. The 3 dB width is what is commonly quoted as "beam width", and
> that's where you get those nice narrow angles. But that's just the width
> at which the beam drops to half its EIRP, not the width at which it can
> no longer interfere. For that, you need the 38 dB width - or thereabouts
> - if you can get it, and this will be significantly more than the 1.2
> degrees or so of 3dB beam width.
>
> But even if you worked with 1.2 degrees at a distance of 600 km and you
> assumed that sort of beam width at the satellite, it still gives you an
> >12 km radius on the ground within which you cannot reuse the downlink
> frequency from the same satellite. That's orders of magnitude more than
> the re-use spatial separation you can achieve in ground-based cellular
> networks. Note that the 0.1 deg beam "precision" is irrelevant here -
> that just tells me the increments in which they can point the beam, but
> not how wide it is and how intensity falls off with angle, or how bad
> the side lobes are.
>
> Whether you can re-use the same frequency from another satellite to the
> same ground area is a good question. We really don't know the beam
> patterns that we get from the birds and from the Dishys, and without
> these it's difficult to say how much angular separation a ground station
> needs between two satellites using the same frequency in order to
> receive one but not be interfered with by the other. Basically, there
> are just too many variables in this for me to be overly optimistic that
> re-use by two different sources within a Starlink cell is possible. And
> I haven't even looked at the numbers for Ku band here.
>
> CDNs & Co - are NOT just dumb economic optimisations to lower bit miles.
> They actually improve performance, and significantly so. A lower RTT
> between you and a server that you grab data from via TCP allows a much
> faster opening of the congestion window. With initial TCP cwnd's being
> typically 10 packets or around 15 kB of data, having a server within 10
> ms of your client means that you've transferred 15 kB after 5 ms, 45 kB
> after 10 ms, 105 kB after 15 ms, 225 kB after 20 ms, and 465 kB after 25
> ms. Make your RTT 100 ms, and it takes half a second to get to your 465
> kB. Having a CDN server in close topological proximity also generally
> reduces the number of queues between you and the server at which packets
> can die an untimely early death, and generally, by taking load off such
> links, reduces the probability of this happening at a lot of queues.
> Bottom line: Having a CDN keeps your users happier. Also, live streaming
> and video conferencing aside, most video is not multicast or broadcast,
> but unicast.
>
> DNS on Starlink satellites: Good idea, lightweight, and I'd suspect
> maybe already in operation? It's low hanging fruit. CDNs on satellites:
> In the day and age of SSDs, having capacity on the satellite shouldn't
> really be an issue, although robustness may be. But heat in this sort of
> storage gets generated mostly when data is written, so it's a function
> of what percentage of your data that reaches the bird is going to end up
> in cache. Generally, on a LEO satellite that'll have to cache baseball
> videos while over the US, videos in a dozen different languages while
> over Europe, Bollywood clips while over India, cooking shows while over
> Australia and always the same old ads while over New Zealand, all the
> while not getting a lot of cache hits for stuff it put into cache 15
> minutes ago, would probably have to write a lot. Moreover, as you'd be
> reliant on the content you want being on the satellite that you are
> currently talking to, pretty much all satellites in the constellation
> would need to cache all content. In other words: If I watch a cat video
> now and thereby put it into the cache of the bird overhead, and then
> send you an e-mail and you're in my neighbourhood and you watch it half
> an hour later, my satellite would be on the other side of the world, and
> you'd have to have it re-uploaded to the CDN on the bird that's flying
> overhead our neighbourhood then. Not as efficient as a ground-based CDN
> on our ground-based network that's fed via a satellite link.
>
> As long as Starlink is going to have in the order of hundreds of
> thousands of direct users, that problem won't go away.
>
> On 31/08/2022 7:33 pm, David Lang wrote:
>
>> On Wed, 31 Aug 2022, Ulrich Speidel via Starlink wrote:
>>
>>> This combines with the uncomfortable truth that an RF "beam" from a
>>> satellite isn't as selective as a laser beam, so the options for
>>> frequency re-use from orbit aren't anywhere near as good as from a
>>> mobile base station across the road: Any beam pointed at you can be
>>> heard for many miles around and therefore no other user can re-use
>>> that frequency (with the same burst slot etc.).
>>
>> not quite, you are forgetting that the antennas on the ground are also
>> steerable arrays and so they can focus their 'receiving beam' at
>> different satellites. This is less efficient than a transmitting beam
>> as the satellites you aren't 'pointed' at will increase your noise
>> floor, but it does allow the same frequency to be used for multiple
>> satellites into the same area at the same time.
>>
>> David Lang
>>
> --
> ****************************************************************
> Dr. Ulrich Speidel
>
> School of Computer Science
>
> Room 303S.594 (City Campus)
>
> The University of Auckland
> u.speidel@auckland.ac.nz<mailto:u.speidel@auckland.ac.nz>
> http://www.cs.auckland.ac.nz/~ulrich/<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cs.auckland.ac.nz%2F~ulrich&data=05%7C01%7Clin.han%40futurewei.com%7Ca42f8a5df7de45f239e708da8b9a4324%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637975791971369095%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=VmZuZendHQ4aco0nywbdmA%2FRg1j77iaO67KQstBQNks%3D&reserved=0>
> ****************************************************************
>
_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net<mailto:Starlink@lists.bufferbloat.net>
https://lists.bufferbloat.net/listinfo/starlink<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.bufferbloat.net%2Flistinfo%2Fstarlink&data=05%7C01%7Clin.han%40futurewei.com%7Ca42f8a5df7de45f239e708da8b9a4324%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637975791971369095%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=OI%2B4gUpL6bRmDK383Nf%2BCL%2FyOI6mZADjvWnDtcDfa5k%3D&reserved=0>

--

****************************************************************

Dr. Ulrich Speidel



School of Computer Science



Room 303S.594 (City Campus)



The University of Auckland

u.speidel@auckland.ac.nz<mailto:u.speidel@auckland.ac.nz>

http://www.cs.auckland.ac.nz/~ulrich/<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cs.auckland.ac.nz%2F~ulrich%2F&data=05%7C01%7Clin.han%40futurewei.com%7Ca42f8a5df7de45f239e708da8b9a4324%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637975791971369095%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=A09JGBKfdxaK3IhoiegLHxlI1ph7TfKa1X%2FxsuVeboM%3D&reserved=0>

****************************************************************







[-- Attachment #2: Type: text/html, Size: 16427 bytes --]

Re: [Starlink] Starlink "beam spread"

[Ulrich Speidel]

[-- Attachment #1: Type: text/plain, Size: 9410 bytes --]

I work on the assumption that Starlink satellites are, or at least will 
eventually be, processing IP packets. For inter-satellite routing it's 
more or less a must-have unless you have some other packet switching 
protocol layered in between.

On 1/09/2022 2:51 am, David Fernández via Starlink wrote:
> "DNS on Starlink satellites: Good idea, lightweight, and I'd suspect
> maybe already in operation?"
>
> Are the satellites processing IP packets? Are the ISLs even in
> operation? I have been told Starlink satellites are transparent.
>
>
> > Date: Thu, 1 Sep 2022 01:41:07 +1200
> > From: Ulrich Speidel <u.speidel@auckland.ac.nz>
> > To: David Lang <david@lang.hm>
> > Cc: Sebastian Moeller <moeller0@gmx.de>, Ulrich Speidel via Starlink
> > <starlink@lists.bufferbloat.net>
> > Subject: Re: [Starlink] Starlink "beam spread"
> > Message-ID: <56e56b0f-07bd-fe0c-9434-2663ae9d4404@auckland.ac.nz>
> > Content-Type: text/plain; charset=UTF-8; format=flowed
> >
> > Um, yes, but I think we're mixing a few things up here (trying to bundle
> > responses here, so that's not just to you, David).
> >
> > In lieu of a reliable Starlink link budget, I'm going by this one:
> >
> > 
> https://www.linkedin.com/pulse/quick-analysis-starlink-link-budget-potential-emf-david-witkowski/ 
> <https://www.linkedin.com/pulse/quick-analysis-starlink-link-budget-potential-emf-david-witkowski>
> >
> > Parameters here are a little outdated but the critical one is the EIRP
> > at the transmitter of up to ~97 dBm. Say we're looking at a 30 GHz Ka
> > band signal over a 600 km path, which is more reflective of the current
> > constellation. Then Friis propagation gives us a path loss of about 178
> > dB, and if we pretend for a moment that Dishy is actually a 60 cm
> > diameter parabolic dish, we're looking at around 45 dBi receive antenna
> > gain. Probably a little less as Dishy isn't actually a dish.
> >
> > Then that gives us 97 dBm - 178 dB + 45 dB = -36 dBm at the ground
> > receiver. Now I'm assuming here that this is for ALL user downlink beams
> > from the satellite combined. What we don't really know is how many
> > parallel signals a satellite multiplexes into these, but assuming at the
> > moment a receive frontend bandwidth of about 100 MHz, noise power at the
> > receiver should be around 38 pW or -74 dBm. That leaves Starlink around
> > 38 dB of SNR to play with. Shannon lets us send up to just over 1.25
> > Gb/s in that kind of channel, but then again that's just the Shannon
> > limit, and in practice, we'll be looking a a wee bit less.
> >
> > That SNR also gives us an indication as to the signal separation Dishy
> > needs to achieve from the beams from another satellite in order for that
> > other satellite to re-use the same frequency. Note that this is
> > significantly more than just the 3 dB that the 3 dB width of a beam
> > gives us. The 3 dB width is what is commonly quoted as "beam width", and
> > that's where you get those nice narrow angles. But that's just the width
> > at which the beam drops to half its EIRP, not the width at which it can
> > no longer interfere. For that, you need the 38 dB width - or thereabouts
> > - if you can get it, and this will be significantly more than the 1.2
> > degrees or so of 3dB beam width.
> >
> > But even if you worked with 1.2 degrees at a distance of 600 km and you
> > assumed that sort of beam width at the satellite, it still gives you an
> > >12 km radius on the ground within which you cannot reuse the downlink
> > frequency from the same satellite. That's orders of magnitude more than
> > the re-use spatial separation you can achieve in ground-based cellular
> > networks. Note that the 0.1 deg beam "precision" is irrelevant here -
> > that just tells me the increments in which they can point the beam, but
> > not how wide it is and how intensity falls off with angle, or how bad
> > the side lobes are.
> >
> > Whether you can re-use the same frequency from another satellite to the
> > same ground area is a good question. We really don't know the beam
> > patterns that we get from the birds and from the Dishys, and without
> > these it's difficult to say how much angular separation a ground station
> > needs between two satellites using the same frequency in order to
> > receive one but not be interfered with by the other. Basically, there
> > are just too many variables in this for me to be overly optimistic that
> > re-use by two different sources within a Starlink cell is possible. And
> > I haven't even looked at the numbers for Ku band here.
> >
> > CDNs & Co - are NOT just dumb economic optimisations to lower bit miles.
> > They actually improve performance, and significantly so. A lower RTT
> > between you and a server that you grab data from via TCP allows a much
> > faster opening of the congestion window. With initial TCP cwnd's being
> > typically 10 packets or around 15 kB of data, having a server within 10
> > ms of your client means that you've transferred 15 kB after 5 ms, 45 kB
> > after 10 ms, 105 kB after 15 ms, 225 kB after 20 ms, and 465 kB after 25
> > ms. Make your RTT 100 ms, and it takes half a second to get to your 465
> > kB. Having a CDN server in close topological proximity also generally
> > reduces the number of queues between you and the server at which packets
> > can die an untimely early death, and generally, by taking load off such
> > links, reduces the probability of this happening at a lot of queues.
> > Bottom line: Having a CDN keeps your users happier. Also, live streaming
> > and video conferencing aside, most video is not multicast or broadcast,
> > but unicast.
> >
> > DNS on Starlink satellites: Good idea, lightweight, and I'd suspect
> > maybe already in operation? It's low hanging fruit. CDNs on satellites:
> > In the day and age of SSDs, having capacity on the satellite shouldn't
> > really be an issue, although robustness may be. But heat in this sort of
> > storage gets generated mostly when data is written, so it's a function
> > of what percentage of your data that reaches the bird is going to end up
> > in cache. Generally, on a LEO satellite that'll have to cache baseball
> > videos while over the US, videos in a dozen different languages while
> > over Europe, Bollywood clips while over India, cooking shows while over
> > Australia and always the same old ads while over New Zealand, all the
> > while not getting a lot of cache hits for stuff it put into cache 15
> > minutes ago, would probably have to write a lot. Moreover, as you'd be
> > reliant on the content you want being on the satellite that you are
> > currently talking to, pretty much all satellites in the constellation
> > would need to cache all content. In other words: If I watch a cat video
> > now and thereby put it into the cache of the bird overhead, and then
> > send you an e-mail and you're in my neighbourhood and you watch it half
> > an hour later, my satellite would be on the other side of the world, and
> > you'd have to have it re-uploaded to the CDN on the bird that's flying
> > overhead our neighbourhood then. Not as efficient as a ground-based CDN
> > on our ground-based network that's fed via a satellite link.
> >
> > As long as Starlink is going to have in the order of hundreds of
> > thousands of direct users, that problem won't go away.
> >
> > On 31/08/2022 7:33 pm, David Lang wrote:
> >
> >> On Wed, 31 Aug 2022, Ulrich Speidel via Starlink wrote:
> >>
> >>> This combines with the uncomfortable truth that an RF "beam" from a
> >>> satellite isn't as selective as a laser beam, so the options for
> >>> frequency re-use from orbit aren't anywhere near as good as from a
> >>> mobile base station across the road: Any beam pointed at you can be
> >>> heard for many miles around and therefore no other user can re-use
> >>> that frequency (with the same burst slot etc.).
> >>
> >> not quite, you are forgetting that the antennas on the ground are also
> >> steerable arrays and so they can focus their 'receiving beam' at
> >> different satellites. This is less efficient than a transmitting beam
> >> as the satellites you aren't 'pointed' at will increase your noise
> >> floor, but it does allow the same frequency to be used for multiple
> >> satellites into the same area at the same time.
> >>
> >> David Lang
> >>
> > --
> > ****************************************************************
> > Dr. Ulrich Speidel
> >
> > School of Computer Science
> >
> > Room 303S.594 (City Campus)
> >
> > The University of Auckland
> > u.speidel@auckland.ac.nz
> > http://www.cs.auckland.ac.nz/~ulrich/ 
> <http://www.cs.auckland.ac.nz/~ulrich>
> > ****************************************************************
> >
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink 
> <https://lists.bufferbloat.net/listinfo/starlink>

-- 
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz  
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************



[-- Attachment #2: Type: text/html, Size: 13030 bytes --]

Re: [Starlink] Starlink "beam spread"

[David Lang]

On Wed, 31 Aug 2022, David P. Reed wrote:

> What's interesting to me is that their coverage map definitely doesn't cover 
> Africa, South America, Cuba, large parts of Asia, and it isn't planned - if 
> they had "mesh routing" working among satellites, those would be easy. But 
> instead, they seem to be focused on the satellite one-bounce architecture 
> (what the satellite industry calls "bent-pipe" however it is done).

The countries covered in the coverage map seems to be as much or more restricted 
by regulations as anything technical.

David Lang

Re: [Starlink] Starlink "beam spread"

[David P. Reed]

[-- Attachment #1: Type: text/plain, Size: 4842 bytes --]


A couple clarifications below on what I meant.
 
On Wednesday, August 31, 2022 4:28pm, "David Lang" <david@lang.hm> said:



> On Wed, 31 Aug 2022, David P. Reed via Starlink wrote:
> 
> > My point is that the discussion here has focused entirely on achievable
> bitrate maximum, with no load and no burstiness.
> 
> well, to be fair, some of that is in response to 'just looking at the bitrate,
> starlink cannot possibly perform well' posts
Who said that? Well a couple of the people who responded to my initial post about beam spread being the wrong way to look at this seemed to decide they wanted to say that.

> 
> > This isn't fixed by having more spatial control, to the extent that is
> > possible.
> 
> agreed, the spactial control discussion is just a response to 'it can't
> possibly...' posts
Actually, the beam spread (the colorful plots and analysis discussing that that Dave Taht highlighted as being important), is all about "spatial control". That was my original point.
 
> 
> > It *is* fixable by suitable Automatic Queue Management in the
> > satellite path (which will be the "bottleneck link" between the home and the
> > public Internet), plus suitable end-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 filter based fair queue dropping).
> 
> if the sats are going to have the ability to route through other satellites,
> they have to be looking at the packets, and once you start doing that, looking
> at ECN should not be a significant load.
 
I agree, but to do good queue management (especially avoiding starvation of some flows) you need to decide what packets on which to set ECN. That means you have to consider the current set of packets in some detail, which requires storing state about some number of IP flows. That's a lot more processing than just looking at a bit. That's what I am referring to here, and I assumed anyone who knows about ECN and AQM and how it works would understand that.
 
I'm not going to reason from "intersatellite" routing being operational until they offer it in operation. It's feasible, sort of. Laser beam aiming is quite different from phased array beam steering, and though they may have tested it between two satellites, that makes it a "link technology" not a network. (you can steer a laser beam by moving lightweight mirrors, I know. But tracking isn't so easy when both satellites are moving relative to each other - it seems like way beyond the technology base that Starlink has put in its satellites so far. But who knows.
--------------
As far as "intersatellite" routing being out there soon, well, there's no evidence it's happening soon. The one thing that may be an indication is that Starlink is claiming it will have achieved extensive maritime coverage in 2023. Since that can't be achieved by placing ground stations over all the oceans involved so that ships can get one "bounce" to some ground station attached to fiber, I'm guessing they may be providing such service by some additional satellite based"backbone" in space.
 
Given the low density of ships, and the fact that ships currently happily tolerate long space delays in the ways they currently offer Internet service far at sea, using "geosynchronous" two way systems positioned in fixed locations over the oceans, it's possible that the Starlink constellation might be using some "backbone" of another structure to get a one hop to groundstation repeater. These wouldn't be LEO, and they might not even be Starlink owned. That's all guesswork on my part.
 
Starlink is very eager to provide coverage at sea because it is a huge marketing win, and probably doable without too much effort. They announced a partnership with Royal Carribean a couple days ago.
 
Satellite "mesh routing" doesn't need to be made to work to provide maritime service away from land. If there's not too much aggregate load.
 
What's interesting to me is that their coverage map definitely doesn't cover Africa, South America, Cuba, large parts of Asia, and it isn't planned - if they had "mesh routing" working among satellites, those would be easy. But instead, they seem to be focused on the satellite one-bounce architecture (what the satellite industry calls "bent-pipe" however it is done).
 
A reason we don't do dynamic mesh routing in the public internet is that backbone concentration works very well as an engineering solution. I suspect that the Starlink guys are taking the lower risk path.

> 
> David Lang_______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
> 

[-- Attachment #2: Type: text/html, Size: 7757 bytes --]

Re: [Starlink] Starlink "beam spread"

[David Lang]

[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]

On Wed, 31 Aug 2022, David P. Reed via Starlink wrote:

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

well, to be fair, some of that is in response to 'just looking at the bitrate, 
starlink cannot possibly perform well' posts

> This isn't fixed by having more spatial control, to the extent that is 
> possible.

agreed, the spactial control discussion is just a response to 'it can't 
possibly...' posts

> It *is* fixable by suitable Automatic Queue Management in the 
> satellite path (which will be the "bottleneck link" between the home and the 
> public Internet), plus suitable end-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 filter based fair queue dropping).

if the sats are going to have the ability to route through other satellites, 
they have to be looking at the packets, and once you start doing that, looking 
at ECN should not be a significant load.

David Lang

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Starlink "beam spread"

[David P. Reed]

[-- Attachment #1: Type: text/plain, Size: 4915 bytes --]


Hi Dick -
glad you joined in the response, given your experience with spatial multiplexing of RF.
 
On Wednesday, August 31, 2022 3:04pm, starlink-request@lists.bufferbloat.net said:



> 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.net>
> Subject: Re: [Starlink] Starlink "beam spread"
> Message-ID: <BCE2EFF2444C470C87D9D4C6D4E6E0A9@SRA6>
> Content-Type: text/plain; charset="iso-8859-1"
> On this particular one, the gateway beams are extremely narrow, around 1.5º
> to 2.5º. SpaceX is working on “mega-gateways” where 32 antennas
> will
> co-exist. They are also deploying a new gateway design with a larger
> antenna, and thus narrower beamwidth and more gain, allowing for a
> considerable reduction in TX power.
> 
> [RR] there is a much better way to do this! I sure hope starlink is
> considering it. Large antennas with 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 electronics level their use of 64 QAM (six bits of signal quantization in amplitude and phase) isn't gonna allow much signalling in multiple directions at once. That's a sampling theory issue, really.
 
There's a lot of handwaving in the discussion here, mostly focused on "beam width" rather than combined channel capacity. To me that's the "sledgehammer" you are referring to.
 
So 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 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 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 bitrate is highly variable, given Internet load.
 
Now RRUL from *one dishy* doesn'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 down links. Then you add a new packet that needs low latency (whether it is ACK packet for TCP or a click from a FPS, or an audio frame in a teleconference, latency matters for all of these, and they aren't predictable in advance). 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 slot time T. Then the delay till slot available can be short, if the slots are short, all dishys get a turn within 2 msec. or less. But if there is a load in 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 Smart TV), then latency due to queueing delay can soar.
 
If 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 capacity to preserve latency for low bitrate traffic.
 
However, high bitrate traffic also has latency requirements. It's not all "background".
 
I'm sure this is something that can be worked out by some algorithm 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 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.
 
My point is that the discussion here has focused entirely on achievable bitrate maximum, with no load and no burstiness.
 
This isn't fixed by having more spatial control, to the extent that is possible. It *is* fixable by suitable Automatic Queue Management in the satellite path (which will be the "bottleneck link" between the home and the public Internet), plus suitable end-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 filter based fair queue dropping).
 
Dave Taht indicates he has some mysterious statistics from (single) dishy experiments. It's a problem that we cannot see into the Starlink black box to understand it fully.
 
But I'm CERTAIN that simplistic analysis about achievable 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.

[-- Attachment #2: Type: text/html, Size: 7749 bytes --]

Re: [Starlink] Starlink "beam spread"

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 524 bytes --]


David Fernández via Starlink wrote:
    > "DNS on Starlink satellites: Good idea, lightweight, and I'd suspect
    > maybe already in operation?"

    > Are the satellites processing IP packets? Are the ISLs even in
    > operation? I have been told Starlink satellites are transparent.

https://www.rfc-editor.org/rfc/rfc8806.html on dishy makes more sense.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide





[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 515 bytes --]

Re: [Starlink] Starlink "beam spread"

[David Fernández]

"DNS on Starlink satellites: Good idea, lightweight, and I'd suspect
maybe already in operation?"

Are the satellites processing IP packets? Are the ISLs even in
operation? I have been told Starlink satellites are transparent.


> Date: Thu, 1 Sep 2022 01:41:07 +1200
> From: Ulrich Speidel <u.speidel@auckland.ac.nz>
> To: David Lang <david@lang.hm>
> Cc: Sebastian Moeller <moeller0@gmx.de>, Ulrich Speidel via Starlink
> 	<starlink@lists.bufferbloat.net>
> Subject: Re: [Starlink] Starlink "beam spread"
> Message-ID: <56e56b0f-07bd-fe0c-9434-2663ae9d4404@auckland.ac.nz>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Um, yes, but I think we're mixing a few things up here (trying to bundle
> responses here, so that's not just to you, David).
>
> In lieu of a reliable Starlink link budget, I'm going by this one:
>
> https://www.linkedin.com/pulse/quick-analysis-starlink-link-budget-potential-emf-david-witkowski/
>
> Parameters here are a little outdated but the critical one is the EIRP
> at the transmitter of up to ~97 dBm. Say we're looking at a 30 GHz Ka
> band signal over a 600 km path, which is more reflective of the current
> constellation. Then Friis propagation gives us a path loss of about 178
> dB, and if we pretend for a moment that Dishy is actually a 60 cm
> diameter parabolic dish, we're looking at around 45 dBi receive antenna
> gain. Probably a little less as Dishy isn't actually a dish.
>
> Then that gives us 97 dBm - 178 dB + 45 dB = -36 dBm at the ground
> receiver. Now I'm assuming here that this is for ALL user downlink beams
> from the satellite combined. What we don't really know is how many
> parallel signals a satellite multiplexes into these, but assuming at the
> moment a receive frontend bandwidth of about 100 MHz, noise power at the
> receiver should be around 38 pW or -74 dBm. That leaves Starlink around
> 38 dB of SNR to play with. Shannon lets us send up to just over 1.25
> Gb/s in that kind of channel, but then again that's just the Shannon
> limit, and in practice, we'll be looking a a wee bit less.
>
> That SNR also gives us an indication as to the signal separation Dishy
> needs to achieve from the beams from another satellite in order for that
> other satellite to re-use the same frequency. Note that this is
> significantly more than just the 3 dB that the 3 dB width of a beam
> gives us. The 3 dB width is what is commonly quoted as "beam width", and
> that's where you get those nice narrow angles. But that's just the width
> at which the beam drops to half its EIRP, not the width at which it can
> no longer interfere. For that, you need the 38 dB width - or thereabouts
> - if you can get it, and this will be significantly more than the 1.2
> degrees or so of 3dB beam width.
>
> But even if you worked with 1.2 degrees at a distance of 600 km and you
> assumed that sort of beam width at the satellite, it still gives you an
>  >12 km radius on the ground within which you cannot reuse the downlink
> frequency from the same satellite. That's orders of magnitude more than
> the re-use spatial separation you can achieve in ground-based cellular
> networks. Note that the 0.1 deg beam "precision" is irrelevant here -
> that just tells me the increments in which they can point the beam, but
> not how wide it is and how intensity falls off with angle, or how bad
> the side lobes are.
>
> Whether you can re-use the same frequency from another satellite to the
> same ground area is a good question. We really don't know the beam
> patterns that we get from the birds and from the Dishys, and without
> these it's difficult to say how much angular separation a ground station
> needs between two satellites using the same frequency in order to
> receive one but not be interfered with by the other. Basically, there
> are just too many variables in this for me to be overly optimistic that
> re-use by two different sources within a Starlink cell is possible. And
> I haven't even looked at the numbers for Ku band here.
>
> CDNs & Co - are NOT just dumb economic optimisations to lower bit miles.
> They actually improve performance, and significantly so. A lower RTT
> between you and a server that you grab data from via TCP allows a much
> faster opening of the congestion window. With initial TCP cwnd's being
> typically 10 packets or around 15 kB of data, having a server within 10
> ms of your client means that you've transferred 15 kB after 5 ms, 45 kB
> after 10 ms, 105 kB after 15 ms, 225 kB after 20 ms, and 465 kB after 25
> ms. Make your RTT 100 ms, and it takes half a second to get to your 465
> kB. Having a CDN server in close topological proximity also generally
> reduces the number of queues between you and the server at which packets
> can die an untimely early death, and generally, by taking load off such
> links, reduces the probability of this happening at a lot of queues.
> Bottom line: Having a CDN keeps your users happier. Also, live streaming
> and video conferencing aside, most video is not multicast or broadcast,
> but unicast.
>
> DNS on Starlink satellites: Good idea, lightweight, and I'd suspect
> maybe already in operation? It's low hanging fruit. CDNs on satellites:
> In the day and age of SSDs, having capacity on the satellite shouldn't
> really be an issue, although robustness may be. But heat in this sort of
> storage gets generated mostly when data is written, so it's a function
> of what percentage of your data that reaches the bird is going to end up
> in cache. Generally, on a LEO satellite that'll have to cache baseball
> videos while over the US, videos in a dozen different languages while
> over Europe, Bollywood clips while over India, cooking shows while over
> Australia and always the same old ads while over New Zealand, all the
> while not getting a lot of cache hits for stuff it put into cache 15
> minutes ago, would probably have to write a lot. Moreover, as you'd be
> reliant on the content you want being on the satellite that you are
> currently talking to, pretty much all satellites in the constellation
> would need to cache all content. In other words: If I watch a cat video
> now and thereby put it into the cache of the bird overhead, and then
> send you an e-mail and you're in my neighbourhood and you watch it half
> an hour later, my satellite would be on the other side of the world, and
> you'd have to have it re-uploaded to the CDN on the bird that's flying
> overhead our neighbourhood then. Not as efficient as a ground-based CDN
> on our ground-based network that's fed via a satellite link.
>
> As long as Starlink is going to have in the order of hundreds of
> thousands of direct users, that problem won't go away.
>
> On 31/08/2022 7:33 pm, David Lang wrote:
>
>> On Wed, 31 Aug 2022, Ulrich Speidel via Starlink wrote:
>>
>>> This combines with the uncomfortable truth that an RF "beam" from a
>>> satellite isn't as selective as a laser beam, so the options for
>>> frequency re-use from orbit aren't anywhere near as good as from a
>>> mobile base station across the road: Any beam pointed at you can be
>>> heard for many miles around and therefore no other user can re-use
>>> that frequency (with the same burst slot etc.).
>>
>> not quite, you are forgetting that the antennas on the ground are also
>> steerable arrays and so they can focus their 'receiving beam' at
>> different satellites. This is less efficient than a transmitting beam
>> as the satellites you aren't 'pointed' at will increase your noise
>> floor, but it does allow the same frequency to be used for multiple
>> satellites into the same area at the same time.
>>
>> David Lang
>>
> --
> ****************************************************************
> Dr. Ulrich Speidel
>
> School of Computer Science
>
> Room 303S.594 (City Campus)
>
> The University of Auckland
> u.speidel@auckland.ac.nz
> http://www.cs.auckland.ac.nz/~ulrich/
> ****************************************************************
>

Re: [Starlink] Starlink "beam spread"

[David Fernández]

f-root dns servers in dishy could be easier than on satellites. Does
it make sense?

For recreational vehicles or home users, quite big caches could be
installed next to the home router, with preloaded versions of the
websites most likely you are going to visit, as per your subscriptions
or indicated preferences, that could be slowly downloaded over night
or while you are working, cooking or doing sport, before you check
them.

>
> Date: Tue, 30 Aug 2022 17:58:52 -0700
> From: Dave Taht <dave.taht@gmail.com>
> To: tom@evslin.com
> Cc: Ulrich Speidel <u.speidel@auckland.ac.nz>,  Dave Taht via Starlink
> 	<starlink@lists.bufferbloat.net>
> Subject: Re: [Starlink] Starlink "beam spread"
> Message-ID:
> 	<CAA93jw60RcjBwGxjwASq75fCdwb8=p0XfFLz4PHoL1w65i7nug@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> I think f-root dns servers in LEO makes a lot of sense. It's not a lot
> of data, nor does it require much cpu. and dns lookups are a frequent
> source of major latency.
>
> CDN in space, well, how much mass, energy, does a set of spindles
> need? Can raid arrays of modern flash or disk survive serious SEVs?
>
>
> ------------------------------
>