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

[David Lang <david@lang.hm>]

[-- Attachment #1: Type: text/plain, Size: 9240 bytes --]

and I have mwan3 on my openwrt router that routes traffic between different 
ISPs. I haven't added my starlink to it as a 3rd ISP yet, but intend to. Nothing 
special there, and it wouldn't really matter that it's a satellite system vs a 
wireless ISP vs a different wired ISP.

But yes, that is a little bit of cooperation. ( I was thinking more of the other 
LEO ISPs, onelink and Amazon)

David Lang

On Tue, 19 Sep 2023, David Fernández via Starlink wrote:

> "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@lang.hm>
>> To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
>> Cc: Hesham ElBakoury <helbakoury@gmail.com>, David Lang
>> 	<david@lang.hm>,  Dave Taht via Starlink
>> 	<starlink@lists.bufferbloat.net>, sat-int@ietf.org
>> Subject: Re: [Starlink] Main hurdles against the Integration of
>> 	Satellites and Terrestial Networks
>> Message-ID: <35r3366r-5pr2-83no-716o-7o4r2820n9pn@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@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@lists.bufferbloat.net
>>>> <mailto:starlink@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@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>>
>>>>>>> Reply-To: Alexandre Petrescu <alexandre.petrescu@gmail.com
>>>> <mailto:alexandre.petrescu@gmail.com>>
>>>>>>> To: starlink@lists.bufferbloat.net
>>>> <mailto:starlink@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@lists.bufferbloat.net
>>>> <mailto:Starlink@lists.bufferbloat.net>
>>>>>>> https://lists.bufferbloat.net/listinfo/starlink
>>>> <https://lists.bufferbloat.net/listinfo/starlink>
>>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink