From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.ohgnetworks.com (smtp.ohgnetworks.com [204.130.133.20]) (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 E4E073B29E for ; Thu, 1 Sep 2022 12:33:27 -0400 (EDT) Received: from smtpclient.apple (castleinthewoods.onholyground.com [204.130.133.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.ohgnetworks.com (Postfix) with ESMTPSA id BEB161F4EC; Thu, 1 Sep 2022 16:33:26 +0000 (UTC) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.6 at mx-out.ohgnetworks.com DMARC-Filter: OpenDMARC Filter v1.4.1 smtp.ohgnetworks.com BEB161F4EC Authentication-Results: smtp.ohgnetworks.com; dmarc=pass (p=none dis=none) header.from=onholyground.com Authentication-Results: smtp.ohgnetworks.com; spf=pass smtp.mailfrom=onholyground.com DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.ohgnetworks.com BEB161F4EC Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) From: Darrell Budic In-Reply-To: Date: Thu, 1 Sep 2022 11:33:25 -0500 Cc: starlink@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <536B72A0-0A51-4829-B116-826870A7D147@onholyground.com> References: To: =?utf-8?Q?David_Fern=C3=A1ndez?= X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on mx-out.int.ohgnetworks.com 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: Thu, 01 Sep 2022 16:33:28 -0000 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 = underlay network and our IP traffic never sees it. This doesn=E2=80=99t = preclude ISL, 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 stations 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 endpoint and does = decryption, but then it=E2=80=99s just another end point on their = underlay. > On Sep 1, 2022, at 10:19 AM, David Fern=C3=A1ndez via Starlink = wrote: >=20 > If Starlink satellites are processing IP packets, shouldn't them be > shown in traceroutes? They are not shown now, AFAIK. >=20 > 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. >=20 >> 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" >>=20 >> 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. >>=20 >> 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?" >>>=20 >>> Are the satellites processing IP packets? Are the ISLs even in >>> operation? I have been told Starlink satellites are transparent. >>>=20 >>>=20 >>>> 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 >>>>=20 >>>> 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). >>>>=20 >>>> In lieu of a reliable Starlink link budget, I'm going by this one: >>>>=20 >>>>=20 >>> = https://www.linkedin.com/pulse/quick-analysis-starlink-link-budget-potenti= al-emf-david-witkowski/ >>>=20 >>> = >>>>=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. >>>>=20 >>>> 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. >>>>=20 >>>> 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 "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. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> As long as Starlink is going to have in the order of hundreds of >>>> thousands of direct users, that problem won't go away. >>>>=20 >>>> On 31/08/2022 7:33 pm, David Lang wrote: >>>>=20 >>>>> On Wed, 31 Aug 2022, Ulrich Speidel via Starlink wrote: >>>>>=20 >>>>>> 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.). >>>>>=20 >>>>> 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. >>>>>=20 >>>>> David Lang >>>>>=20 >>>> -- >>>> **************************************************************** >>>> Dr. Ulrich Speidel >>>>=20 >>>> School of Computer Science >>>>=20 >>>> Room 303S.594 (City Campus) >>>>=20 >>>> 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 >>> > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink