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 083873CB37 for ; Wed, 31 Aug 2022 03:25:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auckland.ac.nz; s=mimecast20200506; t=1661930710; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=cFgIsqFTvhV70nV9FETE80zZPwVBqFOzJ9WGP1UHvQ4=; b=C49G6MnmF90yEzN76pEOWYgWhwr0tezlvL6PZvPW85CGyAzJ2iN1G/lXu7DRpPh9XAxcp9 Qwsecu5lP2gxMTf9S5AV+gaDxa2Vo09lHZhvWOE3nt62MvxdVpaWgYtqmJNWHlQU8yorn8 1z73rc3TB14CFN6Z0zmf+IInscymQEo= Received: from AUS01-SY4-obe.outbound.protection.outlook.com (mail-sy4aus01lp2176.outbound.protection.outlook.com [104.47.71.176]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id au-mta-84-TTp8aY_RNGGu34vlbTRtMQ-1; Wed, 31 Aug 2022 17:25:08 +1000 X-MC-Unique: TTp8aY_RNGGu34vlbTRtMQ-1 Received: from SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) by SYBPR01MB4060.ausprd01.prod.outlook.com (2603:10c6:10:26::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5566.15; Wed, 31 Aug 2022 07:25:07 +0000 Received: from SY4PR01MB6979.ausprd01.prod.outlook.com ([fe80::5599:3984:44a0:fa3d]) by SY4PR01MB6979.ausprd01.prod.outlook.com ([fe80::5599:3984:44a0:fa3d%3]) with mapi id 15.20.5566.021; Wed, 31 Aug 2022 07:25:07 +0000 Message-ID: <2321be3b-957f-2d1f-c335-119c8e76efe5@auckland.ac.nz> Date: Wed, 31 Aug 2022 19:25:06 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 To: Sebastian Moeller , Ulrich Speidel via Starlink 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> From: Ulrich Speidel In-Reply-To: <9CE05D69-FC37-4C97-9D8D-D46B2DF6DE16@gmx.de> X-ClientProxiedBy: SY6PR01CA0144.ausprd01.prod.outlook.com (2603:10c6:10:1b9::23) To SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9fd209ff-6135-4e7f-b07c-08da8b21ee2c X-MS-TrafficTypeDiagnostic: SYBPR01MB4060:EE_ X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0 X-Microsoft-Antispam-Message-Info: HiIGSYiy9qiyinIBHhUYcSMLHfLgk6FbSRPDK3WzIGQQl/1oBRv3Sg2w0xVqzjsa6Y09zzyRdXOLrc+mZCvCcnlJT0vCqh4GYV1+bgX5QHc/3RjK/fnvWqAKR+y+m/daxuKrVDvBt5xr4h4XhFm3IYoMMFENQL8X5yVydWDAt/yDWxOcYW7lBtdZ8MhlCWQdOocKfoXPS1UecrQc+0b+lxuM3EhNNbKERqS9PR8fyUKN5nwGPNdupv/XAVTfNO0+6ffj86sVL68CWvaceXuFqKYiU7maUeqgNirRZrYDv1s+1X45zfJLdVd3c8IZAy/EdyNpqaYosJQjcArzDLeVrjkkVrWJJ5kmQuV++c5HcXQlQJBZxPMUCiHQ3Sp9DAAcO9dWM/l5SpaOlO52rG/J36lNUut/0D1ZOYPymi9IBQe3S0Jn5NxUdoW29BduGfljrUO80fmnkqLelqsZgLWrj60Mvn7DK/voNs7rYrh1fRe0TxGmkn2dcVYUTsqrJOSA4A/TsAhZSNRFiacFK5gysJSgySrgsDIt0GGzZKtGmj/vUZWwMsLy8FvCLTDyyx1PohjO3BnyIugR2l/ZEmrl7O3IMV+fPU/0ov/SvCZ73dScuPXtDPhrWtyRTCeNG/dAp/+eN6CmtDaRShfZd1yjGN/2KJYkOd69jPE3hsECfb4t6ONLIyZ27HnTNBl4I+z6F2uQ7rNP6EdvzLlMoey0EKHwRf+/hdAz2U3WpF9a3LuPbChOi2nG7Zo8eCwr6joFOPFchRM1iFDnNF2/SiJ/xs1k8bNB6kwfXpEFZW7Cy+l9KXLHuIF8jhXnK0pQH00sJH5O2RXeDJkA0hI2eZtRuQ== 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:(13230016)(4636009)(396003)(136003)(39860400002)(346002)(366004)(376002)(66574015)(186003)(2616005)(66946007)(83380400001)(2906002)(110136005)(316002)(786003)(8676002)(66476007)(66556008)(5660300002)(478600001)(53546011)(6512007)(966005)(6486002)(6506007)(8936002)(41300700001)(36756003)(31686004)(38100700002)(86362001)(31696002)(43740500002)(45980500001); DIR:OUT; SFP:1101 X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?6r21D1YRsWhwQvxLHGfH93OjD29Zgrdptp0IoGAD/oQCGtf4kA45mhJqh6oW?= =?us-ascii?Q?Mls6s2WjA9GvNMn8JRcrZ5dmJpdzZmDiadYM0gl5nmU4jZqrNe7r/mCTLaiE?= =?us-ascii?Q?Hbz6lbdIak0f5LE73s1fTWPIORfWfdhqcfEr0KUb5UjWOtuvVvuu8w+aCz6t?= =?us-ascii?Q?R2PAqVmAxXXyz7OGnK0vqkRYYWEKq+6zbwXb+7AEhRdZ17XaFnNOSECZuv/a?= =?us-ascii?Q?g2tmplVSJpKgq9aVap874pppgrselT/1RqbMRb4UyfL8XTIuj4r1mYH2ab0N?= =?us-ascii?Q?pDnUsxRrQRIGTnl6+mzVDUCUwaLRRuO6RyF3EOQZKzGyG6JITvOTOfOR3vI/?= =?us-ascii?Q?M3NcHDVXZIc78IN7rqkglVJrAoDbWldsXojU5XmCdatemYqXqmHMGqyM7EO/?= =?us-ascii?Q?fNSy+J8hKuG+8glTdvqP2U+qi/G1TXXMU/UkWz+AuuONlt5ruRURBfEVQS3E?= =?us-ascii?Q?xoZlt9wnmQiglgyltl854u6fGuRUUFVGwvSfTad0qz+VuJiJ0dsxrpIyKmfY?= =?us-ascii?Q?hqBWDmdyqa4aOyuafu8xIzmQ201i4fpcgc0EWtsi/huddmZhf8Km2fUB3w8C?= =?us-ascii?Q?8K8zNE+FbUMCLWJgC/BXxKGiM6p1T/35KrMJ19jWrYrVOiZ4R4JxwrghZSxt?= =?us-ascii?Q?lopKArM1xrv0BsYQ25KYfABohn9KpJJe5mcXuxdLeEnkyOJyTy9oF1opAx6O?= =?us-ascii?Q?tJILAWM1Wheux9wYijhczcWvTThVza1/z57I+FlkiV+TSg1ALNHnqldFrFHy?= =?us-ascii?Q?cKu0TnM3WdjRa4ah+UPzBMRygH60/NJe+7F7URj3Ws55QdTiNqFzpL83auOd?= =?us-ascii?Q?A3N0YgqlwR4Qfh74inIVQvmOCCn/+XhYL9HbdQDBgPnNPvVwAU1vNjV9LLjR?= =?us-ascii?Q?/bJAEhFArx7uCxyGD+vpRmUZSDxybVHHu0Z9vdS/xHAgOzmrBLzQIA2E8Aat?= =?us-ascii?Q?KJIkyiDUyajpzgSHg4XjYs2R0TrmfTtNJOW+XB1Ua08zDZsWeGMIt0pSmXb5?= =?us-ascii?Q?TvckYbiCCK62H/yXrZGQgHifL8XWtbyuoMs+GvAYh+k0vXk8JukiodbrKVOw?= =?us-ascii?Q?W8JtLJziLdpAGH2/L+SwHmKLO5d82bOK4YuWlU9xDAAhXGPAtIw9uTNrVpYt?= =?us-ascii?Q?4iAboXP2KxieWoGFn3nVHgjI4ADh2I2/W/CDav4rO8T9/so6fmiiVp5LG7Or?= =?us-ascii?Q?lKsUd2fKcoN/K0LUJ4hBoe872fxniRwsmNOxYs1U/zUJgwlrtoeY52sDz6ko?= =?us-ascii?Q?bpVErcjLQnfI4tSuNd3NKoVjYiuRY6IRxKVwsz7vcW7Ci4CFjKrRftukf7jl?= =?us-ascii?Q?P1X/MYlvl4GtvsxnpdIePBkfK6onKQQ6EMEs6DGYqmCYofqwWqreZItrw79C?= =?us-ascii?Q?QMeLSCSCnmEMpIXdEX7YsJ+cDc/sKR/Sp6HfVmH7zG81OynRkHTRcq1mWo76?= =?us-ascii?Q?w8neoyHKa3aVgLfw3pF3WIDQevVCzvrVqJhk0/HZKvl/mUNfSOL4pGYS15xy?= =?us-ascii?Q?O4GvUGlqOk3ieKQfUaHc4tRnNp6r7g4O5C+4cKg/cWITYglfuTkwAisNk3yz?= =?us-ascii?Q?4fh+Thfs2Rr/CYA+NzbocNr5H+Izzw/2/Kvj5SdxW8Bha4W93OXjcMR3IRvj?= =?us-ascii?Q?5XPI0aWXUEoqNYpPm3bKWzvhS6sb6owz7cGrY6oqkYg+o8/jhurNXSshxGm9?= =?us-ascii?Q?wcZvtA=3D=3D?= X-OriginatorOrg: auckland.ac.nz X-MS-Exchange-CrossTenant-Network-Message-Id: 9fd209ff-6135-4e7f-b07c-08da8b21ee2c X-MS-Exchange-CrossTenant-AuthSource: SY4PR01MB6979.ausprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Aug 2022 07:25:07.3840 (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: VHHy0GjTmJQ09uoKZPwXHw+ryVik1y81RLVNjfuzfWOzmMyqkNwY6WR6SFBINRZ6k6Z/IadAV6jGS5Tixysii3vi/NAETwKvEaUxqjrw0PQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SYBPR01MB4060 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] 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:25:13 -0000 On 31/08/2022 6:26 pm, Sebastian Moeller wrote: > Hi Ulrich, > > On 31 August 2022 00:50:35 CEST, Ulrich Speidel via Starlink=20 > wrote: > >There's another aspect here that is often overlooked when looking=20 > purely at the data rate that you can get from your=20 > fibre/cable/wifi/satellite, and this is where the data comes from. > > > >A large percentage of Internet content these days comes from content=20 > delivery networks (CDNs). These innately work on the assumption that=20 > it's the core of the Internet that presents a bottleneck, and that the=20 > aggregate bandwidth of all last mile connections is high in=20 > comparison. A second assumption is that a large share of the content=20 > that gets requested gets requested many times, and many times by users=20 > in the same corner(s) of the Internet. The conclusion is that=20 > therefore content is best served from a location close to the end=20 > user, so as to keep RTTs low and - importantly - keep the load of long=20 > distance bottleneck links. > > > >Now it's fairly clear that large numbers of fibres to end users make=20 > for the best kind of network between CDN and end user. Local WiFi=20 > hotspots with limited range allow frequency re-use, as do ground based=20 > cellular networks, so they're OK, too, in that respect.=C2=A0 But anythin= g=20 > that needs to project RF energy over a longer distance to get directly=20 > to the end user hasn't got nature on its side. > > > >This is, IMHO, Starlink's biggest design flaw at the moment: Going=20 > direct to end user site rather providing a bridge to a local ISP may=20 > be circumventing the lack of last mile infrastructure in the US, but=20 > it also makes incredibly inefficient use of spectrum and satellite=20 > resource. If every viral cat video that a thousand Starlink users in=20 > Iowa are just dying to see literally has to go to space a thousand=20 > times and back again rather than once, you arguably have a problem. > > Why? Internet access service is predominantly a service to transport=20 > any packets the users send and request when they do so. Caching=20 > content closer to the users or multicast tricks are basically=20 > optimizations that (occasionally) help decrease costs/increase margins=20 > for the operator, but IMHO they are exactly that, optimizations. So if=20 > they can not be used, no harm is done. Since caching is not perfect,=20 > such optimisations really are no way to safely increase the=20 > oversubscription rate either. Mind you I am not saying such measures=20 > are useless, but in IAS I consider them to be optional. Ideas about=20 > caching in space seem a bit pie-in-the-sky (pun intended) since at 4ms=20 > delay this would only help if operating CDNs in space would be cheaper=20 > than on earth at the base station or if the ground to satellite=20 > capacity was smaller then the aggregate satellite to end user capacity=20 > (both per satellite), no? Now, assuming for a moment that your typical Starlink user isn't so=20 different from your average Internet user anywhere else in that they=20 like to watch Netflix, YouTube, TikTok etc., then having a simple=20 "transport layer and below" view of a system that's providing=20 connectivity simply isn't enough. The problem is that - Zoom meetings aside - the vast majority of data=20 that enters an end user device these days comes from a CDN server=20 somewhere. It's quietly gotten so pervasive that if a major CDN provider=20 (or cloud service provider or however they like to refer to themselves=20 these days) has an outage, the media will report - incorrectly of course=20 - that "the Internet is down". So it's not just something that's=20 optional anymore, and hasn't been for a while. It's an integral part of=20 the landscape. Access strata folk please take note! This isn't a (huge) problem on classical mobile networks with base=20 stations because of the amount of frequency division multiplexing you=20 can do with a combination of high cell density, the ensuing ability to=20 communicate with lower power, which enables spatial separation and hence=20 frequency reuse. Add beam forming and a few other nice techniques, and=20 you're fine. Same with WiFi, essentially. So as data emerges from a CDN=20 server (remember, most of this is on demand unicast and not=20 broadcasting), it'll initially go into relatively local fibre backbones=20 (no bottleneck) and then either onto a fibre to the home, a DSL line, a=20 WiFi system, or a terrestrial mobile 4G/5G/6G network, and none of these=20 present a bottleneck at any one point. This is different with satellites, including LEO and Starlink. If your=20 CDN or origin server sits at the remote end of the satellite link as=20 seen from the end users, then every copy of your cat video (again,=20 assuming on-demand here) must transit the link each time it's requested,=20 unless there's a cache on the local end that multiple users get their=20 copies from. There is just no way around this. As such, the comparison=20 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=20 satellite network, the edgiest bit of the edge is the satellite itself.=20 If we put a CDN server (cache if you wish) there, then yes we have saved=20 us the repeated use of the link on the uplink side. But we still have=20 the downlink to contend with where the video will have to be transmitted=20 for each user who wants it. This combines with the uncomfortable truth=20 that an RF "beam" from a satellite isn't as selective as a laser beam,=20 so the options for frequency re-use from orbit aren't anywhere near as=20 good as from a mobile base station across the road: Any beam pointed at=20 you can be heard for many miles around and therefore no other user can=20 re-use that frequency (with the same burst slot etc.). So by putting a cache on the server, you've reduced the need for=20 multiple redundant transmissions overall by almost half, but this=20 doesn't help much because you really need to cut that need by orders of=20 magnitude. Moreover, there's another problem: Power. Running CDN servers=20 is a power hungry business, as anyone running cloud data centres at=20 scale will be happy to attest to (in Singapore, the drain on the power=20 network from data centres got so bad that they banned new ones for a=20 while). Unfortunately, power is the one thing a LEO satellite that's=20 built to achieve minimum weight is going to have least of. ICN essentially suffers from the same problem when it comes to Starlink=20 - if the information (cat video) you want is on the bird and it's=20 unicast to you over an encrypted connection, then the video still needs=20 to come down 1000 times if 1000 users want to watch it. --=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/ ****************************************************************