From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from APC01-PSA-obe.outbound.protection.outlook.com (mail-psaapc01on2134.outbound.protection.outlook.com [40.107.255.134]) (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 9046A3CB37 for ; Wed, 31 Aug 2022 03:31:29 -0400 (EDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iIK4x6gKEmV2fx46CJc6J2iyQMshMhuPV5C5qDXW8QmPFNVUUySQ6Y6r4zRqDKYJpNheMkyl/X/beO58ZbU4d4te4+nUd6MVsyr7OK+kufAHySsKKv/tOPjfaoG2ZbJO0riofGXMHI5BkwBuYCBG492k0QZe5dLcX8m4ti/DyCewesQ7wRqjD3nDjdvHX3E/jn+8iggU5WtlmW4O+43vSmbceRHlbLu1udewsg57w+QDAltrKZjueDLaKwmwzD5SgZbrtqOqMk1RIabs88sWip+p9w7JePuwswCf8aQ3EEQArZ1VGQTVW0fYiwqLj56Tp76/VMlKzsipKUXp17zAEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NvFaPN7gdXaaLwslrr9N2GvZTWIKVQQK5tDYokZqZfM=; b=P8C3cRssfKS5x99oauJo2ltU9EF5kEDBEVYmIfMmBq9qfydkmdj3skjQlvTOiBiZg6finWC0Y42a+9rHh09YcjDiGXMtqehW3FDsC+mO5qClLGpa+sey2MwW9f6xtteRu/9CHr3ktaJEiqBtoBMPXRBV9NtTZw8LJCFMLYU8vfDiIPasB+eR0kaeC5OF2dmJkYWKcJemptDce8wcsqEqRycaJWQ47RUyUuQ4RJQ2JBJDGTqfWApQpdcnNcLPKLOtHCr1z85v6Y9r0NIMc5Ie1fTi0P/Wxg+IYl5IWpRxrPKxlROK3xvPvySDOyNcYK/7SW8bK4RTJRFfiGVDjx+PZA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 13.70.157.244) smtp.rcpttodomain=auckland.ac.nz smtp.mailfrom=uber.nz; dmarc=pass (p=none sp=none pct=100) action=none header.from=uber.nz; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uber.nz; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NvFaPN7gdXaaLwslrr9N2GvZTWIKVQQK5tDYokZqZfM=; b=iyvivmAIPW8Pm3Ea7swil5KVBFgNn4idzvsjPkYpDq5xylKSlu7Xx8NLva4qWWd3FwvojoCpDfessrfCTF25MPLoU17Q0unCU0K8nybX7/1UJgogXx2y4b+mQ33T96w605oL5MDtt3cVijE3ycMn/sYhztjfgo0bVFKknK3s4MA= Received: from TYCPR01CA0138.jpnprd01.prod.outlook.com (2603:1096:400:2b7::17) by SG2PR03MB4456.apcprd03.prod.outlook.com (2603:1096:4:81::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5588.10; Wed, 31 Aug 2022 07:31:22 +0000 Received: from TYZAPC01FT035.eop-APC01.prod.protection.outlook.com (2603:1096:400:2b7:cafe::51) by TYCPR01CA0138.outlook.office365.com (2603:1096:400:2b7::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5566.15 via Frontend Transport; Wed, 31 Aug 2022 07:31:22 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 13.70.157.244) smtp.mailfrom=uber.nz; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=uber.nz; Received-SPF: Pass (protection.outlook.com: domain of uber.nz designates 13.70.157.244 as permitted sender) receiver=protection.outlook.com; client-ip=13.70.157.244; helo=au2.smtp.exclaimer.net; pr=C Received: from au2.smtp.exclaimer.net (13.70.157.244) by TYZAPC01FT035.mail.protection.outlook.com (10.118.152.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.5588.10 via Frontend Transport; Wed, 31 Aug 2022 07:31:20 +0000 Received: from APC01-SG2-obe.outbound.protection.outlook.com (104.47.26.105) by au2.smtp.exclaimer.net (13.70.157.244) with Exclaimer Signature Manager ESMTP Proxy au2.smtp.exclaimer.net (tlsversion=TLS12, tlscipher=TLS_ECDHE_WITH_AES256_SHA384); Wed, 31 Aug 2022 07:31:21 +0000 X-ExclaimerHostedSignatures-MessageProcessed: true X-ExclaimerProxyLatency: 44047615 X-ExclaimerImprintLatency: 2991050 X-ExclaimerImprintAction: b6f41661296846efa64ad7f0c5edae2b Content-Type: multipart/alternative; boundary="----_=_NextPart_2f37d6d2-ddf8-45c1-bf0b-2abd09bf8ee9" Received: from SG2PR03MB3753.apcprd03.prod.outlook.com (2603:1096:4:4d::19) by TY2PR03MB3807.apcprd03.prod.outlook.com (2603:1096:404:68::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5588.10; Wed, 31 Aug 2022 07:31:13 +0000 Received: from SG2PR03MB3753.apcprd03.prod.outlook.com ([fe80::411e:671d:75a:2298]) by SG2PR03MB3753.apcprd03.prod.outlook.com ([fe80::411e:671d:75a:2298%7]) with mapi id 15.20.5588.010; Wed, 31 Aug 2022 07:31:13 +0000 From: Hayden Simon To: Ulrich Speidel , Sebastian Moeller , Ulrich Speidel via Starlink Thread-Topic: [Starlink] Starlink "beam spread" Thread-Index: AQHYvJEbgXXcYzRrgEO6ejq5bVLnA63IAKLqgAAMEICAAH9JgIAAEHgAgAABMxA= Date: Wed, 31 Aug 2022 07:31:13 +0000 Message-ID: References: <1661878433.14064713@apps.rackspace.com> <6p5n9262-3745-pq31-5636-1rnon987o255@ynat.uz> <20220830220710.GA2653@sunf10.rd.bbc.co.uk> <15982a40-2b34-7ed1-bfa3-bced03fc3839@auckland.ac.nz> <9CE05D69-FC37-4C97-9D8D-D46B2DF6DE16@gmx.de> <2321be3b-957f-2d1f-c335-119c8e76efe5@auckland.ac.nz> In-Reply-To: <2321be3b-957f-2d1f-c335-119c8e76efe5@auckland.ac.nz> Accept-Language: en-NZ, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=uber.nz; X-MS-Office365-Filtering-Correlation-Id: 9c7041af-db69-4105-cfd7-08da8b22cd6b x-ms-traffictypediagnostic: TY2PR03MB3807:EE_|TYZAPC01FT035:EE_|SG2PR03MB4456:EE_ X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: SubiJ3SY6xuSYNqpFH42LtcX2Sy9CR3ZCM32IyNWiVTaamZnv9TKnR4JWRaRFI/0lJ8ecZqZfkU3xEv8B4TG2tOdytK/vBhHARTO6nVjEJaENUIPVYmXaEXAlFKpL+b7HsL/Oo5SJ/DW3oQZ1GCR/W4/KgPYFfdDeKBOcIuMtwtKSm7cPEN+IR/0k6McCfyZpDA+IqdASHN17znmdK4W4PDHgxPyF1pMO1Rbb5jDPi8v6A4D0VBO3fYGzVRiWgVaWwe8Wh4V0B5l1CT9o/+ytcPka211OrShb9CR7XuiyFEiwPWFDrYG+uJL2GgPo1vwIl2/LyVriYXK0/B2dnYZDFsI2ZtuqnjbdxU4l24ILBX9oRCHWDAsj8PKEbl+tngOJlcLDvsVhF5+M/hpxnt6CbJMtxmpCvgr+faTyCV0XWD8OBfNa97anEudYXlMOgBM8C0Pqc/NSFfbpc8gFg4T55YYT1SkDdsPlE4FLWPrUeZHw3DNkv9LvrGoeTS6C3VLGn/o5U/I2SGvziS3ICze7Ejpfr9igfybYN9JKGYG/bzTUbBtqJHKWh6FnfpO315hV57n78GYhPWaQTxIGXditZZN4hM9njg2Wm+QXw0GKrKAXXFe7EZeEgjOt21jSumfqjL6QoHv42klFaBgOlKiLUIow9MAaUzBVHDJfkuQX64o06M5BmchR35YU1gIjCi5F0EpYmUaJsmVSiDZltloTMEhSgIG9C8SDNn4MV9JGNH8pJzoAKV7dtKjPTWuQcdc4JIEE6MCbrMyztKxPI/xqjDvANXda3S1yWsYm9twjWCpMgf1lrB5HZa66295dp4u X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SG2PR03MB3753.apcprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(346002)(366004)(39830400003)(376002)(136003)(396003)(64756008)(66556008)(122000001)(86362001)(55016003)(38070700005)(8936002)(110136005)(66446008)(66946007)(8676002)(41300700001)(966005)(478600001)(52536014)(38100700002)(76116006)(5660300002)(66574015)(186003)(71200400001)(316002)(6506007)(7696005)(83380400001)(53546011)(2906002)(66476007)(33656002)(9686003)(26005)(49092004); DIR:OUT; SFP:1102; MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR03MB3807 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: TYZAPC01FT035.eop-APC01.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 84470f51-260b-47e6-c6bd-08da8b22c849 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Y03tsnkULfF3zblk7IuxPZzR4D+1sID8NJzhLCfMR/dfJ/nOLi6UzFx5S62nKp3pf8jLD7TdKvJpa99hs7s3Ex1DsdoBCCBPwQX0B8sY7N58n7lXuz3xWa/GXWFtBYA5VioOOAwShNk026U89q2dwHrzmr7qRy5r/UpVkHndZRp42d14nDTPSXUrLFFXp00n8Fj1Szetkk9zOkHNKXVEZY5xsqKNs/2G8yfnv19DPfdQOWHat8hgPe3D34YEYzFa8k/aDl+OfT0xJ3PXWBu+EED08uxHlqwNhIdwHqTgNLA/Zvsbxwb9AsAJlVY7K1HuwNfeju9JpyQiKcVyGcKNA0lCK9GO4Ti+lTaYnwGC0iCd0vr1AwvvzhWzDCcIVNFMLRy6SoEEOeBT0iygM/0PlU652wBtG4t009nChOIoVAR/g3dpu8iRifMuljzepLG0Q/tgHSG/3v0XdqVYBqsAa0GrrttPb2+XIrRKZlugeTqkP7xk3/ASVgEpiVSaZfzpqzzD/8sVN9KhezG6dgSw4P5xQRKCkE6ZTZQ1zoRr+DwEpSSBOnIJxSmaqXF9BtGakf4j/T4giMGfu4S8T0frFYrhszAqsSQFkP7+ojiPgbjqC/BCQMHzj7ddeYaLx7Sjfu0A77rPhTdbsWfBCLWFtIQRSHJZoqLBWBQ4OixwN0AHkRDnbkgB0GGT7wrlHlyVje7u7rCBt6xaM5pDs7LWw6+Wz9t4aqLIhaSZqLZRSZ4HHi38OVWTBYBCzuGd3S9tJuTUa0s6B0jhGjGZ5FBMn0FLvSYEBPLUCXMf5UMDAxvqrfUApXUO+tgUM/pg8+HzZ83A44U0pb5JTJzYg8Du8A== X-Forefront-Antispam-Report: CIP:13.70.157.244; CTRY:AU; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:au2.smtp.exclaimer.net; PTR:au2.smtp.exclaimer.net; CAT:NONE; SFS:(13230016)(376002)(346002)(39840400004)(396003)(136003)(46966006)(36840700001)(70206006)(316002)(166002)(70586007)(15974865002)(336012)(8676002)(66574015)(7636003)(47076005)(7596003)(356005)(110136005)(33964004)(966005)(186003)(53546011)(41300700001)(7696005)(9686003)(6506007)(86362001)(82310400005)(26005)(478600001)(33656002)(30864003)(2906002)(40480700001)(36860700001)(5660300002)(83380400001)(52536014)(8936002)(55016003)(49092004)(15398625002); DIR:OUT; SFP:1102; X-OriginatorOrg: uber.nz X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Aug 2022 07:31:20.3361 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9c7041af-db69-4105-cfd7-08da8b22cd6b X-MS-Exchange-CrossTenant-Id: befadeaa-58d7-4003-bc5e-56f2d93f85ed X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=befadeaa-58d7-4003-bc5e-56f2d93f85ed; Ip=[13.70.157.244]; Helo=[au2.smtp.exclaimer.net] X-MS-Exchange-CrossTenant-AuthSource: TYZAPC01FT035.eop-APC01.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2PR03MB4456 Subject: Re: [Starlink] Starlink "beam spread" X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2022 07:31:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_2f37d6d2-ddf8-45c1-bf0b-2abd09bf8ee9 Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Throwing it out here that I love this group. I *really* enjoy that you all = understand the challenges, limitations and potential points for optimisatio= n so well. It=E2=80=99s 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 On Behalf Of Ulrich= Speidel via Starlink Sent: Wednesday, 31 August 2022 7:25 pm To: Sebastian Moeller ; Ulrich Speidel via Starlink 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 > 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.=C2=A0 But anythin= g > 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 differe= nt from your average Internet user anywhere else in that they like to watch= Netflix, YouTube, TikTok etc., then having a simple "transport layer and b= elow" 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 servic= e provider or however they like to refer to themselves these days) has an o= utage, the media will report - incorrectly of course - that "the Internet is down". So it's not just something that's optional a= nymore, and hasn't been for a while. It's an integral part of the landscape= =2E 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. Ad= d 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 re= latively 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 n= etwork, 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 cac= he on the local end that multiple users get their copies from. There is jus= t no way around this. As such, the comparison of Starlink to GSM/LTE/5G bas= e stations just doesn't work here. So throw in the "edge" as in "edge" computing. In a direct-to-site satellit= e 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 dow= nlink 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 "b= eam" from a satellite isn't as selective as a laser beam, so the options fo= r 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 man= y 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 r= edundant transmissions overall by almost half, but this doesn't help much b= ecause you really need to cut that need by orders of magnitude. Moreover, t= here's another problem: Power. Running CDN servers is a power hungry busine= ss, as anyone running cloud data centres at scale will be happy to attest t= o (in Singapore, the drain on the power network from data centres got so ba= d that they banned new ones for a while). Unfortunately, power is the one t= hing a LEO satellite that's built to achieve minimum weight is going to hav= e 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 t= o 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 ------_=_NextPart_2f37d6d2-ddf8-45c1-bf0b-2abd09bf8ee9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Throwing it out here that I love this group. = I *really* enjoy that you all understand the challenges, limitations and po= tential points for optimisation so well.

It=E2=80=99s a signific= ant shift from my daily grind.

= <= td align=3D"left" style=3D"vertical-align:top;">
HAYDEN​ SIMON
UBER GROUP LIMITED
SUPREME OVERLORD
MANAGING DIRECTOR =E2=80=91 
3D""3D""<= /a>
E: h@uber.nz
=
=
M: 021 0707 014
W: www.uber.nz
53 PORT ROAD | PO&nb= sp;BOX 5083 | WHANGAREI | NEW ZEALAND
    
-= ----Original Message-----
From: Starlink <starlink-bounces@lists.bu= fferbloat.net> On Behalf Of Ulrich Speidel via Starlink
Sent: Wedne= sday, 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 3= 1/08/2022 6:26 pm, Sebastian Moeller wrote:
> Hi Ulrich,
><= br />> On 31 August 2022 00:50:35 CEST, Ulrich Speidel via Starlink
> <starlink@lists.bufferbloat.net> wrote:
> >There= 9;s another aspect here that is often overlooked when looking
> pur= ely 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 th= at
> it's the core of the Internet that presents a bottleneck,= and that the
> aggregate bandwidth of all last mile connections i= s high in
> comparison. A second assumption is that a large share = of the content
> that gets requested gets requested many times, an= d many times by users
> in the same corner(s) of the Internet. The= conclusion is that
> therefore content is best served from a loca= tion close to the end
> user, so as to keep RTTs low and - importa= ntly - 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 e= nd 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, I= MHO, Starlink's biggest design flaw at the moment: Going
> dire= ct 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 tho= usand
> 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 w= hen they do so. Caching
> content closer to the users or multicast= tricks are basically
> optimizations that (occasionally) help dec= rease costs/increase margins
> for the operator, but IMHO they are= exactly that, optimizations. So if
> they can not be used, no har= m is done. Since caching is not perfect,
> such optimisations real= ly are no way to safely increase the
> oversubscription rate eithe= r. Mind you I am not saying such measures
> are useless, but in IA= S I consider them to be optional. Ideas about
> caching in space s= eem 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
> capa= city was smaller then the aggregate satellite to end user capacity
&g= t; (both per satellite), no?

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

The= problem is that - Zoom meetings aside - the vast majority of data that ent= ers 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 servi= ce 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 combinatio= n of high cell density, the ensuing ability to communicate with lower power= , which enables spatial separation and hence frequency reuse. Add beam form= ing and a few other nice techniques, and you're fine. Same with WiFi, e= ssentially. So as data emerges from a CDN server (remember, most of this is= on demand unicast and not broadcasting), it'll initially go into relat= ively 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 netw= ork, and none of these present a bottleneck at any one point.

Th= is 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 th= e end users, then every copy of your cat video (again, assuming on-demand h= ere) 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 &qu= ot;edge" as in "edge" computing. In a direct-to-site satelli= te network, the edgiest bit of the edge is the satellite itself.
If w= e 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 downlin= k 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 fr= equency (with the same burst slot etc.).

So by putting a cache o= n the server, you've reduced the need for multiple redundant transmissi= ons overall by almost half, but this doesn't help much because you real= ly need to cut that need by orders of magnitude. Moreover, there's anot= her problem: Power. Running CDN servers is a power hungry business, as anyo= ne running cloud data centres at scale will be happy to attest to (in Singa= pore, 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 st= ill needs to come down 1000 times if 1000 users want to watch it.

--

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

School of Computer Science
<= br />Room 303S.594 (City Campus)

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

=

_______________________________________________
Starlink m= ailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbl= oat.net/listinfo/starlink
------_=_NextPart_2f37d6d2-ddf8-45c1-bf0b-2abd09bf8ee9--