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.21.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 0A6DD3B2A4 for ; Wed, 31 Aug 2022 09:41:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auckland.ac.nz; s=mimecast20200506; t=1661953271; 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=s3084Fq5KQhBqMwVn2YdU4X3eR02FLKCjm4QSgYp5LA=; b=ipOZFJaMZnr4qj6CZrrWwVTU6KJYO25nAx88AJtRgaazJfp8imCHVW0ZaBcuTZPTG5JZMf ayspA8zSsMmZun4sxUSsYq+evNF5bN6gkubqh+53qT8pVcjqkZCJTQefmzit8K+A2CyvVy 14tWakacD/9kRbliszUCzdUxM11gQUE= 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-45-D2MNWFeqOO-vF7pE08weDg-1; Wed, 31 Aug 2022 23:41:10 +1000 X-MC-Unique: D2MNWFeqOO-vF7pE08weDg-1 Received: from SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) by SY6PR01MB7810.ausprd01.prod.outlook.com (2603:10c6:10:175::23) 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 13:41:08 +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 13:41:08 +0000 Message-ID: <56e56b0f-07bd-fe0c-9434-2663ae9d4404@auckland.ac.nz> Date: Thu, 1 Sep 2022 01:41:07 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 To: David Lang Cc: 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> <2321be3b-957f-2d1f-c335-119c8e76efe5@auckland.ac.nz> <8978587-42op-q175-2o41-qq9p4491459s@ynat.uz> From: Ulrich Speidel In-Reply-To: <8978587-42op-q175-2o41-qq9p4491459s@ynat.uz> X-ClientProxiedBy: SY6PR01CA0087.ausprd01.prod.outlook.com (2603:10c6:10:110::20) 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: dbf326bd-313e-4e52-2eaf-08da8b5675d3 X-MS-TrafficTypeDiagnostic: SY6PR01MB7810:EE_ X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0 X-Microsoft-Antispam-Message-Info: Sj5IJgZIs9HyBNvBYIyniGQ0kt6gbbP9XI2GnW55Nc1VP1RFfxPpzFI9KW1/P6hICXB8CEt/+mCm/thvaAuSNMXT/Qmql2yyTi/DVzL5QJUClu+K8FH+PvhS3h+t5ylYvIG8zJ1tqOPiDqGHIJMMT//timuFYR3JrhK9GtNxaQFWk6o/kR1PJeFyiDH9HXf0p6iOD/WE+AUje3ZS6a2WjYXEbvmNGRuFRAMQZSDuUVnLtBJdJQFF2rHi6W9YcET0kpwkcq2sSGleZLT2qfFadD+eCU67LbeYZkD6Ok/DOy4IHLKL13acfx34/GMeGZdbOlJFeT5dKNH66/BQcmBtNHACV7cfroMNxAUIr6aca59YQipp1N+kliV8zVJnH6cn6oXaLHQorvREH6FZxohH9t/wcQHv+WiKG0mC8epYtomMtslGGhPvl0+W9HikPX2oxupnPRFgp+RKUNnU4vKKB24tmth4r9cl3deXzKTuZnZiFcl7Fn8RXciKT1iQa2lhDnje4d1hZNnKifs9ZJk6cRyQgoGXG5hwsyYElKNW94wmv7/DEQKRy6uEVKYIjTRm2pgW6HcPcop8VCS6HFGmd2m/LDpw4RvgJYNVWh6HZ+JpRK/8lmiFL0wFCsaapdaYiKbTKKvJG7dfBPrwntfAPGgCQuvx5c83lJC6p1upWVefMNfnKRauUYgPVxyl9J+G4lg3A0F9WuPFIlEe9Heqk52147G2hAK9doysSffKhtq1jutISgfl+DSnThBs4l9j5pcsKoU8QyEaLVE9eZJxAsalW7apPZQOkt2AHZvEVdyRlGry6TVAYaRmbqf09ivKV1JSLpRVgZTir0xjpdrUqgb5wrKv0Y2egSO5bJPREaK3df9XRS7uzALXnWzrLC/T/8Fn2lb+cMqigUzTfkbQmQ== 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)(346002)(376002)(39860400002)(366004)(45080400002)(786003)(316002)(54906003)(6916009)(6486002)(966005)(31686004)(478600001)(36756003)(38100700002)(31696002)(86362001)(41300700001)(5660300002)(8936002)(6506007)(2906002)(53546011)(83380400001)(6512007)(8676002)(4326008)(66476007)(66946007)(66556008)(2616005)(186003)(513134003)(45980500001)(43740500002); DIR:OUT; SFP:1101 X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?R3g3QmxZVFFDSCtIMXNoTVJyNTN2TUN4ek4vSWJJdjNXQlBuNU1HZEhXM1hw?= =?utf-8?B?YktVRWJMV3RwNW5HSnl5cUYyL0xENHlEUGduNzd5WjZqMDBGaThOU0RiQ1hm?= =?utf-8?B?K1lRNXNISzRRQW1ndzNIV0U4RGwxTGRkbFUxUVg2aGZveEIyUEFSaXRIL3Qy?= =?utf-8?B?UjRCalBaeE5sbzAwVVFMYmJlcUMvVW1xV2dYVDk5aGlETzA3NnY3czl6cktw?= =?utf-8?B?dkVNaUxjejZGcGZucThaelMvNks1bEJYajJlVGdYZU83dzVyZlJidk14eEFW?= =?utf-8?B?VU1rQWx6a3BJOUpGeVFDMnpabkVtWW1rWXdJZkQ5OUJUNytDOXQxMFZnVk1i?= =?utf-8?B?NzlKKzBNQVJXdW9BYmFNK0IvUXpNK05OTFpVekpyWi9pNFc0T1VHNW84ZExI?= =?utf-8?B?K3N0aHA4azRyT0xWeHEvbTNFWjBoR1h0c3haNk9CZmtQekdlMmFzVWNwR2dH?= =?utf-8?B?b3pTMDdQaGhpdlpDWjhmQi9XMFUrYk5wbkpsaUdJZGltY2hYdkVWYTBQcmpz?= =?utf-8?B?TEpid1UrUWlNTVE5aWtnNVc4eU4zSlFCTXpvZU1EM0ExTGtUVTBkR1hhdjhC?= =?utf-8?B?RFI3Qm51QzQ5bTNoYjQrUkEwQzVxSHlkOFNTK05nNjBqSk15VGJmRHN5d2Jo?= =?utf-8?B?MW9MTnJJcWhna2hodHptb1oxUElGWU82NzRiTk5zQXlrM2RCZFdqZHRPcCs1?= =?utf-8?B?eUpUbE4wU0REN2FiUEF5aCt4bzdrYk5SU2tvN25TUzZEUWNxT0JMQnlwZ1NZ?= =?utf-8?B?SWhPNHNST01VSlN3Y3lxWVB6VmdsVDVzNVJxbklPTjhibWNwTlVHa2hScjhI?= =?utf-8?B?U3RHMEZpSENjUzV0bkk4d1R2U24wVW4vWnhWcThKQnlOczcyRXFKanVzemNs?= =?utf-8?B?Y1dtc3RFT2NuZUEybzh2ajM2SzlVMWZkQjU2Q2UzSzJ5RHZHdGMzZTRjczEv?= =?utf-8?B?MnZESTFtMHdNUlJkZGdNQXF0cWJaaG5RT29DOVlZaUpuVFhNd0FyZ1Y4UmMr?= =?utf-8?B?YThWNmp2YXVXa2Z2OThhTmxnak9SRlhwUUdJWnVOamRaUmptcXpzQkFlR1pm?= =?utf-8?B?V2hZR2E4TFpIajE2ZEc4c3VXZUpmR0xYbmFYM21zb2E5ZHdwMzZ0UXZZZGJF?= =?utf-8?B?UGhmTzl5bDBFQzFWbnFDTjgvbE5qVDJ0K1BaV2l3cFRhZUxTR3RpR1BqSXZl?= =?utf-8?B?L1ppOVZsaktzQml3d0tZRldFMms1K010ODZ6MnNHVVU5bUgwSTltZVNQTVNX?= =?utf-8?B?VTBHcFk0RGdyNHBodjZmVU9lTWp3TkhoZlhqVkp5dDVqZ2o0TG5JeGozWGRn?= =?utf-8?B?elRiS254NTZIQjh1Nkw2Q1FvNFNuS2lWTkRDU1gvQUNEUldMalo3WFJTNzNw?= =?utf-8?B?S0NNOGl4RkpWNGozZTQ0N0tZK2N6ZElFMGFySnVoMmIveUhERE81cDJveFZw?= =?utf-8?B?NHBaR1d3WlIzRTA2cHN6TlU2cHRvRlRJSW5RV1dodXpmVFBJWDZoZVN4SFFB?= =?utf-8?B?WDR2ZUx0emNJMVpsMThIWS9lVUN5bFQzRkZhK284MlhoWWhyanNxa3lyekpB?= =?utf-8?B?c3I4OEt4aERRTGptYVowOVpFZWgwTDQzRkJLTFhMOTBZdFVsZVFMNzJKOXRi?= =?utf-8?B?SW9aU0lpQnJlcGM0Wi9uRzZtU3ViQmxVNTNJTDFzUmxER2N5bHJGNEJtbkN1?= =?utf-8?B?NHBpZis5bFROdWt2V3A0SjQ0a0M0S0VRdjBTL3VpN3VSSGpPeUQvWlI0cXdR?= =?utf-8?B?aGFhSmtQdWc1dTlCeEtlejlIZDEvRFZWS2VzNDFXK0FJalFaSU1oajJKVUhZ?= =?utf-8?B?TWdNbmpJR3VHTWJLVWozN2VSL2ZMNlZNakpMdlNXL3ArdXFIUmNoODliRko5?= =?utf-8?B?TkRyR20xMEZiR3dxRXpOOUNtL1BwRklIR0JSZ1JjeXlidjZwcEZzWWwzY1E1?= =?utf-8?B?Y2JUSFpyNjZ0ZkdBN1FDMEcyd1M1d3FlV0JaRHBlSXZuMnF1cmN1WURzWWx3?= =?utf-8?B?S01DU3JlcXRMbElaZmJycHpFQWQzc3QyU0gvTEtQaWlvNHRPTVJ2NmhubTFj?= =?utf-8?B?Ti81bXdKM1dsd2d2L29sQXRmMUZvMkdnTHVDWHJpTGE0MWlwc3FGTm5PWURq?= =?utf-8?B?MDg2MC9qZEdBN0ZBVVhydHFYQy94R3pCSmpNSTVxY1BjYUU4QlNrbWVIRWJH?= =?utf-8?B?cyt6ZVRacWg2am5JSHRibU9HckpzVmdwUnh4akQyWElLTnA5bWpQNXMrdDVI?= =?utf-8?B?dURqNEF1MmRISGpUTDlFTEVMbkNRPT0=?= X-OriginatorOrg: auckland.ac.nz X-MS-Exchange-CrossTenant-Network-Message-Id: dbf326bd-313e-4e52-2eaf-08da8b5675d3 X-MS-Exchange-CrossTenant-AuthSource: SY4PR01MB6979.ausprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Aug 2022 13:41:08.7975 (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: 17xzFLmihtP72XrFJxWbuKZn6EkSTnXRbNT60Y2FB/C8BMrUlQHxJtAWQo4+aXDApY4vsimzz7kmJfAf4ryXTDY3dpseF7L3EPUEw6PvQfc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SY6PR01MB7810 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 13:41:14 -0000 Um, yes, but I think we're mixing a few things up here (trying to bundle=20 responses here, so that's not just to you, David). In lieu of a reliable Starlink link budget, I'm going by this one: https://www.linkedin.com/pulse/quick-analysis-starlink-link-budget-potentia= l-emf-david-witkowski/ Parameters here are a little outdated but the critical one is the EIRP=20 at the transmitter of up to ~97 dBm. Say we're looking at a 30 GHz Ka=20 band signal over a 600 km path, which is more reflective of the current=20 constellation. Then Friis propagation gives us a path loss of about 178=20 dB, and if we pretend for a moment that Dishy is actually a 60 cm=20 diameter parabolic dish, we're looking at around 45 dBi receive antenna=20 gain. Probably a little less as Dishy isn't actually a dish. Then that gives us 97 dBm - 178 dB + 45 dB =3D -36 dBm at the ground=20 receiver. Now I'm assuming here that this is for ALL user downlink beams=20 from the satellite combined. What we don't really know is how many=20 parallel signals a satellite multiplexes into these, but assuming at the=20 moment a receive frontend bandwidth of about 100 MHz, noise power at the=20 receiver should be around 38 pW or -74 dBm. That leaves Starlink around=20 38 dB of SNR to play with. Shannon lets us send up to just over 1.25=20 Gb/s in that kind of channel, but then again that's just the Shannon=20 limit, and in practice, we'll be looking a a wee bit less. That SNR also gives us an indication as to the signal separation Dishy=20 needs to achieve from the beams from another satellite in order for that=20 other satellite to re-use the same frequency. Note that this is=20 significantly more than just the 3 dB that the 3 dB width of a beam=20 gives us. The 3 dB width is what is commonly quoted as "beam width", and=20 that's where you get those nice narrow angles. But that's just the width=20 at which the beam drops to half its EIRP, not the width at which it can=20 no longer interfere. For that, you need the 38 dB width - or thereabouts=20 - if you can get it, and this will be significantly more than the 1.2=20 degrees or so of 3dB beam width. But even if you worked with 1.2 degrees at a distance of 600 km and you=20 assumed that sort of beam width at the satellite, it still gives you an=20 >12 km radius on the ground within which you cannot reuse the downlink=20 frequency from the same satellite. That's orders of magnitude more than=20 the re-use spatial separation you can achieve in ground-based cellular=20 networks. Note that the 0.1 deg beam "precision" is irrelevant here -=20 that just tells me the increments in which they can point the beam, but=20 not how wide it is and how intensity falls off with angle, or how bad=20 the side lobes are. Whether you can re-use the same frequency from another satellite to the=20 same ground area is a good question. We really don't know the beam=20 patterns that we get from the birds and from the Dishys, and without=20 these it's difficult to say how much angular separation a ground station=20 needs between two satellites using the same frequency in order to=20 receive one but not be interfered with by the other. Basically, there=20 are just too many variables in this for me to be overly optimistic that=20 re-use by two different sources within a Starlink cell is possible. And=20 I haven't even looked at the numbers for Ku band here. CDNs & Co - are NOT just dumb economic optimisations to lower bit miles.=20 They actually improve performance, and significantly so. A lower RTT=20 between you and a server that you grab data from via TCP allows a much=20 faster opening of the congestion window. With initial TCP cwnd's being=20 typically 10 packets or around 15 kB of data, having a server within 10=20 ms of your client means that you've transferred 15 kB after 5 ms, 45 kB=20 after 10 ms, 105 kB after 15 ms, 225 kB after 20 ms, and 465 kB after 25=20 ms. Make your RTT 100 ms, and it takes half a second to get to your 465=20 kB. Having a CDN server in close topological proximity also generally=20 reduces the number of queues between you and the server at which packets=20 can die an untimely early death, and generally, by taking load off such=20 links, reduces the probability of this happening at a lot of queues.=20 Bottom line: Having a CDN keeps your users happier. Also, live streaming=20 and video conferencing aside, most video is not multicast or broadcast,=20 but unicast. DNS on Starlink satellites: Good idea, lightweight, and I'd suspect=20 maybe already in operation? It's low hanging fruit. CDNs on satellites:=20 In the day and age of SSDs, having capacity on the satellite shouldn't=20 really be an issue, although robustness may be. But heat in this sort of=20 storage gets generated mostly when data is written, so it's a function=20 of what percentage of your data that reaches the bird is going to end up=20 in cache. Generally, on a LEO satellite that'll have to cache baseball=20 videos while over the US, videos in a dozen different languages while=20 over Europe, Bollywood clips while over India, cooking shows while over=20 Australia and always the same old ads while over New Zealand, all the=20 while not getting a lot of cache hits for stuff it put into cache 15=20 minutes ago, would probably have to write a lot. Moreover, as you'd be=20 reliant on the content you want being on the satellite that you are=20 currently talking to, pretty much all satellites in the constellation=20 would need to cache all content. In other words: If I watch a cat video=20 now and thereby put it into the cache of the bird overhead, and then=20 send you an e-mail and you're in my neighbourhood and you watch it half=20 an hour later, my satellite would be on the other side of the world, and=20 you'd have to have it re-uploaded to the CDN on the bird that's flying=20 overhead our neighbourhood then. Not as efficient as a ground-based CDN=20 on our ground-based network that's fed via a satellite link. As long as Starlink is going to have in the order of hundreds of=20 thousands of direct users, that problem won't go away. On 31/08/2022 7:33 pm, David Lang wrote: > On Wed, 31 Aug 2022, Ulrich Speidel via Starlink wrote: > >> This combines with the uncomfortable truth that an RF "beam" from a=20 >> satellite isn't as selective as a laser beam, so the options for=20 >> frequency re-use from orbit aren't anywhere near as good as from a=20 >> mobile base station across the road: Any beam pointed at you can be=20 >> heard for many miles around and therefore no other user can re-use=20 >> that frequency (with the same burst slot etc.). > > not quite, you are forgetting that the antennas on the ground are also=20 > steerable arrays and so they can focus their 'receiving beam' at=20 > different satellites. This is less efficient than a transmitting beam=20 > as the satellites you aren't 'pointed' at will increase your noise=20 > floor, but it does allow the same frequency to be used for multiple=20 > satellites into the same area at the same time. > > David Lang > --=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/ ****************************************************************