"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 <[email protected]> > To: Alexandre Petrescu <[email protected]> > Cc: Hesham ElBakoury <[email protected]>, David Lang > <[email protected]>, Dave Taht via Starlink > <[email protected]>, [email protected] > Subject: Re: [Starlink] Main hurdles against the Integration of > Satellites and Terrestial Networks > Message-ID: <[email protected]> > 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 <[email protected] >> [...] >> >>> 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 < >>>> [email protected] >>> <mailto:[email protected]>> 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 >>> <[email protected] <mailto:[email protected]>> >>>>>> Reply-To: Alexandre Petrescu <[email protected] >>> <mailto:[email protected]>> >>>>>> To: [email protected] >>> <mailto:[email protected]> >>>>>> 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 >>>>>> [email protected] >>> <mailto:[email protected]> >>>>>> https://lists.bufferbloat.net/listinfo/starlink >>> <https://lists.bufferbloat.net/listinfo/starlink> > _______________________________________________ Starlink mailing list [email protected] https://lists.bufferbloat.net/listinfo/starlink
