From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from au-smtp-delivery-117.mimecast.com (au-smtp-delivery-117.mimecast.com [103.96.23.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 547D33B2A4 for ; Mon, 26 Feb 2024 21:33:17 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auckland.ac.nz; s=mimecast20200506; t=1709001194; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=OgqL7i8rz3dPl1s/y38afTc56sp2QEUaV2dQLNVOVRE=; b=fnWjKx48PjUUY+YR2ktLJA6StrhBvIdlbxcTn5kRTdpd0jINK9d420Jk4HaD4txEyoP7DE tyAFMlhSv4oec0FS3YRH4zYAgiQZYVhGbkV0GpSUNvVHWCaw1utBctSqxw6VsmKVCFeJMr DqwIWuBR/VpPKIr04YFv7nen46xgUqQ= Received: from AUS01-SY4-obe.outbound.protection.outlook.com (mail-sy4aus01lp2168.outbound.protection.outlook.com [104.47.71.168]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id au-mta-64-nFPS7kRNMiuWmGvmX1IkrQ-1; Tue, 27 Feb 2024 13:33:11 +1100 X-MC-Unique: nFPS7kRNMiuWmGvmX1IkrQ-1 Received: from SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) by ME3PR01MB7544.ausprd01.prod.outlook.com (2603:10c6:220:135::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7316.36; Tue, 27 Feb 2024 02:33:09 +0000 Received: from SY4PR01MB6979.ausprd01.prod.outlook.com ([fe80::2faf:5dbf:9124:8a6f]) by SY4PR01MB6979.ausprd01.prod.outlook.com ([fe80::2faf:5dbf:9124:8a6f%5]) with mapi id 15.20.7316.035; Tue, 27 Feb 2024 02:33:09 +0000 Message-ID: <7c39f363-e988-410d-b284-bfda6163d089@auckland.ac.nz> Date: Tue, 27 Feb 2024 15:33:07 +1300 User-Agent: Mozilla Thunderbird To: David Lang CC: starlink@lists.bufferbloat.net References: <28ro46p9-5620-9qr2-829q-3s0on13q6po6@ynat.uz> <857a228c-cf02-4a2c-98cb-771f71f070d0@auckland.ac.nz> <851pqo7s-pq89-pnp6-o999-o0721n3s19r8@ynat.uz> From: Ulrich Speidel In-Reply-To: <851pqo7s-pq89-pnp6-o999-o0721n3s19r8@ynat.uz> X-ClientProxiedBy: SY5PR01CA0085.ausprd01.prod.outlook.com (2603:10c6:10:1f5::12) To SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SY4PR01MB6979:EE_|ME3PR01MB7544:EE_ X-MS-Office365-Filtering-Correlation-Id: a6590b57-e85a-42f4-0109-08dc373c6f96 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0 X-Microsoft-Antispam-Message-Info: 6nUEvSl/FIw9iKDLJ0v/DA8x4/URt/tfP5bPAKX5cbxyGBFV2nDCCeAQHzLP7/ZCZiR8LakCzh8cDs6znY9hXmv95WJc8HWHaNW+qAiHIatAAvBh8VX14qBnjeb4wRiShnoLWr+UoJToLL8KmAVdKn3ladT7qcbI6a2XnRbU9p7iCvoVJDCZPwgHAYbiDgP90VVENOyi1C+Q08dsbhYTazt/+TNgLIfovIO3ERx+6+DBGMPX2RXDRAOSDB1+8/jWeaLSjn9KCjjcAVu017hgiyN2D1e9sJu41bahzXuUJRCLZFJ4bm/aFBr/ic1BgR++D3aCkQngxLu2Irlbk9J2bcvC+YWVKIpW8vBms5hkBqwoWTBZDMrWdjApcw/Wt7TgD+PuWYfL5SBT/dXC1q+SOsHzZ5ba0R75jv31vxAdRRJ17yxcdgzYg71eRtGv0JpBRhAqcfy3hG6dILRvYS54cRG0zNOgUR2bCkybBcWTQnDjVjn+b8wqzUmHapwSEWUnF1Cp6pafiVsnWHkv8GIuitlcyr/ybeDWTZDnZBLpewMv2d0H7gdGRVQY3yLNBLtyNuXc3WI38B6JsoQkWQdFzsNBhEUtDgXlOt3JJvjq4Ij48e165w+7j/PR0Js+PncG X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SY4PR01MB6979.ausprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031); DIR:OUT; SFP:1102 X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?P36vVQcSQWiWSYD71vgZ//5367vdh7YyA8yQQnxucvrU1tHkFssn/DxPaTDZ?= =?us-ascii?Q?m5pQAZ/ycqnUMVV86o6aghIY3mBL8bXajInVjp3KaiAbCx6aXzp2NBFcC1RP?= =?us-ascii?Q?xqn3EULWTmMJZSfq2RkPZl1MTPqKYshk2l/4QnAW8prRgjrACTk2VdA4F7MU?= =?us-ascii?Q?ZTqYr8ozJHRqiAF6HTV1EVIdL3KJed+qHtKzHhxlXPwh8OdOSKPYHQjGKZnz?= =?us-ascii?Q?X6RpvH1vMQ8m1yowiuhUofeOk+YA3JkepfAsi5afZ/jXFlm6IQRLmJB6ZMN/?= =?us-ascii?Q?VmZ9fMKHjNFkrHHg2RaQ2hKIoo3tRU11cl3WVguWICy4nfKXfso2Vsl4dYJp?= =?us-ascii?Q?v5gymZjKV9k01oClpLDrQ4sevwEiPhDCyshYGwoJT3/XZHoC51TDYW0yqyfg?= =?us-ascii?Q?exxYEswN/XlX6LWIPsTNTnCv3cDXA9RuL+z3Xv9FwqeQL1QkHpydoiydvTmy?= =?us-ascii?Q?M1xQi1b/aiBRFnhPV/ftRkVDZRSsru0oU3hdJYkoCdrtG4G/+nP+2p63m+K1?= =?us-ascii?Q?pP/kW9a4E5yiFuIv+BJfy7GJvt/TMqGbOOal6775XyQ5WnEs+8kmdlp15fCm?= =?us-ascii?Q?hQozQjptJn54xUU+SJW8EIdnySgODQnaA1iGIztCDh9eAE4DmrlpRvbUkvNc?= =?us-ascii?Q?zdnHuNRPmgKpTWMiSODslgfpyAKBixxRmzCa+RPLP7ufVsyqFdqpW02V76n7?= =?us-ascii?Q?EUPtGuuxl0Ws1yO9WUQQqLYBmAu+Jyha/VTv6hgc2qFZu9uk+QGH2ngEbt03?= =?us-ascii?Q?CEtcvHzXlb4FbF/4fE9qL3Eq5fBJlWe8J7IYs71TcFHTIhjOy457bgjYPwWb?= =?us-ascii?Q?ESqAAN1DVSgXLeoxmx6dePKxaE0XHiWfjaVYJqLm8He0bYOWZF8JcWnzpt7D?= =?us-ascii?Q?p5DalJjohNaV3r3s/Sb+H6GKXVhGb4hMamkTmzqQTOS2LYUvtja0+jkfiNzu?= =?us-ascii?Q?HLcRvqW9Z7kUFA11GzL+jLWejn0fxQBTzsNC8JolIx5v4KBI6kYvWCt+m9Ya?= =?us-ascii?Q?fQ3iJRXblxPB4u19PRDr4MyNvOBCFBmH2m28PTu2RFW+k4weLaDH7F0YK+3C?= =?us-ascii?Q?dYilEXG+BovEOu2ZxDUYknkPGBLLu8zKsqQ132ypU5Fi9nQjNLx81kwpU2GX?= =?us-ascii?Q?tKDjrWKmoyeosO6u3WWW/zyaNzpUy04Hpw0LyMthlhDoPc9ADdxVQtkFkk4t?= =?us-ascii?Q?WOGZ9F6bbcVSimmqAfBjnGcC9hTguPu8ivH000ZOBqxTUuBjYaGP+t0bkj6n?= =?us-ascii?Q?dxuZm3D6nRs3+FNJ7gyd5m9RM85maoV7lWMwEn+8RXadAZJxzlqEnYsAT5Hl?= =?us-ascii?Q?6RXkIvM8b2/jbOvKWTW8YqBdZChZoH3pSJH8JnSM4QOr2rtppxfRK/3E7IcO?= =?us-ascii?Q?aRQpfP5FYWh5T/zbKVa5COS1MrcqehRDfH1COkV2BHPoJkjfMBkUSg+wLG6W?= =?us-ascii?Q?9akye0VyxjSyRdxLiVCQvG4yJseFKbu/cFzQYTppPbBiMSz209Az2AIUHJNt?= =?us-ascii?Q?n0PpU7yjuHWCdxmJZIN3aE+5AHk8BxiMuV5tASS36EOJS8I/ZWSmG1ZIlfbg?= =?us-ascii?Q?C0Fp15urgSRvTwFtjOy0YI126LV+2ztsONxjiAkSFOlR0AehRjqdy3PYa/UY?= =?us-ascii?Q?HeH0Hlpsb0yAIAX4OEZDPjz0sxRM7A0Un5RLLX1Ze187QiY7IOTusqOLigp2?= =?us-ascii?Q?dYoDag=3D=3D?= X-OriginatorOrg: auckland.ac.nz X-MS-Exchange-CrossTenant-Network-Message-Id: a6590b57-e85a-42f4-0109-08dc373c6f96 X-MS-Exchange-CrossTenant-AuthSource: SY4PR01MB6979.ausprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Feb 2024 02:33:09.0389 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: d1b36e95-0d50-42e9-958f-b63fa906beaa X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: dugCxdRjvMGY179dR/RsVPmsWdD7bSWWmFfU/TSydh+n0fg0nzclsy9e6HUlobXbiey8eH/Vqixft+ayU9+wJVXEgBjQPGO3bh8yrkKPBuA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: ME3PR01MB7544 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: auckland.ac.nz Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Starlink] Comprehensive Measurement Study on Starlink Performance Published X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2024 02:33:17 -0000 All good points ... see below. On 27/02/2024 2:13 pm, David Lang wrote: > On Tue, 27 Feb 2024, Ulrich Speidel wrote: > >> On 27/02/2024 12:19 pm, David Lang wrote: >>> On Tue, 27 Feb 2024, Ulrich Speidel via Starlink wrote: > >>> There are large areas with poor or non-existant cell coverage. >>> >>> Outside the US, scaling of Starlink can happen just by providing=20 >>> coverage to locations that don't yet have coverage with no=20 >>> additional satellites. >> But what's the population of these areas? Generally quite sparse. (Or=20 >> politically disinclined to accept Starlink service) > > per square mile? low. But there are a LOT of square miles, and those=20 > areas are ones where it's very expensive per-user to run fiber (even=20 > to cell towers or wireless ISP towers) The point though is that these sparsely populated areas aren't where the=20 scalability issue arises. Capacity needs to be where the demand for it is. > > There are governments politically disinclined to allow cell service,=20 > not so much the users. And some of the opposition is not opposition to=20 > Internet service, but rather being protective of existing providers.=20 > Protectionism can be defeated in time. Tick. > >>> In terms of scaling existing areas, larger antennas can reduce cell=20 >>> size, you can have more than one satellite cover a given cell, they=20 >>> are looking at eventually having lower satellites, which again will=20 >>> let them reduce the cell size. >> >> Lower orbit =3D more drag =3D shorter lifetime, and the reduction in=20 >> footprint isn't actually that significant. Larger antennas =3D fewer=20 >> sats per launch =3D more expensive system. > > and at the same time SpaceX is working to massivly reduce the launch=20 > costs. Yep, but much of the gains there have been made. > > >> If you put in fibre today, you know that by upgrading the endpoints=20 >> over time, you can get orders of magnitude of extra bandwidth if needed. > > If you can get fibre, you should get fibre (with starlink as a=20 > possible backup). SpaceX has said many times that Starlink is never=20 > going to be competitive to fibre > > if you can get fibre, you aren't under-connected. Tick. But 2 billion plus can't, or at least not yet. The question is how=20 many of them might Starlink & Co be able to assist in due course? > >> If you can reduce distance between satellite and ground station by a=20 >> factor of 2, all else being equal, theoretically you'd also reduce=20 >> footprint to a quarter, but that's assuming you don't need to worry=20 >> about antenna sidelobes. But say we can, and then that gives us a=20 >> factor of 4 in terms of capacity as long as our user density is the=20 >> same. It also buys us an extra 6 dB in received signal power and=20 >> hence an extra 2 bits per symbol. That's another factor of 4 at best=20 >> if you go from 1 to 3 bits/symbol. Larger antennas: Doubling antenna=20 >> size gives you 3 dB in gain or an extra bit per symbol. So that turns=20 >> into a game of diminishing margins pretty quickly, too. > > add in the ability for multiple satellites to serve a single cell and=20 > you can get a noticable multiple as well Not in terms of capacity - but in terms of a better distribution of it.=20 Already happening - most places can now "see" dozens of Starlink=20 satellites above the horizon. > > >> =C2=A0But now you want to serve cellphones on the ground which have=20 >> smaller antennas by a factor of I'd say about 16:1 aperture-wise. So=20 >> you need to make your antennas in space 16 times larger just to=20 >> maintain what you had with Dishy. > > the cell service is not intended to compete with the Dishy, just be an=20 > emergancy contact capability Here's how one of the local partner organisation here spins it. Much=20 more than just an emergency contact capability: https://one.nz/why-choose-us/spacex/ (Judge for yourself whether this instils the impression that you're=20 going to get 5G level service off this. You really need to read the=20 small print!) > >> That's a far cry from what is needed to get from two million or so=20 >> customers to supply two billion unconnected or under-connected. For=20 >> that, we need a factor of 1000. > > without knowing what the user density of those under-connected are,=20 > it's going to be really hard to get concrete arguments. > > Spacex is intending to launch ~10x as many satellites as they have=20 > now, and the full 'v2' satellites are supposed to be 10x the bandwidth=20 > of the V1s (don't know how they compare to the v2 minis), that's a=20 > factor of 100x there.=20 It's not that easy. Adding satellites in the first instance is just=20 adding transmitters, and unless you have spectrum to accommodate these,=20 then even if the satellites' on-board bandwidth is higher, it doesn't=20 translate into as much extra capacity. Spectrum comes in terms of extra=20 Hertz, and in terms of spatial beam separation. The former is limited in=20 that they don't make any more of it, and the latter is a matter of=20 antenna size and getting antenna side lobes sufficiently far down. And=20 we know that SpaceX are running close to spectral capacity in some areas. Assuming that the spatial distribution of the under-connected is=20 somewhat similar to Starlink's current customer base in terms of=20 densities, we need that factor of 1000. > Is another 10x in the under-served areas being in less dense areas=20 > really that hard to believe? > > And Starlink will hopefully not be the only service, so it shouldn't=20 > have to serve everyone. So which factor in terms of capacity growth should we expect of Starlink=20 & Co over today? > >> And then you need to provision some to compete with extra capacity=20 >> you wanted, and then some to cope with general growth in demand per=20 >> client. And then you have to transmit that same viral cat video over=20 >> and over again through the same pipe, too. > > True, although if you can setup a community gateway of some sort to=20 > share one satellite connection, you gain efficiency (less housekeeping=20 > overhead or unused upload timeslots), and have a place that you can=20 > implement caches. Indeed. Or if you provide a feed to a local ISP. But Starlink still=20 focuses on direct to site, as does every other LEO provider FAIK. --=20 **************************************************************** 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/ ****************************************************************