[Starlink] Main hurdles against the Integration of Satellites and Terrestial Networks

Tue Sep 19 10:55:10 EDT 2023

"I don't see everything, but the news I've heard has been primarily
other companies trying to use regulations to block Starlink, not a
basis for cooperation"

You may have missed this:
https://www.cnbc.com/2023/09/13/spacex-starlink-partners-with-ses-for-combined-cruise-market-service.html

I understand that Starlink is combined as another link, using SD-WAN,
as explained here:
https://www.youtube.com/watch?v=DDM-_MTnRTg

I would expect only latency critical traffic, such as voice and video
calls, to be sent via Starlink, while emails or text messages go via
GEO satellite links.

Regards,

David

> Date: Tue, 19 Sep 2023 07:36:39 -0700 (PDT)
> From: David Lang <david at lang.hm>
> To: Alexandre Petrescu <alexandre.petrescu at gmail.com>
> Cc: Hesham ElBakoury <helbakoury at gmail.com>, David Lang
> 	<david at lang.hm>,  Dave Taht via Starlink
> 	<starlink at lists.bufferbloat.net>, sat-int at ietf.org
> Subject: Re: [Starlink] Main hurdles against the Integration of
> 	Satellites and Terrestial Networks
> Message-ID: <35r3366r-5pr2-83no-716o-7o4r2820n9pn at ynat.uz>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> On Tue, 19 Sep 2023, Alexandre Petrescu wrote:
>
>> Le 19/09/2023 à 02:36, Hesham ElBakoury a écrit :
>> [...]
>>
>>> On Mon, Sep 18, 2023, 5:31 PM David Lang <david at lang.hm
>> [...]
>>
>>> Starlink is just another IP path,
>>
>> Yes.
>>
>> For IPv6 it might not be that simple.  There can be things suggested to
>> starlink to implement, such as to make it better from an IPv6
>> standpoint.  That includes, and is not limited to, this /64 aspect.
>>
>> For IP in general (be it IPv4 or IPv6), as long as starlink stays
>> closed, there might be no interest to suggest anything about IP that
>> they have not already thought of.
>
> Personally, I think that it's more a situation that they are doing something
> that nobody else has done (at least on anything close to this scale) so they
> are
> scrambling to make it work and finding things that the rest of us are just
> speculating about.
>
>> IF on the other hand, starlink feels a need to interoperate, then we can
>> discuss.
>
> interoperate with what is the question.
>
> Interoperate with other ground stations?
>
> include other companies satellites in their space based routing?
>
> Right now there isn't a lot in the way of other space based routing for them
> to
> possibly be interoperable with, and other systems have been actively hostile
> to
> Starlink (I don't know if it's mutual or not, I don't see everything, but
> the
> news I've heard has been primarily other companies trying to use regulations
> to
> block Starlink, not a basis for cooperation)
>
> I also think that it's a bit early to push for standardization of the links.
> We
> don't have enough experience to know what really works on this sort of scale
> and
> dynamic connection environment.
>
>> It is possible that starlink does not feel any need to interoperate now.
>> At that point, the need to interoperate might come as a mandate from
>> some outside factors.  Such factors could be the public-private
>> cooperations.  Other factors could be partnerships that appear when some
>> organisations feel the need to cooperate.  I will not speculate when,
>> but it happens.
>>
>> Assuming that such openness appears, with a need to interoperate, then
>> there certainly will be perspective developped where Starlink is not
>> just another IP path.
>>
>>> all the tools that you use with any other ISP work on that path (or
>>> are restricted like many other consumer ISPs with dynamic addressing,
>>> no inbound connections, no BGP peering, etc. No reason that the those
>>> couldn't work, SpaceX just opts not to support them on consumer
>>> dishes)
>>
>> But, these other ISPs (not Starlink) are all standardized.
>
> they are now, but they have not been in the past, and nothing prevents a
> networking vendor from introducing new proprietary things that only work on
> their equipment and are (hopefully) transparent to users. We actually see
> this
> with caching, 'wan accelerators', captive portals, etc
>
>>> I'll turn the question back to you, what is the problem that you think is
>>>
>>> there that needs to be solved?
>>
>> Here is one, but there are potentially more.  I would not close the door
>> to
>> searching them.
>>
>> I dont have DISHY, so no first hand experience.
>>
>> But I suspect the IPv6 it supports it is an IPv6 encapsulated in IPv4.
>> That
>> adds to latency, not to say bufferbloat.  It brings in a single point of
>> failure too (if it fails, then all fails).
>
> is there some testing that I can do to help you with this?
>
> personally, I suspect that even IPv4 is encapsulated in some way.
>
>> Then, when they'll want to remove that they'd hit into the /64 issue.
>
> I'm not sure exactly what you are referring to here, sorry.
>
> David Lang
>
>> Alex
>>>
>>> David Lang
>>>
>>>> Thanks, Hesham
>>>>
>>>> On Sun, Sep 17, 2023, 12:59 PM David Lang via Starlink <
>>>> starlink at lists.bufferbloat.net
>>> <mailto:starlink at lists.bufferbloat.net>> wrote:
>>>>
>>>>> it's very clear that there is a computer in the dishy that you
>>> are talking
>>>>> to. You get the network connection while the dishy is not connected
>>> to the
>>>>> satellites (there's even a status page and controls, stowing and
>>> unstowing
>>>>> for example)
>>>>>
>>>>> I think we've seen that the dishy is running linux (I know the
>>> routers run
>>>>> an old openwrt), but I don't remember the details of the dishy
>>> software.
>>>>>
>>>>> David Lang
>>>>>
>>>>> On Sun, 17 Sep 2023, Alexandre Petrescu via Starlink wrote:
>>>>>
>>>>>> Date: Sun, 17 Sep 2023 19:21:50 +0200 From: Alexandre Petrescu via
>>>>>> Starlink
>>> <starlink at lists.bufferbloat.net <mailto:starlink at lists.bufferbloat.net>>
>>>>>> Reply-To: Alexandre Petrescu <alexandre.petrescu at gmail.com
>>> <mailto:alexandre.petrescu at gmail.com>>
>>>>>> To: starlink at lists.bufferbloat.net
>>> <mailto:starlink at lists.bufferbloat.net>
>>>>>> Subject: Re: [Starlink] Main hurdles against the Integration of
>>>>> Satellites and
>>>>>> Terrestial Networks
>>>>>>
>>>>>>
>>>>>> Le 16/09/2023 à 01:32, Ulrich Speidel via Starlink a écrit :
>>>>>>> On 16/09/2023 5:52 am, David Lang wrote:
>>>>>>>>
>>>>>>>> In addition to that Ulrich says, the dishy is a full
>>> computer, it's
>>>>>>>> output is ethernet/IP and with some adapters or cable
>>> changes, you
>>>>>>>> can plug it directly into a router.
>>>>>>>
>>>>>>> We've done that with the Yaosheng PoE Dishy adapter - actually
>>> plugged
>>>>>>> a DHCP client straight in - and it "works" but with a noticeably
>>>>>>> higher
>>>>>>> rate of disconnects.
>>>>>>
>>>>>> It is good to know one can plug a DHCP client into the Ethernet
>>> of the
>>>>>> DISHY and receive DHCP replies.
>>>>>>
>>>>>> But that would be only a lead into what kind of DHCPv4 is
>>> supported, or
>>>>> not.
>>>>>>
>>>>>> I would ask to know whether the DHCP server runs on the DISHY, or
>>>>>> whether it is on the ground network of starlink, i.e. the reply
>>> to DHCP
>>>>>> request comes after 50ms, or after 500microseconds (timestamp
>>> difference
>>>>>> can be seen in the wireshark run on that Ethernet).
>>>>>>
>>>>>> This (DHCP server daemon on dishy or on ground segment) has an
>>> impact of
>>>>>> how IPv6  can be, or is, made to work.
>>>>>>
>>>>>> This kind of behaviour of DHCP - basically asking who
>>>>>> allocates an address - has seen a continous evolution in 3GPP
>>>>>> cellular
>>> networks since
>>>>>> they appeared.  Nowadays the DHCP behaviour is very complex in
>>> a 3GPP
>>>>>> network; even in a typical smartphone there are intricacies
>>> about where
>>>>>> and how the DHCP client and server works. With it comes the
>>> problem of
>>>>>> /64 in cellular networks (which some dont call a problem, but I
>>> do).
>>>>>>
>>>>>> So, it would be interesting to see whether starlink has the
>>> same /64
>>>>>> problem as 3GPP has, or is free of it (simply put: can I
>>> connect several
>>>>>> Ethernet subnets in my home to starlink, in native IPv6 that is, or
>>>>> not?).
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>> _______________________________________________ Starlink mailing list
>>>>>> Starlink at lists.bufferbloat.net
>>> <mailto:Starlink at lists.bufferbloat.net>
>>>>>> https://lists.bufferbloat.net/listinfo/starlink
>>> <https://lists.bufferbloat.net/listinfo/starlink>
>