[Starlink] Starlink Digest, Vol 12, Issue 6

[Dick Roy]

-----Original Message-----
From: Starlink [mailto:starlink-bounces at lists.bufferbloat.net] On Behalf Of
Ulrich Speidel
Sent: Friday, March 4, 2022 4:14 PM
To: David Lang
Cc: starlink at lists.bufferbloat.net
Subject: Re: [Starlink] Starlink Digest, Vol 12, Issue 6

 

True, but Starlink is designed as a high bandwidth, low latency (OK, we 

won't mention their bufferbloat issues again here), and (currently) low 

user density service.

 

Bandwidth-wise, good old Shannon and Hartley are agnostic about whether 

you divide your channel between 1 or a million users. 

[RR] But they are assuming a "single" channel in the time domain.  When you
can take advantage of other dimensions (eg. space) to create more channels,
(aka SDMA) the capacity goes up!

But in real 

communication systems that need to manage handovers and joining and 

departing customers, there is a certain amount of overhead involved in 

managing these, and the protocols used for this generally have a 

significant footprint in them that reflects the kind of situation their 

designer had in mind. E.g., since GSM, burst frames have been designed 

to reflect the designer's expectation as to how many end users a base 

station would service. I'd be very surprised if this was any different 

for Starlink.

[RR] When you have more dimensions to work with/in (aka SDMA), the problems
you note get easier to solve!  Just watch the early 60's TV episode of
Maverick about the farmers and the poker game and you will see how it can be
done! WARNING: it's in black and white so don't try to adjust your viewing
screen/TV set :^))))

 

Remember, Starlink's launch and initial target market was the American 

rural and underserved suburban populace. Pretty much all of them already 

had a low bandwidth service, it was high bandwidth service they needed. 

So I'd expect Starlink to be designed around a rather constrained number 

of Dishy clients per satellite.

 

And yes I think it'd be a good idea to use mesh networks etc. in order 

to distribute Starlink resource to more people there. But I guess that 

this is already happening with other types of connectivity over there, too.

 

On 5/03/2022 7:14 am, David Lang wrote:

> On Fri, 4 Mar 2022, Ulrich Speidel wrote:

> 

>> In terms of Starlink - I really think that it's a red herring, at 

>> least for now. As I said, if Starlink can't muster anywhere near 

>> enough satellite capacity to serve all of a small town in Montana 

>> that's surrounded by gateways close by, then it's not going to be 

>> replacing the Internet as we know it in a country 60% larger in area 

>> and 40 x larger in population. At best it might be able to provide 

>> some backup in a relatively small number of places.

> 

> It depends on what you set as your requirements. If you are talking 

> about everyone streaming video, you are correct, but if you talk about 

> less bandwidth intensive uses, a little bandwidth goes a long ways.

> 

> There's also FAR more of a difference between nothing and low 

> bandwidth than between low and high bandwidth.

> 

> Telephone audio is an 64Mb stream, without compression, email and text 

> chat are very low bandwidth.

> 

> 20 years ago, you could have an office of 100 employees living on a 

> 1.5Mb Internet connection and have people very happy. A single dishy 

> is 100x this.

> 

> I agree that Starlink is not a full replacement for hard-wired 

> Internet, and it never will be. But the ability to get that much 

> bandwidth into an area that doesn't have wired Internet wihtout 

> requiring special crews to come in and set up the infrastructure (like 

> you would for geostationary dishes) is a huge step forward for 

> disaster relief.

> 

> With capabilities like this now available, we (the tech community) 

> need to look at options to be able to extend this connectivity from a 

> point source across a wider area (ways to do mesh and have it not 

> collapse, understanding channnel allocations, sane directional antenna 

> uses, etc) including how to provide power.

> 

> And also take a careful look at the bandwith that apps are using and 

> find ones that are sane to use. Since (almost) everyone has phones as 

> endpoints now, having the ability to put a voip app on the phones and 

> have them able to call and text chat freely within the connectivity 

> bubble without any need to use the external bandwith, but be able to 

> connect out in a fairly transparent manner (think how long distance 

> calls were something significant 40-50 years ago, but were still using 

> the same equipment and basic process). Can such apps indicate to the 

> user if they are talking to someone really local (say sharing the same 

> wifi), or more remote, so that they can

> 

> How can such apps be made available to the people with phones? (Apple 

> makes it really hard to side-load apps for example), How can the 

> services get bundled (raspverry pi or live CD linux images that 

> provide these services and the app images to download for example). 

> What can be done with OpenWRT builds to make turnkey conversions of 

> APs into bandwidth-efficient mesh nodes. This includes how a bit of 

> wire can go a long way towards making a wifi system work better.

> 

> How can we bundle lessons for techies on the ground to teach them what 

> to do (and what not to do) in setting these things up?

> 

> David Lang

> 

-- 

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

Dr. Ulrich Speidel

 

School of Computer Science

 

Room 303S.594 (City Campus)

 

The University of Auckland

u.speidel at auckland.ac.nz

http://www.cs.auckland.ac.nz/~ulrich/

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

 

 

 

_______________________________________________

Starlink mailing list

Starlink at lists.bufferbloat.net

https://lists.bufferbloat.net/listinfo/starlink

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20220304/e3c7ebd3/attachment-0001.html>