<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<span style="margin:0px; font-size:12pt; background-color:rgb(255,255,255)"><span style="margin:0px; background-color:rgb(255,255,255); display:inline!important"><span style="margin:0px; font-size:14px; background-color:rgb(255,255,255); display:inline!important">>
But that's exactly the situation that would make it a party to the conflict and its user a target.</span><br>
</span></span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<div style="margin:0px; font-size:12pt; background-color:rgb(255,255,255)"><br>
</div>
<div style="margin:0px; font-size:12pt; background-color:rgb(255,255,255)">How many terminals do you think they have and who -- which class of person -- do you think has them?<br>
</div>
<div style="margin:0px; font-size:12pt; background-color:rgb(255,255,255)"><br>
</div>
<div style="margin:0px; font-size:12pt; background-color:rgb(255,255,255)">I understand the users would be targets, but it will be difficult to locate terminals in the hands of a few people who are able to move around<span> </span><span style="margin:0px; background-color:rgb(255,255,255); display:inline!important">a
233,000 square mile country. Furthermore, the terminals will not be transmitting continuously, and they can be a distance from the people using them. </span></div>
<div style="margin:0px; font-size:12pt; background-color:rgb(255,255,255)"><span style="margin:0px; background-color:rgb(255,255,255); display:inline!important"><br>
</span></div>
<span style="margin:0px; font-size:12pt; background-color:rgb(255,255,255)"><span style="margin:0px; background-color:rgb(255,255,255); display:inline!important">The benefits of being able to communicate seem to outweigh the risk of detection and destruction.
Furthermore, finding and destroying a terminal would cost Russia a lot and the Ukrainians would still have n-1 terminals.</span></span><br>
</div>
<div id="appendonsend"></div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Starlink <starlink-bounces@lists.bufferbloat.net> on behalf of Ulrich Speidel <u.speidel@auckland.ac.nz><br>
<b>Sent:</b> Friday, March 4, 2022 4:14 PM<br>
<b>To:</b> David Lang <david@lang.hm><br>
<b>Cc:</b> starlink@lists.bufferbloat.net <starlink@lists.bufferbloat.net><br>
<b>Subject:</b> Re: [Starlink] Starlink Digest, Vol 12, Issue 6</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="PlainText">True, but Starlink is designed as a high bandwidth, low latency (OK, we
<br>
won't mention their bufferbloat issues again here), and (currently) low <br>
user density service.<br>
<br>
Bandwidth-wise, good old Shannon and Hartley are agnostic about whether <br>
you divide your channel between 1 or a million users. But in real <br>
communication systems that need to manage handovers and joining and <br>
departing customers, there is a certain amount of overhead involved in <br>
managing these, and the protocols used for this generally have a <br>
significant footprint in them that reflects the kind of situation their <br>
designer had in mind. E.g., since GSM, burst frames have been designed <br>
to reflect the designer's expectation as to how many end users a base <br>
station would service. I'd be very surprised if this was any different <br>
for Starlink.<br>
<br>
Remember, Starlink's launch and initial target market was the American <br>
rural and underserved suburban populace. Pretty much all of them already <br>
had a low bandwidth service, it was high bandwidth service they needed. <br>
So I'd expect Starlink to be designed around a rather constrained number <br>
of Dishy clients per satellite.<br>
<br>
And yes I think it'd be a good idea to use mesh networks etc. in order <br>
to distribute Starlink resource to more people there. But I guess that <br>
this is already happening with other types of connectivity over there, too.<br>
<br>
On 5/03/2022 7:14 am, David Lang wrote:<br>
> On Fri, 4 Mar 2022, Ulrich Speidel wrote:<br>
><br>
>> In terms of Starlink - I really think that it's a red herring, at <br>
>> least for now. As I said, if Starlink can't muster anywhere near <br>
>> enough satellite capacity to serve all of a small town in Montana <br>
>> that's surrounded by gateways close by, then it's not going to be <br>
>> replacing the Internet as we know it in a country 60% larger in area <br>
>> and 40 x larger in population. At best it might be able to provide <br>
>> some backup in a relatively small number of places.<br>
><br>
> It depends on what you set as your requirements. If you are talking <br>
> about everyone streaming video, you are correct, but if you talk about <br>
> less bandwidth intensive uses, a little bandwidth goes a long ways.<br>
><br>
> There's also FAR more of a difference between nothing and low <br>
> bandwidth than between low and high bandwidth.<br>
><br>
> Telephone audio is an 64Mb stream, without compression, email and text <br>
> chat are very low bandwidth.<br>
><br>
> 20 years ago, you could have an office of 100 employees living on a <br>
> 1.5Mb Internet connection and have people very happy. A single dishy <br>
> is 100x this.<br>
><br>
> I agree that Starlink is not a full replacement for hard-wired <br>
> Internet, and it never will be. But the ability to get that much <br>
> bandwidth into an area that doesn't have wired Internet wihtout <br>
> requiring special crews to come in and set up the infrastructure (like <br>
> you would for geostationary dishes) is a huge step forward for <br>
> disaster relief.<br>
><br>
> With capabilities like this now available, we (the tech community) <br>
> need to look at options to be able to extend this connectivity from a <br>
> point source across a wider area (ways to do mesh and have it not <br>
> collapse, understanding channnel allocations, sane directional antenna <br>
> uses, etc) including how to provide power.<br>
><br>
> And also take a careful look at the bandwith that apps are using and <br>
> find ones that are sane to use. Since (almost) everyone has phones as <br>
> endpoints now, having the ability to put a voip app on the phones and <br>
> have them able to call and text chat freely within the connectivity <br>
> bubble without any need to use the external bandwith, but be able to <br>
> connect out in a fairly transparent manner (think how long distance <br>
> calls were something significant 40-50 years ago, but were still using <br>
> the same equipment and basic process). Can such apps indicate to the <br>
> user if they are talking to someone really local (say sharing the same <br>
> wifi), or more remote, so that they can<br>
><br>
> How can such apps be made available to the people with phones? (Apple <br>
> makes it really hard to side-load apps for example), How can the <br>
> services get bundled (raspverry pi or live CD linux images that <br>
> provide these services and the app images to download for example). <br>
> What can be done with OpenWRT builds to make turnkey conversions of <br>
> APs into bandwidth-efficient mesh nodes. This includes how a bit of <br>
> wire can go a long way towards making a wifi system work better.<br>
><br>
> How can we bundle lessons for techies on the ground to teach them what <br>
> to do (and what not to do) in setting these things up?<br>
><br>
> David Lang<br>
><br>
-- <br>
****************************************************************<br>
Dr. Ulrich Speidel<br>
<br>
School of Computer Science<br>
<br>
Room 303S.594 (City Campus)<br>
<br>
The University of Auckland<br>
u.speidel@auckland.ac.nz<br>
<a href="https://urldefense.com/v3/__http://www.cs.auckland.ac.nz/*ulrich/__;fg!!P7nkOOY!phUrdzfjr6YUdNCfv4tjZFz3zZe-9hdDlsCjcSc6gmEZDF7mfjlgKK1uZU2tMQmBrxlEaRbKLFMR0TZ1A7RFMULV$">https://urldefense.com/v3/__http://www.cs.auckland.ac.nz/*ulrich/__;fg!!P7nkOOY!phUrdzfjr6YUdNCfv4tjZFz3zZe-9hdDlsCjcSc6gmEZDF7mfjlgKK1uZU2tMQmBrxlEaRbKLFMR0TZ1A7RFMULV$</a>
<br>
****************************************************************<br>
<br>
<br>
<br>
_______________________________________________<br>
Starlink mailing list<br>
Starlink@lists.bufferbloat.net<br>
<a href="https://urldefense.com/v3/__https://lists.bufferbloat.net/listinfo/starlink__;!!P7nkOOY!phUrdzfjr6YUdNCfv4tjZFz3zZe-9hdDlsCjcSc6gmEZDF7mfjlgKK1uZU2tMQmBrxlEaRbKLFMR0TZ1A-oFbS8W$">https://urldefense.com/v3/__https://lists.bufferbloat.net/listinfo/starlink__;!!P7nkOOY!phUrdzfjr6YUdNCfv4tjZFz3zZe-9hdDlsCjcSc6gmEZDF7mfjlgKK1uZU2tMQmBrxlEaRbKLFMR0TZ1A-oFbS8W$</a>
<br>
</div>
</span></font></div>
</body>
</html>