From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x2d.google.com (mail-oa1-x2d.google.com [IPv6:2001:4860:4864:20::2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 2912A3B29D for ; Fri, 2 Sep 2022 05:32:58 -0400 (EDT) Received: by mail-oa1-x2d.google.com with SMTP id 586e51a60fabf-1225219ee46so3426931fac.2 for ; Fri, 02 Sep 2022 02:32:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:from:to:cc:subject:date; bh=AZjQyBFjNUQRWAGGvLFd5zCqhumKU6/ZSiovcqTt8dk=; b=iKtLK750gZj9M063jKpO0lYInOqx9U3FLu50AcenKh5TTSJo8n4i5BjCFUmyuBX7eI RbM0faNPvJjfmCmvX+bP6X1TSBZGIivxKZZoomQOXUIOXBdjE1/ENcaLK++b1gmbSfIT TQbylwLrrXAN3D4H25o6jzd+aj4k+YhpMF2FdeNcw4m97ltBiB4j7BNM+1co4pHl7iUL eQDtWPfsJHVdkLW5jy8mGh8UWFgNcQv+uHJYAIMJCK5QKWKhWaj+TPxjHFaIPOFpBZkQ EGZ+o8Ikklp4xW3bqeUWzwtfjulwiixBJmNIH3fasu+Lr2RKOP2nL2jo/JPDe1PAFhrU 4GXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:x-gm-message-state:from:to:cc :subject:date; bh=AZjQyBFjNUQRWAGGvLFd5zCqhumKU6/ZSiovcqTt8dk=; b=XwYCLOCBq5kMIrQSqaq3hfHQHvqLz/GFPblerOMRHSH2xWhE6nbOgXtUhL1gcNLutd EzuvIzZOTSdpZ0VzIS0jMnPo+KEPaw30DxJ9V+ISLR/bxdnxvdBNWD06oh9eGAEk7ucK T72E1Zm7rZP7mUjPERu4ZU4n+nJicSFvRlxsIQZdwOhFiBC2AT9zH2RAPJ3z1EWFdLs3 EWwoivyevw5Qy0Sz//LKcqJIaPu4e86aMTxxULxrtUnydi3+TYIRhI4tK5sC2juYMAxJ FBbNkzBh1QCNZzBJWWW3NecRYVEiEDeLB/hkaoyzWTovLeYGa/PRq6AOtMi2t7+Szi4W Lrsg== X-Gm-Message-State: ACgBeo2fARDQ8CEGfW/3wEXgV8sA1geWV3/Qm0dQX4dbEnsqTLMmezxu 5xr9i49rWgCfdqelhzER1LUM2r0S7P46YAcwQNzvmDP45cYYBFDe X-Google-Smtp-Source: AA6agR5hRzopMBFo9TdryFqDovwS3w9qe15JXQHxVj1EUh1gayQOMbYE5h3FEO5wyo2GNsmWbeLGob4toFxnDpkz+jk= X-Received: by 2002:aca:110e:0:b0:343:b8d:e8e8 with SMTP id 14-20020aca110e000000b003430b8de8e8mr1485519oir.159.1662111177199; Fri, 02 Sep 2022 02:32:57 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a05:6358:3d4f:b0:b5:d790:a4f with HTTP; Fri, 2 Sep 2022 02:32:56 -0700 (PDT) In-Reply-To: <536B72A0-0A51-4829-B116-826870A7D147@onholyground.com> References: <536B72A0-0A51-4829-B116-826870A7D147@onholyground.com> From: =?UTF-8?Q?David_Fern=C3=A1ndez?= Date: Fri, 2 Sep 2022 11:32:56 +0200 Message-ID: To: Darrell Budic Cc: starlink@lists.bufferbloat.net Content-Type: text/plain; charset="UTF-8" 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: Fri, 02 Sep 2022 09:32:58 -0000 Starlink gateways are connected to Google data centres: https://www.prnewswire.com/news-releases/google-cloud-and-spacexs-starlink-= to-deliver-secure-global-connectivity-301290801.html It has been said that one of the 'killer' applications of SATCOM for companies could be one hop access to their business critical applications in the cloud from anywhere. Starlink goes with Google, SES (O3b) and iDirect with Microsoft Azure, Kuiper for Amazon (in the future)... Oneweb, Telesat... Others? 2022-09-01 18:33 GMT+02:00, Darrell Budic : > If I recall correctly, Starlink has told us they encrypt from ground to > ground. So whatever they do in the sat constellation, it=E2=80=99s an und= erlay > network and our IP traffic never sees it. This doesn=E2=80=99t preclude I= SL, but it > does work against the concept of a CDN in space. Seems like it=E2=80=99s = easier for > them to get on more IXs and even host cache servers at the ground station= s > if they have enough data center space at them. Of course, there=E2=80=99s= nothing > preventing them from putting up a satellite that gets treated as an endpo= int > and does decryption, but then it=E2=80=99s just another end point on thei= r > underlay. > >> On Sep 1, 2022, at 10:19 AM, David Fern=C3=A1ndez via Starlink >> wrote: >> >> If Starlink satellites are processing IP packets, shouldn't them be >> shown in traceroutes? They are not shown now, AFAIK. >> >> A transparent geographical based routing could be possible, with >> signal-pass-through approach to the next satellite on a path >> connecting to a GW, via ISL, if the satellite receiving traffic from a >> dishy does not have any GW at direct sight. >> >>> Date: Thu, 1 Sep 2022 09:46:20 +1200 >>> From: Ulrich Speidel >>> To: starlink@lists.bufferbloat.net >>> Subject: Re: [Starlink] Starlink "beam spread" >>> Message-ID: <7a357510-2d61-dd4a-a59f-3d7d4bd3727c@auckland.ac.nz> >>> Content-Type: text/plain; charset=3D"utf-8"; Format=3D"flowed" >>> >>> 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=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 >>>>> 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-pot= ential-emf-david-witkowski/ >>>> >>>> >>>>> >>>>> Parameters here are a little outdated but the critical one is the EIR= P >>>>> 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 Dish= y >>>>> 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 "beam 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 downlin= k >>>>> frequency from the same satellite. That's orders of magnitude more >>>>> than >>>>> the re-use spatial separation you can achieve in ground-based cellula= r >>>>> 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 muc= h >>>>> faster opening of the congestion window. With initial TCP cwnd's bein= g >>>>> 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 functio= n >>>>> 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 basebal= l >>>>> 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 b= e >>>>> 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 flyin= g >>>>> 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 bea= m >>>>>> 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 >>>> >> _______________________________________________ >> Starlink mailing list >> Starlink@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/starlink > >