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 D3DE43B2A4 for ; Wed, 31 Aug 2022 17:46:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auckland.ac.nz; s=mimecast20200506; t=1661982384; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=V5FfZjxzcYefFmUPlwa+Qqrw4t2VpMluZI3Nk/kGQsI=; b=CI3s2H8yWFOlqTOdfDod4MwpyWYz+u2+wI2XPFjxVIZOA3H7N0R9IgB0MOAGohbPye1Cgk cFgj4Ib/zP1biRJDhssyO3jiiztAIcjdzVVGa0f0nqu6++vZpiyRMIuV4EpeSvHq45tDDP +aQ6yyIBEB2fW+6b8Wat39AbRwOeAm4= Received: from AUS01-SY4-obe.outbound.protection.outlook.com (mail-sy4aus01lp2173.outbound.protection.outlook.com [104.47.71.173]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id au-mta-10-BX8hEi2lNeq8PuoirLT7jg-1; Thu, 01 Sep 2022 07:46:23 +1000 X-MC-Unique: BX8hEi2lNeq8PuoirLT7jg-1 Received: from SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) by ME3PR01MB8226.ausprd01.prod.outlook.com (2603:10c6:220:1b6::8) 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 21:46:21 +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.5588.010; Wed, 31 Aug 2022 21:46:21 +0000 Message-ID: <7a357510-2d61-dd4a-a59f-3d7d4bd3727c@auckland.ac.nz> Date: Thu, 1 Sep 2022 09:46:20 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 To: starlink@lists.bufferbloat.net References: From: Ulrich Speidel In-Reply-To: X-ClientProxiedBy: SY6PR01CA0040.ausprd01.prod.outlook.com (2603:10c6:10:e9::9) 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: 10480d45-b529-4a71-99e8-08da8b9a3e63 X-MS-TrafficTypeDiagnostic: ME3PR01MB8226:EE_ X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0 X-Microsoft-Antispam-Message-Info: yrqYE+bzZPtfRHFGb+WilxvvIcE8kiyXQ4ReXqTYw1NwVSfbZy5tiQOj8EGYjd09S/p4Su6mhMFyXKdhfXd/9V93n4qLZrsVAjVl5TOTX7MUT7iTcZ1YtmgfiEjr7gzY7ritcGo+zbVgUFjOpxl2CSeNbJ3gOiOLeTbkVM1Q7ubo5QAT3AuhUMsIDeJElp/xqTjn8zDf6Uhra/i0Zh0rbm3tQHMGjdRLWWT/gVBQhPYxdhxTTX1muNaLgNRRr4gHHbn/FhU8ruHsLTkRFQUxp2YPBMxbn9xZ+NXjJQHmYiGPWw/qxCIHs9g1GWxSTvo99VpVoMfT0aRUPfqfYOkXUjLrWCCElqPS7t1TJAPR7TMXcgXIPv6ZFWhQuUTY+peE3zRWPX1XeHF4nQgg85kDxRoz1vD1gYmeBn3BiVnS5btNbUrkIZmILvSLIWXXAVaxAkdF7umXXw2jZUKome52uiGq8t7/HHhaXE8oQ33aTZ/7is5aIHTSN+PX5NQYkpwlFXQCDLHAi3dvnTIMwpfHvHfqhYpjlaywj8sGpIKL/bcxPojfgQrXKxQ5RDSjSy2GjckF9aYGKksP/DtONZ6CEcMu2d/T9Gg4km1FSEx+GocZDcXEXg7cFqdfPKUK2aTdSMUdP9iRIxVkQe2bm5G+aIaKXE3gKpkluW7nYYbztpvbpijpXt3+iw6/2VzeNvhg/ags0Hiykufy4L/AB6pWwQgx2rruPp2uEXrRpFt0c9pqJfOBkbOBzVqlczZdfJuCv3K9BmS3Pa8WcY5lhdfKVOpLg6kHZi4zHtBHo8ucWmfM7tIuiXF7n6dqt4BlMAP9AyXpB6dFThXUKt53I8W/smHnWnMJEu1EF9zCQ2Fa3smcvPfiA2DSOOFxqxrnE7U7RtqNpv6szj0t75CPLFiL7w== 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)(136003)(396003)(366004)(39860400002)(346002)(376002)(30864003)(186003)(2616005)(36756003)(83380400001)(2906002)(66574015)(31686004)(5660300002)(45080400002)(6512007)(8936002)(786003)(316002)(66946007)(53546011)(33964004)(6506007)(478600001)(66556008)(66476007)(8676002)(86362001)(38100700002)(6916009)(166002)(966005)(41300700001)(31696002)(6486002)(513134003)(45980500001)(43740500002); DIR:OUT; SFP:1101 X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dFVjT2xycjF5eGJxVVRlTXRUanRBSEE5SmY2eVNXd2RTVnJEZzhUMEdEa0tx?= =?utf-8?B?M1ZwYll6NCtpaUhRaTJlRjNIRmp6MFd4amlDUE9FNkZmdjNGZGptVzA1a2ZX?= =?utf-8?B?YmdKa0JkVnNRRDJodzFEcWFtdjBvZlpwS0V6TUV6ek5GMEN2WDhsVnlXQVBF?= =?utf-8?B?L0ZXcEh4bjlPdk9SdGpqdnF0bWZ0aUJFVS9jQ3dMb1dJeFdJZjNjaE9GenVU?= =?utf-8?B?YTdxRXRQa3U0blo3eHgzZ3h1cDBHTmJCT1k4ZUtPRmFLeFNEQXJaUGxoZUJQ?= =?utf-8?B?WkhJTGlsTjQxSkZrOXVsM1dSdHBuSEdKNE9qeHlzb091Tmp2SlpxelFqVW1y?= =?utf-8?B?QWNIbTl5anhFUnpsQVZPa09zR3JXZmorNmxwR1hQWWthSGxhMkswUzJETkVP?= =?utf-8?B?VVlTS1FZa3RkTFlxMDN0SEorWHNwcUt5bnVxbkllL3NGS3RPanUrMWNIQ1hX?= =?utf-8?B?TitUbytOdWhhaWxaMHpMQ2JDQ0o5a1JCVlpmNzNQTmpqQWhZeS9nVmQ5cU1j?= =?utf-8?B?bTk2TWZsaTRINXJUbzRPVURkVCtyeHdTelpUOVJlY3Y2d1JCeENHc0hpQkFw?= =?utf-8?B?bTRDZlJxK0o3OU4wMFpDbjZPNk1pa1h5d1FnZ3F4S1hWTjd6bDNRbWJtQ3hB?= =?utf-8?B?S2hIRWswSnJENklnSGt0enNuRkprdDFJNkMxRTlwNDNUcHdpSXcxYVVkMUlW?= =?utf-8?B?TkJzNDZQYzRtVkNzVG1RQkIxUUY4bzVJUEFVbVFyTWZMb21mWFk4cFpkUUxo?= =?utf-8?B?M0h3dzdlZFoxOERMbGlwNFM0aFcxSWdaZXA4QmxoNEJMM002SUJsQjFYZCt4?= =?utf-8?B?TmROL3k1ZnQzRXJhZHBsTXRMOXRHWmtWNHZoMFRpSDAyS2E0dkVBZ0YxZlRr?= =?utf-8?B?RkswN1dIWjRlQU53ZXJVTVdrTkVmSnZKQTFpd1hmRWxySGFJTjBjSlpsQUFY?= =?utf-8?B?dzg3TkZmcVNCM2RXaWQ0NEp3ei9CcEl5YjcvQnNxSDlCMmFBNVZya29sZjJJ?= =?utf-8?B?bEN4ZzRRN0tqWWVqdG4zZUNJdURkSUEyU1NHK3NDU3FrU1VzYSt2UmlRbWIx?= =?utf-8?B?OEdoOUJUMzdQbnJxVjAxSnZ4ZEdWSHpnM2E0Si9FRFVCbzhuZ2E0eXN4bXBJ?= =?utf-8?B?bjc2NmFrYXU2NUk2bzJpZDVaQTBYTU45anltbkM4UzdVbVQzQTlLT1hlb3RV?= =?utf-8?B?b3FOT3FIY01YS09JNUFMTTRrcEhOZkt3d291RnVBM3BSU3p0Smw3R2EvK3Fu?= =?utf-8?B?bnFvaXN3QzdxaG1Uc2ZBbWxzcVVhTzVrTURHNjZkQzZKRnl3VGZiK0FuMlJM?= =?utf-8?B?MjVpVWozVEgzRUkvOTAxRm8rRVB6RkcrdEVWUnZZaUJhQjdxdzArQ2ZnTGNN?= =?utf-8?B?SnVVR0VZZjhVZWVKeUw5RXBYM1ZGNSt2K3N1NTdHNzlQZFJTcGszTDdldGZ6?= =?utf-8?B?ajlQMjdIL0dqWHo2VVBnKzNEbWRJOGxMSUFBbHhCZFVWdUNBWU5BbEFrcmZ1?= =?utf-8?B?cVpLUkdmRitFajVZbU05TWk3UTJSL2hkMWRlUk83Zm1KSUVyOGQydXo4Q1RK?= =?utf-8?B?aE1PRWtUZWZPc1NGSEkwR2lVOTMxSnhtQmMxN1NJVnhmb04xekduYVRreThF?= =?utf-8?B?eXZRTmVRSmphcG01ZGZxcjM5Y3RBYnprQjhEOVZsMjA2YUs2Y3VnU3FPUzYw?= =?utf-8?B?UzN0VWd5b29TaCtkaXpKRnhQNlJkMXZsbXJoZGtxQUZ4U2pjc3BOOWM1L2xD?= =?utf-8?B?MFQ4NHRkWVBEZXhkcnJoaHR0NXRsR2hnYUh4eUplYTRqUzFvS2JvaDdydFlM?= =?utf-8?B?NUJGdHJzcFR1OHh0ZkFmQ21YeU1xT2JqQXhkVzZkdTNLMS9TdFdaM29pN2ky?= =?utf-8?B?QXJJaG0waE8vSmk0ckYveFFrK1hadnMxQmowUkppdUxFYXVoOEN6L3NRdEJo?= =?utf-8?B?NUhGQjNjN1Y2T2gvcCs4VXRiMnltZGhyMGM0M0lEejRHTHFUVlZrR2EzZEFJ?= =?utf-8?B?Y1pYeFY2K2Y4ZEVpMU1XVzBTU0VMSzFBK01HWGw1NHhUSGFYZ3FGWjFOa3hH?= =?utf-8?B?OXNJbDhRazUwZ2tCWFR5dG5GQitmUmU0U25zRWw4bTMrNGE4cE1WcXV4cDlh?= =?utf-8?B?MWdtaHo1b1FqSlN1N2FXTDJKVEIvc3drQXpUQnF2d1ZuSGFZNGM3TE5EWTlG?= =?utf-8?B?K3hlLzBXZnl4d0YySnlSS2tDTlp2MFo1YkJ3TEhaN2J4SGc3QlFaMWh0S3Bq?= =?utf-8?Q?oAZz+F9qsTOBaLw5pOXCbEIAzMFBYrhx45uurkn+uM=3D?= X-OriginatorOrg: auckland.ac.nz X-MS-Exchange-CrossTenant-Network-Message-Id: 10480d45-b529-4a71-99e8-08da8b9a3e63 X-MS-Exchange-CrossTenant-AuthSource: SY4PR01MB6979.ausprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Aug 2022 21:46:21.5223 (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: xfvZqA8YJoY7pDKaw/fKh2d0KN+0BCHdHw5mX/ugvQm9vQ1mZYAIRSKpqM2tPh7h3pB/w4msUDxSz1zu2m8Fti4PE0gnlkkJK7GLukSNQjM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: ME3PR01MB8226 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: auckland.ac.nz Content-Type: multipart/alternative; boundary="------------C6wrfODiRHQ00DR0G5kUPqKV" Content-Language: en-US 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 21:46:27 -0000 --------------C6wrfODiRHQ00DR0G5kUPqKV Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable I work on the assumption that Starlink satellites are, or at least will=20 eventually be, processing IP packets. For inter-satellite routing it's=20 more or less a must-have unless you have some other packet switching=20 protocol layered in between. On 1/09/2022 2:51 am, David Fern=C3=A1ndez via Starlink wrote: > "DNS on Starlink satellites: Good idea, lightweight, and I'd suspect > maybe already in operation?" > > Are the satellites processing IP packets? Are the ISLs even in > operation? I have been told Starlink satellites are transparent. > > > > Date: Thu, 1 Sep 2022 01:41:07 +1200 > > From: Ulrich Speidel > > To: David Lang > > Cc: Sebastian Moeller , Ulrich Speidel via Starlink > > > > Subject: Re: [Starlink] Starlink "beam spread" > > Message-ID: <56e56b0f-07bd-fe0c-9434-2663ae9d4404@auckland.ac.nz> > > Content-Type: text/plain; charset=3DUTF-8; format=3Dflowed > > > > Um, yes, but I think we're mixing a few things up here (trying to bundl= e > > responses here, so that's not just to you, David). > > > > In lieu of a reliable Starlink link budget, I'm going by this one: > > > >=20 > https://www.linkedin.com/pulse/quick-analysis-starlink-link-budget-potent= ial-emf-david-witkowski/=20 > > > > > Parameters here are a little outdated but the critical one is the EIRP > > at the transmitter of up to ~97 dBm. Say we're looking at a 30 GHz Ka > > band signal over a 600 km path, which is more reflective of the current > > constellation. Then Friis propagation gives us a path loss of about 178 > > dB, and if we pretend for a moment that Dishy is actually a 60 cm > > diameter parabolic dish, we're looking at around 45 dBi receive antenna > > 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 > > receiver. Now I'm assuming here that this is for ALL user downlink beam= s > > from the satellite combined. What we don't really know is how many > > parallel signals a satellite multiplexes into these, but assuming at th= e > > moment a receive frontend bandwidth of about 100 MHz, noise power at th= e > > receiver should be around 38 pW or -74 dBm. That leaves Starlink around > > 38 dB of SNR to play with. Shannon lets us send up to just over 1.25 > > Gb/s in that kind of channel, but then again that's just the Shannon > > 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 > > needs to achieve from the beams from another satellite in order for tha= t > > other satellite to re-use the same frequency. Note that this is > > significantly more than just the 3 dB that the 3 dB width of a beam > > gives us. The 3 dB width is what is commonly quoted as "beam width", an= d > > that's where you get those nice narrow angles. But that's just the widt= h > > at which the beam drops to half its EIRP, not the width at which it can > > no longer interfere. For that, you need the 38 dB width - or thereabout= s > > - if you can get it, and this will be significantly more than the 1.2 > > degrees or so of 3dB beam width. > > > > But even if you worked with 1.2 degrees at a distance of 600 km and you > > assumed that sort of beam width at the satellite, it still gives you an > > >12 km radius on the ground within which you cannot reuse the downlink > > frequency from the same satellite. That's orders of magnitude more than > > the re-use spatial separation you can achieve in ground-based cellular > > networks. Note that the 0.1 deg beam "precision" is irrelevant here - > > that just tells me the increments in which they can point the beam, but > > not how wide it is and how intensity falls off with angle, or how bad > > the side lobes are. > > > > Whether you can re-use the same frequency from another satellite to the > > same ground area is a good question. We really don't know the beam > > patterns that we get from the birds and from the Dishys, and without > > these it's difficult to say how much angular separation a ground statio= n > > needs between two satellites using the same frequency in order to > > receive one but not be interfered with by the other. Basically, there > > are just too many variables in this for me to be overly optimistic that > > re-use by two different sources within a Starlink cell is possible. And > > I haven't even looked at the numbers for Ku band here. > > > > CDNs & Co - are NOT just dumb economic optimisations to lower bit miles= . > > They actually improve performance, and significantly so. A lower RTT > > between you and a server that you grab data from via TCP allows a much > > faster opening of the congestion window. With initial TCP cwnd's being > > typically 10 packets or around 15 kB of data, having a server within 10 > > ms of your client means that you've transferred 15 kB after 5 ms, 45 kB > > after 10 ms, 105 kB after 15 ms, 225 kB after 20 ms, and 465 kB after 2= 5 > > ms. Make your RTT 100 ms, and it takes half a second to get to your 465 > > kB. Having a CDN server in close topological proximity also generally > > reduces the number of queues between you and the server at which packet= s > > can die an untimely early death, and generally, by taking load off such > > links, reduces the probability of this happening at a lot of queues. > > Bottom line: Having a CDN keeps your users happier. Also, live streamin= g > > and video conferencing aside, most video is not multicast or broadcast, > > but unicast. > > > > DNS on Starlink satellites: Good idea, lightweight, and I'd suspect > > maybe already in operation? It's low hanging fruit. CDNs on satellites: > > In the day and age of SSDs, having capacity on the satellite shouldn't > > really be an issue, although robustness may be. But heat in this sort o= f > > storage gets generated mostly when data is written, so it's a function > > of what percentage of your data that reaches the bird is going to end u= p > > in cache. Generally, on a LEO satellite that'll have to cache baseball > > videos while over the US, videos in a dozen different languages while > > over Europe, Bollywood clips while over India, cooking shows while over > > Australia and always the same old ads while over New Zealand, all the > > while not getting a lot of cache hits for stuff it put into cache 15 > > minutes ago, would probably have to write a lot. Moreover, as you'd be > > reliant on the content you want being on the satellite that you are > > currently talking to, pretty much all satellites in the constellation > > would need to cache all content. In other words: If I watch a cat video > > now and thereby put it into the cache of the bird overhead, and then > > send you an e-mail and you're in my neighbourhood and you watch it half > > an hour later, my satellite would be on the other side of the world, an= d > > you'd have to have it re-uploaded to the CDN on the bird that's flying > > overhead our neighbourhood then. Not as efficient as a ground-based CDN > > 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 > > 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 > >>> 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 frequency (with the same burst slot etc.). > >> > >> not quite, you are forgetting that the antennas on the ground are also > >> steerable arrays and so they can focus their 'receiving beam' at > >> different satellites. This is less efficient than a transmitting beam > >> as the satellites you aren't 'pointed' at will increase your noise > >> floor, but it does allow the same frequency to be used for multiple > >> satellites into the same area at the same time. > >> > >> David Lang > >> > > -- > > **************************************************************** > > 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/=20 > > > **************************************************************** > > > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink=20 > --=20 **************************************************************** Dr. Ulrich Speidel School of Computer Science Room 303S.594 (City Campus) The University of Auckland u.speidel@auckland.ac.nz =20 http://www.cs.auckland.ac.nz/~ulrich/ **************************************************************** --------------C6wrfODiRHQ00DR0G5kUPqKV Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I work on the assumption that Starlink satellites are, or at least will eventually be, processing IP packets. For inter-satellite routing it's more or less a must-have unless you have some other packet switching protocol layered in between.

On 1/09/2022 2:51 am, David Fern=C3=A1nd= ez via Starlink wrote:
=20 "DNS on Starlink satellites: Good idea, lightweight, and I'd suspect
maybe already in operation?"

Are the satellites processing IP packets? Are the ISLs even in
operation? I have been told Starlink satellites are transparent.


> Date: Thu, 1 Sep 2022 01:41:07 +1200
> From: Ulrich Speidel <u.speidel@auckland.ac.nz>
> To: David Lang <david@lang.hm>
> Cc: Sebastian Moeller <moeller0@gmx.de>, Ulrich Speidel via Starlink
> <starlink@lists.bufferbloat.net>
> Subject: Re: [Starlink] Starlink "beam spread"
> Message-ID: <56e56b0f-07bd-fe0c-9434-2663ae9d4404@= auckland.ac.nz>
> Content-Type: text/plain; charset=3DUTF-8; format=3Dflowed
>
> Um, yes, but I think we're mixing a few things up here (trying to bundle
> 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-potential-emf= -david-witkowski/
>
> Parameters here are a little outdated but the critical one is the EIRP
> at the transmitter of up to ~97 dBm. Say we're looking at a 30 GHz Ka
> band signal over a 600 km path, which is more reflective of the current
> constellation. Then Friis propagation gives us a path loss of about 178
> dB, and if we pretend for a moment that Dishy is actually a 60 cm
> diameter parabolic dish, we're looking at around 45 dBi receive antenna
> 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
> receiver. Now I'm assuming here that this is for ALL user downlink beams
> from the satellite combined. What we don't really know is how many
> parallel signals a satellite multiplexes into these, but assuming at the
> moment a receive frontend bandwidth of about 100 MHz, noise power at the
> receiver should be around 38 pW or -74 dBm. That leaves Starlink around
> 38 dB of SNR to play with. Shannon lets us send up to just over 1.25
> Gb/s in that kind of channel, but then again that's just the Shannon
> 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
> needs to achieve from the beams from another satellite in order for that
> other satellite to re-use the same frequency. Note that this is
> significantly more than just the 3 dB that the 3 dB width of a beam
> gives us. The 3 dB width is what is commonly quoted as "bea= m width", and
> that's where you get those nice narrow angles. But that's just the width
> at which the beam drops to half its EIRP, not the width at which it can
> no longer interfere. For that, you need the 38 dB width - or thereabouts
> - if you can get it, and this will be significantly more than the 1.2
> degrees or so of 3dB beam width.
>
> But even if you worked with 1.2 degrees at a distance of 600 km and you
> assumed that sort of beam width at the satellite, it still gives you an
> >12 km radius on the ground within which you cannot reuse the downlink
> frequency from the same satellite. That's orders of magnitude more than
> the re-use spatial separation you can achieve in ground-based cellular
> networks. Note that the 0.1 deg beam "precision" is irrelevant here -
> that just tells me the increments in which they can point the beam, but
> not how wide it is and how intensity falls off with angle, or how bad
> the side lobes are.
>
> Whether you can re-use the same frequency from another satellite to the
> same ground area is a good question. We really don't know the beam
> patterns that we get from the birds and from the Dishys, and without
> these it's difficult to say how much angular separation a ground station
> needs between two satellites using the same frequency in order to
> receive one but not be interfered with by the other. Basically, there
> are just too many variables in this for me to be overly optimistic that
> re-use by two different sources within a Starlink cell is possible. And
> I haven't even looked at the numbers for Ku band here.
>
> CDNs & Co - are NOT just dumb economic optimisations to lower bit miles.
> They actually improve performance, and significantly so. A lower RTT
> between you and a server that you grab data from via TCP allows a much
> faster opening of the congestion window. With initial TCP cwnd's being
> typically 10 packets or around 15 kB of data, having a server within 10
> ms of your client means that you've transferred 15 kB after 5 ms, 45 kB
> after 10 ms, 105 kB after 15 ms, 225 kB after 20 ms, and 465 kB after 25
> ms. Make your RTT 100 ms, and it takes half a second to get to your 465
> kB. Having a CDN server in close topological proximity also generally
> reduces the number of queues between you and the server at which packets
> can die an untimely early death, and generally, by taking load off such
> links, reduces the probability of this happening at a lot of queues.
> Bottom line: Having a CDN keeps your users happier. Also, live streaming
> and video conferencing aside, most video is not multicast or broadcast,
> but unicast.
>
> DNS on Starlink satellites: Good idea, lightweight, and I'd suspect
> maybe already in operation? It's low hanging fruit. CDNs on satellites:
> In the day and age of SSDs, having capacity on the satellite shouldn't
> really be an issue, although robustness may be. But heat in this sort of
> storage gets generated mostly when data is written, so it's a function
> of what percentage of your data that reaches the bird is going to end up
> in cache. Generally, on a LEO satellite that'll have to cache baseball
> videos while over the US, videos in a dozen different languages while
> over Europe, Bollywood clips while over India, cooking shows while over
> Australia and always the same old ads while over New Zealand, all the
> while not getting a lot of cache hits for stuff it put into cache 15
> minutes ago, would probably have to write a lot. Moreover, as you'd be
> reliant on the content you want being on the satellite that you are
> currently talking to, pretty much all satellites in the constellation
> would need to cache all content. In other words: If I watch a cat video
> now and thereby put it into the cache of the bird overhead, and then
> send you an e-mail and you're in my neighbourhood and you watch it half
> an hour later, my satellite would be on the other side of the world, and
> you'd have to have it re-uploaded to the CDN on the bird that's flying
> overhead our neighbourhood then. Not as efficient as a ground-based CDN
> 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
> 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
>>> 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 frequency (with the same burst slot etc.).
>>
>> not quite, you are forgetting that the antennas on the ground are also
>> steerable arrays and so they can focus their 'receiving beam' at
>> different satellites. This is less efficient than a transmitting beam
>> as the satellites you aren't 'pointed' at will increase your noise
>> floor, but it does allow the same frequency to be used for multiple
>> satellites into the same area at the same time.
>>
>> David Lang
>>
> --
> ****************************************************************
> 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
--=20
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

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