Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Colin_Higbie <CHigbie1@Higbie.name>
To: "starlink@lists.bufferbloat.net" <starlink@lists.bufferbloat.net>
Subject: [Starlink] Re: Starlink and Iran
Date: Thu, 15 Jan 2026 21:49:08 +0000	[thread overview]
Message-ID: <BN7PPF7A8514BAD6A406106C3476B563A69F18CA@BN7PPF7A8514BAD.namprd16.prod.outlook.com> (raw)
In-Reply-To: <176851123059.1249.8585659892308012167@gauss>

Ulrich, thanks. That's a great description and you're right that I had not appreciated how much more directional these are today  (in fact, in the early military applications, before it was available in cell phones, the lack of directionality was important to protect our teams from being located, even as they were transmitting from close to an enemy location).

However, this creates a follow-up question: working as you describe, which I accept as correct, why the big concern from Jeff Bezos and others about the sky coverage of the Starlink LEO constellation making it tough for them? If the signal is as hyperdirectional as you've described (also saw your laser pointer example in response to Hayden Simon), I would think that means very low risk of significant interference between two nearby layers of satellites. Even with thousands zipping around the Earth, I would think the probability is quite low of any two of them being on the same line to a home dish. What kind of interference are Starlink's competitors complaining about? Is it that while it's tight beam, it's still not *that* tight, so if they're within a few miles of each other, that's enough to trigger interference?

Thanks,
Colin


-----Original Message-----
From: Ulrich Speidel via Starlink <starlink@lists.bufferbloat.net>
Sent: Friday, 16 January 2026 9:27 am
To: starlink@lists.bufferbloat.net
Subject: [Starlink] Re: Starlink and Iran

On 16/01/2026 6:42 am, Colin_Higbie via Starlink wrote:
> Can't the traditional approach of just flooding the air with noise reduce the SNR to the point that most packets are indecipherable? I don't believe this requires a digital or technically advanced approach nor a focus on GPS or anything else so specific, just sufficient power and ability to broadcast fully across the same spectrum bands to drown out the valid signals. Starlink, like cellular technology, uses excellent methods to operate amidst a lot of noise and find its packets, but it's still not immune to noise.
>
> Iran is a large area, and probably the government lacks the ability to block the entire nation simultaneously, but I would think they could drown out the signal in specific geographic regions, effectively jamming the signal entirely or almost entirely in those areas.
>
> Perhaps some of the cellular or satcom experts here can expand on or correct me if I'm mistaken. My physics knowledge on this has not updated much since the original spread spectrum work decades ago.

The original spread spectrum work concerned much much lower frequencies (in the MHz rather than the GHz) and the physics that goes with lower frequencies (not just spread spectrum) is that at the time, jamming was mostly used against receivers with fairly omnidirectional antennas. 
Read: It doesn't really matter where you transmit your interfering signal from - the receiver will hear it. It also helps that the (free
space) path loss of RF signals is proportional to the square of the frequency, so low frequency means you can hit a receiver over a substantial distance with relatively little power.

Starlink is a different ballgame: It operates in Ku-band above 10 GHz. 
This means highly directional antennas - so you literally need to transmit into the receive beam from the beam's preferred direction to be able to jam at all. Plus having to invest more power to bridge the distance means that flooding just isn't an option here.

--
****************************************************************
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/
****************************************************************


       reply	other threads:[~2026-01-15 21:49 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <176851123059.1249.8585659892308012167@gauss>
2026-01-15 21:49 ` Colin_Higbie [this message]
2026-01-15 23:15   ` [Starlink] Re: Starlink and Iran Frantisek Borsik
2026-01-16  0:13   ` Ulrich Speidel
2026-01-16  1:29     ` David Lang
2026-01-16 22:55       ` Frantisek Borsik
2026-01-16 23:06         ` J Pan
     [not found]     ` <13187.1768590201@obiwan.sandelman.ca>
2026-01-16 23:30       ` Ulrich Speidel
2026-01-17  0:07         ` David Lang
2026-01-17 21:56           ` Ulrich Speidel
2026-01-19 20:39             ` David Lang
2026-01-28  3:09               ` Ulrich Speidel
2026-01-28  3:30                 ` David Lang
2026-01-28  4:02                   ` Mike Puchol
2026-01-28  9:05                     ` Ulrich Speidel
2026-01-28  9:53                       ` David Lang
2026-01-28 20:43                         ` Ulrich Speidel
2026-01-28 20:55                           ` David Lang
2026-01-17 18:32         ` Michael Richardson
2026-01-17 18:38           ` Inemesit Affia
2026-01-17 19:25             ` Michael Richardson
2026-01-17 22:12           ` Ulrich Speidel
     [not found] <176849731431.1249.14387618908540773471@gauss>
2026-01-15 17:42 ` Colin_Higbie
2026-01-15 18:56   ` Jim Forster
2026-01-15 20:15     ` Ulrich Speidel
2026-01-15 20:27   ` Ulrich Speidel
2026-01-15 20:30     ` Hayden Simon
2026-01-15 21:06       ` Ulrich Speidel
2026-01-15 21:09         ` Hayden Simon
2026-01-15 21:20           ` Ulrich Speidel
2026-01-15 21:23             ` Hayden Simon
2026-01-15 14:50 David Fernández
2026-01-15 16:11 ` Oleg Kutkov
2026-01-15 17:13   ` J Pan
  -- strict thread matches above, loose matches on Subject: below --
2026-01-15  9:51 [Starlink] " Ulrich Speidel
2026-01-15 10:06 ` [Starlink] " Inemesit Affia
2026-01-15 10:30   ` Ulrich Speidel
2026-01-15 10:44     ` Inemesit Affia
2026-01-15 11:16       ` Ulrich Speidel
2026-01-15 10:32 ` Inemesit Affia
2026-01-15 10:51   ` Ulrich Speidel
2026-01-15 11:17 ` David Lang
2026-01-15 11:59   ` Sauli Kiviranta
2026-01-15 14:08     ` David Lang
2026-01-15 15:29       ` Sauli Kiviranta
     [not found]   ` <3af2ac06-e098-4c79-869d-9c389959ca07@gmail.com>
     [not found]     ` <q9304244-661o-3qsr-o6rp-9q1nqq09r419@ynat.uz>
     [not found]       ` <4ba64a41-bbbf-4fb5-adb0-c77c15e4ca0f@gmail.com>
2026-01-15 16:20         ` Inemesit Affia
2026-01-15 20:12   ` Ulrich Speidel
2026-01-15 17:10 ` J Pan
2026-01-15 20:07   ` Ulrich Speidel
2026-01-15 21:47     ` Oleg Kutkov
2026-01-16  4:18       ` Ulrich Speidel
2026-01-16  8:12         ` Frantisek Borsik
2026-01-16  8:24           ` Inemesit Affia

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/starlink.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BN7PPF7A8514BAD6A406106C3476B563A69F18CA@BN7PPF7A8514BAD.namprd16.prod.outlook.com \
    --to=chigbie1@higbie.name \
    --cc=starlink@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox