From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 9D4DD3B29E for ; Thu, 1 Sep 2022 11:19:23 -0400 (EDT) Received: by mail-ot1-x32b.google.com with SMTP id y25-20020a056830109900b0063b3c1fe018so5281357oto.2 for ; Thu, 01 Sep 2022 08:19:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:to:subject:message-id:date:from :mime-version:from:to:cc; bh=2Z/1bv+L0x9zt6MPj+/OvQ3Nl9zVVKmQn/GJiHYOq1g=; b=l5nZvkqXtkReanKbKiFuFudsWd9jl2PqIB0E8uavF3RO7XOa7Y7K+w/9rDZxIs1BoO EPTSSKGyFXOUSNAoxetU4pT/u+PXqpTN+gCMxm8qRZHXwHFgGHpYtWdr01j4W2vXYm7O WLN3UEpw7wD1mcCzXOCqTqOhhRxgTf/Z0qYqJQO/u6CuFB84Cr6fc2Y1UhMETfrJsXIu t4eaO0TC4tJH5ejLIqZerF1UCy7fHEZ/gJLoPrMbvpL4vi9S5ReSafzBEVRVcoJlIELa ZvHVgdcSsTx6viSxWsOUVTWSM4E8PN5MD8Nuxqq8CMgXGhLEoYiZMHV0zQu8aLz/GTbH 6X/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:to:subject:message-id:date:from :mime-version:x-gm-message-state:from:to:cc; bh=2Z/1bv+L0x9zt6MPj+/OvQ3Nl9zVVKmQn/GJiHYOq1g=; b=7cNDruUGbee2/ztMcB/oNaYkhvp3uhJiGUQW2SYMmrbCW65BpUq0rRtCCfTA37X/nP XNd/urO5cgGQvk6y5vkJuTmIafDVVXLrOjUHke90GFeTV52EFvrLhbxF8Sci0t+zAX+s P+gVZMzBMuMzRWP20jFMTp4vRr4Lmiv1Fhfdj0oHaffGq4bAOszOgMvhY0H8Tw94NXnO CTSzhmLc+aIb7YjJyeayg8pyrIMawot2XfZO2BnuYIoJUwq2KNCDVqmttPKXvNZ4IBgQ wHm0vt3CAfkC/TYhQFWbV0BKeEs/JptHBeyLagPdIhRtvq9J/F2zXB6Jpa006tyrMqn8 GJaw== X-Gm-Message-State: ACgBeo3euPWOzC/eR0ZdH+rfw5bf4DhwhM5nCRLNmAibtNLTRbHcmLMt /ODeOF/Crp16z0itx6PTzrclNSIMjaUqOiIY9ukDsBpEaiPbDbjo X-Google-Smtp-Source: AA6agR5V1rxuXBLIvm67ArnHPHQwLr0iHbldJV/Mo40qBdu7giUorWnVZjzJKTMZfTAHtMtwmdLXHtv8M1K4HLmZJaI= X-Received: by 2002:a05:6830:1418:b0:639:48a8:f005 with SMTP id v24-20020a056830141800b0063948a8f005mr12888553otp.94.1662045562603; Thu, 01 Sep 2022 08:19:22 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a05:6358:3d4f:b0:b5:d790:a4f with HTTP; Thu, 1 Sep 2022 08:19:22 -0700 (PDT) From: =?UTF-8?Q?David_Fern=C3=A1ndez?= Date: Thu, 1 Sep 2022 17:19:22 +0200 Message-ID: To: 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: Thu, 01 Sep 2022 15:19:23 -0000 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 bund= le >> > 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-poten= tial-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 curren= t >> > constellation. Then Friis propagation gives us a path loss of about 17= 8 >> > 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 antenn= a >> > 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 bea= ms >> > from the satellite combined. What we don't really know is how many >> > parallel signals a satellite multiplexes into these, but assuming at t= he >> > moment a receive frontend bandwidth of about 100 MHz, noise power at t= he >> > receiver should be around 38 pW or -74 dBm. That leaves Starlink aroun= d >> > 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 th= at >> > 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", a= nd >> > that's where you get those nice narrow angles. But that's just the wid= th >> > at which the beam drops to half its EIRP, not the width at which it ca= n >> > no longer interfere. For that, you need the 38 dB width - or thereabou= ts >> > - 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 yo= u >> > assumed that sort of beam width at the satellite, it still gives you a= n >> > >12 km radius on the ground within which you cannot reuse the downlink >> > frequency from the same satellite. That's orders of magnitude more tha= n >> > 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, bu= t >> > 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 th= e >> > 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 stati= on >> > 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 tha= t >> > re-use by two different sources within a Starlink cell is possible. An= d >> > I haven't even looked at the numbers for Ku band here. >> > >> > CDNs & Co - are NOT just dumb economic optimisations to lower bit mile= s. >> > 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 1= 0 >> > ms of your client means that you've transferred 15 kB after 5 ms, 45 k= B >> > 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 46= 5 >> > kB. Having a CDN server in close topological proximity also generally >> > reduces the number of queues between you and the server at which packe= ts >> > can die an untimely early death, and generally, by taking load off suc= h >> > links, reduces the probability of this happening at a lot of queues. >> > Bottom line: Having a CDN keeps your users happier. Also, live streami= ng >> > 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 ove= r >> > 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 vide= o >> > 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 hal= f >> > an hour later, my satellite would be on the other side of the world, a= nd >> > 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 CD= N >> > 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 als= o >> >> 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 >>