Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: "David Fernández" <davidfdzp@gmail.com>
To: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] Main hurdles against the Integration of Satellites and Terrestial Networks
Date: Sun, 3 Sep 2023 03:03:30 +0200	[thread overview]
Message-ID: <CAC=tZ0r+farGZ1jWaZP5YdGBRknRxh+AyehpiNw+7bVj3cOu8w@mail.gmail.com> (raw)

It seems that Starlink follows this norm, although it does not reflect
the entire Starlink system specification:
https://www.etsi.org/deliver/etsi_en/303900_303999/303981/01.02.00_30/en_303981v010200v.pdf

Then, for the ISL, I suppose they are following this:
https://www.sda.mil/wp-content/uploads/2022/04/SDA-OCT-Standard-v3.0.pdf

> Date: Fri, 1 Sep 2023 17:27:30 +0100
> From: Inemesit Affia <inemesitaffia@gmail.com>
> To: David Lang <david@lang.hm>
> Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com>,
> 	starlink@lists.bufferbloat.net
> Subject: Re: [Starlink] Main hurdles against the Integration of
> 	Satellites and Terrestial Networks
> Message-ID:
> 	<CAJEhh70CMSk_WAmd9sgXfMDoWZhhz5uPAU=d5UG3rW5XFkw1KQ@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> For the US military, starlink has already allowed two antenna/terminal
> manufacturers to connect to the network.
>
> Ball aerospace for aircraft.
>
> DUJUD(hope I got that right) for regular user terminals.
>
> Any antenna that connects with OneWeb should theoretically work apart from
> the DRM
>
> On Wed, Aug 30, 2023, 8:36 PM David Lang <david@lang.hm> wrote:
>
>> Exactly my thoughts (I haven't downloaded and read the full report yet).
>> What
>> are they looking to do with this 'integration'? I can integrate my
>> starlink just
>> like any other ISP.
>>
>> or are they looking at the 'cell phones to orbit' functionality thats due
>> to
>> roll out very suddently
>>
>> or are they looking for "intergration" as another way to say "force SpaceX
>> to
>> open the specs for Starlink and allow other user terminals to interact
>> with the
>> Starlink satellites?
>>
>> The cynic in me says it's the latter.
>>
>> long term it may make sense to do this to some degree, but we are WAY too
>> early
>> to define "Interoperability Standards" and block people from coming up
>> with
>> better ways to do things.
>>
>> the Apple vs SpaceX cellphone-to-satellite have completely different ways
>> of
>> operating, and who wants to tell all the Apple people that their way isn't
>> going
>> to be the standard (or worse, that it is and they have to give everyone
>> else the
>> ability to use their currently proprietary protocol)
>>
>> David Lang
>>
>> On Wed, 30 Aug 2023, Inemesit Affia via Starlink wrote:
>>
>> > With the existence of solutions like OpenMTCProuter, SDWAN, policy based
>> > routing or any solution in general that allows combination in a sense of
>> > any number of IP links, I really don't see a point for specific
>> solutions.
>> > Can anyone enlighten me?
>> >
>> > For home users an issue may be IP blocks for certain services like
>> Netflix
>> > when the egress is out of a VPN or cloud provider richer than a
>> residential
>> > provider
>> >
>> > On Wed, Aug 30, 2023, 2:57 PM Alexandre Petrescu via Starlink <
>> > starlink@lists.bufferbloat.net> wrote:
>> >
>> >>
>> >> Le 30/08/2023 à 14:10, Hesham ElBakoury via Starlink a écrit :
>> >>> Here is a report which summarizes the outcome of the last Satellites
>> >>> conference
>> >>> [
>> >>
>> https://www.microwavejournal.com/articles/39841-satellite-2023-summary-linking-up
>> >> ]
>> >>>
>> >>> The report highlights the two main hurdles against the integration of
>> >>> satellites and terrestrial networks: standardization and business
>> model.
>> >>>
>> >>> "/Most of the pushback against closer integration of terrestrial
>> >>> wireless and satellite networks revolved around standardization. This
>> >>> may just be growing pains and it likely reflects the relative
>> >>> positions of wireless and satellite along the maturity curve, but some
>> >>> of the speakers were arguing against standardization. The basis of
>> >>> this argument was that the mobile industry only understands standards,
>> >>> but the satellite industry is currently differentiating based on
>> >>> custom systems and capabilities. The feeling was that the satellite
>> >>> industry had focused on technology and not regulations or standards
>> >>> and changing that course would not be helpful to the industry in the
>> >>> short term. Timing is important in this analysis because almost
>> >>> everyone agreed that at some point, standardization would be a good
>> >>> thing, but the concern was the best way to get to the point in the
>> >>> future. The other interesting argument against closer integration
>> >>> between wireless and satellite had to do with the business model.
>> >>> Several speakers questioned where the customers would go as
>> >>> terrestrial and non-terrestrial networks become more integrated. The
>> >>> underlying issues seemed to include who is responsible for solving
>> >>> network issues and perhaps more importantly, who recognizes the
>> >>> revenue. These issues seem, perhaps a bit simplistically, to be
>> >>> similar to early wireless roaming issues. While these issues created
>> >>> turbulence in the wireless market, they were solved and that is
>> >>> probably a template to address these challenges for the wireless and
>> >>> satellite operators."/
>> >>> /
>> >>> /
>> >>> Comments?
>> >>
>> >>
>> >> It is an interesting report.
>> >>
>> >> For standardisation standpoint, it seems SDOs do push towards
>> >> integration of 5G/6G and satcom; there are strong initiatives at least
>> >> at 3GPP (NTN WI proposals) and IETF (TVR WG) in that direction.  But
>> >> these are SDOs traditionally oriented to land communications, rather
>> >> than space satcom.
>> >>
>> >> I wonder whether space satcom traditional SDOs (which ones?) have
>> >> initiated work towards integration with 5G/6G and other land-based
>> >> Internet?
>> >>
>> >> Alex
>> >>
>> >>>
>> >>> Hesham

             reply	other threads:[~2023-09-03  1:03 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-03  1:03 David Fernández [this message]
2023-09-03  3:44 ` Mike Puchol
2023-09-15 11:35 ` Alexandre Petrescu
  -- strict thread matches above, loose matches on Subject: below --
2023-10-16 13:26 David Fernández
2023-10-18 15:04 ` Alexandre Petrescu
2023-09-19 14:55 David Fernández
2023-09-19 15:15 ` David Lang
2023-09-20  8:09   ` Alexandre Petrescu
2023-09-20  8:32     ` David Lang
2023-08-31 16:12 David Fernández
2023-08-31 15:51 David Fernández
2023-08-30 12:10 Hesham ElBakoury
2023-08-30 13:57 ` Alexandre Petrescu
2023-08-30 16:51   ` Inemesit Affia
2023-08-30 19:35     ` David Lang
2023-09-01 16:27       ` Inemesit Affia
2023-09-15 11:29         ` Alexandre Petrescu
2023-09-15 15:18           ` Ulrich Speidel
2023-09-15 17:52             ` David Lang
2023-09-15 23:32               ` Ulrich Speidel
2023-09-17 17:21                 ` Alexandre Petrescu
2023-09-17 19:58                   ` David Lang
2023-09-18 23:32                     ` Hesham ElBakoury
2023-09-19  0:31                       ` David Lang
2023-09-19  0:36                         ` Hesham ElBakoury
2023-09-19  1:01                           ` David Lang
2023-09-19 13:44                           ` Alexandre Petrescu
2023-09-19 14:36                             ` David Lang
2023-09-19 13:35                       ` Alexandre Petrescu
2023-09-19 14:44                         ` David Lang
2023-09-17 17:12               ` Alexandre Petrescu
2023-09-17 17:09             ` Alexandre Petrescu
2023-09-17 18:06               ` Steve Stroh
2023-08-31  8:44     ` Alexandre Petrescu
2023-08-31 11:39       ` David Lang
2023-08-30 12:02 Hesham ElBakoury

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='CAC=tZ0r+farGZ1jWaZP5YdGBRknRxh+AyehpiNw+7bVj3cOu8w@mail.gmail.com' \
    --to=davidfdzp@gmail.com \
    --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